Agent の評価

最初の 6 章では、単一 Agent の構築——コンテキスト、知識、ツール、コーディング能力、そして観察空間と動作空間——を展開してきました。しかし、構築が完了したことは、正しく構築されたことを意味しません。結果を安定して測定できて初めて、その後のモデルトレーニングとシステム進化に信頼できる方向を与えられます。

Agent システムを構築する際、開発者は数多くの設計上の選択に直面しますが、それらには明白な正解がないことがしばしばです。

• どのモデルを使うか？
• モデルにどんなツールを呼び出させるか？
• 知識ベースにはどんなデータを、どんな構造で構築すべきか？
• ユーザーメモリはどう作るべきか？
• モデルのプロンプトと Skills はどう構成すべきか？
• Harness にはどんな制約を加える必要があるか？
• この Agent の自己進化と自己反復はどうすべきか？

評価は私たちに科学的な意思決定の根拠を提供します。系統的な対比実験（1 つの変数を変えて効果の変化を観察する）とアブレーション実験（コンポーネントを 1 つずつ無効化し、全体性能の変化を観察して、そのコンポーネントの真の寄与を判断する）を通じて、真の能力向上と表面的な変動とを区別し、「ゴマを拾って西瓜を落とす（小を得て大を失う）」ことを避けます。ソフトウェアエンジニアリングにおける「度量なくして改善なし」という言い方の通り、再現可能な評価体系を確立しなければ、Agent の反復の方向は直感に頼るしかありません。

第 1 章で導入した Harness 工学の視点から見ると、評価は Harness の中で「検証」機能という中核的な役割を担っています。1 つの重要な認識は、評価の対象はモデルだけであってはならず、モデルと Harness の組み合わせ体であるべきだ ということです。同じモデルでも、異なる Harness の中では性能に大きな差が出ることがあります。一部のチームは Harness を最適化するだけで、同じモデルの端末系タスクにおける性能を著しく向上させました（詳しくは第 5 章）。これが意味するのは、Agent が評価で振るわないとき、改善の方向はモデルの交換ではなく、Harness のあるコンポーネント（プロンプト、ツール設計、フィードバックループ）の最適化かもしれない、ということです。完備された評価体系は、「モデルの能力不足」と「Harness の設計欠陥」という本質的に異なる 2 種類の問題を区別できるべきです。この 2 種類の問題を区別する一般的な手段がモデル置換実験（model swap）です。Harness を固定し、より強い/より弱いモデルだけを交換して、スコアの変化幅を観察します。もし強いモデルに換えてもスコアが上がらないなら、ボトルネックは Harness にあります。もし弱いモデルに換えるとスコアが大きく下がり、スコアがモデル能力とともに大幅に変動するなら、最も直接的な解釈はボトルネックがモデル能力そのものにあり、現在の性能が主にモデルによって決まっている、というものです（それがタスク自体が難しいためなのか、それとも Harness がモデルの事前知識に過度に依存しているためなのかは、さらなる分析が必要です）。これが先ほど述べた「アブレーション実験」とは 2 つの異なる方法である点に注意してください。アブレーションは Harness のあるコンポーネントを無効化して 全体性能がどう変わるかを見るもので、モデル置換は Harness を固定してモデルだけを交換する ものです。前者は Harness 内部のどの部品が重要かを特定し、後者はボトルネックがモデルにあるのか Harness にあるのかを区別します。

評価体系の価値は、モデルが急速に進化する時代においていっそう際立ちます。モデルの能力は依然として急速に進化していますが、新しいモデルが公開ベンチマークでより良い性能を示したからといって、あなたの特定のタスクでも優れているとは限りません。むしろ性能の後退（regression、すなわち新バージョンが一部の面で旧バージョンに劣ること）が起こることもあります。自分の評価データセットで完全にテストしてはじめて、データ駆動のアップグレード判断ができます。さらに、完備された評価体系は「未来のモデルのために製品を開発する」ことを実行可能な戦略にします。すなわち、現在のモデルが商用に耐えなくても、先に製品開発を完了して評価集を確立し、新しいモデルの性能を継続的に追跡し、閾値に達したらすぐにリリースすることができるのです。 評価体系は 4 つの環節に分解できます。何をもって成功とするか、タスクはどこから来るか、誰が検証するか、スコアをどう意思決定に変えるか——図7-1 に示すとおりです。

評価タスクの解剖：τ²-bench の telecom ドメイン

まず τ²-bench の telecom ドメインから実際のタスクを 1 本、丸ごと解剖してみましょう。τ²-bench は Sierra のオープンソースプロジェクトです。chapter7/tau2-bench-eval/README.md のコマンドでローカルにクローンしたうえで、タスクファイル data/tau2/domains/telecom/tasks_small.json を開いてください。

タスク定義の四つの構成要素

以下はそのファイルに含まれるタスクの 1 つで、読みやすさのために一部を省略しています。

{
  "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off",

  // Agent に渡されるチケット
  "ticket": "ユーザーの携帯がインターネットに接続できず、ステータスバーには
             'No Service' と表示されている。顧客 John Smith、番号 555-123-2002、
             現在フランス滞在中。速度テストの結果が excellent になって初めて解決とみなす。
             プランは変更しないが、必要なら 2.0 GB のデータをチャージしてもよい。",

  // ユーザーシミュレータに渡される行動規範
  "user_scenario": { "instructions": {
      "known_info": "You are John Smith with phone number 555-123-2002.
                     You are currently abroad in France.",
      "unknown_info": null,
      "task_instructions":
        "…express mild frustration after the first unsuccessful attempt.
         You will consider the issue resolved only when speed test returns
         excellent internet speed and nothing else. If it returns poor, fair
         or good, you will not consider the issue resolved.
         Whenever the agent asks you about your device, always ground your
         responses on the results of tool calls. …
         Never make up the results of tool calls."
  }},

  // 実行前に両側の状態を同じ起点にリセットする
  "initial_state": { "initialization_actions": [
      { "env_type": "user",      "func_name": "turn_airplane_mode_on" },
      { "env_type": "user",      "func_name": "turn_roaming_off" },
      { "env_type": "assistant", "func_name": "enable_roaming",
        "arguments": { "customer_id": "C1001", "line_id": "L1002" } }
  ]},

  // 採点基準
  "evaluation_criteria": {
      "actions": [
        { "requestor": "user", "name": "toggle_airplane_mode" },
        { "requestor": "user", "name": "toggle_roaming" }
      ],
      "env_assertions": [
        { "func_name": "assert_mobile_data_status", "expected_status": true },
        { "func_name": "assert_internet_speed",
          "expected_speed": 200, "expected_desc": "excellent" }
      ],
      "communicate_info": null,
      "nl_assertions": null,
      "reward_basis": ["ENV_ASSERTION"]
  }
}

この定義には、掘り下げて説明すべき設計が 4 か所あります。

ユーザーの認知境界が明示的にモデル化されている。 known_info には氏名、電話番号、滞在国の 3 項目しか含まれていません。機内モードがオンであること、データローミングがオフであること——この 2 つの真の故障原因はそこに含まれていません。ユーザーは知らないので自分から述べることができず、Agent は質問し、ユーザーに確認させることでしか入手できません。これが漸進的情報開示（Progressive Information Disclosure） をタスク定義のレベルで実装した姿です。「一度に全部言わないように」というプロンプトでシミュレータを縛るのではなく、ユーザーの知識範囲を独立したフィールドとしてモデル化しています。多くのベンチマークはタスク開始時に完全な要求を提示しますが、現実のユーザーの第一声はたいてい「ネットにつながらない」程度です。要求を実行可能な水準まで明確化すること自体が、Agent の能力の一部なのです。

シミュレータが受け取るのはセリフではなく行動規範である。 task_instructions には 3 種類の制約が混在しています。感情の設定（最初の修復が失敗したら軽い不満を示す）、受け入れ基準（速度テストが excellent のときだけ解決とみなし、poor、fair、good はいずれも受け入れない）、そして事実接地（Grounding） の要求、すなわち端末の状態に関するいかなる回答もツールの返り値を根拠とすること——“Never make up the results of tool calls”。3 つ目がとりわけ重要です。事実接地の制約がなければ、シミュレートされたユーザーは Agent の誘導に乗って「解決した」と確認してしまい、評価は 2 つのモデルが互いに追認し合うだけのものに退化します。

初期状態は制御側で分けられている。 env_type は user と assistant の 2 つの値を取ります。機内モードとローミングのスイッチはユーザー側、キャリア側の enable_roaming は Agent 側です。この分割が故障の形を決めています。キャリア側ではローミングが開通しているのに、ユーザー端末側ではオフになっているため、Agent がデータベースを照会しても「設定は正常」という結論しか得られません。故障はデータベースから見えない側にあり、ユーザーに確認させて初めて発見できます。

採点基準は 4 層に分かれ、この問題はそのうち 1 層だけを採用する。 env_assertions は最終状態を検証し（モバイルデータが利用可能、速度が 200 Mbps 以上かつ評価 excellent）、actions は重要な動作が発生したかどうかとどちら側が実行したかを検証し、communicate_info と nl_assertions は必要な情報がユーザーに伝えられたかを検証します。この問題の reward_basis は ENV_ASSERTION だけを宣言しており、残りの層は通常どおり計算・記録されますが最終報酬には算入されません。採点の基準はタスクごとに宣言されるもので、全体で固定されているわけではありません。

一度の実際の実行の軌跡

以下では読者に τ²-bench telecom ドメインの評価タスクを実行してもらい、タスク設計、ユーザーシミュレータの設計、プロセスと結果の検証ロジックを実際に観察し、さらに Agent の実行軌跡を観察して、Agent がなぜ失敗したのかを分析していただきます。

実験 7-1 ★：τ²-bench を実行し、τ-bench からの進化を比較する

本実験では τ²-bench 評価フレームワークを実行し、人間・機械インタラクション型評価環境の設計上の要点を理解します。まず本節でたどった道筋に沿ってタスク定義ファイルを通読してください。各タスクは既知情報、タスク指示、初期状態、成功条件の 4 つの部分から成ります。続いて評価フローを完全に実行し、ユーザーシミュレータと Agent のマルチターン対話を観察して、典型的な失敗モード（ポリシー違反、情報の欠落、過度な有人転送など）を分析します。

付属リポジトリには 1 回の実行記録（chapter7/tau2-bench-eval）が保存されています。以下ではそのうち成功した 1 本を分析します。

最初の十数ターンはアカウント特定のフェーズです。Agent は番号から顧客 C1001 を割り出し、続いて L1001、L1002、L1003 の 3 回線のデータ使用量を順に照会し、さらにユーザーがフランスで実際に使っている番号を尋ね直します。17 番目のメッセージで、Agent は誤った結論を出します。

Agent（17）：番号 555-123-2002 はあなたのアクティブな回線に含まれていません。最も近いのは 555-123-2001 です……

この結論は L1001 という 1 回線の照会結果だけに基づいています。ユーザーが番号は間違いないと主張したあと、Agent は L1002 を照会して、ようやく一致させます。決定的な転換点は 30 番目に現れます。

ユーザー（30）→ check_network_status()、check_status_bar() を呼び出す

ツールの返り値（31）：Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No

ユーザー（33）：携帯が今は機内モードになっているので信号がないようです。モバイルデータはオンですが、データローミングはオフです。機内モードを切って試してみましょうか？

ツール呼び出しを発したのは Agent ではなくユーザーです。これが双方向制御（Dual-Control） の仕組みです。シミュレートされたユーザーは check_status_bar、toggle_airplane_mode、reseat_sim_card、run_speed_test といった独自のツールセットを持っています。

その後の切り分けは順調です。Agent がユーザーに機内モードを切ってローミングをオンにするよう求め、ユーザーが実行し（35、37）、ステータスバーは 5G フルバーになります。Agent が速度テストを求めると 275 Mbps、評価 Excellent が返り（46）、ユーザーは解決を確認します。2 つの env_assertions はいずれも通過し、reward = 1.0 となります。

この満点の軌跡には、検証器が捉えなかった問題も含まれています。telecom の Agent ポリシーの冒頭には “You should only make one tool call at a time” と明記されているのに、4 番目のメッセージで Agent は get_customer_by_phone と get_customer_by_name の 2 つを一度に発行しています。検証器がこれを誤りと判定しなかったのは、この問題の reward_basis が最終状態しか考慮しないからです。これは τ²-bench の手落ちではなく、二値報酬に固有の代償です。プロセスの粒度を、モデル横断で比較可能な単一の数値と引き換えにしているのです。しかし本番環境の評価システムには、たいていそれ以上のものが必要です。正誤を判定するだけでなく、問題がどこにあるのかを指し示すことです。

失敗したタスクも分析する価値があります。ユーザーの番号は 555-123-2002 なのに、Agent は L1001 回線を選び、その 3.2/5 GB という使用量を根拠に推論を進めました。途中で get_details_by_id(L1001) がその回線の番号は 555-123-2001 だと明確に返しているにもかかわらず、Agent はその結果を読んでも判断を修正せず、その後は無関係な切り分けに数十件のメッセージを費やし、最後は有人対応へ転送しました。実際にはタスクの半分は達成しています——ユーザーにデータセーバーをオフにさせ、そのユーザー側の動作は現実に発生して環境に検証されました。しかし回線の選択を誤ったために必要な 2 GB のチャージが実行されず、3 つの最終状態アサーションはすべて失敗しました。この失敗の形は、後述の「失敗の帰属」の節で論じる AndroidWorld の事例と非常によく似ています。判断を修正するのに必要な証拠はすでにコンテキストに入っていたのに、Agent はそれをもとに引き返さなかったのです。

このタスク 1 本で、評価集が答えるべき問いはすでに出そろっています。何をもって成功とするか、タスクはどこから来るか、誰が検証するか、スコアをどう意思決定に変えるか。以下の各節でこれらを順に展開します。

評価指標：成功の定義

前節の評価結果は 5 本のタスクのうち 4 本通過でした。0.8 という数字だけでは、そのシステムが使えるかどうかは判断できません。それが返金対応のカスタマーサービスなら、5 人に 1 人が受け取るべき返金を受け取れないということです。脆弱性を掘り出すセキュリティ Agent なら、5 回のうち 4 回当たるのはかなり優秀です。違いは、その業務シーンがどれほど高い成功率を求めるかにあります。

技術的な奇跡：Pass@k で能力の上限を見る

現在の多くのモデルと Agent は、「技術的奇観」 と呼べる段階にあります。ここでいう奇観とは、大量の試行、十分な時間、人手による選別のもとで示される能力の上限のことです。そのうち一度でも成功すれば「これは原理的にできる」と示すには足ります。これはまさに Pass@k の論理です。同じタスクを $k$ 回実行し、少なくとも 1 回通れば通過とみなす。出力が連続スコアなら最良の 1 回を取り、Best@k と呼びます。

