PLATEAUで都市をつくり、NILIM2.0で水を動かし、Mesaで人を動かす ― Web防災シミュレーションを10ステップで作ってみる

PLATEAUで都市をつくり、NILIM2.0で水を動かし、Mesaで人を動かす ― Web防災シミュレーションを10ステップで作る

実都市モデル、NILIM2.0水理解析、時系列浸水、避難行動を統合する10ステップ開発計画

はじめに

近年の水害では、洪水浸水想定区域やハザードマップを見るだけでは、実際の避難行動まで十分に検討できない場面が増えています。

たとえば、同じ最大浸水深の地域でも、

• 何時ごろから道路が浸水し始めるのか
• どの道路が先に通れなくなるのか
• 避難開始が10分、20分遅れると結果がどう変わるのか
• 高齢者や子ども連れの世帯は時間内に避難できるのか
• 避難所までの経路が途中で浸水した場合、別の経路へ移れるのか
• 避難所の収容人数は足りるのか
• 水平避難が難しい地域で、垂直避難を選択できるのか

といったことを確認する必要があります。

従来の防災GISでは、ハザード情報、建物、道路、避難所などを重ねて表示することはできます。しかし、水が時間とともに広がることと、住民が時間とともに移動することを同じ時間軸で扱うには、別の仕組みが必要です。

そこで本プロジェクトでは、

• PLATEAUで実際の都市空間を表現し、
• NILIM2.0で河川・内水の水理現象を計算し、
• Mesaで住民や車両の避難行動を計算し、
• OpenLayersで2Dの入力・確認・分析を行い、
• CesiumJSで3D・時系列の結果を確認する、

という構成を考えます。

目標は、単に3Dで都市や浸水を表示することではありません。

「どこが浸水するか」から、「そのとき人は避難できるのか」までを同じシステムで確認できるようにすること

を目指します。

また、このシステムは特定のPCへ専用GISソフトを導入しなければ使えない構成にはしません。
プロジェクト作成、データ取得、入力編集、NILIM2.0の計算実行、Mesaの避難計算、進捗確認、結果比較、2D表示、3D表示まで、利用者の操作はWebブラウザ上で完結する構成にします。

重い計算までブラウザ内で実行するわけではありません。NILIM2.0やMesaなどの計算はサーバー側のWorkerで実行し、ブラウザはAPIを通して計算を開始し、進捗と結果を確認します。

この方式にすると、Windows、macOS、Linuxの違いを利用者が意識する必要がありません。
計算環境やデータをサーバー側で統一できるため、複数人で同じProjectやScenarioを共有しやすく、計算条件や結果の再現性も確保しやすくなります。

本資料では、この最終形をいきなり作るのではなく、10ステップに分けて段階的に構築します。

PLATEAUのマルチエージェント実証から参考にすること

国土交通省PLATEAUでは、2025年度に 「AIを活用したマルチエージェントシミュレーション技術等の開発業務（uc25-05）」 が実施されています。

この実証では、3D都市モデルを単なる背景表示として使うのではなく、

• シミュレーションのフィールド
• エージェント行動モデルへの入力
• 3D可視化
• 条件設定
• シナリオ比較
• 行動ログの分析

へ利用しています。

本プロジェクトでも、この考え方を参考にします。

ただし、目的はまちづくりの人流分析ではなく、水害時の避難行動をNILIM2.0の水理計算と結び付けることです。

PLATEAU公式実証
    3D都市モデル
        +
    マルチエージェント
        +
    条件設定・分析UI

本プロジェクト
    PLATEAU
        +
    NILIM2.0
        +
    Mesa / NetworkX
        +
    Web UI

特に参考にするのは、利用者が複雑な設定ファイルを直接編集するのではなく、Web UIから条件を設定し、複数シナリオを実行・比較できる構成です。

一方、PLATEAUの実証ではLLMを個々のエージェントやパラメータ設定支援へ利用していますが、本プロジェクトでは最初からLLMへ避難判断を任せません。

まずは、

根拠が明確なルール
    ↓
再現可能なMesaモデル
    ↓
実績・文献による検証

を優先します。

そのうえで将来、

ルールベースAgent
        +
一部の判断支援
        ↓
LLM拡張

を検討します。

この順番にすることで、LLMを追加した場合でも「どこまでが水理計算の影響で、どこからが行動モデルの影響か」を確認しやすくします。

---

1. このプロジェクトで作るもの

PLATEAUの3D都市モデルを都市空間の基礎データとして利用し、NILIM2.0で水理現象を、Mesaで住民の避難行動を計算する防災シミュレーションシステムを構築します。

最終的には、次の情報を一つのWebシステムで扱えるようにします。

• PLATEAUの建物、道路、都市情報
• DEM
• 河川、下水道、水路
• 避難所
• 人口統計から生成した合成人口
• 現在機能拡張・修正中のNILIM2.0による1D河道＋2D氾濫解析
• 水理シミュレーションによる時系列浸水深・流速
• Mesaによる住民・車両の避難行動
• NetworkXによる避難経路探索
• OpenLayersによる2D確認・分析
• CesiumJSによる3D・時系列可視化
• シミュレーション結果の比較、集計、再現

PLATEAUを「3Dで建物を表示するためのデータ」として使うだけではなく、実際の都市そのものをシミュレーション空間として利用します。

最終的な流れは次のようになります。

このプロジェクトでは、10ステップに分けて機能を積み上げます。

各ステップは前のステップの成果をそのまま引き継ぎ、ステップごとに実行確認を行います。
最後にまとめて確認するのではなく、各段階で「ここまでは正しく動く」という状態を作ります。

---

2. 基本方針

2.1 Webブラウザで一連の作業を完結させます

本システムは Webファースト で設計します。

利用者が通常の運用で必要とする操作は、原則としてWebブラウザから行えるようにします。

Web Browser
   │
   ├ Project作成
   ├ PLATEAU・DEM等のデータ登録
   ├ Input Studio
   ├ Mesh Mapper
   ├ 河道・横断面・施設編集
   ├ Scenario設定
   ├ NILIM2.0計算開始
   ├ 計算進捗確認
   ├ Mesa避難計算
   ├ 2D結果確認
   ├ 3D結果確認
   ├ Scenario比較
   └ 結果ダウンロード

QGISなどのデスクトップGISは、データ検査や開発時の比較確認には利用できますが、本番運用の必須ソフトにはしません。

Webで完結させる理由

主な理由は次のとおりです。

1. 利用者ごとの環境差を小さくできます。
   Windows、macOS、Linuxで個別に解析環境を構築する必要がなくなります。

2. NILIM2.0の実行環境を統一できます。
   Fortranコンパイラ、入力形式、Exporter、ライブラリの違いをサーバー側で固定できます。

3. 同じProjectを複数人で共有できます。
   入力データ、Scenario、Run、結果を同じデータベースで管理できます。

4. 計算履歴を残しやすくなります。
   誰が、どの入力データを使い、どの条件で計算したかをRun Manifestとして保存できます。

5. 重い計算を利用者PCから切り離せます。
   NILIM2.0や大量AgentのMesa計算はサーバー側Workerで実行できます。

6. 将来クラウドへ移行しやすくなります。
   ローカルDocker Composeから始め、必要になればAWS等へ段階的に移行できます。

ブラウザとサーバーの役割

ブラウザですべての数値計算を行うわけではありません。

この構成により、利用者から見るとWebだけで完結し、計算処理はサーバー側で安全に実行される形にします。

---

2.2 PLATEAUをそのままMesaへ入れない

PLATEAUの原典であるCityGMLは情報量が多く、都市モデルの保存形式として優れています。

一方、MesaやNetworkXで毎ステップCityGMLを解析する構成は適しません。

そこで、データの役割を分ける。

CityGML
    原典・入力

GeoParquet
    建物・道路などのGIS解析

PostgreSQL / PostGIS
    空間検索・属性管理・シミュレーション管理

NetworkX Graph
    避難経路探索

3D Tiles
    CesiumJSでの3D表示

COG
    浸水深などのラスタデータ

Parquet
    時系列計算結果

同じ都市を用途別の形式で持つことになるが、building_id、road_id、shelter_id などの管理IDは共通にします。

---

2.3 計算と表示を分ける

3D表示用のCesiumJSをシミュレーションの計算エンジンにはしません。

同様に、OpenLayersも計算処理から分離します。

Calculation
    Mesa
    NetworkX
    Hydraulic Solver
    Python / GeoPandas / DuckDB

Storage
    PostgreSQL / PostGIS
    GeoParquet / Parquet
    COG
    S3互換Object Storage

Visualization
    OpenLayers
    CesiumJS

この分離をしておけば、将来UIを変更してもシミュレーション本体には影響しにくい。

