DATAGEN を導入前に読む: 8つのエージェントと LangGraph 状態グラフの実際

DATAGEN が埋めようとしている穴は仮説の前段にある

データ分析の自動化ツールは、渡された問いに対してコードを書き、グラフを描くところまでは比較的素直に作れる。難しいのはその手前で、そもそも何を検証すべきかを決める部分だ。DATAGEN は README の Main Components で hypothesis_agent を最初に挙げており、Workflow の手順1も仮説生成である。つまり分析パイプラインの起点を「ユーザーが立てた問い」ではなく「エージェントが立てた仮説」に置いている。

対象読者は、CSV を手元に持っていて、次にどの切り口で見るべきかを考えるのに時間を取られている人である。README の usage 例では user_input に datapath と「Use machine learning to perform data analysis and write complete graphical reports」という一文を書くだけで、具体的な分析軸は指定していない。仮説立案をモデルに委ねる前提の設計だと言える。逆に、検証したい仮説が既に固まっている人にとっては、この最初のステップは省きたい工程になる。

LangGraph の状態グラフと人間が挟まる分岐点

Workflow の記述は、仮説生成、人間による選択(継続か再生成か)、処理、品質レビュー、必要に応じた修正という5段階である。README はこれを LangGraph による state graph として実装していると説明している。注目したいのは2番目の「人間による選択」がグラフのノードとして明示されている点で、仮説を自動で採用せず、いったん停止してユーザーの判断を待つ。完全自動のパイプラインではなく、人間が要所で介入する前提の構成である。

3番目の処理段階には data analysis、visualization、search、report writing がまとめて含まれる。これを担うのが code_agent、visualization_agent、searcher_agent、report_agent で、process_agent が全体を監督し、quality_review_agent がレビューし、note_agent が過程を記録する。8つのエージェントが直列に並ぶのではなく、process_agent の監督下で役割分担する形だ。note_agent については README が Smart Memory Management の項目で「State-of-the-art Note Taker agent」と表現しているが、コンテキスト保持の具体的な実装、たとえば何を要約し何を捨てるかといった方針は README からは読み取れない。ここは設計の意図が文章量に対して説明不足な部分である。

agent_models.yaml でエージェントごとに provider を混ぜられる

設定の中心は CONFIG_DIRECTORY 配下の agent_models.yaml である。README の例では hypothesis_agent に openai の gpt-5-nano、note_agent に google の gemini-2.5-pro、code_agent に anthropic の claude-haiku-4-5 を割り当てており、1つのワークフローの中で複数ベンダーを混在させられる。provider として例示されているのは openai、google、anthropic、ollama、groq である。ollama が含まれるため、少なくとも一部のエージェントはローカルモデルに寄せる構成が想定されていると読める。

各エージェントには model と temperature を指定する。temperature の範囲は 0.0 から 2.0 と明記されている。役割ごとに温度を変える、たとえばコード生成は低め、仮説生成は高めにするといった調整が設定ファイルの編集だけで完結する。README は CONFIG_DIRECTORY の既定値を config/ とし、ローカル開発では config_local を使うことで Git の追跡を避けられると説明している。環境ごとに設定フォルダを差し替える運用が前提だ。

.env 側の必須項目は WORKING_DIRECTORY、CONDA_ENV、CHROMEDRIVER_PATH の3つで、API キー類はすべて optional と記載されている。ただし FIRECRAWL_API_KEY については「If this key is missing, query capabilities may be reduced」と注記があり、省略時の検索能力が落ちることを README 自身が認めている。

起動手順と、キーを省略したときに何が起きるか

手順は README に明示されている。リポジトリを clone し、conda create -n datagen python=3.10 で環境を作り、pip install -r requirements.txt で依存を入れ、.env Example を .env にリネームして値を埋める。その後 data ディレクトリに CSV を置き、main.py の main() 関数内の user_input を編集して python main.py を実行する。Python は 3.10 以上が要件である。

user_input の書式は datapath と指示文を並べる形で、README の例は datapath:YourDataName.csv に続けて分析方法と出力形式を1行で書いている。ここで指定した内容がそのまま process_agent に渡るのか、hypothesis_agent の入力として解釈されるのかは README からは特定できない。

キーの扱いは機能の縮退に直結する。OPENAI_API_KEY、ANTHROPIC_API_KEY、GOOGLE_API_KEY はいずれも optional とされているが、agent_models.yaml で provider に openai を指定しておきながらキーを空にすれば、そのエージェントは動かない。optional という表記は「キーがなくてもシステム全体は起動する」という意味であって「どの provider を選んでもキー不要」という意味ではない。設定ファイルと .env は必ず突き合わせて確認する必要がある。

