LLM Agentの信頼性はモデルだけで決まらない：Harness EngineeringからState-Aware Runtimeへ

1. Agent界隈はついに「モデルだけ」を語る段階を脱した

最近、CMUやYaleなどの研究機関から、Agent Harness Engineeringに関するレビュー論文が発表された。この論文の登場には極めて強い業界的な象徴的意味がある。それは、**「大規模言語モデル（LLM）Agentの信頼性を、モデル単体のみで追求してはいけない」**という合意への転換を正式に宣言したことだ。

これまで、Agentに対する期待は単純な線形外挿に基づいていた。モデルパラメータが大きければAgentは賢くなり、コンテキストウィンドウが長ければより複雑なタスクを処理でき、外部APIツールが多ければ能力の境界が広がる、という考え方だ。

これらの判断は間違ってはいないが、あまりに不十分である。

2. なぜモデルが強化されてもAgentは失敗するのか

実際に長期間のタスクを実行した開発者であれば、Agentが崩壊する原因は、突然論理的推論能力を喪失したからではなく、システム全体に安定したランタイム構造が欠けているからであることに気づくだろう。

• 知らぬ間に現在のタスクの主線を忘れる
• ハルシネーションを含む推論を確定した事実としてメモリに書き込む
• 破壊的なツールを呼び出した後、世界の状態を同期更新しない
• 致命的な誤判断をした後も、極めて自信に満ちた口調で誤った因果関係に沿って突き進む

こうしたシステムレベルの雪崩は、数千億パラメータのモデルに替えたところで、あるいは1Mのコンテキストウィンドウに詰め込んだところで解決できるものではない。

Agentとは単なる「モデル + システムプロンプト」ではないし、「モデル + 数個のFunction Call」でもない。真の産業レベルのAgentとは、モデル、状態マシン、メモリフロー、実行サンドボックス、バリデータ、モニタリング/トレース、そしてリカバリ戦略が共同で構成する複雑なオペレーティングシステムなのである。

3. Harnessの注目度は高いが、それは終着点ではない

CMU/Yaleのレビューは、Harness Engineeringが業界の主要な学問になったことを証明した。しかし、私の研究視点では、Harnessはあくまで第一歩に過ぎないと考えている。

Harnessが解決するのは静的な問題である。つまり「Agentの外接システムはどのようなコンポーネントで構成されるか」ということだ。

一方で私が探求しているのは、より深刻な動的な問題である。**「これらのコンポーネントが、いかにして長期的かつ安定し、監査可能で、ロールバックとリカバリが可能な実行状態を共同で維持するか」**ということだ。

私はこの方向性を 「State-Aware Runtime（状態感知ランタイム）」 と定義している。

4. Harnessの次は、真の問題がRuntimeへ移行する

ここで言うState-Aware Runtimeとは、単にAgentにメモリを追加したり、履歴を長いコンテキストに詰め込んだりすることではない。Agentのあらゆる実行ステップを「検証可能な状態遷移」としてモデリングすることである。システムは、現在の状態が何であるか、どの操作が候補に過ぎないか、どの操作がコミットされたか、どの状態がロールバック可能か、そしてどの失敗を隔離し人間に委ねるべきかを把握していなければならない。

AnthropicやOpenAIのこの一年のプラットフォーム進化は、実はすべて同じことを行っている。LLMをチャットボックスから切り離し、制御可能なエンジニアリングの足場（scaffolding）に組み込むことだ。AnthropicはコンポーザブルなAgentパターン（Context Engineering / Long-running Harness）を強調し、OpenAIはプラットフォームネイティブな機能（State / Guardrails / Monitoring）を推進している。

Harness Engineeringの台頭は、精緻なコンポーネントマップを提供してくれた。しかし、地図に川や山が記してあっても、地図そのものが機械を動かすことはできない。

① Runtimeにおける状態維持の重要性

長期間のAgentにおいて、真の中核は高頻度の 状態遷移 である。一度の動作は、単に次のトークンを生成することではなく、以下のようなプロセスである。

この実行フローにおいて最も恐ろしいのは、モデルが誤った答えを出力することではなく、システムが現在の状態を全く把握していないことである。

どの事実は書き換え不可能な常識か。どれが一時的なセッションコンテキストか。どの操作がすでにデータベースに永久的に書き込まれたか。エラーが発生した際、システムは状態ポインタをどの安全なセーブポイントまで戻すべきか。

明示的な状態管理がなければ、Agentは「見た目は非常に賢いが、内部状態は矛盾だらけのテキスト生成器」に過ぎない。

② 長いコンテキストは長期的な状態管理ではない

現在、多くの企業がコンテキストウィンドウの拡大に心血を注いでいるが、これは核心的なエンジニアリングの痛点を覆い隠している。長いコンテキストは、決して長期的な状態管理と同一ではない。

数万文字の履歴を単純にモデルに投入すれば、安定した記憶が得られるどころか、むしろ災害を招く。初期の厳格な設定が中盤の雑談に上書きされ、一時的な推測が真理として固定され、要約の圧縮プロセスでタスクの本来の意図が密かに改変される可能性がある。

Context Engineeringの核心的な問いは「どうすれば正しい情報をプロンプトに届けられるか」である。対してState-Aware Runtimeの問いはより厳しい。「現在の状態とは何か。誰が状態を変更する権限を持つか。汚染された状態をどう隔離し、回復させるか」だ。これこそが真のシステムエンジニアリングである。

③ 誤った状態の「コミット」というリスク

従来のLLM評価（MMLUなど）では最終回答のみを見る。正解すれば成功、間違えば失敗である。しかし、Agentの評価においてこの思考法は通用しない。Agentの失敗はプロセスの途中で醸成され、連鎖的に伝播（Cascading Failure） する特性を持つためである。

