エージェントゲートウェイが企業AIの全権力を集中させる
ある技術が実験段階から重要インフラへと移行する際には、常に繰り返されるパターンがある。ある時点で、誰も正式には計画していなかった制御レイヤーが出現し、最終的に最も重要な意思決定が行われる場所となる。Webにおけるロードバランサー、クラウドにおけるコントロールプレーン、マイクロサービス時代のサービスメッシュでも同様のことが起きた。今、人工知能エージェントの世界でも同じことが起きており、そのレイヤーが「エージェントゲートウェイ」という名称で呼ばれ始めている。
2026年7月第1週、2つの異なる企業の動きが、このカテゴリーがもはや構築中の概念ではないことを確認させた。Arcadeは、自社の認可・ツール実行エンジンをMicrosoft AzureおよびAWSのマーケットプレイスに直接提供し、企業がワンクリックで自社クラウド内にデプロイできるようにした。その前日、Manufactは、Model Context Protocol（モデルコンテキストプロトコル）をベースとしたMCPホスティングクラウドを公開し、コードリポジトリからサーバーを監視付きの本番環境へと移行できるようにした。どちらも特別な発表は行わなかった。しかし両者を合わせると、1つの明確なシグナルが浮かび上がる——市場は、組織がデプロイ済みの内容を把握し終える前に、エージェント型AIのガバナンス構造を整備しつつある、ということだ。
Nutanixは5月に、Nutanix Enterprise AI バージョン2.7の一部として自社のエージェントゲートウェイを一般提供（GA）製品として発表し、このカテゴリーの輪郭をすでに明確にしていた。このソリューションは、エージェントから言語モデルへのトラフィック、およびエージェントが呼び出すビジネスツールへのトラフィックを管理する集中制御ポイントとして機能する。リクエストをルーティングし、認証を適用し、ツールごとの権限を管理し、監査のためにすべての呼び出しを記録し、エージェントごと・チームごとのトークン消費量を計測する。カスタマーサポートエージェントにはデータベースへの読み取り専用アクセスを付与し、DevOpsエージェントにはGitHubへの完全な書き込み権限を付与することができる。メインプロバイダーに障害が発生したり制限に達した場合は、トラフィックが自動的に設定済みのバックアッププロバイダーへとフォールバックする。
この瞬間が戦略的に重要なのは、機能そのものではない。初めて市場が、企業AIに対する権力が集中する場所を命名し、パッケージ化しているという点にある。
ガバナンスが設計された場に誰がいたか
このレイヤーの重要性を理解するには、エージェントゲートウェイが存在しない状態で、本番環境のAIエージェントがどのように動作するかを観察するとよい。エージェントは長時間単独で行動することはない——推論のためにモデルを呼び出し、次に実行のためにツール（GitHub、Stripe、データベース、内部API）を呼び出す。多くの場合、同じサイクルを繰り返すサブエージェントを生成する。各呼び出しはトークンを消費し、それぞれ固有の権限を持つシステムに触れる。集中制御ポイントがなければ、組織は最終的に、トラフィックを確認・停止・監査する単一の場所がないまま、本番システムに直接接続された数十のエージェントを抱えることになる。
このガバナンスなしの分散アーキテクチャは、単なる運用上のリスクではない。それは権力とデザインに関する問いでもある。明示的なコントロールプレーンがなければ、エージェントのガバナンスは消えるのではなく、断片化して暗黙のものになる。各エージェントがどのツールを呼び出せるか、どのアイデンティティで、どのような条件下で、どの程度の権限の範囲で——こうした決定は、それぞれのエージェントを構築したチームが個別に行い、チーム間の整合性はほとんどない。
その構造的な結果は予測可能だ：周辺的な知性が見えなくなる。システムの周縁で活動するチーム——非典型的なユースケースを知っているチーム、顧客の機密データを扱うチーム、自動化の二次的な影響を目にするチーム——は、エージェントが何をできて何をできないかという設計において代表性を持たない。権限、スコープ、アクセスに関する決定は、エージェントを構築した技術チームによって初期デプロイの段階で一度だけ行われ、集中的なレビューの仕組みも多様な視点を取り込む仕組みも存在しない。
エージェントゲートウェイはそれを変える——少なくとも潜在的には。アクセスポリシー、認証、監査を一貫して見直し、更新し、適用できる単一ポイントにガバナンスを集中させる。しかしこの設計が開く問いは技術的なものではない：その中心的なポイントを誰がどのような基準で管理するか、である。
すでに進行している統合
市場はその問いに対して、2つの同時進行する正反対の答えを示しており、どちらもコントロールレイヤーの管理者は誰であるべきかという根本的な緊張を明らかにしている。
第一の答えは、独自セキュリティプラットフォームへの統合だ。Palo Alto Networksは2026年5月、エージェントガバナンスに特化した自律型AIゲートウェイであるPortkeyの買収を完了し、自社のセキュリティプラットフォームに統合した。その論理は一貫している——高い特権を持つエージェントが新たな企業リスクのベクターであるならば、エージェントが何をできるかに対する制御は、セキュリティ境界の自然な拡張である、という考えだ。エージェントのガバナンスは、大手サイバーセキュリティベンダーがすでに管理しているゼロトラストおよび特権アクセスのポートフォリオの一部となる。
第二の答えは、オープンガバナンスだ。Solo.ioは、Linux Foundationの傘下にあるAgentic AI Foundationにagentgatewayプロジェクトを寄贈し、同グループの第4のホストプロジェクトとした。Rustで書かれたこのプロジェクトは、MCPトラフィック、エージェント間通信、HTTP、gRPCを単一のデータプレーンで処理し、CoreWeave、Red Hat、Adobe、Salesforce、Microsoftを含む60の組織から300人以上のコントリビューターを擁している。ここでの論理も一貫しているが、逆方向を向いている——エージェントゲートウェイが企業AI全体の中核インフラであるなら、単一のベンダーがその所有者であるべきではない、という考えだ。
これら2つの動きは、単に異なる商業戦略ではない。AIインフラに対する権力がどこに置かれるべきかという、2つの異なる理論である。第一はその権力を大手テクノロジー企業のセキュリティ境界に置く。第二はそれを、中立的なガバナンスのもとでのコントリビューターコミュニティへと分散させる。
構造分析が明らかにするのは、この2つの選択肢の間の選択は、第一義的に技術的でも財務的でもない——それは権力のアーキテクチャに関する決定であるということだ。セキュリティベンダーのプラットフォーム内にゲートウェイを統合することを選ぶ企業は、エージェントガバナンスポリシーの設計を、そのベンダーのロードマップに委託することになる。Linux Foundation傘下のプロジェクトを採用する企業は、より多くの技術的責任を引き受けるが、コントロールレイヤーの進化に集合的な影響力を行使する能力を維持する。
市場がまだ解決していない3つの盲点
Forbesの元記事は企業バイヤーに向けた3つのデューデリジェンスの問いを提示しており、その3つには共通の特徴がある——問いの形式は技術的だが、明らかにするものは組織的だ、ということだ。
第一の問いは所有権についてだ——ガバナンスのどの部分がベンダー独自のものであり、どの部分が企業がすでに料金を支払っているAWSまたはAzureのプリミティブの薄いラッパーなのか。この問いは財務的に見えるが、その本質は設計上の依存性に関するものだ。エージェントのガバナンスが内部チームには監査も修正もできないレイヤーにアウトソースされているなら、たとえ名目上は自社で運用していても、その組織は自社のAIをコントロールしていない。
第二の問いはコスト動態についてだ——ツール呼び出しの量が倍増したとき、あるいはデプロイされたエージェントがベンダーの想定を下回るときに、請求書はどうなるか。Gartnerは、エージェント型AIプロジェクトの40%以上が、増加するコストと不十分なリスク管理コントロールにより2027年以前にキャンセルされると予測した。構造的な皮肉は、そのリスクの解決策として位置づけられているゲートウェイそのものが、エージェント量に合わせて価格モデルがスケールする場合、不透明なコストレイヤーになりうるという点だ。
第三の問いは制御の一貫性についてだ——認証がすべてのツールとMCPプロトコルのすべてのメソッドに対して要求されているのか、それとも最も明白なものに対してだけなのか。CyCognitoは、本番環境での最も一般的な障害は制御の完全な欠如ではなく、既存の制御の不整合な適用であることを体系的に記録してきた。露出したMCPサーバーへの非認証アクセスを持つエージェントは、CyCognitoの言葉を借りれば、ビジネスオペレーションの公開カタログである。
しかし、これらの問いのどれも直接的に捉えていない第4の盲点があり、それが組織設計の観点から最も重要なものだ。エージェントゲートウェイはガバナンスを集中させるが、そのガバナンスが賢明であることを保証しない。集中制御ポイントは、ポリシーを設計したチームが持っていたのと同じバイアスや盲点を、より高速かつ広範囲に複製・拡大しうる。ポリシー設計に多様な視点がない集中的なガバナンスはガバナンスではない——それは既存のバイアスのより広いカバレッジである。
コントロールプレーンは権力のプレーンでもある
アナリストがよく用いる歴史的な比較は、マイクロサービス時代のサービスメッシュだ。EnvoyとIstioがサービス間トラフィックのコントロールプレーンとして台頭したとき、企業のネットワークアーキテクチャを変革し、コンポーネント間の通信を観察・管理できる者を決定づけた。エージェントゲートウェイとの並行関係は技術的に正確だが、エージェント型AIの場合により重要な次元を見落としている。
マイクロサービスはデータとビジネスロジックを移動させた。AIエージェントは決定を下し、アクションを実行し、人間の直接監視の有無にかかわらず本番システムに結果をもたらす。今構築されつつあるコントロールプレーンは、単にトラフィックを管理するだけでなく——組織のAIが何をできるか、どのような権限で、どのシステムに対して、どのようなレビュー条件下でできるかを定義する。それは単なるインフラの決定ではない。
Nutanix、Arcade、Manufactがツールレベルのフィルタリング、集中認証、監査ログについて語るとき、彼らは技術的なメカニズムを説明している。しかし、そのメカニズム上で動くポリシー——誰が何を呼び出せるか、どのスコープで、どのオーバーライド条件下で——は組織的な決定であり、ほとんどの企業においては今もなお、デプロイ時にシステムへの技術的アクセスを持つチームが、明示的なガバナンスフレームワークなしに行っている。
エージェントゲートウェイは、エージェント型AIの集中ガバナンスを可能にするインフラだ。組織がそれを、ポリシーを設計する人物を見直すことなく技術的ソリューションとして採用するならば、インストール前に持っていたのと同じ盲点を自動化するための非常に効率的なコントロールプレーンを構築したことになる。
この市場が構築しつつある権力のアーキテクチャは洗練されており、急速に成熟している。まだ解決されていないのは、それを採用する組織が、そのコントロールが既存のバイアスへの速度の付加以上のものになるだけの十分に多様な視点をもってガバナンスポリシーを設計するかどうかだ。
