F5、エンタープライズAIトラフィックの制御を狙いAI Gatewayを拡張

F5は8月18日、AI Gatewayを拡張した。企業はすでにモデルルーター、ガードレール、エージェント向けセキュリティツールがひしめく市場に直面している。それでもGoogle Newsの見出しは、単なる製品アップデートのように聞こえる。その背景にあるのは、従業員、アプリケーション、AIモデル、エージェント、企業向けツールをつなぐあらゆるリクエストを制御しようとする動きだ。

更新されたゲートウェイは、3つの機能を単一のポリシーレイヤーに統合する。Model Gatewayはモデルへのアクセス、ルーティング、トークン利用を管理する。MCP Gatewayはエージェントによるツールへのアクセスを統制し、AI Guardrailsはプロンプトと応答を検査して脅威や機密データを検出する。

この組み合わせこそが本質的な対立を生む。企業は各機能に特化した製品を組み合わせることも、複数のAIトラフィックを1つのインフラプロバイダーの背後に置くこともできる。F5は、個別ツールが提供する自由度や専門性よりも、運用の一貫性が重視されると見込んでいる。

同社が参入するのは競争の激しい領域だ。Kong、Cloudflare、Citrix、Palo Alto Networks、クラウドプロバイダー、AIネイティブのスタートアップはいずれも、何らかの形でコントロールプレーンの機会を追求している。各社は、どのAIリクエストを実行し、何にアクセスさせ、どれだけのコストをかけるかを決める仲介役になろうとしている。

F5は、すでにBIG-IP、NGINX、または同社の分散クラウドサービスを利用している組織で優位性を持つ。これらの導入基盤は、すでにポリシー適用が行われるアプリケーションおよびAPIトラフィックの近くに位置する。ただし、既存のトラフィック上の優位性が、AIガバナンスにおけるリーダーシップを自動的に意味するわけではない。

したがって重要な問いは、企業により優れた制御が必要かどうかではない。モデル、エージェント、データ、コストを1つのゲートウェイで統制しつつ、それ自体が新たな集中リスクにならないかどうかだ。

F5が実際に変更した点

F5はAI Gatewayを、セキュリティの検問所から、より広範な運用コントロールプレーンへと進化させている。

同社は2024年11月にF5 AI Gatewayを初めて発表した。当初は、アプリケーション、API、大規模言語モデルの間を流れるトラフィックの保護と管理を重視していた。

今回のリリースでは、その対象範囲を拡大している。F5は現在、3つの接続されたゲートウェイとセキュリティレイヤーを、異なるポリシーを持つ別製品ではなく、単一のシステムとして提示している。

Model Gatewayは、AIモデルに送信されるリクエストを処理する。F5によれば、プロバイダー、モデル、チーム、個々のユーザーごとにトークン利用を記録する。また、管理者は予算を設定し、リクエスト処理中にそれを適用できる。

ルーティングには経済的な役割もある。ゲートウェイは、より単純なタスクを低コストのモデルに送信し、適切なキャッシュ済み応答を再利用し、利用可能なGPU容量に応じてワークロードを分散できる。これにより、ゲートウェイはセキュリティ製品、トラフィックマネージャー、支出管理ツールという3つの側面を持つことになる。

F5は、これらの機能により、アプリケーションの変更を必要とせずにトークン支出を30%から60%削減できるとしている。現在のAI Gateway overviewでも、重複するエージェントのツール呼び出しを排除することで、関連するトークンの無駄を最大90%削減できると主張している。

これらの数値はベンダーの主張であり、独立したベンチマークではない。実際の削減効果は、リクエストパターン、キャッシュ再利用、モデルの選択、レイテンシー要件、既存の最適化状況に左右される。すでに厳格なルーティングポリシーを利用している組織では、効果が小さい可能性がある。

MCP Gatewayは別のトラフィック経路に対応する。Model Context Protocol、すなわちMCPは、AIアプリケーションがツールやデータソースと接続するための標準的な方法を提供する。こうした接続は、データベース、社内API、ドキュメントリポジトリ、業務システムに及ぶ可能性がある。

