アプリケーションアーキテクチャが大きく変化するたびに、ネットワークにも適応が求められます。これは新しい考え方でも、革新的な考え方でもありません。これまでも同じことが繰り返され、そのたびに同じパターンをたどってきました。新たに主流となるアプリケーションタイプが登場すると、既存のスタックでは提供できない機能が求められるため、「ネットワーク」はそれを支えるように適応してきました。今、AI推論でもまさに同じ圧力が生じています。
推論はトレーニングではありません。実験でも、データサイエンスの演習でもありません。推論は本番環境における実行時の処理であり、アプリケーション層のように機能します。そこにはユーザー、トラフィックパターン、レイテンシーへの敏感さ、障害モード、コスト上の制約、セキュリティリスクがあります。推論をバックエンドサービスや特殊なワークロードとして扱うだけでは、実際に起きていることを捉えられません。
推論は、新しいタイプのアプリケーションです。
F5の年次調査から、この現状は明らかです。約80%の組織が自ら推論を運用しています。パブリックAIサービスのみに依存している組織は、ごく少数です。ほとんどの組織は、自社環境内の複数のクラウドで、従来のアプリケーションやAPIと並行して推論を実行しています。そして、推論時のルーティング、可用性、パフォーマンス、セキュリティに関する問題にすでに直面しています。
ここが重要なポイントです。問題が生じるのは「推論時」であり、その前でも後でもなく、ましてやトレーニング時でもありません。
ここでは、従来のデリバリー手法だけでは不十分です。ロードバランシングは、バックエンドに互換性があることを前提としています。ヘルスチェックは、可用性を利用可能か利用不可かの二者択一で判断できることを前提としています。静的なトラフィックステアリングは、動作が予測可能であることを前提としています。しかし、プロンプト、トークン、モデルの動作に応じてリクエストのコスト、品質、レイテンシ、リスクが変動する場合、これらの前提はいずれも成り立ちません。
したがって、ゆえに、つまり、「ネットワーク」は再び変わらなければなりません。
新しいネットワークスタック
数十年にわたり、ネットワークスタックはパケットとプロトコルの観点から説明されてきました。レイヤー2と3はパケットを処理し、レイヤー4～7はセッション、プロトコル、アプリケーションを処理してきました。この枠組みが成り立っていたのは、アプリケーションがプロトコルを通じて意図と目的を表現していたためです。しかし、推論はそうではありません。
推論は、プロンプトを通じて意図と目的を表現します。
だからこそ今、新たな支配的レイヤーが台頭しつつあります。レイヤー8、プロンプトレイヤーです。
ちょっと待ってください、Lori、と思われるかもしれません。ペイロードの一部に基づくルーティングは以前から行われてきました。それでは、今回は何がそれほど違うのでしょうか？
ご質問ありがとうございます！
実際、その違いは非常に大きなものです。特に、推論ではURIが「関数」に対応しておらず、呼び出される対象を特定するには、プロンプトから意図を抽出する必要があります。ペイロードベースのトラフィックステアリングが新たなレイヤーと呼べる水準に達しなかった根本的な理由は、ここにあります。ゲームを根本から変えるものではなかったのです。では、推論はどうでしょうか。推論はゲームを変えるだけでなく、そのルールを絶えず書き換えます。
ここで重要なのは、「プロンプトレイヤー」におけるルーティングの判断が、IP、ポート、URI、さらにはペイロードの一部だけに基づくものではなくなったことです。判断の基準となるのは、誰がリクエストしているか、何を求めているか、どの程度のコストがかかるか、どの程度のリスクがあるか、そしてどのような出力品質が求められるかです。F5の最新調査では、出力モデレーションやトークン制御と併せて、このスタックレイヤーが、アプリケーションデリバリとセキュリティによる効果が最も大きいレイヤーであることが明らかになりました。さらにモデルルーティング（これもレイヤー8）を加えると、AI推論のセキュリティ確保とスケーリングにおける重要性を、すでに大半の組織が認識していることがわかります。
プロンプト検査、トークン制御、出力モデレーション、モデルルーティングは、オプション機能ではありません。本番環境で推論を運用するための必須要件です。
ご安心ください。L4-7がスタックの最上位になってもL2-3が消えなかったように、その下位レイヤーもなくなるわけではありません。単に基盤となるだけです。パケットルーティングも、プロトコル処理も、引き続き重要です。
しかし、今や価値があるのはレイヤー8です。この点を見誤ってはなりません。
推論への対応が、この変化を裏付ける
パケット向けに構築されたネットワークではアプリケーションをサポートできなかったため、Application Delivery Controllerが登場しました。Webアプリケーション向けに構築されたネットワークではAPIをサポートできなかったため、APIゲートウェイが登場しました。そして今、API向けに構築されたネットワークでは、自律的かつ確率的に動作し、コストが変動するアプリケーションをサポートできないため、推論を支える仕組みが登場しつつあります。
市場の反応は、この変化を裏付けています。モデルルーティング、推論ゲートウェイ、トークンガバナンス、プロンプト制御を軸とするスタートアップが次々と誕生しています。ハイパースケーラーも、同様の機能を社内で着々と構築しています。
企業の対応からも、この変化が裏付けられています。組織の90%が推論サービスを利用しており、そのうち70%は、自社運用のサービスを含む2つ以上の異なる推論サービスを利用しています。企業はマルチモデル戦略を導入し、エージェント型AIを試行するとともに、運用にAI主導の自動化を取り入れています。
これは誇張ではありません。構造的な変化です。
推論は、単なる新たなワークロードではありません。パケットとプロトコルを基盤とし続けるアーキテクチャも機能はしますが、効率的にスケールすることはできません。APIまでしか対応しないネットワークスタックでは、自律システムの制御が困難になります。
推論によって、制御点はスタックの上位層へと移りました。その先の変化は避けられません。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
理由は間違っていても、結果は正しい：止まらないAPIの増加、20億件へ
従来、APIの乱立は人間の作業量によって制約されていました。現在では、AIエージェントが自律的にエンドポイントを作成して連携させるため、AI関連のAPI呼び出しや統合が急増しています。
AIアプリケーションデリバリのトップ10：互換性のないデリバリポリシー
ポリシーの不整合がAI障害を引き起こします。フェイルオーバー、タイムアウト、制限、セキュリティ制御に一貫性がないと、ソフト障害や不完全な結果が発生し、エンドポイントごとに異なる結果が生じます。
AIアプリケーションデリバリーの課題トップ10：最適化されていないトラフィックステアリング
AIは従来のトラフィックステアリングの前提を覆します。バックエンドには互換性がなく、コストも異なり、エージェントは予測不能に処理を分散させるため、ルーティングではモデル、GPUの稼働状態、データの局所性を考慮する必要があります。
パケットからプロンプトへ：推論がスタックに新たなレイヤーを追加
推論はトレーニングでも、実験でも、データサイエンスの演習でもありません。推論は本番環境におけるランタイムの動作であり、アプリケーション層と同様に機能します。
AI規模で制御を維持する唯一の方法はプログラマビリティ
急速に変化する環境でリアルタイム制御を確保しながら、AI駆動型システムを拡張し、セキュリティを確保するうえで、データプレーンとコントロールプレーンのプログラマビリティが重要な理由をご紹介します。
AIのコンテキストウィンドウ管理は魔法ではありません。アーキテクチャです。
AIアプリビルダーが、ドリフト、レイテンシー、プロンプト攻撃を防ぐために、コンテキスト、メモリ、インフラストラクチャを管理しながら、デリバリーとセキュリティを進化させる必要がある理由をご紹介します。