Claude 認定資格（CCA-F）公式サンプル12問を日本語解説【2026年版】

はじめに

「Claudeを仕事で使っているけど、自分がちゃんと理解できているか自信がない」
「Claude API、Claude Code、MCPを実務で使えるレベルで押さえたい」
「公式ドキュメントと記事を断片的に読んでいるだけで、体系的に学べていない気がする」

この記事は、そういう方に向けています。

2026年3月にAnthropicがリリースした「Claude Certified Architect – Foundations（CCA-F）」は、Claude初の公式技術認定資格です。受験は現状 Claude Partner Network 所属者に限られますが、出題される問題は「Claudeを実務でどう設計・実装するか」そのもの。受験の有無に関わらず、この問題を解くこと自体が Claude の体系理解につながります。

この記事では、Anthropic公式が試験ガイド（Exam Guide）で公開しているサンプル問題12問を、英語原文と日本語訳の併記 + 正解理由・不正解理由の詳細解説という形で整理しました。

この記事を書いている私は、Claude API・Claude Codeを使った実務経験があり、UdemyでAI-900対策講座のベストセラー、ChatGPT/生成AIコースを出している講師です。公式サンプル問題を実際に解き、5つのドメインごとに出題傾向と勘所を解説します。

受験を検討している方にも、受験しないけど Claude を体系的に理解したい方にも役立つ内容です。

CCA-Fとは？Anthropic初の公式技術認定資格

CCA-F（Claude Certified Architect – Foundations）は、Anthropicが2026年3月12日に公開した初の公式技術認定資格です。Claudeを使って本番環境のアプリケーションを設計・構築できるソリューションアーキテクトであることを証明する試験です。

AWSの「Solutions Architect Associate」や、GCPの「Professional Cloud Architect」のClaude版、とイメージすると分かりやすいです。「Claudeでチャットができる」レベルの話ではなく、エンタープライズレベルのAIシステムを設計・実装できるかを問う本格的な試験になっています。

試験仕様（公式情報）

試験名: Claude Certified Architect – Foundations（CCA-F）
形式: オンライン多肢選択式（プロクター監視付き）
問題数: 60問
試験時間: 120分
合格基準: 720点 / 1000点満点（スケールドスコア）
受験料: $99（Claude Partner Network所属社員は先着5,000名まで無料）
言語: 英語のみ（2026年4月時点、日本語化予定なし）
受験資格: Claude Partner Network所属が前提。個人単独での申込みルートは公式には未開放

試験範囲：5つのドメイン

試験は以下の5ドメインから出題されます。4つのシナリオが6つの中からランダム選出され、各シナリオに紐づく問題が出題されます。

ドメイン	配点	内容
1. Agentic Architecture & Orchestration	27%	エージェントループ、マルチエージェント、サブエージェント
2. Tool Design & MCP Integration	18%	ツール設計、MCPサーバー統合、エラーハンドリング
3. Claude Code Configuration & Workflows	20%	CLAUDE.md、スキル、フック、CI/CD統合
4. Prompt Engineering & Structured Output	20%	Few-shot、JSON Schema、バッチ処理
5. Context Management & Reliability	15%	コンテキストウィンドウ管理、信頼性設計

Domain 1が27%と最大の配点。Claude Agent SDKによるマルチエージェントシステムの設計が試験の中心です。

公式サンプル問題12問を徹底解説

ここからが本記事の本題です。Anthropic公式のExam Guide PDFに記載されているサンプル問題12問を、原文・日本語訳・解説の3点セットで見ていきます。

📌 Scenario 1: Customer Support Resolution Agent（カスタマーサポート解決エージェント）

Claude Agent SDKを使って、返品・請求問題・アカウント問題を扱うサポートエージェントを構築する。バックエンドへは MCP ツール（get_customer、lookup_order、process_refund、escalate_to_human）経由でアクセス。初回解決率80%以上が目標。

🔹 Question 1（問題1）

原文：

Production data shows that in 12% of cases, your agent skips get_customer entirely and calls lookup_order using only the customer’s stated name, occasionally leading to misidentified accounts and incorrect refunds. What change would most effectively address this reliability issue?

