エージェントの実行トレースがランタイム契約になる

3本の新しいエージェント論文は、別々の角度から同じ主張にたどり着いています。最終回答は、信頼する単位として最も弱いということです。SHEPHERDは、エージェントの実行を型付きで分岐可能なトレースに変えます。AI作業手順ストアは、繰り返し発生するエージェント作業を、その場しのぎの計画ではなく、設計された再利用可能な作業手順として実行すべきだと論じています。WildClawBenchは、最終回答だけでなく、実際のツール、副作用の監査、軌跡の確認を含むネイティブなコマンドラインランタイムの中でエージェントを評価します。¹²³

エージェントの信頼性は今、実行トレース、作業手順の成果物、ランタイム評価の中にあります。 チャットの記録から分かるのは、エージェントが「何をした」と言っているかです。トレースから分かるのは、実際に何に触れたかです。作業手順は、次回に何をしてよいかを制約できます。ネイティブランタイムのベンチマークは、モデル、ツール、状態、制御ループがひとまとまりで機能したかを測れます。

以前、管理型エージェントがランタイム基盤を吸収していると書きました。また、クリーンアップ層こそが本当のエージェント市場であるとも論じました。この記事で扱う範囲はもう少し狭く、その2つの議論の下にある契約、つまりエージェントの実行記録です。トレースを検査、分岐、再生、再利用、評価できないなら、大規模に信頼できるエージェントシステムはまだありません。

隣接する論点として、制御面、証拠の基準、スキルループについては、チャットはAIエージェントのインターフェースとして間違っている、証拠ゲート、静的なスキルは死んだスキルですで扱っています。トレース契約は、この3つすべての土台にあります。

TL;DR

エージェントシステムは、最終回答だけを評価する方向から離れ続けています。SHEPHERDは、すべてのエージェントと環境の相互作用を、Gitに似たトレース内の型付きイベントとして記録し、過去の状態から分岐や再生ができるようにします。¹ AI作業手順ストアは、適切な設計、テスト、敵対的評価、段階的な展開にかかるコストを、毎回のプロンプトで支払うのではなく、多くのユーザーにまたがって償却できる、再利用可能で強化された作業手順を提案しています。² WildClawBenchは、なぜランタイムが重要なのかを示しています。60件の長期タスクを、実際のツールを備えた本物のCLIエージェントランタイム内で実行し、平均でおよそ8分、20回以上のツール呼び出しを行い、成果物と環境への副作用を監査するハイブリッド評価を使っています。³

実務上の変化は明確です。答えが正しいかだけを問うのはやめましょう。トレースは検査可能か、作業手順は再利用可能か、評価はエージェントが実際に働くランタイムで行われたかを問うべきです。

重要なポイント

エージェント開発者へ： - 実行トレースをプロダクト契約として扱いましょう。ツール呼び出し、引数、終了状態、ファイル変更、副作用、判断点を、別プロセスが検査できる構造で記録します。 - 繰り返し発生する高リスクなタスクは、検証済みの作業手順へ昇格させましょう。探索段階では即興が必要です。しかし、繰り返す作業には、テストと制約を備えた再利用可能な成果物が必要です。

評価チームへ： - モデル単体ではなく、モデルとランタイムを合わせて評価しましょう。WildClawBenchは、CLIランタイムを変えるだけで、同じモデルのスコアが最大18ポイント動くことを報告しています。³ - 決定的に確認できる項目と、意味判断を分けましょう。ファイルの存在、形式の妥当性、ワークスペースの清潔さ、サービスへの副作用は、LLM審査員を必要とすべきではありません。³

運用担当者へ： - ベンダーがトレースを示せないなら、「エージェントの信頼性」を買ってはいけません。会話記録、差分、成功したという一文だけでは足りません。 - ローカルな判断ルールはプロダクトの近くに置きましょう。管理されたトレースは何が起きたかを示せます。しかし、何を出荷する価値があるかは決められません。

なぜ最終回答だけでは弱すぎるのか？

最終回答は、圧縮してはいけない情報を圧縮してしまいます。

エージェントは、テストを実行していないのに「テストが通った」と報告できます。下流の呼び出し元を読まずに、マイグレーションについて説明できます。ユーザーが公開するつもりのなかったデータに触れるツール経路を通って、見た目には正しい最終成果物を作ることもあります。回答は整って見えても、ランタイム上の経路は危険で、無駄が多く、再現不能なままかもしれません。

これが、答えの前にツールを評価するで述べた中心的な主張です。背後にあるツールの証拠が欠けているなら、答えは採点できません。最近の研究は、同じ考えを完了報告の下へ押し下げています。トレースそのものが、他のエージェント、評価器、運用者が検査すべき対象になるのです。

WildClawBenchは、この問題のベンチマーク側の姿を名指ししています。著者らは、多くのエージェントベンチマークが、人工的なサンドボックス、短いタスク、模擬API、最終回答の確認に依存していると指摘します。一方、このベンチマークでは、実際のCLIエージェントをDockerコンテナ内で動かし、エージェント終了後に生成物、環境状態、意味的な基準を評価します。³ 長期作業は、間違った文章だけでなく、副作用とランタイム上の選択によって失敗します。だからこそ、この違いは重要です。

