この記事は、「天体観測できるかな？」という天体観測用の各種情報を表示するツールの開発記録（git commit）の内容をcodexに分析させて、自分自身の開発振り返りのために生成した文書です。

気づけばこのリポジトリは、ただの天気ダッシュボードではなく、天体観測に特化した観測支援アプリへ育っていました。

この記事は、weather_dashboard の Git コミット履歴を時系列で追いながら、

何を作ろうとしていたのか
どこで設計が変わったのか
何に苦しみ、どう整えていったのか

を、いわば「現場ログ」としてまとめたものです。

対象読者は、個人開発を継続している人、AI支援開発の進め方に興味がある人、そして「コミット履歴って開発記になるのか？」と思っている人です。

3行でわかるこのプロジェクト

もともとは気象ダッシュボードとして着手
途中から「星空観測の意思決定を支援する」方向へピボット
機能追加の勢いと、後半の品質整備・判定統一が履歴にそのまま残っていた

現時点の README では、アプリ名は 「天体観測できるかな？」、バージョンは 3.8.11 です。

1. すべては天気ダッシュボードから始まった

最初期のコミットはかなり素直です。

f5050b6 2026-01-02 Initial commit
ebcf948 2026-01-02 Add weather dashboard HTML structure
075460d 2026-01-02 Update version and add humidity data to weather API

この時点では、まだ「天体観測」よりも「天気情報を見やすく出す」ことが中心でした。
雲量、湿度、天気 API、グラフ表示といった、ダッシュボードの基礎体力を先に作っています。

ここで重要なのは、最初から巨大な構想を一気に実装していないことです。まずは HTML を立て、API をつなぎ、見えるものを作る。Git 履歴から見ても、かなり小さな差分で前に進んでいます。

2. 「天気アプリ」から「星を見るための道具」へ方向転換した

転機は 2026-01-02 の後半です。

5d90321 2026-01-02 Update version number to 1.3.0 and add astronomy summary
2e0db70 2026-01-02 Enhance weather forecast with moon phase details
948b767 2026-01-02 Change title and header for stargazing dashboard

この3本で、プロダクトの重心が一気に変わっています。

天気を見るアプリではなく、

今夜、星を見に行くべきかを判断するアプリ

に変わったわけです。

このピボットは強いです。なぜなら「単なる情報表示」から「行動判断支援」へ移っているからです。

雲量や湿度はそれ単体ではなく、「観測できるか」を判断するための材料になります。月齢や天文薄明が入ってくると、アプリの人格が明確になる。コミット履歴だけでも、プロダクトの芯がここで立ったことが読み取れます。

3. 1月中旬、機能が一気に爆発した

2026-01-14 から 2026-01-18 にかけて、このリポジトリは急激に進化します。
特に v2 系から v3.2 系までは、毎日のように大型機能が積まれています。

代表的な流れはこんな感じです。

02c5e6e 2026-01-14 Major update to v2.0.0 with comprehensive astronomical features
c9a8f92 2026-01-14 Add ISS crew information display with Open Notify API
404cc9a 2026-01-15 Replace ISS pass predictions with real-time ISS location
70acd1d 2026-01-15 Add ISS tracking with visibility prediction feature
e649675 2026-01-15 バージョン2.4.0へアップデート：天の川視認性予測機能を追加
5af7d1b 2026-01-15 バージョン2.5.0へアップデート：ISS星座図（天球図）表示機能を追加
2008abb 2026-01-15 バージョン2.7.0へアップデート：ISS次回パス予測機能を追加
92e0f3e 2026-01-16 バージョン2.10.0へアップデート：大気透明度・シーイング指標機能を追加
b20073d 2026-01-16 バージョン2.11.0へアップデート：天体写真露出計算機を追加
2187068 2026-01-16 バージョン2.12.0へアップデート：ISS通過の1時間前通知機能を追加

この時期の履歴を見て感じるのは、開発が「要件定義」ではなく「発見駆動」で進んでいることです。

作ってみる。
使ってみる。
足りないものが見える。
次のコミットで足す。

このループが非常に速い。

個人開発や AI 支援開発では、この速度自体が武器になります。一方で、副作用も出ます。履歴を追うと、後でそのツケをきちんと払っているのが面白いところです。

4. ISS 機能は「追加」より「判定の整合」が本番だった

このリポジトリで一番ドラマがあるのは ISS 周りです。

追加して終わりではなく、判定基準や見え方の整合性に何度も手が入っています。

