災害地理空間解析プラットフォーム全体構想

Last updated at 2026-09-02Posted at 2026-09-02

災害地理空間解析プラットフォーム全体構想

英語表記（仮）: Disaster Geospatial Analysis Platform
文書版: r002
作成日: 2026-09-02
状態: 初期構想・今後の設計の基準

はじめに

突然の激しい雨で、道路や地下空間が短時間のうちに冠水することがあります。真夏の危険な暑さが長く続けば、屋外活動だけでなく、日常生活そのものにも影響が出ます。大きな地震が起きたときは、揺れだけではなく、津波、火災、斜面崩壊、道路寸断へ被害が広がる場合があります。火山も、噴火した瞬間だけを見ればよいわけではなく、平常時から警報や観測の変化を追う必要があります。

いわゆるゲリラ豪雨（局地的な短時間強雨）、台風、猛暑・酷暑、熱中症リスク、河川水位、土砂災害、地震、津波、火山活動などについて、役に立つ情報はすでに数多く公開されています。ただし、気象、河川、地震、火山、道路、避難所、衛星画像などの情報は、提供元ごとのWebサイトやAPIに分かれています。対象範囲、更新時刻、単位、地図の見せ方、訂正の扱いも同じではありません。必要な情報を探すだけで複数の画面を行き来し、全体像をつかむまでに時間がかかります。

こうした中、国の防災体制そのものも大きく変わろうとしています。2026年7月には防災庁設置法が成立・公布され、防災庁の発足に向けた準備が進められています。防災庁は内閣に置かれ、防災に関する基本的な方針や計画、大規模災害への対処、関係行政機関との総合調整、事前防災、技術の研究開発などを担うこととされています。また、中央防災会議も内閣府から防災庁へ移管される予定です。法律は2026年12月31日までの間に政令で定める日から施行されることになっています。

防災行政を横断的に進める体制が整えられていく一方で、実際に災害情報を利用する立場から見ると、情報源そのものは今後も一つになるわけではありません。気象庁、国土交通省、国土地理院、自治体、研究機関、道路管理者、衛星データ提供機関など、それぞれが異なる役割を持ち、異なる形式・周期で情報を提供します。むしろ重要になるのは、これらの情報を出典や時刻、空間的位置とともに結び付け、必要なときに横断して利用できる仕組みです。

そこで、このプラットフォームでは、分散している異常気象や災害情報を一つのWebサイトへ集め、地図と時間軸を使って見渡せるようにします。単に外部サイトへのリンクを並べるのではなく、公開API、観測データ、衛星画像、基礎地図、数値解析結果を共通の仕組みで取り込み、出典、発表時刻、有効期間、品質を確認できる形で扱います。

たとえば、一つの豪雨災害について、

気象レーダーで雨の動きを確認し、河川水位の変化を重ね、土砂災害警戒情報や道路規制を確認し、その後に衛星画像や浸水解析結果を比較する、といった流れを一つの環境で扱えるようにします。地震であれば、震源・震度、地盤条件、津波情報、道路状況、避難所、被害情報を時間と位置で結び付けます。火山であれば、噴火警報だけではなく、観測値、降灰、地形、風向・風速などを組み合わせて状況を追えるようにします。

平常時には地域の特徴や過去の災害を調べ、災害が起きているときには現在の状況を追い、発生後には被害や解析結果を振り返ります。さらに、蓄積した観測データや地理空間情報を数値解析へ渡し、洪水、地震、火山、土砂災害などのシミュレーション結果を再び同じ地図上へ戻すことも想定します。

一般向けの公開地図と、解析担当者向けのWorkspaceを同じデータ基盤でつなぐことが、この構想の出発点です。

このサイトは、気象庁、国や自治体、防災庁などが発表する公式の警報、避難情報、防災情報を置き換えるものではありません。災害時の判断では、必ず各機関が発表する最新の公式情報を確認する必要があります。

このプラットフォームが目指すのは、それらの公式情報へたどり着きやすくするとともに、異なる機関から発表される情報を出典付きで見比べ、地図と時間軸の上で関係を把握し、必要に応じて過去データの確認や数値解析へ進めるための共通の入口をつくることです。

防災庁の設置によって国全体の防災行政を横断的に進める体制が強化されていく中で、データの側でも、組織や情報源の違いを越えて災害情報を扱える基盤が必要になります。この「災害地理空間解析プラットフォーム」は、そのための技術基盤を一つずつ組み立てていくことを目的とします。

構想段階ですので、まだまだ不備な点があります。今後いろいろと調べて構想を固めていきたいと考えています。

1. この文書の位置づけ

この文書は、災害地理空間解析プラットフォームの出発点となる全体構想です。今後の要件整理、基本設計、実装、検証、公開、運用は、ここで決めた目的や境界、データモデル、拡張方針をもとに進めます。

対象は洪水だけに絞りません。局地的な短時間強雨（いわゆるゲリラ豪雨）、台風、猛暑・酷暑、熱中症リスクなどの気象情報も、地震・火山情報と並ぶ初期対象にします。最初の本格的な数値解析は洪水から始めますが、気象、地震、火山についても、情報取得、訂正履歴、時系列表示、地図表示・公開を早い段階から用意します。土砂災害、津波、山林火災、雪害、高潮、強風なども、同じ土台へ無理なく追加できる構成にします。

最初のデータ整備と実証には、日本で公開されている情報を主に使います。ただし、システム名やデータモデル、API、解析エンジンの契約は、特定の国や機関に縛られないようにします。

目指すのは、災害情報を並べるだけのサイトでも、単独で動く数値解析ソフトでもありません。

目指すプラットフォーム

衛星観測、地上観測、公開API、地形・地物、災害情報、数値シミュレーションを一つの地理空間基盤につなぎ、災害の把握から解析、予測、検証、影響評価、公開までをWeb上で一続きに扱えるプラットフォームを作ります。

2. 最終的な目標

完成したときには、過去の記録、現在の観測・発表、将来の予測やScenarioを同じ基盤で扱えるようにします。

利用者はブラウザ上で、次の流れに沿って情報を確認し、必要な解析を進められます。

対象地域または災害イベントを選ぶ
    ↓
関連する公開情報・観測・衛星データを検索する
    ↓
データの取得元、時刻、品質、利用条件を確認する
    ↓
必要に応じて解析モデルとシナリオを選ぶ
    ↓
解析を実行する
    ↓
地図、時系列、統計、影響範囲を確認する
    ↓
観測結果や衛星推定結果と比較する
    ↓
承認された成果だけをWebやAPIで公開する

3. このプラットフォームが必要な理由

災害に関する情報は、すでに多くの機関から公開されています。ただ、実際に一つの地図や解析へまとめようとすると、いくつもの問題が出てきます。

提供元ごとにAPI、CSV、XML、GeoJSON、GeoTIFFなど形式が違う
同じ「水位」「雨量」「震度」でも項目名、単位、時刻表現が違う
APIの更新頻度、取得可能期間、利用制限が違う
情報の訂正、取消、再配信を追跡しにくい
公式発表、観測値、衛星推定、モデル計算、利用者投稿が混ざりやすい
座標系、高さの基準、解像度、NoDataの扱いが揃っていない
解析に使ったデータとモデルの版が残らず、結果を再現できない
災害時に外部APIが止まると、公開画面まで巻き込まれる
APIから取得できても、再配布や二次利用が許可されているとは限らない

そこで、外部情報を画面や解析へ直接つなぐのではなく、取得、保存、検査、標準化、版管理、公開判定を通す共通基盤を用意します。

4. 最初に決めておくこと

後から大きな構造変更が必要になったり、データの読み違いや公開事故が起きたりしないように、次の項目は最初から基本方針へ組み込みます。

設計上の重要論点	最初から採用する方針
情報種別と信頼区分	`Bulletin`、`Alert`、`Observation`、`DerivedObservation`、`Forecast`、`RunOutput` / `HazardResult`を分け、画面でも明確に描き分ける
Eventと観測の関係	観測はEventなしでも保存し、後から関連付けられる構造にする
訂正・取消・再配信の履歴	上書きせず、版、訂正元、取消、失効を履歴として残す
時刻の意味と基準	観測時刻、発表時刻、予報基準時刻、予報対象時刻、有効期間、取得時刻、登録時刻を分ける
外部APIの仕様変更への追従	Schema Drift検出、契約テスト、原本再処理を前提にする
API停止時の継続動作	最終正常取得値、縮退表示、再試行、後追い同期を標準機能にする
データ利用条件と公開範囲	License、Attribution、再配布可否、公開範囲をデータごとに管理する
品質と不確実性の明示	精度、欠測、鮮度、推定方法、信頼度を結果と一緒に保持する
水平・鉛直基準	水平CRSだけでなく、鉛直基準、ジオイド、潮位基準まで記録する
複合災害・連鎖災害	`EventRelation`で原因、誘発、同時発生、連鎖関係を表現する
個々の物理現象と災害Event	1回の地震や噴火はHazardOccurrenceとして保持し、社会的・運用上の災害Eventとは分ける
恒常的な監視対象	火山は噴火Eventの有無にかかわらずVolcanoとして管理し、火口・観測点・警戒範囲の版を持つ
高頻度観測データ	地震波形、火山性微動、傾斜、映像等は`Instrument`、`ObservationChannel`、`SignalAsset`としてMetadataと実体を分離する
公開前の検証と承認	DRAFTからPUBLISHEDまでの承認フローを設ける
災害時の継続運転と縮退	公開系と解析系を分け、解析停止時も既存情報を読めるようにする
システム境界ごとのセキュリティ	外部API、ファイル取込、公開API、解析Workerを別々に防御する
個人情報・機微情報の保護	公開範囲、集約、ぼかし、保持期間をデータ種別ごとに決める
公開Webのアクセシビリティ	色だけに頼らず、キーボード、スマートフォン、低帯域を考慮する
モデル結果の再現性と説明責任	入力、パラメータ、Engine、Container、乱数SeedまでRunに固定する
AIの役割と制約	AIは検索・説明・操作補助に限定し、公式判定や自動公開を任せない
段階的なシステム分割	最初はモジュラーモノリスとWorker分離で作り、必要な境界だけ後で分割する

5. システムの基本方針

5.1 全体像は大きく描き、実装は少しずつ進める

このプラットフォームは、気象、洪水、地震、火山など、さまざまな災害情報を扱える仕組みを目指します。Webから利用でき、将来は対象地域や情報源が増えても対応できる構成にします。

ただし、最初からすべての機能を作るわけではありません。

まずは、降雨データの取込、流出解析、河川1D、氾濫2Dなど、洪水に関する一連の処理を最初の本格的な数値解析として実装します。この一連の流れを実際に動かしながら、データ管理、解析、結果保存、公開といった共通の仕組みが問題なく使えるかを確かめます。

一方、気象、地震、火山については、数値解析Engineが完成するのを待たず、公開情報を取得するConnectorや、データを保存する仕組み、訂正履歴、地図・タイムラインなどの情報表示を先に作ります。

ここでは、次の二つを分けて考えます。

災害情報を集めて整理・公開する仕組み
                と
災害を数値計算する解析Engine

この二つを別の責任として設計します。気象、地震、火山などの情報は早い段階からWebで扱えるようにし、本格的な解析機能は検証できたものから順番に追加します。

5.2 取得した元データはそのまま残す

外部APIやファイルから取得したデータは、共通形式へ変換したあとも、元のデータを削除しません。

データは用途に応じて、次のように分けて管理します。

raw
  外部APIやファイルから取得した元データ

normalized
  プラットフォーム内で扱いやすい共通形式へ変換したデータ

derived
  補間、集計、座標変換、推定、解析前処理などを行ったデータ

results
  数値解析や影響評価によって作られた結果

published
  内容を確認し、公開を承認した固定版

元データを残しておけば、変換方法を変更したときや、処理に問題が見つかったときでも、最初からデータを取得し直さずに再処理できます。

また、

どのデータを取得し
どの処理を行い
どの結果が作られたのか

を後から追えるようになります。

5.3 共通部分だけを揃え、災害ごとの違いは残す

気象、河川、地震、火山、衛星では、扱う情報が大きく異なります。

そのため、すべての情報を一つの大きなデータ構造へ無理にまとめることはしません。

例えば、

Dataset
Observation
Bulletin
Alert
Forecast
Event
Model / Scenario / Run

のように、どの分野でも共通して必要になる部分は同じ仕組みで管理します。

一方で、

地震の震源・マグニチュード
火山の火口・噴煙・火山性微動
河川の水位・流量
気象の予報格子
衛星画像の軌道・観測条件

といった分野固有の情報は、それぞれ専用のモデルで持たせます。

基本となる共通モデルの上に、必要な分野ごとのモデルを追加していく考え方です。

これにより、情報源や災害種別が増えても、既存の仕組みを大きく作り直さずに拡張できます。

5.4 災害Eventは情報をまとめるために使う

台風、豪雨、地震、噴火などの災害Eventは、関連する情報を一つにまとめるために使います。

例えば、ある地震Eventには、

地震発生情報
震度観測
公式発表
津波情報
衛星画像
被害情報
解析結果

などを関連付けられます。

ただし、すべてのデータが必ずEventに所属するわけではありません。

平常時の雨量、水位、気温、火山観測などは、特定の災害が発生していなくても継続して保存する必要があります。

そのため、

Observation
Satellite Scene
Alert
Bulletin
Forecast
ImpactResult

などは単独でも登録できるようにします。

災害が発生したあとで、必要な情報を一つまたは複数のEventへ関連付けます。

Eventは「データを保存するための箱」ではなく、関連する情報をまとめて見るための仕組みとして使います。

5.5 内部で使う情報と、一般公開する情報を分ける

解析途中の結果や、まだ確認が終わっていないデータを、そのまま公開サイトへ表示することはしません。

プラットフォーム内部では、

取得直後のデータ
解析途中のデータ
検証前の推定結果
管理者向け情報

なども扱います。

一方、一般利用者が見るPublic Webや公開APIには、公開条件を満たした情報だけを出します。

解析成果や内部で作成した推定結果は、原則として次の流れを通します。

内部データ
    ↓
解析・整理
    ↓
検証
    ↓
レビュー
    ↓
承認
    ↓
Publication
    ↓
Public Web / Public API

公式機関から継続的に配信される情報は、すべてを人手で確認してから公開すると更新が遅れます。そのため、Source、情報種別、License、Schema、品質条件を事前に承認し、その条件を満たす場合だけ自動でPublicationを作成できるようにします。解析結果や条件外のデータは、Reviewerによる確認と承認を必要とします。

この境界により、作業中のデータや未確認の解析結果が意図せず一般公開されることを防ぎながら、公式情報の更新速度も保ちます。

