オフラインでも動くGovTech：つながらない人を起点にしたデジタル行政設計

どうも〜おかむーです！今日は“オフラインファースト”なGovTechの話をザクッとまとめますよ〜

• ネット接続が不安定／低速な地域でも機能する設計が、真の包摂を生む
• 技術的にはPWA、Service Worker、ローカルDB、SMS/USSDなどの組合せが鍵
• 日本では災害対応と高齢者対応を軸にオフライン対応を標準化すべき

結論

オンラインだけを前提にした行政サービスは、見えない住民を生む。2034年に向けたGovTechの成長（WEFは公共価値で9.8兆ドルの可能性を示してます）を本当に全員に届けるなら、オフラインでの利用性・復元力を第一に設計するのが近道です。要するに「つながらない人を主語にする」ことで、サービスの信頼性と公平性が一気に上がるということです。

レポート本文

背景と世界の流れ

世界ではGovTechエコシステムが急成長中で、企業リスト（GovTech 100など）や地域別のブーム（アフリカのデジタル包摂の議論など）が目立ちます（参考：WEFのレポートやストーリー）。ただし成長の恩恵が偏らないようにするには、接続／端末の多様性に対応した設計が必要です。アフリカの議論で「レガシーを飛び越える」って話がありますけど、飛び越える先は“常時オンライン”じゃないんですよね。

オフライン・ファーストの具体技術パターン

• PWA + Service Worker

- ブラウザキャッシュでUIや申請フォームをローカル保存。数MBのアプリシェルで起動可能にする

• ローカルDB（IndexedDB / SQLite）

- 入力データを端末に保管、接続復帰時に差分同期。衝突はタイムスタンプやCRDT的手法で解決

• 軽量同期プロトコル

- バッチ送信、圧縮、部分的PUTを採用して低帯域でも送受信可能に

• フィーチャーフォン対応（SMS/USSD）

- フォールバック経路としてSMSで状態確認や手続き受付を実装

• QRコード / オフラインIDトークン

- 端末間・窓口間での証明を紙/画像ベースに残せるようにしておく

要するに、技術的には「キャッシュ」「差分同期」「代替チャネル」の3つを揃えれば現場で十分使えるサービスになります。

成功と失敗の事例（学び）

• 成功の要素

- 小さな機能での実運用→反復改善：現場での試験を重ねてUXを磨く

- 複数チャネルの併用：ウェブ、アプリ、SMS、窓口が連動する設計

• 失敗にしがちなパターン

- 「全部オンラインに統一して運用停止」→災害時や高齢者が置き去りに

- 同期の衝突やデータ整合性を後回しにして運用コストが膨らむ

日本への示唆（具体的アクション）

• 施策1：自治体向けの「オフライン設計テンプレ」を整備

- PWAテンプレ、IndexedDB同期ライブラリ、SMSゲートウェイの共通仕様を作る

• 施策2：災害対応の標準としてオフライン動作を必須化

- 避難所での申請や名簿管理をオフラインで扱えるようにする

• 施策3：高齢者・障害者のUX評価を導入

- 接続が悪い前提でのユーザビリティテストを必須化

• 施策4：中間事業者と協業して軽量APIを用意

- 大規模APIとは別に低帯域向けのエンドポイントを用意する

技術的にはクラウド＋エッジ（キャッシュノード）＋代替チャネルの三層で設計すれば、運用コストを抑えつつ信頼性を担保できます。

まとめ

つながらない人を起点にGovTechを作ると、結果的に全員に優しいサービスになります。接続性の不均衡は社会的な不平等につながるので、オフライン対応は“良心”ではなく“必須の技術要件”です。世界ではGovTechの市場や事例が増えているので（WEFの示す巨大な公共価値など）、日本も早めに実運用でのオフライン設計を標準化するといいですよね。

おかむーから一言

僕がシンガポールにいた頃、ちょっとした接続トラブルで役所のアプリが止まるのを見てゾッとしたんですよ。テクノロジーって、普通の人の日常を支えるもの。だからこそ、つながらない人を忘れない設計を一緒にやりましょう！