付録B セルフチェックの解答と解説

第1章

1-1. 次の行動をコードで事前に決めた経路に沿って決めるならワークフロー、実行中にモデル自身が決めるならエージェントです。例えば、問い合わせの分類と権限検査はコードが行い、原因調査が必要な問い合わせだけ、モデルがツールを選びながら処理する相談システムは、両者の混合です。設計書には、段階ごとに「誰が次の行動を決めるか」を書きます。

1-2. セクショニングは、独立したサブタスクを同時実行して速度と呼び出しごとの集中度を得ます。投票は同じタスクを複数回実行し、多様な観点と試行で信頼性の高い結果を得ます。投票は呼び出し数に応じてコストが増え、同じ根拠を使うと誤りが相関して期待ほど精度が上がらない場合があります。判断があいまいで、一度の誤りのコストが高い段階だけに使います。

1-3. 目標、出力形式、使うツールと出典の指示、明確なタスク境界です。目標がなければ違う範囲を調査し、境界がなければ複数ワーカーが重複調査し、出力形式がなければ統合が難しくなり、出典の指示がなければ低品質の出典を使います。いずれか一つの症状を説明できれば正解です。

1-4. 最大反復回数と、スコアが上がらない、または改善幅が下限未満なら停止する条件です。二条件はモデルではなくループを動かすコードに置きます。収束せず終了したときに、最後の結果と評価記録を人に渡す手順も設けるとよいでしょう。

1-5. handoffは選択された専門エージェントへ制御権を渡し、そのエージェントがターンの残りを実行して最終回答を出します。agent-as-toolはマネージャーが制御権を保持し、専門エージェントをツールとして呼んで結果だけを受け取り、マネージャーが最終回答を出します。結果を受け取って続けて使うならagent-as-tool、専門家がユーザーへ直接応対するならhandoffです。

1-6. マルチエージェントの利点の多くが追加のトークン利用によるものなら、総コストの増加に見合って成功も増えたか確認すべきです。そのため指標は成功したタスクあたりのコストです。コストが2倍でも成功率が大幅に上がれば正当化でき、同額でも成功率が変わらなければ損になります。

1-7. 解答例です。最も単純なのは、通知ごとに単一のLLM呼び出しで要約し、コードが部署タグでまとめて送る固定ワークフローです。不十分になった兆候は、部署の分類誤り率が所定の基準（例：5%）を超えること、複数の通知を関連付けて読む必要のある要約依頼が無視できないほど増えることです。その場合は部署分類を別のルーティング段階に分け、関連付けが必要な依頼だけをツール使用エージェントに送ります。兆候を数値で書けたかが要点です。

第2章

2-1. 人間の開発者は文書を一度読んで記憶しますが、エージェントは（ツール検索などの遅延ロードを使わない限り）毎回定義と結果をコンテキストとして読むため、ツール数や結果が大きいほどコストが増えます。また、エンドポイントをそのまま包むと似たツールが増えて選択ミスが生じ、複数の呼び出しを組み合わせる負担もモデルに移ります。したがって業務フロー単位の少数のツールが適切です。

2-2. 常に詳細を返すとトークンを浪費し、常に簡潔だと次の呼び出しに必要な識別子が欠ける場合があります。詳しさを選ぶパラメーターで状況に応じて選べば、両方を減らせます。次の呼び出しにIDや詳細フィールドが必要な場合だけ、詳細応答を選ばせます。

2-3. 切り詰めた事実と全体規模（例：1,240件中20件）、そして範囲を絞る方法（フィルター、次ページのカーソル）です。なければ、エージェントは受け取った一部を全部と信じて結論を出したり、必要な項目が存在しないと誤認したりします。

2-4. プロトコルのバージョン、クライアント能力、クライアントの身元です。毎リクエストの_metaに載せます。バージョン（io.modelcontextprotocol/protocolVersion）と能力（io.modelcontextprotocol/clientCapabilities）は必須です。クライアント情報は推奨ですが、自己申告なのでセキュリティ判断には使いません。

2-5. 仕様のデフォルト値に従い、読み取り専用ではなく（readOnlyHintはfalse）、破壊的であり得て（destructiveHintはtrue）、冪等ではなく（idempotentHintはfalse）、外部世界とやり取りできる（openWorldHintはtrue）ものとして扱います。保守的な値なので、アノテーションのないツールは最も注意が必要な側に分類されます。付いていても、信頼できないサーバーのものは信用しません。

