公式の出題範囲（2026年7月版）の全項目を網羅するノートとして執筆中です。章は試験ガイドの出題領域と、節はスキル（項目）と1対1で対応しています。 上から順に読み、各章末のチェック問題を解いたら、別ファイルの問題集で仕上げるのが最短ルートです。

⚠️ 試験範囲のバージョンについて（必読）

CCDV-F の試験ガイドは 2026年7月 に初版（Version 1.0）が公開されました。

✅ 結論：このノートは Version 1.0（2026年7月版）に対応しています。試験ガイドは2026年7月時点の製品を前提にしているので、その後に変わった機能は、時点を添えて両方を書きます。

📋 試験の基本情報

📊 出題比率と時間配分

1問あたり約2分15秒（120分÷53問）。

💡 比率の読み方：Claude Code の領域は3.1%ですが、CLAUDE.md、settings.json、hooks、Skills は、ほかの領域の項目（Configuration Management、Claude Hooks、Agentic Customization）にも出てきます。逆に、一般的なソフトウェア工学の4項目（Understanding Requirements、Systems Life Cycle、Software Engineering Foundations、Technical Fundamentals）が合わせて19.7%あります。

🗺 学習ロードマップ（目安：40時間）

🔗 公式リソース

第1章Agents and Workflows（14.7%）

この章のゴールは、問題文の条件から、何を作るか、何で作るか、エージェントの中をどう組むかの3つを選べるようになることです。

1-1. Agent Architecture（4.5%）

出題範囲：エージェントとワークフローのアーキテクチャの原則・パターン・トレードオフ。ワークフローとエージェントを使い分ける判断基準、マネージャー／スーパーバイザー型の階層の構造、タスクの実行を改善するサブエージェントの役割。

ワークフローとエージェントの違い

「エージェント」という言葉は、長時間自律して動くシステムにも、決めたワークフローに従うシステムにも使われます。Anthropic はこれらをまとめて「エージェント型システム（agentic systems）」と呼び、その中をワークフローとエージェントに分けています。分かれ目は、処理の道筋を誰が決めるかです。

エージェントの実体は、多くの場合「環境からのフィードバックを受けながら、ループの中でツールを使う LLM」です。ツールの実行結果のような環境から返る事実を各ステップで受け取り、進み具合を判断しながら次の行動を決めます。自律して動くぶん、コストが高くなりやすく、誤りが積み重なるおそれもあります。そのため Anthropic は、サンドボックスでの十分なテストと、適切なガードレールを勧めています。

まず一番単純な方法から選ぶ

Anthropic の推奨は、できるだけ単純な方法から始め、必要なときだけ複雑にすることです。エージェント型システムは、レイテンシとコストを払ってタスクの性能を上げる仕組みなので、その交換に見合うときだけ使います。複雑さを足す順番は次のとおりです。

1. 単一の LLM 呼び出し：検索で情報を足し、プロンプトに例を入れて最適化する。多くのアプリはここで足りる
2. ワークフロー：手順を定義できるタスクで、予測しやすさと一貫性が要るとき
3. エージェント：手順を事前に決められず、柔軟性とモデルの判断が要るとき

📌 試験ポイント：「手順が決まっている」「毎回同じ処理」「一貫性が要る」はワークフロー、「何ステップかかるか分からない」「決まった経路を書けない」はエージェント。「まず」「最小限で」と問われたら、単純な構成（単一の呼び出し、ワークフロー）で足りるかを先に検討するのが、Anthropic の推奨に沿った答え。

ワークフローの5つの型

エージェント型システムの基本の部品は「拡張された LLM（augmented LLM）」です。検索、ツール、メモリなどで拡張した LLM の呼び出しを1つの部品と考え、ワークフローではそれを次の型で組み合わせます。型の名前には公式の日本語訳が無いので、英語を併記します。

⚠️ 並列化とオーケストレーター・ワーカーの違い：どちらも複数の LLM に仕事を分けるので、形は似ています。違いはサブタスクの決まり方です。並列化はあらかじめ決めたサブタスクを同時に動かし、オーケストレーター・ワーカーは入力を見てオーケストレーターがその場でサブタスクを決めます。

