公式の出題範囲（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%）

この章のゴールは、Claude を組み込んだアプリケーションについて、要件から設計、実装、構成の管理まで、各段階で何を選ぶかを判断できるようになることです。試験の3分の1を占める最大の領域で、Claude に固有の節（2-3、2-5、2-6）と、一般的なソフトウェア工学の節（2-1、2-2、2-4）が混ざっています。一般的な節は、用語と判断基準に絞っています。

2-1. Understanding Requirements（3.4%）

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

要件は、上から順に具体的にしていきます。まず事業として何を達成したいか（ビジネス要件）を決め、それを満たすためにシステムが何をするか（機能要件）と、どんな条件で動くか（非機能要件、インフラの要件）に分けます。ソリューションアーキテクチャは、ビジネス要件を満たすための構成の全体像です。機能要件とインフラの要件は、この全体像と行き来しながら固まります。

次の表は、社内の規程集に答えるアシスタントを作る場合の例です（説明のための例）。

要件を扱うときの判断基準は、次の3つです。

• 測れる形にする：「速く」ではなく「最初の文字を2秒以内に表示する」と書く。測れないと、構成どうしを比べることも、できあがったものを受け入れてよいかの判定もできない
• 何を優先するかを決める：品質、レイテンシ、コストは、どれかを上げると別のどれかが下がりやすい。優先順位が要件に書かれていれば、モデルや API の選び方がそこから決まる
• 制約を先に洗い出す：規制（データを置く国、保存期間）、既存のクラウドの契約、予算は、使えるプラットフォームと機能を絞る。たとえば「推論を米国内に限る」は、Claude API などでは、Claude 4.6 以降のモデルならリクエストごとに inference_geo: "us" を指定して満たせる。Amazon Bedrock などでは、どのエンドポイントや推論プロファイル（Bedrock で推論を送る地域を決める設定）を使うかで、推論の地域が決まる

📌 試験ポイント：問題文の条件を、ビジネス要件、機能要件、非機能要件、インフラの要件に仕分ける。「翌朝まででよい」「コストを最優先」「推論を米国内に限る」のような非機能要件とインフラの要件の言葉が、選ぶ API やプラットフォームを絞ることが多い。

2-2. Systems Life Cycle（2.8%）

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

システムのライフサイクルは、システムを計画してから廃止するまでの段階の流れです。各段階で何をするかを決めておくための考え方で、そのうちソフトウェアを開発する部分を SDLC（ソフトウェア開発ライフサイクル）と呼びます。段階は次のとおりで、反復型やアジャイルの進め方では、この流れを短い周期で何度も繰り返します。

1. 計画：目的、範囲、予算を決める
2. 要件定義：何を満たすかを決める
3. 設計：構成と方式を決める
4. 実装：作る
5. テスト：要件を満たすかを確かめる
6. 導入：本番の環境に出す（デプロイ）
7. 運用・保守：動かし続け、直し、変化に合わせる
8. 廃止：使うのをやめ、データを移すか消す

開発の進め方には、次のモデルがあります。

• ウォーターフォール：段階を順に1回ずつ進め、前の段階に戻らない前提で進める。要件が最初に固まり、変わりにくいときに向く
• V字モデル：ウォーターフォールの各段階に、対応する検証を組にする。たとえば、システムの要件とシステムの検証、詳細設計と単体テスト。検証の厳しさが求められるときに向く
• 反復型・インクリメンタル：小さく作り、機能を少しずつ足していく。全体像はあるが、作りながら確かめたいときに向く
• アジャイル：小さな単位で作って頻繁に届け、利用者の反応を見て計画を直す。スクラムは1か月以内の決まった周期（スプリント）で回し、カンバンは周期を決めずに作業の流れを整える。要件が変わりやすいとき、早く価値を届けたいときに向く
• DevOps：開発と運用を1つのチームと仕組みでつなぎ、ビルド、テスト、デプロイを自動化する。頻繁にリリースし、運用からの学びを次の開発に戻したいときに向く

運用の枠組みとしては、ITIL（もとは IT Infrastructure Library の略）が広く使われています。ITIL 4 からは、止まったサービスを早く戻すインシデント管理、インシデントの根本原因を突き止めて再発を防ぐ問題管理、変更のリスクを評価して承認してから入れる変更実現（change enablement。旧版では変更管理）などを、プラクティスとして定めています。保守は、目的で4つに分けます（ISO/IEC 14764 の分類）。

• corrective（是正）：見つかった不具合を直す。例：回答が文字化けする不具合を直す
• adaptive（適応）：変わった環境、変わりつつある環境でも使えるようにする。例：提供が終わるモデルから、新しいモデルに移す
• perfective（完全化）：機能や性能を良くする。例：回答に参照先のリンクを足す
• preventive（予防）：潜んだ欠陥を、障害になる前に見つけて直す。例：特定の入力でだけ落ちる不具合を、利用者が当たる前に直す

LLM を使うアプリでは、2つの段階に固有の作業が加わります。

• テスト：同じ入力でも出力が毎回同じとは限らない。そのため、決まった入力の集まりと採点の基準で品質を測る評価（eval）を用意し、プロンプトやモデルを変えたら、前の版と結果を比べる
• 運用・保守：使っているモデルにも寿命がある。Anthropic は、モデルの状態を次の4つに分けている

Anthropic は、一般に公開したモデルの提供終了の少なくとも60日前に、そのモデルを使っている顧客に知らせます。この日程は、Claude API、Claude Platform on AWS、Microsoft Foundry など、Anthropic が運用するプラットフォームのものです。Amazon Bedrock のようなパートナーが運用するプラットフォームは、独自の日程を決めます。Claude Console の使用量のページから、API キーとモデルごとの使用状況を書き出せるので、古いモデルを使っている箇所を探せます。

📌 試験ポイント：Deprecated のモデルは、提供終了の日までに、代わりのモデルでアプリを十分にテストしてから移す。提供終了の後のリクエストは失敗する。モデルの移行は、変わった環境に合わせる adaptive（適応）の保守にあたる。

2-3. Claude API Mechanics（6.8%）

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

この節は、Messages API のリクエストと応答の形から始め、ツールの渡し方、応答の受け取り方（ストリーミング）、画像と PDF の入力、思考、キャッシュ、クラウド経由の呼び出し、データの渡し方、まとめて処理するバッチの順に扱います。

Messages API の基本

