- LLMベースのマルチエージェント・ソフトウェア開発システムの実行トレースをSDLC段階にマッピングし、トークン消費が初期生成よりもコードレビューと検証に集中する構造を測定した研究
- ChatDevが実行した30件のソフトウェア開発タスクでは、コードレビュー段階が平均 59.4% のトークンを使用し、最大の消費区間であることを確認
- 全タスク平均のトークン構成は入力53.9%、出力24.4%、推論21.6%で、エージェント間の反復的なコンテキスト受け渡しが大きな communication tax を形成
- コーディング段階は出力トークン比率が58.0%と高い一方、ドキュメント化段階は入力トークン比率が80.2%と高く、開発段階ごとのトークン利用パターンが明確に分かれる
- コスト予測とワークフロー最適化のため、よりトークン効率の高いエージェント協調プロトコルと標準化された評価フレームワークが必要という結論
要旨
- LLMベースのマルチエージェント（LLM-MA）システムは、要件エンジニアリング、コード生成、テストといった複雑なソフトウェアエンジニアリング作業の自動化にますます適用されている
- 運用効率と資源消費が十分に理解されておらず、予測しにくいコストと環境影響が実運用導入を妨げる要因となっている
- ChatDevフレームワークがGPT-5 reasoning modelで実行した30件のソフトウェア開発タスクの実行トレースを分析し、内部段階を設計、コーディング、コード補完、コードレビュー、テスト、ドキュメント化にマッピング
- 予備的な結果では、反復的なコードレビュー段階が平均59.4%のトークンを占め、最大の消費区間だった
- 入力トークンは平均53.9%で一貫して最大比率を占め、エージェント協調における相当な非効率の可能性を示す実証的根拠となった
- エージェント型ソフトウェアエンジニアリングの主要コストは、初期コード生成ではなく、自動化された改善と検証の過程に集中している
- この方法論は、コスト予測、ワークフロー最適化、よりトークン効率の高いエージェント協調プロトコル研究に活用できる
序論
- 大規模ソフトウェアエンジニアリングでは、SDLC全体にわたる複雑な作業の自動化のために、LLMベースのマルチエージェントシステムを模索している
- LLM-MAフレームワークは、プロダクトマネージャー、アーキテクト、開発者、テスターといった人間チームの役割を専門化されたLLMエージェントでシミュレートし、設計・コーディング・検証作業を協調的に行う
- LLM-MAシステムは原理的に、作業をエージェント間で分担して自律性と堅牢性を高められる
- 先行研究では、LLM-MAシステムが発散的思考を促進し、推論と事実性を強化し、単一エージェントの能力を超える問題へ拡張できることが扱われている
- ソフトウェアエンジニアリングでは、要件からテストまでのエンドツーエンドのワークフローを統合的に自動化できる可能性がある
- AGENTTAXOフレームワークは、一般的なLLM-MAシステムのトークン分布を分析するための分類体系を提供し、エージェント間相互作用のオーバーヘッドを説明する「communication tax」の概念を導入した
- MAST失敗分類は、LLM-MAシステムの多くの問題が、個々のLLMの限界よりも、段階の反復や不完全な検証といったシステム設計・調整の問題に由来することを確認した
- 既存研究は一般的な文脈でのエージェント行動を分析してきたが、多段階のソフトウェアエンジニアリングワークフローに適用されたシステムの資源効率に関する知識の空白がある
- 「トークンはどこへ行くのか」という実用導入の中核的な問いには、ソフトウェアエンジニアリング領域でまだ十分な答えがない
- Tokenomicsは、LLM-MAシステムの運用効率と資源消費を研究するための用語である
- 分析は、ChatDevの内部段階を開発段階にマッピングしてトークン消費分布を調べる方法で進められる
- ChatDevは仮想ソフトウェア企業をシミュレートし、プログラマーやテスターなど複数のエージェント役割がマルチターン対話を通じてSDLCを完了する
- 30件の実行トレースからなるキュレーション済みデータセットと、完全な再現パッケージを提供
研究設計
-
目的と分析対象
- 目的は、LLM-MAシステムがエンドツーエンドのソフトウェア開発タスクを実行する際、トークン消費がどのように分布するかを実証的に調査すること
- 初期の分析対象はChatDev
- ChatDevの「chat chain」アーキテクチャは、設計 → コーディング → テストという明確な逐次的ウォーターフォールモデルを示しており、段階が明瞭でソフトウェア開発段階へのマッピングに適している
- ChatDevは人気があり、よく引用されるオープンソースフレームワークの1つである
-
データセットのキュレーション
- ChatDevを30件の異なるソフトウェア開発タスクで実行
- プロンプトはMAST研究で使用されたProgramDev Datasetから収集
- 選択されたプロンプトには、フィボナッチ数生成のような単純なアルゴリズムから、チェスゲームのようなより複雑なアプリケーションまで含まれる
- 推論トークン数がタスク複雑性の代理指標になり得るという最近の研究に基づき、多様性を確認
- 30件のタスクにおける推論トークン消費範囲は17,280から40,000までで、この範囲は研究に十分なタスク複雑性の多様性を示唆する
-
モデル選択
- すべてのエージェントの基盤モデルはGPT-5 reasoning model
- 選定基準は、モデルの人気と新しさ、エージェント型ユースケースへの適合性、自律エージェントへの期待に見合う強い推論能力
- 実験に使用したモデルバージョンは
gpt-5-2025-08-07 temperatureパラメータはこのモデルでサポートされていないため、デフォルト値1.0を使用- コンテキストウィンドウは400,000トークン、最大出力トークンは128,000トークン
- 知識カットオフは2024年9月30日
-
分析パイプライン
- トレース収集段階では、ChatDevを計測して30件の各タスクの全実行トレースをログとして記録
- 各LLM呼び出しのプロンプト、応答、入力・出力・推論トークン数を捕捉
- 段階マッピングは、ChatDevフレームワークの内部段階を普遍的な開発段階へ変換する中核的方法論
- この抽象化により一般化可能な分析が可能になり、他のソフトウェアエンジニアリングLLM-MAフレームワークにも拡張できる
- トークン集計はPythonスクリプトで実施
- 収集したトレースをパースし、30回の実行全体で開発段階ごとのトークン数を合算
- 入力、出力、推論トークンに細分化
-
ChatDev内部段階と開発段階のマッピング
- 設計段階は
DemandAnalysis、LanguageChooseに対応し、要件理解と高水準の技術決定に集中 - コーディング段階は
Codingに対応し、初期ソースコード作成に直接関与 - コード補完段階は
CodeCompleteに対応し、コーディング段階で残ったプレースホルダーや未完成コードファイルを完成させる - コードレビュー段階は
CodeReviewに対応し、プログラマーエージェントとコードレビューアエージェントの反復対話によってコードの検討と修正・改善を行う - テスト段階は
Testに対応し、実行可能性バグを見つけて修正するための動的システムテストに集中 - ドキュメント化段階は
EnvironmentDoc、Reflection、Manualに対応し、ユーザーマニュアルと必要な環境依存関係の文書を生成
- 設計段階は
研究結果と考察
-
研究課題
- 核心的な問いは、ソフトウェア開発タスクにおけるLLM-MAシステムのトークン消費パターンである
- エージェント型ソフトウェアエンジニアリングシステムのtokenomics理解は、実用的かつ持続可能な導入に重要
- 高いトークン使用量は、財務コスト、エネルギー消費、環境影響の増加に直接つながる
- SDLC内でトークンが消費される位置を特定すれば、コスト予測とワークフロー最適化に活用できる「コスト地図」を作成できる
- 分析は2つの軸で進める
- 設計、コーディングなど、マッピングされた開発段階ごとの総トークン分布
- 各段階内の入力、出力、推論トークン比率
-
発見1: コードレビュー段階がトークン消費を支配
- 開発プロセス全体のトークン使用は非常に不均一な分布を示す
- コードレビュー段階は30件の全タスク平均で59.4%のトークンを使用し、最大の消費区間だった
- コード補完段階は30件中6件のタスクで発生し、それらの実行で平均26.8%のトークンを消費
- ドキュメント化段階は平均20.1%、テスト段階は平均10.3%のトークンを消費
- テスト段階は30件中12件のタスクで発生
- 初期コーディングは平均8.6%、設計は平均2.4%と相対的に低コスト
- エージェント型ソフトウェアエンジニアリングの主要コストは、初期コード生成よりも反復的で対話的な改善・検証過程に集中している
- 図の
n値は、30件のタスクのうち特定段階が実行されたタスク数 - すべての段階が常に実行されるわけではなく、マルチエージェントシステム内のエージェントが、どの段階を実行するかを自律的に決定する
- 誤差棒は ±1 標準偏差で、各段階のトークン消費の変動性を示す
-
発見2: トークン消費は入力トークン中心
- コーディング段階を除くすべての段階で、入力トークンが出力および推論トークンを大きく上回るパターン
- タスクごとの全体平均トークン使用構成は、入力53.9%、出力24.4%、推論21.6%
- 入力トークンと出力トークンのおよそ2:1の比率は、先行研究の「communication tax」に対する強い実証的根拠
- エージェントが協調対話中に大きなコンテキストを繰り返し受け渡ししながらトークンを消費している
- 現在のエージェント協調プロトコルには、新しい出力生成よりもコンテキスト伝達にトークンの大半を使う非効率が存在
- communication tax は、対話型マルチエージェントアーキテクチャ固有の特性である可能性があり、今後さらに研究すべき対象
-
発見3: 開発段階ごとに異なる tokenomic profile
- 段階別トークン比率は、各ソフトウェアエンジニアリング活動ごとに固有のパターンを形成する
- コーディング段階は出力中心の例外的区間で、出力58.0%、入力6.9%
- コーディング段階の出力中心構造は、簡潔な設計仕様から長いソースコードを生成する作業特性と一致する
- コードレビューやドキュメント化のような検証・文書化段階は入力中心
- コードレビューの入力比率は51.4%
- ドキュメント化の入力比率は80.2%
- これらの段階では、既存コードを大きなコンテキストとして消費し、より小さな分析的出力を生成する
- 段階別トークンプロファイルは、エンジニアリング活動ごとのコスト地図として活用できる
- 実務者は、コスト予測とプロセス最適化の機会をより適切に特定できる
-
段階別トークン比率
- 設計段階の平均比率は、入力60.4%、出力3.6%、推論36.0%
- コーディング段階の平均比率は、入力6.9%、出力58.0%、推論35.1%
- コード補完段階の平均比率は、入力47.7%、出力41.7%、推論10.5%
- コードレビュー段階の平均比率は、入力51.4%、出力24.7%、推論23.9%
- テスト段階の平均比率は、入力60.8%、出力20.7%、推論18.4%
- ドキュメント化段階の平均比率は、入力80.2%、出力8.3%、推論11.5%
- タスク別全体平均比率は、入力53.9%、出力24.4%、推論21.6%
-
議論
- 予備的結果は、エージェント型ソフトウェア開発の初期的なコスト地図を提供する
- コードレビュー段階の大きなトークンコストは「対話コスト」と解釈できる
- このコストは、エージェントがコード全体のコンテキストを繰り返しやり取りしながらコードを改善するLLM-MAシステムの対話型アーキテクチャから直接生じる
- 現在の検証用エージェント協調プロトコルは、小さな修正しか必要ない作業でも膨大な資源を消費し得るため、非常に非効率である
- MAST分類の、検証失敗や段階反復に関する結果とも整合的である
- 高いトークン使用量は、エージェントシステムが内在する調整問題を力任せの対話で克服しようとしている症状である可能性がある
- 実務者は、エージェントベースのプロジェクトコストを必要な作業タイプに応じて見積もることができる
- 初期コーディング比重の大きいグリーンフィールドプロジェクトと、既存コードのリファクタリング・デバッグ中心のプロジェクトでは、異なるコスト構造を持つ
- 既存コードのリファクタリング・デバッグ中心のプロジェクトでは、高価で入力中心のコードレビューサイクルがコストを支配する
- コードレビュー段階の前に「human-in-the-loop」チェックポイントを統合すれば、高コストな反復ループを防ぎ、経済面・計算面で効率的な設計判断に活用できる
- 研究課題は、検証と改善のためのよりトークン効率の高い協調プロトコルを設計すること
- 単純な全文脈受け渡しを超える方式が必要
- 標準化され、包括的な評価フレームワークが必要
- このフレームワークは、ChatDevの階層的対話型ワークフローとMetaGPTのSOPベース組立ラインのような異なるLLM-MAアーキテクチャの効率をベンチマークし比較する共通基盤になり得る
- フレームワークごとの動作を普遍的なソフトウェアエンジニアリング活動へ翻訳する「Rosetta Stone」として機能し得る
妥当性への脅威と今後の課題
-
妥当性への脅威
- 分析は、単一のLLM-MAシステムであるChatDevと、単一のLLMであるGPT-5 Reasoning Modelに基づいている
- 観測されたトークン消費パターンは、他のLLM-MAアーキテクチャや、トークン効率が異なるLLMでは変わる可能性がある
- 30件のソフトウェア開発タスクは多様ではあるが、考え得るすべてのソフトウェア開発シナリオや複雑性を代表していない可能性がある
- キュレーション済みデータセットの規模は、ソフトウェアエンジニアリング特化エージェントトレースの公開大規模ベンチマーク不足から直接生じている
- データキュレーションは時間もコストもかかるプロセスである
- 一部の開発段階は、30件のタスクの中でも小さな部分集合でしか実行されない
- コード補完は
n=6、テストはn=12と、まれにしかトリガーされない - これら特定段階の tokenomic profile に関する結論は小標本に基づくため、代表性が低い可能性があり、一般化可能性に制約がある
- ChatDevの内部段階をソフトウェア開発段階にマッピングした方法は抽象化である
- これは標準化された評価フレームワークを作るための論理的かつ有用なマッピングだが、エージェント活動をマッピングする複数の可能な方法の1つにすぎない
-
結論と今後の課題
- エージェント型ソフトウェアエンジニアリングにおけるトークンコストは均等に分布せず、反復的で対話的なコードレビュー段階に圧倒的に集中している
- 「communication tax」を構成する入力トークンが全トークン使用量の大半を占め、今後の最適化の中核領域である
- 今後の作業の第一の課題は、より多くのタスクでデータセットを拡張し、一般化可能性を改善すること
- 第二の課題は、他のLLMへ分析を拡張し、モデルごとの効果を把握すること
- 第三の課題は、他のLLM-MAシステムへ分析を拡張し、アーキテクチャ差がtokenomicsに与える影響を比較すること
- 第四の課題は、トークン消費パターンと失敗モードの間の関係を調査すること
- 第五の課題は、ソフトウェアエンジニアリングエージェントの効率ベンチマークのための、堅牢で普遍的な開発段階マッピングフレームワークのさらなる開発と検証
1件のコメント
Hacker Newsのコメント
個人用にマルチエージェントシステムを作って使っている
問題を与えると、まず高速で安価なモデルが質問を投げ、その回答をもとに入力プロンプトを磨き込む
その後、問題をセクションごとに分けて最終ジャッジが結論を出したり、複数のエージェントが議論したあとでジャッジが要約したりする戦略を選ぶ
いちばん良い方法は私がall anglesと呼んでいるもので、複数の戦略を並列に走らせ、最後にメタジャッジが応答を統合する
最近追加した機能の中で最も便利なのは、各戦略間のばらつきを見られる画面だ
住まい探し、学校、家族の問題のような生活上の課題に使っている
どんな戦略を使っているのか、戦略ごとにコストがどう変わるのかも知りたい
サイバネティクス的に、決定的な検査と自動修正ライブラリを継続的に拡充して、プロンプト出力の安定性を保つやり方だ
そのライブラリで処理できない「問題」は、プロセスを操縦する人に見えるようにしている
1か月はGitHub Copilotを途切れなく十分に使えたのに、価格変更後の翌月は2日でトークンを使い切ってしまった
こうした急激な変化は、トークン価格が恣意的で、AI事業の資金が急速に尽きつつある兆候のように見える
推論の利益率が70%を超えるという噂もある
SpaceXを例にすると、ここ6か月で消費者向け製品の価格を全般的に上げたが、AlphabetとAnthropicが合わせて毎月20億ドル以上を払っているのだから、資金不足というわけではない
Microsoft/GitHubは他社製品を再包装する立場だったので、ここでは損をしたわけだ
一般に価格はいくつもの基礎要因に基づいて決まるもので、それ自体が恣意的という意味ではない
たとえばGitHubの幹部が乱数生成器でトークン価格を決めたなら、それが恣意的な価格設定だ
「入力トークンが平均53.9%で消費の最大比率を占める」という部分があるが、私の使用量では比率はだいたい10:1くらいだ
消費されるトークンの圧倒的大半が入力側で、エージェントがコード1行を直すために100万トークンを読むこともよくある
1:1に近かったり出力側の方が大きいなら、エージェントに問題があるか、コードベースが新しいか空っぽなのだと思う
キャッシュされていない100万トークンはかなり多く見える
モデルに関連コード部分を吐き出させる1回限りの「圧縮」段階を設け、その結果を多数のサブエージェント呼び出しにおけるキャッシュ済みプレフィックスとして使うこともできる
コーディングでエージェントを使うと、単体テストは何千件も書きたがるのに、動的にテストしようとする傾向は弱い
静的テストはlintや型検査のようなものだ
単体テスト以外の種類の動的テストを望むなら、計画やPRDの段階で要件として明示してみたのか気になる
彼らの利害が常にあなたの利害と一致するわけではない
この場合は、役に立たない作業に不必要な金を使わせたいということだ
「トークン」という婉曲表現も、もうやめた方がいい
動的テストがある程度敬遠される理由は、速度を落とし、予期しないところでソフトウェアを停止させ得るからだと思う
去年、トークン使用効率を最適化するために予算ガイダンス情報を提供していた論文を思い出した
[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...
これは航空会社の特典マイルに似ていて、企業の立場からすればベアメタルGPU時間を借りることに比べて利点がない
AI需要の大半がオンプレミスやオンデバイスのハードウェアとモデルで満たせるようになったとき、そうした運用コストをかける超巨大計算ファームとモデルが何の役に立つのか気になる
おそらく残る顧客は大きな政府くらいで、結局はAIカルテルが投じた何十億ドルもの金を納税者が負担することになるだろう
12月にこのテーマでSubstack記事を書いた: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...
以前はGoogleのような企業が、インフラをどれだけうまく最適化できるかを見てエンジニアを採用していた
そのうち企業は、エンジニアのAIトークン効率最適化能力を見るようになるかもしれない
開発者たちがより多くのトークンの使い道を見つける速度が、価格低下の速度と同じくらい速いかどうかは確信が持てない
トークンをインターネットのようなユーティリティ費用として扱い、エンジニア本人に払わせればいい
面白い余談として、新製品候補を検討する会議にいたのだが、順調に進んでいたところで、その製品にAIを追加したという画面が出てきた
当然AIは付いていて、とても無理やりねじ込んだ感じがした
その露骨さのひとつは、各クエリに何トークンかかったかを表示する列があったことだ
トークンコストは誰が払うのかと聞くとライセンスに含まれていると言われ、予算上限があるのか、それとも無制限なのかと聞くと、良い質問なので確認すると言われた
私が聞いたのは、たった今見せられた単純なデバイス関連クエリ1件で25万トークンを燃やしていたからだ
そのとき相手側の役員の1人が「なんでこれを顧客に見せているんだ？」と大声で言うのが聞こえて、私たちはかなり笑った
ここから得た教訓は、何にでもAIを追加するコストがまともに計算されておらず、実際のAI運用の真のコストはなおさら反映されていないということだ
望もうが望むまいが、AIが付いたものはすべて高くなるだろう
Tokenomicsはすでに暗号資産経済を説明する言葉なのに、AIで使うトークンが別種だからといって、なぜわざわざその言葉を再定義しようとするのかわからない
前の流行は忘れて、これもすぐ古くなるのだから、遅すぎる前に乗っておかないといけない
「Web 3.0」も暗号資産界隈がWeb3を暗号資産中心のものにする前から存在していた
だから何が問題なのかわからない
用語は異なる文脈で繰り返し再利用されるものだ
しかも大半の人はもう暗号資産から離れているので、混乱が生じる可能性も大きくない