ステートレス性を超えて：LLMが従来のシステム設計に挑戦する理由

20 年間、スケーラブルなウェブアーキテクチャの設計図は驚くほど一貫していました：状態はデータベースにあり、計算はステートレスです。このモデルでは、ロードバランサーの背後にある任意のサーバーが任意のリクエストを処理でき、データベースが絶対的な単一の真実の情報源として機能します。この設計により、アプリケーションサーバーを使い捨てのコモディティとして扱うことで、インターネットは数十億人のユーザーにスケールしました。

しかし、大規模言語モデル（LLM）と自律エージェントの登場により、この長年の前提が崩れ始めています。「ステートレス計算」モデルは従来の CRUD アプリケーションには機能しますが、エージェント AI の要件にはますます不適切になっています。

ステートレスアーキテクチャの三つの破綻

エージェントワークフローは、従来のステートレスなリクエスト‑レスポンスサイクルでは効率的に処理できない、3 つの具体的な課題をもたらします：

長時間実行作業：トピックの調査やレポート作成といった複雑なタスクを実行する AI エージェントは、完了までに 10 分かかることがあります。これは HTTP の意味での「リクエスト」ではなく、長時間実行される非同期プロセスです。
ステートフル計算：エージェントは蓄積されたコンテキスト、会話の過去のターンの記憶、複数のツール呼び出しの結果に依存します。この状態は単なる「データベース状態」（ユーザープロファイルなど）ではなく、実行中プロセスのアクティブなメモリです。
双方向インタラクション：ユーザーは単に最終的な回答だけでなく、エージェントが「考える」様子を見たり、進行を中断したり、リアルタイムで軌道を変更したりしたいと考えます。これにより、クエリからステートレス API へのやり取りが、実行中プロセスとのライブ会話へと変わります。

ルーティング問題：ポーリングだけでは不十分な理由

この問題の実行部分に対処するため、業界は「耐久実行」フレームワーク（Temporal、Inngest、Restate など）に注目しています。これらのツールはプロセスを回復力のあるものにし、サーバーがクラッシュした場合でもワークフローが中断した地点から再開できるようにします。

しかし、耐久実行は プロセス の問題を解決するだけで、インタラクション の問題は解決しません。標準的なロードバランサーや HTTP では特定の実行中プロセスへリクエストをルーティングできないため、開発者はしばしばポーリングに戻ります。クライアントはデータベースエンドポイントをポーリングして、耐久プロセスが更新を書き込んだかどうかを確認します。

ソース資料で指摘されているように、これは実質的にデータベースをメッセージバスとして扱うことになり、根本的なルーティング欠陥への回避策です。ポーリングはレイテンシを導入し、データベース負荷を増大させ、ストリーミングデータに対するユーザー体験を悪化させます。

新たなルーティングプリミティブの模索

ポーリングを超えるためには、サーバーやデータベースではなくプロセスを指し示すことができるルーティングプリミティブが必要です。目標は、特定のサーバーレプリカや IP アドレスを知らなくても、「ワークフロー X の出力を現在生成している者へこのメッセージを届けて」 と言えることです。

WebSocket が解決策でない理由

WebSocket は双方向通信を提供しますが、接続であり アドレス ではありません。WebSocket 接続が切れた場合（たとえばユーザーがトンネルに入ったため）アドレスは失われます。外部のルーティングメカニズムなしに、正確に同じプロセス状態へ再接続するネイティブな方法はありません。

Pub/Sub チャネルのケース

より堅牢な解決策は、名前付き pub/sub チャネルの使用です。このモデルでは、クライアントもサーバープロセスもアドレスではなく、トランスポートチャネル がアドレスとなります。クライアントとサーバーは共に名前付きチャネルに接続します。接続が切れた場合、クライアントは単に同じ名前付きチャネルに再接続し、データストリームを再開します。

耐久実行と耐久トランスポート（pub/sub）を組み合わせることで、開発者はワークフローが回復力を持ち、通信がシームレスなエージェントアプリケーションを構築でき、回復力のためにすべてのトークンをデータベースを経由させる必要がなくなります。

反論と業界の見解

ステートフルルーティングへのシフトには批判者もいます。一部のエンジニアは、これらの「問題」は新しいものではないと主張します。長時間ジョブ、Webhook、ジョブ ID は何十年も非同期作業を処理するために使われてきました。批判者は、データベースの「単一の真実の情報源」は実証済みのパターンであり、システム設計の核であり続けるべきだと指摘します。

他方では、すでにこれらの課題を解決している既存技術が指摘されています：

Virtual Actors：アクターモデル（Elixir や Azure Orleans で見られる）は、特定のステートフルエンティティを指し示す方法を提供します。
Durable Objects：Cloudflare の Durable Objects は、単一の場所で状態と計算を調整する方法を提供します。
Session Pinning：クライアントが特定のサーバーに接続し続けることを保証する従来の手法です。

なぜ LLM がこの課題を緊急にするのか

これらのパターンが以前から存在したとしても、なぜ今重要になるのでしょうか？違いは LLM の性質にあります：それらは 非決定的 で 高コスト です。

従来のシステムでは、接続が切れた場合でもリクエストを再試行すれば同じ結果が得られることが多いです。LLM では、リクエストを再試行すると異なる回答が生成され、さらに多くのトークンが消費される可能性があります。ネットワークの一瞬の揺らぎだけで、高価な計算を無駄にしたり、複雑で非決定的な思考チェーンの状態を失ったりする余裕はありません。

LLM がこれらの問題を発明したわけではありませんが、問題を増幅させ、20 年前のステートレスウェブアーキテクチャのトレードオフをこれまで以上に痛みと可視性の高いものにしています。