← 試験の目次へ

Architect Foundations ドメイン1: エージェント型アーキテクチャとオーケストレーション（27%）

この章で学ぶこと: エージェントループの制御、コーディネーターとサブエージェントの分担、サブエージェントへの情報の渡し方、フックによる強制、タスクの分け方、セッションの再開とフォーク。

いちばん配点の大きいドメインです。本番の60問のうち約16問が出ます。

Developer Foundations で学んだ基本（ここでは繰り返しません）:

• ツール利用のループのコードと stop_reason → Developer D1 第2.2節
• Agent SDK のループ、組み込みツール、権限モード、max_turns → Developer D1 第2.3節
• フックの種類と書き方（permissionDecision、updatedToolOutput） → Developer D1 第2.5節
• AgentDefinition の項目、サブエージェントが受け取るもの → Developer D1 第3.2節
• 5つのワークフローパターン（チェーン、ルーティング、並列化、オーケストレーター・ワーカー、評価・最適化） → Developer D1 第1.4節

この章では、その上の「設計の判断」に言葉を使います。

名前の注意: 試験ガイドはサブエージェントを起動するツールを「Task ツール」と呼びます。今の公式ドキュメントでは名前が Agent に変わりました（Claude Code v2.1.63 から。system:init のツール一覧では今も "Task" と表示されます）。試験では「Task ツール = Agent ツール」として読みます。allowedTools に入れる名前は、今は "Agent" です。

1. エージェントループ（1.1）

1.1 ループの判断は stop_reason だけで行う

ツールの結果は会話の履歴に足します。だから Claude は、新しい情報を使って次の手を考えられます。

1.2 モデル主導と決定木の違い

両方を組み合わせるのがふつうです。全体はモデルに任せ、外してはいけない順番だけをコードで止めます。

1.3 アンチパターン（試験によく出る）

max_turns や max_budget_usd は「安全装置」です（Developer D1 第2.3節）。設定するのは正しいですが、「これで終わりを決める」は誤りです。

2. コーディネーター・サブエージェント型（1.2）

2.1 ハブ・アンド・スポーク

           ┌─ Web検索サブエージェント
コーディネーター ─┼─ 文書分析サブエージェント
（ハブ）       ├─ 統合サブエージェント
           └─ レポート作成サブエージェント

• サブエージェント同士は直接話さない。すべてコーディネーターを通る
• 理由: 可観測性（何が起きたか1か所で見える）、エラー処理をそろえる、情報の流れを制御する
• サブエージェントは分離されたコンテキストで動く。コーディネーターの会話履歴は自動では届かない（第3節）

2.2 コーディネーターの仕事

2.3 分解が狭すぎるリスク

コーディネーターの分解が狭いと、サブエージェントが全員正しく動いても、報告全体に穴が開きます。

例: 「AI が創造的な産業に与える影響」を、デジタルアート・グラフィックデザイン・写真の3つだけに分けた。音楽・文章・映画が抜ける。

見分け方: 各サブエージェントは「頼まれたこと」は正しくこなしている。問題は「何を頼んだか」。原因はコーディネーターの分解です。下流のエージェントを直しても治りません。

2.4 反復改善ループ

1. コーディネーターがサブタスクを配る
2. 結果を統合する
3. コーディネーターが抜けを評価する（どの観点が足りないか）
4. 抜けの部分だけ、絞った問いで検索・分析サブエージェントに再委任する
5. 十分に網羅できるまで 2〜4 をくり返す

Anthropic の調査システムでも、リードエージェントが結果を見て「もっと調べるか」を判断し、必要ならサブエージェントを追加しています（Multi-agent research system）。

3. サブエージェントの呼び出しと情報の渡し方（1.3）

3.1 呼び出しのしくみ

AgentDefinition の tools で、種類ごとに使えるツールを絞ります（第2章 2.3 の「ツールの配分」とつながる）。

3.2 コンテキストは明示的に渡す

