何が起きたか
DataFlow-Harnessは、LLMエージェントの「出力の形」を変える枠組みです。Pythonスクリプトをゼロから書かせる代わりに、あらかじめ登録された処理部品（オペレータ）を組み合わせ、有向非巡回グラフ（DAG）として段階的にパイプラインを構築させます。生成物は使い捨てではなく、あとから人間がGUI上で点検・修正できる永続的な資産として残ります。ライセンスはApache 2.0で、ソースコードはGitHubで公開されています。
第一著者のRunming He氏はVentureBeatに対し「最初の壁はたいていPythonを書くことではない」と述べています。実際に導入済みのオペレータを使い、本番のスキーマに合わせ、登録済みデータセットやモデルサービスを正しく参照し、工程間の依存関係を保ち、他のエンジニアが読んで直せる成果物を残す——難しいのはそちらだ、という指摘です。研究チームはこれを「NL2Pipelineギャップ」と名付けました。自然言語で要件を語るユーザーと、構造化された永続的な資産を要求する本番環境との断絶です。
なぜ重要か：10.9ポイントの落差
この論文の中心的な発見は、性能ランキングではなく一つの落差にあります。コードベースを文脈に与えたClaude Codeは、自由記述スクリプトなら94.2%の成功率を出しました。ところが同じエージェントに「このプラットフォームの部品だけでネイティブなワークフローグラフを作れ」と制約をかけると、83.3%まで落ちます。つまり、統治可能なパイプラインを作る仕事は、使い捨てコードを書く仕事より約10.9ポイント分ぶん難しい。ここが多くの現場の実感と一致します。デモは動くのに本番に載らない、という現象の正体です。
4層構成と「行動空間の制約」
DataFlow-Harnessは4つの層で構成されます。真実の唯一の源としてDAGを保持するData Pipeline Backend、対話と視覚編集を担うDataFlow-WebUI、オペレータ登録簿と現在のワークフロー状態にAIがアクセスするMCP Tools Layer、そしてドメイン知識をMarkdownで注入するDataFlow-Skillsです。
設計思想はHe氏の「エージェントの行動空間を変える」という言葉に集約されます。任意のコードを吐かせるのではなく、MCP経由で実在するオペレータ一覧と現在の状態を取得させ、「オペレータを追加する」「辺をつなぐ」といった型付きの差分変更だけを適用させる。システム側は受理前に、登録済みデータセット・オペレータ・モデルサービスの参照、フィールドの流れ、一部の不正なパラメータ、構造的妥当性を静的に検査します。ハルシネーションで存在しない依存関係を呼ぶ余地を、そもそも構造で潰しているわけです。
効果が最も出たのは、暗黙のドメイン知識に依存する複雑なタスクでした。Skillsを外したMCP-onlyのベースラインは、構造的に正しいDAGは作れても、オペレータの説明文だけからタスク固有の手順を推論しきれませんでした。教科書からVQAデータを抽出する課題（PDF解析、レイアウト復元、OCR、図表抽出、マルチモーダル理解、長距離のQ&A対応付けを含む）では精度97.2%・カバレッジ87.3%を達成し、数学データの整備タスクでは、生成されたデータで学習したモデルがAIME24・AIME25でvanilla版パイプラインのデータを上回りました。
現実的な制約
汎用ツールではありません。He氏自身が「Airflow、Prefect、Sparkのターンキー型プラグインではない」と明言しており、自社の登録簿・メタデータ・実行インタフェースをエージェントの制御層に接続するアダプタを自前で作る必要があります。さらに、オペレータ登録簿の維持、スキーマの定義、繰り返される業務手順のSkills化という「境界線を引く投資」が前提になります。小さな単発変換や、信頼できるメタデータを出せないレガシー環境には勧めない、とも述べています。構造検査は不合理な接続を防ぎますが、あくまでエンジニアリングの制御層であり、コンプライアンス方針や監査ログ、人間の承認の代替にはなりません。
💼 事業会社視点：これは自社にどう効くか
経営目線で読むべきは、成功率93.3%より1タスク0.261ドル・レイテンシ半減のほうです。AIエージェントのコストは「賢さ」ではなく「行動空間の広さ」で決まる、という原則がここで数字になりました。自由に探索させるほど試行錯誤のトークンが燃える。部品と型を先に定義するほど安く速く正確になる。これはデータ基盤に限らず、社内のあらゆるエージェント導入の設計原則です。
日本の事業会社が今動くべきは、LLMの選定ではなく**自社業務の「オペレータ化」**です。ECなら在庫連携・レビュー審査・商品説明生成、SaaSならログ正規化とRAG用データ整備、受託開発なら顧客ごとのETL定型処理。これらを再利用可能な部品として登録簿に並べ、暗黙知になっている手順をMarkdownで明文化しておく——DataFlow-Skillsの発想はそのまま横展開できます。逆に言えば、スキーマもメタデータも整理されていない企業では、どのエージェントを入れても83.3%側の世界から抜け出せません。
受託開発・SIerにとっては商機と脅威が同時に来ます。単発スクリプトの内製代行は価値が消えますが、「顧客の既存資産をエージェントが安全に触れる制御層に整備する」アダプタ構築は新しい受注領域になります。Apache 2.0で全公開されている以上、検証を止める理由はありません。CTO・事業責任者は、PoCの前に「自社の登録簿は何か」を1枚で描かせるところから始めるべきです。