6月29日、Toward Data ScienceがDatabookのエンジニアによる「Tail Control: The Counterintuitive Engineering of Reliable Agentic Workflows」と題した記事を公開した。100万件以上の本番LLMコールに基づく実運用データをもとに、エージェントワークフローの信頼性を「速度」ではなく「分散の制御」によって高める逆説的なアプローチを詳説している。
「平均」を最適化しても顧客は救われない
LLMを使ったワークフローを社内で運用するうちは、失敗しても再試行すれば済む。しかしそれを顧客向けAPIやMCPサーバーの裏側に置いた瞬間、ルールが変わる。顧客のプロセスはこちらの結果に依存しており、「正しい答えが時間内に届いたか」だけが問われる。
本記事はDatabookでの実運用——100万件以上の本番LLMコール——に基づいており、その数字が示すことは明快だ。平均レイテンシを改善しても、ロングテールがある限り顧客体験は改善しない。
「アジェンティックワークフロー」と「推論エージェント」の違い
本題に入る前に、記事が対象とするシステムの定義を押さえておきたい。記事が扱うのはアジェンティックワークフロー——プロセスフローが既知で、LLMステップを内包し、決定論的オーケストレーターが動かすもの——であり、推論エージェント（実行時に自分で次のアクションを決める、いわゆるReActパターンのようなもの）ではない。
同じタスクに対してワークフローは推論エージェントより速い。計画が既知なのでステップを並列実行でき、コストも時間も大幅に削減できる。ただし失敗のパターンが異なり、対処法も異なる。推論エージェントの問題は「何をすべきか」であり、ワークフローの問題は「わかっていることを、品質を保ちながら時間内に届けること」だ。
顧客向けワークフローが抱える3つの予算
顧客向けワークフローには、同時にクリアしなければならない3つのリソース予算がある。
- 時間: ゲートウェイタイムアウト（多くの場合1〜3分）が存在し、超過すると接続が切断される。再開はなく、顧客は最初からやり直す。
- コスト: 顧客がすでに支払っている価格があるため、各実行は「利益が出る」形で完了しなければならない。
- トークン/レート: TPM（1分あたりトークン数）の上限を複数顧客で共有しており、顧客の呼び出しが集中するタイミングで上限に達しやすい。
そしてこれら3つの予算の下には、どれだけ削っても下回れない品質の床（quality floor）がある。速くて安くても、答えが間違っていれば失敗だ。
3つの予算は相互に引っ張り合う。遅いステップを待てば時間予算を消費する。並列で別のコールを投げればコストとTPMを消費する。精度を上げるためにより強力なモデルに切り替えれば、今度は遅くなる。
核心的テーゼ：信頼性は速度ではなく分散の問題
品質が基準を満たした後、信頼性のある配信は速度ではなく分散の問題だ。
実運用データが示す事実は直感に反する。典型的な長出力コール（出力600トークン以上）は約12秒で返ってくる。しかし100回に1回は30秒、場合によっては60秒以上かかる——処理量とは無関係に。
さらに重要なのは、プロンプトサイズと出力サイズの両方を固定（つまり「仕事量」を一定に）しても、p99はp50の2〜7倍になるという点だ。遅さはワークロードの大きさではなく、キューイングや一時的な輻輳などのトランジェントな要因によるものだ。このような確率的な遅延の特性は、Speculative Decodingなどレイテンシ改善を目的とした研究でも広く認識されている前提でもある。
複数ステップのワークフローになると問題はさらに深刻になる。正確さの複利は広く知られているが、同じ複利がクロックにも働く。各ステップがそれぞれ独立にテールに入る確率を持ち、それが積み重なる。ステップを多く連鎖させるほど、どれか1つがデッドラインを超える確率が上がる。
また、ワークフローが予算超過するとき、原因は「複数ステップがそれぞれ少し遅い」ことではほぼない。1つのステップがテールに入り、残りは正常に動いているというパターンがほとんどだ。チェーン全体の超過は、各ステップの合計ではなく、最大値に支配される。
逆説的な解法：早めに切り捨て、並列で競わせる
ここが記事の最も面白いポイントだ。まだ失敗していないコールを意図的に打ち切り、同時に別のコールを走らせる。
あるステップがテールに入った場合、待ち続けることは最もコストが高く、最もリターンが少ない行動だ。20〜30秒で打ち切り、並列で新しいコールを走らせ、先に返ってきた方を採用する。この「複数リクエストを同時に走らせて最速の結果を採用する」考え方は、Hedged requests（ヘッジリクエスト）としてGoogleのテールレイテンシ研究でも有効性が示されている手法と同系統だ。
数学的な根拠は明快だ。1回のコールがテールに入る確率を q とすると、2回同時に走らせて両方ともテールに入る確率は q² になる。
実運用データでの効果：
- 中央値: 12秒 → 約10秒（ほぼ変わらない）
- p99: 約60秒 → 約25秒（半分以下）
- 標準偏差: 6秒 → 3秒（半減）
「予測可能な完了時間」を買うコストは余分なトークンだ。これは本物のトレードオフだが、顧客向けAPIでは合理的な選択になる。
まとめ
社内システムでは「遅いステップをそのまま待つ」が合理的だが、顧客向けAPIではその戦略が通用しない。タイムアウトは容赦なく切断し、遅延して届いた正しい答えは顧客の目には「失敗」と映る。Databookの実運用データが示す処方箋は、速度の最適化ではなく分散の制御——具体的には、まだ失敗していないコールを早期に打ち切り、並列コールで競わせてテールを潰すことだ。
自社のエージェントワークフローに同様の課題を感じているなら、まず自システムのp99とp50の比率を計測するところから始めるとよいだろう。その数値が2倍を超えていれば、この手法が効く可能性が高い。
詳細はTail Control: The Counterintuitive Engineering of Reliable Agentic Workflowsを参照していただきたい。
