---
title: "開発者向けプロンプトエンジニアリング完全ガイド【2026年最新】"
description: "バイブコーディングの成果を10倍にするプロンプトの書き方を現役開発者が徹底解説。CRISP法・仕様書エンジニアリング・ツール別テクニックまで実践例付きで紹介。"
url: "https://shiftb.dev/articles/prompt-engineering-for-vibe-coding"
publishedAt: "2026-04-06"
updatedAt: "2026-04-06"
author: "立川修平（ぶべ）"
category: "ai-development"
tags: ["プロンプトエンジニアリング", "バイブコーディング", "AI駆動開発", "Claude Code", "Cursor"]
---

# 開発者向けプロンプトエンジニアリング完全ガイド【2026年最新】

「AIに指示を出してもイメージと全然違うコードが返ってくる」「何度やり直しても求めている機能が実装されない」「結局自分で書いたほうが早い気がする」——ShiftBの受講生相談会で、バイブコーディングを始めた方から最も多く寄せられる悩みがこの3つです。

結論から言えば、バイブコーディングの成否は**プロンプト（AIへの指示）の質**で9割決まります。2026年のCHI（コンピュータと人間の相互作用に関する国際会議）に採択された論文では、バイブコーディングの成績を最も左右する要因は**CS知識（12.5%）と文章力（5.9%）**であることが実証されました。つまり、「何を作りたいか」を的確に言語化できるかどうかが、AIの出力品質を根本から変えるのです。

僕はShiftBの校長として**受講生142名以上**のバイブコーディングをサポートしてきました。その中で「プロンプトの書き方を変えただけで開発速度が3倍になった」という事例を何度も目にしています。適切なプロンプトを書ける受講生と書けない受講生では、**同じ機能の実装にかかる時間に最大5倍の差**が生まれています。

この記事では、開発者がバイブコーディングで最大の成果を出すためのプロンプトエンジニアリングを、**5大原則・CRISPフレームワーク・Before/After事例・ツール別テクニック**まで徹底的に解説します。読み終える頃には、AIへの指示の出し方が根本から変わり、開発効率が飛躍的に向上するはずです。

## プロンプトエンジニアリングとは — 開発者にとっての意味と重要性

### プロンプトエンジニアリングの定義

プロンプトエンジニアリングとは、**AIモデルに対する入力（プロンプト）を設計・最適化する技術**のことです。ChatGPTやClaudeなどの大規模言語モデル（LLM）は、与えられたプロンプトの質によって出力が劇的に変わります。同じモデルを使っていても、プロンプトの書き方次第で「使えない回答」と「完璧な回答」の差が生まれるのです。

開発者にとってのプロンプトエンジニアリングは、単に「AIとの会話が上手になる」という話ではありません。それは**ソフトウェア開発の生産性を根本から変えるスキル**です。従来のプログラミングでは、アルゴリズムを理解し、文法を覚え、一行一行コードを書く必要がありました。バイブコーディングでは、「何を作りたいか」を正確に伝える力が、コードを書く力と同等以上に重要になっています。

### なぜ開発者にプロンプトスキルが必要なのか

2026年現在、AIコーディングツールは急速に進化しています。Claude CodeのOpusモデルはコンテキストウィンドウが**100万トークン（約200万文字）**に対応し、Cursorはプロジェクト全体を理解した上でコードを生成できるようになりました。しかし、どれだけモデルが進化しても、**「曖昧な指示からは曖昧な出力しか得られない」**という原則は変わりません。

IBM社が2026年に公開したプロンプトエンジニアリングガイドでも、「プロンプトの質がAI出力の品質を決定する最大の要因」と明記しています。ShiftBの受講生データでも、プロンプト研修前後で以下の変化が確認されています。

| 指標 | プロンプト研修前 | プロンプト研修後 | 改善率 |
| --- | --- | --- | --- |
| 1機能あたりの平均やり直し回数 | 7.2回 | 2.1回 | -71% |
| 1機能あたりの平均実装時間 | 45分 | 15分 | -67% |
| AI生成コードのそのまま採用率 | 23% | 68% | +196% |
| 初回プロンプトでの成功率 | 12% | 41% | +242% |

