洪水対応をSOCのように運用する：タイ進出日系工場のための「Flood SOC」検知・対応設計

2011年のタイ大洪水を、タイに拠点を持つ日系製造業の多くはいまも鮮明に記憶しています。アユタヤとパトゥムタニの工業団地が浸水し、サプライチェーンの寸断は日本国内の生産にまで波及しました。

あれから15年。2026年7月、タイ政府は水文情報研究所(HII)が運営する国家水情報プラットフォーム「ThaiWater」を刷新しました。新バージョンは13省56機関のデータを統合し、雨量レーダー、水位、ダムの状況、警戒区域を一枚のインタラクティブマップに集約。全76県の県別水情報サイトも公開されています。

機関ごとにバラバラで食い違っていた水データという、長年の課題はようやく解消に向かっています。しかし、データが揃ったことで次の課題がはっきりしました。セキュリティ運用に携わる方なら、すぐに気付くはずの課題です。

データがあることと、行動できることは別物です。 深夜3時に上流の水位が上がり始めても、それに気付き、自社拠点にとって重要かを判断し、ケースを起票し、適切な担当者を起こし、正しい手順を発動する仕組みがなければ意味がありません。しかも、流域で雨が降るたびに担当者を起こすようでは運用が続きません。

これはまさに、SOC(セキュリティ・オペレーション・センター)が解決するために存在する問題です。本稿では、サイバー脅威向けに構築してきた検知・対応の型を水害に適用する「Flood SOC」の考え方を解説します。

1. 洪水とサイバー攻撃は、運用上同じ形をしている

ドメインを取り除けば、SOCがやっていることは5つです。多数のノイズの多いソースから信号を集め、相関させて意味のある事象にし、深刻度を評価し、対応をケースとして追跡し、初動を自動化する。洪水対応にも、この5つすべてが必要です。

SOCの概念	洪水対応での対応物
ログソース(FW、端末、VPN)	水位センサー、雨量計、レーダー、CCTV、住民からの通報
SIEMでの取り込みとデコード	センサーと公的データを単一のイベント形式に正規化
相関ルール	「上流が急上昇 かつ 大雨予報 かつ 下流の水門が停止中」
不可能な移動(impossible travel)検知	到達時間の予測:上流の増水はいつ自社に届くか
リスクスコアと深刻度	拠点固有の洪水リスクスコア
ケース管理(DFIR-IRIS)	1回の洪水事象=1ケース、タイムラインと責任者付き
SOARプレイブック	周辺への通知、工場BCPの発動、現場チームの派遣
アラート疲れとチューニング	誤報が続き、警報が無視されるようになる
エージェント沈黙アラート	豪雨の最中に通信が途絶えたセンサー

最後の2行は見た目以上に重要です。多くの洪水警報プロジェクトは、センサーではなくこの2点で失敗します。

2. 2011年の教訓:損害を負ったのは誰だったか

2011年の洪水による被害・損失総額は1.43兆バーツ(約465億米ドル)に達しました。見落とされがちなのは、その約7割を製造業が負担したことです。アユタヤとパトゥムタニの6つの工業団地が浸水したためで、被害・損失全体の約9割は民間部門が負いました。

中部平野の洪水は移動が遅く、理論上は多くの工場に数日の猶予がありました。欠けていたのは、県レベルの情報を拠点レベルの判断に変換する仕組みです。いま在庫を移す、いま安全にラインを止める、いま顧客に連絡するという判断です。

国家プラットフォームが個々の工場の代わりにその判断を下すことはできません。Flood SOCにはそれができます。ルールが一つの敷地、一つの資産群、一つのBCP手順のために書かれているからです。

3. アーキテクチャ

flowchart TD
    S1["河川・水路の水位センサー"] --> N["正規化とエンリッチメント"]
    S2["雨量計とレーダー"] --> N
    S3["ThaiWaterと県別水情報"] --> N
    S4["CCTVによる量水標の読み取り"] --> N
    S5["LINEでの住民通報"] --> N
    H["センサー死活監視"] --> R
    N --> R["相関とリスクスコアリングエンジン"]
    R -->|低スコア| L["記録のみ"]
    R -->|中スコア| C["洪水ケースを起票"]
    R -->|高スコア| P["ケース起票と当番者の呼び出し"]
    C --> I["DFIR-IRISでのケース管理"]
    P --> I
    I --> PB["SOARによるプレイブック実行"]
    PB --> A1["多言語のLINEとSMS通知"]
    PB --> A2["工場BCPの発動"]
    PB --> A3["現場チーム向けTAK地図"]