たとえば 2026-02-16 以降だけでも、

b2b2521 2026-02-16 ISSパス開始終了を仰角10度基準に統一しv3.5.3をリリース準備
47fff87 2026-02-16 ISS評価を昼光/可視/夜に変更し見え始め方角表示を追加してv3.5.4を反映
1af46fd 2026-02-18 ISS可視カテゴリの再判定修正とv3.5.5更新を反映
219fc46 2026-02-18 ISS判定補強と天図モーダル外クリック閉鎖をv3.5.6で反映
e8e84cb 2026-02-18 天文描画停止対策とISS日照表示追加をv3.5.7で反映
407c418 2026-03-07 ISS肉眼可視判定の不整合修正とv3.8.1リリース反映
76db95a 2026-03-07 ISS状態表示を極座標図判定に統一しv3.8.4を反映

と続きます。

ここから見えるのは、「機能を持つこと」と「ユーザーに矛盾なく見せること」は別問題だ、という開発の現実です。

ISS は特にややこしい。

空に出ているか
肉眼で見えるか
太陽光を受けているか
観測地では夜か
どの UI でも同じ基準で表示されているか

このへんが少しでもずれると、一覧では「見える」、星図では「見えない」、通知では別のことを言う、という事故が起こります。

履歴を見る限り、このプロジェクトは後半になるほど「新機能を足す」より「判定を統一する」に重心が移っています。これはかなり健全です。

5. リファクタリングは後追いではなく、開発速度を守るために入った

2026-01-17 と 2026-02-07 のコミット群は、いわば整備フェーズです。

99e6b26 2026-01-17 大規模なリファクタリングの実施。
842193e 2026-01-17 ISSの通知機能、レーダーチャートの描画、月齢計算を含む天文イベントの計算ロジックを追加。また、UIおよびお気に入り管理機能のリファクタリングを実施。
2e6de34 2026-02-07 保守性改善とイベント委譲化を実施しv3.5.2へ更新

CHANGELOG 側を見ると、ここで実際にやっていることはかなり本格的です。

イベント処理を data-action ベースの委譲へ移行
月食・日食探索ロジックをサービス分離
ISS 星図まわりも専用サービスへ分離
バージョン整合チェックや静的品質チェックをスクリプト化

つまり、「動くから良い」から「壊れにくく直しやすい」へ意識が変わっています。

個人開発では、リファクタリングは後回しにされがちです。でもこの履歴では、機能追加のテンポを落とさないために整理を入れている。そこが良いです。

6. 外部 API 依存の怖さには、フォールバックとキャッシュで立ち向かっていた

このプロジェクトは Open-Meteo、各種天文計算、TLE 取得など、外部データへの依存が強い構成です。
当然、壊れどころもそこに集中します。

実際に履歴にはその対策が何度も出てきます。

328fbec 2026-02-07 TLE APIフォールバック機能を実装、セキュリティ強化とコード品質改善。バージョンを3.5.0に更新。
53f5b4b 2026-02-07 TLE再取得に24時間フェッチガードを追加
ad9bffb 2026-03-07 jma_seamlessを基本モデル化し欠落項目をフォールバック補完してv3.8.7へ更新

ここは現場感が強いポイントです。

外部 API は便利ですが、

欠損する
遅い
仕様が一定でない
期待した粒度で返ってこない

という問題が避けられません。

このリポジトリでは、単に「取得失敗時にエラーを出す」のではなく、

別ソースへのフォールバック
キャッシュで連続アクセス抑制
欠落項目だけ補完

という現実的な設計に寄せています。

派手ではないですが、こういうコミットがあるプロジェクトは信頼できます。

7. UI 改善は最後の化粧ではなく、意思決定支援そのものだった

コミット履歴を見ていると、UI 改善がかなり多いです。
でもこれは単なる見た目調整ではありません。

356a531 2026-01-18 週間天気予報パネルの各日の背景を視認スコアに基づいた透過色で表示する機能を追加。
595d04f 2026-01-20 バージョンを3.3.7に更新。全モジュールおよびドキュメントのバージョンパラメータを更新し、気温予報と雲量グラフに現在時刻マーカーを追加。
2bc13fc 2026-03-07 週間予報の日次時間別モーダル追加とv3.7.0改版を反映
a7cca80 2026-03-07 時間別予報モーダルのアイコン追加と数値桁揃えを反映
c4e9faf 2026-03-07 時間別予報モーダルへ平均雲量サマリーを追加

