ドメイン別 習熟度

各ドメインのクイズ正答率と配点ウェイトを表示しています

試験概要

学習の始め方

左メニューの M0: 導入 から順番に進めてください。各モジュールには解説とクイズが含まれています。クイズに回答すると進捗が自動的に記録されます。

Claudeとは何か

Claude（クロード）は、Anthropic社が開発したAIアシスタントです。人間が書いた大量のテキストを学習し、質問への回答、文章の作成、分析、コード生成など、幅広いタスクをこなすことができます。

なぜ「Claude」が注目されるのか

AIアシスタントは複数の会社から提供されていますが、Claudeには以下のような特徴があります。

安全性への注力：Anthropicは「AIの安全性」を企業理念の中心に据えています。Claudeは、有害な出力を避け、正確で信頼できる応答を提供することを重視して設計されています。

長文の処理能力：Claudeは非常に長い文章を一度に読んで理解できます。これを「コンテキストウィンドウ」と呼びます。最新モデルではClaude Opus 4.6とSonnet 4.6が100万トークン（約750,000語）、Claude Haiku 4.5が200,000トークンのウィンドウを持ちます。

ツール連携：Claudeは、外部のツールやデータベースと連携して、検索・計算・ファイル操作などを行うことができます。これが試験で重要なテーマとなります。

Claudeのモデル一覧

Claudeには用途に応じた複数のモデルがあります。試験では各モデルの位置づけを理解しておくことが求められます。

Anthropicの製品群

Anthropicは、Claudeを様々な方法で利用できるようにしています。それぞれのインターフェースは異なりますが、裏側では同じClaudeモデルが動いています。

CCA-F試験との関係

試験では特にClaude APIとClaude Codeの理解が重要です。ユーザーとして使うだけでなく、「Claudeを使ったシステムをどう設計するか」というアーキテクト視点が求められます。

CCA-F 試験の構成

CCA-F試験は5つの「ドメイン（出題領域）」から構成されています。各ドメインには配点のウェイトがあり、重みづけを意識した学習が効率的です。

5つのドメインと配点

合格に必要なスコア

合格ラインは720/1000点です。つまり、すべてのドメインで完璧を目指す必要はなく、得意分野を確実に取り、苦手分野も基本を押さえるという戦略が有効です。

60問を120分で解くため、1問あたり約2分が目安です。わからない問題に時間をかけすぎず、マークして先に進む判断も重要です。

6つの試験シナリオ

CCA-F試験の大きな特徴は、シナリオベースであることです。60問すべてが、実際のビジネスユースケースを想定した「シナリオ」に基づいて出題されます。

基本用語集

この学習を進める上で頻出する用語をまとめました。試験は英語のため、英語表記も併記しています。

確認クイズ

Claudeの製品ラインナップ

Module 0では「Claudeは様々な方法で使える」と学びました。ここでは、各製品の特徴と対象ユーザーを詳しく見ていきます。

イメージとしては、Claudeは「優秀なスタッフ」で、製品群は「そのスタッフに仕事を頼む窓口」です。窓口の種類によって、頼み方や頼める範囲が変わります。

誰でも使える製品

開発者向け製品

チーム・企業向け製品

料金プラン一覧

APIとSDK — プログラムからClaudeを使う

Module 0で「APIはレストランの出前注文窓口のようなもの」と紹介しました。ここでは、その注文の仕組みをもう少し詳しく見ていきましょう。

Messages API（メッセージAPI）

Claude APIの中核となるのがMessages APIです。プログラムからClaudeに「メッセージ」を送り、回答を受け取る仕組みです。

APIを利用するには、3つの必須ヘッダー（送り状）が必要です。

その他の主要API

SDK（Software Development Kit）とは

SDKは「開発キット」のこと。APIを直接呼び出すのは少し手間がかかるため、SDKがその手間を代行してくれます。料理に例えると、APIが「食材と調理器具」なら、SDKは「食材セット＋レシピ付き」のようなものです。

サードパーティプラットフォーム

Claude APIはAnthropicに直接アクセスするだけでなく、大手クラウドプラットフォーム経由でも利用できます。

Claude Code — AIコーディングエージェント

Claude Codeは、CCA-F試験のドメイン2（配点20%）に直結する重要な製品です。Module 7-8で詳しく学びますが、ここでは全体像を把握しましょう。

Claude Codeの主要機能

CLAUDE.md — 設定ファイル

Claude Codeの振る舞いをカスタマイズするためのMarkdownファイルです。プロジェクトのルートに置くと、セッション開始時に自動で読み込まれます。

フック（Hooks）とMCP

Claude Codeの拡張機能として、フックとMCP統合があります。

Claude Agent SDK

Claude Codeの能力を「ライブラリ」として提供するものです。開発者が自分のプログラムの中にClaude Codeと同等の機能を組み込めます。

製品の使い分けガイド

「どの製品をいつ使うべきか」は、CCA-F試験で繰り返し問われるテーマです。ユースケースに応じた最適な選択ができるようになりましょう。

ユーザータイプ別の推奨製品

モデル選択の指針

Module 0で学んだモデル一覧を、より実践的な視点で整理します。

コスト最適化の考え方

確認クイズ

プロンプトエンジニアリングとは

プロンプトエンジニアリング（Prompt Engineering）とは、AIに対して的確な指示を設計する技術です。料理に例えるなら、AIは腕の良いシェフ。でも「何かおいしいもの作って」と言っても期待通りの料理は出てきません。「鶏もも肉を使った和風の煮込み、4人分、30分以内で」と伝えるほど、期待に合う結果が返ってきます。

原則1: 明確かつ直接的に（Be Clear and Direct）

Claudeへの指示は、具体的であればあるほど良い結果が得られます。曖昧さを排除し、何をしてほしいかを明確に伝えましょう。

原則2: コンテキスト（背景）を伝える（Add Context）

「なぜその指示を出しているのか」という背景を添えると、Claudeはより適切な判断ができます。

例えば「省略記号（...）を使わないで」と言うだけでなく、「この文章は音声読み上げソフトで再生されるため、省略記号は読み上げできません。代わりに文を完結させてください」と伝えると、Claudeは意図を理解した上で適切に対応できます。

原則3: 「やるな」ではなく「代わりにこうして」

否定形の指示は意外と伝わりにくいものです。「専門用語を使うな」より「中学生にも分かる言葉で説明してください」の方が、Claudeは正確に従えます。

プロンプトを構造化する

プロンプトが長くなると、Claudeがどこが指示でどこがデータなのか混乱することがあります。そこで活躍するのがXMLタグによる構造化です。

XMLタグ構造化（XML Tag Structuring）

XMLタグは、プロンプト内の要素を「ここからここまでが指示」「ここからここまでがデータ」と明確に区切る方法です。書類にタブを付けて整理するイメージです。

具体例:

<documents>
  <document index="1">
    <source>quarterly_report.pdf</source>
    <document_content>
      {{QUARTERLY_REPORT}}
    </document_content>
  </document>
</documents>

<instructions>
上記の四半期報告書を分析し、売上の傾向を3つ挙げてください。
各傾向は1文で簡潔に。
</instructions>

Few-shotプロンプティング（Few-Shot Prompting）

「百聞は一見にしかず」 — Claudeにも同じことが言えます。具体的な入出力例を2〜5個見せることで、望む形式やトーンをClaudeに伝える最も信頼性の高い手法です。

良い例の3条件:

• 関連性: 実際のユースケースに近い例を選ぶ
• 多様性: エッジケース（境界例）も含める
• 構造化: <example>タグで囲み、指示本文と区別する

具体例:

以下の製品レビューの感情を分析してください。

<examples>
  <example>
    <input>「この商品は最高です！毎日使っています」</input>
    <output>感情: ポジティブ / 信頼度: 高</output>
  </example>
  <example>
    <input>「まあまあかな。期待したほどではない」</input>
    <output>感情: 中立〜やや否定 / 信頼度: 中</output>
  </example>
  <example>
    <input>「最悪。二度と買わない」</input>
    <output>感情: ネガティブ / 信頼度: 高</output>
  </example>
</examples>

<input>「デザインは好きだけど、すぐ壊れた」</input>

長文コンテキストの配置ルール（Long Context Prompting）

20,000トークン以上の長い文書をClaudeに読ませる場合、データをプロンプトの上部に、指示を下部に配置すると、最大30%品質が向上するとAnthropicが報告しています。

イメージとしては、まず資料を机に広げてから（上部=データ）、「この中から要点を見つけて」と指示する（下部=質問）流れです。

高度なプロンプトテクニック

Chain-of-Thought（思考の連鎖）

人間も複雑な問題を解くとき、いきなり答えを出さず順を追って考えます。Claudeも同じで、「ステップバイステップで考えてください」と指示するだけで、推論の正確さが大きく向上します。

Chain-of-Thoughtの実装方法:

プロンプトチェーニング（Prompt Chaining）

一つの大きなタスクを複数の小さなステップに分割し、各ステップの出力を次のステップの入力にする手法です。工場の組立ラインのように、各工程で品質チェックができる利点があります。

最も一般的なパターン: 自己修正（Self-Correction）