モデルがユーザーの意図を誤認しても、それが「候補テキスト」の段階であれば再試行で解決できる。しかし、その誤認がシステムの長期メモリに書き込まれた瞬間、以降の数十ステップに及ぶ計画は、崩れた土台の上に構築されることになる。

同様に、危険なAPI呼び出しを生成しても、外部バリデータが遮断すればシステムは安全だ。しかし、その呼び出しが実際に外部データベースやゲーム世界の状態を変更してしまった場合、エラーは「言語的なハルシネーション」から「外部状態汚染という物理的な影響」へと変貌する。

したがって、長期的Agentの中核設計は、モデルに「絶対に間違えないこと」を強いるのではなく、「候補出力とコミット済み状態を厳格に区別する」 という強固な境界防御を構築することにある。

④ 成功デモではなく「失敗の軌跡」で信頼性を判断する

現在のAI界隈は、モデルが自律的に計画を立て、APIを呼び出し、完璧にタスクをこなす派手な成功デモで溢れている。しかし、研究者として私は、こうした生存者バイアスによる情報の価値を疑っている。高信頼性システムを構築する上で、完璧なデモよりも、真实的で詳細な失敗の軌跡（Failure Trajectory）の方がはるかに価値が高い。

トレースを深く解剖して初めて、以下のようなことが判明する。

• 崩壊はどこで起きたか。状態投影の欠如か、あるいはツール実行チェーンの断絶か。
• モデルが出力形式を無視したのか、それともバリデータのルールが緩すぎたのか。
• 誤った記憶が不意に書き込まれたのか、あるいは再試行時にデッドループに陥りエラーが拡大したのか。

これが、私が Trace-Native Evaluation（軌跡ネイティブ評価） を推奨する理由だ。単に「最後 succeeded したか」を問うのではなく、「この結果がどうステップバイステップで生成されたか」「中間状態に汚染はなかったか」「システムは正確にエラーを特定し、回復を実行できたか」を問わねばならない。

独立研究者が深掘りすべき「システム制御不能」の問題

私の最近の独立研究を振り返ると、最初から「State-Aware Runtime」という概念を持っていたわけではない。最初は次のような単純な疑問だった。

• なぜモデルは正解を出しているのに、プロセスが不安定なのか。
• なぜ長編物語Agentは会話は流暢なのに、キャラクターの知識や関係性の状態が漂流（drift）し続けるのか。
• なぜ構造化生成タスクにおいて、表現は自然なのに底流にある数学的構造が密かに書き換えられるのか。

これらの問題は異なるタスクに分散していたが、次第にある共通の矛盾が浮かび上がった。

LLMの生成能力は向上しているが、生成プロセスに安定した状態境界、プロセス制約、および失敗回復メカニズムが欠けている。

• 規範的な推論では、正解とプロセスの忠実性の乖離（procedural fidelity）に注目した。
• 長編物語Agentでは、キャラクターの認識上の記憶（epistemic memory）に注目した。
• マルチAgent社会交互では、社会的な情報チャネルや規範がAgentの行動をどう形作るかに注目した。
• 構造化生成タスクでは、言語の流暢さと構造の忠実性の乖離に注目した。
• ゲームAgent Runtimeでは、自由対話と世界状態のコミットの境界に注目した。

これらはバラバラの方向性ではなく、すべて一つのトレンドを示している。長期的Agentの信頼性問題は、もはや単一のモデル能力では説明できず、ランタイム層の状態管理、プロセス監査、ゲート遮断、および失敗回復へと移行しなければならない。

したがって、私の現在の研究ポジショニングは以下の通りである。

長期的LLM Agentにおける状態保持、プログラム遵循、プロセス監査、ゲートおよびロールバックメカニズムに注目し、それを単なるプロンプトエンジニアリングやメモリ拡張の問題ではなく、「State-Aware Runtime」の問題として理解する。

計算資源が正義とされるLLM時代において、リソースの限られた独立研究者がモデル訓練やベンチマークのスコア競い合いに飛び込むのは賢明ではない。

しかし、State-Aware Runtime は独立研究者が深掘りするのに極めて適しており、長期的な参入障壁を築ける領域である。ここでは数千基のGPUアレイではなく、システムの失敗に対する極めて鋭敏な感性と忍耐が武器になる。一人で高密度なFailure Traceの分解、状態漂流の分析、バリデータとロールバックの実験を行い、詳細な「Agent崩壊分類学（Failure Taxonomy）」を構築することは十分に可能だ。

大企業の視点は「どうすればモデルに正解を増やさせられるか」に集中しがちだが、独立研究者は「システムが必然的に間違えるとき、いかにして全てを破壊せずに済ませるか」という暗がりの研究を突き詰めることができる。

結び：Agentの後半戦は「システムの戦い」である

LLMはさらに強くなり、コンテキストウィンドウは極限まで拡大し、具身知能やマルチモーダルAPIが波のように押し寄せるだろう。

しかし、潮が引いた後に残る真の産業的ボトルネックは、モデルが十分に賢いかどうかではない。勝敗を分ける尺度は以下のような点になる。「極めて混沌とした外部環境において、内部状態を長期的に維持できるか」「メカニズムによって誤操作のコミットを遮断できるか」「説明可能な監査トレースを残し、雪崩が発生した後にエレガントにロールバックして回復できるか」

モデルが「無限の生成可能性」を担い、Harnessが「物理的な制約環境」を提供し、そして State-Aware Runtimeが「状態の一貫性」「プロセスの忠実性」「破滅的なコミットの阻止」を担う。

Agent競争の後半戦において、これら高能力だが不安定なモデルを、監査可能で回復可能な状態マシンシステムに安全に組み込めた者が、次世代の知能オペレーティングシステムの真の堀（Moat）を築くことになるだろう。