はじめに：災害時のAIチャットボットは「動かすこと」だけが正解ではない
自治体や企業の窓口業務では、AIチャットボットの活用が広がっています。住民や顧客からの問い合わせに24時間対応でき、平常時には業務効率化や窓口負担の軽減に役立ちます。
しかし、地震・台風・豪雨・停電・通信障害などの災害時には、AIチャットボットの役割は大きく変わります。平常時のように「自然な会話で便利に答える」ことよりも、「誤った情報を出さない」「命に関わる情報を迷わせず届ける」ことが最優先になります。
特に生成AIを組み込んだチャットボットでは、事実に基づかない回答、古い情報の提示、避難情報の誤解釈などが起こる可能性があります。災害時にこうした誤情報が広がると、住民や利用者の避難行動を遅らせたり、行政・企業への信頼を損なったりするおそれがあります。
そのため、災害時のAIチャットボット設計では、「いつ稼働させるか」だけでなく、「いつ止めるか」「どの機能を縮退させるか」「どの代替導線へ誘導するか」を平時から決めておくことが重要です。元資料でも、AIチャットボットを無理に稼働させ続けるのではなく、災害フェーズに応じて停止・縮退・再稼働を切り替える設計の必要性が整理されています。
災害時にAIチャットボットが抱える主なリスク
平常時と有事では、求められるAIの役割が違う
平常時のAIチャットボットは、行政手続き、イベント案内、ごみ分別、子育て支援、社内FAQ、顧客対応など、幅広い問い合わせに柔軟に対応することが期待されます。
一方、災害時には対象範囲を広げることが必ずしもよいとは限りません。必要なのは、避難所の開設状況、危険区域、交通・ライフライン、支援制度、問い合わせ先など、限られた重要情報を正確に届けることです。
つまり、災害時のAIチャットボットには「便利な相談相手」ではなく、「公式情報へ迷わず誘導する案内役」としての設計が求められます。
ハルシネーションが直接的な危険につながる
生成AIには、もっともらしい文章を生成する一方で、事実と異なる内容を出力してしまうリスクがあります。いわゆるハルシネーションです。
平常時であれば、多少の言い回しの誤りや不完全な案内は、後から訂正できる場合もあります。しかし災害時には、避難先、河川水位、通行止め、給水場所、支援物資の配布場所などの情報が、人の判断に直結します。
たとえば、すでに閉鎖された避難所を案内してしまう、危険な経路を安全なルートとして示してしまう、公式発表前の不確かな情報を断定してしまうといった事態は避けなければなりません。
災害時のAIチャットボットでは、「答えられることを増やす」よりも、「答えてはいけないことを明確にする」設計が必要です。
通信障害やアクセス集中で情報更新が遅れる
災害時には、通信インフラそのものが不安定になることがあります。アクセス集中によりサーバーの応答が遅くなったり、外部APIとの連携が止まったり、最新情報の取得が遅れたりする可能性があります。
AIが参照しているデータが古くなっているにもかかわらず、画面上では自然な回答が表示され続けると、利用者はその情報を正しいものとして受け取ってしまいます。
そのため、災害時には「AIが回答できるか」だけでなく、「参照している情報が最新か」「公式情報と矛盾していないか」「データ取得に遅延がないか」を監視する必要があります。
AIチャットボットを停止・縮退させる判断基準
気象警報・地震・津波など外部環境の変化
停止判断の第一の基準は、外部環境の変化です。
大雨特別警報、震度の大きい地震、津波警報、大規模停電、避難指示の発令など、命に関わる情報が発生した場合は、通常の自動応答を継続するかどうかを見直す必要があります。
ここで重要なのは、災害が起きてから人が慌てて判断するのではなく、あらかじめトリガーを決めておくことです。
たとえば、一定以上の警報が発令された場合は、通常FAQを停止し、防災モードへ切り替える。震度や河川水位などの条件を満たした場合は、自然文生成を止めて、公式ページや固定メニューへの誘導に限定する。こうしたルールを事前に定めておくことで、緊急時の判断遅れを防ぎやすくなります。
連携データの遅延・欠落・エラー
AIチャットボットが避難所情報、河川水位、気象情報、交通情報、支援制度情報などの外部データを参照している場合、そのデータソースの健全性を確認する必要があります。
データ取得が遅れている、APIがタイムアウトしている、更新時刻が古い、公式発表と内容が一致しないといった状態では、AIに自由回答をさせるべきではありません。
この場合、AIの回答を止めるだけでなく、「現在、最新情報を確認中です」「公式発表ページをご確認ください」といった固定文へ切り替える設計が有効です。
災害時には、情報がないことをAIが推測で補ってしまうのがもっとも危険です。情報がない場合は「ない」と明示し、公式情報へ誘導することが基本です。
ユーザーの質問が急増・混乱している場合
災害時には、利用者の質問が急激に増えます。しかも、平常時のような丁寧な文章ではなく、「避難所どこ」「水きた」「学校は」「停電」「助けて」といった短い入力や曖昧な表現が増えることが想定されます。
AIがその意図を誤って解釈すると、必要な情報にたどり着けないだけでなく、利用者の不安を増幅させる可能性があります。
一定時間内に「わからない」「つながらない」「避難所」「助けて」などの問い合わせが急増した場合は、通常の会話型応答を縮退させ、防災メニューや公式ページ、電話窓口、プッシュ通知などへ誘導する判断が必要です。
公式情報とAI出力に矛盾が出た場合
AIの回答ログを監視し、公式発表と異なる内容が出ている場合は、即時に該当トピックの回答を止めるべきです。
たとえば、公式ページでは「A避難所は満員」となっているのに、AIが「A避難所を利用できます」と回答している場合、その回答は重大なリスクになります。
このような矛盾が見つかった場合は、対象範囲だけを止める方法もあります。全面停止ではなく、避難所情報のみ固定ページへ誘導する、河川水位に関する回答のみ停止する、といった部分的な縮退も考えられます。
全面停止ではなく「段階的縮退」で設計する
自然言語生成を止め、固定メニューへ切り替える
災害時のAIチャットボットでは、いきなりシステム全体を停止するのではなく、リスクの高い機能から段階的に止める設計が現実的です。
最初に止めるべきなのは、自由な自然文生成です。AIが利用者の質問に対して推測を交えながら文章を生成する機能は、平常時には便利ですが、有事には危険を伴います。
代わりに、防災メニュー、避難所一覧、ハザードマップ、公式発表ページ、電話窓口など、確認済みの導線だけを表示する形式に切り替えます。
RAG強制モードで回答範囲を限定する
復旧期や警戒期には、RAGを活用して回答範囲を限定する方法もあります。
RAGとは、AIが自由に知識を生成するのではなく、指定された資料やデータベースを検索し、その内容に基づいて回答する仕組みです。
災害時には、自治体の公式マニュアル、避難所データ、支援制度資料、FAQ、災害対策本部の発表内容など、信頼できる情報源だけを参照対象にすることが重要です。
ただし、RAGを使えば完全に安全というわけではありません。参照データが古ければ、AIの回答も古くなります。したがって、RAGデータの更新頻度、更新責任者、確認フローもセットで設計する必要があります。
「該当なし」の場合は推測回答を禁止する
災害時のAIチャットボットでは、回答が見つからない場合の動作が非常に重要です。
通常のチャットボットでは、ユーザー満足度を高めるために、多少あいまいな質問にも近い答えを返そうとします。しかし災害時には、この姿勢が危険になります。
該当する情報がない場合は、AIが推測して回答するのではなく、「現在確認できる情報がありません」「公式発表をご確認ください」「緊急の場合は指定窓口へ連絡してください」といった固定文に切り替えるべきです。
代替導線設計のポイント
防災モードのリッチメニューを用意する
LINE公式アカウントやWebチャットを活用している場合、災害時にはリッチメニューを防災モードへ切り替える設計が有効です。
平常時は、ごみ分別、手続き、子育て、イベント情報などを並べていても、災害時には情報量を絞る必要があります。
防災モードでは、次のような項目に限定すると、利用者が迷いにくくなります。
- 避難所情報
- ハザードマップ
- 気象・河川情報
- ライフライン情報
- 支援制度
- 緊急連絡先
- 公式発表ページ
重要なのは、AIに長文で説明させるのではなく、利用者がタップするだけで必要情報にたどり着ける状態にすることです。
静的ページ・PDF・公式SNSへ誘導する
AIチャットボットを停止した場合でも、情報提供そのものを止めてはいけません。
代替導線として、静的なWebページ、公式PDF、自治体や企業の公式SNS、緊急告知ページ、プッシュ通知などを用意しておく必要があります。
特に災害時には、チャット形式よりも一覧性のあるページの方が適している場合があります。避難所一覧、給水所一覧、停電エリア、交通規制、問い合わせ窓口などは、チャットで一問一答するより、整理されたページで見せた方が早いこともあります。
AIは入口として便利ですが、有事には「公式情報の場所へ素早く案内する役割」に徹する設計が安全です。
電話・有人対応への切り替えも想定する
災害時には、スマートフォン操作に慣れていない人、外国人、障害のある人、高齢者など、デジタルだけでは十分に情報へたどり着けない人もいます。
そのため、AIチャットボットの代替導線は、WebやLINEだけで完結させるべきではありません。
電話窓口、避難所での掲示、防災無線、広報車、地域団体との連携など、複数の導線を組み合わせることが重要です。
AIチャットボットの停止判断は、単なるシステム運用の話ではなく、住民や利用者に情報を届け続けるためのBCPの一部として考える必要があります。
復旧期にAIチャットボットを再稼働させる条件
再稼働は「元に戻す」ではなく「段階的に広げる」
災害直後の超急性期を過ぎると、問い合わせ内容は変化します。
避難所、命の安全、緊急連絡先に関する質問から、罹災証明、支援金、保険、片付け、住まい、学校、事業再開など、生活再建に関する質問へ移っていきます。
この復旧期には、AIチャットボットの自動応答が再び役立つ場面が増えます。ただし、いきなり平常時の設定に戻すのではなく、回答範囲を限定しながら段階的に再稼働させるべきです。
まずは、公式資料に基づくFAQ、手続き案内、必要書類、申請窓口、受付時間など、比較的安定した情報から再開するのが現実的です。
ログ分析でFAQとRAGデータを更新する
災害時に寄せられた質問ログは、復旧期の重要な改善材料になります。
利用者が何に困っていたのか、どの情報にたどり着けなかったのか、どの質問にAIが答えられなかったのかを分析することで、FAQやRAGデータを更新できます。
この継続的なチューニングがなければ、AIチャットボットは災害対応の経験を次に活かせません。
復旧期の運用では、単にチャットボットを再稼働させるのではなく、問い合わせログ、公式情報、現場の声を反映しながら、回答精度と導線を改善していく体制が必要です。
自治体・企業が平時から準備すべきこと
停止権限と判断責任者を決めておく
災害時に最も避けたいのは、「誰が止めるのか決まっていない」状態です。
AIチャットボットの停止や防災モードへの切り替えは、情報システム部門だけで判断できるものではありません。広報、防災、住民対応、顧客対応、法務、経営層など、関係部署との連携が必要です。
平時から、誰が停止を判断するのか、誰がデータを確認するのか、誰が公式文を承認するのか、どの条件で自動切り替えを行うのかを決めておく必要があります。
訓練で実際に切り替え操作を確認する
停止判断や代替導線は、文書に書くだけでは不十分です。
実際に、防災モードへ切り替える、固定メニューを表示する、AI回答を止める、公式ページへ誘導する、誤回答ログを確認する、といった操作を訓練しておく必要があります。
災害時は担当者自身も混乱している可能性があります。だからこそ、平時に手順を簡単にし、属人化を避け、複数人が対応できる状態を作ることが重要です。
BCPとAIガバナンスを接続する
AIチャットボットの災害時運用は、単独のシステム設定ではなく、BCPやAIガバナンスの一部として位置づけるべきです。
入力してよい情報、出力してよい情報、回答してはいけない領域、公式情報の参照先、ログ監視、責任分担、再稼働条件を整理しておくことで、災害時にも落ち着いた判断がしやすくなります。
AIを導入すること自体が目的ではありません。重要なのは、AIを使うことで情報提供の信頼性を高め、必要なときには安全に止められる設計にすることです。
まとめ：災害時のAIチャットボットは「止められる設計」こそ信頼性を高める
災害時のAIチャットボット運用では、通常時と同じ発想で「できるだけ多くの質問に答える」ことを目指すべきではありません。
大切なのは、命や安全に関わる情報について、誤回答を出さないことです。そのためには、外部環境、データソース、ユーザー行動、ファクトチェック結果をもとに、停止・縮退・代替導線への切り替えを判断する基準が必要です。
また、AIチャットボットを止めることは、情報提供を止めることではありません。防災モードのリッチメニュー、静的ページ、公式SNS、電話窓口、プッシュ通知などを組み合わせることで、AIに頼りすぎない情報提供体制を作ることができます。
復旧期には、RAGやFAQを活用しながら段階的に再稼働し、問い合わせログをもとに継続的に改善していくことが重要です。
災害時のAI活用で問われるのは、AIをどれだけ賢く動かすかだけではありません。危険な場面で、どれだけ適切に止められるか。そこまで設計して初めて、自治体や企業のAIチャットボットは信頼される情報インフラになります。
コメント