ai-agent-book/book-ja/reference-answers.ja.md

# 演習問題の解答例

本ファイルは全 10 章の演習問題について、参考となる解答の概要をまとめたものです。演習問題の多くは開放的な問題であり、答えは一つではありません。参考解答は AI が生成し、人手で簡単に校閲したもので、読者が照らし合わせて着想を得るためだけのものです。読者の皆さんには、LLM を使い本書の内容と組み合わせて、これらの問題をさらに議論することをおすすめします。

## 第一章 AI Agent 入門

**1. (★★) もし Agent システムに一つだけ能力を追加できるとしたら——より強力なモデル、より豊かなコンテキスト、より多くのツール——あなたはどれを選びますか。どんな条件のもとで、あなたの選択は変わるでしょうか。**

> 「脳/目/手足」の公式に対応させ、まず短所を探します。通常はコンテキストの補強、すなわち観測空間（Observation Space）の補強を優先します。タスクがモデルの推論能力を超えるなら、より強力なモデルに換えます。行動空間が不足しているなら（たとえば社内システムにアクセスできないなど）、ツールを追加します。判断の根拠は失敗軌跡を分析し、ボトルネックが知覚・意思決定・行動のどこにあるかを特定することです。

**2. (★★★) ReAct ループでは、累積キャッシュ読み取り量はラウンド数に対しておおむね二次関数的に増加します。この増加をどう抑えられるでしょうか。**

> 第 i ラウンドで読み取るキャッシュ済みプレフィックスの長さはおおむね i に比例するため、累積読み取り量は 1 + 2 + ... + n = O(n²) です。二次増加するのは累積キャッシュ読み取り料金であり、軌跡の長さや KV Cache の占有量ではありません。後者はいずれもおおむね線形に増加します。token の閾値に達した時点で初期の軌跡をまとめて圧縮し、結論と重要な状態だけを残します。大きな中間結果は外部化して必要時に取得するか、サブ Agent で分離します。毎ラウンド圧縮すると 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 の思考の連鎖の保持メカニズムは、「最後の本物のユーザーメッセージより後」の思考だけを保持します。もし 1 つの ReAct ループが数百ラウンドのツール呼び出しにまたがると、累積した思考の内容が大量のコンテキストを消費する可能性があります。あなたなら、超長いループに対処するためにこのメカニズムをどう修正しますか? DeepSeek（過去の思考をすべて剥ぎ取る）の戦略と対比して、それぞれどんな利点と欠点がありますか?**

> 修正の方向：スライディングウィンドウによる保持——直近の数ラウンドの思考を完全に保持し、ウィンドウの外では（固定ラウンド数ではなく）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. (★★) マルチモーダル情報抽出は、図表をテキストの記述に変換してから検索する。この「翻訳」の過程は視覚情報の中の空間関係を失う可能性がある。純粋なテキストの記述では完全に伝えられない図表の情報の具体例を 1 つ挙げ、その情報を保つ方式を 1 つ設計せよ。**

> 例：システムアーキテクチャ図の論理関係、折れ線グラフにおける 2 本の曲線の交点の位置、あるいは PDF の表におけるセルと見出しの行・列の対応です。方策その一：ネイティブなマルチモーダル処理。方策その二：マルチモーダルな画像分析ツールを提供します。

**4. (★★★) Rich Sutton の「苦い教訓」は、汎用的な方法（探索と学習）が最終的には人手で設計した特徴に勝つと説く。本章で構築した知識システム全体（分割戦略、インデックス構造、検索パイプライン）は、それ自体が一種の「人手による設計」ではないか？ もしモデルの能力が十分に強ければ、これらの設計は単純な「全量入力」に取って代わられるのか？**

> 確かに人手による設計です。一部の工程（チャンク化、融合のパラメータ調整）は長いコンテキストによって弱まる可能性があります。しかし「黒猫白猫」の事例が示すように「全量入力」でも不十分です。注意（アテンション）はソフトな検索であり、文書をまたいだ集計・統計にはやはりインデックス作成時の事前抽出が必要です。知識の期限切れ更新、権限/テナントの分離、監査可能性、コストといったエンジニアリング上の制約はモデルの能力とは無関係です。しかも検索とインデックス作成時の LLM による抽出それ自体が「検索＋学習」の汎用的な手法であり、苦い教訓と対立するものではありません。

**5. (★★★) モデルの能力が向上するにつれて、領域知識ベースは依然として重要だと思うか？ 将来の強力なベースモデルは、領域知識ベースの中のすべての情報を含み、もはや領域知識ベースが不要になる可能性はあるか？**

> なお重要です。訓練データには締め切り日があり、知識ベースはいつでも更新できます。企業内部のプロセスや非公開の判例などは、そもそも公開コーパスには存在しません。マルチユーザーでの共有には権限フィルタリングとテナント分離が必要ですが、パラメータ内の知識は呼び出し者に応じて切り分けられません。外部ストレージは監査でき、バージョン管理でき、失効した内容をオフラインにできますが、パラメータ記憶にはそれができません。パラメータ化の路線（ポストトレーニング / User as Engram）を採ったとしても、「覚えるのは簡単だが、それをマルチホップ推論に使うのは難しい」という難題に直面します。

