11月10日、InfoQが「Batch Intelligence at Scale: Cost-Efficient Multi-Agent LLM Workflows with Built-In Resilience」と題した講演録を公開した。Walmart Global TechのシニアソフトウェアエンジニアであるAditya Mulik氏によるQCon講演を収録したもので、4,700店舗規模でマルチエージェントLLMによる夜間在庫予測を本番展開した際の設計判断と、スケールでしか顕在化しなかった失敗から得た知見が詳しく語られている。
4,700店舗に「AIの推薦」を毎朝届ける
Mulik氏が手がけたのは、4,700以上の米国内店舗を対象にした在庫予測の自動化だ。対象は生鮮食品（ロティサリーチキン、鮮肉など）。賞味期限が短い商品は、過剰在庫なら廃棄、欠品なら機会損失と、どちらに転んでもコストが跳ね上がる。
従来、Walmartは過去1〜2年の販売データを使った後ろ向き機械学習モデルで需要予測を行っていた。これは感謝祭などの季節イベントには有効だが、「嵐が来て水の需要が急増する」といった突発事象には対応できない。
そこで設計したのが、リアルタイムコンテキストを取り込む4段階のマルチエージェント逐次ワークフローだ。マルチエージェントLLMワークフローとは、複数のLLMエージェントがそれぞれ異なる役割を担い、出力を順次受け渡しながら最終結果を生成するアーキテクチャを指す。
- コンテキスト収集エージェント — BigQueryなど複数データソースから部門ごとのメタデータを取得する
- 過去データ統合エージェント — データエンジニアリングパイプラインが用意した過去売上データと上記コンテキストを統合する
- グラウンディングエージェント — 天気APIや販売イベント情報など外部データを参照し予測を補正する
- ディレクティブ生成エージェント — 自然言語で最終推薦を生成する（例：「週末に向けてリンゴの在庫を15%増やせ」）
店舗マネージャーは毎朝開店前にこの推薦を受け取り、承認または上書きできる。人間がファイナルチェックポイントに立つ設計で、現場でしか把握できないローカル情報（実際に棚を見た感触など）を最終判断に織り込む余地を残した。
パイロットは完璧、本番は4種類の失敗
10〜15店舗のパイロットは好評だった。しかし4,700店舗への全面展開で、スケールでしか起きない4つの障害が顕在化した。
失敗1：ハルシネーションとスキーマ違反
最初の問題は出力が曖昧だったことだ。実際に出た推薦の例：
「週末に向けて、売れ行きの良い青果カテゴリの在庫を15%程度増やすことを検討してはいかがでしょう」
どの商品を？どのSKUを？——情報が抜けており、店舗マネージャーは自分で確認しなければならなかった。
対策として構造化出力を強制するJSONスキーマを導入した。SKU・品名・部門・調整量をすべて型付きフィールドとして定義し、曖昧さを排除した。OpenAIのStructured Outputsをはじめ、主要なLLM APIがJSON出力の強制をサポートしており、こうした用途に活用されている。
失敗2：セマンティックエラー（スキーマを通過した誤り）
より厄介だったのがこちらだ。JSON構造は正しいが、「Honeycrisp Apple」がauto_parts部門に紐づいて出力されるというケースが発生した。複数部門をまたいで同じSKU番号が存在したために、データ取り込み層でマッピングが混線したのだ。
スキーマバリデーションはこれを検出できない。解決策としてMCPツールコールによるグラウンディングを追加した。MCP（Model Context Protocol）とは、エージェントがリアルタイムで外部データソースを参照するためのオープンプロトコルであり、Anthropicが策定したものだ。各エージェントの出力を正規カタログと照合し、部門とSKUの整合性を確認する工程を挟むことで対処した。
失敗3：推論結果の消失
夜間バッチ処理中、ネットワーク断やDBへの書き込みタイムアウトによって、直前のエージェントが生成した出力が消えるケースが発生した。再試行の仕組みがなければ、その店舗分の推薦は丸ごと欠落する。
対策は永続ストレージへのチェックポイント保存と自動リトライの組み込みだ。エージェントが処理結果を逐次保存し、失敗時は最後のチェックポイントから再開できるようにした。分散バッチ処理における耐障害性設計は、Apache Sparkのチェックポイント機構など従来の大規模データ処理でも長く議論されてきたテーマであり、LLMワークフローでも同様の原則が適用される。
失敗4：コスト爆発
4,700店舗 × 数百万SKUの推論を毎晩回すと、LLM APIコストが予想外の水準に達した。対策としてバッチAPI（リアルタイム推論より低コストで処理できる非同期API）の活用と、エージェントごとのモデルサイズ最適化（すべてに大型モデルを使わない）を実施した。OpenAI Batch APIやAnthropic Message Batches APIはいずれも同期APIに比べてコストを大幅に削減できるとしており、大規模バッチ推論での活用が進んでいる。
設計の要点
Mulik氏がまとめた知見は明快だ。
- スキーマ強制だけでは不十分。セマンティックな整合性チェックをグラウンディングで別途行う必要がある
- 障害は必ず起きる前提で設計する。チェックポイントとリトライを最初から組み込む
- 人間のオーバーライドはフォールバックではなく機能として位置づける
- モデルは目的に応じてサイズを使い分け、コストを制御する
小規模パイロットで動いたアーキテクチャが、スケールで壊れる——これはLLMを実運用に投入するあらゆるチームが直面する課題だ。本講演はその具体的な失敗と対処を、極端なスケールの実例で示している点で参考になる。マルチエージェントLLMの本番運用に関心のある読者には、InfoQが公開している関連講演「Scaling Agentic AI Systems」も合わせて参照することをすすめる。
詳細はBatch Intelligence at Scale: Cost-Efficient Multi-Agent LLM Workflows with Built-In Resilienceを参照していただきたい。