📌 試験ポイント：「カテゴリごとに専用のプロンプトやモデルを使い分ける」「易しい質問は安いモデルへ」はルーティング。「サブタスクが事前に分からない」はオーケストレーター・ワーカー。「基準がはっきりしていて、評価と修正を繰り返す」は評価者・最適化者。「同じ処理を複数回実行して結果を比べる」は並列化の投票。

マネージャー（スーパーバイザー）型の階層

上位のエージェントが全体の計画を立て、サブタスクを下位のエージェントに任せ、戻ってきた結果をまとめる構造です。上位の呼び名は資料によって違い（マネージャー、スーパーバイザー、リードエージェント、オーケストレーター）、下位はサブエージェントやワーカーと呼ばれます。ワークフローの型のオーケストレーター・ワーカーを、エージェントどうしで組んだ形です。

Anthropic の調査機能（Research）は、この構造を次の流れで動かしています。

1. リードエージェントが、ユーザーの質問を分析して調べ方を決め、計画をコンテキストの外に保存する。コンテキストウィンドウがあふれても計画を失わないためである
2. リードエージェントが、調べる観点ごとにサブエージェントを起動する。サブエージェントは並列に動く
3. 各サブエージェントが、検索ツールを繰り返し使って情報を集め、見つけたことをリードエージェントに返す
4. リードエージェントが結果をまとめ、調査が足りるかを判断する。足りなければサブエージェントを追加するか、調べ方を見直して、2に戻る

エージェントを1つで済ませるか、複数に分けるかは、次の観点で決めます。

Anthropic は、多くのコーディングタスクは調査ほど並列に分けられないとしています。

📌 試験ポイント：「幅広い観点を同時に調べる」「1つのコンテキストに収まらない量の情報」はマルチエージェント。「同じ文脈を共有する」「サブタスクの依存が多い」「コストを抑えたい」は単一のエージェントのほうが合う。マルチエージェントはトークンを多く使うので、タスクの価値がそのコストに見合うことが前提になる。

サブエージェントの役割

サブエージェントは、メインのエージェントが、絞り込んだサブタスクのために起動する別のエージェントのインスタンスです。Claude Code のエージェントをライブラリとして使える Claude Agent SDK のドキュメントは、サブエージェントに任せることで得られる利点を4つ挙げています。

⚠️ サブエージェントにもコストがかかる：サブエージェントも自分でモデルにリクエストを送るので、使うトークンは増えます。Anthropic の調査機能の初期には、簡単な質問に50ものサブエージェントを起動する失敗もありました。コンテキストを分けたいときや並列にしたいときに使い、小さな作業まで細かく分けすぎないようにします。

📌 試験ポイント：「メインの会話を検索結果やログで埋めたくない」はコンテキストの分離、「同時に進めて時間を縮めたい」は並列化、「読み取りしかさせたくない」はツールの制限が、サブエージェントを使う理由になる。

1-2. Agent Construction with Claude（5.3%）

出題範囲：Claude のエージェントを作る方法・ツール・プラットフォーム。Claude Agent SDK、自作のエージェントループとハーネス、マネージドなエージェントのデプロイモデル（セルフホストと Anthropic のホスト）、決定的な動作のためのフック。

エージェントを動かすには、モデルの外側に仕組みが要ります。モデルの呼び出しとツールの実行を繰り返すエージェントループ、ツールを実行する環境、コンテキストの管理などで、これらをまとめて「ハーネス（harness）」と呼びます。Claude でエージェントを作る方法は、このハーネスを誰が用意し、どこで動かすかで分かれます。

自作のエージェントループ

モデルはアプリのコードを実行できません。そのため、アプリの中で実行するツールを使うときは、ツールを呼ぶたびに「モデルが頼み、アプリが実行し、結果を返す」往復が起きます。この往復を、stop_reason が "tool_use" である限り繰り返す while ループが、自作のエージェントループの基本形です。1回の往復は次のとおりです。