---

2.4 NILIM2.0を標準水理エンジンとして扱う

このプロジェクトでは、水理計算部分を抽象的な Hydraulic Solver のままにせず、現在機能拡張・修正を進めている NILIM2.0 を標準水理エンジンとして組み込む。

ただし、Mesa側をNILIM2.0固有形式へ直接依存させない。

NILIM2.0
    ↓
NILIM2.0 Result Adapter
    ↓
FloodResult
    ↓
RoadState / BuildingState
    ↓
Mesa

この境界を設けることで、NILIM2.0を主系として使いながら、テスト用人工浸水や既存GeoTIFF/COG、他ソルバーの結果も同じMesaモデルへ入力できる。

NILIM2.0側では、現在進めている次の機能をこのシステムへ接続します。

• Input Studioによる入力データ作成
• Web Mesh Mapperによる2D計算メッシュ作成
• 1D河道網（River / Node / Reach）
• 横断面CSV読込とDEMからの断面標高抽出
• 河道内施設（堰、樋門、水門、ポンプ、オリフィス、BOX等）
• 1D/2D間の接続を一般化したDomainConnection
• 越流、破堤、水路、吐口等を含む領域間接続
• Subcatchment / Reach対応による1D河道への横流入
• 計算前Validator
• Fortran入力Exporter
• 1D＋2D計算
• 水収支確認

NILIM2.0をこの避難シミュレーションへ接続するうえでは、入力データを作る部分、計算する部分、避難モデルへ渡す部分を分離する。

現在のメッシュ仕様

現在のNILIM2.0側では、2D計算領域を

500 × 500 = 250,000 計算セル

とし、配列境界を含む内部配列は

502 × 502

として扱う方針で進めています。

この違いを避難側で曖昧にしません。

計算セルID
    500 × 500

NILIM内部配列
    502 × 502

Mesa / FloodResult
    計算セルIDのみ参照

つまりMesaはFortran内部配列番号へ直接依存せず、NILIM2.0 Result Adapterが cell_id、座標、時刻へ変換して渡す。

1D河道への降雨流出

NILIM2.0では、流域に降った雨を1D河道へ与える際、

Subcatchment
    ↓
対応Reach
    ↓
横流入量
    ↓
1D河道

として扱います。

1D河道の各区間では、

上流からの流量
    +
その区間へ流入する雨量流出

を考慮します。

そのため本システムでも、Subcatchment / Reach / lateral inflow の対応関係をNILIM2.0入力データの正式な一部として保持し、Run Manifestから追跡できるようにします。

1D/2D接続

NILIM2.0で進めているDomainConnectionは、単純な河道と氾濫原の接続だけでなく、

• 越流
• 破堤
• 水路
• 吐口
• 将来のマンホール・下水道接続

などへ一般化できる構造として扱います。

Mesa側はこの詳細を直接解釈しません。

NILIM2.0で計算された結果から、

2D浸水深
2D流速
1D水位
1D流量
1D/2D交換流量

を取得し、防災避難に必要な量だけを共通 FloodResult へ変換します。

---

2.5 PLATEAUの年度を固定する

PLATEAU配信サービスでは、3D TilesやMVTをWebアプリから利用できます。

CesiumJSでの表示は、PLATEAU配信サービスの composite_url を使うと始めやすくなります。

一方、シミュレーションでは再現性を確保する必要があります。

たとえば2026年に計算した結果を2028年に再計算するときに、PLATEAU側の都市モデルが更新されていれば、同じ条件になりません。

そのため、各Runで次を保存します。

plateau_city_code
plateau_dataset_year
plateau_spec_version
plateau_source
plateau_dataset_hash

Web表示では最新データへ追随できるようにしても、解析用データは使用年度を固定します。

---

3. 座標系と高さ

PLATEAUを防災解析へ使う場合、最初に座標系を整理します。

PLATEAUの3D都市モデルでは、基本的にEPSG:6697が利用されます。

EPSG:6697
JGD2011 経緯度
+
東京湾平均海面を基準とする標高

一方、距離、道路長、歩行距離、計算メッシュを扱う場合は、対象地域に対応したJGD2011平面直角座標系へ変換します。

PLATEAU
EPSG:6697
     ↓
pyproj / PROJ
     ↓
対象地域の平面直角座標系
     ↓
GIS解析 / NetworkX / Mesa / 水理計算

プロジェクトごとにCRSを明示します。

project:
  crs_source: EPSG:6697
  crs_analysis: EPSG:XXXX
  timezone: Asia/Tokyo

EPSG:XXXX は対象地域に応じて決めます。

高さについても、

• PLATEAU
• DEM
• 水理モデル
• Cesium

で基準が一致しているか確認します。

特に浸水深は数十cmの差が意味を持つため、水平座標だけ合わせて終わりにしません。

---

4. 全体システム構成

最終的なシステムは、ブラウザを唯一の通常操作画面とし、入力、計算、確認、比較までをWebから実行できる構成にします。

利用者はWebブラウザへアクセスし、Projectを選択して作業します。
NILIM2.0やMesaの計算はサーバー側で実行されるため、利用者PCへFortran、Python、GISライブラリなどを個別に導入する必要はありません。

4.1 Web画面で行う作業

通常の利用者は、次の作業をすべてWeb画面から行います。

機能	Web画面
Project作成	Project Manager
公開データの登録	Data Catalog
PLATEAU確認	OpenLayers / CesiumJS
DEM確認	OpenLayers
2Dメッシュ作成	Mesh Mapper
1D河道編集	Input Studio
横断面・施設編集	Input Studio
DomainConnection編集	Input Studio
Scenario設定	Scenario Editor
NILIM2.0計算	Run Manager
Mesa避難計算	Run Manager
進捗確認	Run Monitor
2D結果確認	OpenLayers
3D結果確認	CesiumJS
Run比較	Dashboard
結果出力	Export

4.2 Web画面からNILIM2.0を実行します

NILIM2.0の入力ファイルを利用者が手作業で配置する運用にはしません。

Web Input Studio
      ↓
Project JSON
      ↓
Validator
      ↓
Exporter
      ↓
NILIM2.0
      ↓
Result Adapter
      ↓
Web Result

これにより、入力作成から計算結果確認までをブラウザから一続きで操作できます。

NILIM2.0がFortranプログラムであることをWeb利用者が意識する必要はありません。

4.3 OpenLayersとCesiumJSを一つのWebアプリに統合します

OpenLayersとCesiumJSを別製品として運用するのではなく、同じProject、Scenario、Runを参照する画面として統合します。

同じ run_id
   │
   ├ OpenLayers
   │    2D解析・入力確認
   │
   └ CesiumJS
        3D・時系列確認

2Dと3Dで別々にデータを管理しないことが重要です。

4.4 Web完結の対象範囲

「Webで完結する」とは、少なくとも通常運用で次の一連の作業をブラウザから実施できることを意味します。

1. Projectを作成します。
2. PLATEAU、DEM、降雨、避難所などのデータを登録します。
3. Input Studio / Mesh MapperでNILIM2.0の入力を編集します。
4. Validatorを実行し、入力エラーをWeb画面で確認します。
5. NILIM2.0の計算を開始します。
6. 計算ログと進捗を確認します。
7. NILIM2.0の結果からFloodResultを生成します。
8. Mesaの避難シミュレーションを開始します。
9. OpenLayersで2D結果を確認します。
10. CesiumJSで3D・時系列結果を確認します。
11. 複数Runを比較します。
12. CSV、Parquet、GeoParquet、画像等を必要に応じて出力します。

サーバーへSSH接続して設定ファイルを書き換えたり、計算ファイルを手作業で所定フォルダへ移したりしなければ通常計算ができない状態は、完成形とはしません。

開発者向けのCLIは、テスト、自動化、障害調査のために残します。ただし、通常利用者の操作経路はWebを正とします。

---

4.5 デスクトップGISは補助ツールとします

QGISなどは開発・検証では有用です。

ただし、本システムの通常運用では必須にしません。

たとえば、Step 2のPLATEAU変換結果はOpenLayers上で確認できるようにし、QGISによる確認は追加検証として扱います。

これにより、自治体や社内の利用者が専用GIS環境を用意しなくても、URLへアクセスするだけで同じシステムを利用できます。

5. Docker Composeの構成

開発・検証・配布で同じ構成を再現できるよう、サーバー側はDocker Composeを基本とします。利用者はDockerを直接操作せず、Webブラウザからシステムを利用します。

最終的には次のサービスを想定します。

web
    Vite + TypeScript
    Project Manager
    Input Studio
    Mesh Mapper
    OpenLayers
    CesiumJS
    Run Manager
    Dashboard

api
    FastAPI

worker
    Celery
    Mesa
    NetworkX

