本文へスキップ
半農エンジニアラボENGINEERING × EVERYDAY

FIELD NOTE / 2026

富士山の降灰を時間で見る「HAIZU」を作った|Codexと進めた防災学習アプリ開発ログ

HAIZUのPC画面。Tephra2と簡易時間モデルによる仮定条件下の降灰分布

富士山が噴火したとき、風向きが変わると火山灰の広がりはどう変わるのか。噴火から時間がたつと、地図の上では何が見えてくるのか。そんな問いを、ブラウザで条件を動かしながら考えられるアプリを作りました。名前はHAIZU。コンセプトは「火山灰を、時間で見る。」です。

開発にはOpenAIのCodexを使いました。今回は、完成した画面を紹介しながら、実装したこと、作る途中で見直したこと、特に留意した点を残しておきます。AIにコードを書いてもらうだけで終わらず、計算の前提やスマホの使い勝手、本番での表示まで確かめる必要がある。そこが、このアプリを作るうえでの大きな学びでした。

HAIZU開発シリーズのご案内
この記事は完成画面と開発の全体像を紹介する、シリーズの入口です。設計と実装の考え方を、初心者向けに順番に解説していきます。

HAIZUは防災学習・参考情報のためのシミュレーションです。実際の噴火や降灰を予測するサービスではありません。以下の画面も、設定した仮定のもとでの表示例です。避難などの判断には、気象庁や自治体の公式情報を確認してください。

HAIZUをブラウザで開く / 使い方とシミュレーションの前提を見る

HAIZUでできること:富士山の降灰を地図と時間で見る

HAIZUは、富士山周辺の地図に降灰の分布を重ね、時間バーを動かして累積降灰の変化を見るWebアプリです。「どこに、どれくらい」という地図の見方に、「いつ」という時間の軸を加えています。初めて使う人がいきなり難しい計算条件と向き合わなくても、地図を眺め、条件を変え、違いを見比べられる入口を目指しました。

HAIZUのPC画面。富士山周辺の地図に仮定条件下の降灰分布を表示
PC版の表示例。風は西南西から12m/s、噴煙高度15km、宝永参考・断続的の条件で、噴火から3日後を表示。Tephra2と簡易時間モデルによる学習用シナリオです。

地図の色は推定堆積厚の区分を表します。時間を変えると、選んだ条件での累積の見え方が変わります。ただし、色が付いた場所をそのまま実際の危険区域と読み替えることはできません。アプリが扱う条件、計算範囲、時間モデルの近似をセットで見てもらう必要があります。

実装した主な機能は、風向・風速・噴煙高度・噴火規模の設定、時間バーと再生・一時停止、地点ごとの降灰情報、地点のブラウザ保存、公式ハザードマップへの切り替えです。条件を一つ変えて、同じ地点や同じ時刻で見比べると、「条件次第で見え方が変わる」というシミュレーションの性格をつかみやすくなります。

条件設定:風向きや噴煙高度を自分で動かす

条件設定では、噴火規模を小規模・宝永噴火級・大規模から選び、風向き、風速、噴煙高度を変更できます。これらの区分や数値は学習用の仮定です。次の噴火がこの規模になる、と判断するための選択肢ではありません。

HAIZUの条件設定画面。噴火規模、噴煙高度、風向コンパスを表示
条件設定画面の上部。風向は「風が吹いてくる方向」と明記し、コンパスで選べるようにしています。

風向きは、実装で取り違えやすいところでした。画面で選ぶ「西風」は西から吹いてくる風です。一方、灰が運ばれる先は反対側になります。そこで表示は「風が吹いてくる方向」にそろえ、計算側への向きの変換と区別しました。ラベルが曖昧なままだと、計算が動いていても利用者の理解は逆になり得ます。

噴煙高度も、単に「高さ」と書くと火口からの高さと海抜の高さを混同しやすいため、画面では「海抜」と添えています。単位や基準を省かないことは、派手な機能ではありません。でも、条件を触って考えるアプリでは、こうした説明が操作の土台になります。

噴火の推移には「宝永参考・断続的」と「単発・一定量」を用意しました。宝永参考の系列は、内閣府の広域降灰に関する資料を参考に、段階ごとの量や継続時間を組み込んだものです。開始時刻などには図から読み取った概略値を使っているため、史実を精密に再現したものではありません。風や噴煙高度も、観察期間を通じて一定と仮定しています。

スマホでは、地図を見る面積を残すことを優先した

PCで見やすい画面が、そのままスマホでも使いやすいとは限りません。説明ボックス、時間操作、条件変更ボタンを全部広げると、小さな画面では地図がほとんど隠れてしまいます。そこで、富士山の説明ボックスと時間操作をそれぞれ縮められるようにしました。

HAIZUのスマホ表示。説明と時間操作を縮め、0時間に戻すボタンと再生ボタンを表示
スマホ版の表示例。上部の説明を縮め、下部の時間操作もコンパクトにした状態です。

実際に触って見直したのが、時間操作の縮小表示です。最初は時間バーと「0時間に戻す」ボタンの距離が近く、スマホでは少し重なっていました。バーとボタンの間に余白を取り、縮めた状態でも再生・一時停止できるボタンを追加しています。画面を縮めたのに、再生するためだけにもう一度広げる必要がある。その小さな手間を減らす修正でした。