Claude API は https://api.anthropic.com の REST API で、Claude との会話には Messages API（POST /v1/messages）を使います。リクエストには、認証（API キーなど）、API のバージョン（anthropic-version）、content-type: application/json のヘッダーが要ります。Client SDK を使えば、これらは自動で付きます。API のバージョンは、2026年10月21日に 2026-10-21 が出ました。それまでの最新は 2023-06-01 で、試験ガイドはその時点の製品を前提にしています。新しい版の Client SDK は、既定で 2026-10-21 を送ります。

応答は、content（テキスト、tool_use、思考などのブロックの配列）、止まった理由の stop_reason、使ったトークン数の usage を持ちます。

Messages API は状態を持ちません（ステートレス）。サーバーは前の発言を覚えていないので、会話を続けるたびに、それまでの全履歴を messages に入れて送ります。履歴はアプリが組み立てるので、途中の assistant の発言をアプリが書いたものにすることもできます。

⚠️ プリフィルは新しいモデルでは使えない：最後に assistant の発言を置いて、応答の書き出しを決める手法をプリフィルと呼びます。Claude 4.6 以降のモデルでは、プリフィルを含むリクエストは 400 エラーになります。出力の形を決めたいなら、構造化出力（応答を JSON のスキーマに必ず合わせる機能）か、システムプロンプトの指示を使います。

📌 試験ポイント：Messages API はステートレスなので、会話を続けるには毎回それまでの履歴を送る。「Claude が前の発言を覚えていない」は、履歴を送っていないことが原因。

ツールの定義と使わせ方

Claude にツールを使わせるには、リクエストの tools にツールを定義します。

• name：ツールの名前
• description：何をするか、いつ使うか、各引数の意味。ツールを正しく選ばせるうえで、最も効く項目
• input_schema：引数の形を、JSON Schema で書く
• input_examples：入力の例（任意）

API は、ツールの定義からツール使用のためのシステムプロンプトを組み立て、指定されたシステムプロンプトと合わせます。そのため、ツールの定義も入力トークンとして数えられます。ツールの呼び出しは、stop_reason が "tool_use" の応答を受けてアプリがツールを実行し、結果を tool_result で返す往復で進みます。

tool_choice は、ツールを使わせるかどうかを決めます。

any と tool は、ツールの使用を強制します。強制すると、Claude は tool_use の前に説明の文を書かず、思考もしません。手動の拡張思考（thinking: {type: "enabled"}）と組み合わせると、エラーになります。

⚠️ 一部の新しいモデルでは強制できない（2026年10月時点）：Claude Opus 5.5、Sonnet 5.5、Fable 5.1、Mythos 5.1 では、any と tool は 400 エラーになります（Opus 5 や Haiku 5.5 は受け付けます）。ツールの入力を確実にスキーマどおりにしたいなら、auto と厳密なツール使用（ツールの入力をスキーマに必ず合わせる strict: true）を組み合わせます。

📌 試験ポイント：「特定のツールを必ず呼ばせる」は tool_choice の tool、「ツールを使わせない」は none。強制すると、ツールの前の説明文も思考も出ない。説明させたいなら、auto のままプロンプトで頼む。

ストリーミング

"stream": true を付けると、応答が SSE で少しずつ届きます。届くイベントは次の順で、2〜4 は内容のブロックの数だけ繰り返します。

1. message_start：中身が空の Message オブジェクト
2. content_block_start：ブロック（テキスト、tool_use、思考など）の始まり
3. content_block_delta：ブロックの中身の差分。1つのブロックで何回も届く
4. content_block_stop：ブロックの終わり
5. message_delta：stop_reason など、メッセージ全体の変更
6. message_stop：終わり

このほか、ping と error のイベントが届くことがあります。たとえば混雑時の overloaded_error は、ストリーミングでなければ HTTP 529 にあたるエラーです。API のバージョンの方針で新しい種類のイベントが足されることがあるので、知らない種類のイベントは読み飛ばすように書きます。

差分（delta）には次の種類があります。

• text_delta：テキストの続き
• input_json_delta：ツールの入力の一部。JSON の文字列の断片なので、content_block_stop まで貯めてからパースする（SDK のヘルパーも使える）
• thinking_delta、signature_delta：思考の中身と、思考ブロックが改ざんされていないことを確かめる署名

message_delta の usage のトークン数は、それまでの累計です。

ストリーミングを使う理由は2つです。1つは、生成された分から表示して、利用者の待ち時間を短くするため。もう1つは、長い応答で HTTP の接続がタイムアウトしないようにするためです。SDK は、ストリーミングしないと約10分を超えると見込まれるリクエストをエラーにして、ストリーミングを求めます（思考のページの説明では、max_tokens が 21,333 を超えるとき）。途中の表示が要らなければ、SDK の .stream() と、最終メッセージを組み立てるヘルパー（Python では get_final_message()）を使います。完成した Message を、ストリーミングしないときと同じ形で受け取れます。

接続が途中で切れたら、受け取った分を保存し、続きを頼みます。Claude 4.6 以降のモデルではプリフィルが使えないので、受け取った途中までの文を入れた user の発言で、続きから書くよう指示します。tool_use と思考のブロックは、途中からは再開できません。

📌 試験ポイント：「最初の文字を早く表示したい」「長い出力でタイムアウトする」はストリーミング。ツールの入力の差分は JSON の断片なので、ブロックが終わるまで貯めてからパースする。

ビジョン（画像の入力）

画像は、messages の中の image ブロックで渡します。渡し方は3つです。

Amazon Bedrock と Google Cloud の Vertex AI では、base64 だけが使えます。

形式は image/jpeg、image/png、image/gif、image/webp で、アニメーションは最初のコマだけが使われます。2026年10月時点の主な上限は次のとおりです。

• 1回のリクエストで600枚まで（コンテキストウィンドウが20万トークンのモデルは100枚）。1枚の大きさは 8000×8000 ピクセルまでで、20枚を超えると1枚あたりの上限が厳しくなる
• 1枚のデータは、Claude API では base64 で 10 MB まで。リクエスト全体の上限（32 MB）に先に達することがあるので、枚数が多いときは Files API で参照する
• 画像もトークンとして課金される。28×28 ピクセルのまとまりを1つの視覚トークンとして、⌈幅÷28⌉×⌈高さ÷28⌉ トークンと数える。モデルごとの上限を超える画像は縦横の比を保って縮小されるので、細かい文字が読めなくなることがある

画像は、質問の文より前に置くと結果が良くなります。後ろに置いても十分に動きますが、選べるなら画像を先にします。

