コンフリクトを見つけた瞬間に、雑に「直しといて」と投げるとだいたい余計にこじれる。Claude Code もそこは人間と同じで、何を残すべきか、どこまで触っていいかが曖昧だと、無難そうな修正を広げてしまう。結果、差分が太る。あとで自分が読むと、何を直したのか分からない。これが一番だるい。
この手の場面で大事なのは、解決作業そのものより、渡し方だ。コンフリクトの前後関係、残したい意図、触ってよい範囲を小さくまとめて渡すだけで、手戻りがかなり減る。開発でも文書整理でも同じで、片方だけ見せて丸投げするのが一番危ない。
まず押さえるべきなのは、Claude Code に見せる情報を「衝突したファイルそのもの」だけに絞らないことだ。コンフリクトは、たいてい前後の変更履歴や目的が分からないと解けない。たとえば設定ファイルなら、「新しい値にしたい」のか「既存の値を残したい」のかで答えが変わる。文書なら、片方の修正が表現の整理で、もう片方が事実の追加かもしれない。そこを切り分けずに渡すと、見た目は直っても意図が死ぬ。
実際の渡し方は、こういう形が使いやすい。
このコンフリクトを解消してほしい。
- 目的: 既存の挙動は変えずに、A 側の新しい文言だけ取り込みたい
- 触ってよい範囲: このファイルだけ
- 残したいもの: 旧来の処理順序、エラー処理
- 取り込みたいもの: 変数名の変更、説明文の更新
- 不明点があれば、勝手に推測せずに質問してほしい
コンフリクト箇所:
<<<ここに該当部分を貼る>>>
これで足りないときは、コンフリクトの周辺を少し広げて貼る。前後 20 行くらい、あるいは関係する関数や段落ごとだ。コンフリクトの印そのものだけ貼ると、Claude Code は文脈を取り違えやすい。筆者は以前、変更部分だけを切り出して渡してしまい、見た目は整ったのに既存のコメントの意味がずれて手戻りした。差分が小さいほど安全、ではない。文脈が小さいほど危ない。
Git のマージコンフリクトを扱うなら、ファイルごとに「どちらを優先したいか」を明言しておくと強い。たとえばこんな書き方だ。
このコンフリクトを解消してほしい。
- base: main
- 片方は機能追加、もう片方はリファクタ
- 機能追加側のロジックを優先しつつ、リファクタ側の命名規則は取り込みたい
- ただし public API は変えない
- コンフリクトは最小差分で解きたい
必要なら、関連する周辺ファイルも見てよい。
ここで大事なのは、「最小差分」と「何を優先するか」を同時に書くことだ。片方だけだと、最小差分に寄せすぎて意図が弱くなるか、意図を守るために広めに直しすぎる。どっちも避けたい。コンフリクト解消は、きれいにする作業ではなく、壊さず通す作業である。
ファイル整理や文書作成で使う場合も同じだ。たとえば、同じ内容のメモが複数あって統合したいなら、「統合してほしい」だけでは足りない。どれを正とするか、何を捨てるか、言い回しを整えるだけかを伝える必要がある。
次の 3 つの文書の内容を統合して、1 本の案にしてほしい。
- 正本にしたいのは 2 番目
- 1 番目の「期限」に関する記述だけ採用したい
- 3 番目の表現のうち、冗長な箇所は削ってよい
- 事実関係は変えず、読みやすさだけ整えてほしい
- 重複は残さないでほしい
この「どれを正本にするか」はかなり重要だ。Claude Code に全部見せてしまうと、良かれと思って平均値を作る。平均はたいてい中途半端だ。設定でも文章でも、元の意図が濃い側を決めておいたほうが仕上がりが安定する。
一方で、渡し方でやりがちな地雷もある。いちばんまずいのは、コンフリクトマーカーをそのまま放り込んで「直して」で終えることだ。もちろん一時的には動くが、何のための変更か分からないまま解消される。特にコードでは、<<<<<<< と >>>>>>> の間を片側丸のみで終えると、見えない不具合を呼び込みやすい。表面上はコンフリクトが消えても、振る舞いが変わっていたら意味がない。
もうひとつ、余計なファイルまで一緒に渡さないことだ。関連しそうだからと何十ファイルも投げると、コンテキストを食う。Claude Code は人間よりは広く見られるが、無限ではない。筆者は一度、関係ありそうなファイルを全部突っ込んで、肝心の差分より周辺のノイズを追いかける羽目になった。結局、狭い範囲に戻したほうが速かった。広く見せるのは最後でいい。
実務では、先に一言だけ添えると通りがいい。
このコンフリクトは、A の新仕様を取り込みつつ、B の例外処理は残したい。
A の変更は反映してよいが、ログ文言は既存のままにしたい。
まず解消案を出して、危ない箇所があれば先に指摘してほしい。
この「先に解消案を出して」は便利だ。いきなり編集させるより、どう解釈したかを確認できる。意図のズレがあれば、その時点で止められる。特に重要な設定ファイル、契約文書、申請書類のようなものは、勝手に直されるより、方針を先に言わせたほうが安全である。
少し進んだ使い方をするなら、コンフリクトだけを見せるのではなく、前後の目的も短く書くといい。たとえば「このブランチはリネームだけが目的」「この修正は表記統一だけ」「この設定はディスク削減のための削除作業で、動作変更は避けたい」みたいに、ゴールをひとことで固定する。すると Claude Code は、正しい差分の太さを選びやすくなる。
要するに、コンフリクト解消を手伝ってもらうときの渡し方は、次の3点に尽きる。何を守るか、何を変えてよいか、どこまで見てよいか。この3つが見えていれば、手戻りはかなり減る。逆にそこが曖昧だと、解けたように見えてもあとで崩れる。
雑に丸投げするより、短くても意図を添える。これだけで、コンフリクトはだいぶ扱いやすくなる。