**6. (★) RAPTOR はボトムアップの階層要約で木構造のインデックスを構築し、GraphRAG はエンティティ関係でグラフ構造のインデックスを構築する。この 2 種類の構造化インデックスは、それぞれどんなタイプのクエリに答えるのが得意か？**

> RAPTOR：マクロな概念から徐々に細部へと掘り下げる「階層をまたぐ往復」型のクエリです。たとえばまず「SIMD 命令セット」の要約に位置づけ、次に SSE の細部へと掘り下げるように、概観と細部の両方の粒度に対応します。GraphRAG：マルチホップの関係推論（「私の主治医が勤める病院の住所」を関係の連鎖に沿って辿る）や、実体の曖昧性解消（2 人の「張医師」は別のノード）といった「A と B にはどんな関係があるか」型のクエリです。コミュニティ要約はさらにトピックのクラスタリングも提供します。

**7. (★★) ファイルシステムのパラダイムは知識をファイルシステムに似た階層構造に組織する。この方式は伝統的なベクトルデータベース RAG と比べて、どんなシーンでより優位か？**

> 純粋なテキストはユーザーが直接読み、編集し、修正でき、Git でバージョン管理とロールバックができます——人間と機械が共同で知識を保守・審査する必要がある場面に適します。Agent は write_file 能力さえあれば自律的に経験を記録でき、記憶の自己進化ループ（外部化学習）を形成します。L0/L1/L2 の漸進的開示により、多くのクエリは L1 まででも意思決定でき、token を節約できます。前提は Wikipedia のように相互リンクとインデックスページを整備することで、そうでないと孤立したファイルが増えるほど検索が難しくなります。

**8. (★★★) 構造化データ（司法判決データベースなど）から「裁判要因」と「要因の重要度階層」を自動的に発見することは、本質的に Agent にデータからルールを帰納させることである。この種のデータ駆動の知識抽出は、人間の専門家が手で書いたルールの品質に達しうるか？**

> 利点：CAIL2018 実験のように、「ボトムアップ」の要因発見は人間の先入観よりもデータに寄り添い、何千何万もの判例に散らばっていて専門家が明示的に書き出しにくい暗黙のトレードオフの経験を捉えられ、しかも定量化できます。限界：LLM の抽出が誤れば知識汚染を引き起こし、データ自体の偏りが継承され、クラスタリングのプロトタイプは相関を反映するだけで因果を説明できません。折衷案：データ駆動のモデリング＋専門家による Schema と結果の審査とし、モデルが問いを立て、統計が説明を裏づけます。

**9. (★★★) Markdown のユーザーメモリについて、増分更新と定期整理の両方の手順を設計せよ。Reviewer と Proposer が同じモデルを使い、Reviewer が Proposer の選んだ対話断片しか見られない場合、どのような誤りがなおマージされうるか？ モデルの独立性、証拠の網羅性、ツール権限の 3 点から改善策を述べよ。**

> 増分更新：記憶ライブラリをコードリポジトリとして扱い、変更ごとに PR を通します。Proposer はまず関連する既存知識を検索し、そのうえでできるだけ小さく完結した diff を提案し、リンク、インデックス、時刻メタデータ、証拠参照も同時に維持します。Reviewer は変更前の知識、diff、生の証拠を用いて独立に監査し、差し戻す際は具体的な証拠と行番号を指す実行可能な指摘を返します。反復には最大回数またはコスト上限を設け、超過したら既定で通すのではなく人間へエスカレーションします。マージ後はまず CI が書式、リンク、メタデータ、権限ラベルを検査し、そのうえでマージ済みバージョンから影響を受けたチャンクとベクトルインデックスを増分再構築します。定期整理：時間または新規項目数で全量スキャンを起動し、重複排除、統合、大きすぎるファイルの分割、入口ページの再構築を行います。肝心なのは元の対話へ段落単位で戻り、古い要約が否定語、時間条件、限定表現を落としていないかを確認することです。矛盾する記述は「最新を残す」で収束させず、それぞれの出典まで遡って成立条件を書き分けます。証拠が足りなければ矛盾と未確認状態をそのまま残します。再編成も同じく PR として提出し、必要ならディレクトリ単位で分割し、すべて通過したらインデックス再構築に加えて典型的な検索ケースを再生し、これまで見つかっていた知識が見えなくなっていないことを確認します。
>
> 同一モデルと切り出し済み断片の組み合わせでは、3 種類の誤りを取りこぼします。**モデルの独立性**：同系統のモデルは訓練上の事前分布と盲点を共有するため、Reviewer は証拠に戻らず Proposer の結論をなぞりがちで、共有された誤読は検出されません——能力が近く別系統のモデルによる相互審査に変えるべきです。**証拠のカバレッジ**：Proposer が選んだ断片だけでは、文脈からの切り取り、落とされた否定語や前提条件、他ファイルとの矛盾がいずれも表に出ません——Reviewer は認可されたテナントやユーザーの範囲内で、完全な知識ベースと生の証拠ストアを自ら検索できなければなりません。**ツール権限**：Proposer が main ブランチへ直接書き込めたり本番インデックスを変更できたりすれば、審査は形だけになります——分業を強制し、Proposer は作業ブランチのみ、Reviewer は証拠の読み取りと判定の提出のみ、main ブランチと本番インデックスの更新はマージ経路だけが行い、検証器とリリースゲート自体は変更可能範囲の外に置きます。

