Go判定を変えたのは新機能ではなく運用条件だった

1. リード

一時 No-Go になったあと、次に必要なのは新機能だと思いやすい。私も最初はそう感じていた。だが 2026-07-26 に v1.0.0 を正式 Go にした根拠は、別の大きな機能ではなかった。運用条件を最小差分で詰め直し、その条件で無人の朝をもう一度確かめたことだった。

Current Context には、RC 検証週の最終判定として「Day 7 の一時 No-Go を経て、2026-07-26 の最終無人検証で Go」とある。同じ文脈で、重大バグ累計 1 件は解消済み、最終無人検証では DarkWake 中に Connector を開始しないこと、通常 Wake 後に GA4 / GSC / Clarity が success だったこと、Metricool は既知許容の partial で 7 / 7 保存だったこと、wrapper exit code 0、stderr 空、全 178 tests passed も確認されている。今回は、この「何を足したか」ではなく「どの条件で Go と言えるようになったか」の話だ。

2. 背景

Vol.11 では、7 日使った上で一時 No-Go を選んだことを書いた。Vol.12 では動く Connector と毎日動く仕組みは別だと書いた。Vol.13 と Vol.14 では、Mac の睡眠や OAuth のように、昼に見えにくい条件が朝の無人実行では前面に出ることも見えてきた。つまり RC 検証週で止まっていた理由は、単一の派手な故障ではなく、毎朝任せるための条件がまだ言い切れないことだった。

Current Context では、その後の整理も明確だ。Step49.1 で launchd による Daily Connector Automation を導入し、そのあとも新機能追加ではなく最小差分で運用条件を詰めた。並んでいるのは DNS / 一時通信障害の有限再試行、Metricool の非対話 OAuth refresh、DarkWake 除外、launchd 実行時の通常 Wake 待ちだ。ここで重要なのは、完成を派手に作り替えたのではなく、朝に必要な前提を一つずつ確認可能な形へ寄せたことだった。

3. 今回のテーマ

テーマは、v1.0.0 の Go 判定を変えたのは新機能追加ではなく、運用条件の明確化と再検証だったということだ。

機能追加は成果として見えやすい。だが Go / No-Go の判断に必要なのは、何が増えたかより、何が説明できるようになったかだと思う。無人実行の朝に何が起きるか、そのとき既知の制限をどう扱うか、どこまでを成功として数えるか。そこが曖昧なままでは、機能が増えても Go にはしにくい。

4. 実際の出来事

Current Context によると、最終無人検証で確認された事実はかなり具体的だ。DarkWake 中は Connector を開始しない。通常 Wake 後には GA4 / GSC / Clarity が success。Metricool は partial だが既知許容として 7 / 7 保存。wrapper exit code は 0、stderr は空、そして全 178 tests passed。これは「だいたいうまくいった」ではなく、朝の運用で見たい条件を列挙して確認した記録に近い。

この並びの中で特に大きいのは、partial を失敗と混同しなかったことだと思う。Current Context には、Metricool は未提供指標がある場合 partial を仕様として許容するとある。つまり、認証失敗、通信障害、仕様上起こりうる欠けを一緒くたにせず、どこまでなら朝の運用として受け入れるのかを先に置いていた。Go 判定を支えたのは、完璧そうに見せる数字ではなく、成功条件と許容条件を分けた整理だった。

もう一つ大きいのは、Step49.1 以降の修正が最小差分にとどまっていることだ。launchd を入れたあとも、DNS の有限再試行、OAuth の非対話 refresh、DarkWake 除外、通常 Wake 待ちといった運用条件の調整に集中している。Current Context でも、v1.0.0 の Go 判定は新機能追加ではなく運用条件の明確化と再検証で成立したことが重要だと明記されている。ここまで書かれていると、Go は勢いで決めたのではなく、条件が並んだので言い切れたのだと分かる。