redis
    Celery broker
    progress / transient state

postgres
    PostgreSQL + PostGIS

object-storage
    S3互換Object Storage

etl
    PLATEAU / GIS前処理用

test
    ruff / mypy / pytest / integration test

水理ソルバーは NILIM2.0を標準構成 とします。

nilim-input
    Input Studio / Mesh Mapperで作成したProject

nilim-validator
    計算前検査

nilim-exporter
    Fortran入力生成

nilim-solver
    NILIM2.0 1D + 2D Solver

nilim-adapter
    NILIM2.0結果 → FloodResult

NILIM2.0本体を同じComposeへ組み込める段階では nilim-solver として実行し、開発途中や既存計算結果を利用する場合は nilim-adapter から結果だけを取り込めるようにします。

避難モデルとの境界は次の共通形式に固定します。

NILIM2.0 Solver
      ↓
NILIM2.0 Result Adapter
      ↓
FloodResult
      ↓
Mesa

この構造なら、NILIM2.0の機能拡張を続けてもMesa側への影響を抑えられる。テスト時には SyntheticFloodProvider、公開ハザードの確認には StaticHazardProvider を利用できるようにし、実計算時は Nilim20FloodProvider を選択します。

---

6. データモデル

最低限、次のエンティティを定義します。

Building

building_id
source_id
geometry
centroid
usage
height_m
storeys
population_est
vertical_evacuation

RoadNode

node_id
x
y
node_type

RoadEdge

edge_id
from_node
to_node
geometry
length_m
width_m
road_type
walkable
drivable
capacity

Shelter

shelter_id
name
geometry
capacity
shelter_type
available_from

Agent

agent_id
household_id
origin_building_id
agent_type
weight
walking_speed
vehicle
evacuation_start_time
destination_shelter_id

FloodState

timestamp
cell_id
x
y
depth_m
velocity_mps
velocity_x_mps
velocity_y_mps
water_level_m
source

NILIM2.0からは必要に応じて、別テーブルで1D河道結果も保持します。

ReachState
    timestamp
    reach_id
    water_level_m
    discharge_m3s
    lateral_inflow_m3s

さらに1D/2D接続の検証用として、

DomainConnectionState
    timestamp
    connection_id
    exchange_discharge_m3s

を保存できるようにします。

RoadState

timestamp
edge_id
depth_m
velocity_mps
congestion
status
cost

SimulationRun

run_id
scenario_id
seed
started_at
finished_at
plateau_dataset_year
hydraulic_result_id
code_version
config_hash
status

AgentTrack

run_id
agent_id
timestamp
x
y
state
edge_id
destination_shelter_id

---

7. Agentの状態

住民エージェントの状態は明示的に管理します。

最初から複雑な心理モデルは入れない。

初期版では、

• 避難開始時刻
• 移動速度
• 避難先
• 道路通行可否
• 避難所収容数
• 混雑

を中心にします。

モデルの挙動が確認できた後に、

• 高齢者
• 子ども連れ
• 要支援者
• 自動車
• 家族単位行動
• 垂直避難
• 避難開始判断

を追加します。

---

8. 道路コスト

経路探索では、単純な最短距離だけでなく、時刻によって変わる道路コストを使う。

基本形は次のようにします。

$$
C_e(t) = T_e(t)
+
P_{flood,e}(t)
+
P_{congestion,e}(t)
+
P_{risk,e}
$$

ここで、

• (T_e(t))：移動所要時間
• (P_{flood,e}(t))：浸水によるペナルティ
• (P_{congestion,e}(t))：混雑によるペナルティ
• (P_{risk,e})：道路固有のリスク

とします。

道路が通行不能になれば、

status = CLOSED

として候補経路から外す。

通行止めの閾値はコードへ直接書かず、シナリオ設定として外出しします。

road_rules:
  pedestrian:
    depth_caution_m: ...
    depth_closed_m: ...
  vehicle:
    depth_caution_m: ...
    depth_closed_m: ...

閾値は利用目的、根拠資料、自治体の運用条件などに合わせて設定し、設定値と出典をRun Manifestへ残します。

---

9. 10ステップの開発計画

---

Step 1 — 実行基盤と共通データ契約

目的

プロジェクト全体の骨格を作る。

この段階ではPLATEAUの高度な処理や浸水計算は行わない。

実装

• Docker Compose
• FastAPI
• PostgreSQL / PostGIS
• Redis
• Celery
• Vite + TypeScript
• OpenLayers
• Mesa
• NetworkX
• pytest
• Ruff
• mypy
• Playwright
• Project / Scenario設定形式
• Run Manifest
• ログ
• テスト用の小規模仮想道路網

ディレクトリ案

mesa_plateau_disaster/
├── compose.yaml
├── .env.example
├── README.md
├── pyproject.toml
├── apps/
│   ├── api/
│   ├── worker/
│   ├── simulator/
│   ├── etl/
│   └── web/
├── packages/
│   ├── domain/
│   ├── geo/
│   ├── routing/
│   └── schemas/
├── data/
│   ├── raw/
│   ├── normalized/
│   ├── derived/
│   └── results/
├── config/
│   ├── project.yaml
│   └── scenarios/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
└── scripts/

完了条件

• docker compose up で主要サービスが起動します
• 利用者はブラウザからProjectとRunを作成できます
• 仮想道路上を1体のAgentが移動できる
• APIからRunを開始できる
• Run IDが発行される
• 結果がDBへ保存される
• Ruff / mypy / pytestが実行できる

リリース

r001

---

Step 2 — PLATEAU取込・正規化

目的

実際のPLATEAUデータをシミュレーションで使える形へ変換します。

入力

• PLATEAU CityGML
• データセット情報
• 対象地域のCRS設定

処理

CityGML
   ↓
Validator
   ↓
地物抽出
   ├ Building
   ├ Road
   └ 必要な都市属性
   ↓
座標変換
   ↓
GeoParquet / PostGIS

元データを消さず、

raw
normalized
derived

の3段階で管理します。

重要事項

• 元のPLATEAU IDを保持する
• 変換後に独自IDを勝手に振り直さない
• CRSをManifestへ残す
• PLATEAU年度を残す
• 入力ファイルのSHA-256を保存する

完了条件

• 実際のPLATEAUデータを読める
• 建物件数を検査できる
• 道路件数を検査できる
• Bounding Boxを検査できる
• 座標変換前後をWebのOpenLayers上で照合できます
• QGISは追加の検証に使えますが、通常運用では必須にしません
• GeoParquetとPostGISの件数が一致する

リリース

r002

---

Step 3 — 道路ネットワークとTopology構築

目的

PLATEAU道路から、Mesaが移動可能なNetworkX Graphを作る。

PLATEAUの道路LOD0は原則として道路中心線ネットワークを採用できるため、これを基礎とします。

処理

PLATEAU Road
      ↓
線形状抽出
      ↓
交差点検出
      ↓
線分分割
      ↓
微小ギャップ補正
      ↓
Node / Edge生成
      ↓
NetworkX Graph

必要な検査

• dangling edge
• disconnected component
• self loop
• duplicated edge
• 交差しているのに接続されていない線
• 微小線分
• 異常な道路長
• 建物から到達不能な道路群

Graph出力

road_nodes.parquet
road_edges.parquet
road_graph.pkl
graph_manifest.json

pickle は内部キャッシュ用途に限定し、正式な再生成元はParquetとします。

完了条件

• 任意の2地点間で経路探索できる
• グラフ連結率を集計できる
• 既知のテスト経路で距離が一致する
• OpenLayers上でNode/Edgeを確認できる

リリース

r003

---

Step 4 — 建物・人口・避難所を実都市へ接続

目的

建物を「人の出発地点」、避難所を「目的地」として道路ネットワークへ接続します。

建物接続

PLATEAU Building
       ↓
代表点
       ↓
接続可能道路を探索
       ↓
Building Connector
       ↓
Road Graph

単純な最近傍だけでは、河川や壁を越えて接続する場合があります。

そのため、

• 最大接続距離
• 道路種別
• 障害物
• 接道状況

を考慮します。

人口

個人情報は使わず、統計データからSynthetic Populationを作る。

人口メッシュ
     ↓
住宅建物へ配分
     ↓
世帯生成
     ↓
Agent生成

Agentには weight を持たせる。

これにより、

1 Agent = 1人

だけでなく、

1 Agent = 5人相当

といった集約計算も可能にします。

避難所

• 指定避難所
• 指定緊急避難場所
• 一時避難場所

などを区別できる構造にします。

完了条件

• Agentの出発建物が決まる
• 建物から道路へ接続できる
• 避難所から道路へ接続できる
• 到達不能建物を一覧化できる
• 人口総数とAgent重み総数が一致する

