AI vibe codingと仕様駆動開発：AI時代から考える開発体制と品質保証

AI vibe coding（バイブコーディング）は、エンジニアが厳密なアルゴリズムや構文の細部を意識することなく、自然言語で「こんな感じの機能が欲しい」「こういうUIを作って」とAIに伝えてコードを生成させる手法です。

このアプローチの最大のメリットは、圧倒的な「速度」です。アイデアを思いついてから、実際にブラウザ上で動作するプロトタイプ（試作品）が出来上がるまでの時間が劇的に短縮されます。特にフロントエンドのUI試作や、新規プロジェクトの立ち上げ時には、手作業でコーディングする感覚とは次元の違うスピードを体感できます。

また、新しいプログラミング言語や、これまで触れたことのないフレームワークを扱う際の学習コストが大幅に下がるという利点もあります。「どのように書くか（How）」の大部分をAIが補ってくれるため、開発者は「何を作りたいか（What）」という探索的なアプローチに集中できるようになり、多くの現場で急速に普及しています。

しかし、この「勢いで作れる」という体験には、深刻な落とし穴が存在します。手軽さの裏返しとして、品質・保守性・セキュリティが担保されず、プロジェクトが制御不能に陥るリスクを抱えています。

最も典型的なのが、「デモでは見事に動くが、本番環境にデプロイ（配置）した途端に破綻する」というパターンです。自然言語による指示は常に曖昧さを孕むため、AIはその隙間を埋めるように「その場しのぎの最短ルート」でコードを出力しがちです。

• 仕様ズレと考慮漏れ：境界値（エッジケース）や、エラーが起きた際の例外処理がすっぽり抜け落ちる。
• 影響範囲のブラックボックス化：既存のコンポーネントへの影響を考慮せず、コードを強引に上書きして別の機能を壊してしまう。
• セキュリティの脆弱性：ロール（役割）に応じた権限チェックや、入力値のサニタイズ（無害化処理）が漏れ、深刻なセキュリティホールが生まれる。
• 依存関係の肥大化とリファクタリング不能：場当たり的にライブラリを追加し、密結合な（依存し合った）コードを量産するため、後からエンジニアが誰も手を出せないスパゲッティコードと化す。

vibe codingの速度を殺さずに品質を守るためには、「仕様駆動開発（Specification-Driven Development）」のアプローチが不可欠です。ただし、設計書を何百ページも書くような過去のウォーターフォール型（上流から下流へ一方通行で作る手法）に戻るわけではありません。

AI時代における仕様は、「人間が後から読むための固定ドキュメント」ではなく、AIの出力を自動で検証するための「評価関数（Quality Gate）」として機能します。

たとえば、フロントエンドやバックエンドの連携において、以下のように制約をコードやスキーマとして定義します。

// 仕様を評価関数とする例（Zodによるスキーマ定義）
export const UserProfileSchema = z.object({
  id: z.string().uuid(),
  role: z.enum(["admin", "user", "guest"]),
  age: z.number().min(18).optional(),
});
// このスキーマ自体が、AIの実装が正しいかを評価する「検証ルール」となる

「何が正解か」を、上記のようなスキーマや、APIリクエストの形式、状態推移のルールとして明確に定義します。それを元に、まずAIにテストコードや検証ルールを書かせます。その後、そのテストを通過するように実装を行い、別窓口のエージェントがレビューを行う。この「仕様 → テスト → 実装 → レビュー」というループを極めて短い時間で高速に回すことこそが、AI前提の新しい開発スタイルです。

プロジェクトの品質防波堤となるのは、以下の軽量なドキュメント群です。すべてマークダウン形式のテキストファイル等でリポジトリ内に管理し、AIと人間が常に同期（アップデート）し続けます。

AIにコーディングを任せる前の「品質ゲート」チェックリスト

AIにコードを書かせる際、1つのチャットにすべての要件や文脈を丸投げすることは危険です。AIは文脈を見失い、幻覚（ハルシネーション＝もっともらしい嘘）によるバグを埋め込みやすくなります。そこで、役割を分割した「マルチエージェント体制」を構築します。

• Builder（実装）：仕様を満たすコードを書くことだけに集中する。
• Spec Guardian（仕様整合）：変更内容が既存の仕様書と矛盾していないか、全体の要件から外れていないかを監視する。
• QA/Test Agent（テスト）：意地悪な境界値テストや、E2E（ユーザー操作の通し）テストのシナリオを作成する。
• Security Reviewer（セキュリティ）：権限の越権アクセスや脆弱性がないか、攻撃者の視点で監査する。
• Refactor Agent（保守性）：型定義の厳密さや依存関係のクリーンさを保ち、負債の解消を提案する。

これらの体制を組むにあたり、適材適所でツールを使い分けます。一例として、ClaudeとAntigravityを組み合わせる場合を想定します。