この図の構成要素は、すべて本番稼働中のSOCにすでに存在します。変わるのは、入ってくるデータと、出ていくプレイブックだけです。

信号層。 水路、橋、敷地周辺の排水路に設置した低コストのレーダー式・超音波式水位センサーを、LoRaWANやNB-IoTで接続します。ThaiWaterや県別水情報センターの公開データは、データ提供元の利用条件の範囲で取り込みます。既存のCCTVで量水標を読み取り、住民や従業員からの通報は写真と位置情報をLINE公式アカウントで受け付けます。

相関層。 正規化処理ですべてのソースを単一のスキーマ(観測所、区間、値、変化率、時刻)に揃えます。相関エンジンは状態を保持する必要があります。ステートレスなルールエンジン単体ではできない部分で、サイバー側でもWazuhではなくSOCインテグレーターが複数イベントの相関と重複排除を担うのと同じ理由です。

対応層。 DFIR-IRISがケースを保持し、Shuffleがプレイブックを実行します。現場との連携では、ケースをTAKの共通作戦図に送ります。この部分は「TAKシステムが洪水災害対応を変革する」で解説しました。Flood SOCは、TAKをいつ起動するかを決める層です。

4. 検知ルール:閾値から相関へ

レベル1 — 閾値。 「観測所Xの水位がYを超えたら通知」。多くの地域の警報システムはこの段階です。ないよりは良いものの、ノイズが多くなります。

レベル2 — リスクスコアリング。 弱い信号を複数組み合わせ、説明可能な一つのスコアにします。河川沿いの工場の例:

信号	スコア
上流観測所が毎時20cm超で上昇	+35
最寄り観測所で堤防天端までの余裕が50cm未満	+30
流域に24時間90mm超の非常に強い雨の予報	+20
下流の水門またはポンプ場が停止中	+15
30分以内に半径1km圏で住民通報が2件以上	+15

70以上は重大(ケース起票+当番者呼び出し)、40〜69はケース起票のみ、40未満は記録のみとします。

数値はあくまで例示です。 実際の重み付けと閾値は、拠点の浸水履歴、水文専門家の知見、そして何より実際の降雨でのチューニングから決まります。

レベル3 — 状態を持つ相関。

• 「不可能な移動」ではなく「到達予測」。 SOCでは、移動が物理的に不可能な2回のログインを検知します。Flood SOCでは、上流観測所の増水と、その区間の過去の流下時間から、下流への到達時間帯を予測します。通知は「どこかで水位が高い」ではなく「9〜14時間後に敷地境界へ到達見込み」になります。
• 重複排除。 同じ区間でケースが開いていれば、新しい観測値は既存ケースに追記します。これがないと、一度の豪雨で50件のケースが生まれ、誰も読まなくなります。
• 傾向によるエスカレーション。 「中」のまま推移しているケースでも、上昇速度が加速すれば自動で再評価します。

エンジンの判定結果は、SOCの判定とほぼ同じ形です。

{
  "decision": "create_case_and_page",
  "severity": "critical",
  "risk_score": 80,
  "reach": "upstream-bridge-to-estate-north-gate",
  "reason": "Upstream rise 28 cm/h, bank crest margin 40 cm, very heavy rain forecast",
  "predicted_arrival_hours": [9, 14],
  "playbook": "estate-bcp-level-2"
}

5. 沈黙もシグナルである

SOCでは、ログ送信が止まったエージェント自体がアラート対象です。simpliSOCはこの機能をログソース向けにすでに提供しており、設定した時間内にイベントが届かなければ通知します。

洪水監視では、このルールはさらに重要です。センサーは、まさに必要なときに故障します。停電、ソーラーパネルへの漂流物、携帯基地局の停止、あるいは水位がセンサー自体を超えることもあります。豪雨の最中に「2時間前:水位正常」と表示し続けるシステムは、システムがない状態より危険です。Flood SOCでは、周辺観測所が上昇している中で沈黙した観測所をスコアに加算し、エスカレーションします。

6. チューニング:誤報の多い警報は、警報がないより悪い

昨年3回誤った避難通知を受け取った住民や従業員は、今年は動きません。導入直後の数週間は、SOC導入時と同じくチューニング期間です。誤報をすべて記録し、重みと閾値を調整し、既知の無害パターン(毎夕の潮位による上昇、保守作業中の異常値など)を抑制してから、通知対象を広げます。

