AI: プロンプトエンジニアリング
最終更新:2026-08-26
「プロンプトエンジニアリング」は何か神秘的な技術のように聞こえるかもしれません。同じ AI でも、プロンプトの言い回し次第で出力の質が大きく変わるからです。しかしプロンプトエンジニアリングの中核は決して神秘的ではありません。それは AI に意図を理解させ、期待する形式でコンテンツを生成させるための一連の設計手法です。この章では設計原則から始め、ゼロショット・フューショット・思考連鎖(CoT)のプロンプト戦略を順に解説し、システムプロンプトと役割設定を理解し、Python で再利用可能な構造化プロンプトテンプレートを作る方法を示します。
1. 学べること
- プロンプトの重要性と設計原則(明確/具体/構造的)
- ゼロショット、フューショット、思考連鎖(CoT)のプロンプト戦略
- システムプロンプトと役割設定
- 構造化プロンプトテンプレート設計(JSON/Markdown 出力形式の制約付き)
- よくあるプロンプトの落とし穴とトラブルシューティング手法
2. ストーリー:プロンプト次第で決まる
(1) 痛みの種:AI の「無意味な作文」
Bob は市場分析レポートが必要で、ChatGPT を開いてこう打ち込みました。
「市場分析レポートを書いて」
その結果、AI は平凡で内容のない応答を生成しました。「市場は成長を続けています…機会と課題が共存しています…市場動向を注視することをお勧めします。」——正しいけれど、有用な情報はまったくありません。
(2) Alice のプロンプト修正
Alice はキーボードを取ってもう一度打ち込みました。
「あなたは電気自動車業界で 15 年の経験を持つシニア市場アナリストです。2025 年の世界の電気自動車市場を分析してください。含めるべきは:3 つの重要なトレンド、2 つの主要リスク、1 つの投資提言。トレンドのセクションは Markdown 表で示してください。」
今度は AI が、よく構成されデータ豊富な分析レポートを生成しました。同じモデル、同じ能力、違いはプロンプトだけです。
(3) 得られるもの:プロンプトは「取扱説明書」のようなもの
Bob は叫びました。「なるほど、AI ができないんじゃなくて、俺がちゃんと説明してなかったんだな!」Alice はうなずきました。「プロンプトエンジニアリングの本質は、AI に正確な『一連の指示』を与えることです。」
3. プロンプト設計の原則
(1) 3 つのコア原則
| 原則 | 意味 | 反例 |
|---|---|---|
| 明確(Clear) | タスクの目的が曖昧でなく、AI が推測する必要がない | 「市場を分析して」 |
| 具体(Specific) | 十分な詳細、制約、文脈を与える | 「レポートを書いて」 |
| 構造的(Structured) | 番号、箇条書き、テンプレートでプロンプトを整理する | 長い自由文の塊 |
良いプロンプトは、AI の仕事を「自由放任」から「ロードマップに従う」状態に変えます。
(2) 比較表:良いプロンプトと悪いプロンプト
| 次元 | 悪いプロンプト | 良いプロンプト |
|---|---|---|
| 目的 | 「何か書いて」 | 「顧客を製品発表イベントに招待する 200 語のビジネスメールを書く」 |
| 役割 | なし | 「あなたはシニア PR マネージャーです」 |
| 形式 | なし | 「Markdown 形式で出力。見出し、本文、署名を含める」 |
| 制約 | なし | 「200 語以内。堅苦しくないが格式は保つ」 |
| 例 | なし | 期待する出力の断片を 1〜2 つ含める |
| 評価 | なし | 「時間、場所、ハイライトに焦点を当てる」 |
(3) プロンプト設計の「6 要素」フレームワーク
完全なプロンプトには通常、以下の要素が含まれます(すべて含める必要はありませんが、要素が多いほど精度が上がります)。
- 役割(Role) — キャラクター説明:「あなたは…です」
- タスク(Task) — タスクの指定:「…を完了してください」
- 文脈(Context) — 背景情報:「対象読者は…です」
- 形式(Format) — 出力形式:「JSON/表/Markdown で出力」
- 制約(Constraint) — 制約:「300 語以内/小学校の語彙のみ使用」
- 例(Example) — 例(フューショット):「以下の例のように…」
Python の文字列テンプレートでは次のように表現します。
PROMPT_TEMPLATE = """
[役割] あなたは {role} です。
[タスク] 次を {task} してください。
[文脈] {context}
[形式] {format} で出力してください。
[制約] {constraints}
[例] {example}
"""
4. プロンプト戦略:ゼロショット/フューショット/思考連鎖
(1) ゼロショット学習
ゼロショットプロンプトは、AI に一切例を与えずにタスクを直接記述します。モデルの既存の知識と理解に依存します。
▶ サンプル: ゼロショットのプロンプトと出力(難易度:⭐)
# ゼロショットプロンプト:例なしで感情を分類
prompt = """
以下のレビューの感情を ポジティブ または ネガティブ に分類してください。
レビュー: "バッテリーの持ちが素晴らしく、1 回の充電で 12 時間続いた!"
感情:
"""
# 期待出力: ポジティブ
出力: ポジティブ
ゼロショット学習は、単純で明確に定義されたタスクに適しています。しかしタスクが複雑だったり特定の形式を要したりする場合、出力が不安定になりがちです。
(2) フューショット学習
「少ない例」とは、プロンプト内にいくつかの「入力→出力」の例を与え、AI が類推で期待するパターンを学べるようにすることを意味します。
▶ サンプル: 少ない例で出力を改善(難易度 ⭐)
# フューショットプロンプト:例付きで感情を分類
prompt = """
各レビューの感情を ポジティブ/ネガティブ/中立 に分類してください。
レビュー: "画面の品質が気に入っている!" -> ポジティブ
レビュー: "ひどいカスタマーサービスだ。" -> ネガティブ
レビュー: "まずまずの製品、特筆すべき点はない。" -> 中立
レビュー: "今年買った中で最高の買い物!" -> ポジティブ
レビュー: "得られたものに対して価格が高すぎる。" ->
"""
# 期待出力: ネガティブ
出力: ネガティブ
少ない例で扱う際の鍵:例は代表性がなければならないこと(さまざまなシナリオをカバーする)、そして形式は一貫していなければならないこと(AI が混沌ではなくパターンを学べるように)。
(3) 思考連鎖(CoT)プロンプト
「思考連鎖」プロンプトは、AI に「一歩ずつ考えさせ」、その推論プロセスを明示させます。これは数学的推論や論理解析などのタスクで特に効果的です。
▶ サンプル: 数学問題を解く CoT プロンプト(難易度:⭐⭐)
# 思考連鎖プロンプト:数学問題をステップごとに解く
prompt = """
以下の問題をステップごとに解いてください。
問題: ある店がノートパソコンを $800 で仕入れ、$1,050 で販売している。
利益率をパーセントで示してください。
ステップごとの解法:
"""
# 期待出力:
# ステップ 1: 利益 = 1050 - 800 = $250 を計算
# ステップ 2: 利益率 = (250 / 800) * 100% = 31.25%
# 答え: 利益率は 31.25%
出力: (例を実行して実際の出力を確認するか、上のコードコメントの期待出力メモを参照してください。)
CoT の 2 つの使い方:
- ゼロショット CoT:プロンプトの末尾に
"Let us think step by step."(一歩ずつ考えてみましょう)を追加する - フューショット CoT:例の中で完全な推論プロセスを提示し、AI に模倣させる
(4) 3 つのプロンプト戦略の比較表
| 次元 | ゼロショット | フューショット | 思考連鎖(CoT) |
|---|---|---|---|
| 例は必要? | いいえ | はい(2〜5) | はい(推論ステップを含む) |
| トークン消費 | 低 | 中 | 高 |
| ユースケース | 単純な分類と整形 | 形式/文体の揃えが必要 | 数学/論理/多段推論 |
| 出力安定性 | 低 | 中 | 高 |
| 精度 | モデル能力に依存 | 大きく改善 | 大きく改善 |
| 典型的な使い方 | Classify: ... |
A->X, B->Y, C->? |
"Step by step..." |
5. システムプロンプトと役割設定
(1) システムプロンプトとは?
Chat API では、メッセージは 3 つの役割に分類されます。
| 役割 | 機能 | 比喩 |
|---|---|---|
system |
AI の振る舞いルールとアイデンティティを設定 | 「社員手帳」 |
user |
ユーザーの実際の質問や指示 | 「顧客の要望」 |
assistant |
AI の返信 | 「社員の応答」 |
システムプロンプトは会話全体を通じて有効であり、AI の振る舞いを制御する最も強力な道具です。
(2) 役割設定の力
役割ベースの設定は、AI の「口調」を変えるだけでなく、引き出す知識の範囲や推論手法も変えます。
- 「あなたは小児科医です」→ AI は医療知識ベースに基づいて応答を優先的に構成する
- 「あなたは Python の専門家です」→ AI はより的確なコード提案を出す
- 「あなたはソクラテス式の教師です」→ AI は直接答えを出すのではなく質問で会話を導く
▶ サンプル: システムプロンプトのロールプレイ(難易度:⭐)
# 技術面接官役のシステムプロンプトを定義
system_prompt = """
あなたは技術面接を実施するシニアソフトウェアエンジニアです。
ルール:
1. 一度に 1 つの質問をする
2. 次の質問の前に候補者の回答を待つ
3. 回答が間違っている場合は、正解ではなくヒントを出す
4. トピックはカバーする:データ構造、アルゴリズム、システム設計
5. 各回答を 1〜5 の尺度で評価する
"""
user_message = "面接の準備はできています。始めてください。"
# AI は一般的なチャットボットではなく、構造的な面接官として振る舞う
出力: (例を実行して実際の出力を確認するか、上のコードコメントの期待出力メモを参照してください。)
(3) システムプロンプトのベストプラクティス
- ルールを先に、その次に役割を書く:ルールは役割より AI に守られやすい
- ルールを番号形式で列挙する:自然言語の段落より AI に見落とされにくい
- 否定的制約を設定する:「これをしてはいけない」は「これをしなさい」より効くこともある
- 限界を試す:わざとルールを破り、AI が修正するか確認する
6. 出力形式の制御
(1) なぜ形式制御が必要か?
AI の出力をプログラムで解析する必要がある場合(人間が読むのではなく)、形式制御は重要です。JSON、表、特定の区切り文字などです。
(2) 出力形式制御手法の比較
| 手法 | 長所 | 短所 | 適したシナリオ |
|---|---|---|---|
| 自然言語記述 | シンプル | AI が従わないことがある | 非構造な出力 |
| Markdown テンプレート | 可読性が良い | 解析に追加処理が必要 | レポート/文書 |
| JSON Schema | 機械可読 | トークン消費が高い | API 連携 |
| 区切り文字マーカー | 正確な制御 | 区切り文字の設計が必要 | 特定フィールドの抽出 |
| フューショット形式 | AI の模倣力が強い | 例がトークンを占める | 複雑な形式の揃え |
▶ サンプル: JSON 形式出力の制御(難易度:⭐⭐)
# スキーマ付きの JSON 出力を強制するプロンプト
prompt = """
以下のテキストから商品情報を抽出してください。
このスキーマに合う有効な JSON のみを出力してください。
{
"name": "string",
"price": "number",
"currency": "string",
"features": ["string"]
}
テキスト: "UltraWidget Pro は $49.99 で、防水ケース、ソーラー充電、5 年保証が付属する。"
JSON:
"""
# 期待出力:
# {
# "name": "UltraWidget Pro",
# "price": 49.99,
# "currency": "USD",
# "features": ["防水ケース", "ソーラー充電", "5 年保証"]
# }
出力: (例を実行して実際の出力を確認するか、上のコードコメントの期待出力メモを参照してください。)
(3) JSON 出力の信頼性を保証する
実際のプロジェクトでは、AI が生成した JSON に形式エラーが含まれることがあります。二次検証に Pydantic の使用を推奨します。
from pydantic import BaseModel
from typing import List
class ProductInfo(BaseModel):
name: str
price: float
currency: str
features: List[str]
# AI の出力を検証
try:
product = ProductInfo.model_validate_json(ai_output)
print(f"Valid: {product.name} - {product.currency}{product.price}")
except Exception as e:
print(f"Invalid JSON: {e}")
7. プロンプトエンジニアリングのワークフロー
(1) 反復最適化プロセス
プロンプトエンジニアリングは一度きりのプロセスではなく、「設計 → テスト → 評価 → 反復」のサイクルです。
graph TB
A[要件] --> B[テンプレート設計]
B --> C[テスト実行]
C --> D{出力を評価}
D -- 不満 --> E[診断]
E --> F[プロンプト修正]
F --> C
D -- 満足 --> G[テンプレート凍結]
G --> H[デプロイ]
(2) 出力品質の評価基準
| 次元 | 評価手法 | ツール |
|---|---|---|
| 正確性 | 人間のアノテーションとの比較 | LLM-as-Judge |
| 形式準拠 | スキーマ検証 | Pydantic / JSON Schema |
| 完全性 | 必須フィールドの確認 | カスタムスクリプト |
| 一貫性 | 複数回実行の比較 | 統計的分散 |
| 関連性 | タスク目的との整合 | 人間評価 |
8. よくあるプロンプトの落とし穴とトラブルシューティング
(1) 5 つのよくある落とし穴
| 落とし穴 | 症状 | 修正 |
|---|---|---|
| 曖昧な指示 | AI 出力が逸脱する | 明確なタスク目的 + 出力形式 |
| 情報過多 | プロンプトが長すぎ、AI が重要部を無視 | 段落に整理;重要情報は末尾に配置 |
| 形式ドリフト | 出力形式が不安定 | 例 + スキーマ制約を与える |
| 役割 conflict | システムとユーザー指示の矛盾 | システムが最優先;指示を統一 |
| 制約の超過 | 制約が多すぎて AI が出力不能に | コア制約を維持し冗長なものを削除 |
(2) プロンプトデバッグ戦略比較表
| 戦略 | アクション | 適したシナリオ |
|---|---|---|
| A/B テスト | 1 変数だけ変えて結果を比較 | どの要因が最大の影響か特定 |
| 段階的単純化 | 完全なプロンプトから要素を徐々に削除 | 最小 viable プロンプトを特定 |
| 段階的拡張 | 最も単純なプロンプトから要素を徐々に追加 | 各要素の貢献を確認 |
| 出力レビュー | AI 出力を文ごとにチェック | 具体的な問題を特定 |
| 境界テスト | 極端/境界の入力を与える | 頑健性をテスト |
| 温度制御 | 温度を下げてランダム性を減らす | 決定的な出力が必要な時 |
(3) 実践デバッグ:プロンプトの診断プロセス
# 悪い例: 曖昧なプロンプト
bad_prompt = "電気自動車市場を分析してください。"
# ステップ 1: 役割を追加
step1 = "あなたはシニア EV 市場アナリストです。EV 市場を分析してください。"
# ステップ 2: 構造を追加
step2 = """あなたはシニア EV 市場アナリストです。
2025 年の世界 EV 市場を以下で分析してください:
1. 3 つの重要なトレンド
2. 2 つの主要リスク
3. 1 つの投資提言"""
# ステップ 3: 形式制約を追加
step3 = """15 年の経験を持つシニア EV 市場アナリストです。
2025 年の世界 EV 市場を以下で分析してください:
1. 3 つの重要なトレンド(Markdown 表で提示)
2. 2 つの主要リスク(発生確率の評価付き)
3. 1 つの投資提言(期待 ROI 範囲付き)
明確な見出しを持つ Markdown 形式で出力してください。"""
9. 総合例:構造化商品分析のプロンプトテンプレート
▶ サンプル: 完全な商品分析プロンプトシステム(難易度:⭐⭐⭐)
システムプロンプト、ユーザープロンプト、出力解析を含む再利用可能な商品分析プロンプトテンプレートを作ります。
from string import Template
from pydantic import BaseModel
from typing import List, Optional
# ステップ 1: システムプロンプト - 役割を定義
SYSTEM_PROMPT = """あなたは市場調査、競合分析、ユーザー体験評価に精通した
シニア商品アナリストです。
構造的でデータ駆動の商品分析レポートを作成します。
ルール:
1. 常に具体的な証拠とデータポイントに基づいて分析する
2. 強みと弱みの両方を客観的に強調する
3. 優先順位付きの実行可能な提言を提供する
4. 可能な限り具体的な数値と指標を使う
5. 出力は有効な Markdown で形式する
"""
# ステップ 2: 6 要素すべてを持つユーザープロンプトテンプレート
USER_PROMPT_TEMPLATE = Template("""
[タスク] 以下の商品を分析し、包括的なレポートを作成してください。
[商品情報]
- 名前: $product_name
- カテゴリ: $category
- 価格: $price
- 対象ユーザー: $target_users
[レポート構成]
以下のセクションを含めてください:
1. **商品概要** - 簡単な説明と位置づけ
2. **強み** - 証拠付きの上位 3 つの利点
3. **弱み** - 例付きの上位 3 つの制限
4. **市場位置** - 競合状況の分析
5. **提言** - 優先順位付きの改善提案
[形式] 見出しと要約表を持つ Markdown で出力。
[制約] 最大 500 語。簡潔かつ具体的に。
[例]
商品概要
ProductX は若手プロ向けのミッドレンジスマートフォン…
要約表
| 側面 | 評価 | 主要な洞察 |
|--------|--------|-------------|
| デザイン | 4/5 | ミッドレンジ価格でプレミアム感 |
""")
# ステップ 3: テンプレートを埋めて API を呼ぶ(疑似コード)
def analyze_product(product_name: str, category: str,
price: str, target_users: str) -> str:
user_prompt = USER_PROMPT_TEMPLATE.substitute(
product_name=product_name,
category=category,
price=price,
target_users=target_users
)
# 実際の使用時はここで LLM API を呼ぶ
# response = client.chat.completions.create(
# model="gpt-4",
# messages=[
# {"role": "system", "content": SYSTEM_PROMPT},
# {"role": "user", "content": user_prompt}
# ],
# temperature=0.3
# )
# return response.choices[0].message.content
return user_prompt # デモ用にプロンプトを返す
# ステップ 4: テンプレートを使う
result = analyze_product(
product_name="EcoBike S3",
category="電動自転車",
price="$1,299",
target_users="25〜40 歳の都市通勤者"
)
print(result[:300] + "...")
出力: (例を実行して実際の出力を確認するか、上のコードコメントの期待出力メモを参照してください。)
主要な設計ポイント: システムプロンプトは役割と一般ルールを定義し、ユーザープロンプトテンプレートは具体的なタスクを扱います。両者を分離することでテンプレートの再利用性が高まります。
❓ よくある質問
📖 まとめ
- 設計原則:明確・具体・構造的——6 要素フレームワーク
- ゼロショットプロンプト:例なし。単純なタスク向き
- フューショット:2〜5 例。形式とスタイルを一貫させる
- 思考連鎖(CoT):「一歩ずつ」。多段推論に適する
- システムプロンプト:役割とルールを制御。最優先
- 形式制御:JSON Schema/Markdown テンプレート/フューショット
- デバッグ手法:A/B テスト、段階的拡張/単純化、境界テスト
次章予告: RAG(検索拡張生成)に踏み込み、AI が外部知識ベースを参照して質問に答えられるようにし、モデルの知識の時間的限界を突破する方法を学びます。
📝 練習問題
基礎(⭐)
同じタスク(英文を中国語に翻訳)を遂行するために、品質の異なる 3 つのプロンプトを設計し、出力の品質を比較しなさい。
# タスク: 英語から中国語への翻訳
# 悪いプロンプト
prompt_v1 = "Translate this: The quick brown fox jumps over the lazy dog."
# より良いプロンプト(文脈と制約を追加)
prompt_v2 = "次の英文を自然で流暢な中国語に翻訳してください。原文のトーンと意味を保ってください。\n\nThe quick brown fox jumps over the lazy dog."
# 最高のプロンプト(役割、形式、例を追加)
prompt_v3 = """あなたはプロの英中翻訳者です。
ルール:
1. 自然で惯用的な中国語に翻訳する
2. 原文のトーンとニュアンスを保つ
3. 文化的参照がある場合は簡単な注釈を加える
例:
EN: "Break a leg!"
CN: "Break a leg!(公演前に幸運を祈るという英語の慣用句)"
次を翻訳してください:
The quick brown fox jumps over the lazy dog."""
# TODO: 各プロンプトを LLM で実行し、出力を比較する
応用(⭐⭐)
少数の例を使って LLM に 5 件のコメントを感情(ポジティブ/ネガティブ/中立)で分類させなさい。
# フューショット感情分類
prompt = """各レビューの感情を分類してください。
レビュー: "この製品が大好き!五星!" -> ポジティブ
レビュー: "金の無駄、1 週間で壊れた。" -> ネガティブ
レビュー: "期待通りに動く、それ以上でも以下でもない。" -> 中立
レビュー: "デザインは美しいがバッテリーが早く減る。" -> ?
次の 5 件を分類してください:
1. "今まで使った中で最高のコーヒーメーカー!"
2. "配達が遅く、箱が破損していた。"
3. "価格の割に並の品質、まずまずだが印象に残らない。"
4. "カスタマーサポートが 10 分で問題を解決、凄い!"
5. "説明書が分かりにくいが製品はちゃんと動く。"
"""
# TODO: LLM で実行し、精度を検証する
チャレンジ(⭐⭐⭐)
LLM に技術面接官として振る舞わせ、マルチターン対話プロセスを実装するシステムプロンプトを設計しなさい。
# 技術面接官システム
SYSTEM_PROMPT = """あなたはコーディング面接を実施するシニアバックエンドエンジニアです。
ルール:
1. Python/データ構造/アルゴリズムについて一度に 1 つ質問する
2. 各回答を評価する:1〜5 で採点し簡潔なフィードバックを出す
3. 間違っている場合は、完全な答えではなくヒントを出す
4. 5 問終わったら総合評価を出す
5. 難易度は徐々に上げる
"""
# シミュレートされたマルチターン会話
conversation = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": "面接の準備はできました。"},
]
# TODO: 以下を実行するループを実装する:
# 1. conversation を LLM に送る
# 2. 面接官の質問を出力する
# 3. ユーザー入力を回答として受け取る
# 4. 両方を conversation に追加する
# 5. 面接が終わるまで繰り返す