F5によれば、そのレジストリはパブリック、リモート、プライベートのMCPサーバーをカタログ化できる。管理者は、個々のツールに対して許可リスト、拒否リスト、クォータ、予算、ロールベースのアクセス制御を適用できる。

システムは各ツール呼び出しも記録する。この記録により、どのIDがリクエストを開始したか、エージェントがどのリソースにアクセスしたか、どのアクションが実行されたかを確認できる。自律プロセスが業務データを変更したり、規制対象の情報にアクセスしたりする場合、こうした証跡は重要になる。

AI Guardrailsは、ゲートウェイを通過するコンテンツを検査する。F5によれば、これらのポリシーは個人識別情報をマスキングし、プロンプトインジェクションの試みをブロックし、ジェイルブレイク手法を阻止できる。フェイルクローズドの適用では、検査レイヤーが安全に評価できないトラフィックを拒否する。

これらのコンポーネントは合わせて、3つの異なる問いに対応する。どのモデルがリクエストを処理すべきか。エージェントはどのツールを利用できるか。どの情報または指示が、いずれかの境界を越えてよいか。

F5はこのゲートウェイを、より広範なAI Security Platformにも組み込んでいる。このプラットフォームは、AIトラフィックを担う稼働中のシステムを中心に、AIガバナンス、利用制御、セキュリティテスト、実行時保護をまとめるものだ。

統合の重要性は、ブランド名よりも大きい。単にリクエストをルーティングするゲートウェイが見られるのは、AIワークフローの一部にすぎない。アプリケーションセキュリティ、API制御、実行時監視と連携するゲートウェイなら、そのリクエストに関するより多くの活動を相関付けられる。

F5はSaaS、ハイブリッドSaaS、ハイブリッドマルチクラウドの導入をサポートする予定だ。外部サービス経由で機密トラフィックを送信できない規制環境向けには、エアギャップ環境のサポートも計画している。

この導入範囲は、AIシステムがプライベートインフラと複数のクラウドプロバイダーにまたがる組織を対象としている。また、F5の主張も補強する。制御レイヤーは、1つのモデルベンダーに属するのではなく、環境をまたいでトラフィックを追うべきだというものだ。

Google Newsの見出しが今重要な理由

Google Newsの記事は、AIモデルの試行から、大規模なAI推論の統制への、より大きな移行を反映している。

F5の2026年版State of Application Strategy調査では、回答組織の77%が推論を主要なAI活動と見なしていた。同社によると、回答者は平均して7つのAIモデルを管理していた。

推論は、訓練済みモデルが実際のリクエストを処理する本番段階だ。従業員向けアシスタント、カスタマーサポートシステム、コードツール、検索アプリケーション、業務タスクを実行するエージェントなどが含まれる。

7つのモデルを管理することは、単に7つの技術的関係を持つことではない。チームは、それらのシステム全体で認証情報、リージョン、リクエスト形式、保持ルール、安全フィルター、フォールバック動作、性能、利用量を追跡しなければならない。

エージェントは、さらに別の権限構造をもたらす。モデルは外部ツールを呼び出すことを決定でき、そのツールはデータを公開したりアクションを実行したりできる。セキュリティチームは、ユーザー、エージェント、モデル、ツール、対象システムを一体として統制する必要がある。

MCPはツール統合を容易にする一方、標準化は増殖も加速させる。開発者はAIアプリケーションごとにカスタムインターフェースを設計せずに、新しいツールを接続できる。中央チームは、どのサーバーが存在し、誰がアクセスできるのかをすぐに把握できなくなる可能性がある。

セキュリティ研究者はすでに、この拡大した攻撃対象領域を指摘している。MCP security controlsに関する2025年の論文は、ツールポイズニング、データ流出、サプライチェーン侵害、システム横断の権限昇格を中心的なリスクとして挙げた。

