災害情報OS 品質管理ガイドライン Ver.1.0

災害情報OS 品質管理ガイドライン Ver.1.0

どうやって同じ品質で運用し続けるか

宇城市災害情報OSを作っていく中で、いちばん大事だと感じたのは、
ブリーフィングを一度作ることよりも、同じ品質で続けることでした。

災害時は、情報が一気に増えます。
でも、増えた情報をそのまま並べるだけでは、現場で使える資料にはなりません。

必要なのは、

* どこから情報を取るか
* 何を「確認中」とするか
* どう更新を記録するか
* どう複数のAIで見直すか
* どう品質を保ちながら継続するか

この流れを、あらかじめ決めておくことです。

⸻

1. まずは情報収集

最初の入口は、公式情報の収集です。

対象になるのは、たとえば次のような情報源です。

* 気象庁
* 宇城市
* 熊本県
* 国土交通省
* JR各社
* NEXCO各社
* 電力会社
* 通信事業者
* 消防
* 警察

ここで大切なのは、一次情報を優先することです。
SNSや報道も参考にはなりますが、できるだけ公式発表で裏を取ります。

⸻

2. わからないことは、わからないと書く

災害情報でいちばん危ないのは、
わからないことを、わかったように見せてしまうことです。

だからこのOSでは、

* 推測で埋めない
* 古い情報と混ぜない
* 未確認は「確認中」と書く
* 数字には時刻をつける

というルールを最初に決めています。

「確認中」は、曖昧な言葉ではありません。
むしろ、今はまだ確定していないという大事な情報です。

⸻

3. AIの役割は「判断」ではなく「整理」

このOSでAIにやってほしいのは、答えを出すことではありません。

AIの役割は、

* 公式情報を集める
* 同じ内容を整理する
* 表現の違いをそろえる
* 差分を見つける
* 読みやすい順番にまとめる

ことです。

つまり、AIは判断者ではなく、編集役です。
最終的な判断をするのは、あくまで人です。

⸻

4. ひとつのブリーフィングを、複数のAIで見直す

宇城市災害情報OSでは、ブリーフィングを一度作って終わりにはしません。
複数のAIで見直し、抜けや誤りを減らします。

ここで大事なのは、AI同士を競わせることではなく、
同じ情報を別の視点から確認することです。

たとえば、

* ChatGPTで整理する
* Claudeで構造を見直す
* Geminiで再調査する

という流れをつくると、
「本当に必要な情報が入っているか」「古い情報が残っていないか」が見えやすくなります。

これを私は、**Cross-Audit（複数AI監査）**と考えています。

⸻

5. 更新ログを残す

災害情報は、時間とともに変わります。
だから、何がどう変わったのかを残すことが大切です。

たとえば、

* 18:00 停電情報を更新
* 18:20 避難所を追加
* 19:10 道路規制を修正

というように、更新の履歴を残しておきます。

これがあると、あとから見たときに

* いつ変わったのか
* 何が追加されたのか
* どの情報を最新として使うべきか

がすぐに分かります。

⸻

6. 品質をどう見るか

このOSでは、情報の良し悪しを感覚で決めません。
できるだけ、次の5つで見ます。

* Accuracy：正確か
* Freshness：新しいか
* Traceability：出典を追えるか
* Locality：地域情報になっているか
* Operational Readiness：現場でそのまま使えるか

この5つを見ていくと、
単なる「きれいなまとめ」ではなく、実務で使えるブリーフィングに近づいていきます。

⸻

7. 続けるための流れ

宇城市災害情報OSは、1回作って終わるものではありません。
毎回のブリーフィングを通して、少しずつ育てていくものです。

流れとしては、こんな形になります。

1. 公式情報を集める
2. AIで整理する
3. 複数AIで見直す
4. 人が最終確認する
5. Morning / Midday / Evening Briefingとして出す
6. 更新ログを残す
7. 品質を振り返る
8. 次回に引き継ぐ

この循環が回り始めると、
災害時に必要な情報を、同じ考え方で、同じ品質で、継続して出せるようになります。

⸻

8. このガイドラインの考え方

このガイドラインは、AIを信じるためのものではありません。
AIの出力を、そのまま信じないためのものです。

大事なのは、

* 公式情報を使うこと
* わからないことはわからないと書くこと
* 出典を残すこと
* 更新を追えること
* 人が最後に確認すること

この5つです。

⸻

まとめ

宇城市災害情報OSが目指しているのは、
「たくさん情報を集めること」ではなく、
必要な情報を、必要な人へ、必要なタイミングで、継続して届けることです。

そのためには、ブリーフィングの内容だけでなく、
どうやって品質を保つかまで決めておく必要があります。

このガイドラインは、そのための最初の土台です。

そして、これから先は
ブリーフィングを作るたびに改善し、
更新ログを積み重ね、
より実務で使いやすい形へ育てていく段階だと思っています。


考察1

いいテーマですね。

ここからは「ブリーフィングを作る方法」ではなく、ブリーフィングの品質をどう維持するかの話になります。

