プロンプトエンジニアリング入門｜実装で学ぶ

※ この記事にはアフィリエイトリンクが含まれています。詳細はプライバシーポリシーをご確認ください。

「ChatGPTに何を聞いても、なんとなく薄い回答しか返ってこない」と感じている方は多いはずです。原因のほぼすべては、AI側ではなく指示の解像度にあります。

この記事は、コードが書けるエンジニア向けにプロンプトエンジニアリングを実装視点で整理します。「呪文集」を覚えるのではなく、構造を理解して自分のコードから安定した出力を引き出すための土台を作ります。Few-shot／Chain-of-Thought／JSON出力指定など、実務でよく使うテクニックをコード付きで解説します。

僕は普段、Claude CodeやCursorをエディタとして毎日使い、自動化スクリプトを書いています。その中で「同じLLMでも、プロンプトを書き換えるだけで出力品質が桁違いに変わる」ことを何度も経験しました。本記事はそこで効いた技だけを抜き出した実装ガイドです。

本記事はAI学び直し｜エンジニアの実務スキル4階層のシリーズ第1回（第1階層：生成AI活用）にあたります。

こんな方に読んでほしい

ChatGPTやClaudeを使い始めたが、出力品質を安定させる方法がわからない方
OpenAI／Anthropic APIを叩き始めたが、プロンプト設計が場当たり的になっている方
業務スクリプトにLLMを組み込むときの「指示の型」を知りたい方
プロンプトエンジニアリングの体系を、初心者向けの抽象論ではなく実装で学びたい方

プロンプトエンジニアリングとは何か
1. 結論：AIから望む出力を引き出す指示設計の技術
2. 「指示の解像度」が出力品質を決める
プロンプト設計の5つの基本要素
実務で効くテクニック3選
初心者がハマる3つの失敗パターン
プロンプトを評価し、再利用可能にする
もっと深く学ぶなら
シリーズの位置づけと次回予告
まとめ｜プロンプトは指示設計の工学

プロンプトエンジニアリングとは何か

結論：AIから望む出力を引き出す指示設計の技術

プロンプトエンジニアリングとは、LLMに対して安定して期待通りの出力を得るための指示設計です。「魔法の呪文を探す」のではなく、構造化された指示を組み立てる工学的なアプローチを指します。

同じモデルでも、指示の書き方ひとつで出力の品質・精度・再現性が大きく変わります。ここを理解しておくと、AI活用の生産性が一段上がります。

「指示の解像度」が出力品質を決める

例として、悪い指示と良い指示を比べてみます。

// ❌ 解像度の低い指示
"このコードをレビューして"

// ✅ 解像度の高い指示
"このTypeScriptコードを以下の観点でレビューしてください:
1. 型安全性（anyの使用、unknownの型ガード）
2. エラーハンドリング（try-catch、Promise rejection）
3. パフォーマンス（不要な再レンダリング、メモ化）
出力は『観点／問題箇所／修正案』の3列でMarkdown表にしてください。"

後者は、観点・形式・制約まで明示しています。LLMは曖昧な指示には曖昧に答え、明確な指示には明確に答えます。

プロンプト設計の5つの基本要素

実務で安定して効くプロンプトには、共通する5つの要素があります。これを意識すると、指示の解像度が一段上がります。

5要素のチェックリスト

ゴール：何を達成したいか（例：コードをレビューする、要約する）
コンテキスト：背景情報（例：このコードはバックエンドAPI、TypeScript）
出力形式：JSON、Markdown表、箇条書きなど明示する
制約：文字数、禁止事項、必ず含める要素
例示：理想の出力サンプル（Few-shot）

5つすべてを毎回詰め込む必要はありません。タスクの難易度と再現性の要求に合わせて、必要な要素を選びます。簡単な要約タスクならゴール＋出力形式の2要素で十分なケースが多いです。

逆に、業務スクリプトに組み込んで毎日自動実行するようなタスクは、5要素すべてを揃えるべきです。再現性が落ちると本番で事故ります。経験的には、コンテキストと制約の手抜きが品質劣化の主因になります。

各要素の具体例

抽象的な説明だけでは伝わりにくいので、各要素の具体例を一つずつ並べます。

