MCP server 統合

MCP server 統合は、CCA-F 試験において Claude Code の最も特徴的な拡張可能性の表面への入口となる章節だ。タスクステートメント2.4「MCP server の Claude Code およびエージェントワークフローへの統合」は Domain 2（ツール設計と MCP 統合、試験全体の18%）に属し、試験で最も問われる2つのシナリオ——Claude による開発者生産性とClaude Code によるコード生成——を支えている。MCP server 統合のスコーピング・クレデンシャル処理・MCP tool と MCP resource の区別について正しく推論できない受験者は、合格ラインが既に720/1000と厳しいこの試験で4〜6点を失う。

本章節では、アーキテクトとして認識できることが期待されるMCP server 統合の全表面を解説する。Model Context Protocol そのもの、プロジェクトレベルの .mcp.json とユーザーレベルの ~/.claude.json の比較、環境変数展開によるシークレットのバージョン管理からの排除方法、Claude Code が接続時に全 MCP server からツールを検出・統合する方法、MCP tool と MCP resource の構造的な違い、既存のコミュニティ製 MCP server の採用とカスタム開発の判断基準、そして見落とされがちなMCP tool の説明を強化して組み込みツールよりエージェントに優先させるレバー——すべてを CCA-F の認識深度で書く。アーキテクチャ的判断であり、実装コードではない。

Model Context Protocol とは何か、なぜ Claude Code がそれを使うのか

**Model Context Protocol（MCP）**は、AI アシスタントを外部システム——データベース・API・ファイルストア・課題追跡システム——に統一されたメッセージインタフェースで接続するためのオープン仕様だ。MCP 以前は、すべての AI クライアントが独自のプラグイン形式を発明しなければならず、すべてのツールプロバイダーは各クライアント向けに異なるアダプターを出荷しなければならなかった。MCP はその N × M 統合マトリクスを N + M に折り畳む：1つのサーバー実装がすべての MCP 対応クライアントと動作し、1つのクライアントがすべての MCP server に到達できる。公式 MCP 仕様はその設計を「AI アプリケーションの USB-C」と表現する——どの適合プラグもどの適合ソケットにも合うからだ。

Claude Code は今日の本番環境で最も MCP ネイティブなクライアントの一つだ。Claude Code セッションは複数の MCP server に同時に接続し、それらのツールカタログをエージェンティックループ中に Claude が推論する単一のツールリストに統合できる。したがって MCP server 統合は Claude Code アーキテクトにとってオプションのアドオンではない——組み込みの Read / Write / Edit / Bash / Grep / Glob ツールを超えて Claude Code を内部システムに拡張する主要メカニズムだ。

3つの MCP プリミティブの概観

MCP server 統合は3つのプリミティブのいくつかの組み合わせを公開する：

• MCP tool — 副作用のある呼び出し可能な関数。例：create_jira_ticket・run_sql_query・send_slack_message。
• MCP resource — URI でアドレス指定された読み取り可能なコンテンツ単位。例：jira://issue/PROJ-123・db://schema/orders・docs://handbook/deployment。
• MCP prompt — クライアントが挿入できる再利用可能なプロンプトテンプレート。例：調査ステップを事前入力する「バグトリアージ」プロンプト。

CCA-F 試験はtool と resource の区別を一貫してテストする。すべての MCP 機能を「tool」として扱う受験者は、「モデルがツールを呼び出す前にブラウズできるコンテンツのカタログを公開するのはどのプリミティブか？」という問題を見逃す——答えは常に resource だ。

MCP が CCA-F の試験範囲に含まれる理由

Domain 2 は MCP 統合に18%の重みを置き、タスク2.4 は具体的に Claude Code 統合を対象にする。コミュニティの試験レポートはすべてMCP ツールの境界とスコーピングを高頻度のトラップとして挙げる。プロトコルが存在する理由——相互運用性・最小権限拡張・サーバーの関心とクライアントの関心の分離——を理解する受験者は、フラグを暗記することなくスコーピングとクレデンシャルの問題に正しく対処する。

プロジェクトスコープ vs ユーザースコープ：.mcp.json vs ~/.claude.json

CCA-F 試験において MCP server 統合で最もテストされる側面はスコーピングだ。Claude Code は2つの場所から MCP server 定義を読み込み、その間の選択はチーム連携・クレデンシャル安全性・設定ドリフトに直接影響する。

プロジェクトスコープ — リポジトリルートの .mcp.json