長時間稼働 Agent に関する Anthropic の議論は、この種の上限をよく表しています。たとえば Agent に一週間自律的に働かせて C コンパイラをゼロから書かせる、重要な数学的予想の反例が見つかるまで探索を続けさせる、あるいはオープンソースソフトウェアを繰り返し精査させ、何十年も潜んでいた重大な脆弱性を発見させる、といった具合です。

この種の工学的・科学的探索で示されるのは、たいてい「毎回正しくやれる」ことではなく、探索予算を十分に伸ばしたときにようやく現れる 1 本の突破的な軌跡です。科学的発見、脆弱性の発掘、オープンエンドな創作といったタスクでは、この能力上限そのものに価値があります。人間が $k$ 本の候補軌跡から最良の 1 本を選べるからです。

基盤モデル以外に、多くのアプリケーション企業も「技術的奇観」戦略を採っています。Manus が広く注目を集めたのは、仮想コンピュータを提供したからです。それまで Agent の実感を持たなかった人々が、AI も人と同じようにコンピュータを操作し、30 分から 1 時間にわたって働き続け、複雑なタスクを段階的に仕上げられることを目の当たりにしました。

OpenClaw は、多くの人が Agent の「生きている感じ」を初めて味わった製品です。ユーザーは実在の人に仕事を頼むのと同じように、インスタントメッセンジャー経由でタスクを割り当てられます。コンピュータ上のあらゆるファイルとオンラインサービスにアクセスでき、ある段階まで進むと自発的に報告したり新しい情報を求めたりし、さらには自分で起動してメールを確認・処理することさえできます。

初期の Manus と OpenClaw は、複雑なタスクの成功率が高いとは言えず、token コストも非常に高いものでした。しかしこれらの Agent フレームワークは汎用的なので、最強のモデルと組み合わせれば複雑なタスクでも Pass@k は高くなりやすく、技術的な上限の高さを示せます。こうした「技術的奇観」がソーシャルネットワークで大量に共有されたことが、これらの Agent 製品の成功の鍵でした。

業務の信頼性：Pass^k

実務が本当に気にするのは、たいてい逆のことです。すなわち、複数回の試行で一度も間違えてはならない。この目標を Pass^k（Pass consecutive k と読みます）と呼びます。同じタスクを連続で $k$ 回実行し、そのすべてが通過すること、かつ安全性・コンプライアンス・ハルシネーションなどの一票否決項に触れないことを求めます。答えるのは「Agent は安定して確実に届けられるか」であって、「たまに奇跡を起こせるか」ではありません。

各実行が独立で、単回成功率が $p$ であれば、2 つの指標の関係は直感的です。

たとえば単回成功率 $p=0.6$、$k=5$ のとき、Pass@5 $=1-0.4^5\approx99.0\%$ となり、「少なくとも 1 回は成功する」がほぼ常に成り立つように見えます。しかし Pass consecutive@5 $=0.6^5\approx7.8\%$ であり、5 回連続でミスなく通すのは依然として難しいことがわかります。前者は探索時の能力の天井を測るのに適し、後者こそ決済、返金、権限変更、本番デプロイといった場面が求める信頼性に近い数字です。

評価レポートには $k$ 回の試行の定義を明記しなければなりません。同一タスクの $k$ 回の独立サンプリングなのか、本番パイプライン上の連続する $k$ 件のタスクなのか。副作用を伴う操作については、単純に「成功するまで再試行」してはならず、サンドボックスやロールバック可能な環境でサンプリングし、失敗の一つひとつを信頼性指標に記録すべきです。

評価環境

指標の基準が定まったら、次の問題はどこで測るかです。評価環境とは繰り返し実行できる装置のことです。同じ初期状態を与えれば、同じ Agent は比較可能な結果を出すはずです。

五つの構成要素

先ほど解剖した telecom のタスクに戻りましょう。それを参照点にすると、繰り返し実行できる評価環境に必要な構成要素はすでにそろっています。

データセット（Dataset） はタスクファイルそのものです。初期状態、Agent 向けのチケット、シミュレータ向けの行動規範、受け入れ基準が 1 件のレコードにまとめられ、1 件が 1 つのテストケースになります。

環境状態（Environment State） はタスク実行中の可変情報です。データベース内の顧客、回線、プラン、請求書に加え、端末側の機内モード、ローミング、データセーバーのスイッチ、残データ量。これはリセット可能でなければならず、initialization_actions がそのリセットスクリプトです。真実性は状態変化が業務ロジックに従うことを要求し、可制御性は毎回の実行前に同じ起点へ戻れることを要求します。

ツールインターフェース（Tools） は両側に属します。Agent は顧客照会、使用量照会、データチャージ、有人転送といったキャリア側の操作を呼び出せます。ユーザーは端末側の各種スイッチを操作できます。どちらのツールセットも原子的な操作であり、「ユーザーのネット接続問題を解決する」といった高レベルの抽象は存在しません。抽象の水準が高すぎると、評価は単一の関数呼び出しの検査に退化し、計画と推論の部分がツール自体に吸収されてしまいます。

採点基準（Rubric） は evaluation_criteria の 4 層の検査に、reward_basis という集約ルールを加えたものです。

実行プロトコル（Interaction Protocol） はやり取りの順序と終了条件を規定します。ここでの正常な終了シグナルはシミュレートされたユーザーが ###STOP### を出力することです。ほかにターン数の上限があり、さらにシミュレートされたユーザーが忍耐を切らして自ら対話を終えることもあります——コミュニケーション効率の低さ自体が失敗としてカウントされるのです。

5 つの要素のどれか 1 つでも欠ければ、評価は繰り返し可能なループを構成できません。以下で他のベンチマークを検討する際も、この 5 項目を対照の枠組みとします。

人間・機械インタラクション型とツール呼び出し型の評価環境

telecom のようなタスクには必ず対話相手が必要で、5 要素のうちユーザーシミュレーションの部分が欠かせません。一方、対話相手がまったく存在しないタスクの一群もあります。コード生成、データ分析、数学の求解といったタスクでは、Agent は最初から最後までツールとしかやり取りせず、正しさは実行検証を通過できるかどうかで決まり、人手のアノテーションもモデルによる評定も必要ありません。この種の環境はユーザーシミュレータを省きますが、残る 4 要素は依然として存在し、形が単純になるだけです。環境状態はファイルシステムかデータベース、採点基準はテストコード、実行プロトコルは「答えを出すかターン数を使い切るまでツールを呼び続ける」に退化します。

Verifiers フレームワークは、この種の環境を 2 つの次元で階層化します。タスクがターンをまたいだ状態を保持する必要があるか、隔離が必要かです。SingleTurnEnv は数学の問題を出して答えを直接検証する場合、ToolEnv は複数のウェブページを検索して総合的に回答し最終結果を検証する場合、StatefulToolEnv はデータベースのレコードを変更して状態変化を検証する場合、SandboxEnv はサンドボックスでコードを実行して出力ファイルを確認する場合に適します。表 7-1 はこの 4 種類の環境をまとめたもので、タスクの状態、ツール呼び出し、隔離の要件に応じて選べます。

表 7-1 Verifiers 環境タイプの比較

このフレームワークは並列サンプリングと軌跡キャッシュに対応し、各評価の完全な軌跡（観察、行動、報酬）が保存されるため、後からの分析や再生が容易です。また、ツールの実行効果は現在の状態に依存するため、失敗時には単一の失敗フラグではなく明確なエラー情報を返し、Agent がそれをもとに戦略を調整できるようにすべきです。

ツール呼び出し型の評価が問うのは観察可能な状態変化の正しさであり、人間・機械インタラクション型の評価が問うのはコミュニケーション戦略の妥当性です。前者は行動を検証し、後者は誘導を検証します。2 種類の環境の構造の対比は図7-2 を参照してください。

評価データセットの設計

評価環境が舞台なら、データセットは脚本です。同じ 5 つの要素でも、タスクの種類が変われば埋め方はまったく異なりえます。タスクはどこから来るか、検証器はどの深さまで確認できるか、どうやって記憶されるのを防ぐか。本節は複数の公開ベンチマークの設計実践から出発し、最後により実務的な問い——自作の評価集のタスクはどこから来るべきか——に戻ります。

ベンチマーク設計の横断的な対照

前節で区別した対話相手の有無は、環境レベルでの第一層の差異にすぎません。データセットのレベルでの分岐のほうが、設計上のトレードオフをよく表します。表 7-2 は頻繁に引用されるベンチマークを並べたものです。

表 7-2 いくつかの Agent ベンチマークにおける主要な設計上の選択

検証器

Agent は「タスクはすべて完了した」と滔々たる報告を書くことができますが、実際にはまったく完了していないことがあります。評価フレームワークは、Agent の自己申告ではなく、機械が独立に照合できる事実を確認しなければなりません。

SWE-bench Verified は「修正完了」を 2 つの独立した命題に分解します。 一方は FAIL_TO_PASS で、修正前は失敗し修正後は通過することで、問題が確かに解決されたことを示します。もう一方は PASS_TO_PASS で、修正の前後どちらでも通過することで、新たな欠陥を持ち込んでいないことを示します。前者だけを検査すれば、Agent は邪魔なアサーションを削除・改変してごまかせます。後者だけなら検査していないのと同じです。両方を同時に検査してはじめて、「修正済み」と「壊していない」がそれぞれ独立に証明可能な結論になります。さらにテスト自体の安定性も確認し、通ったり落ちたりする不安定なテスト（flaky test）を排除します。

OSWorld の検証器は、表面上は完了しているが実質的には誤っている状況を発見できます。 134 個の独立した評価関数と OS への完全なアクセス権を備え、ファイルシステムの構造、プロセスの状態、ネットワーク接続、アプリケーション内部の状態を検査できます。データベース操作のタスクでは、評価スクリプトはレポートファイルの存在を確認するだけでなく、データベースに接続して SQL が正しく実行されたかを照合します。ブラウザのタスクでは DOM ツリーを解析し、cookie と localStorage を調べ、バックエンドに検証リクエストを送ってフォームが本当に反映されたかを確認します。

Terminal-Bench のタスク build-linux-kernel-qemu は、ソースから Linux カーネル 6.9 をビルドし、start_kernel にカスタム printk を追加し、initramfs を生成して QEMU 上で起動することを要求します。成功基準は起動ログにそのカスタムメッセージが現れることです。Agent は出力を偽造できず、全工程を本当にやり遂げるしかありません。

タスクの難易度の区分

評価タスク集にはさまざまな難易度のタスクを含める必要があります。そうすることで、モデルの能力が向上しても評価タスク集がすぐに陳腐化しません。

GAIA は全 466 問を 3 段階の難易度に分けています。Level 1 は 1〜2 個のツールで足り（人間 93.9%、GPT-4 30.3%）、Level 2 は多段の思考を要し（91.8% 対 9.7%）、Level 3 は複雑な組み合わせを要します（87.3% 対 0%）。この階層化は難易度を示すだけでなく、診断的な価値も持ちます。Level 1 の失敗は基礎的なツール利用を、Level 2 は多段の計画と情報統合を、Level 3 は長い系列の思考と複雑性の管理を指し示し、3 つはそれぞれ異なる改善の方向に対応します。

Terminal-Bench は、単純な mlflow のモデル登録から、中程度の難易度である 7z のパスワード解析、困難な git サーバーと webserver の複数コンポーネント統合、最高難度の FEAL 差分解読までをカバーします。

τ²-bench はさらにトラップタスクを用意しています。ユーザーが「カスタマーサービスがキャンセルを承認済みだ」と主張するものの実際にはポリシーに適合しない、という設定で、Agent が圧力と誤導のもとで正しい判断を保てるかを検証します。

データ漏洩の防止

GAIA は答えをインターネットから直接検索できないようにしています。 そのタスクは概念的には単純でありながら経路が開かれています。たとえば、ある特定の日の NASA の「今日の天文写真」を出発点に、写真の宇宙飛行士を特定し、その所属する宇宙飛行士グループを調べ、そのグループの中で宇宙滞在時間が最も短い人物を求め、「姓、セミコロン区切り、桁区切り付き」という形式で厳密に出力させます。答えは極めて具体的で、正誤は厳密な文字列一致で判定されます。漏洩防止は 2 点に依拠します。1 つは、問題が複数の情報源を組み合わせないと答えられず、単一のウェブページでは答えが直接得られないこと。もう 1 つは、一部のタスクに専用に作成された添付ファイル（インターネット上に存在しない PDF、音声、画像）が付いていることです。

AndroidWorld は 1 つのテンプレートから大量のインスタンスを派生させます。 そのタスクは静的なテキストではなく、動的に実体化できるテンプレートです。たとえば「連絡先 [CONTACT_NAME] の電話番号を [NEW_PHONE] に変更する」といった形で、評価のたびにパラメータ値がランダムに生成されます。これには 3 つの利点があります。パラメータが毎回異なるため固定の操作列の再生が無効になること、1 つのテンプレートからほぼ無限のインスタンスを生成できること、一部のパラメータを固定し残りだけを変えることで特定の要因の影響を正確に測定できることです。

Terminal-Bench は問題文にカナリア識別子を埋め込みます。 各問題は canary GUID を持ち、モデルがその GUID を含む内容を出力できるなら、ベンチマークのデータが訓練セットに入ったということです。漏洩を防ぐわけではありませんが、漏洩を検出可能にします。

品質管理と長期的なメンテナンス

高品質な評価集を作るのは非常に困難です。上に挙げたベンチマークの現在の形は、その多くが初版を運用に投入して問題が露呈したあと、何度も修繕を重ねた結果です。たとえば τ-bench から τ²-bench へは、設計をやり直した箇所が 5 つあります。

第 1 に、タスク指示が大雑把すぎて答えが推測できてしまったこと。初版のタスク指示は漠然と書かれていたため、モデルは要求を真に明確化する必要がなく、常識から手順を推測するだけでも通過できました。τ²-bench は脚本を known_info と task_instructions の 2 欄に分割しました。前者はユーザーが知っている範囲を画定し、後者は開示の仕方を規定します。ユーザーが知らない情報は Agent には推測しようがなく、照会して得るしかありません。

第 2 に、成功条件が精確でなく、検証の誤判定を招いたこと。「ネットワークが復旧した」といった条件には照合可能な境界がありません。τ²-bench はこれを「速度テストの結果が excellent のときだけ解決とみなし、poor、fair、good はいずれも受け入れない」に改めました。この変更が狙うのはその場しのぎの修復、つまり症状を抑えるだけで根本原因を解決しないやり方です。