## 第四章 ツール

**1. (★★) MCP 標準はツール定義を Agent フレームワークから解耦しました。しかし標準化はまた、複雑なツールインタラクションのパターン（ストリーミング出力、双方向通信、状態を持つセッションなど）が標準プロトコルの中で表現しにくくなりうることも意味します。あなたは MCP が将来最も拡張を必要とする能力は何だと考えますか。**

> 最も必要な拡張は、セッションをまたぐイベント駆動の能力です。MCP はすでに複数ターンの対話、変更の購読、長時間タスクを支援できますが、その中核はあくまで能力呼び出しの標準化であり、Agent を常時オンラインに保つことではありません。新着メールや外部コールバックで Agent を呼び起こすこと、複数のイベントをキューに入れて再開・再試行することは、なお Agent フレームワークの役割です。このオーケストレーションにより統一された規約があれば、プロトコルの簡潔さを損なわずに MCP の適用範囲を広げられます。

**2. (★★) MCP エコシステムでは、異なる MCP サーバーが機能の高度に重複するツールを提供する可能性があります。Agent が出所は異なるが機能の似た複数のツールに直面したとき、どう選ぶべきでしょうか。もし異なる出所の同名ツールが挙動においてわずかに異なる（例えば一方は要約を返し、もう一方は全文を返す）なら、Agent はこの差異を知覚して利用する能力を持つでしょうか。**

> 選択の根拠：接続前に説明を審査し、バージョンを固定し、最小権限の認証情報を設定し、同名ツールによる遮蔽（tool shadowing）が機微な呼び出しを悪意ある側にルーティングしないよう警戒します。実行時には階層的な分類と動的な発見によって候補を絞ります。モデルが差異を感知できるかどうかは、ツールの説明の質に依存します。

**3. (★★) 本章は「実行―検証―フィードバック」の閉ループ（コードを書いた後に自動的に linter を実行するなど）を提出しました。この「操作後に直ちに自動検証する」パターンは、他のどんなツールのシーンに応用できますか。検証そのもののコストやリスクが操作そのものを上回り、このパターンが実行不可能になるような操作は存在しますか。**

> 応用できる場面：設定を変更した後にサンドボックスで実際に動かして有効性を検証する。文書/プレゼン資料を生成した後にスクリーンショットへレンダリングし、モデルのマルチモーダル能力でレイアウトを確認する。成立しないもの：メール送信、電話発信、対外送金など不可逆で冪等でない操作です——観測しようがないか、それ自体が現実世界のイベントをもう一度引き起こしてしまいます。この場合は事前の手段に切り替えるべきです：提案者-審査者による事前承認です。

**4. (★★) 本章は「ツールの爆発」の問題を提出しました——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 自身が経験を沈殿させる機構は、第 9 章で論じるシステムプロンプトの自動最適化と、どこが同じでどこが異なるでしょうか？**

> GC の考え方：「制約は指導に優先する」——Linter/CI/ツール検証にコード化できるルールはプロンプトから外します。ルールのヒット率を追跡し、LangChain の「失敗軌跡の分析」というデータ駆動の方法を参考にして冗長を識別します。定期的に Agent にコードベースと照らしてルールがなお成立するかを検証させます（時代遅れの文書は無いよりも悪いです）。Markdown＋Git により削除・修正を監査可能かつロールバック可能にします。第 9 章と同じく重みを変えない外部化学習に属します。異なるのは、本章は実行中の増分的な蓄積であり、第 9 章は評価シグナルによって体系的な追加・削除・最適化を駆動する点です。

**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 や可視化コードを生成させ、フロントエンドが直接実行し、LLM が大量のデータを処理するのを迂回します。この「Agent がコードを生成し、システムがコードを実行する」という分業のモードは、従来の「Agent が直接答えを出す」モードに比べて、どんな優劣がありますか？さらに、生成された SQL は破壊的な操作を実行し得て、生成された HTML は脆弱性を含み得ます。システムの安全性をどう担保しますか？**

> 優劣：利点：データがデータベースからフロントエンドへ直接届き、LLM という「仲介者」を迂回します——速く、token を節約でき、大量のデータを書き写す際のハルシネーションによる誤りを避けられ、大量データの提示に適します。コードは監査可能・再利用可能で、パイプラインを組むこともできます（SQL の結果を可視化コードに直接渡す）。欠点：LLM はクエリ結果を見られず、データの内容に基づいてさらなる帰納や意思決定を行えません。モデルがデータを咀嚼してから推論する必要のあるタスクには適しません。
>
> セキュリティ：SQL：クエリは最小権限の読み取り専用アカウントで実行し、CPU、メモリなどのリソース制限を加えて、リソース枯渇を防ぎます。HTML/UI：A2UI のような宣言的プロトコルを優先します。Agent はインターフェース記述の JSON だけを出力し、クライアントは信頼されたコンポーネントカタログでレンダリングし、任意のコードは実行しません。任意の HTML が必要な場合は、インジェクションを防ぐためサンドボックス環境で表示しなければなりません。

