【防災】自治体の手が届かない避難所の「自衛」受付：箱舟プロジェクト(TinyBox)＋Delta Chat＋ちゃっと入退場

Posted at 2026-10-26

大規模災害では、自治体職員も被災します。道路が寸断され、避難所の数が多く、すべての避難所に職員が駆けつけられないことがあります。そのとき、避難所の現場で最初に詰まるのが 「誰が、いま、ここにいるのか」を把握することです。

この記事では、Raspberry Pi 5で作る避難所内の小さな通信網「箱舟プロジェクト（TinyBox）」と、Delta Chatの中で動くQR受付ミニアプリ「ちゃっと入退場（v1.5.1）」を組み合わせた、自治体の手が届かない場面で、住民や自主防災組織が自力で受付を回すための「自衛」の運用案を紹介します。

本記事は災害対策技術の実験・研究に基づく運用案です。アプリv1.5.1の実装に基づいて説明していますが、TinyBoxと複数実機を組み合わせた動作・通信性能・稼働時間の検証結果を示すものではありません。平時に地域の運営体制と既存の受付手順との接続を確認し、訓練で使える範囲を確かめます。「できること」「できないこと」「個人情報の扱い」も後半にまとめています。

1. 自治体の避難所受付は、いまどうなっているか

まず、公式の動きを整理します。避難所受付のデジタル化は、すでに全国で進んでいます。

名古屋市は、能登半島地震で紙の避難者名簿のせいで情報の把握や共有、データ化に時間がかかり、対策本部の情報収集が遅れたことを踏まえ、2026年2月に実証実験を行いました。名簿記入、Webフォーム、LINE、カードリーダーの4方式を比較しています（名古屋市の報道発表）。
デジタル庁は、2026年2月に三重県名張市の協力を得て、マイナンバーカードを使う避難者受付アプリの実証を行いました。このアプリは、インターネット回線が遮断された環境でも動作するとされています（DXマガジン）。
大田区は、2026年4月から、防災アプリとマイナンバーカード、紙の避難者カードによる受付を始めています（大田区）。
豊中市は、QRコードを読み取ってスマホで入退所手続きをし、避難所ごとの滞在者数をリアルタイムで把握できる仕組みを導入しています（豊中市）。

課題は広く認識され、公式の仕組みも整いつつあります。それでも、次のような場面は残ります。

公式の仕組みが届きにくい場面	例
職員が駆けつけられない	職員自身が被災した、道路が寸断された、避難所が多すぎる
公式の仕組みの外にある場所	自治会館、公民館、民間施設、自主的に開設された避難場所
公式の仕組みが使えない・足りない	端末・電源・カードリーダーが足りない、導入前の地域
孤立した地区	外部との連絡が取れず、地区内で完結して動く必要がある

この記事が対象とするのは、この空白を地域が自力で埋めるための備えです。自治体の仕組みの代替ではなく、手が届くまでのつなぎであり、のちに自治体へ引き継げる形（CSV出力など）を意識しています。

2. 現場で何が困るのか

外部通信に依存する受付システムでは、回線断時に共有やオンライン機能が制限されます。オフライン対応のシステムや紙でも受付は続けられますが、複数受付の記録を集約し、現在の状態をそろえる手順が必要です。

困りごと	紙の名簿だと…
現在の人数を集約したい	名簿の回収や手集計に時間がかかる
外出・退所の区別	記録欄と更新手順を決めないと区別しにくい
受付が複数ある	名簿が分散し、重複・漏れが出る
物資の配布記録	別の台帳になり、受付情報との照合に手間がかかる
家族単位の把握	世帯をひも付ける欄や集約手順が必要

必要なのは、インターネットがなくても動く小さな通信網と、その上で動く受付の仕組みです。

3. なぜTinyBoxなのか

受付システムには、クラウド型やオフライン対応型などがあります。本構成では、外部回線が使えない間も、地域内で複数端末をつなぐ通信経路を自分たちで用意するためにTinyBoxを使います。

