AI駆動開発をチームで進めるための「8つの原則」
AIを使った開発は、一人で試すだけならかなり自由に進められます。
Claude CodeやCodexなどを使えば、設計、実装、テスト、修正まで、かなりの範囲をAIに任せられるようになってきました。
一方で、これを複数人のチーム開発に広げようとすると、少し事情が変わります。
社内メンバーだけでなく、外部の開発パートナーも含めてAI駆動開発を進める場合、それぞれが好きな方法でAIを使ってしまうと、コード品質や設計思想、テストの粒度、ドキュメントの残し方などがバラバラになりやすくなります。
AI駆動開発では「どのAIを使うか」以上に、どのような考え方でAIを使うかを揃えることが重要です。
そこで今回は、AIハーネスやAIループ、Rules、SKILL、Hooksといった具体的な仕組みに入る前段として、チームで共有しておきたい「AI駆動開発の8つの原則」を整理します。
1. AIの記憶を信用しない
AIとの開発で最初に理解しておきたいのが、AIの記憶を前提にしてはいけないということです。
AIには会話履歴やMemory機能などがありますが、プロジェクトに必要な情報を常に正確に覚えているとは限りません。
昨日伝えた設計方針を、今日の別セッションでも当然理解している前提で進めると、認識のズレが起こります。
そのため、重要な情報はAIの中ではなく、外部に残します。
たとえば、
- AGENTS.md
- Rules
- SKILL
- docs
- ADR
- 設計書
- コーディング規約
- セキュリティガイド
などです。
考え方としては、
「AIに覚えてもらう」のではなく、「AIが必要な情報をいつでも読み直せるようにする」
という方が適切です。
これは人間のメンバーが増えた場合にも、そのままナレッジ共有の基盤になります。
2. AIの判断を信用しすぎない
AIは非常に優秀ですが、出力にはどうしても揺らぎがあります。
同じような指示でも微妙に異なる実装になることがありますし、一見正しそうに見えるコードに問題が含まれていることもあります。
そこで重要になるのが、AIの判断とは別に、機械的に正しさを確認できる仕組みを持つことです。
代表的なものとしては、
- Lint
- Format
- 型チェック
- Unit Test
- Integration Test
- Build
- Security Scan
- Dependency Check
などがあります。
AIが「問題ありません」と言ったかどうかではなく、
テストが通ったか、型エラーがないか、ビルドできるか
を基準にします。
AIの確率的な判断を、決定論的な仕組みで支える考え方です。
3. AIに自己採点させない
AIにコードを書いてもらった後、そのまま同じAIに、
「問題がないか確認してください」
と聞くことがあります。
もちろん一定の効果はあります。
ただし、AIは直前まで自分が考えていた前提や設計に引っ張られやすいため、同じ観点のままレビューしてしまうことがあります。
そこで、重要な実装については独立した観点からレビューすることが必要です。
たとえば、
実装担当AI
↓
レビュー担当AI
↓
静的解析
↓
人間レビュー
という形です。
別セッション、別Agent、場合によっては別モデルを使う方法もあります。
大切なのは、
「作った人が、そのまま最終確認者にならない」
という昔からの開発原則を、AIにも適用することです。
4. AIに自由に触らせすぎない
AIは問題を解決しようとすると、思った以上に広い範囲を変更することがあります。
たとえば「このAPIの不具合を修正して」と依頼しただけなのに、
- DBスキーマ
- 共通ライブラリ
- 認証処理
- 別モジュール
- 設定ファイル
まで変更してしまう可能性があります。
ここで「そのファイルは触らないでください」とプロンプトに書くだけでは十分ではありません。
より強い方法は、アーキテクチャ自体に境界を持たせることです。
たとえば、
- モジュール間の依存方向を決める
- Domain層からInfrastructure層を直接参照させない
- 特定ディレクトリへの変更を検知する
- 権限を必要最小限にする
- 本番操作には承認を必要とする
といった仕組みです。
AIの振る舞いを「お願い」で制御するのではなく、
構造で制御する
ことが重要になります。
5. AIの失敗を使い捨てない
AI駆動開発では、失敗そのものをなくすことは難しいです。
重要なのは、同じ失敗を何度も繰り返さないことです。
たとえば、マルチテナントのシステムでAIが tenant_id の条件を付け忘れたとします。
その場で修正して終わりにすると、別の画面や別の担当者でも同じ問題が起こる可能性があります。
そこで、
問題発生
↓
原因分析
↓
再発防止
↓
Tests / Rules / SKILL / Docsへ反映
↓
次の開発で自動的に利用
という流れを作ります。
つまり、AIの失敗をチームの知識に変換するわけです。
これがAI駆動開発におけるフィードバックループの基本になります。
6. AIに一度に任せすぎない
AIが高性能になると、つい大きな仕事をまとめて依頼したくなります。
たとえば、
「認証を追加して、DBを変更して、画面も作って、テストを書いて、リファクタリングまでしてください」
という依頼です。
できる場合もありますが、タスクが大きくなるほど途中の判断も増えます。
結果として、どこで間違えたのか分かりにくくなり、レビューも難しくなります。
そのため、
Plan
↓
小さなTask
↓
Implement
↓
Verify
↓
次のTask
という流れに分解します。
AI駆動開発では、AIの性能を上げるだけでなく、
AIが迷いにくい単位まで仕事を分けること
も重要な設計になります。
7. AIの「できました」ではなく証拠を見る
AIは作業終了時に、
「実装が完了しました」
「すべて正常に動作します」
と報告してくれます。
しかし、本当に確認すべきなのは文章ではありません。
たとえば、
- Unit Test 386件 Passed
- Integration Test 42件 Passed
- Lint Error 0
- Type Error 0
- Build Success
- Security Scan Critical 0
といった実行結果です。
つまり、
AIの説明ではなく、検証結果を完了条件にする
ということです。
これをチーム共通ルールにしておけば、「本人の環境では動きました」という問題もかなり減らせます。
Pull Request時にCIを必須にすることも、この原則の延長線上にあります。
8. 最後は人が責任を持つ
AI駆動開発だからといって、すべてをAIだけで完結させる必要はありません。
むしろ、リスクに応じて人間が入る場所を決めることが重要です。
たとえば、
- UIの微修正
- テスト追加
- ドキュメント修正
- 小さなリファクタリング
などは、かなり自動化しやすい領域です。
一方で、
- 認証・認可
- 個人情報
- マルチテナント
- DB Migration
- 決済
- 秘密情報
- 本番インフラ
- 大きなアーキテクチャ変更
などは、人による承認を入れた方が安全です。
すべて人間が確認するのでもなく、すべてAIに任せるのでもありません。
リスクに応じてHuman in the Loopを設計する
ことが重要です。
AIツールを揃えるより、原則を揃える
チームでAI駆動開発を始める際、
「Claude Codeを使うのか」
「Codexを使うのか」
「どのモデルを使うのか」
といったツール選定に目が行きがちです。
もちろんツールも重要です。
ただ、それ以上に重要なのは、チーム全員が同じ原則で開発することです。
まとめると、今回の8原則は次のようになります。
- 記憶を信用しない
重要情報は外部に残す - 判断を信用しすぎない
機械的に検証する - 自己採点させない
独立したレビューを入れる - 自由に触らせない
境界と権限を設ける - 失敗を使い捨てない
仕組みにフィードバックする - 一度に任せすぎない
小さく分けて進める - 報告ではなく証拠を見る
実行結果を確認する - 最後は人が責任を持つ
重要箇所には承認を入れる
原則の次に「仕組み」を作る
これらの原則を共有しただけでは、まだ十分ではありません。
次の段階では、原則を守りやすくする仕組みを作ります。
たとえば、
- Rules
- AGENTS.md
- SKILL
- Hooks
- GitHub Actions
- Lint
- Tests
- AI Review
- Architecture Test
- セキュリティチェック
- フィードバック管理
などです。
これらを組み合わせたものが、AIハーネスやAIループにつながっていきます。
重要なのは、
「全員に気をつけてもらう」のではなく、「普通に開発すれば原則が守られる環境を作る」
ことです。
外部パートナーを含めたチームでAI駆動開発を進めるのであれば、個人のAI活用スキルに品質を依存させるのではなく、共通ルールと仕組みの中でAIを使う。
これが、AI駆動開発を個人技からチーム開発へ広げていくための第一歩だと思います。