1. アプリが、ツールの定義（tools）とユーザーのメッセージを付けて、リクエストを送る
2. Claude が、stop_reason: "tool_use" と、1つ以上の tool_use ブロックを返す
3. アプリが各ツールを実行し、結果を tool_result ブロックにまとめる
4. アプリが、それまでのメッセージ、Claude の応答、tool_result を入れたユーザーのメッセージを付けて、次のリクエストを送る。ここで2に戻る

stop_reason が "tool_use" 以外（"end_turn"、"max_tokens"、"stop_sequence"、"refusal"）になったら、ループを抜けます。最終的な答えが出たか、アプリが別に扱うべき理由で止まったかのどちらかです。

ツールランナーは、この往復を代わりに回す Client SDK の機能（ベータ）です。ツールの実行、リクエストと応答のやり取り、会話の状態の管理、型の検証を自動で行います。ただし公式ドキュメントは、人の承認を挟む、独自のログを取る、条件によって実行を変える、といった制御が要るときは、手書きのループを使うよう勧めています。

📌 試験ポイント：自作のループの終わりの判定は stop_reason。"tool_use" ならツールを実行して tool_result を返し、それ以外なら抜ける。ツールランナーと手書きのループの比較では、「人の承認」「独自のログ」「条件付きの実行」が要るなら手書きのループを選ぶ。

Claude Agent SDK

Claude Agent SDK は、Claude Code を動かしているのと同じツール、エージェントループ、コンテキストの管理を、Python と TypeScript から使えるライブラリです。中では Claude Code の本体を動かしていて、query() にプロンプトとオプションを渡すと、ループを最後まで回します。Claude Code の機能のうち、次のものが SDK でも使えます。

Agent SDK を自分でホストするときは、状態を持たない API のラッパーとは考え方が違います。SDK は、シェル、作業ディレクトリ、ディスク上のセッションのファイルを持つ claude CLI の子プロセスを起動して監視するので、動いているエージェントの1つ1つが、ローカルの状態と結びついた長く動くプロセスになります。そのため、コンテナで動かし、セッションの寿命に合わせて次の型から選びます。

📌 試験ポイント：「Claude Code と同じ組み込みツールやフックを、自社のアプリに組み込む」は Agent SDK。Agent SDK は自分でホストするもので、長く動くプロセスとしてコンテナで運用する。ループそのものを自社で動かす必要がなければ、Managed Agents が候補になる。

Claude Managed Agents

Claude Managed Agents（ベータ）は、Anthropic が用意したハーネスを、Anthropic が管理するインフラで動かすサービスです。エージェントループ、ツールの実行、実行環境を自分で作らなくても、Claude がファイルを読み、コマンドを実行し、Web を調べ、コードを動かせる環境を使えます。次の4つの概念でできています。

公式ドキュメントが挙げる向く場面は、数分から数時間かかる処理、安全なクラウドのサンドボックスが要る処理、コンプライアンスやデータの所在地の要件があるとき、インフラを最小限にしたいとき、ファイルシステムと会話の履歴をやり取りの間で保ちたいとき、cron による定期実行です。

ホストの形は、エージェントループとツールの実行をそれぞれどこで動かすかで整理できます。

⚠️ セルフホストのサンドボックスでも、ツールの入出力は Anthropic を通る：ツールを実行するのは自社のワーカーですが、ツールの入力と出力は Anthropic のコントロールプレーンを流れます。モデルが結果を受け取って、次の行動を決めるためです。

📌 試験ポイント：「ループやサンドボックスを自前で作りたくない」「長時間」「非同期」は Managed Agents。そのうえで「ツールの実行やファイルを自社のインフラに置く」ならセルフホストのサンドボックス。「ループそのものを自社で動かす」なら Agent SDK を自分でホストする。

フックで決定的な動作を加える

