OpenContracts を採用すべきか: 文書に引用グラフを張るセルフホスト基盤

OpenContracts が埋めるのは「引用の抜け」という穴

契約書や有価証券報告書を読むとき、問題になるのは文書そのものより、その文書が何を引用しているかである。ある提出書類がデラウェア州一般会社法のどの条項に依拠しているのか、その条項がさらに何を参照しているのか。通常の全文検索では、この関係は文字列としてしか見えない。OpenContracts は、文書を投入すると引用を検出し、解決し、グラフの辺として描くところを起点にしている。README のデモ説明では、36 件の SEC 提出書類がデラウェア州一般会社法、証券法、SEC 規則へ節単位で接続され、ライブラリがまだ保持していない法令は破線ノードとしてバックログに残るとされている。対象読者は、法務文書を扱うアプリケーションを自分で組みたい開発者と、その上で動くエージェントを作るチームである。完成した SaaS を探している読者ではない。

同一グラフを API・MCP・UI の3面に出す設計

このプロジェクトの中心にある判断は、UI 専用の機能を作らないことだ。README は「Same graph, three surfaces」と表現し、GraphQL + REST API、Model Context Protocol サーバー、React UI が同じグラフを読むと説明している。データの流れはこうである。文書を取り込み、パース、埋め込み、サムネイル生成のパイプラインを通し、注釈と関係（relationships）をグラフとして保持する。抽出は fieldset という単位で定義する。fieldset は列の集合で、各列が自然言語のクエリになっている。これをコーパス全体に対して実行すると、Celery ワーカーにファンアウトし、表計算風のグリッドに結果が並ぶ。README によれば各セルに人間の承認・却下がある。つまり完全自動の抽出ではなく、人間が確認する前提の設計である。MCP 側では search_corpus、list_documents、get_document_text、list_annotations、list_relationships、list_threads、create_thread_message といったツールが公開され、認可があればエージェント自身が注釈を提案できるとされている。

導入手順: リポジトリから読み取れる範囲

README が示す起動の入り口は、コーパスを作成し、文書を投入し、Set up をクリックするという操作である。この1クリックで「intelligence bundle」がインストールされ、エージェントが各文書を要約し、引用の解決が始まると説明されている。API 側から使う場合、README の Python 例は次のとおり。agent = await agents.for_document(123, corpus=45) でエージェントを取得し、async for chunk in agent.stream("Summarize the indemnification clauses") でチャンクを逐次受け取る。Pydantic モデル経由で型付きオブジェクトを受け取る方法も記載されている。MCP を使う場合のエンドポイントは /mcp/（匿名、公開コーパス向け）と /mcp/me/（認証あり）の2つで、 discovery 用に /llms.txt と /.well-known/mcp.json が用意されている。ただし README には docker compose up のような具体的な起動コマンドや環境変数の一覧は載っていない。セルフホストの手順は docs/ 配下の各ガイド（docs/mcp/、docs/pipelines/pipeline_overview.md、docs/architecture/llms/README.md）を読む必要がある。ここは導入前に必ず確認したい箇所だ。

パイプラインが差し替え可能である意味と、その代償

パース、埋め込み、サムネイル生成は交換可能なコンポーネントとして扱われ、独自のパーサーや embedder、thumbnailer を登録しても、下流の検索、注釈、エージェントは変更なしで動くと README は説明している。これは対象文書の形式が一般的でない場合に効く。たとえば独自の契約書テンプレートやスキャン文書を扱うチームにとって、パーサーだけ差し替えられる設計は現実的である。代償は、パイプラインの内部を理解する必要が生じる点だ。登録したコンポーネントが期待する入出力の契約を外すと、検索も注釈も静かに劣化する。README はこの契約の中身までは示していない。また、抽出が Celery ワーカーに依存する以上、ワーカーの数とキューの詰まり具合がスループットを決める。数百文書を一度に処理する使い方を想定するなら、ワーカー構成は導入時に決めておくべき論点になる。

向かないケース: 汎用 DMS として選ぶと重い

README はこのプロジェクトを「DMS for the agentic world」と位置づけるが、汎用の文書管理システムとして評価すると見通しが悪い。バージョン管理、共同編集、権限の細かい階層、Office 形式の往復編集といった一般的な DMS 機能は、少なくとも README からは読み取れない。PostgreSQL と Celery を前提とする構成を抱えるため、単に PDF を保管して全文検索したいだけの用途では、運用コストのほうが大きくなる。もうひとつの制約は、引用グラフが本領を発揮するのは引用関係が意味を持つ文書群だという点である。社内議事録や製品マニュアルのように、文書間の参照がほとんどない集合体では、グラフは疎なままになり、fieldset による抽出だけが残る。その場合は、抽出機能だけを求めてこの構成を選ぶ理由は薄い。

代替としての LlamaIndex 系の自前構成との違い

同じ目的、つまり文書をベクトル化してエージェントから引かせる用途には、LlamaIndex や LangChain を使って自前で組む道がある。違いは抽象の位置である。自前構成では、パーサー、チャンク分割、埋め込み、検索、エージェントのループをすべて自分で配線し、引用グラフが必要なら別途スキーマを設計して保存する。OpenContracts は、注釈、関係、抽出結果、コーパスという単位をあらかじめデータモデルとして持ち、それを GraphQL と REST と MCP で公開する。得られるのは、引用の解決と未保持法令のバックログ管理を自分で書かなくて済むことである。失うのは、検索戦略やチャンク設計を細かく制御する自由だ。検索品質を自前でチューニングしたいチームには、この抽象は邪魔になる。逆に、注釈と引用という概念をアプリの語彙としてそのまま使いたいなら、既存のデータモデルに乗る価値がある。

MIT ライセンスと更新コストの見積もり

ライセンスは MIT と明示されている。商用利用や改変、再配布に関する条件はこの表示の範囲で判断できるが、同梱される第三者依存のライセンスは別途確認が必要で、ここは法的助言の範囲外である。更新の面では、リリース履歴が示す刻みに注意したい。v3.0.0 が 2026-08-10、v3.1.0 が 2026-09-08 と、メジャー間が1か月に満たない。v3.0.0 の表題には Corpus Intelligence、Authority Linking、Deep Research とあり、データモデルや API の表面が動いている時期だと読める。セルフホストで追従するなら、マイグレーションの有無をリリースごとに確認する前提で運用を組むべきである。MCP のツール一覧やエンドポイントのパスも、この速度で変わりうる。バージョンを固定して検証し、上げるときは docs/mcp/ と docs/pipelines/pipeline_overview.md の差分を先に読む、という進め方が現実的だ。

編集部の結論

採用を検討すべきなのは、法令や契約書の引用関係を自前のアプリやエージェントから扱いたいチームである。逆に、汎用の文書管理や単純な全文検索だけが目的なら、PostgreSQL と Celery を抱える構成は割に合わない。導入前に確認するのは、README が示す3つの接続面（GraphQL/REST、/mcp/、React UI）のうち自チームが実際に叩くものはどれか、そして対象文書の形式を既存のパーサーで処理できるかである。パーサーが対応しない形式は、カスタムパーサーを登録する前提で工数を見積もる必要がある。

公式情報源

1. License: MIT
2. Open-Source-Legal/OpenContracts on GitHub
3. Project website
4. README
5. Releases