Google LangExtract：LLM で長文から構造化データを抽出する

LangExtract は、Google が公開している Python ライブラリで、非構造化テキストから構造化情報を抽出するためのものです。

使い方は分かりやすく、テキスト、プロンプト、少数の例を与えると、大規模言語モデルが定義したフィールドに従って内容を抽出し、後続処理しやすいデータとして整理します。

普通に「モデルに要約してもらう」のとは違い、LangExtract は主に 3 つの点を重視します。

固定した構造で情報を抽出する
抽出結果と原文位置の対応を保つ
長文ドキュメントと可視化チェックを支援する

レポート、論文、診療記録、契約書、ログ、Web ページなどから、エンティティ、イベント、関係、属性をよく抽出するなら、この種のツールは手書きの正規表現より柔軟で、単なるチャット型の質問より後続のデータ処理につなげやすくなります。

何を解決するのか

多くのテキスト抽出タスクは簡単そうに見えますが、実際には面倒です。

たとえば、長文から次のようなものを抽出したい場合があります。

人名、組織名、場所
イベント、時間、参加者
薬剤、投与量、副作用
製品型番、パラメーター、価格
契約条項、義務、期限
ログ内のエラー種別とコンテキスト

形式が固定されていれば、正規表現や従来のパーサーで対応できます。
しかし文章表現が少し自然になるだけで、ルールは急に複雑になります。

大規模言語モデルは自然言語の理解に向いていますが、単に「抽出して」と頼むだけでは、いくつかの問題が起きやすくなります。

出力形式が安定しない
情報が原文のどこから来たのか分からない
長文では漏れやすい
バッチ処理しにくい
人間が結果をレビューしにくい

LangExtract が解決しようとしているのはこの部分です。LLM の理解力を、より制御しやすい抽出ワークフローとして扱えるようにします。

LangExtract の特徴

1. 例で抽出形式を制約する

LangExtract は、曖昧な一文のプロンプトだけに頼るのではなく、prompt と examples を使ってモデルに次を伝えます。

何を抽出するか
フィールド名は何か
各フィールドをどう埋めるか
不確実な場合にどう扱うか

この few-shot 方式は情報抽出タスクに向いています。
例が実データに近いほど、モデルは同じ構造で安定して出力しやすくなります。

2. 抽出結果を原文へ対応付けられる

情報抽出で困るのは、「正しそうに見えるが、どこから来たのか分からない」結果です。

LangExtract の重要な点のひとつは、抽出結果と原文位置を対応付けることです。後から確認するとき、JSON の結果だけでなく、その情報が原文のどの部分に由来するのかも確認できます。

これは、医療テキスト、法律文書、研究資料、社内文書など、レビューが必要な場面で重要です。

3. 長文ドキュメントを扱える

長文の抽出では、コンテキストウィンドウ、抽出漏れ、重複抽出の問題が起きやすくなります。

LangExtract は長文向けの処理方法を提供し、ドキュメントを分割して並列処理し、抽出結果を整理できます。

そのため、短いテキスト片だけでなく、完全なレポート、論文、長い Web ページ、まとまった資料の処理にも向いています。

4. 可視化チェックを支援する

抽出結果が JSON だけだと、問題を見落としやすくなります。

LangExtract は抽出結果の可視化を支援し、モデルがどこから何を抽出したのかを直感的に確認できます。
これは prompt の調整、抽出漏れの確認、誤抽出の確認に役立ちます。

どんなときに使うべきか

LangExtract は次のような場面に向いています。

自然言語テキストから構造化フィールドを抽出したい
テキスト形式が完全には固定されていない
抽出結果と原文の対応関係を残したい
長いドキュメントを処理したい
結果に人間のレビューが必要
後続で表、データベース、データ分析に流したい

典型例は次の通りです。

医療テキストから症状、薬剤、投与量、反応を抽出する
契約書から当事者、義務、金額、期限を抽出する
論文から研究対象、方法、結論を抽出する
製品資料から仕様パラメーターを抽出する
カスタマーサポート記録から問題種別と対応結果を抽出する

