LLMアプリの「落ちたら最初から」を無くす設計案──AgentRが提案するステートフル・アーキテクチャ

LLMを使った業務アプリを自分で組んだことがある人なら、「セッションの途中で落ちたら最初からやり直し」という経験に覚えがあるはずだ。多段階の処理・途中経過の保存・失敗時のリトライ・使用量の監査といった要件は、単発のプロンプト→レスポンスのラッパーでは扱いきれない。この課題に正面から取り組んだ論文が、2026年8月15日にarXivで公開された「AgentR」だ（arXiv:2608.15264）。本記事はPDF全文を読んで書いている。

著者はRiya Samanta氏(インドTechno India University、筆頭著者)・Bidyut Saha氏(独立研究者)・Soumya Kanti Ghosh氏(インド工科大学カラグプル校)・Rajkumar Buyya氏(メルボルン大学CLOUDS研究所)の4名。BuyyaはクラウドコンピューティングとGrid/Cloud分散システム分野で長年知られる研究者で、共著者に名を連ねている。

• 多くのLLMアプリは「状態を持たないプロンプト応答ラッパー」または「セッション限定の会話システム」として実装されており、中断・失敗後の復旧や監査が難しいという問題意識から出発している
• AgentRは、非同期ワーカー（BullMQ／Redis）とPostgreSQLによる永続化を組み合わせ、明示的な処理状態遷移・指数バックオフ付きリトライ・孤児ジョブ検出・トークンコストのACIDロギングを備えたアーキテクチャを提案
• 文献レビュー業務を題材にしたプロトタイプでの計測では、LLM段階のジョブ完了率99.2%、並列採点によって逐次実行比で最大4.3倍のウォールクロック高速化が報告されている

何が問題として設定されているか

論文のアブストラクトはこう書いている。

Many LLM applications are still implemented as stateless prompt-response wrappers or session-bounded conversational systems, which makes them difficult to recover, audit, and reproduce after interruption or failure.

（多くのLLMアプリケーションは今なお、状態を持たないプロンプト応答ラッパー、またはセッション限定の対話システムとして実装されており、中断や失敗の後にそれを復旧・監査・再現することを困難にしている）

これは特別に目新しい指摘ではない。だが「研究意図・生成クエリ・候補論文の評価・ギャップ分析を、永続的なワークフロー成果物として表現する」という具体的な設計に落とし込み、実プロトタイプの計測値まで出している点が、この論文の中身になる。

設計の骨格

論文が挙げる設計要素は以下の通りだ。

• 非同期実行：BullMQ（Redisベースのジョブキュー）でワーカーを並列実行し、PostgreSQLを永続ストアとして使う
• 明示的な処理状態遷移：各段階（意図分解・クエリ生成・論文採点など）が明示的な状態を持つ
• リトライと孤児ジョブ検出：指数バックオフ付きの再試行、実行が止まったまま残ったジョブの検出機構
• クレジット意識の事前チェック：実行前に利用可能なクレジット・予算を確認する仕組み
• ACIDなトークンコストロギング：トークン消費とコストの記録をACID特性を保った形で残す
• 価格のType-2 slowly changing記録：料金体系が変わっても過去の計算に使った単価を再現できるよう、価格変更履歴を保持する設計

最後の「Type-2 slowly changing」はデータウェアハウス設計で使われる用語で、レコードを上書きせず、変更履歴そのものを新しい行として追加していく方式を指す。LLMのAPI料金が頻繁に改定される現状（当サイトも料金早見表で繰り返し確認している通り）を踏まえると、コスト計算の再現性を担保する実務的な工夫だと読める。

計測された数字

プロトタイプは文献レビュー（研究意図の分解→検索クエリ生成→候補論文の評価→ギャップ分析）を題材に実装され、実運用相当のテレメトリで評価されている。論文が報告する数字はこうだ。