SHEPHERDは何を加えるのか？

SHEPHERDは、エージェントの実行を、別のエージェントが操作できる第一級の対象として扱います。¹

この論文では、メタエージェントを、他のエージェントを監督、最適化、訓練する高次のエージェントとして定義しています。そのようなメタエージェントに必要なのは、会話記録以上のものです。実行中の状態を読み、危険なターンの前で分岐し、過去の状態から再生し、親実行を汚染せずに分岐を比較できなければなりません。

SHEPHERDは、そのための基盤を提供します。ランタイムは、すべてのエージェントと環境の相互作用を、Gitに似た実行トレース内の型付きイベントとして記録します。すべてのアクションがコミットグラフの一部になります。メタエージェントは、型付きイベントストリームを購読し、過去のコミットをチェックアウトし、スコープを分岐し、後続部分を再生し、必要なブランチをマージできます。¹

このトレースには、通常のチャットログにはない意味的な約束があります。

報告されている数値は、この基盤を具体化しています。SHEPHERDは著者らのベンチマークで、Dockerより速くエージェントプロセスとファイルシステムを分岐し、再生時のプロンプトキャッシュ再利用率は95%超と報告されています。例では、ライブ監督者によってCooperBenchの共同合格率が28.8%から54.7%へ上がり、Tree-RLの構成ではTerminalBench-2の性能が34.2%から39.4%へ上がっています。¹

ただし、これらの数値を、あらゆる本番環境での保証として読みすぎてはいけません。重要なのは形です。ランタイムが最終結果だけでなく、実行への構造化されたアクセスを別プロセスに渡すと、監督、最適化、訓練はいずれも改善します。

AI作業手順ストアは何を加えるのか？

AI作業手順ストアの論文は、同じ信頼性問題を再利用の側から攻めています。²

著者らは、一般的なエージェントループでは、モデルが数秒から数分で計画を合成し、実行することを求められると論じます。その速さは、従来のソフトウェアをどうにか扱えるものにしてきた工程、つまり要件定義、設計、テスト、敵対的評価、段階的デプロイ、監視、フィードバックを短絡させます。この論文では、その場で実行される多くのエージェント作業を、本番品質のシステムというより即席のプロトタイプに近いものと位置づけています。²

提案されている答えは、「モデルにもっと長く考えさせる」ことではありません。答えは、強化された再利用可能な作業手順の共有ストアです。検証済みの作業手順が存在するなら、エージェントはユーザーの依頼をそれに対応づけ、ユーザー固有の詳細をパラメータ化し、毎回新しいツールチェーンを発明するのではなく、その制約された作業手順を実行すべきです。²

この考え方は、スキルをめぐる議論を鋭くします。「Xのやり方はこうです」と書いてあるだけのスキルファイルでは、ランタイム内に残る即興の余地が大きすぎます。作業手順ストアが求めるのは、もっと強い成果物です。

この論文の主要な経済的主張は実践的です。厳密なエンジニアリングには、その場限りの実行より多くの時間と計算資源がかかる可能性があります。だからこそ、そのコストはユーザーと繰り返し依頼にまたがって償却されなければなりません。² この議論は、真剣なエージェント作業の実感とも合っています。高リスクな作業手順を初めて扱うときは探索します。2回目、3回目には、全体を最初から探索し直すのをやめるべきです。

WildClawBenchは何を加えるのか？

WildClawBenchは、この契約の評価版を示しています。³

このベンチマークには、人間が作成した60件のタスクが6カテゴリにわたって含まれています。バイリンガル作業とマルチモーダル作業も含まれます。各タスクは、OpenClaw、Claude Code、Codex、Hermes Agentなどの実際のCLIランタイムをホストする、再現可能なDockerコンテナ内で実行されます。タスクでは模擬サービスのAPIではなく実際のツールを使い、著者らは1回の実行あたり平均でおよそ8分、20回超のツール呼び出しがあったと報告しています。³

ランキングより重要なのは、採点設計です。WildClawBenchは、決定的な成果物チェック、副作用に関する環境状態の監査、そして意味的検証が必要な箇所に限ったLLM/VLM審査員を組み合わせています。採点専用の素材はエージェント終了後まで隠されるため、実行中にエージェントが答え合わせ用の情報を見ることはできません。³

主要な結果はこうです。報告された最良構成の総合スコアは62.2%で、OpenClaw実行では他のすべてのモデルが60%未満にとどまり、ランタイムを切り替えるだけで、あるモデルのスコアは最大18ポイント動きました。³ そこから導かれる結論は明確です。ランタイムは評価対象システムの一部です。モデル単体がプロダクトなのではありません。