1. ステップ1: ドラフトを生成する
2. ステップ2: 基準に照らしてレビューする
3. ステップ3: レビュー結果に基づいて改善する

構造化出力（Structured Output）

Claudeの出力をJSON等の決まった形式に制御する技術です。人間が読むだけなら自由な文章でも良いですが、プログラムが処理する場合は正確なフォーマットが必要です。

テクニック選択の判断基準

用語集 — Module 2

試験は英語で実施されます。日本語で概念を理解したら、英語の用語名もセットで覚えましょう。

確認クイズ — Module 2

5つの質問に答えて、理解度を確認しましょう。

システムプロンプトとは何か

システムプロンプト（System Prompt）とは、AIに対して「あなたはどう振る舞うべきか」を伝える舞台裏の指示書です。レストランに例えると、お客さんが注文する料理が「ユーザープロンプト」、キッチンに貼ってある調理マニュアルや店のルールが「システムプロンプト」にあたります。

お客さん（ユーザー）には見えませんが、シェフ（Claude）の料理の仕方を根本から決める、非常に重要な存在です。

システムプロンプト vs ユーザープロンプト

この2つは似ているようで、役割が大きく異なります。

なぜシステムプロンプトが重要なのか

システムプロンプトは、Claudeの振る舞いを根本から制御する最も強力な手段です。同じClaudeモデルでも、システムプロンプトを変えるだけで、丁寧なカスタマーサポート担当にも、厳格なコードレビュアーにもなります。

本番環境のアプリケーションでは、システムプロンプトの設計品質がユーザー体験と安全性の両方を左右します。「とりあえず動く」プロンプトではなく、意図的に設計されたプロンプトが求められるのです。

システムプロンプトの設計パターン

効果的なシステムプロンプトには、いくつかの定番パターンがあります。これらを組み合わせることで、Claudeの振る舞いを精密にコントロールできます。

パターン1: ペルソナ/ロール設定（Role Assignment）

Claudeに「あなたは〇〇です」と役割を与えるパターンです。たった1行でも、応答のトーンや専門性が大きく変わります。

パターン2: 制約条件の設定（Constraints）

「やってはいけないこと」を伝えるときは、禁止ではなく推奨の形で書くのがAnthropicの推奨です。

パターン3: 出力形式の指定（Output Format）

Claudeの出力形式を制御するには複数の方法があります。

• Structured Outputs：JSONスキーマを指定し、出力形式を厳密に強制する機能（Module 4で詳しく学びます）
• XMLタグでの出力指示：出力にタグを使って構造を示す
• システムプロンプトでの指示：「前置きなしで直接回答せよ」「箇条書きで回答せよ」など

パターン4: 行動制御（Behavior Control）

Claudeに積極的に行動させるか、慎重に行動させるかを制御するパターンです。

XMLタグによるプロンプト構造化

長いシステムプロンプトを整理するために、AnthropicはXMLタグの使用を推奨しています。これは本の「目次」のようなもので、Claudeが指示の各部分を正確に区別できるようになります。

なぜXMLタグが有効なのか

人間にとっての「見出し」や「箇条書き」と同じように、XMLタグはClaudeにとっての明確な区切りとして機能します。特に以下の効果があります：

• 指示と入力データを明確に分離できる
• 例（few-shot examples）と本番の指示を区別できる
• 長いプロンプトの見通しが良くなり、保守性が向上する

Few-shot Prompting（少数例学習）

Claudeに「こういう入力にはこう応答してほしい」という例を示す手法をFew-shot Promptingと呼びます。料理教室で「お手本の盛り付け」を見せるようなものです。

Anthropicは3〜5個の例が最適としています。例が多すぎると逆に柔軟性が失われることがあります。

長文データの配置ルール

20,000トークン以上の長い参照データをプロンプトに含める場合、プロンプトの先頭に配置し、質問やクエリは末尾に置くのがベストプラクティスです。これにより、回答品質が最大30%向上するとAnthropicは報告しています。

思考プロセスの制御（Extended Thinking）

Claudeには「考える時間」を与える機能があります。複雑な推論が必要なタスクでは、thinkingパラメータを設定して、Claudeに内部的な推論ステップを踏ませることができます。

本番環境でのプロンプト管理と安全性

システムプロンプトは「書いて終わり」ではありません。本番環境では、管理・最適化・安全性の3つの観点が求められます。

プロンプトテンプレートと変数

本番環境では、プロンプトを固定部分（指示・制約）と可変部分（ユーザー入力・検索結果）に分離します。可変部分は{{変数名}}のプレースホルダーで表現します。

プロンプトキャッシング（Prompt Caching）

システムプロンプトのように毎回同じ内容を送る部分は、キャッシュ（一時保存）することでコストとレイテンシ（応答時間）を大幅に削減できます。

キャッシュの対象コンテンツは、プロンプトの先頭に配置するのがベストプラクティスです。

プロンプトインジェクション対策

プロンプトインジェクション（Prompt Injection）とは、悪意のあるユーザーが入力を通じてシステムプロンプトの指示を上書きしようとする攻撃です。たとえるなら、レストランのお客さんが「今日から営業時間を変更する」と言い出すようなものです。

主な対策手法は以下の通りです：

品質保証: Multi-pass Review

AIの出力品質を向上させる手法として、Multi-pass Review（多段階レビュー）があります。これは同じClaudeモデルでも、独立した別セッションでレビューさせる方法です。

重要なのは、同一の会話セッション内でのセルフレビューではなく、独立したレビューインスタンスを使うことです。同じ会話内では自分の出力に引っ張られやすく、客観的なレビューになりにくいためです。

Module 3 用語集

このモジュールで登場した重要用語をまとめました。試験は英語のため、英語表記も確認しておきましょう。

確認クイズ

構造化出力（Structured Output）とは

AIに質問すると、通常は自由な文章で回答が返ってきます。しかし、その回答をプログラムで自動処理したい場合、「自由な文章」では困ります。たとえば、顧客メールから「名前」「問い合わせ内容」「緊急度」を抜き出したいとき、AIが毎回違う書き方で返してきたら、プログラムが正しく読み取れません。

そこで登場するのが構造化出力（Structured Output）です。AIの回答をJSONなどの決まった形式で返させることで、プログラムが確実にデータを読み取れるようにします。

なぜ構造化出力が必要なのか

AIの回答をプログラムに渡す場面を想像してみてください。たとえば、AIが商品レビューの感情分析をして、その結果をデータベースに保存したい場合です。

Claudeにおける構造化出力の進化

かつては、AIに「JSONで返してください」とプロンプトでお願いする方法しかありませんでした。しかし、AIが時々フォーマットを無視してしまう問題がありました。

現在のClaudeでは、制約付きデコーディング（Constrained Decoding）という技術により、スキーマ（設計図）通りのJSONが100%保証されます。

構造化出力を得る2つの方法

Claude APIで構造化出力を得るには、大きく2つのアプローチがあります。それぞれ「どこに出力されるか」「どんな場面に向いているか」が異なります。

アプローチ1: JSON Outputs（output_config方式）

Claudeの応答そのものをJSON形式で返させる方式です。「記入式のフォーマット用紙を渡して、その通りに回答させる」イメージです。

API呼び出し時に output_config.format パラメータで json_schema を指定し、どんな形式のJSONが欲しいかを定義します。Claudeの応答テキスト（response.content[0].text）にJSONが入ります。

アプローチ2: Strict Tool Use（strict: true 方式）

ツール定義（Tool Definition）に strict: true を追加し、ツール呼び出しのパラメータがスキーマ通りであることを保証する方式です。「自動販売機のコイン投入口」のように、決まった形式のデータしか出力されません。

応答は tool_use コンテンツブロックの input フィールドに入ります。

どちらを使うべきか（試験頻出）

Prefill技法（歴史的知識）

