AI-Papers
- 自由記述のスクリプトではなく型付きの増分変更でDAGを組ませ、後から編集できるパイプラインを成果物として残す設計です
- 12タスクのデータ処理ベンチマークで成功率93.3%、既存のClaude Code比でコスト72.5%削減、遅延49.9%削減を記録しました
- MCP層が利用可能な処理部品と現在の状態を常に提示し、検証エンジンが実行前にDAG構造とスキーマ整合を点検します
研究の背景
大規模言語モデル（Large Language Model、LLM）の学習では、生データの整形、不要データのフィルタリング、合成データの生成といった一連の処理が最終的な品質を大きく左右します。この作業をコードエージェント（自然言語の指示からコードを書いて実行するAI）に任せる試みが、ここ数年で急速に広がってきました。
ところが現状のコードエージェントは、指示を受けるたびに使い捨てのスクリプトを出力する傾向があります。一度は動いても、後から一部の処理だけ差し替えたい、担当者が中身を目視で確認したい、別の案件で再利用したいといった場面では扱いにくいのが実情です。
論文はこの断絶をNL2Pipelineギャップと呼びます。自然言語の指示と、継続的に使えて編集可能な成果物との間に隔たりがある、という問題提起です。エージェントの基本的な設計思想についてはAIエージェントとは？仕組み・設計パターン・マルチエージェントまでわかりやすく解説もあわせてご覧ください。
提案手法
DataFlow-Harnessは、エージェントにコードを自由に書かせるのをやめ、プラットフォームが理解できるDAG（有向非巡回グラフ、処理が一方向に流れて循環しない図）を組み立てさせます。エージェントが行えるのは、処理部品を追加または削除する、パラメータを更新する、部品同士をつなぐ辺を張る、といった型付きの増分変更だけに限定されています。
この制約によって、生成物は毎回同じ形式のパイプラインになります。人間が後から特定のノードだけ差し替えたり、パラメータを微調整したりできるようになる点が、使い捨てスクリプトとの決定的な違いです。
構成要素は4つあります。DataFlow-Skillsは構築の手順書にあたり、スキーマの推定、処理部品の選択、パラメータ設定という推奨順序を示す手続き的な指針と、どの部品とどの部品を組み合わせてよいかという制約の知識を持ちます。
MCP層は、実際に利用できる処理部品の一覧と、現時点のパイプラインの状態をエージェントに提示し続けます。存在しない関数を呼ぶ、いま何がつながっているか見失うといった典型的な失敗を、参照可能な情報を常に手元に置くことで抑える仕組みです。
検証エンジンは変更のたびに2点を点検します。1つは更新後のパイプラインがDAGのままか、つまり循環が生まれていないか。もう1つは各処理部品の出力フィールドが、下流の部品が求める入力形式と噛み合っているかです。実行してから壊れていたと気づく手戻りを、事前の検査で減らします。
対話とGUIの同期
DataFlow-WebUIは、会話による指示と画面上でのDAG編集を同じパイプライン表現に対して行えるようにしたインターフェースです。エージェントに口頭で指示した結果がそのまま図として現れ、逆に人が図を手で編集した内容もエージェント側の認識に反映されます。
データ整備の現場では、大枠はAIに作らせて細部は人が直す、という進め方が現実的です。どちらか一方でしか編集できない仕組みだと、片方の変更が失われてしまいます。両者が同じ表現を共有する設計は、そうした運用上の摩擦を減らす狙いがあります。
実験結果
評価には、実務でよくある6つの場面を2段階の難易度に分けた計12タスクのベンチマークが使われました。内訳は、QA生成（基本版とフィルタ付き）、レビュー管理（感情分析とポリシー適用）、長文処理（要約と文章からQAへの変換）、複数項目の採点（観点別採点の有無）、スキーマの正規化（項目名の変更と入れ子構造の平坦化）、品質フィルタ（文字数基準とLLMによる意味的判定）です。
比較対象は、素のClaude Codeと、事前に文脈情報を与えたContext-Aware版の2つです。システム間の差だけを見るため、使用モデルはClaude Opus 4.7に固定されています。
構成 | 成功率 | コスト | 遅延 |
|---|---|---|---|
Vanilla Claude Code | 91.7% | 0.950ドル | 190.7秒 |
Context-Aware Claude Code | 94.2% | 0.456ドル | 115.9秒 |
DataFlow-Harness | 93.3% | 0.261ドル | 95.5秒 |
DataFlow-Harnessは素のClaude Codeに対してコストを72.5%、遅延を49.9%削減しました。成功率が最も高いのはContext-Aware版ですが、その差は0.9ポイントにとどまり、コストは42.8%低く抑えられています。
最高精度を単独で更新したというより、実用に足る成功率を保ちながら費用と待ち時間を大きく下げた、という結果の読み方が妥当でしょう。処理部品の一覧と現在の状態をあらかじめ渡すことで、エージェントが手探りで試行錯誤する回数が減り、消費トークンと実行時間が縮んだと考えられます。
残された課題
著者自身が挙げている制約は少なくありません。評価が単一のモデル系統に限られていること、ベンチマークがこのプラットフォーム固有の設計になっていること、各構成要素を個別に外した比較が完全ではないこと、統計的な信頼区間が示されていないことなどです。
また、下流での有用性については複数回の試行ではなく2件の事例研究にとどまっています。パイプラインの保存や再利用、来歴の追跡、複数人での同時編集、失敗からの復旧といった運用面の価値は、今後の直接的な評価に委ねられています。
まとめと今後の展望
DataFlow-Harnessが示したのは、エージェントの自由度をあえて下げることで、実行結果だけでなく編集可能な成果物を手に入れられるという方向性です。生成されたものが人の手に渡って初めて価値を持つ業務では、この考え方が広く応用できそうです。
MCPを通じて実行環境の状態をエージェントに開示し続ける設計も、他分野のツール連携に移しやすい実例といえます。データ整備に限らず、既存のGUIツールを持つ領域でエージェントをどう組み込むかを考えるうえで、参考になる構成です。
