blog
AIブログ
プロンプトエンジニアリング 比較|2026年版ガイド
プロンプトエンジニアリングには、Zero-Shot、Few-Shot、Chain-of-Thought、ReActなど数十種類の手法が存在します。「どの手法を選べばよいかわからない」「手法ごとの違いや適切な使い所が整理できていない」——そんな悩みを抱えるエンジニアや研究者は多いはずです。本記事では、主要なプロンプトエンジニアリング手法を網羅的に比較・解説します。各手法の仕組み、強み・弱み、最適なユースケース、そして実際のプロンプト例まで一気通貫で整理しているので、目的に合った手法をすぐに選べる実践的なリファレンスとしてご活用ください。
プロンプトエンジニアリングとは何か——比較の前提知識
プロンプトエンジニアリングとは、大規模言語モデル(LLM)に対して「どのような指示(プロンプト)を与えるか」を体系的に設計・最適化する技術領域です。モデルのパラメータ(重み)を変更せずに、入力テキストの構造・内容・文脈を工夫するだけでモデルの出力品質を劇的に改善できる点が最大の特徴です。
モデルファインチューニングがコスト・時間・データ量の面でハードルが高いのに対し、プロンプトエンジニアリングはゼロコストで試行錯誤できます。一方で、手法の選択を誤るとハルシネーション(事実と異なる内容の生成)や一貫性のない出力が多発します。適切な手法を選ぶためには、各手法の原理を正確に理解することが不可欠です。
比較軸の整理
各手法を比較するうえで、以下の軸を共通指標として使用します。
- 必要なサンプル数:プロンプト内に含めるデモンストレーション例の数
- 推論精度:複雑な論理・数学・多段階タスクでの正答率
- トークンコスト:プロンプト長に起因するAPI利用コストへの影響
- 実装難易度:プロンプト設計のシンプルさ
- 最適なユースケース:どのようなタスクに向いているか
主要手法の一覧比較表
まず全体像を俯瞰するために、主要10手法を一覧表で比較します。
| 手法名 | 必要なサンプル数 | 推論精度(複雑タスク) | トークンコスト | 実装難易度 | 主なユースケース |
|---|---|---|---|---|---|
| Zero-Shot | 0件 | 低〜中 | 最小 | ★☆☆☆☆ | 汎用テキスト生成、分類 |
| Few-Shot | 3〜10件 | 中 | 中 | ★★☆☆☆ | パターン学習、スタイル統一 |
| Chain-of-Thought (CoT) | 0〜数件 | 高 | 中〜高 | ★★☆☆☆ | 数学・論理推論、多段階問題 |
| Zero-Shot CoT | 0件 | 中〜高 | 中 | ★☆☆☆☆ | 簡易な推論強化 |
| Self-Consistency | 数件 | 非常に高 | 高 | ★★★☆☆ | 高精度が必要な推論タスク |
| Tree of Thoughts (ToT) | 0〜数件 | 非常に高 | 非常に高 | ★★★★☆ | 探索・計画・パズル系タスク |
| ReAct | 数件 | 高(外部情報活用時) | 高 | ★★★☆☆ | ツール連携・エージェント |
| Role Prompting | 0件 | 中(ドメイン依存) | 低〜中 | ★☆☆☆☆ | 専門家口調の出力、ライティング |
| Least-to-Most | 数件 | 高(段階的分解) | 中〜高 | ★★★☆☆ | 複合問題の段階的解決 |
| Automatic Prompt Optimization (APO) | 多数(自動) | 高 | 高(最適化フェーズ) | ★★★★☆ | 大規模本番運用・反復改善 |
Zero-Shot プロンプティング
Zero-Shotは、サンプル例を一切与えずに指示だけでモデルに回答させる最もシンプルな手法です。GPT-4やClaude 3などの大規模モデルが大量のテキストで事前学習されているため、例示がなくても多くの汎用タスクを処理できます。
特徴と限界
トークン数が少なく、APIコストを最小化できるメリットがあります。一方、タスクが高度に専門的であったり、特定のフォーマットを厳密に守る必要があったりする場合は出力ブレが大きくなります。また、多段階の論理推論が必要なタスクでは誤答率が上がります。
プロンプト例
レビュー:「配送は早かったですが、商品の品質はイマイチでした。」
分類:
向いているタスク
- 要約・翻訳・言い換えなど汎用テキスト処理
- 単純な分類・ラベリング
- コスト制約が厳しい大量バッチ処理
Few-Shot プロンプティング
Few-Shotは、プロンプト内に「入力→期待する出力」のデモンストレーション例を複数含める手法です。2020年のGPT-3論文(Brown et al.)で広く知られるようになりました。モデルは例から出力パターン・スタイル・フォーマットを学習し、新しい入力に適用します。
サンプル数の目安
一般的には3〜8件が効果的とされています。サンプルが少なすぎると学習効果が低く、多すぎるとコンテキストウィンドウを圧迫します。また、サンプルの質と多様性が量よりも重要です。偏ったサンプルを与えると、モデルの出力も偏ります。
プロンプト例
入力:「今日は最悪だった」 → 感情:ネガティブ
入力:「明日は晴れらしい」 → 感情:中立
入力:「また失敗してしまった」 → 感情:
向いているタスク
- 特定のライティングスタイル・トーンを統一したい場合
- カスタムフォーマット(JSON出力、特定テンプレートなど)の強制
- 専門ドメインの分類・抽出タスク
Chain-of-Thought(CoT)プロンプティング
CoTは、最終回答に至るまでの「推論ステップ」を明示的に出力させる手法です。Wei et al.(2022)が発表し、特に算術・常識推論・シンボリック推論で大幅な精度向上を示しました。Few-Shot CoTでは推論ステップ付きの例をサンプルとして与え、Zero-Shot CoTでは「ステップ・バイ・ステップで考えてください」という一文を追加するだけで推論を誘導します。