リリース

r004

---

Step 5 — Mesaによる静的避難シミュレーション

目的

浸水がない状態で、実都市上の避難モデルを完成させる。

この段階では道路状態を時間変化させない。

Agentの基本動作

AT_HOME
   ↓
避難開始時刻
   ↓
経路探索
   ↓
EVACUATING
   ↓
避難所到着
   ↓
SHELTERED

実装

• 歩行速度
• 避難開始時間
• 避難先選択
• NetworkX経路探索
• 避難所容量
• 到達不能判定
• 時系列位置保存
• Random Seed固定

重要な確認

浸水モデルを入れる前に、

水がなければ期待した避難行動になる

ことを確定させる。

ここを曖昧にしたまま浸水条件を追加すると、経路探索の問題なのか、水理連携の問題なのか切り分けにくくなります。

行動ログと説明可能性

PLATEAU uc25-05 では、エージェントの行動ログを分析し、「なぜその行動になったのか」を利用者が理解しやすくすることが重視されています。

本プロジェクトでも、LLMを使うかどうかに関係なく、Agentの判断を後から追跡できるログを残します。

agent_id
timestamp
state
current_edge
destination
decision
reason_code
trigger

例：

decision   = REPLAN
reason_code = ROAD_FLOODED
trigger     = edge_001 depth >= threshold

あるいは、

decision    = CHANGE_SHELTER
reason_code = SHELTER_FULL

のように、ルールベースの段階から理由を明示します。

これにより、結果だけではなく、

なぜこのAgentはこの経路を選んだのか

をWeb画面から追跡できるようにします。

将来LLMを導入する場合も、この構造を残し、LLM出力だけを理由として保存するのではなく、入力条件・参照情報・モデルバージョンも併せて記録します。

指標

• 避難完了率
• 平均避難時間
• 中央値
• 95パーセンタイル
• 避難所別人数
• 到達不能Agent数
• 道路別通過人数

完了条件

• 実PLATEAU地域上で複数Agentが移動する
• 同じseedなら同じ結果になる
• AgentTrackをParquetへ保存できる
• 避難所容量を超えない
• Run比較ができる

リリース

r005

---

Step 6 — OpenLayers Web UIとシナリオ実行管理

目的

ここまで作成した機能をWeb UIへ統合し、Project作成、Scenario設定、Run実行、進捗確認、結果確認をブラウザから行えるようにします。

OpenLayersは、Web上での編集・検査・デバッグ・2D分析の中心に置きます。

画面

機能

• Project選択
• Scenario作成
• 分析目的の入力
• シナリオ条件の確認・編集
• Layer表示切替
• 建物クリック
• 道路属性確認
• 避難所確認
• Run開始
• 進捗表示
• Agent再生
• Run比較
• 指標のDashboard表示
• Agent行動ログ確認
• 結果CSV/Parquet出力

PLATEAU uc25-05 の実証では、パラメータ設定、シミュレーション実行、分析を分け、利用者がシナリオを設定して結果を比較できる構成が採られています。

本システムでも、単に「Runボタンを押す画面」ではなく、

分析目的
    ↓
Scenario設定
    ↓
Run
    ↓
結果
    ↓
比較

までを一つのWebフローとして設計します。

API

POST /projects
POST /scenarios
POST /runs
GET  /runs/{id}
GET  /runs/{id}/metrics
GET  /runs/{id}/agents
GET  /runs/{id}/roads

長時間計算はFastAPIプロセスで直接実行せず、Celery Workerへ渡す。

完了条件

• ブラウザからProject作成、入力確認、シナリオ設定、Run実行まで行えます
• 進捗が見える
• Agent移動を再生できる
• エラー時にRunがFAILEDになる
• Playwrightで基本操作を自動テストできる

リリース

r006

---

Step 7 — NILIM2.0水理解析との正式連携

目的

現在機能拡張・修正しているNILIM2.0を、このシステムの標準水理エンジンとして接続します。入力作成から計算開始、進捗確認、結果取得までをWebから操作できるようにします。

このStepから、

PLATEAU + Mesa

の避難シミュレーションを、

PLATEAU + NILIM2.0 + Mesa

の水害避難シミュレーションへ進める。

NILIM2.0入力側

NILIM2.0のInput Studio / Mesh Mapperで、次を準備します。

DEM
 ↓
2Dメッシュ
 ↓
1D河道網
 ↓
河道内施設
 ↓
横断面
 ↓
Subcatchment / Reach
 ↓
DomainConnection
 ↓
Project JSON

現在の入力作成フローは次を基本とします。

1. DEM
2. 2D計算メッシュ
3. 1D河道網
4. 河道内施設
5. 横断面
6. Subcatchment / Reach対応
7. 1D/2D接続
8. 計算前検査
9. Exporter
10. NILIM2.0 Solver

2D計算領域

現在の標準ケースでは、

計算領域
500 × 500セル

内部配列
502 × 502

を前提とします。

Mesaへ渡すときは内部配列インデックスではなく、次の共通形式へ変換します。

cell_id
x
y
timestamp
depth_m
velocity_x_mps
velocity_y_mps
velocity_mps
water_level_m

1D河道

1D側では、

River
  └ Reach
      └ Node

の管理IDを維持します。

各Reachには、Subcatchmentからの横流入を対応させる。

上流流量
   +
lateral_inflow
   ↓
Reach

NILIM2.0から取得する主な1D結果は、

water_level_m
discharge_m3s
lateral_inflow_m3s

とします。

1D/2D接続

DomainConnectionを用いて、

• 河川越流
• 破堤
• 水路
• 吐口
• その他の領域間接続

を扱います。

将来、下水道やマンホールを接続する場合も、Mesa側のインターフェースを変えずにNILIM2.0側で拡張できる構造を維持します。

NILIM2.0 Result Adapter

NILIM2.0の生出力を直接Mesaから読まない。

Adapterでは、

• NILIM2.0セル番号 → 共通cell_id
• 配列位置 → 平面座標
• 水深・水位・流速の単位統一
• 時刻のJST/elapsed seconds対応
• NaN / NoData処理
• 500×500と502×502の境界整理

を行います。

道路への浸水投影

NILIM2.0 2D結果
      ↓
FloodResult
      ↓
RoadEdgeと空間結合
      ↓
RoadState(t)

道路水深は設定により、

• Edge上の最大値
• Edge上の平均値
• 一定間隔サンプリングの最大値

を選択できるようにします。

避難判定では、単一の最近傍セルだけに依存しません。

建物への浸水投影

PLATEAU Buildingについても、

FloodResult
      ↓
Building footprint
      ↓
建物単位浸水深

を計算します。

これにより、

• 住宅の浸水
• 避難所の浸水
• 垂直避難候補
• 建物別最大浸水深

へ利用できます。

水理計算とMesaの時間同期

NILIM2.0の出力間隔とMesa timestepは分離します。

例：

NILIM2.0 output : 60秒
Mesa timestep   : 5秒

初期版では previous value hold を基本とし、必要になった段階で線形補間を追加します。

補間方法はRun Manifestへ保存します。

水収支を品質ゲートにする

NILIM2.0側で計算が終了しただけではMesaへ渡さない。

最低限、

入力流量
降雨流入
横流入
1D/2D交換
領域外流出
貯留量変化

を用いた水収支を確認します。

許容誤差はテストケースごとに明示し、未確認のRunをPASS扱いにしません。

小規模ケース

最初から実流域の大規模ケースだけで確認しません。

次の小規模ケースを保持します。

1D Reach
   ↓
越流
   ↓
小規模2D領域

さらに、

降雨
 ↓
Subcatchment
 ↓
lateral inflow
 ↓
1D Reach

のケースを用意し、

• 横流入量
• 河道流量
• 1D/2D交換
• 2D浸水
• 水収支

を手計算または参照値と比較します。

FloodProvider

システムとしてはProvider方式を維持します。

FloodProvider
 ├ SyntheticFloodProvider
 ├ StaticHazardProvider
 ├ RasterTimeSeriesProvider
 └ Nilim20FloodProvider

正式な実水害Runでは Nilim20FloodProvider を使う。

Synthetic / Static Providerは、

• CI
• UIテスト
• Mesa単体検証
• NILIM2.0未実行時の開発

に利用します。

Step 7の品質確認

NILIM2.0連携では、少なくとも次を確認します。

Input Studio Validator
Exporter
NILIM2.0 input read
NILIM2.0 calculation
500×500 / 502×502 mapping
1D lateral inflow
DomainConnection exchange
2D depth / velocity
timestamp continuity
NoData / NaN
water balance
FloodResult conversion
RoadState conversion
BuildingState conversion

Run Manifestへ追加する情報

