ブラウザ優先・オフラインデータサービス デモ
January 2026
実運用に耐える非常時アドホックネットワーク では、多くの MANET システムがルーティング以外の理由で失敗していることを指摘した。スマートフォンは制限され、利用者は事前準備がなく、アプリ、特殊な Wi-Fi モード、事前設定を前提とした設計は障害時に破綻する。本稿は、実際に動作する反例を記録する。準備のない人が市販状態のスマートフォンを用いて、電源の入った装置に即座に接続し、完全にオフラインのまま有用な情報を交換できるかを問う。
このデモが行うこと
このシステムは小型の OpenWrt ベースのノード（Raspberry Pi 4B）上で動作する。電源投入時に、カスタムの senzuru イメージを SD から起動し、ファイルシステムを拡張し、SENZURU という SSID を告知する Wi-Fi アクセスポイントを立ち上げる。
近くの任意のスマートフォンがネットワークに参加すると、自動的にキャプティブポータルへリダイレクトされる。そのポータルは、次の二つのブラウザベースのサービスを提供する。
- リアルタイムのチャットインターフェース
- ピン、アイコン、コメントを備えた対話型地図
インターネット接続、アカウント、アプリのインストールは不要である。更新は接続中の全利用者に即座に反映される。現段階では、意図的に単一ノード構成としている。マルチホップのルーティングや長距離バックホールはまだ存在しない。目的は、オンボーディング、操作性、有用性――多くのシステムが十分に検証しない層――を検証することにある。
単一ノードから始めて十分な理由
非常時ネットワークの議論は、しばしばトポロジーから始まる。カバレッジ半径、ホップ数、スループットといった話題だ。しかしそれは、利用者の課題がすでに解決されていることを前提としている。人々がネットワークを発見し、迅速に参加し、数秒以内に情報を交換できなければ、ルーティング性能は意味を持たない。単一ノードで、次を検証できる。
- インストール不要のアクセス
- ブラウザ優先の操作
- オフライン動作
- 即時の有用性
マルチノード化はノード間のデータ移動を変えるが、人がノードとどう関わるかは変えない。ここで示すスマートフォン側の体験は、将来のマルチホップネットワーク上でも変更せずに動作させることを意図したデータ層デモである。後続の相互接続デモでも、本デモを参照用のサービス層として引き継ぐ。
正しいメンタルモデル
各ノードは、ポケットサイズの Wi-Fi ルーターのように振る舞う。スマートフォンは通常の Wi-Fi でローカル接続し、常にクライアントであり続ける。中継やメッシュへの参加は行わない。
長距離接続――サブ GHz リンク、Wi-Fi HaLow、有線バックホール――はノード間のみに存在する。スマートフォンはローカルに留まり、リレー処理はノードが担う。この役割分離により、一般的な設計上の誤りを回避できる。
利用者が実際に目にするもの
Wi-Fi ネットワークに参加すると、スマートフォンの OS が自動的にキャプティブポータルを起動する。画面には二つのタブが表示される。
これらの負荷は、ストレス下でも即座に理解できる挙動を持つため選ばれている。説明なしで、同期、更新伝播、競合といった性質を露出させる。
スマートフォン（iOS）
キャプティブポータル内のリアルタイムチャット。
ピンとコメントを備えた地図表示。
デスクトップ（macOS）
デスクトップブラウザで表示される同一のチャット UI。
ローカルに描画された同一の地図 UI。
データ層について
チャットと地図は例示であり、システムの境界ではない。ノードの視点では、いずれもローカルで動作するデータサービスにすぎない。
基盤となるストレージおよび同期層は、ペイロードの種類に依存しない。メッセージ、地図注釈、チェックイン、センサー値はいずれも同じ扱いを受ける。マルチノード構成では、これらは構造化されたデータ単位となり、ポリシーと利用可能な容量に応じてキューイング、転送、フィルタリング、破棄が行われる。
このデモは、理解しやすい一つの負荷を示すものであり、アーキテクチャの限界を示すものではない。
カスタムデータ層と運用者の制御
ここで示すサービスは デモ用の負荷 であり、必須のアプリケーション表面ではない。実運用のネットワークを展開する運用者は、データ層やサービス群を自由に置き換えられる。ノードはチャット、地図、特定の UI を要求しない。クライアントに対して、何らかのサービスがローカルに公開されていればよい。
想定される展開例には、次が含まれる。
- 運用目的に特化した事前インストール済みアプリケーション
- 資格情報、証明書、端末識別により制御される認証付きサービス
- ローカルポリシーに合わせたデータモデルおよび同期規則
- センサー取り込みやメッセージ搬送などの非対話型サービス
エンドユーザーのアクセスと運用者の制御は設計上分離されている。キャプティブポータルは、普遍的な初回接触を保証する。サービス設定、資格情報管理、ルーティングポリシー、データ保持といった管理操作は、公開 UI には露出しない。
このデモは、準備のない利用者に対して必ず動作すべき条件を示すものであり、準備された運用を制限しない。
ATAK と TAK エコシステムについて
Android Team Awareness Kit（ATAK）および TAK エコシステム は、非常時・アドホックネットワークがすでに解決されている証拠として挙げられることがある。重要な参照点であり、本稿のアプローチと両立可能である。
TAK は、準備された利用者を前提とする。訓練を受け、事前にアプリを導入し、管理された端末と確立された資格情報を持つ運用者である。その前提の下で、切断や制約のあるリンク上でも高度な状況認識とデータ交換を提供する。
本稿で示すブラウザ優先の層は、準備のない端末との初回接触を対象とする。市販のスマートフォンで動作する発見性、ローカルアクセス、最小限のデータ表面を提供する。実運用では、同一ノード上で両者は衝突せずに共存できる。
実運用でブラウザ優先が成立する理由
このデモは、先行記事の次の主張を検証するために存在する。
障害時において、キャプティブポータルのブラウザは唯一の普遍的なアプリケーション面である。
この主張は成立する。主要なモバイル OS はキャプティブポータルを検出し、自動的にブラウザを起動し、利用者教育なしで基本的な操作を許可する。
一方、事前インストールアプリ、バックグラウンドサービス、特殊な Wi-Fi モード、OS レベルのルーティング権限に依存する手法は、管理環境外では脆弱である。このデモが機能するのは、プラットフォーム制約を回避するのではなく、それを前提としているからだ。
主インターフェースとしてのキャプティブポータル
キャプティブポータルは煩雑な層として扱われがちだが、オフラインシステムでは、準備のない端末に確実に存在する唯一の対話面である。
インターネット接続のない市販スマートフォンにおいて、次の経路は信頼できる。
- Wi-Fi ネットワークに参加する
- OS にキャプティブポータルを検出させる
- ローカルの HTTP ページで操作する
この挙動は、ホテル、空港、公衆ネットワークで必須とされているため存在する。キャプティブブラウザは制限があるが、テキスト入力、簡易 UI 状態、基本的な JavaScript は一貫して動作する。
いくつかの一般的な手法は、オフライン条件では成立しない。自己署名証明書を用いた HTTPS は警告を表示し、利用者の明示的な操作を要求する。PWA や Service Worker は HTTPS を前提とする。アプリストア経由のインストールは、ベンダー基盤と接続性を必要とする。
そこで本システムは、次の線を引く。
- 普遍的アクセス: キャプティブポータル経由の平文 HTTP、事前準備なし
- 任意の拡張: 信頼済み証明書、HTTPS、PWA、より高度な UI（準備された端末向け）
高度な機能が、基本的な参加を妨げることはない。
ノード接続時に変わること
将来ノード同士が接続されると、メッセージや地図更新は複数ホップを通過する。遅延や帯域制約が顕在化し、転送されるデータを制限するポリシーが必要になる。
変わらないのはスマートフォン側の体験である。端末は引き続きローカル接続し、キャプティブポータルの流れも同一で、UI の挙動も変わらない。無線トポロジーを持ち込む前に、使いやすさと展開性を検証できる。
補足
多くのメッシュ型ネットワークプロジェクトは、想定利用者が実際に使えないまま消えていく。このデモは、ルーティング、カバレッジ、規模での容量を解決すると主張しないが、前提条件を示す。
インストール不要の参加は成立する。オフラインサービスは即座に役立つ。ブラウザ優先のアプローチは、実際のプラットフォーム制約に耐える。これらが欠ければ、どれほど高度なネットワークでも意味を持たない。
今後の記事では、ノード間リンクとデータ移動を扱う。本稿は、拡張前に機能する基準点を確立する。