🆕 2025年11月最新版！
Gemini 2.0、Claude 3.5 Sonnet、GPT-4 Turboなど最新モデルに対応したプロンプト設計手法を追加しました。

10分でわかる：プロンプトエンジニアリングの本質

プロンプトエンジニアリングとは、AIに対して明確で効果的な指示を与える技術です。同じAIモデルでも、プロンプトの質によって出力結果は大きく変わります。

なぜプロンプトエンジニアリングが重要なのか

3つの基本原則

1. 明確性（Clarity）: 曖昧さを排除し、具体的な指示を与える
2. 文脈（Context）: 必要な背景情報を十分に提供する
3. 制約（Constraints）: 出力形式、長さ、スタイルを明示する

第1章：プロンプトの基本構造

1.1 効果的なプロンプトの5要素

優れたプロンプトは以下の5つの要素で構成されます：

【役割（Role）】
あなたは経験豊富なPythonエンジニアです。

【タスク（Task）】
FastAPIを使った認証機能付きRESTful APIの設計を行ってください。

【文脈（Context）】
- 対象：モバイルアプリ向けバックエンド
- ユーザー数：月間10万人規模
- 要件：JWT認証、リフレッシュトークン対応

【制約（Constraints）】
- セキュリティベストプラクティスに従う
- Pythonのコード例を含める
- 説明は日本語で

【出力形式（Format）】
以下の形式で回答してください：
1. アーキテクチャ概要
2. 実装コード（コメント付き）
3. セキュリティ考慮事項
4. テスト方法

1.2 初心者がやりがちな失敗例と改善策

❌ 悪い例1：曖昧すぎるプロンプト

Pythonでウェブアプリを作りたいです。

問題点：

• 何を作りたいのか不明
• 技術スタックの指定がない
• 出力の期待値が不明確

✅ 改善例1：

【目的】
Pythonで個人ブログのウェブアプリを作成したいです。

【要件】
- 記事の作成・編集・削除機能
- マークダウン対応
- タグ機能
- SQLiteでデータ管理

【制約】
- フレームワーク：Flask推奨
- 初心者でも理解できるシンプルな設計
- コメント付きのコード例

【希望する回答】
1. プロジェクト構成
2. 主要なコード（app.py、models.py、routes.py）
3. セットアップ手順
4. 次のステップの提案

❌ 悪い例2：一度に多すぎる要求

Reactで完全なECサイトを作ってください。ユーザー認証、商品管理、カート、決済、レビュー機能、管理画面、メール通知、在庫管理、クーポン機能も全部お願いします。

問題点：

• 1つのプロンプトに詰め込みすぎ
• 優先順位が不明
• AIの回答が浅くなりやすい

✅ 改善例2：段階的なアプローチ

【フェーズ1】Reactで構築するECサイトの基本設計

まず、以下について設計方針を提案してください：

1. **技術スタック**
   - 状態管理（Redux/Zustand/Context API）
   - ルーティング
   - UIフレームワーク
   - バックエンド連携方式

2. **コア機能の優先順位付け**
   - 必須機能（MVP）
   - 第2フェーズ機能
   - 将来の拡張機能

3. **ディレクトリ構成**

その後、各機能を1つずつ実装していきます。

第2章：実践的なプロンプトパターン集

2.1 コード生成パターン

パターン1：機能実装の依頼

【役割】
TypeScriptとNext.js 14の専門家

【タスク】
App Routerを使用したページネーション機能を実装してください。

【詳細要件】
- Server Componentsで実装
- URLパラメータでページ番号を管理（例：/posts?page=2）
- 1ページあたり10件表示
- 前へ/次へボタンと直接ページ指定の両方対応
- SEOフレンドリーな実装

【提供する情報】
データ取得API: `GET /api/posts?page=1&limit=10`
APIレスポンス形式:
{
  "posts": [...],
  "totalCount": 150,
  "currentPage": 1,
  "totalPages": 15
}

【出力形式】
1. コンポーネント設計（役割分担）
2. 実装コード（コメント付き）
3. 使用例
4. アクセシビリティ対応

パターン2：バグ修正の依頼

