MCPの要点整理　2025/06/01時点

Model Context Protocol (MCP) 技術仕様の要点

AIとの連携において、MCPが重要なことはわかったが、実装するに当たり、基本的な理解が足りないと無駄な実装や、セキュリティ的にまずい実装をしそうなので、技術仕様の要点をまとめようと思いました。

今回は「通信仕様」と「セキュリティ」の2つの観点に絞って、MCPを使ったシステムを開発するときに押さえておきたいポイントを整理します。

通信仕様

1. プロトコルは JSON-RPC 2.0

MCPでは、あらかじめ定義された JSON フォーマットJSON-RPC 2.0を使ってメッセージをやり取りします。

リクエスト／レスポンスともに所定の形式に従った JSON ボディを用いることで、クライアント（AIアプリ）⇄サーバー間の互換性を担保します。

2. トランスポート方式は複数。STDIO と HTTP ベースが基本

MCPでは「どのようにコネクションを張ってJSON-RPCを送るか」にもルールがあります。主に以下の２パターンが代表的です。

2-1. ローカル開発向け：STDIO（標準入出力）

AIアプリケーションとMCPサーバーを同じマシンに置いて開発するときは、プロセス間通信として STDIO を使うのが最も手軽。

「AI側がMCPサーバーをサブプロセスとして起動し、標準入力からJSONを受け取り、標準出力に結果を返す」だけなので、ポート開放や認証の手間なく始められます。

ただし、このまま本番に持っていくことは少なく、あくまでローカル検証用のスタイルと考えましょう。
https://modelcontextprotocol.io/docs/concepts/architecture#python

2-2. リモート向け：HTTPベース（SSE や ストリーミングHTTP）

実際の運用では HTTP(S) を使ったトランスポートが必要ですが、従来は以下のような形が主流でした。

• HTTP POSTでリクエスト
  クライアント→サーバーに対して通常の HTTP POST で JSON-RPC リクエストを送信し、

• SSE（Server-Sent Events）でレスポンスをストリーミング
  サーバー→クライアントへは SSE によって一方向にデータを流す仕組みです。

  • SSE はサーバーからの一方通行ストリーミングなので、クライアント→サーバーの双方向性は HTTP POST 側に依存します。

  • 会話的な応答（チャットのように細かくやり取りする場合）ではややレイテンシが大きくなりがちです。

最新の MCP 仕様(2025-03-26版)では、SSE よりも ストリーミング可能な HTTP トランスポート（例：HTTP/2 のストリーミングや HTTP/1.1 のチャンク形式など）を推奨しています。

• クライアント→サーバー：HTTP POST（これまで通り）

• サーバー→クライアント：ストリーミングHTTP

  • HTTP/2 や HTTP/1.1 のチャンク転送などを活用し、複数メッセージをシームレスに送ることができます。

  • これにより、会話的（チャット的）なやり取りでレスポンスを逐次受け取りつつ、SSE よりも低い遅延で双方向通信が可能になります。

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http

セキュリティ対策

1. 通信の暗号化（TLS/HTTPS）

MCPに限らず、AIと外部システムをやり取りする以上は 通信路の暗号化 が基本中の基本です。

HTTPトランスポートを使うなら、必ず TLS（HTTPS） で暗号化しましょう。平文のままJSONを飛ばすと、中間者攻撃や盗聴でやり取り中の資格情報や機密データが丸見えになります。

2. 認証・認可モデルの設計

MCPプロトコル自体には「誰がどこまで使えるか」を規定する仕組みがありません。したがって、実装側でしっかり設計する必要があります。

HTTP(S) 接続＋OAuth 2.1

実運用ではHTTPSを使う前提で、認証・認可は OAuth 2.1（あるいはOAuth 2.0 + PKCEなど）をベースに設計するのが一般的です。

クライアントが最初に認可サーバーでアクセストークンを取得し、そのトークンを HTTPヘッダー（Authorization: Bearer <token>）に載せてMCPサーバーにリクエストします。

MCPサーバーは送られてきたトークンを検証し、有効であればJSON-RPCリクエストを受け入れ、無効なら 401/403 で弾く、という流れです。

「社内用」なのか「社外に公開するAPI」なのかによって、OAuthのクライアント認可フロー（クライアントクレデンシャルズ、認可コード等）を使い分けてください。

認可 (Authorization)

認証が済んだあと「認証済ユーザーにどこまでの権限を与えるか」を判定するモデルです。

以下のような形で 最小権限の原則 を徹底しましょう。

AIエージェント／ユーザーA は「このツールだけ叩いていい」

