同じ日に出したVersion1.0と1.1を混ぜなかった理由

1. リード

2026年7月26日、Kagoshimaniax OSでは v1.0.0 と v1.1.0 が同じ日に正式リリースされた。時間だけを見れば、一続きの大きな完成として書きたくなる。運用の問題を解消し、その勢いで画面も改善し、全部まとめて完成した。そんな説明の方が分かりやすそうに見える。

けれど、Current Context と CHANGELOG の整理はそうなっていない。v1.0.0 は運営OSの正式化、v1.1.0 はDashboardのUI・情報設計改善として分けられている。前者では運用条件を詰めて最終Goを確認し、後者では毎朝60秒以内に「正常 / 注意 / 要対応」を判断しやすくする見え方を受け入れた。

同じ日に出たからといって、同じ意味のVersionではなかった。今回は、なぜこの二つを一つの成果へ混ぜず、別々のVersionとして残したことが大切だったのかを書いてみたい。

2. 背景

v1.0.0 の正式化までには、Operational Validation Weekがあった。Day 7の一時No-Goを経て、2026年7月26日の最終無人検証でGoになった。確認されたのは、DarkWake中にConnectorを開始しないこと、通常Wake後にGA4・GSC・Clarityが success になること、Metricoolが既知許容の partial で7日分保存されること、wrapperのexit codeが0でstderrが空であること、そして178 tests passedだった。

このGoは、新しい機能を大量に足した結果ではない。Current Contextは、DNSや一時通信障害への有限再試行、Metricoolの非対話OAuth refresh、DarkWake除外、通常Wake待ちといった運用条件を最小差分で詰めた結果だと整理している。つまり v1.0.0 が確定したのは、運営OSを毎日の条件で任せられると判断できたからだった。

一方、同日に正式リリースされた v1.1.0 の中心はDashboard UI改善である。完了事項は、毎朝60秒以内の状態判断を助けるUI改善、9画面の最終UI受入、275 tests passed。新Connector、DB・SQL・スキーマ変更、AI要約・自動提案、新しい書き込みAction、Human Approvalの省略は行っていない。

並べてみると、二つのVersionが確定した対象は明確に違う。v1.0.0 は運用の成立、v1.1.0 は成立した運用の見え方である。

3. 今回のテーマ

今回のテーマは、同じ日に公開した二つのVersionを分けたことで、「運用できる」と「判断しやすい」を別々の責任として記録できたということだ。

もし一つにまとめていたら、最終Goの根拠にUI改善まで含まれて見えたかもしれない。逆に、UIが見やすくなった理由を、Connectorや自動化の信頼性改善と混同したかもしれない。しかし実際には、運用条件が整ったことと、朝の画面が読みやすくなったことは別の成果だった。

4. 実際の出来事

v1.0.0 の最終判定には、無人実行の具体的な条件が並んでいる。DarkWakeでは開始しない。通常Wake後には必要なConnectorが動く。Metricoolの partial は既知制限として説明できる。wrapperはexit code 0で、stderrは空。178件のテストも通過した。これは、見た目の印象ではなく、運用を任せるための条件を積み上げた記録だった。

そのため、v1.0.0 の意味をUI改善と一緒にすると、Go判定の輪郭が薄くなる。画面が見やすかったからGoにしたのではない。運用条件を明確にし、最終無人検証で再確認したからGoにした。この順番は崩せない。

一方の v1.1.0 では、毎朝の判断が主役になる。運営OSが動くことは前提として、その状態を60秒以内に「正常 / 注意 / 要対応」へ読み分けやすくする。9画面を最終受入し、275 tests passedを確認する。ここでは、運用の成立そのものをもう一度作り直したのではなく、成立した運用を人が読み取りやすい形へ整えている。

この違いは「やっていないこと」にも表れている。v1.1.0 では新Connectorを増やしていない。DBやスキーマも変えていない。AI要約や自動提案も足していない。新しい書き込みActionもない。Human Approvalも省略していない。つまり、v1.0.0 で成立した基盤や統制を広げず、見え方の改善だけを切り出している。

私は、この切り分けがあるから、あとから正本を読んでも判断理由を追えるのだと思う。v1.0.0 の178 tests passedと v1.1.0 の275 tests passedは、数字が増えた一つの物語ではない。それぞれのVersionで対象とした変更と受入に対応する確認結果だ。大きい数字だけを最後に残すより、どの境界で何を確認したかを残す方が、開発の記録として強い。

また、同日公開であってもVersionを分けたことにより、問題が起きたときの説明も分けやすくなる。運用条件の話なのか、Dashboardの読み取りやすさの話なのか。変更の責任範囲が分かれていれば、原因を探すときも、記事で振り返るときも、別の話を混ぜにくい。

ここで重要なのは、v1.1.0 を小さく見せるために分けたのではないことだ。UI改善は毎朝の判断時間に直結する正式な改善であり、9画面の最終受入まで行っている。だからこそ、v1.0.0 の付録にせず、一つのVersionとして独立させる意味があった。運用完成とUI改善のどちらも重要だが、重要だからこそ同じ箱へ押し込まなかった。

5. 考えたこと

非エンジニアの立場では、同じ日に完成したものは一つにまとめた方が分かりやすいと感じる。数字も大きく見えるし、物語も簡単になる。だが、簡単な物語にすると、何をもって完成としたのかが分からなくなることがある。

今回の二つのVersionを見ると、「できた」という言葉にも種類があると分かる。毎日動かせる条件が整った。朝に状態を読み取りやすくなった。どちらも完成だが、受け入れた対象は違う。対象が違うなら、Versionも分けた方が説明に責任を持てる。

AIとの開発では、後から要約すると出来事が滑らかにつながりすぎることがある。一時No-Go、運用条件の修正、最終Go、UI改善、9画面受入。すべてを一段落にまとめれば、美しい成功談になる。しかしその書き方では、一時No-GoからGoへ変わった根拠と、UI改善を正式受入した根拠が混ざる。

GitHubを正本にし、CHANGELOGとCurrent ContextでVersionごとの意味を分けておくと、その混ざり方を防げる。会話の印象ではなく、どのVersionで何を完了し、何をしていないかを確認できる。記事を書く側にとっても、これはかなり重要な支えになる。

Human Approvalの位置づけも変わっていない。v1.1.0 で画面が読みやすくなっても、最終判断を自動化へ渡したわけではない。UI改善の目的は、人を判断から外すことではなく、人が短時間で判断できるようにすることだった。この境界を v1.0.0 の運用完成と混ぜなかったことで、安全統制がどこまで維持されたかも読みやすい。

同日公開という事実は、二つのVersionが同じものだった証拠ではない。むしろ短い時間の中でも、運用完成とUI改善を分けて管理した証拠として読める。日付ではなく、変更の責任範囲でVersionを切る。この考え方は、コードを書かない私にも理解しやすかった。

6. 学び

• 同じ日に公開しても、運用完成とUI改善は別のVersionとして扱える
• v1.0.0 のGoは運用条件と最終無人検証によって確定した
• v1.1.0 は新機能ではなく、毎朝の判断を助けるUI・情報設計改善だった
• テスト数だけを一続きにせず、どのVersionの受入結果かを残す方が説明しやすい
• 重要な成果ほど一つにまとめず、責任範囲ごとに履歴を残した方が正確になる

7. 次回メモ

次に振り返るなら、Versionが分かれていることで、正式リリース後の記事でも「何をしたか」だけでなく「何をしていないか」を書ける理由につながる。完成を大きく見せるより、境界を正確に残す方が、連載を長く続ける土台になる。