はじめに
この記事は、AIエージェントを使ったチーム開発について考える記事の第1回です。
複数メンバで開発している状況をイメージして記事を書いてみました。
全8回の連載予定です。
内容は抽象的なので「ポエム」として読んでください。
最近、AIエージェントを使って複数人で開発している中で、少し気になることがありました。
一人でAIを使っているときは、とても便利です。
「こういう画面を作りたい」「このAPIを追加したい」「このUIを少し直したい」と伝えると、かなりの速度で動くコードを書いてくれます。
以前なら、既存コードを読み、似た実装を探し、手で少しずつ書いていたような作業も、AIを使うことで一気に進められるようになりました。
これは本当に大きな変化だと思います。
ただ、複数人で同じプロジェクトを開発し始めると、少し違う問題が見えてきました。
たとえば、フロントエンドを複数人で開発していて、それぞれがAIを使っている。
すると、同じような機能を作っているはずなのに、出てくるコードの雰囲気が人によって違うことがあります。
コンポーネントの分け方が違う。
状態管理の置き方が違う。
API呼び出しの書き方が違う。
命名やファイル構成の粒度が微妙に違う。
もちろん、それぞれ単体では動きます。
AIが書いたコードとしては、決して悪いものではないことも多いです。
しかし、チーム開発として見ると、少しずつ違う実装方針が混ざっていきます。
その結果、レビューが難しくなったり、マージ時にコンフリクトが増えたり、後から全体の統一感を取り戻すのが大変になったりします。
この記事では、AIエージェントを使ったチーム開発で起きやすい「同じAIを使っているのにコードが揃わない問題」について、自分なりに整理してみます。
なお、これは「AIを使うべきではない」という話ではありません。
むしろ、AIは非常に便利です。
ただ、チーム開発に入れるなら、従来とは少し違う運用設計が必要になるのではないか、という話です。
昔はベテランがテンプレートを作っていた
少し前の開発現場では、よくこういう進め方がありました。
まず、ベテランのエンジニアや、業務知識・設計知識のある人が代表的な実装を作る。
その実装をテンプレートとして、経験の浅いメンバーが似たような機能を横展開していく。
たとえば、CRUD画面を作る場合、最初にベテランが1画面分のController、Service、Repository、DTO、テストを書きます。
その後、別の画面ではそれを参考にして、同じ構成で実装していく。
このやり方には、いくつかメリットがありました。
- 経験の浅い人でも、ある程度品質の揃ったコードを書ける
- プロジェクト内の構成が揃いやすい
- レビュー観点が固定しやすい
- ベテランの知見をチームに展開しやすい
もちろん、単純作業になりやすいという面もありました。
しかし、チームとしてコードの形を揃えるという意味では、それなりに機能していたと思います。
今はAIが動くコードを書いてくれる
ところが、今は状況が変わりました。
AIに依頼すれば、かなりの範囲のコードを生成してくれます。
しかも、ただのサンプルではなく、実際に動くコードを書いてくれることも多いです。
以前であれば、経験の浅い人がテンプレートを見ながら数時間かけて実装していたようなものを、AIは短時間で作ってしまいます。
これはとても便利です。
ただし、ここで問題になるのが、AIは毎回まったく同じ方針でコードを書くとは限らないということです。
AさんがAIに依頼した場合と、BさんがAIに依頼した場合で、出力されるコードが変わります。
同じAIモデルを使っていても、プロンプト、読ませたファイル、作業ブランチ、周辺コンテキストによって結果が変わります。
つまり、昔のように「このテンプレートを見て同じように書いてください」という統制が、そのままでは効きにくくなっています。
同じAIでも、入力条件が違えば出力は変わる
AIの出力が揃わない理由の一つは、入力条件が人によって違うことです。
たとえば、AさんはAIにこう依頼します。
ユーザー一覧画面を作ってください。
一方で、Bさんはこう依頼します。
既存の商品一覧画面と同じ構成で、ユーザー一覧画面を作ってください。
状態管理、API呼び出し、エラーハンドリング、命名規則は既存実装に合わせてください。
同じAIを使っていても、出力はかなり変わります。
さらに、AIにどのファイルを読ませたかも重要です。
- 既存の似た画面を読ませたか
- 共通コンポーネントを読ませたか
- APIクライアントの実装を読ませたか
- テストコードを読ませたか
- プロジェクトのルールを読ませたか
これらが人によって違えば、AIの出力も当然変わります。
つまり、「同じAIを使っているのにコードがバラバラになる」のではなく、実際には「同じAIに見えて、渡している前提条件がバラバラ」なのだと思います。
AIのブレは悪いことだけではない
ここで誤解したくないのは、AIの出力が毎回違うこと自体は、必ずしも悪いことではないという点です。
むしろ、ある問題に対して、AIが複数の解決策を提案できるのは強みです。
今日の時点で良いと思える実装と、1週間後に良いと思える実装が違うことはあります。
新しいライブラリの使い方を知ったり、既存コードの理解が深まったりすれば、別の実装を提案するのは自然です。
問題は、AIがブレることそのものではありません。
問題は、そのブレがチーム開発の中で制御されないまま混ざることです。
一人開発なら、AIの提案が多少変わっても、自分で判断して採用すればよいです。
しかし、複数人が同時にAIを使い、それぞれが違う方針で実装すると、プロジェクト全体としての一貫性が崩れやすくなります。
チーム開発で揃えるべきもの
AI時代のチーム開発で揃えるべきなのは、AIモデルそのものだけではありません。
むしろ、以下のようなものを揃える必要があります。
- AIに読ませる情報
- AIに渡す作業単位
- AIに許可する変更範囲
- AIに実行させる検証コマンド
- 人間がレビューする観点
- マージ可能と判断する基準
これらが揃っていない状態で、各メンバーが自由にAIに依頼すると、コードの形は自然にバラつきます。
AIを使うこと自体が問題なのではありません。
AIをチーム開発に組み込むための作法が、まだ十分に整っていないことが問題なのだと思います。
スキルファイルだけで解決できるのか
最近は、AIエージェント向けにプロジェクトルールを書く方法も増えています。
たとえば、ステアリングファイル、AGENTS.md、CLAUDE.md、custom instructions のようなものです。
これらはとても有効です。
AIにプロジェクトの前提を伝えるうえで、整備した方がよいと思います。
ただ、個人的には、それだけで完全に統一するのは難しいと感じています。
AIにルールを書いても、必ず毎回完璧に守ってくれるとは限りません。
ルールが長すぎれば読み落としのような挙動も起きますし、直近の指示や周辺コードの影響を強く受けることもあります。
そのため、ステアリングファイルは「強制」ではなく「誘導」と考えた方がよいと思います。
本当に揃えたい部分は、AIへのお願いだけではなく、ひな形、テンプレート、formatter、lint、test、CIのように、機械的に確認できる仕組みに落とし込む必要があります。
まとめ
AIエージェントは、コードを書く力を大きく引き上げてくれます。
しかし、チーム開発では「動くコードが速く書ける」だけでは不十分です。
同じAIを使っていても、渡す情報、作業範囲、指示の粒度、既存コードの読み込み方が違えば、出力されるコードは変わります。
AI時代のチーム開発では、AIの出力そのものを完全に統一しようとするよりも、AIが多少ブレても、チームとして破綻しない仕組みを作ることが重要だと思います。
このシリーズでは、AIエージェントを使ったチーム開発について、以下のような観点で整理していく予定です。
今後
以降の連載予定になります。
- 第1回：同じAIを使っているのに、なぜコードがバラバラになるのか
- 第2回：AIが書いた「動くコード」が、チーム開発では危ない理由
- 第3回：AIに任せたらコンフリクトだらけになった話
- 第4回：AIに「このファイル以外触らないで」と言うのは正しいのか
- 第5回：AI時代のPRは、なぜ重くなりやすいのか
- 第6回：AIには細かく指示しない方がいい、はチーム開発でも通用するのか
- 第7回：スキル・ルールファイルだけでは足りない。AIのブレを仕組みで吸収する
- 第8回：AI時代のベテランは、コードを書く人から仕組みを作る人へ