Domain 1: Agentic Architecture & Orchestration
配点 27%(最重要) — Task 1.1〜1.7
1.1 エージェンティックループの実装
図1-1: 正しいエージェンティックループ制御フロー
// 正しいエージェンティックループ(TypeScript)
const messages: Message[] = [...];
while (true) {
const response = await client.messages.create({ model, tools, messages });
// stop_reasonで分岐
if (response.stop_reason === "end_turn") break; // ✅ 終了
if (response.stop_reason === "tool_use") {
messages.push({ role: "assistant", content: response.content });
const toolResults = await executeTools(response.content);
messages.push({ role: "user", content: toolResults }); // 履歴に追加
}
}
// ❌ Anti-pattern: if (text.includes("完了")) break; → 自然言語で判定
// ❌ Anti-pattern: for (let i=0; i<10; i++) { ... } → 固定回数が主要停止機構1.2 マルチエージェント Hub-and-Spoke
図1-2: Hub-and-Spoke マルチエージェントアーキテクチャ(正しい設計)
| 重要設定・概念 | 説明 |
|---|---|
allowedTools: ["Task"] | コーディネーターがサブエージェントを生成するために必須の設定 |
| 並列実行 | 1 つのレスポンスで複数の Task 呼び出しを発行 → 同時実行。別ターンにすると順次実行になる |
| コンテキスト渡し | 前のエージェントの結果をサブエージェントプロンプトに直接含める。構造化フォーマット推奨 |
| 反復精製 | コーディネーターが合成出力のギャップを評価し、必要に応じて再委譲してカバレッジを向上させる |
🔑
サブエージェント description の設計(コーディネーターによる選択の唯一の根拠)
コーディネーターはサブエージェントの description フィールドを唯一の根拠として委譲先を選択します。これはツール選択と同じメカニズムです。「Search Agent」「Analysis Agent」のような最小限の名前だけでは類似サブエージェント間で誤選択が発生 します。良い description には ① このエージェントが扱うタスクの種類 ② 入力として受け取るべき情報 ③ 出力フォーマット ④ 類似エージェントとの境界線、を含めます。
| ❌ 最小限 | ✅ 良い記述 |
|---|---|
search_agent: “Searches the web”analysis_agent: “Analyzes documents”→ コーディネーターが境界を判断できず誤委譲 | search_agent: “Web 上の最新情報を検索。クエリ+日付範囲を受け取り、URL・抜粋・公開日を返す。社内ドキュメント検索には analysis_agent を使うこと”→ 境界が明確 |
1.3 並列 vs 順次サブエージェント実行
図1-3: 並列実行(1レスポンス内)vs 順次実行(複数ターン)
| パターン | 使いどころ | 実装方法 |
|---|---|---|
| 並列実行(推奨) | サブタスク同士に依存関係がない(独立検索・独立分析・独立要約) | 1 つの assistant レスポンスの content 配列に複数の tool_use(Task 呼び出し)を含める |
| 順次実行 | 後段が前段の結果に依存する(検索結果を分析エージェントに渡すなど) | 1 ターンに 1 Task 呼び出し → 結果を待つ → 次ターンで次 Task 呼び出し |
⚠️
試験頻出の罠:常に順次実行する設計
独立タスクを順次実行すると レイテンシが線形に増加 する。「独立した 4 つの調査をそれぞれ別ターンで実行」は誤り。1 レスポンスで全 Task 呼び出しを発行すれば並列実行される。逆に、依存関係があるタスクを並列化すると、後段が古い情報で動作するバグが発生する。
1.4 サブエージェントへのコンテキスト渡し
🔴
最重要原則:サブエージェントはコンテキストを自動継承しない
コーディネーターの会話履歴・前のサブエージェントの結果・ユーザーからの元入力 — これらはすべて サブエージェントには見えない。コーディネーターが明示的にプロンプトに含めなければ伝わらない。試験ではこの原則を問う問題が複数回出る。
| 渡すべき情報 | 理由・具体例 |
|---|---|
| 元のユーザー要求の核心 | サブエージェントが「なぜこのタスクをやっているか」を理解できるように |
| 前段サブエージェントの構造化出力 | JSON など機械可読フォーマットで渡す(自然言語要約は情報損失) |
| 制約条件・ポリシー | 「金額は $500 未満のみ」「公開日 2023 年以降のみ」など |
| 期待される出力スキーマ | 後段で統合しやすい形式を明示。フィールド名・型・必須/任意を指定 |
| 出所情報(provenance)要件 | 「source URL・公開日・抜粋を必ず含める」を明示的に指示 |
// ✅ 良いコンテキスト渡しの例
const analysisAgentPrompt = `
## 元のユーザー要求
"Q4の売上トレンドと競合動向を比較した投資レポートを作成"
## 前段(Search Agent)の出力
${JSON.stringify(searchResults, null, 2)}
## あなたのタスク
上記の検索結果を分析し、以下のJSON形式で返してください:
{
"trends": [{"metric": string, "direction": "up"|"down", "evidence": {...}}],
"competitors": [{"name": string, "signal": string, "source_url": string}]
}
## 制約
- 公開日2024年以降のソースのみ使用
- 各claim に source_url と公開日を必ず含める
`;
// ❌ 悪い例:コンテキストなし
const badPrompt = "競合を分析してください";
// → サブエージェントが「何の競合?どんなフォーマットで?」を推測することになり信頼性低下1.5 Agent SDK フックパターン
図1-4: PostToolUseフックによるデータ正規化とポリシー強制
PostToolUse フックは MCP ツールの戻り値とエージェントの間に挟まる決定論的レイヤー です。プロンプトでは保証できない「データ正規化」と「ポリシー強制」を保証する箇所として、合格者の答案で頻出します。
1.6 タスク分解戦略
| パターン | 使いどころ | 例 |
|---|---|---|
| Prompt chaining(固定順序) | 手順が予測可能なマルチアスペクトタスク | ファイル別分析 → クロスファイル統合パス |
| 動的適応型分解 | 中間の発見に基づいて次のステップが変わる | 「レガシーコードベースに包括的なテストを追加」 |
1.7 セッション管理
| 方法 | 使いどころ | コマンド/方法 |
|---|---|---|
| Named session resumption | 以前のコンテキストが主に有効 | --resume <session-name> |
| Fork session | 共有ベースラインから複数アプローチを並列探索 | fork_session |
| Fresh start + summary | 以前のツール結果が古くなっている | 構造化サマリーを新セッションへ注入 |
Last updated on