第 3 に、ユーザーシミュレータの振る舞いが機械的すぎたこと。初版のシミュレートされたユーザーは受動的に応答するだけでした。τ²-bench はそこに感情（最初の修復が失敗したら不満を示す）、忍耐の上限（コミュニケーション効率が低すぎるときは対話を打ち切る）、そして事実接地の要求を補いました。3 つが合わさることで、シミュレータは現実のユーザーに近づきながら再現性も保てます。

第 4 に、ユーザーは対話だけでなく操作にも関与すること。telecom ドメインは双方向制御環境を導入しました。それ以前の評価では Agent だけが環境を変えられましたが、テクニカルサポートのような場面では、動作のかなりの部分は本来ユーザーが自分の端末で行うべきものです。双方向制御は検証にもう 1 つの次元を加えます。ユーザーが状態を変えたあと、Agent はツールを呼び直さなければ結果を知ることができないため、検証は「Agent がユーザー側の操作結果を本当に読み取ったか」までカバーするようになります。

第 5 に、タスクのインスタンスを動的に生成すること。τ²-bench の具体的なインスタンス（ユーザー名、番号、故障の組み合わせ）はパラメータ化して一括生成でき、これはカバレッジと漏洩耐性の双方を改善します。

SWE-bench Verified：公開前に元のタスクの 71% を落とした。 OpenAI は元の 2294 件から 1699 件を無作為抽出して人手評価にかけ、Python に堪能な開発者 93 名を集めて 1 件ずつ検査しました。問題の記述は明確か、テストケースは境界条件をカバーしているか、テストは安定しているか、参照 patch は新たな誤りを持ち込んでいないか、難易度は妥当か。最終的に通過したのは 500 件だけでした。高い脱落率がもたらすのはより高い S/N 比であり、評価コストも約 80% 下がります。複雑な Agent のタスクは数分から数時間を要することも珍しくなく、フロンティアモデルで評価データセットを丸ごと走らせると数千ドルの token コストがかかるため、評価コストを下げることは非常に重要です。

OSWorld：公開後 15 か月で 300 件超の問題が露呈した。 2024 年 4 月の公開後まもなくマルチモーダル Agent 評価の重要なベンチマークとなりましたが、その後の広範な利用の中で 4 種類の問題が明らかになりました。環境の問題（サイトのスクレイピング対策、CAPTCHA、動的コンテンツの変化）、タスク記述の問題（表現に曖昧さがある）、検証ロジックの問題（厳しすぎるか緩すぎる）、初期状態の問題（設定が不完全）です。香港大学のチームは約 10 名のグループを編成し、MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular などと 2 か月にわたり緊密に協力して体系的な修復を行いました。環境の問題はバージョン固定とオフラインバックアップで、記述の問題は曖昧な表現の書き換えで、検証の問題は人手で正しいベースラインを作って条件を調整することで、初期状態の問題は完全性チェックの追加で緩和されました。

実験 7-2 ★：ベンチマークタスクを人力で実行する

GAIA、AndroidWorld、SWE-Bench Verified、Terminal-Bench、OSWorld-Verified からタスクを選び、自分の手で完成させてください。各データセットについて易・中・難を 1 つずつ行うことを推奨します。「難」のレベルは人間にとっても挑戦的です。

終えたら 2 つの問いに答えてください。そのタスクの記述には複数の妥当な解釈が存在するか、存在するなら検証器はどれを認めるか。もしごまかして通そうとするなら、最も安上がりな経路は何か、検証器はそれを止められるか。

評価集の三つの出所

よくある見方として、公開ベンチマークはモデルのランキングのためのもので、実際の業務とはあまり関係がない、というものがあります。公開ベンチマークのスコアが製品の意思決定を直接導きにくいのは確かですが、その設計手法は十分に移植可能です。これまで論じてきた検証の深さ、パラメータ化生成、漏洩防止、品質のメンテナンスは、まさに自作の評価集で最も見落とされやすい部分です。

本番環境の評価集には、通常 3 つの出所があります。

公開ベンチマークはモデルの粗い選別と設計手法の借用に用い、一般に製品の意思決定には使いません。そのタスク分布は実際の業務のタスク分布と一致しておらず、GAIA で 2 ポイント上がったことと返金の成功率との間に必然的な関係はありません。

自作の業務集は現実のタスク分布をカバーし、モデル選定や Harness 設計の判断根拠にできます。たとえば τ²-bench は、ユーザーのシミュレーションを必要とする評価システムの骨格としてそのまま使え、ドメインのデータとツールセットを差し替えるだけで済みます。

本番軌跡の還流は現場の実際の失敗事例から来ます。ユーザーによる明示的な訂正、ユーザーの低評価、そして事後の状態チェック、ルールベースの検証器、あるいは LLM のレビューによって発見された問題事例です。失敗の帰属を経て回帰ケースとして蓄積されます。具体的なやり方は後述の「失敗の帰属」と「エンドツーエンド回帰タスクと trajectory prefix 回帰タスク」の節を参照してください。この出所はコストが最も高く、精度も最も高い。ユーザーが実際に遭遇した問題から直接来ているからです。

立ち上げの段階では通常、公開ベンチマークと少量の手書きの自作業務集しかありません。システムが本番で一定期間動いたあとは、本番軌跡から還流したケースが主体になります。

自動化評価方法

これまでの節で論じたベンチマークには 1 つの共通点があります。検証器がほとんどすべて決定的だということです。SWE-bench はテストスイートを実行し、AndroidWorld は最終 UI 状態をアサートし、GAIA は厳密な文字列一致を行い、τ²-bench の 4 層の検査も同じくすべてコードで実行されます。この選択には十分な理由があります。決定的な検証は追加のモデルコストを持ち込まず、結果は完全に再現可能で、ユニットテストのように継続的インテグレーションに組み込め、モデル間のランキングにも都合がよいのです。

その代償として、最終結果の正誤しか評価できず、誤りの原因は示せません。τ²-bench の失敗したタスクは最終的に 0 点でしたが、その 0 点は Agent が回線選択の段階で誤ったのか、データチャージの手順を落としたのかを説明しませんし、次に何を直すべきかも指し示しません。ランキングに用いる公開ベンチマークにとってこれは欠点ではありませんが、継続的な改善を要する本番システムにとっては、まさにそれこそが最も必要な情報です。

本番の場面にはもう 1 つの困難があります。多くの判断は、そもそもコードで検査できるアサーションとして書けないのです。クレーム対応の返信が適切かどうか、調査レポートに重要な情報の抜けがないかどうか、記憶の検索が人物関係を取り違えていないかどうか。これらには照会できる唯一の最終状態もなく、キーワードの一致で判定することもできません。

したがって、公開ベンチマークから本番環境の評価へ進むにあたっては、検証の方式を 1 本のスペクトルに沿って右へ動かす必要があります。その横軸はタスクの機械的検証可能性の程度です。図7-4 に示します。

スペクトルの右側にある 2 つの道具が、こうして本番評価の主役になります。Rubric で漠然とした「良し悪し」を個別に採点できる複数の次元に分解し、LLM-as-a-Judge で決定的な判定基準がない場合の採点を行うのです。両者が合わさってはじめて、漠然とした失敗率を着手可能な具体的問題へと還元できます。さらに本節後半の失敗の帰属と組み合わせることで、本番 Agent 評価の完全な閉ループが構成されます。

なお、右へ動かすことは左側を放棄することを意味しません。プログラムのアサーションとして書ける検査はすべてアサーションのままにすべきで、LLM による評定は機械的に判定できない次元にのみ用います。決定的な検査のほうが安価で安定しており、回帰テストとして長期に走らせるのにも適しています。

LLM-as-a-Judge：自動化評価の核心

なぜ LLM-as-a-Judge が必要なのでしょうか。開放的タスク（レポート生成、顧客クレーム処理、創作コンテンツなど）については、自動的に対比できる標準解がなく、人手評価はコストが高く規模化が難しいのです。LLM-as-a-Judge は、言語モデルに専門家が定義した採点基準（Rubric）に従って評定させることで、自動化のスケールと人間の専門的判断の間のバランスを取ります。しかしこの方法には既知の限界もあります。評者モデルは自身のバイアスを持ちうる（最も典型的なのは 長さバイアス で、内容がより正しいわけでなくても、より長く詳細な返答に高得点をつける傾向がある）ほか、同じ入力を複数回評定しても変動しうるのです。長さバイアスは特に個別に防ぐ価値があり、よく使われる手段は 3 つあります。Rubric の中で冗長さを明示的にペナルティにし、同類タスクに回答の長さ上限を規定すること。配対比較をするとき、まず 2 つの候補の長さを近づけてから評定すること。そして定期的にスコアと回答長の相関を監査すること——もし高得点がほぼ常に長い回答を伴うなら、評定が長さに引きずられていることを示すので、Rubric を作り直す必要があります。これらの課題に系統的に対処するため、Rubric 設計は以下の準則に従わなければなりません。

Rubric（採点基準）：LLM 評定の拠り所。

Rubric 四準則（Scale AI、「Rubrics as Rewards」）：

（1）専門家の指導に基づく——領域知識を反映し、核心的な事実と推論ステップを捉えなければならない。例えば医療 Q&A の Rubric には診断基準と避けるべき医学的誤りを含める必要があり、専門的基礎を欠いた Rubric は言語の流暢さなど表面的な特徴しか捉えられない。

（2）網羅的なカバー——事実の正確性、論理の一貫性、完全性、安全性を含み、しかも正の基準を定義するだけでなく、罠（Pitfall）——すなわち高リスクなよくある誤り、例えば医療アドバイスで未検証の療法を推奨すること——も明確にする。

（3）基準の重要性の重み付け——必須項（Essential）、重要項、任意項、罠項に分ける。一票否決メカニズム（Veto） をサポートする。例えばカスタマーサポートのシーンでは、ハルシネーション（虚偽情報の捏造）が典型的な否決次元であり、他の次元がどれほど優秀でも、虚偽情報が現れたら否決しなければならない。これはキーワード羅列式の報酬ハッキングの防止にも役立つ。

（4）自己完結した評価——各評価項が独立して操作可能で、評価者の領域知識に依存しない。「回答は深い理解を示した」のような抽象的な基準を避け、「少なくとも 2 つの権威ある理論を引用し、それがいかに結論を支えるかを正確に説明した」のような検証可能な基準に改める。

鍵となる実践：各次元に客観的で検証可能な採点段階を定義し、具体的な例と 境界ケース を提供して曖昧な状況の区別を助けます。報酬ハッキング（Reward Hacking）——すなわち Agent が高得点を得る「近道」を見つけたが実際にはタスクを完了していない——を能動的に防ぎ、ハルシネーション、ユーザーへの迎合、キーワードの羅列、難しい問題の回避を明確にペナルティにします。Rubric は反復の産物です。試用を通じて評価者の相違を収集し、徐々に完成させ、抽象的な準則から詳細な判例集へと進化させていきます。

ユーザーメモリ Agent を例に、四準則に合致する完全な Rubric を示します。テスト問題：「私の娘の小児科医は誰？」（答えは 2 つの対話をまたいで関連づける必要があります。1 回目の対話で「娘は Lily という名」と述べ、2 回目で「Lily を Dr. Chen に診てもらった」と述べています）。

rubric:
  dimensions:
    - name: 事实正确性
      weight: essential        # 必要项
      scoring:
        4_优秀: "准确回答 Dr. Chen，且关联到女儿 Lily"
        3_良好: "准确回答 Dr. Chen，但未提及是 Lily 的医生"
        2_及格: "给出了正确医生但附带不确定的额外信息"
        1_不及格: "给出错误医生名，或回答不知道"

    - name: 信息完整性
      weight: important        # 重要项
      scoring:
        4_优秀: "主动补充相关信息（如上次就诊时间、诊断结果）"
        3_良好: "回答了核心问题，无遗漏"
        2_及格: "回答了核心问题，但遗漏了可用的关联信息"
        1_不及格: "关键信息缺失"

    - name: 思考正确性
      weight: important
      scoring:
        4_优秀: "正确关联'女儿=Lily'和'Lily的医生=Dr. Chen'两条跨会话信息"
        3_良好: "关联正确但思考路径不够清晰"
        2_及格: "部分关联正确"
        1_不及格: "错误关联（如把用户自己的医生当成女儿的医生）"

    - name: 幻觉检测
      weight: veto             # 否决项：一旦触发，总分归零
      scoring:
        pass: "所有信息均可溯源到历史对话记录"
        fail: "编造了对话中不存在的信息（如虚构就诊日期、诊断结果）"

  edge_cases:
    - "如果用户有多个女儿且分别看不同的医生，应追问是哪个女儿"
    - "如果记忆中同时存在'Dr. Chen'和'陈医生'，应识别为同一人"

良い Rubric 対 悪い Rubric：上記の各採点段階は検証可能な具体的行動（「Dr. Chen と正確に回答」）を示しており、「メモリへの深い理解を示した」のような客観的に判定不能な記述ではありません。否決項は底線を明確にしています。他の次元がすべて満点でも、ハルシネーションが 1 回でも現れたら直接ゼロと判定します。

Rubric と Agent の回答を評価モデルに渡すと、各項目の点数と根拠が返ります。数十件の結果を集計し、低得点の軌跡を読み直せば、漠然とした「成功率の低下」を具体的な原因に分解できます。情報を取得できなかったのか、人物関係を取り違えたのか、それとも根拠のない内容を補ったのか。Rubric は点数を付けるだけでなく、次に直すべき場所を示す診断器になります。

以下では、ユーザーメモリを具体的な事例として、この汎用的な方法を実行可能な評価セットと検証器へどう落とし込むかを示します。

実験 7-3 ★★：Rubric に基づくユーザーメモリ評価システムの構築

前提要件：第 3 章のユーザーメモリ実験（chapter3/user-memory-evaluation）を完了している必要があります。

本実験では第 3 章の chapter3/user-memory-evaluation フレームワークを改造し、現在の単純な LLM-as-a-Judge に基づく採点メカニズムを、構造化された多次元 Rubric 評価システムへとアップグレードします。既存システムは単一の LLM 呼び出しで通過/失敗と評価理由を返すもので、構造化された診断能力を欠いています。

すべての三層タスクに適用できる統一的な多次元 Rubric フレームワークを設計します。評価次元には次のものを含みます。事実の正確性（Precision、精度——与えられたすべての情報のうち、どれだけが正しいか）は数字/日付/名称が記憶情報と一致するかを検証。事実の完全性（Recall、再現率——与えるべきすべての情報のうち、どれだけが言及されたか）はすべての関連情報を提供したか、重要な内容を漏らしていないかを検証。思考の正確性は情報間の関係と暗黙のロジックを正しく理解したかをチェック。思考の能動性は適切なときに直接の回答を超えた提案やリスクの注意喚起を提供したかを評価。ハルシネーション検出は記憶に存在しない情報を捏造していないことを確保します。

