プロンプトエンジニアリングの基本

ストーリー

「AIの基本はわかったね。ここからが本題だ」

中島先輩が2つのブラウザウィンドウを並べた。同じChatGPTの画面だが、回答の質が全く違う。

「この2つ、同じAIに聞いてるのに、回答の質が全然違うでしょ？」

左の画面には曖昧で長い回答。右の画面には構造化された的確な回答。

「何が違うんですか？」

「聞き方だ。AIの能力を100%引き出すには、適切な質問の仕方を知る必要がある。これをプロンプトエンジニアリングと呼ぶ」

プロンプトとは

定義

プロンプト（Prompt）= AIに対する入力・指示のこと。

プロンプトの構成要素:

1. 指示（Instruction）: 何をしてほしいか
2. コンテキスト（Context）: 背景情報
3. 入力データ（Input）: 処理対象のデータ
4. 出力形式（Output Format）: どんな形式で回答してほしいか

悪いプロンプト vs 良いプロンプト

悪い例：

JavaScriptのコード書いて

→ 何のコードかわからない。AIは推測で汎用的な回答を返す。

良い例：

以下の要件でTypeScriptの関数を書いてください。

要件:
- 配列内のオブジェクトを指定したキーでソートする
- 昇順・降順を切り替えられる
- null/undefinedの値は末尾に配置する

入力:
- items: T[]（ジェネリクス配列）
- key: keyof T（ソートキー）
- order: 'asc' | 'desc'（ソート順）

出力:
- ソート済みの新しい配列（元の配列は変更しない）

出力形式:
- 関数定義とJSDocコメント付き
- 使用例を2つ含める

→ 具体的で明確。AIは的確なコードを生成できる。

プロンプトの基本原則

原則1: 明確で具体的に

❌ 「良いコードを書いて」
✅ 「Express.jsでユーザー認証のミドルウェアを書いてください。
    JWTトークンをAuthorizationヘッダーから検証する実装です」

原則2: コンテキストを提供する

❌ 「このエラーを直して」
✅ 「Node.js 20 + TypeScript 5.3の環境で、
    以下のコードを実行すると TypeError が発生します。

    環境:
    - Node.js 20.10
    - TypeScript 5.3.3
    - Express 4.18

    エラーメッセージ:
    TypeError: Cannot read properties of undefined (reading 'id')

    コード:
    [コードを貼り付け]」

原則3: 出力形式を指定する

❌ 「RESTful APIを設計して」
✅ 「ユーザー管理のRESTful APIを設計してください。

    出力形式:
    | メソッド | パス | 説明 | リクエスト | レスポンス |

    の表形式で、以下のエンドポイントを含めてください:
    - ユーザー一覧取得
    - ユーザー詳細取得
    - ユーザー作成
    - ユーザー更新
    - ユーザー削除」

原則4: 制約条件を明示する

❌ 「ソートアルゴリズムを書いて」
✅ 「クイックソートをTypeScriptで実装してください。

    制約:
    - ジェネリクスを使用すること
    - 比較関数を引数で受け取ること
    - インプレース（元の配列を変更する）ソートであること
    - 安定ソートでなくても良い
    - パフォーマンスを重視すること」

プロンプトの構造テンプレート

基本テンプレート

[ロール設定（オプション）]
あなたは[専門分野]のエキスパートです。

[タスク説明]
以下の要件で[成果物]を作成してください。

[コンテキスト]
背景: [プロジェクトの状況]
技術スタック: [使用技術]

[要件]
- 要件1
- 要件2
- 要件3

[制約]
- 制約1
- 制約2

[入力データ（あれば）]
[データを貼り付け]

[出力形式]
以下の形式で出力してください:
[形式の指定]

実際の使用例

あなたはTypeScriptの上級エンジニアです。

以下の要件でバリデーション関数を作成してください。

背景: ECサイトの注文フォームのサーバーサイドバリデーション
技術スタック: TypeScript 5.3, Zod

要件:
- 注文データのスキーマバリデーション
- 以下のフィールドを検証:
  - 商品ID（正の整数）
  - 数量（1〜99）
  - 配送先住所（必須、100文字以内）
  - メールアドレス（有効な形式）
  - 電話番号（日本の電話番号形式）

制約:
- Zodスキーマを使用すること
- カスタムエラーメッセージを日本語で定義すること
- バリデーション結果はResult型で返すこと

出力形式:
- Zodスキーマ定義
- バリデーション関数
- 使用例（正常系・異常系各1つ）

よくある失敗パターン

1. 曖昧すぎるプロンプト

❌ 「APIを作って」
→ 何のAPI？どの言語？どのフレームワーク？

✅ 「Express.js + TypeScriptでTodo管理のREST APIを作ってください。
    エンドポイントは一覧取得、作成、更新、削除の4つです」

2. 一度に大量のことを要求

❌ 「フルスタックのECサイトを作って。フロント、バックエンド、DB設計、
    デプロイ設定まで全部お願い」
→ 回答が浅く広くなり、実用性が低い

✅ 段階的に質問する:
   1. 「ECサイトのDB設計をER図で示してください」
   2. 「このER図に基づいたPrismaスキーマを生成してください」
   3. 「商品一覧のAPIエンドポイントを実装してください」

3. コンテキスト不足

❌ 「TypeError: Cannot read property 'name' of undefined を直して」
→ どのコードで？どの環境で？何をしようとして？

✅ 「以下の環境・コードでエラーが発生しています。
    [環境情報]
    [コード全文]
    [エラーメッセージ全文]
    [再現手順]」

反復的なプロンプト改善

プロンプトの改善サイクル

Step 1: 初回プロンプトを投げる
Step 2: 回答を評価する
Step 3: 不足点を特定する
Step 4: プロンプトを改善して再投げる
Step 5: 繰り返す

追加指示の例

初回: 「ユーザー登録のAPIを作ってください」
→ 基本的なコードが生成される

追加1: 「パスワードのバリデーション（8文字以上、英数字混合）を追加してください」
→ バリデーション追加

追加2: 「エラーレスポンスをRFC 7807形式にしてください」
→ エラー形式変更

追加3: 「テストコードも生成してください」
→ テスト追加

まとめ

チェックリスト

• プロンプトの4つの構成要素を理解した
• 4つの基本原則を実践できる
• よくある失敗パターンを避けられる
• 反復的なプロンプト改善の方法を理解した

次のステップへ

基本原則を押さえたところで、次はさらに効果的な「プロンプトパターン」を学びます。

実務で即使える具体的なパターンをマスターしましょう。

推定読了時間: 30分