画像の読み取りには、次の限界があります。

• 画像の人物が誰かは答えない（利用ポリシーにより断る）
• 画質が低い、回転している、200ピクセル未満の小さい画像では、誤りやすい
• 位置の座標や物の数は、おおよその値になる
• AI が生成した画像かどうかは判定できない
• CT（コンピューター断層撮影）や MRI（磁気共鳴画像）のような、複雑な診断画像の読影には向かない

PDF は document ブロックで渡します。各ページを画像に変換し、抜き出したテキストと合わせて Claude に渡すので、図や表も読めます。1回のリクエストで600ページまで（コンテキストウィンドウが100万トークン未満のときは100ページ）で、トークンは、テキストの分（1ページあたり、おおよそ 1,500〜3,000）と、ページの画像の分の両方がかかります。

📌 試験ポイント：「同じ画像や文書を何度も使う」は Files API の file_id で参照する。人物の特定は断られ、AI が生成した画像かどうかの判定はできない。PDF の図や表は、ページを画像としても読むので扱える。

思考（thinking）

思考を使うと、Claude は答える前に、問題を言い直し、やり方を試し、途中の結果を確かめます。思考の内容は、応答の text ブロックの前に、思考ブロック（thinking）で返ります。数学、コーディング、分析、長いエージェントの作業のように、途中の作業が答えの質を左右するタスクで効きます。

思考の有無と深さは、thinking パラメータで決めます。適応型思考は、type を "adaptive" にして、いつ・どれだけ考えるかを Claude にリクエストに応じて決めさせます。拡張思考は、type を "enabled" にして、思考に使うトークンの予算を budget_tokens で自分で決めます。どちらを受け付けるか、既定で思考がオンかは、モデルで違います。API での扱いで押さえる点は次のとおりです。

• 課金：思考のトークンは出力トークンとして課金され、max_tokens にも含まれる。思考の文が返らないときも同じ
• 表示：display が "summarized" なら思考の要約を返し、"omitted" なら思考の欄を空で返す。省くと最初のテキストが早く届くが、費用は変わらない。生の思考の過程は、どちらでも返らない。既定はモデルで違う
• 署名：思考ブロックの signature は、思考の全文を暗号化したもの。中身を解釈せず、受け取ったまま返す
• ツール使用：ツールの結果を返すときは、前の応答の思考ブロックを、tool_use ブロックと一緒に、手を加えずに返す。手を加えると 400 エラーになる。安全のために伏せられた redacted_thinking ブロックも同じように返す
• ターンの途中の切り替え：ツール使用のループは、全体で1つの assistant のターンになる。ターンの途中で思考の設定を変えると、エラーにはならず、そのリクエストでは思考が無効になる。設定は、ターンとターンの間で変える
• インターリーブ思考：ツールの呼び出しの合間に、結果を見て考える。適応型思考では自動で行われる
• キャッシュ：思考の設定や、トップレベルの effort（応答全体にかける手間の度合いを決めるパラメータ）を変えると、プロンプトキャッシュのメッセージの部分が無効になる

⚠️ 思考ブロックを捨てるコードは壊れる：ツール使用の往復で、応答のブロックを種類で絞って履歴に戻すとき、text と tool_use だけを残すと思考ブロックが落ちます。thinking だけを足しても、redacted_thinking が落ちます。前の応答の content を、そのまま assistant の発言として戻すのが確実です。

📌 試験ポイント：思考のトークンは出力トークンとして課金され、max_tokens に含まれる。表示を省いても速くなるだけで、費用は下がらない。ツール使用のターンでは、思考ブロックを手を加えずに返す。

プロンプトキャッシング

プロンプトキャッシングは、前のリクエストで処理したプロンプトの先頭部分（プレフィックス）を再利用して、処理時間と費用を減らす機能です。長いシステムプロンプト、たくさんの例、長い文書、長い会話のように、同じ先頭部分を何度も送るときに効きます。

• プレフィックスは、tools、system、messages の順に並べたプロンプトの、先頭からキャッシュブレークポイントまで
• cache_control で有効にする。リクエストのトップレベルに1つ付けると、最後のキャッシュできるブロックに自動でブレークポイントが置かれ、会話が伸びるとブレークポイントも進む（自動キャッシング）。ブロックごとに付けると、どこまでをキャッシュするかを自分で決められる（明示的なキャッシュブレークポイント）
• キャッシュの寿命（TTL（Time To Live））は既定で5分で、使うたびに無料で延びる。追加料金で1時間にもできる。寿命はリクエストの開始から数えるので、応答の生成にかかった時間も寿命を使う
• モデルごとに、キャッシュできる最小のトークン数がある（2026年10月時点で 512〜4,096 トークン）。それより短いと、cache_control を付けてもエラーにならず、キャッシュされない
• 並列に送ると、最初の応答が始まるまでは、そのキャッシュは使えない

キャッシュは tools → system → messages の階層になっていて、ある階層を変えると、その階層と後ろの階層が無効になります。

• ツールの定義を変えると、すべて（ツール、システム、メッセージ）が無効になる
• Web 検索のツールや、引用（citations）の機能を有効・無効にすると、システムとメッセージが無効になる
• tool_choice を変えたり、画像を足したり消したりすると、メッセージが無効になる
• 思考の設定や effort を変えると、メッセージが無効になる。モデルによっては、ツールとシステムも無効になる

先頭に近いところに毎回変わる値（現在の時刻など）を置くと、その後ろは毎回別のプレフィックスになり、キャッシュが当たりません。毎回変わる値は、キャッシュしたい部分の後ろに置きます。

キャッシュの効き方は、応答の usage の3つの項目で確かめます。入力の合計は、この3つの和です。

• cache_creation_input_tokens：キャッシュに書き込んだトークン数
• cache_read_input_tokens：キャッシュから読んだトークン数
• input_tokens：最後のブレークポイントより後ろの、キャッシュの対象外のトークン数。これだけを見ると、入力が小さく見える

📌 試験ポイント：「同じ長い指示や文書を何度も送る」はプロンプトキャッシング。キャッシュが当たらないときは、先頭に毎回変わる値が無いか、最小のトークン数に足りているか、5分の寿命が切れていないか、ツールの定義を変えていないかを見る。

クラウドのプラットフォーム経由で呼ぶ

Claude は、Anthropic の Claude API のほかに、クラウドのプラットフォームからも使えます。クラウドの請求と IAM（Identity and Access Management）にまとめられるのが利点で、既存のクラウドの契約やコンプライアンスの要件があるときに選びます。2026年10月時点の提供形態は次のとおりです。

