Hyper-Extract：hypergraph 抽出を CLI に畳んだ知識構築ツール
Hypergraph is more powerful. Transform unstructured text into structured knowledge with LLMs. Graphs, hypergraphs, and spatio-temporal extractions — with one command.
ひと目でわかる
- これは何？
- 非構造テキストからグラフ、ハイパーグラフ、時空間グラフを生成する Python 製 CLI。templates と provider 設定の分離が設計の中心で、導入判断は抽出精度より運用コストとライセンス表記に寄る。
- 誰に向いている？
- 大量の社内文書を手作業でグラフ化しているチーム、あるいは GraphRAG 系のパイプラインを自作して保守に疲れたチームには、he parse と YAML テンプレートの組み合わせが作業量を減らす可能性がある。逆に、抽出スキーマが固まっていて既存コードが動いている場合や、ライセンス条項を法務が厳格に確認する組織には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
この CLI が埋めようとしている穴
非構造テキストを LLM で知識構造に変換する作業は、これまでパイプラインを自作するか、GraphRAG や LightRAG のような個別フレームワークを直接叩くかの二択だった。前者はチャンク分割、プロンプト、スキーマ検証、埋め込み、保存形式をすべて自分で決める必要があり、後者はフレームワークごとに設定方法も出力形式も違う。Hyper-Extract はこの中間に CLI を置いた。he parse 一発で抽出から保存までを終わらせ、出力先ディレクトリを he search と he show がそのまま読む。対象読者は、研究者、財務アナリスト、社内ナレッジベースの管理者だと README は想定している。注目すべきは抽出エンジンそのものではなく、エンジンとテンプレートと provider を別々に差し替えられる構造にした点である。README の機能表では 9 種類の知識構造、11 以上の抽出エンジン、80 以上の YAML テンプレートが挙げられており、chunk_rag はゼロコストのベースラインとして位置づけられている。
テンプレートと provider を分離した設定モデル
設定は he config 系のサブコマンドで行う。he config init -p openai -k YOUR_OPENAI_API_KEY は LLM と埋め込みを 1 つのキーで賄う。DeepSeek や Anthropic は LLM のみの提供なので、he config llm と he config embedder を別々に叩き、埋め込み側は OpenAI 互換のエンドポイントを指定する。README は DeepSeek を最も費用対効果が高い選択肢として挙げ、1 ページあたり約 0.001 から 0.005 ドルという目安を示している。オンプレミスなら vLLM を 2 ポートで立て、he config llm -p vllm -u http://localhost:8000/v1 -k dummy -m Qwen/Qwen3.5-9B と he config embedder -p vllm -u http://localhost:8001/v1 -k dummy -m BAAI/bge-m3 のように URL とモデル名を直接渡す。Python API 側では create_client(llm="vllm:Qwen3.5-9B@http://localhost:8000/v1", embedder="vllm:bge-m3@http://localhost:8001/v1", api_key="dummy") という文字列 1 本で同じ構成を表現する。provider 名、モデル名、エンドポイントを 1 つの文字列に詰める形式は簡潔だが、エンドポイントに @ やコロンを含む場合はエスケープが必要になる可能性があり、この点は README からは読み取れない。
he parse から検索・可視化までのデータの流れ
基本の流れは 4 段階である。he parse examples/en/tesla.md -t general/biography_graph -o ./output/ -l en で文書とテンプレートを指定し、出力ディレクトリに知識構造を書き出す。he search ./output/ "What are Tesla's major achievements?" がそのディレクトリをそのまま検索対象にする。he show ./output/ が可視化、he export obsidian ./output/ -o ./vault/ が Markdown ノートと [[wikilinks]] の Vault を生成する。つまり出力ディレクトリが事実上のデータベースであり、コマンド間の受け渡しはパス 1 つに集約されている。テンプレートは general/biography_graph や finance/earnings_graph のようにドメイン/名前の階層で指定し、Python API では Template.create("general/biography_graph") として同じものを読み込む。YAML を書けばコードを触らずにスキーマを増やせる設計で、80 以上のテンプレートが同梱されているという記述はこの拡張経路を前提にしている。
来歴管理とロールバックという差分更新の設計
このツールで最も実務的なのは、抽出精度よりも更新の扱いである。he feed ./output/ updated-tesla.md --source tesla.md は既存の source に対して新しい文書を投入し、古い事実を自動的にロールバックすると README は説明している。he tag ./output/ --source tesla.md --add biography で source にタグを付け、he search ./output/ "inventions" --tag biography で検索範囲を絞る。he info ./output/ --sources はどの文書が何を寄与したかを一覧する監査用のコマンドで、he remove --document は文書単位の削除に対応する。文書が更新されるたびに全再構築する運用と比べ、差分だけを畳む前提で設計されている点が構造上の違いである。ただしロールバックがどの粒度で効くのか、たとえば同一 source 内で矛盾する記述が混在した場合にどちらが残るのかは、README の記述からは判断できない。ここは実データで確認するしかない部分だ。
rich document ingestion の依存と入力の制約
v0.9.0 のリリース名は Rich Document Ingestion & chunk_rag Baseline で、PDF、Word、PowerPoint、Excel、HTML、EPUB の取り込みが追加された。ただしこれは本体に同梱されるわけではなく、pip install "hyperextract[ingest]" という extras 指定で入れる別依存である。素の uv tool install hyperextract では .txt と .md が中心になり、PDF を渡しても変換段階で失敗する可能性がある。バイナリ形式の変換精度は元のファイル構造に依存し、表や段組の多い PDF では抽出されるテキスト自体が崩れる。つまり LLM の抽出品質以前に、入力テキストの品質で結果が決まる。研究論文の PDF を he parse paper.pdf -t general/academic_graph に渡す例が README にあるが、これは変換が成功する前提の例であり、スキャン画像の PDF については言及がない。
GraphRAG や LightRAG を直接使う場合との違い
同じ README が抽出エンジンとして GraphRAG、LightRAG、Hyper-RAG、KG-Gen を列挙している点は、この位置づけを考えるうえで重要である。Hyper-Extract はこれらと競合するというより、複数のエンジンを同じ CLI と出力形式の下に並べる層として作られている。GraphRAG を直接使う場合、コミュニティ検出や要約のパラメータ、出力の Parquet 群、検索インターフェースの呼び出し方を自分で管理する。Hyper-Extract 経由なら he parse の -t でエンジンと構造を選び、he search で同じディレクトリを引く。代わりに、エンジン固有の細かいパラメータや出力の内部構造に踏み込みたい場合は抽象化が邪魔になる。抽出品質を突き詰める研究用途では直接使う方が有利で、複数文書を継続的に更新しながら検索したい運用用途では CLI 側に利がある、という切り分けになる。
ライセンス表記の不一致という導入前の確認事項
README のバッジは Apache 2.0 を示し、本文にも LICENSE へのリンクがある。しかしリポジトリのメタデータ上、ライセンスは NOASSERTION と記録されている。GitHub が LICENSE ファイルの内容を既知のライセンスとして認識できなかったという意味で、ファイルが存在しないとは限らないが、少なくとも自動判定は成功していない。Apache 2.0 であれば特許条項と帰属表示の扱いが明確になるが、実際の LICENSE ファイルの中身がバッジと一致するかは別途確認が必要である。ここで法的助言はできないが、社内導入の稟議にライセンス条項を添える運用なら、PyPI のメタデータとリポジトリ直下の LICENSE の両方を開いて突き合わせる作業を最初に済ませておくべきだ。
メンテナンス頻度とバージョンの刻み方から見える成熟度
リリース履歴は v0.8.1、v0.8.2、v0.9.0 と数日単位で並び、最終 push は 2026-09-09 である。0.x 系でマイナー番号が細かく上がる進め方は、機能追加が速い代わりに API や設定キーが動く可能性を含む。実際 v0.8.1 と v0.8.2 はどちらも Scoped Search & Source Tags を掲げており、同じ機能領域を 2 回に分けて出している。he config のキー名、テンプレートのパス、出力ディレクトリの内部スキーマは、バージョンを上げる際に差分を確認すべき対象である。運用に組み込むなら、uv tool install hyperextract で入れたバージョンを固定し、更新時に examples/en/tesla.md を新しいバージョンで処理し直して出力を比較する手順を先に決めておくと、破壊的変更を早い段階で検出できる。
編集部の結論
大量の社内文書を手作業でグラフ化しているチーム、あるいは GraphRAG 系のパイプラインを自作して保守に疲れたチームには、he parse と YAML テンプレートの組み合わせが作業量を減らす可能性がある。逆に、抽出スキーマが固まっていて既存コードが動いている場合や、ライセンス条項を法務が厳格に確認する組織には向かない。導入前に確認すべきは 3 点で、第一にリポジトリの LICENSE と PyPI 上の Apache 2.0 表記が一致するか、第二に examples/en/tesla.md を he parse で処理して出力 JSON のスキーマが自社の下流処理に合うか、第三に he feed で同一 source を再投入したときに古い事実が本当にロールバックされるかである。
コミュニティノート