日本語訳：
本番データで、12%のケースでエージェントが get_customer を完全にスキップし、顧客が名乗った名前だけで lookup_order を呼び出していることが判明。時々、アカウントの誤認識と誤った返金が発生している。この信頼性問題に最も効果的な対処法は？

選択肢：

A) get_customer が検証済み顧客IDを返すまで lookup_order と process_refund の呼び出しをブロックするプログラム的な前提条件を追加する
B) システムプロンプトに「注文操作の前に get_customer での顧客確認が必須」と明記する
C) 顧客が注文情報を自発的に提供した場合でも、常に get_customer を最初に呼ぶfew-shot例を追加する
D) リクエストごとに適切なツールサブセットのみを有効化するルーティング分類器を実装する

正解：A

解説：
重要な業務ロジック（返金前の顧客本人確認など）で特定のツール順序が必要な場合、プログラム的な強制が唯一の確定的な保証になります。

B と C が不正解の理由：どちらもLLMの確率的なコンプライアンスに依存しています。「ほとんどの場合は従う」では、金銭的影響がある業務では不十分。LLMは99%従っても1%違反するので、本番で事故ります。
D が不正解の理由：ツールの可用性を変える話であって、ツールの順序の問題には対処していません。問題の本質がズレています。

実務での示唆： Claude Agent SDK でフック（PostToolUse 等）を使って、前提条件を満たさないツール呼び出しを物理的にブロックする実装パターンが、本番システムでは王道です。

🔹 Question 2（問題2）

原文：

Production logs show the agent frequently calls get_customer when users ask about orders (e.g., “check my order #12345”), instead of calling lookup_order. Both tools have minimal descriptions (“Retrieves customer information” / “Retrieves order details”) and accept similar identifier formats. What’s the most effective first step to improve tool selection reliability?

日本語訳：
本番ログで、ユーザーが注文について質問（例：「注文#12345を確認して」）したときに、エージェントが lookup_order ではなく get_customer を頻繁に呼び出していることが判明。両ツールは説明が最小限(「顧客情報を取得」「注文詳細を取得」)で、似た識別子フォーマットを受け付ける。ツール選択の信頼性を改善する最も効果的な最初のステップは？

選択肢：

A) システムプロンプトに、注文関連クエリを lookup_order にルーティングするfew-shot例を5〜8個追加する
B) 各ツールの説明を拡張し、入力フォーマット、例のクエリ、エッジケース、類似ツールとの使い分けの境界を含める
C) ユーザー入力をパースしてキーワードと識別子パターンから適切なツールを事前選択するルーティング層を実装する
D) 両ツールを単一の lookup_entity ツールに統合し、内部で識別子を判定してバックエンドを選ぶ

正解：B

解説：
ツールの説明文こそがLLMのツール選択の第一メカニズムです。説明が最小限だと、似たツール同士の判別ができません。

A が不正解の理由：few-shot例はトークンオーバーヘッドを増やすだけで、根本原因（説明不足）を解決しません。
C が不正解の理由：ルーティング層はオーバーエンジニアリング。LLMの自然言語理解を回避する設計で、そもそも最初の手段としては重すぎる。
D が不正解の理由：統合は有効なアーキテクチャ選択肢ですが、「最初のステップ」としては工数が重すぎる。説明不足という軽い原因に対して、重すぎる対処。

実務での示唆： MCPツールの説明文は「入力フォーマット・例クエリ・エッジケース・他ツールとの境界」を書くのが鉄則。Claude APIでツール作る人は全員押さえるべきポイントです。

🔹 Question 3（問題3）

原文：

Your agent achieves 55% first-contact resolution, well below the 80% target. Logs show it escalates straightforward cases (standard damage replacements with photo evidence) while attempting to autonomously handle complex situations requiring policy exceptions. What’s the most effective way to improve escalation calibration?

日本語訳：
初回解決率が55%で、80%の目標に遠く及ばない。ログでは、簡単なケース（写真証拠付きの標準的な破損交換など）をエスカレーションし、ポリシー例外が必要な複雑な状況を自律的に処理しようとしている。エスカレーションのキャリブレーションを改善する最も効果的な方法は？

選択肢：

