Versionを境界にして新機能追加を止めた理由

1. リード

問題が見えると、何かを足したくなる。私もそうだった。新しい対策、新しい監視、新しい逃げ道。だが RC 検証週では、その反射を意識して止めた。Version を境界にして、新機能追加を止める。この地味な判断がなければ、検証で見えたことの意味がぼやけていたと思う。

2026-07-24 時点の Current Context には、今やってはいけないこととして「新機能追加」「認証方式変更」「v1.0.0 tag」「Issue 自動クローズ」が並んでいる。これは消極的な制限ではない。正式版へ進むために、何を増やさないかを明確にした線だった。

2. 背景

Vol.10 でも書いたように、2026-07-11 からの 7 日間はコード追加禁止で v1.0.0-rc1 を毎日使う期間だった。RC は完成の祝賀会ではなく、完成と言ってよいかを見張る週だったからだ。

ところが、実際に使い始めると摩擦は出る。日次Connector が動いていない。DarkWake で止まりうる。OAuth やネットワークも朝の文脈では違う顔をする。こうした摩擦を見たとき、最も簡単なのは新しい対策を足し続けることだ。だがそれを続けると、「今何を検証しているのか」が見えなくなる。

Vol.11 では一時 No-Go を選んだ。Vol.12 では、手で動く Connector と毎日動く仕組みは別の品質だと分かった。Vol.13 と Vol.14 では、DarkWake や OAuth のように、朝の無人実行でしか見えにくい条件も表に出てきた。つまり RC 検証週は、足りない機能を増やす期間ではなく、今ある構成のままでどこまで言い切れるかを確かめる期間に変わっていた。

3. 今回のテーマ

テーマは、Version を境界にして新機能追加を止めたことで、RC 検証週を「実装の延長」ではなく「判断の期間」として守れたことだ。

止めると言っても、何もしないわけではない。2026-07-24 時点の Current Context にある --wait-for-user-active のように、最小修正は入る。大事なのは、検証の意味を壊すほど話を広げないことだった。

非エンジニアの立場では、ここがかなり分かりにくかった。問題が見えるたびに、新しい打ち手を入れた方が前進に見えるからだ。だが RC 検証週では、前進して見えることと、判断材料が増えることは同じではなかった。むしろ対策を増やしすぎると、何を確認しているのかが曖昧になる。Version の境界は、その曖昧さを止めるために効いていた。

4. 実際の出来事

2026-07-24 時点の Current Context が示しているのは、かなりはっきりした運用姿勢だ。Version 1.0 は No-Go 継続。Issue #11 / #12 の運用フォローアップが残る。直近の修正は launchd 実行だけ --wait-for-user-active を追加した最小修正。そして「今やってはいけないこと」に、新機能追加と認証方式変更が明記されている。

この並びを見ると、RC 検証週で守りたかったものが見えてくる。問題が出たからといって、すぐ別の仕組みへ跳ばない。認証で摩擦があっても方式変更へ行かない。Issue が残っていても、自動で閉じて進んだ形にしない。つまり、前に進んだ感じを作ることより、今の状態を正確に観察することを優先していた。

最小修正を許しつつ、新機能追加を止めるのは少し難しい。境界が曖昧だと、何でも「必要な修正」と言えてしまうからだ。だからこそ Version が要るのだと思う。RC という言葉があると、「今は完成を増やす期間ではなく、完成と言えるか確かめる期間だ」と言いやすい。

ここで重要だったのは、最小修正と新機能追加を同じ箱に入れなかったことだ。--wait-for-user-active の追加は、DarkWake 文脈の朝の実行条件を壊さないための最小修正として扱われている。だがそれは、朝の運用条件をさらに広げる追加機能ではない。もしこの差を曖昧にしていたら、「必要な修正」の名目で何でも足せてしまう。そうなると、RC 検証週は観察期間ではなく、実装の延長へ戻ってしまう。

Issue #11 / #12 の扱いも同じだった。Issue が残っているのに、別の改善をどんどん入れて前へ進んだ形を作ってしまうと、どこまでが確認済みで、どこからが未確認かが見えにくくなる。Current Context が No-Go 継続、運用フォローアップ残、最小修正、禁止事項を並べているのは、その順番を崩さないためだったのだと思う。

認証で摩擦があると、方式変更まで一気に飛びたくなる。ネットワークの揺れが見えると、別の監視や別の制御を入れたくなる。だがこの時点では、それをやらないと決めていた。やらないと決めるのは消極的ではなく、今ある構成のままで、どこまで言い切れるかを守るための積極的な制限だった。

もう一つ大きいのは、「Issue 自動クローズ」を禁止事項に入れていたことだと思う。見た目だけ前進したように整えてしまうと、RC の判断は簡単に甘くなる。Issue が閉じていないこと、検証が残っていること、Version を上げていないことが、そのまま残っているからこそ、止まっている理由を説明できる。説明できる止まり方は、あとで強い。

5. 考えたこと

非エンジニアの立場では、ここがかなり重要だった。技術課題が見えるたびに、新しい打ち手を並べたくなる。並べると一時的には安心する。だが並べた打ち手が多いほど、どれが効いたのか、何がまだ未確認なのかが分かりにくくなる。分かりにくさは、そのまま Version 判断の弱さになる。

新機能追加を止めることは、後ろ向きではなかった。むしろ「今あるものに責任を持つ」ための前向きな制限だったと思う。追加を止めると、見えている問題から逃げにくくなる。逃げにくくなるから、Issue と既知の制限を正面から書ける。書けるから、No-Go も一時停止も説明しやすくなる。

AI と一緒の開発では、追加案はすぐ出る。だからこそ、止めるルールを先に持っておく価値がある。人間の勢いも、AI の提案量も、境界がないと簡単に膨らむ。Version は、その膨らみを抑えるための技術ラベルでもあった。

私は最初、Version を「ここまで作った」というラベルとして見ていた。だが RC 検証週で見えたのは、Version が「ここから先は増やさない」と言うためにも使えることだった。機能一覧を増やすための記号ではなく、観察対象を守るための線になる。これはコードを書かない立場でもかなり理解しやすい。増やさないと決まっていれば、今朝見えている問題を、別の話で上書きしにくくなるからだ。

Human Approval の思想とも少し似ていると思う。本番の書き込み操作では、実行できることと、実行してよいことを分けていた。RC 検証週でも、思いつけることと、今やってよいことを分けていた。やれる改善はまだあったかもしれない。だがその場で全部やることが、必ずしも品質を強くするわけではない。境界を残すことで、判断と実装を同じ流れにしないようにしていたのだと思う。

毎朝の無人実行を前提にすると、この線引きはさらに重要になる。朝の不安に対してすぐ別の対策を足すと、一時的には安心する。だが翌朝また別の揺れが見えたとき、何が効いたのか、どこまでが既知の制限か、何がまだ未確認かが混ざりやすい。RC 検証週で本当に守りたかったのは、安心感そのものより、安心してよい根拠を混ぜないことだった。

6. 学び

• Version は機能一覧ではなく、何を増やさないかを決める境界にもなる
• RC 検証週で新機能追加を止めると、観察している対象がぶれにくい
• 最小修正と機能追加を分けて考えないと、検証結果を解釈しにくくなる
• 問題が見えたときほど、追加案より現在地の言語化が重要になる
• AI と一緒の開発では、止めるルールがないと提案量に流されやすい

7. 次回メモ

この続きで書くなら、Issue が残るうちは「解決済み」と書かない姿勢へつながる。Version 管理は、言い方の誠実さとも直結していたからだ。