【状況】
Next.jsアプリで画像が表示されない問題が発生しています。

【環境】
- Next.js 14.0.4
- App Router使用
- 画像は /public/images/ に配置

【現在のコード】
```tsx
import Image from 'next/image'

export default function ProductCard({ product }) {
  return (
    <div>
      <Image 
        src={product.imageUrl} 
        alt={product.name}
        width={300}
        height={300}
      />
    </div>
  )
}

【エラーメッセージ】

Error: Invalid src prop (https://example.com/image.jpg) on `next/image`, 
hostname "example.com" is not configured under images in your `next.config.js`

【依頼】

1. エラーの原因を説明
2. 修正したコードを提示
3. next.config.jsの適切な設定
4. 外部画像を扱う際のベストプラクティス

### 2.2 問題解決パターン

#### パターン3：トラブルシューティング

【問題】 Dockerコンテナで動作させているNode.jsアプリケーションで、 ホットリロードが効かない問題に直面しています。

【環境詳細】

• OS: macOS Sonoma 14.2
• Docker Desktop: 4.25
• Node.js: 20.10
• フレームワーク: Express + TypeScript
• ビルドツール: tsx (ts-node後継)

【現在の設定】 docker-compose.yml:

services:
  app:
    build: .
    volumes:
      - .:/app
      - /app/node_modules
    ports:
      - "3000:3000"
    command: npm run dev

package.json:

{
  "scripts": {
    "dev": "tsx watch src/index.ts"
  }
}

【試したこと】

• Dockerコンテナの再起動
• volumes設定の確認
• node_modulesの再インストール

【期待する回答】

1. 問題の原因分析（macOS特有の問題も含めて）
2. 解決策の提示（複数の選択肢）
3. 推奨される設定
4. 動作確認方法
5. 同様の問題を避けるためのベストプラクティス

### 2.3 学習・説明パターン

#### パターン4：コンセプト理解

【学習者プロフィール】

• プログラミング経験：1年（JavaScriptは書ける）
• 目標：モダンなReact開発を理解したい
• これまでの知識：useState、useEffectは使える

【質問】 React Server ComponentsとClient Componentsの違いを、 初心者でも理解できるように説明してください。

【希望する説明内容】

1. 概念の説明

   • 簡単な例え話から始める
   • 技術的に正確だが平易な言葉で

2. 具体例

   • 実際のコード例（2〜3パターン）
   • 「こういう時はServer、こういう時はClient」の判断基準

3. よくある誤解

   • 初心者が勘違いしやすいポイント

4. 実践的なアドバイス

   • 実際のプロジェクトではどう使い分けるか

5. 学習の次のステップ

【出力形式】 段階的に理解を深められるよう、 基礎→応用→実践の順で説明してください。

### 2.4 レビュー・改善パターン

#### パターン5：コードレビュー

【役割】 シニアソフトウェアエンジニア（10年以上の経験）

【タスク】 以下のPythonコードをレビューし、改善提案をしてください。

【対象コード】

def process_user_data(users):
    result = []
    for user in users:
        if user['age'] > 18:
            if user['status'] == 'active':
                result.append({
                    'name': user['name'],
                    'email': user['email'],
                    'age': user['age']
                })
    return result

【レビュー観点】

1. 可読性

   • 変数名、関数名は適切か
   • コードの意図は明確か

2. 保守性

   • 拡張しやすいか
   • テストしやすいか

3. パフォーマンス

   • 効率的か
   • ボトルネックはないか

4. エラーハンドリング

   • エッジケースへの対応
   • 例外処理

5. Pythonのベストプラクティス

   • PEP 8準拠
   • イディオム的な書き方

【出力形式】

• 問題点の指摘（重要度：高/中/低で分類）
• 改善したコード
• 改善理由の説明
• 追加のアドバイス

## 第3章：LLM別の最適化テクニック

### 3.1 ChatGPT（GPT-4 Turbo）向けプロンプト

#### 特徴：
- 長い文脈を理解する能力が高い
- 構造化された出力が得意
- 複雑な推論タスクに強い

#### 最適化された例：

システムロール（Custom Instructions活用）

あなたは経験豊富なシステムアーキテクトです。 技術的な回答をする際は、以下のルールに従ってください：

1. 回答は「要約」→「詳細」→「実例」の順で構造化
2. コードブロックには必ず言語指定とコメント
3. トレードオフがある場合は必ず両論併記
4. セキュリティリスクがある場合は警告を明記

メインプロンプト

マイクロサービスアーキテクチャでのAPI Gateway選定について、 以下の要件に基づいて推奨案を提示してください：

【要件】

• トラフィック: 10,000 req/sec想定
• 機能: 認証、レート制限、ログ、メトリクス
• 環境: AWS上で構築
• チーム: 5名のバックエンドエンジニア
• 予算: 中規模（月額$5,000程度）

【比較してほしい選択肢】

1. AWS API Gateway
2. Kong
3. Nginx + カスタム実装
4. Traefik

【期待する回答構成】

1. 各選択肢の評価（表形式）
2. 推奨案とその理由
3. 導入ロードマップ（3ヶ月）
4. リスクと対策

### 3.2 Claude向けプロンプト

#### 特徴：
- 長文読解と生成が得意（200K context）
- 倫理的配慮が強い
- 自然な文章生成に優れる

#### 最適化された例：

Claude独自の機能として、XML風のタグで構造化すると 精度が上がります。

### 3.3 Gemini向けプロンプト

#### 特徴：
- マルチモーダル対応（画像・動画理解）
- Google検索との連携
- 最新情報へのアクセス

#### 最適化された例：

【タスク】 2025年11月時点での、最新のReactライブラリトレンドを調査し、 包括的なレポートを作成してください。

【調査項目】

1. 状態管理

   • Redux、Zustand、Jotai等の最新状況
   • npmダウンロード数推移
   • GitHub Star数とアクティビティ

2. UIコンポーネント

   • shadcn/ui、Material-UI、Chakra UI等
   • 2024-2025年の成長率

3. フォーム管理

   • React Hook Form、Formik等の比較

4. データフェッチング

   • TanStack Query、SWR、Apolloの状況

【情報源】

• 公式ドキュメント
• GitHub統計
• npm trends
• 技術ブログ（最近6ヶ月以内）

【出力形式】 以下の形式の表を含めてください：

その後、各カテゴリの詳細分析と、 2025年の推奨構成を提示してください。

※Geminiは最新情報へのアクセスがあるため、 このような「現在の状況調査」タスクに向いています。

## 第4章：プロンプトエンジニアリングの高度なテクニック

### 4.1 Chain of Thought（思考の連鎖）

複雑な問題を段階的に解決させる手法：

【問題】 あるECサイトで以下のデータがあります：

• 月間訪問者数: 100,000人
• カート追加率: 15%
• 購入完了率（カート追加からの転換): 30%
• 平均購入単価: 5,000円
• 利益率: 20%

この状況で月間利益を30%向上させるには、 各指標をどの程度改善すべきか、 実現可能性も含めて分析してください。

【思考プロセス】 以下のステップで段階的に考えてください：

Step 1: 現在の月間利益を計算

Step 2: 目標の月間利益を算出

Step 3: 各指標（訪問者数、カート追加率、購入完了率、平均単価） を個別に改善した場合の影響をシミュレート

Step 4: 現実的な改善施策を各指標ごとに提案 （例：訪問者数なら広告、購入完了率なら決済UI改善等）

Step 5: 複数指標の組み合わせパターンを3つ提示 （例：訪問者+10% & 購入完了率+15%など）

Step 6: 最も実現可能性が高いプランを推奨

**効果：** 単純に答えだけを求めるより、思考プロセスを明示することで、
より論理的で実用的な回答が得られます。

### 4.2 Few-Shot Learning（例示学習）

期待する出力形式を例で示す手法：

以下の形式で、各プログラミング言語の特徴を説明してください：

[言語名]

誕生年: [年] 主な用途: [箇条書き3つ] 特徴:

• 👍 強み: [箇条書き3つ]
• 👎 弱み: [箇条書き3つ] 代表的フレームワーク: [3つ] 学習難易度: ⭐[1〜5] ひとこと: [50文字程度の実践的アドバイス]

【例1】

Python

誕生年: 1991年 主な用途:

• AI・機械学習
• Web開発
• データ分析

特徴:

• 👍 強み:
  • 読みやすく学習しやすい文法
  • 豊富なライブラリ（NumPy、Pandas、TensorFlow等）
  • 幅広い用途に対応
• 👎 弱み:
  • 実行速度が遅い
  • モバイルアプリ開発には不向き
  • GILによるマルチスレッド制約

代表的フレームワーク: Django、FastAPI、Flask 学習難易度: ⭐⭐（初心者に最適） ひとこと: まず学ぶべき万能言語。AI時代の必須スキル。

【例2】

TypeScript

誕生年: 2012年 主な用途:

• Webフロントエンド開発
• Node.jsバックエンド
• モバイルアプリ（React Native）

特徴:

• 👍 強み:
  • 静的型付けによる安全性
  • JavaScriptとの完全互換
  • 大規模開発に向いている
• 👎 弱み:
  • 学習コストがJavaScriptより高い
  • ビルドステップが必要
  • 型定義の保守コスト

代表的フレームワーク: React、Next.js、NestJS 学習難易度: ⭐⭐⭐（JavaScript経験があれば⭐⭐） ひとこと: モダンWeb開発の標準。JavaScript知識があれば移行は容易。

この形式で以下の言語も説明してください：

1. Rust
2. Go
3. Kotlin

### 4.3 Role-Playing（役割演技）

特定の専門家の視点から回答させる手法：

【シナリオ】 あなたは以下の3人の専門家です。 それぞれの立場から、「Next.js vs Remix」について意見を述べてください。

キャラクター1: 佐藤さん（スタートアップCTO）

• 背景：創業2年目、エンジニア5名のスタートアップ
• 優先事項：開発スピード、採用のしやすさ、コスト
• 性格：実用主義、トレンドには懐疑的

キャラクター2: 田中さん（大企業シニアアーキテクト）

• 背景：従業員1万人規模の企業、レガシーシステムのモダナイゼーション担当
• 優先事項：安定性、保守性、長期サポート、エンタープライズ対応
• 性格：慎重、実績重視

キャラクター3: 鈴木さん（フロントエンドエンジニア）

• 背景：5年の開発経験、両方のフレームワーク使用経験あり
• 優先事項：開発体験（DX）、技術的な美しさ、学習機会
• 性格：技術トレンドに敏感、理想追求型

【出力形式】 各キャラクターの発言を以下の形式で：

佐藤さん（スタートアップCTO）の意見

選択: [Next.js / Remix / その他] 理由: [200文字程度で、そのキャラクターらしい理由]

具体的根拠:

• [3つの箇条書き]

懸念点:

• [2つの箇条書き]

**効果：** 多角的な視点が得られ、意思決定に役立ちます。

### 4.4 Self-Consistency（自己整合性）

同じ質問に複数回答させて最適解を選ぶ手法：

【タスク】 以下の問題について、3つの異なるアプローチで解決策を提案してください。 その後、それぞれを評価し、最適な案を選んでください。

【問題】 認証トークンの保存場所をどこにすべきか？ （SPAアプリケーション、セキュリティ最優先）

アプローチ1: セキュリティ重視の視点 [localStorage / sessionStorage / Cookie / メモリ のいずれかを選び、 セキュリティを最優先した理由を述べる]

アプローチ2: ユーザビリティ重視の視点 [同様に選択し、UX観点での理由を述べる]

アプローチ3: 実装コスト重視の視点 [同様に選択し、開発・保守コストの観点で理由を述べる]

最終評価

推奨案: [最も総合的に優れた選択肢] 理由: [200文字程度] 注意点: [実装時の注意事項]

## 第5章：プロンプトのトラブルシューティング

### 5.1 よくある問題と解決策

#### 問題1: 回答が毎回異なる（不安定）

**原因：**
- プロンプトに曖昧さがある
- Temperatureパラメータが高い

**解決策：**

【改善前】 良い変数名を考えて

【改善後】 以下の関数に対して、以下の基準で変数名を提案してください：

基準：

• 目的が明確にわかる
• 短すぎず長すぎず（10〜25文字）
• TypeScriptの命名規則に従う
• キャメルケース使用

関数：ユーザーの年齢から成人かどうかを判定する

期待する出力：

1. 推奨名（第1候補）
2. 代替案（第2、第3候補）
3. それぞれの選択理由

#### 問題2: 回答が長すぎる/短すぎる

**解決策：**

【長さを制御するテクニック】

■ 簡潔な回答が欲しい場合： 「100文字以内で要約してください」 「箇条書き3点で説明してください」 「一言で答えてください：」

■ 詳細な回答が欲しい場合： 「段階的に詳しく説明してください（最低800文字）」 「初心者でも理解できるよう、例を多用して詳しく解説してください」 「以下の構成で包括的に説明してください：

1. 概要（300文字）
2. 詳細説明（500文字）
3. 実例（3つ）
4. まとめ（200文字）」

#### 問題3: 期待した形式で出力されない

**解決策：**

【フォーマット指定の強化】

単に「表形式で」ではなく、具体的に：

「以下のマークダウン形式の表で出力してください：

※人気度は GitHub Star数に基づく ※学習難易度は初心者視点で評価

最低5行のデータを含めてください。」

#### 問題4: ハルシネーション（事実と異なる情報）

**解決策：**

【事実性を高めるプロンプト】

以下の制約を明記：

「回答する際は以下のルールを厳守してください：

1. 確実な情報のみを記載
2. 不確実な情報は「〜と考えられます」「〜の可能性があります」と明記
3. 架空の情報は絶対に含めない
4. APIやライブラリの仕様を述べる際は、 「2025年11月時点の情報に基づく」と前置き
5. 古い情報の可能性がある場合は警告を含める

もし質問に答えるための情報が不足している場合は、 「情報が不足しているため正確な回答ができません」と述べてください。」

### 5.2 デバッグテクニック

#### テクニック1: プロンプトの段階的改善

【ステップ1: ミニマルなプロンプトから開始】 TypeScriptでReactのカスタムフックを作りたい

↓ 結果を確認

【ステップ2: 具体的な目的を追加】 TypeScriptでReactのカスタムフックを作りたい。 目的：APIからデータを取得し、ローディング状態とエラーも管理

↓ 結果を確認

【ステップ3: 制約を追加】 TypeScriptでReactのカスタムフックを作りたい。 目的：APIからデータを取得し、ローディング状態とエラーも管理 制約：

• ジェネリクスで型安全に
• AbortController対応
• 再試行機能付き

↓ 結果を確認

【ステップ4: 出力形式を指定】 （ステップ3の内容）

期待する出力：

1. 型定義
2. フック実装
3. 使用例（3パターン）
4. テストコード

#### テクニック2: プロンプトのA/Bテスト

同じ内容を異なる表現で試す：

【パターンA：命令形】 以下のコードをリファクタリングしてください。

【パターンB：問いかけ形】 以下のコードをより良くするには、どのようにリファクタリングすべきでしょうか？

【パターンC：役割付与】 あなたは経験豊富なコードレビュアーです。 以下のコードをレビューし、改善提案をしてください。

※どのパターンが最も良い結果を生むか試してみる

## 第6章：実務での活用シーン別プロンプト集

### 6.1 コードレビュー自動化

【プロンプトテンプレート】

あなたは経験10年以上のシニアエンジニアです。 以下のプルリクエストをレビューしてください。

変更内容: [PRの概要]

変更ファイル:

[コード全文]

レビュー観点:

1. ✅ バグの可能性
2. ✅ セキュリティリスク
3. ✅ パフォーマンス問題
4. ✅ 可読性・保守性
5. ✅ テストカバレッジ
6. ✅ ベストプラクティス準拠

出力形式:

🚨 重大な問題（マージブロック）

[あれば列挙、なければ「なし」]

⚠️ 要改善点

[ファイル名:行番号] - [問題内容]

// 修正案
[コード]

💡 推奨改善

[より良くするための提案]

✅ 良い点

[評価すべきポイント]

総合評価

• セキュリティ: [A/B/C/D]
• 品質: [A/B/C/D]
• 保守性: [A/B/C/D]
• マージ推奨: [Yes/No/条件付きYes]

### 6.2 技術調査・比較レポート

【技術選定のためのプロンプト】

以下のフォーマットで、[技術Aと技術B]を比較してください。

[技術A] vs [技術B] 徹底比較

1. 概要比較

2. 技術特性

技術A

強み:

• [3〜5つ]

弱み:

• [3〜5つ]

技術B

（同様）

3. ユースケース別適性

4. 学習コスト

• 技術A: [初級/中級/上級]、学習時間目安：[時間]
• 技術B: [初級/中級/上級]、学習時間目安：[時間]

5. エコシステム

ツール・ライブラリ

技術A: [主要な関連ツール5つ] 技術B: [主要な関連ツール5つ]

コミュニティ

• 技術A: [活発さ、日本語情報の充実度]
• 技術B: [同上]

6. 移行コスト

技術A→Bの移行:

• 難易度: [低/中/高]
• 推定工数: [期間]
• 主な課題: [箇条書き]

7. 将来性評価

8. 推奨判断

技術Aを選ぶべきケース

• [条件1]
• [条件2]
• [条件3]

技術Bを選ぶべきケース

• [条件1]
• [条件2]
• [条件3]

9. 実際の採用事例

技術A: [有名企業の事例3つ] 技術B: [有名企業の事例3つ]

10. 結論

[総合的な推奨と理由（300文字程度）]

### 6.3 ドキュメント自動生成

【APIドキュメント生成プロンプト】

以下のコードから、包括的なAPIドキュメントを生成してください。

[コード]

ドキュメント構成:

[API名] ドキュメント

概要

[このAPIが何をするものか、2〜3文で]

インストール

# インストールコマンド

クイックスタート

// 最小限の使用例（5行以内）

詳細な使い方

基本的な使い方

// コード例（コメント充実）

高度な使い方

// 複雑なユースケース

API リファレンス

[関数/メソッド名]

シグネチャ:

[型定義]

パラメータ:

返り値:

• 型: [型]
• 説明: [説明]

エラー:

使用例:

// 例1: 基本的な使い方
// 例2: エラーハンドリング
// 例3: 応用例

トラブルシューティング

よくあるエラー

エラー: [エラーメッセージ]

• 原因: [原因]
• 解決策: [解決策]

ベストプラクティス

1. [推奨事項1]
2. [推奨事項2]
3. [推奨事項3]

関連リソース

• [公式ドキュメント]
• [チュートリアル]
• [サンプルコード]

### 6.4 エラー解決支援

【エラー解決プロンプト】

以下のエラーについて、段階的に解決策を提示してください。

環境情報:

• OS: [OS名とバージョン]
• 言語/フレームワーク: [バージョン含む]
• 関連パッケージ: [バージョン含む]

エラーメッセージ:

[完全なエラーメッセージ]

エラー発生時のコード:

[エラーが発生したコード]

試したこと:

• [試したことのリスト]

期待する回答構成:

🔍 エラー原因の分析

直接的な原因

[このエラーが何を意味するのか]

根本原因

[なぜこのエラーが発生するのか]

🛠️ 解決策

方法1: [最も簡単な解決策]

手順:

1. [ステップ1]
2. [ステップ2]

修正コード:

[修正後のコード]

確認方法: [この解決策が成功したか確認する方法]

方法2: [代替案]

（同様の構成）

方法3: [根本的な解決策]

（同様の構成）

⚠️ 注意事項

[この解決策を適用する際の注意点]

🔄 再発防止策

[今後同じエラーを防ぐための方法]

📚 関連情報

[このエラーについて詳しく学べるリソース]

## 第7章：プロンプトのバージョン管理とチーム活用

### 7.1 プロンプトライブラリの構築

実務で使えるプロンプトをテンプレート化：

```markdown
# プロンプトライブラリ（prompts.md）