AIエージェント／ユーザーB は「ファイルの読み書きはできるけど、ネットワークアクセスはNG」

AIエージェント／ユーザーC は「特定のデータベーステーブルに限ってSELECTのみ許可」

権限情報はたとえば RBAC（ロールベースアクセス制御） や スコープベース のトークンに含めて実装するとわかりやすいです。

ユーザーや部署ごとに権限が変わるような企業システムであれば、MCPサーバー側に「このアクセストークンにはこのリソースだけ使えますよ」という情報を持たせておき、処理ごとにチェックするロジックを入れておきましょう。

3. 改ざん検知とデータ整合性

MCPではクライアント⇄サーバー間でJSONメッセージをやり取りしますが、その途中で改ざんされては困ります。以下の対策を講じましょう。

TLSによる改ざん防止

TLS暗号化を使うことで、通信経路上の盗聴・改ざん・なりすましを総合的に防止できます。

HTTP(S)以外にも、独自ソケットでやり取りするときはアプリケーションレイヤーでメッセージのハッシュや署名を付与するなどして検証する仕組みを組み込みましょう。

JSON Schema や バリデーションチェック

MCPメッセージを受け取ったら、必ず 構文チェック を行い、 想定外のフィールドや文字列長オーバーなどがあればエラーにします。

もし不正なデータが来たら「400 Bad Request」や「JSON-RPC のエラーコード (-32602: Invalid params など)」で返して、処理を止めるようにしてください。

これによって、たとえば「AIが悪意を持って不正なSQLを埋め込んだメッセージを送ってくる」ような攻撃を防ぐことができます。

メッセージサイズ制限とペイロードチェック

想定よりも巨大なJSONメッセージを受け付けるとメモリを圧迫し、DoS攻撃につながることがあります。

送受信するJSONのサイズを適切に上限設定し（たとえば 1MB 以内など）、超過したらエラーにするなどして、過負荷や悪意あるペイロードをブロックしましょう。

4. その他の運用上のセキュリティ施策

4-1. レートリミットとタイムアウト

AI側のバグや暴走で同一ツールに対して過剰にリクエストが飛ぶケースがあります。

一定時間あたりのAPIコール回数に制限 を掛け（例：1秒間に10回まで）、それ以上は「429 Too Many Requests」を返すようにすると、バックエンドの過負荷を緩和できます。

またレスポンスタイムが想定外に伸びたら、自動的にコネクションを切るための タイムアウト設定 も必須です。ユーザーが待ちぼうけになるのを防ぐと同時に、サーバー資源の枯渇を防ぎます。

4-2. ローカル開発時の注意点（DNSリバインディング対策など）

ローカルで HTTP(S) を使ったMCPサーバーを起動するとき、ブラウザベースのAIフロントエンドから意図せずアクセスされるリスクがあります。

たとえば 「攻撃者が DNS をコントロールしている環境下で、ユーザーが悪意のあるサイトにアクセスしてしまい、そのサイト経由でローカルのMCPサーバーにリクエストを送らせる」ような DNSリバインディング攻撃 があります。

対策として、HTTPサーバーを 127.0.0.1 （localhost）のみバインドする、HTTPヘッダーの Origin を確認して「許可ドメイン以外はブロック」する、といった設計にしておきましょう。

つまり「http://localhost:5000」のみを許可し、「http://evil.example.com」がローカルMCPに触れないようにするのがポイントです。

4-3. ログと監査

MCPを介した操作はすべて 詳細ログに記録 しておきましょう。

リクエスト内容（どのツールを何回実行したか、どのユーザー／クライアントから来たか）やレスポンス結果（成功かエラーか）を1対1で紐付ける形で保存します。

これにより、万一不正アクセスが疑われた場合や、AIが思わぬ挙動をしたときに原因をたどりやすくなります。

さらに必要に応じて SIEM（Security Information and Event Management） と連携し、不審なアクセスパターンをリアルタイムでアラートしたり、後からレポートを出したりするのもおすすめです。

まとめ

MCPを実装するとき、通信方式（STDIO vs. HTTP/ストリーミング）とJSON-RPCフォーマットはまず押さえておく。

認証は「MCP自体にはないけど、実装ではOAuth 2.1やmTLSを使う」のが一般的。

レスポンスはあくまでJSON-RPCに沿った形で、拡張しすぎず互換性を維持する。

セキュリティは多層的に設計し、通信暗号化・認証・認可・改ざん検知・レート制限・ログ監査などを組み合わせて安全性を確保する。

今回、基本的なところを確認できたので、社内用のMCPサーバを作成するうえで、必要そうな知識を追って整理していこうと思います。