**9. (★★) 業務ルールをツール内部のデータベースの真値に基づく検証へとエンコードし、引数の設計でモデルが呼び出す前に政策条件を照合するよう導くことは、本質的にコードの構造で Agent の振る舞いを制約することです。この「コードすなわちルール」のモードは、自然言語のルールに比べてどんな優位性と限界がありますか？**

> 利点：曖昧さがなく、確定的で、複雑な条件の組み合わせを得意とします。ポリシーの事実はデータベースの真値とサーバー側の時計から取り、モデルの自己申告値を採用しないため、ハルシネーションもプロンプトインジェクションも迂回できず、不可逆な操作を防ぐ最後の門番となります。expected_* パラメータは強制的なチェックリストを兼ねて思考を導きます。限界：コードはユーザーにポリシーを説明せず、迂回策も探しません。しかも保守コストがかかります。結論：自然言語のルールを代替するのではなく補完します。
## 交互：観察空間と動作空間の拡張

**1. (★★) 非同期 Agent アーキテクチャでは、イベントキューの優先度戦略は設計時に確定する必要があります。しかしもし優先度の判断そのものが意味的な理解を必要とする（例えばある新しいメッセージが現在のタスクより緊急かどうかを判断する）なら、この判断は誰が下すべきでしょうか——ルールエンジンか、それとも別の LLM 呼び出しか。それぞれにどんな代償がありますか。**

> 階層的に併用します。イベントの種類が明確なものはルールでハードコードし、遅延ゼロで確定性が高いですが、「今すぐ止めて」と「今日の天気はどう」の意味的な違いは理解できません。意味が曖昧なものは軽量な分類 LLM に任せてイベントルーターとします。その代償は数百ミリ秒の遅延、追加費用、誤判の可能性であり、しかも Sidecar のように構造化フィールドのみを読み取ってプロンプトインジェクションを防ぐ必要があります。

**2. (★★) キュー式のイベント処理では、モデルは最後の 1 つのイベントにだけ注目する傾向があり、本章では Agent ステータスバーの標示とまとめによってそれを緩和しました。しかしもしキューに 20 個のイベント（10 個のツール結果 + 5 通のユーザーメッセージ + 5 個のシステムリマインダー）が滞留したら、あなたはこれらのイベントの提示の順序と形式をどう組織し、モデルが重要な情報を漏らさないようにしますか。**

> まずルールと軽量な LLM で分類・重複排除します。緊急のイベント（アラート、ユーザーによる中断）は個別にキャンセル式の処理へ回し、バッチに混ぜません。長すぎる 10 個のツール結果は切り詰めてファイルに永続化し、先頭・末尾とパスだけを残します。コンテキスト末尾のシステムステータスバーに集約リスト（各種イベントの件数＋一つずつ応答するよう要求）を加えます。

**3. (★★★) Agent がユーザーを代表して外部世界とインタラクションするとき、本質的に 1 つのアイデンティティの選択に直面します。独立した仮想アイデンティティ（専用のメールアドレスと電話番号）で第三者のアイデンティティとして行動するのか、それとも直接ユーザー本人のアイデンティティでその個人アカウントを操作するのか。前者はバックグラウンドで自律的に操作できますが、第三者は生身の人間でないアイデンティティを信頼しないかもしれません。後者はより完全なコンテキストと権限を持ちますが、信頼の認可とセキュリティ境界の問題を導入します。あなたはどんなシーンでどちらのモードを選ぶべきだと考えますか。**

> デフォルトは仮想的アイデンティティです。バックグラウンドで自律的に動き、監査でき、誤りが起きたり侵害されたりしてもユーザーのデジタルアイデンティティ全体を露出しません。秘書が自分の業務用メールを使うようなものです。CAPTCHA/IP レピュテーションの問題に対処する必要があります（住宅用プロキシ）。本人のアイデンティティでなければならない場面（アカウントの本人確認、三者通話での確認。たとえば Pine がカスタマーサポートに電話をかける場合）では HITL 認証を用います。VNC/RDP でユーザーが視覚的に自ら直接ログインします。判断基準：相手がアカウント名義人本人を要求するか、操作のリスクと認証情報の範囲です。

**4. (★★) 音声 Agent のエンドツーエンドモデルは ASR-LLM-TTS を単一のモデルに統合し、遅延を下げた一方でモジュール性を失いました。もしエンドツーエンドモデルがある工程（音声認識など）で誤ると、デバッグと修復は直列パイプラインよりはるかに困難です。あなたならエンドツーエンド音声 Agent の可観測性（observability）システムをどう設計しますか?**