2-6. 監査追跡：下位システムのログにはMCPサーバーではなく元のトークン所有者が呼んだように残り、サーバー側でもクライアントを区別できず、事故調査が難しくなります。レート制限：サーバーや下位APIがトークンの対象と制約に基づいて行う制御を、トークンを直接使う呼び出しが迂回する可能性があります。

2-7. 解答例です。名前はloan_extendのようにサービス接頭辞と動作を含めます。パラメーターはloan_number（例：LN-2026-00123形式の文字列）と新返却日new_due_date（ISO日付、現在の返却日から14日以内）とし、同じ依頼が2回来ても結果を同じにします。業務エラーは「予約待ちの人がいる本は延長できません。返却予定日は2026-10-27です」のように理由と事実を返します。延長回数の上限を超えようとする場合や延滞料が発生する場合に、人の確認を設けます。各項目が誤用をどう減らすか説明できれば正解です。

第3章

3-1. モデルはコンテキスト内の全トークン間の関係に注意を分配するため、増えるほど各情報への注意が薄くなります。これが注意予算で、その結果、情報を正確に想起する力が下がる現象がコンテキスト劣化です。ウィンドウが大きければ多く入れられるだけで、同じようにうまく使えるわけではないため、管理が必要です。

3-2. 会話の奥に残る原文のツール結果はすでに使われ、再読が少ないため、消しても流れや決定が残るからです。ただし削除位置以降のプロンプトキャッシュが無効になり得るため、少量ずつ頻繁に消さず、一度に十分な量を消して代償に見合うようにします。繰り返し参照する結果は削除対象から除外します。

3-3. タスク状態（進捗ファイル、チェックポイント）が根拠です。会話履歴は要約・切り詰めで不正確になり、長期記憶は参考資料にすぎません。タスク状態と業務上の正本が食い違えば、事実の基準である正本に合わせて状態を直し、次の作業を決めます。

3-4. 後続セッションが進捗を見て早々に完了を宣言する、機能一覧を勝手に変えたり試験を消したりして合格に見せる、といった失敗です。JSONはMarkdownより不適切な変更・上書きが起きにくく、変更可能なフィールドを合否一つに制限すれば、範囲の縮小や基準の引き下げができません。

3-5. 結果記録の直前に停止すると、記録だけでは実行済みかわかりません。先に意図を残すと、再開コードは「意図はあるが結果がない」項目を見つけ、再実行前に冪等キーで外部システムへ処理済みか照会できます。済んでいれば結果だけを記録し、未処理なら同じキーで実行して重複を防ぎます。

3-6. 第一に、古い情報かを判断し、期限切れの処理や再確認ができます。第二に、新情報と競合したとき、出典の権威と鮮度で信頼性を比較できます。出典があれば、誤って保存した記憶を追跡し、訂正や削除もしやすくなります。

3-7. 解答例です。①目標と完了基準：何を、いつまでに、どの形式で提出するか。②完了項目と検証結果：何が終わり、どう確認したか。③残作業と優先順位：次に行う仕事の順序。④事実と仮定：出典・確認時刻のある事実と未確認の仮定を区別する。⑤次の行動の前提：再開前に確認する外部変更、必要な承認、成果物と外部操作の識別子の場所。「ほぼ完了」などの自己評価ではなく、検証済み成果物を記すことが要点です。

第4章

4-1. トランスクリプトは試行中の発言、ツール呼び出し、中間結果の記録です。結果は終了後の環境状態、つまり予約システムに該当日の予約が実際に一つあるかです。記録は試みたことを示しますが、環境に残ったことまでは証明しません。「予約しました」とあっても予約がなければ失敗なので、状態を変えるエージェントは結果で採点します。

4-2. 設ける場合は「決済前に必ずユーザー確認」など、結果だけでは遵守がわからない必須・禁止ルールのある課題です。設けない場合は、同じ答えへの正しい照会順序が複数ある課題です。完全な経路一致を求めると、より効率的な正解まで失敗にします。

4-3. pass@3 = 1 − (1 − 0.9)³ = 1 − 0.001 = 0.999、約99.9%です。pass^3 = 0.9³ = 0.729、約72.9%です。3回中一度はほぼ確実に成功しても、3回とも成功する確率は約73%という意味です。再試行や候補選択が可能なら前者、毎回一度で正解すべきなら後者が運用体験に近くなります。実際は同課題の試行間で失敗が相関する場合が多く、独立仮定の値とは異なる可能性があります。

