序章：「Vibe Coding」とは何か？なぜ今必要なのか

2025年現在、「Vibe Coding」という新しい開発スタイルが急速に普及しつつあります。
もはや「コードは人が一行ずつ書くもの」ではなくなりつつある現場。
AIが“人の意図”を受けて、自律的に設計・実装・レビューまで行う時代が到来しました。

このガイドでは、Vibe Codingの思想・流れ・現場での使い方・AIとの設計対話の実践法を、徹底的に分かりやすく・現実的に整理します。

1. Vibe Codingとは──思想と特徴

■ 概念の整理

Vibe Codingとは、「実装を書かず、AIに自然言語で指示（プロンプト）を出し、コードを“生成・設計”してもらう」開発手法です。

  • プロンプト＝新しい設計言語
  • 実装はAI（Copilot、Claude、Cursorなど）が担当
  • 人間は「何をなぜ作るのか」「どんな依存・責務・ドメインか」を言語化し、設計対話を重ねる

■ どこが従来と違うのか

  • 実装“自体”ではなく、「設計・意図・構造」を自然言語で伝える点
  • 実装・リファクタ・テスト生成もAIが担う（Copilot Workspace等の自動化）
  • 人は設計者・レビュワー・プロンプターに集中

■ Andrej Karpathy提唱──「コードを書くのではなくAIに“感じさせる”」

Karpathy氏はVibe Codingを「AIに意図・設計・空気感（Vibe）を伝える技術」と定義しています。
プログラマーの役割は「設計意図・依存・将来像の言語化」そのもの。

2. Vibe Codingの実践プロセス──設計対話の流れ

【1】要件・仕様の自然言語化

まず、「どんな機能がほしいか」「どんな制約があるか」を、人間がプロンプトとして記述します。
要件は曖昧NG、具体的・文脈豊かな表現を心がけます。

“ユーザーが商品をカートに入れるECサイトのショッピングカート機能。  
カートは商品IDと数量を保持し、ログイン中のユーザーごとに管理。  
商品追加・削除・カート内容取得APIをGo言語で実装したい。  
テスト可能な設計・責務分離で。”

【2】AIに設計の骨子・依存関係を問う

  • どんなデータ構造が適切か？
  • どの層がどの責務を持つべきか？
“どのような構造体・インタフェース設計が適切か？  
ドメイン層とAPI層の責務分離、永続化はインメモリでOK。テスト容易性重視。”

【3】AIから設計案・雛形コードをもらい、設計意図を明確化

AIが出力する設計・実装案を人間が評価し、「なぜそうなるか」を明文化。
役割・責務・依存関係を図式化してもよい。

【4】細部のリファクタ・命名改善もAIに反復依頼

  • 名前が曖昧な箇所や、ユースケース漏れに着目
  • 追加仕様も自然言語で伝える（「こういうエッジケースも想定して」）

【5】テスト・レビューまでAIを活用

  • 単体テストコードもプロンプトで生成依頼
  • AIレビュー→人間が理由・設計意図を補足

3. Vibe Codingの現場効果──なぜ現場で使われているか

■ 効果・メリット

  • 実装速度2〜5倍
  • 設計意図・仕様伝達コストの大幅削減
  • リファクタ・テスト生成がAIで一貫
  • 設計レビューの網羅性向上（AIが観点抜けを指摘）
  • “コーディング”から“設計対話”へ役割移行

■ 現場からの実例

  • YC 2025バッチでは「AI主導コードベース」がプロダクトの25%以上
  • VisaやReddit等の大企業でも、「AIリーディングスキル」を採用要件化
  • スタートアップの開発チームで「設計対話を毎日SlackでAIとやる」事例も

4. 実践編──Vibe Codingのプロンプト・レビュー演習

◇ ケース1：APIサービスのVibe Coding

要件を自然言語で記述

“顧客が登録・検索できるシンプルな会員管理APIをGoで。  
永続化はインメモリでOK、会員ID・名前・メールアドレス管理。  
登録・検索・削除API、単体テスト付き。”

AIへのプロンプト実例

“インタフェース設計、構造体設計、各APIの責務分離、テストコードの雛形まで一括生成して。
エラー設計・バリデーションも意識して。”

AIが出力するコード例（Go）

type Member struct {
    ID    string
    Name  string
    Email string
}

type MemberRepository interface {
    Create(m *Member) error
    FindByID(id string) (*Member, error)
    Delete(id string) error
}

type InMemoryMemberRepo struct {
    data map[string]*Member
}

// 実装略

コードレビュー観点（AI→人コメント）

type InMemoryMemberRepo struct {
    data map[string]*Member
}

@Reviewer
dataのスレッドセーフ性が考慮されていません。複数ゴルーチンからの同時アクセスに備え、sync.RWMutex等のロックを導入してください。

Vibe Codingでも、AIの設計案を「なぜこうなっているか？」と理由ごと読解し、必要なら補正することが重要です。

◇ ケース2：ドメイン駆動設計のVibe Coding演習

プロンプト例

“決済ドメインの支払い処理ユースケースをTypeScriptで。  
責務分離（ドメインサービス／エンティティ）、例外設計、外部決済APIラッパーの抽象化も意識して。”