なぜ精度が上がるのか
LLMは自己回帰的に次のトークンを予測します。推論ステップを中間出力として生成させることで、各ステップが次のステップの正確な文脈となり、複雑な問題での誤答連鎖を防ぐ効果があります。これは人間が難問を解くときに「まず整理してから答える」のと本質的に同じです。
プロンプト例(Zero-Shot CoT)
ステップ・バイ・ステップで考えてください。
向いているタスク
- 算数・数学・論理パズル
- 多段階の条件分岐を含む問題
- 因果関係の説明が必要なタスク
Self-Consistency(自己整合性サンプリング)
Self-Consistencyは、同一プロンプトに対してCoTを複数回実行(通常5〜40回)し、最も多く得られた答えを最終回答とするアンサンブル手法です。Wang et al.(2022)が提案しました。
仕組みの図解
(最終出力)
コストと精度のトレードオフ
Self-Consistencyは推論精度を大幅に向上させますが、APIコールが5〜40倍になります。精度最優先の本番タスク(医療・法律・金融分野のQAなど)に適しており、コスト効率が優先される用途には不向きです。
Tree of Thoughts(ToT)
ToTはYao et al.(2023)が提案した手法で、問題解決の思考空間をツリー構造として探索します。CoTが一本道の推論チェーンであるのに対し、ToTは各推論ステップで複数の候補を生成し、それぞれを評価・選択しながら最適パスを探索します。
CoTとToTの構造比較
↓
ステップ1
↓
ステップ2
↓
ステップ3
↓
答え
↓
候補A ✓
候補B ✗
候補C ✗
↓(Aを選択)
候補A1 ✓
候補A2 ✗
↓
最適解
実装上の注意点
ToTはAPIコールが指数的に増加するため、実装にはLangChainなどのフレームワークや独自オーケストレーションが必要です。計算コストが高いため、24手のチェスや複雑なパズル解決など「探索空間が広く、評価基準が明確なタスク」に限定して使うのが現実的です。
ReAct(Reasoning + Acting)
ReActはYao et al.(2022)が提案した手法で、「推論(Reasoning)」と「行動(Acting)」を交互に繰り返すフレームワークです。LLMが外部ツール(検索エンジン、コード実行環境、データベースなど)を呼び出しながら問題を解決します。
ReActの処理フロー
→
「まず◯◯を調べよう」
→
検索ツールを呼び出す
→
検索結果を受け取る
→
結果を踏まえて判断
→
向いているタスク
- 最新情報を参照するリサーチタスク(RAGとの組み合わせ)
- コード生成・実行・デバッグを繰り返すエージェント
- 複数APIを横断して情報を統合するワークフロー
ReActはLangChainのAgentExecutorやOpenAI Function Callingと組み合わせることで、実用的なAIエージェントの基盤として機能します。クリスタルメソッドのバーチャルヒューマン実装においても、外部知識ベースとリアルタイム対話を組み合わせるシーンでReActの設計思想を活用しています。
Role Prompting(ロールプロンプティング)
モデルに「あなたは◯◯の専門家です」とペルソナを割り当てる手法です。シンプルですが、出力のトーン・専門性・スタイルを制御するうえで効果的です。
効果的なロール定義の要素
- 専門性の明示:「20年のキャリアを持つ外科医」「PythonのコアデベロッパーでPEP策定経験あり」など具体的に
- 聴衆の定義:「IT知識のない経営者向けに説明してください」と読者層を指定
- 制約の付加:「専門用語を使う場合は必ず平易な言い換えを括弧内に加えてください」
注意点
Role Promptingはハルシネーションのリスクを下げるわけではありません。専門家ロールを与えたとしても、モデルが持っていない知識は生成されず、むしろ自信を持った誤答が増えるリスクがあります。重要な専門知識を要するタスクでは、RAGや外部ツール連携と組み合わせることが推奨されます。
Least-to-Most プロンプティング
Zhou et al.(2022)が提案した手法で、複雑な問題を小問に分解し、簡単な小問から順番に解いていく段階的アプローチです。前のステップの答えを後のステップに引き継ぐため、長い依存チェーンを持つ問題に有効です。
CoTとの違い
CoTは一つのプロンプト内で推論を展開しますが、Least-to-Mostは「問題の分解フェーズ」と「各小問の解答フェーズ」を明示的に分離します。前の答えを文脈として引き継ぐため、長い推論チェーンでの誤差蓄積を抑えられます。特に、長文の算数文章題や段階的な証明問題で顕著な精度改善が報告されています。
Automatic Prompt Optimization(APO)
APOは人手でプロンプトを設計するのではなく、アルゴリズム(遺伝的アルゴリズム、強化学習、LLM自体を最適化器として使うAuto-Promptなど)によってプロンプトを自動改善する手法群の総称です。
代表的なアプローチ
- DSPy(Stanford):モジュール型プログラミングでプロンプトとモデル呼び出しを宣言的に記述し、最適化を自動化
- OPRO(Google DeepMind):LLM自身を最適化器として使い、過去の試行錯誤を踏まえてより良いプロンプトを生成
- AutoPrompt:勾配ベースの探索でトークン列を最適化(主にBERT系モデル向け)
向いているシーン
テスト用のゴールドラベルデータが100件以上確保でき、本番運用で継続的に品質を改善したい場合に適しています。初期投資(最適化コスト)が高いため、PoC段階よりも大規模サービス展開時に威力を発揮します。
手法選択のデシジョンツリー
実務でどの手法を選ぶかは、タスクの性質・コスト制約・精度要件によって決まります。以下のフロー図を参考にしてください。
→ はい:Zero-Shot(または Zero-Shot CoT で少し精度UP)
→ いいえ:Q2へ
→ はい:Q3へ
→ いいえ:Q4へ
→ はい(探索が必要):Tree of Thoughts
→ はい(並列可):Self-Consistency + CoT
→ 普通でよい:Few-Shot CoT または Least-to-Most
→ はい:ReAct(エージェント設計)
→ いいえ:Q5へ
→ はい:Few-Shot(スタイルサンプル付き)
→ 専門家トーンだけでよい:Role Prompting
→ 大規模本番で自動改善したい:APO(DSPyなど)
組み合わせ活用パターン
現実の本番環境では、単一手法ではなく複数手法を組み合わせることで最大の効果が得られます。代表的な組み合わせパターンを紹介します。
| 組み合わせパターン | 構成 | 効果 | 主な用途 |
|---|---|---|---|
| Role + Few-Shot + CoT | ペルソナ設定 + 例示 + 推論ステップ指示 | スタイル統一と精度の両立 | 法律・医療ドメインのQ&A |
| RAG + ReAct | 外部知識ベース参照 + 行動ループ | 最新・専門知識の活用 | 社内文書検索エージェント |
| CoT + Self-Consistency | 推論ステップ + 多数決 | 高精度な最終回答 | 数学・科学的推論 |
| Least-to-Most + CoT | 問題分解 + 各ステップでの推論明示 | 複合問題の確実な解決 | 複雑な要件分析・プランニング |
| APO + Few-Shot | 自動最適化でサンプル選定と順序を改善 | 人手設計より高性能なプロンプト | 大規模サービスの継続改善 |
プロンプト品質を高める共通原則
手法の選択に加えて、どの手法においても共通して守るべき設計原則があります。
- タスクの明確な定義:「良い回答とは何か」をプロンプト内で定義する。評価基準が曖昧だとモデルも迷う。
- 否定表現より肯定表現:「〜しないでください」より「〜してください」の方が指示に従いやすい傾向がある。
- 区切り文字の活用:入力データと指示を「###」「“`」「—」などで明確に分離し、混乱を防ぐ。
- 出力フォーマットの明示:「JSON形式で返してください」「箇条書き3点で答えてください」と構造を指定する。
- イテレーティブな改善:一発完成を目指さず、小さな変更を一つずつ加えてA/Bテスト的に評価する。
- 温度パラメータとの連携:CoT・ToTでは温度を高め(0.7〜1.0)、分類・抽出では低め(0〜0.3)に設定すると安定する。