かつてはAssistantメッセージに { を先頭に入れることで、Claudeの出力をJSON形式に強制する「Prefill（プレフィル）」という技法が使われていました。

JSON Schemaによるスキーマ設計

構造化出力を使うには、「どんな形のJSONが欲しいか」を定義するJSON Schema（設計図）が必要です。これは「記入用紙のフォーマット設計図」のようなものです。

基本的なスキーマの構造

JSON Schemaでは、「この項目はこんなデータ型で、必須かどうか」を定義します。

使用できるデータ型

サポートされない制約（試験注意）

JSON Schemaの仕様にはあるが、Claude APIの構造化出力ではサポートされない制約があります。これは試験でよく問われるポイントです。

additionalProperties: false の重要性

スキーマ定義では、additionalProperties: false を常に設定することがベストプラクティスです。これは「余白への書き込み禁止」にあたります。設定しないと、定義していないフィールドが予期せず出力に含まれる可能性があります。

SDK連携：Pydantic と Zod

実務では、JSON Schemaを手書きする代わりに、プログラミング言語のライブラリを使ってスキーマを自動生成できます。

実践的な活用パターン

構造化出力は、さまざまなビジネスシーンで活用されています。CCA-F試験のシナリオにも直結するパターンを見ていきましょう。

パターン1: データ抽出（Extraction）

非構造化テキスト（自由な文章）から必要な情報を取り出すパターンです。試験のシナリオ6「構造化データ抽出」に対応します。

パターン2: 分類（Classification）

テキストをカテゴリに分類するパターンです。enum を使って選択肢を限定します。

パターン3: エンティティ抽出（Entity Extraction）

テキストから人名・地名・日付・金額などの「エンティティ（実体）」を識別して取り出すパターンです。

パターン4: エージェントのツール呼び出し

AIエージェントが外部ツール（API・データベース等）を呼び出す際、パラメータの形式を保証するパターンです。Strict Tool Useが適しています。

信頼性を高めるベストプラクティス

検証-再試行ループ（Validation-Retry Loop）

構造化出力の品質をさらに高めるために、マルチパス検証アーキテクチャが推奨されます。

マルチパスレビュー（Multi-pass Review）

構造化出力の品質をさらに高めるために、マルチパスレビューという手法があります。これは「1回のAI呼び出しで終わり」ではなく、複数回のパス（処理）を通して出力を検証・改善するアプローチです。

身近な例で言えば、レポートを書いた後に「自分で読み返す」→「同僚にチェックしてもらう」→「上司の最終確認」という多段階の確認プロセスに似ています。

なぜマルチパスレビューが必要なのか

AIは非常に優秀ですが、1回の出力で常に完璧な結果を返すとは限りません。特に以下のような場面では、マルチパスレビューが効果的です。

• 高精度が求められる場面 — 医療データの抽出、法務文書の分析など、ミスが許されない場面
• 複雑な構造化出力 — 多くのフィールドを持つJSONで、すべてが正確であることを確認したい場面
• ビジネスルールの遵守 — 特定の制約条件を確実に満たす必要がある場面

3つの実装パターン

マルチパスレビューには、主に3つの実装パターンがあります。場面に応じて使い分けましょう。

パターン1: 自己評価（Self-Evaluation）

AIが自分の出力を「もう一度見直す」パターンです。同じAIに「この出力は正しいですか？問題があれば修正してください」と依頼します。

手軽に導入できますが、同じモデルが同じバイアスを持つ可能性があるため、完全な検証には限界があります。「自分で自分の宿題を採点する」ようなものです。

パターン2: クロスチェック（Cross-Check）

出力を生成したインスタンスとは別の独立したAIインスタンスで検証するパターンです。Module 4の「検証-再試行ループ」で紹介した方法がこれにあたります。

「別の担当者にダブルチェックしてもらう」イメージで、生成者と検証者を分離することで、同じバイアスに陥るリスクを軽減します。

パターン3: 段階的精査（Progressive Refinement）

最初は大まかな構造を生成し、パスを重ねるごとに詳細を追加・精査していくパターンです。

たとえば、長い契約書からデータを抽出する場合：

• 第1パス: 主要項目（契約者名、金額、期間）を抽出
• 第2パス: 条件・例外事項を補完
• 第3パス: 全体の整合性と漏れを最終確認

一度にすべてを完璧に処理しようとするより、段階を分けることで各パスの精度が上がります。

3パターンの比較

品質向上のベストプラクティス

Batches APIによるコスト最適化

構造化出力を大量に処理したい場合、1件ずつリアルタイムでAPI呼び出しをするのはコストがかかります。そこで活用したいのがMessage Batches API（メッセージバッチAPI）です。

たとえば、1万件の商品レビューを分類したい場合、通常のAPIで1件ずつ処理するよりも、まとめて一括処理する方がコストが半分になります。「宅配便を1個ずつ送る」のではなく「まとめてトラック1台で運ぶ」イメージです。

Batches APIの仕組み

Batches APIの処理フローは以下の通りです。

• ステップ1: バッチ作成 — 処理したいリクエスト（最大10万件）をまとめて送信
• ステップ2: 非同期処理 — Anthropicのサーバーが順次処理（この間、待つ必要なし）
• ステップ3: 結果取得 — 処理完了後に結果を一括取得（通常数分〜数時間、最大24時間）

料金体系

バッチ処理に適したユースケース

Batches APIは「すぐに結果が必要ない」大量処理に最適です。

同期APIとの使い分け判断基準

コスト最適化の実践パターン

Pydantic実践 — 型安全な構造化出力

Module 4のスキーマ設計セクションで、PydanticがPythonクラスからJSON Schemaを自動生成できることを紹介しました。ここでは、実際にPydanticをClaude APIと連携させて型安全な構造化出力を得る方法を詳しく見ていきましょう。

Pydanticを使うと、「JSON Schemaを手書きする」手間がなくなり、さらにPythonの型システムで出力データを安全に扱えるようになります。「手書きの伝票」から「入力フォーム付きの業務システム」にアップグレードするイメージです。

基本的な使い方: messages.parse()

Anthropic Python SDKにはmessages.parse()という専用メソッドがあります。通常のmessages.create()と異なり、レスポンスを自動的にPydanticモデルに変換してくれます。

tool_use + Pydanticの組み合わせ

PydanticはJSON Outputs（output_config方式）だけでなく、Strict Tool Useとも組み合わせられます。ツールの入力スキーマをPydanticクラスで定義することで、ツール呼び出しのパラメータも型安全に扱えます。

Field制約とdescription自動変換

PydanticのField()で設定した制約（最小値、最大値など）は、Claude APIのJSON Schemaではサポートされていません。しかし、SDKが自動的にdescription（説明文）に変換してくれます。

バリデーションとエラーハンドリング

Pydanticの大きなメリットは、自動バリデーション（検証）です。Claudeの出力がPydanticの制約に違反した場合、ValidationError（バリデーションエラー）が発生します。

Module 4 用語集

構造化出力に関する重要用語をまとめました。試験は英語のため、英語表記も覚えておきましょう。

確認クイズ

Tool Use（ツール利用）とは何か

Claude自体は、天気を調べたりデータベースを検索したりすることができません。しかし「ツール」を定義して渡すことで、Claudeは「このツールを使いたい」と意思表示し、外部の機能を間接的に利用できるようになります。

これは、レストランの注文に似ています。お客さん（ユーザー）が「今日のおすすめは？」と聞くと、ウェイター（Claude）は自分では厨房に入れませんが、「シェフに聞いてきます」と伝票を書いて渡すことができます。開発者のプログラムがその伝票を受け取り、実際にシェフ（外部API）に問い合わせて結果を返します。

なぜTool Useが重要なのか

Claudeは学習データに基づいて回答しますが、以下のようなことは単独ではできません。

• リアルタイム情報の取得 — 今日の天気、最新の株価など
• 外部システムへの操作 — メール送信、データベース更新、ファイル作成
• 計算の正確性 — 複雑な数値計算を電卓ツールに委託
• 社内データへのアクセス — 顧客管理システム、在庫管理など

ツールを使うことで、Claudeは「知識」だけでなく「行動」もできるAIアシスタントになります。これがエージェント（Agent）の基盤技術です。

Tool Useの全体像

Tool Useは、Messages APIのtoolsパラメータを通じて利用します。開発者がAPIリクエスト時に「利用可能なツールの一覧」を定義して渡すと、Claudeはユーザーの質問に応じて適切なツールを選択し、呼び出しに必要な引数を生成します。

ツール定義の設計

ツールを使うには、まず「どんなツールがあるか」をClaudeに伝える必要があります。これをツール定義（Tool Definition）と呼びます。ツール定義はJSON形式で記述し、APIリクエストのtoolsパラメータに渡します。

ツール定義の3つの要素

すべてのツール定義は、以下の3つの要素で構成されます。

ツール定義の具体例

たとえば「天気を取得するツール」は以下のように定義します。

{
  "name": "get_weather",
  "description": "指定された場所の現在の天気情報を取得する。
    ユーザーが天気について質問した場合に使用する。",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "都市名（例: Tokyo, Japan）"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "温度の単位。デフォルトはcelsius"
      }
    },
    "required": ["location"]
  }
}

descriptionの書き方 — 最も重要な要素

Claudeがどのツールを使うかを判断する最大の材料はdescriptionです。履歴書の「職務経歴」のようなもので、ここが曖昧だとClaudeは正しくツールを選べません。

input_schemaの設計パターン

パラメータの定義にもベストプラクティスがあります。

• enum（列挙型）を活用して、選択肢を限定する（例："enum": ["celsius", "fahrenheit"]）
• required（必須）で必ず指定してほしいパラメータを明示する
• descriptionを各パラメータにも書く — 型だけでは意味が伝わらない
• パラメータ名は明確にする（qよりsearch_queryが良い）

ツール実行フローと制御

Tool Useは、4つのステップで動作します。この流れを正確に理解することがCCA-F試験の鍵です。

4ステップの通信フロー

この流れを図にすると、以下のようになります。

tool_use_id — リクエストの紐付け

Claudeがツール呼び出しを返す際、各ツール呼び出しに一意のtool_use_id（例：toolu_abc123）が付与されます。開発者がtool_resultを返す際は、このIDを必ず一致させる必要があります。荷物の追跡番号のようなもので、「どの注文に対する回答か」を紐付けます。

並列ツール呼び出し（Parallel Tool Use）