時間の送り幅は、初期値を6時間から1時間へ変更しました。大まかな変化を見るときは6時間や24時間にも切り替えられます。初期画面は12時間後ですが、0時間へ戻るボタンを独立して置き、始点から見たい人が探さなくても戻れるようにしています。

スマホ対応では、要素が画面内に収まるだけでは足りません。地図を操作する領域が残るか、押したいボタンを押せるか、縮めても必要な機能が使えるかまで確認しました。幅320pxの小さな画面も含め、配置と操作をブラウザで確かめています。

公式ハザードと、アプリ独自のシミュレーションを分けた

HAIZUには「シミュレーション」と「公式ハザード」のタブがあります。公式ハザードでは、富士山火山防災対策協議会の降灰可能性マップを地図上に表示します。自分で条件を変えた計算結果と、公開されている公式の想定資料を、同じ意味のものとして混ぜないための切り替えです。

HAIZUの公式ハザード表示。富士山の降灰可能性マップと出典、注意書きを表示
公式ハザード表示。出典と注意書きを示し、シミュレーションとは異なる色と画面構成で区別しています。

可能性マップに示された範囲すべてが、一度の噴火で同時に危険になるわけではありません。この点も画面に記載しました。広い色付きの領域は視覚的な印象が強いので、出典へのリンクだけを置いて説明を省くことは避けています。

アプリ内の参考表示を見た後、自治体や気象庁の情報へ進める導線も用意しています。HAIZUの中だけで判断が完結する設計にせず、公式情報を確認するきっかけとして使ってもらうことを意識しました。

実装した言語・技術と、言語モデルの役割

画面側はReact・TypeScript・Vite、地図はMapLibre GL JSです。APIはGoとchi、データ管理にはSQLiteを使っています。計算エンジンにはTephra2を組み込み、配信と運用はDocker・nginx・Caddyで構成しました。Android向けにはCapacitorの構成も用意していますが、この記事で紹介するのは公開中のWeb版です。

Tephra2は、噴火条件を与えたときの火山噴出物の堆積量を計算するシミュレーションツールです。実装はCで、HAIZUではその計算結果をアプリの表示につないでいます。詳細はTephra2の公式リポジトリを参照できます。

実装支援に使ったのは、GPT系の言語モデルを使うOpenAIのCodexです。直近の改修を含め、コードの変更、テスト、本番への反映、ブラウザでの確認を一緒に進めました。開発全体を通したモデルの細かな版名は、このログでは一律に断定しません。

ここは混同したくないところですが、AIが火山灰の分布を文章から作っているわけではありません。言語モデルは開発を支援する役割です。降灰の空間分布はTephra2による計算済みデータ、時刻ごとの表示はHAIZU側の簡易時間モデルが担当しています。利用者が時間バーを動かすたびに、言語モデルへ問い合わせる構成ではありません。

一番見直したのは、操作のたびに重い計算をしないこと

最初の仕組みでは、長い観察期間に対応するため、全時刻の画像を先に生成していました。手元の環境では、30日分の処理に約3分40秒かかった記録があります。計算が最後まで終わることは確認できても、条件を少し変えるたびに数分待つのでは、気軽に比較できません。

そこで通常運用は、事前に計算した最終分布を使う方式へ変更しました。用意した条件は、16方向の風向き × 30段階の風速 × 26段階の噴煙高度=12,480通りです。風速は1〜30m/s、噴煙高度は海抜5〜30kmで準備しています。

本番で条件を選んだときは、対応する計算済みの格子データを読み込みます。時刻ごとの画像は、表示が必要になったときに生成する方式です。数百枚の画像を毎回まとめて書き出すことを避け、操作の待ち時間と保存するファイル数を減らしました。

未準備の条件を無理にその場で計算する運用にもしていません。対応範囲を決め、管理側で準備したデータを使います。すべてを自由入力にするより、利用者が触ったときに待ち続けないことを優先した設計です。計算モデルや入力条件を変える場合は、データも検証し直す必要があります。

SE目線では、「速いコードを書く」より前に「どこで計算するか」を決め直す効果が大きかった部分でした。事前計算、表示時の処理、ブラウザへの配信を分けると、改善すべき場所も見えやすくなります。ただし、この方式で操作を軽くできたことと、計算の予測精度が高いことは別の話です。

留意した点:地図が動くことと、予測が正しいことは別

開発中に特に気を付けたのが、動作確認の結果を科学的な精度保証として書かないことです。APIが返る、画像が表示される、時間を動かせる、キャッシュが使える。これらはソフトウェアの検証です。実際の噴火で同じ分布になる、同じ時刻に到達するという検証ではありません。

HAIZUの簡易時間モデルには、到達までの遅延や段階ごとの噴出量を表示へ反映する近似が含まれます。観察期間中の風向・風速は一定、粒径などにも固定した条件があります。雨、再飛散、除灰などによる変化も含めていません。実際の現象すべてを再現できるモデルではなく、条件と限界を示したうえで使う参考表示です。