• Claude API：Anthropic が運用する。最新のモデルと機能を直接使える
• Claude Platform on AWS：Anthropic が運用する（2026年5月から）。AWS の IAM と請求で、Claude API と同じ API を使う。新しい機能は、たいてい Claude API と同じ日に使える
• Amazon Bedrock：AWS が運用し、AWS のセキュリティの境界の中で使える。Opus 4.7 以降や Haiku 4.5 などの新しいモデルは、Messages API と同じ形のエンドポイントで呼ぶ。Opus 4.6 以前のモデルなどの従来の統合は、Bedrock の InvokeModel と Converse の API で呼ぶ。機能は Bedrock の予定で提供される
• Google Cloud：Google が運用する Vertex AI では、モデルを URL に、API のバージョンを本文の anthropic_version に書く。Anthropic が運用する形もある
• Microsoft Foundry：Anthropic が運用する。Azure のマーケットプレイスで請求され、Azure の認証で使う

Google Cloud の Vertex AI での提供は、2026年10月時点のドキュメントでは Claude Models on Google Cloud（Google managed）と呼ばれ、Google Cloud の Agent Platform の一部とされています（SDK のクライアント名などには Vertex の名前が残っています）。2026年10月22日には、Anthropic が運用する形（Anthropic managed）も加わりました。

どのプラットフォームでも共通して押さえる点は、次のとおりです。

• 認証は、クラウドの IAM の認証情報で行う。Anthropic の Client SDK は、どのプラットフォームにも対応している
• 使える機能はプラットフォームで違う。パートナーが運用するプラットフォーム（Amazon Bedrock と Vertex AI）では、ベータの機能や新しい機能が遅れて出たり、無かったりする
• モデルの ID の書き方が違うことがある。Bedrock では anthropic. が頭に付く（例：anthropic.claude-opus-4-7）
• リクエストの大きさの上限も違う。Claude API の 32 MB に対し、Bedrock は 20 MB、Vertex AI は 30 MB
• モデルの提供終了の日程は、パートナーが運用するプラットフォームが独自に決める

📌 試験ポイント：「既存のクラウドの契約、請求、IAM にまとめたい」はクラウドのプラットフォーム経由。「最新の機能やベータをすぐ使いたい」は Claude API か、Anthropic が運用するプラットフォーム。ある機能がプラットフォームで使えないのは、機能の提供がプラットフォームごとに違うため。

データを Claude に渡す方法

試験ガイドの「Messages API data access patterns」には、中身の説明がありません。このノートでは、Messages API で扱うデータをどう Claude に届けるか、と解釈して整理します。

Files API は、ファイルを一度アップロードして、何度も参照する API です。

• アップロード、一覧、削除などの操作は無料で、ファイルの中身は、Messages API で使ったときに入力トークンとして課金される。1ファイル 500 MB まで、組織で合計 1 TB まで
• アップロードしたファイルは変更できない。削除するか、アップロードのときに決めた有効期限（1時間〜90日）が来るまで残る
• 2026年7月時点ではベータで、files-api-2025-04-14 のベータのヘッダーが要った。2026年8月19日に、Claude API で一般提供になった

⚠️ Files API のファイルは、ワークスペース全体から使える：ワークスペースは、Claude Console で API キーや使用量を分ける単位です。アップロードしたファイルは、そのワークスペースのどの API キーからも使え、利用者や会話ごとには分かれません。マルチテナントのアプリでは、テナントごとにワークスペースを分けます。信頼できない相手から受け取った file_id は使いません。

📌 試験ポイント：「同じ大きなファイルを何度も使う」は Files API。「テナントのデータを分けたい」はテナントごとのワークスペース。

バッチ処理（Message Batches API）

Message Batches API は、たくさんの Messages API のリクエストをまとめて送り、非同期に処理させる API です。料金は通常の50%です。

1. アプリが、リクエストの一覧を送ってバッチを作る。各リクエストは、一意の custom_id と、Messages API と同じパラメータ（params）を持つ
2. バッチは非同期に処理され、各リクエストは独立に扱われる。アプリは、バッチの processing_status が ended になるまで、状態を確かめる（ポーリング）
3. アプリが結果を受け取る。結果は1行に1件の JSON（.jsonl の形式）で、順番はリクエストの順とは限らないので、custom_id で対応づける

制限と動きは次のとおりです。

• 1つのバッチは、10万件か 256 MB の、先に達したほうまで
• 多くは1時間以内に終わる。全件が終わるか24時間たつと結果を取れ、24時間で処理されなかったリクエストは期限切れになる
• 結果は、作成から29日間取れる
• 結果の種類は succeeded、errored、canceled、expired の4つで、後の3つは課金されない
• params の検証は非同期に行われ、誤りは全件の処理が終わってから返る。先に、同じ形のリクエストを Messages API で1件送って確かめる
• ストリーミング（stream: true）は使えない
• プロンプトキャッシングと併用でき、割引は重なる。ただし並列に処理されるので、キャッシュが当たるかはベストエフォートになる（ドキュメントでは、当たる割合は30〜98%）

リアルタイムとバッチの選び方

決め手は、結果を待っている人がいるかどうかです。待てるなら、処理が多いほどバッチの割引が効きます。同期のリクエストを並列に送っても、速く終わるだけで、トークンあたりの料金は下がりません。

📌 試験ポイント：「急がない」「大量」「コストを抑えたい」は Message Batches API。「利用者が待っている」「すぐ表示したい」は Messages API（必要ならストリーミング）。バッチの結果は順不同なので、custom_id で対応づける。

2-4. Software Engineering Foundations（7.4%）

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

この節は、一般的なソフトウェア工学の基礎です。用語と判断基準に絞り、Claude での開発に関わるところを添えます。

REST API

REST は、URL で表したリソースを、HTTP のメソッドで操作する API の設計のスタイルです。各リクエストは処理に要る情報をすべて自分で持ち、サーバーはリクエストの間で、クライアントとのやり取りの状態（セッションの状態）を持たない前提です。

冪等なリクエストは、失敗したときに安全に送り直せます。ステータスコードは、2xx が成功、4xx が呼び出し側の誤り（400 不正なリクエスト、401 認証の失敗、403 権限なし、404 見つからない、429 リクエストが多すぎる）、5xx がサーバー側の誤りです。

