5.

Prompt Engineering とは?技法・Chain-of-Thought・実践例

編集

本稿は 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-shot2〜5 個の入出力例を提示形式を揃えたい、独自タスク
Chain-of-Thought (CoT)「ステップを追って考えて」と指示数学・推論・複数手順の問題
Self-Consistency複数回サンプリングして多数決正解が一意に決まる重要タスク
ReAct「考える → ツールを使う → 観察」のループ外部情報が必要なエージェント
Self-Refine出力を自己レビューして改善文章生成・コード生成
ロールプレイ具体的なペルソナを与える専門家視点が欲しい場面
Structured OutputJSON 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 か条

原則
  1. 具体的に書く(「いい感じに」ではなく「3 段落・500 字以内で・結論先出し」)
  2. 役割を与える(「日本語ネイティブの校正者として」)
  3. 出力形式を指定する(JSON / Markdown / 番号付きリスト)
  4. 境界条件を明示(「不明な場合は『不明』と返す」)
  5. 例を見せる(Few-shot で形式を学ばせる)
  6. 段階的に分割(複雑タスクは複数ステップに分ける)
  7. 重要な指示を最後に置く(モデルは末尾に強く影響される傾向)
  8. 反復して改善(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 では「外部情報を必ず引用する」「不明な場合は答えない」を必ず指示
  • 多言語対応では応答言語を明示(「日本語で回答」)
  • システム指示はシステムロールに、ユーザ入力はユーザロールに分けて渡す

関連

編集
Post Share
子ページ

子ページはありません

同階層のページ
  1. LLM (大規模言語モデル)
  2. Transformer
  3. Attention (注意機構)
  4. Embedding (埋め込み)
  5. Prompt Engineering
  6. RAG (検索拡張生成)
  7. ファインチューニング
  8. AIエージェント
  9. マルチモーダルAI
  10. トークンとコンテキストウィンドウ
  11. Diffusion Model (拡散モデル)

最近更新/作成されたページ