宝永噴火級という名称も、「次に起きる噴火の見通し」を示すものではありません。過去の噴火に関する資料を参考にした学習用のシナリオです。内閣府の広域降灰検討資料の条件をすべて再現したわけでもなく、国の計算結果の代替にはなりません。

初期表示には操作体験用のデモもあります。計算済みのTephra2分布を表示したときとは、画面のラベルを分けています。記事のシミュレーション画像は、条件設定から表示を更新した状態で撮影しました。雰囲気のある色付き地図ほど、本物らしく見えやすい。だからこそ、デモ、簡易時系列、公式情報の区別を見失わないようにしています。

Codexとの開発は、小さく直して実画面で確認する進め方

今回の開発は、一度に全部を完成させるより、まず動く部分を作り、触って分かった問題を直す進め方でした。地図、計算エンジンとの接続、時間表示、公式データ、スマホ対応と段階を分けています。最近の改修でも、「説明ボックスが邪魔」「縮小するとバーとボタンが重なる」「縮小したまま再生したい」という具体的な操作から改善しました。

Codexへの依頼も、こうした操作単位にすると確認しやすくなります。「スマホ対応して」だけでは完成の基準が広すぎます。「時間操作を縮めても再生できる」「×以外では広告ポップアップを閉じない」「0時間へ戻るボタンを常に見せる」なら、画面で合否を確かめられます。

ソースの型検査や自動テストだけでなく、本番のブラウザで動かして確認したことも大切でした。直近のフロントエンドでは16件の自動テストが通過しています。そのうえで、実際のスマホ幅、広告を閉じた後の状態、時間バーを動かした後の時刻まで確認しました。コードの検査と、利用者の操作の検査は両方必要でした。

維持するための広告と、改善を受け取る窓口も用意した

個人で公開するアプリなので、作った後に維持できるかも課題です。広告の連携は実際に試し、最終的に忍者AdMaxのバナーを組み込みました。再生ボタンや時間バーの操作後に表示し、×で閉じると操作へ戻る形です。広告クリックを利用の条件にはしていません。

短時間の操作で広告が何度も出ると、条件を比較する体験を邪魔してしまいます。そのため、同じタブでは10分に1回の表示制限を設けました。広告の配信方法によって本番の制限に引っかかることもあり、専用ページの設定を調整して表示を確認しています。画面に枠を置けば終わりではなく、配信環境を含めて確認が必要でした。

現時点で広告収入による維持が実現した、とまでは言えません。収益化も含めて、これからの運用で確かめる段階です。また、改善案や「こんな機能があるとよい」を受け取れるように、ご意見・お問い合わせページを設けました。小さな操作上の違和感も、次の修正に使いたいと思っています。

今後は、ほかの活火山にも広げていきたい

次に考えているのは、富士山以外の活火山への対応です。噴火したときの影響が大きくなり得る火山についても、条件を変えながら学べる入口を作っていきたいと考えています。ただ、火山名と座標を差し替えるだけで同じアプリを増やせるとは考えていません。

対象を選ぶときは、周辺の人口や交通・生活圏との関係、公開されているハザード資料、想定すべき噴火条件、計算範囲を確認します。火山ごとに必要なデータや前提が違うため、対応するシナリオと出典をそろえてから、計算済みデータを準備する流れになるはずです。

また、現在のHAIZUは降灰を中心とするアプリです。火砕流、溶岩流、噴石などを、同じ計算モデルの色だけ変えて追加することは避けたいと思っています。扱う現象が変われば、必要なモデルや情報の見せ方も変わります。対象を増やすほど、何を扱い、何を扱わないのかを明確にする必要があります。

火山を選ぶ順序や提供時期はまだ決めていません。まず富士山版の操作を改善し、データや近似の説明を整え、利用者の意見も受けながら検討していきます。「影響が大きいから急いで作る」だけでなく、どこまで説明できる状態にして公開するかを大事にしたいです。

HAIZUを触って、条件による違いを見比べてほしい

HAIZUは、噴火を言い当てるアプリではありません。仮定した条件のもとで、火山灰の広がりと時間の関係を見ながら考えるために作っています。風向きや噴煙高度を変え、同じ時刻で見比べ、公式ハザードの資料にも切り替えてみる。そんな使い方から始めてもらえればと思います。

AIと一緒に作ることで、画面の実装から運用の調整まで進められました。一方で、何を作るか、何を約束しないか、実画面で何を確かめるかは、依頼する側でも考え続ける必要がありました。HAIZUは、その過程を実際に動く形にした開発ログでもあります。

HAIZUを使ってみる。使いにくいところや追加してほしい機能があれば、アプリのお問い合わせページから教えてください。

実際の火山活動や防災情報は、気象庁の火山情報や自治体の案内を確認してください。この記事は2026年10月14日時点の実装・操作確認に基づいています。

kobashinのプロフィール画像

WRITTEN BY

kobashin

個人事業のシステムエンジニア。開発の実務と、AI・身体ケア・家庭菜園の実践を行き来しながら、試してわかったことを記録しています。

運営者情報を読む ↗

コメント