モデル別の手法相性
手法の効果はLLMの種類・規模によっても異なります。以下はあくまで傾向の整理であり、最終的には実測による検証が必要です。
| LLM | Zero-Shot | CoT | Few-Shot | ReAct | ToT |
|---|---|---|---|---|---|
| GPT-4o / GPT-4.1 | ◎ | ◎ | ◎ | ◎ | ◎ |
| Claude 3.5 / 3.7 Sonnet | ◎ | ◎ | ◎ | ○ | ○ |
| Gemini 1.5 Pro / 2.0 | ◎ | ◎ | ◎ | ○ | ○ |
| Llama 3.1 70B(OSS) | ○ | ○ | ○ | △ | △ |
| 小規模モデル(〜13B) | △ | △(効果薄) | ○ | ✕ | ✕ |
CoTは小規模モデル(概ね100B以下)では効果が限定的または逆効果になる場合があることが複数の研究で示されています(Wei et al. 2022)。小規模モデルではFew-Shotでの例示の方が安定した効果をもたらします。
まとめ
プロンプトエンジニアリングの手法は、Zero-Shotのような最シンプルなものから、Tree of ThoughtsやAPOのような高度な探索・最適化手法まで幅広く存在します。重要なのは「万能な手法は存在しない」という認識です。
- コスト優先・汎用タスク → Zero-Shot / Zero-Shot CoT
- フォーマット統一・スタイル制御 → Few-Shot
- 論理推論・数学 → Few-Shot CoT / Self-Consistency
- 探索・計画が必要な複雑タスク → Tree of Thoughts
- 外部ツール連携・エージェント → ReAct
- 大規模本番・継続改善 → APO(DSPyなど)
実務では手法を組み合わせ、評価データに基づいてイテレーティブに改善することが成功の鍵です。まず自分のタスクに最も近い手法を一つ選んでベースラインを作り、そこから体系的に改善を加えていくアプローチを推奨します。プロンプトエンジニアリングは「設計→評価→改善」のサイクルを高速に回す実験的プロセスです。本記事の比較を出発点として、ぜひ自社タスクに最適な手法を見つけてください。
関連記事
監修
河合 継(クリスタルメソッド株式会社 代表取締役)
AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について | 編集方針
Study about AI
AIについて学ぶ
-
SakuraSpeech(サクラスピーチ)|日本語特化のAI音声合成 – ブラウザ・API・完全オフライン対応【2026年版】
SakuraSpeech(サクラスピーチ)は、入力したテキストを自然で表情ゆたかな日本語音声に変換する、日本語特化のAI音声合成(TTS:Text-to-Spe...
-
GPT-5.5 Claude エージェント ベンチマーク選定——日本企業が問い直すべき評価軸
GPT-5.5がClaude Fable 5を上回った——「Agents’ Last Exam」とは何か 2026年6月、AIエージェント評価の文脈...
-
米上院 金融AI 規制 公聴会——日本の銀行・証券への実務的示唆
上院 金融AI 規制 公聴会の要点——何が、なぜ今議題に上ったか 2026年6月11日午前10時(米東部夏時間)、米上院銀行・住宅・都市問題委員会(U.S. S...