メインコンテンツへスキップ
EastBraver Labs

Guides

MCPとは — AI Agentと外部システムを接続するプロトコル

Model Context ProtocolのHost・Client・Server構成、Tools・Resources・Prompts、Transport、認可と本番導入時の境界を整理します。

(更新日:)9分で読めます
#remote-mcp#ai-agent#software-engineering

MCPはModel Context Protocolの略で、AIアプリケーションが外部のデータ、Tool、定型Promptへ接続するためのオープンプロトコルです。

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の構成を定義しています。

MermaidMCPの接続モデルHostからClientとServerを経由して外部資源へ接続する構成

MCP Hostは用途ごとのMCP Clientを介して複数のMCP Serverへ接続します。各ServerはFiles、API、Database、SaaSなど固有の外部資源との境界を受け持ちます。

  1. UserはMCP Hostを備えたAI applicationへ要求を送ります。
  2. Hostは接続先ごとのMCP Clientへ処理を委ねます。
  3. 各Clientは対応するMCP Serverと通信し、Serverが外部資源へアクセスします。

Host

AIアプリケーション本体です。複数のClientを管理し、LLMとの統合、接続権限、利用者の同意、Contextの集約を扱います。どのServerを接続し、どの情報をモデルへ渡すかはHost側の責任であり、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として説明しつつ、人間が呼び出しを拒否できる仕組みを持つことを推奨しています。

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、呼び出し結果
MCPAIアプリケーションと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を定義しています。

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仕様は、HTTPを使うTransport向けの認可Frameworkを定義しています。OAuthを使えることと、業務上正しいIdentityとAuthorizationを設計できていることは別。ここは混同したくないところです。

本番導入では、少なくとも次を分けて考えます。

  • ClientがServerへ接続してよいか
  • 利用者がそのToolを利用してよいか
  • Agentが利用者の代理でどの操作まで行えるか
  • Toolの実装先APIが操作を許可するか
  • 高リスク操作へ追加承認が必要か
  • 誰が、いつ、どの引数で実行したか記録できるか

広い管理権限を持つTokenをMCP Serverへ一つ渡し、Tool名だけで操作を分ける構成では、Serverが侵害された場合や誤ったTool呼び出しの影響が広がります。避けておきたい構成です。MCPのSecurity Best Practicesは、初期Scopeを読み取りなどの低リスク操作へ絞り、必要な時点で段階的に権限を引き上げるleast-privilegeモデルを示しています。

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接続より運用コストを下げるかで判断します。

関連記事