メインコンテンツまでスキップ

名前のあるテクニック、その評定

中級
What you'll learn
  • 有名な各プロンプティングテクニックが実際には何だったのかを1行で把握する
  • いまやモデルが代わりにやってくれるものと、ハーネスがやってくれるものを見分ける
  • 公式のベンダーガイダンスが現在は積極的に非推奨としている3つのテクニック
  • ベンダーが公然と意見を異にしている箇所 — そして自分のワークロードでそれを決着させる方法

プロンプトエンジニアリングのガイドをほとんど何でも開けば、名前のあるテクニックの一覧が出てきます。Chain-of-Thought、Tree of Thoughts、Self-Consistency、ReAct、Reflexion、Least-to-Most。そのほぼすべてが2022年から2023年の間に発表されたもので、対象はそうさせなければ推論できなかったモデルでした。

その制約はもうありません。今日のフロンティアモデルは回答前に内部で推論し、エージェントハーネスは自らツールをループで回します。つまりそれらのテクニックの多くは反証されたのではなく、モデルの中かハーネスの中へと吸収されたのです。いくつかは今では完全な自爆装置になっています。

このページでは一つずつ名前を挙げ、何のためのものだったのかを述べ、評定を下します。

変わったのはただ1つ​

以下のすべての評定は、同じ転換に行き着きます。推論があなたのプロンプトから、モデル自身のフォワードパスへ移ったのです。主要3ベンダーはいずれも、自社のドキュメントでそう述べています。

ベンダー現行ガイダンスの記述
Anthropic拡張思考は「構造化された推論を自動化する」もので、利用できる場合は「一般に手動のchain of thoughtプロンプティングより望ましい」。
OpenAI「chain-of-thoughtプロンプトは避けること: これらのモデルは内部で推論を行うため、『ステップバイステップで考えて』や『推論を説明して』と促すのは不要です。」
Google「Gemini 2.5に推論を強制するために複雑なプロンプトエンジニアリング（chain of thoughtなど）」を使っていたなら、代わりにモデルのthinking levelを使うこと。

評定の表​

テクニック何だったのか評定
明確で具体的な指示目標、対象読者、形式、制約を述べる✅ いまも本質そのもの
出力コントラクト「JSONだけを返して」／厳密なかたち✅ いまも必須
プロンプトチェイニング／分解難しい1つのタスクを複数の呼び出しに分ける✅ いまも必須
棄権の許可「推測せず、わからないと言って」✅ いまも必須
文脈＋動機制約がなぜ重要なのかを説明する✅ 価値が上がった
メタプロンプティング／APEモデルにプロンプトを書かせる・改善させる✅ 過小評価されているが健在
Chain-of-Thought回答前に「ステップバイステップで考えて」🔁 モデルの中へ移った
Least-to-Most簡単な部分問題から順に解く🔁 モデルの中へ移った
ReActThought: / Action: / Observation: を交互に出させる🔁 ハーネスの中へ移った
Reflexion自己批評し、その教訓を保持して再挑戦する🔁 メモリレイヤーへ移った
Tree of Thoughts部分解を分岐・評価・バックトラックする🔁 ハーネスの中へ移った
Few-shotの例示3〜5個の模範例を見せる⚠️ 議論中 — ベンダー間で見解が異なる
ロール／ペルソナ「あなたは20年の経験を持つ上級税務弁護士です…」⚠️ 格下げ、薄い版だけ残す
Self-ConsistencyN個の回答をサンプリングして多数決⚠️ 状況次第、N倍の代価を払うこと
重厚なXMLスキャフォールディングすべてのプロンプトのすべての部分にタグを付ける⚠️ いまは任意、デフォルトではない
Graph of Thoughts推論ステップの任意のグラフ🧪 研究段階、推奨するベンダーはない
Temperatureのチューニング創造性を上げ下げする⛔ 現行モデルでは明確に却下
感情的圧力／チップの提示「これは私のキャリアにとって非常に重要です」⛔ 現行のベンダーガイドで支持するものはない
指示の繰り返し／全部大文字3回、大声で言う⛔ 引退