5.6 解析結果と公式情報は、はっきり分けて表示する

このプラットフォームでは、衛星画像や数値モデルを使って、

推定浸水域
洪水の危険範囲
地震による影響
降灰範囲
被害推定

などを作ることがあります。

また、将来的にはAIによる要約や説明も表示します。

ただし、これらは行政機関などが発表する、

警報・注意報
避難情報
地震・津波情報
火山情報
公式ハザードマップ

の代わりになるものではありません。

そのため、Web画面では情報の種類を明確に表示します。

例えば、

公式情報
観測情報
衛星による推定
数値解析結果
研究・参考情報
AIによる説明

を見た目でも区別できるようにします。

利用者が「これは公式発表なのか、それともプラットフォームが計算した結果なのか」を迷わないことを重視します。

5.7 外部との連携には共通仕様を使う

プラットフォーム内部の作りまで、すべて既存の標準仕様に合わせる必要はありません。

内部では、処理のしやすさや性能を考えて、その機能に合ったデータ構造や実装方法を選びます。

一方、外部のシステムと情報をやり取りするときは、できるだけ広く使われている共通仕様を利用します。

例えば、次のように使い分けます。

Web API：OpenAPI
APIのURL、入力値、戻り値などを分かりやすく定義します。
非同期の通知：AsyncAPI、CloudEvents
災害情報の更新や解析完了などを、システム間で通知するときに使います。
河川、道路、観測所などの地理情報：OGC API - Features
地図上のFeatureを外部から検索・取得できるようにします。
地図タイル：OGC API - Tiles
背景地図や解析結果をWeb地図へ効率よく配信します。
雨量、水位、気温などの時空間データ：OGC API - Environmental Data Retrieval
場所や時刻を指定して環境データを取得できるようにします。
データカタログ：OGC API - Records、DCAT
どのようなデータがあるのかを外部から検索できるようにします。
衛星画像や時空間Asset：STAC
衛星画像、DEM、解析Rasterなどを場所や日時から探せるようにします。
警報情報の交換：CAP
警報や緊急情報をシステム間で共有するときに利用します。
データの来歴：PROV-Oの考え方
元データ、処理、解析結果のつながりを追跡できるようにします。
Web向けRaster：COG
大きなRasterデータから、必要な範囲だけ効率よく読み込めるようにします。

基本的な考え方は、

プラットフォーム内部
    → 作りやすく、変更しやすくする

外部との接続部分
    → 共通仕様を使い、つなぎやすくする

というものです。

この境界を保つことで、内部実装を改良しても、外部システムとの接続方法をできるだけ安定させられます。

5.8 最初はシンプルなシステム構成で始める

将来は多くの利用者や大量のデータを扱うことを想定していますが、最初からシステムを細かく分割しすぎることはしません。

初期段階では、次のような比較的シンプルな構成から始めます。

Web
  Web画面

API
  データ取得や解析操作の受付

Worker
  データ処理や数値解析

Scheduler
  定期的なデータ取得や処理の開始

Database
  Metadataや地理情報の管理

Object Storage
  衛星画像、Raster、解析結果などの保存

Queue
  時間のかかる処理をWorkerへ渡す

Tile Service
  Web地図用のデータ配信

Observability
  ログ、メトリクス、トレースによる監視

例えば、最初から、

Weather Service
River Service
Earthquake Service
Volcano Service
Satellite Service
Catalog Service
Event Service
Run Service

のように細かく別サービスへ分割することはしません。

ただし、プログラム内部では、

Domain
Connector
Catalog
Event
Hazard Engine
Impact
Publication

などの役割をきちんと分けておきます。

この構成なら、初期段階では一つのシステムとして管理しやすく保ちながら、将来、

衛星処理だけ負荷が大きくなった
Connectorを別サーバーで動かしたい
2D氾濫解析をGPUサーバーへ移したい
公開APIだけ独立して増強したい

といった必要が出てきた部分だけを、別サービスへ切り出せます。

最初から複雑な構成にするのではなく、役割は分けて作り、必要になったところからシステムを分割する方針です。

6. 対象範囲

このプラットフォームでは、Hazard（災害外力）だけでなく、Exposure（曝露）、Vulnerability（脆弱性）、Capacity（対応力）、Impact（影響）まで扱います。これらは同じ概念ではないため、データモデル上も別々に管理します。

主な災害モジュール

局地的な短時間強雨（いわゆるゲリラ豪雨）、台風、雷、暴風、竜巻
猛暑・酷暑、熱中症リスク、干ばつ
洪水、河川氾濫、内水氾濫
土砂災害、斜面崩壊、土石流
地震、地盤変状、液状化
津波、高潮、沿岸浸水
火山噴火、降灰、火砕流、泥流
山林火災
大雪、雪崩、着雪

気象・異常気象情報で扱う範囲

気象情報は、洪水解析へ降雨を渡すためだけに使うものではありません。局地的な短時間強雨、台風、雷、竜巻、暴風、大雪、猛暑・酷暑などは、それぞれが暮らし、健康、交通、農業、ライフラインへ直接影響します。気象の観測、予測、警戒情報を独立した情報Moduleとして扱い、洪水や土砂災害など、ほかの災害Moduleにも渡せるようにします。

区分	主な内容	プラットフォーム内の扱い
公式情報	大雨、台風、雷、強風、高温などに関する発表、警戒・注意、解説、訂正・解除	`Bulletin` / `Alert`
観測	雨量、気温、湿度、風向風速、気圧、日射、積雪、レーダー・衛星観測	`Observation` / `TimeSeries` / `RasterAsset`
予測	短時間予測、数値予報、台風進路、降雨・気温・風の格子予測、予測の更新版	`Forecast` / `DatasetVersion`
派生情報	累積雨量、短時間雨量、暑さ指数、乾燥度、平年差など	`DerivedObservation` / `DatasetVersion`
個別現象	局地的な豪雨、熱波、竜巻、暴風などを個別にまとめる必要がある場合	`HazardOccurrence`
影響	道路冠水、土砂災害、熱中症リスク・健康影響、交通障害、停電、農作物への影響	`ImpactResult`

気象情報では、次の点を押さえます。

「ゲリラ豪雨」は分かりやすい表示名として使えますが、内部では提供元の正式な現象区分と、雨量・継続時間・観測方法を残す
観測時刻、解析基準時刻、予報の基準時刻、予報対象時刻、取得時刻を分ける
新しい予報へ上書きせず、どの時点で利用できた予報かを後から追えるようにする
観測値、予測値、補間値、プラットフォーム独自の派生指標を同じ種類として表示しない
猛暑・酷暑や熱中症リスクの表示には、対象時刻、地域、算出方法、不確実性を添える
プラットフォームが計算した危険度を、提供元の公式な警戒情報として見せない

地震情報で扱う範囲

地震情報では、「発表された情報」「実際に発生した地震」「一連の災害」を分けて扱います。発表内容は後から訂正されることがあり、一つの地震に複数の機関や複数版の情報が付く場合もあります。また、本震と多数の余震を、一つの災害としてまとめて見ることもあります。

区分	主な内容	プラットフォーム内の扱い
個別の地震現象	発生時刻、震央、深さ、規模、震源決定の不確実性	`HazardOccurrence`
公式発表	地震情報、震度情報、長周期地震動に関する情報、訂正・取消	`Bulletin`（原本は`SourceAsset`）
地上観測	観測点震度、加速度、速度、変位、地殻変動	`Observation` / `TimeSeries`
高頻度信号	地震波形、連続波形、処理前信号	`SignalAsset`
基礎データ	活断層、地質、地盤区分、建物、道路、重要施設	`DatasetVersion`
観測由来の推定	観測値を補間・統合して作成した震度面など	`DerivedObservation` / `RasterAsset`
数値解析	地震動、液状化、斜面影響などの解析結果	`RunOutput` / `HazardResult`
影響評価	建物、道路、交通、ライフラインなどへの影響	`ImpactResult`

地震情報では、次の点を押さえます。

外部の発表IDを内部主キーにせず、SourceごとのIDと内部の安定IDを分ける
複数Sourceの発表を同じ地震へ結び付ける場合は、OccurrenceSourceLinkに照合方法と信頼度を残し、曖昧な候補を自動確定しない
発生時刻、震央、深さ、マグニチュードは訂正される前提で版を残す
マグニチュードは値だけでなく種類、算出元、確定状況を保持する
震源位置には水平・深さの不確実性と使用した基準を持たせる
個々の余震は独立したHazardOccurrenceとして保存し、必要に応じて地震活動や災害Eventへまとめる
地震によって発生した津波、斜面崩壊、火災は別のHazardOccurrenceとして保存し、必要に応じてEventへまとめ、TRIGGERS等で関係を表す

火山情報で扱う範囲

火山は、噴火が起きたときだけ存在するEventではありません。平常時から継続して監視され、火口や観測点、警戒範囲も変わるため、恒常的なVolcanoを基準となるEntityとして持ちます。

区分	主な内容	プラットフォーム内の扱い
火山台帳	名称、位置、範囲、火口・噴気孔、標高、別名、外部ID	`Volcano` / `VolcanicFeature`
公式情報	警報・予報、活動解説、噴火情報、降灰予測、訂正・解除	`Bulletin` / `Alert` / `Forecast`
観測	火山性地震、微動、傾斜、GNSS、噴煙、ガス、熱、映像	`Observation` / `TimeSeries` / `SignalAsset`
個別現象	噴火、爆発、降灰、火砕流、融雪型泥流、火山泥流	`HazardOccurrence`
基礎データ	DEM、火山地形、地質、河道、積雪、土地利用、人口・施設	`DatasetVersion`
観測由来の推定	衛星・地上観測から推定した降灰分布、熱異常、噴煙範囲など	`DerivedObservation` / `RasterAsset`
数値解析	噴煙・粒子輸送、火砕流、泥流Scenarioなどの解析結果	`RunOutput` / `HazardResult`
影響評価	交通、建物、設備、取水、農地などへの影響	`ImpactResult`

火山情報では、次の点を押さえます。

Volcano、火口・噴気孔、観測点は、噴火Eventと切り離して版管理する
外部の火山Code、名称、別名は有効期間付きで対応付け、提供元のCode変更を内部IDの変更にしない
活動解説や噴火情報はBulletin、警戒を伴う情報はAlertとして区別する
警戒状態は噴火発生の有無とは別に、発表時刻、有効期間、対象範囲、解除・変更履歴を持つ
警戒レベルや区分は提供元ごとの原Codeを保持し、異なる制度を単純な数値順へ統合しない
噴火開始・終了時刻が不明または推定の場合は、時刻精度と確定状況を明示する
噴煙高度、火口標高、降灰高度は、鉛直基準と単位を明記する
波形、連続画像、熱画像などの大容量データはObject Storageへ置き、Catalogには時間範囲、観測点、ObservationChannel、Checksumを登録する
火山泥流、土石流、洪水、降雪・融雪等との連鎖をEventRelationで表現する

気象・地震・火山のいずれも、外部から取り込んだBulletin、Alert、Forecastと、プラットフォームが独自に計算したRunOutput / HazardResultは分けます。解析Engineがまだなくても、公式情報、観測、履歴、出典を扱う情報基盤は先に利用できるようにします。

共通のImpact評価

影響人口
建物・住宅への影響
道路、鉄道、橋梁の途絶
病院、学校、避難所、行政施設への影響
電力、通信、水道などライフラインへの影響
孤立地域と代替経路
農地、森林、事業所への影響

このプラットフォームで行わないこと

公式な警報・避難指示の発令
行政機関の正式なハザードマップの置き換え
AIだけによる災害判定や公開判断
出所の分からない情報の自動統合
すべての外部APIデータを無条件に再配布すること

7. 利用者ごとの画面と権限

公開Web、解析Workspace、運用管理は、同じ権限では扱いません。

Public Portal

Public Portalは、ログインせずに利用できる公開地図を中心にします。

現在・過去の災害イベント
局地的な強雨、台風、気温、暑さ、風、積雪などの気象情報
地震の個別事象、震度、訂正履歴、関連する津波・被害情報
火山ごとの警報・予報、活動状況、噴火事象、観測時系列
公式情報と出典
観測値と更新時刻
承認済みの解析成果
データの品質、鮮度、不確実性
ダウンロード可能な公開データ

Analysis Workspace

Analysis Workspaceは、権限を持つ利用者が解析を進めるための画面です。

Project、Dataset、Model、Scenario、Run
気象観測、予報格子、局地的豪雨、暑熱指標の確認
河道網・地形・解析条件の編集
地震Occurrence、地盤条件、火山台帳・火口・観測点の確認
衛星・GIS処理、気象・水文・水理・地震・火山の解析、影響評価
Run比較、Validation、Calibration
公開候補の作成

Administration

Source Registry
Connector設定
License・公開範囲
Data Catalog
利用者・Role
Schema、Vocabulary
Publication承認

Operations Console

外部APIの稼働状態とデータの鮮度
Queue、Worker、Job
ストレージ、DB、Backup
エラー、監査、セキュリティ通知
縮退運転への切替

8. 全体フロー

このプラットフォームでは、外部から集めた情報をそのまま画面へ表示するのではなく、取得、保存、検査、整理、解析、確認、公開という流れを通して扱います。

大きく見ると、次のような流れです。

外部情報
  ↓
取得・同期
  ↓
原本保存
  ↓
品質確認
  ↓
共通形式へ整理
  ↓
Data Catalogへ登録
  ↓
Event・観測・警報などへ関連付け
  ↓
解析・影響評価
  ↓
Validation / Review
  ↓
Publication
  ↓
Public Web / API / Download

最初に入ってくる情報は、気象API、河川水位、地震情報、火山情報、衛星画像、道路情報、センサー、CSV、GeoTIFFなど、形式も更新頻度もばらばらです。

そのため、外部サービスごとの違いはConnectorで吸収し、プラットフォーム内部ではできるだけ共通の考え方で扱えるようにします。

ただし、すべての情報を同じ形式へ無理に揃えるわけではありません。

例えば、

地震
  震源、深さ、マグニチュード

河川
  水位、流量

気象
  雨量、気温、予報格子

衛星
  Scene、観測時刻、軌道、Raster

火山
  火山性地震、微動、噴煙、警報

のような分野固有の情報は、それぞれの特徴を残したまま管理します。

共通化するのは、

どこから取得したか
いつ取得したか
いつ観測・発表されたか
どの版か
品質はどうか
何から作られたか
公開してよいか

といった、データを管理するために共通して必要になる部分です。

この流れを一つにしておくことで、単なる災害情報の表示だけではなく、

現在の状況を確認する
過去の災害を振り返る
数値解析を行う
衛星観測と比較する
被害や社会影響を評価する
結果を公開する