Claudeは1回のレスポンスで複数のツールを同時に呼び出すことがあります。たとえば「東京と大阪の天気を教えて」と聞くと、get_weatherを2回分まとめて返すことがあります。開発者は両方のtool_resultを1つのリクエストにまとめて返します。

連鎖ツール呼び出し（Chained Tool Use）

ツールの結果を見て、さらに別のツールを呼ぶこともあります。たとえば「顧客Aの最新注文を確認して、在庫があれば発送手続きをして」という指示では、まず注文検索ツール → 次に在庫確認ツール → 最後に発送ツールと、段階的に進みます。

Tool Choice — ツール選択の制御

開発者はtool_choiceパラメータで、Claudeのツール選択を制御できます。

Strict Mode（厳密モード）

ツール定義に"strict": trueを追加すると、Claudeの出力がinput_schemaに100%準拠することが保証されます。

エラーハンドリングとアンチパターン

ツールの実行は常に成功するとは限りません。APIがダウンしていたり、パラメータが不正だったりする場合のエラー処理もTool Useの重要な要素です。

is_error フラグ

ツール実行でエラーが発生した場合、tool_resultに"is_error": trueを設定してClaudeに返します。

tool_resultの返却は必須

Claudeがtool_useを返したら、必ず対応するtool_resultを返す必要があります。これを省略するとAPIエラーになります。注文した料理が来なければお客さんは困ります。エラーであっても「エラーだった」という結果を返すことが必要です。

ツール設計のアンチパターン

system promptとの連携

system promptでツールの使い方を補足的に指示することも有効です。たとえば「ユーザーが価格を聞いた場合は必ずget_pricingツールを使い、推測で回答しないこと」のような指示を加えることで、ツール使用の精度を高められます。

プロンプトキャッシングとTool Use

ツール定義は毎回のリクエストに含めますが、プロンプトキャッシング（Prompt Caching）を使えばツール定義部分をキャッシュし、コストとレイテンシを削減できます。tools配列にcache_controlを付与することで、繰り返し送信されるツール定義のトークンコストを抑えられます。

ツール説明文（description）のLLM最適化

Module 5の前半で「descriptionがツール選択の最大の判断材料」と学びました。ここでは一歩進んで、LLMの視点から最適な説明文をどう書くかを深掘りします。

Claudeはdescriptionをどう「読んで」いるか

Claudeがツールを選ぶ仕組みを、図書館の司書にたとえてみましょう。ユーザーが「最新の売上データを見たい」と言ったとき、Claudeは手元にある全ツールの説明文を一通り「読んで」、最も適切なツールを選びます。

このとき、Claudeは以下の順序で判断しています。

1. ツール名（name）で大まかな候補を絞る — get_sales_dataは候補に入る、send_emailは外す
2. 説明文（description）で最終判断する — 「月次売上データ」なのか「リアルタイム売上」なのか
3. パラメータ定義で引数を組み立てる — 必要な情報（期間、部門など）を判断

つまり、descriptionはツール選択の「決定打」です。名前が同じでも説明が曖昧なら選ばれません。

良い説明文の5つの要素

悪い説明文 vs 良い説明文 — 実例比較

description最適化チェックリスト

• 1文目で「何をするツールか」が明確に分かるか
• 似た機能の他ツールとの違い・使い分けが明記されているか
• 戻り値の形式や件数制限が記載されているか
• 前提条件（「先に別のツールで○○を取得すること」）が明記されているか
• 曖昧な表現（「データを処理する」「情報を取得する」）を避けているか

構造化エラーハンドリング（isError / isRetryable）

前半のセクションでis_errorフラグの基本を学びました。ここでは、本番環境で重要になる構造化されたエラーレスポンスの設計を深掘りします。

なぜ「構造化」が必要なのか

病院の診察にたとえると、「具合が悪い」と言うだけでは医師は判断できません。「熱が38.5度あり、昨日から咳が出ている」と伝えれば、適切な対応ができます。エラーレスポンスも同じで、何が、なぜ、どうすれば直るかを構造的に伝えることで、Claudeはより賢い対応ができます。

エラーレスポンスの設計パターン

// tool_resultの内容として返すJSON
{
  "error": {
    "type": "invalid_parameter",
    "message": "都市名 'Toko' が見つかりません",
    "isRetryable": true,
    "suggestion": "正しい都市名を入力してください（例: Tokyo）"
  }
}

isRetryable — リトライすべきかの判断

エラーには「やり直せるもの」と「やり直しても無駄なもの」の2種類があります。

自動販売機にたとえると、「お釣りが足りません」はリトライ可能（少額の商品を選べばよい）ですが、「この商品は販売終了です」はリトライ不可（何回ボタンを押しても出てきません）です。

エラータイプの分類

エラーハンドリングのベストプラクティス

• エラーメッセージは具体的に — 「エラーが発生しました」ではなく「顧客ID 'ABC' は無効な形式です。数字6桁の形式を指定してください」
• 次のアクションを示す — Claudeが何をすべきかの「ヒント」を含める
• リトライ可否を明示する — isRetryable情報でClaudeの判断を補助する
• エラーでも必ずtool_resultを返す — 無応答はAPIエラーの原因になる
• 機密情報をエラーに含めない — 内部のスタックトレースやDB接続文字列を返さない

ツール分配（Tool Distribution）と管理

実際のアプリケーションでは、数十個以上のツールを扱うことが珍しくありません。このとき、すべてのツールを毎回Claudeに渡すのではなく、必要なツールだけを適切に配分する戦略が重要になります。

なぜツール分配が必要なのか

レストランのメニューを想像してください。100ページのメニューを渡されたら、注文を決めるのに時間がかかりますよね。Claudeも同じで、渡されるツールが多すぎると、選択に迷い、応答速度が低下し、間違ったツールを選びやすくなります。

ツール分配の3つの戦略

カテゴリ別グルーピングの実践例

ECサイトのサポートボットが30個のツールを持つ場合：

ツール分配における注意点

• 必要なツールを渡し忘れない — フィルタリングが厳しすぎると、必要なツールが欠落して機能しなくなる
• カテゴリ横断のツール — 「ユーザーへのメッセージ送信」のように複数カテゴリで使うツールは共通セットに含める
• tools配列の順序 — 重要なツールを先頭に置くと、Claudeの注目を集めやすくなる

推論オーバーロード防止

ツールの数が増えすぎると、Claudeのパフォーマンスが劣化する現象を推論オーバーロード（Inference Overload）と呼びます。

なぜオーバーロードが起きるのか

Claudeに渡すツール定義は、すべてコンテキストウィンドウ（会話の「作業スペース」）を消費します。ツールが10個なら数百トークンで済みますが、50個になると数千トークンに達し、本来の会話やユーザーの質問に使えるスペースが減ります。

また、選択肢が多いほどClaudeの「迷い」が増えます。テストで4択なら正答率が高いですが、20択になると間違えやすくなるのと同じです。

オーバーロードの影響

オーバーロードを防ぐ5つの対策

ツール統合の具体例

顧客管理で以下の3つのツールがある場合：

• search_customer_by_name — 名前で検索
• search_customer_by_email — メールで検索
• search_customer_by_phone — 電話番号で検索

これらを1つのsearch_customerツールに統合し、search_typeパラメータ（enum: ["name", "email", "phone"]）で切り替える方が効率的です。3ツール→1ツールに削減でき、Claudeの選択も簡単になります。

推奨ツール数の目安

• 1リクエストあたり10-20個程度 — この範囲なら選択精度は安定
• 20個を超える場合 — ツール分配やカテゴリ分けの導入を検討
• 50個以上 — パフォーマンスへの影響が顕著になるため、アーキテクチャの見直しが必要

tool_choiceの高度な使い方

前半でtool_choiceの4つのモード（auto / any / tool / none）を学びました。ここでは、これらをワークフロー制御に応用する高度なパターンを見ていきます。

tool_choiceでワークフローを制御する

tool_choiceは単なるオプション設定ではなく、Claudeの行動を「プログラム的に」制御する強力な道具です。料理のレシピのように、「この段階ではこの作業をしなさい」と指定できます。

パターン1: 強制ツール実行

tool_choice: {"type": "tool", "name": "特定ツール名"}を使うと、Claudeは必ずそのツールを呼び出します。

パターン2: ステップバイステップのワークフロー

複数のステップを順番に実行する場合、各ステップでtool_choiceを切り替えることで、確実な処理フローを構築できます。

パターン3: ツール結果のバリデーション

1. Claudeがデータ抽出ツールで情報を取得
2. クライアント側で結果を受け取り、tool_choice: {"type": "tool", "name": "validate_output"}で検証ツールを強制呼び出し
3. 検証結果に問題があれば、修正を促す

この「抽出→検証→修正」のループは、正確性が求められる業務で重要なパターンです。

tool_choice: noneの活用場面

noneは「ツールを渡しているが使わせない」モードです。

• 最終回答の生成 — ツール結果を取得した後、最終的なテキスト回答だけを生成させたい場合
• 確認フェーズ — 「ツールを使わずに、ユーザーに確認を取ってから次に進む」という流れを強制する場合
• テスト — ツールなしでClaudeがどう回答するかを確認する場合

ツール説明文（description）の実践最適化

