プロンプトエンジニアリング手法一覧｜Few-shot・CoT・ReActの違い

プロンプトエンジニアリングの手法は、「例を見せるか（Zero-shot／Few-shot）」「考える過程を書かせるか（CoT）」「複数回の結果をまとめるか（Self-Consistency）」「外部の情報を取りに行くか（ReAct）」「作業を分けるか（プロンプトチェーン）」「プロンプト自体を作らせるか（メタプロンプト）」の違いで整理できます。 名前は多くても、変えているのはこの6つの軸のどれかです。

この記事は、手法名から引ける逆引きカタログです。9つの手法を「目的・向く課題・手間・注意点」の比較表にまとめ、同じ課題（問い合わせ文の分類）を手法ごとに書き分けたコピペ用テンプレートを並べました。課題の種類から手法を選ぶ早見表と、推論・思考の機能を持つモデルでは「段階的に考えて」という指示の扱いが変わる点も、Anthropic・OpenAI・Google の公式ドキュメントの記載で整理しています。プロンプトの基本の書き方（役割・条件・出力形式など）は扱わず、手法の違いに絞ります。

確認環境：手法の定義は各手法の原論文の要旨（arXiv）、モデルごとの扱いは Anthropic・OpenAI・Google の公式ドキュメントを、いずれも 2026年10月5日に開いて確認しました。Self-Consistency の集計スクリプトは Python 3.11.15（Ubuntu 24.04）で実行した結果を載せています。この記事はテンプレート集で、モデルの回答例は載せていません。

プロンプトエンジニアリング手法の早見表

表計算ソフトに貼れるタブ区切り版です。

手法  目的  向く課題    手間  注意点
Zero-shot   例なしで指示だけで頼む 要約、翻訳、一般的な分類、下書き    小   出力の形がぶれるときは形式の指定か例を足す
Few-shot    入力と出力の例を見せて形をそろえる   独自の分類基準、決まった書式への変換、文体合わせ    中   例の偏りまでまねる。例の書式をそろえる
Zero-shot CoT   答えの前に考える過程を書かせる 計算、条件の多い判断、手順の組み立て  小   推論・思考の機能を持つモデルでは扱いが変わる
Few-shot CoT    考え方つきの例を見せる 判断の筋道まで決まっている審査・採点  大   例の考え方に引っぱられる
Self-Consistency    複数回の結果から多数決で選ぶ  答えが1つに決まる分類・計算・抽出   大   答えが1つに決まらない課題には向かない
Tree of Thoughts    複数の案を出し、評価して絞り込む    設計の案出し、計画、探索が必要な課題  大   評価の基準を先に決める
ReAct   考えることとツールでの調査・操作を交互に進める 最新情報や社内データの参照   大   ツールの実行結果を返す仕組みが要る
プロンプトチェーン   作業を分け、前の出力を次の入力にする  多段の処理、下書き→見直し→修正    中〜大 途中の出力の形を決めておく
メタプロンプト プロンプト自体をモデルに作らせる・直させる   プロンプトの下書きと改善    小〜中 自分のデータで試してから使う

課題の種類から手法を選ぶ早見表

迷ったら Zero-shot から始め、足りない点に合わせて1つずつ足すのが進めやすい順番です。OpenAI の公式ドキュメントも、推論モデルについて「まず Zero-shot を試し、必要なら Few-shot」と書いています。

手法どうしの違いを6つの軸で比べる

よく並べて語られる組み合わせの違いは次のとおりです。

同じ課題を手法ごとに書き分けたテンプレート

題材は、架空の社内備品予約システムに届いた問い合わせ文を「不具合／要望／使い方の質問」に分類する課題です。分類する文は共通で、次の1件を使います。

予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。

1. Zero-shot：指示だけで頼む

次の問い合わせ文を「不具合」「要望」「使い方の質問」のどれか1つに分類してください。

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

出力は分類名だけを1行で書いてください。

使いどころ：分類名が一般的で、基準を説明しなくても通じるとき。まずこの形で試し、結果がぶれる項目を見てから次の手法を足します。

2. Few-shot：入力と出力の例を見せる

問い合わせ文を「不具合」「要望」「使い方の質問」のどれか1つに分類してください。
例と同じ形式で、分類名だけを書いてください。