## カテゴリ: コード生成

### [CG-001] React コンポーネント生成
**目的**: 型安全なReactコンポーネントの雛形を生成
**最終更新**: 2025-11-28
**成功率**: 95%

【テンプレート】 TypeScriptで以下のReactコンポーネントを作成してください：

コンポーネント名: [NAME] 目的: [PURPOSE] Props:

• [prop1]: [type] - [description]
• [prop2]: [type] - [description]

要件:

• TypeScriptで型安全に
• React 18の機能を活用
• アクセシビリティ対応
• レスポンシブデザイン

出力形式:

1. 型定義
2. コンポーネント実装
3. 使用例
4. Storybookストーリー

**使用例**:

[NAMEを「UserProfile」、PURPOSEを「ユーザー情報の表示」に置き換えた実例]

**改善履歴**:
- 2025-11-28: Storybookストーリー追加
- 2025-11-20: アクセシビリティ要件追加
- 2025-11-15: 初版作成

---

### [CG-002] API エンドポイント実装
（同様の構成）

7.2 チームでのプロンプト共有

【チーム用プロンプトガイドライン】

## プロンプト作成ルール

1. **一貫性**
   - 役割は必ず明記
   - 出力形式は具体的に指定
   - エラーケースも考慮

2. **再利用性**
   - プレースホルダー（[NAME]、[PURPOSE]等）を使用
   - パターン化できるものはテンプレート化

