複数のAIコーディングエージェント（Claude CodeやCodexなど、コードを自律的に書き進めるツール）を並行稼働させる構成を組んでいると、同じファイルへの衝突が繰り返し発生する場面に出会います。
たとえば、ログイン処理のバグ修正をエージェントAに、認証まわりの整理をエージェントBに任せたとします。両方ともブランチを分けて作業し、それぞれ完了しました。マージ前にスクラッチブランチ（検証用の使い捨てブランチ）でテストするために統合すると、同じ行で衝突が起きます。手で解決してテストが通ったので、片方を先に本番ブランチへ取り込み、もう片方をリベース（ベースとなるコミットを付け替える操作）したところ、同じ衝突がもう一度出てきました。
この「同じ衝突を何度も手で解くはめになる」状況に心当たりがあるインフラ・運用担当者やテックリードに向けて、Gitのrerere機能を導入すべきかどうかの判断材料を整理します。並行開発の衝突解消は一見ローカルな開発作業の話に見えますが、CI/CDパイプラインの安定性や、マージ起因の障害を防ぐという運用観点でも無視できないテーマです。
rerereとは何をする機能か
rerereは「reuse recorded resolution（記録した解決策を再利用する）」の略です。
Gitの衝突が起きたとき、人間が一度解決すると、その解決パターンを記録しておきます。次に全く同じ衝突が出た場合、その記録をもとにGitが自動で同じ解決を適用します。
仕組みはシンプルです。git mergeが自動マージに失敗すると、rerereが有効な場合はコンフリクトマーカー付きの状態（プリイメージと呼ばれます）を記録します。手で解決してgit commitすると、その解決結果も記録し、以後同じ衝突パターンが出た際に自動適用されるようになります。
有効化はリポジトリ単位の設定変更だけで完了します。
git config rerere.enabled trueこれだけです。あとはgit mergeやgit rebaseの通常フローの中で自動的に働きます。記録済みの解決があるかどうかはgit rerere status、記録されようとしている差分の中身はgit rerere diffで確認できます。
判断軸1: 衝突の再発頻度
複数エージェントが同じファイル・同じ行を繰り返し触る構成かどうかが、最初の判断材料になります。
単発のマージで衝突が一度起きて終わるなら、rerereの記録は一度しか使われず恩恵は薄くなります。一方で「先にマージしたブランチを、別ブランチへリベースし直す」「スクラッチブランチでの検証後に本番ブランチへ改めて適用する」といった、同じ変更を複数回統合する運用では、同じ衝突パターンが繰り返されやすくなります。
AIエージェントを並行稼働させる構成はまさにこのパターンに当てはまります。ログイン処理のファイルのように、認証系・設定系の小さな共通ファイルは複数のタスクから触られやすく、衝突の再発率が上がりやすい領域です。
判断軸2: チームの衝突解決の再現性
解決内容が「毎回同じ判断になる」かどうかも重要な軸です。
rerereはテキストパターンの再利用であり、コードレビューの代わりにはなりません。同じコンフリクトマーカーの組み合わせに対して、常に同じ解決が正しいと判断できる場合にのみ有効に機能します。
逆に、衝突のたびに業務要件を踏まえて判断が変わるような箇所（たとえば料金計算ロジックの条件分岐など）では、自動適用がかえって見落としにつながるおそれがあります。この場合は記録の自動適用に頼らず、都度レビューする運用のほうが安全です。
判断軸3: CI/運用フローへの組み込みやすさ
rerereはリポジトリのローカル設定（.git/configのrerere.enabled）に依存するため、チーム全員・全CI環境で同じ設定が有効になっている保証がありません。
記録データは.git/rr-cacheディレクトリに保存されます。このディレクトリをリポジトリ内で共有する仕組みを別途用意しない限り、CIのビルドエージェントや他の開発者の環境では記録が引き継がれません。チーム全体で運用するなら、rr-cacheの共有方法（リポジトリへのコミット、共有ストレージへの同期など）を事前に決めておく必要があります。
判断軸4: 障害時の追跡しやすさ
運用監視・障害対応の視点では、自動適用された衝突解決が「いつ・どのコミットで」記録され適用されたのかを追えるかどうかも軸になります。
rerereが解決を記録した際、GitはRecorded preimage for、適用時にはRecorded resolution forという行を出力します。これらはコミットログやCIのビルドログに残るため、後から「なぜこの行がこの内容になったか」を遡る手がかりになります。手動マージだけに頼る運用よりも、マージ起因の不具合を調査する際のログの残り方が変わってきます。
選択肢の比較
| 方式 | 衝突の再発耐性 | チーム共有の容易さ | 向くチーム規模 |
|---|---|---|---|
| rerereなし（毎回手動解決） | 低い（毎回同じ作業） | 特別な共有設定不要 | 少人数・単発プロジェクト |
| rerere（ローカル運用） | 高い（記録を自動再利用） | 個人の作業効率化にとどまる | 個人または小規模チーム |
| rerere+rr-cache共有 | 高い | 共有の仕組み構築が必要 | 並行エージェント運用を本格化するチーム |
ケース別の推奨
次のような条件に当てはまるなら、rerereを試す価値があります。
- 複数のAIエージェントや複数人が同一リポジトリの共通ファイルを並行して触っている
- スクラッチブランチでの検証マージと、本番ブランチへの正式マージの2段階で同じ衝突が出る構成になっている
- 衝突のパターンが業務ロジックに依存せず、機械的に同じ解決で問題ない箇所が多い
この場合はまず個人のローカル環境でgit config rerere.enabled trueを試し、git rerere statusやgit rerere diffで記録の中身を確認しながら感触をつかむのがよい進め方です。
チーム全体で効果を出したいなら、rr-cacheディレクトリをリポジトリに含めて共有する運用に進める選択肢もあります。ただしこの場合は、記録された解決が常に正しいかをレビューする仕組みとセットで導入しないと、誤った自動適用に気づかないリスクが残ります。
あえて見送るべき条件
一方で、次のような状況ではrerere導入を急ぐ必要はありません。
- 衝突がそもそも稀で、年に数回程度しか起きていない
- 衝突のたびに業務要件の確認やレビューが必須で、自動化すると危険な箇所が多い
- チームにGitの衝突解決プロセスを運用統一する体制（
rr-cacheの共有先決定やレビュー運用）を整える余裕がない
こうしたケースでは、無理に導入するよりも、衝突が起きやすいファイルの設計そのものを見直す（共通ファイルを分割する、変更頻度の高い箇所をモジュール化するなど）ほうが根本的な対策になります。
まとめ
rerereは「同じ衝突を二度と手で解きたくない」という状況で効果を発揮する機能です。
導入判断は、衝突の再発頻度・解決の再現性・チーム共有のしやすさ・障害調査時の追跡性という4つの軸で見極められます。
まずはgit config rerere.enabled trueをローカルで試し、git rerere statusとgit rerere diffで記録される内容を確認するところから始められます。チーム展開を検討する場合は、rr-cacheの共有方法とレビュー体制をセットで設計しておくと、自動適用による見落としを防ぎやすくなります。