CHROMEDRIVER_PATH は required であり、README の例では ./chromedriver-linux64/chromedriver を指している。ブラウザ自動化を伴う処理が必須経路に含まれていると読める。TAVILY_API_KEY と GITHUB_TOKEN は MCP 設定の項目で optional とされており、Web 検索と GitHub 連携の MCP サーバーに対応する。CRW_API_KEY と CRW_API_URL は fastCRW 用で、既定は https://fastcrw.com/api、自前ホストなら http://localhost:3000 のように上書きする。LANGCHAIN_TRACING_V2 と LANGCHAIN_PROJECT を設定すれば処理のモニタリングができると README は説明している。

ブラウザ依存とベンダー依存という2つの重り

最も見落としやすい制約は ChromeDriver である。必須項目に含まれている以上、ヘッドレス環境やコンテナで動かす場合は Chrome 本体とドライバのバージョンを揃えて用意する必要がある。README はこの点の導入手順を説明していない。環境構築でつまずく箇所になりやすい。

2つ目はモデル API への依存である。エージェントごとに provider を選べる柔軟性は、裏返せば複数ベンダーの障害とレート制限を同時に受ける構成でもある。8つのエージェントが1回の実行で何度モデルを呼ぶかは README からは分からないが、仮説の再生成を選べばその分だけ呼び出しが増える。コスト見積もりは実行ログを取ってからでないと立てられない。

3つ目は、この種のツールに共通する検証の問題である。生成された仮説やレポートの正しさを誰が保証するのかについて、README は quality_review_agent の存在を示すのみで、その判定基準や限界には触れていない。品質レビューもまた言語モデルによる判定である以上、誤りを誤りと認識できない可能性は残る。研究用途で使うなら、出力は下書きとして扱い、主張の根拠は人手で確認する前提で運用することになる。

汎用の LangChain エージェント自作との違い

比較対象として素直なのは、LangChain と LangGraph を使って同じような分析エージェントを自分で組む方法である。違いは役割の分割が最初から固定されている点にある。DATAGEN では hypothesis、process、visualization、code、searcher、report、quality_review、note の8つが所与で、ユーザーが差し替えられるのは agent_models.yaml の provider と model、temperature に限られる。エージェントの数を減らす、順序を変えるといった構造変更は、設定ファイルの編集では完結しない。

自作の場合、構造は自由だが、状態管理、途中での人間の介入、エージェント間の受け渡しをすべて自分で設計する必要がある。DATAGEN はその雛形を提供する代わりに、想定された進め方から外れる使い方には向かない。分析の型が固まっていて、モデルだけを差し替えて試したい人には設定ファイル方式が効く。逆に、分析の進め方そのものを自分で制御したい人には、8エージェント構成は邪魔になる。

もう1つの違いは MCP への対応である。README はファイルシステム MCP サーバーが WORKING_DIRECTORY を共用すること、Tavily による Web 検索と GitHub 連携の MCP サーバーに対応することを記載している。ツール連携をプロトコル側に寄せている分、検索や外部データ取得の拡張は設定の追加で済む可能性がある。ただし個々の MCP サーバーの導入手順は README には書かれていない。

MIT ライセンスと保守コストの読み方

ライセンスは MIT である。商用利用を含めて比較的制約が少ない条件だが、これは DATAGEN 本体のコードに対する条件であって、呼び出し先のモデル API や Firecrawl、Tavily といった外部サービスの利用条件はそれぞれ別に確認する必要がある。ライセンス文書の解釈はここでは扱わない。

保守の観点で効いてくるのは、依存の広さである。requirements.txt の中身は README に列挙されていないため、LangChain と LangGraph のバージョンがどの程度固定されているかは分からない。この2つは更新の頻度が高く、API の変更がエージェント実装に波及しやすい。導入を検討するなら、まず requirements.txt を開いてバージョン指定の有無を確認するのが現実的な最初の一歩になる。

もう1つ確認したいのは、CONFIG_DIRECTORY を分けた運用が実際に機能するかである。README は config_local を .gitignore 済みと説明しており、開発と本番で設定を分ける想定が読み取れる。agent_models.yaml、agents/、mcp.yaml の3つがこのディレクトリ基準で解決される。設定を増やしたときに追跡対象とそうでないものが混ざりやすいので、ディレクトリ構成は導入初期に決めておく価値がある。

編集部の結論

向いているのは、手元に CSV があり、仮説からレポートまでの流れを自分の API キーで回したい個人研究者や小規模チームである。向かないのは、外部 API キーを一切出せない環境や、ChromeDriver を用意できない CI 専用の環境である。導入前に確認すべきは、agent_models.yaml で各エージェントに割り当てる provider と model の組み合わせが自分の契約範囲に収まるか、そして FIRECRAWL_API_KEY を省略した場合に searcher_agent の検索がどこまで縮退するかである。

公式情報源

1. Issues
2. License: MIT
3. README
4. zi-yue-1129/DATAGEN on GitHub