Alibaba Cloudは、Elastic Compute Service（ECS）の問い合わせを処理するAIエージェントから、繰り返し現れる案件の「計画」を外した。KDD 2026で発表した「DualLane」は、既知の定型案件を事前検証済みテンプレートへ流し、未知の案件に限ってLLMに解決手順を組み立てさせる。論文は、1年以上の本番稼働を経て、オフライン評価で96.5%の精度、オンラインで4.2秒の計画・実行時間中央値、7.1%のエージェント起因エラー率を報告している。
この設計が突いているのは、エージェントを賢くするほど運用が安定するとは限らないという問題だ。クラウド障害の対応では、選ぶツール、渡す引数、実行順序、結果の読み方のどこか一つが崩れるだけで、もっともらしい誤答が顧客へ返る。DualLaneはモデルの推論能力を全面に押し出さず、繰り返しが多い領域を決定的な処理へ戻すことで速度と正確さを稼ぐ。
定型案件はテンプレートへ、未知案件はLLMへ
サポートへの問い合わせは均等には現れない。接続できない、インスタンスが起動しない、設定値を確認したいといった反復性の高い案件が大量に届く一方、複数のサービスや障害が絡む事例は低頻度の長い裾をつくる。Alibaba Cloudの現行資料によれば、チケット窓口はBasicからEnterpriseまで全サポートプランに含まれる。ただし、論文が報告する導入先はECSの本番環境で、どの地域やプランまでDualLaneが応答するかは公開要旨から分からない。
The Registerによると、DualLaneは一つの問い合わせに高速経路と低速経路を並行して走らせる。高速経路が既知の定型案件だと判定すると、対応する実行テンプレートを選び、進行中の低速経路を止める。分類に時間をかけてからLLMを起動する構成ではないため、未知案件もルーティング待ちを挟まず計画へ入れる。定型案件では、低速経路を最大3,000トークンに達する前に止められる。
高速経路のテンプレートは、過去の回答文をそのまま貼り付けるマクロではない。必要な運用ツールと依存関係をあらかじめ検証した実行手順である。LLMが問い合わせごとにツール構成を再発明しないため、同じ種類の案件に同じ処理を適用できる。高速経路が短いのは、生成する文章が少ないからというより、計画探索そのものを省くからだ。
ただし、両経路を同時に起動する以上、高速経路の判定が終わるまでに低速経路が使った計算は残る。公開要旨には、高速経路が全問い合わせの何割を覆うか、キャンセルまでに何トークンを費やすかは記載されていない。節約効果を測るには、1件あたりの理論上限より、実トラフィックでの経路比率と投機実行分を見る必要がある。
計画と引数生成を分ける理由
The Registerが論文から引用した説明では、Alibaba Cloudのチームは従来のエージェントが誤る場所を四つに分けた。必要なツールを選べない。ツール名は合っていても、引数が欠けるか、名前や型を間違える。前段の実行結果から次の処理に必要な値を拾えない。そして、最後にツールの出力を読み違えるか、回答から要点を落とす。自然言語として滑らかな応答が返っても、この連鎖の正しさは保証されない。
低速経路は、タスクの分解と具体的な引数の生成を二段階に分ける。先に「何を、どの順序で調べるか」という依存グラフを作り、各ツールを呼ぶ段階で、それまでの結果から引数を埋める。たとえばインスタンスの状態を取得し、その結果に応じてネットワーク設定や監視情報を照合する場合、後段の呼び出しに必要な識別子や条件は前段が終わるまで確定しない。全工程の引数を最初に一括生成するより、値の受け渡しを局所化できる。
比較対象のReActは、LLMの推論とツール実行を交互に進める。途中結果へ柔軟に反応できる反面、独立して実行できる処理まで直列になりやすい。LLMCompilerは依存関係を持つタスクグラフを生成し、独立した呼び出しを並列化することでこの待ち時間を縮めた。DualLaneも複数ツールの依存関係を扱うが、高頻度案件では新しいグラフを生成する工程まで省いた。既知の手順は再計画せず、未知の手順だけを組み立てる。
三つの性能値を同じ物差しで読まない
96.5%、4.2秒、7.1%は、DualLaneの効果を別々の面から測っている。96.5%はオフライン・ベンチマークの精度であり、4.2秒は本番環境における計画から実行までの中央値だ。7.1%はオンラインでエージェントに起因したエラーの比率である。したがって、96.5%の裏側を3.5%の本番エラーと解釈したり、それを7.1%と矛盾する数字として扱ったりはできない。
エージェント起因という限定にも意味がある。クラウドの問い合わせは、サービス側の障害や顧客設定のほか、権限不足やネットワークなど複数の原因を含む。7.1%はチケット全体の未解決率ではなく、エージェントの計画や実行、回答生成に帰属した誤りを指す。総解決率や人への引き継ぎ率は、公開要旨からは分からない。
The Registerによると、低速経路が使う最大3,000トークンの内部コストは約0.001ドルで、Alibaba Cloudはトークン代を主要な動機としていない。金額が小さくても、ツール呼び出しを伴う計画は応答時間と誤りの機会を増やす。DualLaneの経済性はトークン単価より、誤答したチケットを人が調べ直す時間や、顧客が復旧を待つ時間に現れる。
もっとも、公開された数字だけでは経路ごとの寄与を分離できない。高速経路の適合率、低速経路だけの成功率、誤って定型と判断した割合、人間へ戻した割合がなければ、96.5%を他社のサポートエージェントへそのまま当てはめることはできない。結果はAlibaba Cloud自身のECS環境で得られ、著者11人も全員が同社に所属する。
学習するのはモデルより運用経路
The Registerによると、DualLaneは低速経路に残り続ける問い合わせをクラスタリングし、似た案件が繰り返されると高速経路への昇格候補にする。そこで自動的にテンプレートを有効化せず、人が内容を確認してから追加する。未知だった問題が反復可能な運用知識へ変わる一方、LLMの誤った計画をそのまま標準手順として固定することは避けられる。
この循環は、エージェントを「何でも都度考えるモデル」から、検証済み手順と例外処理を持つ運用ソフトウェアへ近づける。高頻度の処理をコンパイル済みの経路として実行し、長い裾だけをLLMで解釈する構成だ。モデルの更新を待たずに、現場で繰り返された成功手順を高速側へ移せる。
適用範囲は明確である。同種の問い合わせが集まり、ツールの入出力仕様が比較的安定し、正しい手順を人が検証できる業務ほど効く。案件の反復が少ない調査や、目的そのものが途中で変わる仕事では、テンプレートへ移せる割合が下がる。さらにECSのAPIや診断手順が変われば、過去に検証したテンプレートも更新しなければならない。
DualLaneの次の評価材料は、派手なモデル性能ではなく、高速経路が安全に覆える割合だ。誤振り分け率、テンプレートの改訂間隔、人への引き継ぎ後まで含めた解決時間が公開されれば、二経路設計がECS以外でも再現できるかを判断できる。LLMを多く使うことではなく、どこで使わないかを決める能力が、本番エージェントの成熟度を分け始めている。
