Simplico
AI City

LLMで洪水は予測できるのか:洪水予測でAIが実際に担う役割と、ドローン・量水標カメラの使いどころ

September 27, 2026

2026年9月末のバンコク浸水以降、在タイの日系工場や工業団地の方々から同じ質問を何度もいただいています。ChatGPTやClaudeのような生成AIで、次の洪水を予測できないのか?

答えは二つに分かれます。LLM単体は、水位を予測する道具としては適していません。一方でLLMは、予測の周辺にあるほぼすべての業務にとても有効です。そして多くのプロジェクトが過小評価しているのはAIそのものではなく、予測が依存している水位データです。

本稿では、実際に洪水を予測している手法、水位データが真のボトルネックである理由、ドローンが役立つ場面と役立たない場面、そしてLLMがシステムのどこで価値を発揮するかを整理します。先に公開した二本の記事——信号をケースと対応手順に変える「洪水対応をSOCのように運用する」と、排水網そのものをモデル化する「排水網のデジタルツイン」——に対し、本稿は「計測とAI」を扱う位置づけです。

関連サービス

1. LLMが水位予測に向かない理由

洪水予測とは、物理的な問いに対する数値の答えです。この降雨、上流からの流入、土壌水分、地形のもとで、この観測点の、この時刻の水位はいくつになるか。答えは流域と河道の中を水がどう動くかから導かれます。

LLMはテキストを予測するよう訓練されています。「木曜日に工場前の水路は溢れるか」と聞けば、流暢で自信のありそうな答えが返ってきます。しかしそこには、リアルタイムの水位データも、その流域のモデルも、自分の誤りに気づく手段もありません。一般的な質問なら不便で済みますが、洪水警報では危険です。もっともらしい誤った数値は、数値がないより悪いからです。

第一の原則はシンプルです。LLMに水位を作らせない。 警報に含まれるすべての数値は、センサーの計測値か予測モデルの出力までたどれる必要があります。

2. 実際に洪水を予測している手法

手法 概要 強み 限界
物理ベースのモデル SWMMやHEC-RASなどの水文・水理シミュレーション 説明可能。ポンプ、水門、背水を扱え、what-ifに答えられる 較正、排水網データ、水文の専門家が必要
時系列の機械学習モデル 降雨と水位の履歴で学習したLSTMなど 記録が充実した河川で高精度、高速 学習には複数年分の観測データが必要
時系列基盤モデル TimesFMやChronosなどの事前学習モデル 記録が短くてもゼロショットで一定の予測が可能 水文学を理解しているわけではなく、あくまでベースライン
LLM 汎用の言語モデル 説明、翻訳、要約、データに基づく質疑応答 水位は予測しない

最もよく知られたAI洪水予測システムは、表の2行目の好例です。GoogleのFlood HubはLSTMモデルで動いており、Nature論文は、観測所のない流域において最大5日先までのAI予測が、世界的な主要システムの当日予測と同程度の信頼性を持つことを示しました。Google Researchの解説によれば、80か国以上の河川について最大7日先の予測を提供しています。

この研究から、現地システムを計画する立場で押さえるべき点が二つあります。

  • 学習データは5,680か所の流量観測所から得ている。 最先端のAI予測も、観測所の記録の上に成り立っています。
  • 対象は河川の外水氾濫。 Google自身、鉄砲水と都市型水害は今後の課題としています。工場周りの排水路、自治体の水路、小さな支川は、まさに全球の河川モデルが解像しない場所です。

時系列基盤モデルについても一言。Chronosが興味深いのは、言語モデルの構造を借りている点です。時系列をトークンに変換し、次のトークンを予測します。「水位を予測するLLM」に最も近い存在ですが、それはチャットボットではなく数値に特化したモデルです。

3. 本当のボトルネックは水位データ

表のどの手法も、同じ入力を必要とします。関心のある地点での、頻度が高く信頼できる水位データです。

タイの国レベルのデータは大きく改善しました。Flood SOCの記事で紹介した通り、ThaiWaterは数十の機関のデータを統合しています。しかし国の観測所は、国レベルの判断のための配置です。工場の外周排水路、放流先の水路、2km上流の支川は、多くの場合ペンキで目盛りを描いた量水標を人が目視で読んでいるだけです。一日に一、二回、あるいはまったく読まれず、嵐の夜に読まれることはまずありません。

日本の読者には、この課題は馴染みがあるはずです。国内でも中小河川の水位把握は長年の課題で、国土交通省は低コストの危機管理型水位計や簡易型河川監視カメラの普及を進めてきました。発想は同じです。高価な本格観測所を増やすのではなく、「必要な場所の水位を、安く、頻繁に、見える形で」取ることです。

予測モデルは準備ができているのに、現地のデータが追いついていない。このギャップを埋める方法は三つあります。

4. 水位を取得する三つの方法

