ぼくのかんがえた最強のチーム開発AI活用
この記事の内容は100%人間が生成しています。
ここで言う「AI」は、claude codeなどのAI Agent系サービスのことを指しています。
ここで話すAIの特性等は、体系的に学んだものではなく、筆者の体感です。
チーム開発とAI活用って相性悪くない？
きっとこの記事の読者さんは、バイブコーディングを嗜んだ経験があるだろう。AIにざっくりした要求をポイと投げれば、それが文書化され、設計が組まれ、タスクに切り出され、タスクの上の方からチョチョイのチョイ〜っと実装されていく。そんな様を眺めていると・・・
これ、一人でやった方が効率いいわね。
そんな考えが頭をよぎる。
チームでのAI活用は、そこそこ課題がある。
以下のような事象を観測した覚えはないだろうか？
- 品質の低いMRが量産され、レビュアーが苦しめられる
- 変な方針で無理やりバグ修正している、足並み揃えてない実装等
もうウチがゼロイチで実装し直していいですかぁ・・・？
- AIが巨・プロンプトに耐えきれず、指示を無視しまくる
- 議事録も開発ルールも受け入れ基準も、何もかもをdoc/に入れとけば、きっとAIがいい感じに全部見てくれて開発中ずっと厳守してくれるよね。そんな訳ないよね。
- プロンプトに誤った情報や無茶な要求が書いてあり、AIのノイズになっている
- 既存コードに対して一切手を入れずに、カバレッジ率100%にしろってそんな無茶な・・・
- フォルダ構成図の情報が古いせいで、AIが一回古いフォルダ構成でファイル検索かけちゃってるよ・・・
- 他人が作ったプロンプトや自動化スクリプト、使わない
- 上記のような事象がままあるため、もはや使う気が起きない
- 何が起きるかわからないスクリプトも怖いので使う気が起きない
- プロジェクト内でのAI活用方法が統一されていない
- AI戦国時代の渦中なので、皆各々好きなAIを使っている
- CLAUDE.mdをこだわって書いたとて、claude使ってなかったら意味ない
- kiroでタスク管理しようって言っても、kiro使ってなかったらタスク進捗更新されないです
- 既存実装の品質が低いと詰む
- 既存実装の品質が低く、AIがそれにあわせて品質が低いコードを書かざるをえない状態になっている
- 既存実装の品質が低すぎて、AIがもはや実装不可能な状態になっている
ぼくのかんがえた最強のチーム開発AI活用
解決策です。
大前提
- ドキュメント全般はgit管理する
- Figmaなど、どうしてもgit上で扱えないものは、MCPで接続できるようにしておく
- DBスキーマ定義やリソースデプロイはコードベースで行う
- 世の中には、まれに手作業でDBスキーマ更新・リソース変更しているプロジェクトがある。ビビる。ほとんどの場合はコードベースでやった方がいいと思う・・・
ドキュメンテーション
AIが動きやすいようにシンプルに、明示的に。
コンテキストの肥大化はAIの精度をモロに下げる。
書かなくていい情報は書かない
見ればわかる情報や、別ファイルに書いてある情報をいちいち書かない。
更新モレ予防にもなる。
ex...
❌ディレクトリのツリーを詳細に書く
⭕️「ディレクトリはクリーンアーキテクチャに基づいた構成です」とか「MVCモデル」だけ書く
❌「webアプリはlocalhost:5173で接続できます、db接続文字列は~~~です」と書く
⭕️「接続情報はcompose.yaml参照」と書く
プロンプトを中途半端に使い回そうとしない
個人用プロンプト置き場を作り、gitignoreする
そもそもAIは個人と喋っていて、複数人と喋っているものではない。
他人の対話用プロンプトをそのまま使っても、「今これ私が喋りたいことじゃないな」と上手く噛み合わないことが多い。
.gitignoreしたtemp/フォルダを掘り、そこに各々自分用のプロンプトを入れよう。
最低限共通認識として持っておきたい情報だけ、docに書いておく
CLAUDE.mdやCODEX.mdには、「そのdocを見るように」とだけ書いておく。
docは必要最小限の情報のみにする。
「この時にはこのプロンプトで実行する」を徹底する
しっかりした詳細設計書がもうあり、その通りに動く物を作らないといけない、といった時にコンテキスト肥大化を防ぐテク。
何をする時にどのドキュメントを見れば良いかを明示する。
- 「APIいじる時はAPI設計書見て〜」とか
- 「実装いじる時はコーディング規約とテスト規約見て〜」とか
- 「デザイン実装する時はMCPサーバ経由でFigma見て〜」とか
参考
実装
プロジェクトの開発最初期に、その後の実装の軸となる「一連のレイヤーを網羅する」機能を1つ実装する
例えばダッシュボードwebアプリなら、認証 ~ UI ~ APIリクエスト ~ API内認証 ~ DB更新 ~ APIレスポンス ~ UI更新 などの、一連のレイヤーを網羅するように機能を実装する。
ワンパステストが通るように、と言った方が伝わるだろうか。
そして、「この技術要素、この作り方を軸にしていれば、後の実装は全部AIに任せても大丈夫そうだね」と思えるまでレビューする。
最後に、レビューを通過したら、開発プロンプトに「XXX(軸にした機能)と足並みを揃えて実装してください。」と入れる。
※このセクションは、AIの精度が上がったら将来的に消えると思われる
（2025年10月時点）未だに、偶にAIがビミョーな実装をすることがある。
たまたま最初にAIがビミョーな実装をして、他の実装が後に続いて・・・となると大変しんどいため、このセクションを設けている。
最初の骨組みさえよければ、それを真似るよう指示を出せばいいので。
人力実装は基本禁止
案件情報や設計が出揃っていて、あとはフレームワークに沿って実装するのみ、となれば、もはや人力でコーディングする必要はない。
フレームワーク=枠組みである。それに沿ってコーディングすれば、誰がやっても似たような実装になるようになっている。じゃあもう人間が実装する必要はないですね？そうですね？
AIがフレームワークに忠実な実装をしていれば、後々に改修作業が発生した際、人間もAIも確認すべき箇所を探しやすくなる。
複雑度が高い箇所・重要度が高い機能はこの限りではない。AIにどれだけ仕事を取られても、人間には「責任を取る」という仕事が最後まで残り続けるのだ・・・
E2Eテストのテスト名を自然言語で書いて、仕様書=テストにする
以下は、ログイン機能の仕様書=テストの例。
重要度が低い機能は、コードに対する人力レビューなしでこのテストのみで品質担保をしてもいいと思う。
その他
案件特性に合った導入の仕方をする
ゼロイチ開発であれば上記の運用を導入しやすいが、既存アプリのリプレイス案件や、納品後の不具合修正フェーズといったプロジェクトだと、運用を変えるコストが高く、メリット < コストになりかねない。
そのような場合は、デグレが怖い箇所だけE2Eテストを導入するとか、部分的に運用を適用すると良い。
終わりに
お読みいただきありがとうございます。
ご指摘やご意見あれば気軽に投げていただければと思います。
では〜👋
Discussion