理由	内容
外部回線なしで動く	Raspberry Pi 5にWi-Fiアクセスポイントとメールサーバー（E-Post）を構築します。端末のアカウント、名前解決、証明書、メール配送を地域内で完結するよう設定し、外部回線を切った状態で動作確認します
持ち運べる・低消費電力	元記事では消費電力3〜8Wを目安としています。連続稼働時間は電池容量・変換損失・Wi-Fi機器などに依存するため、実際の構成で測定します（本記事では未実測）
台数を増やせる	メッシュWi-Fi（BATMAN-adv）で、複数台を中継して範囲を広げられます
地域で所有・運用できる	地域内のメールサーバーとアカウントを自分たちで管理できます。費用は機器・電源・予備品・保守を含めて見積もり、利用ソフトウェアのライセンス条件も確認します
メール方式でデータが残る	Delta Chatはメール方式のチャットです。通信が不安定でも、未送信の分は端末に保持され、接続が戻ったら再送されます

ただし、単一のTinyBoxをメール配送に使う構成では、その停止中は端末間の更新共有が止まります。電源の確保も必要です（限界の章を参照）。

TinyBoxの構築手順は、箱舟プロジェクトの元記事を参照してください。地図で助け合う姉妹編はこちらです。

4. 全体構成

3つの部品でできています。

図：避難所内だけで閉じた通信網。受付端末と管理者端末が、TinyBoxのWi-Fiにつながる。

部品	役割
箱舟プロジェクト（TinyBox）	避難所内だけの通信基地。Wi-Fiアクセスポイントとメールサーバー（E-Post）を担う
Delta Chat	各端末で動くメール方式のチャットアプリ。TinyBoxのメールサーバーにつなぐと、インターネットなしでグループチャットができる
ちゃっと入退場	チャットに`.xdc`ファイルとして送るだけで動く、QR入退場・世帯管理アプリ（Webxdcミニアプリ）

5. Delta ChatとWebxdc

Webxdcは、チャットにファイルとして送るだけで、グループ内で動かせるミニアプリの形式です。webxdcアプリ専用のサーバーや追加アカウントは不要です。共有に使うDelta Chat側には、メールサーバーとアカウントが必要です。

.xdcの実体はZIPファイルで、index.htmlとmanifest.tomlなどを含みます。ちゃっと入退場もこの形式で、アプリ専用の外部サーバーへアクセスしません（QR生成・読取のライブラリも同梱）。

Delta Chat自体は事前にインストールが必要で、TinyBoxのメールアカウントも設定しておく必要があります。 被災後はアプリストアも使えないため、受付担当者・管理者の端末は平時に準備しておく前提です。

6. ちゃっと入退場とは

来場者・避難者ごとにQRコードを発行し、受付端末でスキャンするだけで入退場を記録するアプリです。記録は同じチャット内の全員に共有されます。

基本の流れ

グループを作る：受付担当者と管理者でDelta Chatのグループを作る
アプリを送る：グループに.xdcを送り、全員が同じメッセージのアプリを開く
QRを発行する：避難者の氏名などを登録し、本人用QRを発行（保存・印刷できる）
スキャンする：受付で「入所」「一時外出」「帰所」「正式退所」のボタンを押してQRを読む
状況を見る：管理者端末で在場人数・世帯別の状態・集計を確認する

QRの中身は来場者IDだけです。氏名などの個人情報はQRに入らず、登録情報との照合で表示されます。

操作デモ（約5秒）

[ちゃっと入退場の操作デモ：メンバー端末の画面、世帯・年齢の登録、入所の記録、管理者の在場者表示、避難者HXL CSVの保存、避難者掲示への取込]

ブラウザーデモ版での操作です（画面上部に「記録はこのブラウザーに保存されます」と表示されています）。Delta Chat実機での端末間共有の様子ではありません。

デモの流れは次のとおりです。

メンバー端末の画面で、利用モードを選ぶ
氏名・世帯・年齢などを登録してQRを発行する
「入所」を記録し、最近の記録に表示される
管理者画面で、在場者と本日の記録を確認する
「避難者HXL CSVを保存」でCGI向けのデータを書き出す
避難者掲示（esbbs.cgi）の避難者一覧に、書き出したデータが表示される（章9）

2つの利用モード

端末ごとに、ボタンのレイアウトを切り替えられます。

モード	記録区分
イベント用	入場・退場
避難所用	入所・一時外出・帰所・正式退所

避難所用では、「戻る予定のある外出」と「受入れの終了」を区別できます。

区分	意味	受入継続人数
入所 / 帰所	在所中になる	含む
一時外出	戻る予定がある外出	含む
正式退所	受入れを終了	外れる