Claude Code ワークスペース（通常リポジトリルート）のルートに .mcp.json という名前のファイルが置かれると、Claude Code はそのワークスペースでセッションが開始されるたびに宣言された MCP server をロードする。.mcp.json はリポジトリにコミットされているため、チームのすべての開発者・すべての CI ランナー・リポジトリをクローンするすべての自動化エージェントが同一の MCP server リストを得る。プロジェクトスコープは共有チームツールの正しい選択だ：チーム全体がクエリする Jira server・共有分析ワークフローを支えるデータベーススキーマ server・リリースパイプラインが使用するステージング環境デプロイ server。

ユーザースコープ — ホームディレクトリの ~/.claude.json

第2の MCP 設定は各開発者のホームディレクトリの ~/.claude.json にある。ここのエントリは個人的なものだ——ユーザーが開始するすべての Claude Code セッション、すべてのリポジトリに適用されるが、チームメンバーと共有されることはない。ユーザースコープは開発者固有のツールの正しい選択だ：個人用メモ取りサーバー・プライベートブックマークマネージャー・活発に開発中の実験的な MCP server・開発者がチームの他のメンバーに見せたくないクレデンシャル重い統合。

プロジェクトスコープとユーザースコープの選択

試験がテストする判断ルールは明確だ：

• チームと共有？ → プロジェクトスコープ（.mcp.json）。
• 個人的または実験的？ → ユーザースコープ（~/.claude.json）。

アーキテクチャのミスは両方向で起こる。チーム共有の Jira server をユーザースコープに置くと、すべての開発者が手動で再インストールしなければならず、設定ドリフトが生じる（「なぜ私の Claude Code に Jira ツールが見えないのか？」）。個人的な実験的サーバーをプロジェクトスコープに置くと、チームメンバーのツールリストに彼らが求めておらず使えないものが入り込む。

両スコープが同時にアクティブになれる理由

Claude Code はセッション開始時に両ファイルのサーバーをマージする。開発者がプロジェクトレベルの .mcp.json（Jira server を宣言）とユーザーレベルの ~/.claude.json（個人用メモサーバーを宣言）の両方を持つ場合、実行中のセッションは両方のサーバーのツールを見る。マージは加算的であり排他的ではないため、ユーザースコープのエントリがプロジェクトスコープのエントリをオーバーライドまたは競合することはない（同じサーバー名を使用しない限り）。アーキテクトはスコープを伝えるような名前（team-jira・personal-notes）を選んで偶発的なシャドウイングを防ぐべきだ。

環境変数展開：.mcp.json からシークレットを排除する

.mcp.json はバージョン管理にコミットされるため、クレデンシャルを含んではならない。GitHub 個人アクセストークン・Jira API キー・データベースパスワードを .mcp.json にハードコードすると、すべてのリポジトリクローン・すべてのフォーク・差分をクロールするすべての GitHub 検索にシークレットが漏洩する。これは MCP server 統合で最も重大なミスの一つであり、CCA-F 試験は直接それをテストする。

${VAR_NAME} 展開構文

Claude Code は .mcp.json エントリ内で環境変数展開をサポートする。${VAR_NAME} 形式の文字列はセッション開始時に環境変数 VAR_NAME の値で置き換えられる。正典的なパターン：

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

リポジトリにコミットされるファイルにはプレースホルダー ${GITHUB_TOKEN} のみが含まれる。各開発者は自身のシェル環境（.envrc・direnv・1Password CLI・またはシークレットマネージャー統合経由）で GITHUB_TOKEN を設定し、Claude Code は実行時に変数を解決する。シークレットはリポジトリに入らない。

スケールするクレデンシャル処理パターン

小規模チームでは、direnv と .envrc ファイル（git 無視）で十分だ。大規模組織では、パターンはこうなる：

• 開発者マシン → 1Password CLI または AWS Secrets Manager → 環境変数 → .mcp.json 展開。
• CI ランナー → GitHub Actions Secrets または GitLab CI 変数 → 環境変数 → .mcp.json 展開。
• 共有 CLAUDE.md が必要な変数名を文書化し、すべての開発者が推測なしにオンボードできるようにする。

このレイヤリングにより .mcp.json ファイル自体は安定してレビュー可能であり続け、シークレット表面は組織がすでに信頼するシークレットマネージャーに移動する。

Claude Code が接続時にツールを検出する方法

MCP server 統合について推論するアーキテクトはセッションライフサイクルを理解しなければならない。Claude Code がセッションを開始するとき、以下のシーケンスを実行する：

1. ワークスペースルートから .mcp.json を読み込む（存在する場合）。
2. ユーザーホームディレクトリから ~/.claude.json を読み込む（存在する場合）。
3. 2つのサーバーリストを1つの接続計画にマージする。
4. 各 stdio サーバーを並行して起動する（または各リモートサーバーにダイヤルする）。
5. 正常に接続されたすべてのサーバーに対して MCP の tools/list メソッドでツールカタログをクエリする。
6. 各サーバーの resources/list でリソースカタログをクエリする。
7. 検出されたすべてのツールを Claude Code の組み込みツールとともに単一のリストに連結する。
8. セッションの間、結合されたリストを Claude に提示する。

