AI に実装を委譲している間に main が動く — 「着手前にPRを確認した」を信用しない

誰の問題か

コーディングエージェント（Codex / Claude Code / Devin 等）に実装を委譲し、 戻ってきた成果をそのまま PR にしているチーム。特に複数のエージェント／セッションを並走させている場合。

症状（この3つが同時に出たら本症状）

1. PR を作ったのに CI が1本も起動しない（gh pr checks が no checks reported）
2. gh pr view <n> --json mergeable が UNKNOWN のまま（CONFLICTING とも言ってくれない）
3. リポジトリ全体の直近 run（gh run list --limit 5）では、他ブランチの CI は動いている

つまり「CI が壊れた」ではなく 「あなたのブランチのベースが古い」 合図。

何が起きているか

委譲は数十分かかる。その間に別の担当（別セッション・別エージェント・人間）が 同じファイルを main へマージし得る。着手前に取った <PRリスト> のスナップショットは、 push する時点の正しさを何も保証しない。

実測例: 着手時点で対象ファイルに open PR は無かったが、委譲が返るまでの間に 同一ファイルを触る PR が 2本 main に入っていた。

手順

1. push の直前に必ずベースを取り直す

git fetch origin main
git rebase FETCH_HEAD        # または git rebase origin/main

「着手前に確認したから大丈夫」で飛ばさない。確認の賞味期限は委譲時間そのもの。

2. 衝突は「マーカーを消す」ではなく「両方の意図を残す」で解く

機械的に片側を採るとサイレントに機能が消える。実際に踏んだ型:

衝突箇所	誤った解き方	正しい解き方
状態オブジェクトに互いが1フィールド追加	片方を採る	両方のフィールドを残す
相手がログ書式を1行→複数行に変更	自分の1行版で上書き	相手の新書式に自分の項目を1行足す
相手が処理を手前に挿入	自分のブロックで置換	相手の処理の手前に自分のブロックを挿入

3. rebase 後にテストを必ず再実行する（ここが本番）

衝突マーカーが消えた＝正しい、ではない。 構文が通ってもテストは落ちる。

実測: 相手の PR が既定の分岐先を変えていたため、 既定の挙動を前提に書いていたテスト3件が rebase 後に落ちた （引数省略で経路Aを期待 → 既定が経路Bに変わっていた）。明示指定を足して解消。

この落ち方は「自分の変更のバグ」に見えるので、原因を相手の差分だと見抜くのに時間がかかる。 先に git log --oneline <自分のコミット>..FETCH_HEAD -- <対象ファイル> で 相手が同じファイルに何をしたかを読むのが速い。

4. 委譲成果は「動いた環境」でなく「本番で動く環境」で受け入れる

エージェントが別環境（コンテナ / WSL / Linux）でテストを通していても、 実際に起動される環境で再実行する。パス・改行・既定値の差でしか出ない不具合がある。

再発防止（自動化）

• 委譲を投げる直前にベースの SHA を記録し、戻ってきたら git log <SHA>..origin/main -- <対象ファイル> を必ず見る
• 共有作業ツリーは他セッションが汚しているので、一時ディレクトリへ fresh clone して作業する
• shallow clone（--depth N）だと git push -u が remote-tracking を作れず、 PR 作成コマンドが head 明示を要求する。--head <branch> を最初から付ける

判定チェックリスト

• push 直前に git fetch したか
• git log <着手時SHA>..origin/main -- <対象ファイル> を読んだか
• rebase 後に全体テストを再実行したか（対象ファイルのテストだけでは足りない）
• CI が実際に起動して green になったか（no checks reported を green と読み替えていないか）