<examples>
<example>
<inquiry>予約ボタンを押すと画面が真っ白になります。</inquiry>
<label>不具合</label>
</example>
<example>
<inquiry>予約の一覧を CSV で出せるようにしてほしいです。</inquiry>
<label>要望</label>
</example>
<example>
<inquiry>繰り返しの予約はどこから登録できますか。</inquiry>
<label>使い方の質問</label>
</example>
<example>
<inquiry>予約の取り消しができません。やり方が違うのでしょうか。</inquiry>
<label>使い方の質問</label>
</example>
</examples>

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

使いどころ：独自の線引きがあるとき。4つ目の例のように、迷いやすい境目の例を入れると基準が伝わります。Anthropic の公式ドキュメントは、例は3〜5個、課題に近く、型に幅を持たせ、example タグで囲むことを勧めています。Google の公式ドキュメントは、例どうしの書式（タグ、空白、改行）をそろえること、例が多すぎると例に寄りすぎることがある点に触れています。

3. Zero-shot CoT：答えの前に考える過程を書かせる

次の問い合わせ文を「不具合」「要望」「使い方の質問」のどれか1つに分類してください。

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

答えを出す前に、次の順で検討した内容を書いてください。
1. 利用者が期待した動きと、実際の動き
2. 以前は期待どおりだったかどうか
3. 3つの分類それぞれに当てはまる点・当てはまらない点
最後に、分類名だけを <answer> タグの中に書いてください。

使いどころ：条件が重なる判断や計算。原論文（Kojima ら、2022）は、答えの前に「Let's think step by step」と添えるだけで推論課題の成績が上がることを示しました。最終回答をタグに入れさせると、考えた過程と答えを分けて取り出せます。この書き方は、Anthropic の公式ドキュメントが「思考の機能を切っているときの代わりの手段」として紹介しているものです。推論・思考の機能を持つモデルでの扱いは後の節にまとめます。

4. Few-shot CoT：考え方つきの例を見せる

問い合わせ文を「不具合」「要望」「使い方の質問」のどれか1つに分類してください。
例と同じ形式で、reasoning と label を書いてください。

<examples>
<example>
<inquiry>予約の取り消しができません。やり方が違うのでしょうか。</inquiry>
<reasoning>期待：取り消せる。実際：取り消せない。ただし以前はできたという記述がなく、本人も操作方法を尋ねている。まず手順の案内が必要。</reasoning>
<label>使い方の質問</label>
</example>
<example>
<inquiry>先週から、予約の確認メールが届かなくなりました。</inquiry>
<reasoning>期待：メールが届く。実際：届かない。「先週から」とあり、以前は動いていた機能が動かなくなっている。</reasoning>
<label>不具合</label>
</example>
<example>
<inquiry>予約の30分前に通知が来るとうれしいです。</inquiry>
<reasoning>今ある機能が動かないのではなく、新しい動きを求めている。</reasoning>
<label>要望</label>
</example>
</examples>

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

使いどころ：「以前は動いていたなら不具合」のように、判断の筋道そのものを伝えたいとき。Chain of Thought の原論文（Wei ら、2022）が示したのはこの形で、途中の推論を書いた例を数個見せる方法です。Anthropic の公式ドキュメントも、思考の機能と例示は併用でき、例を「問題・使う方法・期待する答え」の形で見せると考え方に反映されると書いています。

5. Self-Consistency：複数回の結果から多数決を取る

プロンプトは 3 か 4 をそのまま使い、同じプロンプトを別々の会話で複数回（例：5回）実行して、最終回答を集計します。原論文（Wang ら、2022）は、1回の結果だけを採るのではなく、多様な推論の道筋をサンプリングして最も一致した答えを選ぶ方法として提案しています。

集計は表計算でも手作業でもできます。次は Python で多数決を取り、一致の割合が低いものを人の確認に回すスクリプトです。

from collections import Counter


def majority(answers, min_ratio=0.6):
    """同じプロンプトを複数回実行して集めた最終回答から、多数決で1つを選ぶ。"""
    cleaned = [a.strip() for a in answers if a.strip()]
    counts = Counter(cleaned)
    top, n = counts.most_common(1)[0]
    ratio = n / len(cleaned)
    status = "採用" if ratio >= min_ratio else "人が確認"
    return top, n, len(cleaned), ratio, status, counts