受信済みの記録に基づく整合性チェックもあり、たとえば「一時外出は在所中の人物にだけ記録できる」「帰所は一時外出中の人物にだけ記録できる」「正式退所の前に入所記録を確認する」といった制約があります。

複数端末が切断中に操作した場合は、同じ時点の状態を共有できません。復旧後に人物・時刻・区分を照合します。

2つの端末ロール

ロール	できること
メンバ端末	受付・QR発行・スキャン。集計やレポートは出せない
管理者端末	上記に加え、集計グラフ、記録一覧、会場・ブース・物資の管理、世帯管理、CGI出力、設定

管理画面へは「管理者端末としてログイン」から、またはアプリのタイトルを指定回数タップして、パスワードを入力して入ります。

機能一覧

機能	できること
QR発行	氏名・年齢・性別・備考などを登録し、個人QRを発行。画像保存・印刷可
QR再発行	紛失・再印刷時に、同じIDでQRを再発行（履歴を引き継ぐ）
スキャン	ライブカメラ、保存画像、撮影、手動貼り付けの4通りで読取
世帯管理	世帯ID・世帯名・世帯内の関係を設定。世帯ごとの在所・外出・退所数を表示
避難者の状態表示	在所中／一時外出中／正式退所済みを人数で確認
ブース参加・物資受取	相談ブースへの参加、水・食料・ミルク・オムツ等の受取を専用ボタンで記録（1端末12個まで）
集計・グラフ	期間・会場・端末で絞り込み。時間帯別・月別・曜日別・属性別
印刷・PDF	集計レポート、世帯一覧、QRカードを印刷／PDF保存
CSV出力	記録、世帯・状態をCSVで保存
CGI避難者データ出力	避難者HXL CSV、共通メールTXT（ZIP）を出力
バックアップ・引き継ぎ	JSONで端末データを保存し、新しい端末へ移行

7. TinyBoxと組み合わせると何が変わるか

ちゃっと入退場は、記録をWebxdcの更新メッセージとして同じチャットに送ります。つまり、グループ内で記録が揃う土台は、チャットの通信路です。TinyBoxを使うと、その通信路が避難所内に閉じて用意できます。

	紙の名簿	一般的なクラウド型の受付	TinyBox＋Delta Chat＋ちゃっと入退場
インターネット接続	不要	必要	不要（避難所内の通信のみ）
事前に必要なもの	紙・ペン	契約・アカウント・端末	TinyBox、Delta Chat、アプリの準備
複数受付の記録	分散しやすい	一元化できる	同じチャット内で共有できる
人数の集計	手集計	自動	自動（同期は即時ではない）
停電時	動く（筆記できる環境が必要）	端末・回線・サーバー側の備えに依存	サーバー・Wi-Fi機器・端末の予備電源が必要
運用の主体	現場	現場・導入団体（基盤の保守は提供者など）	地域・団体

通信が切れている間の動き

アプリは記録と未送信分を端末内に保存し、アプリ実行中に共有を再試行します。アプリからDelta Chatへ渡った後の配送はDelta Chatが担います。通信復旧後はアプリを開き、管理者端末で記録の受信を照合します。端末故障や保存失敗に備え、バックアップも必要です。

「共有待ち0件」は、全端末への到着保証ではありません。 アプリ側の送信待ちがなくても、Delta Chat側で配送を待っていたり、相手端末が未受信だったりする場合があります。

8. 自治体の仕組みとの住み分け

あくまで私見ですが、両者は競合せず、場面で使い分けるものだと考えています。

	自治体の公式の仕組み	本構成（自衛）
想定する主体	自治体・避難所運営の職員	住民・自治会・自主防災組織
主な使い方	公式の避難所の受付・集計	職員が来られない避難所、公式の外にある場所での受付
準備するもの	自治体が整備（アプリ、カードリーダーなど）	地域が平時に準備（TinyBox、Delta Chat、訓練）
個人情報の扱い	自治体の規程に基づく	地区のルールを決めて運用
運用の安定性	自治体が運用・保守	地域の担当者に依存

自治体の取り組みが整った地域では、そちらを優先するのが自然です。本構成は、公式の仕組みが届くまでの空白期間、または届かない場所を埋めるものであり、のちに職員や支援団体が到着したときは、CSVや集計レポートを渡して引き継ぐことを想定しています。

9. 運用シナリオ（想定）

実機での大規模な運用確認ではなく、想定シナリオです。

事前準備（平時）

