テストを先に考え、品質を均一化しながらチームとAIが学習し続ける進め方

AI駆動開発は、実装スピードを大きく引き上げてくれます。

一方で、実際に複数人で進めてみると、別の課題が見えてきます。

人によってAIの使い方が違う
実装品質にばらつきが出る
AIがもっともらしいコードを書いても、設計上の問題が残る
実装後にテストを追加すると、実装に都合のよいテストになりやすい
同じようなミスが別のPRで再発する
外部メンバーが増えるほど、ノウハウや判断基準が分散する

そこで重要になるのが、AIを単なる「コードを書く道具」として使うのではなく、開発プロセスそのものにAIを組み込むことです。

特に意識したいのが、実装より先に「何を満たせば正しいのか」を決めることです。

そこで、AI駆動開発を次の6つの層に分けて考えます。

AI駆動開発の6層構造

全体の流れは次のようになります。

顧客要望 / Issue / 仕様書 / ADR / 既存コード情報
        ↓
① Planner Agent
        ↓
Implementation Plan
        ↓
② Tester Agent
   仕様起点でテスト・完成条件を設計
        ↓
③ Implementer
   テスト・完成条件を満たすように実装
        ↕
② Tester Agent
   実装を見て追加テスト
        ↓
lint / typecheck / unit / integration / e2e / security
        ↓
④ Reviewer Agent
        ↓
PR
        ↓
⑤ Independent AI PR Review
        ↓
Human Review
        ↓
Merge
        ↓
⑥ Learning Loop
        ↓
Rules / Skills / Hooks / Tests / ADR 更新

ポイントは、1つのAIに計画・実装・テスト・レビューをすべて任せないことです。

さらに、

実装してからテストを書く

のではなく、

要件を整理したら、まずテストと完成条件を考える

という流れにしています。

いわゆるTDD（テスト駆動開発）的な考え方を、AI駆動開発にも取り入れるイメージです。

① Planner Agent (まずは計画から)

いきなりコードを書かず、まず「何を変えるのか」を整理する

AI駆動開発では、要望を受け取ったらすぐAIにコードを書かせたくなります。

しかし、ここで方向を間違えると、実装速度が速いぶん間違った方向にも速く進んでしまいます。

そこで最初に動くのが Planner Agent です。

Plannerには、たとえば次のような情報を与えます。

顧客からの要望
Issue
仕様書
ADR
現在のコード構造
DB Schema
API仕様
関連する既存機能
関連テスト
過去の変更履歴
過去に起きた問題やLessons

そのうえで、

何を変更するのか
どこに影響するのか
既存仕様と矛盾しないか
セキュリティ上の問題はないか
migrationは必要か
どのようなテストが必要そうか
不明点は何か

を整理します。

たとえばPlannerの出力を、次のような形式に揃えてもよいでしょう。

requirement:
current_behavior:
affected_modules:
proposed_design:
security_considerations:
migration_considerations:
test_strategy:
risks:
unknowns:

Plannerはコードを書く役ではありません。

実装前の地図を作る役割です。

② Tester Agent (テストを先行で)

コードを書く前に「何ができれば完成なのか」を決める

Plannerが計画を作ったら、次にImplementerへ進むのではなく、Tester Agent を動かします。

ここがこの構造の重要なポイントです。

先に実装してしまうと、その後のテストが、

今ある実装が動くことを確認するテスト

になりがちです。

しかし本来確認したいのは、

顧客要望や仕様を正しく満たしているか

です。

そのため、Tester Agentには原則として実装コードを見る前に、要件・仕様・Implementation Planからテストを考えさせます。

確認するのは、たとえば次のような観点です。

正常系
異常系
境界値
権限違反
他ユーザーからのアクセス
他テナントからのアクセス
データが存在しない場合
外部APIが失敗した場合
再実行された場合
migration前後
既存機能への影響

たとえば「案件削除機能」であれば、

・通常の案件は削除できる
・存在しない案件は削除できない
・他ユーザーの案件は削除できない
・他Tenantの案件は削除できない
・確定済み案件は削除できない

といった完成条件を先に定義します。

これによって、Implementerへ、

この条件を満たす実装を作ってください

と渡せるようになります。

TDDを厳密にやることが目的ではない

