Kong AI Gateway 2.0 により、エージェントのガバナンスがゲートウェイの仕事の一部に

Kong は、Kong AI Gateway 2.0 の一般提供を開始し、単純な LLM プロキシから、モデル、エージェント、ツール、AI 支出のより広範なコントロール プレーンへの移行の新たな一歩を示しました。

9 月 1 日のリリースでは、管理されたツール アクセスのための MCP サーバー バンドリング、さまざまなモダリティを考慮した動的なコスト管理、より広範なモデルとプロバイダーのカバレッジ、ID 認識 AI ポリシー、Amazon のネイティブ IAM 認証など、すでに本番環境の AI ワークロードを実行しているチームにとって重要ないくつかの機能が提供されます。 Bedrock AgentCore。 Kong は、この製品がベータ版を有効にすることなく Kong Konnect で利用できるようになったとも述べています。

この組み合わせがニュースです。 AI ゲートウェイ カテゴリは、もはや OpenAI スタイルのリクエストを受け取り、それをプロバイダーに転送し、応答を記録するだけのものではありません。企業の購入者は、誰がどのモデルを呼び出すことができるか、エージェントがアクセスできるツールは何か、支出をどのように測定するか、そしてそれらの決定が企業ですでに使用されている ID システムにどのようにマッピングされるかをゲートウェイに決定させることをますます望んでいます。

Kong AI Gateway 2.0 での変更点

最も注目すべき追加点は、MCP サーバー バンドルです。 MCP (モデル コンテキスト プロトコル) は、ツールやリソースを AI エージェントに公開する一般的な方法となっています。ゲートウェイ層で MCP サーバーをバンドルすることで、すべてのアプリケーション チームが独自のエージェント統合を配線して管理するのではなく、プラットフォーム チームにこれらのツールの接続を集約して管理する場所が与えられます。

これは有意義な製品の方向性です。エージェントがデモから社内ワークフローに移行すると、モデルが 1 つの質問に間違って回答するというリスクよりも、モデルが監視が不十分なまま多すぎるツールに接続されることの方がリスクになります。 MCP アクセスをパッケージ化して制御できるゲートウェイは、どのエージェントがどのシステムに、誰の ID で、どのようなポリシー境界でアクセスできるかという運用上の問題に近づきます。

Kong は、動的なモダリティを意識したコスト管理も追加しました。 AI の価格設定はもはや単一のトークン メーターではないため、これは重要です。テキスト、画像、オーディオ、ビデオ、ツール呼び出し、キャッシュされたコンテキスト、および推論モードは、それぞれプロバイダーに応じて異なる経済性を実現できます。モダリティを理解するコスト制御レイヤーにより、一般的なリクエスト カウンターよりも正確な制限とルーティング ルールをチームに提供できます。

このリリースでは、モデルとプロバイダーの対象範囲も拡張され、アイデンティティ認識 AI ポリシーが追加されます。 Bedrock AgentCore は企業がエージェントを実行および管理する場所の 1 つになりつつあるため、Amazon Bedrock AgentCore に対する Kong のネイティブ IAM 認証は特に重要です。ゲートウェイ ポリシーをクラウド ID に接続すると、AI 固有の制御と、企業がすでに監査しているアクセス システムとの間のギャップが減少します。

これが開発者とプラットフォーム チームにとって重要な理由

開発者にとっての実際的な効果は、ゲートウェイが単なるインフラストラクチャ アドオンではなく、アプリケーション アーキテクチャの一部になることです。内部サポート エージェント、コーディング アシスタント、またはデータ分析ワークフローを構築するチームでは、アプリが運用環境に移行する前に、モデル アクセス、ツール アクセス、予算しきい値、ID 伝播のためのゲートウェイ ルールが必要になる場合があります。

