MCP（Model Context Protocol）完全ガイド

MCP（Model Context Protocol）は、Claude Codeを単なる「コードを書くツール」から「外部のシステムと連携しながら作業を進めるエージェント」へと変える、中心的な仕組みです。実践レシピのMCPサーバーをローカル環境で設定するや開発に役立つMCPサーバーを導入するでは「どう設定するか」を手順ベースで解説しましたが、本ガイドではその一歩手前、MCPがそもそもどういう仕組みで成り立っているのかを、アーキテクチャの観点からじっくり掘り下げます。設定手順だけを知りたい場合は上記のレシピを先に参照することをおすすめします。

このガイドで学べること

• MCPのクライアント/サーバーアーキテクチャの全体像
• ローカル（stdio）とリモート（HTTP）のMCPサーバーの構造的な違い
• MCPサーバーが「何を提供しているか」という機能の分類
• 自作MCPサーバーを検討する際の設計の考え方
• セキュリティ上のリスクと、それに対する防御的な考え方
• トラブルシューティングを「仕組みの理解」から行うアプローチ

MCPとは何か、なぜ生まれたのか

Claude CodeのようなAIコーディングツールが普及するにつれて、「AIをそれぞれの外部サービスに接続するための連携部分を、サービスの数だけ個別に作らなければならない」という課題が浮き彫りになりました。GitHub用の連携、Slack用の連携、データベース用の連携……これをツールごと・サービスごとに毎回ゼロから実装するのは非効率です。

MCPは、この「AIツールと外部サービスの間の連携」を標準化するためのオープンプロトコルです。一度MCPに対応したサーバーを作っておけば、Claude Codeに限らず、MCPに対応した別のAIツールからも同じサーバーを利用できます。逆に言えば、Claude Code自身もMCPという共通言語さえ話せれば、世の中に存在するあらゆるMCP対応サービスと連携できるようになります。

アーキテクチャの全体像: クライアント/サーバーモデル

MCPは、クライアントとサーバーという2つの役割に分かれたシンプルなモデルで構成されています。

graph LR
    subgraph "Claude Code（MCPクライアント）"
        CC["Claude Codeのエージェントループ"]
    end
 
    subgraph "MCPサーバー群"
        S1["GitHub MCPサーバー"]
        S2["データベースMCPサーバー"]
        S3["自作MCPサーバー"]
    end
 
    subgraph "実体"
        E1["GitHub API"]
        E2["PostgreSQL"]
        E3["社内システム"]
    end
 
    CC -->|"ツール呼び出し"| S1
    CC -->|"ツール呼び出し"| S2
    CC -->|"ツール呼び出し"| S3
 
    S1 --> E1
    S2 --> E2
    S3 --> E3
 
    style CC fill:#e8f4fd,stroke:#1a73e8

ここで重要なのは、Claude Code自身は個々の外部サービスの仕様を一切知らないという点です。Claude CodeはMCPサーバーに対して「どんなツールが使えますか」と問い合わせ、サーバー側がツールの一覧（名前・説明・パラメータの型）を返します。Claude Codeはその情報をもとに、必要に応じてツールを呼び出します。

つまりMCPサーバーは、外部サービスの複雑な仕様を「Claude Codeが理解できるシンプルなツールの形」に変換する翻訳者のような役割を果たしています。GitHub MCPサーバーの裏側がどれだけ複雑なAPI仕様を持っていても、Claude Codeから見えるのは「Issueを作成する」「PRをレビューする」といった、意味のまとまった単位のツールだけです。

MCPが提供する3つの機能カテゴリ

MCPサーバーは、主に3種類の機能をクライアントに提供できます。

実際に多くの場面で使われるのはToolsですが、Resourcesを使えば「このIssueの内容を見ながら作業して」という指示を@github:issue://123のような形で簡潔に表現できますし、Promptsを使えばサーバー側で定義した定型ワークフローをコマンド感覚で呼び出せます。MCPサーバーを評価するときは、Toolsの数だけでなく、ResourcesやPromptsをどう活用できるサーバーかという視点も持つと理解が深まります。

ローカル（stdio）とリモート（HTTP）の構造的な違い

