# AI に実装を委譲している間に main が動く — 「着手前にPRを確認した」を信用しない ## 誰の問題かコーディングエージェント（Codex / Claude Code / Devin 等）に実装を委譲し、 **戻ってきた成果をそのまま PR にしている**チーム。特に複数のエージェント／セッションを並走させている場合。 ## 症状（この3つが同時に出たら本症状） 1. PR を作ったのに **CI が1本も起動しない**（`gh pr checks` が `no checks reported`） 2. `gh pr view --json mergeable` が **`UNKNOWN` のまま**（`CONFLICTING` とも言ってくれない） 3. リポジトリ全体の直近 run（`gh run list --limit 5`）では、**他ブランチの CI は動いている** つまり「CI が壊れた」ではなく **「あなたのブランチのベースが古い」** 合図。 ## 何が起きているか委譲は数十分かかる。その間に別の担当（別セッション・別エージェント・人間）が **同じファイルを main へマージし得る**。着手前に取った `` のスナップショットは、 **push する時点の正しさを何も保証しない**。実測例: 着手時点で対象ファイルに open PR は無かったが、委譲が返るまでの間に同一ファイルを触る PR が **2本** main に入っていた。 ## 手順 ### 1. push の直前に必ずベースを取り直す ```bash 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 ..origin/main -- <対象ファイル>` を必ず見る - 共有作業ツリーは他セッションが汚しているので、**一時ディレクトリへ fresh clone** して作業する - shallow clone（`--depth N`）だと `git push -u` が remote-tracking を作れず、 PR 作成コマンドが head 明示を要求する。`--head ` を最初から付ける ## 判定チェックリスト - [ ] push 直前に `git fetch` したか - [ ] `git log <着手時SHA>..origin/main -- <対象ファイル>` を読んだか - [ ] rebase 後に**全体テスト**を再実行したか（対象ファイルのテストだけでは足りない） - [ ] CI が実際に起動して green になったか（`no checks reported` を green と読み替えていないか） ---