編集対象
エージェントがツール結果を確認せずに回答する失敗は、三通りに直せる。プロンプトへ確認手順を書く、ワークフローで確認後にしか回答できなくする、実行時へ検証器（validator）を加える、という方法である。同じ失敗でも、どこを書き換えるかによって効果と危険が異なる。
前章では失敗帰属（failure attribution）から修正仮説を作った。本章は、その仮説をどの成果物（artifact）の変更として表すかを扱う。最適化器（optimizer）が書き換えてよい範囲を編集面（edit surface）と呼び、プロンプト、言語モデル（language model, LM）プログラム、メモリ・スキル、ワークフロー、エージェントコード、実行時フック（runtime hook）という保存単位に分ける。これらは一直線の階層ではなく、一つの修正が複数の編集面にまたがることもある。
変更できるものと守るもの
編集面は、ファイル名の一覧だけでは定義できない。次の二つを記述する。
- 構文上の境界: 変更可能なフィールド、モジュール、フック、ファイル
- 意味上の境界: 変更後も守るべきインターフェース、権限、不変条件
たとえばシステムプロンプトを変更可能とするだけでも、出力JSONスキーマ、ツール名、システム方策（system policy）を削除してよいかで探索空間は変わる。実行時フックを変更可能とする場合は、入力型、出力型、タイムアウト、呼び出せるツール、永続化できる状態を固定する必要がある。
編集面を\(\mathcal{H}\)、検証可能なハーネス（harness）集合を\(\mathcal{F}\)とすると、最適化器が探索すべきなのは
\[ H'\in\mathcal{H}\cap\mathcal{F} \]
である。構文上は生成できてもコンパイルできない更新候補（candidate）や、権限方策を破る更新候補は\(\mathcal{F}\)に含めない。
プロンプトとデモンストレーション
最も狭い編集面は、単一の指示やデモンストレーションである。対象モデル（target model）、ツール、制御フローは固定し、入力前に置くテキストだけを変える。
APEはタスク例から指示候補を生成し、タスクスコアで選ぶ (Zhou ほか 2023年)。OPROは過去の指示とスコアの履歴をメタプロンプトへ入れ、次の指示を生成する (C. Yang ほか 2024年)。ProTeGiは誤答への自然言語批評からプロンプト編集を作る (Pryzant ほか 2023年)。RLPromptは対象モデルを固定したまま、離散トークンプロンプトを生成する方策（policy）を学習する (Deng ほか 2022年)。
プロンプト限定編集面には三つの利点がある。
- 差分が短く、人間が読める
- 更新候補間で実行構造とツール権限を揃えやすい
- 元のプロンプトへ戻しやすい
一方、プロンプトは柔らかい制約である。「必ずツール結果を検証する」と書いても、実行時機構がその順序を強制するわけではない。また、ProTeGiの主要評価には最終ビームの複数プロンプトをテスト時に組み合わせる設定が含まれる。永続化した単一プロンプトの改善とテスト時アンサンブルを分けて読む必要がある。
LMプログラムのパラメータ
複数のLM呼び出しをつないだプログラムでは、各モジュールの指示とデモンストレーションを共同で最適化できる。プログラムトポロジーやPythonコードは固定し、テキストパラメータだけを変える編集面である。
DSPyは宣言的なモジュールを持つLMプログラムを、タスク評価指標に合わせてコンパイルする (Khattab ほか 2024年)。MIPROはタスクに基づく指示候補とブートストラップ済みデモンストレーションを作り、多段プログラム全体のスコアをベイズ最適化（Bayesian optimization）で探索する (Opsahl-Ong ほか 2024年)。TextGradは複数ノードの出力へ自然言語フィードバックを逆向きに伝え、上流のテキスト変数を更新する (Yuksekgonul ほか 2025年)。GEPAは複合システムの複数テキスト構成要素を、実行軌跡（trajectory）と評価器（evaluator）のフィードバックから反射的に変異させる (Agrawal ほか 2026年)。
LMプログラムでは、モジュールごとの局所スコアだけを最適化するとエンドツーエンド性能を壊すことがある。検索器が多くのコンテキストを返せば検索再現率は上がるが、下流生成器のコンテキスト予算を圧迫する。したがって、更新候補はプログラム全体を実行して評価する。
メモリ、経験、スキル
メモリ編集面には、保存内容と読み書き方策の二種類がある。
| 種類 | 例 | 永続化するもの |
|---|---|---|
| 内容更新 | 成功実行軌跡、失敗から抽出した洞察 | メモリ項目 |
| 検索更新 | クエリ、順位付け、重複排除、忘却 | 読み出し方策 |
| 書き込み方策更新 | 何を記録・統合・削除するか | 書き込み方策 |
| スキーマ更新 | 経験のフィールド、来歴、信頼度 | メモリ構造 |
| スキル更新 | 手順、例、適用条件 | 版管理したスキル文書 |
ExpeLは学習タスクの成功・失敗実行軌跡を比較し、自然言語の洞察と検索可能な経験を未見タスクへ持ち越す (Zhao ほか 2024年)。これはタスク横断永続メモリの例である。ただし、洞察の追加・削除が外部性能退行テスト一式を通過するわけではない。
SkillOptは、凍結したエージェントが読む単一のスキル文書を限定編集で更新し、保留検証が改善した変更だけを採用する (Y. Yang ほか 2026年)。この保留分割は各ラウンドの採択に使う選択集合であり、最終報告用の封印テスト（sealed test）ではない。スキルは単発のメモリ項目ではなく、後続タスクで再利用する手続き成果物である。プロンプト、メモリ、スキルの区別はファイル名ではなく、誰がいつ読み、どの単位で版化・採用するかで決まる。
単にログを追加するだけでは最適化ではない。メモリ項目や方策を更新候補として比較し、採用した内容を後続タスクへ配るときにハーネス最適化（harness optimization）になる。
ワークフローグラフとモジュール型エージェント
ワークフロー編集面では、LM呼び出し、ツール、検証、分岐、反復をノードとエッジとして変更する。プロンプトでは表現しにくい順序制約を、実行構造として強制できる。
GPTSwarmは言語エージェントをグラフとして表し、エッジ接続やノードプロンプトをタスク損失から最適化する (Zhuge ほか 2024年)。AgentSquareは計画、推論、ツール使用、メモリをモジュールに分け、モジュール進化と再結合で構成を探索する (Shang ほか 2025年)。AFlowはワークフローを実行可能コードとして表し、モンテカルロ木探索で更新候補を生成・評価する (Jiayi Zhang ほか 2025年)。
グラフ表現には、ノードの型とエッジの意味が明示できる利点がある。一方、コードでグラフを表す方法では、見かけ上同じノード集合でも例外処理や状態共有を自由に変更できる。論文名に「ワークフロー」とあっても、実際の編集面が有限グラフなのか任意コードなのかを確認する必要がある。
エージェントシステムコード
エージェントシステムコードを編集面にすると、プロンプト、ツールラッパー、メモリ、制御フロー、エラー処理を同時に変えられる。ADASのMeta Agent Searchは評価済みエージェントプログラムの候補集合（archive）から新しいPython実装を生成し、DGMはコーディングエージェント自身のコードベースと系譜を分岐候補集合へ保存する (Hu ほか 2025年; Jenny Zhang ほか 2026年)。AutoHarnessは環境エラーをフィードバックとして、禁止動作を除く検証器コードを反復的に生成する (Lou ほか 2026年)。
この編集面は表現力が高いが、更新候補の妥当性をスコア評価より前に確認する必要がある。
- 解析またはコンパイルできるか
- 必須インターフェースを実装するか
- タイムアウトと資源上限を守るか
- 禁止ファイルや認証情報へアクセスしないか
- 評価器、テスト、権限方策を変更していないか
- 決定論的に版を再構築できるか
AutoHarnessはさらに、意思決定全体をコード方策へ置き換える設定も報告する。この場合、最適化対象はモデルを補助するハーネスからタスク方策そのものへ移る。コード編集面の広さだけでなく、最終判断をモデルとコードのどちらが担うかも記録する。
実行時ハーネス実装
実行時ハーネスは、モデル呼び出しの前後でコンテキストを組み立て、ツールを仲介し、動作を検証し、失敗から回復する実装である。Meta-Harnessはプロンプトだけでなく、メモリ、検索、コンテキスト提示、オーケストレーションを含むハーネスソースをコーディング提案器で探索する (Lee ほか 2026年)。提案器はファイルシステム上の過去の更新候補、スコア、実行記録（trace）を参照し、新しいコードを生成する。
Harness-R1は実行時機構をライフサイクルフックに分け、失敗実行軌跡からフックパッチ（hook patch）を生成する専用編集器を学習する (Shao ほか 2026年)。パッチはコンパイルと隔離環境検証を通してから適用される。これは実行時編集の直接的な例だが、2026年8月公開の未査読プレプリントであり、一般的な学習済み編集器（learned editor）の確立例とはみなさない。
実行時編集面では、変更対象を「リポジトリ全体」と書くより、フック契約（hook contract）で限定する方が評価しやすい。
| フック | 読める状態 | 変更できる出力 | 固定すべき境界 |
|---|---|---|---|
| コンテキスト前処理 | タスク、許可済みメモリ | コンテキスト | 秘密情報、システム方策 |
| 動作前処理 | 実行軌跡、ツールスキーマ | 動作提案 | ツール許可リスト、引数スキーマ |
| 観測後処理 | ツール結果 | 正規化済み観測 | 生の証拠の保存 |
| 検証 | 更新候補の動作 | 許可 / 拒否 / 修復 | 権限方策 |
| 復旧処理 | エラー、再試行状態 | 再試行 / 代替処理 | 再試行上限、コスト予算 |
複数の編集範囲をまたぐ場合
実際の最適化器は複数の編集面をまたぐ。ADASやMeta-Harnessではコード編集の内部でプロンプトもワークフローも変わり、GEPAは複数のテキスト構成要素を共同で変える。プロンプトだけ、ワークフローだけ、実行時フックだけ、共同変更を同じ評価予算で比較する。広い編集面が勝っても、自由度、更新候補数、最適化器モデルのコンテキスト量が交絡するため、「プロンプト改善」のような単一原因へ帰属させない。
最小の編集範囲から広げる
編集面を選ぶ原則は、最も狭いものを常に使うことではない。失敗を修正でき、かつ十分に検証できる最小編集面を使うことである。
- 指示不足ならプロンプト
- 複数モジュールの協調ならLMプログラムパラメータ
- ツール順序や分岐ならワークフロー
- メモリライフサイクルなら読み書き方策
- インターフェース強制や復旧処理なら実行時フック
- 既存表現で修正不能ならエージェントコード
変更範囲を広げるたびに、妥当性検査、性能退行テスト一式、権限境界、差し戻し成果物も増やす。
要点
編集面はプロンプト、LMプログラム、メモリ、ワークフロー、エージェントコード、実行時フックという重なり得る範囲で記述できる。名称ではなく、実際に変更する成果物、固定インターフェース、永続化単位を確認する。広い編集面ほど強いとは限らず、修正可能性と検証可能性の両方で範囲を決める。