四段階採点（優秀/良好/合格/不合格）とし、各段階に抽象的な記述ではなく具体的な判定基準を配します。ハルシネーション次元は一票否決項に設定します。各次元に例と境界ケースを提供します。

実験 7-4 ★★：Advanced JSON Cards と RAG の対比評価

前提要件：第 3 章のユーザーメモリと RAG 実験（chapter3/user-memory、chapter3/agentic-rag-for-user-memory）を完了している必要があります。

目標：同じ評価セットを使い、構造化メモリと非構造化検索がそれぞれどこで強いかを公平に比較します。第 3 章の 2 つのプロジェクトを再利用し、chapter3/user-memory-evaluation の 60 ケースで、Advanced JSON Cards のみ、RAG のみ、重要な事実を常駐させて原会話を必要時に検索するハイブリッド、という 3 構成を比べます。

検収：三層の複雑度（基礎的な想起 / マルチセッション曖昧性解消 / セッション横断の隠れた関連）で成功率、平均ステップ数、ツール呼び出し回数、遅延、コストを記録し、各方式の失効境界を明らかにします。構造化は何を失ったか、検索は何を漏らしたか、ハイブリッドに本当に協同があるか。構成の詳細とテストケースは付属リポジトリを参照してください。

付属実験では、同じ 60 問を 3 つのメモリ構成に解かせ、実 API の実行軌跡を 180 本保存しました。表 7-3 では、割合だけで標本数が見えなくならないよう、全体成功率に正解数も併記しています。

表 7-3 3 つのユーザーメモリ構成の難易度別成功率

最も注目に値するのは、ハイブリッド方式が自然に勝ったわけではないという点です。3 問では二つの単独方式のどちらもできなかったことを成し遂げましたが、別の 8 問では成績のよい単独方式に及びませんでした。各問での最良の単独方式と比べると、平均成功率はむしろ低かったのです。純粋な RAG は基礎的な想起の問題では構造化カードと大差ありませんでしたが、セッションをまたぐ関連づけの問題になると、成功率は 15% にまで落ちました。もう一つ見落とされやすい数字があります。180 回の評定のうち、ハルシネーション拒否が 28 回発動したことです。一票拒否項目の重要さがここに表れています。

同源モデル問題と多源評定。

Agent と評者モデルが同じファミリーに由来する場合、Agent は評者モデルの好みと盲点を利用することを学びうます。

これはまさにグッドハートの法則（Goodhart’s Law）が言うところです。ある度量指標が最適化目標になると、それはもはや良い度量指標ではなくなる。 Agent がある採点システムの上で訓練やチューニングをすればするほど、真に能力を高めるのではなく、そのシステムの抜け穴を突く傾向が強まります。

さらに巧妙なことに、Agent は評者モデルが検出を苦手とする誤りのタイプを次第に避けるようになり、採点システムから見ればすべて正常に見えるようにもなります。

緩和策は 多源異種評定 です。異なるモデルファミリーの複数の LLM にそれぞれ評定させます（例えば Agent が Claude なら、評定には GPT-5 と Gemini を使う）。異なるファミリーのバイアスはしばしば直交しており、Agent がすべての評者を同時に「欺く」のは非常に困難です。同じ Rubric を使ってみなが同じ目標を評定していることを確保し、加重平均や一致性チェックで結果を集約します。デプロイ段階では単一モデルで素早く評価してもよいですが、定期的に完全な多源評定で品質監査を行うべきです。

多源評定が解決するのは「どのモデルで評定するか」の問題です。次に解決すべきは「どのモダリティを評定するか」の問題です。LLM-as-a-Judge の能力をテキストから音声、画像、動画へと拡張することは、評価カバレッジのもう 1 つの次元です。

マルチモーダル LLM-as-a-Judge。

マルチモーダル評定は LLM-as-a-Judge を音声、画像、動画の領域に拡張します。よくある 4 つの方向は次の通りです。

• TTS 評価（TTS すなわち Text-to-Speech、テキスト読み上げ）：正確性、自然さ、音色の一貫度、感情表現を判断します。これらの次元は、従来の WER（Word Error Rate、単語誤り率）では捉えにくい韻律の問題を発見できます。
• ASR 評価（ASR すなわち Automatic Speech Recognition、音声認識）：意味への影響を判断します。「今日の天気」の認識ミスは無害ですが、「1 千の振込」が「1 万」になれば深刻な結果を招きかねません。
• UI 評価：提案者・審査者（Proposer-Reviewer）メカニズムを採用し、文字のはみ出し、色のコントラスト、ボタンの位置などの問題をチェックします。ここでの提案者・審査者は 評価方法 として使われており、第 5 章での 生成システムのコンポーネント としての用法とは異なりますが、核心メカニズムは同じです。一方のモデルが生成し、もう一方のモデルが独立して審査します。
• 動画編集評価：キーフレームを通じて、編集の始点・終点や特殊効果の適用が正しいかを検証します。

実験 7-5 ★★：全自動 TTS 品質評価パイプラインの構築

本実験では、ゼロから完全なマルチモーダル LLM-as-a-Judge TTS 品質評価システムを設計・実装します。

TTS の多次元 Rubric を設計します。正確性次元はすべての文字を正しく読み上げたか（漏れ/読み誤り/追加がないか）を検証、自然さ次元は音声が流暢か（機械的な感じや不自然な休止がないか、韻律が人間の習慣に合うか）を評価、感情表現次元は語気がテキストの感情的色彩に合うか（疑問文は語尾上げ、感嘆文は強調、悲しい内容は速度を落とし低い調子で）をチェック、音色の一貫性次元は参照音声があるときに話者の類似度を評価します（マルチモーダルモデルが参照音声と合成音声を同時に受け取って対比）。

長さ、文体、感情、数字・固有名詞・多音字・方言などを変えたテストコーパスを用意します。TTS 生成部は OpenAI、ElevenLabs、Fish Audio、Minimax、Doubao などに接続し、音声を直接受け取れるマルチモーダル評価モデルに、合成音声、原文、参照音声、Rubric をまとめて渡します。次元別の分布を分析するだけでなく、評価モデル名、参照音声のハッシュ、候補音声のハッシュも保存し、後から結果を検証できるようにします。

付属リポジトリには、小規模な直接聴取の試行も保存されています。OpenAI と Fish Audio が数字、多音字、長文、興奮した口調の 4 種類を 1 本ずつ生成し、合計 8 本を Voxtral が上記 4 次元で評価しました。正確性と自然さは両者とも 5.00 と 4.00。感情表現と声質の一貫性は Fish Audio が 4.00 と 3.00、OpenAI が 3.75 と 2.75 でした。読み間違いの有無では差がなくても、評価軸を分ければ話し方や声質の違いが見えます。

ただし、この 8 本だけで優劣は決められません。各サービス 4 本という少なさに加え、固定の参照音声が Fish S1 で作られており、声質の類似度では Fish Audio が構造的に有利です。汎用 TTS を比べるなら「Fish の参照音声に似ているか」を総合点から外すべきです。音声クローンを比べるなら、すべての方式に同じ話者を模倣させ、人間のブラインド評価でモデルの点数を校正します。参照回答・参照画像・参照音声の選び方そのものが評価設計であり、評価前の中立な準備作業ではありません。

手書きの Rubric は、このような診断軸を素早く作るのに向いています。規模が大きくなれば、専用の 生成式報酬モデル で評価を自動化する方法もあります。訓練方法は第 8 章で扱います。

評判モデルが出す点数は結果の良し悪しを示すだけです。その結果を修復可能な問題に変えるには、失敗がいったいどの段階から始まったのかを特定する必要があります。

失敗帰属：軌跡全体から最初のエラーを特定する

エンドツーエンド評価は「成功／失敗」しか返さないことが多い。修正に結び付けるには、失敗軌跡ごとに分類、許容できない挙動が初めて現れたステップ、対応するツール呼び出しやモデル出力、監査可能な証拠を記録する。手掛かりはユーザーの明示的な訂正、低評価、後続の状態検査やルール検証である。LLM は補助できるが、失敗は製品問題を示すことも多いため人手の分析を省けない。

Coding Agent では、手順・リポジトリ規則の欠落、ツール／形式エラー、異常終了、完了度・論理エラーを初期分類とする。ステップ番号、ツール、観察、根因と結果、回復可能性、確信度を JSON/YAML に保存し、環境状態・バージョン・全軌跡も併せて保持する。

失敗帰属の仕組みを作るには、本番のバッドケース軌跡を根気よく読み込んで分析する必要がある。この作業は LLM に助けてもらえるが、LLM に任せきりにはできない。失敗帰属はしばしば技術ではなくプロダクトの問題を映し出すからである。

プロダクトが成熟するにつれ、誤りの分類は複数の大分類を持ち、その下にさらに小分類が並び、最終的には数百種に達しうる。これらの分類と帰属手順は、そのまま帰属アノテーション Agent のプロンプトや Skill になる。

Coding Agent を例に取ると、実用的な初期分類は次のようになる。

帰属アノテーション Agent は LLM を使って大量の本番軌跡の根本原因分析を大規模に回せるが、「失敗原因」を一文出すだけでは足りない。帰属記録は構造化されている必要がある。JSON か YAML で、具体的なステップ番号、ツール名、観測された証拠を引用する。さらに根本原因と結果を区別し、回復可能性を判断し、確信度を付す。たとえば edit_file が old_string の不一致を返し、その後 Agent が三度リトライしてもファイルを書けなかった場合、主因は「ファイル編集とツール呼び出しの誤り」であり、三度のリトライは結果であって独立した三つの根本原因ではない。複数の分類が同時に現れたときは「最も早く、かつ後続の失敗を説明できる」ものを主因に選び、残りは副因として残す。上表のうち少なくとも三分類は、LLM に最初の誤りを特定させる前にルールで容疑軌跡を絞り込める。完了宣言と実際に実行されたコマンドの突き合わせ、diff がテストアサーションや skip に触れているか、diff が公開 API や schema をマイグレーションなしに変えているか、である。ルールで絞ってから LLM に渡すほうが、全軌跡を LLM に流し込むより安上がりで精度も高い。

帰属記録を保存する際は、LLM の出力だけでなく、タスク目標、環境状態、Agent のバージョン、ツールセットのバージョン、そして完全な Agent 軌跡も併せて保存し、回帰テストに転用できるようにする。

以下では典型的な三分類を取り上げて説明する。

「やったことは正しいが、伝えたことが誤り」問題

「やったことは正しいが、伝えたことが誤り」は全体成功率に最も隠されやすい。多くの評価が環境状態しか検査しないからだ。τ²-bench はこれを独立に採点する。公開ベースラインのうち情報伝達要件を持つ 704 回の実行で 240 回が失敗し、そのうち 162 回が情報伝達の検査で落ち、80 回（全失敗の三分の一）は環境状態が正しいのに伝えた情報が誤っていた。

付属リポジトリに対応する事例がある。ギャラリーの expenses.jpg の支出を家計簿アプリに入力する課題で、Agent は権限付与、検索、画像の表示、各行の入力、保存を 32 ステップで行い、どのステップもエラーを返さないまま完了を宣言した。しかし検証器は、書き込まれるべき行——Dress、¥436.35——が存在しないと報告した。入力された 4 件とは何の関係もない。第 8 ステップの思考にはこうある。「I cannot actually see the content/details of the expenses in the image」。データを取得できていないと自分で分かっていながら、停止も報告もせずに先へ進み、第 11 ステップでは 4 件の支出が記録に忽然と現れ、以後の入力はその捏造データを忠実に実行した。最初の誤りは第 8 ステップであり、そこにはエラーもなくツール呼び出しでもない。根本原因も取り違えやすい。T3A は観測空間に要素ツリーしか持たず画像の画素が存在しないテキスト専用 Agent なので、原因は「モデルに OCR ができない」ことではなく、観測経路の欠落と「情報が取得できない」という正当な終了動作の不在である。モデル能力の問題として記録すればモデル交換や OCR 学習に向かうが、本当に必要なのは経路と終了動作を足すことだ。

実験 7-6 ★★：AndroidWorld の失敗軌跡に対する失敗帰属

本節の帰属手法を実データで練習する。エミュレータもモデル API も不要である。素材は chapter7/android-world に保存された T3A の実行記録で、t3a.md に全タスクの逐次 Action/Reason/Summary が、t3a_failed.md に 50 件超の失敗軌跡が収められ、いずれも末尾に検証器の客観的な判定が付く。

ステップ 1：サンプリング。t3a_failed.md から、ツールエラーが一度も出ない静かな失敗を 10 件以上抽出する。失敗したツール応答が存在せず、Agent が自ら完了を宣言するかステップ上限に達し、末尾の検証器だけが失敗と判定していることが条件である。

ステップ 2：最初の誤りの特定。各軌跡について最初の誤りのステップ番号を記録し、それがツール呼び出しか assistant message かを明記する。静かな失敗の特定には二つの手法を使う。事実アンカー照合は、Agent の陳述をツール返り値と突き合わせ、最初に食い違う地点を取る。trajectory prefix の二分探索は、軌跡を第 k ステップで切って引き継がせ、まだ挽回できるならエラーは k より後にあると判断する。エラー語句の検索では代用できない。

ステップ 3：構造化記録。軌跡ごとに JSON または YAML の記録を出力し、タスク名、最初の誤りのステップ、誤りの分類、根本原因の帰属先、根拠となる引用を含め、主因と結果を区別する。

ステップ 4：既存メモとの照合。結果を t3a_failed_analysis.md と逐条比較し、相違点を記録する。特に根本原因の帰属に注意すること。同メモは画像転記の失敗を「視覚モデルに OCR 能力がない」と記していたが、T3A の観測空間には画像の画素が存在しない。真の根本原因は観測経路の欠落である。既存の帰属メモは正解ではない。

ステップ 5：回帰タスクへの変換。最初の誤りが assistant message にある軌跡を 3 件選び、その直前までの prefix を切り出し、許容行動集合と禁止行動を書いて trajectory prefix 回帰タスクを作る。

スコープに敏感な文書フォーマットの誤り

ユーザーが「引用符の形式が違う」と言っても、それをそのまま全体一括置換にしてはいけません。少なくとも ASCII の直線引用符（"、'）、中国語の曲線引用符（“”、‘’）、Markdown のバッククォート（`）は区別する必要があります。同じ文字でも、中国語の自然言語、引用された英語原文、インラインコード、コードブロック、コードコメント、JSON、パスのそれぞれで担う構文上の役割が違います。

