アプリを作ってみたいと思ったとき、最初に何を決めますか。プログラミング言語でしょうか。それとも、画面の色やボタンの形でしょうか。どちらも必要ですが、その前に考えておくと後の判断が楽になることがあります。「誰が、何を確かめるために使うのか」です。
富士山周辺の降灰を地図と時間で見るアプリ「HAIZU」も、画面、計算、データ保存など、いくつもの仕組みでできています。このシリーズでは、完成したアプリを入口にして、概要設計から実装、運用までを少しずつ説明していきます。第1回のテーマは、コードを書く前に整理したい「目的と作る範囲」です。
ここでは、設計資料と実装を振り返り、現在のHAIZUにつながる判断を初心者向けに整理します。機能がすべて最初から決まっていたという話ではありません。開発途中で見直したことも、分けて紹介します。
シリーズの入口：富士山の降灰を時間で見る「HAIZU」を作った｜Codexと進めた防災学習アプリ開発ログ
紹介記事では完成した画面を、本記事ではその画面につながる設計の考え方を扱います。
HAIZUは防災学習・参考情報を目的とするアプリです。実際の噴火・降灰を予測するものではなく、避難や安全性を判断するためのものではありません。実際の火山活動については、気象庁の火山情報や自治体の案内を確認してください。
概要設計は「何のために、どこまで作るか」を決めること
「概要設計」と聞くと、専門的な図や大量の書類を思い浮かべるかもしれません。個人開発の入口では、まず「このアプリが引き受ける仕事」を説明できれば十分に役立ちます。
たとえば、飲食店を開くとき、キッチンの道具を買う前に、どんな料理を、どんなお客さんに出すかを考えます。持ち帰り中心なのか、席でゆっくり食べる店なのかで、必要な設備も変わりますよね。アプリも、使う場面が変われば、必要な画面やデータが変わります。
HAIZUで中心に置いたのは、「仮定した噴火条件のもとで、火山灰の広がりと時間の関係を、画面を動かしながら考えられること」です。「火山灰を、時間で見る。」という言葉に、この軸をまとめています。
この一文があると、新しい機能を思いついたときにも判断できます。時間を動かせる機能は目的に直結します。地点ごとの値を確認する機能も、地図を自分に身近な場所と結びつける助けになります。一方で、利用者の交流機能などは、この学習体験を成立させるために必須ではありません。
ここで言う「要件」は、アプリに満たしてほしい条件のことです。「時間を動かせる」「スマホで地図が見える」「何の情報かを誤解させない」といった約束を、画面や計算の作り方へ落としていきます。難しい言葉を覚えるより、まず約束の中身を具体的にする方が進めやすくなります。
「誰が使うか」を、操作の場面まで具体的にする
対象を「防災に関心がある人」とするだけでは、まだ必要な機能を決めにくいところがあります。もう一歩進めて、「その人は画面を開いて何をするのか」を考えます。
HAIZUなら、たとえば「富士山周辺の地図を開く」「風向きなどの条件を見る」「時間を進める」「気になる地点を押す」「条件を一つ変えて見比べる」という使い方です。これは特定の利用者に調査して得た結果ではなく、画面を設計するときに置ける利用場面の例です。
この画面で見てほしいのは、見た目の装飾よりも、情報の置き場所です。地図だけでは、どの条件で計算したのか分かりません。条件の数字だけでも、どの場所に対応するのか分かりません。さらに時間を動かすなら、「今は噴火から何時間後なのか」が見えている必要があります。
つまり、地図・条件・時刻は、それぞれ別の部品でも、利用者にとっては一続きの情報です。概要設計では、部品を並べることに加え、部品同士をどう結びつけて読んでもらうかを考えます。
想定する使い方を文章にしておくと、確認作業にもつながります。「地図が表示されたから完成」ではなく、「条件と時刻を確認しながら、地点の情報を読めるか」まで確かめる。機能の有無から、実際に使えるかという視点へ進めます。
必要な機能は、利用者の疑問から逆算する
使う場面が見えてきたら、その場面で出てくる疑問を機能に置き換えます。HAIZUの主な機能との関係を整理すると、次のようになります。
| 利用者が確かめたいこと | 必要になる機能 | 設計で気をつけること |
|---|---|---|
| どのあたりに広がるのか | 地図と降灰分布の重ね合わせ | 色の意味と計算範囲を伝える |
| 時間がたつとどう変わるのか | 時間バー、再生・一時停止 | 経過時間と累積値の意味をそろえる |
| 風の条件を変えたらどうなるのか | 風向・風速などの条件入力 | 単位と選択できる範囲を示す |
| 気になる地点ではどう見えるのか | 地点の選択、値の表示、地点保存 | 範囲外やデータがない場合を扱う |
| 公式の資料も確認したい | 公式ハザードへの切り替えと出典リンク | 独自計算と公式資料を区別する |
「地図アプリだから地図を置く」という決め方だけだと、地図が表示されたところで手が止まりがちです。「条件を変えて比較したい」まで考えると、条件入力と結果の更新が必要になります。「後でもう一度見たい」なら、地点の保存が役立ちます。
一方で、疑問が増えたら、そのまますべて機能にするわけでもありません。たとえば、「この場所は安全ですか」という問いに、このモデルの結果だけで答えることはできません。要望に合わせて安全・危険の判定表示を付けるのではなく、アプリの目的と根拠に照らして、答えられる範囲を決める必要があります。
個人開発では、思いついた機能を実装し続けると、完成の基準が見えなくなります。「条件を変え、時間を動かし、地点の情報を確かめる」という中心の流れを成立させてから、追加機能を考える。この順番が、作業範囲を扱いやすくします。
入力項目の名前と単位も、設計の一部になる
条件を入力できるだけでは、意図した使い方になるとは限りません。入力した数字や向きの意味が、利用者と計算側で一致している必要があります。
たとえば「西風」は、西から吹いてくる風です。「灰が向かう方向」として西を選んでしまうと、利用者の意図と計算の条件が逆になります。そこで画面では、風向きを「風が吹いてくる方向」と説明しています。コンパスの形にすることと、意味を文章で伝えることは、両方必要でした。
噴煙高度も同じです。「高さ15km」とだけ書くと、火口から15kmなのか、海面を基準に15kmなのかが曖昧になります。画面で「海抜」と添えるのは、計算条件の基準を伝えるためです。単位を付けるだけでなく、何を基準にした数字なのかもそろえます。
また、結果として表示する「厚さ」は、計算した堆積質量を、仮定した火山灰の密度で換算した値です。見た目に分かりやすい単位へ直している一方、密度の仮定によって値が変わることも説明が必要になります。詳しい計算は後の回で扱いますが、第1回の段階でも、「入力と出力の数字を何として読むか」は決めておきたいところです。
自分でアプリを作る場合も、入力欄を並べる前に、項目名・意味・単位・選べる範囲を書き出してみると整理できます。「この数値を見た人は、同じ意味で受け取るだろうか」と考えると、コードだけを見ているときには気づきにくい曖昧さが見つかります。
「動くこと」と「気軽に使えること」は分けて考える
設計には、ボタンや地図のように目に見える機能のほかに、待ち時間、画面の見やすさ、サーバーの負担といった条件もあります。こうした条件は「非機能要件」と呼ばれますが、初心者のうちは「使い心地と、維持するための条件」と考えるとつかみやすいと思います。
HAIZUでは、開発途中に待ち時間の問題が出ました。長期間の表示に対応するため、全時刻の画像を先に作る方式では、手元の環境で30日分の処理に約3分40秒かかった記録があります。処理が成功していても、条件を少し変えるたびに数分待つと、見比べる操作を続けにくくなります。
そこで通常の利用では、事前に計算した分布を使い、時刻ごとの画像は表示に必要になったときに作る方式へ変更しました。富士山用に用意した条件は、風向16方向×風速30段階×噴煙高度26段階の12,480通りです。すべての数字を自由入力するのではなく、準備した条件から選ぶ作りになっています。
この変更には、事前にデータを作る手間や保存容量が必要になる面もあります。「何でも計算できる」方向へ広げる代わりに、「用意した条件を待たずに見比べやすくする」ことを優先しました。なお、待ち時間は環境や通信状態にも左右されるため、どの端末でも瞬時に表示できるという意味ではありません。
この話から分かるのは、概要設計は最初に一度書いて終わりではない、ということです。実際に動かして目的に合わない部分が見えたら、作り方を見直します。HAIZUでは「比較しながら学ぶ」という目的が、計算と表示の分担を変える判断につながりました。仕組みの詳細は第7回で扱う予定です。
スマホでも同じで、要素が画面の幅に収まれば十分、とはいきません。説明欄や操作欄で地図を隠してしまうと、何を見るアプリなのかが伝わりにくくなります。説明を折りたためること、縮めた状態でも時間操作ができることは、「地図を見ながら触る」という使い方から必要になった工夫です。
学習用の表示と公式情報を、見分けられるようにする
HAIZUで特に気をつけたいのが、画面がきれいに動くほど、結果が正確な予測のように受け取られる可能性があることです。地図上の色には、文章以上に強い印象があります。色が付いていない場所を「安全」と読んでしまうと、アプリで説明できる範囲を超えてしまいます。
そこで、独自のシミュレーションと公式ハザードをタブで切り替え、見た目や説明も分けています。公式資料の出典と、想定の読み方を画面に置くのも、その区別を保つためです。
独自シミュレーションは、選んだ仮定条件での計算と簡易な時間表現です。一方、公式ハザードの表示は、公開されている降灰可能性マップを参照するものです。可能性マップの色付き範囲すべてが、一度の噴火で同時に影響を受けるという意味でもありません。どちらも「地図に色が付いている」ので、何を見ているのかを言葉と画面の両方で示します。
また、HAIZUの時間変化は簡易モデルによる近似です。現実の時間・高度ごとの風の変化などをそのまま再現するものではなく、宝永参考の系列も、過去の噴火を精密に再現したものではありません。詳しい前提は、HAIZUの使い方とシミュレーションの前提にまとめています。
これは免責文を最後に付ければ済む話でもありません。表示名、色、切り替え方、出典リンクまで含めて、何が読み取れて、何は判断できないのかを伝える。防災に関わる題材を扱ううえで、情報の見せ方そのものが設計の一部になります。
最初の設計メモを、1枚にまとめてみる
ここまでを、自分の個人開発でも使える形にすると、次のような設計メモになります。以下は本記事用に要点を整理し直したもので、開発開始時の文書をそのまま転載したものではありません。
| 決める項目 | HAIZUの場合 |
|---|---|
| 目的 | 仮定条件のもとで、降灰の広がりと時間の関係を学ぶ入口を作る |
| 想定する使い方 | 条件を確認し、時間を動かし、地点や条件による違いを見比べる |
| 中心となる機能 | 地図、条件設定、時間操作、地点情報、公式ハザードの参照 |
| 使い心地の条件 | スマホでも地図を見ながら触れること、操作ごとの待ち時間を抑えること |
| 実装・運用の条件 | 重い計算と通常の表示処理を分け、準備済みデータを再利用する |
| 引き受けない役割 | 実際の噴火・降灰の予測、避難判断、地点の安全判定 |
| 確かめること | 条件と単位の意味、表示時刻との対応、範囲外の扱い、出典、スマホ操作 |
このメモを作るときは、抽象的な言葉を一つずつ操作へ直してみてください。「使いやすい」なら、何を押せればよいのか。「速い」なら、どの操作の待ち時間を気にしているのか。「分かりやすい」なら、どの数字や情報の意味を伝えたいのか。小さく具体化すると、実装後に確認できるようになります。
開発支援にCodexを使う場合も、このメモは依頼の土台になります。「地図アプリを作って」という一言より、目的、主な操作、扱うデータ、判断させないことをそろえて伝えた方が、変更内容を確認しやすくなります。これは今回の整理から組み立てた依頼の考え方で、過去の指示文をそのまま再現したものではありません。
最初から細かい設定値をすべて決める必要はありません。迷ったときに戻れる目的と、最初に成立させる使い方を決めておく。そのうえで実画面を触り、違和感があれば設計に戻る。HAIZUの待ち時間やスマホ表示の見直しも、この往復として捉えられます。
次回は、画面・サーバー・計算係のつながりへ
第1回で扱ったのは、技術を選ぶ前後で共有しておきたい「アプリが引き受ける仕事」です。HAIZUでは、条件を変えて比較する学習体験を中心に置き、必要な機能、使い心地、情報の限界を整理しました。
続く第2回では、これを実際の仕組みに分けて見ていきます。画面を担当するReact、要求を受け取るGoのAPI、データを管理するSQLite、降灰分布を計算するTephra2。それぞれの役割と、条件を選んでから地図へ表示されるまでの流れを、構成図と実画面で説明しています。
シリーズ案内
入口・完成画面：HAIZUの紹介と開発ログ
第1回：アプリを作る前に、何を決めたのか？（この記事）
第2回：画面・サーバー・計算係の役割は？アプリ全体の仕組みを図解
第3回：地図に火山灰の広がりを重ねるには？座標・色・透明度を図解
第4回：スマホでも地図を見やすくするには？折りたたみと操作画面の設計
画面を見ながら読むなら、HAIZUをブラウザで開くことができます。最初は時間の表示と操作欄、条件の単位、公式ハザードへの切り替えに注目すると、今回の設計と画面の関係が見えてきます。初期表示には操作体験用のデモが使われるため、その表示を実計算の結果と取り違えないようにしてください。
本文の設計説明は、2026年10月17日に確認したプロジェクトの資料と実装をもとにしています。キャプチャは紹介記事で使用した2026年10月14日の富士山版の実画面を再掲しました。開発中の複数火山対応などは、本記事の画面説明と分け、発展編で扱う予定です。
参考情報
- HAIZUの紹介と開発ログ：シリーズの入口となる記事です。
- HAIZUの使い方とシミュレーションの前提：表示の見方とモデルの限界を確認できます。
- 気象庁の火山情報：実際の火山活動や防災情報を確認する入口です。