このページの残りでは、興味深い行を解説します。

モデルの中へ移った​

Chain-of-Thought​

Wei et al. (2022)は、中間の推論ステップを出力するよう促されたモデルが、数学や論理の問題をはるかに多く解けることを示しました。続いてKojima et al. (2022)は、その効果の大半が5語 — 「Let's think step by step」 — で引き出せることを見つけました。4年間、これはプロンプティングにおける単独で最もレバレッジの高い技でした。

フロンティアモデルはいまやそれを促されずに行い、しかもあなたがプロンプト内の文章ではなくeffortやthinking levelを通じて制御する予算をそれに費やします。思考とEffortとEffortのチューニングを参照してください。

つまりその指示はもう無料ではありません。トークンを消費し、本来の指示と並んでモデルが従わなければならない指示を1つ増やし、思考モデルでは推論を目に見える回答の中へ押し出しかねません — まさに入れたくなかった場所です。

2023年の習慣 — これを持ち越さないこと

You are an expert mathematician with 20 years of experience. This is very
important to my career, so please take a deep breath and work through this
step by step, explaining your reasoning carefully before giving the final
answer. Let's think step by step.

Are there infinitely many primes p with p mod 4 == 3?

2026年版 — 同じ問い、無駄なし

Are there infinitely many primes p with p mod 4 == 3?

Give the proof sketch, then the one-line answer. If the result is open, say so.

2つ目のプロンプトはより短く、モデルが本来の依頼とすり合わせなければならない指示を含まず、予算を語りではなく証明に費やします。推論の深さは言葉づかいではなく、リクエストのeffort設定から来ます。

手動のChain-of-Thoughtを残すべきとき: 思考モードのない小型モデルやローカルモデルを使っている場合（モデルをローカルで動かすを参照）、あるいは人間が監査するために推論を目に見える出力の中にどうしても必要とする場合。

Least-to-Most​

Zhou et al. (2022) — モデルに部分問題を列挙させ、それを順に解かせる。Chain-of-Thoughtと同じ話です。これは計画であり、計画は思考モデルが自分で最初にやることになりました。複数の呼び出しに作業を分解するときの人間側の習慣としてはいまも有用で、それはつまりプロンプトチェイニングです。

ハーネスの中へ移った​

ReAct​

Yao et al. (2022)は、モデルに固定形式のThought: / Action: / Observation:テキストを出力させ、それを正規表現でパースすることで、推論とツール呼び出しを交互に行わせました。

この説明をもう一度読んでください。これはツール呼び出しのないAPIに対するテキストプロトコルの回避策です。いまのAPIにはツール呼び出しがあります。ネイティブなツール使用と、ツール呼び出しの合間の思考が、そのままReActです — プロバイダーによって実装され、型チェックされ、ストリーミングされます。2026年に自前でテキストプロトコルを組むのは、余計なコロン1つで壊れうるパーサーを再導入することです。

ReActから残す価値があるもの: モデルは次のツールを選ぶ前にツールの結果について考えられるべきだという洞察。それはもうプロンプトではなく、プラットフォームの機能です。

Tree of Thoughts​

Yao et al. (2023)はChain-of-Thoughtを探索へ一般化しました。候補となる次の手を複数生成し、スコアを付け、有望な分岐を残し、行き止まりからバックトラックする。

プロンプトとして（「3つのアプローチを並行して検討し、それから選んで」）は弱いものです。1つのコンテキストウィンドウの中で1つのモデルが探索木を演じても、だいたい似通った3つの段落と自信ありげな選択が出てくるだけです。アーキテクチャとしては、別の名前のもとで繁栄しています。

これは分岐を実際の並列エージェントとし、評価器を実際の採点ステップとしたTree of Thoughtsです。サブエージェントやエージェントチームで構築し、評価（evals）で採点しましょう — 巧みな1段落ではなく。