試験にとって重要な2つのアーキテクチャ上の結果：

設定されたすべてのサーバーのツールが同時に利用可能

検出が完了すると、Claude はすべての接続済み MCP server のすべてのツールとすべての組み込みツールを1つのフラットリストとして見る。どの server に Claude がアクセスできるかのターンごとのフィルタリングはない——server が接続されていれば、そのすべてのツールに到達できる。これが、エージェント間でのツールの分散（タスク2.3）が重要な理由だ：同時 MCP server が多すぎるエージェントは何百ものツールをコンテキストに持ち、トークンコストを膨らませ Claude のルーティング精度を低下させる。

検出はセッションごとに1回

MCP ツール検出は接続時の操作だ。セッション途中で .mcp.json に新しい MCP server エントリを追加しても、Claude Code は次のセッションが開始されるまでそれを見ない。長時間実行される自動化ワークフローではこれが重要だ：セッション全体の設定を設計し、増分追加のために設計しない。

MCP tool と MCP resource：点数を動かすプリミティブの区別

MCP tool と MCP resource の区別は Domain 2 で最も研究不足のトピックであり、CCA-F 試験はほぼすべての受験でそれをテストする。

MCP tool

MCP tool は副作用または計算出力を持つ呼び出し可能な関数だ。ツールを呼び出すには完全なエージェンティックループのラウンドトリップがかかる：Claude が stop_reason: "tool_use" を発行し、クライアントがツールを実行し、結果が tool_result ブロックとして返り、Claude が続く。ツールはエージェントが行動する方法だ——チケットを作成し、クエリを実行し、メッセージを送信し、スクリプトを実行する。

MCP resource

MCP resource は URI でアドレス指定された読み取り可能なコンテンツ単位だ。resource はサーバーがコンテンツのカタログを公開する方法だ——課題サマリー・ドキュメント階層・データベーススキーマ・ファイルツリー——モデルが完全なツール呼び出しコストを払わずにブラウズできる。よく設計された MCP server は、モデルが読むコンテンツには resource を、モデルが実行する操作には tool を公開する。

resource が探索的なツール呼び出しを削減する理由

ツールのみを公開する Jira MCP server を考えてほしい：search_issues(query)・get_issue(id)・create_issue(...)・update_issue(...)。Claude が更新すべき適切なチケットを見つけたいとき、search_issues のキーワードを推測し、いくつかの候補を調べ、再推測し、繰り返す必要がある。これらの反復のそれぞれが完全なツール呼び出しのラウンドトリップだ。

今度は、ID・タイトル・ステータスを持つオープンチケットのコンパクトなリストを返す jira://project/PROJ/open-issues での課題カタログ resource を公開する同じサーバーを考えてほしい。Claude は会話の開始時にそのリソースを一度読み込み、ユーザーのリクエストに対してパターンマッチングで関連するチケットを特定し、get_issue(id) または update_issue(...) を直接呼び出せる——推測ゼロ。ツール呼び出しが少なく、トークンコストが低く、精度が高い。

同じパターンはドキュメント階層（1つの resource が目次を返す；ツールが特定のページを取得する）とデータベーススキーマ（1つの resource がスキーマ概要を返す；ツールが特定のクエリを実行する）に適用される。

試験の手がかり：「探索的なツール呼び出しを削減する」

CCA-F シナリオが「エージェントは適切なレコードを見つける前に多くの投機的な検索呼び出しを行う」と言う場合、修正はほぼ常に「エージェントがツールを呼び出す前にブラウズできるようカタログを MCP resource として公開する」だ。「ツールを追加する」または「検索ツールの limit パラメータを増加させる」を提案する選択肢はアーキテクチャ上の洞察を見逃している。

やさしい解説: MCP server 統合

抽象的なプロトコル設計は、物理的な日常のシステムに固定することで具体的になる。3つの全く異なる類比で MCP server 統合概念の全範囲をカバーする。

Analogy 1: キッチン — Tool、Resource、そしてサーバー

Claude Code をキッチンを運営するヘッドシェフとして想像してほしい。シェフの組み込みツールはキッチンに付属するナイフ・鍋・コンロだ——Read・Write・Edit・Bash・Grep・Glob。MCP server は必要に応じて搬入される専門ステーションだ：パスタ押し出し機ステーション（Jira server）・製菓ステーション（データベースサーバー）・スービデステーション（デプロイサーバー）。各ステーションはヘッドシェフが操作できる固有の MCP tool のセットを持って到着する——パスタ押し出し機のボタン・スービデの温度ノブ。

