OpenAI の O1、Devin、またはカスタムのエンタープライズ推論エージェントなど、高度な AI エージェントを最近使用したことがある場合は、おそらく目にしたことがあるでしょう。 正確に60秒間回転する糸車。 空白の画面が続きます。 恐ろしいメッセージが続きます: 「504 Gateway Timeout」。
コードのバグではありません。サーバークラッシュではありません。これは、私たちが構築したインターネット (Web 2.0) と、構築中のインターネットのワークロード (Agentic AI) の間の根本的なアーキテクチャ上の非互換性です。
現代の Web は タイムアウト危機 に直面しており、これを修正するには、Web が「高速」であるという中心的な前提を打ち破る必要があります。
古い契約: REST と 30 秒ルール
過去 20 年間、Web は 応答性 という 1 つのことのために最適化されてきました。 主要なパラダイムは REST (Representational State Transfer) です。クライアントとサーバー間のコントラクトは同期的でシンプルです。
- リクエスト: クライアントはデータを要求します (例: 「ユーザー プロファイルを取得してください」)。
- プロセス: サーバーがデータを取得します (データベース クエリ: ~50ms)。
- 応答: サーバーはデータを送り返します。
ステップ 2 に 30 秒 (一部のクラウドでは 60 秒) を超えると、インフラストラクチャがパニックになります。ロードバランサー (NGINX、AWS ALB、Cloudflare) は、サーバーが停止している、「ゾンビ化」している、または無限ループに陥っていると想定します。システムを保護するために接続を切断します。 これはバグではなく機能でした。これにより、ハングしたプロセスが RAM と CPU スレッドを使い果たすのを防ぎました。 「フェイルファスト」の規律を強制した。
Agentic AI の登場: 時間を粉砕するワークロード
古典的に、コンピューターは高速でした。クエリに 5 分かかった場合、SQL に問題があります。 しかし、Agentic AI は単に「クエリを実行する」だけではありません。それは「考える」ことです。
「O1」クラス推論モデルまたはエージェント ワークフローは、データを検索するだけではありません。それ:
- プロンプトを分解してプランを作成します。
- Web を 閲覧します (10 サイトをスクレイピング)。
- コードを書き込みます。
- サンドボックスで コードを実行します。
- エラー ログを 分析します。
- コードを リファクタリングします。
- 反復します。
このプロセスはミリ秒単位では測定されません。分単位で測定されます。時には何時間も。 5 分間の思考プロセスを 30 秒の REST パイプに強制的に入れると、パイプが破裂します。クライアント (ブラウザ) はまだ待機していますが、仲介者 (ロード バランサ) はすでに電話を切っています。エージェントは 4 分後に作業を終了しますが、話し相手がいません。その結果、タスクが失われ、ユーザーはイライラし、コンピューティング クレジットが無駄になります。
アーキテクチャの変化: 同期からイベント駆動へ
Agentic 時代を生き抜くために、SOAP/XML の消滅以来最も重要なアーキテクチャの変化が見られます。 同期リクエスト/レスポンス から 非同期イベント駆動型アーキテクチャ (EDA) に移行しています。
「チケット」システム
新しいパラダイムでは、AI に「ウェブサイトを構築して」と依頼しても、サーバーは応答しません。
- リクエスト: クライアントはプロンプトを送信します。
- Ack: サーバーは すぐに (HTTP 202 Accepted): 「わかりました。チケット ID #1234 です。現在取り組んでいます。さようなら。」
- 切断: HTTP 接続が閉じます。ブラウザは他のことを自由に行うことができます。
- 処理中: エージェントはバックグラウンドで動作します (分/時間)。
- 通知: 完了すると、サーバーは シグナル を送信します。
シグナリング プロトコル: ブラウザはどのようにしてそれを認識するのでしょうか?
ステップ 5 を処理するためのプロトコル戦争が発生しています。
- ポーリング: ブラウザは 5 秒ごとに「もう終わりましたか?」と尋ねます。 (単純ですが、リソースを大量に消費します)。
- Webhook: 完了すると、サーバーは特定の URL を呼び出します (サーバー間では優れていますが、ブラウザーでは役に立ちません)。
- サーバー送信イベント (SSE): サーバーが更新 (「スキャン中…」、「コードの書き込み中…」、「完了」) をプッシュする一方向の永続チャネル。これはストリーミング LLM トークンの標準になりつつあります。
- WebSocket: 完全な双方向通信。ほとんどのテキスト生成には過剰ですが、リアルタイムの音声/ビデオ エージェントには必要です。
永続的な実行が爆発する
タイムアウト危機により、Temporal、Ingest、Hatchet などの Durable Execution プラットフォームの爆発的な増加が加速しました。
標準の Python/ノード スクリプトでは、エージェントがタスクを開始してから 4 分が経過している間にサーバーが再起動またはクラッシュすると、その 4 分間の作業が失われます。 AIには「記憶喪失」がある。 永続的な実行エンジンでは、永続的なログが導入されます。すべてのステップで関数の「状態」を保存します。
- ステップ 1: 計画が生成されました (保存されました)。
- ステップ 2: Google をスクレイピング (保存)。
- クラッシュ (サーバーの再起動)。
- リカバリ: サーバーが起動し、ステップ 2 が完了したことを確認し、ステップ 3 からすぐに再開します。
AI は 非決定的であり、高価であるため、これは非常に重要です。ポッドが再起動したからといって、$2.00 の API 呼び出しを再実行するわけにはいきません。永続的な実行により、エージェントが開始されると、必ず終了することが保証されます。
未来: A2A (エージェント間)
私たちは、インターネット トラフィックの大部分が 人間からサーバー ではなく、エージェント間 (A2A) である世界に急速に近づいています。 これらのエージェントは、「スピナーの読み込み」や「知覚される待ち時間」を気にしません。彼らは信頼性と正確さを重視します。
エージェントが長期間にわたって相互に発見して会話できるようにするために特別に設計された新しいプロトコル (MCP - モデル コンテキスト プロトコル など) が誕生しつつあります。 「インスタントウェブ」の時代は終わりつつあります。 「思慮深いウェブ」が始まります。タイムアウトをやめればいいだけです。
出典 (4)
- temporal.io Durable Execution
- platform.openai.com OpenAI: Optimizing Latency
- aws.amazon.com Asynchronous Patterns
- inngest.com Event-Driven Systems
🦋 Bluesky での議論
Bluesky で議論する