研究者らは、スコープを限定した認可、来歴追跡、サンドボックス化、インラインのデータ制御、集中型ゲートウェイによる適用を推奨した。F5のアーキテクチャはこれらの推奨事項のいくつかと一致するが、製品機能の一覧だけで実装の有効性が証明されるわけではない。

セキュリティリスクと並行して、経済的な圧力も高まっている。各プロンプト、応答、取得ドキュメント、ツール結果は、モデルリクエストにトークンを追加する可能性がある。エージェントは、利用者に見える1つのタスクを完了する間に、複数のモデル呼び出しを生成することがある。

そのため、支出の割り当ては難しい。企業はプロバイダーへの総請求額を把握していても、チーム、アプリケーション、ユーザー、自律ワークフローをまたぐ信頼できる帰属情報を持たない可能性がある。

従来のクラウド予算管理も、一部のAIワークロードには対応が遅すぎる。月次レポートでパターンが特定される前に、エージェントが失敗したステップを繰り返したり、不必要なツール呼び出しを生成したりすることがある。リアルタイムのクォータとルーティングポリシーは、より早い段階で介入できる。

F5の最高製品責任者であるKunal Anandは、この問題を、経済、セキュリティ、ガバナンス上の影響を伴うリクエストに対する制御の断片化として説明した。この枠組みはF5のプラットフォーム戦略に資するものだが、断片化の問題自体は現実に存在する。

このカテゴリーには多額の投資も流入している。Axios reportによると、WitnessAIはエンタープライズAIセキュリティプラットフォームの拡大に向けて5800万ドルを調達した。PitchBookは、エージェント型サイバーセキュリティ企業が2025年に約24件のディールで合計約2億5000万ドルを調達したと推定している。

ただし、導入状況にはばらつきがある。同じAxiosの記事は、回答者のおよそ4分の1がエージェント型システムを本格的にスケールさせているとのMcKinsey調査を引用している。

この隔たりが、ベンダーが今動いている理由を説明する。大半の企業エージェントが本番環境に到達した後ではなく、その前に制御点を確立したいからだ。

したがってGoogle Newsの報道は、F5の機能リリース以上の意味を持つ。それは、支配的なエンタープライズアーキテクチャがまだ定まらないうちに形成されつつある、インフラをめぐる競争を捉えている。

単一のコントロールプレーン対特化型AIツール

F5の主な競合相手は単一のベンダーではない。個別のルーティング、セキュリティ、オブザーバビリティ、エージェントガバナンス製品を組み合わせた特化型スタックだ。

特化型アーキテクチャでは、企業は性能向けのモデルルーター、コンテンツ検査向けのガードレールプロバイダー、MCP認可向けの別製品を選択できる。チームは、システム全体を移行することなく1つのコンポーネントを置き換えられる。

この柔軟性は、カテゴリーがまだ若いことから重要になる。セキュリティ技術、エージェントプロトコル、モデルインターフェースは変化を続けている。より優れたコンポーネントが別の場所に現れた場合、密結合のプラットフォームは調整が難しくなる可能性がある。

専門ベンダーは、狭い課題により深く注力することもできる。AIネイティブのオブザーバビリティサービスは、より豊富なプロンプトトレースや評価ワークフローを提供するかもしれない。専業セキュリティ企業は、汎用的なアプリケーションプラットフォームが見逃す攻撃を検出できる可能性がある。

その代償は運用の断片化だ。各コンポーネントは、別のポリシー言語、ダッシュボード、エージェント、データストア、ID統合、監査形式をもたらし得る。2つの製品が同じユーザーやリクエストを異なる形で解釈すると、ギャップが生じる。

F5は、共有ポリシーがこうしたギャップを減らすと主張する。同社のシステムは、モデルトラフィックとエージェントのツール呼び出し全体に予算、ロールベースのアクセス制御、監査記録、オブザーバビリティを適用する。

最も有力な導入ケースは、既存のF5環境内にある。すでにBIG-IPまたはNGINXを使用している企業は、通常のアプリケーションおよびAPIトラフィックを処理するインフラの近くにAI制御を配置できる。