4-4. ①評価次元を分け、各次元に観察可能な基準と減点例を記し、根拠がなければ判断不能を選べるようにします。②専門家の採点サンプルを作り、採点器との一致度を測ります。③ずれた事例を読んで基準表を直し、再測定します。その後も定期的にサンプルを抽出し、一致度の維持を確認します。

4-5. トレースは一つのワークフローの開始から終了までで、スパンは開始と終了のある構成作業単位であり、親子関係を作ります。一実行には、エージェント実行、LLM生成、関数ツール呼び出し、ガードレール、handoffなどのスパンが生じます（OpenAI Agents SDKのデフォルトスパンに基づく）。

4-6. 失敗は通常、前段階の誤判断から始まり、後段階で表面化します。症状だけを直すと原因が残って別の形で再発し、誤った要素を変えて効果を見誤る場合もあります。最初の誤判断の段階を知ってこそ、ツール定義、プロンプト、環境の何を変えるか決められます。

4-7. 解答例です。必須合格：禁止行動0件、回帰セット合格率が所定基準以上。比較指標：結果基準の成功率とpass^3が既存版以上で、業務種別に退行がないこと。運用制約：成功した課題あたりのコストが既存の1.2倍以下、初回応答レイテンシが契約内。判断保留：版間の差が反復実行の変動幅より小さい、またはサンプルが基準未満なら、試行を増やして再測定します。必須合格を平均と分けたかが要点です。

第5章

5-1. 第一に、一ターンで高価なツールを何度も呼んだり大きな結果を読んだりする場合で、実行ごとのトークン・コスト上限で防ぎます。第二に、同じ検索や照会を反復する停滞で、同一引数の反復検出と進展なしの検出で防ぎます。サブエージェントの増殖を挙げ、サブタスク数・再委任の深さの上限と答えても正解です。

5-2. 各階層が独立して再試行すると回数が乗算で増え、一失敗が数十回の呼び出しとなって過負荷を強めます。再試行は一階層だけで、一時的エラーに限定し、指数バックオフとジッターで間隔を空け、回数上限を設け、サーバーのretry-afterに従います。他の階層は再試行の代わりに回復指示を伝えます。

5-3. 決済、予約、送信など副作用のある呼び出しでは、処理後に応答だけが失われた可能性があります。失敗と見なして再送すると、効果が二度生じます。まず冪等キーやリクエスト識別子で処理済みか照会し、未処理の場合だけ同じキーで再送します。

5-4. 承認依頼が多すぎると、読まずに押す承認疲れが生じ、危険な依頼も形式的に通ります。取り消し可能性（取り消しにくいか）と影響範囲（顧客・外部・金銭に及ぶか）の二軸で選び、取り消せて影響の小さい行動は上限内で自動化します。

5-5. 終了コード2で遮断するPreToolUseフックは、権限ルールの評価前に止めるため、allowがあっても遮断され、標準エラー出力が理由として伝わります。反対にフックが許可してもdenyやaskは迂回できません。権限ルール自体はdeny → ask → allowの順で評価され、最初の一致が決めます。ただし、導入済み拡張機能（mod）のtool.checkは、管理設定やTeam・Enterpriseログインのない環境で、この決定を覆せます。

5-6. サンドボックスはシェルコマンドと子プロセスを包みます。包まないのはRead・Edit・WebFetchなど組み込みのファイル・Webツールと、フックやローカルMCPサーバーなどClaude Codeが起動する他のプロセスです。組み込みツールは権限ルールで制御し、ユーザーの全権限で動くフックとローカルMCPサーバーは、信頼できるものだけを使い、必要なら別に隔離します。大半のセッションで!により直接入力したシェルコマンド、除外コマンド、サンドボックス外の再試行を挙げても正解です。

5-7. 解答例です。ユーザー別の日次コスト（例：3,000ウォン相当のトークン）を上限とし、進行中の実行の予想コストは開始前に予約します。80%では残量を通知し、高価な機能（長い調査、マルチエージェント）を小さなモデルや範囲を絞った経路に変えます。100%では新規実行を始めず、進行中の実行は部分結果を保存して止め、翌日のリセット時刻と上限引き上げの申請方法を案内します。二時点での動作をコードが強制するかが要点です。