> モデルに読み取り可能な中間表現をあわせて出力させます。Moshi の「内なる独白」のテキストストリームや音響イベントの標識（`<emotion>`、`<noise>`）などです。「自己カスケード」で誤りの層を特定します。同一のモデルにまず文字起こしをさせてから推論させ、エンドツーエンドの結果と照らして、誤りが知覚にあるのか思考にあるのかを判断します。オフラインでパラ言語理解、ターンの判断などの次元ごとに項目別の回帰テストを行います。

**5. (★) Step-Audio R1 は MPS デュアルブレイン・アーキテクチャによって「考えながら話す」を実現しました。しかし人間は「考えながら話す」とき、しばしば熟慮を経ていないことを口にしたり、自己訂正したり、フィラーを使ったりします。Agent の「考えながら話す」は、人間のこれらの特徴を模倣すべきでしょうか?**

> シグナルとしての価値がある「不完全さ」は模倣すべきです。間（ポーズ）やフィラーは思考の外化であり、遅延を覆い隠せます。挿入位置は LLM に決めさせます。信頼を損なう自己修正は模倣すべきではありません。方策その一における速い/遅いの矛盾（「結局買うの、買わないの？!」）は信頼を崩壊させます。MPS 実験は、CoT の冒頭は多くが問題の復唱であることを示します。早めに前置きを話し始めるのは安全であり、言い間違えてから直す必要はありません。

**6. (★★) SoM（Set-of-Mark）とその構造化変種（DOM 要素インデックス）は、Computer Use の視覚グラウンディングを開放的な座標予測から閉じた ID 選択へと変えましたが、いずれもまずインターフェースの要素を検出してアノテーションする必要があります――セグメンテーションモデルに頼るにせよ、DOM に頼るにせよ。もしインターフェースが非標準のコントロールや動的に変化する要素を含んでいれば、アノテーションは不完全または不正確になりかねません。この場合、座標予測へフォールバックすべきでしょうか?**

> 座標予測をフォールバックとして残すべきです。それは標識に依存しない唯一の路線であり、非標準のコントロールや動的な要素にも適用できます。より実用的なのは混合 action space で、標識が得られる要素には引き続き ID 選択を用います。座標予測では解像度のマッチングと等比の拡大縮小が必要であり、そうでないと系統的なずれが生じます。

**7. (★★) XLeRobot などの千ドル級のロボットプラットフォームは、テレオペレーションによるデータ収集を安価にしました。しかしテレオペレーションデータの品質は、操作者の技能に大きく依存します。不慣れな操作者が提供したデータは、VLA モデルの訓練にどう影響するでしょうか? データ収集の段階で、いかにして低品質なデータを自動で選り分けますか?**

> VLA は主に模倣学習を用いるため、低品質の実演はぶれ、遠回り、ためらい、失敗した動作を正しい方策として学び込んでしまいます。第 8 章の判断に呼応します。データはアーキテクチャよりも重要です。

**8. (★★★) 本章は音声、Computer Use、ロボットという 3 種類の対話形態をカバーしました。この 3 種類の形態の共通の趨勢は、直列パイプラインからエンドツーエンドモデルへと進化することです。もしこの趨勢が続くなら、5 年後の Agent の対話層はどんな姿になるでしょうか?**

> Thinking Machines Lab の主張によれば、対話性は外付けの harness ではなくモデルに内蔵され、知能とともにスケールするようになります。Computer Use はフレームごとのスクリーンショットから連続的な観測へと進みます。身体性知能の世界モデルは全面的に実現しますが、最先端の推論モデルは急速に進歩するため、速い/遅いの分離は消えません。対話モデルと SOTA の思考モデルが速い思考と遅い思考として協調するアーキテクチャが、長期的な構成になる可能性があります。

**9. (★★) DOM/Accessibility Tree の要素インデックスは標準的な Web アプリでは効果が著しいのですが、ますます多くのソフトウェアインターフェース（Canvas/WebGL レンダリング、プラットフォーム横断の自前描画コントロール）はアクセス可能な構造化情報を提供せず、視覚アノテーションか座標予測に頼るしかありません。あなたは Computer Use が純視覚の路線に賭けるべきだと考えますか、それとも構造化と視覚の 2 つの経路を同時に維持すべきだと考えますか? 2 つの経路を維持するコストと便益は、それぞれ何でしょうか?**

> 短期的には 2 つの経路を併存させます。構造化インデックスが得られるときは位置特定が最も正確で安定し、分割の誤検出も避けられます。純粋な視覚はネイティブソフトウェア、Canvas、ゲームにとって唯一の選択肢です。モデル自体の grounding（指定座標のクリック）能力が高い場合、構造化インデックス方式に顕著な優位性はありません。長期的には、純粋な視覚の路線の方が上限は高くなります。