LLM への指示が守られるかどうかは、モデルの判断に左右されます。フックは、エージェントのライフサイクルの決まった時点で自分のコードを動かす仕組みで、LLM が実行を選ぶかどうかに頼らず、決めた動作を毎回起こせます。Claude Code のドキュメントは、これを「決定的な制御（deterministic control）」と呼んでいます。Agent SDK では、アプリのプロセスで動くコールバック関数として登録します。主なイベントは次のとおりです。

• PreToolUse：ツールを実行する前。入力の検証、危険なコマンドのブロックに使う
• PostToolUse：ツールが結果を返した後。出力の監査、後続の処理の起動に使う
• UserPromptSubmit：プロンプトが送られたとき。プロンプトに追加の情報を差し込む
• Stop：エージェントが終わるとき。結果の検証、セッションの状態の保存に使う
• SubagentStart、SubagentStop：サブエージェントの起動時と終了時。並列のタスクの結果の追跡と集計に使う
• PreCompact：コンパクション（古い履歴を要約して空きを作る処理）の前。要約する前に、会話の全文を保存しておく

フックの動き方で押さえる点は3つです。

• フックの処理そのものは、エージェントのコンテキストウィンドウの外、つまりアプリのプロセスで動くので、コンテキストを消費しない。コンテキストに入るのは、フックが会話に差し込んだ情報だけ
• PreToolUse のフックがツールの呼び出しを拒否すると、そのツールは実行されず、Claude には拒否のメッセージが届く
• 1つのイベントに複数のフックがあると並列に動き、権限の判断は最も厳しい結果が採られる。1つでも拒否すれば、そのツールの呼び出しは止まる

📌 試験ポイント：「毎回必ず実行したい」「LLM の判断に任せたくない」処理はフックで書く。ツールの実行前に止めるなら PreToolUse、実行後の監査なら PostToolUse。システムプロンプトに「〜しないで」と書くだけでは、守られる保証にならない。

1-3. Agent Patterns and Frameworks（4.9%）

出題範囲：よく使われるエージェントの設計パターン（ツール使用のループ、サブエージェント、メモリ、コンテキストウィンドウの管理）と、複数の段階からなるタスクのエージェントやワークフローを作るための抽象化フレームワーク（Strands、LangGraph、Pydantic AI など）。

ツール使用のループを設計する

エージェントは、ツールを使い、結果を見て、次の行動を決めるループを回し続けます。このループを安全に回し切るために、Anthropic の記事とドキュメントは次の点を挙げています。

📌 試験ポイント：エージェントのループには、タスクの完了とは別の停止条件（最大ターン数、予算の上限）を置く。止まらないループや費用の暴走を防ぐためで、問題文に「コストの上限」「ループが終わらない」が出たら停止条件を考える。

サブエージェントに任せる

Agent SDK では、サブエージェントを次の3つの方法で用意し、Claude は Agent ツールを通じて呼び出します。どのサブエージェントをいつ使うかは、定義の description を見て Claude が判断します。

• プログラムで定義する：query() のオプションの agents に書く。SDK のアプリではこれが推奨
• ファイルで定義する：.claude/agents/ に Markdown のファイルを置く
• 組み込みの general-purpose サブエージェントを使う：何も定義しなくても呼び出せる

任せ方の質で結果は大きく変わります。Anthropic は調査機能の開発で、次のことを学んだと書いています。

📌 試験ポイント：サブエージェントへの指示には、目的、出力の形式、ツールと情報源、作業の範囲を入れる。サブエージェントどうしの作業の重複や抜けは、委任の指示があいまいなときに起きる。

メモリ

セッションをまたいで覚えておきたいことや、長い作業の途中で失いたくないことは、コンテキストウィンドウの外に置きます。Claude の API では、メモリツールがこの役割を持ちます。

• Claude が、メモリのディレクトリ（/memories）の中のファイルを作成・参照・更新・削除し、セッションをまたいで知識をためていく
• メモリツールを有効にすると、Claude はタスクを始める前にメモリのディレクトリを自動で確認する
• ファイル操作を実行するのはアプリで、Claude は操作を頼むだけ。データをどこにどう保存するかはアプリが決める。安全のため、/memories の外に出る操作は拒むようにする
• 最初に全部を読み込まず、必要なときに読み戻す「ジャストインタイム（just-in-time）」の取り出しを支える。今のコンテキストを、今のタスクに集中させられる