評価データはまず文書をスコープ付きの断片へ解析すべきです。たとえば ZH_PROSE、EN_PROSE、QUOTED_SOURCE、INLINE_CODE、CODE_BLOCK、CODE_COMMENT、JSON_OR_SCHEMA です。各断片には、許可される変換の集合、保護すべき文字、そして修正後の検証器の結果を保存します。次の 3 か所を同一の置換ルールで処理することはできません：

中国語の説明：`reset()` メソッドを呼び出す。
引用された英語原文：“Please restart the service.”
# 以下のコードブロックは保護されたスコープの説明のみに用いる
# 中国語のコメント：「現在の状態」を表示する
name = "status"

軌跡プレフィックス回帰では、モデルに最小限の修正を求めたうえで、中国語文書のスタイル、英語原文の保持率、コードと JSON の構文、そして対象外テキストの編集距離を同時に確認します。ルールでスコープを確定できないときは、原文を保持して確認を求めることを許可された動作とすべきで、推測による修正を合格扱いにしてはいけません。

正確なコピーの誤り：old_string の mismatch から層ごとの特定へ

old_string の失敗も「モデルが写し間違えた」だけに帰することはできません。同じ文字列について、生バイトのハッシュ、Unicode code point 列、tokenizer の token ID 列を保存し、次の連鎖に沿って最初の差分を探します：

original file bytes → tool return → Harness serialization → model context
→ model token output → decoded string → JSON/tool-call parsing → tool matching

最小限の評価プローブは、直接の復唱、長い文脈からの抽出、ツール引数への配置、類似文字列の選択、そして空白、改行、バックスラッシュ、Unicode 結合文字、低頻度 token を網羅します。指標は byte-exact match、code-point-exact match、token-exact match、最初の差分位置、実際のツール成功率です。直接プローブでは正しいのにツール呼び出しが失敗する場合は、tokenizer、シリアライズ、Harness、ツールプロトコルを修正すべきです。最初の差分がモデル自身の出力に現れたときにのみ、その事例を第 8 章のコピー訓練データに変換します。

エンドツーエンド回帰タスクと trajectory prefix 回帰タスク

失敗帰属で最初の誤りとその分類が定まったら、次は修正目標を再実行可能なテストケース、すなわち回帰タスク（regression task）として書き下す。ここでは補完関係にある二層の回帰タスクが要る。エンドツーエンド回帰タスクは変更がワークフロー全体を壊していないことを検証し、trajectory prefix 回帰タスクは最初の誤りの直前の状態を切り出して、その決定境界が直ったかどうかだけを検証する。

エンドツーエンド回帰タスクは初期状態とユーザー要求から始めて Agent にタスク全体を完了させ、最終状態、必要な出力、安全条件を確認する。本番の結果に最も近い一方で、どのステップで失敗したのかは判別しにくい。一般に、エンドツーエンド回帰タスクは各領域における Agent の能力が期待どおりかを検証するために使う。本章で述べた OSWorld、AndroidWorld、tau-bench などの標準評価セットは、いずれもエンドツーエンド回帰タスクである。

trajectory prefix 回帰タスクは既存の文脈、対話、ツール応答、環境状態を凍結し、Agent には次の一手か数手の観測可能な行動を考えて実行させるだけである。コストが低く、単一のポリシーやツールの問題を切り分けられる。高い信頼性が要る本番級 Agent では、trajectory prefix 回帰タスク集を作るほうがエンドツーエンド回帰タスク集より重要になることが多く、前節で述べた失敗分類体系と失敗帰属の仕組みを根気よく築く必要がある。

trajectory prefix 回帰タスクの答えは、唯一の行動や答えではなく許容される行動の集合として定義すべきである。「まずリポジトリ規則を読む」「まずユーザーに尋ねる」「危険な操作を拒否する」などを要求しつつ、禁止行動も併記する。

失敗帰属が済めば、エンドツーエンドと trajectory prefix の両方を含む評価データセットを構築できる。Coding Agent を例に取る。手順の欠落には、計画文書とテスト受け入れ条件を伴うエンドツーエンド回帰タスクを生成する。ツール呼び出しの誤りには、失敗した prefix を切り出して境界タスクに編集し、形式の修正、特殊文字のエスケープ、適切なツールへの切り替えができるかを試す。異常終了には、切り捨て・タイムアウト・ツール障害からの復帰シナリオを加える。完了度と論理の誤りには、多目標のチェックリスト、残タスクの通知、「まだ不可能と証明されていない」境界を加える。要求理解と曖昧性の分類には、複数の妥当な解釈を持つタスクを prefix として凍結し、「まず確認する」を許容行動に入れる。症状潰しと検証偽装の分類には、受け入れ条件に「テストアサーションを変更してはならない」「完了宣言には実際に実行したコマンドの出力を添えること」の二つの硬い制約を加える。情報伝達の分類には、環境状態だけでなく返答の内容そのものにアサーションを置く。

評価データセットは、第 8 章のポストトレーニングと第 9 章の Agent 自己進化の土台となる。

実験 7-7 ★★：複数表現による trajectory prefix 境界評価

既知のユーザーメモリ、現在の指示、trajectory prefix、ツール応答、環境状態を与え、次の観測可能な行動だけを出力させる。11 ケースを JSON Cards、Markdown、Python-like に符号化し、決定的な規則で判定した。33/33 セルが API エラーなしで完了し、各表現は 6/11 を通過した。表現を変えるだけでは利用ポリシーは修復されない。

実際のモデル選定では、私たちがしばしば直面する問題はこうです。「A と B のどちらが優れているか？」 配対比較は、絶対スコアに依存しない評価方式を提供します。

配対比較とモデルランキング

Elo 評価（もともとチェスに用いられたランキングシステム）は大量の一対一の対決を通じてモデルの相対的な能力を定量化します。点差が大きいほど、強者の予想勝率が高くなります。例えばモデル A のスコアが 1200、モデル B のスコアが 1000 なら、Elo システムは A の勝率を約 76% と予測します。もし B が意外にも勝てば、B は多く加点され A は多く減点されます。番狂わせの結果はより大きなスコア調整をもたらし、このメカニズムがランキングを真の水準へ素早く収束させます。その背後にある統計的基礎が Bradley-Terry モデル です。各モデルを潜在的な「実力スコア」として抽象化し、一対一の対決の勝敗の確率を両者のスコア差によって決めるもので、Elo はこのモデルのオンライン更新形式の工学的実装です。

Chatbot Arena は匿名ランダム対決を採用しています。ユーザーはモデルの正体を知らないまま優れた応答をブラインドで選び、数百万回の投票を通じてランキングを導きます。この方法の利点は「絶対基準」を定義する必要がなく、人間が「A と B のどちらが優れているか」を判断するだけでよい点です。しかし限界もあります。ランキング結果はユーザーが何を尋ねたかに左右されます。もし多くのユーザーがたまたまみなプログラミングの問題を尋ねれば、プログラミングが得意なモデルのランキングが高く出ますが、これは他のタスクでの真の水準を反映するとは限りません。

配対評定が人間の投票ではなく LLM によって行われる場合、さらに 位置バイアス（Position Bias） を防ぐ必要があります。評者モデルはある位置（通常は先に現れる方）の候補を系統的に贔屓する傾向があり、2 つの候補の内容を完全に入れ替えても、判決が変わらないことがあります。標準的な緩和方法は 順序を入れ替えてそれぞれ 1 回ずつ評定する ことです。A を先にして 1 回、B を先にしてもう 1 回評定し、2 回の結果の平均を取ります。より厳格なやり方は、2 回の判決が一致したときのみ計上し、不一致なら引き分けと記録するか人手再審査に回すことです。Chatbot Arena のやり方も本質は同じで、2 つの回答の表示位置をランダム化し、大標本の下で位置バイアスを相殺させます。

実験 7-8 ★★：配対比較データからモデルランキングを構築する

本実験では、ゼロから Elo rating 計算システムを実装することで、Bradley-Terry モデルがいかに大量の配対比較から相対的な能力評価を抽出するかを深く理解します。Chatbot Arena がオープンソースで公開した本物の投票データセット（数百万回のユーザーブラインド投票を含む）を使います。

Elo rating の反復更新アルゴリズムを実装します。初期は全モデルの評価を 1000 点とし、時間順に投票記録を処理します。各対決について、2 つのモデルの現在の評価差に基づいて予想勝率を計算し、実際の結果を予想と比較し、固定の学習率で調整します。勝者は加点、敗者は減点し、調整幅は予想からのずれに比例します（番狂わせの敗北はより大きなスコア変化を招く）。最終評価の降順に並べ、一対一の勝率マトリクスを計算し、公式ランキングと対比してランキングがおおむね一致すればよいとします。1 点単位の完全な一致にこだわる必要はありません。Chatbot Arena 公式が使うのは Bradley-Terry の最尤フィッティング（全対局を一括で解き、投票の前後順序に依存しない）ですが、ここで実装するのはオンライン増分更新の Elo（結果は学習率 K 因子と処理順序に影響される）で、2 つのアルゴリズムは全体のランキングでは一致するはずですが、具体的なスコアは精確には一致しません。

実験の第 2 部では歴史的ランキング推移のアニメーションを作成します。投票データを時間で切り分け（週ごとや月ごと）、各時点で Elo 評価のスナップショットを計算します。D3.js を使って棒グラフレース（水平な棒の長さ=評価、縦方向の位置=ランキング、時間とともに滑らかに変化）を実装します。アニメーションを観察することで、技術的ブレイクスルーの瞬間（あるモデルの評価が急上昇）、競争構図の変遷、モデルのライフサイクルを識別します。

評価駆動のモデル選定

モデル選定は単純に「最強のモデルを選ぶ」ことではなく、応用シーンに応じて複数の次元の間で評価駆動のトレードオフを行うことです。

選定の鍵となる次元

スループット と 遅延 は混同されやすい 2 組の指標ですが、それらを整理するには大規模モデルの推論が 2 つの段階に分かれることを知れば充分です。Prefill（プレフィル） は完全なコンテキストを一度に読み込み、ユーザーが Enter を押してから最初の文字が現れるまでの 初字遅延 を決めます（業界では TTFT、Time To First Token で測る）。コンテキストが長いほど prefill が遅く、TTFT が大きくなります。Decode（デコード） はその後トークンを 1 つずつ生成して回答を作り、以降の文字が出る速度（tokens/秒）を決め、同時に思考時間も直接決めます。50 tokens/s のモデルが 2000 個の思考トークンを生成すれば、思考だけで 40 秒かかります。

この 2 つの段階をめぐる主要なスループットと遅延の指標は次の通りです。

• 入力スループット / 出力スループット：それぞれ Prefill と Decode の速度に対応。
• TTFT：待ち時間に Prefill 時間を加えたもので、ユーザーが感じる「反応の速さ」。
• 思考遅延：異なるモデルが生成する思考トークン数の差は数倍に達することがあり、しかも思考の長さとタスク効果は必ずしも正の相関はありません。自分のワークロードで各モデルの思考トークン使用量とそれに対応する収益を実測すべきで、公開ランキングだけから推し量るべきではありません。
• p95 テール遅延：95% のリクエストが超えない遅延。平均値より実際のユーザー体験をよく反映します。平均値は大量の高速リクエストに引き下げられ、少数のユーザーが遭遇する深刻な引っかかりを覆い隠すからです。

コスト：入力/出力/キャッシュトークンの価格設定。コストは孤立して評価すべきではありません。安いが成功率の低いモデルは、頻繁な再試行が必要なため、実際の出費がかえって高くなることがあります。各タスクの平均コストとコスト・性能比を計算する必要があります。

性能：Pass@1、Pass^k、Pass@k、Best@k の 4 指標の精確な定義は前述の「評価指標体系」を参照。ここでは選定の文脈でどう取捨するかだけを述べます。日常のシーンでは最もよく使う Pass@1（単回の平均成功率）を見ます。重要操作のシーンでは Pass^k を優先し、「毎回間違えないこと」の安定性に注目します。探索的タスクでは Pass@k または Best@k を優先し、充分な機会を与えたときの能力上限を見ます。開放的タスクでは Rubric の多次元採点を使います。

レート制限と信頼性：RPM（毎分リクエスト数）/ TPM（毎分トークン数）の制限は並行能力に影響し、一部の API はピーク時に上限を動的に調整することもあります。頑健性の面では、分布外データ、敵対的入力、長時間実行の安定性（モード崩壊や注意の散漫などの問題が出ないか）に注目する必要があります。

予算—能力曲線：固定予算での一点の成績だけでは、Agent が長時間タスクを担えるか判断できません。成功率に加え、実時間、token、ツール呼び出し回数、計算予算に応じて性能がどう変化するかを報告すべきです。RE-Bench の人間との比較はこの違いをよく示します。各環境に合計2時間の予算を与えたとき、最良の Agent は人間の専門家のおよそ4倍の得点でした。しかし追加時間から得る利益は人間のほうが大きく、8時間では最良の Agent をわずかに上回り、複数試行を合わせて32時間ではおよそ2倍の得点に達しました¹。したがって短い予算での優位を長時間能力へそのまま外挿してはならず、モデル選定では実タスクの所要時間に近い複数の予算点を比較する必要があります。

実践では複数モデル協同の戦略を採れます。軽量モデルで単純なリクエストを処理してコストを下げ、強力なモデルで複雑なタスクを処理して品質を保証する。あるいは専用のモデルで特定のサブタスク（画像理解、コード生成など）を処理し、サブ Agent メカニズムで協調する。この異種の組み合わせは評価を通じて検証し、全体的な便益が増加したシステムの複雑さを上回るかを確認する必要があります（たとえば「9.9 と 9.11 ではどちらが大きいか」「洗車したいが、家から洗車場まで 50 メートルだ。歩いて行くべきか車で行くべきか」といった問いを単純な問題とみなして軽量モデルに任せ、判断を誤るような場合です）。

モデルの振る舞い：いつ読むのをやめ、編集を始めるか

モデル選定では、タスクを完了できるかだけでなく、デフォルトでどのように振る舞うかも比較する必要がある。Coding Agent で観察しやすい差の一つが行動閾値である。同じコーディングタスクに対して、編集前にリポジトリを広く探索し、アーキテクチャ、呼び出し元、テストを確認するモデルもあれば、少ない証拠から変更箇所を絞り込み、早期に編集してテストのフィードバックで理解を補うモデルもある。前者は早すぎる編集のコストを高く見積もり、後者は「もう一つファイルを読む」機会費用を高く見積もっている。

Agent のこうした傾向には二つの源があります。一つは Harness の中のシステムプロンプト、もう一つはモデルの行動方策です。ポストトレーニングはモデルの行動方策の重要な源です。SFT の軌跡は「どこまで読んでから手を動かすか」を示し、プロセス報酬は特定のツール経路を報いたり罰したりし、結果報酬は最終的に成功した一連の方策全体を強化します。そうして時が経つうちに、モデルが学ぶのはコードの書き方だけでなく、エンジニアリングの習慣でもあるのです。