3. **バージョン管理**
   - 変更時は改善履歴を記録
   - 成功率を追跡

4. **ドキュメント化**
   - 使用例を必ず含める
   - 失敗パターンも記録

## プロンプトレビュープロセス

新しいプロンプトをライブラリに追加する際：

1. 最低3回のテスト実行
2. 成功率が80%以上であることを確認
3. チームメンバー1名以上のレビュー
4. 使用例の追加
5. マージ

## プロンプトの評価基準

| 項目 | 評価（5段階） | 基準 |
|-----|------------|-----|
| 明確性 | ⭐⭐⭐⭐⭐ | 曖昧さがない |
| 再現性 | ⭐⭐⭐⭐☆ | 同じ入力で同じ出力 |
| 効率性 | ⭐⭐⭐☆☆ | 適切な長さ |
| 汎用性 | ⭐⭐⭐⭐⭐ | 多様なケースに対応 |

第8章：プロンプトエンジニアリングのベストプラクティス

8.1 DO's（推奨事項）

✅ DO: 具体的な数値と制約を含める

❌ 悪い例: 効率的なアルゴリズムを書いて
✅ 良い例: 10万件のデータを1秒以内で処理できる検索アルゴリズムを、
         時間計算量と空間計算量を明記して実装してください

✅ DO: コンテキストを十分に提供

