DocETL 評:宣言的パイプラインと自動最適化の実効性
A system for agentic LLM-powered data processing and ETL
ひと目でわかる
- これは何？
- LLM による非構造データ処理を map/reduce 演算子と YAML で宣言し、MOAR による書き換え最適化を狙う UC Berkeley 発の MIT ライセンスツール。手書きの LLM 呼び出しと何が変わるのか、導入前に確認すべき点を整理する。
- 誰に向いている？
- 大量のチケットや文書に同じ種類の抽出・分類・要約を繰り返し適用し、そのパイプラインをコードとしてレビューしたいチームには向く。逆に、単発のプロンプト呼び出しや、LLM に依存しない決定的な変換が中心の処理には持ち込む理由が薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 10 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
手書きの LLM 呼び出しが壊れる場所
非構造データに対する LLM 処理は、最初の 1 本を書くのは簡単である。問題はその先にある。チケット 1 万件を分類し、カテゴリごとに要約し、失敗したレコードだけ再試行する、という一連の流れを自前で組むと、並列度、レート制限、リトライ、スキーマ検証、コスト集計がすべてアプリケーションコードに混ざる。プロンプトを 1 行変えたときに、どの出力が変わるのかも追いにくい。
DocETL が狙うのはこの部分である。README では「Without DocETL, you write each LLM call yourself, wire them together, and tune the result for accuracy, cost, and latency by hand.」と対比されている。つまり対象読者は、単発のチャットボットではなく、文書コレクションに対する反復的な処理を本番に載せようとしているエンジニアである。UC Berkeley の EPIC Data Lab と Data Systems and Foundations グループで作られ、VLDB 2025 の論文が参照されている。研究発のツールであり、商用 SaaS ではない。
map と reduce を自然言語で書くという設計
DocETL の中心は、処理を演算子の連鎖として宣言する点にある。README の Python API では docetl.read_json で入力を読み、pipeline.map で分類、pipeline.reduce でカテゴリ単位の要約、という流れを示している。map の prompt は Jinja 風のテンプレートで、"Classify this support ticket: {{ input.text }}" のようにレコードのフィールドを埋め込む。output には schema を渡し、category と priority が str であることを宣言する。
reduce は reduce_key="category" を取り、同じカテゴリのレコードをまとめて 1 つのプロンプトに流し込む。テンプレート内の {% for t in inputs %} は、グループ化された複数レコードを反復する構文である。ここが map との違いで、map は 1 レコード 1 呼び出し、reduce はグループ 1 呼び出しになる。スキーマはパイプライン全体で合成され、pipeline.schema() が {'category': 'str', 'summary': 'str'} を返すと README は示している。演算子は map, filter, reduce のほか、resolve, split, gather, extract がドキュメントの Operators ページに列挙されている。
YAML で書く場合と実行方法
Python を書かずに YAML で同じことを宣言できる。README の例では datasets に tickets というファイル型データセットを定義し、default_model に gpt-4o-mini を指定する。operations には name: classify, type: map, prompt, output.schema を並べる。pipeline.steps で input: tickets と operations: [classify] を結び、output にファイル出力先を書く。実行は docetl run pipeline.yaml の 1 コマンドである。
インストールは pip install docetl と、OPENAI_API_KEY などプロバイダのキーを環境変数に置くだけである。開発に参加する場合は git clone の後 make install、make tests-basic が案内されており、テストは OpenAI で 0.01 ドル未満と README に記載されている。これは README の記述であり、当方が実行して確認した数値ではない。レート制限は Python API 側で docetl.rate_limits に llm_call と llm_tokens のクォータを辞書で渡す形になっている。
MOAR による書き換えと、その不透明さ
DocETL の特徴として README が挙げるのは、パイプラインを自動で最適化する点である。モデルの差し替え、プロンプトの書き換え、演算子の分解、サブタスクのコード置換を通じて精度を上げコストを下げる、と説明されている。この最適化の名称が MOAR で、VLDB 2026 の論文 Multi-Objective Agentic Rewrites for Unstructured Data Processing に対応する。ドキュメント上は Optimization のページで扱われ、Python API から呼ぶ形が示されている。
ここは評価が分かれる。自動書き換えは、プロンプトを手で管理したくないチームには利点になる。一方で、書き換え後のパイプラインが元の意図とどう対応するのかは、生成物を読まないと分からない。精度とコストのトレードオフを自動で選ばせるということは、その選択基準をツールに委ねるということでもある。README の Python API 例では docetl.default_model = "gpt-4o-mini" のように明示指定する経路も用意されているため、最適化を有効にせず素直に実行する選択肢は残っている。
DocWrangler と Claude Code 経由の作成
パイプラインを書く補助が 2 つ用意されている。1 つは DocWrangler で、プロンプトを編集しながら結果をリアルタイムで確認するビジュアル環境である。docetl.org/playground で試すか、ローカルまたは Docker で動かす手順がドキュメントにある。UIST 2025 の論文と Best Paper Honorable Mention が README に記載されている。
もう 1 つは Claude Code 連携で、docetl install-skill を実行してタスクを説明するとパイプラインを組ませられる、と README は案内する。ChatGPT や Claude アプリを使う場合は docetl.org/llms-full.txt のプロンプトを貼る方法が示されている。生成された YAML をそのまま信頼するのではなく、スキーマとプロンプトを読んでから docetl run に渡す運用が現実的である。生成物の検証を省くと、誤ったスキーマのまま大量のレコードを処理してしまう。
向かない場面と、LangChain との違い
DocETL は非構造データに対する反復処理を前提にしている。決定的な変換、たとえば正規表現による整形や列の結合が中心の処理に LLM 演算子を混ぜると、コストと非決定性だけが増える。また、1 回だけの質問応答や、会話状態を持つエージェントの実装は、このツールの想定する形ではない。map と reduce の連鎖に落ちない処理は、素直に自前で書いたほうが読みやすい。
比較対象として LangChain が挙げられる。LangChain は LLM 呼び出し、ツール、メモリ、エージェントを部品として提供し、開発者がコードで組み立てる。DocETL は逆で、処理の流れを YAML または Python のメソッド連鎖として宣言し、並列化と最適化をフレームワーク側が担う。どちらが優れているという話ではなく、パイプラインの形が固定されている処理に向くかどうかの違いである。DocETL では演算子の種類があらかじめ決まっているため、その枠に収まる処理は短く書けるが、収まらない処理は演算子の外側に押し出される。
ライセンスと保守の見通し
ライセンスは MIT で、リポジトリのバッジにも明記されている。商用利用や改変の条件は MIT の条文に従う。ここでは法的助言はしないので、実際の利用条件は自組織の法務やコンプライアンス担当が確認する必要がある。
保守の観点では、直近のリリースが 0.3.0 (2026-06-17)、その前が 0.2.6 (2025-12-28)、0.2.5 (2025-08-09) であり、半年程度の間隔で版が上がっている。0.x 系であるため、マイナー更新で API や YAML の書き方が変わる可能性は残る。パイプラインを YAML でリポジトリに置き、バージョンを固定して docetl run を CI で回す形にしておくと、更新時の差分を追いやすい。コスト面では pipeline.total_cost が README の例に登場するため、実行ごとの支出を記録する経路は用意されている。
編集部の結論
大量のチケットや文書に同じ種類の抽出・分類・要約を繰り返し適用し、そのパイプラインをコードとしてレビューしたいチームには向く。逆に、単発のプロンプト呼び出しや、LLM に依存しない決定的な変換が中心の処理には持ち込む理由が薄い。導入前に確認すべきは、docetl install-skill で生成されるパイプラインが自分のスキーマを正しく扱うか、そして pipeline.total_cost が想定予算に収まるかである。
コミュニティノート