Anthropic公式ドキュメントでは、descriptionを「新しいチームメンバーにツールを説明するつもりで書く」ことが推奨されています。暗黙知を明示化し、LLMがツール選択で迷わない記述を目指します。

公式推奨: 説明文に含めるべき5要素

公式ドキュメントの"Best practices for tool definitions"では、以下を最低限含めることが明記されています。

新機能: input_examples（入力例の提供）

2025年以降のAPIでは、ツール定義にinput_examplesフィールドを追加できるようになりました。これは、Claudeに「正しいツール呼び出しの具体例」を示す機能です。

{
  "name": "search_customer",
  "description": "顧客を名前・メール・電話番号で検索する。部分一致で最大20件返す。顧客IDが既知の場合はget_customer_by_idを使うこと。",
  "input_schema": {
    "type": "object",
    "properties": {
      "search_type": {
        "type": "string",
        "enum": ["name", "email", "phone"],
        "description": "検索キーの種類"
      },
      "query": {
        "type": "string",
        "description": "検索キーワード（部分一致対応）"
      }
    },
    "required": ["search_type", "query"]
  },
  "input_examples": [
    {"search_type": "name", "query": "田中"},
    {"search_type": "email", "query": "tanaka@example.com"},
    {"search_type": "phone", "query": "090-1234"}
  ]
}

ツール統合（Consolidation）パターン

公式engineering blogでは、個別のAPIエンドポイントを1対1でツールにするのではなく、関連操作をまとめた高レベルなツールを作ることが推奨されています。

名前空間（Namespacing）の重要性

複数サービスのツールを扱う場合、サービスプレフィックスを付けることが公式推奨です。

• サービスベース: github_list_prs, slack_send_message, jira_create_issue
• リソースベース: asana_projects_search, asana_users_search

名前空間があると、ツール数が増えても選択の曖昧さが生じにくくなります。特にTool Search機能と組み合わせる場合に効果的です。

構造化エラーハンドリングの実装パターン

公式ドキュメントでは、エラーメッセージを「何が問題で、次に何をすべきか」を明示的に伝えることが強く推奨されています。ここでは公式の最新仕様に基づく実装パターンを深掘りします。

公式仕様: is_errorフラグの正確な理解

tool_resultのis_errorはオプショナルフィールドです。設定しなくてもAPIは動作しますが、Claudeのエラー認識精度が大きく変わります。

// is_error: true を設定したエラーレスポンス（公式推奨）
{
  "type": "tool_result",
  "tool_use_id": "toolu_01A09q90qw90lq917835lq9",
  "content": "ConnectionError: the weather service API is not available (HTTP 500)",
  "is_error": true
}

// is_error なしのエラーレスポンス（非推奨）
{
  "type": "tool_result",
  "tool_use_id": "toolu_01A09q90qw90lq917835lq9",
  "content": "エラーが発生しました"
}

公式推奨: 指示的なエラーメッセージ

公式ドキュメントでは「Write instructive error messages」として、以下のパターンが明示されています。

構造化エラーレスポンスの設計パターン

tool_resultのcontent内に、エラーの種類・原因・リトライ可否を構造化して含めることで、Claudeの判断精度が向上します。

// パターン1: リトライ可能なエラー
{
  "type": "tool_result",
  "tool_use_id": "toolu_abc123",
  "content": "{\"error\": {\"type\": \"rate_limited\", \"message\": \"API rate limit exceeded. Current limit: 100 requests/min.\", \"isRetryable\": true, \"suggestion\": \"Wait 30 seconds before retrying, or reduce request frequency.\"}}",
  "is_error": true
}

// パターン2: リトライ不可のエラー
{
  "type": "tool_result",
  "tool_use_id": "toolu_def456",
  "content": "{\"error\": {\"type\": \"permission_denied\", \"message\": \"User does not have access to project 'confidential-2024'.\", \"isRetryable\": false, \"suggestion\": \"Ask the user to contact their administrator for access.\"}}",
  "is_error": true
}

エラータイプ別の対応マトリクス

Claudeの自動リトライ動作

公式ドキュメントによると、パラメータ不正でis_error: trueが返された場合、Claudeは2-3回まで修正を試みて再試行します。それでも失敗した場合はユーザーに謝罪メッセージを返します。

tool_resultのフォーマット要件

公式ドキュメントで最近明確化された重要ルールがあります。

// 正しい順序
{
  "role": "user",
  "content": [
    {"type": "tool_result", "tool_use_id": "toolu_01", "content": "15 degrees"},
    {"type": "text", "text": "次はどうすればいいですか？"}
  ]
}

// 誤った順序（400エラー）
{
  "role": "user",
  "content": [
    {"type": "text", "text": "結果はこちらです:"},
    {"type": "tool_result", "tool_use_id": "toolu_01", "content": "15 degrees"}
  ]
}

Strict Modeとエラー予防

ツール定義に"strict": trueを設定すると、Claudeの出力がinput_schemaに100%準拠することが保証されます。これにより、パラメータ不足や型不一致によるエラーを完全に排除できます。

ツール分配と統合戦略（公式推奨パターン）

Anthropic公式のengineering blogでは、ツール設計の最も重要な原則として「エージェントが人間と同じようにタスクを分解・解決できる粒度でツールを設計する」ことが掲げられています。

ツール分配の3層モデル

大規模システムでのツール管理を、3つのレイヤーに整理します。

Layer 3: ツールルーティングの実装パターン

大量のツール（50個以上）を扱う場合の推奨アーキテクチャです。

// Step 1: ルーティングツールのみを渡す
tools: [{
  "name": "classify_request",
  "description": "ユーザーの要求を分類する。order（注文関連）、product（商品関連）、account（アカウント関連）、payment（支払い関連）のいずれかを返す。",
  "input_schema": {
    "type": "object",
    "properties": {
      "category": {
        "type": "string",
        "enum": ["order", "product", "account", "payment"]
      },
      "confidence": {
        "type": "string",
        "enum": ["high", "medium", "low"]
      }
    },
    "required": ["category", "confidence"]
  }
}]
tool_choice: {"type": "tool", "name": "classify_request"}

// Step 2: 分類結果に応じた専門ツールセットに切り替え
// category === "order" の場合:
tools: [search_orders, get_order_status, cancel_order, modify_order]
tool_choice: {"type": "auto"}

このパターンのメリットは、最初のリクエストではルーティングツール1個だけでコンテキスト消費を最小化し、以降は関連ツールのみで効率的に処理できる点です。

ツール応答の最適化

公式では、ツールの応答も設計対象として重視されています。「高信号な情報のみ返す」ことが推奨されます。

推論オーバーロード: 定量的な影響

公式データに基づくツール数とパフォーマンスの関係を整理します。

新機能: Tool Search（ツール検索）

大量のツールを扱う場合、Anthropicが提供するTool Search機能を活用できます。これはサーバーサイドツールの一種で、Claudeが必要なツールを自動的に検索・選択する仕組みです。

サーバーツール vs クライアントツール

公式ドキュメントではツールを実行場所で2つに分類しています。

プロンプトキャッシングとの併用

ツール定義は毎回のリクエストに含まれるため、入力トークンコストに直結します。cache_controlを付与することで、変更のないツール定義をキャッシュし、コストを削減できます。

Extended Thinkingとの互換性

Extended Thinking（拡張思考）モードを使う場合、tool_choiceに制限があります。

• auto（デフォルト）: 使用可能
• none: 使用可能
• any: 使用不可（エラーになる）
• tool（特定指定）: 使用不可（エラーになる）

Extended ThinkingでProgrammatic Enforcementが使えないため、プロンプトベースのガイダンスで代替する必要があります。

ツール設計 用語集

このモジュールで登場した重要な用語をまとめています。試験は英語のため、英語表記も併記しています。

確認クイズ

MCPとは何か

MCP（Model Context Protocol / モデルコンテキストプロトコル）は、Anthropicが2024年11月に公開したオープンプロトコル（通信規約）です。AIモデルと外部のツールやデータソースを、標準化された方法で接続するために設計されました。

MCPが解決する問題 — 「M×N問題」

MCPが登場する前は、AIアプリケーションが外部サービスに接続するたびに、サービスごとに専用のコードを書く必要がありました。AIアプリがM個、接続先サービスがN個あると、M×N通りの接続コードが必要になります。これを「M×N問題」と呼びます。

MCPは、この問題を解決します。共通のプロトコルを定めることで、各AIアプリはMCPクライアントを1つ実装するだけ、各サービスはMCPサーバーを1つ実装するだけで済みます。必要な実装はM+N個に削減されます。

MCPの特徴

オープンソース：MCPの仕様はオープンソースとして公開されており、誰でも自由にMCPサーバーやクライアントを作成できます。Anthropic専用の技術ではなく、他のAIプロバイダーも採用できる標準規格です。

JSON-RPC 2.0ベース：MCPの通信メッセージは、JSON-RPC 2.0という広く使われている形式に基づいています。

能力交渉（Capability Negotiation）：接続時にサーバーが「私はこういうことができます」と自分の能力を宣言します。

MCPのアーキテクチャ