❌ 悪い例: このコードのバグを直して
✅ 良い例: 
【状況】このコードはユーザー登録APIですが、
       メールアドレスの重複チェックが動作していません
【期待動作】既に登録済みのメールアドレスでは409エラー
【現在の動作】重複していても200が返る
【環境】Node.js 20、PostgreSQL 15、Prisma ORM

✅ DO: 段階的に改善する

最初: シンプルなプロンプト
   ↓ 結果確認
次: 詳細化・制約追加
   ↓ 結果確認
最後: 出力形式の最適化

✅ DO: 負の指示も含める

以下の要件でコードを書いてください：
- TypeScriptを使用
- async/awaitで非同期処理
- ❌ try-catchを過度にネストしない
- ❌ any型は使用禁止
- ❌ console.logでのデバッグコードを含めない

8.2 DON'Ts（避けるべき事項）

❌ DON'T: 曖昧な表現

❌ 避ける: 良い感じのデザインで
✅ 改善: モダンでミニマルなデザイン。
       参考：Apple公式サイトのような余白を活かしたレイアウト

❌ DON'T: 複数の要求を1つに詰め込む

❌ 避ける: ReactでTodoアプリを作って、テストも書いて、
         Dockerで動くようにして、CICDも設定して、
         ドキュメントも書いて、デプロイもして...

