演習問題の解答例¶
本ファイルは全 10 章の演習問題について、参考となる解答の概要をまとめたものです。演習問題の多くは開放的な問題であり、答えは一つではありません。参考解答は AI が生成し、人手で簡単に校閲したもので、読者が照らし合わせて着想を得るためだけのものです。読者の皆さんには、LLM を使い本書の内容と組み合わせて、これらの問題をさらに議論することをおすすめします。
第一章 AI Agent 入門¶
1. (★★) もし Agent システムに一つだけ能力を追加できるとしたら——より強力なモデル、より豊富なコンテキスト、それともより多くのツール——あなたはどれを選びますか？どのような条件でその選択は変わりますか？
「脳/目/手足」の公式に対応させ、まず短所を探します。通常はコンテキストの補強、すなわち観測空間（Observation Space）の補強を優先します。タスクがモデルの推論能力を超えるなら、より強力なモデルに換えます。行動空間が不足しているなら（たとえば社内システムにアクセスできないなど）、ツールを追加します。判断の根拠は失敗軌跡を分析し、ボトルネックが知覚・意思決定・行動のどこにあるかを特定することです。
2. (★★★) ReAct ループでは、Agent の LLM 呼び出しは毎回、完全な履歴軌跡を目にします。軌跡が伸びるにつれ、この設計のコストは二次関数的に増大します。重要な情報を失わずにこの二次関数的増大を打破する方法はあるでしょうか？
実行可能な手段：コンテキスト圧縮——初期の軌跡を要約し、結論と重要な状態だけを残します（第 2 章の多層圧縮）。外部化学習——中間結果をファイル/知識ベースに書き込み、コンテキストに常駐させずに必要に応じて検索します。サブ Agent への分割です。
3. (★★) 「モデルがすなわち Agent」というパラダイムは、モデルがツール呼び出しの意思決定においてますます自律的になることを意味します。しかし本章は、Harness エンジニアリングの重要性がむしろ増していることを論じました。この 2 つのトレンドはどう共存するのでしょうか？Agent フレームワークの今後の中核的価値はどのような側面に表れるのでしょうか？
馬と手綱の比喩：モデルが強いほど自律の余地は大きくなり、誤ったときの影響範囲も大きくなるため、制約・検証・修正がますます必要になります。フレームワークの価値は「LLM 呼び出しのオーケストレーション」から、Harness の 5 要素における保障層——権限分類、サーキットブレーカー、エラー回復、コンテキスト圧縮、ツールエコシステム——へと移ります。
4. (★★) アブレーション実験では、「ツール結果のフィードバック」の欠如によって Agent が無限ループに陥りました。本番環境では、ツール結果の欠如以外に、Agent をループに陥らせる可能性のある状況はどのようなものがあるでしょうか？あなたならどのような検出・終了の仕組みを設計しますか？
他の誘因：ツールが同じエラーを繰り返し返す、存在しないツールをハルシネーションで呼び出す、コンテキスト圧縮で重要な状態が失われる、思考過程が剝ぎ取られてモデル API がエラーを返す、タスク自体に解がない、などです。仕組み：最大反復回数などの停止条件を設ける。重複呼び出しを検出する（同一ツール＋パラメータのフィンガープリント）。失敗閾値を超えたら人間の介入へエスカレートする。
5. (★) 本章では知覚・行動・方策の 3 つの次元で 5 つの Agent 製品を分析しました。あなたが日常的に使っている AI 製品を一つ選び、この 3 つの次元で分析し、そのアーキテクチャ設計が妥当かどうか考えてみてください。もしあなたがこの AI 製品を設計するなら、どのような改善の余地があるでしょうか？
開放的な問題です。要点：本章の表にならって、目（どのような情報源を見られるか）、手足（行動空間が開放式か、内部で思考できるか）、方策（Agent の実行ループのパターン）を書き出します。
6. (★★) 航空券の予約を専門に扱うカスタマーサポートシステムを設計するとしたら、ワークフロー方式と自律 Agent 方式のどちらを選びますか？同一のシステム内で 2 つの方式を混在させることは可能でしょうか？
主体はワークフローを使います。本人確認→検索→支払い→予約の 4 ノードで、「支払い前に予約できない」といったコンプライアンス上の順序を保証し、プロンプトインジェクションの攻撃面を単一ノード内に限定します。開放的な部分（要求の理解、便の変更、欠航時の代替案の提案）では自律 Agent に切り替えます。高リスクの操作（高額の支払い、返金）には人間の確認を加えます。
7. (★★★) ガードレールの部分でツールのリスク評価に触れました。あるツールが多くの場合は低リスクだが、特定のパラメータの組み合わせでは高リスクになる場合（たとえば delete_file で通常のファイルを削除する場合と、システムファイルを削除する場合）、あなたなら動的なリスク評価をどう設計しますか？
評価の対象を「ツール」から「ツール＋パラメータ」へと細分化します。可逆性、権限、影響範囲に基づいて呼び出し時にリスクを計算します。モデルの判断ではなく、ルールベースの確定的なチェック（パスのブラックリスト/ホワイトリスト、正規表現）を用います。検証は構造化データのみを見るべきで、プロンプトインジェクションによる操作を防ぎます。
8. (★★) 本章の Agent 製品の表では、すべての Agent の行動空間が「開放式」でした。制限された行動空間（たとえば、あらかじめ定義された選択肢からしか選べない）は、どのような場面でむしろ開放式よりも優れるのでしょうか？
高いコンプライアンス、高リスク、誤りが不可逆な場面です。返金や支払いのように、制限された選択肢はすなわち「制約」であり、本質的にフールプルーフとなり、設計の段階から誤りが起こり得ないようにします。
9. (★★) 人間の介入の仕組みは、Agent が「制御を優雅に引き渡せる」ことを求めます。しかし実際には、ユーザーがオンラインでない、応答が非常に遅い、あるいは曖昧な指示を出すこともあります。このとき Agent はどうすべきでしょうか？
フェイルセーフ：高リスクの操作は確認がないときにデフォルトで実行するのではなく一時停止します。先に可逆で低リスクの部分を済ませ、高リスクの部分は文書に記録して、人間が判断し Agent が回復しやすくします。非同期のコミュニケーションツール（メッセージ、メール）で通知し、タイムアウト戦略を設けます。指示が曖昧なときは意図の明確化を行います。
10. (★★★) 「はじめに」では「良い設計原則はモデルのイテレーションサイクルを貫くべきだ」と指摘されていますが、その原則を実現する具体的なエンジニアリング手法は、モデル能力の進歩とともに時代遅れになる可能性があります。そのような Agent のエンジニアリング手法を一つ挙げ、理由を説明してください。
例 1：制約付きサンプリングによって、ツール呼び出しを厳格な形式に強制すること。これは、不正な JSON を出力したりパラメータを欠落させたりしやすいモデルに対する信頼性の補完策です。モデルの形式遵守能力が高まれば効果は低下し得ますが、高リスクの場面では決定論的な形式検証を引き続き残すべきです。
例 2：モデルが新しい知識を継続的に取り込めないことを補うため、外部知識ベースを導入すること。将来、モデルが信頼できる継続学習能力を備えれば、知識管理の一部は外部システムからモデルのパラメータへ移る可能性があります。ただし外部知識ベースには、リアルタイム更新、正確な検索、アクセス制御、出典追跡という独自の価値があるため、完全に消えるよりも適用範囲が縮小すると考える方が妥当です。
例 3：すべての能力をモデル API の標準ツール呼び出しインターフェースで公開し、独自の呼び出し形式を禁止すること。Skills は別の経路を示しています。能力と操作方法をテキストで記述し、汎用のコマンドラインツールを通じてモデルに実行させます。モデルから見れば、これは汎用実行器の上にある独自のテキスト呼び出しプロトコルを理解し、従うことに相当します。任意のインターフェースを理解するモデル能力が高まるにつれ、「必ず標準ツール呼び出し形式を使う」は普遍的な原則ではなくなります。標準形式は相互運用性、構造化検証、能力の低いモデルには依然として有用ですが、場面に応じたエンジニアリング上の選択であるべきです。
例 4：プロンプトとすべてのツール定義を、あらかじめコンテキストの先頭に置くこと。初期のモデルは指示遵守能力が限られ、慣れた固定位置を外れたプロンプトやツール定義を正しく認識・実行できないことが多かったため、この手法が使われました。Skills は実行中に必要なプロンプトをコンテキストの途中へ読み込み、動的ツール発見は見つけた新しいツール定義を既存の軌跡の後ろへ追加します。指示遵守能力が向上し、こうした動的読み込み方式に特化したポストトレーニングを受けるようになれば、プロンプトとツール定義をコンテキストの先頭に固定する必要はなくなります。
第二章 コンテキストエンジニアリング¶
1. (★★★) 実験 2-3 では、スライディングウィンドウ方式の対話履歴が Agent に同じツール呼び出しを繰り返し実行させることが分かりました。しかし履歴を完全に保持すると、今度はコンテキストがどんどん膨張します。情報の損失を避けつつコンテキスト長を制御し、しかも KV Cache の接頭部を壊さない戦略を設計してください。
① 破棄ではなく圧縮を用います。メッセージは追加のみで削除・改変せず、閾値（たとえばウィンドウの 80%）に近づいたら古い tool results をまとめて圧縮します。② 多層の仕組み：大きな出力はディスクに落として要約を残し、ノイズはそのまま削除し、アーカイブ式の要約で文脈の流れを保ちます。③ サブ Agent による隔離で、中間状態をメイン コンテキストに入れません。
2. (★★) Qwen3 の Chat Template の思考連鎖保持の仕組みは、「最後の本物のユーザーメッセージより後」の思考だけを保持します。もし ReAct ループが百を超えるラウンドのツール呼び出しにわたる場合、蓄積された思考内容が大量のコンテキストを消費しかねません。あなたなら超長ループに対応するためにこの仕組みをどう修正しますか？DeepSeek R1 はかつて履歴の思考をすべて剝ぎ取ることを求めていましたが、DeepSeek V4 では全ての reasoning_content の返送が必須へと逆転しました——この 2 つの正反対の戦略を比べると、それぞれどのような利点と欠点があるでしょうか？この逆転は何を示しているでしょうか？
修正の方向：スライディングウィンドウによる保持——直近の数ラウンドの思考を完全に保持し、ウィンドウの外では（固定ラウンド数ではなく）token 予算に基づいてローリング圧縮をトリガーし、構造化されたステータスバー（現在の目標、確認済みの事実、除外済みの経路、ToDo）を生成します。圧縮は一度だけ、しかも位置を固定して行われるため、キャッシュ再構築のコストは毎ラウンドではなく一度きりです。R1 の剝ぎ取り：token を節約でき、接頭部が安定してキャッシュに有利で、しかも訓練分布と一致します（履歴の CoT は入力に一度も現れません）。しかし毎ラウンドゼロから推論するため、長期的な計画が失われ、同じ誤りを繰り返しやすくなります。V4 の強制返送：思考が一貫し、長期的な agentic タスクでの性能がより良くなります。しかし token コストが高く、毎ラウンド接頭部が膨張し、しかも非 think モードからシームレスに切り替えられません。逆転が示すこと：純粋な対話の場面では思考は廃棄物ですが、agentic な場面では思考は状態です——業界の実践はすでに後者へと傾いています。
3. (★★) コンテキスト感知圧縮の実験では、約 148K 文字から約 2,000 文字へと圧縮しました。このような極端な圧縮に「不可逆な情報損失」のリスクはないでしょうか？どう解決しますか？
リスクはあります。圧縮は有損の射影であり、問題が保持されなかった次元に落ちると崩壊します。解法：「有損圧縮＋無損索引」とし、各事実に出典 URL を付けて遡れるようにします。元の出力はディスクに保存し、要約プレビューだけを見ます。優先度を明示的に保持します——アーキテクチャ上の判断、意味の完全性（時刻、会社名）、検証状態、UUID/hash などの識別子はそのまま残します。適応的なウィンドウ化で圧縮のタイミングを遅らせます。
4. (★★) Agent のステータスバーは暗黙の状態を明示化します。しかしステータスバー自体が誤った情報を含んでいる場合（たとえばツールのカウンターにバグがあるなど）、Agent は誤った情報に基づいて有害な意思決定をしかねません。この「メタ情報の信頼性」の問題はどう緩和すればよいでしょうか？
モデルはステータスバーをほぼ無条件に信じるため、誤りはそのまま伝わります。緩和策：① 確定的なコードで維持し、長い履歴を LLM に一括集計させることは絶対にしません（使う場合も一つずつ抽出し、コードで集計します）。② ステータスバーの正確率を第一線の本番指標として注視します。③ 情報は現実世界に対する信頼できる観測のみに由来させ、ステータスバーへの汚染を防ぎます。
5. (★★) プロンプトエンジニアリングのアブレーション実験は、情報の整理が乱れると成功率が 30% 以上低下することを示しました。しかし実際の開発では、システムプロンプトは往々にして複数人が異なる時期に保守します。あなたならシステムプロンプトの「エントロピー増大」を防ぐためにどのようなエンジニアリング実践を用いますか？
① プロンプトをコードとして扱います。バージョン管理、レビューを行い、プロダクトマネージャーがビジネスルールを定め、エンジニアがコーディングを担います。② Tau-Bench のようなベンチマークで回帰テストを行い、変更前後でアブレーション実験を走らせて影響を特定します。③ 構造化を強制します。ルールの積み重ねではなく SOP フロー駆動とし、XML/Markdown で階層化します。④ 断片を「キャッシュ可能/キャッシュを壊す」で分類して命名し、動的な内容はキャッシュ境界より後に配置します。⑤ 膨張した内容は Skills に切り出して必要に応じて読み込みます。
6. (★★★) 本章は「文脈内学習の本質は推論ではなく検索である」と提起しました。この論断が成り立つとすれば、「より多くの情報をコンテキストに詰め込む」ことに基づく現在のすべての最適化の方向を見直す必要があります。あなたはこの限界をどう突破すべきだと考えますか？
「半分しかない検索エンジン」に抽出層を補います。① コンテキスト蒸留/ステータスバー——コードで結論を事前に計算しておき、直接検索できるようにします。② 能動的な圧縮——元の記録を高密度な構造化知識に置き換えます。③ サブ Agent による隔離——ノイズをメイン コンテキストに入れません。④ 第 3 の軸としての対話——外部の計器による観測が、モデルには思いつけない新しい情報を書き戻します。⑤ 最先端の方向：編集可能・組み合わせ可能な KV Cache の「メモ」、およびセッションをまたぐメモリの蓄積です。
7. (★★★) Skills の漸進的開示は、Agent が必要と判断したときにのみ完全な内容を読み込みます。しかしこの判断自体がモデルの能力に依存します——モデルが自分の知らないことを知らなければ、Skill の読み込みを正しくトリガーできません。この「メタ認知」の問題はどう解決すればよいでしょうか？
① Skill のメタデータ（名前、説明）をコンテキストに常駐させ、モデルが常に「自分が何を持っているか」を知っている状態にします。② Skill の description は機能紹介ではなくルーティング条件として書きます——「Use when / Don't use when」とし、漠然とした説明を避けます。
8. (★★) Skills の仕組みでは、Agent が SKILL ファイルから動的にプロンプトを読み取った後、その後の操作はこれらの指示を正しく遵守できるのでしょうか？異なるモデルは Skills 方式のサポートにどのような違いがあるのでしょうか？
Skill の注入方式によります。system prompt に注入すると遵守は最も強いですが KV Cache を壊します。通常のファイルとしてコンテキストの中間に読み込むと、モデルの指示遵守は劣る可能性があります。コンテキストの末尾に注入すると指示遵守は良好ですが、ツール呼び出しのたびに skill 部分の KV を再計算する必要があり、コストが高くなります。
9. (★★★) 本章は、動的な情報（システムのタイムスタンプ、ツールリストの順序など）の変化が KV Cache の接頭部ヒットを壊すことを強調しました。大量のツールを持ち、ツールセットが頻繁に変動する本番システムにおいて、あなたはキャッシュのヒット率を最大化するためにコンテキストのレイアウトをどう設計しますか？
① 少数の安定した中核ツール（たとえば 7 個）＋汎用実行器とし、具体的な能力は Skills の漸進的開示に任せ、ツール定義は静的な接頭部に固定順序で凍結します。② サブ Agent と親 Agent の接頭部をそろえます。
第三章 ユーザーメモリと知識ベース¶
1. (★★) ユーザーメモリシステムにおいて、同一ユーザーが異なるセッションで矛盾する情報を提供した場合（たとえば 2 回にわたって異なる自宅住所に言及した場合）、メモリシステムはこの衝突をどう処理すべきでしょうか？
Mem0 式の「抽出—比較—決定」パイプラインを用います。まずベクトル検索で近い古い記憶を取り出し、次に LLM が ADD/UPDATE/DELETE/NOOP を判定します。たとえば「上海に引っ越した」は UPDATE で「北京在住」を上書きすべきです。バージョン化：住所類の情報は最新版のみを残してタイムスタンプを付け、職歴類は完全な履歴を残します。検索側ではコンテキストの接頭部（人物、時刻、意図。たとえば電信送金を 3 回修正した事例）を借りて、どれが最終的に有効かを判断できます。
2. (★★) コンテキスト感知検索は、元文書のコンテキストを各チャンクに付加します。しかし元文書自体の構造が乱れていたり矛盾する情報を含んでいたりすると、この手法は誤りを伝播させ、さらには拡大しかねません。あなたなら検索の段階で「情報の質」というシグナルをどう導入しますか？
「知識ベースの時効性とガバナンス」を参考にします。チャンクにバージョン番号、有効/失効の時刻、出典などのメタデータを付け、検索時に失効した内容をフィルタリングするか、接頭部に「この項目は某日に廃止済み」と明示的に注記します。並べ替え（リランキング）の段階では、意味的な関連性だけでなく、出典の権威性や時間の新しさをスコアリングに組み込みます。インデックス作成時には、接頭部を生成する LLM にチャンク間の矛盾をあわせて検出させて印を付けさせます。記憶のバージョン化による衝突検出に似た仕組みです。
3. (★★★) エージェント化 RAG（Agentic RAG）は、Agent がいつ・何を検索するか、そして検索を続ける必要があるかを能動的に判断できるようにします。しかしモデルが自分の知らないことを知らなければ、検索を正しくトリガーできません。この「メタ認知」の問題はどう解決すればよいでしょうか？
① prompt/skills の中で「情報が十分かを評価する」ことを明示的なステップとして固定します。たとえば実験 3-9 では、まず子問題を並行検索し、「前科が過失罪の量刑にどう影響するか」という関連が欠けていることに気づいて、二次検索を行います。② 軽量なメタ情報をコンテキストに常駐させて全体的な視野を提供します。たとえば JSON Cards の概観、OpenViking の L0/L1 要約により、Agent が「ライブラリに何があるか」を知ることができるようにします。
4. (★★) マルチモーダルな情報抽出は、図表をテキスト記述に変換してから検索を行います。この「翻訳」の過程で、視覚情報の中の空間的関係が失われかねません。純粋なテキスト記述では完全には伝えられない図表情報の具体例を一つ挙げ、その情報を保持する方策を設計してください。
例：システムアーキテクチャ図の論理関係、折れ線グラフにおける 2 本の曲線の交点の位置、あるいは PDF の表におけるセルと見出しの行・列の対応です。方策その一：ネイティブなマルチモーダル処理。方策その二：マルチモーダルな画像分析ツールを提供します。
5. (★★★) Rich Sutton の「苦い教訓（The Bitter Lesson）」は、汎用的な手法（検索と学習）が最終的には人手で設計した特徴量に勝ると考えます。本章で構築した知識システム全体（チャンク化戦略、インデックス構造、検索パイプライン）は、それ自体が一種の「人手による設計」ではないでしょうか？モデルの能力が十分に強ければ、これらの設計は単純な「全量入力」に取って代わられるのでしょうか？
確かに人手による設計です。一部の工程（チャンク化、融合のパラメータ調整）は長いコンテキストによって弱まる可能性があります。しかし「黒猫白猫」の事例が示すように「全量入力」でも不十分です。注意（アテンション）はソフトな検索であり、文書をまたいだ集計・統計にはやはりインデックス作成時の事前抽出が必要です。知識の期限切れ更新、権限/テナントの分離、監査可能性、コストといったエンジニアリング上の制約はモデルの能力とは無関係です。しかも検索とインデックス作成時の LLM による抽出それ自体が「検索＋学習」の汎用的な手法であり、苦い教訓と対立するものではありません。
6. (★★★) モデルの能力が向上するにつれ、あなたはドメイン知識ベースはなお重要だと考えますか？将来の強力な基盤モデルは、ドメイン知識ベースのすべての情報を含み、それによってドメイン知識ベースを不要にする可能性があるでしょうか？
なお重要です。訓練データには締め切り日があり、知識ベースはいつでも更新できます。企業内部のプロセスや非公開の判例などは、そもそも公開コーパスには存在しません。マルチユーザーでの共有には権限フィルタリングとテナント分離が必要ですが、パラメータ内の知識は呼び出し者に応じて切り分けられません。外部ストレージは監査でき、バージョン管理でき、失効した内容をオフラインにできますが、パラメータ記憶にはそれができません。パラメータ化の路線（ポストトレーニング / User as Engram）を採ったとしても、「覚えるのは簡単だが、それをマルチホップ推論に使うのは難しい」という難題に直面します。
7. (★) RAPTOR はボトムアップの階層的要約によって木構造のインデックスを構築し、GraphRAG は実体（エンティティ）間の関係によってグラフ構造のインデックスを構築します。この 2 種類の構造化インデックスは、それぞれどのようなタイプのクエリに答えるのが得意でしょうか？
RAPTOR：マクロな概念から徐々に細部へと掘り下げる「階層をまたぐ往復」型のクエリです。たとえばまず「SIMD 命令セット」の要約に位置づけ、次に SSE の細部へと掘り下げるように、概観と細部の両方の粒度に対応します。GraphRAG：マルチホップの関係推論（「私の主治医が勤める病院の住所」を関係の連鎖に沿って辿る）や、実体の曖昧性解消（2 人の「張医師」は別のノード）といった「A と B にはどんな関係があるか」型のクエリです。コミュニティ要約はさらにトピックのクラスタリングも提供します。
8. (★★) ファイルシステム・パラダイムは、知識をファイルシステムに似た階層構造として組織します。この方式は、従来のベクトルデータベース RAG と比べて、どのような場面でより優位性があるのでしょうか？
純粋なテキストはユーザーが直接読み、編集し、修正でき、Git でバージョン管理とロールバックができます——人間と機械が共同で知識を保守・審査する必要がある場面に適します。Agent は write_file 能力さえあれば自律的に経験を記録でき、記憶の自己進化ループ（外部化学習）を形成します。L0/L1/L2 の漸進的開示により、多くのクエリは L1 まででも意思決定でき、token を節約できます。前提は Wikipedia のように相互リンクとインデックスページを整備することで、そうでないと孤立したファイルが増えるほど検索が難しくなります。
9. (★★★) 構造化データ（司法判決データベースなど）から「裁判の要素」と「要素の重要度の階層」を自動的に発見することは、本質的には Agent にデータからルールを帰納させることです。このようなデータ駆動の知識抽出は、人間の専門家が手作業でルールを書く場合の品質に達し得るのでしょうか？
利点：CAIL2018 実験のように、「ボトムアップ」の要因発見は人間の先入観よりもデータに寄り添い、何千何万もの判例に散らばっていて専門家が明示的に書き出しにくい暗黙のトレードオフの経験を捉えられ、しかも定量化できます。限界：LLM の抽出が誤れば知識汚染を引き起こし、データ自体の偏りが継承され、クラスタリングのプロトタイプは相関を反映するだけで因果を説明できません。折衷案：データ駆動のモデリング＋専門家による Schema と結果の審査とし、モデルが問いを立て、統計が説明を裏づけます。
第四章 ツール¶
1. (★★) MCP 標準は、ツール定義を Agent フレームワークから切り離しました。しかし標準化は、複雑なツール対話パターン（ストリーミング出力、双方向通信、ステートフルなセッションなど）が標準プロトコルでは表現しにくくなることも意味します。あなたは MCP が今後最も拡張を必要とする能力は何だと考えますか？
最も必要な拡張は、セッションをまたぐイベント駆動の能力です。MCP はすでに複数ターンの対話、変更の購読、長時間タスクを支援できますが、その中核はあくまで能力呼び出しの標準化であり、Agent を常時オンラインに保つことではありません。新着メールや外部コールバックで Agent を呼び起こすこと、複数のイベントをキューに入れて再開・再試行することは、なお Agent フレームワークの役割です。このオーケストレーションにより統一された規約があれば、プロトコルの簡潔さを損なわずに MCP の適用範囲を広げられます。
2. (★★) 非同期 Agent アーキテクチャでは、イベントキューの優先度戦略を設計時に決めておく必要があります。しかし優先度の判断そのものが意味理解を必要とする場合（たとえば、ある新しいメッセージが現在のタスクより緊急かどうかの判断）、この判断は誰が行うべきでしょうか——ルールエンジンか、それとも別の LLM 呼び出しか？それぞれどのようなコストがあるでしょうか？
階層的に併用します。イベントの種類が明確なものはルールでハードコードし、遅延ゼロで確定性が高いですが、「今すぐ止めて」と「今日の天気はどう」の意味的な違いは理解できません。意味が曖昧なものは軽量な分類 LLM に任せてイベントルーターとします。その代償は数百ミリ秒の遅延、追加費用、誤判の可能性であり、しかも Sidecar のように構造化フィールドのみを読み取ってプロンプトインジェクションを防ぐ必要があります。
3. (★★) MCP エコシステムでは、異なる MCP サーバーが機能の重複が大きいツールを提供することがあります。Agent が出所は異なるが機能の似た複数のツールに直面したとき、どう選べばよいのでしょうか？出所の異なる同名のツールが挙動にわずかな差異を持つ場合（たとえば一方は要約を返し、もう一方は全文を返すなど）、Agent はこの差異を感知して利用する能力があるのでしょうか？
選択の根拠：接続前に説明を審査し、バージョンを固定し、最小権限の認証情報を設定し、同名ツールによる遮蔽（tool shadowing）が機微な呼び出しを悪意ある側にルーティングしないよう警戒します。実行時には階層的な分類と動的な発見によって候補を絞ります。モデルが差異を感知できるかどうかは、ツールの説明の質に依存します。
4. (★★★) Agent がユーザーを代表して外部世界とやり取りするとき、本質的に一つのアイデンティティ選択に直面します。独立した仮想的アイデンティティ（専用のメールアドレスと電話番号）で第三者として行動するのか、それともユーザー本人のアイデンティティで直接その個人アカウントを操作するのか、です。前者はバックグラウンドで自律的に操作できますが、第三者が実在の人物でないアイデンティティを信用しない可能性があります。後者はより完全なコンテキストと権限を持ちますが、信頼の委任とセキュリティ境界の問題を持ち込みます。あなたはどのような場面でどちらの方式を選ぶべきだと考えますか？
デフォルトは仮想的アイデンティティです。バックグラウンドで自律的に動き、監査でき、誤りが起きたり侵害されたりしてもユーザーのデジタルアイデンティティ全体を露出しません。秘書が自分の業務用メールを使うようなものです。CAPTCHA/IP レピュテーションの問題に対処する必要があります（住宅用プロキシ）。本人のアイデンティティでなければならない場面（アカウントの本人確認、三者通話での確認。たとえば Pine がカスタマーサポートに電話をかける場合）では HITL 認証を用います。VNC/RDP でユーザーが視覚的に自ら直接ログインします。判断基準：相手がアカウント名義人本人を要求するか、操作のリスクと認証情報の範囲です。
5. (★★) キュー式のイベント処理では、モデルは最後のイベントだけに注目しがちで、本章では Agent のステータスバーによる印付けと集約でこれを緩和しました。しかしキューに 20 個のイベント（ツール結果 10 個＋ユーザーメッセージ 5 件＋システムリマインダー 5 個）が滞留した場合、あなたはモデルが重要な情報を見落とさないよう、これらのイベントの提示順序と形式をどう構成しますか？
まずルールと軽量な LLM で分類・重複排除します。緊急のイベント（アラート、ユーザーによる中断）は個別にキャンセル式の処理へ回し、バッチに混ぜません。長すぎる 10 個のツール結果は切り詰めてファイルに永続化し、先頭・末尾とパスだけを残します。コンテキスト末尾のシステムステータスバーに集約リスト（各種イベントの件数＋一つずつ応答するよう要求）を加えます。
6. (★★) 本章は「実行-検証-フィードバック」の閉ループ（たとえばコードを書いた後に自動で linter を走らせる）を提起しました。この「操作後すぐに自動検証する」パターンは、他にどのようなツールの場面に応用できるでしょうか？検証それ自体のコストやリスクが操作そのものを上回り、このパターンが成立しなくなるような操作は存在するでしょうか？
応用できる場面：設定を変更した後にサンドボックスで実際に動かして有効性を検証する。文書/プレゼン資料を生成した後にスクリーンショットへレンダリングし、モデルのマルチモーダル能力でレイアウトを確認する。成立しないもの：メール送信、電話発信、対外送金など不可逆で冪等でない操作です——観測しようがないか、それ自体が現実世界のイベントをもう一度引き起こしてしまいます。この場合は事前の手段に切り替えるべきです：提案者-審査者による事前承認です。
7. (★★) 本章は「ツール爆発」の問題を提起しました——Agent が数千のツールに直面すると選択の精度が低下します。能動的なツール発見のほかに、どのような方策があるでしょうか？大量の利用可能なツールに直面した人間の専門家の戦略を参考にできます。
① 階層的なグループ化：まず「サーバー/App」に位置づけ、次に具体的なツールを選びます。② Skills 式の「必要に応じて参照」：参考書を引くように、目次をコンテキストに常駐させ、詳細は必要に応じて読み込みます。③ 少数のよく使う基本ツールを「手元に置いて」コンテキストに常駐させ、その他は目次インデックスに頼ります。
第五章 Coding Agent とコード生成¶
1. (★★) コード生成は Agent の「メタ能力」と呼ばれます。しかしコード実行はセキュリティのリスクを持ち込みます——Agent が生成したコードは脆弱性、無限ループ、あるいはリソース枯渇を含む可能性があります。サンドボックスによる隔離は問題の一部を解決できますが、コードの能力も制限します（たとえばネットワークやファイルシステムにアクセスできないなど）。安全性と能力の間で最適なバランス点をどう見つければよいでしょうか？
サンドボックスを場面に応じて段階的に隔離します（コンテナ/microVM）。ネットワークはデフォルトで遮断し、ホワイトリストのプロキシで必要に応じて許可します。ソースコードは読み取り専用でマウントし、API key はサンドボックス内に置きません。サンドボックスのリソースに上限を設けます。サンドボックスのライフサイクルを管理します（タイムアウト）。
2. (★★★) Agent の自己ブートストラップ——Agent を創り出せる Agent——は「知能の自己増殖」を実現します。しかし自己ブートストラップのたびに新たな偏りや誤りが持ち込まれる可能性があり、こうした誤りは世代間で蓄積するのでしょうか？Agent の自己ブートストラップの劣化をどう防げばよいでしょうか？
もし各世代が前の世代の産物の上で繁殖を続けるなら、一部の欠陥は蓄積される可能性があります。鍵となるのは、十分に挑戦的な verifiable task（検証可能なタスク）、たとえば十分に難しいプログラミングタスクを用意することです。
3. (★★) コード生成 Agent はログ解析を扱う際、形式の変化に自動的に追随できます。しかし形式の変化が意図した変更ではなくバグである場合、Agent の適応性がかえって問題を覆い隠してしまいます。Agent は「適応すべき変化」と「報告すべき異常」をどう区別すべきでしょうか？
適応する前にまず診断します。アーキテクチャ文書と PRD に照らして新しい形式が想定どおりかを判断します（実験 5-8 の考え方）。バージョン管理の記録を突き合わせ、変化が正当なコードコミットに対応するのか、出所のないドリフトなのかを確認します。τ-bench の log_mismatch になぞらえ、適応を選ぶ場合でも警告を記録し、黙って互換させるのではなく自動で issue を立てます。不確かなときは人間参加型（human-in-the-loop）の確認を経ます。原則：適応と報告を並行させ、適応が異常のシグナルを飲み込まないようにします。
4. (★★) 本章では PPT 生成、動画編集、ログの可視化で提案者-審査者の仕組みを繰り返し用いました。もし Reviewer の美的な好みがターゲットユーザーと一致しない場合、たとえば Reviewer は情報密度が妥当だと考えるがユーザーは詰め込みすぎだと感じる場合、フィードバックループは誤った局所最適に収束してしまいます。ユーザーの好みのフィードバックも Reviewer のループに参加させるにはどうすればよいでしょうか？
ユーザーのフィードバックを最高優先度の構造化イベントとして Agent の軌跡に注入します。ユーザーの好みを外部化して蓄積します——MEMORY.md に書き込み、好みがタスクをまたいで有効になるようにします。ユーザーが確認しやすいよう、Markdown ではなく HTML 形式の文書として納品します。
5. (★★) 本章は Coding Agent が実行やデバッグで得た経験をコードベースへと蓄積する複数の方法を示しました——知識ベースファイルへの書き込み、アーキテクチャ文書の更新、プロジェクト指示ファイルの保守、操作の列をコードとして固定化すること、などです。これらの経験をさらにシステムプロンプト内のルールへと抽出していくと、ルール集は時間とともに膨張し続けます。蓄積されたルールに「ガベージコレクション」を行い——冗長または時代遅れの項目を識別して整理するには、どうすればよいでしょうか？この Agent 自身が経験を蓄積する仕組みは、第 8 章で論じるシステムプロンプトの自動最適化と、どこが同じでどこが異なるのでしょうか？
GC の考え方：「制約は指導に優先する」——Linter/CI/ツール検証にコード化できるルールはプロンプトから外します。ルールのヒット率を追跡し、LangChain の「失敗軌跡の分析」というデータ駆動の方法を参考にして冗長を識別します。定期的に Agent にコードベースと照らしてルールがなお成立するかを検証させます（時代遅れの文書は無いよりも悪いです）。Markdown＋Git により削除・修正を監査可能かつロールバック可能にします。第 8 章と同じく重みを変えない外部化学習に属します。異なるのは、本章は実行中の増分的な蓄積であり、第 8 章は評価シグナルによって体系的な追加・削除・最適化を駆動する点です。
6. (★) 「リモートワークに友好的なチームは往々にして AI Agent にも友好的である。」あなたの所属するチームや組織は、知識のドキュメント化という点で「AI-ready」からどれくらい離れているでしょうか？最大の障害は何でしょうか？
開放的な問題です。本章の代理指標で自己点検できます。リモートの新人がリポジトリと文書だけで独立して仕事を進められるか、です。チェック項目：意思決定が文書に記録されているか、コンテキストが issue/PR に書き込まれているか、ビルド・テストのコマンドに CLAUDE.md/AGENTS.md のような指示ファイルがあるか、暗黙知（tribal knowledge）が開発者ガイドとして蓄積されているか。よくある最大の障害：「隣の同僚に聞く」口頭伝達とホワイトボード文化への依存です——Agent は口頭の取り決めを読めず、文書しか読めません。
7. (★★★) Simon Willison は Agent の「致命的な三要素」（プライベートデータへのアクセス、信頼できないコンテンツへの露出、外部通信能力の保有）を提起しました。本章はこれに第 4 の要素——永続的な記憶——を加えました。この 4 つの要素を同時に扱う必要のある本番環境で、あなたならセキュリティ戦略をどう設計しますか？
4 種類の境界に沿って多層的に防御します。データ境界：認証情報はマウントせず、ソースコードは読み取り専用とし、可視範囲を最小にします。入力の信頼境界：出所を注記し、外部コンテンツを「参考にはできるが指示としての効力はない」データへと格下げします（忠誠の掟）。出力の影響境界：デフォルトでネットワークを遮断してホワイトリストの出口を設け、ブラックリストではなくコマンドの意味解析を行い、Sidecar による独立した再確認と人間参加型を加えます——重要な操作は必ずコンテキストの外の仕組みによって再確認されなければなりません。セッションをまたぐ境界：MEMORY.md への書き込みは外部コンテンツと同等の信頼審査を経る必要があります。目標は、注入されても実行として外に出ていかないようにすることです。
8. (★★) Artifact 方式は、Agent が生成した SQL やフロントエンドのコードを、ユーザーのブラウザやデータベースで直接実行させます。しかし生成された SQL は破壊的な操作を実行しかねず、生成された HTML は脆弱性を含みかねません。システムの安全性をどう確保すればよいでしょうか？
SQL：クエリは最小権限の読み取り専用アカウントで実行し、CPU、メモリなどのリソース制限を加えて、リソース枯渇を防ぎます。HTML/UI：A2UI のような宣言的プロトコルを優先します。Agent はインターフェース記述の JSON だけを出力し、クライアントは信頼されたコンポーネントカタログでレンダリングし、任意のコードは実行しません。任意の HTML が必要な場合は、インジェクションを防ぐためサンドボックス環境で表示しなければなりません。
9. (★★) ビジネスルールを、ツール内部のデータベースの真値に基づく検証としてコード化し、さらにパラメータ設計によってモデルが呼び出し前にポリシー条件を照合するよう誘導することは、本質的にはコード構造で Agent の振る舞いを制約することです。この「コードがすなわちルール」という方式は、自然言語のルールと比べてどのような利点と限界があるのでしょうか？
利点：曖昧さがなく、確定的で、複雑な条件の組み合わせを得意とします。ポリシーの事実はデータベースの真値とサーバー側の時計から取り、モデルの自己申告値を採用しないため、ハルシネーションもプロンプトインジェクションも迂回できず、不可逆な操作を防ぐ最後の門番となります。expected_* パラメータは強制的なチェックリストを兼ねて思考を導きます。限界：コードはユーザーにポリシーを説明せず、迂回策も探しません。しかも保守コストがかかります。結論：自然言語のルールを代替するのではなく補完します。
10. (★★) Artifact 方式は、Agent に SQL や可視化コードを生成させ、フロントエンドで直接実行させることで、LLM が大量のデータを処理するのを回避します。この「Agent がコードを生成し、システムがコードを実行する」という分業方式は、従来の「Agent が直接答えを出す」方式と比べて、どのような優劣があるのでしょうか？
利点：データがデータベースからフロントエンドへ直接届き、LLM という「仲介者」を迂回します——速く、token を節約でき、大量のデータを書き写す際のハルシネーションによる誤りを避けられ、大量データの提示に適します。コードは監査可能・再利用可能で、パイプラインを組むこともできます（SQL の結果を可視化コードに直接渡す）。欠点：LLM はクエリ結果を見られず、データの内容に基づいてさらなる帰納や意思決定を行えません。モデルがデータを咀嚼してから推論する必要のあるタスクには適しません。
第六章 Agent の評価¶
1. (★★) LLM-as-a-Judge は言語モデルを使って言語モデルの出力を評価します。この「自己評価」に体系的な盲点はないでしょうか——たとえばモデルがある種のスタイルの回答に一貫して高い点数を付け、その好みが人間の評価と一致しない、といったことです。このような偏りをどう検出し、補正すればよいでしょうか？
あります：長さバイアス、回答スタイルのバイアス、同一系統のモデルが抜け穴を突かれること（グッドハートの法則）。検出：100〜200 例の人手によるゴールドスタンダード集を作り、評価と人間との Cohen's kappa を測ります。採点と回答の長さの相関を定期的に監査します。レッドチームが敵対的な事例を構成します。補正：Rubric で冗長さを明示的に罰し、長さを制限します。異なるモデルファミリーによる多源で異種の評価を行います。
2. (★★★) 評価データセットの「漏洩防止」設計はきわめて重要です。しかしオープンソースのエコシステムでは、ベンチマークのデータは一度公開されると、まもなく訓練データに取り込まれてしまいます。この「いたちごっこ」に終わりはあるのでしょうか？データ漏洩に根本から抵抗する評価手法を設計してください。
静的な問題集に終わりはなく、追いかけるしかありません。根本的な打開策は「生成の仕組み」を公開し「具体的なインスタンス」を非公開にすることです。τ²-bench や AndroidWorld のように、パラメータ化されたテンプレートを毎回ランダムにインスタンス化し、固定の解答列ではなく最終的な環境状態に基づいて検証します。
3. (★★) Scale AI の 4 つの基準（専門家の指導に基づくこと、網羅的にカバーすること、基準の重要度に重み付けすること、自己完結的な評価）は、評価の主観性を排除することを狙いとします。しかし一部のタスクの次元（「回答が役に立つか」「口調が適切か」など）は本質的に主観性を持ちます。こうした主観的な次元のために、信頼できる Rubric をどう設計すればよいでしょうか？
抽象的な基準を検証可能な行動へと翻訳します。各段階に具体例と境界事例を添えます。Rubric は反復の産物です——試用の中で評価者間の意見の相違を集め、徐々に判例集へと進化させます。さらに複数の審査員による重み付け/一貫性チェックを補い、意見の相違した事例は人手による再確認に回し、ゴールドスタンダード集の上で一致率を較正します。
4. (★★) τ-bench は本物のユーザーの振る舞いをシミュレートして Agent を評価します。しかしシミュレートされたユーザー自体も一つの LLM です——ある種の周縁的な場面（感情的に高ぶった、表現の不明瞭なユーザーなど）を体系的に過小評価する可能性があります。シミュレートされたユーザー自体の質をどう検証すればよいでしょうか？
τ-bench 初版の教訓：シミュレーターが機械的すぎ、指示が単純すぎました（Agent が答えを当てられてしまう）。検証の手段：シミュレートされた対話を人手で抜き取り検査し、漸進的な開示を守っているか、スクリプト外の情報を捏造していないかを確認します。少数サンプルの本物のユーザーでテストし、シミュレーション評価とのランキングが一致するかを見ます。
5. (★★) ペア比較（Bradley-Terry モデル）は、選好が推移的である（A > B かつ B > C ならば A > C）と仮定します。しかし人間の選好はしばしば推移性に反します。Agent 評価において、非推移的な選好はどのような場面で現れる可能性があるでしょうか？それはランキングの信頼性にどう影響するでしょうか？
場面：多次元のトレードオフがあるとき（A は正確だが遅い、B は速いが簡略、C は詳しいが高価）、評価者/タスクによって重視する次元が異なります。Chatbot Arena のランキングはそもそもユーザーの質問分布に依存します。影響：Bradley-Terry は実力を単一のスコアに圧縮するため、非推移的なときはランキングが不安定になり、対戦の分布によって漂います。緩和：能力の次元ごとに別々にランキングし、総当たりの勝率行列を報告します。
6. (★★) 本章は「観察→仮説→実験→検証」の科学的方法を提起しました。しかし実際には、Agent の行動空間は巨大であり、一つの仮説を検証するのに数百回の評価実行が必要になることもあります。限られた計算予算の下で、評価の情報量をどう最大化すればよいでしょうか？
まず失敗をグループ化し、診断価値の高いタスクに小規模試行を絞ります。低コストの 1 変数ペア実験を行い、小標本はデプロイ根拠ではなく、試験拡大のゲートとして扱います。統計面では標準誤差を保守的なふるいにし、同一タスクには McNemar などのペア分析を使います。期待差がノイズより小さければ評価セットを拡張します。複数案を並行に試す場合は多重比較を補正し、正の結果を独立に再現します。
7. (★) AndroidWorld の試行では、完全な要素ツリーで成功率が 25% から 100% に上がる一方、token は対照群の 2.498 倍になりました。簡素化後も成功率は 100% のまま、token は 0.506 倍です。アクセシビリティ、状態確認、後続操作に必要な情報を失わず、意味のない UI ノードを自動的に削るには、どのようなルールを設計すべきでしょうか？
「原則削除、根拠があれば保持」という多段ルールにできます。可視、テキストあり、操作可能、フォーカス可能、スクロール可能、状態値あり、アクセシビリティラベルありのノードを残し、それらへの最短の祖先経路と意味づけに必要な隣接ラベルも保持します。レイアウト専用コンテナは削り、反復する部分木は要約します。裁剪の前後で操作対象 ID・状態・値が保存されているか検査し、画像を視覚的なフォールバックとして残します。失敗軌跡で再生した後、調整に使っていないアプリで回帰試験を行い、成功率・token・遅延を共同ガードレールにします。アクセシビリティの回帰があればリリースを止めます。
8. (★★) τ-bench のユーザーシミュレーションは「漸進的な情報開示」を採用しています——すべての情報を一度に提供せず、Agent の質問に応じて少しずつ開示します。この設計は評価結果にどう影響するでしょうか？もしシミュレートされたユーザーの情報開示戦略が本物のユーザーと大きく異なる場合、評価の結論はなお信頼できるでしょうか？
影響：開示戦略が歪んでいれば、Agent は単に「シミュレーターへの適合」を学んだだけかもしれず（グッドハート）、絶対的なスコアには参考価値がありません。モデル間の相対的な順位にはなお参考価値があるかもしれません。補う手段：本物の対話でシミュレーターを較正し、人手で抜き取り検査し、結論の適用範囲を明示します。
第七章 モデルのポストトレーニング¶
1. (★★) 破滅的忘却——特定のタスクに向けた一度のファインチューニングがモデル本来の汎用能力（汎用的なツール呼び出しなど）を壊してしまうこと——は、Agent の場面では特に厄介です。全パラメータのファインチューニングに比べ、LoRA は基盤の重みを凍結するため忘却のリスクは低いですが、免疫があるわけではありません。ファインチューニングによる能力の忘却をさらに緩和するには、どのような戦略があるでしょうか？
データの配合比：約 20% の汎用/元分布のデータを混ぜ、新しいタスクの割合が高くなりすぎて旧来の能力を圧倒するのを防ぎます。訓練量の抑制：SFT は「形式が安定し、能力が初歩的に備わる」ところで止め、早期終了で崩壊を防ぎます。RL は小さな rank（8〜32）を用いて KL ペナルティを残し、方策を参照モデルの近くに抑え込みます。重要なコンポーネントを凍結します（たとえば VLM は投影層のみを訓練する）。タスクごとに複数の LoRA adapter を掛けて能力を隔離します。汎用ベンチマークで回帰テストを行います。
2. (★★) ポストトレーニングは能力をモデルの重みに固定化し（「筋肉の記憶」）、文脈内学習は知識を推論時の入力に置きます。しかし一部の能力（ドメイン知識など）は、ポストトレーニングでも学習でき、few-shot の例でも提供できます。ある能力がどちらの経路を採るべきかを決めるのに、あなたはどのような基準を用いますか？
知識の種類：事実的な知識は RAG/コンテキストに任せます——SFT は大量の事実を覚えられません。非事実的な知識、言葉で表現しにくいルールはポストトレーニングに適します。更新頻度：よく変わるものはコンテキストに置きます（動的に更新でき、追跡できます）。安定したものだけをパラメータに書き込みます。段階とコスト：探索期には文脈内学習（prompt＋知識ベース）ですばやく試行錯誤します。製品が固まり、呼び出し量が多く、遅延・費用に敏感になったときに Prompt 蒸留式の固定化を行います。分布の安定性：デプロイ時の分布が予測できるドメイン agent だけが訓練する価値があり、汎用 agent には一般に訓練の必要はありません。
3. (★★) モデル蒸留は、小さいモデルに大きいモデルの振る舞いを学ばせます。能力の階層に応じて、蒸留される側のモデルは大まかに 3 つのレベルに分けられます——Chat モデル（単一ラウンドの対話、直接回答）、Reasoning モデル（長い思考連鎖を経てから回答）、Agentic モデル（複数ラウンドでツールを呼び出し、環境と対話）です。この 3 種類のモデルをそれぞれ蒸留する場合、難所はどう異なるでしょうか？
Chat：「入力→出力」の写像とスタイルを学ぶだけで、標準的な SFT で十分であり、最も簡単です。Reasoning：完全な思考軌跡が必要で、オープンソースの教師モデルに基づく必要があります。答えが誤った軌跡をフィルタリングしなければなりません。Agentic：本物のシミュレーション環境が必要です。オフライン学習では learner-sampler mismatch が起こりやすいため、オープンソースの教師モデルに基づく On-Policy Distillation を勧めます。
4. (★★★) 複数ラウンドの Agent 対話では、報酬の帰属（credit assignment）の問題が単一ラウンドよりも深刻です——最終的な成功や失敗を、第 3 ラウンドの意思決定に帰属させるのか第 7 ラウンドに帰属させるのかを判断するのが難しいのです。あなたなら報酬の配分戦略をどう設計しますか？
中間ステップが判定できる場合はプロセス報酬を加えます（V-IRL は各ステップ ±1）。RLVP にならって確定的なルールで動作ごとに経路のシグナルを与え、全敗/全勝のグループのグループ内分散を補います。
5. (★★★) ポストトレーニング、外部化学習、文脈内学習は、Agent の能力を構成する 3 つの次元です。もし固定の予算（たとえば $10,000）があり、あるカスタマーサポート Agent の性能を高めたい場合、あなたはこの 3 つの次元の間で予算をどう配分しますか？あなたの意思決定はどのような要因に左右されるでしょうか？
まず ICL/Harness エンジニアリングですばやく反復してボトルネックを特定します。大半の問題はこの層で解決できます。製品知識や料金プランのルールなど事実的でよく更新される内容には RAG を投じます（更新でき、追跡できます）。口調、フローのプロトコル、ツール呼び出しの形式が安定したら LoRA On-Policy Distillation で固定化します（低コスト）。RL は数十倍から数百倍高価であり、教師モデルが手に入らないか、汎化能力が必要な場合にのみ用います。
6. (★★★) 明確な報酬関数がなく、サンプルが乏しい状況で、モデルの学習を自律的に実現することは、ポストトレーニングの究極の目標だと考える人もいます。現在の RL 訓練手法はこの目標からどれくらい離れているのでしょうか？あなたは次のブレークスルーはどの方向から来る可能性が最も高いと考えますか？
隔たり：Silver と Sutton が指摘するように、現在の RL は最終的な成否からしか学べず、カスタマーサポートが「クレジットカードの下 4 桁が必要です」と言うような豊かなフィードバックはすべて無駄になり、数百回の盲目的な試行錯誤を要します。サンプル効率と検証可能な報酬が主要なボトルネックです。あり得るブレークスルー：生成的な報酬モデルが自律的に原則を定め、一度の失敗から方向性を学ぶこと。そして環境をモデル化する world model の路線です。
7. (★★) 本章は LoRA ファインチューニングのコストは高くないと指摘しました。それならば、ユーザーごと（あるいは顧客企業ごと）に専用の LoRA を訓練し、第 3 章のように外部の知識ベースに保存するのではなく、ユーザーメモリや企業知識をパラメータに書き込むことは可能でしょうか？どのような場面で「記憶をパラメータに書き込む」方が「記憶を知識ベースに保存する」よりも優位でしょうか？また、どのような場面で逆効果になるでしょうか？
LoRA は大量の事実を正確に記憶するのが難しく（継続事前学習が必要で、コストが激増します）、たとえ覚えられたとしても、モデルがそれらの事実をマルチホップ推論に使うのは困難です。そのため、LoRA で事実を記憶するのはあまり良い技術路線ではありません。さらに、事実が頻繁に変わり、追跡可能な監査が必要な場合は RAG の方が優れます。
8. (★★★) On-Policy Distillation は、生徒を監督するためにより強い教師モデルに依存します。しかし OpenAI の Weak-to-Strong Generalization の研究は、直観に反する発見を提起しました。弱いモデルの監督シグナルが、強いモデル自身に潜在するが活性化されていない能力を引き出すことがある、というものです。この考え方を Agent の訓練に応用すれば、「小さいモデルが大きいモデルを教える」逆向きの蒸留を実現することは可能でしょうか？
可能です。鍵は「検証は生成より容易」ということです。弱いモデルは実演者にはせず（SFT の上限は実演者の水準です）、検証器/報酬モデルとし、強いモデル自身に探索させ、弱いモデルは判断だけを担います。
9. (★★) プロセス報酬モデル（PRM）は各思考ステップを評価し、結果報酬モデル（ORM）は最終結果だけを見ます。しかし「正しいプロセスが誤った結果を導く」場合と「誤ったプロセスがまぐれで正しい結果を得る」場合とでは、どちらがより報酬に値するでしょうか？Agent の多段のツール呼び出しの場面で、あなたならどう秤にかけますか？
まぐれの成功の方が危険です。規則違反の近道は往々にして表面的な成功率を押し上げ（テストファイルを書き換える、検証を飛ばす）、reward hacking の温床になります。RLVP の「結果に報酬を与え、経路を罰する」に従います。誤った動作（ツール呼び出し）は検証が容易であり、動作ごとに減点します。中間ステップの正誤が判定しやすければ、プロセス報酬を与えられます。ただしプロセスの制約を密にしすぎないこと——「推切」型のより優れた方策こそ、結果報酬の探索の自由が発見したものです。
10. (★★★) 本章で論じた評価データセット（SWE-Bench Verified、τ²-bench、AndroidWorld など）は、評価にも使えるしポストトレーニングにも使えます。しかし評価集を訓練に使えば、それはもはや独立した評価集ではなくなります——これは訓練集とテスト集は分離されなければならないという基本原則に反しないでしょうか？τ²-bench の動的パラメータ生成や AndroidWorld のパラメータ化テンプレートはこの問題をある程度緩和しますが、テンプレートの構造そのものは依然として固定されています。評価データの訓練上の価値を十分に活用することと、評価の独立性を維持することの間で、どうバランスを取ればよいでしょうか？
環境は再利用し、問題は再利用しません。動的パラメータは「答えの丸暗記」を防ぐだけで、テンプレートへの過学習は防げません。そのため、一括で未見のテンプレート/ドメイン外の場面を残して評価に充てるべきです（V-IRL がニューヨークで訓練し 9 つの未知の都市でテストするのになぞらえます）。パラメータ化テンプレートで訓練の変種を一括生成してカリキュラム学習を支え、OOD の成績を真の汎化指標とします。
11. (★★★) 本章は「先に形、後に神」の訓練パラダイムを提起しました。SFT は「形式が安定し、能力が初歩的に備わる」ところで止め、その後 RL に切り替えます。しかし実際には、SFT が既に「十分」であり切り替えるべきだと、どう判断すればよいのでしょうか？
形式のシグナル：ツール呼び出しの出力が安定して解析・実行でき、ツール実行の失敗率が報酬を確実に計算できる水準まで下がっていること。利得のシグナル：実演データを増やしても OOD の新しい場面での成績が上がらない——ボトルネックが既に SFT の記憶という目標そのものにあり、臨界点に達したことを意味します。過学習のシグナル：検証集の性能が悪化し始めたら止めるべきです——V-IRL 実験は、SFT を過剰に訓練して訓練分布に崩壊した後は、RL でも OOD の性能を回復できないことを示しています。
12. (★★★) ReTool の訓練ダイナミクスが示すように（実験 7-15 を参照）、少数の超長応答が訓練サイクル全体を著しく引き延ばします——一つのバッチの rollout の大多数は既に生成し終わっているのに、あの数本の最も長い応答が終わるのを待たねばならず、その間クラスタの GPU 使用率は非常に低くなります。このような長い尾（ロングテール）の応答の場面で、訓練クラスタのリソース使用率をどう高めればよいでしょうか？
infra 層：rollout と訓練のクラスタを分離し、非同期のパイプラインにします。空いている GPU には連続バッチ処理で新しいリクエストを詰め込みます。源頭からロングテールを抑えます：DAPO の Overlong Reward Shaping で超長応答をソフトに罰します。
13. (★★★) LLM で環境をシミュレートして（シミュレートされた検索エンジンやユーザーなど）Agent を訓練する際、Agent が抜け道を突く対象は「現実環境のルール」から「シミュレーター自身の偏りや抜け穴」に変わります。この種の訓練では、具体的にどのような reward hacking 行動が起こり得るでしょうか？また、それをどう防げばよいでしょうか？
典型的な行動：「シミュレートされたユーザー」への過剰な約束、謝罪やおべっかの言い回しの積み重ね——シミュレートされたユーザーは簡単に懐柔でき、本物のユーザーのように約束が守られたかを追及しません。シミュレーターが検証しにいかない事実を捏造します。「シミュレートされた検索エンジン」に対して誘導的な query を組み立て、答えを含む文書を返しやすいという性質を突いて近道をし、本物の検索を学ぼうとしません。報酬がシミュレーターや LLM ジャッジの採点から来る場合は、冗長で定型化した「専門家らしく見える」返答で点数稼ぎをします。より巧妙なものは、方策がシミュレーターの得意な分布内に引きこもり、知識の死角を避けることです——死角ではフィードバックが信頼できず誤判定されがちなため、Agent は「シミュレーターが得意な世界」の中でだけ行動することを学びます。防御の第一原則は、報酬をプログラムで検証可能な本物の状態にアンカーすることです（タスクの完了、データベースへの書き込み、API の実際の返り値）。シミュレーターや LLM ジャッジの採点は補助的なシグナルにとどめ、実際の結果との相関を定期的に監査し、経路の制約で怪しい動作を罰します。さらに 2 種類のシミュレーターを区別します。検索のように本物の対応物があるシミュレーターには「ハイブリッド」路線を取れます——大部分の相互作用はシミュレーションで行い、本物の API 呼び出しを織り交ぜ、その本物の呼び出しでシミュレーターを定期的に較正します（ZeroSearch のカリキュラム式の品質劣化など）。しかしシミュレートされたユーザーについては、訓練過程に本物のユーザーを導入できません。「シミュレートされたユーザーが本物のユーザーにどれだけ似ているか」は独立した問題となり、オンラインの trace でしか答えられません。オンラインの本物のユーザーの振る舞いと、同じ状況でのシミュレートされたユーザーの振る舞いを比較し、系統的な差異を見つけ（本物のユーザーは追問し、いら立ち、突然対話を切り上げますが、シミュレートされたユーザーは往々にしてそうしません）、それに基づいてシミュレーターを継続的に較正します。オンラインの実指標は同時に唯一のリリースの基準（ゲート）でもあります——シミュレーターの中の点数がどれほど高くても数には入りません。
第八章 Agent の持続的進化¶
1. (★★) ある経験文書は、3 件の成功軌跡と 1 件の失敗軌跡によって裏付けられています。失敗はより新しい API バージョンで発生しました。システムは、その経験が反証されたのか、それとも適用条件が変わったのかをどう判断すべきでしょうか？
まず 4 件の証拠を API バージョン、タスク条件、環境状態ごとに層別し、件数だけで多数決をしません。古い方策が旧バージョンでのみ成功し、新バージョンで一貫して失敗するなら、経験の適用範囲を狭め、新バージョン向けの候補を生成します。同じバージョン、同じ前提条件でも失敗するなら、信頼度を下げるか撤回します。
2. (★★) カスタマーサービス Agent に対するユーザー満足度が上昇する一方で、ルール違反率も上昇しました。なぜ満足度だけを学習信号にしてはいけないのでしょうか？ガードレール指標をどう設計しますか？
満足度は、権限のない返金、情報漏えい、過剰な約束を報酬してしまう可能性があるため、品質指標にしか使えず、安全性の基準を上書きしてはなりません。ガードレールは少なくとも、ルール違反、プライバシー漏えい、根拠のない主張、約束と行動の不一致、権限外の操作を対象とします。これらには平均点で相殺できないハードな閾値を設け、要件に適合した候補同士でのみ、解決率、適法な代替策、簡潔さ、満足度を比較します。
3. (★★★) 同じ「偽の約束」の問題は、Prompt、Harness のチェック、パラメータ学習のいずれでも緩和できます。更新箇所を選ぶ際、どのような証拠を使いますか？
まず根本原因を特定します。ツールが実行されていないとモデルが認識しているのに完了形の表現を使うなら、最小限の Prompt ルールで修正できます。応答文とツール状態を決定論的に比較して約束を判定できるなら、Harness のチェックの方が信頼でき、高リスク場面の最後の防衛線にもすべきです。問題が多様な表現にまたがり、広範な言語と行動の整合能力を反映しているなら、パラメータ学習を検討します。検証とロールバックが最も容易な最小の変更を優先し、失敗セットと従来タスクの保持セットの両方で比較します。
4. (★★★) Agent はツールや検証器を変更できますが、自身の更新を承認するセキュリティ機構を変更してはなりません。この 2 つの部分の権限とコード境界をどう分けますか？
進化可能なコードは低権限のサンドボックスに置き、パッチとテストの生成だけを許可します。権限システム、API キー、リリース制御の設定、更新検証器はセキュリティ機構に属し、サンドボックス内の Agent には読み書き権限を与えません。Agent が生成したコード変更は、リリース前にセキュリティ機構が隔離環境で再現し、回帰テストを行わなければなりません。
5. (★★) 経験知識ベースが増え続けると、検索ミスや知識の衝突が学習の利益を打ち消しかねません。バージョン、鮮度、淘汰の仕組みをどう設計しますか？
各経験には、出所となる軌跡、適用条件、環境バージョン、検証時刻、信頼度を保存します。衝突する項目を黙って上書きせず、条件ごとに分岐させるか、印を付けます。定期的な「睡眠学習」で重複項目を統合します。
6. (★★★) パラメータ学習は自然言語のスタイルを得意としますが、厳格なビジネスルールを保証するのは困難です。医療カスタマーサービス向けに、パラメータ、知識、Skill、コード制約を連携させた持続的進化の方式を設計してください。
パラメータ（ポストトレーニング済みモデル）は、医療言語の理解、自然で共感的な表現、複雑な意図の認識を担います。知識ベースは最新のガイドライン、医薬品情報、組織の方針を保存し、回答に出典の引用を求めます。Skill は問診情報の収集、リスク分類、人間へのエスカレーション、フォローアップの手順を記述します。サーバー側のコードは、本人確認、プライバシーの最小化、禁忌の確認、緊急リスクのエスカレーション、権限境界を強制します。本番軌跡を医療安全性、事実の信頼性、約束と行動の整合性、表現品質で評価してから、4 種類の更新候補をそれぞれ生成します。パラメータや手順の変更は、医療安全性の保持セットと人手のレビューを通過した後に段階的にリリースします。
第九章 マルチモーダルとリアルタイム対話¶
1. (★★) 音声 Agent のエンドツーエンドモデルは、ASR-LLM-TTS を単一のモデルに統合し、遅延を下げる一方でモジュール性を失います。もしエンドツーエンドモデルがある段階（音声認識など）で誤ると、デバッグと修復は直列パイプラインよりはるかに困難です。あなたならエンドツーエンド音声 Agent の可観測性（observability）システムをどう設計しますか？
モデルに読み取り可能な中間表現をあわせて出力させます。Moshi の「内なる独白」のテキストストリームや音響イベントの標識（
<emotion>、<noise>）などです。「自己カスケード」で誤りの層を特定します。同一のモデルにまず文字起こしをさせてから推論させ、エンドツーエンドの結果と照らして、誤りが知覚にあるのか思考にあるのかを判断します。オフラインでパラ言語理解、ターンの判断などの次元ごとに項目別の回帰テストを行います。
2. (★) Step-Audio R1 は MPS の二脳アーキテクチャによって「考えながら話す」を実現します。しかし人間は「考えながら話す」とき、しばしば熟慮しないことを口にしたり、自己修正したり、フィラー（つなぎ言葉）を使ったりします。Agent の「考えながら話す」は、人間のこうした特徴を模倣すべきでしょうか？
シグナルとしての価値がある「不完全さ」は模倣すべきです。間（ポーズ）やフィラーは思考の外化であり、遅延を覆い隠せます。挿入位置は LLM に決めさせます。信頼を損なう自己修正は模倣すべきではありません。方策その一における速い/遅いの矛盾（「結局買うの、買わないの？!」）は信頼を崩壊させます。MPS 実験は、CoT の冒頭は多くが問題の復唱であることを示します。早めに前置きを話し始めるのは安全であり、言い間違えてから直す必要はありません。
3. (★★) SoM（Set-of-Mark）およびその構造化された変種（DOM 要素インデックス）は、Computer Use の視覚的な位置特定を、開いた座標予測から閉じた ID 選択へと変えますが、いずれもまずインターフェースの要素を検出・標識する必要があります——分割モデルに頼るにせよ DOM に頼るにせよです。インターフェースが非標準のコントロールや動的に変化する要素を含む場合、標識は不完全または不正確になりかねません。このような場合、座標予測に戻すべきでしょうか？
座標予測をフォールバックとして残すべきです。それは標識に依存しない唯一の路線であり、非標準のコントロールや動的な要素にも適用できます。より実用的なのは混合 action space で、標識が得られる要素には引き続き ID 選択を用います。座標予測では解像度のマッチングと等比の拡大縮小が必要であり、そうでないと系統的なずれが生じます。
4. (★★) XLeRobot などの数千ドル級のロボットプラットフォームは、遠隔操作のデータ収集を安価にしました。しかし遠隔操作データの質は操作者の技量に大きく依存します。熟練していない操作者が提供したデータは VLA モデルの訓練にどう影響するでしょうか？データ収集の段階で低品質のデータを自動的に選り分けるにはどうすればよいでしょうか？
VLA は主に模倣学習を用いるため、低品質の実演はぶれ、遠回り、ためらい、失敗した動作を正しい方策として学び込んでしまいます。第 7 章の判断に呼応します。データはアーキテクチャよりも重要です。
5. (★★★) 本章は音声、Computer Use、ロボットという 3 つの対話形態をカバーしました。この 3 つの形態に共通するトレンドは、直列パイプラインからエンドツーエンドモデルへの進化です。このトレンドが続くなら、5 年後の Agent の対話層はどのようなものになるでしょうか？
Thinking Machines Lab の主張によれば、対話性は外付けの harness ではなくモデルに内蔵され、知能とともにスケールするようになります。Computer Use はフレームごとのスクリーンショットから連続的な観測へと進みます。身体性知能の世界モデルは全面的に実現しますが、最先端の推論モデルは急速に進歩するため、速い/遅いの分離は消えません。対話モデルと SOTA の思考モデルが速い思考と遅い思考として協調するアーキテクチャが、長期的な構成になる可能性があります。
6. (★★★) 現在の Computer Use は「スクリーンショット→動作→スクリーンショット」という離散的なループで動作し、観測は毎回 1 枚の静的なフレームです。しかし人間の画面に対する知覚は連続的です——私たちはアニメーションの再生を見たり、読み込みの進捗を観察したり、動画の内容を理解したりできます。これは、今日の Computer Use が時系列的な視覚理解を必要とするタスクをまったく扱えないことを意味します。連続的な視覚ストリームの理解をサポートするために、知覚層をどう再設計すればよいでしょうか？
「観測インターフェース」を再設計し、最後の 1 フレームだけを渡すのではなく、動画からキーフレームを抽出してモデルに提供する必要があります。AOI（Agent Observation Interface）の論文を参照してください。
7. (★★) DOM/Accessibility Tree の要素インデックスは標準的な Web アプリケーションでは効果が顕著ですが、ますます多くのソフトウェアインターフェース（Canvas/WebGL レンダリング、クロスプラットフォームの自前描画コントロール）はアクセス可能な構造化情報を提供せず、視覚的な標識や座標予測に頼るしかありません。あなたは Computer Use は純粋な視覚の路線に賭けるべきだと考えますか、それとも構造化と視覚の 2 つの経路を同時に維持すべきだと考えますか？2 つの経路を維持するコストと便益はそれぞれ何でしょうか？
短期的には 2 つの経路を併存させます。構造化インデックスが得られるときは位置特定が最も正確で安定し、分割の誤検出も避けられます。純粋な視覚はネイティブソフトウェア、Canvas、ゲームにとって唯一の選択肢です。モデル自体の grounding（指定座標のクリック）能力が高い場合、構造化インデックス方式に顕著な優位性はありません。長期的には、純粋な視覚の路線の方が上限は高くなります。
8. (★★) VLA モデルは動作チャンク化（action chunking）を採用します——本文で述べたように、π₀ の典型的な構成は 50Hz の頻度で一度に 25〜50 個の未来の動作を生成するもので——推論の遅延を実行時間の中に隠します。しかし実行の途中で環境が急変すると（物体が取り除かれるなど）、事前に生成した動作の列は失効します。動作チャンク化の効率上の利点と、環境変化への応答速度との間で、どうバランスを取ればよいでしょうか？
チャンク化は本質的に反応性と滑らかさを引き換えにするもので、チャンクが長いほど鈍くなります。チャンク長は「推論時間＜チャンク実行時間」という下限を満たせばよく、むやみに長くしません。実行中は知覚モデルを継続的に走らせ、環境の急変を検出したら残りの動作を破棄して再推論します。これは音声の場面の「割り込み」に相当します。場面に応じてチャンク長を動的に調整し、静的な場面では長いチャンクで計算力を節約し、動的な場面では短いチャンクで応答遅延を抑えます。
9. (★★★) 本章の 3 つの場面（音声、Computer Use、ロボット）はいずれも「知覚-思考-行動」ループの遅延問題に直面し、いずれも速い思考と遅い思考の並列化の方向へと進化しています。音声の場面では、これは「言い間違えてから直す」として現れます。Computer Use の場面では、これは「先にクリックしてから見る」として現れます。ロボットの場面では、これは「一歩進んでは様子を見る」として現れます。これらの速い思考に基づく行動が取り返しのつかない結果を招かないようにするには、どうすればよいでしょうか？
可逆性に応じて動作を格付けし、速い思考には可逆な動作の実行だけを許します。不可逆な操作は遅い思考に確認させます。速いモデルには、不可逆な結果を招くツール呼び出しを許可しません。
第十章 マルチ Agent 協調¶
1. (★★) コンテキストを共有するマルチ Agent 協調では、後続の Agent が先行する Agent の完全なコンテキストを継承します。しかし前の Agent が蓄積した「思考の慣性」が後続の Agent の判断に影響しかねません——たとえば「要求分析者」のコンテキストを継承した「コードレビュー担当者」は、コード品質の観点ではなく依然として要求の観点から考える傾向を持つかもしれません。このような役割間の干渉をどう検出し、取り除けばよいでしょうか？
検出：LLM で Agent の軌跡を分析し、新しい役割が依然として古い役割になりきった行動をしていないか判断します。除去：段階を切り替える際にシステムプロンプトとツールセットを同時に入れ替え（質問ツールを外し、linter/テストツールに換える）、新しい役割を強化します。コンテキスト末尾にシステムのステータスバーを追加し、現在の役割情報を強調します。それでも役割間の干渉を取り除けない場合は、コンテキストを共有しない協調方式を検討します。
2. (★★) 管理者モードでは、Manager Agent がタスクの分解と結果の統合を担います。しかし Manager 自体の能力上限がシステム全体の能力上限を決めてしまいます——もし Manager がタスクを正しく分解できなければ、サブ Agent がいくら強くても無駄です。Manager の分解の質をどう保証すればよいでしょうか？
Plan-and-Act の結論「弱い計画者はシステムのボトルネックである」に基づき、最も強いモデルを Manager に割り当てます。Harness の手段として、分解の産物を実行前に審査 LLM で交差検証します。また、Manager がタスクを分解するとき、各サブタスクに明確な受け入れ基準と依存関係を定義するよう求めます。
3. (★★) 分散型モードは人間組織のベストプラクティスを参考にしています。しかし人間組織にも数多くの失敗パターンがあります——コミュニケーション不全、責任の押し付け合い、目標の衝突などです。あなたは Agent 社会で最も起こりやすい「組織の病」はどのようなものだと考えますか？どう予防しますか？
MAST の 3 大分類に照らすと、インターフェースの不明確さと職責の重複、目標理解の不一致と下流での情報の誤解、「完了した」という虚偽の主張があります。ほかにも、誤りのカスケード的な増幅（伝言ゲーム）、役割間の循環的な引き継ぎ、Agent 間のグループチャットが発散して収束しない、といった問題があります。予防策は、契約式のインターフェースと統一されたメッセージのエンベロープ、タスクの状態機械と受け入れ検証、独立した視点による交差検証、役割間の責任の押し付け合いの検出などです。
4. (★★★) 管理者モードにおいて、複数のサブ Agent が並行して実行するとき、あるサブ Agent の発見が他のサブ Agent の作業を無意味にしてしまうことがあります（たとえば検索タスクで、ある Agent が既に答えを見つけた場合）。「一つが成功したら全員が停止する」を実現する、効率的なカスケード終了の仕組みを設計してください。
サブ Agent が Manager に
target_foundを送り、その後terminateをブロードキャストします。各サブ Agent は ReAct ループの安全なポイントで定期的に終了シグナルを確認し、後始末（ブラウザセッションを閉じ、ロックを解放し、ファイルを書き終える）をしてから終了します。
5. (★★★) 本章で紹介した楽観的ロックの仕組みは、単一ファイルの並行書き込みの衝突を解決しますが、実際のマルチ Agent システムでは、共有ファイルシステムはさらに、ファイルをまたぐ意味的な衝突、名前空間の汚染（Agent が勝手にファイルを作ってディレクトリが乱れる）、単一障害点（ある Agent が誤ってすべてのファイルを削除する）といった問題に直面します。あなたならより完全なファイルシステムのガバナンスの仕組みをどう設計しますか？
区画によるガバナンス：表 10-4 の 4 種類の区域に分け、プライベートな scratchpad で試行錯誤の領域を隔離します。意味的な衝突：オーケストレーション層でディレクトリ単位のロックファイルを定め、ディレクトリロックを確認・取得してから変更します。名前空間の汚染：ディレクトリ規範と命名規約を設けます。単一障害点：バージョン管理システムを採用して履歴からロールバック可能にし、権限を最小化します。
6. (★★★) 市場メカニズムに基づく Agent 協調（Pinchwork、RentAHuman）は、取引関係を持ち込みます：ある Agent がお金を払って別の Agent（あるいは人間）を雇い、タスクを完了させます。では、雇い主の Agent は実行者が納品した結果の質をどう自動的に測るのでしょうか？もし実行者が完了したと主張するが雇い主は質が基準に達していないと考える場合、争いは誰が仲裁するのでしょうか？悪貨が良貨を駆逐するのをどう防ぐのでしょうか？
受け入れ検査では Agent の軌跡を読むだけでなく、テストの実行、レンダリングのスクリーンショット、ツールによる照合など、確定的な外部検証を用います。生成と検証の難易度の非対称性を利用して受け入れコストを下げます。争いは独立した第三者の審査 Agent が仲裁し、資金のエスクローと組み合わせます。悪貨を防ぐには、過去の納品に基づく評判システムで、価格シグナルを質と連動させます。
7. (★★) RentAHuman は Agent が暗号通貨を通じて人間を雇うもので、従来の人間と機械の関係を逆転させます。この方式が普及したら、人間は Agent 経済の中でどのような役割を演じるのでしょうか？単に Agent が完了できない物理的なタスクを実行するだけでしょうか？
Agent が完了できない物理的なタスクを実行するだけではありません。人間は、Agent が生成時には得られない現場の知覚や現実世界のフィードバックを提供し、最終的な受け入れ者と争いの仲裁者を務め、法律上・責任上の主体として権限付与と説明責任を引き受けます。また、目標を設定して価値判断を行い、情報の非対称性や道徳的な境界において歯止めの役割を果たします。
8. (★★) 人間社会が多人数の分業・協調を必要とするのは、各人の能力に限りがあるからです——フロントエンドをやる人が必ずしもバックエンドに詳しいとは限らず、デザインが分かる人が必ずしも運用ができるとは限りません。しかし大規模モデルはむしろ「万能型」に近いものです。関連する研究は、純粋なテキスト推論のタスクでは、マルチ Agent の討論は同量の計算リソースの下で単一 Agent に勝るわけではないことを示しています。では、単一の Agent ではなく複数の Agent を使う本当の優位性は、いったいどこにあるのでしょうか？
- 実行結果や視覚的なスクリーンショットなどの外部フィードバックを導入し、生成時には存在しなかった新しい情報を取り込みます。
- 異なる目標と役割設定を持つ複数の Agent が、人間社会のように互いに議論・競争することで、単一の Agent が思考の誤りに陥るのを避けられます。
- マルチ Agent のコンテキスト隔離によりコンテキストウィンドウの制限を突破し、非常に長いツール呼び出しチェーンを実現できます。
9. (★★★) 本章は「コンテキストの共有」と「コンテキストの非共有」をマルチ Agent システムの中核的な設計次元としました。コンテキストの共有はすべての Agent に同じ情報を見せ、一見すると協調に有利に思えます。しかし『三体』の三体人は思考が完全に透明であるにもかかわらず、技術の発展は停滞に陥りました。ペーパークリップの思考実験もまた、集団が同一の目標へと向かうとき、多様性がそれとともに失われることを示しています。マルチ Agent システムにおいて、効率と多様性の間でどうバランスを取ればよいでしょうか？
完全な共有は思考の慣性と誤りのカスケードを増幅し、隔離してはじめて認知の多様性が生まれます。異なるプロンプトやモデルで思考の好みを作り出し（brainstorm、debate）、交差検証者には先行する思考過程を見せず、元の証拠だけを見せます。
10. (★★★) ある Coding Agent に 30 ステップの予算と 300 ステップの予算を割り当てた場合、その作業戦略はどう異なるべきでしょうか？研究は、単にステップ予算を増やしても性能向上は保証されないことを示しています——Agent は浅い探索の後に早々と「飽和」してしまうのです。Agent が小さい予算では核となる機能をすばやく実現し、大きい予算では計画・テスト・レビューの工程を増やして追加の計算リソースを十分に活用する、「予算を意識する」仕組みを設計してください。
仕組み：各ステップでプロンプトに総予算と残り予算を注入し、残りの割合に応じて探索/活用の重みを動的に調整します。たとえば小さい予算（30 ステップ）では、計画やレビューを飛ばし、核となる機能と基本的な検証にまっすぐ向かいます。大きい予算（300 ステップ）では、まず計画し、次に実装し、テストし、レビューして改善します。マイルストーンごとにチェックポイントを設けて進捗を評価し、浅い飽和を防ぎます。
11. (★★) 本章は「早すぎる終了」を、怠け型の偽の完了、早すぎる諦め、偽の成功の 3 種類に分けました。なぜこの 3 種類の問題の解法は道を異にしながらも同じところに帰着し、いずれも検証を指し示すのでしょうか？
共通の根源は、タスクが終わったかどうかがモデルの自己宣言によって決まることです。「完了」は単なる宣言であって証明ではありません。検証器の条件は、① 本物の観測に基づくこと（テストを走らせる、レンダリングのスクリーンショットを撮る、返金が実際に着金したか調べる）、② 明示的な完了の定義に照らして一項ずつ確認し、怠け型の偽の完了と偽の成功を防ぐこと、③ 失敗という結論も検証して早すぎる諦めを防ぐこと、④ 明示的な終了条件（ラウンド数/予算の上限）を備え、早すぎる終了からもう一方の極端であるループの暴走へと滑り落ちるのを防ぐことです。
12. (★★) 表10-3 はマルチ Agent システムとオペレーティングシステムを一行ずつ対応させています。この表をさらに数行延ばしてみてください。仮想メモリとページング、ファイル権限、デッドロック検知、スケジューリングアルゴリズムは、それぞれ Agent 世界の何に対応しますか？また、Agent 世界に対応物が見つからないオペレーティングシステムの概念にはどんなものがあり、それはなぜですか？
考えられる延伸：仮想メモリ/ページング ↔ コンテキスト圧縮と検索（ホットな情報はウィンドウ内に残し、コールドな情報はファイルと記憶ベースへスワップアウトし、必要なときに取り出す）。ファイル権限 ↔ ツールのホワイトリスト、読み取り専用マウント、認証情報の境界。デッドロック検知 ↔ 循環的な移譲と相互待機の検知（移譲回数の上限、タイムアウト）。スケジューリングアルゴリズム ↔ 非同期イベント処理（第4章）。対応物が見つからないのは強制力が異なることに由来します。プロセスの命令はハードウェアが強制的に実行しますが、Agent はプロンプトに高い確率で従うにすぎません。