「LLMの出力品質をもっと上げたい」「複雑なタスクでAIが的外れな回答をしてしまう」「業務に使えるレベルの精度が出ない」——こうした課題に直面しているエンジニアやAI活用担当者は少なくないでしょう。
プロンプトエンジニアリングの基本は「明確な指示を書く」ことですが、複雑なタスクではそれだけでは不十分です。LLMの推論能力を最大限引き出すには、学術研究に裏打ちされた高度なプロンプティング手法を適切に使い分ける必要があります。
本記事では、Chain-of-Thought、Few-Shot、ReAct、Tree-of-Thoughtなど、上級のプロンプティングテクニックを具体的なプロンプト例とともに解説します。
プロンプトエンジニアリングの基礎を振り返る
上級テクニックに入る前に、効果的なプロンプトの基本要素を確認しておきましょう。
良いプロンプトには以下の要素が含まれます。
役割の指定(Role):AIにどのような専門家として振る舞うかを指示します。「あなたはシニアバックエンドエンジニアです」のように設定することで、回答の専門性と文脈が適切になります。
タスクの明確な記述(Task):何をしてほしいのかを具体的に記述します。曖昧な指示は曖昧な出力につながります。
コンテキスト(Context):タスクの背景情報や制約条件を提供します。AIが適切な判断を行うために必要な情報です。
出力形式の指定(Format):期待する出力のフォーマットを明示します。JSON、マークダウン、箇条書きなど、形式を指定することで構造化された出力が得られます。
# 基本的なプロンプトの構造
あなたは[役割]です。
[コンテキスト/背景情報]
以下のタスクを実行してください:
[具体的な指示]
# 制約条件
- [制約1]
- [制約2]
# 出力形式
[期待する出力のフォーマット]
これらの基本を押さえた上で、以下の上級テクニックを活用することで、出力品質を飛躍的に向上させることができます。
Chain-of-Thought(CoT):段階的推論の促進
Chain-of-Thought(CoT)は、LLMに「思考のステップ」を明示させることで、推論の精度を向上させるテクニックです。Google Researchが2022年に発表した論文で提案され、特に数学的推論、論理的推論、多段階の問題解決で劇的な効果があります。
Zero-Shot CoT
最もシンプルなCoTは、プロンプトに「ステップバイステップで考えてください」と一言加えるだけです。
# Zero-Shot CoTの例
## CoTなし(精度が低い)
Q: 店に500円のりんごが3個と300円のみかんが5個あります。
合計金額から15%割引した場合、支払い金額はいくらですか?
## Zero-Shot CoT(精度が向上)
Q: 店に500円のりんごが3個と300円のみかんが5個あります。
合計金額から15%割引した場合、支払い金額はいくらですか?
ステップバイステップで考えてから、最終的な答えを出してください。
たったこれだけの追加で、LLMは中間ステップ(りんごの合計→みかんの合計→総合計→割引計算→最終金額)を明示的に出力し、最終回答の精度が大幅に向上します。
Few-Shot CoT
推論の手本を示すことで、より精密な思考プロセスを誘導できます。
# Few-Shot CoTの例:ビジネス判断の推論
以下の例を参考に、ステップバイステップで分析してください。
## 例題
Q: 月額1万円のSaaSツールを導入すべきか判断してください。
ツール導入前:手作業で月40時間、人件費は時給2,000円
ツール導入後:作業時間が月10時間に短縮
A: ステップ1: 現在のコストを計算する
手作業コスト = 40時間 × 2,000円 = 80,000円/月
ステップ2: 導入後のコストを計算する
作業コスト = 10時間 × 2,000円 = 20,000円/月
ツール費用 = 10,000円/月
合計 = 30,000円/月
ステップ3: 効果を比較する
削減額 = 80,000円 - 30,000円 = 50,000円/月
ROI = 50,000円 / 10,000円 = 500%
結論: 月5万円のコスト削減(ROI 500%)が見込めるため、導入を推奨します。
## 本題
Q: 月額5万円のAIチャットボットを導入すべきか判断してください。
導入前:カスタマーサポート3名(月給25万円/人)で月600件対応
導入後:AIが60%の問い合わせを自動処理、人員を2名に削減可能
Few-Shot Prompting:例示による学習
Few-Shot Promptingは、タスクの入出力例を数個示すことで、LLMにタスクのパターンを学習させるテクニックです。ファインチューニングなしで、特定のタスクに対するモデルの性能を向上させることができます。
効果的なFew-Shotの設計
# Few-Shot: 問い合わせ分類の例
以下の例を参考に、顧客の問い合わせを分類してください。
## 例1
問い合わせ: 「注文した商品がまだ届きません。注文番号は12345です」
分類: 配送遅延
緊急度: 中
推奨対応: 配送ステータスを確認し、到着予定日を回答
## 例2
問い合わせ: 「クレジットカードの二重請求が発生しています」
分類: 請求トラブル
緊急度: 高
推奨対応: 即座に請求部門にエスカレーション、返金処理を開始
## 例3
問い合わせ: 「商品の使い方がわかりません。マニュアルはありますか?」
分類: 使い方の質問
緊急度: 低
推奨対応: 製品マニュアルのURLを案内
## 分類対象
問い合わせ: 「昨日購入した製品の液晶画面に傷がついていました。交換してほしいです」
Few-Shotの設計で重要なポイントは以下の通りです。
・例は3〜5個程度が最適(多すぎるとコンテキスト長を圧迫)
・タスクの多様なパターンをカバーする例を選ぶ
・出力形式を統一し、一貫したフォーマットで提示する
・エッジケースや境界的なケースも含める
ネガティブFew-Shot
「こう回答してほしくない」という悪い例も含めると、出力品質がさらに向上します。
# ネガティブFew-Shotの例
## 悪い回答の例(このように回答しないでください)
問い合わせ: 「商品が壊れていました」
悪い回答: 「申し訳ありません。返品をご検討ください。」
理由: 具体的な手順がなく、顧客に負担をかけている
## 良い回答の例(このように回答してください)
問い合わせ: 「商品が壊れていました」
良い回答: 「ご不便をおかけして申し訳ございません。
商品の交換手続きをすぐに開始いたします。
1. 破損箇所のお写真をこちらのフォームからお送りください: [URL]
2. 確認後、24時間以内に交換品を発送いたします。
3. 破損品の返送は、交換品に同梱する着払い伝票をご利用ください。」
ReAct:推論と行動の統合
ReAct(Reasoning + Acting)は、LLMに「考える」と「行動する」を交互に行わせるプロンプティング手法です。特にツール連携を伴うAIエージェントの開発で重要な手法です。
ReActプロンプトの構造
# ReActプロンプトの設計例
あなたは以下のツールを使用できるアシスタントです:
ツール:
1. search(query) - Web検索を実行します
2. calculate(expression) - 数式を計算します
3. lookup_database(table, conditions) - データベースを検索します
以下の形式で回答してください:
Thought: [現状の分析と次に何をすべきかの推論]
Action: [使用するツール名]
Action Input: [ツールへの入力]
Observation: [ツールの実行結果]
... (Thought/Action/Observation を必要な回数繰り返す)
Thought: 十分な情報が集まったので、最終回答を作成する
Final Answer: [ユーザーへの最終回答]
ユーザーの質問: 「当社の先月の売上と、同業他社の平均売上を比較してください」
ReActパターンの利点は、推論プロセスが透明であること、適切なツールの選択が行われること、中間結果に基づいて計画を修正できることです。
ReActの実装上の注意点
・ツールの説明は具体的かつ簡潔に記述する(LLMが選択判断に使う)
・ループの最大回数を設定し、無限ループを防止する
・Observationの内容が長い場合は要約してからThoughtに反映させる
・ツールのエラー時のリカバリー手順も含める
Tree-of-Thought:複数の推論パスの探索
Tree-of-Thought(ToT)は、1つの推論パスだけでなく、複数の異なるアプローチを並行して探索し、最も有望なものを選択するテクニックです。
# Tree-of-Thoughtの例:システム設計の判断
以下の課題に対して、3つの異なるアプローチを検討してください。
各アプローチについて、メリット・デメリット・リスクを分析し、
最終的に最も適切なアプローチを選択してください。
課題: ECサイトの検索機能がレスポンス500ms以上かかっており、改善が必要
## アプローチ1を検討
[検索エンジンの導入(Elasticsearch / Algolia)]
思考: ...
メリット: ...
デメリット: ...
実現可能性: /5
## アプローチ2を検討
[データベースクエリの最適化(インデックス追加、クエリ改善)]
思考: ...
メリット: ...
デメリット: ...
実現可能性: /5
## アプローチ3を検討
[キャッシュレイヤーの導入(Redis)]
思考: ...
メリット: ...
デメリット: ...
実現可能性: /5
## 最終判断
3つのアプローチを総合的に評価し、推奨するアプローチを選択してください。
複数の組み合わせが最適な場合は、その旨も記述してください。
ToTは、重要な意思決定やトレードオフの分析が必要な場面で特に効果を発揮します。
Self-Consistency:多数決による精度向上
Self-Consistencyは、同じ質問に対して複数回の推論を実行し、多数決で最終回答を決定する手法です。LLMの出力のランダム性を活かし、複数の推論パスが同じ結論に至るかどうかで信頼性を判断します。
実装アプローチ
# Self-Consistencyの実装(Pythonでの概念例)
import openai
def self_consistent_answer(question: str, n_samples: int = 5) -> str:
"""同じ質問を複数回実行し、多数決で回答を決定する"""
answers = []
for _ in range(n_samples):
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "user",
"content": f"""
以下の問題をステップバイステップで解いてください。
最後に「最終回答: 」の形式で答えを記載してください。
問題: {question}
"""
}],
temperature=0.7, # 多様な推論を生成するため、温度を上げる
)
answer = extract_final_answer(response.choices[0].message.content)
answers.append(answer)
# 多数決で最終回答を決定
from collections import Counter
most_common = Counter(answers).most_common(1)[0]
confidence = most_common[1] / n_samples
return {
"answer": most_common[0],
"confidence": confidence,
"all_answers": answers,
}
Self-Consistencyは特に、数学的な問題やコードの生成、ファクトチェックなど、正解が明確に存在するタスクで有効です。APIコストが増加するため、精度が重要なタスクに限定して使いましょう。
Structured Output:構造化された出力の設計
プロダクション環境でLLMを利用する場合、出力を構造化してプログラムで処理できる形式にすることが不可欠です。
JSONモードの活用
# 構造化出力のプロンプト設計
以下のユーザーレビューを分析し、指定されたJSON形式で結果を返してください。
レビュー: 「このノートPCは画面がとても綺麗で動作も軽快です。ただ、バッテリーの持ちが悪くて外出先では不安です。あと、キーボードの打鍵感は好みが分かれそう。価格を考えると全体的にはお買い得だと思います。」
必ず以下のJSON形式で出力してください:
```json
{
"overall_sentiment": "positive" | "negative" | "neutral",
"score": 1-5の数値,
"aspects": [
{
"aspect": "評価対象",
"sentiment": "positive" | "negative" | "neutral",
"detail": "具体的な評価内容"
}
],
"purchase_recommendation": true | false,
"summary": "レビューの要約(50文字以内)"
}
```
最新のOpenAI APIやAnthropic APIでは、JSONモードやStructured Outputs機能が提供されており、確実にJSON形式の出力を得ることができます。
出力検証の組み込み
# 出力検証を含むプロンプト設計
以下のタスクを実行し、結果を出力してください。
## タスク
[タスクの内容]
## 出力後の自己検証
出力が完成したら、以下のチェックリストで自己検証してください:
□ JSON形式が正しいか(パース可能か)
□ すべての必須フィールドが含まれているか
□ 数値フィールドが指定範囲内か
□ テキストフィールドが指定文字数以内か
検証でエラーが見つかった場合は修正した上で出力してください。
テクニック選択のガイドライン
どのテクニックをいつ使うべきか、判断基準をまとめます。
単純なQ&A・テキスト生成
基本的なプロンプト設計で十分です。役割・タスク・出力形式を明確にするだけで高品質な出力が得られます。
数学的・論理的推論が必要な場合
Chain-of-Thoughtを使いましょう。「ステップバイステップで考えてください」の一言を追加するだけでも効果があります。精度が重要ならSelf-Consistencyと組み合わせます。
特定のフォーマットや判断基準で出力したい場合
Few-Shot Promptingで例を示します。3〜5個の良質な例が、長い指示文よりも効果的な場合が多いです。
外部ツールとの連携が必要な場合
ReActパターンを使います。ツールの定義とThought-Action-Observationのループ構造を設計しましょう。
複雑な意思決定・設計判断の場合
Tree-of-Thoughtで複数のアプローチを比較検討させます。トレードオフの分析が必要な場面で特に有効です。
プログラムで出力を処理する場合
Structured Outputでフォーマットを厳密に指定します。JSON SchemaやPydanticモデルでの検証を組み込みましょう。
まとめ
プロンプトエンジニアリングの上級テクニックは、LLMの出力品質を劇的に向上させる力を持っています。本記事のポイントを振り返ります。
・Chain-of-Thoughtで段階的推論を促し、複雑な問題の正答率を向上させる
・Few-Shotでタスクのパターンを示し、出力のフォーマットと品質を制御する
・ReActで推論とツール利用を組み合わせ、外部データを活用した回答を実現する
・Tree-of-Thoughtで複数のアプローチを比較し、最適な判断を導く
・Self-Consistencyで多数決による信頼性の高い回答を得る
・Structured Outputでプログラムが処理可能な形式の出力を確保する
まずはChain-of-Thoughtを日常的なプロンプトに取り入れるところから始めてみてください。「ステップバイステップで考えてください」の一言を追加するだけで、出力品質の変化を実感できるはずです。その上で、タスクの特性に応じて他のテクニックを組み合わせていきましょう。
関連記事
AIエージェント開発入門|自律型AIの仕組みと構築方法を解説【2026年版】
AI駆動コーディングワークフロー|Claude Code・Cursor・Copilotの実践的使い分け
APIレート制限の設計と実装|トークンバケット・スライディングウィンドウ解説
APIバージョニング戦略|URL・ヘッダー・クエリパラメータの使い分け
BIツール入門|Metabase・Redash・Looker Studioでデータ可視化する方法
チャットボット開発入門|LINE Bot・Slack Botの構築方法と活用事例
CI/CDパイプラインの基礎|継続的インテグレーション・デリバリーの全体像
クリーンコードの原則|可読性・保守性を高める7つの実践ルール