分類とアプリケーションデリバリーの進化

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

私がこれまで、そう、20年近くにわたって書いてきたものを何かしらお読みいただいている方なら、すでにご存じでしょう。アプリケーションアーキテクチャは、アプリケーションデリバリに大きな影響を及ぼします。これは、アプリがどのように構築されるかだけの話ではありません。アプリがどのように動作し、スケールし、障害を起こすのか、そして何より、アプリを配信するために構築したインフラストラクチャをどのように通過するのかという話です。エージェントアーキテクチャは、そのすべてを大きく変えようとしています。

今回の進化には、新たなプロトコルへの対応や新たなセキュリティ機能だけでは不十分です。分類が必要になります。

業界では長年にわたりトラフィックを分類してきましたが、その主な目的はトラフィックを阻止することでした。分類を利用してボットをブロックし、脅威を除外し、悪意のあるペイロードにWAFポリシーを適用することは、どの組織でも行われています。これは最低限必要な取り組みにすぎません。そして、分類の用途はこれまで、ほぼセキュリティに限られてきました。

しかし、AIはトラフィックだけでなく、その処理に必要なリソースも変えつつあります。では、エージェントアーキテクチャはどうでしょうか。ゲームのルールを変えるだけでなく、ゲームそのものを変えます。

AIの導入は、これまでのほとんどのテクノロジーを上回る速さで進んでおり、AIエージェントはすでに企業に導入され始めています。

POSTは、単なるリクエストかもしれません。目標かもしれません。あるいは、スタック全体をたどりながら推論しようとするAIエージェントかもしれません。オーケストレーションを開始したり、再帰的なワークフローをトリガーしたり、200トークンのプロンプトが20,000トークンに膨らんでバックエンドをダウンさせたりする可能性もあります。では、インフラストラクチャはどうでしょうか。今もすべてのPOSTを同じものとして扱っています。

そこに問題があります。

現代のトラフィックは、単なるトラフィックではありません。タスクであり、処理であり、判断でもあります。トラフィックをルーティングする前に分類できるかどうかが、アプリの応答性と可用性、そして最終的にはセキュリティを維持できるかどうかを左右します。

1. 接続ベースのルーティング（レガシー）

まずは、よく知られた仕組みから見ていきましょう。レイヤー4（L4）ルーティングを基盤とする従来型のトラフィック管理モデルは、今なおインターネットの多くを支えています。このアプローチでは、次の基本的なパラメーターを使用します。

• L4ルーティング： IPアドレスやポート番号など、トランスポート層の情報に基づいて判断します。
• パスベースルーティング：通常はアプリケーション層（レイヤー7）でURLパスを限定的に検査します。
• 同種サーバープール： バックエンドサーバーを同一のものとして扱い、特化した機能に基づく区別は行いません。
• 負荷分散：過負荷を防ぐため、複数のサーバーに接続を均等に分散します。

問題は、このモデルがリクエストの「意味」をほとんど認識できないことです。トラフィックを、それぞれ異なるニーズを持つ多様なタスクではなく、均一なパケットとして捉えます。生成AI、組み込み型大規模言語モデル（LLM）、エージェントベースのフレームワークが普及する現在、すべてのトラフィックを同等に扱うことはできないため、こうした認識不足はますます大きなリスクとなっています。

2つのHTTP POSTリクエストを考えてみましょう。

• 一方は、ユーザープロファイルの更新など、単純なCRUD（作成、読み取り、更新、削除）操作かもしれません。
• もう1つは、5つのダウンストリームツールを呼び出し、データベースに書き込み、長時間実行されるテキスト要約タスクを開始するAI駆動型の推論ループなど、複雑なマルチエージェントワークフローをトリガーする場合があります。

インフラストラクチャがこれらのリクエストを同一に扱い、同じルーティングルール、タイムアウト、バックエンドサーバーを使用すると、問題を招くおそれがあります。リソースを大量に消費するAIタスクを軽量なデータベースクエリと同じように処理すると、ボトルネックや障害、パフォーマンス低下が発生する可能性があります。現代のトラフィックには、より高度な管理が必要です。

2. 分類ベースのルーティング（現在／移行期）