• Claude：優れた論理的思考力と文章作成能力を活かし、人間との対話を通じてPRDからSpecへの詳細化、複雑なアーキテクチャの議論を行います。また、Security ReviewerやRefactor Agentとして、コードのピアレビュー（相互確認）やADRの文書化を担当させるのに適しています。
• Antigravity：実際のローカル環境や開発リポジトリにおける「自律的なタスク実行」や「実装支援」を得意とします。既存のソースコード群を即座に読み込み、Specに基づいたコンポーネントの自動生成、リファクタリングの適用、複数ファイルにまたがるテストコードの配置など、Builderとしての具体的な変更作業を高速に実行させます。

特定の製品にこだわるのではなく、「深い思考やレビュー」を得意とするモデルと、「広範囲かつ自律的な作業実行」を得意とするエージェントを適宜組み合わせるという思想が重要です。

小〜中規模チーム（1〜10名程度）が1週間（1スプリント）で安全にAI開発を回すための具体的なフローです。プロセスの要所では、必ず人間による意思決定（Human in the Loop）が入ります。

AIとの対話やリポジトリの管理で即使える、マークダウン形式のテンプレートです。

# [機能名] PRD
## 1. 解決したい課題 (Why)
- （なぜこの機能が必要なのか）
## 2. 対象ユーザーとユースケース (Who/How)
- （誰がどのような状況で使うのか）
## 3. スコープ (What)
- 対象にすること:
- 対象外にすること (Non-Goals): 
## 4. 成功指標 (Success Criteria)
- （何をもって完了とするか、定量・定性目標）
## 5. 制約事項 (Constraints)
- （スケジュール、インフラ制限、依存システムの条件など）

# [機能名] Spec
## 1. 入出力定義 (Input / Output)
- Request (入力データと型): 
- Response (出力形式とステータスコード): 
## 2. 状態遷移・ライフサイクル (State)
- （データが作成されてから削除されるまでの推移）
## 3. エラー処理 (Error Handling)
- [エラー条件] -> [ユーザーへの表示メッセージ] / [内部でのリカバリ処理]
## 4. 権限・セキュリティ (Authorization)
- アクセス可能なロール・アクセス不可能なロール:
## 5. 非機能要件 (NFR: パフォーマンス等)
- （レスポンスタイムの要件、許容される負荷など）

あなたは厳格なQAエンジニア（QA/Test Agent）です。
以下の【PRD】と【Spec】を読み込み、この機能に対する「受け入れ条件」および「テスト観点（正常系・異常系・境界値）」をリストアップしてください。
特に、既存システムへの影響（リグレッションのリスク）や、ユーザーが意図しない操作をした場合のエッジケース（極端な条件）を推測し、論理的に指摘してください。

【PRD】:
[PRDの内容を手入力、または参照先を指定]

【Spec】:
[Specの内容を手入力、または参照先を指定]

AI開発を導入したプロジェクトで共通して起こる失敗パターンと、その対策です。

• 1. 仕様が無いまま作り、後から破綻する

  現象：最初の数時間で機能の9割が完成するが、残りの1割であるエラー処理や権限管理の段階でAIが迷走し始めます。つじつま合わせが連続し、結果としてイチから書き直すハメに陥ります。

  対策：いきなりコードを書かせる前に、必ず「PRD」と「Spec」のアウトライン作成を第一ステップとしてAIと対話（壁打ち）します。ゴールを先に固定することが最大の近道です。

• 2. 仕様はあるが更新されず、現実と乖離する

  現象：実装中に気づいた変更をコードに直接パッチ当て（直書き）してしまい、次に別機能を足0そうとした際、AIが古いままの仕様書を読み込んでしまい、矛盾したバグを量産します。

  対策：コード修正とドキュメント更新を常にセットで行います。「仕様への反映（Specのアップデート）も同時に行ってください」とAIに命じる癖をつけます。

• 3. テストが追いつかない（回帰地獄）

  現象：AIがものすごい猛スピードでコードを量産するため、人間が行うテストの手動確認が完全にボトルネックとなります。新機能を追加するたびに、どこか別の機能が気づかないうちに壊れ続けます。

  対策：品質ゲートとして自動テスト（CI/CD）の導入を必須にします。さらに、AIに実装させる前に、先にAIに手堅いテストコードを書かせる手法を取り入れます。

• 4. エージェントが増えるほど混乱する

  現象：あちこちのチャットやツールで色々な指示を出した結果、どれが最新の「正解」なのかわからなくなり、ソースコード群がコンフリクト（競合・衝突）を起こします。

  対策：責任の所在を決めます。要件の合意事項は必ず1つのファイル（単一情報源）に集約し、各エージェントは常にそのファイルを参照してから動くルールを徹底します。

スピードと品質を両立させる体制は、いきなり完璧なものを目指す必要はありません。以下のステップで小さく定着させることが成功の秘訣です。