実験 7-9 ★★：固定 Coding Harness でモデルの行動閾値を測定する

目的：モデル要因を分離し、情報収集を続けるか編集を始めるかという Coding モデルのデフォルトの選択を定量化し、経路効率と最終品質を併せて評価する。

方法：chapter6/model-action-threshold/experiment.py を実行する。デフォルトでは、同じ OpenRouter OpenAI-compatible エンドポイントから GPT-5.6-sol と Claude Sonnet 5 を呼び出し、システムプロンプト、ツール Schema、タスクリポジトリ、テストコマンド、最大ターン数を固定する。中立プロンプトは、読むべき最小ファイル数も早期編集も指定しない。三種類のタスクをそれぞれ最低 3 回繰り返し、モデルの実行順を交互にする。最初の編集までのツール呼び出し数、読んだファイル数、検索回数、実時間に加え、最初にテストしたパッチの合格率、テスト後の手戻り、最終成功率、変更ファイル数、Token 使用量を記録する。

因果解釈：中立キャンペーンは、同一 Harness 内でモデルとともに振る舞いが変わるかを問う。Harness の調整効果を測るには、--policy explore-first で別キャンペーンを実行し、二つの policy を一つのモデル比較に混ぜない。モデル交換で変わり、同一モデルでは Harness をまたいで維持される振る舞いはモデル効果の強い証拠であり、その逆は Harness 効果をより強く支持する。

合格基準：オフラインの単体テストがすべて通ること。各タスク fixture は初期状態でテストに失敗することを先に確認すること。正式結果に モデル × タスク × 反復 の全セル、API エラー 0、独立した最終テスト、監査可能な軌跡が含まれること。manifest.json が設定、観測、要約ファイルのハッシュを検証すること。付属ディレクトリには 18/18 セルを完了した実測結果を保存している。読者はこの小規模リポジトリの数値を恒久的なランキングとみなさず、対象とするモデル版と実際のワークロードで再実行すべきである。

Agent システムのコスト分析

前節ではコストをモデル選定の鍵となる次元の 1 つに挙げましたが、Agent のシーンにおけるコストは単純なトークン価格設定よりはるかに複雑です。複数ターンの推論、ツール呼び出し、コンテキストの累積がコストを非線形に増大させます。系統的なコスト分析は評価体系に欠かせない一環であり、本番デプロイの必要な前提でもあります。

コストの構成要素。

Agent システムのコストは 3 つの層に分解できます。

モデル推論コスト は最も直接的な部分で、入力トークンと出力トークンの消費によって決まります。しかし Agent のシーンには見落とされやすい 2 つの増幅要因があります。1 つは コンテキスト累積効果 です。Agent は LLM を呼び出すたびに、それまでのすべての対話履歴とツールの返り値を一緒に送ります（そうしてはじめてモデルがコンテキストを理解できる）。もし KV Cache（すなわち処理済みのコンテキストをキャッシュし、重複計算を避ける）をうまく活用しなければ、コストの増加は非常に速くなります。第 1 ターンで 1000 トークン、第 2 ターンで 2000 トークン、第 3 ターンで 3000 トークンを送ると、総量は 1000+2000+3000=6000 であって 3×1000=3000 ではなく、ターン数が多いほど差が大きくなります。もう 1 つは 思考トークンコスト です。思考をサポートするモデルは大量の思考トークンを生成し、これらのトークンはユーザーには表示されませんが、同様に費用に計上されます。

ツール呼び出しコスト には外部 API の費用（検索エンジンは回数課金、データベースクエリは計算リソースを消費）、コード実行のサンドボックスリソース、そして見落とされやすい間接コストが含まれます。ツールの返り値をコンテキストに注入した後に生じるトークン費用です。1 回のウェブ検索の返り値が 2000〜5000 個のトークンを占めることもあり、しかも以降の各ターンの推論で入力として繰り返し課金されます。

インフラコスト はベクトルデータベース（RAG 検索用）、メッセージキュー、リレーショナルデータベース、ログとトレースのストレージ（可観測性用）などの運用開銷をカバーします。

実際の費用の内訳を見るため、付属実験では 8 ターンの返金業務を固定しました。注文、配送、返金規約、ナレッジベースを確認し、リスク判定、返金、通知、クローズまでを実行します。gpt-4o-mini の実 API 呼び出しで「安定したプレフィックス」と「履歴圧縮」を個別にオン・オフし、同じ業務を 4 構成で比較しました。表 7-4 の金額は、各実行に保存された token 使用量と当時の価格から計算しています。

表 7-4 8 ターンの Agent タスクにおける実コスト

ベースラインでは、1 回の入力が 1,113 token から 3,668 token まで増えました。ツール出力が後続リクエストに繰り返し入り、8 ターンで 9,544 token を占めています。2 つの最適化を併用すると 5,248 token まで減り、総コストは 30% 下がりました。

ただし効果は足し算になりません。安定プレフィックスだけで 28.3%、履歴圧縮だけで 17.5% 節約できても、併用時は 30.0% です。履歴を圧縮すると、キャッシュに当たるプレフィックス自体も短くなるためです。**複数のコンテキスト最適化を組み合わせるときは、完全なタスクで全組み合わせを測り、個別の削減率を足し合わせてはいけません。**モデル、価格、タスク長が変われば 30% という値も変わります。再利用すべきなのは 4 群で比べる設計です。

コスト最適化戦略。

入力側では、まず 3 つを試す価値があります。プレフィックスを安定させて KV Cache を再利用する、古い軌跡や冗長なツール出力を減らして コンテキストを圧縮する、単純な処理と複雑な推論で モデルを使い分ける。具体的な方法は第 2 章で説明しました。ここで重要なのは、それぞれを独立にオン・オフできる設計です。個別の寄与だけでなく、併用時に効果を打ち消していないかも確認できます。加えて、評価・運用に固有の施策が 2 つあります。

非同期バッチ処理 は非リアルタイムのタスクを溜めて一括処理し、API プロバイダーのバッチ価格割引を利用します。自己デプロイのシーンでは、閑散時間帯の GPU 利用率も高められます。

コスト監視と予算制御。

本番環境では、リアルタイムのコスト監視体系を確立すべきです。タスクタイプ、モデル、ユーザーなどの次元でトークン消費と API 費用を追跡します。同時に各タスクにコスト上限を設定し、Agent がループに陥ったり探索が深すぎたりしたときに自動的に終了させ、単一のタスクが異常に高額の費用を生むのを防ぎます。

実験 7-10 ★：Agent タスクのエンドツーエンドコスト分析

実験目標：上記の 8 ターン業務のコスト分解を再現し、自分の実ワークロードでも最適化を検証します。

技術方式：まず付属リポジトリの固定タスクを再現し、その後で自分の代表的なタスクに置き換えます。LangSmith または自作のトレースで、入出力 token、思考 token、ツール呼び出しと返却サイズ、エンドツーエンド遅延を記録し、平均コスト、p50/p95/p99、費目別の構成を算出します。

検収基準：主要なコスト要因を示すレポートを作ります。キャッシュと圧縮の 4 組をすべて実行し、単独効果と相互作用を確認します。モデルを変えた場合は、付属軌跡の削減率を流用せず、必ず測り直します。

評価駆動の継続的反復

モデル選択は一度きりの意思決定ではなく、モデルの進化に伴って動的に調整すべき継続的な過程です。本章の冒頭ですでに「評価体系を持てば素早くモデルの進化についていける」という核心理念を提起しました。以下では具体的なモデル切り替えの事例を用いて、この体系が現実の意思決定でいったいどう機能するかを説明します。

あなたの Agent システムが現在 Claude をベースに構築されており、ツール呼び出しと複雑なオーケストレーションで優れた性能を発揮していると仮定します。ある日 Gemini が新しいモデルをリリースし、公開ベンチマークでは複数の指標で Claude を上回り、しかも価格が安い。このときあなたが直面する問題は「Gemini は Claude より強いか」ではなく、「私の特定のタスクで、Gemini は Claude より優れているか？ どれだけ？ 切り替えコストは何か？」です。

完備された評価体系を持つチームは数時間以内に答えを出せます。自分の評価データセットで新しいモデルを走らせ、タスク成功率、ツール呼び出し正確率、遅延、コストを対比します。新しいモデルは単純なタスクでは確かにより優れて安いが、複雑な複数ターンのツールオーケストレーションが絡む核心シーンでは、成功率がかえって 5% 下がる、と気づくかもしれません。この差異がノイズの帯域幅を超えていることを確認した後（後述の「評価結果の統計的有意性」を参照）、あなたの意思決定は「単純なタスクは新しいモデルに移してコストを下げ、複雑なタスクは元のモデルを保持して品質を確保する」という差別化戦略になり、盲目的な全量切り替えにはなりません。この精緻化されたデータ駆動の意思決定は、あらかじめ評価体系を構築しておいてはじめて実現可能なのです。

実験 7-11 ★★：多次元モデル性能ベンチマーク

主要な LLM と異なる API プロバイダーに対して全面的なベンチマークを行い、多次元のモデル選定意思決定データベースを構築します。

テスト範囲を選びます。GPT 系列、Claude 系列、Gemini 系列、Doubao 系列などのクローズドソース SOTA モデル、および Qwen、Kimi、DeepSeek などのオープンソースモデル。同じモデルに対して異なる API プロバイダー（DeepSeek 公式 対 Siliconflow など）をテストし、第三者の性能監測プラットフォーム（Artificial Analysis など）の結果を検証します。

標準化されたテストワークロードを設計します。入力スループットテストは固定長のコンテキスト（8K/32K/128K tokens）を使い、出力スループットテストは固定長の応答（512/2048 tokens）の生成をリクエストします。遅延テストは TTFT（最初のトークン生成時間）とエンドツーエンド遅延を含み、思考をサポートするモデルには思考の長さと思考遅延を別途測定します。各構成で少なくとも 100 回リクエストし、標準偏差/p50/p95/p99 を計算します。高い遅延分散はユーザー体験の不安定さを意味します。

API の可用性と安定性を評価します。1 週間、1 時間ごとに 1 回探測し、成功率、エラータイプ、故障時間を記録します。故障率、MTTR（平均復旧時間）、最長連続可用時間を計算します。レート制限の実際の閾値をテストします。並行量を段階的に上げてスロットリング点を見つけ、RPM/TPM の上限を記録します。総合コストを計算します。価格情報（入力/出力/キャッシュトークンの単価）を集め、KV Cache の影響を考慮し、典型的な複数ターン Agent タスクの平均コストを計算します。

実験 7-12 ★★：ユーザーメモリシステムのエンドツーエンド選定評価

前提要件：第 3 章のコンテキスト検索またはエージェント化 RAG 実験を完了している必要があります。

目標：ユーザーメモリ検索 Agent に対して全リンクの選定評価を行い、埋め込みモデル、reranker、Agent 主モデルの 3 つの選択点がいかに共同で検索品質、遅延、コストに影響するかを見ます。chapter3/contextual-retrieval-for-user-memory または chapter3/agentic-rag-for-user-memory を再利用し、60 個のテストケースで対比します。

検収：3 つの選択点をそれぞれ走査します——埋め込みモデル（BGE-M3 / OpenAI / Doubao など、top-5 検索精度、遅延、コストを記録）、reranker（「reranker なし」ベースラインを含め、その限界的価値を定量化）、主モデル（同じ検索構成の下で成功率とツール使用効率を比較）。鍵はコンポーネント間の協同を読み取ることです。より強い埋め込みは reranker を不要にするかもしれず、より強い主モデルは検索の不足を補うかもしれません。選定は系統的なトレードオフであって、1 つずつ最強を選ぶことではありません。構成の詳細は付属リポジトリを参照してください。

評価結果の統計的有意性

評価セットは有限で、モデルの出力にはランダム性があります。したがってスコアの差は、単なる標本ノイズかもしれません。$n$ 件のケースで成功率 $p$ を測ったとき、標準誤差はおおよそ次のように見積もれます。

たとえば 100 件・成功率 70% なら、95% 信頼区間はおよそ $70\%\pm9$ パーセントポイントです。「新モデル 73% 対 旧モデル 70%」では切り替えの根拠として不十分です。

同じ一群のタスクで二つの構成を比較するときは、ペア分析を優先すべきです。設問ごとにどちらが勝ったかを記録し、McNemar 検定またはペア bootstrap で差を判定するのであって、独立した二つの成功率をそのまま引き算するのではありません。Agent は実行のたびに結果が変わりうるので、各構成を複数の乱数シード（たとえば 3～5 回）で走らせ、平均と変動幅を報告するのが望ましく、単発の実行は方向性のふるい分けにしか使えません。期待される改善がわずか 2～3 ポイントで、評価セットが数十問しかないなら、まず標本を拡大すべきです。標準誤差は $1/\sqrt{n}$ で小さくなります。

for task in paired_tasks:
    for seed in fixed_seeds:
        a = run(config_a, task, seed)
        b = run(config_b, task, seed)
        record_paired_delta(verifier(a), verifier(b))

return paired_bootstrap_or_mcnemar(all_deltas)

ペアにするとは、二つのグループがタスクと乱数条件を共有することであって、別々に二つの標本を取ってから平均を比べることではありません。

複数の仮説を並行して検証するときは、多重比較も考慮しなければなりません。有意水準のしきい値を厳しくするか、陽性の結果については独立に再実行します。実務上の判断基準は単純です。スコア差がノイズを超え、ペア分析でも成り立ち、しかも再現できる——そのときにはじめて、モデルの切り替えや変更のリリースに値します。

Agent の可観測性

評価駆動の意思決定（モデル選定であれ継続的反復であれ）は、いずれも高品質の実行データに依存します。以下ではまず、いかにこれらのデータを系統的に収集するか（可観測性）を紹介し、次にいかに評価結果をシステム改善へと転化するかを論じます。

可観測性（Observability）というこの概念は分散システムの領域から借りたものです。システムの内部を直接開いて何をしているかを見ることはできず、それが出力するログ、指標、トレースデータを通じてのみ、何が起きたかを推し量れます。ちょうど医師が患者の体内を直接見ることはできず、体温、血圧、画像などの外部信号を通じてのみ問題を診断できるのと同じです。Agent システムはこれをさらに難しくします。同じ入力でも異なる出力を生みうるし、複数ターンの推論とツール呼び出しが実行経路をきわめて複雑にし、しかもモデルの「思考」過程は外部にはまったく不透明です。

