八代の災害情報サイト、AIで作り人が確かめる運営の分担

急いで作る場面と、確かめて載せる場面

インタビューでは、2016年の熊本地震の際にもJimdoで情報サイトを作った経験が語られている。以前のサイトはその後閉じた。今回の取り組みでは、画面の構成をChatGPTと考え、その内容をReplitへ渡して実装を進めたという。過去の経験を持つ制作者が、設計と実装の往復にAIを使った事例と読める。

短期間で公開したという結果だけから、経験のない人でも同じ時間で安全に運営できると結論づけることはできない。どの情報が必要か、利用者がどこで迷うかという判断は、画面のコードとは別の仕事だ。開発を速める道具があっても、地域の事情を理解する人の役割は残る。

特に災害時のSNSでは、以前の災害の案内や終了済みの配布情報が再び共有されることがある。福原氏は、情報の日付を確認しながら手で収集する運用を採ったと説明している。文章が自然であることと、その情報が今も有効であることは異なる。自動収集の速さを、そのまま掲載の可否に結びつけない設計だ。

制作の速さを、そのまま運営の自動化としない

取材で語られた手順では、AIへいきなり完成サイトの制作を丸投げするのではなく、必要な画面や機能を先に言語化していた。対話を通じて仕様をまとめ、実装する道具へ渡し、動作を確かめて直す。この過程には、地域の利用者が必要とする情報を選ぶという人の判断が入っている。

編集部としては、災害情報のサービスにおける「公開できた」と「役に立ち続ける」を別の状態として管理することが重要だと考える。ページが開いても、更新する人がいなければ、古い情報が見やすい形で残るだけになってしまう。制作期間の短縮によって空いた時間を、情報の確認や問い合わせに回せるかが、利用者にとっての価値を左右する。

また、支援情報を登録する側にも、通常の生活や復旧作業がある。掲載依頼の入口を複雑にしすぎると集まらず、自由入力だけにすると確認に時間がかかる。日時と場所など最低限の項目をそろえ、不足分を確認する仕組みは、AIの回答精度とは独立した情報設計の課題である。

地図だけでは伝わらない時間

報道によると、炊き出しや物資の情報を地図で見せるだけでなく、日程を把握しやすいカレンダーも整えた。利用者に必要なのは場所の座標だけではなく、いつ行けば利用できるか、何を持参すべきかという行動につながる情報である。情報の項目を増やすことより、期限切れの内容を見分けられることが重要になる。

これは編集部の考察だが、同種の仕組みを他地域へ移すなら、入力時点で開催日、掲載日、確認日、問い合わせ先を分けて記録する方法が考えられる。日付が不明な投稿は確認待ちに置き、期限後の扱いを決めておく。誤りを見つけた人が連絡できる経路も、地図の見栄えと同じ程度に必要だ。

飲食店の営業情報も人が集めていたとされる。SNSを日常的に使わない人へ情報を届ける目的も語られており、特定のアプリの利用を前提にしないWebサイトの意味がある。もっとも、通信や端末を使えない人の問題までWebで解消できるわけではない。掲示や地域の支援者など、別の伝達手段と併用する余地が残る。

多言語の入口は、情報源を絞って作る

取材時の説明では、投稿のたびに全言語へ翻訳する代わりに、サイト内の情報を検索して回答するチャットの入口を設けた。利用者が自分の言語で質問し、登録された情報を参照して回答を得る構成だ。検索した情報を回答に使うRAGは、費用と多言語対応を両立させる選択として採られたという。

ただし、RAGを使えば翻訳や回答が必ず正しくなるわけではない。検索対象の情報が古ければ古い案内が返る可能性があり、元の記載が曖昧なら回答も曖昧になりうる。災害時には、回答に情報源と確認日を添え、情報が足りなければ推測せず問い合わせ先を示す運用が大切だ。これは今回の運営で全項目が実装済みとする意味ではなく、横展開時に評価したい事項である。

