AI駆動開発のパターンとベストプラクティス：TDD・SDD・PDD・Vibe Codingの比較と導入戦略

AI駆動開発

最終更新日: 2025.12.15

公開日: 2025.08.31

20分で読めます

はじめに

本レポートは、大規模な開発現場の開発者及び管理者を対象に、生成AIの台頭によって劇的に変化したソフトウェア開発の現在地と、開発プロセスの再定義について論じるものです。

従来のウォーターフォール開発やアジャイル開発は、「人間がコードを書く」ことを前提にプロセスが最適化されていました。

しかし、生成AIを前提とした開発（AI Native Development）では、コーディングそのもののコストが劇的に下がっています。

このパラダイムシフトにより、ボトルネックは「実装」から「要件定義」「要件のAIへの伝達」と「検証」へと移動しました。

この状況を踏まえると、AIを単なる入力補完ツールとして使うだけでは不十分です。 AIを「主体的な実装者（Agent）」として扱い、人間は「監督者（Director）」として振る舞うための新たな規律が求められています。

本レポートでは、現在主流となりつつある4つのAI駆動開発パターンを整理し、現場への導入戦略を提案します。

AI駆動開発（AI-Driven Development）の概要

まず最初に、AI駆動開発の概念を明確にしましょう。 AI駆動開発とは、AIを開発のサポーターではなく、主たる実装の担い手として位置づける開発手法の総称です。多くの場合、人間が細かいロジックを考えるのではなく、人間は「何を作りたいか（What）」や「どう検証するか（Test）」を定義し、AIが「どう作るか（How）」を解決します。

この手法により、実装速度は従来の数倍〜数十倍に跳ね上がりますが、同時に「AIが生成したブラックボックスなコード」をどう品質保証するかという新たな課題も生まれます。これに対応するために活用可能なのが、4つのアプローチを解説していきます。

AIとTDD（テスト駆動開発）を組み合わせる

TDD（テスト駆動開発）とは

TDD（Test-Driven Development）は、「実装の前にテストコードを書く」という手法です。「失敗するテストを書く（Red）」→「テストを通すための最小限の実装を行う（Green）」→「コードを整理する（Refactor）」というサイクルを繰り返します。最初に作成されたテストは、プロダクトの仕様を表現するものとして機能し、以降の実装が仕様に準拠していることを保証します。 AI時代以前から存在する手法ですが、AI開発においてその重要性は再評価されています。

AI駆動開発とTDDを組み合わせるには

具体的にAI駆動開発とTDDを組み合わせる方法を検討していきましょう。まず、最初にAIにテストコードを先に書かせます。ここで作成されたテストは、AIに対する「実行可能な仕様書」として機能する上、今後これを使うことでAIが生成したコードの正しさを即座に機械的に検証できます。

AIが実装したい機能のテストコードを書く。
AIがそのテストをパスする実装コードを生成する。
テストを実行し、失敗すればエラーログをAIにフィードバックして修正させる。

今回はこの検証として、Cursorを使ってFastAPIでTODOアプリのAPI（TODOリスト取得）を作成してみました。まず、最初に下記の指示を出してテストコードを書かせました。

FastAPIでサンプル用のTODOメモアプリのAPIを作りたいです。 TODOリストを取得するAPIを作成します。ただし、今回はTDD（テスト駆動開発）を行って開発します。まずはそのためのAPIのテストコードを作成してください。そして最初の段階ではエラーになってテストが通らないことを確認してください。

この結果、以下のようなテストコードが生成されました。

`# 実装予定のFastAPIアプリをインポート（現時点では存在しないためテストは失敗する想定） from app.main import app from fastapi.testclient import TestClient

client = TestClient(app)

def test_get_todos_returns_sample_list(): response = client.get("/todos")

assert response.status_code == 200

payload = response.json()

# 取得できるTODOは固定のサンプルデータであることを期待
expected = [
    {"id": 1, "title": "買い物に行く", "completed": False},
    {"id": 2, "title": "テストを書く", "completed": True},
]

assert payload == expected`

この段階で、テストを実行すると、当然ながらテストが失敗します。次に、以下の指示を出して、テストをパスする実装コードを書かせました。

次にテストを通すための実装を行ってください

すると、以下のような実装コードが生成されました。

`from fastapi import FastAPI

app = FastAPI()

# 固定のサンプルTODOデータ
SAMPLE_TODOS = [
    {"id": 1, "title": "買い物に行く", "completed": False},
    {"id": 2, "title": "テストを書く", "completed": True},
]


@app.get("/todos")
def get_todos():
    return SAMPLE_TODOS`

※conftest.pyその他のテスト実行に必要なファイルも自動生成されました。

そして、AIが自らテストを実行し、テストが成功しました。

