Google ResearchのGroundsourceを読み解く ─ AIで非構造データから構造化知識を作る技術

はじめに

LLM を「回答生成」ではなく「データ生成」に使うと、AI 活用の幅はかなり広がります。

こんにちは。GovTech東京 AIイノベーショングループの本城です。今回は、その具体例として Google Research が公開した Groundsource を取り上げます。

Groundsource は、ニュース記事のような非構造テキストから「何が起きたか」「いつか」「どこか」を抽出し、再利用可能な構造化データセットを作る取り組みです。面白いのは、AI が記事を読んで「答える」のではなく、予測や分析に使える「データ」を生成している点です。

この記事では、このアプローチの技術的な仕組みと設計の工夫を解説します。

Groundsourceとは何か

Google Research の説明によると、Groundsource は、ニュースや公開レポートのような非構造データを Gemini で解析し、構造化された知識データへと変換する仕組みです。その具体的な適用例として洪水分野では、ニュース記事から洪水イベントを抽出し、さらに Google Maps Platform を使って地理情報を付与することで、再利用可能な履歴データセットを構築しています。Google はこのデータを用いて、都市部の鉄砲水を最大24時間前まで予測する新モデルを訓練したと説明しています。

Google Research のブログによると、データ生成は次のような流れで行われています。

図: Groundsource のデータ生成パイプライン全体像（Google Research ブログより）

もう少し具体的に見ると、Gemini による抽出は段階的なプロセスになっています。

まず 分類（Classification） として、記事が「実際に起きた、あるいは進行中の洪水」を報じているかを判定します。将来の警告や政策会議、リスクモデリングに関する記事はここで除外されます。

次に 時間抽出（Temporal Extraction） として、「先週の火曜日」のような相対的な時間表現を、記事の公開日を基準にして具体的な日付に変換します。

さらに 空間抽出（Spatial Extraction） として、近隣地区や街路レベルの粒度で場所を特定します。続く 場所照合（Location Reconciliation） で、抽出された場所名を WebRef^[1] の候補地名と照合し、Google Maps Platform を通じて標準化された空間ポリゴン^[2]へマッピングします。

この手法で500万件超のニュース記事から260万件の洪水イベントが抽出されました。これらは後述する品質検証を経て、最終的なデータセットとして整備されています。

重要なのは、個々の記事を要約して終わるのではなく、記事群から「何が起きたか」「いつか」「どこか」を取り出し、別用途でも使えるデータに変えていることです。

非構造データから構造化された知識を作り、それを下流のモデルや分析へつなげる。この使い方こそが、Groundsource の本質だといえます。

パイプライン詳解

前のセクションでは Groundsource の全体像を俯瞰しました。ここでは、パイプラインの各ステップをもう少し掘り下げて、設計の工夫や技術的なポイントを考えてみます。

段階的抽出の設計思想

Groundsource: A Dataset of Flood Events from News（以下「論文」）によると、Gemini による抽出は単一の structured prompt^[3] によって行われています。このプロンプトは「分類（Classification）→ 時間抽出（Temporal Extraction）→ 空間抽出（Spatial Extraction）→ 場所照合（Location Reconciliation）」の4つの分析ステップを順に踏ませる設計になっており、最終的に JSON 形式で結果を返します。Location Reconciliation は、Gemini が抽出した場所名を WebRef の候補地名と照合し、正しい地理エンティティに紐づけるステップです。その後、Google Maps Platform を用いて空間ポリゴンへのマッピングが行われます。

つまり、複数のプロンプトに分割して処理するのではなく、単一のプロンプト内で段階的な分析手順を踏ませることで、一貫した文脈のもとで構造化抽出を行っているわけです。

この段階的設計の意図は公開情報では明示されていません。しかし、技術的に見ると以下のような合理性があります。

