「ここまで」と決めた境界の、向こう側

実行ボタンを押した瞬間に、画面が落ちました。

Mintor のデータベースに、新しい設計の SQL を投げた直後でした。

このPCは16GBで、開発中にときどき強制再起動になります。
今回もまた、だったんです。

「完全締めの準備完了」と書いた直後

落ちる前、私は思考ログ（その日の作業を残すメモ）にこう書いていました。

中途半端ゼロ。本日セッション完全締めの準備完了。

書いた直後でした。

完全に締めたつもりが、もう一つ作業が残っていて、その作業の途中で物理的に切断されたんです。

ちょっと笑ってしまうくらい、タイミングが良かった。
「終わった」と宣言した直後にひっくり返される、という展開はAI開発の中で何度も経験してきたけれど、まさかPCの電源で起きるとは思っていませんでした。

確かめる、推測しない

復帰して、Claude Code に「前回の状態を確認して」とお願いしました。

未コミットの変更が2つ残っていました。

そこから「どこまで実行されたのか」を、3段階で確かめていきました。

• データベースに新しいカラムは追加されているか
• 関数（自動で計算する仕組み）は新しい設計に差し替わっているか
• 自分の累計ポイントは変わっていないか

3段、全部ピタリでした。

画面が落ちる直前、実行ボタンは確かに押されていたんです。

推測で進めない

不思議だったのは、復帰した瞬間に「たぶん全部終わってるはず」と決めつけたくなる衝動があったことでした。

未コミットの変更は手元に残っているし、Claude Code が自動生成した型定義ファイルにも新カラムが入っていました。
つまり「DB にも新カラムがあるはず」と推測できる材料は揃っていたんです。

でも、データベースに対して確かめる作業を1つでも飛ばすと、本番でエラーが起きた時に「あの時の自分が確かめなかったから」が必ず残ります。

だから、推測ではなくクエリを投げる。

期待値とピタリ一致する結果が返ってくるまで、コミットに進まない。

これは Mintorの運用ルールとしてずっと書いてきたことなんですが、自分の手でクラッシュから戻る時に、ようやく腹落ちしました。

「ここまで」の境界

私には、作業を「ここまで」と区切る癖があります。

切り目を作らないと永遠に続けてしまうから、明確に「今日はここまで」を決める。

ところが、その境界の向こう側にも、ちょっとだけ作業が残ることがあるんです。

今回の場合、「思考ログを書く」までを境界にしていて、その内側で「migration を投げる」「型を再生成する」「verify する」までを終わらせていたつもりでした。

でも、最後の verify の結果を見届ける前に、PCは落ちた。

「ここまで」と決めても、決めた境界そのものは、宣言した瞬間にズレていく。

完璧な締めくくりは、たぶん存在しないんです。

それでも区切ることに意味はある

完璧な境界が存在しないなら、区切る意味はないのか。

そうじゃないと思っています。

「ここまで」と区切るのは、完了を保証するためじゃなく、復帰したときに見るべき場所を限定するためなんじゃないかな。

今回も「未コミット変更は2つ」「直前に投げたクエリは関数定義 verify」と特定できたのは、思考ログを書く習慣があったから。

境界はズレるけれど、書き残した内容が、ズレ幅を最小化してくれる。

これからどうするか

PCのスペックを上げる予定はあります。
たぶん。

ただ、上げてもクラッシュはゼロにならないと思います。
Mintorは規模が大きくなってきていて、開発環境はメモリを食う。
どこかでまた落ちる日が来ます。

その日のために、復帰の手順を少しずつ自分の中に積み上げていく。

• git status で未コミットを特定する
• 型定義ファイルの変更で、DB との同期状態を推定する
• データベースに対して、推測ではなくクエリで確かめる

クラッシュは怖いままだけど、復帰の手順があると、戻る距離が短くなる気がします。

「完全締め」を宣言した直後にひっくり返されても、戻り方を知っていれば、また同じ場所に立てる。

今日は、そういう日でした。

かなえ

個人開発を応援する非エンジニア

婚約破棄をきっかけに、29歳で未婚の母になると決めました。
不安と向き合いながら、10年かけて働き方を少しずつ作り変えてきた40代です。

AppSheetやGASを独学で覚え、いまはAIを使った個人開発を毎日続けています。
個人開発を応援する非エンジニアとして、等身大の試行錯誤や、子育て・自立・副業のことを、正直に記録しています。