MCPサーバーには大きく分けて「ローカルで自分のマシン上のプロセスとして動くもの」と「リモートでクラウド上にホストされているもの」があります。この違いは単なる設定上の違いではなく、アーキテクチャ的な性質の違いでもあります。

graph TD
    subgraph "ローカル（stdio）サーバー"
        L1["Claude Codeプロセス"]
        L2["子プロセスとして起動<br/>標準入出力で通信"]
        L1 -->|"起動・通信"| L2
    end
 
    subgraph "リモート（HTTP）サーバー"
        R1["Claude Codeプロセス"]
        R2["クラウド上のサーバー"]
        R1 -->|"HTTPリクエスト/レスポンス"| R2
    end
 
    style L2 fill:#fff3e0,stroke:#e65100
    style R2 fill:#e8f4fd,stroke:#1a73e8

ローカル（stdio）サーバーの性質

stdioサーバーは、Claude Codeが起動時に子プロセスとして立ち上げ、標準入出力（stdin/stdout）を通じてJSON-RPCメッセージをやり取りします。マシン上に存在するファイルシステムやローカルプロセスに直接アクセスできるため、ブラウザ操作（Playwright MCP等）やローカルファイルの高度な操作、ローカルで動いているデータベースへの接続などに向いています。

認証情報はサーバー起動時の環境変数として渡されることが多く、外部にトークンを送信する経路がない分、設計次第ではリモートサーバーよりも閉じた構成にしやすいという特徴があります。一方で、Claude Codeのセッションが動いているマシンでしか使えず、チームで同じ体験を共有するには各自の環境にサーバーをセットアップしてもらう必要があります。

リモート（HTTP）サーバーの性質

HTTPサーバーは、クラウド上でホストされた1つのサーバーに対して、複数のクライアント・複数のユーザーが接続する構成です。SaaSサービス（GitHub、Sentry、Notionなど）が公式に提供するMCPサーバーの多くはこの形態を取ります。OAuth 2.0による認証フローをサポートしており、/mcpコマンドからブラウザ経由でログインすることで、安全にトークンを発行・更新できます。

リモートサーバーの強みは、ローカル環境のセットアップが不要で、サーバー側のアップデートが自動的に全クライアントに反映される点です。一方で、ネットワーク越しの通信が前提になるため、ローカルサーバーに比べると接続の安定性やレイテンシの影響を受けやすく、また「外部のサーバーがどこまでデータを保持するか」という、自分のコントロールが及ばない領域が増えることにも注意が必要です。

主要なMCPサーバーをアーキテクチャ視点で分類する

実践レシピの開発に役立つMCPサーバーを導入するでは具体的な導入手順を紹介しましたが、ここではサーバーの「設計思想」という切り口で分類してみます。

この分類を意識すると、新しいMCPサーバーに出会ったときに「これはどの設計思想に近いか」を素早く把握でき、導入の判断や、期待していい挙動の見積もりがしやすくなります。たとえばAPI直結型のサーバーは、裏側のAPI仕様の制約（レート制限など）をそのまま引き継ぐ傾向がある、といった具合です。

自作MCPサーバーの考え方

自分たちのプロダクトや社内システムに合わせたMCPサーバーを自作したくなる場面は珍しくありません。本ガイドでは実装の詳細なチュートリアルは扱いませんが、設計時に意識しておくべき考え方を紹介します。

ツールの粒度を「人間が依頼する単位」に合わせる

自作する際に陥りがちな失敗が、内部APIの関数をほぼそのままツールとして公開してしまうことです。たとえば「ユーザーIDからユーザー名を取得する」「ユーザーIDからメールアドレスを取得する」という細かいツールを別々に作るより、「ユーザー情報を取得する」という1つのまとまったツールにし、必要な情報をまとめて返す方が、Claude Codeにとっても扱いやすくなります。MCPツールの設計は、API設計というより、**「何も知らない新入社員に何をどう依頼するか」**に近い感覚で考えると筋が良くなります。

ツール数より説明の質を優先する

MCPサーバーが増えるとコンテキストを圧迫するのではないかという懸念をよく聞きますが、Claude Codeにはツール検索の仕組みが備わっており、必要なツールだけをオンデマンドで読み込むようになっています。そのため、ツールの「数」そのものより、各ツールの説明文（description）がどれだけ的確に書かれているかの方が、実用上は重要です。曖昧な説明のツールは、検索の仕組みがあっても正しく見つけてもらえません。