ところまで、同じ基盤の上で扱えるようにします。

9. システム全体の層構成

プラットフォーム全体は、役割ごとにいくつかの層へ分けます。

┌───────────────────────────────────────────────────────────┐
│ Public Portal / Analysis Workspace / Admin / AI           │
├───────────────────────────────────────────────────────────┤
│ Public API / OGC API / STAC / Download / Tiles            │
├───────────────────────────────────────────────────────────┤
│ Publication / Review / Access Policy                      │
├───────────────────────────────────────────────────────────┤
│ Hazard / Impact / Validation / Reporting                  │
├───────────────────────────────────────────────────────────┤
│ Model / Scenario / Run / Workflow                         │
├───────────────────────────────────────────────────────────┤
│ Event / HazardOccurrence / Bulletin / Alert / Observation │
├───────────────────────────────────────────────────────────┤
│ Data Catalog / Version / Provenance / Quality             │
├───────────────────────────────────────────────────────────┤
│ Normalize / Mapping / Validation / Quarantine             │
├───────────────────────────────────────────────────────────┤
│ Connector SDK / Source Registry / Synchronization         │
├───────────────────────────────────────────────────────────┤
│ API / Satellite / Sensor / File / Database                │
└───────────────────────────────────────────────────────────┘

下の層ほどデータ取得や保存に近く、上へ行くほど解析、公開、利用者向けの機能に近くなります。

外部データ層

API / Satellite / Sensor / File / Database

一番下は、プラットフォームへ入ってくる情報そのものです。

対象には、

気象API
河川API
地震・火山情報
衛星データ
観測センサー
CSV / JSON / XML
GeoTIFF / NetCDF
外部Database

などがあります。

ここでは、データの中身をまだプラットフォーム独自の形へ変えません。

まずは「外から来た情報」として扱います。

Connector層

Connector SDK / Source Registry / Synchronization

外部の情報源ごとの違いを吸収する層です。

例えば、

Weather Connector
River Connector
Earthquake Connector
Volcano Connector
Satellite Connector
Traffic Connector

などを用意します。

Connectorは、

接続
取得
差分更新
再試行
認証
Rate Limit対応
取得日時記録

などを担当します。

新しい情報源が増えた場合も、できるだけPlatform Coreを変更せず、新しいConnectorを追加するだけで対応できる構成にします。

取込・品質確認層

Normalize / Mapping / Validation / Quarantine

取得したデータを、そのまま解析や公開には使いません。

ここで、

Schema確認
必須項目確認
座標系確認
単位確認
時刻確認
欠損確認
異常値確認
重複確認

などを行います。

問題があるデータは削除せず、

Quarantine

へ移して確認できるようにします。

正常なデータは、プラットフォーム内部で扱いやすい形式へ整理します。

Data Catalog層

Data Catalog / Version / Provenance / Quality

ここはプラットフォームの中心となる部分です。

「どんなデータを持っているか」だけではなく、

誰が提供したか
どのSourceから取得したか
いつ取得したか
どのVersionか
どの処理から作られたか
どのCRSか
どの期間を対象とするか
どのLicenseか
品質はどうか

まで管理します。

解析結果についても、

どのDatasetVersionを使ったか
どのModelVersionで計算したか
どのEngineVersionだったか

を追跡できるようにします。

これによって、後から同じ条件で解析を再現できるようになります。

災害情報層

Event / Occurrence / Bulletin / Alert / Observation

Data Catalogに登録されたデータを、「災害情報としてどういう意味を持つか」という視点で整理する層です。

例えば、

Observation
  雨量、水位、震度、気温、火山性微動など

Bulletin
  地震情報、火山活動解説、各種発表

Alert
  警報、注意情報

Forecast
  予報、予測

HazardOccurrence
  実際に発生した地震、噴火、崩壊など

Event
  複数の情報や現象をまとめた災害事象

として整理します。

この層を分けておくことで、単なるデータファイルの一覧ではなく、

この地震に関連する情報
この台風に関連する観測
この噴火に関連する警報

のような見方ができるようになります。

Model / Run層

Model / Scenario / Run / Workflow

数値解析を実行するための層です。

ここでは、

どのModelを使うか
どのScenarioで計算するか
どの入力データを使うか
どのEngineで動かすか

を固定してRunを実行します。

例えば洪水なら、

降雨
  ↓
水文解析
  ↓
河川1D
  ↓
氾濫2D

という複数の解析をWorkflowとしてつなげることもできます。

Runごとに入力、出力、ログ、メトリクス、Artifactを残し、あとから再実行や比較ができるようにします。

Hazard / Impact層

Hazard / Impact / Validation / Reporting

解析結果を単に保存するだけではなく、その結果が何を意味するかを評価する層です。

Hazardでは、

浸水深
震度
液状化
降灰
土砂災害範囲

などの災害外力を扱います。

Impactでは、それを、

人口
建物
道路
鉄道
病院
避難所
ライフライン

などと重ね合わせます。

そこから、

影響人口
建物被害
道路寸断
重要施設への影響
集落孤立
連鎖影響

などを評価します。

また、観測データや衛星画像と計算結果を比較し、Validationも行います。

Publication層

Publication / Review / Access Policy

内部で作られた結果を、そのまま外部へ公開することはしません。

ここで、

内容
出典
License
品質
公開範囲
個人情報
不確実性

などを確認します。

承認されたものだけをPublicationとして固定し、Public Webや公開APIへ出します。

これにより、

内部で計算中の結果
未確認の推定値
一般公開してはいけないデータ

が誤って公開されることを防ぎます。

外部提供層

Public API / OGC API / STAC / Download / Tiles

承認された情報を、外部へ提供するための層です。

Web画面だけではなく、

REST API
OGC API
STAC
GeoJSON
GeoPackage
COG
Tile
Download

など、用途に応じた方法で提供します。

他のGIS、研究システム、自治体システム、AIなどからも利用できるようにします。

利用者向けの層

Public Portal / Analysis Workspace / Admin / AI

一番上が、利用者が直接触れる部分です。

利用目的ごとに画面を分けます。

Public Portal
  一般利用者向けの災害情報・地図

Analysis Workspace
  データ分析、Model設定、Run実行

Admin
  Source、Catalog、License、公開管理

AI Assistant
  Catalog検索、Event検索、結果比較、
  地図操作、説明補助

すべての利用者が同じ画面や権限を持つのではなく、目的ごとに利用できる機能を分けます。

9.1 各層を横断する共通機能

次の機能は、特定の層だけに置くのではなく、プラットフォーム全体に関わる共通機能として扱います。

Identity
Security
Audit
Observability
Backup
Schema Registry
Vocabulary

Identity

利用者や外部システムが誰なのかを管理します。

User
Service Account
API Client
Worker
Connector

などを識別します。

Security

認証だけではなく、

認可
API Key
Secret管理
暗号化
Rate Limit
Network Policy

なども含めます。

Audit

誰が、

データを登録した
設定を変更した
解析を実行した
公開を承認した
公開を撤回した

のかを記録します。

Observability

Web、API、Worker、Connectorなどの状態を、

トレース
メトリクス
ログ

で確認します。

外部APIの取得失敗や解析Engineの異常も、同じ仕組みで追跡できるようにします。

Backup

Databaseだけではなく、

Catalog
Metadata
Object Storage
Publication
設定

も含めて復旧できるようにします。

Schema Registry

ConnectorやAPIごとにデータ構造がばらばらにならないよう、利用しているSchemaとVersionを管理します。

Vocabulary

同じ意味の項目が、

water_level
river_height
wl

のように別々の名前で増えていかないよう、共通の用語やCodeを管理します。

この層構成で大切なのは、単にシステムを細かく分けることではありません。

外から情報を集める
        ↓
安全に保存する
        ↓
意味を整理する
        ↓
解析する
        ↓
確認する
        ↓
公開する

という責任の境界をはっきりさせることです。

この境界を最初に決めておけば、将来情報源や災害種別、解析Engine、公開方法が増えても、既存部分への影響を抑えながら機能を追加しやすくなります。

10. 機能領域（Domain）の分け方

このプラットフォームでは、すべての処理を一つの大きな機能として作るのではなく、役割ごとにDomainを分けます。

ここでいうDomainは、単なるフォルダ分けではありません。

例えば、

外部から情報を取得する
データの意味やVersionを管理する
災害事象として整理する
数値解析を実行する
結果を検証する
公開する

といった責任を、それぞれ別の領域として扱います。

この境界を守れば、気象APIの追加、新しいHazard Engineの導入、公開方法の変更があっても、関係のない部分まで大きく修正せずに済みます。

Domain一覧

Domain	主な役割	代表的な内容
Source	外部情報源そのものを管理する	`Provider`、Endpoint、利用条件・License、取得頻度、認証方式、利用可否、稼働状態
Connector	外部情報を実際に取得し、内部へ渡す	探索、取得、解析、Normalize、差分同期、再試行、Rate Limit対応
Catalog	プラットフォーム内にどのデータがあるかを管理する	`Dataset`、`DatasetVersion`、Asset、Metadata、検索、Lineage、Checksum
Observation	実際に観測された値と観測系、観測から作った派生値を管理する	雨量、気温、風、水位、流量、震度、`Station`、`Instrument`、`ObservationChannel`、`Observation`、`DerivedObservation`、`SignalAsset`
Bulletin	機関などから発表された情報文書を管理する	気象情報、地震情報、噴火情報、活動解説、調査報告、訂正情報
Alert	注意や警戒を促す情報を管理する	警報、注意報、避難関連情報、有効期間、対象地域、解除、訂正
Forecast	提供元が発表・配信する将来予測を管理する	基準時刻、予測対象時刻、`lead_time`、予測値、予報版、不確実性
Occurrence	実際に発生した個々の物理現象を表す	豪雨、熱波、地震、噴火、斜面崩壊、越水などの`HazardOccurrence`
Event	複数のOccurrenceや関連情報を、一つの災害としてまとめる	災害名、期間、範囲、別名、`EventOccurrenceLink`、Bulletin、Alert、Forecast、Observation、ImpactResult
Hazard Reference	長期間利用する基準情報を管理する	火山、火口、噴気孔、活断層、河川、監視対象区域など
Geospatial	空間情報を共通して扱う	CRS、Geometry、Raster、Bounding Box、Tile、Spatial Index
Model	解析モデルと、それを実行するEngineの定義を管理する	`Model`、`ModelVersion`、`Engine`、`EngineVersion`、入力要件、Parameter Schema
Scenario	解析条件を管理する	境界条件、仮定、対策条件、外力条件、`ScenarioVersion`
Run	実際の計算を一つの再現可能な単位として管理する	`Run`、`ProjectSnapshot`、状態、`RunInput`、`RunOutput`、`Artifact`、ログ、メトリクス
Hazard	災害外力の解析結果を管理する	`HazardResult`、浸水深、震度面、液状化、降灰、土砂移動範囲など
Impact	Hazardが人や社会へ与える影響を評価する	`ImpactResult`、影響人口、建物被害、道路寸断、施設影響、孤立、連鎖影響
Validation	計算のVerificationと、観測・実績によるValidationを管理する	既知解・質量保存、観測比較、衛星比較、精度指標、不確実性、Calibration
Publication	外部へ公開する版を管理する	Review、Approval、Published Snapshot、撤回、新版への切替
Identity	誰が何をできるかを管理する	User、Organization、Role、Permission、Service Account
Operations	システムを安定して動かすための状態を管理する	稼働状態、監視、障害対応、Backup、Job状態、運用通知

10.1 SourceとConnectorは分けて考える

SourceとConnectorは似ていますが、役割が違います。

Sourceは、

気象情報を提供しているサービス
河川水位を提供しているサービス
地震情報を提供しているサービス

そのものを表します。

一方、Connectorは、そのSourceへ接続してデータを取得するための実装です。

Source
  気象情報サービスA

        ↓ 接続方法

Connector
  WeatherApiConnector

Sourceには、

提供者
Endpoint
License
更新頻度
認証方式
利用条件
現在の稼働状態

を持たせます。

Connectorには、

どう検索するか
どう取得するか
どうJSONやXMLを読むか
どう内部形式へ変換するか
どこまで取得済みか
失敗時にどう再試行するか

を持たせます。

この分離により、提供元のAPI仕様が変わった場合も、基本的にはConnector側の修正で対応できます。

10.2 Catalogはデータを探すためだけのものではない

Data Catalogは、単なるファイル一覧ではありません。

このプラットフォームでは、

このデータは何か
どこから来たか
どのVersionか
いつのデータか
どの地域を対象としているか
どの処理から作られたか
利用条件は何か

まで管理します。

例えば、

SourceAsset
    ↓
DatasetVersion
    ↓
派生DatasetVersion
    ↓
RunInput
    ↓
RunOutput

という流れを追えるようにします。

そのためCatalogは、検索機能だけでなく、Version管理とProvenanceの中心として扱います。

10.3 Observationは「値」と「観測方法」の両方を持つ

観測値だけを保存してしまうと、

どこで測ったのか
何という機器で測ったのか
どの`ObservationChannel`なのか
単位は何か

が分からなくなります。

そこで、

Station
  ↓
Instrument
  ↓
ObservationChannel
  ↓
Observation

という構造を基本にします。

地震波形や火山性微動、連続映像など、大きなデータについてはDatabaseへ直接入れず、

ObservationChannel
    ↓
SignalAsset
    ↓
Object Storage

として管理します。

Databaseには、保存場所、期間、サンプリング周波数、ChecksumなどのMetadataを持たせます。

10.4 Bulletin、Alert、Forecastは分ける

外部から発表される情報をすべて一つの「災害情報」テーブルへ入れると、後で意味が分からなくなります。

例えば、

地震が発生したという発表
        Bulletin

大雨に注意するよう促す情報
        Alert

明日の雨量を予測した情報
        Forecast

では性質が違います。

Bulletinは「発表された情報」。

Alertは「注意や警戒を促す情報」。

Forecastは「提供元が発表・配信した将来に対する予測」。

として分けます。

プラットフォーム自身がRunで計算した将来予測はForecastへ入れず、RunOutputやHazardResultとして管理します。これにより、外部から受け取った予報と、プラットフォーム内で計算した結果を混同しません。

この分け方により、発表履歴、訂正、有効期間、予報更新をそれぞれの意味に沿って管理できます。

10.5 OccurrenceとEventも分ける

ここも重要な境界です。

Domain名は簡潔にOccurrenceとしますが、個々の物理現象を表すEntity名にはHazardOccurrenceを使います。以下では、文脈上明らかな場合に限りOccurrenceと略記します。

HazardOccurrenceは、実際に発生した個々の現象です。

例えば、

