はじめに
この記事は、AIエージェントを使ったチーム開発について考える全8回の連載の第4回です。
AIを使って開発していると、こう感じることがあります。
「そこまで直してほしいとは言っていない」
こちらは小さな修正を依頼したつもりなのに、AIが関連ファイルをまとめて変更する。
共通コンポーネントや状態管理まで触る。
命名や構成まで変える。
一人で開発しているときは、それでもよい場合があります。
しかし、チーム開発では危険です。
では、AIに対して「このファイル以外は触らないで」と指示するべきなのでしょうか。
私の考えでは、答えは「言うべき」です。
ただし、それだけでは不十分です。
変更範囲を明示するのは有効
AIに変更範囲を明示することは有効です。
たとえば、次のような指示です。
今回の修正では、以下のファイルのみ変更してください。
それ以外のファイルは変更しないでください。
変更可能：
- src/pages/UserListPage.tsx
- src/components/UserSearchForm.tsx
変更禁止：
- src/components/common/*
- src/api/*
- src/store/*
- src/router/*
このように書くことで、AIは作業範囲を意識しやすくなります。
特に、共通コンポーネントや状態管理のように影響範囲が広い部分は、勝手に触らせない方が安全です。
「直さないでほしいこと」も書く
変更してよいファイルを書くのと同じくらい重要なのが、変更してはいけない内容を書くことです。
たとえば、以下のような指示です。
以下は禁止です。
- 仕様変更と関係ないリファクタ
- 既存コンポーネントの責務変更
- 共通関数の追加
- 状態管理方式の変更
- APIクライアントの修正
- import整理だけの変更
- 命名規則の一括変更
AIは、こちらが明示しないと「より良くする」方向で動くことがあります。
もちろん、それはAIの強みでもあります。
しかし、チーム開発では「今はそこを直さない」ことが重要な場面もあります。
問題を見つけても、勝手に直させない
個人的に重要だと思っているのは、次の指示です。
既存コードに問題を見つけた場合も、勝手に修正しないでください。
まず「別途修正候補」として報告してください。
AIは、既存コードの問題を見つけると、その場で直そうとすることがあります。
しかし、その修正が今回の目的に含まれているとは限りません。
たとえば、AIが次のように考えることがあります。
- この関数名は分かりにくいので変えよう
- このコンポーネントは分割した方がよい
- この処理は共通化できる
- この型定義は別ファイルに出した方がよい
一つひとつは正しいかもしれません。
しかし、それを今回の修正に混ぜると、差分が大きくなります。
そのため、「見つけても報告だけにして」と指示することが大切です。
ただし、AIへの指示は絶対ではない
ここで注意したいのは、AIに指示したからといって、必ず守られるわけではないということです。
AIはコンパイラではありません。
ルールを書けば必ず従う、というものではありません。
特に、長いコンテキストや複雑な修正では、指示から外れることがあります。
そのため、「このファイル以外触らないで」と書くだけでは足りません。
実装後に、必ず差分を確認する必要があります。
git diff --name-only
まず変更されたファイル一覧を見る。
意図しないファイルがあれば戻す。
必要ならAIに再修正させる。
AIへの指示と、Git差分の確認はセットで考えるべきです。
ファイル単位だけでは足りないこともある
「このファイル以外触らないで」は分かりやすい指示ですが、ファイル単位だけでは不十分な場合もあります。
なぜなら、同じファイルの中にも、触ってよい部分と触ってはいけない部分があるからです。
たとえば、画面コンポーネントの中で、検索条件部分だけを修正したい場合があります。
そのとき、同じファイル内にある一覧表示やページング処理まで変えられると困ります。
その場合は、次のように書くとよいです。
このファイル内では、検索フォームの表示条件のみ修正してください。
一覧表示、ページング、API呼び出し、エラーハンドリングのロジックは変更しないでください。
AIに依頼するときは、「どのファイルか」だけでなく、「どの責務か」まで指定すると安全です。
変更範囲を狭めることは、AIの力を弱めることではない
AIに細かく制約をかけると、AIの良さを殺してしまうのではないか、と思う人もいるかもしれません。
確かに、探索フェーズではAIに広く任せた方がよい場面があります。
しかし、既存のチーム開発に入れるコードでは、話が違います。
チーム開発では、自由な提案よりも、既存設計との整合性やレビューしやすさが重要になることがあります。
変更範囲を狭めることは、AIを信用していないという意味ではありません。
AIの出力を、チーム開発で扱える単位にするための工夫です。
実際に使えるプロンプト例
以下のようなテンプレートを用意しておくと便利です。
今回の目的：
- ユーザー一覧画面に部署名での検索条件を追加する
変更してよい範囲：
- src/pages/UserListPage.tsx
- src/components/UserSearchForm.tsx
変更してはいけない範囲：
- 共通コンポーネント
- APIクライアント
- 状態管理
- ルーティング
- 既存の一覧表示ロジック
禁止事項：
- 目的外のリファクタ
- 命名変更
- 共通化
- ファイル分割
- 既存責務の変更
既存コードに問題を見つけた場合：
- 勝手に修正せず、別途修正候補として報告してください
実装後：
- 変更ファイル一覧を提示してください
- 目的外の変更がないか確認してください
これを毎回手で書くのは面倒なので、チーム内でテンプレート化しておくとよいと思います。
まとめ
AIに「このファイル以外触らないで」と言うのは、正しいと思います。
ただし、それだけでは不十分です。
重要なのは、以下をセットで行うことです。
- 変更してよいファイルを明示する
- 変更してはいけないファイルを明示する
- 禁止する作業内容を書く
- 問題を見つけても勝手に直させない
- 実装後に差分を確認する
AIへの指示は絶対ではありません。
だからこそ、指示だけでなく、差分確認やCIと組み合わせる必要があります。
次回は、AI時代にPRは機能するのか、という問題について考えます。
今後
以降の連載予定になります。
- 第1回：同じAIを使っているのに、なぜコードがバラバラになるのか
- 第2回：AIが書いた「動くコード」が、チーム開発では危ない理由
- 第3回：AIに任せたらコンフリクトだらけになった話
- 第4回：AIに「このファイル以外触らないで」と言うのは正しいのか
- 第5回：AI時代のPRは、なぜ重くなりやすいのか
- 第6回：AIには細かく指示しない方がいい、はチーム開発でも通用するのか
- 第7回：ステアリングファイルだけでは足りない。AIのブレを仕組みで吸収する
- 第8回：AI時代のベテランは、コードを書く人から仕組みを作る人へ