{
  "nilim_version": "...",
  "nilim_input_format_version": "...",
  "input_studio_version": "...",
  "mesh_mapper_version": "...",
  "project_json_hash": "...",
  "exporter_version": "...",
  "mesh_nx": 500,
  "mesh_ny": 500,
  "solver_array_nx": 502,
  "solver_array_ny": 502,
  "rainfall_hash": "...",
  "cross_section_hash": "...",
  "domain_connection_hash": "...",
  "flood_provider": "Nilim20FloodProvider",
  "flood_time_interpolation": "previous"
}

完了条件

• Input Studio / Mesh Mapperで作成したProjectをNILIM2.0へ渡せる
• ValidatorからExporterまで通る
• NILIM2.0が実際に計算を完了する
• 1D横流入がReachへ反映される
• 1D/2D DomainConnectionが結果へ反映される
• 500×500計算セルをFloodResultへ正しく変換できる
• 2D浸水深・流速を道路へ投影できる
• PLATEAU建物へ最大浸水深を付与できる
• 水収支を確認できる
• MesaがNILIM2.0結果を使ってRunできる

リリース

r007

Step 8 — 動的避難・再経路探索・混雑・車両

目的

水害時の避難行動として必要な動的処理を入れます。

Step 8では、Step 7で生成した NILIM2.0由来のRoadState / BuildingState をMesaの各時刻へ反映する。NILIM2.0は水の挙動、Mesaは人の挙動を担当し、両者の責務を分離します。

時刻ごとの処理

再探索の条件

• 道路が浸水で閉鎖
• 混雑が一定以上
• 避難所が満員
• 避難先が利用不能
• 現在ルートが切断

歩行者

歩行者はAgent属性によって速度を変えられるようにします。

ただし、最初から細かな属性を増やしすぎない。

代表的な属性を少数設定し、実測・文献との比較が可能な構造にします。

車両

車両避難は歩行者と同じEdgeを使えても、ルールは別にします。

RoadEdge
 ├ walkable
 └ drivable

混雑モデルも歩行者とは分離します。

垂直避難

水平避難が困難になった場合に備え、

vertical_evacuation = true

の建物を候補として扱える構造を用意します。

初期実装では自動判断を単純化し、シナリオでON/OFFできるようにします。

完了条件

• 浸水道路を避けて再探索する
• 避難所満員時に代替先へ変更できる
• 混雑で所要時間が増える
• 徒歩と車両を別条件で動かせる
• STRANDEDを正しく判定できる

リリース

r008

---

Step 9 — CesiumJSによる3D・時系列表示

目的

PLATEAU建物、浸水、AgentをWebブラウザ上のCesiumJSで同じ時間軸に表示します。

OpenLayersを置き換えるのではなく、用途を分ける。

OpenLayers

• データ検査
• 道路ネットワーク
• 2D経路
• 入力編集
• 詳細な属性確認
• デバッグ

CesiumJS

• PLATEAU建物
• 地形
• 浸水面
• Agent
• 垂直避難
• 時系列再生
• プレゼンテーション

PLATEAU

初期版ではPLATEAU配信サービスの3D Tilesを利用します。

Web表示には composite_url を利用しやすい。

解析で使用したPLATEAU年度と、表示中の年度が異なる場合はUIで警告します。

Agent表示

MesaのAgentTrackから、

agent_id
timestamp
longitude
latitude
height
state

を生成します。

必要に応じてCZMLへ変換します。

浸水表示

水理結果は用途に応じて、

• COG → タイル配信
• 時刻別ポリゴン
• 3D Tiles
• CZML

などへ変換します。

完了条件

• PLATEAU建物を3D表示できる
• Agentを時系列再生できる
• 浸水時系列とAgentの時間が一致する
• OpenLayersとCesiumで同じRunを参照できる

リリース

r009

---

Step 10 — 検証、キャリブレーション、比較、運用パッケージ

目的

「動くデモ」から「Web上で入力・計算・検証・比較まで行えるシミュレーションシステム」へ仕上げます。

シナリオ比較

例として、

Scenario A
全員が警戒レベル相当の早い時刻に避難開始

Scenario B
避難開始が30分遅れる

Scenario C
主要道路1本が使用不能

Scenario D
徒歩中心

Scenario E
車両避難率が高い

を比較できるようにします。

指標

• 避難完了率
• 避難完了時刻
• 平均避難時間
• p50 / p95
• STRANDED人数
• 浸水前に避難できた人数
• 避難所利用率
• 道路最大混雑度
• 道路閉鎖時刻
• ボトルネック箇所
• 垂直避難人数

キャリブレーション

可能であれば、

• 実避難訓練
• 人流観測
• GPS軌跡
• 道路交通量
• 過去の災害時行動

などと比較します。

シミュレーション結果だけを見て「正しい」と判断しません。

性能試験

PLATEAU uc25-05 では、システムの実運用性を確認するため、パラメータ設定時間とシミュレーション動作時間を実測しています。

本プロジェクトでも、計算速度だけでなく Web操作から結果確認までの時間 を測定します。

測定対象は次のとおりです。

Project読込時間
PLATEAU表示時間
Scenario保存時間
NILIM2.0開始待ち時間
NILIM2.0計算時間
Result Adapter変換時間
Mesa計算時間
OpenLayers結果表示時間
CesiumJS結果表示時間
Run比較表示時間

Agent数を段階的に増やします。

1,000
10,000
50,000

などのベンチマークを実行し、

• 実行時間
• CPU
• メモリ
• DBサイズ
• 出力ファイルサイズ

を記録します。

事前に「5万Agentでも問題ない」と推測で決めず、実測値を残します。

Run Manifest

最終的に全Runへ次の情報を残します。

{
  "run_id": "...",
  "scenario_id": "...",
  "code_version": "...",
  "git_commit": "...",
  "random_seed": 12345,
  "plateau_dataset_year": "...",
  "plateau_spec_version": "...",
  "plateau_source_hash": "...",
  "population_source": "...",
  "hydraulic_result_id": "...",
  "hydraulic_result_hash": "...",
  "analysis_crs": "EPSG:XXXX",
  "started_at": "...",
  "finished_at": "..."
}

最終E2E

Web Project作成
   ↓
PLATEAU / DEM等のデータ登録
   ↓
ETL
   ↓
道路Graph
   ↓
合成人口
   ↓
避難所
   ↓
Input Studio / Mesh Mapper
   ↓
NILIM2.0 Validator / Exporter
   ↓
NILIM2.0 1D + 2D計算
   ↓
NILIM2.0 Result Adapter
   ↓
Mesa
   ↓
結果保存
   ↓
OpenLayers
   ↓
Cesium
   ↓
Web Dashboard
   ↓
シナリオ比較

を一つの検証手順として実行します。

完了条件

• 配布ZIPまたはGit tagから再構築できる
• 同じ入力・seedで結果を再現できる
• E2Eテストが完走する
• 実データRunの検証記録がある
• 未確認項目をPASS扱いにしない
• READMEだけで第三者が実行できる

リリース

r010

---

10. 各Stepの関係

順番は重要です。

特に、

PLATEAU
 ↓
道路Graph
 ↓
静的避難
 ↓
浸水連携
 ↓
動的避難

の順を崩さない。

最初から水理計算、車両、3D表示、AIを同時に入れると、問題が発生したときに原因を切り分けにくくなります。

---

11. 品質ゲート

各Stepで最低限、次を確認します。

Ruff format
Ruff check
mypy
pytest
Docker build
Docker Compose smoke test

Web UIが入るStep6以降は、

Playwright

も追加します。

GIS処理では通常のUnit Testだけでは不十分なので、次も検査します。

• feature count
• geometry validity
• CRS
• bounds
• null geometry
• duplicated ID
• graph connectivity
• length sanity check
• population total
• shelter capacity
• timestamp continuity

---

12. テストの階層

Unit Test

個別関数。

例：

座標変換
道路分割
Agent速度
Flood threshold
Cost計算

Integration Test

複数コンポーネント。

PLATEAU → Road Graph
Building → Road Connector
Flood → RoadState
Mesa → PostgreSQL

Simulation Test

小さな人工ケースを使う。

A────B────C
     │
     D

期待する経路を手計算できるケースを用意します。

道路BCを閉鎖した場合に、

A → B → D

へ再探索することを確認します。

Real Data Smoke Test

実際のPLATEAUの小地域を使う。

E2E Test

WebからRunを開始し、結果表示まで通す。

---

13. 結果データ

時系列結果をすべてGeoJSONで保存すると、Agent数が増えたときに扱いにくい。

正式結果は、

Parquet / GeoParquet

を中心にします。

例：

results/
└── RUN_20260922_001/
    ├── manifest.json
    ├── metrics.json
    ├── agents.parquet
    ├── roads.parquet
    ├── shelters.parquet
    ├── flood.parquet
    ├── events.parquet
    └── logs/