A) システムプロンプトに明示的なエスカレーション基準とfew-shot例を追加し、エスカレーションと自律解決の使い分けを示す
B) 各応答前に信頼度スコア（1-10）を自己報告させ、閾値以下なら自動的に人間にルーティングする
C) 過去のチケットで訓練した別の分類器モデルをデプロイし、メインエージェント処理前にエスカレーション要否を予測する
D) 感情分析を実装し、顧客の不満レベルが閾値を超えたら自動エスカレーションする

正解：A

解説：
不明確な判断境界が根本原因。明示的なエスカレーション基準とfew-shot例が最も直接的な対処です。

B が不正解の理由：LLMの自己報告信頼度はキャリブレーションが甘い。この問題でもエージェントは「難しいケースで誤って自信を持っている」のが問題なので、自己報告させてもバイアスが変わらない。
C が不正解の理由：オーバーエンジニアリング。ラベル付きデータとMLインフラが必要で、プロンプト最適化を試す前に飛ばすには重すぎる。
D が不正解の理由：感情とケースの複雑さは相関しない。感情的な顧客でも簡単なケースはあるし、冷静な顧客でも複雑なケースはある。問題がズレています。

📌 Scenario 2: Code Generation with Claude Code（Claude Codeによるコード生成）

Claude Codeを使ってコード生成・リファクタリング・デバッグ・ドキュメント作成を加速する開発ワークフロー。カスタムスラッシュコマンド、CLAUDE.md設定、plan modeの使い分けが焦点。

🔹 Question 4（問題4）

原文：

You want to create a custom /review slash command that runs your team’s standard code review checklist. This command should be available to every developer when they clone or pull the repository. Where should you create this command file?

日本語訳：
チームの標準コードレビューチェックリストを実行するカスタム /review スラッシュコマンドを作りたい。このコマンドは、開発者がリポジトリをclone/pullしたときに全員が使えるようにしたい。このコマンドファイルはどこに作るべきか？

選択肢：

A) プロジェクトリポジトリの .claude/commands/ ディレクトリ
B) 各開発者のホームディレクトリの ~/.claude/commands/
C) プロジェクトルートの CLAUDE.md ファイル
D) commands 配列を持つ .claude/config.json ファイル

正解：A

解説：
プロジェクトスコープのスラッシュコマンドは .claude/commands/ に置きます。バージョン管理され、cloneで全開発者に自動配布される仕組みです。

B が不正解の理由：~/.claude/commands/ はユーザー個人用（バージョン管理されない）。チーム共有にならない。
C が不正解の理由：CLAUDE.md はプロジェクト指示・文脈用であって、コマンド定義用ではない。
D が不正解の理由：.claude/config.json という仕組みはそもそも存在しません。ひっかけ選択肢。

🔹 Question 5（問題5）

原文：

You’ve been assigned to restructure the team’s monolithic application into microservices. This will involve changes across dozens of files and requires decisions about service boundaries and module dependencies. Which approach should you take?

日本語訳：
モノリシックアプリケーションをマイクロサービスに再構築するタスクを担当。数十ファイルの変更と、サービス境界・モジュール依存関係の判断が必要。どのアプローチを取るべきか？

選択肢：

A) plan modeに入り、コードベースを探索し、依存関係を理解し、変更前に実装アプローチを設計する
B) direct executionで始めて、実装しながら段階的に変更し、自然なサービス境界を見つける
C) direct executionを使い、各サービスの構造を事前に詳細指示する
D) direct executionで始めて、予期せぬ複雑さに遭遇したときだけplan modeに切り替える

正解：A

解説：
plan modeは大規模変更・複数の有効アプローチ・アーキテクチャ判断・複数ファイル変更のための機能です。モノリス→マイクロサービスの再構築はまさにこれ。

B が不正解の理由：依存関係が後から発覚したときのリワークコストが大きい。
C が不正解の理由：コードを探索せずに「正しい構造」が分かっているという前提がそもそも無理。
D が不正解の理由：複雑さは「後から出てくるかも」じゃなく、要件の時点で既に明確です。

🔹 Question 6（問題6）

原文：