Reflexion​

Shinn et al. (2023)は、失敗した試行のあとにエージェントに短い言語による振り返りを書かせ、そのメモを次の試行へ持ち越させました — 重みに触れずに学習させたのです。

発想は正しく、そして勝ちました。ただプロンプトの中に住むのをやめただけです。いまはメモリレイヤーに住んでいます。メモリとコンテキスト編集およびマネージドなエージェントメモリストアを参照してください。「失敗を振り返って」の現代版は、コンパクションを生き延びる永続ストアに教訓を書き込むエージェントです。

安い版は手作業で今もやる価値があります: 悪い実行のあと、プロンプトやツールセットの何が誤誘導したのかをモデルに尋ね、それを直しましょう。振り返りの成果物は、次のターンではなくシステムプロンプトに置くべきものです。

Graph of Thoughts​

Besta et al. (2023)は木を任意のグラフに置き換えました — 分岐を統合し、ノードをその場で洗練し、ループさせる。本当に興味深い研究ですが、推奨するベンダーはなく、主要なハーネスも実装しておらず、トークンコストは残酷です。名前は知っておき、何かが変わるまで、その上に構築はしないこと。

議論中: few-shotの例示​

これは正直に扱うべき項目です。3つのベンダーは、まさに現在、3つの異なる答えを文書で示しています。

ベンダー例示に関するガイダンス
OpenAI「まずzero shotを試す… 推論モデルは良い結果を出すのにfew-shotの例示をあまり必要としない。」
Anthropic「1つの例（one-shot）から始める。出力がまだ望みどおりでない場合にのみ、例を追加（few-shot）する。」
Google「few-shotの例示がないプロンプトは効果が低くなりやすい」 — そして常に含めることを推奨。

これを、好きなベンダーを選ぶことで解決しないでください。この不一致は本物で、これらのモデルの訓練方法の実際の違いを反映しています。解決は自分のタスクでのアブレーションで行いましょう — 20分の作業で、誰のアドバイスにも勝ります。このページのものも含めて。

Guided walkthrough1 of 6
  1. 正解がわかっている実際の入力を20件集めます。3件ではありません — 3件では15%の変化とノイズを区別できません。/docs/foundations/evals を参照。

名前を挙げるに値する失敗モード: 例が多すぎるとパターンロックが起きます。別のかたちを必要とする入力に対してまで、モデルが例の表面的なかたちを再生産してしまう現象です。出力が奇妙に画一的に見えるなら、指示を追加する前に例を削りましょう。詳しくはFew-Shotを正しくやる。

格下げ: ロールとペルソナ​

「あなたは一流事務所で20年の経験を持つ世界水準の上級税務弁護士です」は標準的な作法でした。Anthropicの現行ガイダンスはもっと率直です。「過度に具体的なロールはAIの有用性を制限しうる。」

ロールの有用な部分は、そもそも経歴ではありませんでした — 語彙と対象読者です。それを残し、履歴書は捨てましょう。

  • ⛔ 「あなたはバグを書いたことがない伝説の10倍エンジニアです。」
  • ✅ 「Lambdaで動くPython 3.12のサービスという前提でこれをレビューして。並行コールドスタート下で壊れそうなものを指摘して。」

2つ目はモデルが知らなかったことを伝えています。1つ目は自信を持てと伝えており、それはレビュアーに求めるものの正反対です。システムプロンプトとロールを参照してください。

状況次第: self-consistency​

Wang et al. (2022) — 同じ質問をN回サンプリングして多数派の答えを取る。これは機能しますし、いまも機能します。問題は請求額です。1つの答えのためにN倍のトークンとN倍のレイテンシがかかります。