📌 試験ポイント：「安全に再送できる」は冪等なメソッド（GET、PUT、DELETE）。POST は冪等ではないので、再送すると二重に作られることがある。4xx は呼び出し側、5xx はサーバー側の誤り。

JSON

JSON は、オブジェクト（{}）、配列（[]）、文字列、数値、真偽値、null でデータを表すテキストの形式です。JSON Schema は、JSON の形（どの項目があり、どの型で、どれが必須か）を書くための仕様で、Claude ではツールの引数（input_schema）と構造化出力のスキーマに使います。

非同期プログラミング

API の呼び出しのように、時間の大半がネットワークの応答待ちになる処理では、待っている間に別の処理を進める非同期プログラミングが効きます。Python の async/await や JavaScript の Promise がその仕組みで、イベントループが、待ちに入った処理を切り替えながら進めます。Anthropic の Python の SDK には、非同期のクライアント（AsyncAnthropic）があります。

たくさんのリクエストを並列に送るときは、同時に送る数に上限を設けます。Claude API にはレート制限があり、超えると 429 が返るためです。

バージョン管理

Git では、変更をコミットで記録し、ブランチで並行して作業します。GitHub などのホスティングのサービスでは、プルリクエストでレビューしてから統合します。ブランチの運用には、次の型があります。

• トランクベース開発：全員が1本の主ブランチ（トランク）に、小さく頻繁に統合する。未完成の機能は、機能フラグでオフにしたまま本番に出せる
• GitHub Flow：main から機能ブランチを切り、プルリクエストでレビューして main に戻す。マージしたらブランチは消す
• Git Flow：長く続く2本のブランチ（本番用と開発用）に、機能、リリース、緊急の修正（hotfix）のブランチを組み合わせる。版を明示して出すソフトウェアや、複数の版を並行して保守する開発向け

リリースには、セマンティックバージョニング（メジャー.マイナー.パッチの3つの番号）で版を付けることが多く、互換性を壊す変更でメジャー、互換性のある機能の追加でマイナー、修正でパッチを上げます。依存する側は、この番号の範囲で互換性を判断します。

開発の流れへの組み込み（SDLC integration）

Claude は、SDLC の各段階に組み込めます。

Claude Code GitHub Actions は、Claude Code をリポジトリのワークフローの中で動かす GitHub Action で、Agent SDK の上に作られています。Claude Code で /install-github-app を実行すると、GitHub App のインストール、認証情報のリポジトリのシークレットへの登録、ワークフローのファイルを入れるプルリクエストの準備まで進みます。

コードレビュー

コードレビューは、変更をマージする前に、別の人（や別のエージェント）が確かめる工程です。正しさ、セキュリティ、テスト、読みやすさを見ます。変更を小さく保ち、目的を説明に書くと、見落としが減ります。Claude にレビューさせる形は2つです。

書いた本人と同じコンテキストで見させると、自分が書いたコードに引きずられます。新しいコンテキストで見させるのは、そのためです。また、粗を探すよう頼まれたレビュアーは、問題が無くても何かを挙げがちです。指摘に全部従うと作り込みすぎるので、正しさや要件に関わる指摘だけを挙げさせます。

📌 試験ポイント：AI のレビューは人の判断の代わりではない。Code Review は承認もブロックもせず、マージの判断はチームに残る。レビューは、書いたときとは別の新しいコンテキストで行わせる。

リファクタリング

リファクタリングは、外から見た振る舞いを変えずに、コードの構造を良くすることです。振る舞いが変わっていないことを確かめるために、先にテストをそろえます。

• 小規模：名前の変更、関数の抽出、1ファイルの整理など。差分を一文で言えるなら、計画を立てずにそのまま頼む
• 大規模：複数のファイルやモジュールにまたがる構造の変更や、ライブラリや言語の移行。調べる、計画する、実装する、コミットする、の順に分け、Claude Code では plan モードを使う。小さく、テストできる単位で進める

対象のファイルが多い大規模な変更は、並列に分けます。Claude Code の /batch は、作業を5〜30の単位に分けた計画を示し、承認すると、単位ごとに別の worktree でサブエージェントを動かします。自分のスクリプトで claude -p をファイルごとに呼ぶこともでき、そのときは最初の2〜3件で指示を直してから全体に広げます。

📌 試験ポイント：計画を立てる価値があるのは、やり方が決まっていない、複数のファイルを変える、よく知らないコードを変える、のどれかのとき。大規模なリファクタリングは、テストをそろえ、小さな単位で進める。

2-5. Claude Application Design（8.6%）

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

インターフェースごとの指示の受け取り方

同じモデルでも、どのインターフェースから使うかで、Claude が受け取る指示の組み合わせが変わります。

• claude.ai（Web）とモバイルアプリ
  • システムプロンプト：Anthropic のものが入る。現在の日付などを渡し、コードを Markdown で書くといった振る舞いを促す。定期的に更新され、Claude API には入らない
  • 利用者が足す指示：アカウント全体の指示（Instructions for Claude）、プロジェクトの指示、Skills。プロジェクトには文書をアップロードして、ナレッジとして使わせられる
• Claude Code
  • システムプロンプト：Claude Code のものが入り、ツールの使い方と安全の指示を含む。足したいなら、起動時に --append-system-prompt を使う
  • CLAUDE.md：システムプロンプトの一部ではなく、その後のユーザーメッセージとして渡る
• Claude API
  • システムプロンプト：開発者が system に書いたものだけ。ツールや構造化出力を使うと、API がそのための指示を足す
• Claude Agent SDK
  • システムプロンプト：指定しなければ、ツールの呼び出しだけを扱う最小のプロンプトで、Claude Code の安全の指示は入らない。claude_code のプリセットを指定すると Claude Code と同じになり、append で指示を足せる。独自の文字列にもできる
  • CLAUDE.md：settingSources を省略すると、ユーザー、プロジェクト、ローカルの設定と CLAUDE.md を読み込み、CLAUDE.md の内容を会話に差し込む

Claude Desktop（デスクトップアプリ）は、チャットのほかに、Claude Code を動かす Code タブを持っています。Code タブは、ターミナルの Claude Code と同じ設定ファイルを読みます。

インターフェースをまたいで設計するときに、押さえる点は3つです。

