easy-dataset: ドメイン文書からLLM用データセットを組み立てるデスクトップアプリ
A powerful tool for creating datasets for LLM fine-tuning 、RAG and Eval
ひと目でわかる
- これは何？
- PDFやDOCXを取り込み、分割、質問生成、回答生成、書き出しまでをUIで通すツール。向いているのは自社文書からSFT/RAG用データを作りたいチームで、パイプラインをコードで管理したいチームには向かない。
- 誰に向いている？
- 導入を検討すべきなのは、社内のPDFやDOCXを素材にSFT用QAやRAG評価セットを短期間で作りたいが、PythonでETLを書く余力は割きたくないチームだ。逆に、生成ロジックをGitで差分管理しCIで回したいチームや、データを外部のマネージドサービスに預けられない規制下のチームには向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 137 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のどの作業を置き換えるのか
LLMのファインチューニングやRAGの評価セットを作るとき、実際に時間を食うのは学習ではなく前処理だ。PDFをテキストに落とし、見出し構造を保ちながらチャンクに割り、各チャンクから質問を作り、回答を付け、フォーマットを揃えて書き出す。この一連の作業はどのプロジェクトでもほぼ同じなのに、毎回スクリプトを書き直すことになる。easy-dataset はこの区間をブラウザUIのアプリとしてまとめたもので、README は「convert domain-specific documents in various formats into high-quality structured datasets」と説明している。想定読者は、Pythonのデータ処理に明るくないドメイン専門家や、少量のデータセットを何度も作り直す評価担当者だ。逆に、既にAirflowやdbtでパイプラインを組んでいるチームにとっては、UIで完結する設計そのものが制約になる。
文書がQAになるまでの流れ
READMEの機能一覧を素直に読むと、処理は一方向のパイプラインとして整理されている。入口はPDF、Markdown、DOCX、TXT、EPUBで、ここを「Intelligent Document Processing」がテキスト化する。次に分割で、Markdown構造、再帰セパレータ、固定長、コード対応チャンクという複数のアルゴリズムが用意され、UI上で分割位置を目視で調整できるとされている。分割された各セグメントから質問を生成し、質問テンプレートとバッチ生成で件数を増やし、LLM APIで回答とChain of Thoughtを付ける。このとき「Domain Label Tree」が文書構造から分野ラベルを自動で作り、タグ付けを行う。最後にデータクリーニングを通して書き出す。単発QAだけでなく、マルチターン対話、画像QA、そして文書をアップロードせずトピックから直接データを作る「Data Distillation」という経路もある。1.7.0以降は評価用データセットの生成とJudge Modelによる自動採点、二重盲検のArena比較まで同じアプリ内に入った。生成と評価が同一UIに同居するのは設計上の利点で、データを作った直後にその品質を測れる。
起動方法と設定の勘所
READMEが案内する入口は2つある。ひとつは配布されているデスクトップクライアントで、WindowsのSetup.exe、macOSのIntel/Apple Silicon、Linux向けのビルドがreleasesから取得できる。もうひとつはソースからの起動で、リポジトリはJavaScriptで書かれており、Next.js系の構成と推測されるが、READMEの抜粋にはnpm installやnpm run devの行が含まれていないため、正確なコマンドはリポジトリのpackage.jsonのscriptsを確認する必要がある。設定面で重要なのはモデル接続だ。OpenAI形式のAPIに準拠していれば接続でき、OpenAI、MiniMax、Ollama、Zhipu AI、Alibaba Bailian、OpenRouterが例として挙げられている。ローカルモデルをOllamaで動かせる点は、文書を外部に送りたくない場合の実用的な逃げ道になる。PDF解析や画像QAにはGeminiやClaudeなどのビジョンモデルが使われると明記されており、テキスト生成用とビジョン用で別々のプロバイダを設定する前提で考えるとよい。プロンプトはプロジェクト単位で全テンプレートを差し替えられる。
書き出し形式と周辺ツールへの接続
エクスポートはAlpaca、ShareGPT、Multilingual-Thinkingの3形式で、ファイルはJSONまたはJSONL。タグごとに件数を指定するBalanced Exportがあり、ラベルの偏りを意図的に調整できる。学習側への接続として、LLaMA Factory用の設定ファイルをワンクリックで生成する機能と、Hugging Face Hubへの直接アップロードがある。ここは評価が分かれる部分だ。LLaMA Factoryの設定生成は便利だが、生成された設定ファイルは結局リポジトリで管理することになる。つまりデータ本体はアプリの内部DBにあり、学習設定だけがGitに出るという非対称な状態が生まれる。データの来歴をコードと同じレビュー工程に載せたいチームは、この非対称性をどう埋めるかを先に決めておく必要がある。
向かないケース: パイプラインをコードで持ちたいとき
同じ目的をコードで達成する選択肢として、Microsoft Presidioのようなライブラリではなく、データ処理そのものをPythonで書くアプローチがある。代表例はLangChainやLlamaIndexのドキュメントローダとテキストスプリッタを組み合わせ、生成ステップを自作スクリプトで回す構成だ。違いは明確で、easy-datasetは分割アルゴリズムの選択やプロンプトの調整をUI操作として提供し、その状態はアプリの内部に保存される。コード側のアプローチでは、チャンク戦略もプロンプトも設定ファイルやPythonコードとして差分管理でき、CIで回せる。数百件を一度作って終わりならUIの速さが勝つ。数千件を毎月作り直し、そのたびに分割パラメータを変えて比較したいなら、UIの操作ログを再現する手段がない点が効いてくる。もうひとつの限界はスケールだ。READMEにはバックグラウンドのバッチ処理とタスク管理センター、トークン消費の統計ダッシュボードが挙げられているが、これは単一インスタンスのアプリとしての機能であり、複数ノードに分散させる記述は見当たらない。大量の文書を継続的に処理する用途では、APIレート制限とアプリ側のキューが詰まる可能性を想定しておくべきだ。
ライセンスと更新コストの見積もり
READMEのバッジはAGPL-3.0を示しているが、リポジトリのライセンス識別子はNOASSERTIONであり、この2つは一致していない。採用判断の前にLICENSEファイルの実物を読むべきで、バッジだけを根拠にしない方がよい。AGPL-3.0だと仮定した場合、社内でデータ生成に使う分には通常の業務利用の範囲に収まるが、このアプリを改変してネットワーク越しに第三者へサービスとして提供する形にすると、ソース開示の義務が論点になる。ここは法的助言ではなく、確認事項の指摘だ。更新コストについては、1.7.1が2026年1月、1.7.2が2月、1.7.3が4月と、およそ1〜2か月間隔でリリースが続いている。活発である一方、UIと内部データ構造が動く前提で運用を組む必要がある。生成済みデータセットを長期の資産として保持するなら、アプリのエクスポート機能で定期的にJSONLへ吐き出し、アプリの外側に正本を置く運用が現実的だ。
編集部の結論
導入を検討すべきなのは、社内のPDFやDOCXを素材にSFT用QAやRAG評価セットを短期間で作りたいが、PythonでETLを書く余力は割きたくないチームだ。逆に、生成ロジックをGitで差分管理しCIで回したいチームや、データを外部のマネージドサービスに預けられない規制下のチームには向かない。試す前に確認するのは3点。package.json の scripts に何が定義されているか、LICENSE ファイルの実際の条文がAGPL-3.0とどう一致するか、そして生成したQAを書き出す前にアプリ内のAI品質評価でどれだけ落ちるか。特にライセンスは、AGPL-3.0であれば自社内でのデータ生成利用は問題になりにくい一方、このアプリ自体を改変してネットワーク経由で第三者に提供する形にするとソース開示の論点が生じる。ここは弁護士に確認する領域で、この記事は法的助言ではない。
コミュニティノート