さらに、正式化のあとに v1.1.0 で UI 改善だけを積んだことも、この Go 判定の読み方を補強している。もし v1.0.0 の Go に新機能追加が必要だったなら、直後の整理ももっと混ざっていたはずだ。だが実際には、v1.0.0 は運用条件を詰めて Go にし、その先の v1.1.0 では Dashboard の見え方だけを改善している。Version の切り分けが残っているからこそ、どの段階で何が根拠だったかを読み分けやすい。

運用条件の整理で効いているのは、成功だけを数えることではない。どこまでを既知の制限として受け入れるか、どこからを Go の妨げとみなすか、線を先に持つことだ。DarkWake 除外も通常 Wake 待ちも、その日の都合で場当たり的に増えたルールではなく、朝の無人実行に必要な前提を明文化したものとして Current Context に残っている。

この残り方は大事だと思う。もし条件の整理が会話の中だけにあり、最終判定の文書へ落ちていなければ、何が Go の理由だったのかはあとでかなり曖昧になる。だが実際には、最終無人検証で何を確認したか、既知の制限をどう扱うか、どの最小差分が必要だったかが並んでいる。だから Go は気分ではなく、確認済み条件の束として読み取れる。

最終無人検証で wrapper exit code 0 と stderr 空まで確認しているのも地味だが強い。表向きの成功だけでなく、実行の終わり方まで含めて見ているからだ。非エンジニアの立場では、成功画面だけ見て安心しがちだが、朝の自動運用では裏側の実行結果も条件に入ってくる。その条件が文章として残っていると、任せてよい理由がかなり説明しやすい。

5. 考えたこと

非エンジニアの立場では、No-Go のあとに必要なのは「もっと強い何か」だと思いやすい。新機能、新しい監視、新しい設計変更。だが今回の Current Context を読むと、Go に必要だったのは強い新要素ではなく、朝に任せるための条件を曖昧にしないことだった。これは少し意外で、かなり大きな学びだった。

条件を詰める作業は、機能追加より地味だ。だが地味だからこそ、説明責任に向いているのだと思う。DarkWake 中は開始しない。通常 Wake を待つ。Metricool の partial は仕様として許容する。DNS や一時通信障害には有限再試行で向き合う。こうした条件は、一つずつは派手ではないが、朝の「今日は任せてよいか」を支える線になる。

Human Approval の考え方とも似ている。押せることと、押してよいことを分ける。動くことと、任せてよいことを分ける。v1.0.0 の Go でも同じで、機能があることと、正式版として説明できることは別だった。今回 Go を変えたのは、何かをたくさん作ったからではなく、任せてよい条件を文章と検証で揃えたからだったのだと思う。

ここには Version の強さも出ている。Version を上げる前に条件を詰め、Version を上げたあとに別テーマの改善へ進む。順番が守られているから、どの改善が正式化の根拠で、どの改善がその後の使いやすさ向上だったのかが混ざらない。条件整理と新機能追加を同じ箱に入れなかったこと自体が、Go 判定を強くしていた。

私は最初、条件を詰める作業を「本質に入る前の地味な調整」だと少し見ていた。だが今は逆で、毎日任せる仕組みではそこが本質なのだと思っている。派手な新機能は注目を集めやすいが、朝 06:30 に本当に必要なのは、起動条件、許容条件、終了条件が説明できることだ。説明できる条件が積み上がって初めて、Go は言い切りやすくなる。

6. 学び

• No-Go のあとに必要なのは、必ずしも新機能追加ではない
• Go 判定は「何を足したか」より「どの条件で任せてよいか」を説明できるかで変わる
• partial を失敗と混同しない整理が、無人運用の判断を強くする
• 最小差分で運用条件を詰めると、何が Go の根拠だったかを追いやすい
• Version を分けて記録すると、正式化の根拠と次の改善テーマを混同しにくい

7. 次回メモ

この続きで書くなら、v1.0.0 正式化のあとに v1.1.0 で UI 改善だけへ範囲を絞った判断につながる。Go を決めた根拠と、その次に改善したものがきれいに分かれていたからだ。