ゴール：「次のメールを顧客問い合わせ／社内連絡／スパムに分類する」
コンテキスト：「メールはSaaS企業のサポート窓口に届いたもので、英語と日本語が混在する」
出力形式：「JSON形式で {"category": string, "confidence": number} のスキーマに従う」
制約：「カテゴリは3種類のみ。それ以外を返してはいけない」
例示：「『プランの料金体系について教えてください』→ 顧客問い合わせ」

システムプロンプトと役割設定

API経由で使う場合、systemメッセージに「役割」を書き込むことで、出力のトーンと観点を固定できます。

const res = await llm.chat({
  system: "あなたは10年のTypeScript経験を持つシニアエンジニアです。" +
          "コードレビューでは型安全性を最優先に指摘してください。",
  user: "次のコードをレビューしてください: ...",
});

役割を与えると、LLMは「その役割らしい応答」を生成しやすくなります。汎用的な「アシスタント」より、専門特化した役割を与えるほうが出力が引き締まります。

実務で効くテクニック3選

Few-shot Learning：例を3つ見せる

Few-shotは、理想の入出力ペアを2〜5例見せて、同じ調子で答えさせるテクニックです。複雑な分類やフォーマット変換に強く効きます。

const prompt = `
次のメールを「顧客問い合わせ／社内連絡／スパム」に分類してください。

例1:
入力: "プランの料金体系について教えてください"
出力: 顧客問い合わせ

例2:
入力: "今週の定例MTGアジェンダを共有します"
出力: 社内連絡

例3:
入力: "限定割引コード！今すぐクリック"
出力: スパム

入力: "${mail.body}"
出力:`;

「分類カテゴリの定義を文章で書く」より、「具体例を3つ並べる」ほうが精度が出ます。LLMは抽象定義よりパターンマッチングが得意だからです。

Chain-of-Thought：考える過程を書かせる

Chain-of-Thought（CoT）は、結論の前に推論過程を出力させる手法です。複雑な計算や論理問題で精度が上がります。

const prompt = `
次の問題を解いてください。
**まず推論過程をステップ番号付きで書いてから、最後に「答え:」で結論を書いてください。**

問題: 倉庫に商品Aが120個、Bが80個ある。
Aを毎日15個、Bを毎日10個出荷する。
何日後にBが先に在庫切れになるか？
`;

「答えだけ書いて」より、「考えてから書いて」のほうが、LLMの内部推論が明示的になります。出力トークンは増えますが、その分精度が伸びます。

最近の推論特化モデル（OpenAI o3／Claude Opus 4.7等）は、内部で自動的にCoTを行います。それでも明示的な指示を加えると、さらに精度を引き出せるケースがあります。

JSON出力の強制：パース可能な形式で受け取る

業務スクリプトに組み込むなら、出力をJSON固定にしてパースできる形にするのが鉄則です。

const res = await llm.chat({
  system: "出力は必ず以下のJSONスキーマに従ってください。" +
          "余分な文字列やコードフェンスは絶対に含めないこと。",
  user: `次のレビュー文を分析してください:\n${review}\n\n
スキーマ: {
  "sentiment": "positive" | "negative" | "neutral",
  "score": number (0-100),
  "key_points": string[]
}`,
  response_format: { type: "json_object" },
});

const parsed = JSON.parse(res.content);

OpenAI／Anthropic APIにはresponse_formatパラメータがあり、JSON出力を強制できます。これでパース失敗のリスクが大幅に減ります。スキーマもプロンプトに明示すると、フィールド漏れが起きにくくなります。

各社の公式ガイドが一次情報として最も信頼できます。OpenAI Prompt engineering guideとAnthropic Prompt engineering overviewを併読すると、実務で迷ったときの拠り所になります。

初心者がハマる3つの失敗パターン

初学者のプロンプトを見ていると、共通する失敗パターンがあります。事前に知っておくと回り道を減らせます。

失敗1：抽象的すぎる指示

「いい感じにまとめて」「適当にレビューして」のような曖昧な指示は、出力も曖昧になります。「いい感じ」の定義はAI側にはありません。観点を3つ以上明示するだけで、出力は引き締まります。

失敗2：1つのプロンプトに詰め込みすぎる

「データ取得→変換→要約→メール送信文作成」のような複合タスクは、プロンプトを分割したほうが品質が上がります。LLMは長い指示の途中要素を取りこぼしやすい性質があるからです。

