2026年7月28日、Snowflake がセキュリティカンファレンス Black Hat で Cortex AI Gateway を発表しました（Snowflake 公式ブログ、SiliconANGLE）。同社がこれを「信頼できるエージェント活動すべての結合レイヤー」と呼んでいる点に、いまの潮流が凝縮されています。AIエージェントの統制は、個々のエージェントやモデルの中ではなく、エージェントが外の世界に触れる一点=ゲートウェイに集約しはじめました。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の MCP 活用を「PoCから本番・全社へ」日々支援しています。その現場から見ると、Snowflake の発表は単一製品のニュースを超えた意味を持ちます。「どのエージェントを入れるか」から「すべてのエージェントのツール呼び出しは、どこを通り、そこで何が効くか」へ——統制の問いそのものが移ったのです。本稿は「MCPゲートウェイ」という新しい制御点を、日本企業の実務設計の視点で読み解きます。
MCPゲートウェイとは何か——「すべてのツール呼び出しが通る一点」
MCP（Model Context Protocol）は、AIエージェントを社内外のツール・データ・システムへ接続する共通規格です。エージェントが増え、接続先の MCP サーバーが増えるほど、「誰が・どのエージェントで・どのツールを・どの権限で呼んだか」は指数関数的に散らばります。ここを一点に束ねるのが MCPゲートウェイ です。
MCPゲートウェイは、エージェントとツールの間に立つコントロールプレーンで、機能を一言で言えばこうです。
すべてのツール呼び出しを、1つの統治された入口の背後に集約し、誰が何を呼べるかを判断し、あらゆる呼び出しを記録する。
つまり、ツール呼び出しの一つひとつが「セキュリティ上の判断」であり「監査イベント」になる——どのエージェントが、どのツールを、どんな引数で、誰の代わりに呼び、何が返ったか。この粒度で制御と証跡を持てるかが、本番運用の分かれ目です。実際、この領域はもはや単発の道具ではなく、Gartner が「MCPゲートウェイ」を1つのカテゴリとして位置づけ、代表ベンダーを挙げはじめる段階に入っています（Lunar.dev）。
Snowflake Cortex AI Gateway——「データ倉庫」が「エージェントの統制層」を名乗る
今回の Cortex AI Gateway の中核は、Snowflake が 2026年5月に買収を発表した Natoma です（Snowflake プレスリリース）。Natoma は2024年創業・27人規模のスタートアップで、その正体は「ID・ポリシー・監査を、個々のツール呼び出しの単位で強制する集中型 MCPゲートウェイ」でした。エージェントが行動を起こす前に「誰が要求したか／どの権限が当たるか／その操作は許可されるか」を確認し、そのうえで記録する。100以上の検証済み MCP サーバーのライブラリを備え、人間ではない**非人格アイデンティティ（non-human identities）**の認証・きめ細かな認可・監視を扱います。
Cortex AI Gateway は、この Natoma を Snowflake 基盤に統合し、100超の MCP サーバーへのアクセスについて、アクセスポリシー・認証・権限・監査ログを1か所に集約します。セキュリティ面では、エージェントがデータの1行に触れる前に、ゼロコピー境界の強制・動的データマスキング・リアルタイムの情報持ち出し（exfiltration）防止を効かせます。そしてすべてのエージェントはデータに触れる前に検証済みのアイデンティティを持ち、ロールベースの権限とすべての操作の監査証跡を通じて、暴走した／侵害されたエージェントを追跡・封じ込められる、という設計です。
なぜ制御は「ゲートウェイ」に集約するのか
エージェントごと・アプリごとに制御を分散させる方法は、規模が出た瞬間に破綻します。理由は3つあります。
- エージェントは自分で増える。導入するより先に、使っている SaaS の内側に業務特化エージェントが増えていく——この「ベンダー内蔵エージェントの氾濫」は別稿「エージェントは『導入する』ものから『気づけば増えている』ものへ」で扱ったとおりで、統制を各エージェント任せにすると横断の可視性が失われます。
- 許可リストだけでは意図を守れない。静的な許可/拒否リストは、プロンプトインジェクションやデータ持ち出しの「文脈」を取りこぼします（参照: セマンティック・ガバナンス）。判断を1か所に集めてはじめて、ポリシーや意図照合を一貫して差し込めます。
- 統制点は「ツール単位」へ降りている。制御の焦点は「ワークフロー全体」から「個々のツール呼び出し」へ移りました（参照: ツール単位の統制）。その最小単位を確実に押さえられる場所こそがゲートウェイです。
注意したいのは、「AIゲートウェイ」を名乗る製品でも守備範囲が違うことです。たとえば Cloudflare の AI Gateway はモデルプロバイダの手前に立ち、キャッシュ・レート制限・分析を足しますが、MCP のツール通信やエージェントから非LLMサービスへの任意の外向き通信は、その中心的な検査面の外にあります。一方で Cloudflare は WAF 側の「AI Security for Apps」で受信 MCP トラフィックのプロンプトインジェクションや機微情報漏えいを検査する仕組みも用意しており、エンタープライズ MCP のリファレンスアーキテクチャを公開しています（Cloudflare ブログ）。「LLM API の関門」と「MCP ツール呼び出しの関門」は別物——ここを取り違えると、監査したつもりで一番危ない経路が素通りします。
ゲートウェイが引き受ける5つの制御
MCPゲートウェイに集約すべき制御を、実務の観点で整理すると次の5つになります。Cortex AI Gateway をはじめ、この領域の製品はおおむねこの5点を競っています。
| 制御 | ゲートウェイで効かせること |
|---|---|
| アイデンティティ | エージェントごとに検証済みIDを付与（非人格アイデンティティ）。誰の代わりの操作かを特定 |
| 認可・ポリシー | ツール呼び出しごとに「その操作は許可か」を判定。RBAC＋きめ細かな認可 |
| 情報持ち出し防止 | ゼロコピー境界・動的データマスキング・リアルタイムの exfiltration 検知 |
| 監査 | すべての呼び出しを「どのエージェントが・何を・どの引数で・何を返したか」で記録 |
| コスト | 呼び出しの集約点で使用量を可視化し、暴走したコストを抑える |
重要なのは、これらをバラバラの製品で継ぎ接ぎしないことです。ID は認証基盤、ポリシーはWAF、監査はログ基盤、コストは別ダッシュボード……と分散させると、「一つの操作」を横断で追えなくなります。同じ一点で、同じ操作を、同じ粒度で押さえる——これがゲートウェイに集約する最大の狙いです。エージェント同士が信頼境界をまたいで連携する A2A 的な世界（参照: A2A プロトコル）では、この「検証済みID×一点の監査」の価値はさらに高まります。
homulaの観点——「接続の共通化」と「統制の一点集約」を分けて設計する
ゲートウェイ集約は、homula がこれまで日本企業に設計してきた勝ち筋とまっすぐ噛み合います。ポイントは、接続の共通化と統制の一点集約を役割として分けて設計することです。
接続の共通化を担うのが Agens です。MCP を活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。エージェントや接続先が増えても、接続の抽象化はプラットフォーム側で吸収でき、「ゲートウェイに束ねる対象」を無秩序に散らばらせません。
その束ねた一点で統制を効かせるのが Agens Control です。承認フロー・DLP・5年分の監査ログ・RBAC を備え、上表の5つの制御——検証済みID、ツール単位の認可、情報持ち出し防止、監査、そして統制の効いた運用——を、自社のポリシーに沿って一貫して回します。Snowflake のような基盤ベンダーがゲートウェイを提供する流れは本物ですが、企業の現実はマルチベンダーです。特定ベンダーの城の中だけで完結しない、ベンダー中立の統制点をどう置くか——ここにインテグレーターの設計価値があります。
導入は無理のない三段で進めます。(1) 1業務で PoC（最短5日）→ (2) 価値の出る接続を Agens で共通化し、統制の境界を Agens Control で設計 → (3) ID・認可・DLP・監査・コストの5点をゲートウェイに寄せて横展開。AIエージェント・ブートキャンプでは、業務棚卸しとあわせて「どの接続を、どの統制境界に束ね、何を関門で強制するか」を3〜5日で設計します。
まとめ
Snowflake Cortex AI Gateway が示したのは、一製品の登場ではなく、AIエージェント統制の重心が「エージェント」から「ゲートウェイ」へ移ったという構造変化です。MCP が標準として固まり、ツール呼び出しがエージェント運用の最小単位になったいま、その一点をどう束ね、そこで何を強制するかが本番・全社展開の成否を分けます。
日本企業にとっての実務的な問いは、「どのゲートウェイ製品を買うか」ではありません。自社のすべてのエージェントのツール呼び出しが通る一点をどこに定め、そこで検証済みID・認可・情報持ち出し防止・監査・コストの5つをどう効かせるか——この設計図を、ベンダーロックインを避けながら早めに描くことです。関門の位置と、そこで守るルールを言語化しておくことが、増え続けるエージェントを安全に任せる近道になります。
エージェントの統制は、個々のエージェントの賢さより「すべてのツール呼び出しが通る一点で、何を強制できるか」で差がつきます。自社のどの業務から、どの接続を、どんな承認・監査の境界に束ねて本番化するか——その最初の線引きを早めに整理しておきましょう。