• LLM段階のジョブ完了率：99.2%
• 各段階の平均レイテンシ：意図分解9.0秒、クエリ生成18.9秒、論文採点25.4秒
• 並列採点によるウォールクロック高速化：逐次実行比で最大4.3倍
• 1プロジェクトあたりの予想コスト：GPT-4o料金で0.04〜0.38ドル(結論部分に明記)

論文自身が「これは予備的な概念実証（preliminary proof-of-concept）」と位置づけており、大規模な本番運用での検証結果ではない点は明記されている。実装規模についても論文のTable 2に具体的な数値がある。

パイプライン自体も、現時点で実装済みなのは「意図分解→クエリ生成→論文採点」の3段階のみで、自動的な論文取得・複数論文をまたいだ統合分析といった追加段階は「今後の計画」だと本文に明記されている。つまり記事タイトルの「文献レビュー」システムとして見ると、まだ一部の工程しか実装されていない。

手元でリポジトリを確認した。ライセンスは完全なオープンソースではない

論文にはプロトタイプ実装へのリンク（github.com/RiyaSamanta/AgentR-public）が記載されている。自分でこのリポジトリのメタデータをGitHub APIで確認したところ、TypeScript製で、作成日時と最終プッシュ日時がともに2026年6月22日、スター数は0だった。継続的にメンテナンスされている実運用プロダクトというより、論文用に一度まとめて公開された研究プロトタイプという位置づけだと見るのが妥当だ。

リポジトリのLICENSEファイルを直接確認すると、MITやApache 2.0のような一般的なオープンソースライセンスではなく、**Business Source License 1.1（BSL 1.1）**だった。開発・評価・学術研究・個人利用・教育目的での利用は許可されており、本番利用も可能だが、「ライセンサーのSaaS製品と競合するサービスの提供」は明示的に禁止されている。ライセンスがMIT Licenseへ自動的に切り替わる「Change Date」は2030年6月22日と設定されている。つまり論文の付随コードとして無条件に自由に使えるわけではなく、競合サービスとしての商用利用には制限がかかる設計だと分かった。

著者ら自身が挙げる「今後の課題」

論文の結論部分(Conclusion)には「著者は利益相反なし、特定の資金提供は受けていない」という開示があり、本文執筆にあたって「ChatGPTを文章の推敲に使用したが、実験データ・評価結果・システムテレメトリ・図表・技術的主張の生成には使用していない」という生成AI利用の開示もある。Future Work節には、著者ら自身が認める3つの限界が明記されている。

• 大規模運用での挙動は未検証:数百件の同時進行プロジェクト、100件超の論文を含む大規模プロジェクト、長期運用時のキュー待機時間・メモリ圧迫・DBコネクションプール枯渇などは、今回の評価には含まれていない
• クレジット管理はプロジェクト単位までで、LLM呼び出し1件ごとの元帳(ledger)はまだ無い:個々のLLM呼び出しをクレジット控除・モデル呼び出し・ワークフロー段階・成果物に紐付ける仕組みは今後の課題としている
• Redis自体の状態喪失からの完全復旧(Strategy B)は未実装:現在の実装はRedisレベルのリトライ(ワーカークラッシュや一時的なAPI障害への対応、Strategy A)が中心で、Redisのキュー状態そのものが失われた場合に、永続化されたDB状態からペイロードを再構築して完全復旧する仕組みは、まだ実装されていない

「Recovery-Aware（復旧を意識した）」という論文タイトルの主張と照らすと、この3つ目の限界――Redis自体が壊れた場合の完全復旧が未実装――は特に留意すべき点だと考えられる。

論文本文は読んだが、コードは動かしていない

本記事はarXivのPDF全文とGitHubリポジトリのメタデータ・LICENSEファイルを情報源としているが、リポジトリのコードを実際に手元で動かしての追試、査読の有無についての独立した確認は行っていない。上記の数字（99.2%・4.3倍・0.04〜0.38ドルなど）はすべて論文本文に記載された値をそのまま転記したものであり、この記事の執筆にあたって独自の実験は行っていない。

関連記事: AIエージェントとは / MCPとは / Claude・GPT・Gemini API料金の読み方

感想・指摘はコメント欄へ。