F5は2026年3月、この戦略を強化した。ADSP expansionでは、同社のアプリケーションデリバリーポートフォリオ全体に、MCPトラフィックの可視性とエージェント重視の制御を追加した。

発表によると、NGINXはトラフィック経路内でMCPメタデータを検査できる。運用担当者は、既知またはこれまで追跡されていなかったエージェント活動全体で、リクエストパターン、レイテンシー、スループット、エラーを観測できる。

この位置付けにより、導入時の摩擦を減らせる可能性がある。チームは別のプロキシを挿入し、独立した運用プロセスを確立する代わりに、既存のトラフィックレイヤーを拡張できる。

競合各社も同様の主張をしている。Citrixは7月、基盤製品の発売からわずか数か月後に、NetScaler AI GatewayへMCP Gateway機能を追加した。

NetScaler updateは、モデルルーティング、トークン追跡、エージェントのツールガバナンスを組み合わせている。Citrixは、モデルとMCPの両方のトラフィックを単一のプラットフォームとダッシュボードで管理できる点も強調している。

KongはAPIインフラの観点からこのカテゴリーに取り組んでいる。CloudflareはAIルーティングを大規模なエッジネットワークと結び付けられる。Palo Alto Networksは、より広範なエンタープライズセキュリティポートフォリオにAIゲートウェイ機能を組み込んでいる。

クラウドプロバイダーには別の優位性がある。Amazon、Microsoft、Google、Databricksは、それぞれのID、データ、AIサービスの近くにモデルアクセス制御を配置できる。

この競争は、独立系AIゲートウェイベンダーに圧力をかける。トラフィック経路に製品をもう1つ追加する価値を、より深いAI特化機能によって示さなければならない。

F5にも圧力がかかる。同社は、既存のアプリケーションインフラが通常のネットワークリクエストを超えてガバナンスを行えるほど、エージェントの挙動を深く理解していることを示す必要がある。

従来のゲートウェイは、ID、宛先、リクエスト形式、レート制限を確認する。AIゲートウェイはさらに、プロンプト内容、モデル選択、ツールの意図、データの機微性、複数ステップにまたがる挙動を判断しなければならない。

こうした判断は異なる層で機能する。認可されていないデータベースツールを遮断することは、明確なアクセス制御アクションだ。一方、認可済みのエージェントが取得コンテンツによって操作されているかを判断するには、より文脈的な分析が必要になる。

共有されたIDとテレメトリーがこうした判断を改善するなら、プラットフォーム戦略は成功する。統合が主に単一のコンソールを生むだけで、専門的な制御が浅いままなら、その戦略は弱まる。

調達はこの緊張を増幅させる。セキュリティ責任者はベンダー数の削減と一貫した証跡を好むことが多い一方、開発チームは迅速に進化し、可搬性を維持するツールを好む。

結果は組織によって異なる。F5はすべての新しいAIプロジェクトで勝つ必要はない。既存顧客がそのゲートウェイを本番環境への標準経路とみなすことが必要だ。

ゲートウェイはポリシーを適用できるが、安全性を証明することはできない

中央集約型の適用は制御を改善するが、モデル出力やエージェントの挙動を本質的に信頼できるものにするわけではない。

AIゲートウェイは、その境界を通過するトラフィックを把握する。IDの認証、コンテンツの検査、判断の記録、レート制限、認可されていない宛先の遮断を行える。

ただし、許可されたアクションが正しいかどうかを常に判定できるわけではない。従業員が顧客記録に正当にアクセスしつつ、エージェントに誤った更新を実行するよう依頼することもあり得る。リクエストはすべてのポリシーを満たしていても、害を生む可能性がある。

プロンプトインジェクションも同様の問題をもたらす。悪意ある指示は、Webページ、文書、メッセージ、取得された記録の中に現れる可能性がある。エージェントは、その内容を信頼できないデータではなくコマンドとして解釈するおそれがある。