短いテキストの概要を一時的に知りたいだけなら、普通のチャットモデルで十分です。
テキストを後続処理できるデータに変えたい場合は、LangExtract のほうが向いています。

基本的なインストール

プロジェクトは pip でインストールできます。

1

pip install langextract

ソースからインストールすることもできます。

1
2
3


git clone https://github.com/google/langextract.git
cd langextract
pip install -e .

モデル API を使う場合は、対応するモデルプロバイダーの API key を設定します。
プロジェクト文書では Gemini 関連の使い方が中心に紹介されており、アダプター経由で他のモデルプロバイダーにも接続できます。

基本的な使い方

典型的な流れは次のようになります。

原文テキストを準備する
抽出対象を明確に書く
少数の例を与える
LangExtract を呼び出して抽出する
構造化結果を確認する
必要なら可視化ページを生成してレビューする

特に重要なのは 2 番目と 3 番目です。

プロンプトではタスクを明確に書く必要があります。

テキスト内に明示された情報だけを抽出する
常識で補完しない
フィールドが欠けている場合は空にする
同じ種類のエンティティでは同じフィールド構造を保つ
出力に原文断片または位置を残す

例は実際の入力にできるだけ近づけるべきです。
実テキストにノイズ、略語、改行、表の残骸があるなら、例にもそれを反映するとよいです。

使うときの注意点

第一に、抽出タスクを広くしすぎないことです。

「有用な情報を抽出する」は広すぎます。
「薬剤名、投与量、投与頻度、副作用を抽出する」のように書くほうがよいです。

第二に、モデル出力を完全には信頼しないことです。

LangExtract は結果と原文を対応付けられますが、モデルが漏れや誤抽出をしないという意味ではありません。重要な場面ではサンプリング確認や人間のレビューが必要です。

第三に、長い説明より例が有効です。

情報抽出タスクでは、モデルは出力形式を理解するために例へ強く依存します。
抽象的なルールを長く書くより、高品質な example をいくつか用意するほうが有効です。

第四に、長文ではコストと速度を見ることです。

長文分割、並列抽出、モデル呼び出しにはコストがかかります。本格的なバッチ処理の前に、小さなサンプルでプロンプトとフィールド構造を調整するのがよいです。

正規表現や従来 NLP との違い

正規表現は、形式が安定しルールが明確なテキストに向いています。

従来の NLP パイプラインは、タスク境界が明確で、モデルや辞書がすでに準備されている場面に向いています。

LangExtract は、形式がそこまで固定されていないが、意味は比較的明確なテキストに向いています。
すべての表現に対してルールを書くのではなく、LLM が例から抽出対象を理解します。

ただし、正規表現の完全な代替ではありません。

固定形式のテキストでは、正規表現のほうが安価で安定している
高リスク場面では検証とレビューが必要
大規模バッチ処理ではモデル呼び出しコストを考える必要がある

現実的には、ルールが明確な部分はプログラムで処理し、意味の揺れが大きい部分を LangExtract に任せるのがよいです。

どんな開発者に向いているか

次のようなことをしているなら、LangExtract を試す価値があります。

長文を表に整理する
文書からエンティティと関係を抽出する
ナレッジベース投入前のデータクレンジングをする
業務テキストからフィールドを抽出する
LLM 駆動の情報抽出プロトタイプを作る
抽出結果と原文証拠を残したい

これは「クリックすればすべての文書を理解する」ツールではありません。LLM 抽出フローを工程化するためのライブラリに近いものです。

それでも、フィールド設計、例の作成、結果確認は必要です。
しかし毎回モデル呼び出しを書き、prompt を組み、出力を解析するより、より完整な抽出フレームワークを提供します。

参考

google/langextract

最後に

LangExtract の価値は、「LLM にテキストから情報を探させる」作業をより制御しやすくすることにあります。

気軽な要約ではなく、フィールド、根拠、レビュー要求がある情報抽出タスクに向いています。
長文を構造化データに変える仕事が多いなら、試す価値のあるツールです。