私たちは、モデルを単なるエンドポイントとして扱い続けています。まるで、入力を理解不能な数値の羅列に変換するエンジンをホストするサーバーなど存在しないかのようです。
そう、確かに存在します。そして、アプリケーションの提供において、これまでWebサーバーやアプリケーションサーバーが果たしてきたのと同じくらい重要な存在になるでしょう。さらに、インフラストラクチャアーキテクチャの再考を再び迫ることにもなります。
つまり、モデルをエンドポイントの背後に配置した瞬間（要するに、推論サーバーをデプロイした瞬間）、そのモデルはビジネスを支えるレイヤー4～レイヤー7（L4～L7）の同じ通信経路を通ることになります。F5の最新調査によると、組織の80%がすでにクラウドまたはオンプレミスで推論を実行しています。つまり、モデルはロードバランサー、ゲートウェイ、WAF、APIブローカーを経由する、もう1つの本番ワークロードになっているのです。
また、耳の痛い事実もいくつか明らかになりました。
推論によってAPIが増加
まず、推論を運用するとAPIが増加します。モデルを利用する新たなアシスタント、スコアリングサービス、機能フラグは、いずれも新たな侵入口となります。その結果、プロンプトインジェクション、情報漏えい、出力操作が入り込む箇所が増え、コンテキストが内部ネットワークを行き交う経路も増加します。推論のデプロイは、ランタイムの衛生管理が良好であることと相関していますが、依然として課題は残ります。推論を運用するチームでも、14%はプロンプトを検査せずに通過させています。SaaSのみを利用するユーザーでは、その割合が40%に跳ね上がります。検査を省くことは、「シンプルに保つ」ことではありません。馬が勢いよく逃げ出すのを見ながら、その健脚を褒めつつ、納屋の扉を開け放しているようなものです。
だからこそ、制御ポイントが重要です。推論はAPIと同じ経路を通るため、ポリシーは通信経路上で適用する必要があります。推論をデプロイする組織は、この点を理解しているようです。61%が入出力の検査にAIゲートウェイを使用し、39%がファイアウォールを追加し、35%がカスタムプロキシを使用しています。一方、SaaSのみを利用する組織はベンダーのデフォルト設定に依存しており、その差は明らかです。テストや監視を一切行わない割合は3倍に上り、30%が監査用にプロンプトや生成結果を記録していません。これに対し、推論をデプロイする組織でログを記録していない割合はわずか8%です。これは成熟度の差であると同時に、改善の機会でもあります。アプリがサードパーティのAIを利用する場合、AIゲートウェイは継続的なテスト、フィルタリング、ポリシー適用の組み込みポイントとなります。丁寧なプロンプトを書いて、あとは祈るだけでは不十分です。
推論によりDPUの重要性が高まる
第2に、推論により、DPUは「あれば便利」なものから必要不可欠なものへと変わりつつあります。推論を実行しているチームの71%は、ハードウェアの購入時やインスタンスの選択時にDPUを検討または採用しています。一方、推論を導入していないグループでは、その割合は43%です。アプリケーションの稼働を支える同じマシンで、暗号化トラフィック、インライン検査、ポリシー評価も処理する場合、オフロードは単なるパフォーマンス向上のための小技ではありません。大規模な復号、分類、検査、ポリシー適用を行いながら、レイテンシを許容範囲内に抑えるための手段です。DPUは、推論で特に必要となる処理、すなわちTransport Layer Security（TLS）、テレメトリ、きめ細かなポリシー、リクエスト単位のチェックを高速化します。端的に言えば、推論が増えるほどネットワーク上の処理負荷も増え、その負荷をDPUが担います。
推論にはコンテキストへの配慮が不可欠
最後に、コンテキストは、多くのチームが軽視しがちなもう1つの重要な要素です。推論は、入力と出力だけで成り立つものではありません。履歴、検索結果、ツール、エージェント間のやり取りも含まれます。組織がModel Context Protocol（MCP）の導入を検討するなか、ここでも同じ傾向がすでに見られます。導入グループでは58%がMCPの採用意向を示し、非導入グループの21%を上回っており、標準化を進める計画です。その魅力は明らかです。MCPは、コンテキストフローを構造化できる可能性をもたらします。
リスクも明らかです。不透明なコンテキストは、見栄えよく整えたポリシーを迂回するサイドチャネルになり得ます。そのため、プロンプトと応答だけでなく、コンテキスト自体の来歴とポリシーも把握できる検査が必要です。監査されていないデータを取引エンジンに入力しないのと同様に、監査されていないコンテキストをモデルに取り込んではなりません。
インフラストラクチャアーキテクチャへの影響
では、これらすべてがアーキテクチャにとって何を意味するのでしょうか。何らかの影響があることは、すでにお分かりでしょう。
主なポイント
- 経路にポリシーを組み込む。ゲートウェイとL7プロキシは、すでにトラフィック経路上にあります。これらを推論対応にします。プロンプトを検査し、出力をフィルタリングし、データにタグを付け、モデルにとって実効性のあるアプリ単位およびユーザー単位の制限を適用します。
- DPUを活用してレイテンシーを抑える。オフロードせずに実行時の復号、分類、検査、ポリシー適用を行おうとすれば、金曜の夜にはセキュリティを犠牲にしてパフォーマンスを優先し、月曜にはそれが熟慮の末の判断だったかのように取り繕うことになります。
- コンテキストをサプライチェーンとして扱う。コンテキストの構築方法を標準化し、ラベルを付け、使用前に検証して、来歴を記録します。MCPは有用ですが、コンテキストの悪用を可視化して阻止できるオブザーバビリティと適用制御を組み合わせる必要があります。
最新の調査で得られた最も重要な知見は、端的に言えば、推論が今や第一級のワークロードになったということです。推論は他のあらゆる処理と同じパイプライン上で実行されますが、従来の「API対応の定石」だけでは十分に対処できない新たなリスクをもたらします。
パイプラインを高度化し、負荷の高い処理をDPUに移行するとともに、呼び出しだけでなくコンテキストも管理します。これを実践するチームは、より迅速にリリースでき、安心して運用できます。そうでないチームは、困難を通じてレジリエンスの重要性を学ぶことになるでしょう。
著者について
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アプリビルダーが、ドリフト、レイテンシー、プロンプト攻撃を防ぐために、コンテキスト、メモリ、インフラストラクチャを管理しながら、デリバリーとセキュリティを進化させる必要がある理由をご紹介します。