• CLAUDE.md は、強制される設定ではなく、コンテキストとして読まれる。具体的で矛盾の無い指示ほど守られる。必ず実行したい処理は、フックにする
• 複数の階層の CLAUDE.md の指示が食い違うと、どちらに従うかの決まりは無く、Claude の解釈しだいになる。優先させたいなら、より具体的なほうのファイルに、そう明記する
• claude.ai で試したプロンプトを API に移すと、claude.ai のシステムプロンプトは付いてこない。日付のような前提も含めて、必要な指示は system に自分で書く

📌 試験ポイント：「Agent SDK で Claude Code と同じ振る舞いにしたい」は claude_code のプリセット。「CLAUDE.md の指示が守られない」は、指示を具体的にし、矛盾を消す。必ず守らせたいならフック。「claude.ai と API で振る舞いが違う」は、claude.ai のシステムプロンプトが API には入らないため。

コンテンツの境界

試験ガイドの「content boundaries」にも、中身の説明はありません。このノートでは、Claude がどこまでの内容を見られるかと、指示とデータをどう分けるか、の2つとして整理します。

Claude が見るのは、そのリクエストのコンテキストに入れたものだけです。

• Messages API は状態を持たないので、前の会話も、別の利用者の会話も、入れなければ見えない
• claude.ai のプロジェクトは、それぞれが自分のチャットの履歴とナレッジを持つ、独立した作業場所になっている
• Claude Code は、CLAUDE.md と、作業中に読んだファイルやコマンドの結果を見る

プロンプトに、指示、背景の情報、例、利用者の入力が混ざると、Claude がどれを指示として扱うかがあいまいになります。種類ごとに XML タグで囲む（<instructions>、<context>、<input> など）と、取り違えが減ります。タグの名前は、プロンプトの間でそろえます。文書が複数あるなら、<documents> の中に <document index="n"> を並べ、出典などの情報も子のタグに入れます。

利用者がアップロードした文書、Web のページ、ツールの結果のように、外から来た内容はデータとして扱い、信頼できる指示とは分けて置きます。外から来た内容に指示が紛れ込んでいても、それに従って重要な操作をさせないためです。

📌 試験ポイント：「指示と入力を取り違える」は、XML タグで種類ごとに分ける。「Claude が前の会話や別の資料を知らない」は、コンテキストに入れていないため。外から来た内容は、信頼できる指示と分けて扱う。

スキーマの設計

Claude の入出力の形は、JSON Schema で決めます。スキーマを使う場所は3つです。

• ツールの引数：input_schema に書く。Claude がツールに渡す引数の形を決める
• 構造化出力：output_config.format に、type: "json_schema" と一緒に書く。Claude の応答そのものの形を決める
• 厳密なツール使用：ツールの定義に strict: true を付ける。ツールの名前と引数を、スキーマに必ず合わせる

構造化出力と厳密なツール使用は、制約付きのデコーディング（スキーマに合わないトークンを選ばせない生成の方式）で、スキーマどおりの出力を保証します。プロンプトで頼むだけだと起きる、JSON の構文の崩れ、必須の項目の欠け、型の違いを防げます。スキーマを設計するときの注意点は、次のとおりです（2026年10月時点）。

• 使えない記法：再帰するスキーマ、数値の範囲（minimum など）、文字列の長さ（maxLength など）、minItems の 0 と 1 以外の値は使えず、400 エラーになる。SDK のヘルパーが変換してくれる場合がある。オブジェクトの additionalProperties は false にする
• 複雑さの上限：1回のリクエストで、厳密なツールは20個まで、省略できる引数は合計24個まで、anyOf などで型を複数にした引数は合計16個まで。省略できる引数を必須にする、入れ子を浅くする、厳密にするツールを絞る、で減らす
• 項目の順番：出力では、必須の項目が先、省略できる項目が後に並ぶ。順番が大事なら、すべての項目を必須にする
• 保証されない場合：安全のために断った応答（stop_reason: "refusal"）と、max_tokens で切れた応答は、スキーマに合わないことがある。enum の値の大文字・小文字も保証されないので、区別せずに比べる
• 理由を書かせる項目：「考えの過程」を書かせる項目は、reasoning_extraction の拒否で断られることがある。短い説明か根拠を求める
• 最初の遅延：初めて使うスキーマは、制約に使う文法への変換で遅くなる。変換の結果は、最後に使ってから24時間キャッシュされる

📌 試験ポイント：「JSON のパースエラーや必須項目の欠けを無くしたい」は、応答なら構造化出力、ツールの引数なら厳密なツール使用。「スキーマが複雑すぎる」という 400 エラーは、省略できる引数を減らし、入れ子を浅くする。

セッションの衛生管理（session hygiene）

Claude のコンテキストは、関係の無い会話、ファイルの中身、コマンドの出力でも埋まっていき、埋まるほど性能が落ちます。セッションの衛生管理は、今のタスクに要るものだけがコンテキストに残るように、セッションを区切り、整理することです。Claude Code のベストプラクティスは、次のやり方を勧めています。

• 別のタスクに移る：/clear でコンテキストを空にする。1つのセッションでいろいろ頼み続けると、関係の無い情報で埋まる
• 同じ誤りが直らない：2回直しても直らないのは、失敗したやり方がコンテキストに残っているため。/clear して、わかったことを入れた、より具体的なプロンプトで始め直す
• 長く続けたい：/compact <指示> で、残す内容を指定して要約する
• 途中に戻したい：Esc を2回押すか /rewind で、チェックポイントから会話やコードを戻すか、そこから要約する
• 調べ物をする：サブエージェントに調べさせ、要約だけを受け取る
• 関係の無い質問をする：/btw で聞く。答えは会話の履歴に入らない
• 仕様から実装する：仕様を書き終えたら、新しいセッションで実装させる

API で自作のアプリを作るときも、考え方は同じです。Messages API に毎回送る履歴はアプリが選ぶので、今のタスクに関係の無い古いやり取りは送りません。

📌 試験ポイント：「関係の無いタスクに移る」は /clear。「何度直しても同じ誤りに戻る」は、/clear してプロンプトを書き直す。「調べ物でメインのコンテキストを汚したくない」はサブエージェント。

プラグインの管理

Claude Code のプラグインは、Skills、サブエージェント、フック、MCP サーバーなどをまとめ、1つの単位としてインストールして読み込むディレクトリです。名前やバージョンを書いたマニフェスト（.claude-plugin/plugin.json）を持ちます。多くは、プラグインの一覧と取得元を載せたカタログであるマーケットプレイスからインストールします。

インストールするときは、スコープを選びます。