Your codebase has distinct areas with different coding conventions: React components use functional style with hooks, API handlers use async/await with specific error handling, and database models follow a repository pattern. Test files are spread throughout the codebase alongside the code they test (e.g., Button.test.tsx next to Button.tsx), and you want all tests to follow the same conventions regardless of location. What’s the most maintainable way to ensure Claude automatically applies the correct conventions when generating code?

日本語訳：
コードベースには異なる規約を持つ領域がある：Reactコンポーネントは関数型 + hooks、APIハンドラーは async/await + 特定のエラーハンドリング、DBモデルはリポジトリパターン。テストファイルはコードと並置（Button.test.tsx が Button.tsx の隣）。場所に関係なく全テストに同じ規約を適用したい。Claudeが自動的に正しい規約を適用する最もメンテナンス性の高い方法は？

選択肢：

A) .claude/rules/ にYAMLフロントマター付きのルールファイルを作り、glob パターンでファイルパスに基づいて規約を条件付き適用する
B) ルートの CLAUDE.md にすべての規約を領域別ヘッダーで統合し、Claudeに適切なセクションを推論させる
C) .claude/skills/ にコードタイプごとのスキルを作り、SKILL.mdに規約を含める
D) 各サブディレクトリに個別の CLAUDE.md を配置し、その領域の規約を記載する

正解：A