ここでいうTDD的な進め方は、必ずしもすべてのコードについて、

Red
↓
Green
↓
Refactor

を厳密に繰り返すという意味ではありません。

重要なのは、

実装より先に期待する振る舞いを定義する

ことです。

AI駆動開発では、AIは非常に高速にコードを書けます。

だからこそ、

何を書けば完成なのか

という制約を先に与えたほうが、暴走しにくくなります。

③ Implementer (実装)

テストと完成条件を満たすように実装する

Testerが完成条件を整理したら、Implementerが実際のコードを書きます。

Implementerへの入力には、

Implementation Plan
テストケース
Acceptance Criteria
共通Rules
案件固有Rules
関連Skills

などを含めます。

つまり、

顧客要望
↓
設計
↓
テスト・完成条件
↓
実装

という順番です。

Implementerでは、

既存アーキテクチャとの整合
責務分離
重複コードの回避
validation
authorization
tenant isolation
error handling
logging
migration
backward compatibility

なども確認します。

AIが自由に「それっぽい実装」を作るのではなく、先に決めた制約の中で実装させることが重要です。

TesterとImplementerは一度で終わらない

②Tester → ③Implementerという順番にしていますが、完全な一方向ではありません。

実装を見て初めて見つかる問題もあります。

そのため、

Tester
  ↓
Implementer
  ↓
Tester
  ↓
Implementer

という往復を許容します。

最初のTesterは 仕様起点。

実装後のTesterは 実装起点 です。

仕様起点で見るもの

要件
Acceptance Criteria
正常系
異常系
境界値
権限
業務ルール

実装起点で追加するもの

分岐漏れ
exception
race condition
想定外入力
transaction
migration
regression
実装特有の副作用

つまり、

仕様から先にテストを作り、実装後にさらに穴を探す

という二段構えです。

AIにレビューさせる前に、機械で確認できることは機械で止める

TesterとImplementerのやり取りが終わったら、自動チェックを通します。

たとえば、

format
↓
lint
↓
typecheck
↓
build
↓
unit test
↓
integration test
↓
e2e
↓
dependency scan
↓
security scan
↓
static analysis

などです。

ここで大切なのは、何でもAIレビューに任せないことです。

それぞれ得意な仕事があります。

手段	主な確認対象
Compiler / Type Check	型
Lint	コーディングルール
Static Analysis	危険なコードパターン
Security Scan	既知のセキュリティ問題
Unit Test	小さな単位の挙動
Integration Test	DB・API等との連携
E2E	重要なユーザーフロー
AI Review	文脈・設計・仕様との整合

確定的に検査できるものは、できるだけ確定的な仕組みに任せる。

AIはその上の、意味や文脈を考える層で使います。

④ Reviewer Agent (批判的なレビュー)

「たぶん正しい」ではなく「何か間違っていないか」で見る

自動チェックを通過したら、Reviewer Agentへ進みます。

Reviewerは、実装者の説明をそのまま信用する役ではありません。

むしろ、

この実装には何か問題があるかもしれない

という立場でレビューします。

たとえば、

要件漏れ
hidden assumption
変更漏れ
architecture violation
不要な複雑化
重複実装
セキュリティ
validation不足
authorization不足
テスト不足
migrationリスク
既存機能へのregression

などを探します。

実装AgentとReviewer Agentを分離することで、同じ思考の延長線上だけで品質確認することを避けます。

⑤ Independent AI PR Review (独立したレビュー)

PR後に、開発工程とは独立したAIでもう一度疑う

Reviewerを通過したらPull Requestを作成します。

しかし、ここでもう一段レビューを追加します。

それが Independent AI PR Review です。

実装時のAIやReviewerとは別のコンテキストから、PR全体をもう一度確認します。

たとえば、

Architecture Reviewer
Security Reviewer
Test Reviewer
Critical Reviewer

のように観点を分離できます。

同時に、

CodeQL
Semgrep
dependency scan
secret scan
CI

なども実行します。

ここでの目的は、

人間のReviewerへ渡す前に、AIと機械でできるだけ粗を落とすこと

です。

そうすることで人間は、

本当に顧客の課題を解決しているか
この設計判断でよいか
運用上問題ないか
将来的に保守できるか
リリースして問題ないか