MCP tool と MCP resource の区別は同じキッチンにマッピングされる。パスタ押し出し機はボタンを押すと何かを行う（それが tool だ）。ステーションの側面に留められたラミネートされたレシピブック——シェフが何も押さずに読めるもの——が resource だ。よく装備されたステーションには常に両方が付属する：レシピブックはシェフにステーションが何のためにあるかを教え；ボタンが実際にパスタを作る。

**プロジェクトスコープ（.mcp.json）**はキッチンの壁に貼られた共有機器リストだ——すべてのシフトのすべてのコックが同じステーションを見る。**ユーザースコープ（~/.claude.json）**はシェフが自身のロールで持ち込む個人的なキット——お気に入りのマイクロプレーン・カスタム温度計——夜には一緒に帰る。環境変数展開はクレデンシャル（冷凍庫の鍵・酒類免許）が入る金庫だ；壁の機器リストは鍵自体を印刷するのではなく「金庫の中の鍵」を参照する。

Analogy 2: 図書館 — コンテンツ発見における Resource と Tool の比較

図書館の類比は resource と tool の区別を鮮明にする。特定の本を探して参照図書館に入ったとする。図書館は2つの方法で見つけることを提供する。

ツールのみのアプローチは、レファレンスデスクに行き、司書にキーワードで本を検索してもらうことだ。すべての検索がラウンドトリップだ——キーワードを述べ、司書が書棚に消え、候補を持って戻り、再クエリする。適切なキーワードを見逃すと永遠にループする。

resource + tool アプローチは入口のカードカタログだ——自分でスキャンして正確なデューイ十進数を見つけ、それから司書にその特定の本を取ってきてもらうよう依頼する。カードカタログが MCP resource だ：司書（tool）を何度も煩わす回数を削減する読み取り可能なコンテンツ表面。よく設計された図書館は両方を組み合わせる。

この類比は Jira の例に直接マッピングされる。ツールのみの Jira 統合は Claude が検索キーワードを推測し続けるよう強制する。オープン課題カタログを resource として公開する Jira 統合は Claude がリストをブラウズし、適切なチケットを特定し、更新するための1つの外科的なツール呼び出しを行うことを可能にする。

Analogy 3: オープンブック試験 — スコープ・クレデンシャル・検出

オープンブック試験の類比はスコーピングとクレデンシャル処理をカバーする。すべての学生（開発者）は2つのバインダーを持って来る。**コース支給バインダー（プロジェクトスコープ — .mcp.json）**はすべての学生に同一だ：クラス全体が使用を許可された数式・参照表・共有素材が含まれ、共有シラバスにコミットされている。**個人バインダー（ユーザースコープ — ~/.claude.json）**は各学生自身のノートだ：注釈・個人的な記憶術・練習スクラッチパッド。2人の学生の個人バインダーは同一でない。

どちらのバインダーにも解答キー（クレデンシャル）を含めることは許可されていない。解答キーは試験監督の封筒に封じられている；各学生は試験開始時に「問題7の答えが必要な場合、参照コードは ${PROBLEM_7_KEY} であり、試験監督が読み上げる」と言われる。これが環境変数展開だ：コミットされたバインダーはシークレットを値ではなく名前で参照する。

接続時の検出は、学生が試験開始時に持ち込んだバインダーのみを使用できるというルールだ。試験途中に学生がバインダーを忘れたことに気づいても、取りに出ることはできない——次の受験（次の Claude Code セッション）まで持っているもので作業する。

試験日にどの類比を使うか

• MCP tool と MCP resource についての問題 → 図書館の類比。
• プロジェクトスコープ vs ユーザースコープ・クレデンシャル・環境変数についての問題 → オープンブック試験の類比。
• サーバーが1つのエージェントのツールリストにどのように組み合わさるかについての問題 → キッチンの類比。

コミュニティ製 MCP server とカスタム実装の比較

CCA-F のアーキテクチャ問題は、既存のコミュニティ製 MCP server を採用するかカスタムを一から構築するかの選択を繰り返し組み立てる。原則的な答えはほぼ常に「標準統合にはコミュニティサーバーを使用し、チーム固有のワークフローのみカスタムを確保する」だ。

標準統合でコミュニティサーバーが勝つ理由

Anthropic・MCP コミュニティ・サードパーティベンダーは最も一般的な統合ターゲット向けに MCP server を維持している：GitHub・Jira・Slack・Linear・Google Drive・PostgreSQL・Notion・Sentry。これらのサーバーは：

