2026年の夏、私たちは「エージェントとツールの間に**関所（ゲートウェイ）**を置く」という動きを何本かの記事で追ってきた。Citrix の NetScaler、Snowflake の Cortex AI Gateway——いずれも 独立した製品 として登場した“MCPゲートウェイ”だった（別稿: MCPゲートウェイという新しい制御点）。
9月中旬、その流れは次の章に入った。わずか1週間ほどの間に、ServiceNow・Microsoft・GitLab という性格の異なる3社が、そろって「MCP経由のポリシー強制」を出荷したのだ。しかも今回は後付けの箱ではなく、それぞれのプラットフォーム／ネットワーク／CIパイプラインの標準機能 として組み込まれている。海外メディアはこれを「MCP is becoming the governance surface（MCPが統制の面になりつつある）」と表現した（Forkast）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、MCPを軸にした統合基盤 Agens と、統制レイヤー Agens Control を手がけてきた。その視点から言えば、この1週間の意味は明快だ。MCP は「ツールをつなぐ規格」から「組織のポリシーを強制する面（surface）」へと役割を変え始めた。本稿では一次情報でその中身を棚卸しし、日本企業が“制御面”をどこに置くべきかを設計論として示す。
「つなぐ」から「統べる」へ——MCPが制御面になるとはどういうことか
MCP（Model Context Protocol）はもともと、モデルと外部ツールを標準化された作法でつなぐための規格だ。だが企業導入が進むと、論点は「つなげるか」から「誰が・どのツールを・どこまで・いつ呼べるか」へ移る。そしてこの問いへの答えは、モデルの中（賢く振る舞わせる）でもアプリの中（画面ごとに作り込む）でもなく、モデルとツールの間を流れる MCP のトラフィックそのもの で強制するのが最も確実だ、という合意がこの夏から固まってきた。
なぜ“間”なのか。理由は Anthropic が自社の封じ込め設計で言語化している。「エージェントが何をするかを監督するのではなく、何をできるかを監督する」——確率的なモデルの判断に頼るのではなく、アクセス境界を決定論的に敷く、という考え方だ（Anthropic Engineering: How we contain Claude）。MCP はまさにその「できること」が通る一本道であり、そこに関所を置けば、モデルがどれだけ賢く（あるいは誤って）振る舞おうと、呼べないものは呼べない。
夏の“独立ゲートウェイ”はこの関所を製品として切り出したものだった。9月の3社は、それを 自分たちの土俵の標準機能 として実装した。制御面が「特別な装置」から「あって当たり前の基盤」へ降りてきた、という段差がここにある。
この1週間で何が出荷されたか（一次情報の棚卸し）
3社が強制している“層”は少しずつ違う。まず事実を並べる。
| ベンダー | 出荷物（時期） | どこで強制するか | 主な統制内容 |
|---|---|---|---|
| ServiceNow | AI Gateway v3.4（9/10） | プラットフォーム内（AI Control Tower連携） | MCPサーバーのライフサイクル管理・ランタイム強制・スコープ付き短命トークン・緊急停止 |
| Microsoft | Global Secure Access の MCPファイアウォール（プレビュー）＋ Agent 365 のシャドーAI発見 | ネットワーク層 | プロトコル対応の既定拒否・未登録MCPサーバーの発見 |
| GitLab | 19.4（9/17） | CI/開発プラットフォーム内 | ツール単位の許可規則・既定値の作り込み・ユーザー単位の消費上限 |
ServiceNow AI Gateway v3.4（9月10日）
ServiceNow は AI Control Tower の一部として、MCP接続のランタイム強制層を出荷した。組織は「どのMCPサーバーをエージェントが発見できるか」「どのツールを呼べるか」「どのリソースに触れるか」を定義でき、それが モデルやアプリではなくゲートウェイ層で強制される。
実装で注目すべきは資格情報の扱いだ。ゲートウェイは接続ごとに エージェントの身元を検証し、スコープを絞った短命の OAuth トークンを発行 する。サーバーの資格情報は中央で保管・ローテーションされ、エージェントには一切渡らない（＝エージェントからサーバーへの直接接続は存在しない）。さらに、脅威が疑われれば 任意のMCPサーバーをコード変更なしにワンクリックで全体停止／個別停止 でき、収束後は設定を保ったまま復旧できる（ServiceNow Community: What's new in AI Gateway v3.4）。承認・監査・非常停止という統制の三点セットが、MCPの接続点に集約されている。
Microsoft：ネットワークに降りたMCPファイアウォール（9月中旬）
Microsoft は Global Secure Access に、MCPトラフィックを対象にした プロトコル対応のファイアウォール をプレビュー投入した。汎用のアプリ層フィルタではなく、「エージェントがツール単位で何をしようとしているか」を理解した上で 既定拒否（known-good だけを通す） を敷ける点が新しい（Microsoft Learn: Configure Global Secure Access MCP firewall）。あわせて Agent 365 側の シャドーAI発見（Defender＋Intune のスイープ）が、ローカル／リモートのMCPサーバーを含む20種類超の未管理エージェントをあぶり出す（bex.co）。
ただし、ここには重要な限界がある。このファイアウォールが守れるのは“ルーティングされたトラフィック”だけ だ。未管理端末で動くエージェント、転送対象外の経路、ローカルの stdio サーバーは、この関所の外側に残る（WindowsForum）。この「敷いた場所しか守らない」という性質は、後述する設計判断の核心になる。
GitLab 19.4（9月17日）
GitLab は 19.4 で、AIエージェントのツール統制を GitLab MCP サーバー経由の外部エージェントにも拡張 した。管理者は Duo Agent Platform 向けに設定した規則をそのまま適用でき、読み取り専用ツールは既定で「常に許可」、書き込み・削除ツールは既定で「常に確認」 という安全側の初期値が入る。加えて ユーザー単位の消費上限（クレジットキャップ） を設定でき、部門ごとの利用を請求書を待たずに可視化できる（GitLab 19.4 リリースノート）。開発の現場（CI）でも、統制の単位が「ツール呼び出し」へ降りている（別稿: 統制はツール単位へ）。
なぜ「制御面」がいま必要とされるのか
背景にあるのは、経営の認識と現場の実態のギャップだ。Okta の「AI Agents at Work 2026」調査（Apprize360 実施、日本を含む7カ国／経営層292名・ナレッジワーカー492名）によれば、米国の労働者の67%が未承認のAIツールを業務に使い、一方で 経営層の92%は自律エージェントが社内で広く／ある程度使われていると認識 している。そして 未承認AIツールの検知までの中央値は403日 に達する（Okta Newsroom）。
見えないものは統べられない。棚卸しも承認もされていない「シャドーMCP」が現場で先に増え、検知は1年以上遅れる——この時間差こそが、決定論的な強制面を“接続点”に置くべき理由だ（別稿: シャドーMCPの発見が統制の出発点）。
モデルを賢くしても、アプリを作り込んでも、この403日は縮まない。縮めるのは、エージェントの言い分に関係なく通信を検め、通す／止めるを機械的に決める面 だ。3社が同じ週に、それぞれの土俵でこの面を敷いたのは偶然ではない。
落とし穴——「制御面」は“敷いた場所”しか守らない
ここからが実務の勘所だ。制御面が標準機能になったのは朗報だが、各社の制御面は「自社のサーフェスの上」でしか効かない。
- Microsoft のMCPファイアウォールは、前述のとおりルーティングされた経路の外（ローカル stdio、未管理端末）を守れない。
- ServiceNow の強制は AI Control Tower を通る接続に、GitLab の統制は GitLab の土俵に、それぞれ効く。裏を返せば、別のSaaSや自前基盤で動くエージェントのMCP呼び出しは、その制御面の視界に入らない。
- ベンダーの制御面に寄せるほど、統制の記録も緊急停止のスイッチも そのベンダーの中 に閉じる。マルチクラウド・マルチベンダーが常態の日本企業では、制御面が断片化し、監査証跡が分割されるリスクがある。
つまり「MCPが統制の面になった」は、「どこか1社の面に全部を預ければ安心」を意味しない。問うべきは“強制できるか”ではなく、“その強制面を自社が横断的に握れているか” だ。
homulaの観点——制御面は「自社が握れる場所」に置く
homula がエンタープライズ導入で一貫して勧めてきたのは、統制点を特定ベンダーのサーフェスに丸ごと預けず、自社が横断的に握れる中立な層に置くという設計だ。今回の3社の出荷は、この設計思想の正しさを裏づける形で“制御面”を一般化してくれた。
具体的な当てはめはこうなる。
- 接続の一元化（Agens）: MCPを活用した統合基盤 Agens で、200以上のツールと構築ゼロで接続する。まず「どのエージェントが、どのMCPサーバー／ツールにつながっているか」を1枚の面に集める——シャドーMCPを可視化する出発点だ。
- 強制と証跡（Agens Control）: 承認フロー・DLP・RBAC・5年分の監査ログ を接続点で効かせる。ServiceNow が示した「短命トークン・中央での資格情報管理・非常停止」、GitLab が示した「書き込み／削除は既定で確認」を、ベンダーをまたいで一貫したポリシーとして敷く。
- 中立性と可搬性: 活用技術は n8n / Dify / LangGraph など。特定プラットフォームに統制を閉じ込めず、基盤を移しても制御面と監査証跡が分断されない ように設計する。
導入の順序も明快だ。まず AIエージェント・ブートキャンプ（業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結）で「どこに何がつながっているか」を面に載せ、最短5日のPoCで承認・監査・停止の三点を接続点に通す。処理時間 93%削減 のような成果は、この“制御面を握った上での自動化”から生まれる。宣伝ではなく順序の問題として、可視化 → 接続点での強制 → 拡大 を踏むことを勧めたい。
まとめ
- 2026年9月中旬、ServiceNow（AI Gateway v3.4）・Microsoft（GSAのMCPファイアウォール＋Agent 365発見）・GitLab（19.4）が、MCP経由のポリシー強制 を相次いで出荷した。
- 統制点は「後付けゲートウェイ」から 各プラットフォームの標準機能 へ降り、MCPは「つなぐ規格」から 「統べる面（governance surface）」 へ変わりつつある。
- 強制すべき層は、確率的なモデルでも作り込むアプリでもなく、決定論的に検められる“接続点”——身元検証・スコープ付き短命トークン・ツール単位の許可・監査・非常停止が集まる面だ。
- ただし各社の制御面は “敷いた場所”しか守らない。ルーティング外・別ベンダー・自前基盤は視界の外に残る。だからこそ、制御面は自社が横断的に握れる中立な層に置く ことが設計の要になる。
エージェントが「つながる」段階は終わり、「誰が握る面で統べるか」が競争条件になった。自社のMCP接続点は、いま誰の手のひらにあるだろうか。
制御面を“自社が握れる場所”に置く設計から、まずは業務棚卸しとPoCで始めませんか。