サブエージェントは、親の会話履歴もツールの結果も受け取りません。呼び出し間でメモリも共有しません。受け取るのは、自分のシステムプロンプトと、呼び出しのプロンプトです（フォークは例外。下の 3.5）。

だから:

• 前のエージェントの結果を、次のサブエージェントのプロンプトに丸ごと入れる。例: Web検索の結果と文書分析の結果を、統合サブエージェントのプロンプトに入れる
• 「さっきの結果を使って」は通じない。中身を書く

3.3 構造化して出典を保つ

エージェント間で結果を渡すときは、本文とメタデータを分けた構造にします。

{
  "claims": [
    {
      "claim": "2025年の市場規模は約120億ドル",
      "source_url": "https://example.com/report",
      "document_name": "業界レポート2025",
      "page": 14,
      "excerpt": "...市場規模は約120億ドルに達した...",
      "published_date": "2025-03-01"
    }
  ]
}

散文の要約だけで渡すと、どの主張がどの出典から来たかが消えます（第5章 5.6 の出典管理）。

3.4 並列に生成する

複数のサブエージェントを同時に動かしたいときは、コーディネーターの1回の応答の中に、複数の Task（Agent）ツール呼び出しを並べます。1つずつ別のターンで呼ぶと、順番に待つことになり遅くなります。

Anthropic の調査システムでは、リードエージェントが3〜5個のサブエージェントを並列に起動し、複雑な問いの調査時間を最大90%縮めたと報告しています（Multi-agent research system）。

3.5 コーディネーターのプロンプトの書き方

• 手順を細かく指示するより、調査の目的と品質の基準を伝える。サブエージェントが状況に合わせて動ける
• 各サブエージェントへの依頼には、目的、出力の形、使うべきツールや情報源、仕事の範囲（どこまでやるか）を書く。Anthropic の記事も、あいまいな依頼は重複や抜けを生むとしている

3.6 フォーク型のセッション

共通の分析を終えた時点から、別々の方針を試したいときはフォークします（第7節）。フォークしたサブエージェントは、親の会話をコピーして始まります。

4. 強制と引き継ぎ（1.4）

4.1 プロンプトの誘導 と プログラムの強制

試験の目印: 「本番で 12% のケースで確認を飛ばした」「誤った返金が起きた」のように、失敗に金銭的な影響があるなら、答えはプログラムによる強制です。few-shot 例やプロンプトの強調は「確率的」なので不十分です。

4.2 前提条件ゲートの例（考え方）

verified_customer_id = None  # セッションの状態

async def gate_refund(input_data, tool_use_id, context):
    # PreToolUse フック: 確認済みの顧客がいなければ、注文・返金のツールを止める
    name = input_data["tool_name"]
    if name.endswith(("lookup_order", "process_refund")) and verified_customer_id is None:
        return {"hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason": "先に get_customer で顧客を確認してください",
        }}
    return {}

拒否の理由は Claude に届くので、Claude は次に get_customer を呼べます。MCP ツールの名前は Agent SDK では mcp__<サーバー名>__<ツール名> の形になるため、例では末尾で判定しています。

4.3 複数の問題を含む依頼

顧客が1通のメッセージで「返品したい」「請求が二重」「住所を変えたい」と言ったとき:

1. 個別の項目に分ける
2. 共有のコンテキスト（顧客 ID、注文一覧）を使って、それぞれを並列に調べる
3. 1つの回答にまとめて返す

4.4 人への引き継ぎ（エスカレーション）の要約

人の担当者は、エージェントの会話記録を見られないことが多いです。だから、引き継ぎには構造化した要約を付けます。

「会話の全文を渡す」は答えになりにくいです。担当者が読む時間がかかり、要点が埋もれます。

5. Agent SDK のフック（1.5）

フックの書き方は Developer D1 第2.5節 で学びました。ここでは試験の2つの使い方をおぼえます。

5.1 PostToolUse: 結果をそろえてからモデルに渡す

