Architect Foundations 6つのシナリオの解説
本番では、6つのシナリオのうち4つがランダムに出ます。問題は「このシナリオの中で、どの設計が最も良いか」を問います。どのシナリオが出ても困らないよう、6つすべてを見ておきます。
| # | シナリオ | 主なドメイン（試験ガイド） | よく出る判断 |
|---|---|---|---|
| 1 | カスタマーサポート解決エージェント | D1、D2、D5 | フックでの強制、ツールの説明、エスカレーション |
| 2 | Claude Code でのコード生成 | D3、D5 | CLAUDE.md、コマンドとスキル、plan mode |
| 3 | マルチエージェント調査システム | D1、D2、D5 | 分解、コンテキストの受け渡し、エラー伝播、出典 |
| 4 | Claude による開発者の生産性向上 | D2、D3、D1 | 組み込みツール、MCP、探索のコンテキスト |
| 5 | 継続的インテグレーションでの Claude Code | D3、D4 | -p、構造化出力、誤検知、バッチ |
| 6 | 構造化データ抽出 | D4、D5 | スキーマ、検証と再試行、確信度と人のレビュー |
シナリオの「主なドメイン」以外の問題も出ます。1つのシナリオの中で、ほかのドメインの考え方を問われることはよくあります。
解き方のコツ（6つのシナリオに共通）
- 根本原因を探す。症状の出ている部品（下流のエージェント、モデルの大きさ）ではなく、原因の部品を直す選択肢を選ぶ
- 「最初の一手」と書いてあれば、根本原因に効いて手間の小さいものを選ぶ。大がかりな仕組み（別の分類モデル、振り分けの層）は誤答になりやすい
- お金・本人確認・ポリシーなど「必ず守る」ことは、プロンプトではなくプログラム（フック、ゲート）
- 存在しない機能（
CLAUDE_HEADLESS、--batch、.claude/config.jsonの commands）は誤答 - 「全部入れる」「全部読む」「ツールを全部渡す」は、たいてい誤答（コンテキストと選択の信頼性を下げる）
シナリオ1: カスタマーサポート解決エージェント
場面: Agent SDK でサポートのエージェントを作る。返品、請求の争い、アカウントの問題など、あいまいな依頼が多い。MCP ツールは get_customer、lookup_order、process_refund、escalate_to_human。目標は初回解決率80%以上と、適切なエスカレーション。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
| 確認の前に返金してしまう | get_customer が確認済み ID を返すまで lookup_order と process_refund を止める前提条件ゲート |
D1 第4節 |
| 上限を超える返金 | PreToolUse フックで止め、escalate_to_human へ |
D1 第5節 |
| ツールの取り違え | 説明文を詳しくする（入力形式、例、境界） | D2 第1節 |
| 返品期限切れのエラー | 業務エラー、再試行不可、顧客向けの説明を返す | D2 第2節 |
| ツールごとに日付の形が違う | PostToolUse フックで正規化 | D1 第5節 |
| 初回解決率が低い、エスカレーションの判断がずれる | 明確な基準と few-shot 例をシステムプロンプトに | D5 第2節 |
| 顧客が人を求めた | すぐに応じる | D5 第2節 |
| 同じ名前の顧客が複数 | 追加の識別情報を尋ねる | D5 第2節 |
| 長い会話で金額が消える | case facts ブロック | D5 第1節 |
| 1通に3つの問題 | 分けて並列に調べ、1つの回答にまとめる | D1 第4節 |
| 人への引き継ぎ | 顧客 ID、根本原因、金額、推奨アクションの構造化要約 | D1 第4節 |
落とし穴: 「自己申告の確信度でエスカレーション」「感情分析でエスカレーション」「別の分類モデルを先に作る」は、サンプル問題でも誤答です。
シナリオ2: Claude Code でのコード生成
場面: チームが Claude Code をコード生成、リファクタリング、デバッグ、文書化に使う。カスタムのスラッシュコマンド、CLAUDE.md の設定、plan mode と直接実行の使い分けを決める。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
チーム全員の /review |
.claude/commands/（今は .claude/skills/ も）にコミット |
D3 第2節 |
| 自分だけのコマンド | ~/.claude/commands/ か ~/.claude/skills/ |
D3 第2節 |
| 新メンバーに決まりが効かない | ユーザー単位からプロジェクト単位へ移す | D3 第1節 |
| 散らばったテストファイルの規約 | .claude/rules/ に paths: ["**/*.test.tsx"] |
D3 第3節 |
| モノリスの分割、大きな移行 | plan mode で調べて設計してから | D3 第4節 |
| 明確な1か所の修正 | 直接実行 | D3 第4節 |
| 探索でコンテキストが埋まる | Explore サブエージェント、/compact、スクラッチパッド |
D3 第4節、D5 第4節 |
| 出力の多いスキル | context: fork |
D3 第2節 |
| 変換の説明が伝わらない | 2〜3個の入出力例 | D3 第5節 |
| 昨日のセッションの続き | --resume <名前> と変更したファイルの共有 |
D1 第7節 |
落とし穴: 「直接実行で始めて、困ったら plan mode」は誤答。複雑さが最初から要件に書いてあるなら、最初から plan mode です。
シナリオ3: マルチエージェント調査システム
場面: Agent SDK で調査システムを作る。コーディネーターが、Web 検索、文書分析、統合、レポート作成のサブエージェントに仕事を配る。出典付きの総合的な報告書を作る。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
| 報告に分野の抜け。各サブエージェントは正常 | コーディネーターの分解が狭い | D1 第2節 |
| サブエージェントが前の結果を知らない | 結果をプロンプトに明示的に入れる | D1 第3節 |
| 遅い | 1回の応答で複数の Task（Agent）呼び出し | D1 第3節 |
| サブエージェントを呼ばない | allowedTools に "Task"（今は "Agent"） |
D1 第3節 |
| 統合エージェントが Web 検索を始める | 役割に必要なツールだけ渡す | D2 第3節 |
| 事実確認の往復が多い | 範囲を絞った verify_fact。複雑なものはコーディネーター経由 |
D2 第3節 |
| 検索のタイムアウト | 失敗の種類、問い合わせ、部分結果、代案を含む構造化エラー | D5 第3節 |
| 出典が消える | 主張と出典の対応を構造化して保つ | D5 第6節 |
| 情報源で数字が違う | 両方を出典付きで、食い違いを注記 | D5 第6節 |
| どこまで調べられたか | 網羅の注記 | D5 第3節 |
| 途中でクラッシュ | 各エージェントの状態とマニフェストから再開 | D5 第4節 |
落とし穴: 抜けの原因を、正しく動いている下流のエージェント（検索の語、統合の指示）のせいにする選択肢。
シナリオ4: Claude による開発者の生産性向上
場面: Agent SDK で開発者向けのツールを作る。知らないコードベースの探索、レガシーの理解、定型コードの生成、くり返しの作業の自動化を助ける。組み込みツール（Read、Write、Bash、Grep、Glob）と MCP サーバーを使う。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
| 関数の呼び出し元を探す | Grep | D2 第5節 |
**/*.test.tsx を探す |
Glob | D2 第5節 |
| Edit が一意に一致しない | Read して Write | D2 第5節 |
| 知らないコードベースの理解 | Grep で入口 → Read で import をたどる。全部は読まない | D2 第5節 |
| 別名で再公開された関数 | 公開名をすべて特定してから、それぞれを検索 | D2 第5節 |
| MCP ツールより Grep ばかり使う | MCP ツールの説明に能力と出力を詳しく書く | D2 第4節 |
| Jira 連携 | 既存の MCP サーバー | D2 第4節 |
| 課題の一覧を見せたい | MCP リソース | D2 第4節 |
| 「十分なテストを追加して」 | 構造を把握 → 影響の大きい部分 → 優先順位付きの計画（動的な分解） | D1 第6節 |
| 長い探索で一般論を語り出す | スクラッチパッド、サブエージェント | D5 第4節 |
| 2つのリファクタリング方針を比べる | fork_session |
D1 第7節 |
シナリオ5: 継続的インテグレーションでの Claude Code
場面: CI/CD に Claude Code を組み込み、自動のコードレビュー、テストの生成、PR へのフィードバックを行う。実行できるフィードバックを出し、誤検知を減らすプロンプトを設計する。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
| ジョブが入力待ちで止まる | -p |
D3 第6節 |
| PR のインラインコメントに使う | --output-format json と --json-schema（structured_output） |
D3 第6節 |
| CI にテスト規約を伝える | CLAUDE.md に規約、価値のあるテストの基準、フィクスチャ | D3 第6節 |
| 再レビューで同じコメント | 前回の指摘を渡し、新規と未修正だけ | D3 第6節 |
| テストが重複 | 既存のテストを渡す | D3 第6節 |
| 誤検知が多い | 報告するもの・しないものを具体的に | D4 第1節 |
| 1つのカテゴリの誤検知 | 一時的に止めて直す | D4 第1節 |
| 14ファイルの PR でレビューがぶれる | ファイルごとのパスと統合のパス | D4 第6節 |
| 生成と同じセッションでレビュー | 独立したインスタンス | D4 第6節 |
| コストを下げたい | 夜間のレポートだけバッチ、マージ前は同期 | D4 第5節 |
| 却下された指摘の分析 | detected_pattern |
D4 第4節 |
シナリオ6: 構造化データ抽出
場面: Claude で非構造化の文書から情報を抜き出し、JSON スキーマで検証し、高い精度を保つ。例外的なケースをうまく扱い、下流のシステムとつなぐ。
| 設計の判断 | 良い答え | 関係する節 |
|---|---|---|
| JSON の構文エラー | JSON スキーマ付きのツール（tool_use）、strict: true |
D4 第3節 |
| 文書の種類がわからない | tool_choice: "any"（新しいモデルでは auto + strict か構造化出力） |
D4 第3節 |
| 値をでっち上げる | その項目を nullable に | D4 第3節 |
| 想定外の分類 | "other" + 詳細、"unclear" |
D4 第3節 |
| 合計が合わない | 検証して、具体的なエラーで再試行。stated_total と calculated_total |
D4 第4節 |
| 情報が別の文書にしかない | 再試行は効かない | D4 第4節 |
| 形式の違う文書で項目が空になる | 多様な文書構造の few-shot 例 | D4 第2節 |
| 大量の文書を安く | Message Batches API、custom_id、失敗分だけ再投入 |
D4 第5節 |
| 全体で97% | 種類と項目ごとに確かめる | D5 第5節 |
| 人のレビューの振り分け | ラベル付きのセットで調整した項目ごとの確信度 | D5 第5節 |
| 自動化した後の監視 | 層別ランダムサンプリング | D5 第5節 |
落とし穴: 「スキーマを厳しくすれば合計の食い違いも防げる」は誤り。スキーマが防ぐのは構文で、意味のエラーは検証が必要です。
出典
- Claude Certified Architect – Foundations Exam Guide（PDF、Version 1.0、2026年7月）: 第5章 試験シナリオ、第8章 準備演習、第9章 サンプル問題
- 各行の根拠は、リンク先の教材の出典を参照してください。
シナリオの文章は試験ガイドを要約・言い換えたものです（ライセンスに配慮して書き直しています）。