✅ 改善: タスクを分割
       Task 1: ReactでTodoアプリの基本機能実装
       Task 2: Jestでユニットテスト作成
       Task 3: Dockerコンテナ化
       ... （個別に実行）

❌ DON'T: 前提知識を仮定しすぎる

❌ 避ける: HoCsパターンで実装して

✅ 改善: Higher-Order Components（HoCs）パターンで実装してください。
       HoCsとは、コンポーネントを引数に取り、
       新しいコンポーネントを返す関数パターンです。
       認証チェックのような横断的関心事に使用します。

8.3 プロンプトの品質チェックリスト

新しいプロンプトを作成したら、以下をチェック：

□ 役割（Role）が明確に定義されているか
□ タスク（Task）が具体的か
□ 必要な文脈（Context）が含まれているか
□ 制約（Constraints）が明示されているか
□ 出力形式（Format）が指定されているか
□ 例（Examples）が含まれているか（必要なら）
□ 専門用語に説明があるか
□ 曖昧な表現がないか
□ 数値・基準が具体的か
□ 負の指示（してはいけないこと）を含むか
□ 実際にテストして期待通りの結果が得られたか

第9章：プロンプトエンジニアリングの未来

9.1 2025年のトレンド

1. マルチモーダルプロンプト テキストだけでなく、画像・音声・動画を組み合わせたプロンプトが主流に。