L7ルーティングは長年にわたって行われてきました。パスの照合、ペイロードの検査、ヘッダーの確認を通じて、トラフィックの送信先プールを決定します。これがコンテンツベースルーティングです。便利ではありますが、わかるのはリクエストに何が含まれているかだけであり、なぜそのリクエストが存在するのかまではわかりません。

今後必要となるのは、コンテキストベースの分類です。

• L7以上で動作し、ペイロード検査の枠を超えます。
• トラフィックは、意図、複雑さ、コストに基づいて分類されます。
  • これは要約タスクですか、それともユーザーログインですか？
  • 再帰的な処理、AIによる生成、またはレイテンシーの影響を受けやすい処理ですか？
• プールは、容量だけでなく機能によっても区別されます。
• ルーティングの判断では、形式だけでなく目的も考慮されます。

これにより、トラフィックを「配信すべきコンテンツ」ではなく「処理すべき作業」として扱うようになります。リクエストが達成しようとしている目的に基づき、リクエストをどこに送るか、どのように優先順位を付けるか、そしてどのポリシーを適用するかをリアルタイムで判断できます。インテントベースでも、コンテキストアウェアでも、呼び方はさほど重要ではありません。変化そのものは現実だからです。リクエストはもはや単なるトランザクションではなく、呼び出し、トリガー、HTTPに包まれた目標へと変わりつつあります。

これらはすべて、Application Delivery Top 10の第4位（トラフィック制御）、第5位（トラフィックステアリング）、第6位（レイテンシ管理）に直接対応します。コンテキストを把握できなければ、制御も、誘導も、最適化もできないからです。

3. タスクベースのルーティング（新興）

私たちが目指しているのは、まさにこの方向です。特に、エージェント型システムや再帰的プランナーが本番環境に組み込まれるにつれ、その傾向は強まります。もはやコンテンツを提供するだけではありません。目標を管理するのです。それによって、すべてが変わります。

このモデルでは、1つのリクエストが必ずしも1つのレスポンスに対応するとは限りません。代わりに、一連の小さなタスクが開始される場合があります。並列で実行されるタスクもあれば、別のタスクの完了を待ってから実行されるタスクもあります。単にトラフィックをルーティングするのではなく、処理全体をオーケストレーションすることになります。

パイプラインというより、ワークフローとして捉えてください。成果につながる一連のステップをチェックリストに沿って管理します。すぐに実行できるステップもあれば、順番を待つ必要があるものもあります。ただし、すべてのステップを連携させて監視し、機能、ポリシー、現在の負荷に基づいて制御する必要があります。

そうなると、従来のルーティングロジックでは対応しきれなくなります。すべてのリクエストが複数のステップと複数のエージェントからなるプロセスへと展開する可能性があるため、静的なパスや一律のポリシーでは不十分です。パケットの送信先を決めるだけでなく、タスクの内容と要件を把握し、その処理に最適な人やシステムを判断できる仕組みが必要です。

そして、ここが重要です。こうした処理は、分類なしには実現できません。インフラストラクチャがリクエストの目的を理解できなければ、インテリジェントにルーティングすることもできません。これは遠い未来の話ではなく、現実になりつつあります。そして分類は、リクエストのルーティングから真の連携へと移行するための架け橋となります。

これが重要な理由

明確にしておきましょう。これは、メタデータを増やしたり、より高度なルーティングテーブルを構築したりするという話ではありません。すでに観測しているトラフィックに対する考え方を変えるということです。

分類によって、リクエストに反応するだけの状態から、ルーティングやスケーリングを行う前、あるいは再帰的なエージェントループを静的アセットの取得と同じように扱って障害を引き起こす前に、リクエストを理解できる状態へと移行できます。

もはやセキュリティだけのものではありません。リクエストの「中身」だけが問題なのでもありません。重要なのは、リクエストが何を「意味するか」、何をしようとしているか、どの程度の負荷があるか、そしてダウンストリームの何に影響するかです。

だからこそ、分類は単なる新たなトレンドではなく、必須要件です。エージェント、タスク、ワークフロー、リアルタイムオーケストレーションが例外的なケースではなく広く導入される世界に対応できるよう、トラフィック管理を進化させるうえで欠かせないステップです。

理解できないものは管理できません。分類は、理解への第一歩です。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事