AIによるテストコードのハックの対策

ここで極めて重要な注意点があります。 AIに「テストを通すような実装を生成してください」と指示すると、AIは時として「テストを通すためだけの意味のない実装」を行うことがあります。例えば、「1+1は2になる」というテストに対し、汎用的な足し算ロジックではなく、単に return 2 と書くような行為です。

先程の検証の例でも、AIがテストコードを確認可能であったため、生成されたコードはテストで想定している固定データをそのまま返すだけのものになっています。（とはいえ、今回の場合は検証用のサンプルのアプリなので他に書きようがなく、これで正しい実装だと言えますが）

一般的には、これを防ぐための対策手法として最も手軽なのはAIにテストコードの中身を見せないことです。例えば、関数のシグネチャと「テストが失敗した」という事実、あるいはエラーメッセージのみを伝えて実装させる方法です。これにより、AIは汎用的に正しいロジックを推論せざるを得なくなります。ちなみに、Cursorなどでは特定のファイルを見せないように設定することが可能です。具体的には、.cursorignoreファイルに記載したコードはAIに見せないようにできます。

AIとSDD（仕様駆動開発）を組み合わせるには

SDD（仕様駆動開発）とは

そもそもSDD（Specification-Driven Development）は、自然言語による仕様書やドキュメントを「正（Single Source of Truth）」とし、そこからコードやテスト、設計図を一貫して生成・管理するアプローチです。従来の「仕様書書いて終わり」ではなく、仕様書とコードが常に同期している状態を目指します。

Kiroを使ってSDDを行う

AWSが提供するAIネイティブIDE「Kiro」や、それに類するSpec-Drivenなツール（GitHub Spec Kit等）を活用することで、このアプローチを実現可能です。 Kiroを使用する場合は、おおまかには下記のフローで開発が進行していくのが基本パターンとなります。

Spec生成： Kiroはまずコードを書くのではなく、requirements.md（要件定義）、design.md（設計）、tasks.md（タスク一覧）といった仕様ドキュメント（Spec）を生成します。
人間によるレビュー： 人間はこの段階で仕様の矛盾や不足を指摘し、Specを修正します。
実装の自動化： 確定したSpecに基づき、KiroのAgentが自律的にファイルをまたいだ実装を行います。

この手法の最大の利点は、人間が「コードの細部」ではなく「仕様の整合性」に集中できる点です。 AIがコードを勝手に書き換えても、Specという上位概念が固定されているため、意図しない機能乖離（ドリフト）を防ぐことができます。大規模なエンタープライズ開発においても推奨されるパターンです。

さて、こちらも実際にKiroを使用して、サンプルのTODOメモアプリを開発してみました。といってもやることは単純にKiroのSpecモードでチャットに作って欲しいアプリを指示するだけです。今回は下記のように指示しました。

サンプルのTODOメモアプリをfastAPIで構築して。

ざっくりとした指示ですが、これを受けてKiroは自動的に.kiroフォルダの配下にrequirements.mdやdesign.mdやtasks.mdといった仕様書群を生成しました。

実装に入る前に、これらの仕様書群の内容を確認し、必要に応じて修正や追加を行います。多くの場合、テストコードの実装などもこの段階で計画されます。

そして、そのまま仕様書の内容を実装させてみたところ、無事メモアプリのAPIが完成し、問題なく起動が出来ました。

PDD（プロンプト駆動開発）を実施するには

PDDとは

ここでいうPDD（Prompt-Driven Development）は、詳細に構造化されたプロンプト自体を「プロダクトの仕様が詰まった設計図」と見なし、一度の実行で高品質な出力を得る手法です。単なるチャット指示とは異なり、要件、制約条件、出力形式、エッジケースの扱いなどを網羅したいわば「スーパープロンプト」を作成・管理します。 SDDと似ていますが、PDDはドキュメントという中間生成物を経ずに、プロンプトから直接実装へジャンプする傾向があります。また、単純なプロンプト作成→LLMで出力というフローのみを実行できれば良いため、ChatGPTやGeminiなどの汎用AIサービスでも実践可能です。社内規約などで、これらのサービスのみが使用可能な場合に有効です。ただし、大規模なプロジェクトではプロンプトが長大になりすぎたりするケースがあるため、その場合は開発する機能群ごとにプロンプトを分割・管理する工夫が必要です。また、割り切ってPoCなどの短期開発に限定してPDDを採用するのも一つの手です。

PDDを実施する手順

PDDを実施するには、以下のステップを踏みます。

プロンプト作成： 役割（Role）、タスク（Task）、制約（Constraints）、出力形式（Format）などを定義したMarkdownテンプレートを用意する。
生成と検証： AIに入力し、出力を確認。修正が必要な場合はコードを直すのではなく、プロンプトを修正して再生成する。

