1. リード
Release Candidate を置いたあと、ふと静けさが来る。タグは付いた。テストは通った。Release Notes も書いた。では、終わりか？——違う。ここからが、運営 OS としての本番に近い週だ。コードを足さず、毎日使い、違和感を記録する。Kagoshimaniax OS は Step49 の運用検証週に入った。Season 1 の最終話は、達成の祝杯ではなく、区切りと継続の話として書く。
非エンジニアの私がこのシリーズで伝えたかったのは、完成の瞬間ではない。完成の直前に、何を止め、何を残したかだ。止められたから RC があり、残したから朝の確認が続く。
2. 背景
Vol.01 で書いたのは、コードを書けない私が、なぜ運営 OS を作ることになったかだった。朝の確認がつらい。バラバラのツール。昨日との比較ができない不安。そこから MCP、暴走の制御、仕様のオーナーシップ、SQLite、Connector Platform、Human Approval、レビュー、そして 1.0.0-rc1 へ——一本の線が見えてきた。
見えてきたからこそ、最後に誤解を直したい。「作ったら終わり」ではない。地域メディアの運営は、毎日続く。OS も、毎日開く道具であるべきだ。道具は、棚に飾るものではない。手が汚れるものだ。汚れるとは、実際の朝に使われることだ。
3. 今回のテーマ
テーマは、Season 1 の区切りと、Step49 運用検証週のはじまりだ。
2026-07-11 から始まった 7 日間。コード追加禁止。v1.0.0-rc1 を毎日使う。Dashboard で分析を見る。コネクタの実行状況を確認する。必要なら Human Approval 付き Actions を試す。違和感は docs/operational-validation-report.md に残す。残すことが、次の Version への入力になる。
未来の機能の予告はしない。書けるのは、すでに始まった検証だけだ。
4. 実際の出来事
Step48 の翌日、運用検証週がスタートした。ルールは単純だ。新しい機能を足さない。バグ修正は最小限。毎日同じ手順で OS を開く。開く時間を、できるだけ本番の朝に近づける。近づけると、テストでは見えない摩擦が出る。摩擦は、宝物だ。宝物を隠すと、次の Version でまた驚く。
検証のチェックリストには、Connector の健康、SQLite の行、Dashboard 8 画面、Human Approval の動作、セキュリティの基本——Must が、日常で生きているかを見る項目が並ぶ。並んでいると、迷わない。迷いは、朝の 10 分を食う。
私が最初の日に感じたのは、意外な安心だった。RC という文字が Sidebar にあるだけで、「今日は足さない」と自分に言える。足さない日が続くと、違和感の解像度が上がる。上がると、改善の優先順位が自然に付く。付くのは、機能リストではなく、実際の運営からだ。
Season 1 を振り返ると、失敗の方が多い。暴走した。用語が揺れた。文書を後回しにした。「あと一つだけ」と凍結を破りかけた。失敗を書けるようになったのは、CHANGELOG と Step ログがあったからだ。記録は、恥の解毒剤になる。解毒されない恥は、次の判断を遅らせる。
成功したこともある。それは派手な機能ではない。朝の確認の地図が一枚になったこと。GA4、Search Console、Clarity、Metricool の日次が SQLite に溜まり、Dashboard で昨日と比べられる。本番変更は Human Approval を挟む。提案は AI、決断は人——その線が文書とテストに残っている。
Dogfood Before Deploy は、検証週の思想と同じだ。自分で先に使う。使わない道具は、他人に勧められない。勧められないものを Version 1 と名乗る勇気は持てない。持てたのは、RC だからだ。正式版 1.0.0 は、検証のあとに判断する。判断を先延ばしにしないが、飛び越えもしない。
このシリーズに Vol.11 はない。終わりではなく、読み物としての区切りだ。体験談は、実装が進むほど古くなる。古くなる前に、当時の時系列で残した。残したものの正は、あくまでリポジトリ内の docs/——architecture、ADR、releases——にある。連載は、その横にある日記だ。
運用検証週の初日、私は意図的に「新しいことはしない」と宣言した。宣言は、自分へのルールだ。ルールがあると、出てきた不満を正しく分類できる。分類は、バグなのか、仕様なのか、単に慣れ不足なのか。慣れ不足は、時間で直る。仕様は文書で直す。バグだけが、例外としてコードに触れる候補になる。
7 日間と聞くと短い。短いからこそ、毎日同じ手順を繰り返す価値がある。繰り返すと、儀式になる。儀式は、非エンジニアの運営に向いている。天才のひらめきより、毎朝開ける画面の方が、地域メディアには効く。効くかどうかは、検証週のレポートに書いていく。
Vol.01 で「コードを書けない」と書いた。書けないは、できないと同じではない。書けないからこそ、判断と記録に集中できた。集中の成果が、Connector Platform と Human Approval と RC だ。コードが読めなくても、動いたかどうかと説明できるかどうかは、運営者が一番よく知る。知っているから、Dogfood は非エンジニアにこそ向いている。
5. 考えたこと
「ここで終わらない」は、開発が終わらないという意味でも、記録が終わらないという意味でもある。開発は、検証週のあとも続く。ただし、続け方が変わる。足すフェーズから、使い、直し、また足す——の循環へ。
非エンジニアが AI とプロダクトを進めるとき、一番の敵は能力不足ではない。成功の定義を曖昧にすることだ。曖昧だと、永遠に足す。足し続けると、朝は楽にならない。朝が楽にならない OS は、趣味にはなるが、運営にはならない。
Kagoshimaniax OS は、運営の道具として RC に立った。立った場所から見える景色は、まだ完璧ではない。完璧を待っていたら、一生 RC は出せない。出したから、現実のフィードバックが始まる。始まったことが、Season 1 の結論だ。
読者のもし誰かが、非エンジニアで AI とプロダクトを進めているなら、伝えたい。完璧な設計図は最初から存在しない。存在するのは、毎日の判断の積み重ねだけだ。積み重ねを残す手段——ログ、CHANGELOG、ADR、Release Notes——を早めに用意した人が、最後まで説明できる。
Season 1 を書き終えて思う。一番の変化は、ツールの数ではない。朝の不安の質が変わったことだ。以前は「何も分からない」だった。今は「分からないことが、どこにあるか分かる」。分かることは、解決の半分だ。残り半分は、承認と検証と、また記録だ。ここで終わらない、とは、その残り半分を引き受ける宣言でもある。
GitHub のリポジトリを見る人に伝えたい。docs/qiita/ は体験談、docs/releases/ は事実だ。事実と日記が並んでいるから、再現しやすい。再現しやすいプロジェクトは、一人運営でも育つ。育つとは、機能が増えることだけではない。朝の 10 分が、少しずつ短くなることだ。
6. 学び
- RC はゴールではなく、運用検証の開始地点
- Step49 はコード追加禁止で、毎日使って違和感を記録する週
- 足さない期間があると、違和感の解像度が上がる
- 失敗をログに残すと、次の判断が速くなる
- 連載の終わりと、プロダクトの終わりは別物
- 朝の 10 分は、これからも North Star のまま
- 検証週の記録はリポジトリに残り、連載の先を担う
7. 次回予告
Season 1 はここまでです。Vol.11 の予告はありません。
体験談としての一区切りを付け、運用検証週の記録は docs/operational-validation-week.md と logs/ に残しています。OS 本体の最新は GitHub の docs/releases/v1.0.0-rc1.md を参照してください。連載はここまでですが、朝の Dashboard を開く習慣は、検証週のあとも続きます。続くことが、OS としての正しい完了条件だと思っている。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 10 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回予告
Season 1 完 — ご読了ありがとうございました。運営 OS の物語は、検証週のログに続きます。