• 実績がある — 何千もの Claude Code インストールにデプロイされ、エッジケースはすでに提出されて修正済み。
• 仕様準拠 — ページネーション・エラー形状・resource URI を含む MCP プロトコルを正しく実装。
• 維持されている — 上流システムの API 変更（GitHub API v4 移行・Jira Cloud スキーマ更新）を追跡し、チームが追跡する必要はない。
• 発見可能 — MCP ディレクトリに現れ、@modelcontextprotocol/ または知名度のあるベンダー npm パッケージによって認識される。

標準的な「Claude Code セッションから Jira チケットを作成する」ワークフローには、コミュニティ Jira server を使用するのが正しいアーキテクチャ選択だ。カスタム Jira MCP server を書くことは、数ヶ月の作業を複製し、新しいメンテナンス負担を導入し、ほぼ常にコミュニティバージョンよりも悪いエラー処理で出荷する。

チーム固有ワークフローでカスタムサーバーが勝つ理由

コミュニティはあなたの内部システム向けのサーバーを維持できない。チームが以下を持つ場合：

• 標準 MCP server が一致する公開 API 表面を持たない独自の内部ツール（デプロイオーケストレーター・内部 CMS・専有分析プラットフォーム）；
• 複数の内部システムを1つの論理操作に組み合わせるドメイン固有のワークフロー（「顧客インシデントチケットを作成し、オンコールローテーションにリンクし、インシデントチャンネルにサマリーを投稿する」）；
• 特定のネットワーク境界内またはその下で実行しなければならないコンプライアンスに敏感な統合；

...そのときカスタム MCP server が正しい選択だ。カスタムサーバーはチームの内部の複雑さをクリーンな MCP インタフェースの背後にカプセル化し、チーム全体のすべての Claude Code セッションが自動的にその機能を継承する。

試験がテストする判断ルール

CCA-F シナリオは通常、1つのフレーズで正しい選択を示す：

• 「Jira / GitHub / Slack / PostgreSQL との統合」 → コミュニティ MCP server。
• 「チームの内部デプロイシステムとの統合」 → カスタム MCP server。
• 「チームが複数の選択肢を評価している」 → 存在する場合はコミュニティ；存在しない場合にのみカスタム。

MCP tool の説明を強化してエージェントが組み込みツールよりそれを優先するようにする

MCP server 統合において微妙だが頻繁にテストされるレバーはtool の説明だ。Claude Code の組み込みツール（Read・Write・Edit・Bash・Grep・Glob）は、汎用的なファイルとシェル操作のデフォルトのルーティングターゲットにするよく調整された説明を持つ。MCP server が説明が弱いまたは曖昧な新しいツールを追加すると、Claude は MCP ツールが建築的に正しい選択であっても組み込みにフォールバックする傾向がある。

ルーティングメカニズムとしての tool 説明の原則

これは広範な **Domain 2 の問題点（pp-02）**に一致する：tool の説明はルーティングメカニズムだ。2つのツールが重複する場合、Claude は現在のタスクをより具体的に説明する方の説明にルーティングする。「サービスをデプロイする」という説明を持つ deploy_service というカスタム MCP ツールは、ユースケースを明示的に命名するよく調整された説明を持つ Bash に対してルーティングコンテストで負ける。書き直された説明——「会社の Kubernetes クラスターに内部ロールアウトコントローラー経由で名前付きサービスをデプロイする；kubectl や helm を直接実行する代わりにデプロイタスクにはこれを使用する；サービス名とターゲット環境を受け入れる；デプロイステータスとロールバック手順を返す」——は Claude にこのツールをいつ優先すべきかを伝えるためルーティングコンテストに勝つ。

説明チューニングのチェックリスト

本番品質の MCP tool の説明には以下を含めるべきだ：

• 特定のドメインを命名する1文の目的文（「クラスター」ではなく「会社の Kubernetes クラスター」）。
• Claude がいつデフォルトをオーバーライドするかを知るための組み込みツールに対する明示的な境界（「kubectl を直接実行する代わりにこれを使用する」）。
• 少なくとも1つの具体的な例を持つ入力形式の例。
• エッジケースと失敗モード（「アクティブなロールアウト中は503を返す；60秒後に再試行する」）。
• Claude が後続のツールを正しくチェーンできるよう出力形状。

試験の手がかり

CCA-F シナリオが「Claude は Bash 経由で生の kubectl コマンドを実行し続け、カスタム deploy_service MCP ツールを使用しない」と言う場合、修正はデプロイタスクで Bash より優先させるよう MCP ツールの説明を書き直すことだ。「Bash ツールを制限する」または「Bash を許可リストから削除する」を提案する選択肢は誤りだ——脆弱性を導入する。軽量で耐久性のある修正はより良い tool の説明だ。

