あなたが眠っている間のエージェント：ランタイムは些細、パイプラインが難しい

AIエージェントで構築しているすべての開発者が同じ午前3時の幻想を抱いたことがある。あなたは眠る。エージェントの艦隊がバックログを拾い、バグを修正し、機能を構築し、朝には小さくてテスト済みでよく説明された変更の山をレビューする。悪い朝には、災害をレビューして捕まえてよかったと思う。

これを現実にしようとしてきて、当たり前に聞こえることを苦労して学んだ：エージェントのプロセスを生かし続けるのは些細だ。作業パイプラインが本当の問題だ。

ランタイムは週末プロジェクト

エージェントを24時間稼働させ続ける方法は四つあり、どれも難しくない：

tmux — 対話型エージェントが切断やSSHログアウトを生き延びる
cron + プリントモード — タイマー上の pi -p "check the failing tests"、きれいに終了するワンショット実行
RPCモード — 別のプログラムが話しかける長寿命プロセス
SDKデーモン — 自分のNodeプロセスにエージェントを埋め込み、キューをループする

これらのどれも七十二時間連続で動いて文句を言わない。そしてどれも有用なコミットを一つも生み出さない。なぜなら問いは決して「どうやってプロセスを生かし続けるか？」ではなかったからだ。それは：

エージェントは何を作業するのか？
doneとは何か？
作業はどう着地するのか？
複数のエージェントはどうお互いを踏みつぶすのを避けるのか？

これら四つをタスクソース、doneの定義、着地ゲート、アロケータと呼ぶ。

約300回の実行が踏みつぶし部分について教えてくれたこと

私はgitaccordを構築している。複数のAIエージェントが一つのリポジトリで並行して作業できるようにするgit hooksだ。それは実験で繰り返し見た失敗のせいで存在する：複数の有能なエージェントに同じリポジトリを与え、プレーンなgitで機能を選び自分の作業を着地させる——中央の人間マージ権限なし。エージェントはマージコンフリクトをうまく解決する。それが危険ではない。

危険なのは最後に着地したエージェントが静かに別のエージェントの機能を自分に合わせて書き換え、テストを調整し、成功を報告することだ。私たちのスパイクでは、Claude Code（Sonnet）とpi（GLM）で約300回の実行のうち、プレーンgitでそれが24–28%の実行で起きた。どこにも悪意はない。各エージェントは行儀の良い単独エージェントがすべきことを正確にやった。失敗は構造的だった：エージェント同士の計画と推論が見えなかったので、「merge」が静かに「overwrite」になった。

gitaccordの修正は意図的に退屈だ。エージェントごとに一つのブランチ。すべてのエージェントが読むタスクごとの計画ファイル。すべてのコミットに推論を説明するWhy:行。別のエージェントの機能を壊す変更の着地を拒否するpre-pushゲート。ただし人間レビュー用のOverride:として宣言された場合を除く。同じ約300回の実行で：静かな上書きは**0%**になり、mainは決して壊れたまま残らず、勝ち目のない決定はすべて人間にフラグされ、静かに解決されなかった。

だから四つの部品のうち、着地ゲートとアロケータは解決可能だと言える——主に慣習とhooksで、新しいプラットフォームではなく。

実際に夜間にうまくいく仕事

制約はエージェントの能力ではない。doneが機械でチェック可能かどうかだ。眠っている人間は午前3時に「これがあなたが意図した機能か？」と聞けない。

うまくいくもの：

失敗する再現付きのバグ修正。 赤いテストが緑になり、フルスイートが通り、diffが小さい。
既存コード上のテストカバレッジ拡大——カバレッジが上がり、振る舞いが変わっていないことが証明される。
人間が書いた計画からスライスされた小さく完全に指定された機能。
依存関係のアップグレード、スイートが決める。
トリアージ——バグレポートを再現し、失敗するテストを書き、ブランチ上で修正をドラフトする。着地さえする必要がない。

夜間にうまくいかないもの——多くの24/7エージェントの夢が静かに死ぬ場所：

「次に何を構築するか考えろ。」 オープンエンドの方向には機械でチェック可能なdoneがない。正しい形はある：エージェントがブランチ上で提案 + spike + 失敗する受け入れテストを書き、着地させない。朝に方向を承認する。着地の自律性は常に簡単な問題だった；方向の自律性こそあなたが保持すべきものだ。

夜間ループ

うまくいくときの全体像：

夕方            夜                               朝
─────────          ──────────────────────────────      ──────────────
人間が書く/      エージェントがタスクNを選ぶ          人間がダイジェストを読む：
バックログを剪定 ──▶ 計画を書く                       ▸ 何が着地したか
                   実装、テスト、コミット              ▸ フラグされた上書き &
                   mainをマージ、ゲートを通る            勝ち目のない決定
                   タスクN+1のために繰り返す …         ▸ 方向待ちの提案

朝まで生かし続けるルール：

小さなタスク。 長い自律実行はコンテキストドリフトで腐る。タスクごとに一つのバグ、機能ごとに一つのスライス。
有界な自律性。 夜ごとの上限、実行ごとの予算、エージェントごとのブランチ。失敗したタスクは記録され、ループはスラッシングせずに進む。
読まなければならない一つの出力： フラグキュー。システムの仕事はそのキューを短く高シグナルにすること——Override:と勝ち目のない決定——朝のレビューが時間ではなく分になるように。

しかし本当のエンジニアリングがどこに住んでいるかに注意。デーモンループは百行だ。バックログ形式、アロケータ、ダイジェスト生成器——人間の方向とエージェントの実行の間のその接着剤が本当の構築だ。ほとんど誰もそれを製品化していない。なぜならみんな（私も）エージェントのランタイムを磨いて足止めされているからだ。

正直なところ、私はどこにいるか

まだ夜間ループは動いていない。難しい中間部分は進行中：人間のゲートがないときにエージェントが互いの仕事を壊すのを止めるhooksと慣習。ランタイムのオプションはそこに準備できている。欠けている部分は退屈なパイプライン——そして私の計画はまずgitaccord自体でそれを走らせること：スパイクから本物の実装への各hookの移植のバックログは自分で書き、夜間エージェントが何かを壊したら、自分の着地ゲートがそれを学ぶ最も安い場所になる。

あなたから聞きたいこと

無人でエージェントを走らせたことがある——またはしないと決めた——なら、どこで壊れたか聞きたい：

ジョブソースは何か？バックログファイル、GitHub issues、それ以外？
doneの定義はどんな感じで、エージェントは抜け穴を見つけたか？
作業をmainブランチに着地させたか、朝のレビュー用にキューに入れたか？
誰か良いタスクアロケータ / ダイジェストツールを出荷したか、それともみんな手作業か？

ランタイム戦争は終わった。パイプラインが勝ち負けの場所だ。