2026年○月○日 10:32の地震

○○火山で発生した噴火

○○地区で発生した斜面崩壊

などです。

一方、Eventは、それらをまとめて扱うための単位です。EventとHazardOccurrenceの対応はEventOccurrenceLinkで管理し、一つのOccurrenceを複数のEventへ関連付ける必要がある場合にも履歴を失わないようにします。

例えば、

大きな地震
  ├── 本震
  ├── 複数の余震
  ├── 津波
  ├── 斜面崩壊
  └── 被害情報

を一つのEventとして整理できます。

したがって、

Occurrence
    = 実際に起きた一つの現象

Event
    = 関連情報をまとめる災害単位

と考えます。

10.6 Hazard ReferenceはEventとは別に持つ

火山や活断層のような対象は、災害が起きていないときにも存在しています。

例えば火山は、

噴火したから火山が作られる

わけではありません。

そのため、

Volcano
Fault
Crater
Monitoring Area
River

など、長く使い続ける対象はHazard Referenceとして管理します。

例えば、

Volcano
   ↓
Observation
   ↓
Bulletin
   ↓
Alert
   ↓
Occurrence

というように、平常時から災害発生時まで同じ基準Entityへ情報を結び付けられます。

10.7 Model、Scenario、Runを混ぜない

数値解析では、この三つを明確に分けます。

Modelは、解析で使う物理モデルや計算方法の論理的な定義です。

洪水モデル
地震動モデル
降灰モデル

一方、Engineは、そのModelを実際に実行するソフトウェアです。ModelVersionではモデルの定義や入出力条件を固定し、EngineVersionでは実装、Container image、依存Libraryなど実行環境の版を固定します。同じModelでもEngineの実装が変われば結果が変わる可能性があるため、Runでは両方を記録します。

Scenarioは、その計算で使う条件です。

雨量条件
下流端水位
地震規模
風向・風速
対策施設の有無

Runは、ModelとScenarioと入力データを固定して、実際に一度計算した記録です。

ModelVersion
       +
ScenarioVersion
       +
DatasetVersion
       +
EngineVersion
       +
ProjectSnapshot
       ↓
      Run

とします。

これによって、

同じModelでScenarioだけ変える
Engineを更新して再計算する
入力データのVersionを変えて比較する

といったことができるようになります。

10.8 HazardとImpactを分ける

Hazardは「どの程度の災害外力が発生するか」を表します。

例えば、

浸水深 2.0 m
震度6強
降灰10 cm

などです。

Impactは、

その場所に何があり
どのような影響を受けるか

を評価します。

Hazard
   +
Population
Building
Road
Rail
Hospital
Utility
   ↓
Impact

という関係です。

これを分けておけば、一つのHazardResultを使って、

人口への影響
道路への影響
医療施設への影響
ライフラインへの影響

など、複数のImpact評価を実行できます。

10.9 Validationは解析Engineの外に置く

解析Engine自身が、

自分の計算結果は正しい

と判断する構造にはしません。

Validation Domainは解析Engineから独立させ、その中でもVerificationとValidationを分けて記録します。

Verification
  理論解・既知解との比較
  標準問題との比較
  質量保存などの数値的な確認

Validation
  観測値との比較
  衛星推定範囲との比較
  過去の実績との比較

共通
  過去Runとの比較
  精度指標
  不確実性

Calibrationを行う場合も、入力データや評価指標、調整したParameterを別に残します。

例えば洪水なら、

2D Solver
    ↓
計算浸水域
             ↘
               Validation
             ↗
Sentinel-1推定浸水域

とします。

Solverを変更しても、同じValidation方法で比較できることが重要です。

10.10 Publicationは「表示する処理」ではない

Publicationは、Web画面へ表示する処理そのものではありません。

どの情報を、

どの版で
どの範囲へ
どのLicenseで
誰の承認によって
いつ公開したか

を固定するDomainです。

RunOutput
   ↓
Validation
   ↓
Review
   ↓
Approval
   ↓
Publication
   ↓
Public Web / API / STAC / Download

という流れにします。

この構造にしておけば、新しい解析結果を公開しても、以前公開していた結果を履歴として残せます。

10.11 Domain同士はDatabaseを直接触らない

Domainを分けても、

Catalogの処理からEventのテーブルへ直接INSERT

Runの処理からPublicationのテーブルを直接UPDATE

といった実装をすると、結局すべてが強く結び付いてしまいます。

そこで、Domain間のやり取りはServiceやPortを通します。

Catalog Domain
     │
     │ CatalogQueryPort
     ▼
Run Domain

例えばRunがDatasetVersionを使いたい場合、

Run Service
    ↓
DatasetCatalogPort
    ↓
Catalog Service
    ↓
Catalog Repository

という流れにします。

Run Domainは、

catalog_dataset_version テーブル

の存在を知る必要がありません。

同じように、PublicationがRunOutputを公開するときも、

Publication Service
    ↓
RunResultPort
    ↓
Run Service

を通して必要な情報を取得します。

10.12 Portを置く理由

Portは、Domain同士の約束事です。

例えば、

DatasetVersionを取得する

Observationを検索する

Runを開始する

Publicationを承認する

といった操作をInterfaceとして定義します。

実際の保存先が、

PostgreSQL
PostGIS
Object Storage
外部API

のどれであっても、呼び出す側から見えるInterfaceは変えません。

これにより、内部実装を変更しても、ほかのDomainへの影響を小さくできます。

10.13 Domain間の基本的な流れ

全体を簡単にすると、次のような関係になります。

Source
  ↓
Connector
  ↓
Catalog
  ↓
────────────────────────────
Observation / Bulletin
Alert / Forecast
Occurrence / Event
────────────────────────────
  ↓
Model / Scenario
  ↓
Run
  ↓
Hazard
  ↓
Impact
  ↓
Validation
  ↓
Publication

Geospatial、Identity、Operationsは、この流れの一か所だけではなく、複数のDomainから利用される共通領域になります。

10.14 この分け方で目指すこと

Domainを細かく分けること自体が目的ではありません。

大切なのは、

情報源が増えてもConnectorを追加すればよい

新しい災害を追加してもCatalogを作り直さない

新しい解析Engineを追加してもEvent管理を変更しない

解析Engineを更新しても過去Runを再現できる

公開画面を変更しても解析結果そのものは変わらない

という状態にしておくことです。

最初は一つのAPIやWorkerとして動かしても、コード内部ではこの責任の境界を守ります。

そうしておけば、プラットフォームが大きくなったときに、必要なDomainだけを別Workerや別Serviceとして切り出しやすくなります。

11. Connectorで外部情報を取り込む

11.1 Connectorを追加の単位にする

外部APIごとの細かな仕様は、Platform Coreへ埋め込みません。

新しい情報源は、ConnectorとMappingを追加して取り込みます。本体側のEvent、Catalog、Map、解析処理は変更せずに済む構造にします。

11.2 Connectorの共通契約

Connector SDKには、少なくとも次の機能を揃えます。ここでのvalidate()はSource固有の形式や必須条件を確認するためのものです。プラットフォーム共通のSchema、単位、時刻、CRSなどの検査は、取込・品質確認層でも改めて実行します。

discover()       取得可能なCollectionや期間を調べる
health()         Endpoint、認証、応答を確認する
fetch()          Page、期間、範囲、Cursorを指定して取得する
parse()          JSON、XML、CSV等を安全に解釈する
normalize()      共通モデルへ変換する
validate()       必須項目、単位、時刻、座標、範囲を確認する
checkpoint()     次回同期位置を保存する
backfill()       過去期間を再取得する
reconcile()      訂正、削除、重複、再配信を整理する

11.3 取得方式

定期Pull
差分Pull
Webhook
Publish / Subscribe
Stream
STAC / OGC API検索
ファイル取込
データベース連携
手動登録

取得方法が違っても、原本をSourceAssetとして保存した後の処理は同じ流れに揃えます。

11.4 同期時に必要な仕組み

PaginationとCursor
Rate LimitとQuota
Timeout、Retry、指数Backoff
Idempotency
Checkpoint
重複排除
Dead Letter Queue
Quarantine
Schema Drift検出
訂正・取消の追跡
Last Known Good
復旧後のBackfill

11.5 Connectorの状態

公開画面では、データが古くなったときに値を消すだけではなく、最後に取得できた時刻とSTALE表示を出します。

11.6 Connectorの安全性

外部のEndpointや取得したファイルは、最初から安全だとは考えません。

接続先のAllowlist
Private NetworkへのSSRF防止
認証情報をSecretsで管理
XML External Entityの無効化
ZIP Bomb、巨大ファイル、Path Traversal対策
MIME、拡張子、実体の照合
Connector WorkerのCPU、Memory、実行時間制限
Raw Dataを実行可能領域へ置かない
外部API応答をそのままHTMLへ出さない

12. 情報源を管理するSource Registry

Source Registryには、URLだけではなく、提供元、更新頻度、利用条件、取得状態などもまとめて持たせます。

Source
├── source_id
├── provider_id
├── name
├── category
├── authority_class
├── endpoint_type
├── connector_type
├── expected_update_interval
├── stale_after
├── license_id
├── attribution
├── redistribution_policy
├── access_policy
├── terms_reviewed_at
├── enabled
├── status
├── last_attempt_at
├── last_success_at
└── last_error

情報の性質を表す区分例

authority_classはSourceそのものの種類ではなく、取得・生成された情報の性質を表す分類です。外部Sourceには既定値を設定できますが、プラットフォーム内部で生成した解析結果や手動編集データは、Sourceに依存せずレコード側へ設定します。

OFFICIAL_ALERT             公式な警報・注意報
OFFICIAL_EVENT_INFO        公式な地震・噴火等の発生情報
OFFICIAL_FORECAST          公式な予測・見通し
OFFICIAL_OBSERVATION       公式観測
OFFICIAL_DATASET           公式基礎データ
PARTNER_DATA               協定・連携先の情報
RESEARCH_DATA              研究成果
SATELLITE_DERIVED          衛星観測から作成した派生・推定情報
PLATFORM_MODEL_RESULT      プラットフォーム内の数値解析結果
COMMUNITY_REPORT           一般投稿・通報
MANUAL_ANNOTATION          内部の手動編集
AI_GENERATED_EXPLANATION   AIが生成した説明

この区分は、情報の「正しさ」を自動で順位付けするためのものではありません。情報の性質を明確にするために使います。提供元によって値が食い違った場合は、どちらかを消さず、両方を残してCONFLICTとして扱います。

13. 共通データモデル

このプラットフォームでは、気象、河川、地震、火山、衛星、道路など、性質の異なるデータを扱います。

すべてのデータを一つの形式へ無理に揃えるのではなく、

共通して必要な情報
        +
分野ごとに必要な情報

に分けて管理します。

例えば、雨量観測と地震情報では中身は大きく異なりますが、

どこから取得したか
いつ観測されたか
いつ発表されたか
どのVersionか
どの場所に関係するか
品質はどうか
元データは何か

といった情報は共通して必要です。

この共通部分を揃えておくことで、分野が違っていてもCatalog検索、時系列表示、地図表示、Version管理、Provenance追跡などを同じ仕組みで行えるようにします。

13.1 主なEntity

主なEntityは次のように分けます。

情報源と取得

Provider
Source
ConnectorInstance
SourceAsset

データ管理

Dataset
DatasetVersion
DatasetAsset
DatasetVersionSource
DatasetLineage

観測

Station
Instrument
ObservationChannel
Observation
DerivedObservation
TimeSeries
SignalAsset

発表・警報・予測

Bulletin
Alert
Forecast
GriddedForecastAsset

災害現象とEvent

HazardOccurrence
OccurrenceSourceLink
Event
EventOccurrenceLink
EventAlias
EventRelation

長期間利用する基準情報

Volcano
VolcanicFeature
Fault
River
MonitoringArea

地理空間Asset

GeospatialFeature
RasterAsset
SatelliteScene

Hazard・影響評価

HazardResult
ExposureAsset
VulnerabilityProfile
ImpactResult

解析

Model
ModelVersion
Engine
EngineVersion
Scenario
ScenarioVersion
ProjectSnapshot
Run
RunInput
RunOutput
Artifact

検証・公開

Verification
Validation
Calibration
Publication
PublicationItem

これらを一つの巨大なEntityへまとめるのではなく、役割ごとに分けて関係を持たせます。

13.2 Provider、Source、SourceAssetを分ける

外部情報を扱うときは、提供組織、情報サービス、実際に取得したデータを分けます。

Provider
   ↓
Source
   ↓
SourceAsset

例えば、

Provider
  ある気象機関

Source
  気象観測API

SourceAsset
  2026-08-28 12:00に取得したJSON

という関係です。

Providerには組織情報、SourceにはEndpointやLicense、取得頻度、認証方式を持たせます。

SourceAssetは実際に取得した原本です。

これを分けておくことで、同じProviderが複数のAPIやファイル配信サービスを持っていても自然に扱えます。

13.3 DatasetとDatasetVersion

Datasetは論理的なデータのまとまりです。

例えば、

全国河川データ
全国DEM
気象観測データ
土地被覆データ

などです。

一方、DatasetVersionは、実際に解析で使用する特定の版です。

Dataset
    ↓
DatasetVersion 2026-08-01
DatasetVersion 2026-08-15
DatasetVersion 2026-08-28

解析ではDataset名だけではなく、必ずDatasetVersionまで固定します。

これにより、

同じ解析をあとから再現する
古いVersionと新しいVersionを比較する
Source更新による結果の違いを確認する

ことができます。

13.4 観測データは観測系まで含めて管理する

Observationは値だけを持つものにはしません。

例えば水位2.31 mという値があっても、

どの観測所なのか
どの機器なのか
どの`ObservationChannel`なのか
どの単位なのか
観測品質はどうか

が分からなければ使いにくいためです。

基本的には、

Station
  ↓
Instrument
  ↓
ObservationChannel
  ↓
Observation

という構造にします。

観測値を補間、集計、換算、複数観測の組合せなどで加工した値はDerivedObservationとして分けます。元のObservationを上書きせず、使用した観測値と処理方法をProvenanceから追えるようにします。

地震波形、火山性微動、連続映像、熱画像などの大きなデータは、Databaseへ直接保存せず、

ObservationChannel
       ↓
SignalAsset
       ↓
Object Storage

として管理します。

Database側には、

開始時刻
終了時刻
サンプリング周波数
ObservationChannel
ファイル形式
Checksum
Object Storage上の保存先

などのMetadataだけを持たせます。

13.5 ForecastとGriddedForecastAsset

予報データは、単純な時系列だけでは足りない場合があります。

例えば数値予報では、

予報開始時刻
予報対象時刻
高度
変数
予報メンバー
緯度
経度