まず、各分析ステップの精度を独立に検証できることです。structured prompt は各ステップの結果を JSON のフィールドとして返すため、分類の精度、時間抽出の精度、空間抽出の精度をそれぞれ測定でき、どこがボトルネックになっているかを特定しやすくなります。

次に、分類を最初に置く設計も合理的です。パイプライン設計の定石として、ノイズ除去は上流で行うのが鉄則です。洪水と無関係な記事や、将来の警告・政策会議に関する記事を最初に除外することで、後続の時間抽出や空間抽出にかかる処理コストとエラーを大幅に削減できます。

また、80言語の記事を英語に翻訳してから抽出にかけている点も注目に値します。LLM の性能は一般に英語で最も高く、プロンプトを単一言語で統一できるメリットも大きい。80言語分のプロンプトを個別に最適化するのは現実的ではありません。

入力から出力への変換過程

Google Research のブログによると、入力は80言語のニュース記事・公開レポートで、500万件超が処理されています。これらは Cloud Translation API で英語に翻訳された後、Gemini による抽出を経て、最終的に260万件の洪水イベントレコードが生成されています。対象は150か国以上、2000年から現在までの期間をカバーしています。

論文で公開されているデータセットには uuid, area_km2, start_date, end_date, geometry といった列が含まれています。これらは洪水イベントの一意識別子、影響範囲の面積、発生期間、空間ポリゴンに対応しており、予測モデルの訓練に使える構造になっています。

前処理について、論文では具体的な手法が説明されています。Google の Read Aloud user-agent を使って Web ページから記事本文と公開日を抽出し、WebRef を用いて本文中の地名候補を特定しています。つまり、汎用の HTML パースライブラリではなく、Google のインフラを活用した前処理パイプラインが構築されています。記事の公開日は時間抽出の基準点として不可欠なため、この段階で確実に抽出されています。

もう一つ触れておきたいのは、件数がどのように絞り込まれているかです。論文によると、パイプラインは約950万件の URL から出発し、アクセス可能だった約750万件の記事を取得し、そこから Gemini による分類で約500万件が実際の洪水イベント記事と判定され、さらに抽出・フィルタリングを経て最終的に約260万件のレコードが生成されています。つまり、件数の減少は主に分類やフィルタリングによるものであり、重複排除だけで大幅に圧縮されたわけではありません。

実際、論文では「1つの大規模洪水が複数のレコードとして残ることがある」と明記されており、完全な重複排除は行われていないことがわかります。同じ洪水イベントを複数の記事が異なる粒度で報じた場合、それぞれが別レコードとして残り得る設計です。

品質管理・検証アプローチ

Google Research のブログによると、品質検証は2つの方法で行われています。

1つ目は手動レビューです。抽出されたイベントのうち、60%が場所・時間の両方で正確と判定され、82%が実用上十分（正しい行政区画内、またはピーク日から1日以内）と評価されました。

2つ目はGDACS（Global Disaster Alerts and Coordination System）との照合です。2020年から2026年にかけての深刻な洪水イベントの85〜100%を Groundsource が捕捉していることが確認されています。

この二段階の精度評価は、地理空間データの特性を踏まえた合理的な設計です。「完全一致」と「実用上許容可能」を分けて報告することで、用途に応じた判断が可能になります。たとえば、都市部の鉄砲水予測に使うなら街区レベルの精度が求められますが、国・地域レベルのリスク分析であれば行政区画単位で十分です。

大規模パイプラインでは、モデル出力に信頼度スコアを付与し、低スコアのイベントを人手レビューに回すトリアージが一般的です。Groundsource の公開情報では詳細な運用設計までは説明されていませんが、洪水予測モデルの論文（AI learns to forecast global flood events from historical news）でも、手動監査で「偽陽性^[4]と分類されたアラートの多くが実際には検証済みの洪水イベントだった」と報告されており、ニュースベースのデータ特有の検証の難しさがうかがえます。