MCPのアーキテクチャは、3つの役割と2つのトランスポート方式で構成されています。

3つの役割: Host / Client / Server

トランスポート方式

通信の流れ（具体例）

ユーザーがClaude Desktopで「このフォルダのファイル一覧を見せて」と聞いた場合：

1. ホスト内のLLM（Claude）が「ファイル一覧を取得するツールを使おう」と判断
2. クライアントがFilesystem MCPサーバーに list_directory ツールの呼び出しを送信
3. MCPサーバーがローカルファイルシステムにアクセスし、一覧を取得
4. 結果をクライアント経由でホストに返送
5. LLMが結果を解釈し、ユーザーに自然言語で回答

MCPの3つのプリミティブ

MCPサーバーが提供できる機能は、3つのプリミティブ（Primitives / 基本要素）に分類されます。

1. Resources（リソース）— データの公開

MCPサーバーが持つ読み取り用のデータです。ファイルの内容、データベースのレコード、APIの応答など。

2. Tools（ツール）— アクションの実行

MCPサーバーが公開する実行可能な操作です。

3. Prompts（プロンプト）— テンプレートの提供

MCPサーバーが提供する再利用可能なプロンプトテンプレートです。

制御主体のまとめ

補足: Sampling（サンプリング）

MCPにはもう一つ、Samplingという仕組みがあります。MCPサーバーがクライアントを通じてLLMに推論をリクエストできる逆方向の通信です。部下（サーバー）が上司（LLM）に「判断をお願いします」と相談するイメージです。

MCP と Tool Use の違い

Module 5で学んだTool Use（Function Calling）とMCPは、どちらもAIにツールを使わせる仕組みですが、位置づけが異なります。

比較表

実用的なMCPサーバーの例

MCP設定ファイルの階層構造

MCPサーバーをClaude Codeで使うには、設定ファイルに接続情報を記述します。設定ファイルには複数のレベルがあり、「どの設定ファイルに書くか」で適用範囲が変わる仕組みです。

2つの設定ファイル

優先順位のルール

同じMCPサーバーが両方の設定ファイルに記述されている場合、プロジェクトレベル（.mcp.json）が優先されます。

1. .mcp.json（プロジェクト固有）— 最優先
2. ~/.claude.json（グローバル）— .mcp.jsonにない設定のみ適用

設定ファイルの記述例

プロジェクトの.mcp.jsonにMCPサーバーを登録する例：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
      "env": {}
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Enterprise環境でのMCP管理

企業のEnterprise/Teamプランでは、管理者がMCPコネクターを制御できます。管理者は、ユーザーが接続を許可されるMCPサーバーの種類を制限できます。

MCPサーバー設計パターン

MCPサーバーを設計・構築する際には、セキュリティと使いやすさの両面を考慮する必要があります。

認証・権限管理のパターン

Roots（ルーツ）— アクセス範囲の制限

MCPのRootsは、サーバーが安全にファイルアクセスするための仕組みです。ホスト（Claude Desktopなど）がサーバーに対して「ここからここまでの範囲だけ見てよい」と指定します。

サーバー設計のベストプラクティス

• 最小権限の原則：サーバーには必要最小限のアクセス権限だけを与える
• 入力の検証：クライアントからの入力を常に検証し、不正なリクエストを拒否する
• エラーの構造化：エラーが発生した場合、isError: trueを返し、エラーの内容を明確に伝える
• タイムアウトの設定：長時間かかる処理にはタイムアウトを設け、無限待ちを防ぐ
• ログの記録：重要な操作とエラーをログに記録し、トラブルシューティングに備える

ツール定義のベストプラクティス

MCPサーバーが公開するツールのdescription（説明文）は、LLM（AIモデル）がツールを選ぶ際の判断材料になります。

MCPの高度な機能

MCPには基本的な3つのプリミティブ（Resources, Tools, Prompts）に加えて、より高度な機能があります。

サンプリング（Sampling）— AIの力を借りる

サンプリングは、MCPサーバーがクライアントを通じてLLM（AIモデル）に推論を依頼できる仕組みです。通常、MCPの通信は「ホスト → サーバー」の方向ですが、サンプリングでは逆方向（サーバー → ホスト経由でLLMに問い合わせ）が可能になります。

サンプリングが役立つ場面

• データの要約：大量のデータを取得した後、LLMに要約させてからクライアントに返す
• 判断の委譲：複数の選択肢がある場面で、LLMに最適な選択を判断してもらう
• コスト管理：AI推論のコストをクライアント側（ホスト側）に負担させる設計が可能

通知（Notifications）— 進捗を伝える

2種類の通知

通知は「応答を求めない一方通行のメッセージ」です。サーバーからクライアントへの報告であり、クライアントからの返事は不要です。

初期化ハンドシェイク — 最初のあいさつ

MCPクライアントとサーバーが接続する最初のステップでは、初期化ハンドシェイクが行われます。

1. クライアントがinitializeリクエストを送信（自分の対応バージョンと能力を伝える）
2. サーバーが応答（自分の対応バージョンと能力を伝える）
3. クライアントがinitialized通知を送信（接続完了を確認）

トランスポート選定ガイド

MCPには複数のトランスポート方式（データの運び方）があり、用途に応じて選び分けます。

3つのトランスポート方式の比較

選定フローチャート

1. ローカルで動かすだけ？ → stdio（最もシンプル）
2. リモートアクセスが必要？ → HTTP系を検討
3. リアルタイムの進捗通知が必要？ → Streamable HTTP
4. 大量のユーザーに対応する必要がある？ → ステートレスHTTP

ステートレスHTTPのトレードオフ

MCP設定ファイルの実践ガイド

Module 6の基礎編で学んだ.mcp.json（プロジェクト設定）と~/.claude.json（グローバル設定）の使い分けを、実践的な場面に沿ってさらに深掘りします。

チーム共有パターン

チームでMCPサーバーを共有する場合、設定ファイルをどこに置くかがセキュリティと利便性のバランスを決めます。

設定の優先順位と競合解決

同じMCPサーバーが両方の設定ファイルに定義されている場合、以下のルールで解決されます。

Enterprise環境でのMCP管理

企業のEnterprise/Teamプランでは、管理者がMCPコネクターを制御できます。

• 許可リスト方式: 管理者が承認したMCPサーバーのみ接続可能にする
• Managed Settings（管理設定）との連携: 組織全体のMCPポリシーを強制適用
• ユーザーが未承認のMCPサーバーを追加できないよう制限可能

MCPサーバーの認証とセキュリティ

MCPサーバーを安全に運用するには、「誰がアクセスしているか（認証）」と「何ができるか（認可）」を適切に管理する必要があります。

3つの認証パターン

セキュリティ上の脅威と対策

ツール定義のセキュリティ設計

MCPサーバーが公開するツールには、操作の危険度に応じた設計が求められます。

MCPの高度な通信パターン

MCPの高度な機能をさらに深掘りし、サンプリングの詳細、新しいプリミティブ、トランスポート選定の実践基準を学びます。

サンプリング（Sampling）の詳細

サンプリングでは、MCPサーバーがクライアントを通じてLLMに推論を依頼する際、モデルの選び方を指定できます。

サンプリングのHuman-in-the-loop

サンプリングでは、信頼と安全のため、人間による確認が常に推奨されます。

1. サーバーがsampling/createMessageリクエストを送信
2. クライアントがユーザーにリクエスト内容を提示して承認を求める
3. ユーザーが承認（または修正）→ クライアントがLLMに送信
4. LLMの応答をユーザーが再度確認してからサーバーに返送

Elicitation（引き出し） — 新しいプリミティブ

MCP仕様にはElicitation（エリシテーション / 引き出し）という機能があります。サーバーがクライアントを通じてユーザーから追加情報を直接取得できる仕組みです。

セッション管理（Session Management）

Streamable HTTPトランスポートでは、セッション管理の仕組みが提供されています。

トランスポート選定の実践基準

トランスポート選定の詳細な判断基準を整理します。

用語集

Module 6で登場した重要用語をまとめました。

確認クイズ

Module 6の内容を確認しましょう。全5問、すべて4択です。

Claude Codeとは何か

Claude Code（クロード・コード）は、Anthropicが提供するエージェント型コーディングツールです。普通のチャットAIとの違いは、「会話するだけ」ではなく、実際にファイルを読み書きし、コマンドを実行し、Gitを操作できる点です。

たとえるなら、普通のAIチャットが「電話で相談できるアドバイザー」なら、Claude Codeは「実際にオフィスに来て一緒に作業してくれる同僚」です。

利用できる環境

内蔵ツールと権限モデル

Claude Codeには多数の内蔵ツール（Built-in Tools）があり、それぞれに権限が必要かどうかが決まっています。

主要な内蔵ツール

5つの権限モード（Permission Modes）

権限の評価順序

権限ルールはdeny → ask → allowの順で評価されます。deny（拒否）が常に最優先です。

設定ファイルの優先順位

CLIコマンドとワークフロー

基本コマンド

主要なCLIフラグ

チェックポイント機能

Claude Codeはファイル変更前の状態を自動保存（チェックポイント）します。/rewindコマンドで以前の状態に復元できます。

サブエージェントの仕組み