PDDの概念はこれだけのステップで完結するものなので、AI駆動開発をまずは始めてみたい場合にも手軽に導入できる方法です。

Vibe Codingを実施するには

Vibe Codingとは

著名なAI研究者Andrej Karpathy氏らが提唱し、SNS等で話題となった開発スタイルです。「Vibe（雰囲気・ノリ）」に身を任せ、コードの詳細を一行一行読むことを放棄し、「書いて、走らせて、エラーが出たらエラーログをAIに投げて直させる」を高速回転させる手法です。人間はコードレビューをあまり行わず、動作確認（Run）のみに責任を持ちます。「Accept All（全て承認）」ボタンを連打するスタイルとも言えます。ここまでのTDDやSDDの検証として行ってきた手法も、Vibe Codingの一種とみなすこともできます。非エンジニアが作りたいプロダクトの使用感をざっくり検証したり、本開発の前にプロトタイプを高速に作成したりするのに適しています。

適用シーンハッカソン、PoC（概念実証）、使い捨てのスクリプト作成など、「品質」よりも「速度」と「動くこと」が絶対的な正義である場面で無類の強さを発揮します。一方で、技術的負債が積み上がりやすく、また人間がどうしても実装の詳細を確認しない状況になりがちなので、セキュリティ脆弱性が混入しても気づけないリスクがあります。そのため、基幹システムでの採用は慎重になるべきとの意見もあります。

Vibe Codingを実施する手順

CursorやWindsurfなどのAIエディタを使用したり、Claude Codeを使用するのが簡単です。

ざっくり指示： 「画面中央にボタンを配置して、押すと花吹雪が舞うようにして」と自然言語で指示。
実行＆エラー： 即座に実行。動かなければターミナルのエラーをコピー（またはAIツールが自動検知）し、「直して」とだけ指示。もしくは設定によってはAIが自動で修正を試みる。
ループ： 動くまでこれを繰り返す。コードの中身は頻繁には見ない。

現代のLLMの精度であれば、小規模なPoCであれば人間の助けなしにAIが完結させられることも珍しくありません。

大手SIerにおけるAI開発手法の選び方とベストプラクティス

ここまで紹介した4つの手法は、相反するものではなく、適材適所で使い分けるべきツールです。以下に選定マトリクスを示します。

基幹システム・コアロジック（品質重視）： TDD + SDD- 絶対にバグが許されない領域では、人間が書いたテスト（TDD）と詳細な仕様書（SDD/Kiro）でAIを厳格に管理すべきです。なお、金融領域や決裁系システムなどではAIが出力したコードに対して最終的な人間のチェックを怠らないようにしましょう。
社内ツール・管理画面・PoC（速度重視）： Vibe Coding- 多少のバグがあっても即座に修正できれば問題ない領域では、圧倒的な速度が出るVibe Codingが最適です。
クイックにAI駆動開発を試したい： PDD- まずはAI駆動開発を試してみたい場合、PDDは最も手軽に始められます。特にChatGPTやGeminiなどの汎用AIサービスしか使えない場合に有効です。

まとめ

生成AIの登場により、ソフトウェア開発は「コードを書く作業」から「仕様を定義し、AIを監督する作業」へとシフトしました。 TDDで品質を担保し、SDDで仕様の整合性を保ち、PDDで知見を資産化し、Vibe Codingで爆発的な速度を得る。これらを状況に応じて使い分けることが、これからの開発組織には求められます。

特定のツールに固執する必要はありません。しかし、「人間がコードを一行一行書く」という前提を捨て、AIをパートナーとしてプロセスを再定義することは急務です。まずは小規模な社内ツール開発において、KiroやCursorを導入し、これら4つのパターンを試験的に運用してみることを推奨します。

FAQ generated by AI

CursorやWindsurfなどのエディタでも、Markdownで書いた仕様書（requirements.md）をコンテキストとして読み込ませ、「この仕様書に従って実装して」と指示することで、擬似的にSDDを実践可能です。

そのままでは保守性が低い傾向にあります。プロトタイプが完成した後、正式採用が決まった段階で、改めてテストコードを追加したり、リファクタリング（AIに行わせることも可能）を行ったりして、技術的負債を解消するフェーズを設けるべきです。

教育的観点からは推奨されません。コードの中身を理解せずに出力する癖がつくと、トラブルシューティング能力が育たないためです。学習段階ではAIに「なぜそのコードになるのか」を解説させるプロセスを挟むよう指導してください。

AIは動くコードを書くのが得意ですが、セキュアなコードを書くとは限りません。生成されたコードに対し、静的解析ツール（SAST）を通すことや、セキュリティレビューのプロセスは従来通り、あるいはそれ以上に厳格に行う必要があります。