観測支援アプリでは、「正しい情報」だけでは足りません。
短時間で読める形になっているかが重要です。

たとえば、

色で今夜の当たり日がわかる
現在時刻マーカーで読む位置が迷子にならない
日次モーダルで 24 時間の傾向が一気に見える
雲量の平均が添えられて判断が速い

といった改善は、全部「現場の意思決定時間を削る」ためのものです。

UI を装飾ではなく、判断コストを下げる手段として扱っている点は、このプロジェクトの良い癖だと思います。

8. ドキュメントとリリース運用のコミットが多いのも、この履歴の特徴だった

見落としがちですが、このリポジトリはドキュメント整備のコミットもかなり多いです。

bdbaea1 2026-01-14 Add comprehensive README.md for v2.0.0
867713d 2026-01-17 AI支援開発のための包括的なCLAUDE.mdドキュメントを追加。
e3f86cb 2026-01-18 CLAUDE.mdに「コミット前の必須チェックリスト」セクションを追加し、AI支援開発の品質向上を実現。バージョンを3.1.9に更新。
5b7b2cd 2026-01-19 README.mdのバージョン履歴をCHANGELOG.mdと同期。
35e7265 2026-03-09 リリース手順のバージョン更新項目を明確化しv3.8.10へ更新

これは AI 支援開発との相性が良い動きでもあります。

AI を使うと実装速度は上がりますが、そのぶん

どこを更新すべきか
バージョンをどこで揃えるか
リリース前に何を確認するか

を明文化しないと、すぐにズレます。

このプロジェクトは、そのズレを「気合い」ではなく「手順書」「チェック」「スクリプト」で抑えにいっています。

個人的にはここが一番「天体観測できるかな？」っぽいと感じました。開発の勢いを、運用の型で受け止めているからです。

9. Revert が1本あるのも、むしろ健全だった

2026-03-07 にはこんなコミットもありました。

158e5d6 2026-03-07 Revert "バージョン表記修正とISS肉眼可視判定統一をv3.8.3に反映"

Revert は悪ではありません。
むしろ、早く戻せる状態を保っている証拠です。

個人開発、とくに高速開発中は「直したつもりが別の場所を壊す」が起きやすい。
そのときに履歴が細かく、リリース単位が明確だと、撤退コストが小さくなります。

履歴全体を通して見ても、このリポジトリは

小刻みに刻む
バージョンを頻繁に上げる
問題が出たらすぐ修正、必要なら戻す

というリズムで進んでいます。この運び方はかなり実戦的です。

10. コミット履歴から読み取れた、この開発の学び

このリポジトリを追っていて、特に印象に残った学びは5つありました。

1. 最初から完成形を決めなくてもいい

天気ダッシュボードから始めて、途中で「天体観測支援」に軸を移したことで、プロダクトの価値が明確になりました。
最初のスコープを狭くして着手するのは、やはり強いです。

2. 機能追加の本当の敵は、判定基準のズレ

ISS まわりの履歴が象徴的でした。
複数 UI・複数ロジック・複数 API が絡むと、仕様の不整合が一気に表面化します。
後半はその是正にかなりの投資が入っていて、これは正しい投資です。

3. フォールバックとキャッシュは、機能ではなく信頼性そのもの

天気や軌道データのように外部依存があるなら、「取得できたら使う」では足りません。
取得できない前提で設計する必要があると、コミットが教えてくれます。

4. ドキュメントは開発速度を落とすどころか、守ってくれる

README、CHANGELOG、CLAUDE.md、チェック用スクリプトの整備は、機能開発の邪魔ではなく、むしろ高速開発の土台でした。

5. コミット履歴は、そのまま開発記になる

履歴が細かく、主語があり、変更意図が読めると、後から記事に起こせます。
つまり、コミットメッセージは未来の自分へのログでもあります。

まとめ

この weather_dashboard の履歴は、

思いついた機能を高速に形にする前半
不整合を潰して設計を締める中盤
信頼性と運用を整えながら体験を磨く後半

という、かなりきれいな成長曲線を描いていました。

「天体観測できるかな？開発記」と呼ぶなら、これは単なる実装記録ではなく、

作る
壊れる
揃える
運用に載せる

の反復が刻まれたログです。

個人開発でも、AI 支援開発でも、結局プロダクトを前に進めるのはこの反復なんだと思います。

コミット履歴は、ちゃんと読むと、想像以上に開発チームの思考を語ってくれます。