Claude Codeにはサブエージェント（Sub-agents）機能があります。メインのClaude Codeが「上司」、サブエージェントは「特定の仕事を任された部下」です。

組み込みサブエージェント

Hooksによるライフサイクル制御

CI/CD統合

Claude Codeは対話的な開発だけでなく、CI/CDパイプライン（自動ビルド・テストの仕組み）の中でも活用できます。コードレビューの自動化や、テスト生成、ドキュメント更新など、開発プロセスの様々な場面で力を発揮します。

たとえるなら、対話モードが「一緒に作業する同僚」なら、CI/CD統合は「決まった手順書に沿って自動で仕事をしてくれるロボット社員」です。

-pフラグ（非対話モード）の活用

-p（--print）フラグは、Claude Codeをヘッドレスモード（Headless Mode）で起動します。人間の入力を待たずに、プロンプトに対する回答を返して終了するため、自動化に最適です。

Batch APIとの連携パターン

大量のファイルを一括処理したい場合、AnthropicのBatch API（バッチAPI）と組み合わせるパターンが有効です。

セッション隔離（CI環境のベストプラクティス）

CI/CD環境でClaude Codeを使う際は、セッション隔離が重要です。複数のCIジョブが同時に実行されても、お互いに干渉しないようにする仕組みです。

実践例: GitHub Actionsでの活用

Claude Codeのセキュリティ

Claude Codeは強力なツールですが、ファイルの読み書きやコマンド実行ができるため、セキュリティ（安全対策）が非常に重要です。Anthropicはこの点を重視し、多層的な安全設計を採用しています。

たとえるなら、Claude Codeのセキュリティは「金庫室」のような仕組みです。入室する人（ツール操作）ごとに身分証（権限承認）をチェックし、持ち出せるもの（データ送信範囲）を制限し、監視カメラ（ログ記録）で記録を残します。

セキュリティアーキテクチャ概要

データ取扱い

権限モデル（サンドボックスとツール承認フロー）

セキュリティベストプラクティス

Module 7 用語集

確認クイズ

CLAUDE.md — Claude Codeの「ルールブック」

CLAUDE.mdは、Claude Codeがプロジェクトで作業する際に自動的に読み込む指示書ファイルです。新入社員が初日に「社内ルールブック」を渡されるのと同じです。

3層の階層構造

何を書くべきか・書くべきでないか

Claude Codeの設定ファイル体系

settings.json — 機械的な設定

settings.jsonはJSON形式の設定ファイルで、権限、MCPサーバー、環境変数などの機械的な設定を記述します。

ワークフロー設計 — Hooks、Commands、Skills

Hooks（フック）— 自動チェックポイント

特定のイベントの前後にスクリプトを自動実行する仕組み。settings.jsonで定義します。

Custom Slash Commands（カスタムコマンド）

.claude/commands/ にMarkdownファイルを置くと、/コマンド名 で呼び出せます。$ARGUMENTS プレースホルダーでユーザーの引数を受け取れます。

Skills（スキルファイル）

再利用可能な専門知識をまとめたMarkdownファイル。CLAUDE.mdから参照指示を書いて、必要な時に読み込みます。

チーム開発とCI/CDでのClaude Code活用

チーム開発での設定管理

CI/CDパイプラインでの活用

@importモジュール化 — CLAUDE.mdを分割管理する

プロジェクトが大きくなると、1つのCLAUDE.mdにすべてのルールを書くのは大変です。@importディレクティブを使えば、CLAUDE.mdを複数ファイルに分割して管理できます。会社の就業規則が1冊ではなく「総則」「経理規程」「開発規程」と分冊されているのと同じ考え方です。

いつ分割すべきか？

.claude/rules/ — 条件付きルールファイル

CLAUDE.mdに書いたルールは常に読み込まれますが、「特定の状況でだけ適用したいルール」もあります。.claude/rules/ ディレクトリに置くルールファイルは、こうした条件付きの指示を実現します。

ルールの種類

CLAUDE.md と .claude/rules/ の使い分け

Plan mode — まず計画、それから実装

コードを書く前に「何をどう変更するか」を整理したい場面があります。Plan mode（計画モード）は、Claude Codeにファイル変更を行わせず、設計・方針の検討だけをさせるモードです。建築で言えば「設計図を描く段階」です。

Plan modeの起動方法

Plan modeでできること・できないこと

Plan modeの活用パターン

Agent Skills — 専門知識をパッケージにする

Claude Codeで繰り返し使う「特定分野の専門知識」をまとめたものがAgent Skills（エージェントスキル）です。料理に例えると、レシピ本をまるごと覚えさせるのではなく、「和食のスキル」「洋食のスキル」と分けて、必要なときだけ参照するイメージです。

スキルの呼び出し方

CLAUDE.md・カスタムコマンド・スキルの比較

エンタープライズでのスキル配布

Module 8 用語集

確認クイズ

エージェントとは何か

これまでのモジュールで、Claudeにプロンプトを送り、ツールを使わせる方法を学びました。しかし、現実の仕事は「1回のやり取り」では終わりません。調べ物をして、判断して、実行して、結果を確認して、必要なら修正する ── このループ（繰り返し）を自律的に回せるAIシステムが「エージェント」です。

身近な例えで言うと、チャットAIは「質問したら答えてくれる辞書」、エージェントは「指示を出したら自分で段取りを考え、必要な道具を使いこなして仕事を片付けてくれる優秀な部下」のようなものです。

拡張LLM（Augmented LLM）— エージェントの基本部品

Anthropicは、エージェントの基本構成要素を「拡張LLM（Augmented LLM）」と呼んでいます。素のLLM（脳だけの状態）に3つの能力を付与したものです。

ワークフロー vs 自律エージェント — 2つのアプローチ

Anthropicは、エージェント的なシステム（Agentic Systems）を大きく2種類に分けています。

5つのワークフローパターン

Anthropicは公式ブログ「Building effective agents」で、5つの基本ワークフローパターンを提唱しています。これらはCCA-F試験で最も頻出するテーマの一つです。

1. プロンプト連鎖（Prompt Chaining）

2. ルーティング（Routing）

3. 並列化（Parallelization）

4. オーケストレータ-ワーカー（Orchestrator-Workers）

5. 評価者-最適化者（Evaluator-Optimizer）

パターン選択の早見表

自律エージェントとエージェントループ

5つのワークフローパターンでは対応できない、手順が事前に予測できないタスクには自律エージェントを使います。

エージェントループ（Agentic Loop）の仕組み

自律エージェントの核心は、ループ（繰り返し）です。Anthropicは「エージェントとは、ループ内で環境フィードバックに基づきツールを使うLLMに過ぎない」と述べています。実装は意外とシンプルです。

stop_reasonによるループ制御

エージェントループの制御で最も重要なのが、APIレスポンスのstop_reasonフィールドです。

Coordinator-Subagentパターン

複数のエージェントが協力するマルチエージェントシステムでは、Hub-and-spoke（車輪のハブとスポーク）型のアーキテクチャが推奨されます。

Agent SDKでは、サブエージェントの生成にはTaskツールを使います。並列実行するサブエージェントは、1回のコーディネーターレスポンスで複数のTaskツール呼び出しをまとめて発行します（別々のターンに分けない）。

セッション管理

長時間にわたるエージェント作業では、セッションの管理も重要です。

• セッション再開（Resume）：名前付きセッションを途中から再開できる。ただし、コード変更後は変更内容をエージェントに明示的に通知する必要がある
• セッション分岐（Fork）：共有の分析ベースラインから独立した探索ブランチを作成。異なるアプローチを並列で試す場合に有効
• コンテキスト圧縮（Context Compaction）：コンテキスト限界に近づくと、前のメッセージを自動要約してウィンドウを確保

エージェント設計の原則とベストプラクティス

27%という最大配点を持つこのドメインでは、「どうやってエージェントを作るか」だけでなく、「どう設計すべきか」「何を避けるべきか」の判断力が問われます。

Anthropicの3原則

プログラム的エンフォースメント vs プロンプトベースのガイダンス

エージェント設計で最も重要な判断の一つが「ルールをどう強制するか」です。

検証の3手法

エージェントの出力を検証する方法は3つあります。

ツール設計のベストプラクティス（ACI設計）

エージェントが使うツールの設計も、エージェントの品質を大きく左右します。

• ポカヨケ設計（Poka-yoke）：ミスが起きにくいインターフェースにする。たとえば、相対パスではなく絶対パスを要求する
• description の充実：エッジケース・使用例・境界条件を含める。「ジュニア開発者が理解できるドキュメント」レベルの記述を目指す
• ツール数の制限：多すぎるとLLMの選択精度が下がる。1リクエストあたり4〜5個に絞ることを推奨
• 結果の整形：ツール戻り値が巨大すぎるとコンテキストウィンドウを圧迫する。必要な情報だけに絞る

よくあるアンチパターン

エージェントアーキテクチャ 用語集

このモジュールで登場した重要な用語をまとめています。試験は英語のため、英語表記も併記しています。

確認クイズ

Agent SDKで作るエージェント