F5は、ガードレールがプロンプトインジェクションとジェイルブレイクの試みを遮断するとしている。また、同社の脅威ライブラリは毎月1万件を超える攻撃パターンを受け取るとしている。これらの主張は、各顧客のアプリケーションとデータに照らして慎重に評価する必要がある。

パターンの網羅性は、完全な保護と同義ではない。攻撃者は表現を変えたり、複数の入力に指示を分割したり、アプリケーションロジックを悪用したり、コンテンツ検査を通過した後に認可済みツールを標的にしたりできる。

誤検知は別の運用リスクを生む。厳格なフィルターは、承認済みワークフローに必要な有効なソースコード、医療用語、セキュリティ研究、顧客情報を遮断する可能性がある。

ゲートウェイがリクエストを検査できない場合、フェイルクローズの挙動は露出を抑えられる。一方で、ポリシーサービスの障害や分類の不確実性が生じた際、重要なアプリケーションを中断させる可能性もある。

企業には明確な例外手順が必要になる。誰が判断を上書きできるのか、そのアクションがどのように記録されるのか、緊急アクセスが恒久的なポリシーの抜け穴を生まないかを把握しなければならない。

レイテンシーも精査に値する。ルーティング判断、コンテンツ検査、データ分類、監査処理はいずれも時間を要する。複数のモデル呼び出しやツール呼び出しを順番に実行するエージェントでは、小さな遅延でも蓄積する。

F5は、このプラットフォームが高スループットのトラフィックに適していると説明しているが、すべての検査モードを対象とする包括的な独立ベンチマークは公表していない。購入者は、現実的なプロンプト、ストリーミング応答、長時間のエージェントセッションで検証すべきだ。

コントロールプレーン自体が機微なインフラとなる。そこにはモデル認証情報、ユーザーID、プロンプト内容、ツールの一覧、予算ルール、内部活動の記録が含まれ得る。

侵害が発生すれば、1つのアプリケーションをはるかに超える情報が露出する可能性がある。中央集約化は可視性と適用を集中させるが、運用面とセキュリティ面の影響も集中させる。

したがって、デプロイ設計が重要になる。規制対象の組織は、どこで検査が行われるのか、どのデータがF5サービスに到達するのか、ログがどのように保持されるのか、機微なコンテンツがテレメトリーに現れるかを確認すべきだ。

エアギャップ対応は、提供開始後には一部のデータ所在地に関する懸念に対処できる可能性がある。それまでは、購入者は現在提供されている機能と計画中のデプロイオプションを分けて考えなければならない。

コンプライアンスに関する表現にも節度が必要だ。SOC 2、ISO規格、HIPAA関連の制御との整合性が、顧客のデプロイメントを自動的に準拠済みにするわけではない。

コンプライアンスは、設定、運用手順、契約、アクセスレビュー、保持ポリシー、周辺アプリケーションに左右される。ゲートウェイが提供するのは制御と証跡であり、自動的な認証ではない。

チームはゲートウェイの外部にも記録を保持すべきだ。インシデント調査には、アプリケーションの文脈、モデルバージョン、取得文書、ツール結果、人間による承認が必要となる。

適切に維持された技術ナレッジベースは、これらの記録をシステム文書と結び付けられる。その文脈は、一見有効に見えるリクエストが予期しない結果を生んだ理由を調査担当者が理解する助けになる。

最後に、ゲートウェイが統制できるのは、その経路を通るトラフィックだけだ。従業員は依然として、未承認のチャットサービス、ブラウザー拡張機能、プロバイダーの直接認証情報、ローカルモデルを利用できる可能性がある。

F5はシャドーAI向けのより広範な制御と統合できるが、適用ポイントを迂回するトラフィックをゲートウェイが捕捉することはできない。アーキテクチャ図では、統制されたフローと、単に発見されたフローを区別すべきだ。

F5のコスト削減に関する主張には、実際のワークロードによる裏付けが必要だ

