自動化の翌朝、botはgitで死んでいた

何が起きたか

8月26日と27日の夜、リプライ相手を探す仕組みに続けて改修を入れました。掲載済みの相手を記録する台帳を増やしたり、「証拠のない投稿」を下に回すフラグを足したり。夜の手動実行はどちらも問題なく通りました。

8月27日の朝、毎朝のキューが出ていない。28日の朝も出ていない。投稿のほうも動いていない。2日間、静かに止まっていました。

AIの診断（1回目）

Codeに調べさせました。返ってきた診断はこうです（要約）。

推定原因はコードではなく「定時実行が発火していない」。根拠は、同じコードが手動実行では成功していること、失敗なら残るはずの部分的な痕跡（支出の加算・実行ログ）が一切ないこと、独立した2つの処理が同時に沈黙していること。GitHub Actionsの定時実行は毎時0分・10分などの混む時刻で遅延やスキップが起きやすい。

筋は通っています。ぼくも一度はそう思いました。

ただし末尾にこう書いてありました。「発火して失敗した可能性をリポジトリの中からは完全に排除できない。確定にはActionsの画面の目視が必要」。

画面を見た

見に行くと、実行は存在していました。失敗として。

ログを読むと、コミットまではランナーの中で成功しています。その直後の git pull --rebase が「unstaged changes（コミットされていない変更）がある」と言って拒否し、終了コード128で落ちていました。

つまり、スクリプトが書き換えたファイルのうち、ワークフローの git add の一覧に入っていないものがあった。27日の夜に増やした著者の台帳（shown_authors.jsonl）です。コミットされない変更が残ったまま同期できず、ランナーごと消えるので、リポジトリには何も残らない。

追記（2026年8月31日）: Actionsの一覧で27日の分を確認しました。27日の朝は、実行そのものが存在していませんでした。定時実行が発火していない──AIの1回目の診断は、この日の分については当たっていました。28日の分は6時間半遅れて発火し、gitで死んでいた。原因は2つあり、修正はたまたま両方に効いていました（時刻を端数の分にずらしたのが27日型に、git add の一覧が28日型に）。「外れた」と書いた診断は、半分は正しかったことになります。

「痕跡がゼロだから動いていない」というAIの読みは、ここで外れます。動いて、消えていたので痕跡がゼロだった。リポジトリの中からだけでは、「動かなかった」と「動いて push前に死んだ」は区別がつきません。

直したこと

Codeに出した指示は4点です。

1. git add を「スクリプトが出力し得る全ファイルの明示リスト」に更新する
2. コミットのあと pull --rebase --autostash（コミットされていない変更を一時退避してから同期する）に変える
3. 投稿側は、投稿の前に同期を済ませる順序にする。投稿に成功してから同期に失敗すると、翌日に同じものをもう一度投稿してしまうので
4. 定時実行の時刻を、混む0分・10分から端数の分にずらす

直した翌日の8月28日、手動で一度通し実行して、キューが出ることを確認しました。その日の夕方、初めて機械がぼくの代わりにXへ投稿しました。

残った弱さ

「出力し得る全ファイルの明示リスト」は、次に出力ファイルを増やした瞬間に同じ事故が起きる構造です。git add -A（全部拾う）にすれば消えますが、意図しないファイルが混ざるリスクと引き換えなので採用しませんでした。

代わりに、決定記録に1行だけ規約を残しました。「スクリプトの出力ファイルを増やす改修は、ワークフローの git add リスト更新をセットで行う」。

8月30日、ボードに週次報告を足す改修で出力ファイルが1つ増えました。Codeはこの規約を読んで、同じコミットで git add リストを更新しました。31日の朝、定時実行は通っています。

ぼくが覚えておくこと

AIの診断は、与えた材料の範囲でしか正しくなりません。今回の材料はリポジトリの中身だけで、実行画面はぼくしか見られなかった。「確定にはあなたの目視が必要」と書いてあった一文を、ぼくが読み飛ばさなかったのが分かれ目でした。

自動化して最初に増える仕事は「動いているかを見ること」でした。止まったのは2日ですが、気づくまでにかかったのは2日でした。