解説：
.claude/rules/ + glob パターン（例：**/*.test.tsx）なら、ディレクトリ場所に関係なくファイルタイプで規約を自動適用できる。テストファイルがコードベース中に散らばっているケースにピッタリ。

B が不正解の理由：Claudeの推論に頼るので信頼性に欠ける。
C が不正解の理由：スキルは手動呼び出しが前提。「自動適用」とは意味が違う。
D が不正解の理由：CLAUDE.md はディレクトリ単位の仕組みなので、散らばったファイルへの一括適用が難しい。

📌 Scenario 3: Multi-Agent Research System（マルチエージェント調査システム）

コーディネーターエージェントが複数のサブエージェント（web検索、文書分析、統合、レポート生成）に委譲して、調査レポートを生成するシステム。

🔹 Question 7（問題7）

原文：

After running the system on the topic “impact of AI on creative industries,” you observe that each subagent completes successfully: the web search agent finds relevant articles, the document analysis agent summarizes papers correctly, and the synthesis agent produces coherent output. However, the final reports cover only visual arts, completely missing music, writing, and film production. When you examine the coordinator’s logs, you see it decomposed the topic into three subtasks: “AI in digital art creation,” “AI in graphic design,” and “AI in photography.” What is the most likely root cause?

日本語訳：
「AIがクリエイティブ産業に与える影響」というトピックでシステムを実行。各サブエージェントは成功（web検索は適切な記事発見、文書分析は論文を正確に要約、統合エージェントは一貫した出力を生成）。しかし最終レポートはビジュアルアートのみをカバーし、音楽・文章・映画製作を完全に見落としている。コーディネーターのログを見ると、トピックを3つのサブタスク「デジタルアート制作のAI」「グラフィックデザインのAI」「写真のAI」に分解していた。最も可能性の高い根本原因は？

選択肢：

A) 統合エージェントが他エージェントから受け取った発見のカバレッジギャップを特定する指示を持っていない
B) コーディネーターのタスク分解が狭すぎて、サブエージェントへの割り当てがトピックの全関連領域をカバーしていない
C) web検索エージェントのクエリが十分に包括的でなく、より多くのクリエイティブ産業セクターを含めるべき
D) 文書分析エージェントが、過度に制限的な関連性基準により非ビジュアル系クリエイティブ産業のソースをフィルタアウトしている

正解：B

解説：
コーディネーターのログが直接根本原因を示しているのがポイント。「クリエイティブ産業」を視覚芸術系サブタスクのみ（デジタルアート、グラフィックデザイン、写真）に分解し、音楽・文章・映画を完全に省略している。

他の選択肢（A/C/D）は、正しく動いている下流のエージェントを誤って責めている。割り当てられたスコープ内では全員正しく仕事をしています。

実務での示唆： マルチエージェントシステムでは、コーディネーターのタスク分解設計が品質の80%を決めます。サブエージェントのクオリティより上流の分解がボトルネック。

🔹 Question 8（問題8）

原文：

The web search subagent times out while researching a complex topic. You need to design how this failure information flows back to the coordinator agent. Which error propagation approach best enables intelligent recovery?

日本語訳：
web検索サブエージェントが複雑なトピックの調査中にタイムアウト。この失敗情報をコーディネーターエージェントにどう伝えるか設計する必要がある。インテリジェントなリカバリーを可能にする最適なエラー伝播アプローチは？

選択肢：

A) コーディネーターに構造化エラーコンテキスト（失敗タイプ、試行したクエリ、部分結果、代替アプローチ）を返す
B) サブエージェント内で指数バックオフ付きの自動リトライを実装し、全リトライ枯渇後に「検索利用不可」という汎用ステータスのみ返す
C) タイムアウトをサブエージェント内でcatchし、成功とマークされた空の結果セットを返す
D) タイムアウト例外をトップレベルハンドラーに直接伝播し、調査ワークフロー全体を終了する

正解：A

解説：
構造化エラーコンテキストは、コーディネーターにインテリジェントなリカバリー判断に必要な情報を提供します（変更クエリでリトライ、代替アプローチ、部分結果で進める等）。

B が不正解の理由：汎用ステータスはコーディネーターから貴重なコンテキストを隠す。
C が不正解の理由：失敗を成功と偽装するのは最悪の反パターン。不完全な調査出力のリスク。
D が不正解の理由：リカバリー戦略が成功する可能性があるのに、全ワークフローを不必要に終了させる。

🔹 Question 9（問題9）

原文：

During testing, you observe that the synthesis agent frequently needs to verify specific claims while combining findings. Currently, when verification is needed, the synthesis agent returns control to the coordinator, which invokes the web search agent, then re-invokes synthesis with results. This adds 2-3 round trips per task and increases latency by 40%. Your evaluation shows that 85% of these verifications are simple fact-checks (dates, names, statistics) while 15% require deeper investigation. What’s the most effective approach to reduce overhead while maintaining system reliability?

日本語訳：
統合エージェントが発見を組み合わせる際、頻繁に特定の主張を検証する必要がある。現在は、検証が必要なとき統合エージェントがコーディネーターに制御を返し、web検索エージェントを呼び出し、結果と共に統合を再呼び出しする流れ。これでタスクごとに2-3往復追加、レイテンシ40%増。評価では、これらの検証の85%は単純な事実確認（日付・名前・統計）、15%がより深い調査が必要。システム信頼性を維持しつつオーバーヘッドを減らす最も効果的なアプローチは？

選択肢：

A) 統合エージェントに単純な検索用の scoped な verify_fact ツールを与え、複雑な検証はコーディネーター経由でweb検索エージェントに委譲を続ける
B) 統合エージェントが全検証ニーズを蓄積し、パス終了時にコーディネーターにバッチで返し、コーディネーターがweb検索エージェントに一括送信する
C) 統合エージェントに全web検索ツールへのアクセスを与え、コーディネーター経由の往復なしに検証ニーズを直接処理させる
D) web検索エージェントが初期調査中に各ソース周辺の追加コンテキストを事前キャッシュし、統合エージェントが検証する可能性のあるものを予測する

正解：A

解説：
最小権限の原則を適用。85%の一般ケース（単純な事実検証）に必要な分だけ統合エージェントに与え、複雑ケース用の既存調整パターンは維持する。

B が不正解の理由：バッチング方式はブロッキング依存を作る（統合ステップが先に検証された事実に依存する可能性）。
C が不正解の理由：統合エージェントの過剰プロビジョニング、関心の分離に違反。
D が不正解の理由：統合エージェントが何を検証する必要があるかを確実に予測できない投機的キャッシング。

📌 Scenario 5: Claude Code for Continuous Integration（CI/CD統合）

Claude CodeをCI/CDパイプラインに統合。自動コードレビュー、テストケース生成、PRフィードバック、プロンプト設計によるアクション可能なフィードバックと偽陽性最小化。

🔹 Question 10（問題10）

原文：

Your pipeline script runs claude "Analyze this pull request for security issues" but the job hangs indefinitely. Logs indicate Claude Code is waiting for interactive input. What’s the correct approach to run Claude Code in an automated pipeline?

日本語訳：
パイプラインスクリプトで claude "Analyze this pull request for security issues" を実行しているが、ジョブが無限にハング。ログはClaude Codeがインタラクティブ入力を待っていることを示している。自動化パイプラインでClaude Codeを実行する正しいアプローチは？

選択肢：

A) -p フラグを追加：claude -p "Analyze this pull request for security issues"
B) コマンド実行前に環境変数 CLAUDE_HEADLESS=true を設定
C) stdinを /dev/null にリダイレクト：claude "..." < /dev/null
D) --batch フラグを追加：claude --batch "..."

正解：A

解説：
-p（または --print）フラグが、Claude Codeを非インタラクティブモードで実行する公式に文書化された方法。プロンプトを処理し、結果をstdoutに出力して、ユーザー入力を待たずに終了する。

B の CLAUDE_HEADLESS、D の --batch フラグは存在しない。ひっかけ選択肢。
C は Unix の回避策だがClaude Codeのコマンド構文には適切に対処していない。

🔹 Question 11（問題11）

原文：

Your team wants to reduce API costs for automated analysis. Currently, real-time Claude calls power two workflows: (1) a blocking pre-merge check that must complete before developers can merge, and (2) a technical debt report generated overnight for review the next morning. Your manager proposes switching both to the Message Batches API for its 50% cost savings. How should you evaluate this proposal?

日本語訳：
自動分析のAPIコストを削減したい。現在、リアルタイムClaude呼び出しで2つのワークフローを運用：(1) 開発者のマージ前に完了する必要があるブロッキング事前マージチェック、(2) 翌朝レビュー用に夜間生成する技術的負債レポート。マネージャーが両方をMessage Batches APIに切り替えて50%コスト削減を提案している。この提案をどう評価すべきか？

選択肢：

A) 技術的負債レポートのみバッチ処理を使用。事前マージチェックはリアルタイム呼び出しを維持
B) 両ワークフローをバッチ処理に切り替え、完了確認のためステータスポーリングを使用
C) バッチ結果の順序問題を避けるため、両方ともリアルタイム呼び出しを維持
D) 両方をバッチ処理に切り替え、バッチが時間かかりすぎたらリアルタイムにフォールバック

正解：A

解説：
Message Batches APIは50%コスト削減だが、処理時間が最大24時間でレイテンシSLA保証なし。ブロッキング事前マージチェック（開発者が結果を待つ）には不適切だが、夜間の技術的負債レポートには理想的。

B が不正解の理由：「しばしば速い」に頼るのはブロッキングワークフローに許容不可。
C が不正解の理由：バッチ結果は custom_id フィールドで相関可能という誤解。
D が不正解の理由：シンプルな解決策（各APIを適切なユースケースに合わせる）があるのに不必要な複雑さを加えている。

🔹 Question 12（問題12）

原文：

A pull request modifies 14 files across the stock tracking module. Your single-pass review analyzing all files together produces inconsistent results: detailed feedback for some files but superficial comments for others, obvious bugs missed, and contradictory feedback—flagging a pattern as problematic in one file while approving identical code elsewhere in the same PR. How should you restructure the review?

日本語訳：
PRが在庫追跡モジュール全体で14ファイルを変更。全ファイル一括分析の単一パスレビューが一貫性のない結果を生成：一部ファイルには詳細フィードバック、他には表面的コメント、明白なバグを見逃し、矛盾フィードバック（同PR内で同じパターンをあるファイルで問題視、別ファイルで承認）。レビューをどう再構成すべきか？

選択肢：

A) フォーカスパスに分割：各ファイルを個別にローカル問題でレビュー、次にクロスファイルデータフロー調査用の別統合パス
B) 自動レビュー実行前に、開発者に大きなPRを3-4ファイルの小さな提出に分割するよう要求
C) 大きなコンテキストウィンドウを持つ上位モデルに切り替え、14ファイル全てに1パスで適切な注意を与える
D) 完全PRで3つの独立レビューパスを実行し、3つのうち2つ以上で現れる問題のみフラグする

正解：A

解説：
フォーカスパスへの分割が根本原因（多数ファイルを一度に処理する際の注意散漫）に直接対処。ファイルごとの分析で一貫した深さ、別の統合パスでクロスファイル問題をキャッチ。

B が不正解の理由：システム改善なしに開発者に負担を転嫁。
C が不正解の理由：大きなコンテキストウィンドウは注意品質問題を解決しないという誤解。
D が不正解の理由：実際のバグ検出が断続的に発生する可能性があり、コンセンサス要求で実問題の検出を抑制してしまう。

この12問を解いてみた感想

出題傾向のまとめ

5ドメインを見ると、「理論知識」ではなく「本番環境で何を選ぶか」を問う実装判断型の試験です。サンプル問題でも顕著です。

「プロンプトで指示する vs プログラムで強制する」→ 強制を選ばせる
「少数の精密ツール vs 大量の汎用ツール」→ 精密を選ばせる
「バッチ処理 vs リアルタイム」→ ユースケース次第で判断
「単一パス vs マルチパス」→ マルチパスを選ばせる

これ、Claude Agent SDK / Claude Code / Claude API で何かを本番投入した経験がある人なら、論点自体は馴染みがあるはずです。逆に、チャット利用だけの人には厳しい内容です。

合格に必要なレベル感（体感）

Claude APIでtool_use を書いたことがある：必須レベル
Claude Codeを日常的に使っている：CLAUDE.md、スラッシュコマンド、スキル等の細部を問われる
MCPサーバーを自作 or 統合した：Domain 2が楽になる
マルチエージェントシステムを試した：Domain 1の27%で有利

これらの実装経験がないと、知識だけでは720点（合格ライン）は厳しい印象です。

「Claudeをチャットで使ってます」レベルでは厳しい

このサンプル問題を見て「ぜんぜん分からない」となった方は、先に実装経験を積むほうがコスパいいです。Anthropic Academyの無料コースで Claude API と Claude Code の基礎を押さえ、実際にコードを書いてから受験を検討しましょう。

CCA-F の受験資格と日本から受ける現実

2026年4月時点の事実を整理します。

受験には Claude Partner Network メンバーシップが必要

Anthropic公式FAQに明記されています：

This certification is currently available to Anthropic partners. If your organization isn’t yet an Anthropic partner, you can apply to become one.

つまり、所属組織が Claude Partner Network に参加している必要があり、個人単独での申込みルートは公式には開放されていません。

日本から受ける現実的なルート

Accenture Japan、Deloitte Tohmatsu、Cognizant Japan 等の日本法人社員：グローバル本社がPartner Networkに参加しているため、社内経由で受験できる可能性があります
それ以外の日本企業：公式パートナーディレクトリに日本法人単独の掲載はまだ少なく、自社がPartner Networkに参加していない場合は、会社として参加申請するルートになります
個人事業主・フリーランス：現時点では公式ルートなし。今後の個人向け解禁を待つ形

言語は英語のみ

試験・対策コース・UI・ドキュメントすべて英語のみです。日本語化の公式アナウンスはありません。Claude公式ドキュメントを普段読んでいる方なら、そこまで高い英語力は要求されません。

学習リソースの現状（2026年4月時点）

CCA-F の対策、および Claude を体系的に学ぶための現実的な選択肢を整理します。

Anthropic Academy（公式・無料）

anthropic.skilljar.com で13コースの動画学習が無料で受けられる。Claude 101、Building Applications with the Claude API、Claude Code in Action、Introduction to MCP など、CCA-F 試験範囲と直接リンクするカリキュラム。

ただし試験形式の練習問題は Exam Guide PDF に収録されたサンプル12問のみ（本記事で全問解説済み）。本番形式の問題を繰り返し解いて慣れる、という用途には明確に足りない。

公式ドキュメント（docs.claude.com）

Agent SDK、Claude Code、MCP、Batch API の各セクションが試験範囲を網羅。英語のみ。正確性は最高水準だが、自分で「何を重点的に読むか」の道筋を引く必要がある。体系学習の足場を持っていない段階で飛び込むと、広大なドキュメントに迷う。

日本語記事（note、企業メディア等）

試験概要・5ドメインの解説記事は複数公開されている。ただし、サンプル問題に踏み込んで正解・不正解の理由まで日本語で解説した記事はほぼない。概要レベルで止まっているのが現状。

英語の模擬問題集（Udemy等）

Jon Bonso 氏（Tutorials Dojo）、Certification Trainer 等が英語の模擬問題集を公開している。問題文・選択肢・解説すべて英語。英語ドキュメントに日常的に触れている人向けで、日本語で学習を進めたい人にはハードルが高い。

独学の現実

2026年4月時点で、日本語で大量の模擬問題を解説付きで演習しながら Claude を体系的に理解できるリソースは存在しない。

現実的な選択肢は以下のいずれか：

英語で学ぶ（Anthropic Academy + 英語模擬問題集 + 公式ドキュメント）
日本語記事で概要を掴んだ後、公式ドキュメントを自力で読み込む
実務で Claude API / Claude Code を使い倒しながら経験で覚える

どれも相応の英語力・自走力が求められ、
「日本語で体系的に学ぶ」選択肢は現時点では限られています。

まとめ

CCA-Fの出題内容は、「Claude をチャットで使う」レベルではなく、Claude API・Claude Code・MCP・Agent SDK を実務でどう設計・実装するかを問う実装判断型です。

この記事の12問を時間を測らず解いてみて、どの選択肢に理由をつけて答えられるか試してみてください。

8割以上説明できる方：Claude を実務レベルで理解できています。受験を目指すなら追加対策1-2週間で合格ラインに届く実力です
半分程度の方：論点は見えているが実装経験が浅い段階。この12問の解説を起点に、各ドメインを順に深掘りしていくのが効率的です
ほとんど分からない方：まずは Anthropic Academy の「Building Applications with the Claude API」「Claude Code in Action」で基礎を押さえ、実際にコードを書きながら戻ってきてください

受験資格の有無に関わらず、これらの論点（ツール設計、エージェント設計、CI/CD統合、コンテキスト管理）は Claude を仕事で使う人全員に直接役立つ実装判断です。この記事が Claude の体系理解への入り口になれば幸いです。

参考リンク（公式）

Anthropic Academy: https://anthropic.skilljar.com
Claude Partner Network: https://claude.com/partners
Claude公式ドキュメント: https://docs.claude.com

著者プロフィール

Shota｜Udemyベストセラー講師
Udemy累計40,000名以上。AI-900対策講座でベストセラー獲得。
ChatGPT/生成AI入門、Claude API活用のSEOアプリ開発、
Claude Codeでのアプリ開発実務経験あり。
AI駆動開発・Spring Boot・Playwright等の実践講座を多数リリース。

はじめに

CCA-Fとは？Anthropic初の公式技術認定資格

試験仕様（公式情報）

試験範囲：5つのドメイン

公式サンプル問題12問を徹底解説

📌 Scenario 1: Customer Support Resolution Agent（カスタマーサポート解決エージェント）

🔹 Question 1（問題1）

🔹 Question 2（問題2）

🔹 Question 3（問題3）

📌 Scenario 2: Code Generation with Claude Code（Claude Codeによるコード生成）

🔹 Question 4（問題4）

🔹 Question 5（問題5）

🔹 Question 6（問題6）

📌 Scenario 3: Multi-Agent Research System（マルチエージェント調査システム）

🔹 Question 7（問題7）

🔹 Question 8（問題8）

🔹 Question 9（問題9）

📌 Scenario 5: Claude Code for Continuous Integration（CI/CD統合）

🔹 Question 10（問題10）

🔹 Question 11（問題11）

🔹 Question 12（問題12）

この12問を解いてみた感想

出題傾向のまとめ

合格に必要なレベル感（体感）

「Claudeをチャットで使ってます」レベルでは厳しい

CCA-F の受験資格と日本から受ける現実

受験には Claude Partner Network メンバーシップが必要

日本から受ける現実的なルート

言語は英語のみ

学習リソースの現状（2026年4月時点）

Anthropic Academy（公式・無料）

公式ドキュメント（docs.claude.com）

日本語記事（note、企業メディア等）

英語の模擬問題集（Udemy等）

独学の現実

まとめ

関連記事

参考リンク（公式）

著者プロフィール

コメントを残す コメントをキャンセル

運営者プロフィール

カテゴリー

タグ

アーカイブ

コメントを残すコメントをキャンセル