Architect Professional ドメイン3: 統合（19%）
この章で学ぶこと: ツールやエージェントの機能過多（capability bloat）の見つけ方、認証・認可の穴の見つけ方、精度と遅延のトレードオフ、大規模なオブザーバビリティ、RAG の設計（チャンク分割・インデックス・検索・リランク）、MCP・API/CLI・エージェント間の選び方、段階的な発見と一括のコンテキストの比較。
| タスク（試験ガイド） | この章の節 |
|---|---|
| ツール/エージェントの構成が機能過多になっていないか評価する | 第1節 |
| 認証・認可の要件を分析し、セキュリティの穴を見つける | 第2節 |
| 精度とレイテンシのトレードオフを評価し、構成の判断を正当化する | 第3節 |
| 大規模でのオブザーバビリティの課題を分析し、監視戦略を選ぶ | 第4節 |
| 適切なチャンク分割とインデックス戦略で RAG パイプラインを設計する | 第5節 |
| データの形とクエリのパターンに合った検索戦略を使う | 第6節 |
| 接続プロトコルを評価し、適切な統合の仕組みを選ぶ（MCP、API/CLI、エージェント間） | 第7節 |
| 段階的な発見（progressive discovery）と一括のコンテキスト（monolithic context）を比較する | 第8節 |
本番の63問のうち約12問で、いちばん大きいドメインです。RAG はこれまでの3つの試験では扱っていない新しい範囲なので、第5節と第6節を厚くしています。
基礎はここで復習してください:
- ツールの定義、
tool_choice、MCP のしくみ、通信方式 → Developer F ドメイン8 - ツールの説明、構造化エラー、
.mcp.json、ツールの数 → Architect F ドメイン2 - 最小権限、秘密情報、API キーの管理 → Developer F ドメイン7
- トレースと OpenTelemetry の基本 → Developer F ドメイン4 第3節
1. 機能過多（capability bloat）を見つける
機能過多とは、エージェントが仕事に必要な以上のツール・権限・接続先を持っている状態です（この教材の定義）。
1.1 なぜ問題か
| 問題 | 内容 |
|---|---|
| セキュリティ | 使わないツールも攻撃面になる。プロンプトインジェクションで悪用されうる |
| 精度 | 公式のツール検索のドキュメントによると、使えるツールが30〜50を超えると、正しいツールを選ぶ力が落ちる |
| コスト | ツール定義はトークンを使う。GitHub・Slack・Sentry・Grafana・Splunk のような複数サーバーの構成で、定義だけで約55kトークン |
1.2 試験のサンプル問題1と同じ論点
サポート担当はチケットを読む・返信を下書きするだけなのに、エージェントに返金とアカウント削除のツールもある → 返金と削除のツールを構成から外すのが最も効きます。ログ（あとで見つける統制）や確認画面（補う統制）は、不要な権限そのものを消すわけではありません。大きいモデルにしても、権限の範囲は変わりません。
1.3 点検のしかた
| 点検 | 質問 |
|---|---|
| 役割と照らす | この役割の人は、このツールを使うか |
| 読み取りと書き込みを分ける | 読むだけでよいのに、書き込みのツールや資格情報がないか |
| 範囲を絞る | 「どの表でも SQL を実行」ではなく「注文を ID で検索」 |
| 重複 | 似たツールが複数あり、選び間違いを起こしていないか |
| サブエージェント | 各サブエージェントに、その仕事のツールだけを渡しているか |
| 使用状況 | ログで一度も使われていないツールはないか |
2. 認証・認可の穴を見つける
2.1 2つを分けて考える
| 認証（authentication） | 認可（authorization） | |
|---|---|---|
| 問い | あなたは誰か | あなたは何をしてよいか |
| 例 | API キー、OAuth のトークン、SSO | 役割ごとのツール、行レベルのアクセス権 |
2.2 よくある穴
| 穴 | 何が起きるか | 直し方 |
|---|---|---|
| エージェントが強いサービスアカウントで全データにアクセス | 利用者が本来見られないデータを、エージェント経由で見られる（confused deputy、混乱した代理人） | 利用者本人の権限でデータにアクセスする（委任されたトークン）。または行レベルの絞り込み |
| RAG の索引に全社の文書を入れ、権限を見ずに検索 | 人事や役員の文書が、誰の質問にも出る | 文書に権限のメタデータを付け、検索時に利用者の権限で絞る |
| 受け取ったトークンを、そのまま下流の API に渡す（token passthrough） | トークンの宛先の確認が飛ばされ、権限が広がる | MCP の公式のセキュリティのベストプラクティスは token passthrough を禁止。サーバーは自分宛てに発行されたトークンだけを受け付ける |
| API キーをクライアント（ブラウザ・アプリ）に埋め込む | キーが盗まれる | 自分のバックエンドから呼ぶ。ZDR の組織はブラウザからの直接の呼び出しが拒否される |
| 長く使える1本のキーを全員で共有 | 誰が何をしたか追えない。漏れたときの影響が大きい | ワークスペースや用途ごとにキーを分ける、ローテーション、監査ログ |
| プロンプトで「管理者にだけ答える」と書く | プロンプトは認可ではない。だまされうる | 認可はプログラムで（ツールの側で権限を確かめる） |
2.3 MCP の認可（概要）
MCP の仕様では、HTTP で動くリモートの MCP サーバーの認可に OAuth 2.1 の考え方を使います。ローカルの stdio サーバーは、この仕組みではなく環境の資格情報を使います。詳しい流れ（認可サーバーの発見、トークンの宛先〈audience〉の確認など）は仕様が更新されやすいので、公式の MCP の仕様で確かめてください。
3. 精度と遅延のトレードオフ
| つまみ | 精度 | 遅延 | コスト |
|---|---|---|---|
| 上位のモデル | 上がりやすい | 増える | 増える |
| effort / thinking を上げる | 上がりやすい | 増える | 増える |
| 検索するチャンクを増やす（top-K） | 上がりやすい（ある所まで） | 増える | 増える |
| リランクを足す | 上がる | 少し増える | 少し増える |
| マルチエージェント | 上がることがある | 並列なら短くなることも | 大きく増える（約15倍） |
| キャッシュ | 変わらない | 減る | 減る |
| ストリーミング | 変わらない | 体感が良くなる（TTFT） | 変わらない |
正当化のしかた: 「精度を上げたから良い」ではなく、SLA（例: p95 で3秒以内）を満たす中で、評価の正答率がいちばん高い構成を選ぶ、と数字で説明します（ドメイン6）。
例: リランクは遅延が少し増えるが、モデルに渡すチャンクが減るので、全体のコストと遅延が下がることもある（Contextual Retrieval の記事）。
4. 大規模なオブザーバビリティ
4.1 LLM システムで難しいこと
| 課題 | 理由 |
|---|---|
| 同じ入力でも結果が変わる | 非決定性。1回の再現では原因がわからない |
| 失敗が「エラー」にならない | HTTP 200 でも中身が間違い（ハルシネーション） |
| 長いエージェントの流れ | 何十回ものツール呼び出しのどこで外れたか追う必要 |
| プライバシー | 中身をそのまま記録すると個人情報が残る |
| 量 | すべての中身を人が読むことはできない |
4.2 監視の戦略
| 戦略 | 何を見るか | 道具 |
|---|---|---|
| 構造の指標 | 遅延、トークン、コスト、エラー率、stop_reason の分布、ツールの呼び出し回数 |
OpenTelemetry のメトリクス、応答の usage |
| トレース | 1つの依頼の中の、モデル呼び出しとツール呼び出しの流れ | Agent SDK / Claude Code の OpenTelemetry のトレース |
| 品質のサンプリング | 本番の一部を LLM の採点者や人が採点 | オンライン評価（ドメイン4） |
| 変化の検知 | 入力の種類の変化（drift）、指標の急な変化 | ダッシュボードとアラート |
| 中身を見ない監視 | 判断のパターンや構造だけを見る | Anthropic の Research も、個々の会話の中身を見ずに判断のパターンを監視している |
Agent SDK と Claude Code の OpenTelemetry は、初期設定では構造の情報（時間、モデル名、ツール名、トークン数）だけを記録し、プロンプトやツールの中身は設定したときだけ記録します（Developer F ドメイン4 第3.2節）。
5. RAG パイプラインの設計（チャンク分割とインデックス）
5.1 RAG が要るか
Anthropic の Contextual Retrieval の記事: 知識ベースが 200,000 トークン（約500ページ）より小さいなら、RAG を使わずに全部をプロンプトに入れる方法もある。プロンプトキャッシュで速く安くできる。それより大きい知識ベースには RAG が必要です。
注意: この「200,000 トークン」は記事が書かれた時点のコンテキストウィンドウにもとづく目安です。今のモデルは 1M トークンですが、多く入れるほどコストと遅延が増え、気が散ることもあるので、量・更新の頻度・権限の要件で判断します。
5.2 パイプラインの全体
| 段階 | いつ | やること |
|---|---|---|
| 1. 取り込み | 前もって | 文書を集める。形式をそろえる（PDF・HTML → テキスト）。権限・日付・出典のメタデータを付ける |
| 2. チャンク分割 | 前もって | 文書を小さな塊に分ける（記事によると、ふつうは数百トークン以下） |
| 3. インデックス | 前もって | 埋め込み（ベクトル）と、語の一致のための索引（BM25）を作る |
| 4. 検索 | 質問のたび | 質問に近いチャンクを探す |
| 5. 結合・リランク | 質問のたび | 複数の検索の結果をまとめ、リランカーで並べ直し、上位 K 件に絞る |
| 6. 生成 | 質問のたび | チャンクをプロンプトに入れて答えさせる。出典を示させる |
| 7. 更新 | 文書が変わるたび | 再インデックス、古いチャンクの削除 |
5.3 チャンク分割の決めごと
| 決めること | 選択肢 | 判断の目安（一般的な実践） |
|---|---|---|
| 大きさ | 小さい / 大きい | 小さいと的確だが文脈が欠ける。大きいと文脈はあるが関係ない部分も入る |
| 区切り方 | 固定の長さ / 文や段落 / 見出しなどの構造 | 構造のある文書（マニュアル、規程）は見出しで区切ると意味がまとまる |
| 重なり（overlap） | なし / 少し重ねる | 区切りの前後の文脈を失わないために重ねる |
| メタデータ | 文書名、章、日付、権限、版 | 絞り込み、出典、古い情報の除外に使う |
Contextual Retrieval の記事も、チャンクの大きさ・区切り・重なりの選び方が検索の性能に影響すると書いています。正解の値は決まっていないので、評価で決めます。
5.4 チャンクが文脈を失う問題と Contextual Retrieval
問題: 「同社の売上は前の四半期より3%伸びた」というチャンクだけでは、どの会社のいつの話かわかりません。
Anthropic の Contextual Retrieval（記事の数字）:
| 手法 | しくみ | 検索の失敗率（top-20） |
|---|---|---|
| ふつうの埋め込み | チャンクをそのまま埋め込む | 5.7% |
| Contextual Embeddings | Claude が各チャンクに、文書全体から見た短い説明（ふつう50〜100トークン）を前に付けてから埋め込む | 3.7%（35%減） |
| ＋ Contextual BM25 | 説明を付けたチャンクで BM25 の索引も作る | 2.9%（49%減） |
| ＋ リランク | 上位150件をリランカーで採点し、上位20件に絞る | 1.9%（67%減） |
コストの工夫: 文書をプロンプトキャッシュに1回読み込み、チャンクごとに参照するので安く作れます（記事の条件で、100万文書トークンあたり約 $1.02 の1回きりの費用）。
記事のまとめ:
- 埋め込み＋BM25 は、埋め込みだけより良い
- 上位20件をモデルに渡すほうが、10件や5件より良かった（ただし自分の用途で試す）
- チャンクに文脈を足すと、検索の精度が大きく上がる
- リランクはあったほうが良い
- これらの効果は重ねられる
5.5 埋め込みモデル
公式の Embeddings のページによると、Anthropic は自社の埋め込みモデルを提供していません。例として Voyage AI（MongoDB）を紹介しています（ほかの提供者も比べるように、とも書いています）。
| 選ぶときの観点（公式） | 内容 |
|---|---|
| 学習データの大きさと分野 | 分野に近いデータで学んだモデルは、その分野で良い埋め込みを作る |
| 推論の性能 | 検索の速さと全体の遅延。大規模な本番で大事 |
| カスタマイズ | 自社データで追加学習できるか |
Voyage AI の例（2026年11月時点。変わりやすい）: 汎用の voyage-4 系、コード向けの voyage-code-4、金融向け・法律向けのモデル、画像も扱うマルチモーダルのモデル、リランカーの rerank-3 系。文書を埋め込むときは input_type="document"、質問を埋め込むときは input_type="query" を使い分けます。
5.6 インデックスの決めごと
| 決めること | 内容 |
|---|---|
| 索引の種類 | ベクトルの索引（意味の近さ）と、語の索引（BM25）。両方を持つハイブリッド |
| 再インデックス | 文書を更新したら、そのチャンクを作り直す。消えた文書のチャンクを消す |
| 埋め込みモデルをそろえる | 文書と質問で同じ埋め込みモデル（と同じ版）を使う。モデルを変えたら全部作り直す |
| 権限 | 文書の権限をメタデータに持ち、検索時に絞る（第2.2節） |
| 版と日付 | 新旧の文書が混ざらないよう、版や有効期間で絞る |
試験のサンプル問題3と同じ論点: 文書を更新したあと、RAG が自信ありげに間違えるようになった（遅延とモデルは変わらない）→ 最初に調べるのは、検索・インデックスの段階が無関係または古いチャンクを返していないかです（再インデックスの失敗、埋め込みの不一致など）。
6. データの形と質問の形に合った検索
6.1 検索の方法
| 方法 | 得意 | 苦手 |
|---|---|---|
| 意味検索（埋め込み） | 言い換え、あいまいな質問（「返品の決まりは?」） | 型番、エラーコード、固有名詞の完全一致 |
| 語の検索（BM25） | 完全一致（「エラーコード TS-999」） | 言い換え |
| ハイブリッド | 両方。結果を順位の融合（rank fusion）でまとめる | 少し複雑 |
| メタデータの絞り込み | 日付、部門、製品、権限 | 中身の意味は見ない |
| 構造化データへの問い合わせ | 数字の集計（「先月の売上の合計」） → SQL や API のツール | 自由な文章 |
| エージェント型の検索 | 何回も検索し、結果を見て次の検索を決める | 遅く高い |
6.2 選び方
| データの形 / 質問の形 | 合う検索 |
|---|---|
| 型番・コード・ID が多い技術文書 | ハイブリッド（BM25 を必ず含める） |
| 言い換えの多い FAQ | 意味検索（＋リランク） |
| 表やデータベースの数字 | RAG ではなく、SQL や API をツールとして呼ぶ |
| 日付や版で答えが変わる規程 | メタデータで有効な版に絞ってから検索 |
| 複数の文書をまたぐ調査（「A と B を比べて」） | 質問を分ける、エージェント型の多段階の検索 |
| コード | コード向けの埋め込み、または grep などのツールでの検索（Claude Code はファイルを直接探す） |
| 小さく変わらない知識 | RAG なしで全部をプロンプトに入れ、キャッシュ |
Anthropic の Research の記事は、ふつうの RAG を「静的な検索」（質問に近いチャンクを1回取ってくる）と呼び、エージェントの多段階の検索（見つけたことに合わせて次を探す）と比べています。
6.3 答えの品質を上げる
| 打ち手 | 内容 |
|---|---|
| 出典を示させる | どのチャンクから答えたかを示させる。引用（citations）の機能も使える |
| 「わからない」を許す | 検索結果に答えがなければ、そう言うように指示（ハルシネーションを減らす） |
| 文脈とチャンクを分ける | 記事: チャンクと付けた説明を分けて渡すと、生成が良くなることがある |
| 検索と生成を別々に評価 | 検索の再現率（recall@K）と、答えの正しさを分けて測る（ドメイン4） |
7. 統合の仕組みを選ぶ: MCP、API/CLI、エージェント間
| 仕組み | 何をつなぐか | 向いている | 注意 |
|---|---|---|---|
| MCP | エージェントとツール・データ（agent-to-tool） | 多くのクライアントで同じ連携を使い回す。既存の MCP サーバーがある | リモートは認可（OAuth）、ツールの数によるトークン |
| 直接の API（関数呼び出し、tool use） | 自分のアプリと自分のシステム | 1つのアプリだけで使う、細かく制御したい | アプリごとに作る |
| CLI | エージェントとコマンドラインの道具 | Claude Code などで、git・gh・社内の CLI を使う |
権限（permissions の allow / deny）、サンドボックス |
| エージェント間（A2A など） | 別々に作られたエージェント同士 | 組織・製品・フレームワークをまたいで仕事を任せる | 認証・信頼・監視が難しい。中身が見えない相手 |
| 自分のシステムの中のサブエージェント | 同じシステムのエージェント | 1つの製品の中の分業 | A2A は要らない（フレームワークの機能を使う） |
7.1 A2A について（Anthropic 以外の仕様）
A2A（Agent2Agent）プロトコルは Google が作り、Linux Foundation に寄付されたオープンな標準です（a2a-protocol.org）。公式サイトの説明では、MCP はエージェントとツールの通信、A2A はエージェントとエージェントの通信で、競合ではなく組み合わせて使うものです。A2A は、自分のサブエージェントとの通信やツールの呼び出しのための仕組みではない、とも書いています。
試験ガイドは「agent-to-agent」と書いていますが、特定のプロトコル名は書いていません。A2A はその代表例として覚えてください（この教材の判断）。
7.2 判断の例
| 状況 | 選ぶ |
|---|---|
| 社内の Jira を Claude Code・Claude Desktop・自社エージェントの全部から使いたい | MCP サーバーを1つ作る |
| 自社アプリから在庫 API を1つ呼ぶだけ | 直接の tool use |
開発者が gh で PR を作る |
CLI（Claude Code の権限で許可） |
| 取引先の会社のエージェントに見積もりを任せる | エージェント間のプロトコル（相手の中身は見えない前提で、認証と結果の検証） |
8. 段階的な発見 と 一括のコンテキスト
| 一括のコンテキスト（monolithic） | 段階的な発見（progressive discovery） | |
|---|---|---|
| しくみ | ツール定義・知識をすべて最初からコンテキストに入れる | 最初は目次や検索の道具だけ。必要なときに必要な分を読み込む |
| 長所 | 簡単。すべて見えているので、1回で選べる | トークンが少ない、ツールが多くても選び間違いにくい |
| 短所 | トークンが多い、ツールが多いと選び間違う、遅い | 探す手間（1回多く呼ぶ）。見つからないことがある |
| 向いている | ツールが少ない（目安で数個〜十数個）、知識が小さい | ツールが何百・何千、知識が大きい、MCP サーバーが多い |
8.1 公式の仕組みと数字
| 仕組み | しくみ | 数字（公式） |
|---|---|---|
| ツール検索（tool search tool） | ツールに defer_loading: true を付け、Claude が検索して必要なツールだけ読み込む。正規表現版と BM25 版がある。検索の道具自体は遅延読み込みにしない |
定義のトークンを85%以上減らすことが多い。1回の依頼で読み込むのは3〜5個 |
| MCP をコードの API として見せる（code execution with MCP） | ツールをファイルとして並べ、エージェントが必要なファイルだけ読む。データはコードの中で絞ってから返す | 記事の例で 150,000 トークン → 2,000 トークン（98.7%減） |
| Skills | メタデータだけ常に読み込み、本文と資料は使うときだけ | メタデータは1スキルあたり約100トークン |
code execution with MCP の注意（記事）: エージェントが書いたコードを動かすには、サンドボックス・資源の上限・監視が必要で、運用の手間とセキュリティの考慮が増えます。直接のツール呼び出しと比べて決めます。
9. 試験に向けたまとめ
- 機能過多 → 役割に要らないツールを外すのがいちばん効く（ログや確認は補助）
- 認可はプログラムで。利用者本人の権限でデータへ。token passthrough をしない。RAG の索引も権限で絞る
- 精度と遅延は SLA の中で評価の数字で選ぶ
- 監視は構造の指標・トレース・品質のサンプリング・変化の検知。中身の記録は最小限
- RAG: チャンク（大きさ・区切り・重なり・メタデータ）、ハイブリッド検索（埋め込み＋BM25）、リランク、Contextual Retrieval（失敗を49%減、リランクで67%減）
- 文書更新のあとに自信ありげな誤答 → まず検索・インデックスを疑う
- 数字の集計は RAG ではなく SQL や API のツール
- MCP はエージェントとツール、A2A はエージェントとエージェント
- ツールが多い → 段階的な発見（ツール検索、Skills、コードの API）
10. 用語集
| 用語 | 意味 |
|---|---|
| capability bloat（機能過多） | 必要以上のツールや権限を持つこと |
| confused deputy（混乱した代理人） | 権限の強い仲介役が、権限の弱い依頼者の代わりに許されない操作をしてしまうこと |
| token passthrough | 受け取ったトークンを確かめずに下流に渡すこと |
| RAG | 検索拡張生成。検索した情報をプロンプトに足して答えさせる |
| チャンク | 文書を分けた小さな塊 |
| 埋め込み（embedding） | 文の意味を数字の並び（ベクトル）にしたもの |
| BM25 | 語の一致で順位を付ける昔からの方法。TF-IDF を改良したもの |
| リランク | 最初の検索の結果を、専用のモデルで並べ直すこと |
| rank fusion | 複数の検索の順位をまとめる方法 |
| recall@K | 正しいチャンクが上位 K 件に入った割合 |
| A2A | Agent2Agent。エージェント同士の通信のオープンな標準 |
| defer_loading | ツール検索で、最初は読み込まないツールに付ける設定 |
出典
- Introducing Contextual Retrieval（Anthropic）: 200,000 トークンの目安、RAG の流れ、BM25、Contextual Embeddings / BM25、35%・49%・67%、リランク、$1.02、チャンクの境界、20件
- Embeddings（Claude Platform Docs）: Anthropic は埋め込みモデルを提供しない、Voyage AI、選ぶ観点、
input_type、リランカー - Tool search tool（Claude Platform Docs）: 約55k トークン、85%以上、30〜50個、
defer_loading、3〜5個 - Code execution with MCP（Anthropic Engineering）: 段階的な開示、98.7%、データをコードで絞る、サンドボックスの必要
- How we built our multi-agent research system（Anthropic Engineering）: 静的な検索と多段階の検索、中身を見ない監視
- API and data retention（Claude Platform Docs）: ZDR の組織はブラウザから呼べない
- MCP Security Best Practices（modelcontextprotocol.io）: token passthrough はアンチパターンで、認可の仕様で明確に禁止。宛先（audience）の確認、confused deputy
- MCP Authorization（modelcontextprotocol.io）: HTTP のサーバーの OAuth 2.1 による認可
- A2A Protocol（a2a-protocol.org）: A2A と MCP の関係、Linux Foundation（Anthropic 以外の情報源）
- 試験ガイド サンプル問題1・3
注意: 第1節の「機能過多」の定義と点検表、第2.2節の穴の一覧、第5.3節の判断の目安、第6.2節の選び方の表、第8節の「ツールが少ない」の目安は、この教材の整理です。MCP の認可の仕様、Voyage のモデル名、ツール検索の対応モデルは変わりやすい情報です。MCP の Authorization のページ（OAuth 2.1 の部分）は今回取得していないので、本番前に確かめてください（Security Best Practices のページは取得して確認済み）。