ADC09の当初の記事では、すべてのアプリケーションが標準化されたデリバリーモデルにうまく適合するわけではないという現実的な見解を示しています。アプリケーションによっては、デフォルトの負荷分散やセキュリティのパターンでは対応できない、カスタムルーティング、特別な統合、固有の処理が必要です。ここから得られる教訓も現実的です。すべてのアプリケーションを同じ型に無理に当てはめようとすると、アプリケーションが機能しなくなるか、運用上の負担が生じます。その解決策は一貫してデリバリー層のプログラマビリティです。これにより、すべてを書き直すことなく適応できます。
その前提は今も変わりません。
変わったのは、AIによって、このように動作するアプリケーションが劇的に増えたことです。かつては例外的だったケースが、急速に当たり前になりつつあります。
AIシステムは静的なものではありません。複数の要素を組み合わせ、コンテキストに応じて動作し、リクエストへの対応方法もますます自律的になっています。つまり、「個別仕様」はもはや一部のアプリケーションだけの特性ではなく、アーキテクチャ自体の特性なのです。
個別仕様のAIアプリケーション要件がもたらす影響
可用性への影響
従来のシステムでは、個別要件に対応するためにルーティングやフェイルオーバーへカスタムロジックを組み込むことで、可用性の確保が複雑になることがよくありました。標準パターンは、予測可能な動作を前提としています。アプリケーションがその前提から外れる場合は、それに合わせて可用性戦略を調整する必要があります。
AIによって、課題はリクエストのルーティングから意思決定の完了へと移ります。
AIシステムへのリクエストは、単純なトランザクションではありません。モデルの選択、コンテキストの取得、ポリシーの適用、応答の生成に加え、追加のサービスやツールの呼び出しが必要になる場合もあります。各ステップはそれぞれ独立して成功または失敗する可能性があり、レイテンシーのしきい値、コスト上限、規制要件など、異なる制約が適用されることがあります。
つまり、可用性はもはや、エンドポイントに到達できるかどうかだけの問題ではありません。リクエストを処理するために必要な一連の判断を、システムがすべて正常に実行できるかどうかが重要です。
すべてのコンポーネントが技術的には正常であっても、アプリケーションが回答を生成できない場合があります。モデルが利用可能でも、特定のデータセットに対しては使用が許可されていないことがあります。取得処理でデータが返されても、ポリシーにより使用できない場合があります。エージェントがワークフローを開始しても、必要なアクションがブロックされているため、完了できないことがあります。
これにより、従来とは異なる種類の可用性の課題が生じます。従来のフェイルオーバーは、リクエストを別の場所に送信できることを前提としています。AIシステムでは、多くの場合、タスクを完了するための別の方法を見つける必要があります。そのためには、インフラストラクチャの冗長化だけでなく、デリバリーレイヤーでの動的な意思決定が必要です。
スケーラビリティへの影響
元の項目では、個別に構築された統合に依存するアプリケーションをスケールさせる難しさが強調されています。依存関係が増えるたびに複雑さが増し、スケーリングには多くの場合、それらの統合を効果的に管理するための追加の開発作業が必要になります。AIは本質的に複数の要素を組み合わせて構築されるため、この問題をさらに増幅させます。
AI駆動型アプリケーションは、複数のモデル、ベクトルデータベース、API、外部データソースに依存する場合があります。これらの要素の組み合わせは固定されておらず、リクエスト、ユーザー、コンテキストに応じて変化する可能性があります。この変動性が、スケーラビリティを左右する主要因となります。
スケーリングでは、単に1秒あたりのリクエスト処理数を増やすだけでは不十分です。リクエストごとに、より多様な動作の組み合わせに対応する必要があります。
すべてのバリエーションをアプリケーションコードに実装しなければならない場合、システムはすぐに管理しきれなくなります。変更に伴うリスクが高まり、デプロイが遅くなり、アプリケーションは条件分岐ロジックの寄せ集めになってしまいます。
そのため、従来型アプリケーションで用いられてきた同じ解決策が、さらに重要になります。つまり、こうした可変性をアプリケーションから切り離し、デリバリーレイヤーに移します。ルーティングの判断はオーケストレーションの判断へと拡張され、サービスの挿入は動的な構成へと発展します。デリバリー層は、各リクエストを処理するために適切なコンポーネントの組み合わせを選択する役割を担います。
この移行を行わなければ、複雑さが増大し、スケーラビリティを維持できなくなります。
運用効率への影響
個別要件は、これまでも運用負荷を増大させてきました。例外を設けるたびに保守が必要となり、カスタマイズするたびに新たな障害点が生じます。こうした負荷が時間とともに積み重なると、管理が難しく、進化にも時間がかかるシステムになります。これが運用上の負債であり、AIはその蓄積を加速させます。
システムは、事前定義されたパスを処理するだけではなく、パス自体を生成するようになっています。プロンプトが異なれば、異なる実行パスがトリガーされる可能性があります。エージェントは、事前に明示的に設計されていない方法で複数のアクションを連鎖させることがあります。また、新しいモデルやサービスが定期的に導入され、それぞれに固有の特性と制約があります。
これにより絶えず変化が生じるため、運用チームは継続的に対応する必要があります。
その変動に対処する方法が、アプリケーションコードの変更や静的な構成の更新に限られていると、システムは変化に弱くなります。チームはシステム全体を管理するのではなく、エッジケースへの対応に追われます。環境間に不整合が生じ、動作にもずれが生じます。
したがって、運用効率は、こうした変動性を一元的に制御できるかどうかに左右されます。デリバリーレイヤーは安定化の役割を担い、変動し続けるシステム全体の差異を吸収しながら、一貫したポリシーを適用する必要があります。これがなければ、個別対応はたちまち混乱を招きます。
個別要件を管理するためのベストプラクティス
第一級の機能としてのプログラマビリティ
AI、従来型、モダン、あるいは「次世代の何か」であっても、個別の要件に対応する鍵となるのは、引き続きプログラマビリティです。アプリケーションにロジックをハードコーディングする代わりに、さまざまなニーズに適応できるプログラマブルなレイヤーをデリバリーパスに導入します。
AIシステムは急速に進化するため、AIではこれが不可欠です。新しいモデルが導入され、ポリシーやデータソースが変化し、予期しないインタラクションパターンが生まれます。設計時にそのすべてを予測することはできず、何かが変わるたびにアプリケーションを再構築する余裕もありません。
プログラム可能なデリバリーレイヤーを使用すれば、その場で変化に対応できます。リクエストの検査、コンテキストに応じたルーティングの適用、入出力の変更、必要に応じたサービスの追加や削除が可能です。さらに重要なのは、こうした対応を複数のアプリケーションにわたって一貫して実施できることです。
ここで、アプリケーションデリバリは単なる配管のような役割を超え、コントロールプレーンとしての性格を帯び始めます。単にトラフィックを転送するだけではありません。システムの動作そのものを形作ります。
トラフィックステアリングから意思決定に基づくルーティングへ
従来のアプリケーションデリバリでは、トラフィックを適切な宛先に振り分けることに重点が置かれてきました。これまでは常に「このリクエストをどこに送るべきか」が問われていました。AIによって、この問いは「このリクエストに応える最適な方法は何か」という、よりきめ細かなものへと変わります。
場合によっては、レイテンシ、コスト、コンプライアンス要件に基づいて複数のモデルから選択します。また、モデルに送信する前に、リクエストに追加のコンテキストを付加することもあります。さらに、AIをまったく使用せず、より正確な回答やコンプライアンスに準拠した回答を提供できる決定論的サービスにルーティングする場合もあります。
もはや、判断基準は場所だけではありません。どのように実行するかが重要です。
この変化により、ルーティングはより高度な機能へと進化します。複数の利用可能な機能の中から、リクエストがたどる経路を選択する役割を担うようになります。また、デリバリーレイヤーには、ネットワークの状態だけでなく、ポリシー、コンテキスト、期待される結果も把握できる可視性が必要になります。
これは、ADC09が一貫して主張してきたことの自然な延長です。アプリケーションに固有の要件がある場合、デリバリーレイヤーはそれに適応する必要があります。AIによって、その適応がより高いレベルで行われるようになるだけです。
まとめ
プログラマビリティという機能は、アプリケーションは一様ではなく、インフラストラクチャはその違いに対応する必要があるという単純な事実を、常に前提としてきました。この事実は今も変わりません。
AIによって、こうした違いが生じる頻度と複雑さはいずれも増大します。システムはより動的かつ構成的になり、実行時の判断への依存度も高まります。その結果、「標準的な」アプリケーションパスという考え方を維持することが難しくなります。
対応はこれまでと変わりませんが、緊急性は一層高まっています。
デリバリーレイヤーにはプログラマビリティが必要です。リクエストの処理、ルーティング、実行方法を一元的に制御する必要があります。さらに、変更が生じるたびにアプリケーションを書き直すことなく、新たな要件に対応できる能力も必要です。
AI主導のアーキテクチャでは、個別対応はもはや例外として設計時に回避すべきものではないからです。
それこそが、設計の前提となる運用モデルです。
世界中の組織が直面しているアプリケーションデリバリに関する課題トップ10について詳しくご覧ください。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
AIアプリケーションデリバリの10大課題：セキュリティと規制遵守の欠如
AIにより、コンプライアンスの対象は経路やストアのセキュリティ確保から、モデルへのアクセス、検索コンテキスト、出力、エージェントのアクションといったランタイム動作のガバナンスへと広がります。そのため、制御を推論処理により近い場所へ移す必要があります。
Application Delivery Top 10とは？
F5は、Application Delivery Top 10リストを通じて、アプリケーション、API、生成AIの配信とセキュリティ確保に伴う課題への組織の対応を支援することを目指しています。
AIアプリケーションデリバリのトップ10：互換性のないデリバリポリシー
ポリシーの不整合がAI障害を引き起こします。フェイルオーバー、タイムアウト、制限、セキュリティ制御に一貫性がないと、ソフト障害や不完全な結果が発生し、エンドポイントごとに異なる結果が生じます。
AIアプリケーションデリバリーの課題トップ10：レイテンシーに対応できない
AIにより、レイテンシは単なるパフォーマンス上の問題ではなく、信頼に関わる問題になります。「アシスタント」の応答が遅いと、ためらいや障害のように感じられます。また、トークン数の多いプロンプトや出力は、システムが正常でも処理負荷を増大させます。
AIアプリケーションデリバリーの課題トップ10：最適化されていないトラフィックステアリング
AIは従来のトラフィックステアリングの前提を覆します。バックエンドには互換性がなく、コストも異なり、エージェントは予測不能に処理を分散させるため、ルーティングではモデル、GPUの稼働状態、データの局所性を考慮する必要があります。
AIアプリケーションデリバリーのトップ10：不十分なトラフィック制御
従来のレート制限やスロットリングでは、実際の影響範囲を捉えきれません。AIワークロードはモデル、ベクトルストア、サービスへと処理を分散させるため、レイテンシの急増、連鎖的な障害、再試行を引き起こします。