# MCPとは — AI Agentと外部システムを接続するプロトコル > Model Context ProtocolのHost・Client・Server構成、Tools・Resources・Prompts、Transport、認可と本番導入時の境界を整理します。 Canonical URL: https://labs.eastbraver.com/guides/mcp Published: 2026-07-01 Updated: 2026-07-24 Category: field-guide Tags: remote-mcp, ai-agent, software-engineering MCPはModel Context Protocolの略で、AIアプリケーションが外部のデータ、[Tool](/guides/tool)、定型[Prompt](/guides/prompt-and-instruction)へ接続するためのオープンプロトコルです。 MCPを使うと、AIアプリケーションごとに独自のTool接続方式を作る代わりに、共通のメッセージとライフサイクルで機能を公開できます。ただし、MCPはAgentそのものではありません。接続しただけで、認証・認可・監査まで完成するわけでもありません。 このGuideは、2026年7月1日時点で公開されているMCP仕様2025-11-25を基準にしています。MCPは仕様更新が続いているため、実装時には利用するClient、Server、SDKが対応するProtocol Revisionも確認してください。 ## MCPはAIアプリケーションと機能提供側の接続境界 [MCPの公式仕様は、Host、Client、Serverの構成を定義しています](https://modelcontextprotocol.io/specification/2025-11-25/architecture)。 ### MCPの接続モデル MCP Hostは用途ごとのMCP Clientを介して複数のMCP Serverへ接続します。各ServerはFiles、API、Database、SaaSなど固有の外部資源との境界を受け持ちます。 - UserはMCP Hostを備えたAI applicationへ要求を送ります。 - Hostは接続先ごとのMCP Clientへ処理を委ねます。 - 各Clientは対応するMCP Serverと通信し、Serverが外部資源へアクセスします。 *HostからClientとServerを経由して外部資源へ接続する構成* ### Host AIアプリケーション本体です。複数のClientを管理し、LLMとの統合、接続権限、利用者の同意、Contextの集約を扱います。どのServerを接続し、どの情報をモデルへ渡すかはHost側の責任であり、[Context Engineering](/guides/context-engineering)の対象になります。 ### Client Hostの内部で、特定のServerとの接続を担当します。一つのClientは一つのServerと状態を持つSessionを確立し、Capability negotiationとメッセージの送受信を行います。 ### Server Tool、Resource、Promptを公開します。ローカルプロセスとして動く場合と、ネットワーク越しのRemote MCP Serverとして動く場合があります。 Serverが複数ある場合も、Server同士が会話全体を共有する構成ではありません。公式アーキテクチャでは、完全な会話履歴をHostに残し、各Serverには必要なContextだけを渡す。この分離が設計原則として示されています。 ## Tools、Resources、Promptsは役割が異なる ### Tools モデルが選択して呼び出す操作です。検索・API呼び出し・ファイル更新・チケット作成を、名前、説明、入力Schemaとともに公開します。[MCP仕様ではToolsをmodel-controlledとして説明しつつ、人間が呼び出しを拒否できる仕組みを持つことを推奨しています](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)。 ### Resources ファイル・ドキュメント・Schema・アプリケーション固有データといったContextをURIで公開します。Hostは必要なResourceを取得し、モデルへ渡せます。 ### Prompts Server側が用意する再利用可能なPrompt templateです。利用者やHostが選択して使う想定で、Toolのような外部操作とは役割が異なります。 ### Client側の機能 MCPには、ServerからHost側のLLM利用を依頼するSamplingや、利用者へ追加情報を求めるElicitationもあります。どの機能を使えるかは、接続開始時のCapability negotiationで確認します。 ## APIやFunction Callingとの違い | 仕組み | 主な役割 | 標準化する範囲 | | --- | --- | --- | | HTTP API | システム間の機能・データ提供 | Endpoint、Request、Response | | Function Calling / Tool Calling | モデルが呼ぶ関数の表現 | Tool名、入力Schema、呼び出し結果 | | MCP | AIアプリケーションとServerの接続 | Session、Capability、Tools、Resources、Prompts、Transport | | AI Agent | 目標に向けた判断と実行 | 処理経路、Tool選択、停止判断 | MCP Serverの内側で既存のHTTP APIを呼び出す構成は一般的です。MCPはAPIを置き換えるというより、AIアプリケーションからAPIやデータを扱う接続層、と考える方が分かりやすいと思います。 Function CallingはモデルAPIの機能としてTool呼び出しを表現します。MCPはTool一覧の取得、呼び出し、結果返却に加えて、Resource、Prompt、Session、Capability negotiation、Transportを含みます。 AI Agentは目標に応じて何を実行するかを決めるシステムです。MCPはAgentが利用できる接続方式の一つ。Agent loopや業務上の終了条件までは定義しません。 ## TransportはローカルとRemoteで分かれる [MCP仕様2025-11-25は、標準TransportとしてstdioとStreamable HTTPを定義しています](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports)。 ### stdio HostがMCP Serverを子プロセスとして起動し、標準入力と標準出力でJSON-RPCメッセージを交換します。ローカルの開発ToolやDesktopアプリケーションで使いやすい一方、起動するプロセス・ファイルアクセス・環境変数・秘密情報の扱いはHost側で制限します。 ### Streamable HTTP HTTP POSTとGETを使い、ネットワーク越しに接続します。複数利用者から使うRemote MCP Serverに向きます。認証・認可・TLS・Origin検証・Session管理・レート制限・監査ログまで、Webサービスとして設計します。 ClientとServerが同じMCP対応を名乗っていても、Protocol Revisionと対応Capabilityが一致するとは限りません。「MCP対応」だけで判断せず、接続時のnegotiationと、利用する機能の互換性を確認します。 ## MCP対応は認証・認可の完了を意味しない [MCPのAuthorization仕様](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)は、HTTPを使うTransport向けの認可Frameworkを定義しています。OAuthを使えることと、業務上正しい[IdentityとAuthorization](/guides/ai-identity-authorization)を設計できていることは別。ここは混同したくないところです。 本番導入では、少なくとも次を分けて考えます。 - ClientがServerへ接続してよいか - 利用者がそのToolを利用してよいか - Agentが利用者の代理でどの操作まで行えるか - Toolの実装先APIが操作を許可するか - 高リスク操作へ追加承認が必要か - 誰が、いつ、どの引数で実行したか記録できるか 広い管理権限を持つTokenをMCP Serverへ一つ渡し、Tool名だけで操作を分ける構成では、Serverが侵害された場合や誤ったTool呼び出しの影響が広がります。避けておきたい構成です。[MCPのSecurity Best Practicesは、初期Scopeを読み取りなどの低リスク操作へ絞り、必要な時点で段階的に権限を引き上げるleast-privilegeモデルを示しています](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)。 Toolの説明に「管理者だけ」と書いても、認可にはなりません。Serverと実際のAPIで、IdentityとScopeを検証します。 ## Webシステムへ組み込むときの実装単位 既存システムをMCP対応にするとき、内部APIをそのまますべてToolへ変換すると、Tool数、権限、説明、評価の範囲が広がります。 最初は、利用目的が明確な操作へ絞ります。 - 注文番号から状態を取得する - 指定した顧客の公開可能な情報を返す - 下書きチケットを作成する - 承認済みのチケットを更新する 一つの万能Toolへ任意のEndpointとRequest bodyを渡すより、業務操作ごとに入力Schemaと権限を固定する方が、モデルは選びやすく、監査と評価も行いやすくなります。 入力はSchemaで検証し、Tool結果は成功と失敗を区別します。更新系ではIdempotency key・タイムアウト・再試行可否・取り消し方法も決めます。MCP固有の話というより、既存のWeb API運用で必要だった設計を、Tool接続にも適用するイメージです。 ## よくある誤解 ### MCP ServerをつなげればAgentになる MCPは接続と機能公開のプロトコルです。目標・Agent loop・終了条件・評価は、HostやAgent側で設計します。 ### MCP対応ならServerを安全に使える 仕様へ準拠していても、公開したTool・Token・Scope・Server実装が安全とは限りません。接続元の確認・最小権限・入力検証・監査・承認は別途設計します。 ### Toolを増やすほどAgentができることも増えてよい Toolが増えると、モデルが選ぶ候補と誤選択も増えます。利用頻度が低い管理操作まで常時公開せず、役割や業務ごとにTool集合を分けます。 ### MCPが既存APIを置き換える MCP Serverが既存APIを呼び出す構成では、業務ルールとデータ整合性は引き続きAPI側が持ちます。MCPが追加するのは、Agent向けの接続面です。 ### Remote MCPだけ認可を考えればよい stdioでも、起動したServerはローカルファイル、環境変数、他プロセスへアクセスできる場合があります。Remoteとは脅威が異なりますが、実行権限と隔離は必要です。 ## EastBraver Labsの判断基準 EastBraver Labsでは、MCPを接続数を増やすための仕組みではなく、**AI Agentへ渡す機能と責任を明示する境界**として扱います。 MCP Serverを導入するときは、対応Tool数より先に次を確認します。 - ToolごとのIdentityと最小Scopeを説明できるか - 読み取りと更新を分離できるか - 取り消せない操作を承認対象にできるか - 入力、実行者、結果を追跡できるか - Server停止時に本体のWebシステムまで巻き込まないか - SDKやProtocol Revisionの更新を検証できるか 最初の接続では、読み取り専用で、結果を人間が確認できるToolを選びます。まずは手元から。更新系はIdempotencyと監査を先に作り、失敗時に戻せる範囲から追加します。 MCPを採用するかどうかも、流行や対応製品数だけでは決めません。複数のHostから共通Toolを利用する、ResourceとToolを同じ接続で扱う、Remote Serverとして認可を標準化する。その利点が、自前のHTTP API接続より運用コストを下げるかで判断します。 ## 関連記事 - [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708) - [エージェント運用の境界が具体化](/digest/ai-digest-20260709) - [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710) ## 検証範囲 - 一次情報: 公式ドキュメント / 仕様書 / 設計面からの分析 - ローカル検証: 手元で再現しています - 実運用: 本番運用の実績については、このGuideでは触れていません ## 変更履歴 - 2026-07-24: Mermaid図にテキスト等価物を追加 - 2026-07-15: 検証範囲と根拠区分を明示 - 2026-07-01: 初版公開