はじめに
この記事は、AIエージェントを使ったチーム開発について考える全8回の連載の第3回です。
AIを使った開発では、コードを書く速度がかなり上がります。
ただ、その速度がチーム開発では別の問題を生むことがあります。
その一つが、コンフリクトです。
今回は、複数人でAIを使って開発していたときに、マージ時のコンフリクトがかなり大変になった、という話をもとに考えます。
起きたこと
あるプロジェクトで、フロントエンドを複数人で開発していました。
そのうち、同じフロントエンド領域を2人で並行して触っていました。
2人ともAIを使っていました。
それぞれの作業自体は進みました。
AIは画面修正も、コンポーネント修正も、状態管理の変更も、かなり速く進めてくれます。
しかし、マージの段階で問題が出ました。
コンフリクトが多い。
しかも、単純な行の衝突ではなく、AIが広い範囲を修正しているため、どちらの変更を残すべきか判断しにくい。
結果として、マージ作業がかなり大変になりました。
なぜAIを使うとコンフリクトが増えやすいのか
AIは、人間よりも広い範囲を一気に直すことがあります。
人間が手で修正する場合、目的の箇所だけを最小限直すことが多いです。
もちろん人によりますが、作業コストがあるため、無関係な箇所まで大きく触ることは比較的少ないです。
一方、AIは違います。
「この画面を直して」と依頼すると、AIは関連するコンポーネント、hooks、API呼び出し、型定義、状態管理、スタイルまでまとめて修正することがあります。
それ自体は便利です。
しかし、複数人が同じようにAIを使うと、変更範囲が重なりやすくなります。
たとえば、AさんのAIが共通コンポーネントを少し直す。
BさんのAIも同じ共通コンポーネントを別の目的で直す。
どちらも「良い修正」に見えるが、マージすると衝突する。
こういうことが起きます。
コンフリクトの本質は「同じファイルを触ったこと」だけではない
Gitのコンフリクトだけを見ると、問題は「同じファイルを触ったこと」に見えます。
しかし、実際にはそれだけではありません。
問題は、AIが変更した意図が見えにくいことです。
人間が小さく修正していれば、コンフリクトしても判断しやすい場合があります。
しかし、AIが複数ファイルを一気に直していると、マージ時にこうなります。
- この変更は仕様上必要なのか
- これは単なるリファクタなのか
- これはAIが勝手に直しただけなのか
- どちらの実装方針を採用すべきなのか
- 両方の変更を統合しても壊れないのか
この判断が難しくなります。
つまり、AI時代のコンフリクトは、単なる行単位の衝突ではなく、意図の衝突になりやすいのです。
AIは「ついでに直す」
AIを使っていてよく感じるのは、AIが「ついでに直す」ことです。
たとえば、こちらはボタンの動作だけを直したい。
しかしAIは、ついでにコンポーネントの分割や命名変更、スタイル整理までやることがあります。
AIとしては、より良いコードにしようとしているのだと思います。
ただ、チーム開発では、この「ついでに直す」が危険です。
特に、複数人が同じ領域を触っている場合、ついでの修正がコンフリクトを増やします。
本来の目的とは関係ない差分が増えるほど、マージもレビューも難しくなります。
対策1：AIに変更範囲を明示する
まず必要なのは、AIに変更してよい範囲を明示することです。
たとえば、以下のように指示します。
今回の修正では、以下のファイルだけを変更してください。
それ以外のファイルは変更しないでください。
- src/pages/UserListPage.tsx
- src/components/UserSearchForm.tsx
共通コンポーネント、APIクライアント、状態管理、ルーティングは変更禁止です。
既存コードに問題を見つけた場合は、勝手に直さず、別途修正候補として報告してください。
この指示で完全に防げるわけではありません。
しかし、何も言わないよりはかなり効果があります。
特に重要なのは、「問題を見つけても勝手に直さないで」と伝えることです。
AIは親切なので、問題を見つけると直そうとします。
しかし、チーム開発では、それを今の差分に混ぜてよいとは限りません。
対策2：同じ領域を同時に触らない
これは従来の開発でも同じですが、AI時代はより重要です。
同じ画面、同じ状態管理、同じ共通コンポーネント、同じAPIクライアントを、複数人が同時にAIで修正すると、コンフリクトしやすくなります。
AIは一気に広い範囲を触るため、従来より衝突範囲が広がる可能性があります。
そのため、チーム内で作業領域を分ける必要があります。
- Aさんは画面A
- Bさんは画面B
- 共通コンポーネントは別作業にする
- 状態管理の変更は先に合意する
- APIクライアントの変更は一人が担当する
このように、AIに任せる前に人間側で境界を引く必要があります。
対策3：リファクタと機能追加を分ける
AIを使うと、機能追加とリファクタが混ざりがちです。
しかし、チーム開発ではできるだけ分けた方がよいです。
- 先にリファクタだけを行う
- その後に機能追加を行う
- あるいは、機能追加を先に行い、リファクタは別PRにする
どちらでもよいですが、とにかく混ぜないことが重要です。
混ぜると、レビュー時に「この差分は仕様変更なのか、整理なのか」が分からなくなります。
対策4：AIに差分レビューをさせる
実装後に、AI自身に差分レビューをさせるのも有効です。
たとえば、こう依頼します。
今回の差分を確認し、以下の観点でレビューしてください。
- 目的外のファイルを変更していないか
- 仕様変更と関係ないリファクタが混ざっていないか
- 既存の責務を変更していないか
- 共通コンポーネントを不要に変更していないか
- 他メンバーの作業と衝突しやすい変更がないか
もちろん、最終判断は人間が行う必要があります。
しかし、AIに差分の棚卸しをさせることで、不要な変更に気づきやすくなります。
まとめ
AIを使うと、開発速度は上がります。
しかし、複数人が同じ領域でAIを使うと、コンフリクトが増えることがあります。
原因は、AIが広い範囲を一気に修正しやすく、ついでのリファクタも混ぜやすいからです。
対策としては、以下が重要です。
- AIに変更範囲を明示する
- 同じ領域を複数人で同時に触らない
- リファクタと機能追加を分ける
- 実装後に差分レビューを行う
AIが悪いのではありません。
AIに広すぎる作業範囲を渡したまま、複数人が同時に作業することが危険なのです。
次回は、「AIにこのファイル以外触らないで」と指示するのは正しいのか、もう少し掘り下げます。
今後
以降の連載予定になります。
- 第1回：同じAIを使っているのに、なぜコードがバラバラになるのか
- 第2回：AIが書いた「動くコード」が、チーム開発では危ない理由
- 第3回：AIに任せたらコンフリクトだらけになった話
- 第4回：AIに「このファイル以外触らないで」と言うのは正しいのか
- 第5回：AI時代のPRは、なぜ重くなりやすいのか
- 第6回：AIには細かく指示しない方がいい、はチーム開発でも通用するのか
- 第7回：スキル・ルールファイルだけでは足りない。AIのブレを仕組みで吸収する
- 第8回：AI時代のベテランは、コードを書く人から仕組みを作る人へ