フロンティアモデルでは、1回の呼び出しのeffortや思考予算を上げる方が、安い呼び出し3回＋投票よりもトークンあたりの精度を稼げるのが通常です。Self-Consistencyがいまも正しい道具であるのは次の場合です。

  • 答えが短く検証可能（数値、ラベル、はい/いいえ）で、投票が明確に定義できる。
  • 安価なモデルやローカルモデルを使っていて、3回の呼び出しでもフロンティアモデル1回より安い。
  • 確信度のシグナルが必要 — 3対0と2対1は別のことを伝えており、それを他の方法で得るのは難しい。

エッセイ、コード、そして「多数派」が意味を持たないものには不適切な道具です。

引退​

  • Temperatureのチューニング。 単に非推奨なのではなく、却下されています。現行のフロンティアClaudeモデルでは、デフォルト以外のtemperature、top_p、top_kはすべてのリクエストで400エラーを返します。Googleは全Gemini 3モデルについて「temperatureパラメータはデフォルト値の1.0に保つことを強く推奨」しており、下げると「ループや性能劣化といった予期しない挙動につながる可能性がある」と警告しています。挙動はプロンプトとeffort設定で形づくりましょう。どのモデルがどのノブを公開しているかは動く標的です。モデルと価格とサンプリング制御を確認してください。
  • 感情的圧力。 Li et al. (2023)は2023年当時のモデルで「これは私のキャリアにとって非常に重要です」による向上を実際に測定しており、チップを提示する変種も広く流布しました。現行のベンダーガイドでどちらかを推奨するものはありません。測定された効果は、それが測定されたモデルの性質であって、プロンプティングの法則ではないと捉えましょう — そしてフロンティアモデルでの再現を誰も公表していないことにも留意してください。
  • 指示の繰り返しと全部大文字。 長いプロンプトの中盤から指示を取りこぼすモデルへの念入りな保険でした。非常に長い文書のあとで依頼を言い直すのはいまも妥当です（長いコンテキスト）。200トークンのプロンプトで3回言うのは、コンテキストを浪費し、解決すべき矛盾を生むだけです。
  • アシスタントターンのプレフィル。 かつてはClaudeに出力形式を強制する確実な方法でした。引退 — 現行モデルは最終アシスタントターンがプレフィルされていると400を返します。出力コントラクトか構造化出力を使いましょう。

任意のテクニックをどう判断するか​

このページ全体がその図に圧縮されます。名前のあるテクニックとは、ある能力がどこに住まなければならないかについての仮説です — プロンプトの中か、モデルの中か、ハーネスの中か。能力が移動すれば、テクニックの住所も一緒に移動します。

正典を押さえる
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 10

理解度チェック

0/4
  1. 思考モデル向けのプロンプトに「ステップバイステップで考えて」を加えることが、いまでは利益ではなくコストになるのはなぜですか？
  2. Tree of Thoughtsの、現代における正しい住所はどこですか？
  3. 主要3ベンダーは現在、few-shotの例示について異なる助言を文書で示しています。このページは何を推奨していますか？
  4. 現行のフロンティアClaudeモデルにデフォルト以外のtemperatureを送るとどうなりますか？
Key takeaways
  • 名前のあるテクニックは、ある能力がどこに住まなければならないか — プロンプト、モデル、ハーネスのどこか — についての仮説。能力が移れば、テクニックも移る。
  • 手動のChain-of-ThoughtとLeast-to-Mostはモデルの中へ移った: 言葉づかいではなくeffortとthinking levelを使う。
  • ReActとTree of Thoughtsはハーネスの中へ移った: ネイティブなツール使用、並列サブエージェント、そして実際の評価器。
  • Reflexionはメモリレイヤーへ移った: 教訓は次のターンではなく、永続的な場所へ書く。
  • few-shotはベンダー間で本当に議論が分かれている — どのガイドを信じるかではなく、自分のケース20件でアブレーションする。
  • Temperatureのチューニングと感情的圧力は引退。ロール付けは薄く保つ: 語彙と対象読者だけで、履歴書は決して書かない。

次に読むもの​