if __name__ == "__main__":
    # 5回の実行で得た「分類」欄を手で写したもの（説明用の値）
    runs = {
        "問い合わせ1": ["不具合", "不具合", "不具合", "不具合", "不具合"],
        "問い合わせ2": ["要望", "使い方の質問", "要望", "要望", "要望"],
        "問い合わせ3": ["不具合", "使い方の質問", "要望", "不具合", "使い方の質問"],
    }
    for name, answers in runs.items():
        top, n, total, ratio, status, counts = majority(answers)
        print(f"{name}: {top}（{n}/{total}、{ratio:.0%}）→ {status}  内訳={dict(counts)}")

python3 vote.py の出力です（入力の値は集計の動きを示すために用意したもので、モデルの回答ではありません）。

問い合わせ1: 不具合（5/5、100%）→ 採用  内訳={'不具合': 5}
問い合わせ2: 要望（4/5、80%）→ 採用  内訳={'要望': 4, '使い方の質問': 1}
問い合わせ3: 不具合（2/5、40%）→ 人が確認  内訳={'不具合': 2, '使い方の質問': 2, '要望': 1}

使いどころ：答えが1つに決まり、取り違えの影響が大きい判定。一致の割合がそのまま確からしさの目安になるので、割れたものだけ人が見る、という分担ができます。実行回数ぶんの時間と利用量がかかる点が手間です。

6. Tree of Thoughts：案を出し、評価して絞る

分類のような答えが決まる課題より、案を比べる課題に向きます。ここでは題材を「この問い合わせへの対応方針を決める」に広げます。原論文（Yao ら、2023）は、途中の考えを単位として複数の道筋を検討し、自己評価しながら次の進み方を決める枠組みとして提案しています。1つのプロンプトにまとめた簡易版です。

次の問い合わせへの対応方針を決めます。

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

次の3段階で進めてください。
第1段階：対応方針の案を3つ出す（それぞれ2〜3行）。互いに違う方向の案にする。
第2段階：各案を次の基準で5点満点で評価し、表にする。
  - 利用者が早く困りごとから抜けられるか
  - 原因の特定に近づくか
  - 対応にかかる手間
第3段階：合計点が最も高い案を選び、その案を具体的な手順（番号つき）に展開する。
  2番目の案のうち取り入れられる点があれば加える。

使いどころ：設計や計画のように、最初の案に決め打ちしたくないとき。評価の基準を先に書くのが要点です。段階ごとに別のプロンプトに分けると、次のプロンプトチェーンの形になります。

7. ReAct：考えることとツールの利用を交互に進める

原論文（Yao ら、2022）は、推論の記録と課題に応じた行動を交互に生成させ、行動によって外部の知識源や環境から追加の情報を得る方法として提案しています。次は、ツールの実行を人が代行する、チャット画面でも使える形です。

あなたは備品予約システムの問い合わせ調査の担当です。
次の問い合わせを分類し、根拠を示してください。

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

使えるツール（実行は私が行い、結果を Observation として返します）
- search_manual(keyword)：利用マニュアルを検索する
- get_reservation(reservation_id)：予約1件の状態を取得する
- list_releases(days)：直近の日数ぶんのリリース内容を一覧にする

次の形式で1ステップずつ進め、Action を書いたらそこで止めてください。
Thought: いま分かっていることと、次に調べること
Action: ツール名(引数)

私が Observation を返したら、次の Thought と Action を書いてください。
十分な情報が集まったら、次の形式で終えてください。
Final Answer: 分類名／根拠にした Observation／担当者への申し送り
ツールの結果にないことは推測で書かず、「確認できていない点」として挙げてください。

使いどころ：マニュアルやデータを調べてからでないと決められない課題。API でモデルを使う場合は、各社のツール利用（Function calling）の機能がこの往復を受け持ちます。Anthropic の公式ドキュメントでは、モデルがツールの名前と引数を入れた tool_use ブロックを返し、アプリケーション側が実行して tool_result として結果を返し、モデルがそれを使って回答するか次のツールを呼ぶ、という流れで説明されています。

8. プロンプトチェーン：作業を分けて順につなぐ

