AI が仕事の進め方を正しく説明できることと、その説明に沿って最後まで仕事を進められることは別の能力である。既稿「AI に仕事を任せるには、モデルの外側を設計する」では、生成した答えを現実の仕事へ接続するには、観測、判断、操作、検証を閉じた循環として設計する必要があると整理した[1]。この循環をさらに分解すると、モデルが作った計画や方針と、その方針に従って実際の処理を進める制御機構の間にも境界がある。計画が会話履歴に存在することは、その計画が実行順序や分岐条件を拘束していることを意味しない。
たとえば、ソフトウェア修正で「原因を調査し、問題を再現し、必要な箇所だけを修正し、テストで確認する」という計画を最初に作ったとする。この計画をエージェントが正しく文章化できたとしても、実行時に各操作をその都度選択する構成では、再現確認を省いて修正へ進むことも、テスト失敗後に別の変更を加えて当初の修正範囲から広がることも起こり得る。各時点では直前の観測結果と現在の目的からもっともらしい操作を選べても、その局所判断を積み重ねた軌跡が最初の計画と一致する保証は生じない。
ここには二つの段階がある。第一に、自然言語で書かれた計画はモデルが参照できる情報として保持される。第二に、実行系はその情報を使って次の操作を選ぶ。この第二段階に「再現結果を確認するまで修正へ進まない」「テストが成功するまで完了状態へ遷移しない」といった条件が実装されていなければ、計画は判断材料にはなっても実行制約にはならない。逆に、完了条件や遷移条件を実行系へ組み込めば、モデルが途中で別の操作を提案しても、許可される状態遷移そのものを限定できる。
この差は AI エージェントの性能を読む単位を変える。モデルが何を知っているか、どの計画を生成したかという評価だけでは、失敗が計画生成にあったのか、計画の選択にあったのか、実行途中の逸脱にあったのかを区別できない。実際の仕事では、判断がどの仕組みによって次の計算、ツール操作、状態更新、検証へ変換されたかまで追う必要がある。2026 年 9 月に公開された三つの研究は、計画、計算資源の配分、過去経験という異なる対象について、この変換過程をそれぞれ独立した設計対象として扱っている。
1. 計画を作れることと計画どおり動けることは別である
AI エージェントが扱う仕事では、開始時に存在する情報だけで最後まで処理順序を確定できるとは限らない。コードを変更すればテスト結果が生まれ、検索を実行すれば新しい候補が見つかり、ブラウザーを操作すれば画面状態が変わる。さらに、テスト失敗の内容によっては原因調査へ戻り、検索結果によっては別の候補を調べ、画面遷移によっては利用できる操作そのものが変わる。各操作が新しい状態を作り、その状態が後続判断の入力になるため、長い仕事は固定された手順列より、状態遷移を伴う制御過程として進む。
計画には、この制御過程で到達したい順序や条件を先に整理する役割がある。「原因を確認してから変更する」「変更後に検証する」「検証に失敗した場合は完了としない」といった関係を明示すれば、個々の操作を一つの仕事として結び付けられる。ただし、自然言語として計画を書いた時点では、それぞれの条件はまだ実行系の規則にはなっていない。モデルは計画文と現在の観測結果を同時に受け取り、その都度次の操作を生成するため、局所的には妥当に見える別の操作を選択できる。
| 状態 | 計画の置かれ方 | 実行時に起こること |
|---|---|---|
| 宣言 | 「調査、再現、修正、検証」のような方針が自然言語として保持される。 | 後続判断から参照できるが、各段階を通過する順序や完了条件はモデルの判断に残る。 |
| 制御 | 各段階の開始条件、完了条件、遷移条件が実行系へ組み込まれる。 | 再現確認前の修正や、検証失敗後の完了など、許可しない状態遷移を機構として遮断できる。 |
| 検証 | 宣言した計画と実際の操作履歴を別々の情報として記録する。 | 計画そのものの選択ミスと、妥当な計画から実行中に逸脱した失敗を分離して観測できる。 |
三つの状態は、それぞれ異なる問いに対応する。宣言を見れば、エージェントがどの手順を妥当だと判断したかが分かる。制御を見れば、その判断が実際の操作可能範囲へどこまで反映されたかが分かる。検証を行えば、宣言と実行の差を結果から逆算するのではなく、軌跡そのものから確認できる。最終的に同じ失敗へ到達した場合でも、「誤った計画を選んだ」「正しい計画を選んだが途中で逸脱した」「計画には従ったが各操作の内容が誤っていた」では、修正すべき場所が異なる。
計画を詳しく書くことは、宣言段階の情報量を増やす。実行忠実性を高めるには、その情報のうちどの条件を実行系が強制し、どの判断をモデルへ残すかという別の設計が必要になる。すべての手順を固定すれば、観測結果に応じて方針を変える柔軟性まで失われる。一方で、すべてをモデルの局所判断へ任せれば、長い作業ほど当初の計画との対応を維持する負担が増える。計画能力を評価するときには、計画文の品質に加えて、計画がどのような制御構造へ変換され、実際の軌跡をどこまで拘束したかを見る必要がある。
2. AI エージェントには判断を行動へ変換する層がある
既稿「最新 AI は何が変わったのか 2026」では、AI の性能をモデル能力、コンテキスト、推論制御、ツール実行、エージェント実行といった複数の層へ分けた[2]。この分解を仕事の実行へ当てはめると、モデルが生成した判断と、外部環境で実際に起きる変化の間にも複数の処理が存在する。記憶から必要な情報を取り出し、利用可能な操作手段を選び、現在状態に応じて実行順序を決め、操作結果を次の判断へ戻す処理である。モデル出力は、この一連の処理へ渡される入力の一つとして位置付けられる。
Cognitive Architectures for Language Agents は、言語エージェントを、記憶、構造化された行動空間、行動を選択する意思決定過程から成る認知アーキテクチャとして整理した[3]。ReAct は、推論と行動を交互に行い、外部環境から得た観測を後続の推論へ戻す構造を示した[4]。両者に共通するのは、モデルが一度生成した文章だけで処理を完結させず、現在状態を観測しながら次の行動を選び直す構造である。エージェントの仕事は、一回の生成結果ではなく、判断、操作、観測を繰り返す状態遷移として進む。
たとえば、モデルが「テストを実行すべきだ」と判断しただけでは、テスト結果は得られない。実行系には、対象プロジェクトを特定し、利用可能なテスト手段を選び、必要な作業ディレクトリや権限を設定し、コマンドを実行し、終了状態と出力を取得する処理が必要になる。その後、取得した結果から「成功した」「特定のテストが失敗した」「テスト自体を開始できなかった」といった現在状態を構成し、その情報を後続判断へ戻す。判断が一つの操作へ変換され、その操作が新しい観測を生み、観測によって次の判断条件が変わる。
この過程では、同じ最終的な失敗でも発生箇所によって意味が異なる。「テストが必要だ」と判断できなかった場合は判断段階の失敗である。必要性を認識していても誤ったテストコマンドへ割り当てれば変換段階で失敗する。正しいコマンドを選んでも権限不足や環境不整合で実行できない場合は実行段階の問題になる。さらに、テストが失敗しているのに出力を誤って成功と解釈すれば、観測から状態を構成する段階で誤りが入る。最終結果だけを見ると同じ「検証に失敗した」という状態でも、修正対象はそれぞれ異なる。
| 層 | 入力 | 役割 | 典型的な失敗 |
|---|---|---|---|
| 判断 | 目的、現在状態、制約、過去の観測を受け取る。 | 次に必要な処理、優先順位、停止条件を選ぶ。 | 調べる対象を誤る、不要な処理を優先する、完了条件を早く満たしたと判断する。 |
| 変換 | 判断された方針や計画を受け取る。 | 方針を具体的な制御フロー、ツール操作、状態遷移へ割り当てる。 | 正しい方針を選んでいても、実行順序や利用する操作手段へ正しく反映されない。 |
| 実行 | 具体化された操作と現在の環境を受け取る。 | ファイル、画面、外部サービスなどへ操作を加え、環境状態を変える。 | 権限不足、対象の取り違え、操作失敗、外部サービス側の制約によって意図した状態へ到達しない。 |
| 観測 | 操作後の環境状態と実行結果を受け取る。 | 後続判断で利用できる現在状態へ整理する。 | 古い状態、不完全な結果、誤った要約を現在状態として採用し、後続判断の前提を崩す。 |
この分解によって、モデル能力と実行系の設計を別々に評価できる。同じモデルが同じ計画を生成しても、その計画を毎回の判断材料として読むだけの構成と、計画上の段階や分岐を制御フローとして実装する構成では、許可される行動系列が変わる。前者では各時点のモデル判断が実行順序を書き換えられる。後者では、モデルが選択できる範囲そのものを現在の状態に応じて限定できるため、計画と実際の軌跡の対応を構造として維持できる。
エージェントの性能を「どのモデルを使ったか」だけで説明すると、この差は観測できない。実際には、判断をどの操作へ割り当てるか、どの状態を保存するか、どの結果を次の判断へ渡すかという実行層の設計が、モデル内部で生成された方針を現実の軌跡へ変換する。計画の妥当性を評価するだけでなく、その計画がどの実行機構を通って行動へ変わったかを追うことで、モデルの判断能力とシステムの実行能力を分離して扱える。
3. 計画は文章として渡すだけでは制御フローにならない
Do LLM Agents Execute the Plans They Declare? は、計画を宣言することと、その計画構造に沿って実行することの差を Plan Declaration–Execution Gap として測定した研究である[5]。研究では、計画方式を Predefined、Sequential、Hierarchical、Search の四つに分け、モデルが方式を宣言した後、その計画を汎用 ReAct 実行器へ渡す条件と、宣言した方式に対応する専用実行器へ振り分ける Planning-as-Routing を比較した。両条件で計画方式そのものは明示されているため、差が生じる場所を「計画を作れるか」より後段へ絞り込める。
Plan+ReAct では、宣言した計画はコンテキストに残るが、実際の制御は各時点で次の行動を生成する ReAct の反復として進む。たとえば Hierarchical を選んでも、親タスクと子タスクの関係を実行器が状態として保持し、子タスクの完了を親タスクの遷移条件として強制するわけではない。モデルは計画文を参照しながら行動できる一方で、その時点の観測や局所的な判断によって別の順序へ進む余地を持つ。
この条件で、ALFWorld、Mind2Web、SWE-bench Verified において宣言した計画構造を維持した軌跡は、全体として 22〜45% にとどまった[5]。さらに、宣言した計画が長くなるほど構造維持率は低下した[5]。計画が長くなると、後続の各判断で守るべき関係や順序も増える。そのすべてを自然言語の文脈として保持し、各ターンで再解釈する構成では、局所判断の積み重ねによって当初の構造から外れる機会も増える。
Planning-as-Routing では、宣言された計画方式を単なる説明として保持するのではなく、対応する実行器の選択へ使う。Search を選べば探索用の制御構造、Hierarchical を選べば階層的な制御構造が実行過程を担当する。ここでは、計画方式が「モデルが覚えておくべき文章」から「許可される状態遷移を決める実装」へ変わる。論文の主要比較では、ALFWorld の成功率が Plan+ReAct の 0.48 から 0.92 へ、SWE-bench Verified では 0.36 から 0.44 へ上昇した[5]。
この比較で変更されている中心部分は、モデルへ追加の説明を与えたことではなく、宣言した方式と実行器を対応付けたことである。同じ計画情報を持っていても、その情報を毎回モデルが解釈する構成と、実行器が制御構造として保持する構成では、途中で変更できる範囲が異なる。計画を文章として保存する方式では逸脱の抑制をモデル判断へ依存し、専用実行器を使う方式では一部の制約を実装側へ移せる。
計画と実行の関係を別の方法で測った研究もある。From Plan to Action は、SWE-agent の軌跡を分析し、明示的な計画、計画の質、計画を再提示するリマインダーと、実行時の計画遵守やタスク成功との関係を調べた[6]。Plan-and-Act は、高水準の計画を担当する Planner と、個々の操作を担当する Executor を分離し、長いタスクで計画生成と実行を異なる役割として扱う[7]。両者は実装方法こそ異なるが、計画文を生成した時点で計画能力の評価を終えず、その後の軌跡との対応を測るという点で共通している。
| 方式 | 計画の扱い | 実行構造 | 分離できる評価 |
|---|---|---|---|
| Plan+ReAct | 宣言した計画を自然言語として実行器のコンテキストへ渡す。 | 各時点で汎用 ReAct が観測結果から次の行動を選ぶ。 | 計画が文脈に存在する状態で、宣言した構造が実際の軌跡へどこまで残るかを測れる。 |
| Planning-as-Routing | 宣言した計画方式を実行器の選択条件として使う。 | 方式ごとの専用実行器が状態遷移と制御フローを担当する。 | どの方式を選ぶかという判断と、選んだ方式を忠実に実行する能力を分けて測れる。 |
ただし、実行構造を専用化すると別の判断が前面に出る。同研究では、最も高い成功率を出す計画方式がベンチマークやモデルによって異なり、モデル自身による方式選択は、最も成績の高い固定方式へ安定して到達しなかった[5]。つまり、Planning-as-Routing は「選んだ方式をどう実行するか」という問題を実行器へ移せる一方で、「どの方式を選ぶか」という上位の選択問題を残す。
この結果から、計画能力は少なくとも三つに分けて評価できる。候補となる計画方式を生成する能力、その中から現在のタスクに合う方式を選ぶ能力、選んだ方式を実際の軌跡として維持する能力である。最終成功率だけを見ると三つは一つの数値へ畳み込まれるが、計画宣言と実行構造を分離すれば、失敗が選択にあるのか、実行忠実性にあるのかを特定できる。計画を制御フローへ変換するという設計は、計画問題を消すのではなく、計画の生成、選択、実行を別々の評価対象へ分解する。
4. 長い作業では次に何を計算するか自体が問題になる
Thinking Before Thinking は、対象問題を解く処理と、その処理へ計算資源をどう配分するかを分離した[8]。Worker は証明、推論、コード修正などの対象作業を担当し、Controller は Assess、Propose、Evaluate、Dispatch の四段階で実行過程を制御する。Assess では現在までに得られた成果と未解決部分を整理し、Propose では次に試す計算候補を作り、Evaluate では残り予算を使う価値を比較し、Dispatch では選んだ作業と必要な情報を Worker へ渡す。対象問題を直接解く計算と、「次にどの計算を実行するか」を決める計算を別の役割へ分けた構成である。
この分離が意味を持つのは、長い作業では計算回数を増やすだけで有効な探索が増えるとは限らないためである。途中で有望な仮説が見つかっても、その後も価値の低い候補へ同じ量の計算を割り当てれば、追加予算は成果へ結び付きにくい。逆に、失敗した経路を早く打ち切り、既に得られた途中成果を別の探索へ再利用できれば、同じ呼び出し回数でも計算の使われ方が変わる。計算予算の大きさと、その予算をどの分岐へ配分するかは別の変数になる。
ProgramBench で GPT-5.5 を使った実験では、Meta-Reasoning の名目上限を 400 回から 1200 回へ増やすと、成功率は 64.1% から 71.5% へ上昇した[8]。一方、Direct Control は同じ範囲で約 64% にとどまり、1200 回の主要条件では Meta-Reasoning が 71.5%、Direct Control が 63.7% だった[8]。論文は外部比較として Codex の 58.0% も示している[8]。
この比較では、Controller の処理も無料ではない。論文では Controller と Worker のモデル呼び出しをすべて同じ名目上の呼び出し予算に含めており、Assess、Propose、Evaluate、Dispatch に使う呼び出しも計算予算を消費する[8]。その状態でも予算増加に対する性能の伸び方が Direct Control と異なったため、この実験条件では、追加呼び出しの量だけでなく、途中成果の評価、候補の選別、探索の継続や停止といった配分規則が結果に関係している。ただし名目上のモデル呼び出し回数をそろえた比較であり、総トークン数、実時間、計算資源まで同一にした効率比較ではない。
候補を増やすことと、候補から正しいものを選ぶことが別の能力である点は、Repeated Sampling を大規模に調べた Large Language Monkeys でも確認されている。同研究では、生成回数を増やすと候補集合のどこかに正解が含まれる割合、すなわち正答包含率は上昇する一方、その集合から正答を選択する能力が別の制約として残る[9]。正解候補を一度生成できたとしても、選択段階で別の候補を採用すれば最終結果には反映されない。探索能力と選択能力を一つの成功率へまとめると、どちらが律速しているかを判別できなくなる。
Thinking Before Thinking は、この分離を一回の候補選択から長時間エージェントの実行過程へ広げている。Controller が扱う対象には、次の候補を作ることだけでなく、現在の進捗を評価すること、以前の成果を再利用すること、探索を別方向へ分岐させること、残り予算に対して継続価値が低い処理を止めることが含まれる。つまり、長い作業では「何を計算できるか」と同時に、「得られた途中状態から次の計算をどう選ぶか」が性能を左右する。
この制御には記憶の扱いも関係する。作業が長くなるほど、過去のすべての観測、仮説、失敗、途中成果を毎回現在のコンテキストへ戻す方法は、利用可能なコンテキスト量と再読コストの両方を消費する。MemGPT は、限られたコンテキストウィンドウの外側に複数層の記憶を配置し、必要な情報を現在の文脈へ移動させる仮想コンテキスト管理を提案した[10]。情報を保持する場所と、現在の推論へ載せる情報を分離することで、長期記憶と短期的な作業文脈を別々に管理する構成である。
Meta-Reasoning でも、途中成果は永続的な artifact memory に保存され、Controller は現在の判断に必要な状態を使って後続作業を組み立てる[8]。過去成果を保存するだけでは再利用は起こらず、どの成果を現在の候補評価へ戻すかを選ぶ必要がある。ここで記憶管理は保存容量の問題から、計算予算の配分問題へ接続する。何を残すか、何を現在状態へ戻すか、何を再計算せず使い回すかによって、その後に必要なモデル呼び出しも変わる。
| 対象 | 量だけを増やした場合 | 制御を分離した場合 | 残る評価問題 |
|---|---|---|---|
| 候補 | より多くの候補を生成し、正解を含む可能性を上げる。 | 途中結果から候補の価値を比較し、追加探索する方向を選ぶ。 | 正解候補を生成できたかと、その候補を正しく選択できたかを分けて測る必要がある。 |
| 計算予算 | 同じ制御方式のままモデル呼び出し回数を増やす。 | 残り予算と進捗を見ながら、継続、分岐、再利用、停止へ配分する。 | 追加計算の量と、追加計算を割り当てた場所の効果を分ける必要がある。 |
| 過去成果 | 履歴を現在のコンテキストへ戻し、モデルに再読させる。 | 成果を外部記憶へ保持し、現在の判断に必要な部分を選んで再利用する。 | 保存できたかに加えて、必要な成果を適切な時点で取り出せたかを評価する必要がある。 |
長時間エージェントでは、対象問題を解く計算と、その計算を管理する処理が並行して必要になる。追加予算が性能へ反映されるためには、進捗を観測し、探索候補を比較し、過去成果を再利用し、継続価値の低い処理を止める機構が必要になる。実行構造は計画順序を守るための枠組みであると同時に、限られた計算資源をどの処理へ割り当てるかを決める配分機構としても働く。
5. 経験は文章として渡すだけでなく実行環境へ変換できる
Learning Meta-Skills for Agent Harness Design in Test-Time AI4AI は、実行構造へ変換する対象を、現在の計画から過去の経験へ広げている[11]。この研究では、Builder が Target の開発用タスクにおける実行履歴と結果を観察し、どの状況で支援が必要になるか、どの資源を用意すべきか、その資源を Target がどのように利用すべきかという Meta-Skill を抽出する。未見タスクでは、その Meta-Skill を基に、指示、記憶、コンテキスト、ツール、Controller、検証器、作業環境などを組み合わせた Harness を構築する。経験から得た知識を、そのまま次の入力へ追加するのではなく、Target が動く環境の構成へ変換する点に特徴がある。
この構成では、経験の再利用が二段階に分かれる。第一段階では、過去の軌跡から「どの条件で失敗しやすいか」「何を補助するとよいか」という一般化された Meta-Skill を取り出す。第二段階では、その原則を未見タスク向けの具体的な Harness へ変換する。たとえば、ある種類の失敗に検証不足が関係していると判断した場合、その知見を「必ず検証すること」という文章として Target に渡す方法もあれば、検証器を Harness に組み込み、一定の結果を満たすまで完了状態へ進めない構成にする方法もある。前者では知識の適用が Target の判断に残り、後者では知識の一部が実行条件へ移る。
研究では、この差を直接比較するため、同じ Meta-Skill 群を Target へ文章として渡す条件も用意している。GPT-5.6-Sol を Builder とし、Gemini-3.6-Flash、Qwen3.8-Flash、GPT-OSS-120B を Target として Harness-Bench と NewtonBench を評価したところ、すべての Meta-Skill を利用する Builder のマクロ平均は 65.31% だった[11]。Meta-Skill を利用しない Builder の 56.36% に対して 8.95 ポイント高く、同じ Meta-Skill 群を Target へ直接渡す条件の 53.29% に対しては 12.02 ポイント高かった[11]。
比較対象に含まれる知識を同じ Meta-Skill 群にそろえているため、少なくともこの実験では「知識を持っているか」だけでは差を説明できない。Target が Meta-Skill を文章として受け取る条件では、その原則を現在のタスクへ対応付け、必要な操作を選び、適用時点を判断し、実行結果を再評価する処理まで Target が担う。Builder が Harness へ変換する条件では、その一部をツール、状態、検証、制御フローとして事前に配置できる。研究内の六つのモデルとベンチマークの組み合わせでは、Builder が Harness を構築する条件が、同じ Meta-Skill 群を直接提示する条件をすべて上回った[11]。
この結果から読み取れるのは、経験の内容と経験の配置を分けて評価する必要性である。同じ「テストを確認する」「外部情報を取得する」「途中結果を保持する」という知識でも、自然言語として Target に解釈させる場合と、検証器、ツール、記憶、Controller として外部化する場合では、実行時に Target が処理すべき範囲が変わる。外部化された部分では、毎回同じ原則を再解釈する必要が減り、Harness が許可する操作や状態遷移によって一定の振る舞いを再現できる。一方、Harness に表現されていない判断や、タスク固有の例外処理は Target に残る。
この発想には連続した研究系統がある。AI4AI at Test-Time は、強い Builder が弱い Target のために推論時 Harness を構築し、Target のパラメーターを更新せずに能力を移す構成を調べた[12]。Meta-Harness は Harness のコード自体を探索対象とし、過去候補のソースコード、評価値、実行軌跡を使って外側から Harness を最適化する[13]。Evo-Harness は、単発の実行軌跡に含まれる成功要因とノイズを分けながら再利用可能な Harness を作り、凍結されたエージェントが逐次タスクを通して Harness を更新する構成を扱う[14]。
これらの研究では、改善対象がモデル重みの外側に置かれている。Target の内部パラメーターを変えず、どのツールを与えるか、どの状態を保存するか、どの検証を強制するか、どの順序で処理を進めるかを更新することで、同じ Target の実行軌跡を変える。経験から得た改善点をモデル内部へ圧縮する代わりに、モデルが接続する実行環境へ保持する構成である。
一方、経験を再利用する方法は Harness に限られない。Agentic Context Engineering は、実行フィードバックから指示、戦略、証拠を含むコンテキストを段階的に更新する[15]。ExpeL は、過去の経験から自然言語の知識を抽出し、後続タスクで過去経験や一般化された知見を推論時に再利用する[16]。これらを Harness 系の研究と並べると、経験は同じ形式で保存されるわけではなく、自然言語の知識、更新されたコンテキスト、実行可能な支援機構という異なる場所へ配置できる。
| 経験の配置 | 再利用方法 | 実行時に Target が担うこと | 外部へ移せること |
|---|---|---|---|
| 自然言語の知識 | 経験から得た原則、注意点、成功条件を Target の入力へ追加する。 | 現在の状況に合う原則を選び、具体的な操作へ変換し、適用時点を判断する。 | 過去経験を再読せず、抽出済みの知識として参照できる。 |
| 更新されたコンテキスト | 有効だった戦略、証拠、途中状態を蓄積し、後続実行から参照できる状態へ整える。 | 蓄積された情報のうち何を現在タスクへ適用するかを判断する。 | 経験の保存、整理、検索を現在の一回の推論から分離できる。 |
| Harness | 経験から得た原則をツール、状態管理、検証器、制御フローとして実装する。 | Harness に表現されていない判断、例外処理、タスク固有の選択を担当する。 | 反復して必要になる操作、検証条件、状態遷移の一部を実行系へ固定できる。 |
三つの配置は、経験を保存する形式だけでなく、後続タスクで誰がその経験を実行へ変換するかが異なる。自然言語として保存すれば、Target が毎回意味を解釈して操作へ落とし込む。コンテキストとして整理すれば、必要な情報へのアクセスは改善できるが、適用判断は Target に残る。Harness として実装すれば、経験の一部を状態遷移や検証条件として実行系へ移せる。経験の再利用能力を評価するときには、何を学んだかと同時に、その知識がどこへ配置され、どの段階まで実行可能な構造へ変換されたかを見る必要がある。
モデルの重みを固定していても、経験の配置を変えればシステム全体の挙動は変化する。ここで更新されるのはモデル内部のパラメーターではなく、モデルが参照する情報、利用できる操作、通過する検証、許可される状態遷移である。経験から得た知識を次の入力へ追加する方法と、その知識を実行環境へ組み込む方法を分けることで、AI エージェントの改善を「モデルが何を覚えたか」だけでなく、「過去の経験が次の実行をどのように拘束する形へ変換されたか」として評価できる。
6. 実行構造を作っても選択と監視の失敗は残る
三つの研究を並べると、実行構造へ判断を外部化した後にも別の失敗点が残ることが分かる。Planning-as-Routing では、専用実行器によって選択済みの計画方式を構造として維持できても、モデル自身がタスクに適した方式を安定して選べるとは限らなかった[5]。Meta-Reasoning では、Controller が進捗と候補価値を評価して計算予算を配分するため、その評価を誤れば、有望な経路を早く打ち切ったり、価値の低い経路へ呼び出し回数を使ったりする。Meta-Skill の研究でも、学習した支援の効果はタスク分類ごとに一様ではなく、Harness-Bench では分類によって改善と悪化が混在した[11]。
共通しているのは、判断を実行構造へ移すと判断そのものが消えるのではなく、判断が必要になる場所が変わることである。たとえば、Sequential や Hierarchical といった計画構造を専用実行器に持たせれば、各ターンで「元の計画へ戻るべきか」をモデルが再判断する必要は減る。その代わり、タスク開始時または途中状態に応じて、どの実行器を使うかという選択が上位に残る。局所的な計画遵守を決定的な制御へ移した結果、失敗点は実行忠実性から方式選択の品質へ移動する。
進捗管理でも同じ構造が生じる。専用 Controller を設ければ、Worker が対象問題を解きながら同時に全探索履歴を整理する負担を分離できる。しかし Controller は、どの途中成果が有望か、どの候補へ追加計算を使うか、どの時点で停止するかを判断しなければならない。進捗管理を独立させることで観測可能性は高まる一方、その観測結果から正しい配分判断を作る能力が新しい律速要因になる。外部化は判断を削除する操作ではなく、判断対象をより明示的な場所へ移す操作として働く。
検証器でも同じである。出力形式、終了コード、数値条件、テスト成否のように機械判定できる条件を検証器へ移せば、その確認をモデルの自己評価へ任せる必要は減る。ただし、何を合格条件として定義するか、どこまでを機械判定へ含めるかという設計判断は残る。誤った検証条件を固定すれば、実行時には一貫して誤った判定を強制することになる。判断を決定的な機構へ移すほど、その機構へ埋め込んだ条件の妥当性が結果へ直接反映される。
| 外部化するもの | 減らせる判断 | 残る判断 | 新しい失敗点 |
|---|---|---|---|
| 計画構造 | 各段階で元の計画構造を維持するかを毎回判断する負担を減らせる。 | タスクに適した計画方式や実行器の選択が残る。 | 適切でない方式を選ぶと、その構造を忠実に実行しても最終成果が悪化する。 |
| 進捗管理 | 過去成果の整理、候補比較、残予算の管理を専用 Controller へ集約できる。 | 進捗評価、候補価値、継続、分岐、停止の判定が残る。 | 進捗を誤認すると、有望な探索を停止したり低価値の探索へ予算を割り当てたりする。 |
| 検証 | 形式、数値、状態、テスト成否など決定的に確認できる条件をモデル判断から分離できる。 | どの条件を検証対象とし、何を合格とするかという設計判断が残る。 | 不適切な条件を固定すると、誤った判定を一貫して強制する。 |
| 記憶 | 全履歴を毎回読み直し、現在の推論だけで保持する負担を減らせる。 | 何を保存し、何を検索し、どの情報を現在コンテキストへ戻すかが残る。 | 必要な情報を保存していても、適切な時点で取り出せなければ後続判断へ利用されない。 |
この表で共通するのは、外部化によって一つの判断負荷を減らすと、その判断を設定、選択、監視する上位の判断が残ることである。計画構造を固定すれば方式選択が重要になり、Controller を導入すれば監視と選択が重要になり、検証器を導入すれば検証契約の設計が重要になる。記憶を外部化すれば、保存容量より取り出し方の選択が結果を左右する。実行構造の追加は、失敗可能性を単純に減らすのではなく、失敗が発生する場所を変える。
設計上の中心は、モデル判断と決定的機構の境界をどこに置くかにある。状態遷移や検証条件を広く固定すれば、宣言した方針からの逸脱は抑えやすくなる一方、想定外の観測に応じて経路を変更する余地も狭くなる。反対に、多くの判断をモデルへ残せば環境変化には適応しやすいが、計画遵守、停止条件、検証基準まで毎回再解釈する負担が増える。この境界の適切な位置は、タスクで許容される自由度、失敗時の損失、利用するモデル、計算予算によって変わる。
三つの研究が示しているのは、実行構造を増やすほど一方向に性能が改善するという関係ではない。実行構造は、どの判断をモデルの確率的な選択へ残し、どの判断を状態、ルーター、Controller、検証器として固定するかを明示する手段である。評価するときにも、最終成功率だけでなく、方式選択、進捗監視、候補選択、検証条件、記憶検索のどこで誤りが生じたかを分けて見る必要がある。
7. 最終成功率だけではエージェントの能力を説明できない
実行構造を分解すると、評価指標も一つの最終成功率へ集約しにくくなる。成功率が 60% だったとしても、残り 40% が計画選択、計画逸脱、環境観測、ツール実行、候補選択、検証、停止判断のどこで生じたかは、その数値だけでは分からない。さらに、同じ失敗率でも、計画段階で誤った方式を選んだシステムと、妥当な計画を立てながら実行中に逸脱したシステムでは改善すべき場所が異なる。評価には、最終的な成否に加えて、失敗がどの処理段階で発生したかを追跡できる指標が必要になる。
Harness-Bench は、この問題をモデルと Harness の組み合わせ単位で扱う[17]。隔離環境で実行する 106 個のタスクを使い、モデル単体ではなく、コンテキスト、ツール、状態、制約、権限、追跡、回復を担う Harness と組み合わせて評価する。5,194 の実行軌跡から、完了率だけでなく過程品質、効率、失敗挙動の差を調べることで、同じモデルでも Harness の構成によって実行結果が変わることを測定している[17]。この評価単位では、「どのモデルを使ったか」だけでなく、「そのモデルがどの状態を見て、どの操作を許可され、どの制御と回復機構の中で動いたか」まで実験条件に含まれる。
この違いは、失敗原因の切り分けに直接関係する。たとえば、モデルが適切な修正方針を生成していても、Harness が必要なファイルを観測できなければ実行は失敗する。正しい操作を選んでも、権限設定によってツールが実行できなければ成果へ到達しない。操作そのものが成功しても、実行後の状態を Harness が正しく取得できなければ、モデルは古い状態を前提に次の判断を行う。同じモデルの成功率が環境によって変わる場合、その差をモデル内部の能力へ直接帰属させるには、こうした実行条件を統制する必要がある。
AgentBoard は、最終成功率に加えて、タスクの途中でどこまで進んだかを測る進捗率を導入した[18]。最終状態に到達しなかった軌跡でも、必要な中間目標をどこまで満たしたかを観測することで、完全な失敗と部分的な進展を区別できる。長いタスクでは、この差が重要になる。最初の数段階で停滞した実行と、最終検証の直前まで進んだ実行は、どちらも最終成功率では 0 と記録されるが、必要な改善は同じではない。
AgentDiagnose は、さらに軌跡を複数の能力へ分けて診断する[19]。探索と後戻り、タスク分解、観測読解、自己検証、目的品質といった観点から実行過程を見ることで、「失敗した」という一つの結果を、どの判断や状態更新で崩れたかへ分解する。たとえば、必要な情報を一度取得できていたのに後続判断で利用しなかった場合と、そもそも必要な情報へ到達できなかった場合では、最終結果は同じでも原因は異なる。軌跡を残すことで、生成、選択、観測、検証を別々の故障点として扱える。
既稿「AI の『正しい』を決める検証契約」では、AI の出力を受理する条件を、検証対象、検証単位、判定規則、保証範囲へ分けた[20]。エージェント評価でも、最終成果物の正しさと、成果へ至る過程の妥当性は別の情報を与える。最終成果物が正しくても、途中で禁止された操作を行っていれば運用上は受理できない場合がある。反対に、計画を忠実に守り、必要な検証まで実行しても、外部サービスの障害によって最終成果だけ得られない場合もある。成果物評価と過程評価を分けることで、システムが「正しく終わったか」と「正しい手順で進んだか」を別々に確認できる。
| 評価対象 | 観測する問い | 失敗時に切り分けられること | 改善対象 |
|---|---|---|---|
| 計画生成 | 目的と制約に合う計画や方式を作れたか。 | 実行前の方針自体に誤りがあったかを確認できる。 | 計画生成、方式候補、前提条件の読み取りを見直せる。 |
| 方式選択 | 複数の実行方式から現在のタスクに適したものを選べたか。 | 候補は妥当でも方式選択で誤ったケースを分離できる。 | 選択規則、タスク分類、方式ごとの適用条件を見直せる。 |
| 実行忠実性 | 宣言した計画構造を実際の軌跡が維持したか。 | 計画自体の問題と実行器による逸脱を分離できる。 | 制御フロー、遷移条件、実行器の実装を見直せる。 |
| 進捗監視 | 途中成果、未解決点、現在状態を正しく認識したか。 | 誤った状態認識から後続判断が崩れたケースを確認できる。 | 観測方法、状態表現、Controller の評価規則を見直せる。 |
| 候補選択 | 生成済みの候補から適切なものを採用できたか。 | 正答候補を生成できていたのに選択で失敗したケースを分離できる。 | 比較規則、評価器、再検討条件を見直せる。 |
| 検証 | 完了条件、制約、出力品質を必要な範囲で確認したか。 | 未完成状態を完成として受理した失敗や、誤った合格判定を分離できる。 | 検証対象、判定規則、検証器の配置を見直せる。 |
| 最終結果 | 要求された成果と完了条件を最終的に満たしたか。 | システム全体として実用上の目的を達成したかを確認できる。 | 上位の各評価結果と対応付けて、どの層の改善が成果へ影響するかを判断できる。 |
このように評価を層へ分けると、同じ失敗でも原因に応じて異なる改善を選べる。計画生成で失敗しているなら実行器を複雑にしても直接の改善にはならない。計画は妥当でも実行忠実性が低いなら、計画生成モデルを変更するより制御フローを見直す方が原因に近い。候補を生成できているのに選択で失敗している場合は、追加生成より評価器や選択規則の改善が必要になる。評価指標を分解することは、性能を細かく見せるためではなく、観測した失敗と修正対象を対応付けるために必要になる。
モデル能力はこの評価の中でも中心的な要素である。ただし、観測された成功率は、モデルの生成能力、利用できるコンテキスト、実行器、状態管理、権限、検証、回復処理が組み合わされた結果として現れる。モデルがどの Harness の中で、どの判断を担当し、どの情報と操作へアクセスし、どの条件を通過して完了へ到達したかまで記録して初めて、成功率の差を具体的な原因へ結び付けられる。AI エージェントの評価単位は、モデル名だけではなく、モデルと実行構造が作る一つの動作系として捉える必要がある。
8. AI エージェントの能力は方針と実行構造の対応で読む
三つの研究は、扱う対象こそ異なるが、情報を実行可能な構造へ変換するという同じ種類の問題を扱っている。Do LLM Agents Execute the Plans They Declare? は、モデルが宣言した計画方式を、対応する専用実行器へ割り当てる[5]。Thinking Before Thinking は、現在の進捗、途中成果、残り予算を、次にどの Worker へどの処理を任せるかという計算資源配分へ変換する[8]。Learning Meta-Skills for Agent Harness Design in Test-Time AI4AI は、過去経験から得た支援原則を、記憶、ツール、検証器、Controller、作業環境を含む Harness へ変換する[11]。入力は計画、現在状態、過去経験と異なるが、いずれも自然言語や内部状態として存在する情報を、後続の行動を実際に制約する仕組みへ対応付けている。
この対応が必要になる理由は、情報を保持することと、その情報に従って状態を遷移させることが別の処理だからである。計画がコンテキストに保存されていても、汎用の実行ループが各ターンで次の操作を独立に選べば、局所的に妥当な判断を積み重ねながら当初の計画から逸脱できる。正しい候補を一度生成できても、進捗評価や候補選択を誤れば、その候補へ追加計算を割り当てられず最終成果へ反映されない。過去経験から有効な原則を抽出しても、その原則をどの状況で適用し、どの操作へ変換するかを毎回 Target 自身が判断する構成では、経験の利用成否もその時点のモデル判断へ依存する。
三つの事例を並べると、エージェントの実行過程には少なくとも「情報を作る」「情報を実行構造へ対応付ける」「その構造の中で操作する」という段階があることが分かる。計画生成は最初の段階に属し、Planning-as-Routing は二段階目を明示する。Worker は三段階目で対象作業を実行し、Meta-Controller は途中状態を再び二段階目へ戻して後続の計算を組み替える。Meta-Skill Builder は過去の軌跡から新しい支援原則を作り、それを Harness へ変換することで、次のタスクにおける二段階目の構造そのものを更新する。
| 入力 | 変換を担うもの | 実行側での表現 | 変換が失敗した場合 | 観測する指標 |
|---|---|---|---|---|
| 計画 | ルーターと専用実行器 | 順序、階層、探索などを維持する制御フローになる。 | 妥当な計画を宣言していても、実際の軌跡が別の構造へ逸脱する。 | 計画構造の維持率、方式ごとの成功率、方式選択の成否を測る。 |
| 現在状態 | Meta-Controller | 次に実行する Worker、参照する途中成果、継続、分岐、停止として表現される。 | 有望な候補を打ち切る、価値の低い探索へ予算を使う、必要な成果を再利用できない。 | 計算予算を増やしたときの性能変化、候補選択、進捗評価の精度を測る。 |
| 過去経験 | Builder | 記憶、ツール、検証器、Controller、作業環境として配置される。 | 有用な原則を抽出していても、現在タスクで再利用されず、同じ失敗を繰り返す。 | 同じ Meta-Skill を直接提示した条件との性能差、タスク分類ごとの効果を測る。 |
この表で共通するのは、変換層が情報の意味を追加するというより、情報が作用する場所を変えることである。計画文を実行器の制御構造へ移せば、順序や分岐の一部を毎回のモデル判断から外せる。現在状態を Meta-Controller が扱えば、対象作業を行う Worker から探索配分や停止判断を分離できる。経験を Harness へ移せば、過去の知見の一部をツールや検証条件として再利用できる。情報そのものが同じでも、それをモデルの文脈へ置くか、実行系の状態や規則へ置くかによって、後続行動への拘束力が変わる。
この見方を採ると、AI エージェントの能力を「何を知っているか」「どの答えを生成できるか」だけで測ると、実行能力の原因を取りこぼすことが分かる。評価すべき対応は、生成した計画と実際の軌跡、認識した途中状態と次の計算、過去経験から抽出した原則と環境側の支援機構の間にある。これらの対応が崩れれば、モデル内部では妥当な判断が生成されていても、システム全体としては成果へ到達しない。
一方、判断を外部構造へ移すほど性能が一方向に上がるわけでもない。Thinking Before Thinking では、小さい計算予算では Controller の固定的な計算コストが相対的に大きくなる[8]。Planning-as-Routing では、計画方式の選択を誤れば、専用実行器はその不適切な構造を忠実に実行する[5]。Meta-Skill に基づく Harness も、Harness-Bench のすべての分類で同じ方向の改善を示すわけではない[11]。実験が共通して示しているのは、複雑な実行構造そのものの優位性ではなく、判断をどこへ配置したかによって、失敗点、計算コスト、適応可能性、再現性が変わることである。
設計上の焦点は、モデル、プロンプト、ツール、記憶、Controller、検証器のどれか一つを選ぶことではなく、それぞれに何の判断を担当させるかにある。探索的で例外の多い判断はモデルへ残し、順序、権限、形式、数値条件のように明示できる制約は実行系へ移すという分担もできる。逆に、環境条件が頻繁に変わる領域で制御を固定しすぎれば、正しい例外処理まで遮断する。エージェント設計は、知能をモデル内部へ集約する作業ではなく、判断の性質に応じて責任を複数の層へ配置する作業として読める。
AI が仕事の進め方を説明できるかという問いを、AI の判断がどの機構を通って次の状態へ変換されるかという問いへ置き換えると、計画、計算資源、記憶、ツール、検証を一つの動作系として評価できる。計画を作る能力と計画を実行する能力の境界は、その動作系を分解する最初の観測点である。そして三つの研究が示すのは、その境界が計画だけに存在するのではなく、現在状態から次の計算を選ぶ場面にも、過去経験を次の支援へ変える場面にも繰り返し現れるということである。AI エージェントの能力は、モデルが何を言語化したかだけでなく、その情報がどの実行構造へ変換され、実際の軌跡をどこまで拘束したかによって読む必要がある。
参考文献
- id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
- id774, 最新 AI は何が変わったのか 2026（2026-07-03）. https://blog.id774.net/entry/2026/07/03/4937/
- Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths, Cognitive Architectures for Language Agents (2023). https://arxiv.org/abs/2309.02427
- Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 2023). https://arxiv.org/abs/2210.03629
- Subba Reddy Oota, Francisco Herrera, Jordi Cabot Sagrera, Marcos López de Prado, Shadab Khan, Do LLM Agents Execute the Plans They Declare? From Planning-Mode Declaration to Pattern-Specific Execution (2026). https://arxiv.org/abs/2609.38108v1
- Shuyang Liu, Saman Dehghan, Jatin Ganhotra, Martin Hirzel, Reyhaneh Jabbarvand, From Plan to Action: How Well Do Agents Follow the Plan? (2026). https://arxiv.org/abs/2604.12147
- Lutfi Eren Erdogan, Nicholas Lee, Sehoon Kim, Suhong Moon, Hiroki Furuta, Gopala Anumanchipalli, Kurt Keutzer, Amir Gholami, Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks (ICML 2025). https://proceedings.mlr.press/v267/erdogan25a.html
- Paras Dahal, Anton Bakhtin, Taco Cohen, Zhengxing Chen, Carole-Jean Wu, Rob Fergus, Scott Yih, Gabriel Synnaeve, Ruslan Salakhutdinov, Sanjeev Arora, Jason Weston, Anirudh Goyal, Thinking Before Thinking: Scaling Agentic Inference Through Meta-Reasoning (2026). https://arxiv.org/abs/2609.38147v1
- Bradley Brown, Jordan Juravsky, Ryan Ehrlich, Ronald Clark, Quoc V. Le, Christopher Ré, Azalia Mirhoseini, Large Language Monkeys: Scaling Inference Compute with Repeated Sampling (2024). https://arxiv.org/abs/2407.21787
- Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, Joseph E. Gonzalez, MemGPT: Towards LLMs as Operating Systems (2023). https://arxiv.org/abs/2310.08560
- Cheng Qian, Kunlun Zhu, Beibin Li, Zhenhailong Wang, Heng Ji, Learning Meta-Skills for Agent Harness Design in Test-Time AI4AI (2026). https://arxiv.org/abs/2609.38143v1
- Cheng Qian, Wenting Zhao, Liangwei Yang, Heng Wang, Jielin Qiu, Heng Ji, Silvio Savarese, Huan Wang, Shelby Heinecke, AI4AI at Test-Time: Strong-to-Weak Capability Transfer via Harnesses (2026). https://arxiv.org/abs/2608.12307
- Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, Chelsea Finn, Meta-Harness: End-to-End Optimization of Model Harnesses (2026). https://arxiv.org/abs/2603.28052
- Tianxin Wei, Zhan Shi, Minhua Lin, Bing He, Zewen Liu, Yisi Sang, Yuanchen Bei, Xuying Ning, Jiaru Zou, Ting-Wei Li, Xiao Lin, Yanjun Zhao, Chi Wang, Benoit Dumoulin, Dakuo Wang, Jingrui He, Hanqing Lu, Evo-Harness: Context-to-Harness Skill Compilation for Self-Evolving Agents (2026). https://arxiv.org/abs/2608.15071
- Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, Kunle Olukotun, Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models (2025). https://arxiv.org/abs/2510.04618
- Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong-Jin Liu, Gao Huang, ExpeL: LLM Agents Are Experiential Learners (AAAI 2024). https://ojs.aaai.org/index.php/AAAI/article/view/29936
- Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang, Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows (2026). https://arxiv.org/abs/2605.27922
- Chang Ma, Junlei Zhang, Zhihao Zhu, Cheng Yang, Yujiu Yang, Yaohui Jin, Zhenzhong Lan, Lingpeng Kong, Junxian He, AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents (NeurIPS 2024). https://proceedings.nips.cc/paper_files/paper/2024/hash/877b40688e330a0e2a3fc24084208dfa-Abstract-Datasets_and_Benchmarks_Track.html
- Tianyue Ou, Wanyao Guo, Apurva Gandhi, Graham Neubig, Xiang Yue, AgentDiagnose: An Open Toolkit for Diagnosing LLM Agent Trajectories (EMNLP 2025 System Demonstrations). https://aclanthology.org/2025.emnlp-demos.15/
- id774, AI の「正しい」を決める検証契約（2026-09-24）. https://blog.id774.net/entry/2026/09/24/5642/