Web表示用のGeoJSONやCZMLは、この結果から生成する派生データとします。

---

14. Scenario設定

コードを変更せずに条件を変更できるようにします。

scenario:
  name: flood_case_001
  random_seed: 12345

simulation:
  timestep_seconds: 5
  duration_seconds: 10800

evacuation:
  start_policy: distributed
  vertical_evacuation: true

routing:
  allow_replan: true
  congestion_enabled: true

population:
  pedestrian_ratio: 0.8
  vehicle_ratio: 0.2

flood:
  source: result_001

重要なパラメータをPythonコードへ直書きしません。

---

15. 最初は入れないもの

開発を安定させるため、初期段階では次を対象外とします。

• LLMによる避難判断
• 実住民の個人情報
• リアルタイム警報配信
• 自動での避難指示判断
• 建物内部の詳細な人流
• CFDによる個人周辺流体計算
• 全都市を最初から対象にした大規模実行

これらは基本システムが検証できてから追加します。

特にLLMは、Mesaの基本行動モデルの代わりにはしません。

必要になれば将来、

Rule-based Agent
        ↓
Calibration済み
        ↓
一部AgentだけLLM拡張

の順で検討します。

---

16. Mesaの採用方針

2026年9月時点では、Mesa公式ドキュメントでは安定版3系が案内され、4系の開発版も提供されています。

このプロジェクトでは最初の実装は安定版3系を固定して使い、4系への移行は別ブランチで評価します。

シミュレーションの再現性を確保するため、単に

mesa

とするのではなく、lock fileで実際に使用したバージョンを固定します。

同様に、

• NetworkX
• GeoPandas
• Shapely
• pyproj
• FastAPI
• OpenLayers
• CesiumJS

も配布時のバージョンを固定します。

---

17. PLATEAU道路を使う際の注意

PLATEAUの道路LOD0は道路中心線ネットワークを利用できるが、

道路データが存在する = そのまま避難経路として完全

ではありません。

実際には、

• 建物と道路の接続
• 避難所敷地内の接続
• 私道
• 徒歩道
• 横断歩道
• 高架・地下
• 河川をまたぐ誤接続
• 立体交差

などを確認する必要があります。

PLATEAU公式の避難シミュレーションの解説でも、建物と道路が常に接続しているわけではなく、避難所までの接道処理が必要になる例が示されています。

したがってStep3とStep4は、このプロジェクトでかなり重要な工程になります。

---

18. 防災シミュレーションとしての最終画面

最終的には、次のような画面構成を想定します。

2Dと3Dで別のシステムを作るのではなく、同じ run_id を表示します。

---

19. 最終的に確認したいこと

このシステムで重要なのは、派手な3D表示ではありません。

最終的には、次の問いに答えられるようにします。

避難開始が10分遅れるとどうなるか？

どの道路が最初にボトルネックになるか？

浸水によって何時に避難経路が失われるか？

どの地区で逃げ遅れが生じるか？

高齢者の歩行速度を考慮すると結果はどう変わるか？

避難所の収容人数は足りるか？

車避難の割合を増やすと渋滞はどう変わるか？

新しい避難所を追加すると改善するか？

垂直避難を認めると何人が安全側へ移るか？

PLATEAU、Mesa、水理シミュレーションを組み合わせる意味は、こうした条件を同じ都市モデル上で比較できることにあります。

---

20. このプロジェクトの完成形

最終的な完成条件を、機能ではなく処理の流れで定義します。

次の一連の処理を、同じ配布物から再現でき、利用者が通常操作をWebブラウザだけで行えれば第一段階の完成とします。

1. Web画面でProjectを作成し、PLATEAUデータを登録します
2. 建物・道路を正規化する
3. 道路ネットワークを生成する
4. 建物と避難所を道路へ接続する
5. 合成人口を作る
6. Input Studio / Mesh MapperからNILIM2.0入力を作成する
7. NILIM2.0で1D＋2D水理計算を実行し、道路・建物浸水状態へ変換する
8. Mesaで避難を計算する
9. WebのOpenLayers / CesiumJSで結果を確認します
10. Web Dashboardでシナリオを比較します

---

21. 開発ロードマップ一覧

Step	Release	主な成果	この段階で確認すること
1	r001	Docker・API・Mesa基本基盤	仮想道路でAgentが動く
2	r002	PLATEAU ETL	実PLATEAU建物・道路を読める
3	r003	NetworkX Graph	実道路で経路探索できる
4	r004	建物・人口・避難所	実都市にAgentを配置できる
5	r005	静的避難モデル	浸水なし避難が成立する
6	r006	OpenLayers Web UI	ブラウザからRunできる
7	r007	NILIM2.0正式連携	1D/2D計算結果から道路・建物状態を生成できる
8	r008	動的避難	再探索・混雑・車両が動く
9	r009	CesiumJS	PLATEAU上で3D時系列再生
10	r010	検証・比較・運用	E2E・再現性・性能を確認

---

22. 進め方

各Stepで追加した機能は、最終的に必ずWeb UIから利用できる形へ接続します。CLIだけで実行できる状態を完成とはしません。内部の検証用CLIは残しますが、通常の利用フローはWebを正とします。

このプロジェクトはStep1から順に実装します。

Step10の設計を先に意識しておくが、一度にすべてを作らない。

各Stepでは、

設計
 ↓
実装
 ↓
Unit Test
 ↓
Integration Test
 ↓
Docker実行
 ↓
実データ確認
 ↓
README更新
 ↓
Release

までを1セットにします。

「ソースを書いたので完了」ではなく、実際に使うデータと配布物で動作したところまでを完了とします。

---

23. NILIM2.0との統合で特に守ること

23.1 NILIM2.0は水を計算し、Mesaは人を計算する

責務を混ぜない。

NILIM2.0
    水位・流量・浸水深・流速・1D/2D交換

Mesa
    避難開始・移動・再経路探索・避難所選択

Mesa側へ水理方程式を再実装しません。

NILIM2.0側へ避難者ロジックを入れない。

---

23.2 Input StudioのProjectを水害シナリオの原典にする

河川・横断面・施設・接続・Subcatchment / Reach対応は、できるだけInput StudioのProjectとして一元管理します。

避難システム側へ同じデータを別形式で手入力しません。

Input Studio Project
       ↓
NILIM2.0
       ↓
FloodResult
       ↓
Mesa

とします。

---

23.3 PLATEAU建物をNILIM2.0メッシュへ直接埋め込むかは分けて考える

PLATEAU建物は、最初は被害・避難評価側で利用します。

NILIM2.0
    DEM・河川・施設から浸水計算

PLATEAU
    建物単位の影響評価

建物形状を水理計算の障害物として直接考慮する機能は、基本連携が安定した後に別検証とします。

これにより、

• 水理モデルの精度
• 建物形状による流れの影響
• 計算負荷

を分けて評価できる。

---

23.4 現在のEPSG:6676運用と全国展開を分離する

現在のNILIM2.0 Input Studio / Mesh MapperではEPSG:6676を基本としています。

したがって最初の統合検証は、EPSG:6676で扱える既存検証地域を使う方が安全です。

全国のPLATEAU都市へ展開するときは、

Project CRS Adapter

を設け、NILIM2.0側の複数平面直角座標系対応を別工程として進める。

最初から全国対応を前提に座標変換ロジックを複雑化しません。

---

23.5 水理側の品質確認を避難側より先に行う

NILIM2.0の出力をMesaへ渡す前に、

Validator
Exporter
Solver
水収支

まで確認します。

避難結果がおかしいときに、

水がおかしいのか
道路判定がおかしいのか
Mesaがおかしいのか

を切り分けられるようにします。

---

23.6 将来のリアルタイム化

将来、観測雨量や予測雨量を使ったリアルタイム計算へ拡張する場合も、基本構成は変えない。

NILIM2.0計算の完了時刻、Mesa計算の完了時刻、表示時刻をRun単位で記録し、実時間との遅延を計測できるようにします。

---

24. 参考資料・リンク集

この章では、本システムの設計・実装・検証で参照する資料を分野別に整理します。

リンクは、できるだけ国土交通省、国土地理院、気象庁、総務省統計局、OGC、各OSSプロジェクトの公式資料を優先した。

確認日：2026年9月22日

[!NOTE]
現在機能拡張・修正を進めている NILIM2.0そのものの公開公式マニュアルは確認できなかった。
そのため、NILIM2.0固有の入力形式、River / Node / Reach、DomainConnection、Subcatchment / Reach、500×500計算セル、502×502内部配列、Exporter等については、社内で管理しているNILIM2.0設計書・ソースコード・テストケースを一次資料とします。

