CCA Foundations シナリオドリル（クローズドブック想定）
「CCA」= Claude Certified Architect – Foundations の略（cca-foundations.md 参照）。同日ローンチの非技術者向け新資格「Claude Certified Associate – Foundations」とは別物。
本番は「Xとは?」型でなく「システムが壊れている／要件がある、正しいアーキ判断は?」型（→ cca-foundations.md）。本ファイルはその本番フレーミングを真似たシナリオ設問を5ドメイン分そろえ、各設問に 正解・なぜ正解か・なぜ他が誤りか を付ける。題材はにしざきの実スタック（umaq race-engine・zenq・MCP サーバ群・Claude Code 運用）に寄せ、言語化練習＝実務の棚卸しを兼ねる。
使い方: ①選択肢だけ見て答えを決める → ②根拠を声に出して言語化 → ③答え合わせ → ④外したら該当ドメインの「言語化すべき要点」を再読。重みは cca-foundations.md 参照、最大は ①（~25–27%）。
⚠️ ここの設問は学習用の自作（非公式）。本番の正解判断は Anthropic 公式の原則に従うこと。最終的な範囲・正答は Partner Academy 内の公式 Exam Guide / 練習試験で確認する。
ドメイン① エージェント・アーキテクチャ＆オーケストレーション（~25–27%・最大）
クローズドブックで言語化すべき要点
- ワークフロー vs エージェント: タスクが予測可能で固定的ならワークフロー（プロンプトチェイン／ルーティング／並列化／orchestrator-workers／evaluator-optimizer）。経路が事前に決められない・モデルに動的判断を委ねたいならエージェント。最小限の複雑さから始め、必要になって初めて agentic にするのが大原則（複雑さはレイテンシ・コスト・デバッグ性を犠牲にする）。
- 代表パターン:
- プロンプトチェイン: タスクを順次サブタスクに分解（各段で検証ゲートを挟める）。
- ルーティング: 入力を分類し専門経路へ。分類が明確なときに有効。
- 並列化: sectioning（独立サブタスクを同時実行）／voting（同じタスクを複数回流して多数決・信頼性向上）。
- orchestrator-workers: 中央が動的にサブタスクを分割し worker に委譲、結果を統合。サブタスク数が事前に読めないとき。
- evaluator-optimizer: 生成→評価→改善のループ。明確な評価基準があり反復で質が上がるとき。
- サブエージェント＝コンテキスト分離: 親の文脈を汚さず専門タスクを別ウィンドウで回し、結論だけ返す。並列の独立調査・大量ファイル横断に効く。
- ガードレール／human-in-the-loop: 不可逆・外向きの行動の前に確認。自律ループには停止条件・最大反復・チェックポイントを置く。
設問 1-1
umaq の race-engine は「出走馬ごとの脚質推定 → ペース展開シミュレーション → 着順予測 → レポート整形」の固定された段階を毎回同じ順で通す。各段の中間結果は検証可能で、経路が入力で変わることはない。この構成として最も適切なのは？
- A. 自律エージェントに全権委譲し、ツール群から動的に手順を選ばせる
- B. プロンプトチェイン（各段を順次サブタスク化し、段間に検証ゲートを置く）
- C. voting（同一プロンプトを多数回流して多数決）
- D. orchestrator-workers で毎回サブタスク分割をモデルに決めさせる
答え
正解: B。経路が予測可能で固定なので、最小の複雑さ＝プロンプトチェインが正解。段間に検証ゲートを挟めるのも噛み合う。
- A は誤り: 経路が決まっているのに自律エージェントを使うのは過剰。レイテンシ・コスト・デバッグ性を無駄に損なう（「必要になって初めて agentic に」原則違反）。
- C は誤り: voting は信頼性目的で同じタスクを反復するパターン。段階の異なる順次処理には合わない。
- D は誤り: サブタスク数・内容が事前に確定しているのに動的分割は不要。orchestrator-workers は分割が読めないときの道具。
設問 1-2
レポート整形だけが他段より低品質で、品質基準（事実整合・読みやすさ・免責の明記）は明確に言語化できている。整形段の質を自動で底上げしたい。最適なパターンは？
- A. evaluator-optimizer（生成→基準で評価→フィードバックで再生成のループ）
- B. 並列 sectioning で同時に3案出して最初の1つを採用
- C. 温度を上げて多様性を出す
- D. システムプロンプトを長くして全ルールを列挙し一発生成
答え
正解: A。明確な評価基準があり反復で質が上がる典型 → evaluator-optimizer。
- B は誤り: sectioning は独立サブタスクの並列。同一タスクの質改善ではなく、しかも「最初の1つ採用」は評価が無く無意味。
- C は誤り: 温度は多様性を増すだけで品質基準への収束を保証しない。
- D は誤り: 一発生成は評価ループが無く、本番の壊れ方（特定段だけ低品質）を直さない。
設問 1-3
あるエージェントが「ツール呼び出し→結果待ち」を延々繰り返して停止せず、コストが膨らむ。アーキテクチャ上の正しい対処は？
- A. モデルをより大きいものに替える
- B. 停止条件・最大反復回数・チェックポイント（human-in-the-loop / 予算上限）を設計に入れる
- C. temperature を 0 にする
- D. ツールの説明文を消してツールを使えなくする
答え
正解: B。自律ループには明示的な停止条件・最大反復・予算/時間のガードレール・必要なら人手チェックポイントが必須。これが本番信頼性の核。
- A は誤り: モデル容量は無限ループの根本原因ではない。
- C は誤り: temperature は決定性に効くだけでループ停止を保証しない。
- D は誤り: ツールを奪うのは機能破壊で、設計上の停止制御ではない。
ドメイン③ Claude Code 設定・ワークフロー（~20%）
クローズドブックで言語化すべき要点
- 設定の層:
CLAUDE.md（プロジェクト/ユーザーの恒久指示・自動読込）／.claude/settings.json（権限・env・hooks）／.claude/agents/*.md（サブエージェント）／.claude/skills/（再利用可能な手順）／slash コマンド／MCP サーバ設定。「毎回 X して」のような自動挙動は hooks（ハーネスが実行する。memory/指示では実現しない）。 - 権限: allowlist で許可コマンドを絞る。permission mode（既定/受け入れ/計画）。不可逆・外向き操作は確認を挟む。
- コンテキスト管理: 長い会話は要約・サブエージェントで分離。CLAUDE.md は簡潔に（読み込みコスト）。スキル/エージェントへ委譲して親文脈を節約。
- サブエージェント: 専門役割＋専用ツール許可＋独立コンテキスト。結論を親へ返す。
- MCP: 外部ツール/データを Claude Code に接続。サーバごとに権限・スコープを管理。
設問 3-1
「コミット前に必ず lint と型チェックを走らせる」をチームの全 Claude Code セッションで自動的に徹底したい。正しい実装は？
- A. CLAUDE.md に「コミット前に lint してね」と書く
- B.
.claude/settings.jsonに PreToolUse/Stop 等の hook を設定し、ハーネスに lint・型チェックを実行させる - C. memory に「lint を忘れない」と保存する
- D. 毎回ユーザーが口頭で指示する
答え
正解: B。「毎回/必ず X する」という自動挙動はハーネスが実行する hook で実現する。これが設計上の正解。
- A/C は誤り: CLAUDE.md や memory は Claude への指示・背景であって、決定的な自動実行を保証しない（Claude が読み飛ばしうる）。
- D は誤り: 自動化要件を人手運用に落とすのは要件未達。
設問 3-2
巨大モノレポで「依存グラフの循環参照を全パッケージ横断で洗い出す」調査を、親セッションの文脈を汚さずに回したい。最適なのは？
- A. 親セッションで全ファイルを順に Read していく
- B. 専用サブエージェントに調査を委譲し、結論（循環の一覧）だけ親に返させる
- C. CLAUDE.md に全ファイルの内容を貼る
- D. 会話を一旦終了して新規セッションで手作業
答え
正解: B。広域の横断調査はサブエージェントでコンテキスト分離し、ファイルダンプでなく結論を返させるのが定石（親の文脈節約＋並列化可）。
- A は誤り: 親文脈が膨張し、肝心の作業の文脈を圧迫する。
- C は誤り: CLAUDE.md は恒久指示用で、巨大データの置き場ではない。
- D は誤り: 手作業化は委譲の放棄。
設問 3-3
あるサブエージェントに、リポジトリ全体を書き換えられる広い権限を与えていたが、本来は読取り＋検索だけで十分だった。是正の原則は？
- A. 権限はそのままにして注意書きを増やす
- B. 最小権限: そのエージェントのツール許可を read/search 系に絞る
- C. サブエージェントを廃止して全部親でやる
- D. permission mode を常に「全許可」にする
答え
正解: B。役割に対し最小権限を与えるのがエージェント設計の基本。読取り調査役に write を与えない。
- A は誤り: 注意書きは強制力が無い。
- C は誤り: 委譲の利点（分離・並列）を捨てる過剰反応。
- D は誤り: 真逆。被害範囲を広げる。
ドメイン② ツール設計＆MCP統合（18%）
クローズドブックで言語化すべき要点
- 良いツールスキーマ: 明確で曖昧さのない名前・説明、各引数の意味と形式、例、エラー時に何を返すか。モデルがゼロショットで正しく呼べる説明を書く（人間の新人に渡すつもりで）。曖昧な引数は enum や形式制約で poka-yoke（取り違え防止）。
- エラーハンドリング: ツールは例外を投げて落とすのでなく、モデルが回復行動を取れるエラーメッセージを返す（何が悪く、どう直すか）。
- トークン効率: 結果は必要十分に。巨大な生レスポンスでなく整形・要約・ページングで文脈を食い潰さない。
- MCP の3プリミティブ: tools（モデルが呼ぶ動作）／resources（読めるデータ）／prompts（再利用テンプレ）。
- トランスポート: stdio（ローカル）／Streamable HTTP（リモート。単一エンドポイントへの POST＋必要に応じて SSE でストリーミング応答にアップグレード）。単体の HTTP+SSE トランスポート（
/sseと/messagesの2エンドポイント構成）は2025年3月の仕様改定で非推奨化済みで、現在は後方互換のためだけに残る。スコープと認証はサーバ単位で。
設問 2-1
あるツール get_data は失敗時に未捕捉例外でプロセスごと落ち、モデルが次の手を打てない。正しい設計は？
- A. 例外をそのまま投げ続ける（モデルが気づくべき）
- B. 「何が失敗し、どう直せるか」を記した構造化エラーを正常な戻り値として返す
- C. 失敗時は空文字を返して握りつぶす
- D. 失敗したらランダムなダミーデータを返す
答え
正解: B。ツールはモデルが回復行動を取れるエラーを返すべき。原因＋是正のヒントを含める。
- A は誤り: 落ちるとモデルは回復不能。
- C は誤り: サイレント失敗は最悪。誤った前提で先へ進む（silent failure）。
- D は誤り: 捏造データは下流を汚染する重大バグ。
設問 2-2
ツール convert(unit) で unit の取り違え（"kg" vs "kilogram" vs "KG"）が頻発し誤変換が出る。スキーマ設計の最善手は？
- A. 説明文に「気をつけて」と書く
- B.
unitを enum（許容値の固定集合）にし、説明に各値の意味を明記する - C. 引数を自由記述のままにしてモデルの賢さに任せる
- D. ツールを2つに分けてどちらか呼ばせる
答え
正解: B。曖昧さは型・enum・形式制約で構造的に潰す（poka-yoke）。許容値を固定すれば取り違えは起きない。
- A は誤り: 注意書きは強制力が弱い。
- C は誤り: 自由記述は今のバグの原因そのもの。
- D は誤り: 分割は根本（値の曖昧さ）を解決しない。
設問 2-3
社内ドキュメント群を Claude に読ませたい（モデルが任意に呼ぶ動作ではなく、参照可能なデータとして）。MCP でのモデリングは？
- A. すべて tools として実装する
- B. resources として公開する（読めるデータ）。動作が要るものだけ tools に
- C. prompts に全文を貼る
- D. MCP では不可能なので諦める
答え
正解: B。MCP の resources は「読めるデータ」を表すプリミティブ。参照データは resources、能動的な動作は tools、再利用テンプレは prompts と役割が分かれる。
- A は誤り: 参照データを無理に tools 化するのは設計の取り違え。
- C は誤り: prompts はテンプレ用途で大量データ置き場ではない。
- D は誤り: 事実誤認。MCP の中心的ユースケース。
ドメイン④ プロンプトエンジニアリング＆構造化出力（~20%）
クローズドブックで言語化すべき要点
- 構造化（XML タグ）: 指示・入力・例・出力フォーマットを
<...>で区切ると Claude が解釈しやすい。 - 役割分担: system プロンプト＝役割/恒久制約、user＝タスク/入力。
- few-shot: 期待する入出力の例を数件示すと精度・形式が安定。
- 構造化出力（厳密な JSON）: 信頼できる JSON が要るなら、ネイティブの Structured Outputs 機能（または
strict: trueのツール使用）でスキーマを強制するのが最も堅い。prefill（応答を{で始めさせる）は extended thinking と併用できない上、最新モデルでは API から廃止されエラーになるため非推奨。「JSON で返して」と頼むだけより、スキーマ強制が確実。 - extended thinking: 難しい推論は拡張思考で質が上がる（が、レイテンシ/コスト増。要否を判断）。
- プロンプトキャッシュ: 長い不変の前置き（システム/ドキュメント）はキャッシュしてコスト・レイテンシ削減（→ ドメイン⑤）。
設問 4-1
zenq のあるエンドポイントが Claude の出力を JSON.parse しているが、たまに前置きの散文や ```json フェンスが混ざり parse 落ちする。最も堅い対処は？
- A. 「絶対に JSON だけ返して」と強く頼む
- B. 出力スキーマを定義し、ツール使用（structured output / tool calling）で JSON を強制する
- C. 正規表現で散文を後から剥がす
- D. temperature を上げる
答え
正解: B。厳密な構造化出力が要るなら、ネイティブの Structured Outputs 機能（または strict: true のツール使用）でスキーマを強制するのが最堅。prefill（{ 始まり）は最新モデルでは API から廃止され使えないため非推奨。
- A は誤り: 自然言語の依頼だけでは混入を完全には防げない（現に落ちている）。
- C は誤り: 後処理は対症療法で、形式が崩れる根本を直さない。
- D は誤り: 温度上げは形式の安定性をむしろ損なう。
設問 4-2
分類タスクの出力ゆれ（ラベル表記の不統一）を減らしたい。最小コストで効く一手は？
- A. few-shot で期待する入出力例を数件示し、ラベルは enum 的に固定提示する
- B. モデルを最大サイズに変える
- C. システムプロンプトを 5,000 語に増やす
- D. 毎回 voting を 9 回流す
答え
正解: A。few-shot の少数例は形式・表記の安定に最も費用対効果が高い。許容ラベルを明示するのも効く。
- B は誤り: サイズ増は表記ゆれの直接対処ではなくコスト過多。
- C は誤り: 冗長な system は逆効果になりうる。
- D は誤り: voting は信頼性目的でコスト9倍。表記統一には過剰。
設問 4-3
複雑な多段推論問題で初手の精度が低い。質を上げる適切な手段と、その代償の理解は？
- A. extended thinking を有効化する（代償: レイテンシ・コスト増を許容できる箇所に限る）
- B. temperature を 1.5 にする
- C. ツールを全部外す
- D. 出力を短く制限する
答え
正解: A。難しい推論は拡張思考で質が上がる。ただしレイテンシ・コスト増という代償を理解し、効く箇所に絞って使うのが設計判断（CCA はこの「トレードオフを言える」かを問う）。
- B は誤り: 高温は推論の安定を損なう。
- C は誤り: ツール除去は推論精度の手段でない。
- D は誤り: 出力制限は思考余地を奪い逆効果になりうる。
ドメイン⑤ コンテキスト管理＆信頼性（~15%）
クローズドブックで言語化すべき要点
- プロンプトキャッシュ: 長く不変の前置き（システム指示・大きな参照ドキュメント・few-shot 群）をキャッシュすると、繰り返し呼び出しのコスト・レイテンシを大幅削減。可変部分は末尾に置く。
- コンテキスト窓の使い方: 全部を詰め込まず、関連情報だけを入れる（RAG／retrieval）。contextual retrievalでチャンクに文脈を付与すると検索精度が上がる。長い会話は要約・サブエージェントで分離。
- 信頼性パターン: 一時的失敗には指数バックオフ付きリトライ。レート制限を尊重（429）。大量・非同期で良い処理は Batch API（安価・高スループット、即時性は捨てる）。冪等性で二重実行を防ぐ。
- ストリーミング: 体感レイテンシ改善・長応答のタイムアウト回避。
- 可観測性: ログ・トレースで失敗を可視化し、サイレント失敗を作らない。
設問 5-1
kabu の TDnet 分析は、毎回同じ長い分析指示＋固定の評価ルーブリックを前置きし、可変の開示テキストだけ差し替えて多数回 Claude を呼ぶ。コストとレイテンシを下げる最善手は？
- A. 不変の前置き（指示＋ルーブリック）をプロンプトキャッシュし、可変の開示本文を末尾に置く
- B. 毎回モデルを小さくする
- C. 指示を毎回少しずつ削る
- D. リクエストを1つにまとめて巨大プロンプトで一括処理
答え
正解: A。不変・長い前置きはプロンプトキャッシュの理想的対象。可変部を末尾に置くのがコツ。繰り返し呼び出しでコスト/レイテンシが大きく下がる。
- B は誤り: 品質を犠牲にしうるしキャッシュ効果に比べ筋が悪い。
- C は誤り: 指示削りは品質低下リスク。
- D は誤り: 巨大一括は文脈窓・可観測性・部分失敗の扱いで不利。
設問 5-2
即時性の要らない数万件の一括分類を、できるだけ安く高スループットで回したい。正しい選択は？
- A. 同期 API を for ループで叩く
- B. Batch API を使う（安価・高スループット、即時性を捨てる）
- C. レート制限を無視して並列を最大化
- D. 1リクエストに全件を詰める
答え
正解: B。即時性不要・大量は Batch API の典型ユースケース（コスト減・高スループット）。
- A は誤り: 同期ループは遅く高コスト、レート制限に当たる。
- C は誤り: 429 を招きむしろ遅延・失敗増。
- D は誤り: 文脈窓と部分失敗の観点で破綻。
設問 5-3
本番で散発的に 429（レート制限）と一時的 5xx が出てジョブが落ちる。信頼性設計の正解は？
- A. すぐ同じ間隔で無限リトライ
- B. 指数バックオフ（＋ジッター）付きリトライ、429 の Retry-After を尊重、冪等性で二重実行を防ぐ
- C. エラーを握りつぶして次へ進む
- D. 失敗したらユーザーに毎回手動再実行させる
答え
正解: B。一時的失敗には指数バックオフ＋ジッター、レート制限ヘッダの尊重、再試行時の冪等性確保が定石。
- A は誤り: 即時等間隔リトライは輻輳を悪化させる。
- C は誤り: サイレント失敗で結果欠損が見えなくなる。
- D は誤り: 自動回復すべきものを手作業に落とすのは信頼性設計の放棄。
仕上げ: 自己診断ルーブリック
各ドメインで「選択肢を選べる」だけでなく「なぜ正解か・なぜ他が誤りかを 30 秒で口頭説明できる」かを ✓ / △ / ✗ で記録する。✗ と △ を competency-map の「次の一手」に転記し、3→4 へ。
| ドメイン | 選べる | 根拠を言語化できる | 次の一手 |
|---|---|---|---|
| ① エージェント・アーキ＆オーケストレーション | ワークフロー6パターンの使い分けを umaq/workflow の実例で説明 | ||
| ② Claude Code 設定・ワークフロー | hook vs CLAUDE.md vs memory の役割境界を言語化 | ||
| ③ ツール設計＆MCP | tools/resources/prompts の振り分けと poka-yoke 設計 | ||
| ④ プロンプト＆構造化出力 | 「JSON 強制＝ツール使用」と few-shot/extended thinking のトレードオフ | ||
| ⑤ コンテキスト管理＆信頼性 | キャッシュ対象の見極めと retry/batch/冪等の本番パターン |