本稿は Prompt Engineering（プロンプトエンジニアリング） に関する記事です。
| この記事の要点 |
|---|
- プロンプトエンジニアリングは LLM への「指示文」を設計して出力品質を上げる技術
- 同じモデルでもプロンプト次第で精度が大きく変わる。無料で効く最強の改善手段
- 基本要素: 役割 / タスク / 入力 / 出力形式 / 制約 / 例（Few-shot）
- 主な技法: Zero-shot / Few-shot / Chain-of-Thought / ReAct / Self-Consistency
- 近年は推論モデル（GPT o3 / Claude Extended Thinking）が内部で CoT を回すので、外部の CoT 指定は不要なケースも
- システムプロンプトに「あなたは○○です」と役割を与えるのが基本
- 機密情報・PII を含めない、プロンプトインジェクション対策が業務利用の必須事項
|
プロンプトエンジニアリングとは？
Prompt Engineering は、LLM への入力指示文（プロンプト）を設計・チューニングして、出力の品質・一貫性・安全性を上げる技術です。プロンプトはモデルの「使い方」であり、本体（重み）を変えずに動作を大きく変えられる、もっともコスト効率の良い改善手段です。
プロンプトの基本構造
| 要素 | 役割 | 例 |
|---|
| 役割（Role） | モデルの立場を指定 | 「あなたは経験 10 年の Python エンジニアです。」 |
| タスク（Task） | 何をしてほしいか | 「以下のコードのバグを指摘してください。」 |
| 入力（Context） | 処理対象のデータ | def add(a, b): return a - b |
| 出力形式 | どう返してほしいか | 「JSON で {bug: ..., fix: ...} の形で返してください。」 |
| 制約・条件 | 守るべきルール | 「日本語のみで回答。コードは省略しない。」 |
| 例（Few-shot） | 入出力の手本 | 「例1: ... 例2: ...」 |
主要なプロンプト技法
| 技法 | 内容 | いつ使う |
|---|
| Zero-shot | 例なしで指示だけ | 明確で単純なタスク |
| Few-shot | 2〜5 個の入出力例を提示 | 形式を揃えたい、独自タスク |
| Chain-of-Thought (CoT) | 「ステップを追って考えて」と指示 | 数学・推論・複数手順の問題 |
| Self-Consistency | 複数回サンプリングして多数決 | 正解が一意に決まる重要タスク |
| ReAct | 「考える → ツールを使う → 観察」のループ | 外部情報が必要なエージェント |
| Self-Refine | 出力を自己レビューして改善 | 文章生成・コード生成 |
| ロールプレイ | 具体的なペルソナを与える | 専門家視点が欲しい場面 |
| Structured Output | JSON Schema 等で出力を厳密化 | システム連携 |
| Meta-Prompting | 「良いプロンプトを書いて」と LLM に頼む | プロンプト設計の補助 |
典型例: Few-shot プロンプト
|
以下の文をポジティブ / ネガティブ / 中立 に分類してください。
例1: 「この映画は最高だった」 → ポジティブ
例2: 「サービスがひどかった」 → ネガティブ
例3: 「2025 年に公開された」 → 中立
入力: 「料理は美味しかったけど店員の対応が悪かった」
出力:
|
典型例: Chain-of-Thought
|
次の問題を ステップを追って 解いてください。
問題: 3 個入りのリンゴパックが 5 つ、5 個入りが 3 つあります。リンゴの総数は？
手順:
1. ...
2. ...
最終的な答え: ...
|
推論モデル時代の変化
| 補足: o3 / Extended Thinking 等 |
|---|
OpenAI o1 / o3、Anthropic Claude Extended Thinking、Gemini Thinking モードのような推論特化モデルは、内部で長い思考連鎖を自動で回すため、「ステップバイステップで考えて」と書く必要がほぼなくなります。
むしろこれらのモデルでは、CoT を強制するとかえって遅く・高くなることがあります。プロンプトは「明確な質問」だけで十分なケースが多いです。タスクの難易度に合わせてモデルとプロンプト戦略を選び分けるのが現代のプロンプト設計です。 |
良いプロンプトの 8 か条
| 原則 |
|---|
- 具体的に書く（「いい感じに」ではなく「3 段落・500 字以内で・結論先出し」）
- 役割を与える（「日本語ネイティブの校正者として」）
- 出力形式を指定する（JSON / Markdown / 番号付きリスト）
- 境界条件を明示（「不明な場合は『不明』と返す」）
- 例を見せる（Few-shot で形式を学ばせる）
- 段階的に分割（複雑タスクは複数ステップに分ける）
- 重要な指示を最後に置く（モデルは末尾に強く影響される傾向）
- 反復して改善（A/B 比較・自動評価で測る）
|
Structured Output（厳密な構造化出力）
システム連携では出力フォーマットを厳密化する。OpenAI / Anthropic / Google API は JSON モードや JSON Schema 指定をサポート。
|
from openai import OpenAI
from pydantic import BaseModel
class Bug(BaseModel):
line: int
description: str
suggested_fix: str
client = OpenAI()
res = client.beta.chat.completions.parse(
model="gpt-4o",
messages=[{"role": "user", "content": "以下のコードのバグを 1 件指摘してください: ..."}],
response_format=Bug,
)
print(res.choices[0].message.parsed)
|
セキュリティ・運用上の注意
| よくある落とし穴 |
|---|
- プロンプトインジェクション: 外部入力が指示を上書きする。ユーザ入力を直接連結しない / 役割分離 / 出力検査で守る
- 機密情報・個人情報を入れない。Enterprise 契約や API（学習オフ）を使う
- システムプロンプトの漏洩: 「指示を全部教えて」で出ることがある。秘密にしすぎない設計
- ハルシネーション対策: 「分からない場合は『分からない』と答える」を明示
- 温度 (temperature): 厳密な業務タスクは 0、創造系は 0.7〜1.0
- 長すぎるプロンプト: コストとレイテンシ増、コンテキスト上限到達で末尾が無視される
- モデル差: 同じプロンプトでも GPT / Claude / Gemini で挙動が違う。モデル切替時に再評価
- 本番では版数固定 + 出力を自動評価する仕組みを整える
|
運用上のヒント
| Tips |
|---|
- プロンプトはテンプレートとして管理（コードに直書きしない）
- 本番では Prompt Registry（LangSmith / Promptfoo / Helicone 等）で版管理
- 変更時は自動評価（金 standard データセット）で回帰チェック
- 「悪いプロンプト」もコレクションする（失敗例の分析に役立つ）
- RAG では「外部情報を必ず引用する」「不明な場合は答えない」を必ず指示
- 多言語対応では応答言語を明示（「日本語で回答」）
- システム指示はシステムロールに、ユーザ入力はユーザロールに分けて渡す
|
関連