可観測性の価値はまず 問題診断 にあります。完全な軌跡があれば、開発者は推測に頼らず全過程を再生できます。次に 継続的最適化 の基礎です。どのタスクが複数ターンの反復を要するか、どのツールの成功率が最も低いか、どの検索クエリが常に空の結果を返すかが見えます。コスト管理 では、Agent の実行コストはタスクによって 1〜2 桁も差がありえ、追跡によって異常に高コストのケースを識別できます。最後に、蓄積された軌跡データは、後続のシステム最適化とモデル改善の基礎も提供します。

Agent 可観測性のデータ基礎は トレース（Trace） で、そのデータ構造は分散システムの span ツリーモデルを直接踏襲しています。1 回のタスク実行が 1 本の trace に対応し、その中の各 LLM 呼び出し、各ツール呼び出し、各検索が 1 つの span（入出力、開始・終了時刻、トークン消費、エラー情報を記録する実行単位）であり、span 間の親子関係が 1 本の実行ツリーを構成します。例えば「Agent メインループ」span の下にいくつかの「LLM 呼び出し」と「ツール呼び出し」の子 span がぶら下がる、というように。この層にはすでに標準化されたプロトコルが使えます。OpenTelemetry は汎用の分散トレースの標準で、OpenInference などの規範はその上に LLM アプリ特有の意味的約束（プロンプト、モデルパラメータ、トークン使用量などをどう記録するか）を定義します。標準プロトコルを採用する利点は、収集と分析が疎結合になることです。同じトレースデータを異なる分析バックエンドに接続でき、単一プラットフォームへのロックインを避けられます。

LangSmith はこの領域の代表的なプラットフォームの 1 つ（似た位置づけには Langfuse、Arize Phoenix などもある）で、可観測性、評価、最適化を閉ループに統合します。実行のたびに 1 つのトレースセッションを作成し、その中のモデル呼び出し、ツール使用、知識検索が独立した実行単位として記録され、因果関係でリンクされて 1 本の実行ツリーを形成します。各単位は完全な入出力、時間情報、コストデータ、エラー情報を記録します。プラットフォームは非同期バッチのデータ収集を採用し、トレース自体が Agent の応答遅延に影響しないよう確保します。

プラットフォームはさらに A/B テスト（一部のユーザーのトラフィックを新バージョンにルーティングし、各指標を自動対比し、素早いロールバックや段階的な拡大をサポート）、プロンプトのバージョン管理（各バージョンが実行時の性能データに関連づけられる）、および協働的な開発（チームメンバーがトレースデータと問題ケースを共有できる）をサポートします。本番環境の膨大な実データは継続的改善の金鉱です。予期しなかったシーンを発見し、最も最適化を要する機能点を識別できます。

可観測性データの最も価値ある行き先は、評価資産として還流すること です。1 つの実用的な閉ループはこうです。本番軌跡から失敗と疑わしいケースを選別 → 匿名化処理（ユーザーのプライバシー、鍵などのセンシティブなフィールドを除去）→ 評価集の新しいケースと回帰テストとして蓄積。こうすれば評価集はもはや一度きりに構築した静的な集合ではなく、製品の進化とともに継続的に実ユーザー分布に近づく生きた資産になります。今日オンラインで露呈した失敗モードが、明日にはこの底線を守る回帰ケースになるのです。これがまさに可観測性と本章の評価の本筋とのインターフェースです。可観測性は「現実世界で何が起きたかを見る」ことを担い、評価はこれらの観察を繰り返し検証できる基準として固定することを担います。

完備された評価体系とデータセットを備えた後、鍵は評価結果を実質的なシステム改善へと転化することにあります。

Benchmark レポートからシステム改善へ

ここでは、付属リポジトリに保存された AndroidWorld の実際の改善試行を見ます。対象は API 35 エミュレーター上の Wi-Fi 設定 4 タスクだけで、各タスクにつき 1 回のペア実行です。116 タスクの完全な Benchmark でも、API 33 の標準環境での再検証でもありません。価値があるのはシステム全体の改善率を示すことではなく、1 ラウンドの結果から次の 1 変更をどう決めるかを示す点です。

Harness 工学の視点から見ると、この節が本質的に語っているのは Harness の反復最適化の方法論です。評価データを通じて Harness の弱点（コンテキスト不足？ 制約の欠如？ 検証の不足？ フィードバックの遅れ？）を特定し、的を絞って改善し、再び評価して、Harness が継続的に進化する閉ループを形成します。

Benchmark レポートの分析を始める前に、見落とされやすい 1 つの原則があります。Agent の性能低下を見たときは、まず評価システム自体をチェックしてから Agent に手をつけるべき です。よくある誤りは、スコアの低下を見た途端に Agent のコードを修正し、評価システム自体が先に問題を起こしているかもしれないことを無視することです。歪んだ信号に基づいて方向を調整すれば、改善の方向が最初から誤っているかもしれません。評価システムのよくあるエラー源には、実行環境のリソース不足でプロセスが kill される（ランダムな失敗として現れる）、検証器自体にバグがあり正解を失敗と判定する、テストケースと本番シーンの間に乖離がある、などがあります。これらの問題は結果の数字上ではモデルの退化とまったく同じに見え、完全な軌跡を精査してはじめて区別できます。

Benchmark レポートを読み解く：問題発見の技

最初のレポートは 116 タスクを各 1 回実行し、全体成功率は約 88% でした。ただし失敗は散発的ではありません。4 つの SystemWifiTurn* タスクのうち 3 つが失敗し、軌跡には画面を行き来する、最終状態を確認できない、といった挙動が繰り返し現れました。考えられる原因は少なくとも 2 つあります。設定画面への行き方を知らないか、Agent に渡る画面情報が足りないかです。

88% という総合値だけを見ると、この小さな失敗の塊は埋もれます。ステップ上限を増やすだけでは、「画面が見えていない」問題を「時間が足りない」問題と取り違えかねません。まず失敗が集中するタスクと能力を特定し、軌跡を再生して、見る・考える・操作する・検証するのどこで詰まったかを分けます。4 つの Wi-Fi タスクへの絞り込みは低コストの原因診断であり、システム全体の性能推定ではありません。

データから仮説へ：改善のロードマップを構築する

最初に、最も安い変更を試しました。H1 は「道順が分からないだけ」という仮説で、実験群に Wi-Fi 設定への案内と最終状態の確認指示を追加しました。しかし成功率は変わらず、原因がプロンプトではないことが分かりました。

次に Agent が何を見ているかを調べました。H5 では、API 35 と互換性のない accessibility feed を、AndroidWorld が対応する UIAutomator の要素ツリーに置き換えました。成功率は上がりましたが、完全なツリーは長く、token 使用量が急増しました。そこで H5C は新情報を足さず、不可視・テキストなし・操作不能のコンテナを削り、成功率を保ったままノイズを減らせるかを試しました。

3 ラウンドともモデル、タスクパラメータ、乱数シード、ステップ上限、エミュレーターを固定し、対照群と実験群の実行順を交互にしました。各ラウンドで変えるのは 1 変数だけです。前の結果で見つかった問題が、次のラウンドで検証する唯一の変更になります。

結果から意思決定へ：データ駆動のトレードオフ

3 ラウンドの実測値を表 7-5 にまとめます。各群 4 タスクしかないため、ここで判断できるのは試験を拡大する価値があるかどうかまでです。AndroidWorld 全体の成功率は推定できません。

表 7-5 AndroidWorld の Wi-Fi サブセットに対する 3 ラウンド

3 ラウンドを通して見ると、単独の百分率より有用な知見が得られます。Agent がそもそも受け取っていない情報は、詳しいプロンプトでは補えません。この種の失敗では、まず入力を確認します。一方、情報は多ければよいわけでもありません。完全な要素ツリーは「見えない」問題を解決したものの、大量のノイズを増やしました。意味のないノードを削った後も 4 タスクはすべて成功し、token は約半分になりました。モデルを変えず、Harness の画面表現だけで、まず実行可能性、次にコストを改善できたのです。

継続的反復：最初の改善からシステムの進化へ

H5C が 4 タスクを通過したのは、次の試験に進む資格を得たという意味にすぎず、デプロイ可能という意味ではありません。次は第三者アプリも含め、Pixel 6 / API 33 の標準環境で 116 タスクを 5 シードずつ実行します。成功率は非劣性、token 比は 0.75 以下、遅延比は 1.5 以下が条件です。この完全再検証までは、サブセットの 4/4 をシステム全体の 100% と書けません。

継続的な反復とは、証拠の規模に見合う次の一歩だけを認めることです。H1 の失敗でプロンプト追加を打ち切り、H5 で方向を見つけると同時にコスト問題を発見し、H5C でそれを解いて初めて試験を拡大できます。良い Benchmark レポートはスコアだけでなく、結論の適用範囲、未達のガードレール、次に検証する項目まで明記します。

実験 7-13 ★★★：AndroidWorld の評価と改善

本実験では、評価レポートからシステム改善までの流れを練習します。chapter6/android-world に保存された過去のレポートと 3 組のペア実行を出発点にします。

第 1 歩：診断。タスクごとの表と能力ラベルマトリクスを交差分析し、表面的なタスクの失敗を深層の能力欠陥にマッピングします。予想を下回る成功率の能力ラベルと集中的に失敗するタスク領域を識別します。

第 2 歩：仮説の構築。三層フレームワーク（表層→中層→深層）に沿って改善仮説を立て、各仮説に予想される成功率向上目標と検証方法を明確にします。

第 3 歩：段階的実験。H1、H5、H5C を再現し、各ラウンドで 1 変数だけを変更します。成功率に加えて token、遅延、リグレッションを記録します。

第 4 歩：データ駆動の意思決定。コスト収益比に基づいてデプロイの意思決定を行います。単純にすべての有効な改善を採用するのではなく、各改善の適用範囲、遅延への影響、コスト開銷を天秤にかける必要があります。低コスト高収益の改善を優先してデプロイし、高コストの改善は重要なシーンに限定して使います。

第 5 歩：反復。小規模試行を通過しても、進めるのは完全再検証までです。標準環境で 116×5 回を終える前にデプロイを論じません。レポートには環境差、標本数、未実施部分を残します。

外部評価から内部評価へ：本番級 Agent の評価インフラ

前のいくつかの節では、いかに Agent システムを外部から評価するか——評価環境の構築、データセットの設計、Benchmark レポートの分析——を論じました。しかし最も優れた Agent 製品は外部評価を受け入れるだけでなく、継続的な自己評価のインフラを内蔵しています。以下では第 5 章で紹介したオープンソースの汎用 Agent OpenClaw を例に、トップの Coding Agent 製品の公開技術分析と実務者の共有を交えて、参考に値する内部評価体系を示します。それは ML 研究の実験方法論を系統的に製品工学に埋め込んだものです。

アブレーションインフラ：各特性の真の寄与を理解する

ML 研究者は長らくアブレーション実験（Ablation Study）を使って、モデルのどのコンポーネントが本当に重要かを理解してきました。いわゆるアブレーションとは、あるコンポーネントを 1 つずつ「取り外し」、全体性能がどれだけ落ちるかを見ることです。OpenClaw はこの方法論を製品工学に持ち込みました。システムに 1 つの総スイッチを内蔵し、複数の主要な特性（思考モード、コンテキスト圧縮、自動記憶、バックグラウンドタスクなど）を同時に無効化して、「素のモデル」ベースラインを作れます。これによりチームは 1 つの鍵となる問いに答えられます。ある特性は本当にユーザー体験を改善したのか、それとも役立つように感じるだけなのか？

アブレーションを一度きりの研究ではなく常態的な工学実践とすることには、いくつかの実際的な意義があります。まず、アブレーションスイッチは起動経路のごく初期——いかなるモジュールレベルの定数が設定値を捕捉するより前——に注入しなければなりません。これはアブレーションインフラを最初からシステムアーキテクチャに設計し込まなければならず、後付けではだめだということを意味します。次に、定期的にアブレーション実験を走らせること（大きなバージョンリリースごとなど）で、「特性の負債」——かつて有効だったがモデルの進化とともにもはや不要になった特性——を発見できます。本番 Agent を構築するどのチームにも、推奨される実践はこうです。各主要特性は独立して無効化できるべきで、チームは定期的に各特性の実際の寄与を検証すべきです。

AB テスト方法論：メカニズムと目標を区別する

成熟した Agent 製品は自身の振る舞いに対して厳格な AB テスト（すなわちユーザーをランダムに 2 グループに分け、一方は旧バージョン、一方は新バージョンを使い、両グループの実際のデータを対比して変更が有効かを判断する）を行います。精緻に設計された Agent の AB テスト事例は、いくつかの鍵となる方法論的原則を示しています。

二値ではなく多腕。「ある」と「ない」を対比するだけでなく、複数の漸進的なバリアントを設計します（例えば異なる強度のプロンプト制約をテストするとき、対照群と 3 つの漸進的により厳格な実験群を設ける）。この設計は用量・効果関係を明らかにし、最適点を見つける助けになります。

メカニズム指標と目標指標を区別する。これは最も犯しやすい誤りです——あなたが変えているものを最適化目標だと勘違いすることです。例えば「Agent の計画ファイルの長さを短くする」をテストしているなら、計画の長さはメカニズム指標（あなたが直接変えているもの）ですが、それは目標ではありません。本当の目標は「セッションレベルのコストを下げる」かもしれません。計画ファイルを短くすればコストが下がるかもしれませんが、計画が詳細でないために編集・チェック・編集のループが増え、かえって総出力量が増えるかもしれません。常に自問してください。私が変えているもの（メカニズム）と、私が本当に気にしているもの（目標）は同じか？ もし違うなら、目標を基準にします。

ガードレール指標を設定する。目標指標が改善したとしても、ユーザー満足度が下がる、操作回数が増える、あるいはエラー率が上がるなら、実験は停止すべきです。ガードレール指標は「悪化してはならない底線」です。

ベースライン統計を記録する。標本量、分布のパーセンタイル、相関分析（「拒否率が計画サイズに単調増加する」など）を含め、実験結果の解釈に必要なコンテキストを提供します。ベースラインがなければ、実験結果が統計的有意性を持つかを判断できません。

二層特性スイッチシステム

Agent 製品は初日から特性スイッチ（Feature Flag）インフラを設計する必要があります。いわゆる特性スイッチとは、ある機能をユーザーに対して有効にするか無効にするかを、コードを再デプロイせずにリモートで制御できるスイッチのことです。それは同時に 3 つの目的に資します。実験、段階的リリース、緊急遮断です。

コンパイル時スイッチ はビルド段階で関連コードを成果物から物理的に取り除きます。内部専用の特性は外部ビルドにはそもそも存在せず——リバースエンジニアリングしても取り除かれた機能は発見できません。これはクリーンなアブレーションメカニズムでもあります。ある特性を無効化するのは実行時にロジックをスキップするのではなく、対応するコードが物理的にそもそも存在しないのです。