外部公開資料については、国土交通省、国総研、土木研究所が公開している洪水・内水・氾濫解析関係の技術資料を、水理モデルの考え方と検証方法を確認するための参考資料として利用します。

---

24.1 PLATEAU

1. Project PLATEAU

国土交通省によるPLATEAU公式サイト。

PLATEAUの概要、ユースケース、データ、技術資料などの入口として利用します。

---

2. PLATEAU Open Data

対象都市、整備年度、LOD、提供データを確認します。

本システムでは、解析用PLATEAUデータの取得元と整備年度をRun Manifestへ保存します。

---

3. PLATEAUサイトポリシー・利用条件

PLATEAUオープンデータの利用条件、出典表記を確認します。

公開システムや成果物へ利用する場合は、データセットごとの利用条件と合わせて確認します。

---

4. PLATEAU Handbooks

PLATEAUを扱ううえで最も重要な資料群。

2026年3月31日公開の 3D都市モデル標準製品仕様書 第5.1版 などが掲載されています。

主に確認する資料は次のとおり。

• PLATEAU Guidebook
• 3D都市モデル標準製品仕様書
• 3D都市モデル標準作業手順書
• 3D都市モデルを活用した災害リスク情報の可視化マニュアル
• 3D都市モデルのデータ変換マニュアル
• PLATEAU VIEW構築マニュアル

Step 2のPLATEAU ETLを実装するときは、標準製品仕様書を基準にします。

---

5. PLATEAU Technical Reports

PLATEAUを使った実証システムの技術検証資料。

防災、人流、シミュレーション、CityGML変換、3D表示などの設計を検討するときに利用します。

---

6. PLATEAU配信サービス

PLATEAUの3D Tiles、MVT、地形などをWebシステムから利用するときの公式ドキュメント。

Step 9のCesiumJS連携で利用します。

---

7. PLATEAU配信サービス クイックスタート

都市やデータセットを検索し、PLATEAU配信サービスを利用する基本手順。

3D TilesをCesiumJSへ表示する場合は、年度更新への追随が容易な composite_url の利用を基本とします。

ただし解析用データは年度を固定し、表示用データと混同しません。

---

8. PLATEAU 3D Tiles

PLATEAUから配信される3D Tilesの仕様と利用方法。

Step 9でPLATEAU建物をCesiumJSへ表示するときに参照します。

---

9. PLATEAUで構成したデジタルツインで避難シミュレーションする

3D都市モデルを利用して避難シミュレーション環境を構築する公式チュートリアル。

本プロジェクトではUnityではなくMesaを利用するが、

• 道路と建物の接続
• 避難所への接続
• 実都市を避難空間にする考え方

の参考になります。

特に、PLATEAU道路と建物が必ず接続しているわけではない点はStep 3、Step 4で重要になります。

---

10. 徒歩及び車による時系列水害避難行動シミュレーション

徒歩避難と車両避難を扱うPLATEAUの防災ユースケース。

Step 8で歩行者と車両を別ルールで扱う際の参考にします。

---

11. 住民個人の避難行動立案支援ツール

浸水の時間変化と避難経路の関係を扱うユースケース。

NILIM2.0の時系列浸水結果をMesaの再経路探索へ接続する考え方の参考にします。

---

12. AIを活用したマルチエージェントシミュレーション技術等の開発業務

2025年度に実施されたPLATEAUのマルチエージェント実証です。

本プロジェクトでは特に、次の考え方を参考にします。

• 3D都市モデルをシミュレーションのフィールドとして使うこと
• 都市形状・属性をAgent行動の入力として利用すること
• パラメータ設定、実行、分析をWeb UIでつなぐこと
• 複数シナリオを比較すること
• 行動ログを残して結果の理由を確認できるようにすること
• システムの設定時間と実行時間を実測すること

公式実証ではLLMとUnityも利用していますが、本システムでは初期段階からLLMをAgent判断へ入れず、まずMesaによる再現可能なルールベースモデルを構築します。

LLMは、基本モデルの妥当性が確認できた後に、

• Scenario設定支援
• Agent行動理由の説明支援
• 条件比較の補助

などへ段階的に利用する方針とします。

---

24.2 CityGML・3D Tilesの標準仕様

13. OGC CityGML Standard

CityGMLの国際標準仕様。

PLATEAUのCityGMLを独自仕様として扱わず、CityGMLの概念モデルとの関係を理解するときに利用します。

CityGML 3.0への将来対応もこの仕様を基準に確認します。

---

14. OGC 3D Tiles Standard

大規模3D地理空間データ配信のためのOGC Community Standard。

現行仕様として3D Tiles 1.1が掲載されています。

CesiumJSだけに依存した独自形式ではなく、公開標準として扱います。

---

24.3 NILIM2.0・洪水・氾濫解析

15. 国土交通省 水管理・国土保全局 指針・ガイドライン

河川、防災、洪水、内水等の技術資料をまとめたページ。

NILIM2.0で洪水・内水計算の条件や結果を検証するときの基本資料として利用します。

---

16. 洪水浸水想定区域図作成マニュアル 第4版

河道内不定流計算、溢水・越水・氾濫流量、浸水解析、浸水継続時間などの考え方が整理されています。

NILIM2.0の、

• 1D河道計算
• 河川から2D領域への越流
• 浸水解析
• 水位・流量の扱い

を確認する参考資料として利用します。

---

17. 洪水浸水想定区域図・洪水ハザードマップ

洪水浸水想定区域図作成マニュアル、電子化ガイドライン、小規模河川の手引きなどがまとめられています。

NILIM2.0から出力した浸水深結果を、外部の公表データと比較するときにも利用できます。

---

18. 内水浸水想定区域図作成マニュアル（案）

内水氾濫、排水施設、降雨、地表流、下水道を扱う際の参考資料。

将来NILIM2.0へ下水道・マンホール等を接続する際にも参照します。

---

19. 下水道による内水浸水対策について

内水浸水対策に関するガイドライン、雨水管理総合計画、内水浸水想定区域図作成マニュアル等がまとめられています。

---

20. 国総研 下水道研究室 技術資料

国総研が関与した下水道・内水関係の技術資料一覧。

NILIM2.0を将来、内水・下水道連携へ拡張するときの参考にします。

---

21. 土木研究所 氾濫シミュレーション・マニュアル（案）

資料紹介：

PDF：

古い資料ではあるが、

• メッシュ分割
• 地盤高
• 氾濫原粗度
• 水路
• 破堤
• 二次元不定流
• 計算結果の検証

など、氾濫解析モデルの基本的な考え方を確認できます。

NILIM2.0の数値モデルそのものの仕様書として使うのではなく、基礎的な検証観点を整理するために参照します。

---

24.4 公的オープンデータ

22. PLATEAU Open Data

用途：

• 建物
• 道路
• 都市計画
• 土地利用
• 災害リスク
• 3D都市モデル

---

23. 国土地理院 基盤地図情報ダウンロードサービス

用途：

• DEM
• 基盤地図情報

無償で利用できるが、ダウンロードには利用者登録が必要。

2026年7月31日以降の提供データでは、座標参照系がJGD2011からJGD2024へ変更されているため、取得年度を必ずManifestへ記録します。

---

24. 国土地理院 数値標高モデルの説明

現在提供される数値標高モデルとして、

• 1mメッシュ
• 5mメッシュ
• 10mメッシュ

が整理されています。

NILIM2.0のDEM入力を作成するときは、取得元、DEM種別、作成年月、座標参照系を保存します。

---

25. 国土地理院 高精度標高データ

1mメッシュDEMの整備状況などを確認します。

詳細な浸水解析では1m DEMも候補になるが、NILIM2.0の計算メッシュを同じ解像度にするとは限りません。

入力DEM解像度と計算メッシュサイズは分けて管理します。

---

26. 国土地理院 指定緊急避難場所・指定避難所データ

CSV、GeoJSON等で指定緊急避難場所・指定避難所が提供されています。

Step 4の避難所データの基本候補とします。

ただし最新情報や未掲載施設がある可能性があるため、実案件では自治体データと照合します。

---

27. 指定緊急避難場所・指定避難所データ ダウンロード

全国、都道府県、市町村単位で避難所データを取得するときに利用します。

---

28. e-Stat 統計地理情報システム

用途：

• 国勢調査
• 小地域統計
• 地域メッシュ統計
• 境界データ

Synthetic Populationを作る際の基礎人口データとして利用します。

---

29. e-Stat 地域メッシュ統計

人口を地域メッシュ単位で取り扱う際の参考。

PLATEAU建物への人口配分を行う場合は、メッシュ人口総数とAgentの重み総数が一致することを品質確認項目とします。

---