トークン支出を30%から60%削減できるという約束は、一部のワークロードではもっともらしいが、測定の基準線がなければ、その範囲が示すことは少ない。

セマンティックキャッシュは、繰り返し発生するモデル呼び出しを回避できる。完全に同じテキストを照合するのではなく、新しいリクエストの意味が実質的に類似している場合に回答を再利用しようとする。

この手法は、安定して反復的な問い合わせで最も効果を発揮する。カスタマーサポートの回答、社内ポリシーに関する質問、一般的な開発者からの依頼では、有意義なキャッシュ再利用が期待できる。

一方、回答が最新データ、ユーザー固有の権限、変化する会話コンテキストに依存する場合には、信頼性が下がる。不適切な回答を再利用すれば、コストを削減する一方で不正確な情報を持ち込む可能性がある。

スマートルーティングは、別のコスト削減経路を提供する。ゲートウェイは、定型的な分類や抽出タスクを小規模モデルに振り分け、難しいリクエストには大規模モデルを確保できる。

難しいのは、どのリクエストにどのモデルが必要かを判断することだ。過度に積極的なポリシーは、プロバイダーへの支払いを下げる一方で、回答品質を落としたり再試行を増やしたりする可能性がある。

モデルの階層化には評価データも必要だ。チームは、モデル間で精度、レイテンシー、安全性、総コストを比較するタスク固有のテストを必要とする。価格だけで正しい経路を決めることはできない。

GPU対応の負荷分散は、主に組織がプライベートまたはセルフホスト型の推論インフラを運用する場合に適用される。過負荷のアクセラレーターを避けてリクエストを振り分けることで、利用率を改善できる。

ただし、インフラの節約とトークンの節約は同じではない。分析では、プロバイダー料金、GPU利用率、ゲートウェイコスト、エンジニアリング時間、失敗したリクエストのオーバーヘッドを分けるべきだ。

トークンの帰属は、それでもすぐに価値をもたらし得る。多くの組織には、モデル消費量をチーム、ユーザー、アプリケーションに結び付ける一貫した方法がない。

F5のチーム単位の予算は、ワークロードが定められた上限を超える前に停止させられる。プロバイダーの請求書が届いた後に超過を発見するより、実行可能性が高い。

ただし、予算は行動を歪めるインセンティブを生む可能性がある。チームは、アプリケーションを複数のアカウントに分割したり、制御を迂回するルートを使ったり、恣意的な上限内に収めるために性能の低いモデルを選んだりするかもしれない。

したがって、コストポリシーはサービスレベル目標と結び付けるべきだ。不正検知システムと社内向け文章作成支援ツールに、同じルーティングルールや支出ルールを適用すべきではない。

エージェントのツール呼び出しは、会計処理をさらに複雑にする。従業員からの1つのリクエストが、計画、検索、複数のツール呼び出し、検証、最終的なモデル応答を引き起こす場合がある。

F5は、MCP Gatewayが冗長な呼び出しを排除し、関連するトークンの無駄を最大90%削減できるとしている。購入者は、製品が冗長性をどのように定義しているのか、エージェントの実行計画を変更するのかを確認すべきだ。

完全に同一の繰り返し呼び出しを防ぐことは、比較的安全だ。根本データがその間に変化している場合、見かけ上似ている2つの呼び出しを抑制することはリスクになり得る。

チームは、記録された本番トレースでゲートウェイをテストすべきだ。個々のリクエストあたりの消費トークンだけでなく、タスク全体の完了率を比較する必要がある。

有用な評価には複数の観点を含めるべきだ。成功した結果、再試行、キャッシュエラー、セキュリティブロック、レイテンシー、プロバイダー支出、インフラ利用、運用担当者の負担を測定する。

基準線には、既存の制御も反映させなければならない。F5をまったく最適化されていないアプリケーションと比較すれば、成熟したルーティングレイヤーと比較するよりも見かけ上の効果は大きくなる。

これはコスト削減の主張を無効にするものではない。利点はゲートウェイというラベルそのものではなく、特定のワークロードとポリシー設計に属することを意味する。