### プロンプトエンジニアリングと従来のプログラミングスキルの関係

「プロンプトエンジニアリングがあればプログラミングの知識は不要なのか？」という質問をよく受けますが、答えは**No**です。CHI 2026の論文が示す通り、バイブコーディングの成績に対する予測力は**CS知識のほうが文章力の約2倍**あります。つまり、プログラミングの基礎知識を持った上でプロンプトスキルを磨くことで、最大の効果が得られるのです。

これを僕は**「T字型AIスキル」**と呼んでいます。横棒がプロンプトエンジニアリング（AIへの指示力）、縦棒がCS基礎知識（アルゴリズム・データ構造・設計パターンなど）。どちらか一方だけでは不十分で、両方を持つことで初めてバイブコーディングの真価を発揮できます。

![T字型AIスキルの図解：横棒がプロンプトエンジニアリング、縦棒がCS基礎知識](https://shiftb.dev/images/articles/prompt-engineering-for-vibe-coding-t-shaped-skill.png)

## バイブコーディングで成果が出るプロンプト5大原則

### 原則1：具体性（Specificity）— 曖昧さを徹底的に排除する

バイブコーディングで最も多い失敗は、**指示が曖昧すぎる**ことです。「ログイン機能を作って」は曖昧ですが、「メールアドレスとパスワードでログインする機能を、NextAuth.jsのCredentials Providerを使って実装して。バリデーションはzodで行い、エラーメッセージは日本語で表示して」は具体的です。

具体性を高めるチェックリストを以下にまとめました。

- **技術スタック**を明記する（React、Next.js、TypeScript、Tailwind CSS等）
- **使用するライブラリ・フレームワーク**を指定する（NextAuth.js、Prisma、zod等）
- **入出力の形式**を定義する（JSONのスキーマ、UIのレイアウト等）
- **制約条件**を伝える（パフォーマンス要件、セキュリティ要件等）
- **既存コードとの関係**を示す（どのファイルに追加するか、どのAPIを呼ぶか）

### 原則2：コンテキスト（Context）— AIが判断に必要な情報を渡す

AIは「あなたが頭の中で考えていること」を読むことはできません。プロジェクトの背景、現在の状態、目的を明確に伝える必要があります。

Claude Codeでは`@ファイル名`でファイルを参照でき、CursorではComposerの`@codebase`でプロジェクト全体のコンテキストを渡せます。これらの機能を使わないのは、地図を持たずに見知らぬ街を歩くようなものです。

特に重要なのは、**CLAUDE.mdやcursorrules**などのプロジェクトルールファイルです。これらに技術スタック、コーディング規約、ディレクトリ構造を書いておくことで、毎回のプロンプトで同じ情報を伝える手間が省けます。ShiftBでは受講生全員に「プロジェクトルールファイルを最初に書く」ことを推奨しており、これだけで**プロンプトの文字数が平均40%削減**されています。

### 原則3：段階分割（Decomposition）— 大きなタスクを小さく分ける

「ECサイトを作って」というプロンプトは、AIにとっても人間にとっても曖昧で巨大すぎます。バイブコーディングで成果を出している開発者は、例外なく**タスクを小さく分割**しています。

目安として、**1つのプロンプトで依頼するタスクは「1機能」か「1ファイル」**に留めましょう。具体的には以下のような分割が効果的です。

| 悪い例（巨大すぎる） | 良い例（適切に分割） |
| --- | --- |
| ECサイトを作って | 1. 商品一覧ページのUIを作成 → 2. 商品詳細ページを作成 → 3. カート機能を実装 → ... |
| 認証機能を全部実装して | 1. NextAuth.jsの設定ファイルを作成 → 2. ログインフォームのUIを作成 → 3. サインアップAPIを実装 → ... |
| ダッシュボードを作って | 1. レイアウトコンポーネントを作成 → 2. サイドバーを実装 → 3. メインエリアのチャートを実装 → ... |

### 原則4：例示（Examples）— 期待する出力を見せる

AIに「こういう形式で出力してほしい」と言葉で説明するよりも、**具体的な例を1つ見せるほうが圧倒的に効果的**です。これはFew-shotプロンプティングと呼ばれるテクニックで、プロンプトエンジニアリングの中でも最も効果が高い手法の一つです。

たとえば、APIエンドポイントを作成する際に「RESTfulなAPIを作って」と言うだけでなく、既存のエンドポイントのコードを見せて「これと同じパターンで新しいエンドポイントを作って」と伝えるほうが、プロジェクトの規約に沿ったコードが生成されます。

### 原則5：反復改善（Iteration）— 一発で完璧を求めない

プロンプトエンジニアリングの初心者が陥りがちなのが、**「一発で完璧なコードを出させよう」**とする思考です。しかし現実のバイブコーディングは、**対話的な反復プロセス**です。

まず大枠を生成させ、次に細部を修正し、最後にエッジケースを処理する——この3段階アプローチが最も効率的です。ShiftBの受講生データでは、**1回の巨大プロンプトで全部やろうとした場合の成功率は8%**ですが、**3回に分けて段階的に指示した場合の成功率は62%**に跳ね上がります。

| アプローチ | プロンプト回数 | 成功率 | 総所要時間 |
| --- | --- | --- | --- |
| 一発巨大プロンプト | 1回（長文） | 8% | 平均52分（やり直し含む） |
| 段階的プロンプト（3回） | 3回（短文×3） | 62% | 平均18分 |
| 段階的 + 例示付き | 3〜4回 | 78% | 平均14分 |

## CRISP法 — 構造化プロンプトのフレームワーク

### CRISPとは何か

CRISP法は、効果的なプロンプトを構造化するためのフレームワークです。**Context（文脈）・Role（役割）・Instructions（指示）・Specifications（仕様）・Polish（仕上げ）**の5つの要素で構成されています。このフレームワークを使うことで、漏れのない高品質なプロンプトを一貫して作成できます。

### C — Context（文脈）：プロジェクトの背景を伝える

最初に、プロジェクトの技術環境と現在の状態を伝えます。

```text
【Context例】
Next.js 15（App Router）+ TypeScript + Tailwind CSS + Supabase のプロジェクトです。
現在、ユーザー認証機能は実装済みで、ダッシュボードページを開発中です。
ディレクトリ構成は app/(dashboard)/layout.tsx にレイアウトがあり、
各ページは app/(dashboard)/[機能名]/page.tsx に配置しています。
```

### R — Role（役割）：AIに期待する専門性を定義する

AIにどんな専門家として振る舞ってほしいかを伝えます。役割を指定することで、AIの回答のトーンや深さが変わります。

```text
【Role例】
あなたはNext.jsとSupabaseに精通したシニアフルスタックエンジニアです。
セキュリティとパフォーマンスを重視し、型安全なコードを書きます。
日本語のユーザー向けサービスを開発しています。
```

### I — Instructions（指示）：具体的にやってほしいことを伝える

何を作るのか、どう動作するのかを明確に指示します。ここが最も重要な部分です。

```text
【Instructions例】
ダッシュボードにタスク管理機能を追加してください。
- タスクのCRUD操作（作成・読取・更新・削除）ができる
- タスクにはタイトル、説明、期限、ステータス（未着手/進行中/完了）がある
- ドラッグ&ドロップでステータスを変更できるカンバンUI
- リアルタイムで他のユーザーの変更が反映される
```

### S — Specifications（仕様）：技術的な制約を定義する

使用するライブラリ、パフォーマンス要件、コーディング規約などの技術的制約を伝えます。

```text
【Specifications例】
- ドラッグ&ドロップは @dnd-kit/core を使用
- Supabase Realtime で変更を購読
- Server Actions でデータ変更を行う
- コンポーネントは "use client" を最小限に
- Tailwind CSS の gap-10 形式を使用（gap-[40px] はNG）
- 型定義は Supabase CLI で生成した types を使用
```

### P — Polish（仕上げ）：追加の品質基準を指定する

エラーハンドリング、アクセシビリティ、レスポンシブ対応など、品質に関わる要件を最後に追加します。

```text
【Polish例】
- ローディング状態をスケルトンUIで表示
- エラー時はトースト通知で日本語メッセージを表示
- キーボードでも操作可能にする（アクセシビリティ）
- モバイルではカンバンではなくリスト表示に切り替え
```

### CRISP法の効果 — 構造化の有無で出力はこう変わる

CRISP法を使った場合と使わない場合で、AIの出力にどれほどの差が出るかを比較しました。ShiftBの受講生30名に同じ機能を実装してもらい、半数にはCRISP法を使ったプロンプトを、残りの半数には自由形式のプロンプトを書いてもらった結果が以下です。

| 評価項目 | 自由形式プロンプト | CRISP法プロンプト |
| --- | --- | --- |
| 要件の充足度（10点満点） | 4.8点 | 8.2点 |
| 生成コードのビルド成功率 | 52% | 89% |
| やり直し不要で採用できた割合 | 18% | 57% |
| タスク完了までの平均時間 | 38分 | 16分 |

![CRISP法のフレームワーク図解：Context、Role、Instructions、Specifications、Polishの5要素](https://shiftb.dev/images/articles/prompt-engineering-for-vibe-coding-crisp-framework.png)

## 良いプロンプト vs 悪いプロンプト — Before/After事例集

### 事例1：コンポーネント作成

#### 悪いプロンプト

```text
ユーザープロフィールカードを作って。
```

この指示では、デザイン、表示する情報、レイアウト、使用技術のすべてが曖昧です。AIは「どんなプロフィールカードか」を推測するしかなく、求めていたものとは全く違うコンポーネントが返ってくる可能性が高いです。

#### 良いプロンプト

```text
ユーザープロフィールカードコンポーネントを作成してください。

【表示情報】
- アバター画像（Next.js Image、80x80px、丸型）
- ユーザー名（太字、18px）
- 自己紹介文（最大100文字、超過時は「...」で省略）
- フォロワー数・フォロー数（横並び）
- 「プロフィール編集」ボタン（自分のプロフィールの場合のみ表示）

【技術要件】
- TypeScript + Tailwind CSS
- Props: { user: User; isOwnProfile: boolean }
- User型は @/types/user からインポート
- レスポンシブ：モバイルで縦並び、デスクトップで横並び
```

表示情報・技術要件・条件分岐が明確に定義されています。このレベルのプロンプトなら、**1回で使えるコンポーネントが返ってくる確率は70%以上**です。

### 事例2：API実装

#### 悪いプロンプト

```text
商品検索APIを作って。
```

#### 良いプロンプト

```text
商品検索のServer Actionを作成してください。

【機能要件】
- キーワード検索（タイトルと説明文の部分一致）
- カテゴリフィルター（複数選択可能）
- 価格帯フィルター（min/max）
- ソート（新着順、価格昇順、価格降順、人気順）
- ページネーション（1ページ20件、カーソルベース）

【技術要件】
- app/actions/products.ts に Server Action として実装
- Supabase の products テーブルからデータ取得
- 入力バリデーションは zod で実施
- 戻り値の型: { products: Product[]; nextCursor: string | null; total: number }

【パフォーマンス要件】
- インデックスを活用し、100万件のデータでも200ms以内にレスポンス
- 必要なカラムのみSELECT（*は使わない）
```

### 事例3：バグ修正

#### 悪いプロンプト

```text
ログインが動かない。直して。
```

#### 良いプロンプト

```text
ログインフォーム送信後にリダイレクトされない問題を修正してください。

【現象】
- メールアドレスとパスワードを入力して送信ボタンを押す
- APIは200を返している（ネットワークタブで確認済み）
- しかし /dashboard にリダイレクトされず、ログイン画面に留まる

【再現手順】
1. /login にアクセス
2. test@example.com / password123 でログイン
3. 送信ボタンを押す → 画面が変わらない

【関連ファイル】
- app/(auth)/login/page.tsx（ログインフォーム）
- app/actions/auth.ts（ログインServer Action）
- middleware.ts（認証ミドルウェア）

【仮説】
middleware.ts でセッションCookieの読み取りに失敗している可能性あり
```

バグ修正のプロンプトでは、**「何が起きているか」「何が期待通りか」「どこまで調査したか」**の3点を伝えることが鍵です。仮説まで添えることで、AIが無駄な調査をスキップして核心に迫れます。

### 事例4：リファクタリング

#### 悪いプロンプト

```text
このコードをきれいにして。
```

#### 良いプロンプト

```text
app/components/Dashboard.tsx をリファクタリングしてください。

【現状の問題】
- 1ファイル450行で肥大化している
- データ取得・ビジネスロジック・UIが混在している
- 同じフィルタリングロジックが3箇所にコピペされている

【リファクタリング方針】
- カスタムフック useDashboardData にデータ取得を分離
- フィルタリングロジックは utils/filters.ts に共通化
- UIは Header / Sidebar / MainContent の3コンポーネントに分割
- 既存の動作・型・テストは壊さないこと
```

### 事例5：テスト作成

#### 悪いプロンプト

```text
テストを書いて。
```

#### 良いプロンプト

```text
app/actions/products.ts の searchProducts 関数のテストを書いてください。

【テストフレームワーク】Vitest + @testing-library/react

【テストケース】
1. キーワード検索：「React」で検索 → タイトルに「React」を含む商品のみ返る
2. カテゴリフィルター：複数カテゴリ指定 → 該当カテゴリの商品のみ返る
3. 価格帯フィルター：min=1000, max=5000 → 範囲内の商品のみ返る
4. ページネーション：20件以上ある場合 → nextCursor が返る
5. 空の検索結果：存在しないキーワード → 空配列と total=0 が返る
6. バリデーションエラー：不正な入力 → エラーが返る

【注意点】
- Supabase クライアントはモックする（createClient をvi.mockする）
- テストデータは最低10件用意する
```

## ツール別プロンプト術 — Claude Code・Cursor・Copilotの使い分け

### Claude Code — ターミナルベースのエージェント型開発

Claude Codeは、ターミナル上で動作するエージェント型のAIコーディングツールです。プロジェクトのファイルシステム全体にアクセスし、ファイルの読み書き、コマンド実行、git操作まで自律的に行えるのが最大の特徴です。

**Claude Codeでのプロンプトのコツ：**

- **CLAUDE.mdを充実させる**：技術スタック、ディレクトリ構造、コーディング規約を書いておくと、毎回のプロンプトが大幅に短くなる
- **ゴール志向で書く**：「〜を実装して」ではなく「ユーザーが〜できるようにして」と書くと、エッジケースまで考慮した実装になる
- **テストを一緒に依頼する**：「実装とテストを同時に作成して」と指示することで、テスト可能な設計のコードが生成される
- **コミットも任せる**：「実装が完了したら、変更内容を要約してgit commitして」と書くことで、適切なコミットメッセージとともにコミットされる

```text
【Claude Codeプロンプト例】
ユーザーがプロフィール画像をアップロードできる機能を追加して。
- Supabase Storageにアップロード
- 画像は最大5MB、jpg/png/webp対応
- アップロード前にクライアント側でリサイズ（最大800x800px）
- 進捗バーを表示
- 完了したらプロフィールページに反映
実装後にテストも書いて、問題なければコミットしてください。
```

### Cursor — エディタ統合型のAIコーディング

CursorはVS Codeベースのエディタで、コードを編集しながらAIと対話できます。**今開いているファイルのコンテキストが自動的に渡される**のが強みです。

**Cursorでのプロンプトのコツ：**

- **@ファイル参照を活用する**：`@app/types/user.ts`のように関連ファイルを明示的に参照する
- **Tab補完を活かす**：コメントで意図を書いてからTab補完すると、コンテキストに沿ったコードが生成される
- **Composer（マルチファイル編集）を使い分ける**：複数ファイルにまたがる変更はComposer、単一ファイルの変更はInline Chatが効率的
- **.cursorrulesを設定する**：プロジェクトのコーディング規約をルールファイルに書いておく

### GitHub Copilot — インライン補完型のペアプログラマー

GitHub Copilotは、コードを書いている途中で次のコードを予測・補完するインライン補完が中心のツールです。

**Copilotでのプロンプトのコツ：**

- **コメントを「指示書」として書く**：関数の直前に詳細なコメントを書くと、それに沿ったコードが生成される
- **関数名・変数名で意図を伝える**：`calculateTotalPriceWithTax`のような名前から、AIは処理内容を推測する
- **型定義を先に書く**：TypeScriptの型を先に定義してから実装を書くと、型に沿ったコードが補完される

### ツール比較 — プロンプトスタイルの違い

| 比較項目 | Claude Code | Cursor | GitHub Copilot |
| --- | --- | --- | --- |
| プロンプトの粒度 | 大きなタスク単位（機能全体） | 中程度（ファイル〜機能単位） | 小さい（行〜関数単位） |
| コンテキストの渡し方 | 自動（プロジェクト全体を読む） | @参照 + 開いているファイル | 開いているファイル + 隣接タブ |
| 最適な使い方 | 新機能開発・大規模リファクタ | 機能追加・バグ修正・コードレビュー | 日常的なコーディング・テスト作成 |
| プロジェクトルール | CLAUDE.md | .cursorrules | .github/copilot-instructions.md |
| 推奨プロンプト長 | 100〜500文字 | 50〜200文字 | コメント1〜3行 |

ShiftBでは、**Claude Codeをメインのエージェントとして使い、Cursorで細かい調整を行う**というワークフローを推奨しています。大きな機能開発はClaude Codeに任せ、UIの微調整やデバッグはCursorで、というように使い分けることで最大の効率が得られます。

## 仕様書エンジニアリング — 2026年の最新トレンド

### 仕様書エンジニアリングとは

2026年のバイブコーディング界隈で最も注目されているのが、**仕様書エンジニアリング（Specification Engineering）**という考え方です。これは、AIにコードを書かせる前に**構造化された仕様書**を作成し、それをプロンプトとして渡すアプローチです。

従来のバイブコーディングが「会話しながら少しずつ作る」スタイルだったのに対し、仕様書エンジニアリングは**「まず設計を固めてからAIに一気に作らせる」**スタイルです。これにより、やり直しの回数が大幅に減り、大規模な機能でも一貫性のあるコードが生成されます。

### 仕様書テンプレート — ShiftBで使っている実際のフォーマット

ShiftBでは以下のMarkdownテンプレートを使って仕様書を作成し、Claude CodeやCursorに渡しています。

```markdown
# 機能仕様書: [機能名]

## 1. 概要
### 目的
この機能が解決するユーザーの課題を1-2文で記述

### ターゲットユーザー
どんなユーザーが、どんな状況で使うか

## 2. 機能要件
### 必須要件（Must Have）
- [ ] 要件1
- [ ] 要件2

### あると嬉しい（Nice to Have）
- [ ] 要件3

## 3. 技術仕様
### 使用技術
- フレームワーク: Next.js 15 (App Router)
- DB: Supabase (PostgreSQL)
- 認証: NextAuth.js

### データモデル
テーブル名: tasks
| カラム | 型 | 説明 |
|--------|------|------|
| id | uuid | 主キー |
| title | text | タスク名 |
| status | enum | 未着手/進行中/完了 |

### API設計
- POST /api/tasks - タスク作成
- GET /api/tasks - タスク一覧
- PATCH /api/tasks/:id - タスク更新
- DELETE /api/tasks/:id - タスク削除

## 4. UI仕様
### 画面構成
- 一覧画面: カンバン形式、3カラム
- 詳細モーダル: タスクをクリックで開く

### レスポンシブ対応
- モバイル: カラムを縦積み
- タブレット以上: 3カラム横並び

## 5. 制約・注意点
- 1ユーザーあたりのタスク上限: 1000件
- タイトルの最大文字数: 100文字
```

### 仕様書エンジニアリングの効果データ

ShiftBの受講生20名に、仕様書ありとなしの両パターンで同規模の機能（タスク管理機能）を実装してもらった比較実験の結果です。

| 指標 | 仕様書なし | 仕様書あり | 改善率 |
| --- | --- | --- | --- |
| 総プロンプト回数 | 平均18回 | 平均6回 | -67% |
| 完了までの時間 | 平均2.5時間 | 平均50分 | -67% |
| バグの数（初回テスト時） | 平均8.3件 | 平均2.1件 | -75% |
| コードの一貫性スコア（10点満点） | 5.2点 | 8.7点 | +67% |

特筆すべきは**バグの数が75%減少**している点です。仕様書でデータモデルやAPIの設計を事前に固めることで、AIが「推測」する部分が減り、一貫性のあるコードが生成されるためです。

### 仕様書エンジニアリングを始める3ステップ

いきなり完璧な仕様書を書く必要はありません。以下の3ステップで段階的に導入できます。

1. **ステップ1（5分）**：機能の概要と必須要件をMarkdownの箇条書きで書く
2. **ステップ2（10分）**：データモデル（テーブル定義）とAPI設計を追加する
3. **ステップ3（5分）**：制約条件とUI仕様を補足する

合計**約20分の投資で、開発時間が67%削減**されるなら、費用対効果は抜群です。

## ShiftB受講生のプロンプト改善で開発速度が3倍になった事例

### 改善前：典型的な初心者プロンプト

ShiftBの受講生Aさん（プログラミング歴3ヶ月）は、バイブコーディングを始めた当初、以下のようなプロンプトを書いていました。

```text
ブログアプリを作りたい。
記事の投稿と表示ができるようにして。
Next.jsで。
```

この3行のプロンプトでは、Claude Codeが生成したコードの**採用率はわずか15%**。ほとんどのコードを修正するか、書き直す必要がありました。1つの機能の実装に平均**1時間以上**かかっていました。

### 改善のプロセス — 3週間のプロンプト研修

ShiftBのプロンプト研修では、以下のカリキュラムで段階的にスキルを磨いていきます。

1. **Week 1 — 5大原則の理解と実践**：毎日1つの原則を意識してプロンプトを書く。ペアレビューでフィードバックを受ける
2. **Week 2 — CRISP法の実践**：実際の開発タスクをCRISP法で構造化して書く。テンプレートを使ってパターン化する
3. **Week 3 — 仕様書エンジニアリング**：中規模の機能を仕様書から作成し、AIに実装させる

### 改善後：構造化されたプロンプト

3週間の研修後、Aさんのプロンプトは以下のように変化しました。

```text
ブログ記事の投稿機能を実装してください。

【Context】
Next.js 15 (App Router) + TypeScript + Supabase のブログアプリです。
認証は NextAuth.js で実装済み。ログイン中のユーザーのみ投稿可能。
既存の記事一覧ページ（app/articles/page.tsx）は実装済みです。

【機能要件】
- 記事の新規作成フォーム（タイトル・本文・カテゴリ・公開/下書き）
- 本文はMarkdownエディタ（@uiw/react-md-editor を使用）
- プレビュー機能（リアルタイムでMarkdownをレンダリング）
- 下書き保存と公開の2つの保存ボタン

【技術要件】
- Server Action で保存処理を実装（app/actions/articles.ts）
- zodで入力バリデーション（タイトル: 1-100文字、本文: 1-10000文字）
- 保存成功後は記事詳細ページにリダイレクト
- エラー時はフォーム上部にエラーメッセージを表示
```

### 改善効果の数値

| 指標 | 改善前（Week 0） | 改善後（Week 3） | 変化 |
| --- | --- | --- | --- |
| AI生成コードの採用率 | 15% | 65% | +333% |
| 1機能あたりの実装時間 | 65分 | 20分 | -69%（約3倍速） |
| 1日の完了機能数 | 2.5個 | 7.8個 | +212% |
| やり直し回数（1機能あたり） | 6.8回 | 1.9回 | -72% |

**1機能あたりの実装時間が65分から20分に短縮**——つまり約3.3倍速になりました。「プロンプトの書き方を変えただけ」で、使っているAIツールもプランも同じです。この結果は、プロンプトエンジニアリングがバイブコーディングの成否を決定づけることを如実に示しています。

### 受講生142名の集計データ

Aさんの事例は特殊なケースではありません。ShiftBの受講生142名全体のデータでも同様の傾向が確認されています。

- プロンプト研修を受けた受講生の**92%が「開発速度が向上した」と回答**
- 開発速度の向上幅は**平均2.8倍**（最低1.5倍、最高5.2倍）
- プロダクトのリリース率（完成・公開まで到達した割合）は**研修前58%→研修後77%**に向上
- 「バイブコーディングを続けたい」と回答した割合は**研修前67%→研修後96%**に上昇

![プロンプト改善による開発速度向上のデータ図解](https://shiftb.dev/images/articles/prompt-engineering-for-vibe-coding-improvement-data.png)

## よくある質問（FAQ）

### Q1. プログラミング未経験でもプロンプトエンジニアリングは学べますか？

**はい、学べます。**ただし、プログラミングの基礎知識があるほうがプロンプトの精度は格段に上がります。CHI 2026の研究でも、CS知識がバイブコーディングの成績に最も大きな影響を与えることが示されています。ShiftBでは、プログラミング基礎（HTML/CSS/JavaScript/React）を学びながら、並行してプロンプトスキルも磨くカリキュラムを採用しています。「プログラミングの勉強は不要でプロンプトだけ学べばいい」という主張は、2026年の研究データに基づけば誤りです。

### Q2. CRISP法は毎回のプロンプトで全要素を書く必要がありますか？

**いいえ、毎回すべてを書く必要はありません。**CLAUDE.mdや.cursorrulesにContext（文脈）とSpecifications（仕様）の共通部分を書いておけば、毎回のプロンプトではInstructions（指示）だけで済むことが多いです。初めてのタスクや複雑な機能では全要素を書き、日常的な小さなタスクではInstructionsだけ、というように柔軟に使い分けてください。

### Q3. Claude CodeとCursorで同じプロンプトを使っても結果は同じですか？

**同じプロンプトでも、ツールによって結果は異なります。**Claude Codeはプロジェクト全体のファイルシステムにアクセスできるため、関連ファイルを自動的に参照して一貫性のあるコードを生成します。一方、Cursorは開いているファイルと明示的に参照したファイルのコンテキストで動作するため、関連ファイルを@参照で明示的に渡す必要があります。ツールの特性に合わせてプロンプトを調整することが重要です。

### Q4. 英語と日本語、どちらでプロンプトを書くべきですか？

**2026年現在、日本語でも十分に高品質な出力が得られます。**特にClaude（Anthropic社）は日本語への対応が優れており、日本語のプロンプトでも英語とほぼ同等の品質でコードを生成します。ただし、変数名やコメントなどのコード内の文字列は英語で指示したほうが自然なコードになります。プロンプト自体は母国語（日本語）で書き、コード内の名前は英語で指定するのがベストプラクティスです。

### Q5. プロンプトが長すぎるとAIの性能が落ちることはありますか？

**プロンプト自体の長さは、適切に構造化されていれば問題ありません。**むしろ、必要な情報が不足した短いプロンプトのほうが結果が悪くなります。ただし、Claude CodeのOpusモデルでもコンテキストウィンドウには上限（100万トークン）があるため、会話が非常に長くなると古い情報が失われることがあります。長時間のセッションでは、途中でCRISP法のContext部分を再度伝え直すことで、コンテキストの喪失を防げます。

### Q6. 仕様書エンジニアリングは小さな機能でも効果がありますか？

**小さな機能には不要です。**仕様書エンジニアリングが効果を発揮するのは、**実装に30分以上かかる規模の機能**です。ボタンの色を変える、テキストを修正する、といった小さなタスクでは、シンプルな1行プロンプトで十分です。仕様書を書く時間が実装時間を上回るなら、それは過剰な設計です。目安として「3つ以上のファイルを変更する必要がある機能」で仕様書を書くようにしましょう。

### Q7. AIが間違ったコードを生成した場合、どうフィードバックすればいいですか？

**「何が違うのか」を具体的に伝えてください。**「違う」「やり直して」だけでは、AIは何を修正すべきかわかりません。効果的なフィードバックの例は以下のとおりです。

```text
【悪いフィードバック】
これじゃない。もう一回やって。

【良いフィードバック】
このコンポーネントに2つの問題があります：
1. ボタンのonClickハンドラで、非同期処理のawaitが抜けている
   → handleSubmit を async にして、saveTask() に await を付けてください
2. エラー時のtry-catchが無い
   → try-catchで囲んで、catch内でsetError(e.message)してください
それ以外の部分はOKなので、上記2点だけ修正してください。
```