【例：画像+テキストプロンプト】
[画像: ワイヤーフレーム画像をアップロード]

この画像のワイヤーフレームを基に、
以下の技術スタックで実装してください：

- Next.js 14 (App Router)
- Tailwind CSS
- shadcn/ui
- TypeScript

要件：
- レスポンシブ対応
- アクセシビリティAAA準拠
- ダークモード対応

2. プロンプトチェーン 複数のプロンプトを連鎖させて複雑なタスクを実行。

Chain 1: 要件分析
  ↓ 出力を次のプロンプトの入力に
Chain 2: アーキテクチャ設計
  ↓
Chain 3: 実装
  ↓
Chain 4: テスト生成
  ↓
Chain 5: ドキュメント作成

3. 自己改善プロンプト プロンプト自身が結果を評価し、自動的に改善。

【メタプロンプト】
以下のプロンプトを評価し、改善してください：

【元のプロンプト】
「Reactでボタンコンポーネントを作って」

【評価基準】
- 明確性: /10
- 具体性: /10
- 再現性: /10

【改善されたプロンプト】
[AIが自動的に改善したプロンプトを出力]

9.2 学び続けるために

プロンプトエンジニアリングは急速に進化している分野です。

推奨リソース：

1. OpenAI Cookbook: 公式のベストプラクティス集
2. PromptBase: コミュニティ作成のプロンプト集
3. LangChain Documentation: 高度なプロンプトチェーン
4. 各LLMの公式ドキュメント: 最新機能とガイドライン