**10. (★★) VLA モデルは動作分割（action chunking）を採用しています――本文で述べたとおり、π₀ の典型的な構成は 50Hz の周波数での未来の 25〜50 個の動作を一度に生成するもので――推論の遅延を実行時間の中に隠します。しかしもし実行の過程で環境が急変すれば（物体が動かされるなど）、事前に生成した動作の並びは無効になります。動作分割の効率上の優位と、環境変化への応答速度の間で、いかにバランスを取りますか?**

> チャンク化は本質的に反応性と滑らかさを引き換えにするもので、チャンクが長いほど鈍くなります。チャンク長は「推論時間＜チャンク実行時間」という下限を満たせばよく、むやみに長くしません。実行中は知覚モデルを継続的に走らせ、環境の急変を検出したら残りの動作を破棄して再推論します。これは音声の場面の「割り込み」に相当します。場面に応じてチャンク長を動的に調整し、静的な場面では長いチャンクで計算力を節約し、動的な場面では短いチャンクで応答遅延を抑えます。

**11. (★★★) 本章の 3 つの場面（音声、Computer Use、ロボット）はいずれも「知覚-思考-行動」ループの遅延問題に直面し、いずれも速い・遅い思考の並行化の方向へ進化しています。音声の場面では、これは「言い間違えたら訂正する」と表れ、Computer Use の場面では「先にクリックしてから見る」と表れ、ロボットの場面では「一歩進んでは様子を見る」と表れます。これらの速い思考に基づく行動が、取り返しのつかない結果を招かないことを、いかにして保証しますか?**

> 可逆性に応じて動作を格付けし、速い思考には可逆な動作の実行だけを許します。不可逆な操作は遅い思考に確認させます。速いモデルには、不可逆な結果を招くツール呼び出しを許可しません。

**12. (★★★) 本章では同じ原語群（起動、セーフポイント、キャンセル、プリエンプション、速い／遅いの分離）が異なる時間スケールで繰り返し実装されました。そのうち一つを選び、イベント駆動（秒〜日）とロボットの動作チャンク化（ミリ秒）における実装の違いを説明してください。この違いを主に決めるのは何でしょうか——環境変化の速さ、動作の可逆性、それとも観察の取得コストでしょうか。**

> 「キャンセル」を例に取ります。イベント駆動でのキャンセルは、二度のツール呼び出しのあいだのセーフポイントで起きます。Agent は terminate を受け取るとリソースを片づけ、確認を返してから終了します。遅延が秒単位でも許容されるのは、ツール呼び出し一回自体が数秒から数分かかるからです。動作チャンク化でのキャンセルはミリ秒以内に効かねばなりません。制御スレッドが安全イベントや観察の顕著な変化を見つけた瞬間に、現在の動作を止め、残りのチャンクを捨て、観察をやり直す必要があります。一歩遅れれば障害物に衝突しかねません。
>
> 三つの候補要因のうち、**観察の取得コスト**が実は最も本質的ではありません。どちらの側も安価に観察をやり直せるからです。差を本当に決めるのは残る二つの組み合わせです。**環境変化の速さ**がセーフポイントの密度を決め（ツール呼び出しのあいだで足りるか、制御周期ごとに必要か）、**動作の可逆性**がセーフポイントを逃した際の代価を決めます（メールを一通余計に送っても謝罪で埋め合わせられますが、倒した杯は取り消せません）。
>
> ここから一つの設計規則が導けます。セーフポイントの密度は環境変化の速さに合わせるべきであり、セーフポイントの外にどれだけの追加防護（ハードウェア非常停止、独立した安全コントローラ、二重確認）が要るかは、動作がどれだけ不可逆かで決まります。第四章の高リスク操作が事前承認を要し、ロボットがモデルから独立したハードウェア安全層を要するのも同じ理由です。どちらも「セーフポイントだけでは足りない」ところに足された第二の防衛線なのです。

## 第六章 Agent の評価

**1. (★★) LLM-as-a-Judge は言語モデルを使って言語モデルの出力を評価します。この「自己評価」には系統的な盲点が存在するのでしょうか——例えばモデルがある種のスタイルの回答に一貫して高得点をつけ、その好みが人間の評定と一致しない、というような？ こうしたバイアスをどう検出し校正しますか？**

> あります：長さバイアス、回答スタイルのバイアス、同一系統のモデルが抜け穴を突かれること（グッドハートの法則）。検出：100〜200 例の人手によるゴールドスタンダード集を作り、評価と人間との Cohen's kappa を測ります。採点と回答の長さの相関を定期的に監査します。レッドチームが敵対的な事例を構成します。補正：Rubric で冗長さを明示的に罰し、長さを制限します。異なるモデルファミリーによる多源で異種の評価を行います。

**2. (★★★) 評価データセットの「漏洩防止」設計はきわめて重要です。しかしオープンソースのエコシステムでは、benchmark データがいったん公開されると、すぐに訓練データに取り込まれます。この「いたちごっこ」に終局はあるでしょうか？ データ漏洩に根本的に抵抗する評価方法を設計してください。**

> 静的な問題集に終わりはなく、追いかけるしかありません。根本的な打開策は「生成の仕組み」を公開し「具体的なインスタンス」を非公開にすることです。τ²-bench や AndroidWorld のように、パラメータ化されたテンプレートを毎回ランダムにインスタンス化し、固定の解答列ではなく最終的な環境状態に基づいて検証します。