Claude Code と Agent SDK では、CLAUDE.md も決まりの置き場になります。CLAUDE.md は毎回のリクエストに入り直すので、コンパクションで古い会話が要約されても消えません。守らせ続けたい決まりは、最初のプロンプトではなく CLAUDE.md に書きます。

⚠️ メモリとコンパクションは役割が違う：コンパクションは今の会話を小さく保つ仕組み、メモリは要約で消えては困る情報を残す仕組みです。長く動くエージェントでは、両方を組み合わせます。

コンテキストウィンドウの管理

エージェントのコンテキストには、システムプロンプト、ツールの定義、会話の履歴、ツールの入力と出力がたまり続けます。大きなファイルを読んだり、出力の多いコマンドを動かしたりすると、1回で数千トークンを使うこともあります。しかも、コンテキストのトークンが増えるほど、モデルがその中の情報を正確に思い出す力は落ちます。Anthropic はこれを「コンテキストの劣化（context rot）」と呼び、コンテキストを、入れるほど効き目が薄れる有限の資源として扱うよう勧めています。目指すのは、望む結果につながる情報の濃いトークンを、できるだけ少なく入れることです。

Anthropic の記事は、長時間のタスクのための手法を次のように整理しています。

📌 試験ポイント：「長いやり取りの流れを保つ」はコンパクション、「区切りのある開発をセッションをまたいで続ける」はメモリ（構造化ノート）、「並列に調べ、メインのコンテキストを汚さない」はサブエージェント、「古いツールの結果が場所を取る」はツール結果のクリア。

エージェントのフレームワーク

エージェントのフレームワークは、LLM の呼び出し、ツールの定義と解析、呼び出しの連結といった低レベルの作業を簡単にする、抽象化のライブラリです。試験ガイドは例として次の3つを挙げています。

フレームワークを使うと始めるのは簡単になりますが、抽象化の層が重なり、実際に送られるプロンプトと応答が見えにくくなって、デバッグしにくくなります。単純な構成で足りるのに、複雑さを足したくなる誘惑も生まれます。Anthropic は、まず LLM の API を直接使うことを勧めています。多くのパターンは数行のコードで書けるからです。フレームワークを使うなら、中で何が起きているかを理解しておきます。中身についての思い込みは、よくある失敗の原因です。本番に近づいたら、抽象化の層を減らすことも勧めています。

📌 試験ポイント：「デバッグしにくい」「プロンプトが見えない」は、フレームワークの抽象化の弱点。「決定的なステップと LLM のステップを1つのグラフで組む」「永続的な実行」は LangGraph の特徴。どのフレームワークを使うときも、中で送られているプロンプトと応答を理解しておく。

✅ 第1章 チェック問題

Q1. 社内のヘルプデスクで、問い合わせを「パスワード」「経費」「その他」に分け、それぞれ専用のプロンプトとツールで答えたい。分類は高い精度でできる。合うワークフローの型はどれか。

Q2. 依頼ごとに、変更するファイルの数も中身も違うリファクタリングを、複数の LLM に分担させたい。プロンプトチェーンとオーケストレーター・ワーカーのどちらが合うか。

Q3. Agent SDK で作ったエージェントに、rm -rf を含むコマンドを決して実行させたくない。システムプロンプトに禁止を書くより確実な方法は何か。

Q4. エージェントループは自前で作りたくないが、規制のため、ツールの実行とファイルは自社のネットワークの中に置く必要がある。合う構成はどれか。また、この構成でツールの入力と出力はどこを通るか。

Q5. 数百の文献を調べて報告をまとめるエージェントで、検索結果がメインのコンテキストを埋めてしまい、後半の判断の質が落ちている。どう組み替えるとよいか。また、その代わりに増えるものは何か。

Q6. 何日もかけて段階ごとに機能を作るコーディングエージェントで、前のセッションで決めたことと残りの作業を、次のセッションに引き継ぎたい。合う手法はどれか。