この結果は、エージェントベンチマークを見るチームに慎重さを求めます。短く人工的で、最終回答だけを見るベンチマークで高得点を取っても、運用者が本当に知りたい問いには答えられません。つまり、実際のランタイムで、実際のツールを使い、環境を意図した状態に保ちながら、長いタスクを完了できるのか、という問いです。

契約とは何か？

3本の論文を合わせると、契約の形が見えてきます。

それぞれの層は、別々の嘘を防ぎます。

トレースは、存在しないツール呼び出しをもっともらしい回答で覆い隠すことを防ぎます。作業手順は、繰り返しタスクがいつまでも新しい即興を必要とするふりをすることを防ぎます。ネイティブランタイムのベンチマークは、モデルスコアがランタイムの重要性をなかったことにするのを防ぎます。プロダクト基準は、チェックに通っただけの成果物が価値あるもののように振る舞うことを防ぎます。

最後の層はいまも重要です。トレースは何が起きたかを証明できます。作業手順は何が起きるかを制約できます。ベンチマークはタスク完了を測れます。しかし、その結果がユーザー、プロダクト、作業の背後にある基準を尊重しているかは、どの層も決められません。その判断は、いまもチームの仕事です。

運用者は今、何を変えるべきか？

まず、トレースの完全性から始めましょう。

ランタイムが、ツール呼び出し、引数、終了コード、ファイル変更、起動されたエージェント、生成された成果物の構造化された記録を出せないなら、自律性を増やす前にそこを直すべきです。弱いトレースは、下流のあらゆる主張の検証コストを高くします。

次に、トレースの採点と回答の採点を分けます。テストが通ったと主張する完了報告は、まずテストコマンドが実行され、正常終了したことを証明すべきです。変更ファイルを挙げる報告は、そのファイルが読まれた、または書かれたことを証明すべきです。外部アクションを要約する報告は、その副作用が期待状態と一致していることを証明すべきです。回答の品質を判断するのは、トレースがその主張を支えてからです。

次に、繰り返し発生する作業手順を特定します。定期的に発生するエージェントジョブには、昇格の問いを持たせるべきです。次回の実行は、再利用可能な作業手順の成果物に値するか。ソースのスキャン、ガイド更新、翻訳リリース、依存関係更新、インシデントのトリアージ、コンテンツ公開はすべて、ランタイムが手順を毎回作り直すのをやめると良くなります。

最後に、出荷するランタイムで評価します。模擬ツールや人工的なタスクは開発中には役立ちますが、リリース判断を担わせるべきではありません。リリース判断には、実際のエージェントが直面するものと同じツール境界、ファイルシステム状態、時間予算、副作用チェックが必要です。

簡単なまとめ

エージェントのトレースは、信頼性の契約になりつつあります。SHEPHERDは、ランタイムが型付きで再生可能なトレースを公開すると、メタエージェントが実行を監督し、分岐できることを示しています。AI作業手順ストアは、繰り返し作業をその場限りの即興から、再利用可能な設計済み作業手順へ移すべきだと論じています。WildClawBenchは、ネイティブランタイム、ツール、副作用、軌跡監査が、測定される性能を大きく変えることを示しています。最終回答は依然として重要です。しかし、それは契約の中心ではなく、終点にあります。

FAQ

実行トレースはオブザーバビリティと同じですか？

いいえ。オブザーバビリティは、運用者に何が起きたかを伝えます。契約として使える実行トレースには、さらに別プロセスが検査、分岐、再生、採点できるだけの構造が必要です。ログは人間のデバッグを助けます。型付きトレースは、監督者、評価器、作業手順の作成者が実行そのものを直接扱えるようにします。

SHEPHERDを使えばエージェントは自動的に安全になりますか？

いいえ。SHEPHERDが提供するのは、観測、分岐、再生、メタエージェント介入のための基盤です。悪い監督者は、依然として悪い判断を下せます。得られる利点は、監督者がチャットの会話記録を解析するのではなく、構造化された実行オブジェクトに基づいて行動できることです。

AI作業手順ストアは、エージェントが即興してはいけないという意味ですか？

いいえ。検証済みの作業手順が存在しない場合や、タスクが本当に新しい場合には、エージェントには探索が必要です。重要なのは昇格です。あるタスクが繰り返され、実際のリスクを伴うようになったら、システムは成功した経路を、制約、テスト、保守を備えた再利用可能な作業手順へ変えるべきです。

WildClawBenchは、どのエージェントランタイムが最良かを証明していますか？

いいえ。WildClawBenchが示しているのは、そのタスクセットと実験設定の下で、ランタイム選択が測定性能を大きく変えるということです。これは、ランタイムを評価に含めるべきだという証拠として扱うべきであり、プロダクトの恒久的なランキングとして扱うべきではありません。

チームは最初に何を作るべきですか？

まずトレースを作りましょう。次に、裏付けのない主張を拒否する基準を追加します。そのうえで、繰り返し発生する作業を作業手順へ昇格させます。信頼できるトレースのない高度なオーケストレーションは、失敗の再構築を難しくするだけです。

参考文献