30. 気象庁 気象データ高度利用ポータルサイト

AMeDASなどの気象観測データを機械判読可能な形式で扱うための入口。

NILIM2.0の降雨入力作成に利用できます。

---

31. 気象庁 過去の気象データ・ダウンロード

地点、項目、期間を選択し、観測データをCSVで取得できる。

過去災害の再現計算で利用します。

データは後から修正される場合があるため、取得日時とRawファイルのSHA-256をManifestへ残します。

---

32. 国土数値情報 道路データ

2024年度版では、全国の道路中心線と道路分類、幅員区分などが整備されています。

PLATEAU道路が不足する地域の補完候補として利用します。

このデータはノード・リンク構造を持たないため、NetworkXで利用するにはTopology生成が必要。

---

33. 国土数値情報 洪水浸水想定区域

2025年度版の洪水浸水想定区域データ。

用途：

• NILIM2.0計算結果との概略比較
• 初期デモ
• StaticHazardProvider
• PLATEAU建物の既存洪水リスク確認

これは時系列水理計算結果ではないため、Nilim20FloodProvider の代わりにはしません。

---

34. 国土数値情報 土砂災害警戒区域

将来、洪水避難だけでなく土砂災害を含む複合災害避難へ拡張するときに利用できます。

地域によって公開条件が異なる場合があるため、利用前に条件を確認します。

---

35. ハザードマップポータルサイト

洪水、土砂災害、高潮、津波などを重ねて確認できます。

シミュレーション対象地域の基礎確認や、公表ハザードとの位置関係確認に利用します。

---

24.5 Mesa・経路探索

36. Mesa Documentation

PythonのAgent-Based Modelingフレームワーク。

2026年9月時点では、公式ドキュメントで安定版Mesa 3系とMesa 4の開発版が案内されています。

本プロジェクトでは最初は安定版3系を固定し、4系は別ブランチで評価します。

Step 1から実際に利用したバージョンをlock fileへ固定します。

---

37. NetworkX Documentation

道路ネットワーク、避難経路、グラフ解析に利用します。

---

38. NetworkX shortest_path

重み付き最短経路探索の公式リファレンス。

本システムでは weight に道路長だけでなく、

• 浸水
• 混雑
• 道路リスク

を含めた動的コストを与える。

---

24.6 2D・3D Web GIS

39. OpenLayers

2D GISの中心ライブラリ。

本システムでは、

• 道路ネットワーク
• 建物
• 避難所
• Agent
• 浸水
• デバッグ
• 入力確認

を担当します。

---

40. OpenLayers API

2026年9月時点の公式APIページではOpenLayers v10.10.0が案内されています。

配布時には実際に採用したnpmバージョンを固定します。

---

41. CesiumJS

3D都市モデルと時系列シミュレーション結果の可視化に利用します。

本システムではStep 9から利用します。

---

42. Cesium Data Formats

主に次の形式を確認します。

• 3D Tiles
• CZML
• glTF
• Quantized Mesh

Mesa Agentの時系列軌跡をCZMLとして表示する場合にも参照します。

---

24.7 API・非同期処理・データベース

43. FastAPI

APIサーバー。

---

44. FastAPI Tutorial

Project、Scenario、Run、結果取得APIの実装時に参照します。

---

45. Celery

長時間のNILIM2.0計算やMesa計算をFastAPIプロセスから分離するために利用します。

---

46. Celery Getting Started

Worker、Task、Broker、Result Backendの構成確認に利用します。

---

47. PostGIS

建物、道路、避難所、シミュレーション管理などの空間データをPostgreSQLで扱います。

---

48. PostGIS Official Manual

空間インデックス、交差判定、最近傍検索、空間結合などを実装する際に参照します。

---

24.8 クラウドネイティブGIS形式

49. GeoParquet

PLATEAUから正規化した建物・道路や、解析用ベクタデータを保存する形式として利用します。

---

50. GeoParquet Specification 1.1.0

GeoParquetのメタデータ、geometry encoding等を確認します。

配布物では、使用したGeoParquet仕様バージョンを明記します。

---

51. Cloud Optimized GeoTIFF

NILIM2.0の最大浸水深、最大流速、時刻別ラスタ等をObject Storageへ配置するときの候補。

HTTP Range Requestで必要範囲を取得できるため、Web GISとの相性がよい。

---

24.9 実装時に作成する社内一次資料

公開資料だけでは、現在拡張中のNILIM2.0固有仕様は管理できません。

このプロジェクトでは、次の資料をリポジトリ内で正式に管理します。

docs/
├── architecture/
│   ├── overall_architecture.md
│   ├── data_flow.md
│   └── coordinate_height_policy.md
│
├── plateau/
│   ├── plateau_etl_spec.md
│   ├── building_schema.md
│   └── road_topology_spec.md
│
├── nilim20/
│   ├── nilim20_interface.md
│   ├── project_json_spec.md
│   ├── river_node_reach.md
│   ├── subcatchment_reach.md
│   ├── domain_connection.md
│   ├── mesh_500x500_502x502.md
│   ├── exporter_spec.md
│   ├── result_adapter_spec.md
│   └── water_balance_test.md
│
├── mesa/
│   ├── agent_model.md
│   ├── routing_cost.md
│   ├── evacuation_state.md
│   └── synthetic_population.md
│
└── tests/
    ├── reference_cases.md
    ├── e2e_test.md
    └── validation_policy.md

特にNILIM2.0については、外部資料よりもこの社内資料と実際のFortranソース、Input Studio、Exporter、テストケースを一次資料として扱います。

---

24.10 データの利用条件を記録する

取得したデータは、ファイルだけ保存して終わりにしません。

最低限、次をManifestへ記録します。

source:
  name: PLATEAU
  dataset: building
  url: https://...
  acquired_at: 2026-09-22
  dataset_year: 2025
  license: PDL-1.0
  sha256: ...

crs:
  source: EPSG:...
  analysis: EPSG:...

notes:
  - attribution required

データによって、

• PDL 1.0
• CC BY 4.0
• 国土地理院コンテンツ利用規約
• 都道府県ごとの追加条件

などが異なります。

「国のデータだから自由に使える」と一括りにせず、取得時点の利用条件をRunとは別のDataset Manifestへ保存します。

---

24.11 開発時に優先して読む資料

全資料を最初から読む必要はない。

Stepごとの優先資料は次のようにします。

Step	最初に確認する資料
Step 1	Mesa / NetworkX / FastAPI / Celery
Step 2	PLATEAU標準製品仕様書 / Open Data
Step 3	PLATEAU道路LOD / NetworkX
Step 4	e-Stat / 国土地理院避難所
Step 5	Mesa / NetworkX shortest_path
Step 6	OpenLayers / FastAPI
Step 7	NILIM2.0社内仕様 / 洪水浸水想定区域図作成マニュアル / 内水マニュアル
Step 8	PLATEAU水害避難ユースケース / Mesa / NetworkX
Step 9	PLATEAU 3D Tiles / CesiumJS / OGC 3D Tiles
Step 10	全入力データの利用条件 / 検証資料 / Run Manifest

---

24.12 参考資料の扱い

このリンク集は固定ではありません。

PLATEAU、国土地理院、国土数値情報、Mesa、CesiumJS等は継続的に更新されるため、各リリースで

docs/reference_links.md

を更新します。

特に次の項目はリリース前に再確認します。

• PLATEAU標準製品仕様書の最新版
• PLATEAU配信サービス仕様
• PLATEAU対象都市・整備年度
• 国土地理院DEMの座標参照系
• 避難所データ更新日
• e-Stat使用統計年度
• AMeDAS取得期間と修正情報
• 国土数値情報の最新年度
• Mesa安定版
• NetworkX
• OpenLayers
• CesiumJS
• FastAPI
• Celery
• PostGIS

再現性を優先するため、

最新バージョンへ自動的に追随すること

より、

検証したバージョンを固定し、更新時に再テストすること

を基本方針とします。

25. 次の作業

次は Step 1 — 実行基盤と共通データ契約 に進む。

Step1ではまだPLATEAUの大規模データを入れず、テスト用の小さな都市モデルを使い、最初からWebブラウザを入口として、

Docker Compose
   ↓
FastAPI
   ↓
Celery
   ↓
Mesa
   ↓
NetworkX
   ↓
PostgreSQL
   ↓
OpenLayers

までを一度通す。

この段階で、

• Project
• Scenario
• Run
• Agent
• RoadNode
• RoadEdge
• Shelter

のデータ構造を確定させる。

ここが安定すれば、Step2からPLATEAUの実データへ置き換えていける。

Step1の段階から FloodProvider インターフェースだけは定義しておき、Step7で Nilim20FloodProvider を追加してもMesa側のモデルを変更しなくて済むようにします。