という複数の次元を持ちます。

そのため、大きな予報格子はGriddedForecastAssetとして扱います。

例えば、

temperature[time, level, y, x]

rainfall[forecast_time, y, x]

wind[
  forecast_time,
  pressure_level,
  y,
  x
]

ensemble_rainfall[
  member,
  forecast_time,
  y,
  x
]

といったデータです。

MetadataはCatalogやDatabaseで管理し、実体は、

NetCDF
Zarr
COG
GRIB

などの形式でObject Storageへ保存します。

GriddedForecastAssetでは、ファイル全体が複数の時刻・高度・アンサンブルメンバーを含む場合があるため、単一値だけをMetadataとして持たせません。少なくとも次の内容を管理します。

forecast_reference_at
forecast_valid_range
forecast_time_axis
lead_time_axis
variables
vertical_levels
vertical_level_type
ensemble_members
grid_definition
units

個々の予測値やスライスを扱うときは、forecast_valid_at、lead_time、vertical_level、ensemble_memberを明示します。

13.6 共通Envelope

外部データを正規化するときは、分野固有の内容だけではなく、多くのレコードで共通して必要になる情報をEnvelopeとして持たせます。

例えば水位観測なら次のようになります。

{
  "schema_name": "observation.water_level",
  "schema_version": "1.0",
  "record_id": "internal-stable-id",
  "record_version_id": "immutable-version-id",
  "revision": 1,
  "source_id": "source-id",
  "source_record_id": "provider-record-id",
  "authority_class": "OFFICIAL_OBSERVATION",
  "observed_at": "...",
  "issued_at": null,
  "valid_from": "...",
  "valid_to": null,
  "retrieved_at": "...",
  "ingested_at": "...",
  "geometry": {},
  "horizontal_crs": "...",
  "vertical_datum": "...",
  "quality": {},
  "provenance": {},
  "payload": {}
}

Envelopeは、外部情報を正規化したレコードで共通して必要になる情報を入れる場所です。source_idやsource_record_idを持たない内部生成データでは、これらを無理に埋めず、Provenanceや関連Entityから入力元をたどれるようにします。

13.7 時刻は意味ごとに分ける

災害情報では、「日時」を一つだけ持つ設計にしません。

例えば、

observed_at
  実際に観測された時刻

occurred_at
  現象が発生した時刻

issued_at
  提供元が発表した時刻

forecast_reference_at
  予報計算や予測の基準時刻

forecast_valid_at
  予測値が対象とする時刻

valid_from / valid_to
  情報が有効な期間

retrieved_at
  Connectorが取得した時刻

ingested_at
  プラットフォームへ登録した時刻

published_at
  一般公開した時刻

を分けて持ちます。

例えば、

10:00 観測
10:05 提供元が発表
10:06 プラットフォームが取得
10:07 プラットフォームへ登録
10:15 Review後に公開

という流れを追えるようにします。

13.8 record_id、record_version_id、source_record_id

内部の論理ID、各版のID、外部IDは分けます。

record_idは、訂正前後を通して同じ情報であることを示すプラットフォーム内部の安定IDです。record_version_idは、訂正や更新で作られた各版を一意に識別する不変IDです。source_record_idは外部Providerが使っているIDです。

record_id
  訂正前後を通して変わらない論理ID

record_version_id
  各版を一意に識別する不変ID

source_record_id
  提供元APIのID

提供元がID体系を変更しても、プラットフォーム内部のIDまで変わらないようにします。提供元がRevision IDを持つ場合は、それも別項目として保持します。

13.9 authority_class

同じ地図に表示される情報でも、その性質は違います。

そこで、

OFFICIAL_ALERT
OFFICIAL_OBSERVATION
OFFICIAL_EVENT_INFO
SATELLITE_DERIVED
PLATFORM_MODEL_RESULT
RESEARCH_REFERENCE
AI_GENERATED_EXPLANATION

など、情報の性質を示す分類を持たせます。authority_classはEntityの種類ではなく、出典や情報の性質を表示・制御するための分類です。

これによりPublic Webでも、

公式情報
観測
推定
解析結果
参考情報

を区別できます。

13.10 GeometryとCRS

位置を持つデータにはGeometryだけでなく、座標系も残します。

{
  "geometry": {},
  "horizontal_crs": "..."
}

標高、水位、震源深さなどでは、さらに、

vertical_crs
vertical_datum
depth_reference
positive_direction

も管理します。

元データのCRSは失わず、

Source CRS
    ↓
Analysis CRS
    ↓
Web Display CRS

という変換履歴をProvenanceへ残します。

13.11 Quality

品質情報も共通Envelopeの一部として扱います。

例えば、

{
  "quality": {
    "status": "VALID",
    "completeness": "COMPLETE",
    "location_status": "FINAL",
    "flags": []
  }
}

のようにします。

分野によって品質項目は異なるため、共通部分と拡張部分を分けます。

例えば地震では、

震源位置が暫定か確定か
Magnitudeが暫定か

を持てます。

気象なら、

欠測
異常値
品質管理Flag

などを持たせます。

13.12 Provenance

Provenanceでは、

このデータがどこから来て
何を使って
どの処理で作られたか

を記録します。

例えば、

SourceAsset
   ↓
Normalize
   ↓
DatasetVersion
   ↓
DEM補間処理
   ↓
Derived Dataset
   ↓
RunInput
   ↓
Flood Solver
   ↓
RunOutput

という流れを後からたどれるようにします。

最低限、

source
input_asset
process
software_version
engine_version
parameter
created_at
checksum

などを管理します。

13.13 payloadの扱い

payloadは分野固有の値を入れる場所ですが、何でもJSONとして押し込む場所にはしません。

例えば、

時刻
位置
Source
品質
Version
Provenance
公開制御

など、検索や管理に頻繁に使うものは共通列として持ちます。

payloadには、

地震のMagnitude
火山のAlert Level
河川の流量
衛星Scene固有Metadata

など、そのSchemaに固有の情報を入れます。

ここでは、次の二つを分けて考えます。

共通して検索・管理する項目
       → Envelope

分野固有の内容
       → Payload

という分け方です。

13.14 地震向け拡張Schema

地震Occurrenceでは、共通Envelopeに加えて、地震固有の項目を持たせます。

{
  "schema_name": "occurrence.earthquake",
  "schema_version": "1.0",
  "record_id": "internal-occurrence-id",
  "record_version_id": "immutable-occurrence-version-id",
  "revision": 1,
  "source_id": "source-id",
  "source_record_id": "provider-event-id",
  "authority_class": "OFFICIAL_EVENT_INFO",
  "occurred_at": "...",
  "geometry": {
    "type": "Point",
    "coordinates": [139.0, 35.0]
  },
  "quality": {
    "location_status": "PRELIMINARY"
  },
  "payload": {
    "depth": {
      "value": 10.0,
      "unit": "km",
      "reference": "source-defined-reference",
      "positive_direction": "down"
    },
    "magnitude": {
      "value": 5.2,
      "type": "source-defined-type",
      "status": "PRELIMINARY"
    },
    "uncertainty": {}
  }
}

この例は、一つのSourceの情報からHazardOccurrenceを初期生成した場合の簡略形です。複数Sourceを同じ地震へ関連付ける場合は、次節のOccurrenceSourceLinkを使い、一つのsource_idだけを正本とみなしません。

地震情報では、Magnitudeの数値だけを保存しません。

Magnitudeの種類
暫定値か確定値か
震源深さの基準
位置の確度
不確実性

も一緒に持たせます。

13.15 同じ地震に複数Sourceがある場合

複数の機関が同じ地震を発表することがあります。

この場合、Sourceごとの情報を上書きせず、

Source A
    ↓
OccurrenceSourceLink

Source B
    ↓
OccurrenceSourceLink

        ↓

HazardOccurrence

として関連付けます。

同一地震かどうかが曖昧な場合は、無理に自動統合せず、

AUTO_MATCHED
MANUAL_CONFIRMED
PENDING_REVIEW
REJECTED_MATCH

などの状態を持てるようにします。

13.16 火山向け拡張Schema

火山情報では、噴火が起きたときだけEntityを作るのではなく、恒常的なVolcanoを基準にします。

Volcano
  ├── Observation
  ├── Bulletin
  ├── Alert
  ├── Forecast
  └── HazardOccurrence

例えば火山Alertは次のようになります。

{
  "schema_name": "alert.volcano",
  "schema_version": "1.0",
  "record_id": "internal-alert-id",
  "record_version_id": "immutable-alert-version-id",
  "revision": 1,
  "source_id": "source-id",
  "source_record_id": "provider-alert-id",
  "authority_class": "OFFICIAL_ALERT",
  "subject_id": "volcano-id",
  "issued_at": "...",
  "valid_from": "...",
  "valid_to": null,
  "quality": {},
  "payload": {
    "alert_level": {
      "code": "source-defined-code",
      "label": "source-defined-label"
    },
    "target_areas": [],
    "phenomena": [],
    "status": "ACTIVE"
  }
}

subject_idはプラットフォーム内部の安定した火山IDです。

提供元によって火山名やCodeが違う場合は、

Provider Volcano Code
       ↓
Vocabulary / Mapping
       ↓
プラットフォームVolcano ID

として対応付けます。

13.17 火山観測

火山では、次のような多様な観測を同じ火山へ関連付けます。

火山性地震
火山性微動
GNSS
傾斜
地殻変動
噴煙
噴気
火山ガス
熱観測
カメラ
衛星観測

波形や映像はSignalAsset、衛星RasterはRasterAssetやSatelliteSceneとして扱い、Observationから参照します。

13.18 訂正・新版・取消

災害情報は、発表後に訂正されることがあります。

そのため、同じrecord_idの内容をUPDATEして最新版だけ残す方法は使いません。訂正や更新のたびに新しいrecord_version_idを発行し、版同士の関係を残します。

例えば、

record_id = A

Version 1  record_version_id = A-1
   ↓ corrects / supersedes
Version 2  record_version_id = A-2
   ↓ corrects / supersedes
Version 3  record_version_id = A-3

という形です。

版の状態は、

ACTIVE       現在有効な版
SUPERSEDED   新版に置き換えられた版
WITHDRAWN    取消・撤回された版

のように管理します。訂正版か通常更新かといった変更の種類は、状態とは分けてrevision_type等に記録します。

Public Webでは現在有効な版を基本表示とし、必要に応じて過去版と訂正関係も確認できるようにします。

13.19 Schema Registry

共通Envelopeと分野別SchemaはVersion管理します。

例えば、

observation.water_level 1.0
observation.water_level 1.1

occurrence.earthquake 1.0
occurrence.earthquake 2.0

alert.volcano 1.0

のようにします。

Schemaを変更するときは、

後方互換性がある変更か
必須項目が増えたか
型が変わったか
Migrationが必要か

を確認します。

Connectorは、どのSchema VersionへNormalizeするかを明示します。

これにより、外部APIの変更があっても、プラットフォーム内部のSchema変更を管理しやすくなります。

13.20 Vocabulary

同じ意味の値が情報源ごとに違う表現にならないよう、内部Vocabularyを持ちます。

例えば、

river_height
waterLevel
wl

をプラットフォーム内部では、

water_level

へ揃えます。

ただし、元の項目名やCodeは失いません。

内部標準値
    +
Provider原語
    +
Provider Code

を一緒に保存します。

火山Alert LevelやMagnitude Type、観測種別なども同じ考え方で扱います。

13.21 大きなデータはDatabaseへ入れすぎない

すべてをPostgreSQLへ保存する構成にはしません。

Databaseには、

ID
Metadata
Relation
Geometry
検索に必要な属性
Object Storageへの参照

を置きます。

一方、

衛星画像
DEM
予報格子
地震波形
火山性微動
連続映像
2D氾濫結果

などはObject Storageへ置きます。

PostgreSQL / PostGIS
        │
        │ Metadata / URI
        ▼
Object Storage
        │
        ├── COG
        ├── NetCDF
        ├── Zarr
        ├── GeoParquet
        └── Signalファイル

という分担です。

これにより、Databaseを巨大なファイル置き場にせず、検索と関係管理に集中させます。

13.22 共通データモデルで目指すこと

このデータモデルで重要なのは、すべての災害データを同じ形にすることではありません。

目指すのは、

違う分野のデータでも
出典を追える

Versionを追える

時間で検索できる

地図で検索できる

品質を確認できる

解析入力として固定できる

公開版を再現できる

という状態です。

気象、地震、火山、洪水、衛星といった分野ごとの違いは残しながら、データ管理の基本部分だけを共通化します。

この構造なら、新しい災害種別や外部APIが増えても、既存のデータモデルを大きく作り直さずに拡張できます。

14. Event、Occurrence、Bulletin、Alert、Observation、Forecast、Scenarioを分ける

これらは同じ災害に関係する情報でも、意味と更新のされ方が違います。保存するときに一つの種類へまとめず、それぞれの役割を分けます。

種別	意味
HazardOccurrence	局地的な豪雨、熱波、地震、噴火、崩壊など、実際に発生した個々の物理現象
Event	複数のOccurrence、Bulletin、Alert、Forecast、Observation、ImpactResult等を一つの災害としてまとめる単位
Bulletin	提供機関などが発表した、発生事象や活動状況を伝える情報文書
Alert	危険への注意・警戒を促し、有効期間や対象範囲を持つ情報
Observation	センサー、現地調査、衛星などによって実際に観測された値
DerivedObservation	Observationを補間・集計・換算・推定して作成した派生値
Forecast	提供元が発表・配信する将来時刻に対する予測情報
Scenario	解析のために仮定した条件の組合せ
RunOutput / HazardResult	プラットフォーム内でModelを実行して得た出力と、そのうち災害外力として整理した結果
ImpactResult	Hazardが人、建物、交通、施設などへ与える影響の評価結果

地震や火山では、とくに「発表された情報」と「実際に起きた現象」を分けておく必要があります。

例えば、公式機関から地震に関する発表が一つ届いても、その発表文そのものを一つの地震として保存するわけではありません。

地震に関する発表
    → Bulletin

実際に発生した地震
    → HazardOccurrence

同じ地震について、後から震源位置やマグニチュードが修正され、新しい発表が出ることがあります。その場合も、発表が増えるたびに別の地震が発生したことにはしません。

複数の発表は、必要に応じて同じ地震を表すHazardOccurrenceへ関連付けます。

最初の地震情報
        │
訂正された地震情報
        │
震度に関する発表
        ↓
  一つのHazardOccurrence

本震の後に余震や津波、斜面崩壊などが続いた場合は、それぞれを別のHazardOccurrenceとして残し、必要に応じて一連の災害Eventへまとめます。