TinyBoxを設置し、Delta Chatのアカウントを受付担当者・管理者の端末に設定する
受付用グループを作り、.xdcを送る
各管理者端末で管理パスワードを変更する（後述）
会場（体育館、教室など）を登録する
端末ごとに名前（例：北口受付A）と会場、利用モード（避難所用）を設定する
必要な範囲で人物情報を事前登録し、個人ごとのQRを平時に発行・配布する（登録情報の保管・更新と、各端末への同期も確認します）
訓練で一度、QR発行からスキャン、集計までを通す

岸和田市の実験では、マイナンバーカードは平均9秒、QRコード方式は平均1分45秒、手書きは平均1分10秒と報告されています。ただし、手書きは職員のシステム入力まで含み、方式ごとに参加者構成や計測範囲も異なります。これはその実験条件での結果で、本アプリの受付時間や方式一般の優劣を示す数値ではありません（岸和田市の実証結果）。本構成でも初回の人物入力と登録済みQRの読取を分けて計測し、事前登録の効果を確かめます。

発災後の受付

避難してきた人の氏名・年齢などを登録し、QRを発行して渡す（事前登録済みならスキャンのみ。家族は世帯としてまとめる）
入所時にQRをスキャンして「入所」を記録
買い出しや様子見で出かけるときは「一時外出」、戻ったら「帰所」
他の避難所や自宅へ移るときは「正式退所」
管理者は「避難者・世帯」画面で、在所中・一時外出中・正式退所済みの人数を確認する
水や食料の配布時に「物資受取」ボタンでQRをスキャンし、配布を記録する

自治体・支援団体が到着したとき

管理者端末からCSVや集計レポート（印刷・PDF）を出力できます。また、避難者データをCGI向けの形式（HXL CSV／メールTXT）で出力する機能があり、esbbs.cgiなどの避難者掲示システムへの取込用データを作れます。CGIへの自動送信はしません。 書き出したCSVをCGI側の取込画面で読み込む手順です（章6の操作デモの後半が、その流れです）。公開検索対象にするチェックは初期状態でOFFです。このチェックは出力対象者全員に適用され、アプリが本人別の許諾を自動判別するものではありません。ONにする場合は、出力対象者全員の公開許諾を確認し、対象を絞って出力します。CGI本体は今回確認した添付アプリに含まれないため、設置版で取込・公開表示を確認します。

平時の訓練・イベントでの利用

イベント用モード（入場・退場）があるため、平時の受付にも使えます。平時に使い慣れておくことが、いちばん効く備えです。

場面	使い方（想定）
防災訓練	参加者のQR受付、避難所用モードでの入所〜退所の通し練習
地域イベント・学園祭	来場者の受付と、時間帯別・日別の来場者集計
屋外イベント	ネット接続が不安定な環境での受付（TinyBoxを会場に持ち込む）
地区の備え	世帯情報でひも付けた、家族一人ひとりのQRを事前に作って配布しておく

10. 情報の扱いと運用上の注意

避難者の氏名・年齢などの個人情報を扱うため、ここは特に重要です。

個人情報の範囲

QRに埋め込むのは来場者IDのみで、氏名・住所・電話番号などは含めません。ただし、IDは人物情報と照合できるため、QRカードも管理対象として扱います
ただし、登録情報（氏名・年齢・性別・備考など）は、同じチャットのグループ参加者に共有されます。受付用グループには、必要な人だけを入れてください
近所の人同士で名簿を扱うことになるため、平時に「誰が見られるか」「何を備考に書くか」「どう保管し、いつ消すか」を地区のルールとして決めておいてください
備考欄に健康状態などの配慮事項を入れる場合は、本人の同意を得て、扱う人を絞ってください。自治体や支援団体へ引き継ぐときは、先方の個人情報の取扱いルールに従ってください
JSONバックアップやCSVには個人情報が含まれます。保存先と共有先を確認してください

管理者の設定

管理パスワードの初期値は secret です。 端末内の設定なので、各管理端末で運用前に変更してください
管理画面の入口は「タイトルのタップ回数」でも変えられますが、これは安全な認証の代わりにはなりません
管理モードは操作画面を分ける機能です。共有データを管理者だけに秘匿する仕組みではないため、グループ参加者を必要なスタッフに限定します
管理者端末の役割は、受付担当と分けて決めておきます

QRの扱い

QRを再発行しても、紛失したQRは無効になりません。拾った人が使える可能性があるため、QRカードの管理に注意してください
カメラが使えない場合に備え、保存画像・撮影・手動貼り付けの代替手段があります。Androidでは、Delta Chatのカメラ権限を事前に確認してください

11. 限界と注意点

同期は即時ではありません。 アプリ側の「共有待ち0件」でも全端末への到着を保証しません。復旧後は受信側で記録を照合してください
単一のTinyBoxをメール配送に使う構成では、その停止中は端末間の更新共有が止まります。 電源も必要です
自治体の本部などへの自動連携はありません。 引き継ぎはCSV・レポート・CGI向けデータを手動で渡す形です
記録上の状態であり、点呼や安否確認の代わりではありません。 画面にも「点呼・安否確認と照合してください」と表示されます
避難者が自分のスマホで受付を完結させる機能はありません。 QRは氏名などを登録して発行し、受付端末でスキャンします。QRを持たない人の扱いは、運用で決めておく必要があります（紙の名簿との併用など）
要配慮者の専用項目はありません。 配慮事項は備考欄の自由記述になります
物資の在庫・受給資格・重複配布の自動判定はしません
共有の単位は「同じメッセージのアプリ」です。 送り直したアプリや新バージョンは別の共有場所になります。移行にはJSONバックアップを使います
端末のストレージ容量に依存します。 容量不足の警告が出たら、バックアップを保存してください
CGI出力は、同じCSVを繰り返し取り込むと重複します（CGI側に重複除去がないため）
地域側の準備と訓練が前提です。 TinyBoxの構築、Delta Chatの設定、担当者の育成は、平時に地域で行う必要があります
TinyBoxと複数実機の組み合わせ、カメラ対応、大人数での性能、連続稼働時間は本記事では未検証です。
端末の時計をそろえてください。 履歴は時刻を含めて並ぶため、大きな時計のずれは状態の判断に影響する可能性があります
「すべての記録を削除」は完全消去ではありません。 共有履歴の表示対象から記録を除外する処理であり、過去の通信データ・端末保存・出力ファイルまで消すものではありません
Wi-Fi機器は技適取得品を使ってください

12. どんな場面で価値が高いか

**発災直後から数日の「空白期間」**に、準備済みの運営班が受付を回す場面
自治体職員が駆けつけられない避難所での自主運営
孤立しやすい地域での初動と、公的なシステムがつながるまでのつなぎ
自治体の仕組みの外にある場所（自治会館、公民館、民間施設、自主的に開設された避難場所）での受付
訓練できるグループ（自治会、防災班、学校、公民館など）での運用

逆に、自治体の公式の仕組みがすでに使える場面や、事前準備がない場合は、メリットは小さくなります。「万能の解決策」ではなく、訓練しておけば、手が届かない場面の初動で効く一案と位置づけています。

13. 今日からできるチェックリスト

お住まいの自治体の避難所受付の仕組み（防災アプリ、マイナンバーカード等）を確認する
Delta Chatを入れて、受付用グループを作ってみる
.xdcをグループに送り、QRの発行とスキャンを試す
家族を「世帯」にして、入所→一時外出→帰所→正式退所を一度通してみる
各管理端末の管理パスワードを secret から変更する
集計レポートとCSV出力を試す
訓練終了時・担当交代時・重要な登録後など、更新量に応じてJSONバックアップを保存し、予備端末で復元を試す
外部回線を切り、TinyBox内で通常チャットとアプリ更新が届くか確認する
受付端末の切断・再接続後に記録を照合する
サーバー・Wi-Fi機器・受付端末を含めて、必要な時間だけ電源で動かせるか実測する
地域で導入するなら、「誰が管理者か」「不在のときは誰か」「QRを持たない人をどうするか」を決めておく
個人情報の扱い（誰が見るか、何を書くか、いつ消すか）を地区のルールとして決める
自治体や防災担当に、地区の自主的な取り組みとして相談しておく

箱舟プロジェクトが目指す未来

災害時に本当に必要なのは、単に「通信できること」ではなく、必要な情報を、必要な人に、分かりやすく届けることです。地図による状況共有に加えて、避難所の受付という「人の把握」も、自治体の手が届かない場面で、地域コミュニティ自身が運用できる形にしていきたいと考えています。

試験運用に協力していただける自治会・防災組織の方や、ご意見・ご指摘をお寄せいただける方を探しています。コメントやフィードバックをお待ちしています。