第2章Applications and Integration（33.1%）

（未執筆）

2-1. Understanding Requirements（3.4%）

出題範囲：ビジネス要件とソリューションアーキテクチャに基づく、機能要件とインフラの要件。

（本文は未執筆）

2-2. Systems Life Cycle（2.8%）

出題範囲：IT システムの開発・導入・運用・保守に使う、システムのライフサイクル管理の概念とフレームワーク。

（本文は未執筆）

2-3. Claude API Mechanics（6.8%）

出題範囲：Claude API の動作と仕組み。メッセージ、ツール、ストリーミング、画像の入力（vision）、思考（thinking）、キャッシュ、他社のベンダー経由での Claude の呼び出し、Messages API のデータアクセスのパターン、バッチ API の使い方、リアルタイムとバッチの API の選び方のトレードオフ。

（本文は未執筆）

2-4. Software Engineering Foundations（7.4%）

出題範囲：ソフトウェア工学の基本の原則と実践。REST API、JSON、非同期プログラミング、バージョン管理、SDLC（ソフトウェア開発ライフサイクル）への組み込み、コードレビュー、小規模・大規模なリファクタリング。

（本文は未執筆）

2-5. Claude Application Design（8.6%）

出題範囲：Claude のアプリケーションを作るときの設計上の考慮点。インターフェース（Claude Code、Desktop、claude.ai、API、SDK）ごとに Claude が指示をどう解釈するか、コンテンツの境界、スキーマの設計、セッションの衛生管理（session hygiene）、プラグインの管理。

（本文は未執筆）

2-6. Configuration Management（4.1%）

出題範囲：Claude のシステムの構成要素の構成管理。CLAUDE.md、settings.json、モデルのバージョンの固定、プロンプトのバージョン管理、プラグインの依存関係。

（本文は未執筆）

✅ 第2章 チェック問題

（章を書き終えたら作る）

第3章Claude Code（3.1%）

（未執筆）

3-1. Claude Code Operation（3.1%）

出題範囲：Claude Code の中核の構成要素（Rules、Skills、Commands、Agents、Agent Memory）、機能（セッション管理、組み込みとカスタムのスラッシュコマンド、ヘッドレスモード、ストリーミングモード、auto モード）、CLAUDE.md の階層、リポジトリの初期化、settings.json の設定。

（本文は未執筆）

✅ 第3章 チェック問題

（章を書き終えたら作る）

第4章Eval, Testing, and Debugging（2.6%）

（未執筆）

4-1. Debugging and Error Handling（2.6%）

出題範囲：Claude のアプリケーションのデバッグとエラー処理。エラーの種類の特定、回復の方針の選択、トレースの分析による失敗のパターンの特定、問題の原因が統合のレイヤーとモデルの出力のどちらにあるかの切り分け。

（本文は未執筆）

✅ 第4章 チェック問題

（章を書き終えたら作る）

第5章Model Selection and Optimization（16.8%）

（未執筆）

5-1. LLM Fundamentals（5.2%）

出題範囲：LLM の基本（トークン、コンテキストウィンドウ、サンプリング、非決定性、次のトークンの生成）、モデルのオプション（fast mode、拡張思考（extended thinking）、適応型思考（adaptive thinking）、effort レベル）、基本のプロンプト手法（zero-shot、single-shot、multi-shot）。

（本文は未執筆）

5-2. Technical Fundamentals（6.1%）

出題範囲：AI アプリケーションの開発を支える技術の基礎。基本的なエンジニアリングの実践（REST API をラップする SDK との連携、WebSocket）。

（本文は未執筆）

5-3. Model Selection and Tradeoffs（2.7%）

出題範囲：Claude のモデルの能力（Opus・Sonnet・Haiku の使いどころ、adaptive thinking への対応）、品質・レイテンシ・コストのトレードオフ、タスクに合うモデルを選ぶときの、モデルのリリースをまたぐ破壊的な動作の変更。

（本文は未執筆）

5-4. Cost and Token Management（2.8%）