本震HazardOccurrence
余震HazardOccurrence
余震HazardOccurrence
津波HazardOccurrence
斜面崩壊HazardOccurrence
        ↓
      一つのEvent

火山も同じ考え方です。火山に警報や注意情報が出ていることと、実際に噴火が発生したことは別です。

火山の警報・警戒状態
    → Alert

火山活動に関する解説
    → Bulletin

実際に発生した噴火
    → HazardOccurrence

そのため、警戒レベルが上がっただけで「噴火が発生した」として保存することはしません。

また、火山そのものは噴火していない期間にも存在します。

Volcano
  ├── 平常時のObservation
  ├── 火山性地震・微動のObservation / SignalAsset
  ├── 噴煙・熱観測
  ├── Bulletin
  ├── Alert
  └── 噴火HazardOccurrence

Volcanoは長く使い続ける基準Entityとして管理し、観測、発表、警報、噴火などをそこへ関連付けます。

同じ考え方で、情報の種類を混ぜないようにします。

観測した値
    → Observation

観測から計算・推定した派生値
    → DerivedObservation

提供元から発表された情報・解説
    → Bulletin

警報・注意情報
    → Alert

提供元が発表・配信した将来予測
    → Forecast

実際に発生した現象
    → HazardOccurrence

複数の現象や情報をまとめた災害
    → Event

プラットフォーム内で計算した結果
    → RunOutput / HazardResult

例えば、数値モデルで計算した浸水深をObservationとして保存したり、AlertそのものをEventとして扱ったりはしません。

「何が発表されたのか」「何が観測されたのか」「何が推定されたのか」「実際に何が起きたのか」「プラットフォームが何を計算したのか」を分けて保存することで、あとから見ても情報の意味と出典を判断できます。

15. 時刻と訂正履歴

災害情報では、単に「いつ起きたか」だけでは足りません。

時刻	用途
observed_at	実際に観測した時刻
occurred_at	事象が発生したとされる時刻
issued_at	提供者が情報を発表した時刻
forecast_reference_at	予報計算や予測の基準時刻
forecast_valid_at	予測値が対象とする時刻
valid_from / valid_to	情報が有効な期間
retrieved_at	Connectorが外部から取得した時刻
ingested_at	内部へ登録した時刻
published_at	プラットフォームが公開した時刻
superseded_at	新版に置き換えられた時刻
retracted_at	取消・撤回された時刻

気象予報では、予報を作った基準時刻と、その予報が対象とする時刻を分けます。同じ対象時刻に対して予報が何度も更新されるため、最新値だけに上書きせず、lead_timeや予報版も含めて履歴を残します。地震の発生時刻はoccurred_atへ記録し、後の発表で内容が変わった場合も旧版を残します。火山の噴火開始・終了は、不明、概略、推定、確認済みを区別し、必要に応じて時間の幅として持たせます。火山Alertの有効期間は、噴火そのものの期間とは別に管理します。波形や高頻度時系列では、サンプル開始時刻、サンプリング周波数、時計品質、欠測区間をSignalAssetのMetadataへ持たせます。

時刻には、必要に応じてtime_precision、time_uncertainty、time_statusを付けます。DB内の時刻はUTCで揃えますが、元データのタイムゾーンと時刻表記も残します。画面では、利用者の地域設定に合わせて表示します。

外部情報の訂正を受け取っても、旧レコードをUPDATEで消しません。supersedes、retracts、correctsの関係を残します。

16. 地理空間データで最初に揃えておくこと

16.1 水平座標と鉛直基準を分ける

洪水、津波、河川、水位、DEMだけでなく、地震の震源深さ、火口標高、噴煙高度、地殻変動でも、座標と高さ・深さの基準が合っていなければ正しい解析はできません。

次の項目をMetadataへ含めます。

horizontal_crs
vertical_crs
vertical_datum
geoid_model
tidal_datum
unit
axis_order
spatial_resolution
horizontal_accuracy
vertical_accuracy
depth_reference
positive_direction
coordinate_epoch

16.2 表示用と解析用のCRSを分ける

Web表示は一般的な地図タイルへ合わせても、距離、面積、水理計算まで表示用CRSで行うことはしません。

16.3 Rasterで管理する情報

Pixel size
Grid origin
Grid alignment
NoData
Mask
Resampling method
Data type
Scale / Offset
Spatial extent
Overviews

同じ解像度でも、Grid originが違うRasterを暗黙に重ねることは避けます。

16.4 Vectorで管理する情報

Geometry type
2D / 3D
Validity
Topology
Direction
Network connectivity
Spatial accuracy
Generalization level

16.5 国際展開を見据えて考慮する事項

日付変更線をまたぐGeometry
複数言語の名称
地域ごとの単位
地域固有の測地系・高さ基準
行政区分の変更履歴
地域ごとの公開条件と法制度

16.6 地震・火山で必要な3D・深さ情報

地震・火山では、2Dの地図座標だけでは足りません。次の情報を明示します。

震源深さ          何を基準に下向きを正とするか
火口・噴気孔標高  使用したDEM、測地系、鉛直基準
噴煙・雲頂高度    地表からの相対高か、海面等からの標高か
地殻変動          東西・南北・上下成分と座標フレーム、観測Epoch
断層形状           Strike、Dip、Rakeと3D Geometryの定義

震源のPoint Geometryへ深さを暗黙の3番目の座標として入れるだけではなく、depth、depth_reference、positive_directionを明示します。解析用の3D座標へ変換した場合も、元の表現と変換手順をProvenanceへ残します。

16.7 気象予報と多次元格子で揃えること

気象データは、単純な2次元Rasterだけでは表せません。時刻、高度、予報時間、予報メンバーを持つデータがあるため、次の情報をMetadataへ含めます。

forecast_reference_at
forecast_valid_at
lead_time
vertical_level
vertical_level_type
ensemble_member
grid_definition
cell_methods
calendar
units

同じ変数名でも、瞬間値、時間平均、積算値では意味が異なります。雨量や日射量などは、集計期間とcell_methodsを確認せずに足し合わせません。観測所のPoint時系列、レーダーや衛星の格子、数値予報の格子も、同じ値のように見えても別のAssetとして扱い、変換や補間を行った場合は手順を残します。

17. データの流れと保存先

PostgreSQL / PostGIS

Metadata
Source Registry
Catalog
Event、HazardOccurrence、Bulletin、Alert、Forecast、Observation
Geometry、Station、Network
Model、Scenario、Run、Publication
Permission、Audit

Object Storage

外部原本
GeoTIFF / COG
NetCDF / Zarr、気象予報・レーダー・多次元格子
Parquet / GeoParquet
SatelliteScene
地震波形、火山性微動、傾斜、GNSS等のSignalAsset
カメラ映像、熱画像、連続観測ファイル
Modelファイル
RunのArtifact
レポート

Redis / Queue

Job Queue
短期Cache
Lock
Progress

Redisは、記録の正本には使いません。

主な形式

用途	基本形式
Raster配信	COG
気象予報・時系列Raster・多次元計算	原本形式を保持し、内部利用はNetCDF / Zarrを基本とする
Vector交換	GeoPackage / GeoJSON
大規模Vector分析	GeoParquetを採用候補とする
時系列・表形式	Parquet / CSV
高頻度波形・信号	分野標準のSignalファイル＋Catalog Metadata
衛星・Asset Catalog	STAC
地図表示	Raster Tile / Vector Tile

保存期間の考え方

PERMANENT    原本、公開版、再現に必要な成果
LONG_TERM    正規化データ、主要Run
TEMPORARY    中間処理、再生成可能成果
CACHE        Tile、Preview、一時Download

Licenseや契約で保存期間が決まっている場合は、一般的な保持期間の方針より利用条件を優先します。

18. Data Catalog、Version、Provenance

Catalogは単なる「ファイル一覧」ではありません。何があり、どこから来て、どの版が、どの処理に使われたかまで追跡します。

各DatasetVersionには、少なくとも次の情報を残します。

provider
source
license
attribution
retrieved_at
checksum
schema_version
spatial_extent
temporal_extent
CRS / vertical datum
quality summary
source asset一覧
parent version / DatasetLineage
transformation history

外部へ公開するときは、内部Catalogをそのまま見せるのではなく、公開してよい項目だけをOGC API - Records、DCAT、STACなどへ投影します。

19. 品質、不確実性、競合

19.1 品質を見る観点

完全性（Completeness）
鮮度・適時性（Timeliness）
妥当性（Validity）
一貫性（Consistency）
空間精度（Spatial accuracy）
時間精度（Temporal accuracy）
解像度（Resolution）
信頼性（Credibility。出典や検証状況に基づいて評価する）
仕様適合性（Conformance）
Lineageの完全性（Lineage completeness）

19.2 品質状態

19.3 不確実性の持ち方

可能な場合は、値だけではなく、次の情報も保持します。

uncertainty_type
uncertainty_value
confidence_level
method
spatial_accuracy_m
temporal_accuracy_s
quality_flags
assumptions

地震では、震源位置や深さの誤差、Magnitudeの種類と確定状況、観測点数などを品質情報として残します。火山では、観測方法、検出限界、欠測、観測範囲、推定・目視・機器観測の違いを記録します。地図上では、信頼度を色だけで表さず、凡例、パターン、ツールチップ、数値を組み合わせます。

19.4 情報が食い違う場合

複数機関の値が違っていても、一つの値へ上書きしません。

Source A  2.31 m
Source B  2.44 m
プラットフォーム判定  CONFLICT

代表値が必要な場合は、別にDerivedObservationを作り、採用ルール、入力元、計算方法を残します。

20. 複合災害と連鎖災害

一つのEventに、一つのHazardだけを割り当てる設計では足りません。

EventRelationでは、EventやHazardOccurrenceの間にある因果・連鎖関係と、Event同士の構成関係を扱います。単にOccurrenceをEventへ所属させるだけの場合はEventOccurrenceLinkを使い、因果関係とは分けます。

CAUSED_BY
TRIGGERS
CONTRIBUTES_TO
COINCIDES_WITH
CASCADES_TO
PART_OF
MERGED_FROM
SPLIT_INTO

例えば、地震HazardOccurrenceが津波HazardOccurrenceを誘発した関係はTRIGGERSで表せます。PART_OF、MERGED_FROM、SPLIT_INTOのような構成・再編成の関係は、主にEvent同士で使います。

人、施設、道路、ライフラインなどへの影響はEventRelationへ入れず、Impact Domainで管理します。また、Bulletin等の訂正・新版関係に使うsupersedesとも分けます。

Eventは後から統合・分割されることがあるため、外部IDを主キーには使いません。内部の安定IDを持ち、別名や外部IDとの対応を別に管理します。

21. Hazard ModuleとAnalysis Engine

解析エンジンは、プラットフォームDBへ直接依存させません。

Engineが宣言する内容

各Engineは、次の内容を宣言します。

engine_id
engine_version
container_image_digest
supported_hazards
required_inputs
optional_inputs
parameter_schema
output_schema
resource_requirements
supports_restart
supports_gpu
deterministic
verification_suite
license

共通の実行規則

入力はDatasetVersionまたは固定Artifactを参照する
実行開始後に入力の最新版へ自動追従しない
Container imageはTagだけでなくDigestを残す
乱数を使う場合はSeedを残す
単位変換、CRS変換、補間方法をArtifactへ記録する
Solverの標準問題によるVerificationを別に持つ
実観測との比較はValidationとして分ける
Calibration結果を元データへ上書きしない

情報Moduleと解析Engineを分ける

気象、地震、火山では、公式のBulletin、Alert、Forecast、観測、訂正履歴、地図表示を扱う情報Moduleを先に運用できるようにします。数値解析Engineがまだなくても、情報ModuleはConnector、Catalog、Bulletin、Alert、Forecast、Observation、Occurrence、Publicationの共通機能だけで成り立ちます。プラットフォーム内で解析結果を作る場合にだけEngine Contractを使い、結果はRunOutput / HazardResultとして保存します。

気象情報Moduleと異常気象の分析

気象情報Moduleでは、雨量、気温、湿度、風、気圧、積雪などの観測と、予報、発表、警戒情報を同じ地図と時間軸へ整理します。洪水・土砂災害へ入力を渡すだけでなく、局地的な豪雨、猛暑・酷暑、強風、大雪など、それ自体の影響も確認できるようにします。

プラットフォーム独自の処理として、累積雨量、短時間雨量、平年差、暑さ指数などの派生指標を計算できます。曝露人口や健康影響まで評価する場合は、これらの指標を入力としてImpact Domainで扱います。いずれも提供元の公式発表とは分けて表示し、使用した観測、予報版、計算式、対象期間を追えるようにします。

最初に実装する数値解析モジュール

洪水Moduleでは、次の機能を一つの解析の流れとしてつなぎます。

洪水の次は、同じEngine Contractを使って異常気象、土砂災害、地震、火山、津波などへ広げます。ただし、気象・地震・火山の情報Moduleは、解析Engineの完成を待たず、共通基盤の段階から提供します。

地震情報Moduleと将来の地震解析Engine

初期段階では、まず情報Moduleを完成させます。地震動推定、液状化、斜面、建物被害などのEngineは、入力データ、Verification、利用目的がはっきりしたものから順に追加します。

火山情報Moduleと将来の火山解析Engine

火山では、降灰分布、噴煙・粒子輸送、火砕流・泥流などを、一つのSolverへ無理に押し込みません。現象ごとにEngineを分け、共通の火山台帳、観測、Scenario、Run、Impactへつなぎます。

22. Model、Scenario、Runと解析結果

Runに固定するもの

DatasetVersion
ModelVersion
ScenarioVersion
EngineVersion
ProjectSnapshot
実際に渡したRunInput
Parameter
境界条件
Container image digest
Python・ネイティブLibraryのVersion
CPU / GPU情報
Seed
開始・終了時刻
結果Checksum

RunOutputとArtifact

RunOutputは、最大浸水深、流量時系列、影響人口など、後続の処理が参照する論理的な出力です。

Artifactは、GeoTIFF、CSV、NetCDF、ログ、画像、レポートなど、実際に保存される物理ファイルです。

両者を分けておけば、ファイル名や保存場所が変わっても、解析上の意味は保てます。

Run状態

23. Impact評価

HazardResultと社会基盤を空間的に重ねるだけでなく、ネットワークのつながりや代替性も確認します。

Riskを示すときは、Hazardだけから計算した値を「総合リスク」とは呼びません。Exposure、Vulnerability、Capacityとして何を使ったかを明示し、既存ハザードマップの代わりではなく、リスクの抽出や優先順位付けを補う情報として扱います。

気象・地震・火山では、共通のOverlayに加え、それぞれのHazardに合った影響指標を持たせます。