これによりセットアップ コストがいくらか追加される可能性がありますが、実際の障害モードにも対処できます。共有ゲートウェイ層がないと、モデルの選択、プロバイダーの資格情報、ツールの権限、支出制御がアプリケーション コード、CI シークレット、SDK ラッパー、チーム固有のダッシュボードに広がる傾向があります。この断片化により、インシデントの調査が困難になり、モデルの移行の実行が困難になります。

Kong のリリースは、OpenAI 互換の API レイヤーやマルチモデル API 製品を構築するベンダーへのシグナルでもあります。互換性だけが重要な要素になりつつあります。顧客は、ポリシーの適用、使用状況分析、チームレベルのアクセス、予算管理、フォールバック ルーティング、モデル/プロバイダーの可視化など、リクエストに関するガバナンスをますます期待しています。

Model Gate ユーザーの場合、接続は直接です。モデルへのアクセスがワークフローの一部にすぎない場合、統合請求、API キー管理、使用状況分析、チーム制御はすべて、より価値が高まります。エージェントが MCP スタイルのインターフェイスを通じてツールにアクセスできるようになると、ゲートウェイはどのモデルが呼び出されたかだけでなく、どのチーム、キー、ツール バンドル、およびポリシー コンテキストが関与したかを表す必要があります。

競争ベンチマークは変化しています

この方向に取り組んでいるのは Kong だけではありません。市場全体の最近の動きは、AI インフラストラクチャ ベンダーが同じ広範な問題に集中していることを示しています。エンタープライズ AI には、ユーザー、モデル、エージェント、ツール、支出の間の管理されたパスが必要です。ゲートウェイ製品は、リクエスト形式を正規化できるかどうかではなく、生産管理をサポートできるかどうかで判断されるようになっています。

そのため、購入者にはより鋭い質問をするようプレッシャーがかかっています。ゲートウェイはプロバイダー固有の価格設定と方式を理解していますか?管理者はチームまたは ID ごとにポリシーを設定できますか?監査可能性を失わずにプロバイダー間をルーティングできますか?モデルのエンドポイントだけでなく、エージェント ツールも管理できますか?財務、セキュリティ、エンジニアリングのすべてが利用できる方法で、使用状況とコストのデータを公開できるでしょうか?

これらの質問は、もはや理論的なものではありません。ロングコンテキスト モデル、エージェント ツールの呼び出し、マルチモーダル ワークロードにより、コスト プロファイルが急速に変化する可能性があります。テスト中には低コストに見えるワークフローも、繰り返しのコンテキスト、画像入力、またはツールを多用するエージェント ループが運用環境に入ると、高コストになる可能性があります。これらのパターンを区別できないゲートウェイでもアクセスを一元化できる可能性はありますが、オペレーターに十分な制御を提供することはできません。

まだ不確実なこと

今回の発表では、一般的な可用性が確立され、主要な機能の名前が示されていますが、実際の導入は、チームが MCP バンドルを構成する方法、ID 認識ポリシーの粒度、混合プロバイダー間でコスト管理がどのように動作するか、実際に顧客がどの程度運用上の可視性を得ることができるかなど、実装の詳細に依存します。

また、企業がそうであるかどうかを知るには時期尚早です。単一の AI ゲートウェイでエージェントのガバナンスを標準化するか、クラウド プラットフォーム、セキュリティ ツール、開発者プラットフォーム、可観測性ベンダー間で責任を分割します。 AWS、ホスティング プラットフォーム、IDE ベンダー、スタンドアロン ゲートウェイ プロバイダーはすべて、同じコントロール サーフェスの一部を所有しようとしています。

それでも、方向性は明確です。 Kong AI Gateway 2.0 は、AI トラフィックをモデル呼び出しのストリームではなく、管理されたエンタープライズ システムとして扱います。モデル API に基づいて構築している開発者や企業にとって、これはゲートウェイの決定がアーキテクチャの決定になりつつあることを意味します。これらの決定は、コスト、セキュリティ、モデルの選択、ツールのアクセス、エージェント ワークフローの信頼性に影響します。