9年ぶりに福岡市向け防災マップアプリを更新した話

01そもそも、なぜ防災マップアプリを作ったのか

きっかけは、2016年の熊本地震でした。福岡は直接被災エリアではありませんでしたが、 あの経験で「自分が住む街の防災情報を、スマートフォン一台で確認できる手段が思ったより整っていない」 という事実を改めて認識しました。

行政が公開しているハザードマップはPDFや紙が中心で、いざというときに使いにくい。 浸水想定区域・土砂災害警戒区域・避難所の位置を地図上で重ねて確認できるアプリが、 地元の人間の手で作れるなら作るべきだ——そう考えて着手したのが最初です。

商業的な狙いはほとんどありませんでした。「福岡市に住む人が、災害時に正確な情報を持って 動ける手助けができれば」という、ごく単純な動機です。 その後、2016年の防災減災アプリコンテストでBousaixTech賞をいただいたことで、 「作り続ける意義がある」という確信が少し深まりました。

029年間で、iOSエコシステムはまったく別物になった

9年前のコードを開いたとき、まず感じたのは「懐かしさ」より「遠さ」でした。 当時のSwiftは1.xから2.x過渡期。Objective-Cとの混在も当然で、 ARCが普及して間もない時代です。クロージャの書き方も、エラーハンドリングの設計も、 今とは相当異なります。

特に変化が大きかったのは次の領域です。

SwiftUIへの移行は、UIKit主体の既存コードをどこまで残すかという判断が必要でした。 全面書き直しは理想ですが、防災アプリとして動き続けていることの方が重要です。 今回は「完全リライトよりも、確実に動く状態でモダン化する」方針を選びました。

古いコードに触れながら、「当時なぜこう書いたか」を思い出せる部分と、 「なぜこうしたのかまったく思い出せない」部分があります。 9年前の自分へのコメントは、一行も残っていませんでした。 それは純粋に反省点です。

03地図アプリ特有のメンテナンス課題

一般的なアプリと比べて、地図・GIS系アプリのメンテナンスには特有の難しさがあります。 単にコードを更新すればいいのではなく、データレイヤーの管理が常に絡みます。

マップタイルの管理問題

現在のアプリは、行政が公開している避難所データをJSONで保持し、 MapKit上にマーカーとして表示する構成が中心です。 浸水想定区域・土砂災害警戒区域のようなハザードレイヤーをラスタータイルとして オーバーレイ表示する機能は、今後実装すべき課題として残っています。

GISデータの変換・配信パイプラインの構築は、地図系アプリのメンテナンスにおいて 最も工数がかかる部分のひとつです。行政データのフォーマット（Shapefile・GeoJSON・ 国土交通省独自形式など）は提供元・年度によってまちまちで、 自動変換が難しいケースが多く発生します。 このパイプライン整備は今回の更新では着手できておらず、次フェーズの課題です。

オフライン動作の考え方

防災アプリにとって、オフライン動作は単なる「あると便利」ではなく、 本来の意義に直結する要件です。大規模災害時には通信インフラが寸断されることがあります。 その状況下でアプリが何も表示できなければ、存在価値がありません。

しかしオフライン地図タイルのキャッシュはストレージを大量に消費します。 福岡市全域をカバーするタイルを複数ズームレベルで保持すると、 数百MBに達することもあります。ユーザーのデバイスストレージを圧迫しすぎない範囲で、 どの地域・どのズームレベルをキャッシュするか——このトレードオフは今回も判断が難しい箇所でした。

地名・行政区画の変化への対応

9年の間に、町丁目レベルの地名変更や住居表示の整備が行われています。 Apple Mapsのデータ品質は2016年当時と比べて大幅に改善されており、 日本の地名精度も向上しています。一方で、行政が提供するGISデータの座標系（JGD2011など）との 整合性を常に確認する必要があります。 「地図の上でズレている」というフィードバックは、ユーザーの信頼を直接損なうため、 精度の検証は省けない工程です。

04今回のアップデートで実際に取り組んだこと

「9年ぶりの大幅更新」とは言っても、劇的な新機能追加よりも、 「正しく・速く・長く動き続けるために必要な整備」の比重が大きいアップデートです。

05レガシーシステムのリビルドから学んだこと

9年前のコードを読み解きながら、いくつかのことを考えさせられました。

「全部書き直したい衝動」と戦う

古いコードを見ると、書き直したくなります。これはエンジニアとして自然な反応ですが、 ほぼ常に危険なシグナルでもあります。当時のコードが「なぜそうなっているか」を理解しないまま 書き直すと、見えていなかった暗黙の仕様を壊す可能性があります。 今回は「動いている部分に触れない」原則を徹底しました。

シンプルな設計が長生きする

9年前の設計判断のうち、今でも問題なく機能しているものは、 概ねシンプルな構造のものでした。特定のサードパーティライブラリに深く依存した部分は 軒並みメンテナンスが困難になっており、純粋なAppleフレームワークのみで書かれた部分は 今も手を入れやすい状態を保っていました。 「依存を増やすことのコスト」を9年というタイムスパンで目の当たりにした感覚があります。

技術的負債の「利息」は静かに積み重なる

9年間で積み重なった技術的負債の総量は、想定より大きいものでした。 しかし重要なのは、そのほとんどが「当時の最善」だったということです。 技術的負債とは、未来の知識を過去に持ち込むことができなかった結果であり、 誰かの怠慢ではありません。だからこそ、今の判断も9年後に評価されることを意識して、 今回は変更箇所に十分なコメントと意図の記録を残しました。

06防災アプリを維持し続けることの意味

率直に言えば、防災マップアプリは商業的に成功するプロダクトではありません。 有料課金には馴染みにくく、広告モデルも防災という文脈に合わない。 ダウンロード数も、一般的なエンタメアプリとは比べ物になりません。

それでも続けているのは、「使われる場面」を想像するからです。 このアプリが最も必要とされるのは、平和な日常ではなく、 台風が接近している夜や、地震直後の混乱した時間帯です。 そのとき正確な情報を届けられるかどうかが、アプリとしての価値のすべてです。

地域コミュニティ向けの技術は、スケールを求めるものではありません。 「福岡市に住んでいる人が、ちゃんと使える」——それだけで十分です。 そういう範囲の問題を解くことに、エンジニアリングは確かに役立ちます。

07振り返りと今後の方針

今回の更新作業を通じて、「9年間このアプリが動き続けた」という事実を改めて認識しました。 大きな障害もなく、Apple Storeからリジェクトされることもなく、 ユーザーの手元で機能し続けていたのは、初期設計のシンプルさと、 細かな対応を続けてきた積み重ねのおかげです。

今後の方針としては、年に1〜2回のデータ更新サイクルを維持しつつ、 Appleが新しいMapKit機能を提供するたびに段階的に取り込む形で進めます。 大きな設計変更は最小限にとどめ、「確実に動く状態」を第一優先に置きます。

防災DXという文脈では、行政との連携やオープンデータの活用も今後の課題です。 福岡市がリアルタイムの避難情報APIを整備する動きがあれば、 それとの統合も視野に入れています。ただし、複雑にするほど壊れやすくなる—— このトレードオフは、今後も意識し続けます。