GDACS 照合の位置づけも興味深いポイントです。260万件のイベントすべてを人手で検証するのは不可能です。そこで、既存の権威的なデータベースを ground truth^[5] として活用し、大規模データの品質を効率的に検証しています。サンプリングによる手動レビューと、既存 DB との照合という二段構えは、大規模 AI パイプラインにおける品質管理の実践的なパターンと言えます。

Google Research は「2000年から現在まで」のデータを対象としており、今後も継続的な更新を前提にした運用が視野に入っていると読めます。いずれにせよ、この規模のデータ生成では、検証と更新をどう回すかが重要になります。

RAGやAIエージェントとどう違うのか

ここまで見てきたパイプラインを、既存のLLM活用パターンと比べると位置づけがよりはっきりします。

ざっくり整理すると、こんな違いがあります。

観点	RAG	Agent	Groundsource型
担当レイヤー	既存データを検索・参照	既存データ＋ツールで処理	非構造データから新たなデータを生成
入力	インデックス済み文書	文書＋外部API/ツール	未整理の非構造データ
出力	自然言語の回答	タスク実行結果	構造化データセット
LLMの役割	検索結果の要約・回答生成	計画・ツール選択・実行制御	情報抽出・分類・構造化

こうして並べてみると、Groundsource 型のアプローチは、RAG や Agent の上流に位置するデータ生成レイヤーという見方ができます。RAG が参照する知識や、Agent が処理する入力データそのものを、非構造データから作り出す役割です。

つまり、RAG や Agent の代替ではなく、それらを補完する関係にあります。Groundsource 型で構造化されたデータがあれば、その上に乗る検索や自動化の仕組みも一段強くなるはずです。

こういうアプローチもあるのだと知っておくと、LLM の活用を考えるときの選択肢が広がると思います。

Groundsourceデータはどう使われているか

Groundsource の技術的な仕組みを見てきましたが、実際にこのデータがどう活用されているかも触れておきます。

Google Research は、Groundsource で生成した260万件の洪水イベントデータを Ground Truth として、LSTM^[6] ベースの洪水予測モデルを訓練しています。このモデルは150か国以上で実運用されており、Google Flood Hub（https://g.co/floodhub）で無料公開されています。

論文によると、このモデルは米国での評価において National Weather Service（NWS）の洪水警報に近い精度（comparable）を達成しています。ただし、これは分類しきい値の選び方に依存し、precision と recall^[7] のトレードオフの中での比較です。NWS は高密度のセンサー網や高解像度レーダーを備えた高度な警報システムですが、Groundsource ベースのモデルはグローバルに利用可能な低解像度の入力データのみで動作する点が特徴です。従来は高価な物理センサーに依存していた地域ごとのモデル調整（キャリブレーション）を、ニュース記事由来の構造化データで代替した形と言えます。

技術的に面白いのは、LLM が生成したデータを別の AI モデルの訓練に使うという構図です。しかも、そのデータをそのまま使うのではなく、下流タスクに合わせた加工が施されています。たとえば、洪水イベントの持続時間を最大3日に制限する、終了日のないイベントは1日として扱う、正例と負例の比率を調整する（正例を20%にアップサンプリング^[8]）といった処理です。LLM 生成データを訓練用に使う際の実践的なノウハウとして参考になります。

一方で、データの限界がそのまま下流タスクに影響する点も興味深い課題です。Groundsource は洪水の種別（河川氾濫、鉄砲水、沿岸洪水など）を区別しないため、予測モデルも全種類の洪水を一括で扱っています。論文ではこれを「limitation and feature at the same time（制約であると同時に利点でもある）」と表現しています。また、ニュースカバレッジが薄い地域（アフリカの一部など）では、Groundsource のデータが少ないために precision（適合率）が過小評価されうる（実際の洪水を捕捉できていないために、正しい予測が偽陽性と判定されてしまう）と論文は指摘しています。データ生成パイプラインのカバレッジの偏りが、下流の予測タスクの評価にも影響するわけです。

