項目	AIが得意	人が不可欠
コード生成	◎	△（微修正のみ）
テスト生成	◎	○（観点補足）
構文・静的解析	◎
設計意図・ドメイン知識	△	◎
責務分離・副作用抑止	○	◎
命名・API整合性	○	◎
設計意図・理由の説明	△	◎

2.3 「設計対話」を可視化する例

2.4 Vibe Codingが変えるエンジニアの役割

実装担当から「設計意図・レビュー・対話の専門家」へ
Why／Whatを言語化・体系化できる設計者の価値が飛躍的に上がる
AIレビュー結果を鵜呑みにせず、文脈・業務背景を補足できる人材がコアに

第3章：実践フローで掴む──Vibe Coding×現場ユースケース大全

3.1 小規模APIサービスを丸ごとVibe Codingで実装

【エピソード】

ある新規サービス立ち上げで「API＋ストレージ＋テスト」まで最速で組みたい──
従来はAPI設計・ドメインモデリング・DB設計・テスト・レビューまで複数人で2週間。
Vibe Codingなら「プロンプト設計 → AI対話 → コード＋設計＋テスト＋ドキュメント」まで1人＋AIで2日。

【演習例：Goによる会員管理API】

1. 要件・仕様プロンプト（例）

プロンプト

会員登録・取得・削除APIをGoで。ストレージはメモリ常駐、テスト可能、入力バリデーションとエラー設計も。REST/JSON形式で。

2. 設計案プロンプト

プロンプト

会員ID・名前・メール・作成日。設計意図・API設計・リポジトリ責務分離・テストコードも自動生成して。

3. AI出力コード例

type Member struct {
    ID   string
    Name string
    Email string
    CreatedAt time.Time
}

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

// 以下にAPIハンドラ、インメモリ実装、テストが続く...

4. 人間レビューコメント例

type MemberRepository interface {
    Create(*Member) error
    GetByID(id string) (*Member, error)
    Delete(id string) error
}
@Reviewer
インタフェース設計は良いですが、テスト時にエラー注入できる仕組み（例：エラー返却用のMock実装）も準備しましょう。保守性・障害テスト容易性の観点から重要です。

AI出力に「テスト容易性」「障害テスト対応」「責務分離」など、Whyコメントを追記する訓練がVibe Coding現場で必須になっています。

3.2 ドメインモデル構築型：業務ルールをAI設計対話に落とし込む

【エピソード】

既存SIer現場で「請求ドメインの集約ルート設計」「トランザクション管理」「例外伝播」が属人化。
Vibe Coding導入後は、「ドメイン用語・業務要件・例外仕様」までプロンプトでAIに指示→設計意図をレビューで体系化。

【演習例：TypeScriptによる決済ドメイン設計】

1. 要件プロンプト

プロンプト

クレジットカード決済ドメイン。決済処理はTransactionService。外部APIは抽象化。エラー・例外・テスト戦略も指示。DDD原則・責務分離を守って。

2. AI設計案・コード例（抜粋）

typescript

class TransactionService {
    process(request: PaymentRequest): PaymentResult {
        // 入力チェック
        // 外部API呼び出し
        // エラー時ロールバック
    }
}

interface PaymentGateway {
    pay(req: PaymentRequest): PaymentResponse;
}

3. 人間レビューコメント例

typescript

class TransactionService {
    process(request: PaymentRequest): PaymentResult {
        // 省略
    }
}
@Reviewer
TransactionServiceの責務が肥大化しています。外部APIのエラー・リトライ・ロールバック等は、専用のアダプタ層に委譲し、ドメイン層の関心事を明確に切り分けましょう。

AI提案を「なぜこの責務分離か？」「どこがドメイン固有か？」で必ず反証・分解するクセを付けることが現場で必須です。

既存UserServiceのグローバル変数依存・副作用・密結合を排除。DI設計＋モック可能化＋テスト戦略もAIで出して。

2. AI出力設計案（抜粋）

type UserService struct {
    repo UserRepository
    logger Logger
}
func (s *UserService) RegisterUser(name string, email string) error {
    // 省略
}