**3. (★★) Scale AI の四準則（専門家の指導に基づく、網羅的なカバー、基準の重要性の重み付け、自己完結した評価）は評価の主観性を排除することを狙いとしています。しかし一部のタスク次元（「回答が役立つか」「語気が適切か」など）は本質的に主観性を持ちます。こうした主観的な次元に信頼できる Rubric をどう設計しますか？**

> 抽象的な基準を検証可能な行動へと翻訳します。各段階に具体例と境界事例を添えます。Rubric は反復の産物です——試用の中で評価者間の意見の相違を集め、徐々に判例集へと進化させます。さらに複数の審査員による重み付け/一貫性チェックを補い、意見の相違した事例は人手による再確認に回し、ゴールドスタンダード集の上で一致率を較正します。

**4. (★★) τ-bench は本物のユーザーの振る舞いをシミュレートして Agent を評価します。しかしシミュレートされたユーザー自体も 1 つの LLM です——それはある種のエッジシナリオ（感情が激しい、表現が不明瞭なユーザーなど）を系統的に過小評価するかもしれません。シミュレートされたユーザー自体の品質をどう検証しますか？**

> τ-bench 初版の教訓：シミュレーターが機械的すぎ、指示が単純すぎました（Agent が答えを当てられてしまう）。検証の手段：シミュレートされた対話を人手で抜き取り検査し、漸進的な開示を守っているか、スクリプト外の情報を捏造していないかを確認します。少数サンプルの本物のユーザーでテストし、シミュレーション評価とのランキングが一致するかを見ます。

**5. (★★) 配対比較（Bradley-Terry モデル）は好みが推移的である（A > B かつ B > C なら A > C）と仮定します。しかし人間の好みはしばしば推移性に反します。Agent 評価において、非推移的な好みはどんなシーンで現れうるでしょうか？ これはランキングの信頼性にどう影響しますか？**

> 場面：多次元のトレードオフがあるとき（A は正確だが遅い、B は速いが簡略、C は詳しいが高価）、評価者/タスクによって重視する次元が異なります。Chatbot Arena のランキングはそもそもユーザーの質問分布に依存します。影響：Bradley-Terry は実力を単一のスコアに圧縮するため、非推移的なときはランキングが不安定になり、対戦の分布によって漂います。緩和：能力の次元ごとに別々にランキングし、総当たりの勝率行列を報告します。

**6. (★★) 本章は能力の上限を表す Pass@k と、業務上の信頼性を表す Pass consecutive@k を区別しました。単発の成功率が 60% しかない Agent について、タスクの失敗コスト、リトライコスト、副作用をどう組み合わせて、どちらの指標を報告するか、$k$ をどれだけ大きく取るかを決めますか？**

> まず失敗がロールバックできるかを見ます。自動でリトライでき、外部への副作用も残さない場合（検索、下書き生成、コード補完）、問うているのは「十分な機会を与えれば成功するか」なので、k を実際に許されるリトライ予算として Pass@k を報告します。失敗が不可逆な結果を残す場合（支払い、返金、対外メール送信、本番デプロイ）は、一度の誤りがそのまま実損なので Pass^k を報告します。単発成功率 0.6 のとき Pass@5 ≈ 99.0%、Pass^5 ≈ 7.8%——同じ Agent の 2 つの数字が一桁違うため、前者だけを報告すると信頼性を大きく過大評価します。
>
> k は見栄えのよい数字ではなく、デプロイの現実から取ります。Pass@k の k はリトライ予算、Pass^k の k は 1 回の当番や 1 バッチで連続実行されるタスク数です。リトライが高くつくなら受け入れを 2 段階に——まず Pass@1 で候補を絞り、残った少数にだけ Pass^k を回します。どちらの指標を報告するにせよ、k とサンプリングの取り方を明記してください。副作用のある操作では、サンドボックスかロールバック可能な環境でサンプリングし、「成功するまでリトライ」ではなく失敗の一つひとつを信頼性の統計に数え入れます。

**7. (★★) 本章は「観察→仮説→実験→検証」の科学的方法を提起しました。しかし実践では、Agent の行動空間は巨大で、1 つの仮説の検証に数百回の評価実行が必要かもしれません。限られた計算予算の下で、いかに評価の情報量を最大化しますか？**

> まず失敗をグループ化し、診断価値の高いタスクに小規模試行を絞ります。低コストの 1 変数ペア実験を行い、小標本はデプロイ根拠ではなく、試験拡大のゲートとして扱います。統計面では標準誤差を保守的なふるいにし、同一タスクには McNemar などのペア分析を使います。期待差がノイズより小さければ評価セットを拡張します。複数案を並行に試す場合は多重比較を補正し、正の結果を独立に再現します。