実践的学習法：

1. 毎日1つ新しいプロンプトパターンを試す
2. 失敗例を記録して改善する
3. チームでプロンプトライブラリを構築
4. 定期的にプロンプトレビュー会を開催

まとめ：プロンプトエンジニアリングのゴールデンルール

最後に、最も重要な5つのルールをまとめます：

🥇 ルール1: 明確さは力

曖昧さを徹底的に排除する。「良い」「適切な」「効率的な」といった抽象的な言葉は、 具体的な基準に置き換える。

🥈 ルール2: 文脈がすべて

AIは文脈がなければ適切な回答ができない。背景情報、制約、目的を惜しまず提供する。

🥉 ルール3: 例示は最強の教師

期待する出力形式は、説明よりも実例で示す。Few-Shot Learningを活用。

4️⃣ ルール4: 段階的改善

一度で完璧なプロンプトを作ろうとしない。テスト→改善→テストを繰り返す。

5️⃣ ルール5: 失敗から学ぶ

うまくいかなかったプロンプトこそ、最高の学習材料。失敗例を記録し、 なぜ失敗したのかを分析する。

プロンプトエンジニアリングは、AIを使いこなすための必須スキルです。 この記事で紹介したテクニックを実践し、自分なりのプロンプトライブラリを 構築していってください。

あなたのプロンプトが、明日の開発を加速させることを願っています。

Happy Prompting! 🚀