前の出力を次の入力にします。3つのプロンプトに分けた例です。

【プロンプト1：事実の抽出】
次の問い合わせ文から、事実だけを取り出して JSON で返してください。
キー：expected（期待した動き）、actual（実際の動き）、since（いつからか。不明なら null）、target（対象の機能）

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

【プロンプト2：分類】
次の JSON は、問い合わせ文から取り出した事実です。
「不具合」「要望」「使い方の質問」のどれか1つに分類し、理由を1文で添えてください。
出力形式：{"label": "...", "reason": "..."}

<facts>
（プロンプト1の出力を貼る）
</facts>

【プロンプト3：返信の下書き】
次の事実と分類をもとに、問い合わせた人への返信の下書きを書いてください。
- 200字以内、です・ます調
- 分類が「不具合」なら、調査すること・追加で教えてほしいことを1つずつ入れる
- 事実にないことは書かない

<facts>
（プロンプト1の出力を貼る）
</facts>
<classification>
（プロンプト2の出力を貼る）
</classification>

使いどころ：一度に頼むと途中の工程が抜ける作業。Google の公式ドキュメントは、複数の手順からなる課題は手順ごとにプロンプトにして、前の出力を次の入力にする形を勧めています。Anthropic の公式ドキュメントは、途中の出力を確かめたいときや処理の流れを固定したいときに有効だとし、よく使う形として「下書きを作る→基準に照らして見直す→見直しをもとに直す」の自己修正を挙げています。

自己修正の型に使う見直し用のプロンプトです。

次の返信の下書きを、基準に照らして見直してください。直した文章はまだ書かないでください。

<draft>
（プロンプト3の出力を貼る）
</draft>

<criteria>
1. 事実にないことを書いていないか
2. 相手が次に何をすればよいかが分かるか
3. 200字以内か
</criteria>

基準ごとに「満たす／満たさない」と、満たさない場合は該当の箇所と直し方を表にしてください。

9. メタプロンプト：プロンプトを作らせる・直させる

あなたはプロンプトの設計者です。次の課題のためのプロンプトを作ってください。

<task>
社内の備品予約システムに届く問い合わせ文を「不具合」「要望」「使い方の質問」に分類する。
1日に50件ほどあり、担当者が結果を見て振り分ける。
</task>

<requirements>
- 分類の基準を、境目の扱いも含めて文章にする
- 入力と出力の例を4つ入れる（うち1つは境目の例）。例の書式はそろえる
- 出力は JSON（label、reason）にする
- 判断できない場合の出力（label を "要確認" にする）を決める
</requirements>

出力は次の2つに分けてください。
1. 完成したプロンプト（そのまま貼れる形）
2. このプロンプトを試すためのテスト用の問い合わせ文を6つ（期待する分類つき）
作る前に、基準を決めるうえで足りない情報があれば質問してください。

既存のプロンプトを直させる形です。

次のプロンプトを改善してください。

<current_prompt>
（今のプロンプトを貼る）
</current_prompt>

<problems>
（うまくいかなかった入力と、そのときの出力、本来ほしかった出力を貼る）
</problems>

1. 今のプロンプトのどの記述が、その出力につながったと考えられるか
2. 直したプロンプト（変更した箇所が分かるように）
3. 変更によって、これまでうまくいっていた入力に影響が出ないかの確認方法

使いどころ：新しい課題の最初の一歩と、既存プロンプトの手直し。OpenAI の公式ドキュメントは、課題の説明からよいプロンプトを作ったり既存のものを改善したりするようモデルに指示するものをメタプロンプトと呼び、Playground の Generate ボタンで使っていると説明しています。作らせたプロンプトは、テスト用の入力で試してから使います。

推論・思考の機能を持つモデルでの書き方の違い

答える前にモデルが内部で推論する機能（OpenAI の推論モデル、Anthropic の拡張思考・適応型の思考、Google の思考機能）を持つモデルでは、CoT のように「段階的に考えて」と書く指示の扱いが変わります。 各社の公式ドキュメントの記載を並べます。

「—」は、今回開いたページにその項目の記載が見当たらなかったことを表します。

この表から、手法ごとの扱いを次のように整理できます。

Zero-shot CoT のテンプレート（3番）を推論・思考の機能を持つモデル向けに書き直すと、次の形になります。