**8. (★) AndroidWorld の試行では、完全な要素ツリーで成功率が 25% から 100% に上がる一方、token は対照群の 2.498 倍になりました。簡素化後も成功率は 100% のまま、token は 0.506 倍です。アクセシビリティ、状態確認、後続操作に必要な情報を失わず、意味のない UI ノードを自動的に削るには、どのようなルールを設計すべきでしょうか？**

> 「原則削除、根拠があれば保持」という多段ルールにできます。可視、テキストあり、操作可能、フォーカス可能、スクロール可能、状態値あり、アクセシビリティラベルありのノードを残し、それらへの最短の祖先経路と意味づけに必要な隣接ラベルも保持します。レイアウト専用コンテナは削り、反復する部分木は要約します。裁剪の前後で操作対象 ID・状態・値が保存されているか検査し、画像を視覚的なフォールバックとして残します。失敗軌跡で再生した後、調整に使っていないアプリで回帰試験を行い、成功率・token・遅延を共同ガードレールにします。アクセシビリティの回帰があればリリースを止めます。

**9. (★★) τ-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 種類のモデルをそれぞれ蒸留するとき、難点はどう異なるでしょうか。（ヒント：「蒸留すべきはいったい何か」から入ってください――出力のスタイルか、完全な思考軌跡か、それとも環境と相互作用する意思決定の方策か。軌跡の中のどの token を学ぶべきで、どれが環境の返した学ぶべきでないものか。そして成否信号がどれだけ遅く、どれだけ疎に現れるか。）**

> 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 種類の更新候補をそれぞれ生成します。パラメータや手順の変更は、医療安全性の保持セットと人手のレビューを通過した後に段階的にリリースします。

## 第十章 マルチ 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 を使う本当の優位はいったいどこにあるのでしょうか？**

> 1. 実行結果や視覚的なスクリーンショットなどの外部フィードバックを導入し、生成時には存在しなかった新しい情報を取り込みます。
> 2. 異なる目標と役割設定を持つ複数の Agent が、人間社会のように互いに議論・競争することで、単一の Agent が思考の誤りに陥るのを避けられます。
> 3. マルチ Agent のコンテキスト隔離によりコンテキストウィンドウの制限を突破し、非常に長いツール呼び出しチェーンを実現できます。

**9. (★★★) 本章は「コンテキスト共有」と「コンテキスト非共有」をマルチ Agent システムの中核的な設計次元としました。コンテキスト共有はすべての Agent に同じ情報を見せ、一見協調に有利です。しかし『三体』の三体人は思考が完全に透明でありながら、技術の発展は停滞に陥りました。ペーパークリップの思考実験もまた、群体が同一の目標に向かうとき、多様性がそれとともに失われることを示しています。マルチ Agent システムで、効率と多様性の間のバランスをどう見つけますか？**

> 完全な共有は思考の慣性と誤りのカスケードを増幅し、隔離してはじめて認知の多様性が生まれます。異なるプロンプトやモデルで思考の好みを作り出し（brainstorm、debate）、交差検証者には先行する思考過程を見せず、元の証拠だけを見せます。

**10. (★★★) ある Coding Agent に 30 ステップの予算と 300 ステップの予算を割り当てるとき、その作業戦略はどう異なるべきでしょうか？ 研究は、単にステップ予算を増やしても性能向上は保証されないことを示しています——Agent は浅い探索のあと早々に「飽和」してしまいます。「予算感知」メカニズムを設計し、Agent が小さな予算では中核機能を素早く実装し、大きな予算では計画・テスト・審査の段階を増やして、追加の計算資源を十分に活用できるようにしてください。**

> 仕組み：各ステップでプロンプトに総予算と残り予算を注入し、残りの割合に応じて探索/活用の重みを動的に調整します。たとえば小さい予算（30 ステップ）では、計画やレビューを飛ばし、核となる機能と基本的な検証にまっすぐ向かいます。大きい予算（300 ステップ）では、まず計画し、次に実装し、テストし、レビューして改善します。マイルストーンごとにチェックポイントを設けて進捗を評価し、浅い飽和を防ぎます。

**11. (★★) 表10-3 はマルチ Agent システムとオペレーティングシステムを一行ずつ対応させています。この表をさらに数行延ばしてみてください。仮想メモリとページング、ファイル権限、デッドロック検知、スケジューリングアルゴリズムは、それぞれ Agent 世界の何に対応しますか？ また、Agent 世界に対応物が見つからないオペレーティングシステムの概念にはどんなものがあり、それはなぜですか？**

> 考えられる延伸：仮想メモリ/ページング ↔ コンテキスト圧縮と検索（ホットな情報はウィンドウ内に残し、コールドな情報はファイルと記憶ベースへスワップアウトし、必要なときに取り出す）。ファイル権限 ↔ ツールのホワイトリスト、読み取り専用マウント、認証情報の境界。デッドロック検知 ↔ 循環的な移譲と相互待機の検知（移譲回数の上限、タイムアウト）。スケジューリングアルゴリズム ↔ 非同期イベント処理（第4章）。対応物が見つからないのは強制力が異なることに由来します。プロセスの命令はハードウェアが強制的に実行しますが、Agent はプロンプトに高い確率で従うにすぎません。