要旨
本稿は、Anthropicが提供する設計者向け認定資格 Claude Certified Architect – Foundations（略称 CCA-F、CCAR-F とも） の合格に向けて、出題範囲・暗記事項・設計判断の要点を学術論文の形式で網羅的に整理した学習リファレンスである。本試験は「実運用のソリューションをClaudeで構築する際のトレードオフについて、根拠を持って判断できること」を検証する、シナリオ型・監督付き・クローズドブックの試験である。試験は英語のみで提供され、本番中の翻訳ツール利用は認められない。したがって、概念の理解を日本語で行いつつ、英語の専門用語（terminology）を確実に対応づけて記憶することが得点に直結する。
本稿では、まず試験のメタ情報（形式・受験資格・配点）を確定し、続いて5つの出題ドメインを個別に詳解する。各ドメインでは、(1) 概念解説、(2) 暗記ポイント（英日用語の対訳表）、(3) 学習用に自作したシナリオ型の練習問題と解説、の3点セットを提示する。なお、実際の試験問題は非公開かつ監督下で出題されるため、本稿は「本物の過去問」を転載しない。掲載する練習問題はすべて公式の出題範囲に沿って新規に作成した学習用の例題である。事実関係は公式ドキュメントを一次ソースとして裏取りし、検証しきれない事項は「要確認」と明示した。
1. 序論：本資格の位置づけと本稿の目的
1.1 背景
CCA-Fは、フロンティアAI企業であるAnthropicが公開した設計者向けの正式な認定である。プログラムは近年に開始され、2026年6月30日以降、試験の配信はPearson VUE、デジタルバッジの発行はCredlyに移行した（受験料も改定された。詳細は第2章）。対策用の学習は主にSkilljar上のAnthropic Academyで提供される。
本資格が対象とするのは、Claudeを用いて現実の課題を解決する「ソリューション・アーキテクト」である。単なる暗記ではなく、「この状況ではどの構成を選ぶべきか」という設計判断（tradeoffs）を問うのが本試験の特徴であり、すべての問題は具体的な本番シナリオ（production scenario）を提示したうえで最適な設計を選ばせる形式を取る。
1.2 技術の4本柱
出題は、次の4つの技術領域を土台とする。
- Claude API … Messages APIを中心とした基盤。tool use、structured output、prompt caching、token countingなどはすべてこの単一エンドポイント上の機能である。
- Claude Agent SDK … Claude Codeをライブラリ化した「バッテリー同梱型」のエージェント基盤（旧Claude Code SDK）。
- Claude Code … CLAUDE.md・hooks・skills・subagents・MCP設定などによる、AIファーストの開発ワークフロー基盤。
- MCP（Model Context Protocol） … AIとツールを接続するオープン標準。tools/resources/promptsという3種のプリミティブを持つ。
これら4本柱が、後述の5ドメインに横断的に分布する。
1.3 本稿の使い方と出典方針
本稿は日本語を主体としつつ、試験が英語であることを踏まえ、重要用語は英語を併記した。各ドメイン末尾の「暗記ポイント」は英日対訳表であり、そのまま単語帳として使える。
出典は、Anthropicの認定FAQ、Pearson VUEの公式試験ページ、研究記事「Building Effective Agents」、および platform.claude.com / code.claude.com の公式ドキュメントを一次ソースとした。ドメインの配点や細目の一部は、公式Exam Guideおよびコミュニティの学習資料の突き合わせに基づくため、受験前には必ず最新の公式Exam Guideで最終確認されたい。
2. 試験の全体像（メタ情報）
設計判断そのものより先に、まず「試験の器」を数値で押さえる。ここは配点に関わらず落とせない前提知識である。
2.1 試験形式（暗記必須の数値）
| 項目 | 値 |
|---|---|
| 問題形式 | シナリオ型・多肢選択（scenario-based multiple choice） |
| 問題数 | 60問 |
| シナリオ構成 | 6シナリオ中4シナリオを出題、各シナリオ15問（15×4＝60） |
| 制限時間 | 120分（1問あたり約2分） |
| 合格点 | 1000点満点中 720点（スケールドスコア100〜1000） |
| 受験環境 | 監督付き（proctored）・クローズドブック・AI利用禁止 |
| 配信 | Pearson VUE（オンライン監督 OnVUE またはテストセンター）※2026年6月30日移行 |
| バッジ | Credly（デジタルバッジ） |
| 受験料 | 125 USD（2026年6月30日に99→125 USDへ改定） |
| 再受験 | ローリング12か月で最大4回。待機期間は14日、30日、90日と段階的に延伸 |
| 言語 | 英語のみ（日本語版なし。本番中の翻訳不可） |
2.2 受験資格（重要な前提）
公式FAQによれば、認定は現在 Claude Partner Network 加盟組織のみ を対象とし、登録には 認識済みの会社ドメインのパートナー用メールアドレス が必要である。個人のフリーメール（Gmail等）では登録できない。加盟自体は無料で、加盟すると認定へのアクセスが付与される仕組みである。まず会社ドメインのメールで無料加盟し、そのうえで受験料を決済してPearson VUEで日程を予約する、という順序になる。
2.3 出題ドメインと配点
| # | ドメイン | 配点 | 中心となる技術 |
|---|---|---|---|
| D1 | Agentic Architecture & Orchestration | 27% | Agent SDK、マルチエージェント |
| D2 | Tool Design & MCP Integration | 18% | MCP、tool use |
| D3 | Claude Code Configuration & Workflows | 20% | Claude Code |
| D4 | Prompt Engineering & Structured Output | 20% | Claude API |
| D5 | Context Management & Reliability | 15% | Claude API |
配点の合計は100%。最大領域はD1（27%）であり、エージェント設計とオーケストレーションが最重要である。以下、各ドメインを詳解する。
3. ドメイン別詳解
3.1 D1：Agentic Architecture & Orchestration（27%）
概念解説
このドメインの根幹は、Anthropicの研究記事「Building Effective Agents」の枠組みである。まず次の定義を厳密に区別する。
- Workflow（ワークフロー） … 「LLMとツールが、あらかじめ定義されたコードパスを通じてオーケストレーションされるシステム」。手順が予測可能で一貫性が求められる場合に用いる。
- Agent（エージェント） … 「LLMが自らのプロセスとツール利用を動的に指揮し、タスクの達成方法を自身で制御するシステム」。ステップ数を事前に予測できない open-ended な問題に用いる。
両者の土台は Augmented LLM（拡張されたLLM＝検索・ツール・メモリを備えたLLM）である。
5つのワークフローパターンを、適用場面とともに暗記する。
| パターン | 一言でいうと |
|---|---|
| Prompt chaining | タスクを逐次ステップに分解し、各LLM呼び出しが前の出力を処理する |
| Routing | 入力を分類し、専門化された下流タスクへ振り分ける |
| Parallelization | 独立サブタスクに分割（sectioning）、または同一タスクを複数回実行（voting） |
| Orchestrator-workers | 中央LLMがタスクを動的に分解しワーカーに委譲、結果を統合する |
| Evaluator-optimizer | 一方のLLMが生成し、もう一方が評価とフィードバックを反復する |
設計の指針となる 3つの中核原則 は次の通り。
- Simplicity（シンプルさ） … 最も高度な構成ではなく、必要十分な構成を作る。「まず単純なプロンプトから始め、評価で最適化し、単純な解では不足するときにのみ多段のエージェント構成を追加する」。
- Transparency（透明性） … エージェントの計画ステップを明示的に見せる。
- ACI（Agent-Computer Interface） … 丁寧なツールのドキュメント化とテストで、エージェントとツールの接点を設計する。
さらに、「エージェントを構築する4つの方式」は、ハーネス（agent loop）とデプロイの担い手で区別する。
| 方式 | 自分で書くもの | ハーネスとデプロイ | 使いどころ |
|---|---|---|---|
| Claude API 手動ループ | while stop_reason == "tool_use" を自作 |
ハーネスもデプロイも自分 | ループ全体を完全に自作したい |
| Claude API Tool Runner | ツール関数のみ | ハーネスはSDK、デプロイは自分 | 自作ツールのエージェントをループ自作なしで |
| Managed Agents | エージェント設定とツール結果 | ハーネスもデプロイもAnthropic（セッションごとにサンドボックス） | ループとサンドボックスを任せたい |
| Claude Agent SDK | プロンプトとオプション | Claude Codeハーネス＋組み込みツール、デプロイは自分 | 全部入りのコーディング/ファイルエージェント |
注意すべき紛らわしさとして、Tool Runner と Claude Agent SDK は別物である。Tool Runnerは通常のAnthropic SDKの一機能（client.beta.messages.tool_runner）で、あなたが定義したツールだけをループする。Claude Agent SDKはClaude Codeをライブラリ化した別パッケージで、組み込みのRead/Write/Edit/Bash等を持つ。両者とも「ハーネスのみ（デプロイは自分）」であり、マネージドなデプロイを足すのがManaged Agentsである。
コスト最適化の文脈では Batch API（非同期・標準価格の50%）も押さえる。レイテンシ非依存の大量処理に適し、結果は投入順ではなく custom_id で突き合わせる。
暗記ポイント（英日対訳）
| English term | 日本語 | 一言メモ |
|---|---|---|
| Workflow | ワークフロー | 定義済みコードパス。予測可能な手順 |
| Agent | エージェント | LLMが自律的に制御。open-endedな課題 |
| Augmented LLM | 拡張LLM | 検索・ツール・メモリを備える基盤 |
| Prompt chaining | プロンプト連鎖 | 逐次分解、前段出力を次段へ |
| Routing | ルーティング | 分類して専門タスクへ振り分け |
| Parallelization | 並列化 | sectioning（分割）／voting（多数決） |
| Orchestrator-workers | オーケストレータ・ワーカー | 中央が分解・委譲・統合 |
| Evaluator-optimizer | 評価・最適化 | 生成と評価を反復 |
| Simplicity / Transparency / ACI | 3原則 | シンプル・透明・ツール接点設計 |
| Tool Runner | ツールランナー | SDKがループ、自作ツールのみ |
| Claude Agent SDK | エージェントSDK | Claude Codeのライブラリ、組み込みツール |
| Managed Agents | マネージドエージェント | Anthropicがループとサンドボックスを運用 |
| Batch API | バッチAPI | 非同期・50%コスト・custom_idで照合 |
練習問題（学習用の自作例題）
D1-Q1. サポートチケットを内容で分類し、それぞれ専門の処理系（返金・技術・一般）へ渡す。手順は予測可能で毎回ほぼ同じである。最も適切なパターンはどれか。
- A. Orchestrator-workers
- B. Routing
- C. Evaluator-optimizer
- D. 自律エージェント
正解：B（Routing）。 入力を分類して専門下流へ振り分ける典型例。手順が予測可能なのでworkflowで足り、自律エージェント（D）は過剰。Aは「動的にタスクを分解」する場合に使うが本件は分解不要。Cは生成物を反復評価する用途で不一致。
D1-Q2. あるチームが、ステップ数を事前に決められない探索的なコード修正タスクを自動化したい。設計方針として最も適切なものはどれか。
- A. まず単一のLLM呼び出しと評価から始め、不足するときにのみエージェント化する
- B. 最初から最大限に高度なマルチエージェント構成を組む
- C. すべてのツールをbash一本に集約し可読性より柔軟性を優先する
- D. 透明性より速度を優先し計画ステップは隠す
正解：A。 「シンプルさ」の原則そのもの。open-endedなのでいずれエージェント化はあり得るが、まず単純解から始めるのが正道。Bは原則違反、Cはツール設計（ACI）の観点で誤り、Dは透明性の原則に反する。
3.2 D2：Tool Design & MCP Integration（18%）
概念解説
MCP（Model Context Protocol） は、AIとツール・データソースを接続するオープン標準である。MCPサーバは3種の プリミティブ を公開する。
- Tools … モデルが呼び出せる機能（副作用を伴い得る）。
- Resources … モデルが読み取れるデータ（
@で参照）。 - Prompts … 定型のプロンプト（Claude Codeではスラッシュコマンドとして表面化する）。
ツール定義 の基本は name・description・input_schema（JSON Schema）である。description は「何をするか」だけでなく「いつ呼ぶか（when to call）」を明記すると、ツール選択の精度が上がる。tool_choice は auto（既定）・any（最低1つ使う）・tool（特定ツール強制）・none（不使用）から選ぶ。
サーバ側ツール vs クライアント側ツール の区別も重要である。web search / web fetch / code execution はAnthropic基盤で実行される server-side tool、bash / text editor / computer use はスキーマだけAnthropic定義でユーザ側が実行する client-side tool である。
Claude API から直接リモートMCPサーバに接続する MCPコネクタ では、mcp_servers（接続定義）と tools 内の mcp_toolset（サーバ名参照）の 両方 が必須で、片方だけだと検証エラーになる（beta mcp-client-2025-11-20）。Managed Agentsの場合、MCPの認証情報はエージェント定義ではなく vault に置き、セッションに vault_ids で結び付ける（秘密情報をサンドボックスに露出させない）。
Claude Code側のMCPは、スコープ（local / project（.mcp.json）/ user）と トランスポート（stdio / SSE / HTTP）を押さえる。MCPツールは mcp__<server>__<tool> という命名で表面化し、hooksのmatcherでは mcp__memory__.* のように参照する。
暗記ポイント（英日対訳）
| English term | 日本語 | 一言メモ |
|---|---|---|
| MCP primitives | MCPプリミティブ | tools / resources / prompts の3種 |
| input_schema | 入力スキーマ | ツール引数のJSON Schema |
| tool_choice | ツール選択 | auto / any / tool / none |
| server-side tool | サーバ側ツール | web search・fetch・code exec（Anthropic実行） |
| client-side tool | クライアント側ツール | bash・text editor（ユーザ実行） |
| MCP connector | MCPコネクタ | mcp_servers＋mcp_toolset を両方指定 |
| mcp_toolset | MCPツールセット | サーバ名でツール群を参照 |
| vault | ボールト | MCP認証情報の保管、vault_idsで付与 |
| scope（local/project/user） | スコープ | project は .mcp.json |
| transport（stdio/SSE/HTTP） | トランスポート | 接続方式 |
mcp__server__tool |
MCPツール命名 | matcherは .* を付ける |
練習問題（学習用の自作例題）
D2-Q1. MCPサーバがモデルに公開できる3種類のプリミティブの組み合わせとして正しいものはどれか。
- A. tools / resources / prompts
- B. functions / files / memories
- C. commands / hooks / skills
- D. actions / documents / templates
正解：A。 MCPの3プリミティブは tools・resources・prompts。resourcesは読み取りデータ、promptsは定型プロンプトである。
D2-Q2. Messages API のMCPコネクタで、開発者が mcp_servers だけを指定したところ検証エラーになった。正しい対処はどれか。
- A.
toolsに{"type":"mcp_toolset","mcp_server_name": …}を追加し、対応するbetaを付ける - B.
mcp_serversを削除しツールをすべてbashに置き換える - C.
tool_choiceをnoneに設定する - D. サーバ側で
resourcesを無効化する
正解：A。 MCPコネクタは mcp_servers と mcp_toolset の両方が必要。各サーバは必ず1つのtoolsetから参照されなければならない。B・C・Dはいずれも接続の必須要件を満たさない。
3.3 D3：Claude Code Configuration & Workflows（20%）
概念解説
CLAUDE.md の階層と読み込み順 が最重要である。スコープは広い順に次の4層で、すべて上書きではなく 連結（concatenate） して文脈に載る。
| スコープ | 場所 | 用途 |
|---|---|---|
| Managed policy（組織） | macOS /Library/Application Support/ClaudeCode/CLAUDE.md ほかOS別の固定パス |
組織全体の方針。個人設定で除外不可 |
| User（個人） | ~/.claude/CLAUDE.md |
全プロジェクト共通の個人設定 |
| Project（プロジェクト） | ./CLAUDE.md または ./.claude/CLAUDE.md |
チーム共有。バージョン管理に載せる |
| Local（個人・プロジェクト） | ./CLAUDE.local.md |
個人のプロジェクト設定（.gitignore） |
補助機構として、@path によるインポート（最大4ホップ）、.claude/rules/（paths フロントマターでファイル種別にスコープ可能）、そして auto memory（MEMORY.md） がある。MEMORY.mdは冒頭200行または25KBまでがセッション開始時に読み込まれる。
決定的に重要な設計判断は、「CLAUDE.md は文脈であって強制ではない」 ことである。特定の危険な操作を必ず阻止したいなら、CLAUDE.mdの指示ではなく PreToolUse フック を使う。ハード強制（ツールやコマンドの禁止）はmanaged settingsの permissions.deny で行う。
Hooks はライフサイクルの各時点で走るシェルコマンド等で、settings.json に定義する。主要イベントは、PreToolUse（ツール実行前・ブロック可）、PostToolUse（実行後・出力改変可）、UserPromptSubmit（プロンプト処理前・ブロック可）、SessionStart、Stop、SubagentStop、PreCompact、Notification、SessionEnd 等。PreToolUseでブロックする方法 は、(1) 終了コード exit 2（stderrがエラーメッセージになる）か、(2) exit 0 でJSON出力し permissionDecision を deny（他に allow・ask・defer）にする、の2通り。matcherはツール名（Bash、Edit|Write）やMCPツール（mcp__memory__.*）を指定する。
Slash commands と Skills は統合された。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md はどちらも /deploy を作る。Skillは本文が必要時のみ読み込まれるため、長い手順を常時コンテキストに載せずに済む。フロントマターで allowed-tools・argument-hint・description・model・呼び出し主体（誰が起動するか）を制御し、$ARGUMENTS で引数を受ける。
Subagents は .claude/agents/（プロジェクト）や ~/.claude/agents/（個人）に定義し、独立したコンテキストウィンドウ・独自のシステムプロンプト・限定したツール・独自モデルを持つ。探索やログの読み込みなど「本筋の会話を汚したくない副作業」を隔離コンテキストで処理し、要約だけ返す。Haiku等の安価なモデルへルーティングしてコストを抑える用途にも使う。
CI/自動化では、claude -p（print/ヘッドレスモード）や --output-format、GitHub Actions連携で非対話実行する。settings.json の層 は user（~/.claude/settings.json）・project（.claude/settings.json）・local（.claude/settings.local.json）・managed policy で、permissions の allow / deny / ask を制御する。
関連する社内ノウハウは Claude Code完全ガイド でも扱っている。
暗記ポイント（英日対訳）
| English term | 日本語 | 一言メモ |
|---|---|---|
| Managed policy CLAUDE.md | 管理ポリシー | 組織固定パス。除外不可 |
~/.claude/CLAUDE.md |
ユーザ設定 | 全プロジェクト共通 |
./CLAUDE.md / ./.claude/CLAUDE.md |
プロジェクト設定 | チーム共有 |
CLAUDE.local.md |
ローカル設定 | 個人・gitignore |
@path import |
インポート | 最大4ホップ |
.claude/rules/ |
ルール | paths でファイル種別スコープ |
| auto memory / MEMORY.md | 自動メモリ | 先頭200行・25KBを読み込み |
| PreToolUse hook | 事前フック | exit 2 か JSON deny でブロック |
| permissions.deny | 権限拒否 | ハード強制はここ |
| Skill / slash command | スキル／コマンド | .claude/commands と .claude/skills は統合 |
| Subagent | サブエージェント | 隔離コンテキスト、要約を返す |
headless（claude -p） |
ヘッドレス | CI・非対話実行 |
練習問題（学習用の自作例題）
D3-Q1. 特定の破壊的なbashコマンドを、Claudeの判断に関わらず必ず実行させたくない。最も確実な手段はどれか。
- A. CLAUDE.mdに「このコマンドは実行禁止」と書く
- B. PreToolUseフック（またはmanaged settingsの
permissions.deny）で拒否する - C. Skillのフロントマターに注意書きを追加する
- D. auto memory に禁止事項を保存する
正解：B。 CLAUDE.mdやメモリは「文脈」であり強制力を持たない。必ず阻止したいならPreToolUseフック（exit 2 またはJSON deny）か permissions.deny を使う。A・C・Dはいずれも守られる保証がない。
D3-Q2. 組織全体に適用し、個人設定では除外できないコーディング標準をClaude Codeに持たせたい。適切な配置はどれか。
- A. 各開発者の
~/.claude/CLAUDE.md - B. プロジェクトの
./CLAUDE.local.md - C. Managed policy の CLAUDE.md（組織固定パス）
- D. 会話中に毎回貼り付ける
正解：C。 Managed policyのCLAUDE.mdは組織固定パスに置かれ、個人設定で除外できない。Aは個人スコープ、Bはgitignore対象の個人設定、Dは持続しない。
3.4 D4：Prompt Engineering & Structured Output（20%）
概念解説
現行モデル（Claude Opus 4.8、Sonnet 5、Haiku 4.5、Fable 5）を前提に、プロンプト設計と構造化出力の要点を押さえる。
構造化出力（Structured Outputs） は独立したAPIではなく、Messages APIの機能である。応答形式は output_config.format（json_schema）で制約し、ツール引数は strict: true で検証する。推奨は client.messages.parse() でスキーマ検証を自動化する方法である。なお、旧来の output_format パラメータは非推奨で、output_config.format を使う。
重要な破壊的変更：現行モデルでは、最終アシスタントターンの prefill（プレフィル）が400エラー になる。「JSONを強制するために {"role":"assistant","content":"{"} を置く」古い手法は使えない。代替は次の対応表の通り。
| prefillの用途 | 代替 |
|---|---|
| JSON/スキーマ強制 | output_config.format（json_schema） |
| 分類ラベル強制 | enumを持つツール、または構造化出力 |
| 前置き（preamble）除去 | システムプロンプトで「前置きなしで直接答える」と指示 |
Strict tool use は、ツール定義に strict: true を置き（tool_choice ではない）、スキーマに additionalProperties: false と required を備える。これで tool_use.input がスキーマに完全一致することが保証される。JSON Schemaの制約には限界があり、数値制約（minimum/maximum）や文字数制約（minLength/maxLength）、再帰スキーマは非対応である点も要注意。
プロンプト工学の基本要素として、system prompt、few-shot（少数例）、XMLタグによる入力の構造化、思考の誘導（現行モデルは thinking: {type:"adaptive"} と output_config.effort で制御し、旧来の budget_tokens は400になる）を押さえる。「プログラム的な強制」（strict / json_schema）と「プロンプトによる誘導」の使い分けが設計判断の核である。確実性が要るならスキーマで強制し、柔軟性が要るならプロンプトで誘導する。
暗記ポイント（英日対訳）
| English term | 日本語 | 一言メモ |
|---|---|---|
| Structured outputs | 構造化出力 | Messages APIの機能 |
output_config.format |
出力フォーマット | json_schema。旧 output_format は非推奨 |
messages.parse() |
パース | スキーマ検証を自動化（推奨） |
| Prefill（廃止） | プレフィル | 最終assistantターンは400 |
strict: true |
厳格ツール | additionalProperties:false＋required |
tool_choice |
ツール選択 | strictはここではなくツール定義側 |
| few-shot | 少数例 | 例示で挙動を誘導 |
| XML tags | XMLタグ | 入力の構造化 |
| adaptive thinking / effort | 適応思考／努力度 | budget_tokensは廃止（400） |
| programmatic vs prompt-based | 強制 vs 誘導 | 確実性か柔軟性かで選ぶ |
練習問題（学習用の自作例題）
D4-Q1. 開発者が Claude Opus 4.8 で、JSON出力を強制するために最終アシスタントターンに {"role":"assistant","content":"{"} を置いたところ400エラーになった。正しい対処はどれか。
- A.
output_config.formatにjson_schemaを指定する（またはmessages.parse()／strictツールを使う） - B.
temperatureを0にする - C.
budget_tokensを増やす - D. モデルを旧世代に戻す
正解：A。 現行モデルは最終ターンのprefillが400。構造化出力（output_config.format）やstrictツールで代替する。Bは無関係、Cは廃止パラメータ、Dは設計上の後退で不適切。
D4-Q2. ツールの入力が必ずスキーマに完全一致することを保証したい。正しい設定はどれか。
- A.
tool_choiceにstrict: trueを付ける - B. ツール定義に
strict: trueを置き、スキーマにadditionalProperties:falseとrequiredを備える - C. system promptに「必ず正しいJSONを出せ」と書くだけ
- D.
output_config.effortをmaxにする
正解：B。 strict tool use はツール定義側に strict:true を置き、additionalProperties:false＋required が必要。Aは配置が誤り、Cは強制にならず、Dは思考の深さの制御で無関係。
3.5 D5：Context Management & Reliability（15%）
概念解説
長時間・大規模な対話における文脈管理と信頼性がテーマである。まず前提として、Messages APIはステートレス であり、毎回の呼び出しで会話履歴の全体を送る。
Prompt caching（プロンプトキャッシュ） は「プレフィックス一致（prefix match）」で機能する。プレフィックスのどこか1バイトでも変わると、それ以降のキャッシュはすべて無効化される。レンダー順は tools → system → messages。したがって、安定した内容（凍結したシステムプロンプト、決定的なツール順）を前に、変動する内容（タイムスタンプ、リクエストID、可変の質問）を最後のブレークポイントより後に置く。cache_control: {type:"ephemeral"} を用い、ブレークポイントは最大4つ、キャッシュ可能な最小プレフィックスはモデル依存（おおむね1024〜4096トークン）。効果は usage.cache_read_input_tokens で検証し、繰り返しても0なら サイレントな無効化要因（システムプロンプト内の datetime.now()、未ソートのJSON、可変のツール集合など）を疑う。
長い会話への2つの対処を区別する。
- Compaction（コンパクション） … 文脈が上限に近づくと、過去の文脈をサーバ側で 要約 する（beta
compact-2026-01-12）。応答はresponse.contentを 丸ごと 追記して返す必要がある（テキストだけ抜くとコンパクション状態を失う）。 - Context editing（コンテキスト編集） … 古いツール結果や思考ブロックを 削除（prune） する（要約ではない。
clear_tool_uses_20250919など）。
トークン数の計測 は count_tokens エンドポイントを使う。tiktoken はOpenAI用でClaudeを15〜20%過小評価するため使わない。
信頼性パターンとして、stop_reason の網羅的なハンドリング（end_turn / max_tokens / tool_use / pause_turn / refusal）、リトライ（SDKは429・5xxを指数バックオフで自動再試行）、そして Fable 5 では refusal fallback（分類器が拒否した場合に別モデルへ退避する fallbacks パラメータ、beta server-side-fallback-2026-06-01）を押さえる。サーバ側ツールが反復上限に達すると pause_turn になり、そのまま再送すると続きから再開する。
なお、第三者の学習資料に登場する「CALM framework」という語は、公式ドキュメントで確認できなかった。コミュニティの記憶術（mnemonic）の可能性があり、本稿では公式用語として扱わない（要確認）。試験対策としては、上記の公式概念（prefix caching・compaction・context editing・token budgeting・stop_reason）を正確に押さえることを優先する。
暗記ポイント（英日対訳）
| English term | 日本語 | 一言メモ |
|---|---|---|
| stateless | ステートレス | 毎回履歴全体を送る |
| prefix match | プレフィックス一致 | 1バイト変化で以降が無効 |
cache_control ephemeral |
キャッシュ制御 | ブレークポイント最大4 |
| cache_read_input_tokens | キャッシュ読取 | 0なら無効化要因を疑う |
| silent invalidator | サイレント無効化 | datetime・未ソートJSON・可変ツール |
| Compaction | コンパクション | 要約。response.content丸ごと追記 |
| Context editing | コンテキスト編集 | 古い結果を削除（要約ではない） |
count_tokens |
トークン計測 | tiktokenは使わない |
| stop_reason | 停止理由 | refusal・pause_turn等を分岐 |
| refusal fallback | 拒否フォールバック | Fable 5、別モデルへ退避 |
練習問題（学習用の自作例題）
D5-Q1. 大きな共有システムプロンプトを付けた同一プレフィックスのリクエストを繰り返しているのに、cache_read_input_tokens が常に0である。最も疑うべき原因はどれか。
- A. プレフィックス内にリクエストごとに変わる要素（
datetime.now()やUUID、未ソートJSON、可変のツール集合）がある - B.
max_tokensが小さすぎる - C. モデルがHaikuだから
- D.
temperatureを設定していない
正解：A。 キャッシュはプレフィックス一致。前方に変動要素があると毎回別プレフィックスになり読取が発生しない。B・C・Dはキャッシュ無効化の原因ではない。
D5-Q2. コンパクション（compaction）とコンテキスト編集（context editing）の違いとして正しいものはどれか。
- A. どちらも過去の文脈を要約する
- B. コンパクションは過去文脈を要約し、コンテキスト編集は古いツール結果や思考を削除する
- C. コンパクションは削除、コンテキスト編集は要約
- D. 両者は同一機能の別名
正解：B。 compactionは要約（compact-2026-01-12、response.content を丸ごと追記）、context editingは削除（clear_tool_uses_20250919）。要約か削除かの違いが核心である。
4. 横断的な学習戦略と誤答パターン
4.1 一次教材（公式）
- Anthropic Academy（Skilljar） の無料コース：Building with the Claude API、Introduction to Model Context Protocol、Model Context Protocol: Advanced Topics、Claude Code in Action、Introduction to Agent Skills など。
- 研究記事「Building Effective Agents」（D1の土台）。
- 公式ドキュメント：Claude API（tool use / structured outputs / prompt caching / context editing / compaction）、Claude Code（memory / hooks / mcp / sub-agents / skills）、Claude Agent SDK、MCP Introduction。
4.2 頻出の誤答パターン（引っかけ対策）
- workflow と agent の取り違え：手順が予測可能ならworkflow。open-endedならagent。「まずシンプルに」を忘れない。
- Tool Runner と Claude Agent SDK の混同：前者は自作ツールをループするSDK機能、後者はClaude Codeのライブラリ（組み込みツールあり）。
- prefill を現行モデルで使う：最終assistantターンのprefillは400。構造化出力かstrictツールへ。
output_formatを使う：非推奨。output_config.formatが正しい。- MCPコネクタで片方だけ指定：
mcp_serversとmcp_toolsetは両方必須。 - キャッシュのプレフィックス無効化を見落とす：前方に可変要素を置かない。
- CLAUDE.md を強制手段だと思う：強制はhook（PreToolUse）や
permissions.deny。 budget_tokensを現行モデルで使う：廃止。adaptive thinking＋effortへ。- tiktoken でトークン数を数える：Claudeでは不正確。
count_tokensを使う。
4.3 用語総まとめ（クロスドメイン最終チェック）
| 領域 | 必ず言える状態にする語 |
|---|---|
| D1 | workflow / agent、5パターン、3原則、4方式、Batch API |
| D2 | tools・resources・prompts、mcp_servers＋mcp_toolset、strict、tool_choice、mcp__server__tool |
| D3 | CLAUDE.md 4層、hooks（PreToolUse deny）、skills=commands統合、subagents、permissions.deny |
| D4 | output_config.format、prefill廃止、strict tool use、adaptive thinking/effort |
| D5 | prefix caching、compaction vs context editing、count_tokens、stop_reason、refusal fallback |
4.4 学習計画の目安
配点順（D1 27% → D3 20% → D4 20% → D2 18% → D5 15%）に重み付けしつつ、まず本記事の用語表で英語語彙を固め、次にAcademyの該当コースで手を動かし、最後にシナリオ型の設計判断（「この状況ならどれを選ぶか」）を反復するのが効率的である。英語のみの試験なので、勉強フェーズでは翻訳を活用しつつ、本番は英語の設問を直接読める状態に仕上げる。
5. 結論
CCA-Fは、Claudeを用いた実運用アーキテクチャの設計判断を、5ドメイン（Agentic Architecture 27%、Claude Code 20%、Prompt/Structured Output 20%、Tool/MCP 18%、Context/Reliability 15%）にわたって問う、シナリオ型・監督付き・英語のみの試験である。合格の鍵は、(1) 4本柱（Claude API・Agent SDK・Claude Code・MCP）の概念を正確に押さえること、(2) 英語の専門用語を確実に対応づけること、(3) 「予測可能ならworkflow、open-endedならagent。まずシンプルに」という設計原則を軸に、各機能のトレードオフを説明できることである。本稿の用語表と練習問題を単語帳・模試として反復し、最後に公式Exam Guideと公式ドキュメントで最終確認してから臨まれたい。
6. 参考文献（出典）
認定・受験（公式）
- Anthropic 認定FAQ（受験資格・英語のみ・Pearson移行）：https://anthropic-partners.skilljar.com/page/faq-certifications
- Claude Certification Program（Pearson VUE 公式）：https://www.pearsonvue.com/us/en/anthropic.html
- Claude Partner Network 発表（無料加盟・加盟で認定アクセス）：https://www.anthropic.com/news/claude-partner-network
- Claude Certified Architect – Foundations Exam Guide（公式PDF）
技術ドキュメント（公式）
- Building Effective Agents（Anthropic研究記事）：https://www.anthropic.com/engineering/building-effective-agents
- Claude Code：CLAUDE.md/メモリ https://code.claude.com/docs/en/memory ／ hooks https://code.claude.com/docs/en/hooks ／ MCP https://code.claude.com/docs/en/mcp ／ subagents https://code.claude.com/docs/en/sub-agents ／ skills https://code.claude.com/docs/en/skills
- Claude API（Messages API、tool use、structured outputs、prompt caching、compaction、context editing、token counting）：https://platform.claude.com/docs
注記
- ドメインの配点と細目の一部は、公式Exam Guideおよびコミュニティ学習資料の突き合わせに基づく。受験前に最新の公式Exam Guideで最終確認すること。
- 「CALM framework」等、公式で確認できなかった第三者用語は本稿では公式用語として扱っていない（要確認）。
- 本稿の練習問題はすべて学習用に新規作成した例題であり、実際の試験問題ではない。