この記事は、AIエージェント時代のチーム開発について書いた記事を、自分なりの流れで並べたインデックスです。
AIエージェントをチームで使うことを否定したいわけではありません。
むしろ、うまく使えば個人の開発速度はかなり上がると思っています。
ただ、チーム開発では「動いたからOK」だけでは済まないこともあります。
コードの揃い方、PRの大きさ、変更範囲、レビュー、暗黙知、現場の詳しい人との関係など、個人開発とは違う難しさが出てくるように感じています。
はじめに
AIエージェントを使うと、実装はかなり速くなります。
コードを書いてもらう。
エラーを直してもらう。
リファクタしてもらう。
テストを書いてもらう。
自分ひとりで使っている分には、かなり便利です。
ただ、それをチーム開発に持ち込むと、少し違う問題が見えてきます。
同じAIを使っているはずなのに、コードの書き方がバラバラになる。
動いているけど、保守しやすいのか少し不安になる。
AIが気を利かせて、頼んでいないところまで直す。
PRが重くなって、レビューしづらくなる。
現場の詳しい人に聞く前に、みんなAIに聞くようになる。
AIは便利です。
でも、チームで使うなら、AIの出力だけではなく、AIが動く範囲や、差分の見せ方、知見の残し方も見ていく必要があるのだと思います。
この記事は、そのあたりを考えた記事をまとめたページです。
単なるリンク集というより、AIエージェントをチーム開発に入れたとき、どこがズレやすいのか を整理するためのインデックスとして書いています。
目次
この連載では、AIエージェント時代のチーム開発を、だいたい次の流れで見ています。
| 回 | テーマ | 含めている話 |
|---|---|---|
| 第1回 | 同じAIなのにコードがバラバラになる | AIの出力は入力条件や人の頼み方で変わるという話 |
| 第2回 | 「動いてOK」が少し怖い | 動くコードと保守できるコードは違うという話 |
| 第3回 | コンフリクトが増える | AIが同じ領域や周辺コードを触りやすい問題 |
| 第4回 | 変更範囲をどう伝えるか | 「このファイル以外触らないで」は有効だが限界もある話 |
| 第5回 | PRが重くなる | AI時代のPRは変更の種類で分けた方がよさそうという話 |
| 第6回 | 細かく指示しない方がいいのか | 探索フェーズと実装フェーズで任せ方を変える話 |
| 第7回 | スキルファイルだけでは足りない | AIのブレを文章だけでなく仕組みで吸収する話 |
| 第8回 | みんなAIに聞くようになる | 暗黙知や知見者の役割が見えにくくなる話 |
最初は、AIエージェントを使えば、チーム全体の開発も自然に速くなると思っていました。
でも、考えていくうちに、速くなる部分と、むしろ気をつけた方がよさそうな部分が分かれて見えてきました。
AIをチームで使うなら、AIに何を任せるかだけではなく、人間同士がどう揃えるか、どこで止めるか、何を残すか も一緒に考える必要がありそうです。
AIエージェント時代のチーム開発
第1回：同じAIだよね？なんでコードがバラバラに？
同じAIを使っているはずなのに、出てくるコードが人によって変わる。
これは、AIの性能が不安定という話だけではなく、入力条件や頼み方、持っている前提が人によって違うからなのだと思います。
AIは動くコードを書いてくれます。
ただ、チーム開発では、動くことに加えて、どこまで揃えるのかも大事になります。
この記事では、AIのブレを悪いものとして見るだけではなく、チームで揃えたいものは何なのかを考えています。
第2回：「動いてOK」が、ちょっと怖い...
AIが書いたコードは、かなりの確率で動くところまで持っていけます。
ただ、動くコードと、チームで保守できるコードは少し違います。
AIは局所最適になりやすく、頼んだことの周辺まで気を利かせて直すことがあります。
その差分が大きくなると、意図が読みにくくなります。
この記事では、「動いたからOK」と言い切る前に、チーム開発では何を見る必要があるのかを整理しています。
第3回：AIに任せたらコンフリクトだらけになった話
AIに任せると、作業自体は速く進みます。
でも、複数人が同じようにAIを使うと、コンフリクトが増えることがあります。
AIは、頼まれた変更だけでなく、周辺のリファクタや整理も一緒にやりたがることがあります。
その結果、同じファイルを触っただけではなく、同じ前提や同じ責務の周辺に変更が集中しやすくなります。
この記事では、AI時代のコンフリクトはコード差分だけではなく、変更範囲や前提のぶつかりとして見た方がよさそうだ、という話をしています。
第4回：AIに「このファイル以外触らないで」と言うのは正しいのか
AIに変更範囲を明示するのは、かなり有効です。
ただ、「このファイル以外触らないで」と言えばすべて解決するわけでもありません。
ファイル単位ではなく、責務やユースケース、影響範囲で見た方がよいこともあります。
また、問題を見つけても勝手に直させない、気になった点は別提案として出してもらう、という制御も必要になってきます。
この記事では、AIの力を弱めるためではなく、チームでレビューできる差分にするために変更範囲をどう伝えるかを考えています。
第5回：PRが重いんですけど...
AIを使うと、短い時間でかなり大きな差分が作れます。
つまり、作業時間とPRの大きさの関係が崩れます。
人間が1日かけて作ったPRより、AIで数十分作ったPRの方が重くなることもあります。
そうなると、レビューする側が追いつきません。
この記事では、AI時代のPRは日数や作業時間ではなく、設計変更、実装変更、リファクタ、テスト追加のように、変更の種類で分けた方がよさそうだ、という話をしています。
第6回：AIには細かく指示しない方がいい？はチーム開発でも通用するのか
AIには細かく指示しすぎない方が、よい提案が出ることがあります。
ただ、それがいつでも正しいわけではありません。
探索フェーズでは、ある程度自由に考えてもらう方が広がることがあります。
一方で、実装フェーズでは、変更範囲、制約、既存ルール、レビューしやすい単位が効いてきます。
この記事では、「細かく指示しない」と「制約を与えない」は違う、という前提で、チーム開発におけるAIへの任せ方を考えています。
第7回：スキルファイルだけでは足りない。AIのブレを仕組みで吸収する
AIにルールを読ませるために、スキルファイルやガイドラインを用意することは役に立ちます。
ただ、文章で書いたルールだけで、AIの出力を完全に揃えるのは難しいです。
ルールが長すぎると効きづらくなりますし、人によって使い方も変わります。
だから、文章で伝えるものと、Lint、型、テスト、テンプレート、CIのように機械で縛るものを分けた方がよさそうです。
この記事では、AIのブレをなくすのではなく、仕組みで吸収するという見方を整理しています。
第8回：現場の詳しい人に聞く前に、みんなAIに聞くようになった
昔は、現場の詳しい人に聞いていたことを、今はまずAIに聞くようになってきました。
これは便利です。
ただ、その分、知見者が問題に気づくタイミングが遅くなることがあります。
暗黙知がAIに渡らないまま、AIの答えで進んでしまうこともあります。
この記事では、知見者が全部をコントロールするのではなく、聞かれなくても効く環境をどう作るかを考えています。
おわりに
AIエージェントは、チーム開発でもかなり使えると思っています。
ただ、チーム開発では、個人開発とは違う見方が必要になります。
動くかどうか。
速いかどうか。
AIが良い提案を出したかどうか。
それだけではなく、レビューできる差分になっているか。
チームで揃えたいものが揃っているか。
変更範囲が見えるか。
暗黙知がどこかに残っているか。
詳しい人があとから気づける仕組みがあるか。
そういう部分も見ていく必要がありそうです。
AI時代のチーム開発は、AIを禁止する方向ではなく、AIが速く動けるからこそ、人間側の揃え方や止め方を少し変えていく話なのだと思います。
まだ整理中ですが、今の自分にはそんなふうに見えています。