リモート MCP server と Messages API の MCP connector

CCA-F は Claude Code に焦点を当てているが、アーキテクトは Messages API からアクセス可能なリモート MCP server の隣接する表面を認識すべきだ。MCP connector は、Messages API リクエストが MCP server URL を指定できるパブリックベータ機能であり、Anthropic のインフラストラクチャがクライアントの代わりにそのサーバーに接続し、進行中の会話でそのツールを公開する。

リモート MCP がアーキテクチャ的に重要な理由

リモート MCP は、Claude Code 向けに構築された MCP server が最小限の追加作業でサーバー側の Messages API アプリケーションによって再利用できることを意味する。サーバーはクライアントごとの統合ではなく組織的な機能になる。CCA-F はこれをクロスドメインシナリオで表面化させる可能性がある：「チームはすでに Claude Code 用に Jira MCP server を実行している；Messages API 上に構築されたカスタマーサポートアプリケーションからそれを再利用できるか？」——はい、MCP connector を通じて。

CCA-F Foundations の範囲外

CCA-F 試験は MCP server のデプロイとホスティング（Kubernetes トポロジー・ロードバランシング・TLS 終端）をテストしない。これらの関心はアーキテクチャの基礎ではなくインフラストラクチャエンジニアリングに属する。プロトコル・スコーピング・設定の表面内に留まる——そこに試験の点数がある。

よくある試験のトラップ：スコーピング・クレデンシャル・プリミティブの混同

CCA-F 試験は5つの繰り返し発生する MCP server 統合のトラップに集中する。

トラップ 1: プロジェクトスコープとユーザースコープの混同

選択肢はファイルの場所を入れ替える。.mcp.json はプロジェクトスコープであり、リポジトリにコミットされている；~/.claude.json はユーザースコープであり、ホームディレクトリにあり、コミットされない。これを逆にするすべての選択肢は誤りだ。

トラップ 2: .mcp.json 内のリテラルクレデンシャル

シークレットを .mcp.json にリテラル文字列として書くすべてのスニペットは誤りだ。周囲のテキストがシークレットは低権限または一時的と主張しても同様だ。正しいパターンは常に ${VAR_NAME} 環境変数展開だ。

トラップ 3: MCP resource を tool として扱う

課題またはドキュメントページのカタログをブラウズすることについてのシナリオは resource に解決し、tool ではない。「list_issues ツールを追加する」と答える受験者は、MCP resource がすでにより低いトークンコストでこの問題をネイティブに解決していることを見逃している。

トラップ 4: コミュニティ製サーバーが存在する場合に「カスタム MCP server を構築する」

標準統合（Jira・GitHub・Slack・PostgreSQL）でカスタム実装に手を伸ばすことは常に誤ったデフォルトだ。カスタムはコミュニティに同等品がないチーム固有のワークフローのために確保される。

トラップ 5: 説明を改善する代わりに組み込みツールを制限する

Claude が組み込みツールをカスタム MCP ツールより優先する場合、修正はルーティングを勝ち取るよう MCP tool の説明を書き直すこと——許可リストから組み込みを削除することではない。組み込みを削除することは脆弱性を導入する；より良い説明が耐久性のある修正だ。

区別注記：CCA-F の認識レベル vs 高度な MCP 実装の深さ

CCA-F は6ヶ月以上の実践的な Claude 経験を持つアーキテクト向けの基礎レベルの Anthropic 認定として位置づけられている。MCP server 統合の表面に対して認識レベルのコンピテンシーをテストする——正しいスコープ・正しいプリミティブ・正しいクレデンシャルパターン・正しいビルド対採用の選択を特定できるか？

CCA-F があなたに期待すること

• .mcp.json（プロジェクト）と ~/.claude.json（ユーザー）のスコープを区別する。
• クレデンシャルをバージョン管理から排除するために環境変数展開を適用する。
• MCP ツールはセッション開始時に検出され同時に利用可能であることを認識する。
• 「実行 vs 読み取り」シグナルによって MCP tool と MCP resource を区別する。
• 標準統合にはコミュニティ MCP server をデフォルトとし、チーム固有のワークフローのみカスタムを確保する。
• 組み込みツールに対するルーティングを勝ち取るよう MCP tool の説明を改善する。

CCA-F があなたに期待しないこと

• TypeScript または Python で完全な MCP server 実装をコーディングする。
• リモート MCP server の Kubernetes ingress を設定する。
• stdio と HTTP を超えてカスタム MCP トランスポートを作成する。
• JSON-RPC ワイヤーフォーマット仕様をゼロから導出する。
• 最初の原則から MCP server 認証スキームを設計する。