ここまでエージェントの「考え方」を学びました。ここからは、Anthropicが提供するAgent SDKを使って、実際にどうやってエージェントを「動かす」のかを見ていきましょう。

Agent SDKは、エージェントを作るための「公式キット」です。身近な例えで言うと、エージェントループのSection 3で学んだ「計画→実行→確認→修正」のサイクルを、最小限のコードで動かせるようにした「組み立てキット」のようなものです。

Agent SDKの基本構成

Agent SDKには、3つの主要な構成部品があります。

エージェントループの実装

Section 3で学んだ「stop_reasonでループを制御する」仕組みを、Agent SDKは内部で自動的に処理してくれます。開発者が書くのは「何をさせるか」だけです。

サブエージェントの作り方

Agent SDKでは、サブエージェントをツールとして定義します。「リサーチ担当」「レビュー担当」など、専門的な役割を持つエージェントをツールのように呼び出せます。

ハンドオフ（Handoff）との違い

サブエージェントの呼び出し方法にはもう1つ、ハンドオフ（Handoff）があります。

Hooks — 決定論的な処理を注入する

Section 4で「プログラム的エンフォースメント」を学びました。その実装手段がHooks（フック）です。

Hooksとは、エージェントの動作の「特定のタイミング」にコード処理を差し込む仕組みです。身近な例えで言うと、工場の品質管理です。製品が工程から工程に移るとき、必ず検査を通す仕組み ── それがHooksです。

Hooksのタイミング（ライフサイクル）

Hooksを差し込めるタイミングは、大きく4つあります。

Hooksで実現できること

具体的なビジネスシーンでの活用例を見てみましょう。

Hooks vs プロンプト指示 — 使い分け判断表

エラー処理とフォールバック設計

エージェントは複数のツールを連続で使うため、途中でエラーが起きることは避けられません。ここでは「エラーが起きたらどうするか」を設計する方法を学びます。

ツールエラーの2つの分類

エージェントがツールを使ったとき、エラーが起きるのは日常的なことです。大切なのは、そのエラーが「やり直せるもの」か「やり直してもダメなもの」かを区別することです。

エラー伝搬の仕組み

マルチエージェントシステムでは、サブエージェントで起きたエラーを親エージェントにどう伝えるかが重要です。これをエラー伝搬（Error Propagation）と呼びます。

構造化エラー報告

エラーを伝えるとき、「エラーが起きました」だけでは不十分です。以下の情報を構造化して伝えることで、親エージェントが適切に対処できます。

フォールバック設計

エラーが起きたときの「代替手段」を事前に設計しておくことを、フォールバック設計と呼びます。

コンテキスト隔離 — サブエージェントの「記憶」は共有されない

マルチエージェントシステムを設計するうえで、最も誤解されやすいのがコンテキスト隔離です。ここをしっかり理解すると、試験でのミスを大幅に減らせます。

コンテキスト隔離とは

身近な例えで説明しましょう。

なぜ自動継承しないのか

正しい情報共有の方法

よくある間違い

エージェントの安全なデプロイ

優秀なエージェントを作っても、安全に動かせなければ意味がありません。Anthropicは、エージェントを本番環境にデプロイ（公開・運用開始）する際の3つの安全原則を提唱しています。

3つの安全原則

原則1: 隔離（Isolation）

• コンテナ（Container）で実行環境を分離する
• アクセスできるファイルやフォルダを限定する
• ネットワーク接続先を制限する（必要なAPIだけに接続許可）
• サブエージェントごとに独立した実行環境を用意する

原則2: 最小権限（Least Privilege）

• 読み取り専用で十分な場面では、書き込み権限を与えない
• ツールごとに操作の範囲を限定する（「全顧客データ」ではなく「該当顧客のデータのみ」）
• APIキーの権限スコープを最小化する
• 時間制限付きの一時的な認証情報を使う（長期間有効な認証情報を避ける）

原則3: 多層防御（Defense in Depth）

人間の関与（Human-in-the-Loop）

Agent SDK実装詳細 — ストリーミング・max_turns・SDK vs 直接API

Section 7ではAgent SDKの基本を学びました。ここでは、実際にエージェントを動かすときに知っておくべき実装レベルの詳細を掘り下げます。

Client SDK vs Agent SDK — 2つのSDKの違い

Anthropicは2種類のSDKを提供しています。名前が似ているため混乱しやすいですが、役割が全く異なります。

Agent SDKの組み込みツール

Agent SDKには、Claude Codeと同じ組み込みツールが搭載されています。独自にツールを定義しなくても、すぐに使える「標準装備」です。

ストリーミング（Streaming）

Agent SDKのquery()関数は、結果をストリーミング形式で返します。これは、「手紙を全部書き終わってから投函する」のではなく、「書きながらリアルタイムに1文字ずつ送る」ようなイメージです。

ストリーミングでは、エージェントの動作状況をリアルタイムに追跡できます。

• initメッセージ — セッションの開始を知らせる。session_idが含まれ、セッション再開に使える
• assistantメッセージ — Claudeの応答テキスト
• tool_useメッセージ — ツール呼び出しの内容
• tool_resultメッセージ — ツール実行の結果
• resultメッセージ — エージェントの最終結果

max_turns — 安全装置としてのループ制限

セッション管理

Agent SDKは、長時間のエージェント作業を中断・再開する仕組みも提供しています。

Hooks実践 — ガードレール・監査ログ・権限制御

Section 8ではHooksの基本（4つのタイミング）を学びました。ここでは公式ドキュメントに基づいた実践的な設計パターンを深掘りします。

Hookイベントの全体像

公式ドキュメントでは、基本の4つに加えてさらに多くのイベントが定義されています。主要なものを押さえましょう。

権限判定の優先順位

複数のHookが同じイベントに登録されている場合、権限判定には明確な優先順位があります。

この仕組みは「拒否権」のようなものです。10人中9人が「OK」と言っても、1人が「ダメ」と言えば操作は止まります。これにより、安全側に倒す設計になっています。

ルールベースガードレールの設計パターン

Hooksを使ったガードレールには、いくつかの典型的なパターンがあります。

非同期Hook — ブロックしない副作用

matcherによるフィルタリング

全てのツール呼び出しに対してHookを実行するのではなく、特定のツールだけを対象にできます。

エラー伝搬設計 — スキップ・エスカレーション・構造化エラー

Section 9ではエラー処理の基本を学びました。ここでは、マルチエージェントシステムにおけるより高度なエラー伝搬パターンを掘り下げます。

エラー対応の4つの戦略

エージェントがエラーに遭遇したとき、取りうる対応は4つあります。状況に応じて最適な戦略を選ぶことが重要です。

エスカレーションの仕組み

マルチエージェントシステムでは、サブエージェントが解決できない問題をコーディネーター（親エージェント）に報告する「エスカレーション」が非常に重要です。

PostToolUseFailure Hook — ツール失敗時の自動対応

Agent SDKには、ツールが失敗した場合に自動的に呼ばれる専用のHookがあります。

スキップ戦略の設計

全てのエラーが致命的なわけではありません。オプショナル（あれば嬉しいが、なくても目的は達成できる）な処理の失敗は、スキップして先に進むのが正しい判断です。

グレースフルデグラデーションの実践

Section 9で学んだグレースフルデグラデーションを、マルチエージェントの文脈でより具体的に見てみましょう。

べき等性（Idempotency）とリトライの安全性

安全なデプロイ実践 — サンドボックス・データフロー制御

Section 11ではSecure Deploymentの3原則を学びました。ここでは公式ドキュメントに基づいた具体的な実装手法を掘り下げます。

脅威モデル — 何から守るのか

安全対策を設計する前に、「何が脅威なのか」を明確にすることが大切です。

サンドボックス — エージェントの「実験室」

Section 11で学んだ「隔離（Isolation）」の具体的な実装がサンドボックスです。

分離技術の比較

Anthropicの公式ドキュメントでは、4つの分離技術とその特性が示されています。

データフロー制御 — 情報の入口と出口を管理する

エージェントが「何にアクセスできるか」だけでなく、「データがどこに流れるか」を制御することも重要です。

プロキシパターン — 認証情報をエージェントから隔離する

機密ファイルの除外リスト

エージェントからアクセスをブロックすべきファイルの例です。

クラウド環境でのデプロイパターン

マルチエージェントシステムとは

Module 9で学んだエージェント（自律的にタスクを遂行するAI）を複数協調させるのがマルチエージェントシステムです。1人で全部やるのではなく、チームで分業して仕事を進めるアプローチです。

会社に例えると、Module 9は「1人の優秀な社員」の働き方でした。Module 10は「チーム全体」の編成方法 — 誰にどの仕事を任せるか、どう連携するか、問題が起きたらどうエスカレーションするかを学びます。

いつマルチエージェントにすべきか？

Anthropicは「シンプルさを優先せよ（Start with the simplest solution）」と明確に推奨しています。いきなり複雑なマルチエージェントを組むのではなく、段階的に複雑さを増やすのが正しいアプローチです。

料理に例えると：まず一人で作れるか試す → 助手に下ごしらえを頼む → 複数人で分担する → フルキッチンチームを組む。いきなりチームを組むのは非効率です。

マルチエージェントが適するケース