7. 日系企業にとっての論点:BCPとサプライチェーン

BCPの「発動条件」をデータで定義する。 多くの在タイ日系工場のBCPには、洪水時の手順は書かれていても、「いつ発動するか」は担当者の判断に委ねられています。Flood SOCは、リスクスコアとプレイブックを結び付けることで、発動条件を事前に合意された、監査可能なルールにします。ケース管理のタイムラインは、誰がいつ何を判断したかの記録として、日本本社への報告にもそのまま使えます。

サプライチェーン強靭化の文脈。 経済安全保障推進法をはじめ、供給網の途絶リスクへの関心は高まっています。タイ拠点の洪水リスクをリアルタイムに把握し、顧客や本社への連絡をプレイブック化することは、その具体的な一手になり得ます。

センサー網もサイバー攻撃面になる。 偽の水位データが注入されれば、不要な操業停止や、逆に本当の危険の見落としにつながります。水害監視とサイバー監視を一つの運用センターで扱う利点はここにもあります。

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

現在提供しているもの:

• simpliSOC:Wazuhによる検知、DFIR-IRISによるケース管理、Shuffleによる自動化、相関・重複排除・深刻度マッピングを担うインテグレーター。Docker Composeでオンプレミスに展開。
• 送信が途絶えたログソースの沈黙アラート。
• TAKインテグレーション(サービス提供)。ケースやアラートを共通作戦図へ連携。

案件ごとに構築するもの(パッケージ機能ではありません):

• センサーの取り込み、デコーダー、洪水イベントの正規化スキーマ。
• 拠点に合わせた相関ルール、リスクスコア、到達予測ロジック。
• ThaiWaterや県別水情報とのコネクター(データ提供元の利用条件に従う)。
• LINE公式アカウントでの通知フローと多言語テンプレート(日本語・タイ語・英語・ミャンマー語など)。
• 工場BCPのプレイブックとERP連携(浸水リスクのある在庫のフラグ付けなど)。
• 現場デバイス向けの死活監視ルール。

対象外:

• 公式の警報や避難指示。これらはタイ防災局(DDPM)、気象局、地方自治体の権限です。Flood SOCは意思決定を支援するものであり、公的警報を置き換えるものではありません。
• 公的な水文予測の提供。予測や過去の流下時間を取り込みますが、予報機関ではありません。
• センサーハードウェアの製造。ハードウェアパートナーの機器を統合します。

よくある質問

「Flood SOC」は既製品として販売しているのですか?
いいえ。既存のコンポーネント(simpliSOC、インテグレーター、TAKインテグレーション)と、拠点ごとの構築作業(センサー、ルール、プレイブック、チューニング)を組み合わせた参照アーキテクチャです。

ThaiWaterや公的警報の代わりになりますか?
なりません。ThaiWaterは最も重要な入力の一つです。Flood SOCは、自社敷地のためのルール、ケース、責任者、手順という運用層を加えるものです。

Wazuhで本当に水位データを扱えるのですか?
Wazuhは構造化されたJSONイベントをデコードできるため、センサー値を流すことは可能です。ただし、上昇速度や流下時間、区間ごとの状態といった水文的な相関は、サイバー側の状態を持つ相関と同様にインテグレーター層で扱います。役割分担は案件ごとに決めます。

データはどこに保存されますか?
simpliSOCと同様、オンプレミスまたは貴社のプライベートクラウドです。センサーデータや連絡先リストを社外に出す必要はありません。

最初のプロジェクトはどの程度の規模ですか?
一拠点、数台のセンサー、一つの公的データフィード、一つの通知チャネルから始め、実際の降雨でチューニングしてから拠点や通知対象を広げます。

ご相談ください

2011年に浸水した拠点、あるいは昨年の雨季に危うかった拠点をお持ちでしたら、敷地図、リスクとなる河川・水路、そして深夜3時に起こすべき担当者を教えてください。どの信号を集め、どのルールから始め、どのプレイブックを最初に動かすか、小さく始める計画をご提案します。日本語でのご相談も可能です。

メール:hello@simplico.net
simpliSOC と TAKインテグレーション の詳細もご覧ください。

---

出典:

• All-in-One Page: Government Revamps ThaiWater App — Thairath English, 2026年7月17日
• 2011 Thailand Floods — Rapid Assessment for Resilient Recovery and Reconstruction Planning — PreventionWeb / 世界銀行
• 現代 SOC における Automated Decision Logic の構築方法 — Simplico
• TAKシステムが洪水災害対応を変革する — Simplico