次の問い合わせ文を「不具合」「要望」「使い方の質問」のどれか1つに分類してください。

<inquiry>
予約した会議室のプロジェクターを当日キャンセルしたのに、一覧に残ったままです。昨日までは消えていました。
</inquiry>

判断の基準
- 以前は期待どおりに動いていた機能が、同じ操作で動かなくなっていれば「不具合」
- 今ない動きを求めていれば「要望」
- 操作の方法を尋ねていれば「使い方の質問」
- 2つ以上に当てはまる場合は、上に書いた基準を優先する

出力形式
label: 分類名
reason: 根拠にした問い合わせ文の語句を引用して、1〜2文で

手順を指定する代わりに基準と出力の形を書き、考える過程はモデルに任せています。

手法を組み合わせるときの順番

一度に全部を入れず、足した手法ごとに同じテスト用の入力で結果を比べると、どの手法が効いたかが分かります。

よくある質問

Q. Few-shot の例はいくつ入れればよいですか？ A. Anthropic の公式ドキュメントは3〜5個を勧めています。Google の公式ドキュメントは、数個の例でパターンをつかめることが多いが最適な数は試して決めること、多すぎると例に寄りすぎることがあると書いています。境目の例を1つ以上含め、書式をそろえるのが要点です。

Q. CoT と ReAct はどう違いますか？ A. CoT は、モデルが持っている知識と与えられた入力だけで、考える過程を書きながら答えます。ReAct は、考えた結果として検索やデータ取得などのツールを使い、返ってきた結果を見てからまた考えます。外部の情報が要るかどうかで選びます。

Q. 「ステップバイステップで考えて」は、今も書いたほうがよいですか？ A. 使うモデルによります。OpenAI は推論モデルについてこの種の指示は不要としており、Google も思考機能を持つモデルでは回答に手順を書き出させる必要は基本的にないとしています。Anthropic は、思考の機能を使わないときの代わりの手段として紹介しています。推論・思考の機能を持つモデルでは、手順よりも判断の基準と成功の条件を書くほうが合っています。

Q. Self-Consistency は何回実行すればよいですか？ A. 決まった回数はありません。多数決が成り立つ奇数回（3回や5回）から始め、結果が割れる入力が多ければ、回数を増やす前にプロンプトの基準や例を見直します。

まとめ

• 手法の違いは、例の有無・考える過程・実行回数・外部ツール・作業の分割・プロンプトを書く人の6つの軸で整理できる
• Zero-shot から始め、形がぶれたら Few-shot、判断がぶれたら CoT や Self-Consistency、工程が長ければプロンプトチェーンを足す
• CoT はモデルの中で考える、ReAct はツールを使って調べながら考える。外部の情報が要るかで選ぶ
• Self-Consistency は一致の割合が確からしさの目安。割れたものだけ人が確認する
• 推論・思考の機能を持つモデルでは、「段階的に考えて」より、基準・制約・成功の条件を書く
• メタプロンプトで作ったプロンプトは、テスト用の入力で試してから使う

参考・出典

• Anthropic「Prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Anthropic「Tool use with Claude」 https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
• OpenAI「Prompt engineering」 https://developers.openai.com/api/docs/guides/prompt-engineering
• OpenAI「Reasoning best practices」 https://developers.openai.com/api/docs/guides/reasoning-best-practices
• OpenAI「Prompt generation」 https://developers.openai.com/api/docs/guides/prompt-generation
• Google「Prompt design strategies」 https://ai.google.dev/gemini-api/docs/prompting-strategies
• Wei et al.「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」（2022） https://arxiv.org/abs/2201.11903
• Kojima et al.「Large Language Models are Zero-Shot Reasoners」（2022） https://arxiv.org/abs/2205.11916
• Wang et al.「Self-Consistency Improves Chain of Thought Reasoning in Language Models」（2022） https://arxiv.org/abs/2203.11171
• Yao et al.「ReAct: Synergizing Reasoning and Acting in Language Models」（2022） https://arxiv.org/abs/2210.03629
• Yao et al.「Tree of Thoughts: Deliberate Problem Solving with Large Language Models」（2023） https://arxiv.org/abs/2305.10601

（いずれも 2026年10月5日に閲覧）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。