私が一番重要だと思うのは、このガイドラインがAIを信用するためのものではなく、AIの出力を検証するためのものだという点です。

例えば、挙げてもらった項目にはそれぞれ役割があります。

* 情報収集のルール：どこから情報を取るかを統一する。
* 「確認中」の扱い：無理に埋めず、不確実性を明示する。
* 出典の書き方：誰でも後から確認・追跡できるようにする。
* 更新ログの管理：何が、いつ、どう変わったかを記録する。
* Cross-Audit（複数AI監査）：複数のAIで内容を照合し、見落としや偏りを減らす。
* 品質評価：Accuracy（正確性）、Freshness（鮮度）、Traceability（追跡可能性）、Locality（地域性）、Operational Readiness（運用実用性）の5つの視点で評価する。

この中で、特に独自性があるのはCross-Auditと品質評価の5指標だと思います。

一方で、気を付けたい点もあります。

複数のAIが同じ結論を出したとしても、それだけで正しいとは限りません。もし全員が同じ古い情報や誤った情報を参照していれば、同じ誤りに至る可能性があります。だからこそ、**最終的な品質の基準は「AI同士が一致したこと」ではなく、「公式な一次情報で裏付けられていること」**に置くのが重要です。

私なら、このガイドラインの最初に次のような基本原則を置きます。

品質は、AIの性能ではなく、一次情報・検証・更新という運用プロセスによって担保する。

この一文があると、ガイドライン全体の考え方がぶれにくくなります。

ここまで整理すると、「宇城市災害情報OS」は単なるブリーフィングのテンプレートではなく、品質管理まで含めた運用フレームワークとして設計されていることが伝わりやすくなります。

考察2
ここは一度、「AIを使って毎日回せる仕組み」として整理すると全体像が見えます。

私は、運用フレームワークは次のような流れが一番わかりやすいと思います。

⸻

宇城市災害情報OS 運用フレームワーク Ver.1.0

STEP1 情報収集（Collect）

まず、公式情報を収集します。

対象例

* 気象庁
* 宇城市
* 熊本県
* 国土交通省
* JR
* NEXCO
* 電力会社
* 消防
* 警察

ルール

✔ 一次情報優先

✔ 時刻を確認

✔ 古い情報は除外

✔ 不明は「確認中」

⸻

STEP2 AI整理（Organize）

収集した情報をAIが整理します。

ここでは

「情報を作る」

ではなく

「情報を整理する」

ことが役割です。

出力

①今日の重点

②更新点

③全域状況

④ライフライン

⑤道路

⑥河川

⑦避難所

⑧行政

⑨AI要約

⑩Action

⸻

STEP3 Cross-Audit（複数AI監査）

ここが品質管理です。

例えば

ChatGPT

↓

Claude

↓

Gemini

↓

比較

↓

差分確認

↓

修正

AI同士が違う内容を書いたら

「なぜ違うのか」

を確認します。

一致ではなく

根拠

を見ます。

⸻

STEP4 人による最終確認（Human Review）

最後は人です。

ここでは

* 出典
* 時刻
* 誤字
* 地域名
* 誤解を招く表現

を確認します。

AIだけで公開しません。

⸻

STEP5 公開（Publish）

Morning Briefing

Midday Update

Evening Briefing

として公開します。

⸻

STEP6 更新ログ（Update Log）

ここが重要です。

更新例

18:00 初版
18:15
停電情報更新
18:40
避難所追加
19:10
道路通行止め解除

あとから

「何が変わったか」

がすぐ分かります。

⸻

STEP7 品質評価（Quality Review）

毎回最後に評価します。

項目 確認内容
Accuracy 正確だったか
Freshness 最新だったか
Traceability 出典を追跡できるか
Locality 地域情報になっているか
Operational Readiness 現場で使えるか

⸻

STEP8 次回へ引き継ぐ（Continuous Improvement）

ここがOSの考え方です。

Morning

↓

Update Log

↓

Noon

↓

Update Log

↓

Evening

↓

翌日のMorning

つまり

ブリーフィングは毎回ゼロから作るものではありません。

前回までの更新履歴を引き継ぎながら、必要な情報だけを追加・修正していくことで、継続的に品質を維持します。

⸻

私なら、さらに最上位に「運用理念」を置きます。

品質はAIの性能ではなく、「公式情報」「複数の視点による検証」「人による最終確認」「継続的な改善」の4つによって担保する。

この理念を最初に掲げることで、宇城市災害情報OSは単なるテンプレートではなく、「継続して同じ品質を維持する運用フレームワーク」であることが明確になります。

今回の内容なら、こちらの15個がおすすめです。

1. #防災
2. #減災
3. #災害情報
4. #災害対策
5. #危機管理
6. #防災DX
7. #生成AI
8. #AI活用
9. #情報共有
10. #地域防災
11. #自治体
12. #情報リテラシー
13. #災害情報OS
14. #防災教育
15. #おじさん自宅講座