実行時スイッチ の設定はサーバー側から配信され、ローカルディスクに 1 部キャッシュされます。設計上、やや古いキャッシュ設定を読む方を選んでも、Agent がネットワークリクエストを待って起動をブロックさせてはなりません。具体的なグループ分けの決定は実験プラットフォーム（GrowthBook など）を通じて完了し、AB テストグループの割り当てに使います。1 つの鍵となる設計の細部は、各特性の露出イベントが各セッションで最大 1 回しか記録されないことです。重複記録が実験データを汚染するのを避けます。

Agent 開発者への示唆はこうです。特性スイッチはデバッグツールではなく、一等市民級のアーキテクチャコンポーネント です。

プロンプト敏感性評価

システムプロンプトは Agent の振る舞いの核心的な「コード」ですが、通常のコードと同等のバージョン管理と回帰テストを欠いていることがしばしばです。OpenClaw のやり方は、指定した git バージョンで完全にレンダリングされたシステムプロンプト——すべての動的条件が展開された後の最終テキストを含む——を抽出できる専用ツールを提供することです。これによりチームは正確に答えられます。どの commit がプロンプトを変えたか？ 評価集への影響は何か？

どの Agent チームにも、推奨される実践はこうです。(1) システムプロンプトは決定的にレンダリングできるべき（同じ設定入力が与えられれば、永遠に同じ出力を生む）。(2) プロンプトのバージョン化スナップショットのメカニズムを確立する。(3) プロンプト変更のたびに評価集で回帰テストを走らせる——ちょうどコード変更が CI を走らせる必要があるように。

プライバシー配慮の分析を評価の基礎とする

評価は良いデータに依存しますが、Agent 製品が扱うのはしばしばユーザーのセンシティブな内容です。OpenClaw は型システムを通じてこの矛盾を解決します。分析インターフェースは特殊な型でラップされた値しか受け付けず、型名そのものが監査の手がかりになります——それは率直に「これがコードやファイルパスでないことを検証済みだ」と宣言します。この設計はプライバシー制約を、文書化された規範から、コンパイル時に強制される型チェックへと変えます。

核心原則はこうです。最初からプライバシー制約を設計に組み込み、後付けにしない。もしあなたの分析システムが安全にデータを収集できないなら、有効に評価することはできません。プライバシーと評価は対立しません——プライバシー配慮の設計は、本当に何を計測する必要があるか を真剣に考えることを迫り、これがかえってより精確な評価指標を生み出すのです。

外部から内部へ：評価思考の転換

本節の核心メッセージはこうです。前のいくつかの節はいかに外部から Agent を評価するかを教え、本節が明らかにするのは最良の Agent 製品がいかに内部から自らを評価するかです。外部評価は「Agent がどれほど優れているか」を教え、内部評価インフラは「どの変更がそれを良くしたか」を教えます。アブレーション実験はどの特性が本当に重要かを発見し、AB テストは各変更の影響を定量化し、特性スイッチは実験とロールバックのインフラを提供し、プロンプト敏感性評価はシステムプロンプトを CI 体系に組み込み、プライバシー配慮の分析はデータ収集のコンプライアンスを確保します。この 5 つのコンポーネントが共に評価駆動の製品工学を構成します——たまに一度評価するのではなく、評価を製品の意思決定の一つひとつに埋め込むのです。

シミュレーション環境：評価からポストトレーニングへの橋

評価の終点は採点ではなく、改善です。本章はすでに改善の 2 つの道を示しました。Harness の調整（Benchmark レポートからシステム改善へ）と、評価を製品工学に埋め込むこと（内部評価インフラ）です。そして改善の最強の形態は訓練です。目標が「既存の能力を評価する」から「新しい能力を育てる」へと拡張するとき、特に第 8 章で論じるポストトレーニング技術を通じて、評価環境は シミュレーション環境 へと進化する必要があります。Agent が繰り返し練習し、自動的に採点される仮想の練習場です。シミュレーション環境と評価環境の核心的な違いはこうです。インタラクションの頻度がはるかに高い（数百万回 対 数千回）、ランダム化が必要（特定の構成の丸暗記を防ぐ）、そして即時のフィードバックを提供しなければならない。応用領域から見ると、シミュレーション環境はデジタル環境（情報処理タスク）と身体化環境（物理世界の知覚と操作）の 2 大類に分かれます。

この橋の両端はこう接続されます。評価側ですでに蓄積した資産は、ほぼシームレスに訓練信号に転換できます。定義の明確な一組の Rubric や検証器は、本質的に 検証可能報酬（RLVR、Reinforcement Learning with Verifiable Rewards） の報酬関数そのものです——採点スクリプトがそのまま報酬スクリプトになり、テストが通るか、状態が達成されたかは、評価の判拠であると同時に強化学習の報酬でもあります。しかし訓練は評価段階では気にしなくてよかった新しい要求を突きつけます。1 つは 信頼できる reset の意味論 です。訓練は数百万の episode（1 つの episode とは初期状態からタスク終了までの 1 回の完全なインタラクションのラウンド）を走らせ、各 episode は環境を確定的でクリーンな初期状態にリセットできなければならず、さもなくば勾配信号が前ラウンドの残留状態に汚染されます。もう 1 つは 評価をはるかに上回るスループット です。評価は数千回で結論を出せば充分ですが、訓練は許容できる実時間の中でモデルに数百万回のインタラクションを与えねばならず、環境の並列度と単一インスタンスの開銷が訓練の実行可能性を直接左右します。この 2 点——報酬関数化された検証器、訓練向けの reset とスループット——はいずれも第 8 章で展開します。

デジタル環境 の面では、AWorld フレームワークが GAIA タスクのために制御可能な MCP サーバーサンドボックスを構築し、26 個の MCP サーバーを提供し、126 個のツール関数をカバーし、本物の API への直接アクセスがもたらす BAN や制御不能な副作用を避けます。すべてのツール呼び出しは再生可能で監査可能です。AWorld の分散アーキテクチャは従来の直列実行の 7695 秒を 525 秒に短縮し（14.6 倍の高速化）、環境のステートレス設計により各インスタンスが完全に独立し、効率的な並列をサポートします。

身体化環境 の面では、RoboTwin2 が物理エンジンに基づいて双腕操作タスクを構築し、環境は物体の位置、向き、外観をランダム化して汎化能力を高めます。観測空間はマルチカメラの視覚と関節状態を含み、動作チャンキング（Action Chunking）——モデルが一度に複数の連続動作を計画する——を通じてリアルタイム制御を実現します（詳しくは第 6 章）。OSWorld は仮想マシンのスナップショットを通じてリセット可能性を実現し、AndroidWorld はモバイルアプリの自動化に焦点を当てます。デジタル環境であれ身体化環境であれ、シミュレーション環境は同様に第 4 章で論じた隔離実行環境と仮想身元メカニズム（VM/コンテナ隔離、住宅プロキシ、Human-in-the-Loop 認証、共有ファイルシステム）を必要とします。ここでは繰り返しません。

実験 7-14 ★★：OpenVLA と RoboTwin2 の身体化知能環境を構成する

ロボット操作のシミュレーション環境を構築します。ch7/SimpleVLA-RL と OpenVLA のドキュメントを読み、視覚・言語・行動モデルのアーキテクチャ（視覚エンコーダ + 言語モデル + 行動デコーダをエンドツーエンドに統合、画像とテキストを共有の意味空間に投影）を理解します。RoboTwin2 環境を構成し、観測空間（3 視点 RGB + 14 次元関節状態）と行動空間（14 次元制御ベクトル）を理解します。move_can_pot における環境ランダム化メカニズムと空間制約ロジックを研究します。事前学習済みモデルの評価を実行し、成功率、完了時間、失敗モードを記録し、動作チャンキングメカニズムの影響を重点的に観察します。

忠実度のトレードオフと領域ランダム化

高忠実度の環境はより良く現実世界に転移できますが、計算開銷が大きいのです。忠実度のもう 1 つの次元はランダム化の程度です。適度なランダム化は汎化能力を高め、過度なランダム化はタスクを難しくしすぎます。領域ランダム化（Domain Randomization） はシミュレーションと現実のギャップ（sim-to-real gap）を縮める鍵となる技術です。物理パラメータ、視覚外観、センサーノイズなどの面で大範囲のランダムな変化を導入します——さまざまな照明と角度の下で把持を練習しておけば、本物の環境でも光の変化で取り落とさないのと同じです。デジタル環境では、sim-to-real はインターフェースのレンダリング、応答時間などの面での差異として現れ、遅延と失敗のランダム化を導入することで緩和できます。

本章のまとめ

本章の中心にある問いは、Agent が本当に改善したとどう判断するかです。この鎖は 4 つの環節から成ります。まず何をもって成功とするかを整理し（Pass@k、Best@k、Pass consecutive@k の基準の違い）、次にタスクがどこから来るかを定め（公開ベンチマーク、自作の業務集、本番軌跡の還流という 3 つの出所）、続いて検証の方式を選び（決定的検証器から検査項目リスト、Rubric と LLM 評定、さらに配対比較まで）、最後にスコアを意思決定へ変えます（統計的有意性、失敗の帰属、回帰タスク、モデル選定）。どの環節が崩れても、結論は信用できません。実測からはさらに 4 つの注意点が得られました。構造化メモリと RAG の併用は相乗効果を保証しない。キャッシュと圧縮の削減率は足せない。参照音声の選び方でマルチモーダル評価の意味が変わる。そして Agent が UI を読めるか、そのために何 token 使うかは、Harness が入力をどう表現するかに左右される。モデル選定では一点の成績ではなく、資源予算ごとの能力曲線を比べるべきです。本番評価は時折行う試験ではなく、製品判断に組み込まれた継続的な検証です。

本書全体の構造から言えば、本章が組み立てているのは第 1 章の発見ループにおける証拠の区間です。失敗帰属が、後続の提案に拠るべき根拠があるかどうかを決めます。

軌跡プレフィックス境界評価はさらに、ある情報を得ることと、それを現在の判断に正しく使うことは別の能力であることを示しています。エンドツーエンドの回帰テストは基本タスクが退化しないことを保証し、trajectory prefix の境界セットはスコープの判断、現在の指示による上書き、確認の求め、危険な操作の前の確認を直接検査します。ユーザーメモリは、この汎用的な方法の一つの事例にすぎません。本番水準の Agent の評価は、たまに一度行う試験ではなく、実際の問題事例から回帰タスクと境界タスクを継続的に生成する検証システムなのです。

核心的な方法論：観察→仮説→実験→検証→新しい認識→新しい仮説。これが Agent 工学を経験駆動の「錬金術」からデータ駆動の科学的工学へと転換させます。

本章で紹介した評価体系は 1 つの完全な閉ループを形成します。評価環境 が自動化されたテストインフラを提供する → 評価データセット がテストケースを定義する → 自動化評価方法（決定的検証器、LLM-as-a-Judge、Rubric）が Agent の性能を採点する → Benchmark 分析 が改善の方向を明らかにする → システム改善 が問題を修復する → 評価環境とデータセットを更新し、新しいラウンドの反復を始める。

本章で確立した評価体系は現在のシステムの最適化に資するだけでなく、次章のモデルのポストトレーニングに鍵となる基礎も提供します——評価環境とデータセットはポストトレーニングの重要な入力であり、シミュレーション環境はポストトレーニングの練習場です。次章では評価からモデルレベルの改善へと転じ、いかに SFT と RL を通じてインタラクション方策をモデルパラメータに書き込むかを深く論じます。

演習問題

1. ★★ LLM-as-a-Judge は言語モデルを使って言語モデルの出力を評価します。この「自己評価」には系統的な盲点が存在するのでしょうか——例えばモデルがある種のスタイルの回答に一貫して高得点をつけ、その好みが人間の評定と一致しない、というような？ こうしたバイアスをどう検出し校正しますか？
2. ★★★ 評価データセットの「漏洩防止」設計はきわめて重要です。しかしオープンソースのエコシステムでは、benchmark データがいったん公開されると、すぐに訓練データに取り込まれます。この「いたちごっこ」に終局はあるでしょうか？ データ漏洩に根本的に抵抗する評価方法を設計してください。
3. ★★ Scale AI の四準則（専門家の指導に基づく、網羅的なカバー、基準の重要性の重み付け、自己完結した評価）は評価の主観性を排除することを狙いとしています。しかし一部のタスク次元（「回答が役立つか」「語気が適切か」など）は本質的に主観性を持ちます。こうした主観的な次元に信頼できる Rubric をどう設計しますか？
4. ★★ τ-bench は本物のユーザーの振る舞いをシミュレートして Agent を評価します。しかしシミュレートされたユーザー自体も 1 つの LLM です——それはある種のエッジシナリオ（感情が激しい、表現が不明瞭なユーザーなど）を系統的に過小評価するかもしれません。シミュレートされたユーザー自体の品質をどう検証しますか？
5. ★★ 配対比較（Bradley-Terry モデル）は好みが推移的である（A > B かつ B > C なら A > C）と仮定します。しかし人間の好みはしばしば推移性に反します。Agent 評価において、非推移的な好みはどんなシーンで現れうるでしょうか？ これはランキングの信頼性にどう影響しますか？
6. ★★ 本章は能力の上限を表す Pass@k と、業務上の信頼性を表す Pass consecutive@k を区別しました。単発の成功率が 60% しかない Agent について、タスクの失敗コスト、リトライコスト、副作用をどう組み合わせて、どちらの指標を報告するか、$k$ をどれだけ大きく取るかを決めますか？
7. ★★ 本章は「観察→仮説→実験→検証」の科学的方法を提起しました。しかし実践では、Agent の行動空間は巨大で、1 つの仮説の検証に数百回の評価実行が必要かもしれません。限られた計算予算の下で、いかに評価の情報量を最大化しますか？
8. ★ AndroidWorld の試行では、完全な要素ツリーで成功率が 25% から 100% に上がる一方、token は対照群の 2.498 倍になりました。簡素化後も成功率は 100% のまま、token は 0.506 倍です。アクセシビリティ、状態確認、後続操作に必要な情報を失わず、意味のない UI ノードを自動的に削るには、どのようなルールを設計すべきでしょうか？
9. ★★ τ-bench のユーザーシミュレーションは「漸進的情報開示」を採用しています——すべての情報を一度に提供せず、Agent の質問に応じて段階的に開示します。この設計は評価結果にどう影響しますか？ もしシミュレートされたユーザーの情報開示戦略が本物のユーザーと大きく異なるなら、評価結論はなお信頼できるでしょうか？