git index.lock 並行エラーの正体と対処：AIセッションがindexを取り合う事故

複数のAIエージェント（Claude Code等）を同じリポジトリで並行して動かしていると、こんなエラーに遭遇します。

fatal: Unable to create '/path/.git/index.lock': File exists.

もっと厄介なケースもあります。git add A B でステージしたはずなのに、git commit したら別のファイルC D Eが含まれていて、A Bは未コミットのまま残っている。何度見返してもステージ操作は間違っていない。なのに結果がズレる。

これは「たまたまの不具合」ではありません。並行セッションがgit indexを取り合う構造的な競合です。一度起きると、並行運用を続ける限り再発します。

この記事では、並行AIセッション環境で起きる2種類のgit事故と、その対処をまとめます。

結論：git add と git commit を1コマンドで連結し、lockは確認してから消す

要点を先に置きます。

• git add X && git commit -m "..." を1コマンドで連結して、競合の窓を消す
• ステージ後・commit前に git diff --cached --stat で中身を確認する
• index.lock 残骸は、サイズとプロセスを確認してから消す（即rmは危険）
• push済みの汚染コミットはamendせず別コミットで補正する

並行運用が前提なら、「git addしてから別の作業を挟む」のをやめるだけで、事故の大半は消えます。

なお、そもそもセッションごとに作業ディレクトリを分けてしまえば、indexを共有しないので競合の根を断てます。Claude Code × git worktreeで並行作業を分離する方法は別記事で解説しました。本記事は「同一リポを共有したまま運用する」ケースの応急処置と作法です。

事故A：lockファイルの残骸

git操作中はリポジトリに .git/index.lock（＝gitが操作中に作る一時的な鍵ファイル）が作られ、操作が完了すると消えます。ところが次のような状況では残骸として残る。

• プロセスがクラッシュした
• 並行する別セッションが先にロックを取り、こちらが待たされて中断した

ロックが残ると、次のgit操作で「lockが存在する」と弾かれます。

対処：消す前に必ず確認

ロックファイルを即 rm するのは危険です。本当に別プロセスが動いている可能性があるから。次の手順で確認してから消します。

# 1. サイズと更新時刻を確認
ls -la .git/index.lock

# 2. 実際に動いているgitプロセスがないか確認
ps aux | grep -E "git (add|commit|push)" | grep -v grep

# 3. 0バイト かつ gitプロセスなし → クラッシュ残骸なので消してOK
rm .git/index.lock

# 4. 非0バイト or プロセスがいる → 触らず、完了を待つ

0バイトでプロセスもいなければ、クラッシュ残骸で確定。安全に消せます。逆に、ここを確認せず消すとindexを破損させかねません。

事故B：git add と git commit の間にindexが乗っ取られる

こちらの方が厄介です。症状はこうなります。

1. git add A B を実行 → git status では A B がステージされている
2. git commit を実行
3. commitされたのは別のファイル C D E で、A B は未コミット状態に戻っている

原因は、git add から git commit までのわずかな間に、並行する別セッションが git add を実行して共有のindexを上書きしたことです。index（＝次にコミットする内容を一時的に置いておく場所）はリポジトリに1つしかない共有リソースなので、並行操作で取り合いになります。

対処：addとcommitを1コマンドに連結する

git add と git commit を別々に実行すると、その間に「競合の窓」が開きます。1コマンドに連結すれば窓が消えます。

# ❌ 危険: addとcommitの間に窓が開く
git add A B
（ここで別セッションのgit addが割り込む）
git commit -m "..."

# ✅ 安全: 1コマンドで連結
git add A B && git commit -m "..."

さらに、commit前にステージ内容を確認する習慣をつけます。

git add A B
git diff --cached --stat   # ← 何がステージされているか即確認
git commit -m "..."

意図したファイルだけがステージされているか、commit直前に目で見て確かめる。たったこれだけで、乗っ取りに気づけます。

push済みの汚染コミットは「別コミット」で直す

競合に気づかず、間違ったファイルを含むコミットをpush済みだった場合はどうするか。

git commit --amend でメッセージや内容を修正したくなります。しかしpush済みのコミットをamendすると、force-push（＝リモートの履歴を強制的に書き換える操作）が必要になります。force-pushは、他の人が同じブランチで作業していると履歴を壊すので危険です。

なので、push済みの汚染コミットはamendせず、別の補正コミットで修正します。

# ❌ push済みをamend → force-push必要、履歴破壊リスク
git commit --amend

# ✅ 別コミットで補正
git add 正しいファイル
git commit -m "fix: 前コミットの取りこぼしを補正"
git push

履歴は少し増えますが、こちらが安全です。

アンチパターン3つ

アンチパターン1：lockファイルを確認せず即rmする

別プロセスが本当に動いている最中にlockを消すと、indexが破損するリスクがあります。サイズ・プロセスを確認してから消すこと。

アンチパターン2：git addの後に別の作業を挟む

git add してから他のコマンドを実行したりファイルを編集したりすると、その間に並行セッションがindexを上書きする窓が開きます。addしたら即commit。

アンチパターン3：並行セッションの干渉を「偶然」と片付ける

一度起きた競合は、並行運用が続く限り再発します。「たまたま」で片付けず、構造的な問題として捉え、addとcommitの連結を習慣にしてください。

並行運用の予防チェックリスト

複数のAIセッションを同じリポジトリで走らせる前に、次を確認しておくと事故が激減します。本記事の対処を運用ルールに落とした形です。

• git add と git commit を && で連結しているか（間に別作業を挟まない）
• commit前に git diff --cached --stat でステージ内容を目視確認しているか
• index.lock を消す前に ls -la でサイズ、ps aux でプロセスを確認しているか
• push済みコミットの修正でamend（＝force-push必要）を避け、別コミットで補正しているか
• そもそもセッションごとに作業ディレクトリ（worktree）を分けて、indexの共有自体を避けられないか

まとめ：並行運用は「競合の窓」を消す

複数のAIエージェントを並行で動かす環境でのgit運用は、次の4点に集約されます。

1. git add X && git commit を1コマンドで連結する（競合の窓を消す）
2. commit前に git diff --cached --stat で中身を確認する
3. lockファイルはサイズ・プロセスを確認してから消す
4. push済みの汚染コミットはamendせず別コミットで補正する

AIエージェントを並行で走らせるのは強力です。一方で、共有リソース（git index）の競合という新しい落とし穴がある。「addとcommitを離さない」という小さな習慣で、その大半は防げます。

AIエージェントの並行運用でgit競合に悩んでいるなら

複数のAIエージェントを同時に走らせて作業を高速化したいが、ファイルやgitの競合が頻発する。原因が構造的なのか偶発的なのか切り分けられない。社内に並行運用の作法を整備できる人がいない。そんな状況なら、作業フローの設計から見直す価値があります。f2t.jpでは、AIエージェントの並行運用設計と安全な作業フローの整備をお手伝いしています。お問い合わせフォームからどうぞ。