AI & 機械学習

Gemini 2.0 を使用してドキュメントの抽出を高速化し、費用を削減する

2025年3月17日

Meenu Bondili

Field Solutions Developer, Generative AI

Jonathan Chen

Gen AI Field Solutions Architects Manager

※この投稿は米国時間 2025 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

数週間前、Google DeepMind は Gemini 2.0 を一般公開しました。これには、Gemini 2.0 Flash、Gemini 2.0 Flash-Lite、Gemini 2.0 Pro Experimental が含まれます。すべてのモデルで少なくとも 100 万個の入力トークンがサポートされるようになったため、画像生成から創造的な文章作成まで、多くのことをより簡単に行えるようになりました。また、ドキュメントを構造化データに変換する方法も変わりました。手動のドキュメント処理には時間も費用もかかります。しかし、Gemini 2.0 は RAG システム用の PDF のチャンキングを全面的に変え、PDF から分析情報を引き出すことも可能にしました。

今回は、生成 AI を使用したマルチステップアプローチについて詳しく説明します。このアプローチでは、Gemini 2.0 を使用して、言語モデル（LLM）と構造化および外部化されたルールを組み合わせることで、ドキュメントの抽出を改善できます。

ドキュメント抽出のマルチステップアプローチを簡単に

単一のモノリシックなプロンプトに依存するのではなく、マルチステップアーキテクチャを使用すると、抽出を確実に行うにあたって大きなメリットが得られます。このアプローチは、モジュール式の抽出から始まります。最初のタスクは、ドキュメント内の具体的なコンテンツの位置を対象とする、より焦点を絞った小さなプロンプトに分割されます。モジュール式で実行することで、正確性が高まるだけでなく、LLM の認知負荷の軽減にもなります。

マルチステップアプローチのもう一つのメリットは、ルール管理を外部化できることです。たとえば、Google スプレッドシートや BigQuery テーブルを使用して後処理ルールを外部で管理することで、簡単な CRUD（作成、読み取り、更新、削除）操作のメリットを享受し、ルールのメンテナンス性とバージョン管理の両方を改善することができます。この分離により、抽出ロジックと処理ロジックも分離されるため、それぞれを独立させた状態で変更し、最適化できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_zd4iHbn.max-1400x1400.png

つまり、このハイブリッドアプローチは、LLM を活用した抽出と構造化ルールエンジンの長所を組み合わせたものです。LLM は、非構造化データの情報を理解して抽出する複雑さを処理し、ルールエンジンは、ビジネスロジックと意思決定を適用するための透明性と管理性の高いシステムを提供します。実際の実装は、おおむね以下のような流れになります。

ステップ 1: 抽出

構成可能なルールセットを使用して、サンプルプロンプトをテストしてみましょう。このハンズオンサンプルでは、ビジネスロジックの定義と抽出されたデータのへ適用がいかに簡単かを説明します。使用するツールは Gemini と Vertex AI です。

まず、ドキュメントからデータを抽出します。ソースドキュメントとして Google の 2023 年度環境報告書を使用します。データの抽出に Gemini と最初のプロンプトを使用します。これは既知のスキーマではなく、この記事のために作成したプロンプトです。特定のレスポンスのスキーマを作成するには、Gemini の生成制御機能を使用します。

lang-py

読み込んでいます...

<ペルソナ>
あなたは、企業の環境報告書から主要なサステナビリティ指標とパフォーマンス データを抽出することを専門とする、細部にまで注意をめぐらせる AI アシスタントです。提供されたドキュメントから特定のデータポイントを正確に特定して抽出し、正確な値とコンテキスト情報を確実に取得できるようにすることがあなたのタスクです。サステナビリティの目標の進捗状況を追跡し、情報に基づいた意思決定をサポートするために、あなたの分析は不可欠です。

<カスタム指示>

**タスク:**
提供されている Google の 2023 年度環境報告書（PDF）を分析し、次の「key_metrics」を抽出します。指標は以下のとおりです。

