TL;DR
OpenDracoは、LLMマルチエージェントのエージェント定義・プロンプト・ツール・モデル・通信トポロジをバージョン付きJSONで表し、LangGraph実行からSWE-bench評価・結果比較までを一つの流れにするOSS基盤です。APR向けの予備評価では、同程度の修復結果でも構成により時間・トークン費が大きく異なり、chainベースラインは77件中12件を解決しました。再構成の忠実度、単一モデル、逐次実行、少ない反復回数が主な限界です。
既存手法との違い
原論文は、Flowise、Langflow、Crew Studio、AutoGen Studio、LangGraph Studioなどの可視化・ワークフロー構築環境とOpenDracoを比較し、可視化や宣言的仕様、再利用部品自体は独自ではないとしています。違いは、SEタスク向けにバージョン付き仕様、実行、タスク評価、結果比較を統合し、APRではSWE-bench評価まで接続する点です。実験では同一のローカルモデルqwen3.5:9bで、chainベースラインと7つの再構成構成を比較しました。23件開発サブセットではchainとhyperagent_starが2件解決し、chainは時間39.78%減、トークン47.32%減でした。77件サブセットではchainが12/77を解決しています。ただし再構成は元システムの完全再現ではありません。
使える条件
対象はLLMベースMASのモデリング・実行・評価で、特に自動プログラム修正（APR）に適用されています。入力は、エージェント、プロンプト、ツール、モデル、パラメータ、通信トポロジを記述したJSON仕様と、SWE-bench形式のインスタンスです。実行はDockerによるローカル配備、Web UIまたはCLI、OllamaローカルまたはOpenAI互換クラウドAPIを前提とします。APR評価はSWE-bench harness（Docker、remote、local）を使い、合成5件、SWE-bench Lite開発23件、テスト77件（gold patchが600文字未満）で実施されています。実験はqwen3.5:9b、6GB VRAM、逐次実行です。翻訳ワークフローは概念実証です。他モデル、並列実行、SWE-bench以外のSEタスクの大規模適用は提示された本文からは確認できません。
限界と未検証の範囲
再構成したAPR構成は元システムのエージェント、プロンプト、ツール、通信構造を近似するもので、実行時挙動の完全再現ではありません。したがって構成間の差をトポロジだけに帰属できません。実験は6GB VRAMのGPUで全エージェントを逐次実行しており、並列化の利得は評価されていません。モデルはqwen3.5:9bのみで、他モデルへの一般化は未検証です。変動研究を除き各構成は原則1回実行で、実問題では3構成のみ、大規模サブセットではchainのみが評価されています。そのため構成差や変動性についての結論は限定的です。
解説
智也くん、このOpenDracoってやつ、名前からして強そうだけど何なの？
LLMマルチエージェントの構成を作って、実行して、評価して、また比べるためのOSS基盤。特にソフトウェア工学の実験向け。
構成を作るだけじゃなくて、評価と比較まで一つの流れにするってこと？
そう。背景には、エージェントの役割やプロンプト、ツール、モデル、通信トポロジを変えながら試すと、ベンチマーク管理や結果比較が散らかりやすいって問題がある。既存の可視化ツールだけだと、そこが分断されがち。
なるほど。既存のFlowiseとかLangflow、Crew Studio、AutoGen Studio、LangGraph Studioとは何が違うの？
可視化、宣言的JSON、再利用部品そのものは独自じゃない。OpenDracoの違いは、SEタスク向けにバージョン付き仕様、実行、タスク評価、結果比較を統合して、APRではSWE-bench評価までつなぐ点。
じゃあ、エージェントをノード、通信をエッジで表して、JSONで保存して、LangGraphで動かす感じ？
その通り。エージェント、プロンプト、ツール、モデル、パラメータ、通信トポロジをエクスポート可能なバージョン付きJSONにまとめて、LangGraphのワークフローに変換する。ローカルでもクラウドでもLLMを使える。
使うときの前提は？
Dockerでローカル配備して、Web UIかCLIから使う。推論はOllamaのローカルか、OpenAI互換APIのクラウド。APR評価はSWE-bench harnessを使う。仕様JSONとSWE-bench形式のインスタンスが入力って整理できる。
実験は何を比べたの？
論文の報告では、同一のローカルモデルqwen3.5:9bで、chainのベースラインと7つの再構成構成、合計8構成。トポロジはchain、star、tree、hybrid。評価は合成5件、SWE-bench Lite開発23件、テスト77件で、テスト側はgold patchが600文字未満のインスタンスに限定してる。
結果は？
合成5件ではopenhands_starが全5件を解決して、8構成の中で時間もトークンも最小。23件開発サブセットではchainとhyperagent_starがどちらも2件解決したけど、chainの方が時間39.78%減、トークン47.32%減だった。
同じ解決数でもコストが全然違うんだ。
そう。だから効果とコストを同じ環境で比べる意味がある。そのトレードオフを見て、大きい77件サブセットにはchainを選んで、12/77、15.58%を解決してる。
再現性の話もあったよね。温度の変動は？
temperature 0ではchainが合成の同じ3件を5回とも解決。temperature 1では解決数が2から4件にばらついて、実行時間とトークン使用量も変動が大きい。だから非ゼロ温度の構成は繰り返し評価が必要って示唆。
意義は、構成をゼロから実装し直さずに、同じ土台で再構成して、結果とコストを比べられることかな。
それに加えて、APR以外の概念実証として翻訳ワークフローもUIから作って、BLEUで評価してる。タスク固有のエージェント、トポロジ、ツール、評価器だけで、フレームワーク本体に変更は不要だった。
限界もちゃんとある？
ある。再構成したAPR構成は元システムのエージェント、プロンプト、ツール、通信構造を近似したもので、実行時挙動の完全再現じゃない。だから構成間の差をトポロジだけに帰属できない。
リソースとモデルの制約は？
6GB VRAMのGPUで全エージェントを逐次実行してるから、並列化の利得は評価されてない。モデルもqwen3.5:9bだけだから、他モデルへの一般化は未検証。
評価範囲も限られてる？
変動研究を除くと各構成は原則1回。実問題では3構成だけ、大きい77件サブセットはchainだけ。だから構成差や変動性についての結論は限定的。他モデルや並列実行、SWE-bench以外の大規模適用は提示された本文からは確認できない。
じゃあ亜美も『おやつ探索エージェント』をJSONで組んで、冷蔵庫ベンチで評価しちゃおうかな。
評価ハーネスが冷蔵庫なだけで、たぶん再現性は怪しいぞ。