• ユーザー：自分の、このマシンのすべてのプロジェクトに効く。~/.claude/settings.json の enabledPlugins に記録される
• プロジェクト：このリポジトリで作業する全員に効く。.claude/settings.json に記録し、コミットする。有効になるだけなので、各自が一度インストールする
• ローカル：自分の、このリポジトリだけに効く。.claude/settings.local.json に記録される
• 管理：組織が配る全員に効く。管理設定に記録され、利用者は無効にも、アンインストールもできない

同じプラグインが複数のスコープにあれば、ローカル、プロジェクト、ユーザーの順に優先されます。

インストール、有効・無効の切り替え、更新、アンインストールは、/plugin の画面（Discover、Installed、Marketplaces のタブ）か、シェルの claude plugin のコマンドで行います。変更は /reload-plugins で、今のセッションに反映されます。

マーケットプレイスの自動更新がオンなら、セッションが始まった後に新しい版を取ってきます。claude-plugins-official をはじめとする Anthropic の公式のマーケットプレイスの多くは既定でオン、コミュニティ、他社、ローカルのマーケットプレイスは既定でオフです。動いているセッションは読み込んだ版を使い続け、次のセッションか /reload-plugins で新しい版に替わります。

入れる前に知っておくことは、次の3つです。

• 有効なプラグインは、使わないセッションでもコストがかかる。Claude が自分で呼び出せる Skills やサブエージェントの名前と説明は、毎ターンのコンテキストに入る。MCP サーバーは、セッションと一緒に動く
• プラグインが実行するものは、自分の権限で動く。入れる前に、信頼できるかを確かめる
• 使わないプラグインは、アンインストールせずに無効にできる

📌 試験ポイント：「チームの全員に同じプラグインを使わせる」はプロジェクトのスコープ（.claude/settings.json をコミット）、「組織で必須にする」は管理設定。「使っていないのにコンテキストが減る」は、有効なプラグインの説明が毎ターン入るためで、要らないものは無効にする。

2-6. Configuration Management（4.1%）

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

Claude を組み込んだシステムでは、コードのほかに、設定ファイル、指示のファイル、モデルの ID、プロンプト、プラグインも、振る舞いを決める構成要素です。どれもバージョン管理し、誰に効くかと、いつ変わるかを管理します。

settings.json のスコープと優先順位

Claude Code の設定（使うモデル、確認なしで実行してよいこと、読ませないファイルなど）は、JSON の設定ファイルに書きます。どのファイルに書くかで、誰に効くかが決まります。

• 管理：managed-settings.json などで、組織の配布の仕組みやサーバーからも届く。組織が配る全員に効き、セキュリティの方針やコンプライアンスの要件に使う
• ユーザー：~/.claude/settings.json に書く。自分の、このマシンのすべてのプロジェクトに効き、個人の好み（テーマ、既定のモデル、自分の権限のルール）に使う
• 共有プロジェクト：.claude/settings.json に書き、Git にコミットして、このプロジェクトで作業する全員で共有する。チームの権限、フック、プラグイン、プロジェクトに要る環境変数に使う
• プロジェクトローカル：.claude/settings.local.json に書く。Git に入れず、自分の、このプロジェクトだけに効く。自分だけの上書きや、共有する前の試しに使う

同じキーが複数の場所にあれば、優先順位の高いほうの値が使われます。高い順に、管理、コマンドライン（起動時の --settings。そのセッションだけ）、プロジェクトローカル、共有プロジェクト、ユーザーです。このほか、次の点を押さえます。

• 管理設定は、利用者のどのファイルでも、--settings でも上書きできない（安全のための一部のキーは、下の階層のより厳しい値が優先される例外がある）
• permissions.allow のようなリストのキーは、上書きではなく、各ファイルの分が合わさる
• 環境変数は、この順位とは別に、キーごとに決まる。たとえば、シェルの ANTHROPIC_MODEL は、どのファイルの model より優先される
• .claude/settings.local.json は、Claude Code が作るときに Git の除外に加える。手で作ったときは、自分で .gitignore に足す
• 共有プロジェクトのファイルに書いても効かないキーや、各自がそのフォルダを信頼するまで効かないキー（permissions.allow など）がある

📌 試験ポイント：「チームで共有する」は .claude/settings.json をコミット、「自分だけ変える」は .claude/settings.local.json、「組織で強制する」は管理設定（最優先で、利用者は上書きできない）。

CLAUDE.md の置き場所と管理

CLAUDE.md は、セッションの始めに Claude が読む指示のファイルです。置き場所で、共有の範囲が決まります。

• 管理ポリシー：OS ごとの決まった場所に置き、組織の全員に効く。Linux なら /etc/claude-code/CLAUDE.md
• ユーザー：~/.claude/CLAUDE.md に置き、自分の、すべてのプロジェクトに効く
• プロジェクト：./CLAUDE.md か ./.claude/CLAUDE.md に置き、Git でチームと共有する
• ローカル：./CLAUDE.local.md に置き、自分の、このプロジェクトだけに効く。.gitignore に足す

構成として管理するときの決まりは、次のとおりです。

• プロジェクトの CLAUDE.md は、コードと同じくコミットし、変更をレビューする。個人の好みは入れず、プロジェクトの決まりに絞る
• 毎回のセッションで要る事実（ビルドのコマンド、規約、構成、「必ず〜する」決まり）に絞る。手順の長いものや、コードの一部にだけ効くものは、Skills や、パスで絞った rules に移す
• 1ファイルを200行未満に収めるのを目安にする。長いほどコンテキストを使い、守られにくくなる
• 矛盾する指示があると、Claude はどちらかを勝手に選ぶことがある。定期的に見直して、古い指示と矛盾を消す
• 足す合図は、Claude が同じ誤りを2回した、レビューで Claude が知っておくべきことが見つかった、前のセッションと同じ訂正を打った、など
• 指示が無くても正しくできていることは消す。必ず守らせたいことは、フックに移す

📌 試験ポイント：「チームの規約」はプロジェクトの CLAUDE.md（コミットする）、「自分だけの指示」は CLAUDE.local.md か ~/.claude/CLAUDE.md。「長すぎて守られない」は、削る、Skills や rules に分ける、フックに移す。

モデルのバージョンを固定する

モデルが変わると、同じプロンプトでも出力が変わります。本番では使うモデルを固定し、新しいモデルはテストしてから、自分の都合で移ります。Claude API のモデルの ID は、次のように扱います。