出題範囲：Claude のアプリケーションのトークンの予算とコストの管理。トークンの使用量の追跡、コストの見積もり、コストを下げるキャッシュの手法（プロンプトキャッシング、キャッシュのチェックポイント）。

（本文は未執筆）

✅ 第5章 チェック問題

（章を書き終えたら作る）

第6章Prompt and Context Engineering（11.0%）

（未執筆）

6-1. Context Engineering（3.8%）

出題範囲：Claude のアプリケーションのコンテキストとメモリの管理。コンテキストウィンドウの管理、コンテキストのドリフトと肥大化の防止（ツールの出力の刈り込み、コンパクション）、サブエージェントや複数の段階からなるエージェントのワークフローによるコンテキストの分離。

（本文は未執筆）

6-2. Prompt Engineering（4.6%）

出題範囲：プロンプトエンジニアリングの原則と方法。指示の明確さ、few-shot の例、system と user のどちらに置くか、出力の制約、構成要素をまたぐプロンプトと指示の配置、反復による改善、プロンプトの調整、入力のサニタイズ。

（本文は未執筆）

6-3. Output Handling（2.6%）

出題範囲：Claude の出力を作る・検証する・使うための確立したパターンと手法。構造化出力のパターン、応答の検証、防御的なパース、自信のある出力を鵜呑みにしないこと。

（本文は未執筆）

✅ 第6章 チェック問題

（章を書き終えたら作る）

第7章Security and Safety（8.1%）

（未執筆）

7-1. AI Application Security（3.2%）

出題範囲：データのプライバシーとセキュリティのベストプラクティス。プロンプトインジェクションの認識と緩和、ジェイルブレイクの防御、信頼できない入力の扱い、データ漏えいの防止、PII（個人を特定できる情報）の扱い、認証・認可・機密性・プライバシー・完全性の確保。

（本文は未執筆）

7-2. Guardrails and Safe Deployment（2.3%）

出題範囲：安全で責任あるデプロイの実践（コンテンツポリシー、ガードレールの多層化）と、セキュア・バイ・デザインの原則（プライバシー、ID とアクセスの管理、最小権限）。

（本文は未執筆）

7-3. Claude Hooks（1.0%）

出題範囲：Claude のアプリケーションで、破壊的な操作を防ぐガードレールと安全の制御にフックを使う。

（本文は未執筆）

7-4. Identity, Secrets, and Key Management（1.6%）

出題範囲：Claude の開発環境と本番環境をまたぐ、シークレット・資格情報・API キーの管理。ID の検証と認証、アクセスの承認と権限レベルの確認、許可されたアクセスの監視。

（本文は未執筆）

✅ 第7章 チェック問題

（章を書き終えたら作る）

第8章Tools and MCPs（10.6%）

（未執筆）

8-1. Tool Implementation（4.4%）

出題範囲：Claude のアプリケーションのツールの実装。ツール使用と関数呼び出し、外部システムとやり取りするための設定、ツールの説明の書き方、エラー処理、ツールの使い方のパターン（エージェントのハーネスによるディスパッチ、クライアント側とサーバー側のツール、承認のパターン）、ツール群の組み立て方のベストプラクティス。

（本文は未執筆）

8-2. MCP Server Development（2.1%）

出題範囲：MCP サーバーの開発。サーバーの作成、デプロイ、Claude のアプリケーションとの統合、MCP のリソース・ツール・プロンプト、通信のパターン（stdio、ソケット、クライアントとサーバー）。

（本文は未執筆）

8-3. Agentic Customization（4.1%）

出題範囲：組み込みのツール、カスタムのツール、Skills、MCP のトレードオフと、ユースケースに合うやり方の選び方。

（本文は未執筆）

✅ 第8章 チェック問題

（章を書き終えたら作る）

第9章直前まとめ

（本編を書き終えたら作る）

9-1. 早見表

9-2. 逆引き「〜したいときは何を使う？」

9-3. 紛らわしいペア比較

9-4. 数字・固有名詞の暗記リスト

（本編を書き終えたら作る）