3. 人間レビューコメント例

func (s *UserService) RegisterUser(name string, email string) error {
    // 省略
}
@Reviewer
RegisterUser内でバリデーション・エラーハンドリング・ログ出力まで一手に処理しているため、今後の保守負荷増が懸念されます。責務を小分けに分離し、メソッドごとのテスト容易性を向上させましょう。

このPRの修正意図・設計意図を要約。設計・依存関係・テスト観点の抜け漏れもAIでチェック。

2. AI自動レビュー例（抜粋）

依存パッケージのバージョン更新が正しいか
テストケース網羅に不足がないか
パフォーマンスへの影響はないか

3. 人間が補足すべきレビューコメント例

// PR内でDI設計が抜けている箇所に対して
@Reviewer
今回の変更により依存関係の逆転が弱くなっています。インタフェース経由の注入設計を継続適用し、テスト容易性と拡張性のバランスを保ちましょう。

第4章：AIレビュー時代の“読む力”──レビューアー育成・Why/What訓練法

4.1 AIレビューの普及がもたらす“読解力の空洞化”

AIレビュー（Copilot Workspace/Claude/ChatGPT等）は、

「修正案」を即座に提示
コーディング規約や一般的バグを瞬時に指摘
パターン化された観点を網羅

しかし、現場で次の課題が深刻化している。

「なぜこの設計？」に答えられる人材が減った
レビューコメントが表面的な形式指摘のみになりやすい
プロジェクト固有の背景・仕様・歴史をAIが補完できない

4.2 Why/Whatコメント訓練：設計意図を伝えるレビューアー技術

◇ Why/Whatコメントの基本構造

Why（理由）→ What（具体的な行動） を必ずセットで書く
「なぜ修正が必要か」「なぜこの設計なのか」を説明できることが“レビューアーの本質”

良い例

func Process(input string) error {
    var err error
@Reviewer
この変数はifブロック内でのみ使用されています。変数のスコープを必要最小限に抑えることで、将来的な副作用や保守コストを削減できます。ifブロック内で宣言しましょう。
    if input == "" {
        err = errors.New("empty input")
        return err
    }
    return nil
}

悪い例

Comment

// コメントが「短くしましょう」「ifの中に寄せましょう」だけではWhyがない

◇ Why/Whatコメント訓練プロンプト例

プロンプト

次のコードをレビューしてください。なぜその指摘をするか理由（Why）＋どう直すか（What）を必ずセットで明記。

◇ 代表的なレビュー観点（Why/Whatテンプレ）

観点	Why（理由）	What（行動）
スコープ管理	変数の生存期間が長いと誤用や副作用を生む	変数宣言を使用箇所に近づける
責務分離	1つの関数・構造体が複数責務を持つと保守困難	責務ごとに関数・型・層を分割
命名	意図不明・曖昧な命名はバグ温床	ドメイン・役割を反映した命名に修正
テスト容易性	テスト困難な設計は将来的なバグ混入リスク	DI、インタフェース、モック設計を導入
副作用	関数外部への状態変更は読解・バグ発生源	副作用箇所を明示or排除

4.3 レビューアー育成・現場OJT演習法

◇ AIレビュー＋人コメントのペアレビュー訓練

AIレビュー結果を受け取り、Why/Whatコメントで補足説明を必ず追加
ドメイン知識・業務仕様・設計方針が反映されているかを再確認
コード内に“設計理由”まで言語化してコメントを残す

コード演習例

type Cart struct {
    Items []CartItem
    UserID string
}
func (c *Cart) AddItem(item CartItem) {
    c.Items = append(c.Items, item)
}
@Reviewer
AddItemでバリデーションや重複チェックが未実装のため、同一商品が何度も追加されるリスクがあります。商品ID単位での重複排除ロジックを追加してください。

◇ 組織でのレビューアー育成ロードマップ例