AIが出す設計案に「なぜ？」を重ねていく

  • なぜここでインターフェース切っているのか
  • どこに業務ロジックを閉じ込めているのか
  • 型安全性、例外伝搬の流れは妥当か

コードレビュー例

class PaymentService {
    process(paymentRequest: PaymentRequest): PaymentResult {
        // 省略
    }
}

@Reviewer
PaymentServiceが外部APIラッパーの詳細（APIキー、タイムアウト等）まで直接保持しています。責務を分離し、外部依存はAdapter層に集約しましょう。

ドメイン設計では「どこに依存を持たせるか」「なぜその責務分離か」を常にAIと対話しながら調整します。

◇ ケース3：AIレビュー＋人レビューの併用演習

プロンプト例

“上記コードのテストケース・カバレッジ不足、潜在的な副作用がないかチェックして。設計意図が不明瞭な箇所があれば、理由ごと指摘して。”

AIのレビュー指摘

  • テストカバレッジが不足
  • 命名が曖昧
  • スコープを縮められる変数

人間が加えるべき補足コメント

  • なぜその命名が不十分か
  • なぜ副作用が起こる可能性があるか
  • ドメインモデル・依存関係設計が現場要件に合っているか

5. Vibe Codingの“やってはいけない”ポイント

■ 要件が曖昧なまま丸投げしない

  • AIは具体的な要件・制約・背景情報がなければ「汎用的すぎる実装」を返す
  • 「こういうエッジケースも考えて」など具体化が必須

■ “いい感じでやって”は禁句

  • 「いい感じ」は人間ならニュアンスで通じてもAIには曖昧
  • 「テスト容易性」「トランザクション制御」「依存逆転」など具体単語を入れる

■ 責務分離・依存関係をAI任せにしない

  • AIはよく「Service」「Manager」「Util」など汎用的な層を作るが、現場要件を意識しないと破綻しやすい

■ AI出力を盲信しない

  • なぜその設計か？なぜその責務分離か？「なぜ」を必ず問い直す
  • コードレビュー・設計レビューを“必ず人間が補足”

6. Vibe Codingのプロンプト設計術

■ 良いプロンプトの特徴

  • 要件・背景が具体的である
  • ドメイン語彙・用語を明確にする
  • 責務・依存関係・非機能要件（例：性能・可用性）も指示
  • 出力例・NG例も入れると精度UP

プロンプト例（良い例）

“ユーザー登録APIをGoで。バリデーションは外部パッケージで。テストコード付きで。  
例：ユーザーIDはUUID、メールはRFC準拠チェック。バリデーションエラー時は400返却。将来MySQL化を想定したインタフェースで。”

プロンプト例（悪い例）

“ユーザー登録API作って”

■ 「設計対話」をプロンプトに仕込む

  • どの層がどの責務を持つべきか
  • ドメインルールの優先順位
  • 外部サービスとの依存関係の制御
  • テスト容易性（DI、モック化設計）

7. Copilot Workspace／Claude 3でのVibe Coding活用例

■ Copilot Workspaceの流れ

  1. 自然言語で「仕様」「背景」「期待する動作」記載
  2. AIが設計案＋コードを自動生成（PullRequest単位）
  3. AIレビュー→人がWhyをコメントで補足、設計意図の明文化
  4. PRの説明文もAIが要約・自動記述
  5. Merge→次タスク化までAIエージェントで流す

■ Claude 3／Cursorによる「設計対話」の演習

  • Claudeは「なぜこう設計したのか？」に理由まで答えやすい
  • 「この設計をDDD的に分割し直して」「依存逆転にして」等、具体設計対話が可能

8. Vibe Coding設計観点・レビュー観点チェックリスト

9. まとめ──Vibe Codingは「設計対話」の時代へ

AIが“正解”を出す時代、現場で評価されるのは「何をなぜ作るか」をAIに的確に伝え、「出てきた設計・実装の意味」を深く読み解き・補足できる人間です。

  • コードを書かせるのはAI
  • 設計意図・責務分離・依存のコントロールは人間
  • Vibe Codingとは「設計と実装の対話をAIと協働する」技術

あとがき

この記事ではVibe Codingの思想から実践法、レビュー演習まで一気通貫で解説しました。
本記事を参考に、「AIとの設計対話力」を磨き、現場で活きるエンジニアリングを実現してください。

付録：Vibe Codingプロンプトテンプレ・演習素材

◇ プロンプトテンプレ例

“（ドメイン説明）
（仕様・非機能要件）
（実装言語・設計観点）
（テスト・レビューも依頼）

例：
“サブスクリプションサービスのプラン管理API。
プランID・価格・有効期間を管理し、追加・更新・取得・削除APIをGoで。
テスト・エラー設計も重視、拡張性も考慮。”
”

◇ 設計観点リスト

  • ドメインモデル／責務分離
  • 依存逆転／インタフェース設計
  • テスト容易性／モック設計
  • 例外・エラー設計
  • 拡張性／APIバージョン管理

◇ で設計の可視化も推奨

UML Diagram