社内の MCP 利用を棚卸しするとき、ネットワークの検知ログだけでは一覧を完成できません。
ローカルの標準入出力で行う通信は HTTP 検査を通らず、HTTP を使う接続でも検査の除外や経路によって記録される内容が異なるためです。
管理しているクライアントの設定と実行記録を、ネットワーク側の記録に突き合わせます。
MCP（Model Context Protocol） は、AI アプリと外部のツールやデータを接続するためのプロトコルです。
Cloudflare は 2026 年 8 月 14 日の解説で、クライアント内部、ネットワーク、MCP サーバーの三つに制御点を分けています。
以下は、この解説と MCP 仕様を基にした設計レビュー案です。
特定製品の導入手順や、実機で検出率を測った報告ではありません。
接続方式と通る経路
最初に、MCP クライアントからサーバーへどう接続しているかを確認します。
stdio は、クライアントが起動したサブプロセスと標準入出力でメッセージを交換する方式です。
2026-07-28版の仕様では、この方式に HTTP ヘッダー層はありません。
したがって、このやり取りを外向きの HTTP 検査で読むことはできません。
一方、Streamable HTTP は HTTP エンドポイントへメッセージを送る方式です。
接続先が社外にあるとは限りません。
同じ端末のローカル HTTP サーバーに接続する場合もあるため、「HTTP なら社外のゲートウェイを通る」とは扱いません。
stdio を使うサーバープロセスが、別途 SaaS の API を呼ぶ構成も考えられます。
その外部通信がネットワークで観測できても、クライアントとの stdio の内容まで見えたことにはなりません。
「ローカル MCP は通信しない」ではなく、どの二者間の通信を見ているかを区別します。
| 接続や処理 | ネットワーク検査で確認できる範囲 | 照合する情報 |
|---|---|---|
| 管理ゲートウェイを通るリモート HTTPS | TLS 検査が適用され、製品が対応する場合の HTTP ヘッダーや本文 | 端末、利用者、接続先、検査ルール、クライアントの設定 |
| TLS 検査を除外した HTTPS | 同じ復号検査でヘッダーや本文は読めない。接続のメタデータは製品や構成による | 除外理由、対象、期限、代替の記録 |
| 外向きの検査を通らないローカル HTTP | その外向き検査では扱わない | 待受先、プロセス、クライアントとサーバーの記録 |
| ローカル stdio | 標準入出力の MCP メッセージは HTTP 検査の対象外 | 起動した実行ファイル、その版、実行ユーザー、許可した操作 |
| ローカル MCP サーバーから外部 API への接続 | 実際に通った経路と検査設定に応じた外部通信 | 外部接続を行ったプロセス、接続先、使用する権限 |
| 管理ゲートウェイを通らないリモート接続 | そのゲートウェイの検知ログには残らない | 端末側の記録、許可された接続経路、サーバー側のアクセス記録 |
ネットワーク担当者は検査した経路を、端末担当者は起動を許可したプロセスを確認します。
この表に担当者と証跡の保存先を追記すると、未確認の行がどこに残っているかを整理できます。
プロトコルのヘッダーと検知の限界
MCP-Protocol-Version は、HTTP 通信を識別する手掛かりになります。
ただし、付くタイミングはプロトコルの版で異なります。
| 参照した版 | 仕様上のヘッダー要件 | ログを読むときの注意 |
|---|---|---|
| 2025-06-18 | 初期化後の HTTP リクエストに付ける | 初回から同じヘッダーが付く前提にしない |
| 2026-07-28 | MCP エンドポイントへの各 POST リクエストに付ける | 対象クライアントとサーバーがこの版を使っているか確認する |
出典：2025-06-18版、2026-07-28版。
全版の差分を網羅した表ではありません。
仕様に要件があっても、すべての通信が準拠しているとは限りません。
ヘッダーが見つからない理由には、旧版、検査対象外、独自の接続方式、非準拠の実装などがあります。
逆にヘッダーを見つけても、そのサーバーが組織で承認済みであることや、操作が安全であることまでは証明できません。
識別に使う値と、利用を許可する根拠を分けます。
Cloudflare の解説も、ホスト名や URL に mcp が含まれるかという検索には、見逃しと誤検出があると説明しています。
検知ログの件数を評価する前に、既知の利用がどう記録されるかを確かめる必要があります。
承認した接続先と承認した経路
組織が承認した MCP サーバーでも、承認した経路を使っているとは限りません。
たとえば認証やログ記録を行う集約ポータルの背後にサーバーを置いても、そのサーバーへの直接接続を受け付けていれば、ポータルを通らない経路が残ります。
これは構成を説明する仮想例です。
レビューでは「未承認の接続先」と「承認済み接続先への直接接続」を別に記録します。
前者は接続先の審査、後者は経路の強制と例外管理が論点になります。
自社で管理するサーバーなら、許可した経路から来たことをどう確認するかも設計します。
外部 SaaS では同じ制御ができるとは限らないため、提供側の仕様と契約を確認します。
接続先への到達を許可することと、特定の操作を許可することも別です。
MCP サーバー側では、実行する利用者がそのツールや対象データを扱えるかを、操作の実行前に確認します。
クライアントを変更しただけで、この確認を省略できる構成にはしません。
非機密データで行う照合試験
まず、管理下の検証端末と承認済みのサーバーを使い、読み取りだけの試験操作を決めます。
次の表は試験案です。
TLS 検査の解除や未承認サーバーへの接続を勧めるものではありません。
除外や直接接続を試す必要がある場合は、隔離した検証環境で別途承認を得ます。
| 条件 | 試験で見るもの | 記録から判断すること |
|---|---|---|
| 既知のリモート MCP を検査経路から利用 | クライアントの成功記録と、同時刻のゲートウェイ記録 | 想定した検査ルールと識別が適用されたか |
| 同じ試験のログが見つからない | 時刻と検索条件、取込遅延、保存期間、対象経路 | 「未使用」ではなく、どの観測条件が未確認か |
| 外部通信を行わない既知の stdio サーバーを利用 | 起動記録と、クライアント側で確認できる呼び出し記録 | HTTP 検知ログ以外の証跡で利用を追えるか |
| ローカルサーバーが外部 API を呼ぶ承認済み構成 | 起動プロセスと外部接続の対応 | MCP の呼び出しと、その結果発生した API 接続を区別できるか |
| ポータル利用を必須にした検証用サーバー | 正規経路は成功し、禁止した直接経路は拒否されるか | 経路の強制がどの制御で働いたか。画面表示だけで判断しない |
呼び出しの記録では、時刻、利用者、端末、接続先またはプロセス、操作名、許可や拒否の結果を照合する方法が考えられます。
製品ごとに取得できる項目は違うため、すべてが記録される前提にはしません。
共通の識別子がなければ、時刻が近いだけで同一操作と断定せず、対応付けの限界も残します。
ログへ認証ヘッダーやプロンプト全文を追加すればよいわけではありません。
ツールの引数や応答には業務データが入り得るため、必要な項目に限定し、閲覧権限と保存期間を決めます。
非機密データを使った試験の証跡と、本番で常時保存する情報は分けて設計します。
点検の成果物には、検知件数に加え、接続方式、管理経路、取得できる証跡、対象外の理由、確認担当を残します。
これなら「どの利用を確認できたか」と「どこがまだ分からないか」を、次の設計レビューに持ち込めます。
参考資料
- Cloudflare: How Cloudflare detects MCP traffic and helps secure it（公開2026-08-14、更新2026-08-18）
- MCP 2026-07-28: stdio
- MCP 2026-07-28: Streamable HTTP
- MCP 2025-06-18: Transports
資料確認日：2026-09-17。