固定式水位センサー 量水標を読む固定カメラ ドローン調査
仕組み 水面上の電波式または超音波式センサー IPカメラが量水標を撮影し、画像認識で水位を読む ドローンがルートを飛行し、量水標と周辺を撮影
更新頻度 1〜15分ごと 1〜15分ごと 多くても一日数回
豪雨・強風時 可 防雨ハウジングと照明があれば可 多くの場合不可
夜間 可 赤外線照明があれば可 制約あり
カバー範囲 一点 一点+画像記録 広域。量水標のない場所も
人による確認 難しい(数値のみ) 容易(全計測に画像) 容易
最適な用途 予測用の連続データ 証拠付きの連続データ 浸水範囲の把握、検証、流量計測

要点はこうです。洪水予測には連続データが必要で、ドローンが生むのはスナップショットです。 河川は、飛んでいない1時間のうちに、飛んでいた一日全体より大きく上昇することがあります。そして最もデータが必要な豪雨と強風の時こそ、ドローンは安全に飛べません。

したがって背骨になるのは固定センサーと量水標カメラです。ドローンは、固定点ではできないことで価値を発揮します。

  • 浸水範囲のマッピング。 オルソ画像で実際に浸水した範囲がわかり、予測が当たったかを検証する最良の手段になります。
  • 量水標のない地点の水面標高を、写真測量やLiDARで取得。
  • 表面流速の計測。 動画からLSPIV(large-scale particle image velocimetry)という手法で求め、測量済みの河道断面と組み合わせれば流量が得られます。水文の専門家が必要とするのは、水位だけでなく流量です。
  • 固定センサーの点検・較正、出水後の護岸・水門・吐口の点検。

タイでドローンを定常的に運用するなら、法令対応の工数も見込んでください。カメラ付きドローンはCAATとNBTCの両方への登録が必要で、運航者は第三者賠償責任保険に加入しなければなりません。飛行は原則として目視内・日中に限られ(特別な許可がある場合を除く)、人が映り込む映像にはPDPA(タイ個人情報保護法)が適用されます。日本の本社で航空法の手続きに慣れている方も、タイでは別の手続きになる点にご注意ください。飛行制限区域は特に国境付近で変わるため、作業のたびに最新のCAATの規則を確認する必要があります。

5. 画像から量水標を読む:画像認識が主、LLMはセカンドオピニオン

画像が固定カメラ由来でもドローン由来でも、ピクセルを水位に変換する仕組みが必要です。選択肢は二つあり、組み合わせるのが最善です。

専用の画像認識モデル——自社の量水標で学習させた検出・セグメンテーションモデル——が量水標と水際線を見つけ、水位を読みます。高速で、画像あたりのコストが低く、結果が安定し、信頼度スコアも得られます。これを主たる読み取り手段にします。

マルチモーダルLLMも、学習なしでプロンプトだけで量水標の写真を読めます。試作には非常に便利で、反射、漂流物、一部が水没した量水標など難しい画像のセカンドオピニオンとして有用です。ただし遅く、画像あたりのコストが高く、自信満々に誤読することがあります。写真と洪水アラートの間に立つ唯一の判断者にしてはいけません。

両者を組み合わせるロジックは小さいですが、正しく作る価値があります。

from dataclasses import dataclass
from datetime import datetime

MIN_CONFIDENCE = 0.85   # below this, the CV reading needs a second opinion
AGREE_M = 0.05          # CV and second reader must agree within 5 cm
MAX_RATE_M_PER_H = 0.6  # tuned per station from its flood history

@dataclass
class GaugeReading:
    station: str
    level_m: float | None
    confidence: float
    image_path: str
    taken_at: datetime

def triage(reading, previous, second_reader):
    """Decide whether an image-based gauge reading can feed the forecast."""
    if reading.level_m is None:
        return "human_review"                      # gauge not found in image
    if reading.confidence < MIN_CONFIDENCE:
        second = second_reader(reading.image_path)   # multimodal model
        if second is None or abs(second - reading.level_m) > AGREE_M:
            return "human_review"
    if previous is not None:
        hours = (reading.taken_at - previous.taken_at).total_seconds() / 3600
        if hours > 0 and abs(reading.level_m - previous.level_m) / hours > MAX_RATE_M_PER_H:
            return "urgent_verify"                 # misread, or a real surge
    return "accept"

最後のチェックに注目してください。その観測点で過去に例のない速さの上昇は、誤読かもしれませんし、本当の洪水かもしれません。黙って捨ててはいけません。画像を添えて至急人に回します。Flood SOCの記事で述べた「沈黙したセンサーもシグナルとして扱う」のと同じ原則です。

6. LLMが価値を発揮する場所

信頼できる計測値が本来の予測モデルに流れるようになって初めて、LLMは得意な仕事を担えます。

  • 予測を「人が動ける警報」に変える。 「観測点7は03:00に4.2mを超える見込み」を、日本語、タイ語、英語、ミャンマー語で、日本人駐在員、ラインのリーダー、タイ人スタッフそれぞれに合わせた明確なメッセージにします。数値はモデルから差し込み、LLMには生成させません。
  • データへの自然言語インターフェース。 担当者が「直近6時間で最も上昇が速い観測点は?」「昨年10月と比べて今日はどうか?」と尋ねると、LLMがデータベースと予測ツールを呼び出し、その結果に基づいて答えます。
  • 非構造データの読み取り。 従業員や住民からのLINEの写真とメッセージ、現場報告、ニュース、SNS投稿から、場所・時刻・深刻度を、人が読むよりはるかに速く抽出します。
  • 自社文書に基づく回答。 避難計画、ダムの操作規則、BCP手順書、過去の出水報告をRAGで検索可能にし、自社の手順に根拠を持つ回答にします。
  • ドローン調査の報告書作成。 飛行ごとの所見を、日本本社や経営層向けの短い報告にまとめます。