Hazard	主なImpactの例
気象・異常気象	短時間強雨による冠水、酷暑による健康影響、強風・大雪による交通障害や停電、農業・水資源への影響
地震	揺れによる建物・橋梁・設備影響、液状化、斜面崩壊、道路閉塞、停電・通信障害、津波への連鎖
火山	降灰厚・堆積量、屋根・設備への負荷、視程・交通への影響、取水・農地への影響、火砕流・泥流による到達性低下

同じ「影響あり」という判定でも、根拠になるHazard強度や閾値は異なります。そのため、HazardごとのVulnerabilityProfileと判定ルールをVersion管理します。

24. Publicationと公開判定

Runが成功しても、それだけで解析成果を公開することはしません。

公開前に確認する内容

出典とAttribution
Licenseと再配布可否
観測時刻、発表時刻、更新時刻
公式情報、推定、計算結果の分類
空間・時間の精度
不確実性と注意事項
個人情報・機微情報
凡例と単位
旧版との関係
Reviewerと承認日時

Public WebとPublic APIは、Publicationに含まれる固定版だけを参照します。

25. 公開APIと標準

外部から入ってくるAPIの仕様はばらばらでも、プラットフォームから外へ出すAPIは揃えます。

REST API

/api/v1/sources
/api/v1/datasets
/api/v1/events
/api/v1/bulletins
/api/v1/alerts
/api/v1/occurrences
/api/v1/observations
/api/v1/forecasts
/api/v1/weather
/api/v1/earthquakes
/api/v1/volcanoes
/api/v1/volcanoes/{volcano_id}/observations
/api/v1/hazards
/api/v1/impacts
/api/v1/models
/api/v1/scenarios
/api/v1/runs
/api/v1/publications

/weatherは観測、Forecast、Alertを気象向けにまとめたRead Model、/earthquakesはHazardOccurrenceを地震向けに見せるRead Model、/volcanoesは恒常的な火山台帳と現在の状態を返すRead Modelです。個別APIが増えても、正本となるHazardOccurrence、Alert、Observation、Forecast、Catalogの契約は変えません。

地理空間API

用途	公開方式
Vector Feature	OGC API - Features
Raster / Vector Tile	OGC API - Tiles
Environmental time-space query	OGC API - EDR
Catalog検索	OGC API - Records
Satellite / Asset検索	STAC API
解析Job公開	内部Job APIを先に整備し、必要に応じOGC API - Processesへ対応
Alert交換	CAP互換の入出力

API設計規則

OpenAPIを正本にする
非同期EventはAsyncAPIで契約を記述する
Event envelopeはCloudEventsを採用候補とする
URLまたはHeaderでVersionを明示する
廃止予定と終了日を通知する
Pagination、Filter、Sort、Field selectionを揃える
Rate LimitとQuotaを公開する
ETag、Last-Modified、Cache-Controlを使う
大容量成果物は署名付きURLまたはDownload Jobで渡す
破壊的変更は新Versionへ分ける

26. Web画面

全体構想のイメージ図です。

災害地理空間解析プラットフォーム
│
├── Public Map
├── Events
├── Bulletins / Alerts / Observations
├── Weather Information
├── Earthquake Information
├── Volcano Information
├── Data Catalog
├── Satellite
├── Hazard Analysis
│   ├── Flood
│   ├── Landslide
│   ├── Earthquake
│   ├── Volcano
│   ├── Tsunami
│   └── ...
├── Impact
├── Models
├── Scenarios
├── Runs
├── Results
├── Validation
├── Sources / Status
└── Administration

地図表示で必ず出す情報

レイヤー名
情報種別
提供元
観測・発表・更新時刻
単位
精度・解像度
品質フラグ
License・Attribution
公式情報か解析結果か
最新版か旧版か

災害時を想定したUI

スマートフォン対応
低帯域モード
地図以外の一覧表示
色覚差に配慮した凡例
色だけに依存しない記号
キーボード操作
画面読み上げ用ラベル
印刷・PDF・画像出力
「○分前」だけでなく絶対時刻も表示
古いデータであることをSTALEとして明示

Webアクセシビリティは、WCAG 2.2のAA相当を目標にします。

気象画面では、雨量、気温、風、積雪などを観測と予測に分け、基準時刻と対象時刻を確認しながら表示します。局地的な強雨や酷暑については、現在値だけでなく、時間変化、過去との比較、関連するAlertやImpactResultも追えるようにします。地震画面では、震央、深さ、Magnitudeの種類、観測震度、発表版、訂正関係、関連する津波・被害情報を確認できるようにします。火山画面では、火山台帳、火口・観測点、現在有効なAlert、活動履歴、噴火HazardOccurrence、観測時系列、対象範囲を一つの画面で追えるようにします。

気象・地震・火山とも、最新値だけを大きく見せて履歴を隠すことはしません。現在有効な情報、直前の版、発表時刻や予報基準時刻、取得時刻、Sourceの状態を同時に確認できるようにします。

27. AIとGIS MCPの位置づけ

AIはPlatform Coreの代わりではなく、プラットフォームAPIを利用する一つのクライアントとして置きます。

AIへ任せること

Catalog検索
EventやRunの要約
複数Runの差分説明
地図操作
出典付きの質問応答
定型レポートの下書き

AIへ任せないこと

警報や避難情報の発令
未承認結果の公開
出典なしの断定
権限を越えたデータ取得
数値Solverの代替
人命に関わる最終判断

初期のToolは読み取り専用を基本にします。更新、実行、公開には、明示的な権限と利用者の確認を必要とします。外部文書や取得データに含まれるPrompt Injection（プロンプトインジェクション）も想定し、AIが本文中の指示をそのまま実行しない構造にします。

28. セキュリティ、プライバシー、法的な扱い

28.1 Identityと権限

OIDC / OAuth系の認証
RBACを基本に、必要な部分だけABACを追加
Public、Viewer、Analyst、Reviewer、Data Steward、Operator、Administratorを分ける
Project・Organization単位でデータを分離する
Service Accountを利用者Accountと分ける

28.2 API Security

Object単位とField単位の認可
Rate Limit、Request size、Execution quota
SSRF対策
CORS、CSP、TLS、Secure Cookie
入力検証（Input Validation）
Unsafe API consumption対策
API Inventoryと廃止Endpoint管理
Audit Log

28.3 ソフトウェア供給網

Dependency lock
Container image digest
SBOM
Vulnerability scan
Base image更新方針
署名・Checksum
非root実行
Read-only filesystemを可能な範囲で使用
SecretをImageやGitへ入れない

28.4 プライバシー

災害情報には、住所、氏名、避難状況、被災写真、位置情報などが含まれることがあります。

個人情報を共通Catalogへ無条件に載せない
公開前に匿名化、集約、位置のぼかしを行う
原本と公開版を分ける
Access Policyと保持期間を設定する
操作履歴とDownload履歴を残す

28.5 ライセンスと再配布

APIから取得できることと、その内容をWebで再公開できることは別です。

各SourceとDatasetVersionには、次の情報を持たせます。

license
attribution
commercial_use
modification_allowed
redistribution_allowed
public_api_allowed
storage_allowed
retention_limit
terms_url
terms_reviewed_at

公開できないデータは、内部解析に使えてもPublic APIやTileへは出しません。

29. 災害時の継続稼働

災害時に解析Workerや外部APIが止まっても、すでに公開している情報まで見られなくなる構成は避けます。

運転モード

NORMAL                 通常運転
DEGRADED               一部Source・Worker停止
EMERGENCY_READ_ONLY    公開済み情報の閲覧を優先
MAINTENANCE            管理作業

縮退時の動作

最後に正常取得できた値を保持する
STALE表示を出す
外部API復旧後に欠落期間をBackfillする
重い解析Jobを止め、情報取得と公開を優先する
Public Portalは静的Snapshotへ切り替えられるようにする
Sourceごとに障害を隔離する

バックアップと復旧

PostgreSQLとObject Storageを両方Backupする
Catalogだけ復元してArtifactがない状態を許容しない
Backup取得だけでなくRestore試験を行う
Migration前にRollback手段を用意する
RPO、RTOは本番運用前にSourceと機能ごとに決める

30. 監視と運用指標

サービスが起動しているかだけではなく、利用者が必要な情報を正しく得られているかまで監視します。

監視対象

Sourceごとの最終成功時刻
想定更新間隔と実際の遅延
取得件数、重複、Quarantine数
Schema Drift
API遅延、エラー率
Queue長、Job待ち時間
WorkerのCPU、Memory、GPU、Disk使用量
Tile生成時間
Object Storage容量
DB接続状態、slow query
Public Portalの可用性
BackupとRestoreの試験結果

Sourceの鮮度は、Serviceの稼働状態とは分けて見ます。APIが200を返していても、データが何時間も更新されていなければ正常とはみなしません。

31. Docker Composeを基準にした初期構成

Composeサービス案

workspace-init     Volumeの所有権と初期ディレクトリ
web-public         公開Portal
web-workspace      解析Workspace
api                FastAPI
scheduler          定期同期とJob起動
connector-worker   外部情報取得
analysis-worker    GIS・衛星・解析Engine
tile               Raster / Vector Tile
redis              Queue / Cache
postgres           PostgreSQL + PostGIS
object-storage     MinIO等
otel-collector     トレース / メトリクス / ログ収集
reverse-proxy      Nginx / TLS終端
smoke              公開Web・API・Worker接続確認
test               lint / type / unit / integration

初期段階では、複数のサービスを同じContainer imageから起動しても構いません。ただし、RoleとEntrypointは分け、実行ユーザー、書込み先、必要なバイナリをサービスごとに確認します。

32. Repository構成案

disaster-geospatial-platform/
├── apps/
│   ├── web-public/
│   └── web-workspace/
│
├── services/
│   ├── api/
│   ├── scheduler/
│   ├── connector-worker/
│   ├── analysis-worker/
│   └── tile-service/
│
├── packages/
│   ├── domain/
│   ├── application/
│   ├── ports/
│   ├── schemas/
│   ├── geo/
│   ├── catalog/
│   ├── events/
│   ├── runs/
│   └── security/
│
├── connectors/
│   ├── sdk/
│   ├── weather/
│   ├── river/
│   ├── earthquake/
│   ├── volcano/
│   ├── satellite/
│   ├── traffic/
│   └── custom/
│
├── engines/
│   ├── sdk/
│   ├── flood/
│   ├── landslide/
│   ├── earthquake/
│   ├── volcano/
│   └── impact/
│
├── schemas/
│   ├── jsonschema/
│   ├── openapi/
│   ├── asyncapi/
│   ├── stac/
│   └── vocabularies/
│
├── migrations/
├── infra/
│   ├── compose/
│   ├── nginx/
│   ├── postgres/
│   ├── monitoring/
│   └── scripts/
│
├── tests/
│   ├── unit/
│   ├── contract/
│   ├── integration/
│   ├── e2e/
│   ├── numerical/
│   ├── geospatial/
│   ├── security/
│   └── fixtures/
│
├── docs/
│   ├── architecture/
│   ├── adr/
│   ├── data-model/
│   ├── operations/
│   └── user-guide/
│
├── compose.yaml
├── pyproject.toml
├── package.json
└── README.md

ConnectorとPlatform Coreの依存方向は一方向に揃え、解析EngineはPlatform Coreから独立させます。

Connector
    ↓
Connector SDK / Port / Schema
    ↓
Application
    ↓
Domain

Analysis Engine
    ↓
Engine SDK / Input・Output Schema

DomainからFastAPI、PostGIS、Redis、外部APIを直接参照しません。また、解析EngineからPlatformのApplicationやDomainを直接参照せず、Engine SDKと入出力Schemaを境界にします。これにより、Engineを別ContainerやGPUサーバーへ移してもPlatform Coreへの依存を増やさずに済みます。

33. テストと公開前の確認

テストの種類

テスト種別	内容
Unit	Domain、Mapping、Validation、数式
Schema	JSON Schema、OpenAPI、AsyncAPIの整合
Connector Contract	Fixtureに対するParse・Normalize・訂正処理。地震の震源改訂、火山Alert変更・解除も含む
Integration	PostGIS、Object Storage、Queue、Tile
Geospatial	CRS、Geometry、NoData、Raster alignment、震源深さ・火口標高・噴煙高度の基準
Numerical Verification	既知解、標準問題、質量保存
Validation	観測・衛星・実績との比較
API	認証、認可、Pagination、Rate Limit
Security	SSRF、Path Traversal、危険ファイル、権限越境
E2E	取得から公開まで
Performance	大量Observation、Tile、同時閲覧、Job Queue
Resilience	API停止、Worker停止、DB復旧、Backfill
Restore	Backupからの復元

通常の回帰テストは、外部APIの生の応答へ依存させません。保存したFixtureと契約テストを使い、外部接続テストは別Profileで実行します。

配布・公開前の確認

Python compile
Frontend build / type check
Ruff / mypy / pytest
Schema validation
Database migrationテスト
Docker Compose config
Container image build
非root実行
UID / GIDと書込み権限
EntrypointとHealthcheck
必要なバイナリとLibraryのVersion
API smokeテスト
Worker / Queue smokeテスト
Tile表示
Backup / Restore確認
Manifest / Checksum
SBOM
ZIPまたはRelease Artifact再展開後の再検証

「作業ディレクトリでは動いたのに、配布物では動かない」という状態を防ぐため、最終成果物をいったん展開し直してから検証します。

34. 開発ロードマップ

全体を10のStepに分けます。Step番号は機能の大きさではなく、依存関係に沿って並べます。

Step 1 — 基本原則、Domain、実行基盤

目的
後から大きく作り直さずに済むよう、最初に境界を決めます。

実装

用語集
Domain Model
HazardOccurrence、Volcano、Instrument、SignalAsset、Forecast、GriddedForecastAssetの基本Entity
ADR
Repository
Docker Compose
FastAPI、OpenLayersの最小構成
PostgreSQL / PostGIS、Object Storage
Migration、テスト、CI
Security baseline

完了条件

Public Web、API、DB、Object StorageがComposeで起動する
非root、権限、Healthcheckを確認できる
Project、User、Roleの最小機能が動く
配布物再展開後のテストが通る

Step 2 — Public PortalとAnalysis Workspace

目的
公開閲覧と内部解析を、最初から分けて作ります。

実装

Public Map
Weather Information / Earthquake Information / Volcano Informationの画面骨格
Analysis Workspace
Admin画面の骨格
OIDC連携の境界
Role、Project、Organization
Base map、Layer panel、時刻表示
Accessibility baseline
Public read-only fallback

完了条件

Public利用者がログインなしで公開Layerを閲覧できる
Analystだけが内部Projectへ入れる
未公開データがPublic APIへ出ない