といった、人間が判断すべき部分へ集中できます。

Human Reviewはなくさない (人の最終チェック)

AIレビューを何層追加しても、最終的なHuman Reviewは残します。

AI駆動開発では、

AIレビューが通ったから安全

とは考えない方がよいでしょう。

AI、テスト、静的解析、セキュリティスキャンにはそれぞれ守備範囲があります。

そのため、

機械
+
AI
+
人間

による多層レビューとします。

⑥ Learning Loop (学習のループ)

PRで見つかった問題を「次回の標準」に変える

そして最後が Learning Loop です。

この6層構造の中でも、特に重要な部分です。

たとえばReviewerが、

tenant条件の付け忘れがあります

と指摘したとします。

そのPRだけ直して終われば、次のPRでも再発する可能性があります。

そこで、

なぜ起きた？
↓
また起きる？
↓
どうすれば次回から自動的に防げる？

と考えます。

反映先としては、

Rules
Skills
Hooks
Tests
ADR
Static Analysis
Semgrep
CI
Review Checklist

などがあります。

人ではなく「仕組みに覚えさせる」

たとえばtenant条件漏れなら、

PRで指摘
↓
Lessonとして記録
↓
Multi Tenant Rule追加
↓
Repository Pattern追加
↓
Integration Test追加
↓
Semgrep Rule追加

という形にできます。

最初は人やAIが見つけた問題でも、次回からは静的解析やテストが止めてくれるようになります。

これがLearning Loopの狙いです。

経験
↓
Lesson
↓
Knowledge
↓
Rule
↓
Skill
↓
Test
↓
Static Analysis
↓
Quality Gate

つまり、

人が覚えるのではなく、開発環境そのものに覚えさせる。

これを繰り返します。

6層構造を支える「AI駆動開発ナレッジベース」

このLearning Loopを成立させるためには、RulesやLessonsを置く場所も必要になります。

そこで別途、

AI駆動開発ナレッジベース

を用意します。

たとえば、

Common
├─ Security
├─ Git / PR
├─ Agent
├─ Testing
└─ Architecture

Languages
├─ TypeScript
├─ C#
└─ Python

Frameworks
├─ Next.js
├─ NestJS
├─ ASP.NET Core
└─ FastAPI

Cloud
├─ Azure
├─ AWS
└─ Cloudflare

Data
├─ Prisma
├─ EF Core
├─ PostgreSQL
└─ SQL Server

といった形です。

各案件は必要なナレッジだけを組み合わせます。

そして案件内で得られたLessonのうち、他案件にも使えるものは共通知識へ戻します。

外部メンバーを含むチームほど効果が大きい

この構造は、複数人や外部メンバーを含む開発で特に効果があります。

全員へ、

同じ品質で開発してください

と言うだけでは、なかなか揃いません。

人によって、

得意分野
経験
AIへの指示方法
テストの考え方
レビューの細かさ

が異なるからです。

それよりも、

同じPlanner
同じTester
同じRules
同じCI
同じReviewer
同じPR Review

を通す仕組みにする。

重要なのは、人を均一にすることではなく、成果物が通る工程を均一にすることです。

最初から6層すべてを完璧にする必要はない

ここまで仕組み化すると、大規模に見えるかもしれません。

しかし、最初からすべて完成させる必要はありません。

たとえば次の順番で始められます。

Step 1

Plannerを分ける
TesterをImplementerより先に動かす
PRを必須化する

Step 2

lint
typecheck
build
unit test
integration test
secret scan

を自動化する。

Step 3

Reviewer Agent
Independent AI PR Review
Semgrep
Security Scan

を追加する。

Step 4

PRで見つかった問題をLessonとして保存し、

Lesson
↓
Rule
↓
Skill
↓
Test / Static Analysis

へ昇格させる。

このように、実案件を通して開発基盤を少しずつ育てていく方が現実的です。

まとめ

AI駆動開発では、コードを書く速度は確実に上がっています。

だからこそ次に重要になるのは、

高速な開発を、高品質のまま繰り返す仕組み

です。

今回の6層構造では、

Planner Agent
要件整理・影響調査・設計
Tester Agent
実装前にテストと完成条件を定義
Implementer
テストと設計を満たすように実装
Reviewer Agent
実装を批判的にチェック
Independent AI PR Review
PR後に別視点から再チェック
Learning Loop
指摘や失敗を次のRules・Skills・Testsへ反映