認証情報をハードコードしない設計にする

自作サーバーであっても、APIキーやトークンはサーバー起動時の環境変数として受け取る設計にし、設定ファイルやコードに直接書き込まない構成を徹底します。これはMCPに限った話ではありませんが、外部接続を前提とするMCPサーバーだからこそ、最初の設計段階で徹底しておきたい原則です。

セキュリティ上の注意点

MCPサーバーは、Claude Codeに強力な権限を与える仕組みであるため、セキュリティの考慮は欠かせません。

信頼できる提供元のサーバーのみを接続する

MCPサーバーはClaude Codeの代わりに外部とやり取りするため、悪意のあるサーバーや、脆弱性のあるサーバーを接続してしまうと、意図しない操作が実行されるリスクがあります。特に外部コンテンツを取得するタイプのサーバー（Web検索、メール、チケット管理ツールなど）は、取得した内容に紛れ込んだ悪意ある指示によってClaude Codeの挙動を操作される「プロンプトインジェクション」のリスクにもさらされやすいため、サーバーの提供元が信頼できるかを必ず確認しましょう。

最小権限の原則を徹底する

データベースMCPサーバーを例にとると、本番データベースへの接続には読み取り専用のユーザーを使う、操作可能なテーブルを制限する、といった「最小権限」の考え方が重要です。MCPサーバー自体がどれだけ安全に作られていても、接続先の権限が広すぎれば、意図しないクエリが実行されたときの被害も大きくなります。

機密情報の取り扱い

APIキーやトークンは環境変数で渡し、.mcp.jsonにハードコードしないことが基本です。プロジェクトスコープの.mcp.jsonをリポジトリにコミットする場合は特に、コミット前に機密情報が混ざっていないか確認する習慣をつけましょう。

組織導入を見据える場合は、許可・拒否するMCPサーバーを組織レベルで一元管理する仕組みも用意されています。詳しい権限設計の考え方はClaude Codeセキュリティ設計ガイドで扱っています。

トラブルシューティングの考え方

MCP関連のトラブルは多岐にわたりますが、闇雲にエラーメッセージで検索するより、「クライアント・サーバー・通信経路・認証」のどこで問題が起きているかを切り分けることが近道です。

flowchart TD
    A["MCPサーバーがうまく動かない"]
    B{"サーバーは接続されているか?<br/>(/mcp や claude mcp list で確認)"}
    C{"ツールは表示されているか?"}
    D{"認証は完了しているか?"}
    E["起動コマンド・パス・<br/>環境変数を確認"]
    F["サーバー側の実装・<br/>権限設定を確認"]
    G["OAuth再認証 or<br/>トークンの有効期限を確認"]
    H["ツール呼び出し自体の<br/>エラー内容を確認"]
 
    A --> B
    B -->|未接続| E
    B -->|接続済み| C
    C -->|表示されない| D
    D -->|未認証| G
    D -->|認証済み| F
    C -->|表示されている| H
 
    style A fill:#fff3e0,stroke:#e65100

この切り分けを行うだけで、「コマンドのタイプミス」「ネットワークの問題」「認証切れ」「サーバー側の権限不足」のどれが原因かをかなり早い段階で絞り込めます。具体的なエラーパターンごとの対処法は、実践レシピのよくあるエラーと対処法を知りたいやMCPサーバーをローカル環境で設定するのトラブルシューティングセクションも参考にしてください。

まとめ

MCPは、Claude Codeと外部世界をつなぐ「共通言語」としてのプロトコルです。クライアント/サーバーという単純なモデルの上に、Tools・Resources・Promptsという3つの機能カテゴリが乗り、ローカル（stdio）とリモート（HTTP）という2つの接続方式が選べる、という全体構造を理解しておくと、新しいMCPサーバーに出会ったときにも迷わず判断できるようになります。

自作を検討する際は「人間が依頼する単位」でツールを設計し、セキュリティの観点では「信頼できる提供元か」「最小権限になっているか」を常に問い直す。この基本姿勢があれば、MCPエコシステムが今後どれだけ拡大しても、適切に向き合っていけるはずです。