データ管理に厳しい日系企業では、このLLM層はオンプレミスで動かすべきです。センサーデータ、従業員の連絡先、社内計画が自社インフラの外に出ません。

7. アーキテクチャ

flowchart TD
    S1["電波式と超音波式の水位センサー"] --> Q["計測値の検証と振り分け"]
    S2["量水標を撮影する固定カメラ"] --> CV["画像認識による量水標読み取り"]
    S3["ドローン調査画像"] --> CV
    CV --> Q
    VLM["マルチモーダルモデルによるセカンドオピニオン"] --> Q
    Q -->|採用| DB["時系列データストア"]
    Q -->|要確認| HR["画像付きで人が確認"]
    P["ThaiWaterと降雨予測"] --> DB
    DB --> FM["予測モデル 機械学習または水理"]
    FM --> AL["警報ルールとFlood SOCのケース"]
    S3 --> MAP["浸水範囲と流量のマッピング"]
    MAP --> FM
    AL --> LLM["オンプレミスのLLM層"]
    DB --> LLM
    LLM --> OUT1["LINEとSMSによる多言語警報"]
    LLM --> OUT2["担当者向け質疑応答"]
    LLM --> OUT3["出水報告と調査報告"]

上から順に読んでください。センサーとカメラは検証ステップに入り、採用された計測値だけが予測モデルに届きます。予測が警報ルールを動かし、LLMは最後段で説明と伝達を担います。最初段で数値を作ることはありません。

8. 提供済みのもの、個別構築するもの、対象外のもの

現在提供しているもの:

案件ごとに構築するもの(パッケージ化された洪水製品はありません):

  • 貴社の量水標で、昼夜それぞれ学習・検証する画像認識の読み取りモデル。
  • 計測値の振り分けロジック、閾値、人による確認のワークフロー。
  • 予測モデルの統合。時系列機械学習、基盤モデルによるベースライン、またはパートナーの水理モデルを、貴社の観測点で較正します。
  • 有資格のドローン運航者と連携した、浸水範囲・水位・流量のドローン画像処理パイプライン。
  • 対象言語と受け手に合わせたLLMのプロンプト、ツール、メッセージテンプレート。

対象外:

  • ドローンの飛行、ドローン・センサーのハードウェア供給。有資格の運航者とハードウェアパートナーと協業します。
  • 公式の警報と避難指示。引き続きタイ防災局(DDPM)、タイ気象局、地方自治体の権限です。
  • 認証された水文予測と技術的承認。有資格の水文・土木技術者の領域です。

よくある質問

ChatGPTやClaudeに、今週この地域が浸水するか聞けますか?
信頼できる答えは得られません。リアルタイムの水位データと予測モデルなしでは、LLMはもっともらしい推測しか返せません。数値は公式予測と自社センサーから取り、LLMはその説明と伝達に使ってください。

Google Flood Hubで十分では?
大河川については有用な入力です。ただし対象は河川の外水氾濫で、Google自身が鉄砲水と都市型水害を今後の課題としています。敷地の排水路、水路、小さな支川には、現地の計測点が必要です。

ドローンとカメラ、どちらを先に導入すべきですか?
予測が目的なら、連続記録が取れる固定センサーと量水標カメラが先です。ドローンはマッピング、検証、流量計測のために追加します。

マルチモーダルLLMで量水標は読めますか?
はい、多くの場合うまく読めますし、試作の近道になります。本番では学習済みの画像認識モデルを主とし、マルチモーダルモデルはセカンドオピニオンに。両者が食い違えば必ず人が確認します。

データを社外に出す必要はありますか?
ありません。LLM層はオンプレミスで動かせ、センサーデータ、画像、連絡先は自社インフラ内にとどまります。

最初のプロジェクトはどんな形ですか?
小さく始めます。一つの水路の数か所の量水標にカメラかセンサーを付け、検証済みの時系列を作り、予測手法を一つ、警報チャネルを一つ。実際の雨季で調整してから拡大します。

ご相談ください

貴社の拠点や周辺地域にとって重要な量水標の一覧を、各地点の昼と夜の写真1枚ずつとともにお送りください。あわせて、現在は誰がどのくらいの頻度で読んでいるかも教えてください。どの地点にカメラを付けるか、どこにセンサーが必要か、どこでドローン調査が効くか、手元のデータに合う予測手法は何か——小さく始める計画をご提案します。日本語でのご相談も可能です。

関連記事

すべての記事を読む →

メール:hello@simplico.net

出典:

最新の記事

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch