機能を作るだけではなく、災害時の「情報が届くか」を測るためのアプリ開発

写真交換アプリとトランシーバ型アプリは、単なる便利ツールではない。通信インフラが弱い、壊れる、混雑する、届かないという状況で、どこまで人と人をつなげられるかを検証するための小さな実験装置である。

1. 出発点：災害時に本当に困るのは「情報の空白」である

大規模災害では、道路、電気、水道だけでなく、通信も同時に傷む。スマートフォンは手元にあっても、基地局が止まる、回線が混雑する、停電でルータが落ちる、避難所のWi-Fiが足りない。つまり、端末はあるのに情報が届かないという状態が起きる。ここに、デジタル技術の本当の課題がある。

防災アプリというと、避難所マップ、安否確認、防災クイズ、備蓄リストなどが想像されやすい。もちろんそれらも重要である。しかし、さらに根本にある問いは「そもそも通信できるのか」である。どれほど優れたアプリでも、サーバに接続できない、画像が送れない、位置情報が伝わらない、近くの人に助けを求められないのであれば、災害時には絵に描いた餅になる。しかもその餅は、停電すると表示すらされない。ここは笑いごとではない。

そこで、現在弊社で開発しているシステム・アプリ群は、個別機能の完成だけを目的にしていない。写真を交換できる、声を送れる、端末同士が近距離で接続できる、データを軽くして送れる、相手の同意を確認してから受け渡す。これら一つひとつを、災害時の情報伝達ベンチマークとして扱う。平常時には遊びや学習に見える機能でも、非常時には「誰が、どこで、何を見たか」「助けが必要か」「現場に危険があるか」を伝える基礎技術に変わる。

2. 例1：写真交換アプリが持つ意味

写真交換アプリは、近くにいる相手とお気に入りの写真を交換するアプリとして公開している。iOS版とAndroid版があり（下にリンクあり）、Android版の説明では、アカウント登録なし、メールアドレスや電話番号なし、Bluetoothによる端末間の直接交換、サーバへアップロードしないこと、iPhone版との交換対応などを特徴としている。iOS版も、近くにいる友だちと写真を交換し、受け取った写真を自分のアルバムで楽しむアプリとして掲載されている。

平常時の見え方

子どもや家族が、近くの人と写真を見せ合い、双方が納得した写真だけを交換する。サーバに預けず、端末同士で完結するため、個人情報を大きく集めない設計にしやすい。

防災技術としての見え方

通信回線に依存せず、現場で撮った画像を近くの端末へ渡す練習になる。瓦礫、道路寸断、浸水、火災、避難所の混雑、要救助者の位置などを、低容量化して人づてに運ぶ可能性がある。

重要なのは、写真交換の目的を「写真を送れた」で終わらせないことである。どれくらいの距離で接続できるか。屋内、屋外、人混み、避難所、地下、学校、体育館で成功率は変わるか。画像サイズを落とすと、どの程度まで内容が判別できるか。交換にかかる時間は何秒か。相手の端末OSが違っても成立するか。子どもや高齢者でも操作できるか。誤送信を防ぐために、相互承認のUIは必要か。これらはすべて、災害時の情報伝達能力を測る指標になる。

たとえば、災害直後にインターネットが不安定でも、近くの人に画像を渡せるなら、情報は完全には止まらない。さらに、その画像を受け取った人が別の場所へ移動し、次の人に渡せば、データは人の移動とともに運ばれる。これは高速通信ではないが、ゼロよりは圧倒的に強い。災害時には、完璧な通信網よりも「細くても切れない経路」が命を救うことがある。

3. 例2：トランシーバ型アプリが持つ意味

もう一つの例が、現在開発中のトランシーバ型アプリである。これは、音声をリアルタイムまたは準リアルタイムで近距離に届けるための試作・検証対象である。一般的な通話アプリは、インターネット接続、アカウント、クラウドサーバ、通知サービスに依存しやすい。しかし、災害現場ではこの前提が崩れる。だからこそ、近距離で直接つながる音声伝達の検証には意味がある。

音声は、写真やテキストとは違う強みを持つ。手がふさがっていても使える。文字入力が難しい人でも使える。緊急度や感情が伝わる。視界が悪い場所でも、短い呼びかけだけで方向感を共有できる。救助や避難誘導では、「右に行って」「ここにいる」「水が来ている」「子どもがいる」といった短文音声が価値を持つ。

一方で、音声は帯域を消費しやすく、接続が不安定だと途切れやすい。だから、ベンチマークとしては厳しい。つまり、トランシーバ型アプリが動く条件を把握できれば、画像、短文、位置情報のような軽いデータの設計にも応用できる。音声で駄目ならテキストへ落とす。テキストが駄目なら定型メッセージにする。定型メッセージも駄目なら、数ビットの状態信号にする。防災に必要なのは、豪華な機能ではなく、状況に応じて通信量を落とせる設計である。

4. 本質は「アプリ」ではなく「通信の生存性」を測ること

この取り組みの本質は、アプリストアに並ぶアプリの数を増やすことではない。むしろ、災害時に情報伝達がどこで失敗するかを、実際に動くアプリで測ることにある。机上の構想だけでは、通信距離、接続時間、失敗率、電池消費、操作ミス、OS間の差、端末性能差は見えない。小さくても実装し、実地で試すことで、初めて現実の癖が見える。

検証項目	見るべき内容	防災上の意味
接続成立率	Bluetooth、Wi-Fi Direct、ローカルWi-Fi、将来的なLoRa等で、何回中何回つながるか。	「使えるはず」ではなく「何割使えるか」を把握する。
伝送時間	画像、音声、短文、位置情報の送受信にかかる時間。	緊急情報として成立する速度かを判断する。
低容量化	画像解像度、圧縮率、サムネイル、音声品質をどこまで落とせるか。	混雑時・低速時でも最低限の情報を残す。
人づて転送	端末から端末へ、複数回の受け渡しが可能か。	通信圏外でも、移動する人を情報の運び手にできる。
操作の単純さ	子ども、高齢者、疲労状態の人でも迷わず使えるか。	非常時に説明書を読む余裕はない。

5. アドホックネットワークと「ばらまき型」の安価な装置

次の段階で重要になるのが、アドホックネットワークと、ばらまき型の安価な中継装置である。アドホックネットワークとは、固定の基地局や中央サーバに依存せず、端末同士がその場でつながるネットワークである。災害時には、普段の通信インフラが止まる前提で、スマートフォン、安価な無線ノード、モバイルバッテリー、太陽光電源、避難所の簡易ゲートウェイなどを組み合わせる必要がある。

「ばらまき型」という言い方は少々乱暴だが、現場感覚としては正しい。高価な専用装置を数台だけ持つより、安価な中継ノードを多数配置できるほうが強い場面がある。橋、学校、避難所、公民館、消防団詰所、町内会倉庫、移動車両、ドローン、徒歩の見回り隊。こうした場所や人に小さなノードを持たせれば、面としての通信路が生まれる可能性がある。

もちろん、スマートフォンだけですべてを解決できるわけではない。Bluetoothは距離が短い。Wi-Fiは消費電力や設定が課題になる。LoRaは長距離に強いが帯域が細い。衛星通信は強力だがコストや端末配備が問題になる。だから単一技術で勝負するのではなく、近距離はBluetoothやWi-Fi、中距離・低容量はLoRa、外部接続は衛星や復旧したインターネットへ橋渡しする、という階層構造が現実的である。

6. 海外の関連事例

この考え方は、海外にも複数の先行例がある。完全に同じものではないが、通信インフラが壊れたときに、端末同士、低電力無線、メッシュネットワーク、オープンソースを使って情報伝達を維持しようとする方向性は共通している。

Meshtastic

LoRa無線を使い、携帯基地局やインターネットなしで低電力・分散型のメッシュ通信を行うオープンソースプロジェクト。スマートフォンと小型ノードを組み合わせ、主に短文や位置情報の共有に向く。

Serval Project

通常のAndroid端末を使い、携帯通信やインターネットがない状況でも、ピアツーピアで音声、テキスト、データ通信を行うことを目指した研究・開発プロジェクト。

Briar

中央サーバに依存せず、インターネットが使えない場合でもBluetooth、Wi-Fi、メモリカード経由でメッセージを同期できるメッセージングアプリ。危機時の情報共有を強く意識している。

Project OWL / ClusterDuck

災害後に安価な無線ノードを配置し、周辺のノード同士でメッシュネットワークを作る構想。Linux Foundationによるオープンソース化の発表もあり、災害時の通信確保を明確な目的にしている。

goTenna

モバイルメッシュネットワークや衛星との組み合わせにより、災害対応や人道支援の現場での接続性を支える製品群を展開している。

Sahana / WFP ETC

Sahanaは災害・人道支援のためのオープンソース情報管理基盤であり、WFPが主導するEmergency Telecommunications Clusterは災害時に通信とインターネット接続を提供する国際的な枠組みである。

これらの事例から分かるのは、災害時通信の世界では「大きな中央システム」だけでは足りないということである。現場に残る小さな端末、安い無線機、ローカルネットワーク、人の移動、紙の情報、音声、画像、位置情報を組み合わせる必要がある。言い換えると、防災のデジタル化とは、巨大なシステムを一つ作ることではなく、壊れてもなお残る小さな経路を多数用意することである。

7. 今すぐ実現できる可能性

この分野は、未来の夢物語ではない。スマートフォンはすでに普及している。Bluetooth、Wi-Fi、位置情報、カメラ、マイク、圧縮処理、ローカル保存、QRコード、NFC、簡易暗号化、オフラインUIは、今ある技術で実装できる。LoRaや小型マイコン、太陽光電源、モバイルバッテリーも安価に入手できる。問題は、技術がないことではなく、それらを災害時の運用に合わせて組み直し、試験し、失敗条件を把握することである。

写真交換アプリとトランシーバ型アプリは、その入口になる。写真を送る、声を届ける、近くの端末とつながる。これらは一見すると小さな機能だが、災害時には「現場の情報を外へ出す」「避難者同士をつなぐ」「孤立した人の存在を伝える」「救助対象の状態を共有する」ための基礎になる。特に、子どもや地域住民が平常時から使える形にしておけば、非常時だけ突然使わせるよりも定着しやすい。

防災技術は、普段から使われていなければ本番で使われない。非常袋の奥で眠る機器は、いざという時に電池が切れている。アプリも同じで、年に一度の訓練だけでは弱い。遊び、学習、地域活動、写真交換、見回り、イベント運営など、平常時の用途に溶け込ませることで、災害時に自然に使える可能性が高まる。

8. 今後の展開案

今後は、アプリ単体ではなく、通信ベンチマークの測定基盤として整備していくことが重要である。たとえば、接続方式ごとに成功率を記録する。画像サイズ、送信時間、失敗回数、距離、端末種別、OS、電池残量、屋内外、障害物の有無をログ化する。結果を可視化し、どの条件なら使えるかを判断する。これは、単なるアプリ改善ではなく、地域ごとの防災通信設計に使えるデータになる。

さらに、安価な中継ノードを使った実験も考えられる。避難所に小型ゲートウェイを置く。町内にLoRaノードを置く。移動する見回り隊が端末を持つ。学校や公民館を一時的な情報集約点にする。インターネットに接続できる場所が一つでもあれば、そこから外部へ必要最小限の情報だけを出す。逆に外部からの警報や支援情報を、ローカル網へ配る。これができれば、通信の完全復旧を待たずに、地域の情報インフラを仮復旧できる。

最終的な目標は、災害時に「誰かがどこかでつながっている」状態を作ることだ。すべての人が常時高速通信できる必要はない。助けを求める一文、危険を知らせる一枚、現在地を示す一点、無事を伝える一言が届けばよい場面は多い。高機能であることより、壊れにくいこと。美しいUIより、迷わず押せること。大容量より、必要最小限が届くこと。ここを間違えないことが、防災とデジタル技術を結びつけるうえで最も大切である。

9. まとめ

写真交換とトランシーバは、単なるアプリではない。災害時に情報が届くかを測るための、現実に動くベンチマークである。通信手段が失われたとき、人命救助や避難支援に必要なのは、巨大で完璧なシステムだけではない。近くの端末、安価な中継装置、アドホックネットワーク、人の移動を組み合わせた、しぶとい情報伝達の仕組みである。今ある技術で、すぐに試せる。すぐに失敗できる。すぐに改善できる。防災においては、この「小さく作って、現場で鍛える」姿勢こそが強い。