並走するAIセッションが同じ目的を二重着手する事故を止める

複数の AI コーディングセッション（別ウィンドウ・別タブ・夜間の無人実行）を同時に走らせている環境で、 2つのセッションが同じ作業を同時に始めて、同じファイルを互いに書き潰す事故を検知して回収する手順。

何が起きるか

引き継ぎファイル（前のセッションが「次にやること」を1件だけ書き残す運用）を採用していると、 同じ引き継ぎを読んだ2つのセッションは必ず同じ目的を選ぶ。結果:

1. 同じ新規ファイルを両方が作り、後に書いた方が前の方を消す（気付く手がかりは git status に「自分が触っていないファイル」が現れることだけ）
2. レート制限のある外部 API のクレジットを食い合って両方が 429 になる。 片方が待って再試行しても、もう片方が同じ窓のクレジットを焼くので回復しない
3. 同じ結論に到達するまでのトークンを2重に払う

引き継ぎに「並行セッションが X を作業中なので X に触るな」と書いてあっても防げない。 警告に書かれた領域の外側にある「次の1目的」こそが衝突する。

排他ロックでは防げない理由

資源単位のロック（db / deploy / config のような粒度）を実装していても、 ロックはファイルを守らない。両セッションがロックを取らずに同じソースファイルを書けてしまう。 ファイル単位のロックまで作るのは現実的でないので、着手前の検知で止める。

検知の3点セット（コードを1行も書く前に実行する）

# 1. 対象ファイルの更新時刻。数分前なら並走している
ls -l --time-style=full-iso <対象ファイル>

# 2. 自分が起動していない対象スクリプトが動いていないか
#    (Windows/PowerShell)
Get-CimInstance Win32_Process -Filter "Name='node.exe'" |
  Select-Object ProcessId, CreationDate, CommandLine
#    (macOS/Linux)
ps -eo pid,lstart,args | grep -v grep | grep <対象ファイル名>

# 3. 自分が触っていないファイルが変更されていないか
git status --short

引き継ぎに「新規作成」と書かれていても、ファイルが既に存在するなら中身を読む。 存在すれば、それは並走の証拠か、あるいは前のセッションが途中まで作った実体である。

衝突していたときの正しい振る舞い

実装を譲る。 判断基準は先着でも行数でもなく実装の質。 例: 片方が「ページ単位で取得結果をディスクに残す」実装で、もう片方が「毎回1ページ目から取り直す」 実装だったなら、前者を残す（レート制限に当たったとき、後者は永久に完走できない）。

譲ったあと、そのセッションは何もせず閉じてはいけない。次のどれかを仕上げる:

• 外部 API を使わずに確定できる部分を仕上げる。多くの場合これが一番価値が高い（次節）
• 相手が書けない永続知識（恒久メモリ・ドキュメント）に、確定した事実を書く
• 相手の実装を査読する（自分は同じ問題を考えたので、査読者として最も適格）

併せて効く教訓: データを取る前に主張の出どころのコードを読む

「過去平均と比べて N ポイント遅れている」のような数値の主張を検証する仕事では、 データを取り直す前にその数値を出しているコードを読む。

実例: 「比較相手の平均が特定イベント期間のデータで汚染されている」という疑いを検証する依頼で、 集計スクリプトを読んだら取得範囲がそのイベント期間より後から始まっていた。 つまり汚染は構造的に成立しない。API を1回も叩かずに前提を否定できた。

• 検証すべきは「データがどうか」ではなく、まず「そのコードが実際に何を読んでいるか」
• 取得範囲（from / to）と、比較相手の集合を定義している行を必ず突き合わせる
• ここで前提が崩れれば、重い集計をゼロから書く必要がなくなる

検証ツール側の作り方（このパターンで必ず要るもの）

• 分母を必ず出力する。「取得総件数 / 有効件数 / 除外件数（理由ごとの内訳）」を先頭に出す。 分母が無いと「全件一致」「該当0件」が、成功なのか入力欠損なのか区別できない
• 比較の窓の手前を余分に取る。期間で絞る API は「開始日以降に始まったもの」しか返さないので、 窓の直前に始まって窓に入り込むレコードを丸ごと落とす。落ちると対象期間が実際より低く出る
• 判定を exit code にする（差が閾値未満なら 0、以上なら 1）。人間が表を読んで解釈する形にすると、 次のセッションが同じ表を読み直して違う結論を出す
• レート制限にはページ単位のディスクキャッシュ。途中で 429 になっても取れた分を捨てない。 再実行で足りないページだけ取りに行く

チェックリスト

• 着手前に 対象ファイルの mtime / 実行中プロセス / git status を見た
• 引き継ぎが「新規作成」と言っていても、存在するファイルは中身を読んだ
• 数値の主張の検証なら、データより先にその数値を出しているコードを読んだ
• 検証ツールは 分母 / 窓の手前 / exit code / ページキャッシュ を備えている
• 衝突していたら、質の高い実装を残し、自分は API 不要の部分と査読に回った