Step 3 — Connector SDKとSource Registry

目的
形式や仕様が異なるAPIやファイルを、同じ流れで取り込めるようにします。

実装

Connector interface
Source Registry
気象情報・地震情報・火山情報を含む代表Connectorと保存Fixture
Pull、差分同期、ファイル取込
Raw保存
Checkpoint、Retry、DLQ、Quarantine
Schema Drift
License、Attribution、再配布条件
Connector稼働状態画面

完了条件

新しいConnectorをCore変更なしで追加できる
同じデータを再取得しても重複しない
API停止後にBackfillできる
原本から再Normalizeできる

Step 4 — Data Catalog、Provenance、共通時空間モデル

目的
データを検索し、再利用し、元の情報までたどれる状態にします。

実装

Dataset / DatasetVersion
SourceAsset / DatasetAsset
Observation、DerivedObservation、Station、Instrument、ObservationChannel、SignalAsset
Forecast、GriddedForecastAsset、基準時刻・対象時刻・lead_time
HazardOccurrence、Volcano、VolcanicFeature
時刻・CRS・鉛直基準・深さ基準
Quality、Lineage
Catalog検索
STAC
OGC API - Records / DCATへの公開境界

完了条件

DatasetVersionから原本と変換履歴を追える
空間・期間・Source・品質で検索できる
Licenseに応じて公開可否を制御できる

Step 5 — Event、Bulletin、Alert、Observation、Forecastの統合

目的
過去と現在の災害情報を、同じ時間軸と地図で扱えるようにします。

実装

Event
HazardOccurrenceとEventOccurrenceLink
Bulletin、Alert、Forecastの分離
気象観測・予報・発表の履歴と、局地的豪雨・酷暑等の表示
EventAlias、EventRelation
地震の震源・Magnitude改訂と地震活動のグルーピング
Volcano Registry、火山Alert、噴火HazardOccurrence
Alertと訂正・取消
Observation、TimeSeries、SignalAsset Metadata
Event自動候補と手動確定
CAP入出力
OGC API - EDR
タイムライン、Source間の競合、STALE表示

完了条件

Eventに複数Sourceの情報を集約できる
Eventなしの観測も継続保存できる
訂正前後と取消を追跡できる
気象予報の基準時刻、対象時刻、lead_time、更新前の版を追跡できる
局地的な豪雨や酷暑を、観測・予報・Alert・派生指標に分けて表示できる
一つの地震に複数版の発表を結び、個別HazardOccurrenceと地震災害Eventを分けられる
噴火がない期間もVolcano、Alert、観測時系列を管理できる
公式、推定、計算結果を描き分けられる

Step 6 — 共通GIS、衛星、地形処理

目的
各Hazard Moduleで共通して使う空間処理を整えます。

実装

Raster / Vector取込
CRS、鉛直基準、Clip、Mosaic、Resample
COG、Tile、Preview
STAC Scene検索
DEM、土地被覆、行政界、道路、建物
雨量・気温・風・積雪等の観測格子、予報格子、レーダー・衛星Asset
地質、地盤、活断層、火山地形、火口・観測点
衛星前処理、地殻変動・熱・噴煙等の派生Asset受入れ
空間品質チェック

完了条件

大容量Rasterを全読込せずWeb表示できる
元CRS、解析CRS、表示CRSを追跡できる
Raster alignmentとNoDataを自動検査できる

Step 7 — Hazard Engine Frameworkと洪水Module

目的
解析Engineを追加しやすい枠組みを作り、その上で最初の本格的なHazard Moduleを完成させます。

実装

Engine SDK / Manifest
Model / Scenario / Run
水文解析
河道網Editor
河川1D
2D氾濫
1D-2D連成
Sentinel-1等から推定した浸水域
Numerical Verification

完了条件

DatasetVersion、ModelVersion、ScenarioVersionを固定してRunできる
質量保存、境界条件、既知解テストが通る
計算浸水域と衛星推定浸水域を比較できる
EngineをPlatform Coreから独立して更新できる

Step 8 — Impact、Network、複合災害

目的
「どこでHazardが起きるか」だけでなく、「何に、どのような影響が出るか」まで扱います。

実装

Exposure Asset
Vulnerability Profile
Critical Facility
Road / Rail / Utility Network
到達性、代替経路、孤立
EventRelation
複合・連鎖災害
局地的豪雨から内水・交通障害、酷暑から健康・電力影響への連鎖
地震から津波・斜面崩壊・火災への連鎖
噴火から降灰・火砕流・火山泥流・交通影響への連鎖
ImpactResult

完了条件

Hazardごとに共通Impact処理を再利用できる
影響人口、施設、道路途絶を算出できる
入力不足の評価を総合Riskとして誤表示しない

Step 9 — Validation、Publication、公開API、AI支援

目的
解析結果を検証し、安全に共有・公開できる状態にします。

実装

Validation / Calibration
不確実性
Run比較
Publication workflow
Public API、OGC API、STAC
気象観測・予報・Alert、地震Occurrence、火山台帳・現在状態の公開Read Model
Download Manifest、Checksum
GIS MCP / AI Assistant
出典付きレポート

完了条件

未承認結果が公開されない
公開成果から入力、Run、Sourceを追跡できる
AIが出典と時刻を示して回答する
AIの更新Toolは権限と確認なしに実行できない

Step 10 — 本番運用、耐障害性、他Hazardへの展開

目的
災害時にも使い続けられる公開プラットフォームとして仕上げます。

実装

Observability
SLO、Alerting、Runbook
Backup / Restore / 災害復旧（DR）
CDN、Static fallback、Emergency read-only
Load test、Security test
Cost、Quota、Job priority
異常気象、Landslide、Earthquake、Volcano、Tsunami等の解析Engine追加
地域別Connector Pack
多言語・国際展開

完了条件

一部APIやWorker停止時も公開情報を読める
Backupから復旧できる
新しいHazard Moduleと地域ConnectorをCore変更なしで追加できる
公開運用手順と責任分界が文書化されている

35. Step間の依存関係

実装は、すべてを完全な直列で進めるわけではありません。Step 2の画面基盤とStep 3のConnectorは並行して進められますが、Catalogが固まる前にHazard固有データを大量に登録することは避けます。

36. 最初から変えない方針

次の項目は、今後の基本設計として固定します。

システム名は地域名や単一Hazardへ固定しない
最初の実証地域は日本、最初の数値解析Hazardは洪水とし、気象・地震・火山情報は共通情報基盤の初期対象にする
外部情報はConnector経由で取り込む
Raw Dataは改変せず保存する
Data Catalog、Version、Provenanceを全機能の土台にする
Event中心だが、ObservationをEventへ依存させない
Bulletin、Alert、Observation、DerivedObservation、Forecast、Scenario、RunOutput / HazardResultを分ける
公式、推定、解析、投稿を明確に分類する
水平CRSと鉛直基準を必須Metadataにする
解析はModel、Scenario、Run、Engine、Inputを版固定する
Public PortalとAnalysis Workspaceを分ける
公開は必ずPublicationを通し、解析成果や条件外データにはReview / Approvalを必須にする
API、Web、AIはPlatform Coreの共通Serviceを利用する
初期構成はモジュラーモノリス＋Worker分離とする
公開系は解析系停止時も読めるようにする
License、Attribution、再配布可否をData Modelへ入れる
Security、Privacy、Auditを後付けにしない
Docker Composeと配布物再展開検証を開発基準にする
個別の地震・噴火等はHazardOccurrenceとし、災害Eventのグルーピングと分ける
火山は噴火Eventから独立したVolcanoとして管理する
高頻度波形・映像はSignalAssetとしてMetadataと実体を分離する
気象予報は基準時刻と対象時刻を分け、更新前の予報版も残す

37. 実装を進めながら決めること

次の項目は、要件や実測結果を見ながら決めます。早い段階で特定の製品へ固定しません。

本番環境のContainer Orchestrator
Message Brokerの最終製品
Workflow Engineの最終製品
OIDC Provider
Raster / Vector Tile Serverの最終構成
Observability Backend
検索Engine
全Hazard Moduleの実装順
GeoParquet等の新しい形式を公開契約に使う時期
Multi-region構成と具体的なRPO / RTO

Port、Schema、Artifact形式を先に安定させ、実装製品は後から交換できるようにします。

38. 全体の完成条件

このプラットフォームが「ひと通り完成した」と言えるのは、次の条件を満たしたときです。

新しい情報源をConnector追加だけで取り込める
外部APIが止まっても他の機能が巻き込まれない
取得した値の提供元、原本、時刻、版を追跡できる
公式情報、観測、予測、推定、解析結果を区別できる
局地的豪雨、酷暑等の気象情報について、観測・予報・Alert・派生指標の時刻と履歴を追跡できる
地震の個別Occurrenceと複数版の発表、地震災害Eventを相互に追跡できる
噴火がない期間もVolcano、現在有効なAlert、観測履歴を管理できる
訂正、取消、旧版を追跡できる
Dataset、Model、Scenario、Engineを固定してRunを再現できる
数値SolverのVerificationと実績Validationを分けて説明できる
HazardResultから人、建物、交通、施設への影響を評価できる
未承認、権利未確認、機微情報を公開しない
Public WebとAPIが災害時の縮退運転に対応できる
新しいHazard ModuleをCoreの作り直しなしに追加できる
Web、API、Downloadのすべてで出典、時刻、品質を確認できる
波形・映像等のSignalAssetをCatalog Metadataから取得し、欠測・時間範囲・Checksumを確認できる
BackupからDBとArtifactを一体で復元できる
Docker image、Entrypoint、実行ユーザー、権限、必要なバイナリ、Versionを検証できる
AIがプラットフォームAPIを経由し、出典付きで説明できる

39. 最終像

このプラットフォームでは、最初の本格的な数値解析として洪水解析に取り組みます。ただし、洪水だけを対象にしたシステムにはしません。

開発の初期段階から、局地的な豪雨や猛暑・酷暑などの気象情報、地震情報、火山情報、各種観測データも取り込めるようにします。地震情報の訂正履歴や、火山の継続的な観測、地震波形のような大容量データについても、同じ仕組みで出典や更新履歴を確認できるようにします。

まずは、

気象・地震・火山などの情報を集める
        ↓
整理して保存する
        ↓
地図や時系列で確認する
        ↓
洪水解析を実行する
        ↓
解析結果を検証して公開する

という一連の流れを作ります。

その基盤ができれば、将来は地震動や液状化、火山の降灰、異常気象などの解析機能を追加しても、データ管理や公開の仕組みを最初から作り直す必要はありません。被害や交通への影響評価、外部向けAPI、AIによる情報検索や解析結果の説明なども、同じ基盤の上へ段階的に追加できます。

全体としては大きなプラットフォームを目指しますが、一度にすべてを作るわけではありません。

まず共通となるデータ管理、Catalog、Connector、解析実行、検証、公開の仕組みをしっかり作り、その上へ機能を一つずつ追加していきます。各Stepは途中段階でも実際に使える状態まで仕上げ、最後にそれらをつないで、一つの災害地理空間解析プラットフォームとして完成させます。

40. 参考にする公開標準・仕様

以下の標準・仕様は、実装時に適用範囲とVersionを確認したうえで採用します。

OGC API Standards: https://ogcapi.ogc.org/
OGC Standards: https://www.ogc.org/standards/
STAC Specification: https://stacspec.org/
Common Alerting Protocol: https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
CloudEvents: https://cloudevents.io/
OpenAPI Specification: https://spec.openapis.org/
AsyncAPI Specification: https://www.asyncapi.com/docs/reference/specification/latest
W3C DCAT: https://www.w3.org/TR/vocab-dcat-3/
W3C PROV-O: https://www.w3.org/TR/prov-o/
OGC Cloud Optimized GeoTIFF: https://www.ogc.org/standards/ogc-cloud-optimized-geotiff/
GeoParquet: https://geoparquet.org/
OpenTelemetry: https://opentelemetry.io/docs/
OWASP API Security: https://owasp.org/API-Security/
WCAG 2.2: https://www.w3.org/TR/WCAG22/

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

災害地理空間解析プラットフォーム 全体構想

災害地理空間解析プラットフォーム 全体構想

はじめに

1. この文書の位置づけ

2. 最終的な目標

3. このプラットフォームが必要な理由

4. 最初に決めておくこと

5. システムの基本方針

5.1 全体像は大きく描き、実装は少しずつ進める

5.2 取得した元データはそのまま残す

5.3 共通部分だけを揃え、災害ごとの違いは残す

5.4 災害Eventは情報をまとめるために使う

5.5 内部で使う情報と、一般公開する情報を分ける

5.6 解析結果と公式情報は、はっきり分けて表示する

5.7 外部との連携には共通仕様を使う

5.8 最初はシンプルなシステム構成で始める

6. 対象範囲

主な災害モジュール

気象・異常気象情報で扱う範囲

地震情報で扱う範囲

火山情報で扱う範囲

共通のImpact評価

このプラットフォームで行わないこと

7. 利用者ごとの画面と権限

Public Portal

Analysis Workspace

Administration

Operations Console

8. 全体フロー

9. システム全体の層構成

外部データ層

Connector層

取込・品質確認層

Data Catalog層

災害情報層

Model / Run層

Hazard / Impact層

Publication層

外部提供層

利用者向けの層

9.1 各層を横断する共通機能

Identity

Security

Audit

Observability

Backup

Schema Registry

Vocabulary

10. 機能領域（Domain）の分け方

Domain一覧

10.1 SourceとConnectorは分けて考える

10.2 Catalogはデータを探すためだけのものではない

10.3 Observationは「値」と「観測方法」の両方を持つ

10.4 Bulletin、Alert、Forecastは分ける

10.5 OccurrenceとEventも分ける

10.6 Hazard ReferenceはEventとは別に持つ

10.7 Model、Scenario、Runを混ぜない

10.8 HazardとImpactを分ける

10.9 Validationは解析Engineの外に置く

10.10 Publicationは「表示する処理」ではない

10.11 Domain同士はDatabaseを直接触らない

10.12 Portを置く理由

10.13 Domain間の基本的な流れ

10.14 この分け方で目指すこと

11. Connectorで外部情報を取り込む

11.1 Connectorを追加の単位にする

11.2 Connectorの共通契約

11.3 取得方式

11.4 同期時に必要な仕組み

11.5 Connectorの状態

11.6 Connectorの安全性

12. 情報源を管理するSource Registry

情報の性質を表す区分例

13. 共通データモデル

13.1 主なEntity

情報源と取得

データ管理

観測

発表・警報・予測

災害現象とEvent

災害地理空間解析プラットフォーム全体構想

災害地理空間解析プラットフォーム全体構想