並列ブランチ問題
概要
Claude Code（またはClaude Webのリサーチプレビュー）で複数のタスクを並列実行しそれぞれがPRを作成した場合、同じファイルの同じ位置を変更しようとするとコンフリクトが発生する。
実際に起きたケース
状況
urawa.jsonファイルに財務データを追加するタスク：
- 元のファイル: 2024年のデータのみ
- 追加したいデータ: 2023年、2022年、2021年
実行方法
Claude Codeリサーチプレビュー（Web版）で3つの別々のセッションを作成し、それぞれに依頼：
- 2023年のデータを取得してPR作成
- 2022年のデータを取得してPR作成
- 2021年のデータを取得してPR作成
上記スクリーンショットのように、3つのセッションが並列で作成された：
| セッション | 状態 |
|---|---|
| Add 2021 data to JSON file | ⚠️ コンフリクト（+194行） |
| Add 2022 data to JSON file | ✅ 完了（+204行） |
| Add 2023 data to JSON to prompt file | 進行中 |
各セッションは独立してブランチを作成するため、同じmasterをベースに同じファイルの同じ位置を変更しようとした。
結果
PR #21 (2023年追加) → ✅ マージ成功
PR #22 (2022年追加) → ❌ コンフリクト
PR #23 (2021年追加) → ❌ コンフリクト
なぜコンフリクトが発生したか
図解
master (2024年のみ)
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
PR #21 PR #22 PR #23
(2023年追加) (2022年追加) (2021年追加)
│ │ │
│ │ │
「2024年の後に 「2024年の後に 「2024年の後に
2023年を追加」 2022年を追加」 2021年を追加」
↓ 同じ位置への変更！
問題の本質
- 3つのブランチが同じベース（master）から分岐
- 3つとも「2024年データの後」という同じ位置に新しいデータを挿入
- 最初のPRがマージされると、その位置の構造が変わる
- 残りのPRは古いベースを参照しているためコンフリクト
マージ後の状態
PR #21マージ前: years: [2024]
PR #21マージ後: years: [2023, 2024]
↑
2024の後の位置が変わった！
PR #22は「2024の後に2022を追加」しようとするが、
実際のmasterでは2024の後に2023が既に存在
→ コンフリクト
解決方法
方法1: 順次実行（最も安全）
2023年取得 → PR作成 → マージ完了を待つ
↓
2022年取得 → PR作成 → マージ完了を待つ
↓
2021年取得 → PR作成 → マージ
メリット: コンフリクトが発生しない デメリット: 時間がかかる
方法2: 1つのPR/ブランチで全部まとめる
1つのブランチで:
2023年追加 → 2022年追加 → 2021年追加
↓
1つのPRでまとめてマージ
メリット: 1回のマージで完了、コンフリクトなし デメリット: PRが大きくなる、レビューが大変
方法3: 並列実行後にリベース
並列でPR作成
↓
1つ目をマージ
↓
残りのPRをリベース（最新masterに追従）
↓
2つ目をマージ
↓
残りをリベース...
メリット: 並列で作業を開始できる デメリット: リベース作業が必要
ベストプラクティス
判断基準
| 状況 | 推奨方法 |
|---|---|
| 同じファイルの同じ位置を変更 | 順次実行 or 1つのPR |
| 異なるファイルを変更 | 並列実行OK |
| 同じファイルの異なる位置を変更 | 並列実行OK（注意は必要） |
Claude Codeへの指示例
悪い例（コンフリクトの可能性）:
「2023年、2022年、2021年のデータをそれぞれ別のPRで追加して」
良い例:
「2023年、2022年、2021年のデータを1つのPRで追加して」
または:
「まず2023年のデータを追加してマージして。
完了したら次に2022年をお願いします」
まとめ
- 同じファイルの同じ位置への変更は並列実行するとコンフリクトする
- 最初のPRがマージされた時点で他のPRのベースが古くなる
- 順次実行か1つのPRにまとめるのが安全
- 並列で作成した場合はリベースで解決可能