AIが答える範囲をサイト内へ限定することにも意味がある。広いWebの情報を自由に混ぜるより、運営者が確認した情報の集合に責任範囲を合わせやすい。一方で、対象外の支援制度まで尋ねられたときの案内や、緊急対応を求められたときの分岐は別途必要になる。便利なチャットを、行政や緊急通報の代わりとして見せない配慮が求められる。

制作費より見えにくい運営費

インタビューには、被災して仕事が減った3人へ作業を依頼し、JPYCで対価を払ったという説明がある。支援を集めて第三者へそのまま渡す形ではなく、自身の事業として発注した作業への報酬だと区別されている。この事例を、特定の決済手段を用いた公的な救済制度と読み替えることはできない。

また福原氏は、Replitの費用が使い方で変わることにも触れている。月額プランだけを制作費の上限と考えると、AIの作業や外部サービスの利用を含む総額を見誤る。小規模な地域プロジェクトでも、開発に使う費用と、公開後のホスティング、問い合わせ、更新作業の費用は分けて見積もりたい。

運営者のクラウドファンディングページでは、被災したIT教室の再開に向けた計画とともに、構成ファイルの提供や運用代行がリターンとして示された。募集期間は9月9日から30日で、この記事の公開時点とは異なる。現在も募集しているという案内として扱うべきではない。

地域への横展開に必要な引き継ぎ

同じプログラムを別の市町村に持っていっても、同じ情報が集まるとは限らない。どの団体が炊き出しを行い、どこで情報を公表し、誰へ確認できるかという地域の関係性は、ファイルの外側にある。取材で語られた横展開の難しさは、この運営知識も含めて考えると理解しやすい。

具体的には、情報源の一覧と連絡先、掲載を見送る条件、訂正の手順、担当者の交代方法をまとめることが考えられる。これは現在のサイトに不足があるという評価ではなく、別地域で仕組みを再利用する際の提案だ。公開するための設定と、掲載判断を続けるための手順は、別々の引き継ぎ資料にしたほうが使いやすい。

支援が落ち着いた後の休止にも判断が必要になる。残す資料と現在の案内を区別し、更新が止まったことを利用者が分かるようにする。将来の再開では、以前の連絡先や権限が有効かを確認する。災害時だけ動く仕組みほど、平常時の維持管理が次の立ち上げの速さに影響する。

費用面でも、構築作業に対する一度の支援と、月々の運営を賄う仕組みは同じではない。寄付や発注の対価をどう使い、何を継続できるかを説明できる状態が望ましい。AIの利用料金が変わった場合にも、必要な機能を残して縮小できる構成なら、運営を止める以外の選択肢を持ちやすい。

本番への反映は、公開用の環境で分ける

Replitの公開に関する公式説明では、開発と公開の環境を区別している。エージェントが本番データベースを直接変更できないという制限も記載されている。取材では、福原氏も開発環境でエラーを確認してから本番へ反映する運用を説明していた。

環境を分けても、誤った仕様を公開したり、情報を載せ間違えたりする問題は残る。バックアップ、公開前の表示確認、権限の限定は、それぞれ別の役割を持つ。復旧できることまで確認して初めて、失敗時にサービスを戻す見通しが立つ。地域の少人数運営では、特定の一人しか手順を知らない状態を減らすことも重要だ。

福原氏は周辺の市町村への横展開を望む一方、ファイルを渡すだけでは別の運営者が立ち上げるのは難しいと話していた。取材で語られた震度5以上での再稼働の構想についても、将来の構想と、現在確実に動作する仕組みを分けて理解したい。次の災害に自動的に対応できると保証されたものではない。

編集部がこの事例から重視するのは、AIに制作を任せる範囲より、情報更新と運営の責任を継続して引き受ける体制である。確認者の交代、費用の負担者、サイトの休止と再開の判断を先に決めれば、短期間の開発を継続的な支援へつなげやすくなる。

AIを使ったサイト制作・業務運用の相談先と運営会社情報はRO合同会社へ。事例のサイトはやつしろ災害情報共有。記載した取り組みの事実と、横展開に関する編集部の提案は区別している。