MCP server デプロイトポロジーまたは認証フロー図を研究していることに気づいた場合、CCA-F のスコープを超えてドリフトしている——アーキテクチャ判断の深さに向き直し、先に進む。

実践アンカー：タスク2.4 シナリオ問題テンプレート

MCP server 統合に結びついた CCA-F 練習問題は5つの形にまとまる。各形はマルチエージェント研究システムシナリオにクリーンにマッピングされる。

テンプレート A: スコープ配置

チームはすべてのエンジニアの Claude Code セッションがチケットを作成および更新できるよう共有 Jira MCP server を標準化することを決定した。MCP server はどこで設定すべきか？正解：リポジトリルートにコミットされた .mcp.json のプロジェクトスコープ。ディストラクターはユーザースコープ（「すべてのエンジニア」シグナルを無効にする）またはグローバルインストール（Claude Code のスコーピングはそのように機能しない）を主張する。

テンプレート B: クレデンシャル安全性

開発者が「新しいエンジニアのオンボーディングを容易にするため」に GitHub 個人アクセストークンを .mcp.json に直接コミットすることを提案する。どのアプローチが正しいか？正解：.mcp.json で ${GITHUB_TOKEN} 環境変数展開を使用し、変数をチームのオンボーディングガイドに文書化する。ディストラクターには「低権限なのでトークンをコミットする」（絶対に許容できない）および「リポジトリのシークレットファイルにトークンを保存する」（同じ漏洩、異なる名前）が含まれる。

テンプレート C: プリミティブ選択

チームの Claude Code エージェントは、更新すべき適切な Jira チケットを見つける前に推測したキーワードで繰り返し search_issues 呼び出しを行う。探索的なツール呼び出しを削減するためにサーバーはどの MCP 機能を追加すべきか？正解：オープン課題カタログを公開する MCP resource（例：jira://project/PROJ/open-issues）——エージェントがツールを呼び出す前に一度読み込める。ディストラクターは「より多くの検索ツールを追加する」または「検索ツールの limit パラメータを増加させる」を提案する——どちらもアーキテクチャ上の根本原因に対処しない。

テンプレート D: ビルド vs 採用

チームはスキーマクエリのために Claude Code を PostgreSQL データベースと統合したい。PostgreSQL 向けのコミュニティ MCP server がすでに存在し広く使われている。どれが正しいアーキテクチャの選択か？正解：コミュニティ PostgreSQL MCP server を採用する。ディストラクターは「より厳密な管理のためにカスタムサーバーを構築する」を主張する——シナリオがコミュニティオプションを明示的に除外しない限り誤ったデフォルト。

テンプレート E: tool 説明のチューニング

Claude は組み込みの Bash ツールを通じて生の kubectl コマンドを実行し続け、チームのカスタム deploy_service MCP ツールを使用しない。どの修正が最も適切か？正解：目的・Bash に対する境界・入力・出力形状を明示的に命名して Claude がデプロイタスクでそれを優先するよう deploy_service ツールの説明を書き直す。ディストラクターは許可リストから Bash を削除する（脆弱）または CLAUDE.md ルールを追加する（よく調整された説明より耐久性が低い）を提案する。

MCP server 統合 よくある質問（FAQ）

CCA-F 試験において .mcp.json と ~/.claude.json の違いは何か？

.mcp.json はリポジトリルートにありバージョン管理にコミットされる；チーム全体が共有する MCP server を定義する。~/.claude.json はユーザーのホームディレクトリにありコミットされない；1人の開発者に個人的な MCP server を定義する。プロジェクトスコープ（.mcp.json）はチーム共有統合（Jira・GitHub・内部デプロイツール）に正しい。ユーザースコープ（~/.claude.json）はプロジェクトではなく開発者についていくべき個人的・実験的・またはクレデンシャルに敏感なサーバーに正しい。両ファイルはセッション開始時に読み込まれ、サーバーリストが1つのツールカタログにマージされる。

コミットされるリポジトリにある .mcp.json からクレデンシャルを排除するにはどうすればよいか？

環境変数展開を使用する：MCP server 設定がクレデンシャルを必要とする場所はどこでも、リテラル文字列ではなく ${VAR_NAME} として書く。Claude Code はセッション開始時にシェル環境からプレースホルダーを解決する。開発者はローカルで direnv・.envrc・1Password CLI・または組織のシークレットマネージャーを通じて変数を設定する。CI ランナーはパイプラインシークレット経由で注入する。セッション開始時に変数が欠落している場合、Claude Code はサイレントに空文字列に展開するのではなく MCP server 起動エラーを報告する。プレースホルダーとしてであってもリテラルトークンをコミットしない——シークレットが git 履歴に入った瞬間にローテーションしなければならない。