タスクを単機能に切り、各ステップで結果を確認しながら進めるほうが安定します。Agent的に自動化する場合も、まず手動でステップごとに動かすのが定石です。

失敗3：温度（temperature）の設定を意識していない

temperatureはLLMの「ばらつき度」を制御するパラメータです。0に近いほど決定的、1に近いほど創造的になります。

使い分けの目安は次の通りです。

temperature: 0：コードレビュー／分類／要約など再現性重視のタスク
temperature: 0.3〜0.5：ドキュメント生成／説明文作成など中庸タスク
temperature: 0.7〜1.0：企画案出し／コピーライティングなど創造性重視

多くの初学者は既定値（0.7程度）のまま使い、再現性が必要なタスクで結果がブレて困ります。タスクの性質に合わせて明示的に指定するのが定石です。

プロンプトを評価し、再利用可能にする

「書いて終わり」ではなく、評価して改善し、資産化するのがプロンプトエンジニアリングの本質です。コードと同じく、テストとリファクタの対象として扱います。

評価の3つの観点

業務プロンプトを評価するときは、次の3観点で見ます。

正確性：望む出力が得られているか（事実誤り・フォーマット崩れの有無）
再現性：同じ入力で似た出力が出るか（temperature 0で実行して比較）
頑健性：入力のばらつきに耐えるか（境界ケース・想定外の入力で試す）

テストデータセットを作っておく

業務で使うプロンプトには、最低5〜10件のテスト入力を保存します。プロンプトを書き換えるたびに全件流して比較すれば、品質劣化を即座に検知できます。

// テストデータの最小例
const testCases = [
  { input: "プランの料金は？", expected: "顧客問い合わせ" },
  { input: "明日のMTG資料です", expected: "社内連絡" },
  { input: "限定割引コード", expected: "スパム" },
];

for (const tc of testCases) {
  const out = await classify(tc.input);
  console.log(out === tc.expected ? "✓" : "✗", tc.input);
}

これは正式な評価フレームワーク（LangSmith、Promptfoo等）の最小版です。複雑なツールに飛びつく前に、自前のシェルスクリプトで回せる状態を作るのが先決です。

コードリポジトリにルールファイルを置く

毎回ゼロからプロンプトを書くと再現性が下がります。リポジトリにCLAUDE.mdや.cursorrulesを置くと、AIエディタが自動でルールを読み込んでくれます。

# CLAUDE.md（プロジェクトルートに置く）
## コーディング規約
- 一人称は「僕」固定
- TypeScriptは厳格モード（strict: true）
- テストはvitest、E2EはPlaywright
- 外部APIへのアクセスは必ずfetchラッパ経由

## レビュー観点
- 型安全性（any禁止、unknownにはガード必須）
- エラーハンドリングの網羅性
- セキュリティ（OWASP Top 10）

1枚置くだけで、出力品質が体感で大きく変わります。本を何冊も読むより速い投資対効果です。

プロンプトもバージョン管理する

業務で重要なプロンプトは、コードと同じくGitで管理するのがおすすめです。prompts/ディレクトリを作ってMarkdownで保存し、変更履歴を追える状態にします。

「先週のほうが出力が良かった」が起きたとき、差分を見て戻せます。これは複数人で運用する場面ほど効いてきます。レビュー対象になる、改善の議論ができる、責任の所在が明確になる、という3つの副次効果もついてきます。

テンプレート化で属人化を防ぐ

プロンプトを資産化するもう一つの形が、関数化です。よく使うパターン（要約・分類・コードレビュー）はラッパー関数にして、引数で本文だけ受け取る設計にします。

// プロンプトテンプレートの関数化
async function summarize(text: string, maxChars = 200): Promise<string> {
  const res = await llm.chat({
    system: `あなたは技術文書の要約専門です。出力は${maxChars}字以内、` +
            `箇条書きを使わず、結論を最初の1文に置いてください。`,
    user: text,
    temperature: 0,
  });
  return res.content;
}

この形にしておくと、呼び出し側はawait summarize(text)とだけ書けばよく、プロンプトの中身を意識する必要がなくなります。チームで使う共通ライブラリとして整備していくと、生産性の差がはっきり出ます。