アプリケーション配信の分類と進展
過去20年にわたり私の書いた内容を追ってきたなら、アプリケーション アーキテクチャがアプリケーション配信に深い影響を与えると知っているはずです。 問題はアプリの作り方だけではありません。動作の仕方、スケールの方法、障害の対応、そして何より、配信のために構築したインフラをどのように通過するかです。 エージェント アーキテクチャはまさにその流れを大きく変えています。
今回は、新しいプロトコルの対応やセキュリティ機能の追加だけでは足りません。 分類が必要になります。
業界では長年にわたりトラフィックを分類してきましたが、その目的の多くは阻止することにありました。 私たちは皆、ボットをブロックし、脅威を除外し、悪意のあるペイロードにWAFポリシーを適用するために分類を利用しています。 それは基本的な対応です。 分類は主にセキュリティのために使われてきたのです。
AIがトラフィックとそれを処理するためのリソースのあり方を大きく変えています。 では、エージェントアーキテクチャはどうでしょうか？ 単にルールを変えるだけでなく、ゲームの本質自体を変えているのです。
AIの導入はこれまでの技術よりも急速に進んでおり、エージェントはすでに企業で活用されています。
すべてのPOSTがリクエストであり、目標であり、あるいはあなたのスタックを通じて推論しようとするAIエージェントかもしれません。 オーケストレーションを開始し、再帰的なワークフローを呼び出し、200トークンのプロンプトが2万トークンに膨らんでバックエンドを圧倒することもあります。 そのインフラストラクチャは？ いまだにすべてのPOSTを同じものとして扱っています。
そこに問題があります。
現代のトラフィックは単なる流れではなく、ひとつのタスクであり、仕事であり、意思決定そのものです。 ルーティングする前に正確に分類できるかどうかで、アプリの応答性や可用性、さらには安全性を確保できるかが決まります。
1. コネクションベースのルーティング（旧方式）
まずはおなじみのところから始めましょう。 レイヤー4（L4）ルーティングに基づく従来のトラフィック管理モデルは、いまだにインターネットの多くを支えています。 私たちはこの方法で基本的なパラメータを活用します。
- L4ルーティング： IPアドレスやポート番号などトランスポート層の情報をもとに判断します。
- パスベースのルーティング： 通常はアプリケーション層（レイヤー7）でURLパスを限定的に検査します。
- 均質プール： バックエンドサーバを専門機能に関係なく同等に扱います。
- ロードバランシング: サーバに負荷を集中させないよう接続を均等に分配します。
問題とは？ このモデルはリクエストの意味をほとんど理解できていません。 トラフィックを異なるニーズを持つ多様なタスクではなく、均一なパケットとして扱っています。 生成AIや組み込みの大規模言語モデル（LLM）、エージェントベースのフレームワークが広まる現代では、すべてのトラフィックが同じでないため、この視野の狭さは大きなリスクとなっています。
2つのHTTP POSTリクエストについて考えてみてください。
- ユーザープロフィールを更新するような、シンプルなCRUD（作成、読み取り、更新、削除）操作の一例です。
- あるものは、AI駆動の推論ループを用いて5つの下流ツールを呼び出し、データベースに書き込み、長時間稼働するテキスト要約タスクを開始するような複雑なマルチエージェントのワークフローを引き起こします。
インフラストラクチャがこれらのリクエストをすべて同じように扱い、同じルーティングルール、タイムアウト、バックエンドサーバを使用しているなら、問題を招いています。 リソースを大量に消費するAIタスクを軽量なデータベースクエリのように扱えば、ボトルネックや障害、パフォーマンスの低下が起こります。 現代のトラフィックには、より賢明な管理が必要です。
2. 分類に基づくリクエスト ルーティング（現状／移行期）
私たちは長年にわたりL7ルーティングを実践してきました。 パスを照合し、ペイロードを検査し、ヘッダーを確認してどのプールにトラフィックを送るか決めます。 それがコンテンツベースのルーティングです。 役に立ちます。 しかし、それはリクエストの内容は教えてくれても、なぜそのリクエストがあるのか理由は教えてくれません。
私たちが次に進むには、コンテキストに基づく分類が必要です。
- L7+で動作しながらも、単なるペイロード検査を超えています。
- トラフィックを意図、複雑さ、コストに応じて分類します。
- これは要約作業ですか、それともユーザーログインですか？
- 再帰的ですか？AI生成ですか？それともレイテンシーに敏感ですか？
- プールは容量だけでなく、機能によっても区別されます。
- リクエスト ルーティングの判断には、形式だけでなく目的を重視しています。
こうして私たちはトラフィックを「配信すべきコンテンツ」から「処理すべき作業」へと捉え方を変えます。 リクエストがどこへ行き、どのように優先され、またどのポリシーを適用するかを、リクエストの目的に応じてリアルタイムに判断できるのです。 これを意図ベースと呼びましょう。 これをコンテキスト認識と呼んでください。 呼び名は重要ではありません。変化は確実で、リクエストは単なる取引から進化しているのですから。 それは呼びかけになりつつあります。 トリガーです。 HTTPで包まれた目標なのです。
これらはすべてアプリケーション配信トップ10の#4（トラフィック制御）、#5（トラフィックステアリング）、および#6（レイテンシ管理）に直結しています。 文脈を理解できなければ、制御も誘導も最適化もできません。
3. タスクベースのルーティング（新技術）
特にエージェントシステムや再帰的プランナーが生産環境の一部となる中で、私たちはここに向かっています。 もはやコンテンツを単に提供するだけではありません。 私たちは目標を管理しています。 それがすべてを変えるのです。
このモデルでは、1つのリクエストが必ずしも1つのレスポンスに対応しません。 代わりに、小さなタスクの連続を開始することがあります。 そのタスクの中には並行して実行できるものもあります。 他のタスクは先に別の処理が完了するのを待ちます。 あなたは単にトラフィックをルーティングするだけでなく、作業の調整も担います。
パイプラインというよりも、ワークフローのように捉えてください。 目標達成につながるステップのリストをあなたが管理します。 すぐに実行できるステップもあれば、順番を待つ必要があるものもあります。 しかし、すべてを機能やポリシー、現在の負荷に合わせて調整し、監視し、適切に誘導しなければなりません。
その時点で、従来のルーティングの考え方は通用しなくなります。 リクエストごとに複数のステップや複数の担当者が関わる可能性があるなら、静的な経路や画一的なポリシーでは対応できません。 必要なのは、タスクの内容、必要な要素、そして最適な担当者や処理主体を理解し、単にパケットの送り先を決めるだけでないシステムです。
そこで重要なのは、分類なしでは何も進められないということです。 もしあなたのインフラストラクチャがリクエストの目的を理解できなければ、賢くルーティングすることはできません。 これは遠い未来の話ではなく、今まさに現実になりつつあります。 分類はリクエスト ルーティングから真の連係へとつなげる架け橋です。
なぜ重要なのか
はっきり言います。メタデータを増やしたり、より複雑なルーティングテーブルを作る話ではありません。 既に目の前にあるトラフィックの捉え方を変えることが重要なのです。
分類とは、再帰エージェントループを静的なアセット取得と同様に扱うことで、リクエストのルーティングやスケール調整、破損を起こす前にリクエストを理解するプロセスを指します。
もはやセキュリティだけの話ではありません。 リクエストに含まれる内容だけが重要なのではありません。 リクエストが何を意味し、何を実現しようとしていて、どのくらい負荷があり、その先に何を影響させるのかがポイントです。
だから、分類は単なる新興の潮流ではありません。 これは絶対に必要なことです。 エージェントやタスク、ワークフロー、リアルタイム オーケストレーションが例外ではなく一般的に広がっている今の世界に対応するために、トラフィック管理を進化させるための必須のステップなのです。
理解できなければ、管理はできません。 分類こそが、理解の出発点です。