• モデルの ID は、固定された版（スナップショット）を指す。同じ ID のモデルの重みや設定は変わらず、新しい版は新しい ID で出る
• Claude 4.6 の世代からは、claude-opus-4-6 のような日付の無い ID になった。日付が無くても、最新の版を指す別名ではなく、それ自体がスナップショット
• それより前のモデルは claude-sonnet-4-5-20250929 のような日付付きの ID で、Claude API では、日付を省いた claude-sonnet-4-5 のような別名も使える。別名は、その版の最新の日付付きのスナップショットを指すので、固定にはならない
• 同じ ID でも、モデルの周りの基盤（リクエストの振り分け、安全のための分類器など）の更新で、振る舞いがわずかに変わることがある
• ID ごとに、廃止と提供終了の日程がある。固定していても、提供終了の前には移る必要がある

Claude Code では、opus、sonnet、haiku のような別名が、そのときの推奨の版を指し、時とともに変わります。固定するなら、完全なモデルの名前（例：claude-opus-5-5）を指定するか、ANTHROPIC_DEFAULT_OPUS_MODEL のような環境変数で、別名が指す ID を決めます。Amazon Bedrock などのクラウドのプラットフォーム経由で展開するときは、利用者に配る前に固定します。固定しないと、別名がプラットフォームごとの既定の ID に解決され、それが最新の版より古かったり、利用者のアカウントで有効になっていなかったりします。

📌 試験ポイント：別名は指す先が変わるので、固定には完全なモデルの ID を使う。Claude 4.6 以降の日付の無い ID は、それ自体が固定された版。同じ ID でも、周りの基盤の更新で振る舞いがわずかに変わることがある。

プロンプトのバージョンを管理する

プロンプトも、振る舞いを決めるコードの一部です。Git でアプリのコードと一緒に管理し、変えるたびに評価を回して、どの版のプロンプトとどのモデルの ID の組み合わせで、どんな結果だったかを残します。問題が出たら、前の版に戻せるようにしておきます。

Claude Managed Agents では、エージェント（モデル、システムプロンプト、ツール、MCP サーバー、Skills をまとめた設定）そのものが版を持ちます。

• 設定を変えて更新すると、新しい版ができる。版の番号は1から始まり、設定が変わるたびに増える。何も変わらない更新では増えない
• 版の履歴を一覧で取れる
• セッションを作るときにエージェントの ID だけを渡すと最新の版が使われ、版を指定するとその版に固定される。新しい版を一部のセッションから順に広げられる

📌 試験ポイント：プロンプトは、モデルの ID と組にして版を管理し、変えるたびに評価する。「エージェントの設定の変更を段階的に広げたい」は、Managed Agents でセッションを版に固定する。

プラグインの依存関係

プラグインは、ほかのプラグイン（その MCP サーバーや Skills を呼ぶものなど）に依存できます。依存は、plugin.json の dependencies に書きます。

• 名前だけを書く（"audit-logger"。別のマーケットプレイスなら "名前@マーケットプレイス"）と、そのマーケットプレイスの最新の版に追従する。依存先が MCP のツールの名前を変えた版を出すと、更新した全員の環境で壊れる
• 名前と範囲を書いたオブジェクトで、"version": "~2.1.0" のようにバージョン制約を付けると、範囲内の版だけを使う。範囲はセマンティックバージョニングの書き方で、~2.1.0 なら 2.1.x、^2.0 なら 2.x
• 制約は、依存先のプラグインを置いているリポジトリの Git のタグで解決される。タグは secrets-vault--v2.1.0 のように、プラグインの名前と版を --v でつないだ形で、依存される側がリリースのたびに付ける
• 複数のプラグインが同じ依存先に制約を付けると、すべてを満たす最も新しい版になる。範囲が重ならなければ、インストールが失敗する
• 別のマーケットプレイスのプラグインへの依存は、利用者が同じスコープで既に有効にしていなければ、既定では入らない
• 別のマーケットプレイスからの依存を入れるには、インストールするプラグインがあるマーケットプレイスの marketplace.json で、allowCrossMarketplaceDependenciesOn に許可を書く
• インストールすると、依存先も同じスコープに入って有効になる。ほかのプラグインが必要としているプラグインは、無効にできない。アンインストールしても、自動で入った依存先は残り、claude plugin prune で消す
• 依存だけを並べたプラグインを作ると、チームの標準のプラグインの組を、1回のインストールで配れる

📌 試験ポイント：「依存先の更新で壊れた」は、バージョン制約を付けて、テストした範囲の版だけを使う。「チームに決まったプラグインの組を配りたい」は、依存だけを並べたプラグインを作る。

✅ 第2章 チェック問題

Q1. 毎週日曜の夜に、過去1週間の問い合わせのログ5万件をカテゴリに分け、月曜の朝の会議で使う。費用を抑えたい。Messages API を並列に呼ぶのと、Message Batches API のどちらが合うか。また、結果とリクエストはどう対応づけるか。

Q2. 思考を使うツール使用のエージェントで、tool_result を返すときに、前の応答の content から text と tool_use のブロックだけを取り出して履歴に入れている。何が問題か。

Q3. システムプロンプトの先頭に「現在時刻：2026年10月23日 10:15:32」を入れ、その後に3万トークンの社内規程を置き、規程の最後に cache_control を付けた。キャッシュがまったく当たらない。なぜか。どう直すか。

Q4. 複数の顧客企業（テナント）の契約書を Files API にアップロードして要約するアプリを、1つのワークスペースで動かしている。何が問題で、どう分けるべきか。

Q5. チームの全員に同じフックと権限のルールを使わせたい。ただし、1人だけ、自分の環境のこのプロジェクトでだけ既定のモデルを変えたい。それぞれどのファイルに書くか。また、組織として誰にも変えさせたくない設定は、どこに書くか。

Q6. Agent SDK で作ったエージェントが、Claude Code の CLI で動かしたときと振る舞いが違い、安全の指示も効いていないように見える。何が違い、どうすれば合わせられるか。

Q7. Claude Code を Amazon Bedrock 経由で社内に展開する。設定の model に別名の sonnet を書いて配ろうとしている。何が問題か。どうすべきか。

Q8. 自作のプラグインが、別のプラグインの MCP サーバーのツールを呼んでいる。依存先の新しい版でツールの名前が変わり、更新した利用者の環境で動かなくなった。再発を防ぐにはどうするか。

Q9. Claude Code で、同じ不具合の修正を3回頼み直したが、毎回同じ誤ったやり方に戻ってしまう。どうするのがよいか。

第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. 数字・固有名詞の暗記リスト

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