1. **「metric_id」**: 指標の短い固有識別子（以下で指定）。
2. **「description」**: 指標の簡潔な説明（以下で指定）。
3. **「value」**: ドキュメントで報告されている指標の数値。厳密な数値を示す（例: 「約 1,000 万」ではなく「1,020 万」）。範囲が指定されていて、単一の値が明確に示されていない場合は、必ず最大範囲を使用する。
4. **「unit」**: 指標の測定単位（例: 「tCO2e」、「ガロン」、「%」など）を、報告書に記載されているとおりに使用する。
5. **「year」**: 指標が適用される年（特に指定がない場合は 2022 年）。
6. **「page_number」**: 指標の値が見つかったページ番号。情報が複数のページに分散している場合は、該当するすべてのページをカンマ区切りで列挙する。ページに基づいて計算が必要な値の場合は、最終的な解があるページを示す。
7. **「context」**: 指標をコンテキストに当てはめた単文。
**抽出する指標:**

```json
[
   {
     "metric_id": "ghg_emissions_total",
     "description": "GHG 排出量合計（スコープ 1、2 市場ベース、3）",
   },
   {
     "metric_id": "ghg_emissions_scope1",
     "description": "スコープ 1 GHG 排出量",
   },
   {
     "metric_id": "ghg_emissions_scope2_market",
     "description": "スコープ 2 GHG 排出量（市場ベース）",
   },
   {
     "metric_id": "ghg_emissions_scope3_total",
     "description": "スコープ 3 GHG 排出量の合計",
   },
   {
     "metric_id": "renewable_energy_capacity",
     "description": "締結した契約に基づくクリーン エネルギー発電容量（2010～2022 年）",
   },
   {
     "metric_id": "water_replenishment",
     "description": "還元された水量",
   },
    {
     "metric_id": "water_consumption",
     "description": "水の消費量",
   },
   {
     "metric_id": "waste_diversion_landfill",
     "description": "埋め立て式ごみ廃棄場からの食品廃棄物の転換率",
   },
   {
     "metric_id": "recycled_material_plastic",
     "description": "製品に使用された再生プラスチックの割合",
   },
     {
     "metric_id": "packaging_plastic_free",
     "description": "プラスチックを使用していない商品パッケージの割合",
   }
]

以下の JSON 出力は、変数「extracted_data」に割り当てられます。これは、Gemini による最初のデータ抽出の結果を表します。この構造化されたデータは、次の重要なフェーズである事前定義されたビジネスルールの適用に使用できます。

lang-py

読み込んでいます...

extracted_data= [
 {
   "metric_id": "ghg_emissions_total",
   "description": "GHG 排出量合計（スコープ 1、2 市場ベース、3）",
   "value": "1,430 万",
   "unit": "tCO2e",
   "year": 2022,
   "page_number": "23",
   "context": "2022 年の Google の GHG 排出量の総量は、スコープ 1、2（市場ベース）、3 を含めて 1,430 万 tCO2e でした。"
 },
 {
   "metric_id": "ghg_emissions_scope1",
   "description": "スコープ 1 GHG 排出量",
   "value": "23 万",
   "unit": "tCO2e",
   "year": 2022,
   "page_number": "23",
   "context": "2022 年の Google のスコープ 1 温室効果ガス排出量は 23 万 tCO2e でした。"
 },
 {
   "metric_id": "ghg_emissions_scope2_market",
   "description": "スコープ 2 GHG 排出量（市場ベース）",
   "value": "3 万",
   "unit": "tCO2e",
   "year": 2022,
   "page_number": "23",
   "context": "2022 年の Google のスコープ 2 の GHG 排出量（市場ベース）は合計 3 万 tCO2e でした。"
 },
 {
   "metric_id": "ghg_emissions_scope3_total",
   "description": "スコープ 3 GHG 排出量の合計",
   "value": "1,400 万",
   "unit": "tCO2e",
   "year": 2022,
   "page_number": "23",
   "context": "2022 年の Google のスコープ 3 温室効果ガス排出量の合計は 1,400 万 tCO2e に達しました。"
 },
 {
   "metric_id": "renewable_energy_capacity",
   "description": "締結した契約に基づくクリーン エネルギー発電容量（2010～2022 年）",
   "value": "7.5",
   "unit": "GW",
   "year": 2022,
   "page_number": "14",
   "context": "Google は 2010 年以降、2022 年末までに、7.5 GW のクリーン エネルギー発電容量を実現するという契約を締結しました。"
 },
 {
   "metric_id": "water_replenishment",
   "description": "還元された水量",
   "value": "24 億",
   "unit": "ガロン",
   "year": 2022,
   "page_number": "30",
   "context": "Google は 2022 年に 24 億ガロンの水を還元しました。"
 },
  {
   "metric_id": "water_consumption",
   "description": "水の消費量",
   "value": "34 億",
   "unit": "ガロン",
   "year": 2022,
   "page_number": "30",
   "context": "2022 年の Google の水の消費量は合計 34 億ガロンでした。"
 },
 {
   "metric_id": "waste_diversion_landfill",
   "description": "埋め立て式ごみ廃棄場からの食品廃棄物の転換率",
   "value": "70",
   "unit": "%",
   "year": 2022,
   "page_number": "34",
   "context": "Google は 2022 年に食品廃棄物の 70% を埋め立て地に廃棄せず、転換しました。"
 },
 {
   "metric_id": "recycled_material_plastic",
   "description": "製品に使用された再生プラスチックの割合",
   "value": "50",
   "unit": "%",
   "year": 2022,
   "page_number": "32",
   "context": "2022 年、製造プロダクトに使用されたプラスチックの 50% が再生素材でした。"
 },
 {
   "metric_id": "packaging_plastic_free",
   "description": "プラスチックを使用していない商品パッケージの割合",
   "value": "34",
   "unit": "%",
   "year": 2022,
   "page_number": "32",
   "context": "2022 年、Google の商品パッケージの 34% がプラスチックを使用していませんでした。"
 }
]

ステップ 2: 抽出されたデータをルールエンジンにフィードする

次に、この「extracted_data」をルールエンジンに渡します。この実装では、Gemini をもう一度呼び出して、高性能で柔軟なルールプロセッサとして機能させます。抽出されたデータとともに、「analysis_rules」変数で定義された一連の検証ルールも渡します。Gemini を活用したこのエンジンは、抽出されたデータの正確性、整合性、事前定義基準への準拠性を体系的にチェックします。以下は、これを実現するために Gemini に提供したプロンプトとルールです。

lang-py

読み込んでいます...

<ペルソナ>
あなたはサステナビリティ データ アナリストとして、企業の環境報告書から抽出されたデータの正確性と整合性を検証する責任を担っています。抽出されたデータに一連の事前定義済みのルールを適用して、不整合があれば特定し、さらなる調査が必要な領域をハイライトし、目標達成の進捗状況を評価することがあなたのタスクです。細部にまで気を配り、サステナビリティに関する報告のニュアンスを理解していることが求められます。

<カスタム指示>

**入力:**

1. 「extracted_data」:（JSON）前回のターンで提供されたように、「extracted_data」変数には Google の 2023 年度環境報告書から抽出された値が格納されます。これは、Gemini の最初の抽出からの出力です。
2. 「analysis_rules」: （JSON）「analysis_rules」変数には、抽出データに適用する一連のルールを定義する JSON 文字列が格納されます。各ルールには、「rule_id」、「description」、「condition」、「action」、「alert_message」が含まれます。

**タスク:**

1. **ルールを反復処理する:** 「analysis_rules」で定義されている各ルールを処理します。
2. **条件を評価する:** 各ルールについて、「extracted_data」のデータを使用して「condition」を評価します。条件には次の項目が含まれます。
   *   「extracted_data」内の特定の「metric_id」値にアクセスする。
   *   異なる指標間で値を比較する。
   *   データ型を確認する（値が数値であることを確認するなど）。
   *   ページ番号の整合性を確認する。
   *   論理演算子（AND、OR、NOT）と数学的な比較演算子（>、<、>=、<=、==、!=）を使用する。
   *  データの存在を確認する。
3. **アクションを実行する:** ルールの条件が TRUE と評価された場合、ルールで指定された「action」を実行します。アクションでは、ルールがチェックする *内容* を説明します。
4. **アラートをトリガーする:** 条件が TRUE の場合、そのルールに関連付けられた「alert_message」を生成します。コンテキストを提供するために、アラート メッセージに関連する「metric_id」の値とページ番号を含めます。

**出力:**

トリガーされたアラートを含む JSON 配列を返します。各アラートには、次のキーを含む辞書が必要です。

*   「rule_id」: アラートをトリガーしたルールの ID。
*   「alert_message」: アラート メッセージ。「extracted_data」の特定の値が含まれる場合があります。

「analysis_rules」は、抽出されたレシートデータに適用するビジネスルールを含む JSON オブジェクトです。各ルールでは、チェックする特定の条件、条件が満たされた場合に実行するアクション、違反が発生した場合に表示するオプションのアラートメッセージを定義します。このアプローチの強みは、これらのルールに柔軟性があることです。軸となる抽出プロセスを変更することなく、ルールを簡単に追加、変更、削除できます。Gemini を使用する利点は、ルールを人間が読みやすい言語で記述でき、コーディングの知識がない人でも管理できることです。

読み込んでいます...

analysis_rules = {
 "rules": [
   {
     "rule_id": "AR001",
     "description": "必要な指標がすべて抽出されたかどうかを確認します。",
     "condition": "extracted_data に、元の抽出プロンプトからのすべての metric_id が含まれている",
     "action": "期待されるすべての指標の存在を確認します。"
     "alert_message": "抽出されたデータに指標がありません。次の指標 ID が見つかりません: {missing_metrics}"
   },
   {
     "rule_id": "AR002",
     "description": "GHG 排出量の合計がスコープ 1、2、3 の合計と一致しているかどうかを確認します。",
     "condition": "extracted_data['ghg_emissions_total']['value'] != (extracted_data['ghg_emissions_scope1']['value'] + extracted_data['ghg_emissions_scope2_market']['value'] + extracted_data['ghg_emissions_scope3_total']['value']) AND extracted_data['ghg_emissions_total']['page_number'] == extracted_data['ghg_emissions_scope1']['page_number'] ==  extracted_data['ghg_emissions_scope2_market']['page_number'] == extracted_data['ghg_emissions_scope3_total']['page_number']",
     "action": "Scope 1、2、3 の排出量を合計し、報告された合計と比較します。",
     "alert_message": "不整合が検出されました: {total_page} ページの総 GHG 排出量（{total_emissions} {total_unit}）が、{scope1_page} ページのスコープ 1（{scope1_emissions} {scope1_unit}）、スコープ 2（{scope2_emissions} {scope2_unit}）、スコープ 3（{scope3_emissions} {scope3_unit}）の排出量の合計と一致しません。合計は {calculated_sum} です"
   },
   {
     "rule_id": "AR003",
     "description": "還元量と比較して異常に高い水の使用量があるかどうかを確認します。",
     "condition": "extracted_data['water_consumption']['value'] > (extracted_data['water_replenishment']['value'] * 5)  AND extracted_data['water_consumption']['unit'] == extracted_data['water_replenishment']['unit']",
     "action": "水の消費量と還元量を比較します。",
     "alert_message": "水の消費量が多い: {consumption_page} ページと {replenishment_page} ページによると、消費量（{consumption_value} {consumption_unit}）は還元量（{replenishment_value} {replenishment_unit}）の 5 倍以上です。"
   }
 ]
}

ステップ 3: 分析情報を統合する

最後に、そして最も重要な点として、ルールエンジンによって生成されたアラートや分析情報を既存のデータパイプラインやワークフローに統合します。ここで、このマルチステップアプローチの真の価値が発揮されます。この例では、Google Cloud ツールを使用して堅牢な API とシステムを構築し、ルールベースの分析によってトリガーされるダウンストリームアクションを自動化できます。ダウンストリームタスクの例:

タスクの自動作成: Cloud Functions をトリガーしてプロジェクト管理システムでタスクを作成し、適切なチームにデータ検証を割り当てます。
データ品質パイプライン: Dataflow と統合して、BigQuery テーブルのデータの不整合と思われるものを検知し、検証ワークフローをトリガーします。
Vertex AI との統合: Vertex AI Model Registry を活用して、抽出された指標や行われた修正に関連するデータリネージとモデルのパフォーマンスを追跡します。
ダッシュボードの統合: Looker、Google スプレッドシート、データポータルを使用してアラートを表示します。
人間参加型のトリガー: Cloud Tasks を使用して人間参加型のトリガーシステムを構築し、どの抽出に重点を置いてダブルチェックすべきかを示します。

ドキュメントの抽出を今すぐ簡単に

この実践的なアプローチは、堅牢なルールベースのドキュメント抽出パイプラインを構築するための確かな基盤となります。このアプローチを採用する際は、以下のリソースをご覧ください。

Gemini によるドキュメントの理解: ドキュメント処理のニーズに対応する包括的なワンストップソリューションをお求めの場合は、Gemini によるドキュメントの理解をご覧ください。これにより、抽出に関する一般的な課題を単純化できます。
少数ショットプロンプト: Gemini の利用を開始するにあたり、はじめに少数ショットプロンプトを試すのは良い方法です。このパワフルな手法では、プロンプト自体に例を含めることで、最小限の労力で抽出の品質を大幅に向上させることができます。
Gemini モデルのファインチューニング: 専門性の高い分野固有の抽出結果が必要な場合は、Gemini モデルのファインチューニングを検討してください。要件を厳密に満たせるようにモデルのパフォーマンスを調整できます。

-生成 AI 担当フィールドソリューションデベロッパー Meenu Bondili
-生成 AI フィールドソリューションアーキテクトマネージャー Jonathan Chen

投稿先

https://storage.googleapis.com/gweb-cloudblog-publish/images/hero_image_ryohinkeikaku_horizontal.max-700x700.jpg

Customers

無印良品が Recommendations AI で実現する「感じ良い」個客体験

執筆者: Google Cloud Japan Team • 所要時間: 2 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/Next_generation_customer_engagement.max-700x700.jpg

AI & Machine Learning

AI エージェントと次世代の Customer Engagement Suite でカスタマーエクスペリエンスを変革

執筆者: Duncan Lennox • 所要時間: 4 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/hero_image_tbs_horizontal.max-700x700.jpg

Customers

TBSテレビ: Gemini 1.5 Pro / 2.0 Flash で映像メタデータの自動生成を世界に先駆けて実現、作業効率化とクリエイティブな業務への注力も促進

執筆者: Google Cloud Japan Team • 所要時間: 3 分

AI & Machine Learning

GKE 上の NVIDIA BioNeMo Framework と Blueprint を使用してヘルスケアにおける AI を加速

執筆者: Sujit Khasnis • 所要時間: 6 分

Gemini 2.0 を使用してドキュメントの抽出を高速化し、費用を削減する

Meenu Bondili

Jonathan Chen

ドキュメント抽出のマルチステップ アプローチを簡単に

ステップ 1: 抽出

ステップ 2: 抽出されたデータをルールエンジンにフィードする

ステップ 3: 分析情報を統合する

ドキュメントの抽出を今すぐ簡単に

関連記事

無印良品が Recommendations AI で実現する「感じ良い」個客体験

AI エージェントと次世代の Customer Engagement Suite でカスタマー エクスペリエンスを変革

TBSテレビ: Gemini 1.5 Pro / 2.0 Flash で映像メタデータの自動生成を世界に先駆けて実現、作業効率化とクリエイティブな業務への注力も促進

GKE 上の NVIDIA BioNeMo Framework と Blueprint を使用してヘルスケアにおける AI を加速

ドキュメント抽出のマルチステップアプローチを簡単に

AI エージェントと次世代の Customer Engagement Suite でカスタマーエクスペリエンスを変革