Why/Whatコメント訓練（AI出力＋自分の言葉で補足）
設計意図をUML図などで必ず明文化
レビュー観点チェックリスト運用を徹底
現場仕様・業務用語・背景の言語化をレビューコメントに必ず含める
OJT・ペアレビューでWhy/What理由を口頭説明＋記述

◇ 設計意図を可視化する訓練

4.4 Why/Whatレビュー観点チェックリスト

指摘コメントに理由（Why）が明記されているか？
具体的な修正提案（What）が明確か？
設計意図・責務分離・副作用の観点が抜けていないか？
ドメイン知識や現場背景を補足しているか？
テスト容易性・エラー設計まで言及されているか？
図や表で設計意図を補助しているか？

第5章：プロンプト設計術──仕様・設計・非機能要件をAIに伝える技法

5.1 プロンプト設計の重要性──AIは“曖昧”を苦手とする

Vibe Codingの成否を分ける最大のポイントは「プロンプトの質」です。
AIは自然言語に強くなりましたが、「何をどこまでどう考慮するか」を明確に伝えなければ、

汎用的で浅い実装
現場仕様を無視したコード
バリデーションや拡張性の抜け

…といった「惜しい」アウトプットになりやすいです。

5.2 良いプロンプト・悪いプロンプトの比較

悪いプロンプト例	問題点
「ユーザー登録API作って」	要件・制約が何もない
「Goで商品管理サービス」	データ構造もAPI詳細も未指定
「バリデーションもお願いします」	何のバリデーションか曖昧

良いプロンプト例	強み
「Goで会員登録API。会員IDはUUID、メールはRFC準拠チェック、登録失敗時は400返却。ストレージはメモリ常駐でOK。登録・取得・削除API、テストコードも含めて」	具体性・バリデーション要件・失敗時動作・テスト要件が明示

5.3 プロンプト設計4つの型

【1】機能要件型

何を実現したいか（CRUD/API/画面など）

【2】非機能要件型

パフォーマンス、スケーラビリティ、セキュリティ、テスト容易性

【3】設計・責務型

層構造（API層／ドメイン層／データアクセス層）
責務分離、依存逆転、例外設計

【4】テスト・拡張性型

ユニットテスト生成、モック化設計
拡張・将来対応性

5.4 現場で使えるプロンプトテンプレート集

◇ 新規API設計テンプレ

プロンプト

Goで商品登録API。商品IDはUUID、価格は0以上、小数点以下2桁まで。登録・取得・削除API、入力バリデーション、エラー時400返却。インメモリストレージ、テストコード付き。

◇ 業務ドメイン駆動テンプレ

プロンプト

TypeScriptで売上集計ドメイン。売上エンティティ・集約ルート設計、期間指定集計API、エラー設計。テスト容易性・将来拡張も考慮。

◇ レガシーリファクタ用テンプレ

プロンプト

現行UserServiceのグローバル変数依存・副作用・密結合を排除。依存注入設計、テスト可能化、リファクタ後のAPIドキュメントも自動生成して。

◇ AIレビュー用テンプレ

プロンプト

このPullRequestの修正意図・設計意図を要約。設計・依存関係・テスト観点の抜け漏れもAIでチェック。

5.5 エッジケース網羅指示のコツ

例外ケース／バリデーション失敗時の動作も指示
業務用語・現場固有仕様を明示
「～も考慮して」だけでなく、“どう”考慮すべきかまで踏み込む

悪い例

プロンプト

バリデーションも考慮して

良い例

プロンプト

メールはRFC5322形式。パスワードは8文字以上、英数混在。重複ID登録はエラーに

“Goでタスク管理API。タスクID/タイトル/期限/完了フラグ。登録・取得・削除API、期限切れタスク取得APIも。バリデーション・テストコード付き。”

AI出力例（抜粋）

type Task struct {
    ID string
    Title string
    DueDate time.Time
    Done bool
}

レビューコメント例

type Task struct {
    ID string
    Title string
    DueDate time.Time
    Done bool
}
@Reviewer
Titleは255文字以内、DueDateは過去日時不可などの制約が抜けています。要件を満たすバリデーションをモデル内に追加してください。