おわりに

Groundsource の技術的な仕組みを読み解いてみて、いくつかの学びがありました。

まず、単一プロンプト内での段階的抽出の設計です。分類・時間抽出・空間抽出・場所照合というステップを1つのプロンプトに埋め込み、各ステップの結果を JSON のフィールドとして返すことで、一貫した文脈を保ちつつ各段階の精度を独立に検証・改善できるようになっています。LLM を使ったパイプラインを設計するときに、「構造化された分析手順をプロンプトに組み込む」という手法は広く応用できそうです。

次に、品質管理のアプローチです。サンプリングによる手動レビューと、既存データベースとの照合という二段構えの検証は、大規模な AI パイプラインにおける実践的なパターンとして参考になります。「完全一致」と「実用上許容可能」を分けて評価する考え方も、用途に応じた品質基準の設計に活かせると思います。

そして、LLM が生成したデータで別の AI を訓練するという循環です。Groundsource のデータが洪水予測モデルの Ground Truth として実際に機能し、150か国以上で運用されているという事実は、このアプローチの実用性を強く裏付けています。同時に、データの偏りが下流タスクに伝播するという課題も、今後 LLM 生成データを活用する際に意識しておくべきポイントだと思います。

LLM の活用を考えるとき、「回答生成」だけでなく「データ生成」という選択肢を持っておくと、設計の幅が広がります。個人的に引き続き注目していきたいテーマです。

行政分野にも非構造データは多く存在します。Groundsource が示した段階的抽出や品質検証のパターンは、こうしたデータの構造化にも参考になるはずです。同時に、Groundsource の事例は裏を返せば、元データが人間向けの非構造テキストだからこそ高度な抽出パイプラインが必要になることも示しています。機械可読なフォーマットでの提供や表記の統一といった上流の工夫があれば、下流のAI活用のハードルは大きく変わってきます。

参考文献

• Groundsource データセット論文: Groundsource: A Dataset of Flood Events from News
• 洪水予測モデル論文: AI learns to forecast global flood events from historical news
• Google Research ブログ: Introducing Groundsource: Turning news reports into data with Gemini
• Google Flood Hub: https://g.co/floodhub

脚注

1. Google が開発したエンティティ認識システムで、テキスト中の固有名詞を知識グラフ上のエンティティに紐づける。本記事では、記事本文中の地名を地理エンティティの候補に結びつける前処理に使われている。

2. 地理的な領域を多角形（ポリゴン）の頂点座標で表現したデータ形式。GIS（地理情報システム）で広く用いられる。本記事では、洪水の影響範囲を地図上の領域として表現するために使われている。

3. LLM に対して、出力形式や分析手順を明示的に指定した構造化されたプロンプト。自由応答ではなく、定められた手順と形式に沿って回答させる。本記事では、4つの分析ステップを1つのプロンプトに組み込む設計を指す。

4. 実際には条件を満たさないのに「条件を満たす」と誤って判定すること（false positive）。本記事では、洪水が起きていないのに「洪水あり」と判定するケースを指す。

5. モデルの予測精度を評価するための正解データ。本記事では、Groundsource が生成した洪水イベントデータが洪水予測モデルの訓練における正解データとして使われている。

6. Long Short-Term Memory の略。時系列データの長期的な依存関係を学習できるニューラルネットワークの一種。本記事では、洪水予測モデルのアーキテクチャとして採用されている。

7. precision（適合率）は「モデルが陽性と判定したもののうち実際に正しかった割合」、recall（再現率）は「実際の陽性のうちモデルが正しく検出できた割合」。本記事では、洪水予測の精度評価におけるこの2指標のトレードオフを取り上げている。

8. 訓練データ中の少数派クラスのサンプル数を増やしてクラス間のバランスを調整する手法。本記事では、洪水が発生した正例の比率を20%に引き上げる処理を指す。