MCP ツールごとに、データの形がばらばらなことがあります。

PostToolUse フックで、モデルが読む前に1つの形（例: ISO 8601 と文字のステータス）にそろえます。今の Agent SDK では、PostToolUse の戻り値 updatedToolOutput で結果を差し替えられます（additionalContext で情報を足すこともできる）。

利点: プロンプトで「Unix 時刻は変換して読んで」と頼むより確実で、トークンも少なくてすみます。

5.2 PreToolUse: ルール違反の操作を止めて別の流れへ

例: 500ドルを超える返金は人の承認が必要。

• process_refund の PreToolUse フックで金額を見る
• 上限を超えたら permissionDecision: "deny" と理由を返す
• 理由に「escalate_to_human を使って」と書けば、Claude は人へのエスカレーションに切り替えられる

5.3 フックか、プロンプトか

公式の Claude Code のドキュメントも、「必ず決まったときに動かすこと」は CLAUDE.md ではなくフックに書くよう勧めています（Memory）。

6. タスク分解の戦略（1.6）

6.1 固定のチェーン と 動的な分解

6.2 大きなコードレビューを分ける

多くのファイルを1回で見ると、注意が分散します。詳しく見るファイルと浅いファイルが出て、同じ書き方を片方では指摘し、もう片方では見逃します。

1. ファイルごとのパス: 各ファイルのローカルな問題を見る
2. 統合パス: ファイルをまたぐデータの流れ、呼び出しの整合性を見る

これは第4章 4.6 の「複数パスのレビュー」と同じ考えです。

6.3 答えの決まっていない仕事の分け方

例: 「レガシーコードに十分なテストを追加して」

1. まず構造を把握する（モジュール、入口、依存関係）
2. 影響の大きい部分を特定する（よく使われる、壊れると困る、テストがない）
3. 優先順位付きの計画を作る
4. 依存関係がわかるたびに、計画を見直す

最初から全ファイルに順番にテストを書く、は誤りです。

7. セッションの状態・再開・フォーク（1.7）

7.1 道具

フォークの例: 認証モジュールの分析を終えたセッションから、「JWT の方針」と「OAuth2 の方針」を別々に試す。2つの枝は別々に再開できます（Session management）。

7.2 再開するか、要約で新しく始めるか

公式の Agent SDK のドキュメントも、別のホストで再開する方法の1つとして「再開に頼らず、必要な結果（分析、決めたこと、差分）をアプリの状態として保存し、新しいセッションのプロンプトに入れる。こちらのほうが堅牢なことが多い」としています。

古いツール結果のまま再開すると、Claude はもう存在しない関数やデータを前提に考えることがあります。

8. 試験に向けたまとめ

9. 用語集

出典

• Claude Certified Architect – Foundations Exam Guide（PDF、Version 1.0、2026年7月）: 第6章 ドメイン1 のタスクステートメント、第9章のサンプル問題
• How the agent loop works（Claude Code Docs）: ループ、メッセージの種類、上限
• Subagents in the SDK（Claude Code Docs）: AgentDefinition、コンテキストの受け渡し、Task から Agent への名前の変更、フォーク
• Intercept and control agent behavior with hooks（Claude Code Docs）: PreToolUse / PostToolUse、permissionDecision、updatedToolOutput
• Session management（Claude Code Docs）: continue、resume、fork、再開に頼らない方法
• Memory（Claude Code Docs）: 必ず動かすものはフックに
• How we built our multi-agent research system（Anthropic Engineering）: リードエージェントとサブエージェント、並列化、依頼の書き方
• Building effective agents（Anthropic Engineering）: ワークフローとエージェント、プロンプトチェーン

注意: 第4.2節のコードは考え方を示す例で、そのまま動く完全なプログラムではありません。Agent SDK と Claude Code は更新が速いので、本番前に公式ドキュメントで確かめてください（2026年11月時点の内容）。内容は上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。