すべての MCP server のツールが Claude に同時に利用可能か、それとも Claude はターンごとに1つのサーバーを選ぶのか？

すべての接続済み MCP server のすべてのツールがセッション全体にわたって同時に利用可能だ。セッション開始時、Claude Code は .mcp.json と ~/.claude.json に宣言されたすべてのサーバーに接続し、各サーバーの tool と resource カタログをクエリし、組み込みツール（Read・Write・Edit・Bash・Grep・Glob）とともにすべてを1つのフラットリストにマージする。ターンごとのサーバー選択はない——Claude はセッションの間フルカタログを見る。これがアーキテクトがツール数に注意を払わなければならない理由だ：接続済み MCP server が多すぎるエージェントは何百ものツールをコンテキストに持ち、トークンコストを膨らませルーティング精度を低下させる。

MCP tool と MCP resource の違いは何か？

MCP tool は副作用のある呼び出し可能な関数だ——呼び出すと完全なエージェンティックループのラウンドトリップが引き起こされる（stop_reason: tool_use → クライアントが実行 → tool_result ブロック → Claude が続く）。ツールはエージェントが行動する方法だ：チケットを作成し、クエリを実行し、メッセージを送信する。MCP resource は URI でアドレス指定された読み取り可能なコンテンツ単位（jira://issue/PROJ-123・db://schema/orders）——コンテンツのカタログを公開し、モデルが完全なツール呼び出しコストを払わずにブラウズできる。課題カタログを resource として公開するサーバーは、モデルがどのツールを呼び出すかを決める前にカタログを直接読めるため探索的なツール呼び出しを削減する。よく設計された MCP server は両プリミティブを提供する。

いつコミュニティ製サーバーではなくカスタム MCP server を構築すべきか？

正しいアーキテクチャのデフォルトは標準統合（Jira・GitHub・Slack・Linear・PostgreSQL・Notion・Sentry）にはコミュニティ MCP server を使用し、コミュニティに同等品がないチーム固有のワークフローのみカスタム実装を確保することだ。コミュニティサーバーは実績があり・仕様準拠で・上流 API 変更に対してメンテナンスされ・発見可能だ。既存のコミュニティサーバーのカスタムバージョンを構築することは数ヶ月の作業を複製し悪いエラー処理で出荷する。カスタムは独自の内部システムを統合する・複数の内部システムを1つの論理操作に組み合わせる・またはコミュニティサーバーが満たさないコンプライアンス要件を満たす場合に正しい選択だ。

なぜ Claude Code が時々カスタム MCP ツールを無視して組み込みツールを使うのか？

tool の説明が重複するツール間の選択に Claude が使うルーティングメカニズムだからだ。Bash や Read のような組み込みツールは、弱く説明されたカスタムツールに対してルーティングコンテストで勝つよく調整された説明で出荷される。修正は組み込みツールを制限することではほぼない——それは脆弱性を導入する。耐久性のある修正はカスタム MCP tool の説明を書き直すこと：特定の目的・組み込みツールに対する境界（「kubectl を直接実行する代わりにこれを使用する」）・例を持つ入力形式・出力形状を命名する。具体的で境界を意識した説明がルーティングコンテストに勝ち、Claude の優先する選択になる。

CCA-F 試験は MCP server のデプロイとホスティングをテストするか？

しない。CCA-F Domain 2 タスク2.4 は統合——Claude Code から MCP server を設定・スコープ・クレデンシャル管理・使用する方法——をテストし、デプロイはテストしない。リモート MCP server の Kubernetes ingress・TLS 終端・水平スケーリング・カスタムトランスポートプロトコルは範囲外だ。試験はファインチューニング・ビジョン・ストリーミング API の詳細・クラウドプロバイダー固有の設定もテストしない。試験の点数があるプロトコル・スコーピング・設定の表面内に留まる。

さらなる読み物

• Claude Code MCP Integration Docs: https://docs.anthropic.com/en/docs/claude-code/mcp
• Model Context Protocol Introduction: https://modelcontextprotocol.io/introduction
• MCP Build a Server Guide: https://modelcontextprotocol.io/docs/develop/build-server
• MCP Connector for the Messages API: https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector
• Anthropic Engineering — Writing Tools for Agents: https://www.anthropic.com/engineering/writing-tools-for-agents
• Claude Code Tool Reference (Built-in Tools): https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• CCA-F Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf

関連 ExamLab 章節：ツール設計と MCP 統合の概要、MCP ツールの構造化エラー応答、Claude Code 組み込みツール、CLAUDE.md 設定階層、ルーティングメカニズムとしてのツール説明。