8月3日、Nirmataが「The AI Gateway Buyer's Guide: Beyond Routing and Tool Visibility」と題した記事を公開した。AIエージェントの本番運用において「ルーティング」や「ツール可視化」だけではガバナンスとして不十分である理由と、ゲートウェイ選定で問うべき12の質問について詳しく紹介されている。
※本記事はポリシー実施型AIゲートウェイのベンダーであるNirmataが公開したものであり、市場評価には出典バイアスが含まれる可能性がある点に留意されたい。
「見えている」と「制御できている」は別物だ
AIエージェントがデモではなく実システムを操作するようになった今、多くのエンジニアリング組織が最初に手を伸ばすのはAIゲートウェイだ。その判断自体は正しい。問題は、ゲートウェイが何をしてくれているかについての思い込みにある。
記事が繰り返し指摘するのは、次の誤解だ。
「モデル間のルーティングができて、エージェントがどのツールを呼んでいるか見えている——だからコントロールできている」
これはガバナンスではなく、オブザーバビリティ（可観測性） だ。ルーティングと可視化が答えるのは「何が起きたか」であり、ガバナンスが答えるべきは「そのエージェントはその操作を許可されていたか、次回は止められるか」という別の問いである。
なぜルーティングとMCPゲートウェイだけではガバナンスにならないのか
モデルルーターは「どのLLMにリクエストを投げるか」を決める。コストやレイテンシの最適化には有効だ。しかし、ルーティング先を変えることは、そのリクエストが引き起こすアクションを許可すべきかどうかとは無関係である。
エージェントがデータベースレコードを削除しようとしているとき、どのモデルがそのツール呼び出しを決定したかは関係ない。問題は「この引数でこのツール呼び出しを、今この瞬間、このエージェントが行うことが許可されているか」だ。ルーターはその問いに答えられる設計になっていない。記事はこれを端的に表現している。「ルーティングインフラをガバナンス層として扱うのは、ネットワークロードバランサーをファイアウォールとして扱うようなものだ」。
同様の問題がMCP（Model Context Protocol）ゲートウェイにも存在する。MCPはエージェントがツールを呼び出すための標準プロトコルとして急速に普及しており、「MCPゲートウェイを置けばガバナンスは完璧」という誤解も広まっている。記事はこれを構造的な問題として退ける。
エージェントが実際に操作するトラフィックは3種類ある。
- LLM APIへの直接呼び出し（生のcompletion requestなど）
- MCPツール呼び出し
- 直接HTTPリクエストやローカル実行（シェルコマンド、内部API呼び出しなど）
MCPゲートウェイが監視できるのはこのうち2番だけだ。シェルアクセスを持つエージェントがローカルコマンドを直接実行すること、コード実行能力を持つエージェントが内部APIにraw HTTPリクエストを投げることは、悪意がなくても起きる——モデルが「最短経路」を選んだだけの結果として。記事の結論は明快だ。「LLM、MCP、HTTPの3つのトラフィック種別をまたぐ単一の実施レイヤーが必要だ。より高度なMCPポリシーでは解決しない」。
さらに、現世代の「AIセキュリティ」ツールの多くはツール呼び出しの事実をログに記録できる。execute_queryが呼ばれた、send_emailが実行された——これをガバナンスと呼ぶ製品が多い。だが、クエリが実行されたことを知ることと、そのクエリの中身を知ることは別だ。 ネットワークトラフィックを外側から監視するツールは、HTTPS通信を傍受して「AIプロバイダーへの呼び出しがあった」とログに残せるが、その通信の中にあるSQLステートメントの中身は見えない。見えたとしても止められない。本物のガバナンスはプロトコルの会話の内側に座る必要がある——ツール名、正確な引数、レスポンスを、実行される前に見られなければ意味がない。
「多数のコネクタ」は深さではなく幅の話
ベンダーがSlack・Salesforce・GitHubなど数十のロゴを並べる「連携対応一覧」はよく見るスライドだ。これは統合の幅（breadth）であり、実施の深さ（depth）ではない。
特に問題になるのがKubernetesだ。多くのエージェントの本番ワークロードはK8sクラスタ内で動いており、独自のサービスアカウントID、内部ツール呼び出し、SaaS以外へのエグレス通信を持つ。SaaS連携の幅を誇示するベンダーに「K8sクラスタ内で動くエージェントのガバナンスはどうなるか」と聞くと、回答が急に薄くなることが多いと記事は指摘する。
選定で使える12の質問
記事の核心は、どのベンダーにも投げられる12の質問リストだ。エンジニアが実際の評価フェーズで使えるよう整理されており、ツール呼び出しの粒度・実行前制御の有無・ポリシー管理の方法・トラフィック種別の網羅性など、ガバナンス層として機能するかを多角的に問う構成になっている。以下に代表的な6問を紹介するが、いずれも12問全体の中でベンダーの実施能力の有無を見極めるための問いとして位置づけられている。
- ツール呼び出しの「引数」を評価するか、「ツール名」だけか？ 「DBツールが呼ばれた」ではなく「
DROP TABLEが実行されようとした」まで見えるか。 - 実行前に止められるか、実行後にログに残すだけか？ ダッシュボードに表示されるだけなら、それはオブザーバビリティだ。
- すべての判断がエージェントの身元（identity）に紐づいているか？ 人間がエージェントに委任した権限が、呼び出しチェーン全体を通じて保持されるか。
- 高リスクなアクションに対して人間が介在する承認フローがあるか？ アラートを送るだけでは何も止まらない。
- ポリシーはコードとして管理できるか？ Gitでバージョン管理され、PRでレビューできるか。ベンダーUIだけの設定ではdiffも取れない。
- LLM呼び出し、MCPツール呼び出し、直接HTTPの3つ全てに同じポリシーと監査証跡が適用されるか？ エージェントがMCPをバイパスした場合に「見えない」なら、それは設計上のブラインドスポットだ。
記事は12問のうち4問以上に明確なYesで答えられないベンダーが売っているのは「ガバナンスのラベルを貼った可視化ツールだ」と締める。6問の抜粋を示した上でこの閾値を読むと「抜粋外の6問にYesが多ければ通過できる」とも取れるが、原文の趣旨は12問を総体として使い、いずれかの軸で実施能力が欠けていないかを確認することにある。個別の質問の重みよりも、網羅的なチェックリストとして運用することが意図されている。
現状の市場評価
記事は現在の市場に対して公平な見方を示している。「現在出回っているほとんどのツールが可視化優先なのは、特定ベンダーへの批判ではなく、カテゴリ全体がまだそこにいるという現状描写だ」。可視化は必要なステップだ——見えないものはガバナンスできない。問題はそこで止まることだ。
ランタイムでのポリシー実施（runtime enforcement）こそが、主要なアナリストが注目している軸であり、かつ「最も主張するベンダーが多く、最も実際に提供するベンダーが少ない」機能でもあると記事は指摘する。
詳細はThe AI Gateway Buyer's Guide: Beyond Routing and Tool Visibilityを参照していただきたい。