同社の経済面での訴求は、購入に関わる層を広げる。セキュリティチームはポリシー適用を、プラットフォームチームはルーティングを、財務チームは帰属情報を得る。

この連合は導入を加速させ得る。一方で、支出削減、より強力な検査、より高速な応答がルーティング判断を異なる方向へ引っ張る場合、目標の衝突も生み得る。

F5の戦略が機能するかを示す3つのシグナル

次の試金石は、別の機能発表ではない。企業が統合コントロールプレーンを通じて意味のある本番トラフィックをルーティングするかどうかだ。

最初のシグナルは、独立して文書化された顧客導入だ。F5は、Model Gateway、MCP Gateway、AI Guardrailsを併用する本番デプロイメントを示すべきである。

そうした事例には、トラフィック規模、デプロイアーキテクチャ、ポリシーの適用範囲、測定可能な運用成果を含めるべきだ。大企業に関する匿名の主張は、詳細な実装例よりも信頼性を与えにくい。

規制の厳しい業界からの証拠は、特に重要となる。金融サービス、医療、政府の顧客は、厳格なID、データ所在地、監査、可用性の要件に直面している。

そこでの導入成功は、F5の統合プラットフォームという主張を強化する。実験的なアプリケーションでの限定的な利用にとどまれば、この製品が中核インフラではなく追加レイヤーのままであることを示唆するだろう。

2つ目のシグナルは、コストと性能に関する主張の検証だ。顧客は、トークン削減率30%から60%という範囲について、再現可能な証拠を必要としている。

有用なベンチマークは、ワークロードの種類、キャッシュ率、モデル構成、ルーティングルール、応答品質、ゲートウェイのレイテンシーを開示すべきだ。これらの詳細がなければ、割合で示された削減効果を比較するのは難しいままである。

独立テストでは、負荷下でのガードレールも評価すべきだ。購入者は、コンテンツ検査が障害時のレイテンシー、スループット、誤検知、可用性をどのように変えるのかを把握する必要がある。

強力な結果が出れば、セキュリティと最適化が単一のリクエスト経路を共有できるという主張を裏付けることになる。結果が弱ければ、高速ルーティングと、より深い非同期分析を分離するアーキテクチャが有利になる。

3つ目のシグナルは競合の対応だ。CitrixはすでにモデルとMCPのガバナンスを組み合わせており、Kong、クラウドプラットフォーム、セキュリティベンダーもそれぞれのゲートウェイを拡充し続けている。

これらのベンダーがF5の共有ポリシーモデル、デプロイメントの選択肢、アプリケーションセキュリティとの統合に追随するかを注視したい。また、企業が個別のゲートウェイコンポーネントを置き換えられるオープンなインターフェースを求めるかにも注目すべきだ。

オープンなポリシー形式への移行は、強く束ねられたプラットフォームを弱体化させる。一方、セキュリティ調達の集約が進めば、F5や他の既存インフラプロバイダーにとって追い風となる。

Google Newsは、統合されたAIガバナンスをうたう発表を引き続き取り上げるだろう。より重要なのは、そうした見出しの後、プラットフォームチームがモデルやツールに到達する前にリクエストをどこへ通すべきかを決める作業だ。

企業の購買担当者は、ゲートウェイを選定する前に実際のAIトラフィックを整理すべきだ。直接的なモデル呼び出し、エージェントツール、機密データの経路、未承認サービス、追加レイテンシーを許容できないシステムを特定する必要がある。

次に、代表的な本番ワークフローをエンドツーエンドでテストする。タスク品質、ブロックされたリクエスト、データ露出、応答時間、総コスト、そして各判断を説明するために必要な労力を測定する。

F5は、AIツールの乱立に対する一貫した答えを提示した。すなわち、モデル、エージェント、セキュリティを横断する単一のコントロールプレーンだ。今後3カ月で、顧客がこの制御点を基盤と見るのか、それとも管理対象となる別の製品と見るのかが明らかになるはずだ。