寝ている間にAIに仕事をさせる前に決めたこと

AIに「寝ている間に仕事を進めておいて」と頼めたら、朝起きたときに仕事が片づいている。小さなチームにとって、これは魅力的な話だ。

実際に自社で作った。毎晩、検知系が見つけた課題を拾い、処理できるものは処理し、翌朝にはDraft PRが並んでいる。夜間クエスト自走ランナーと呼んでいる仕組みだ。

ただ、設計するときに最初に議論したのは「何をやらせるか」ではなかった。「何をやらせないか」だった。

夜中に動くとは、止められないということ

日中なら、Slackの通知を見て「それ止めて」と言える。画面を見て「おかしい」と気づける。

夜中にAIが自走しているとき、その安全弁が全部外れる。外れた状態で動くのだから、安全弁がなくても事故にならない範囲でしか動かしてはいけない。当たり前の話だが、「何ができるか」から入ると、この当たり前が後回しになる。

3つの条件を全部満たすものだけ、自走させる

夜間ランナーに自走を許す条件は3つで、全部同時に満たす必要がある。

• gitで戻せる——コードや台帳の変更で、revertすれば元に戻る
• 外に出ない——メール、SNS投稿、外部APIへの書き込みがない
• 契約に触らない——請求、支払い、権限変更、削除を含まない

この3つを全部満たす作業だけが「safe-class」。台帳の更新、docsの整備、仕分け、下書き生成がこれにあたる。ひとつでも外れた瞬間、safe-classではなくなる。

逆を言えば、safe-classを外れたものは、どれだけ簡単に見えても「人ゲート」に回す。夜中の3時にAIが「これくらい大丈夫だろう」と判断することを、設計として許さない。

止める手段を、いちばん先に用意する

夜間ランナーの設計で最初に作ったのは、キルスイッチだった。

リポジトリのルートに1つファイルを置くだけで、ランナーは何もせず終了する。個別のタスクに「hold」ラベルを付ければ、そのタスクだけ飛ばす。

自動化を作るとき、「どう動かすか」から入りがちだが、「どう止めるか」のほうが先に要る。夜中に動くものは特にそうで、止め方が簡単でなければ、枕元でスマホを構えて監視する羽目になる。それでは自動化した意味がない。

やったことの上限は、Draft PRまで

ランナーがsafe-classの作業を終えたあと、やるのはDraft PRを作るところまでだ。マージはしない。

つまり、朝起きたらDraft PRが並んでいて、中身を見て「これでいい」と思えばマージする。「おかしい」と思えばクローズする。最終的に本線に入れるかどうかは、人が決める。

自動化の信頼は段階で積む。最初から「全部お任せ」にすると、うまくいっている間は楽だが、事故が起きたときの被害が大きい。まずはDraft PRまで。実績が溜まったら、条件付き自動マージに昇格する。段階を飛ばさない。

報告は1行、例外なく

ランナーが1サイクル終わったら、1行だけ報告する。「PR何件・人ゲート何件・持ち越し何件」。

詳しいログは見たければ見に行ける。でも毎朝の確認は1行で済むようにする。情報が多すぎると、毎朝確認する習慣が崩れる。習慣が崩れると、夜間ランナーが何をしているか誰も見なくなる。見なくなった自動化は、壊れていても気づけない。

今回の線引き

• 無人時間帯の自走は「gitで戻せる・外に出ない・契約に触らない」の3条件を同時に満たすものだけ
• 自動化の設計は「どう動かすか」より「どう止めるか」を先に決める
• 信頼の昇格は段階的に。Draft PRまで→条件付き自動マージ→……と、飛ばさずに積む