宇城市災害情報OSをつくる
宇城市災害情報OSをつくる
今回あらためて強く感じたのは、災害時に本当に必要なのは「情報をたくさん集めること」ではなく、必要な情報を、必要な人へ、必要なタイミングで届ける仕組みだということです。
最初は、地震やデマ、ライフラインの混乱をどう見るかという話から始まりました。
けれど、話を深めていくうちに、本質はもっと別のところにあると分かってきました。
それは、情報が一方通行ではなく、循環していく仕組みをどう設計するかです。
⸻
1. 情報は「配る」だけでは足りない
災害が起きると、情報は一気に増えます。
* 気象庁の速報
* 自治体の避難情報
* 報道機関の速報
* インフラ事業者の発表
* 現場の声
* SNSの投稿
しかし、現場で本当に必要なのは、全部をそのまま見ることではありません。
必要なのは、
* 今どこが危ないのか
* 何が止まっているのか
* どこを優先して確認すべきか
* 市民は次に何をすればいいのか
という、判断と行動につながる情報です。
だからこそ、災害情報は「配る」だけでなく、圧縮し、整理し、返していく必要があると考えました。
⸻
2. 人へのプロンプトという考え方
AIに「これを教えて」と聞くように、災害時には人にも次に何を確認すればいいかを渡す必要があります。
たとえば、
* 避難指示は出ていますか
* 自分の地域は対象ですか
* 家族と連絡は取れていますか
* 停電や断水はありますか
* 次の公式更新はいつですか
こうした問いがあるだけで、人は混乱の中でも次の行動に進みやすくなります。
つまり、災害対応で大切なのは、情報そのものだけではなく、人が自分で判断できるようになるためのプロンプトを用意することです。
⸻
3. 平時の戦略と、非常時の戦術
ここまでの話で一番大きかったのは、
平時と非常時を分けて考えるという視点でした。
平時は戦略
平時にやるべきことは、仕組みを作ることです。
* どんな情報を集めるか
* どう分類するか
* 誰が見るか
* AIはどこで使うか
* どの情報を見せ、どの情報を見せないか
これは、災害が起きる前に整えておくべき設計です。
非常時は戦術
実際に災害が起きたら、必要なのはスピードです。
* 必要な情報だけを届ける
* 市民の状況を集める
* 優先順位を整理する
* 行政の判断を支える
つまり、非常時は「全部出す」のではなく、選んで届けることが重要になります。
⸻
4. 宇城市災害情報OSという構想
ここから、考え方は少しずつ具体化していきました。
最初に作るのは、宇城市を対象にした災害情報OSです。
これは単なる地図ではありません。
状況を見える化し、判断につなげる情報循環のインフラです。
宇城市で扱う情報
* 震度・震源
* 停電
* 断水
* ガス
* 通信
* 道路
* JR
* 港湾
* 避難所
* 医療機関
* 河川
* 土砂災害
* 行政発表
* 人的被害
これらを一枚の画面に集約し、さらに時間とともに変化を追えるようにします。
⸻
5. 毎朝6時のモーニング・ブリーフィング
この構想を実務レベルに落とし込むために、
毎朝6:00に最新の運用画面を作るという形を考えました。
つまり、毎朝見るのは「昨日のまとめ」ではなく、
今この時点での状況判断シートです。
画面には、たとえば次のような情報を載せます。
* 今日の重点
* 災害概要
* 宇城市全域のステータス
* ライフライン
* 道路
* JR
* 河川
* 避難所
* 医療
* 行政動向
* 被害状況
* AIによる差分解析
* 本日の行動
特に大事なのは、最後のActionです。
状況を表示するだけで終わらず、
* 給水車派遣
* 避難所追加
* 河川巡回
* 道路点検
* 高齢者安否確認
* 広報配信
のように、次にやることまで見えるようにすることです。
⸻
6. 3つのAIの役割分担
この構想では、AIを一つにまとめるのではなく、役割を分けます。
Gemini
* 最新情報の収集
* 公式発表の確認
* 情報源の抜け漏れチェック
Claude
* データ構造の整理
* JSONやCSVへの変換
* GISレイヤー設計の確認
* システムとして壊れないかのレビュー
ChatGPT
* 全体設計
* 画面設計
* 情報循環の整理
* 論点とトレードオフの整理
そして最後の判断は、AIではなく人間が行います。
ここは絶対に揺らいではいけない部分です。
⸻
7. 画面より先に、データをそろえる
実際にHTMLを組んでみて分かったのは、
見た目が動いても、データが構造化されていないと運用できないということでした。
ここで必要なのは、まず共通のデータ構造です。
* status
* value
* geo_ref
* updated_at
* source
* reliability
* note
この共通スキーマがあると、画面、GIS、PDF、API、CSVのすべてがつながります。
つまり、まず必要なのは「きれいな画面」ではなく、共通の情報の型です。
⸻
8. 災害情報OSの本当の目的
この構想の目的は、地図を作ることでも、AIを競わせることでもありません。
本当にやりたいのは、
人が混乱したときに、迷わず次の行動へ進める仕組みをつくること
です。
そのために必要なのは、
* 情報を増やすことではなく、整理すること
* 正解を急ぐことではなく、確認中を残すこと
* AIを判断者にすることではなく、編集者にすること
* 一方向ではなく、情報を循環させること
だと思っています。
⸻
9. これからの進め方
ここまで来て、次の段階が見えてきました。
1. 宇城市版の共通データモデルを決める
2. JSONスキーマを固定する
3. GISレイヤーを整理する
4. 毎朝6:00のモーニング・ブリーフィングを更新する
5. Gemini・Claude・ChatGPTの役割を固定する
6. 実運用で見えた弱点を修正する
この流れができれば、宇城市モデルは単なる試作品ではなく、
災害情報OSの実証モデルになります。
⸻
まとめ
今回の話を一言でまとめるなら、
必要な情報を、必要な人へ、必要なタイミングで届けるために、情報を循環させる仕組みをつくる。
です。
地図はその一部であって、本体は情報の流れそのもの。
AIは主役ではなく、その流れを支える編集層。
宇城市から始めるこの試みが、
災害時に人が迷わず動けるための新しい情報の形につながればと思っています。
こちらが今回の記事に合うタグ15個です。
* #宇城市災害情報OS
* #防災
* #災害情報
* #危機管理
* #防災DX
* #GIS
* #WebGIS
* #生成AI
* #AI活用
* #情報設計
* #情報共有
* #情報循環
* #自治体DX
* #災害対策
* #おじさん自宅講座
