Unstract を採用する前に確認すべきこと: Prompt Studio と AGPL-3.0 の境界
LLM-Driven Extraction of Unstructured Data — Built for API Deployments & ETL Pipeline Workflows
ひと目でわかる
- これは何？
- PDF やスキャン画像から LLM で構造化 JSON を抜き出す Unstract は、プロンプトでスキーマを定義し REST API か ETL として配備する。Docker Compose で立ち上がる構成と、AGPL-3.0 が配備形態に与える制約を整理する。
- 誰に向いている？
- 向いているのは、PDF やスキャン画像のレイアウトが取引先ごとにばらつき、正規表現やテンプレートの保守に開発工数を取られているデータエンジニアリングチームだ。逆に、抽出スキーマが数年単位で固定されており、既存の OCR テンプレートが安定して動いている現場では、LLM 呼び出しのコストと非決定性を持ち込む理由が薄い。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Unstract が埋めようとしているのは、スキーマ定義のたびに発生する作り直しのコスト
請求書、保険証券、検査結果、本人確認書類。こうした文書から数値を取り出す作業は、これまでベンダーごとのテンプレートと正規表現の山として積み上がってきた。README の比較表はこの状態を「Write regex, build templates per vendor」と表現し、Unstract 側では「Write a prompt once, handles variations」に置き換わると説明している。対象として README が挙げるのは finance、insurance、healthcare、KYC/compliance の各領域で、いずれも帳票レイアウトの版差が継続的に発生する業種だ。つまり Unstract は OCR エンジンの置き換えではなく、抽出ルールの保守単位を「テンプレート」から「プロンプト」へ移す試みだと読める。向いているのは、文書種別が増え続ける、あるいは同じ種別でも取引先ごとに様式が違うチームである。逆に、様式が完全に固定され、年に一度しか変わらない帳票だけを扱うのであれば、既存のテンプレート方式のほうが検証しやすく、実行ごとの揺らぎもない。
Prompt Studio、API、ETL、MCP という 4 つの出口
抽出の定義は Prompt Studio で行う。自然言語でプロンプトを書き、対象文書からどのフィールドを抜くかを決める。README はこれを「Define document extraction schemas with natural language」と説明している。定義したスキーマの出口は複数用意されている。REST API として配備すれば、文書を送ると JSON が返る。ETL パイプラインとして配備すれば、フォルダから文書を読み、処理し、ウェアハウスへ書き込む。加えて MCP サーバー経由で Claude などのエージェントから接続する経路と、n8n のカスタムノードとして既存の自動化フローに差し込む経路が README に列挙されている。ここで実務上効いてくるのは、抽出ロジックが Prompt Studio 側に一元化され、API と ETL とエージェントが同じ定義を共有する点だ。バッチ処理とリアルタイム処理で別々のスクリプトを保守する必要がなくなる。ただし README には各出口のスループットや同時実行数の記載はなく、どの経路がどの程度の文書量に向くかは読み取れない。
起動は run-platform.sh 一本だが、ENCRYPTION_KEY が単一障害点になる
動作要件は README によれば Linux または macOS（Intel と M シリーズの両方）、Docker と Docker Compose、RAM 8 GB 以上、Git だ。手順は短い。git clone でリポジトリを取得し、ディレクトリに入り、./run-platform.sh を実行する。起動後は http://frontend.unstract.localhost を開き、初期資格情報 unstract / unstract でログインする。スクリプトにはフラグが用意されている。-v でバージョンタグを指定し、-u で既存環境のアップグレード、-b でローカルビルド、-p でイメージの取得のみ、-e で環境ファイルのセットアップのみ、-d でデタッチ実行、-h でヘルプ表示になる。バージョンを固定したい現場では ./run-platform.sh -v v0.188.0 のように指定し、-u -v で特定バージョンへ上げる運用が README の例に沿う形だ。見落としやすいのが暗号化キーである。README は警告として、このキーが adapter の資格情報を暗号化しており、失うと既存の adapter にアクセスできなくなると明記している。値は backend/.env または platform-service/.env の ENCRYPTION_KEY にあり、別の安全な場所へ複製しておく必要がある。つまり run-platform.sh によるアップグレードは、このキーを保持していることが前提の操作だ。
LLM 抽出を本番に置くときに残る非決定性
Unstract の抽出は LLM の出力に依存する。同じ文書を同じプロンプトに通しても、返る JSON が毎回完全に一致する保証は README には書かれていない。これは設計上の欠陥というより、方式そのものの性質である。正規表現やテンプレートマッチングであれば、同じ入力に対して同じ出力が機械的に決まる。LLM 経由では、モデルのバージョン更新、温度パラメータ、文書のスキャン品質といった要素が出力に影響しうる。金融や保険の帳票を扱う場合、この差は「たまに違う値が入る」という形で現れ、下流のデータベース制約や突合処理で初めて発覚する。README が想定用途として挙げる領域がまさにこの性質と衝突しやすい領域である点は、採用判断で正面から扱うべき論点だ。もう一点、LLM プロバイダの選択肢として OpenAI、Anthropic、Bedrock、Ollama が README に列挙されている。Ollama が含まれるため、文書を社外に送れない制約がある現場でも、ローカルモデルで構成する余地は残されている。ただしローカルモデルでの抽出精度がクラウドモデルと同等かは README からは判断できない。
AGPL-3.0 であることの実務的な意味
Unstract のライセンスは AGPL-3.0 で、リポジトリの LICENSE ファイルがそれを示している。AGPL はネットワーク越しに利用者へ機能を提供する場合にもソース開示の条件が及ぶ点で、通常の GPL と扱いが異なる。Unstract の主要な使い方が REST API としての配備である以上、この条項は他人事ではない。社内システムから呼ぶだけなのか、社外の顧客に API として提供するのかで、検討すべき範囲が変わる。README には Enterprise 向けの導線が用意されており、ライセンス条件の違いはそちらで扱われると推測できるが、本記事の材料からは Enterprise 版の具体的な条件は確認できない。法的な判断はここで下せる話ではないので、API を社外公開する計画があるなら、実装着手前に法務へ諮る順序を取るべきだ。ソースを改変せず、社内のバッチ処理としてのみ動かす使い方であれば、条件に触れる可能性は大きく下がる。
比較対象としての LlamaParse と、アーキテクチャの違い
同じ「文書を LLM で構造化データに変える」目的の選択肢に LlamaParse がある。両者はレイヤーが違う。LlamaParse は文書を解析して Markdown やテキストに変換するパース処理に重心があり、その出力をどう構造化するかは呼び出し側の LlamaIndex パイプラインに委ねられる。一方 Unstract は、パースだけでなくスキーマ定義、プロンプト管理、API 配備、ETL 配備までを一つのプラットフォームに収めている。自作パイプラインの自由度を保ちたいなら LlamaParse 側の粒度が合う。逆に、抽出定義を非エンジニアが触れる画面に置きたい、配備までを一つのスクリプトで完結させたいなら Unstract のまとまりが効く。トレードオフは明確で、Unstract を選ぶと抽出ロジックがプラットフォーム内に閉じる。モデルを差し替えるにも、プロンプトを管理するにも、Unstract の抽象に従う必要がある。
アップグレード頻度と、検証すべき 3 つの項目
リリースは密である。v0.188.0 が 2026-09-09、v0.187.2 が 2026-09-03、v0.187.1 が 2026-09-01 と、マイナーバージョンが数日単位で並ぶ。0.x 系が続いている点も含め、追従には相応のコストを見込むべきだ。run-platform.sh -u で上げられるとはいえ、上げた後に抽出結果が変わっていないかを確認する手順は自前で用意する必要がある。導入検討時に確かめるべきは 3 点だ。第一に、AGPL-3.0 のまま社外に API を公開するのか、Enterprise 契約が要るのかを先に決めること。第二に、ENCRYPTION_KEY を backend/.env と platform-service/.env のどちらから取得し、どこに保管するかを決めること。失えば既存 adapter が使えなくなる。第三に、代表的な文書を 2 回投入し、返る JSON が一致するかを自分の環境で確認すること。この 3 点が埋まらないうちは、本番のデータベースへ直接書き込む配備は避けたほうがよい。
編集部の結論
向いているのは、PDF やスキャン画像のレイアウトが取引先ごとにばらつき、正規表現やテンプレートの保守に開発工数を取られているデータエンジニアリングチームだ。逆に、抽出スキーマが数年単位で固定されており、既存の OCR テンプレートが安定して動いている現場では、LLM 呼び出しのコストと非決定性を持ち込む理由が薄い。採用を決める前に確認すべきは 3 点ある。第一に、AGPL-3.0 のまま API として社外に公開するのか、Enterprise 契約が必要なのかを法務判断として先に確定させること。第二に backend/.env と platform-service/.env の ENCRYPTION_KEY を、adapter の資格情報を失わない形で保管する運用を決めること。第三に、同じ文書を 2 回投入して同じ JSON が返るかを自分の手元で確かめること。この 3 点が埋まらない限り、本番投入は時期尚早と判断してよい。
コミュニティノート