Architect Foundations ドメイン5: コンテキスト管理と信頼性（15%）
この章で学ぶこと: 長いやりとりで大事な事実を失わない方法、エスカレーションとあいまいさの解消、マルチエージェントでのエラーの伝え方、大きなコードベースでのコンテキスト管理、人のレビューと確信度の調整、出典と不確かさの扱い。
本番の60問のうち約9問が出ます。ほかのドメインのシナリオ問題にも、この考え方がよく混ざります。
| タスクステートメント | この章の節 |
|---|---|
| 5.1 長いやりとりで重要な情報を失わない | 第1節 |
| 5.2 エスカレーションとあいまいさの解消 | 第2節 |
| 5.3 マルチエージェントのエラー伝播 | 第3節 |
| 5.4 大きなコードベースの探索でのコンテキスト管理 | 第4節 |
| 5.5 人のレビューと確信度の調整 | 第5節 |
| 5.6 出典を保ち、不確かさを扱う | 第6節 |
Developer Foundations で学んだ基本（ここでは繰り返しません）:
- コンテキストエンジニアリング、肥大化とずれ、ツール出力を削る、圧縮、構造化したメモ → Developer D6 第1節
- コンテキストウィンドウの管理の手法（
/compact、サブエージェント、ツール検索） → Developer D1 第3.4節 - 自信ありげな出力を疑う、ハルシネーション対策 → Developer D6 第3.4節、Developer D4 第4.3節
1. 長いやりとりで重要な情報を失わない（5.1）
1.1 3つのリスク
| リスク | 何が起きるか |
|---|---|
| 段階的な要約で数字が消える | 「注文 #4471 を 12,800円で 3月2日に返品希望、配送料は顧客負担で合意」が「顧客は返品を希望」に縮む |
| lost in the middle | 長い入力の最初と最後はよく読まれるが、中ほどの内容は抜けやすい |
| ツール結果がたまる | 返品に必要なのは5項目なのに、注文検索が40以上の項目を返し、それが毎ターン残る |
会話の一貫性のために、次の API リクエストには会話の履歴を丸ごと渡します（Messages API は状態を持たない）。だからこそ、履歴に何を残すかの設計が大事です。
新しいモデルでの注意（2026年11月時点）: 公式のプロンプトのドキュメントは、Claude 5.1 以降のモデルでは、前のメッセージを編集したり、古いターンをその場で要約し直したりすると、それより後の thinking ブロックが無効になるとしています。履歴は追記だけにして、変更は会話の途中のシステムメッセージやサーバー側のコンテキスト管理で行うよう勧めています。case facts ブロックのような「毎回入れる事実」は、この注意と合わせて設計します。
公式の長い文書のこつ: 長い文書はプロンプトの上に置き、問いと指示は後ろに置く。複数の文書は <document> で囲み、出典などのメタデータを子のタグに入れる。先に関係する部分を引用させてから仕事をさせる。
1.2 対策
| 対策 | やり方 |
|---|---|
| case facts ブロック | 取引の事実（金額、日付、注文番号、ステータス、顧客が言った期待）を、要約される履歴とは別の、変わらない「case facts」ブロックに抜き出し、毎回のプロンプトに入れる |
| 問題ごとの構造化データ | 複数の問題を扱うセッションでは、問題ごとに（注文 ID、金額、ステータス）を別の層に保つ |
| ツール出力を削る | たまる前に、必要な項目だけに削る（例: 注文検索から返品に関係する項目だけ）。PostToolUse フックでもできる（第1章 5.1） |
| 位置の工夫 | 集めた入力の最初に重要な結果の要約を置き、詳細ははっきりした見出しで整理する |
| メタデータを必ず入れる | サブエージェントの構造化出力に、日付、出典の場所、方法論の文脈を入れさせる |
| 上流で構造化する | 下流のコンテキストの予算が少ないなら、上流のエージェントに長い文章や推論の連鎖ではなく、重要な事実・引用・関連度のスコアを返させる |
<case_facts>
customer_id: C-20931（確認済み）
issue_1: 注文 #4471 / 12,800円 / 返品希望 / 配送料は顧客負担で合意 / 3月2日
issue_2: 3月の請求 / 二重請求の疑い / 4,400円 / 調査中
</case_facts>
2. エスカレーションとあいまいさの解消（5.2）
2.1 エスカレーションのきっかけ
| きっかけ | 例 |
|---|---|
| 顧客がはっきり人を求めた | 「人と話したい」「担当者につないで」 |
| ポリシーの例外や抜け | ポリシーは自社サイトの値下げだけを扱い、競合店との価格合わせについては何も書いていない |
| 意味のある進展ができない | 必要な情報が取れない、何度試しても解決しない |
「複雑だから」だけではエスカレーションの理由になりません。複雑でも、能力とポリシーの範囲内なら解決を目指します。
2.2 顧客が人を求めたとき
| 状況 | 正しい対応 |
|---|---|
| はっきり人を求めた | 先に調べようとせず、すぐに応じる |
| 不満を表しているが、人を求めてはいない。問題は単純 | 気持ちを受け止め、解決を申し出る。顧客がもう一度人を希望したら、エスカレーションする |
2.3 当てにならない指標
| 指標 | なぜ当てにならないか |
|---|---|
| 感情（怒っているか） | 感情の強さは、問題の複雑さと関係しない |
| モデルの自己申告の確信度 | 調整されていない。難しいケースほど誤って自信を持つことがある |
エスカレーションの判断がずれているときの最初の一手は、システムプロンプトに明確なエスカレーションの基準と、「エスカレーションする / 自分で解決する」の境目を示す few-shot 例を入れることです（サンプル問題3）。別の分類モデルを作る、感情分析を入れる、は大がかりすぎるか、別の問題を解いています。
2.4 候補が複数あるとき
get_customer で「田中 花子」が3人見つかった。推測でどれかを選ばず、追加の識別情報（メールアドレス、注文番号、電話番号の下4桁など）を尋ねます。誤った顧客の口座を操作するほうが、ずっと高くつきます。
3. マルチエージェントのエラー伝播（5.3）
3.1 構造化されたエラーの文脈
サブエージェントがコーディネーターに返すエラーに入れるもの:
| 項目 | 例 |
|---|---|
| 失敗の種類 | タイムアウト（一時的） |
| 試した問い合わせ | 「2025年 欧州 洋上風力 発電容量」 |
| 部分的な結果 | 取れた3件の資料 |
| 考えられる代案 | 期間を絞って再検索、別の情報源（政府の統計）を使う |
これがあれば、コーディネーターは「問いを変えて再試行」「別の方法」「部分的な結果で進める」を賢く選べます。
3.2 アンチパターン
| アンチパターン | なぜだめか |
|---|---|
| 一般的なステータス（「検索が使えません」） | コーディネーターから大事な文脈を隠す |
| エラーを黙って握りつぶし、空の結果を成功として返す | 回復の機会がなくなり、抜けのある報告になる |
| 1つの失敗でワークフロー全体を止める | 回復できる場面まで止まる |
| サブエージェント内で再試行を尽くしてから、一般的なステータスだけ返す | 再試行は良いが、最後に文脈を捨てている |
3.3 どこで回復するか
- 一時的な失敗は、サブエージェントがその場で回復する（再試行など）
- 解決できないエラーだけを、試したことと部分的な結果と一緒にコーディネーターへ
- アクセスの失敗と、正当な空の結果（該当なし）を区別して伝える（第2章 2.4）
3.4 網羅の注記
統合の結果に、網羅の状況を書きます。
## 網羅の状況
- 十分な裏付け: 発電容量の推移、主要国の政策
- 抜けあり: 洋上風力の保守コスト（業界団体のデータベースがタイムアウトし、取得できなかった）
読み手は、どこまで信じてよいかを判断できます。
4. 大きなコードベースの探索でのコンテキスト管理（5.4）
4.1 コンテキストの劣化のサイン
長いセッションで、回答の一貫性がなくなる。前に見つけた具体的なクラス名（LegacyInvoiceAdapter）ではなく、「よくあるパターンでは〜」のような一般論を語り始める。これは劣化のサインです。
4.2 対策
| 対策 | やり方 |
|---|---|
| スクラッチパッドのファイル | 重要な発見（クラス名、依存関係、決めたこと）をファイルに書かせ、後の質問ではそれを参照させる。コンテキストの境界（圧縮や新しいセッション）をこえて残る |
| サブエージェントに任せる | 具体的な問いごとに生成する（例: 「テストファイルを全部探す」「返金フローの依存関係をたどる」）。大量の出力はサブエージェントの中に残り、メインは全体の調整を続ける |
| フェーズの間で要約する | 次のフェーズのサブエージェントを生成する前に、前のフェーズの重要な発見を要約し、最初のプロンプトに入れる |
/compact |
探索の出力でコンテキストが埋まったら、要約して空きを作る |
Anthropic の記事「Effective context engineering for AI agents」も、長い仕事の手法として、圧縮（compaction）、構造化したメモ（エージェントがコンテキストの外にメモを書く）、サブエージェントの3つを挙げています。
4.3 クラッシュからの回復: マニフェスト
- 各エージェントは、決まった場所に自分の状態を書き出す（例:
state/search-agent.jsonに、終わった問い、取れた結果、残りの仕事） - コーディネーターは、全体の進み具合をマニフェスト（
state/manifest.json）にまとめる - 再開するとき、コーディネーターはマニフェストを読み込み、それぞれのエージェントのプロンプトに状態を入れる
会話の記録に頼らず、構造化された状態から再開できます（第1章 7.2 の「要約で新しく始める」と同じ考え）。
5. 人のレビューと確信度の調整（5.5）
5.1 全体の正確さに隠れる弱点
| 文書の種類 | 件数 | 正確さ |
|---|---|---|
| 請求書 | 9,000 | 99% |
| 領収書 | 800 | 95% |
| 手書きの納品書 | 200 | 71% |
| 全体 | 10,000 | 約97.6% |
全体では97%を超えても、手書きの納品書は71%です。「全体で97%だから人のレビューを減らす」は危険です。
5.2 自動化の前に確かめること
- 文書の種類ごと、項目ごとに正確さを分析し、すべての区分で性能が安定しているか確かめる
- そのうえで、確信度の高い抽出だけを自動化する
5.3 確信度を調整して使う
- モデルに、項目ごとの確信度を出させる
- ラベル付きの検証セット（正解のわかっている文書）で、確信度と実際の正しさを比べる
- レビューのしきい値を決める（例: 確信度 0.9 以上の項目は、検証セットで正答率 99%だった）
自己申告の確信度を、調整せずにそのまま使ってはいけません。
5.4 層別ランダムサンプリング
自動化した「確信度の高い抽出」からも、文書の種類などの層ごとにランダムに少しずつ取り出し、人が確かめます。
- 誤り率を続けて測れる
- 新しい誤りのパターン（新しい様式の請求書など）に早く気づける
5.5 人の時間をどこに使うか
| 人のレビューに回す | 自動で通す |
|---|---|
| 確信度の低い抽出 | 確信度が高く、その区分の正確さが確かめられた抽出（サンプリングで監視） |
元の文書があいまい・矛盾している（conflict_detected が true） |
— |
6. 出典を保ち、不確かさを扱う（5.6）
6.1 要約で出典が消える
要約の段階で、主張と出典の対応を残さずに圧縮すると、どの主張がどこから来たかがわからなくなります。
対策: サブエージェントに、主張と出典の対応表（出典の URL、文書名、該当の抜粋）を構造化して出させ、統合のエージェントはそれを最後まで保ちます（第1章 3.3）。
6.2 食い違う統計
信頼できる2つの情報源で、数字が違う（例: A は「市場の成長率 12%」、B は「8%」）。
| やり方 | 評価 |
|---|---|
| どちらかを勝手に選ぶ | 誤り |
| 平均を取る | 誤り（根拠のない新しい数字を作る） |
| 両方の値を出典付きで書き、食い違いを注記する | 正しい |
- 文書分析のサブエージェントは、食い違う値も含めて注記したまま仕事を終える
- どう折り合いをつけるかは、コーディネーターに決めさせる
- 報告書は、確立した結果と議論のある結果を別の節に分け、元の出典の言い方と方法論の文脈を保つ
6.3 時期のデータ
A は2023年のデータ、B は2025年のデータなら、数字の違いは矛盾ではなく変化かもしれません。サブエージェントの構造化出力に、公開日やデータの収集日を必ず入れさせます。
6.4 内容に合った表現
| 内容 | 表現 |
|---|---|
| 財務データ | 表 |
| ニュース、経緯 | 文章 |
| 技術的な結果 | 構造化したリスト |
すべてを同じ形式にそろえる必要はありません。
7. 試験に向けたまとめ
| 問われ方 | 答えの考え方 |
|---|---|
| 要約で金額や日付が消える | case facts ブロックに抜き出し、毎回入れる |
| 長い入力の中ほどを見落とす | 重要な要約を最初に、詳細は見出しで整理 |
| ツール結果でコンテキストが埋まる | 必要な項目だけに削る |
| 顧客がはっきり人を求めた | すぐにエスカレーション |
| 不満はあるが、問題は単純 | 受け止めて解決を申し出る。再度求めたらエスカレーション |
| ポリシーに書いていない依頼 | エスカレーション |
| エスカレーションの判断がずれる | 明確な基準と few-shot 例。感情や自己申告の確信度ではない |
| 同じ名前の顧客が複数 | 追加の識別情報を尋ねる |
| サブエージェントのタイムアウト | 失敗の種類、問い合わせ、部分結果、代案を含む構造化エラー |
| エラーを空の成功にする / 全体を止める | どちらもアンチパターン |
| 長いセッションで一般論を語り出す | スクラッチパッド、サブエージェント、フェーズ間の要約、/compact |
| クラッシュからの再開 | 各エージェントの状態とマニフェスト |
| 全体97%だからレビューを減らす | 種類・項目ごとに確かめる |
| 確信度で振り分ける | ラベル付きの検証セットで調整してから |
| 自動化した後の監視 | 層別ランダムサンプリング |
| 情報源で数字が違う | 両方を出典付きで。食い違いを注記 |
| 年の違うデータ | 公開日・収集日を必ず入れる |
8. 用語集
| 用語 | 意味 |
|---|---|
| case facts | 会話の要約とは別に保つ、取引の事実のブロック |
| lost in the middle | 長い入力の中ほどが見落とされやすいこと |
| スクラッチパッド | エージェントが発見を書き残す作業用のファイル |
| マニフェスト | 全体の進み具合と各エージェントの状態の一覧 |
| 確信度の調整（calibration） | 確信度の数字が実際の正しさと合うように合わせること |
| 層別ランダムサンプリング | グループごとにランダムに取り出して確かめること |
| 網羅の注記 | どこまで調べられたか、どこに抜けがあるかの説明 |
出典
- Claude Certified Architect – Foundations Exam Guide（PDF、Version 1.0、2026年7月）: 第6章 ドメイン5、第8章の演習、第9章のサンプル問題
- Effective context engineering for AI agents（Anthropic Engineering）: 圧縮、構造化したメモ、サブエージェント
- How we built our multi-agent research system（Anthropic Engineering）: 外部メモリ、エラーからの回復、出典の付け方
- Prompting best practices: Long context prompting（Claude Platform Docs）: 長い文書は上に、文書ごとに
<document>と出典のタグ、先に引用を抜き出す。会話の履歴は追記だけにする（新しいモデルの注意） - Reduce hallucinations（Claude Platform Docs）: 「わからない」と言わせる、引用で裏付ける
- Memory（Claude Code Docs）:
/compactの後に残るもの
注意: 第5.1節の表の数字は説明のための例です。「lost in the middle」は試験ガイドの用語で、公式ドキュメントでは「長い文書は上に、問いは最後に置く」などの形で説明されています。内容は2026年11月時点のもので、上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。