という役割分担を行います。

特に、

Planner
↓
Tester
↓
Implementer

という順番が重要です。

AIがコードを書く前に、

何を満たせば完成なのか

を先に決めておく。

そして実装後にもTesterを戻し、実装固有の穴を探します。

さらに、レビューで見つかった問題をその場限りで終わらせず、

Rules
Skills
Hooks
Tests
ADR
Static Analysis

へ戻していく。

こうすることで、

開発するほど、次の開発が安全で速くなる

という状態に近づいていきます。

AI駆動開発の本当の強みは、単にAIが高速にコードを書けることではありません。

人とAIが得た知識を、次の開発プロセスへ継続的に反映できること。

そこまで仕組み化できると、AI駆動開発は単なる開発効率化ではなく、チーム全体の開発力を継続的に高める仕組みになっていきます。

AI駆動開発を強くする「6層構造」とは

テストを先に考え、品質を均一化しながらチームとAIが学習し続ける進め方

AI駆動開発の6層構造

① Planner Agent (まずは計画から)

いきなりコードを書かず、まず「何を変えるのか」を整理する

② Tester Agent (テストを先行で)

コードを書く前に「何ができれば完成なのか」を決める

TDDを厳密にやることが目的ではない

③ Implementer (実装)

テストと完成条件を満たすように実装する

TesterとImplementerは一度で終わらない

仕様起点で見るもの

実装起点で追加するもの

AIにレビューさせる前に、機械で確認できることは機械で止める

④ Reviewer Agent (批判的なレビュー)

「たぶん正しい」ではなく「何か間違っていないか」で見る

⑤ Independent AI PR Review (独立したレビュー)

PR後に、開発工程とは独立したAIでもう一度疑う

Human Reviewはなくさない (人の最終チェック)

⑥ Learning Loop (学習のループ)

PRで見つかった問題を「次回の標準」に変える

人ではなく「仕組みに覚えさせる」

6層構造を支える「AI駆動開発ナレッジベース」

外部メンバーを含むチームほど効果が大きい

最初から6層すべてを完璧にする必要はない

Step 1

Step 2

Step 3

Step 4

まとめ

関連記事

Claude Codeで何でも作れる？実際にAI駆動開発をやると見えてくる「本当に難しいところ」

AI駆動開発を「フィードバックで育つ仕組み」にする

AI駆動開発をチームで進めるための「8つの原則」

お気軽にご相談ください

AI駆動開発を強くする「6層構造」とは

テストを先に考え、品質を均一化しながらチームとAIが学習し続ける進め方

AI駆動開発の6層構造

① Planner Agent (まずは計画から)

いきなりコードを書かず、まず「何を変えるのか」を整理する

② Tester Agent (テストを先行で)

コードを書く前に「何ができれば完成なのか」を決める

TDDを厳密にやることが目的ではない

③ Implementer (実装)

テストと完成条件を満たすように実装する

TesterとImplementerは一度で終わらない

仕様起点で見るもの

実装起点で追加するもの

AIにレビューさせる前に、機械で確認できることは機械で止める

④ Reviewer Agent (批判的なレビュー)

「たぶん正しい」ではなく「何か間違っていないか」で見る

⑤ Independent AI PR Review (独立したレビュー)

PR後に、開発工程とは独立したAIでもう一度疑う

Human Reviewはなくさない (人の最終チェック)

⑥ Learning Loop (学習のループ)

PRで見つかった問題を「次回の標準」に変える

人ではなく「仕組みに覚えさせる」

6層構造を支える「AI駆動開発ナレッジベース」

外部メンバーを含むチームほど効果が大きい

最初から6層すべてを完璧にする必要はない

Step 1

Step 2

Step 3

Step 4

まとめ

関連記事

Claude Codeで何でも作れる？ 実際にAI駆動開発をやると見えてくる「本当に難しいところ」

AI駆動開発を「フィードバックで育つ仕組み」にする

AI駆動開発をチームで進めるための「8つの原則」

お気軽にご相談ください

Claude Codeで何でも作れる？実際にAI駆動開発をやると見えてくる「本当に難しいところ」