「ステップバイステップで考えて」はもう古い？──推論モデル時代にプロンプトを「断捨離」すべき理由と新常識

はじめに

「ステップバイステップで考えて（Let's think step by step）」

LLMを業務や個人開発で使ってきたエンジニアなら、一度はこのフレーズをプロンプトの末尾に書き添えた経験があるはずです。2022年に東京大学の小島武氏らが発表した論文『Large Language Models are Zero-Shot Reasoners』（Kojima et al.）を機に広まったこの魔法の呪文は、複雑な推論タスクの正解率を一気に引き上げるプロンプトエンジニアリングの黄金律として親しまれてきました。

ところが、OpenAIのo1やo3、あるいはDeepSeek-R1といった「推論モデル（Reasoning Models）」の普及によって、状況は一変しました。各社の公式ドキュメントには、従来の常識を覆す指示がはっきりと記されています。「思考ステップを細かく指示しないでください」「"think step by step" のようなフレーズは含めないでください」という警告です。

かつて精度を上げるための必須テクニックだったものが、今やモデルの性能を阻害し、レイテンシとAPIコストを無駄に跳ね上げる原因になっています。

この記事では、なぜ推論モデルにおいて「ステップバイステップ」が逆効果になるのか、その内部メカニズムを紐解きます。そのうえで、私たちが長年蓄積してきたプロンプトをどのように「断捨離」し、新しい世代のモデルとどう向き合うべきかを具体例とともに解説します。

従来のLLMで「ステップバイステップ」が有効だった理由

理由を理解するために、まずは従来の自己回帰型（Autoregressive）LLMがどのように推論を行っていたのかを簡単に振り返ります。

GPT-4oやClaude 3.5 Sonnetのような一般的なLLMは、入力されたテキストに対して「次に来る確率が最も高い1トークン」を順番に予測して出力します。内部で時間をかけて考え直す仕組みはなく、一度出力したトークンを取り消すこともできません。

この仕組みにおいて、複雑な計算や論理パズルに対して「答えだけを出力せよ」と命じると、モデルは最初の数トークンで正解に直結する単語を当てにいかなければならず、推論の失敗を招きやすくなります。

Q: りんごが3個あります。2個追加し、1個食べました。残りは？
A（即答指示）: 残りは [ここで即座に計算結果を当てる必要がある]

そこで登場したのが、思考の過程を出力させるChain-of-Thought（CoT）でした。「ステップバイステップで考えて」と指示することで、モデルは次のように思考の中間ステップをテキストとして出力し始めます。

A（CoT指示）: 
1. 最初はりんごが3個ありました。
2. 2個追加されたため、合計は5個になります。
3. そこから1個食べたため、5 - 1 = 4 となります。
したがって、残りは4個です。

モデルにとって、出力したテキスト自体が「計算用紙（スクラッチパッド）」の役割を果たします。前のトークンを参照しながら次のトークンを生成できるため、ステップを言語化させることがそのまま精度の向上に直結していました。これが、長らくCoTがプロンプトの必須要素とされてきた背景です。

推論モデル（Reasoning Models）で何が変わったのか

この前提を根本から変えたのが、強化学習によって思考プロセスを内面化した推論モデルです。

推論モデルは、ユーザーに見える最終回答を出力する前に、内部で「隠れ思考トークン（Thinking Tokens）」と呼ばれる推論を自律的に実行します。これは従来のCoTとは異なり、モデルが自身の判断で仮説を立て、途中で誤りに気づけばバックトラック（やり直し）を行い、多角的に検証を繰り返す仕組みです。

[ユーザー入力]
    ↓
[推論モデル内部] 隠れ思考（自律探索・自己修正・反復検証）
    ↓
[最終出力] 整えられた結論のみを生成

このアーキテクチャの登場により、プロンプトで「ステップバイステップで考えて」と指示することは、次のような問題を引き起こすようになりました。

1. 探索空間の制約と誘導ミス

推論モデルは、タスクに応じて最も効率的な思考経路をモデル自身が探索します。それにもかかわらず、ユーザーが「まずAをして、次にBを比較して」と外部から固定的な手順を与えてしまうと、モデルはその窮屈な指示に縛られます。結果として、モデルが自力で見つけられたはずの優れた解法パスを遮断してしまう現象が起きます。

2. 二重思考による過剰思考（Overthinking）

モデルが内部で自律的に考えている最中に、「思考プロセスを詳しく説明せよ」という指示が混ざると、内部思考と出力生成の両方で同じような推論を二重に回し始めます。

その結果、出力が無意味に冗長になり、推論トークンの消費量が跳ね上がります。推論トークンは出力トークンレートで課金されるだけでなく、モデルの「最大コンテキストウィンドウ」の上限にもカウントされます。無駄な思考を誘発した結果、コンテキスト上限に達してしまい、肝心の最終回答が途中で切り詰められる（truncate）という実務上の重大なトラブルも引き起こします。

3. 公式ドキュメントの警告

この挙動は推測ではなく、各ベンダーの公式ガイドラインにも明記されています。

OpenAI (o1/o3 プロンプティングガイド)
プロンプトは直接的かつ簡潔に保つことが推奨されています。「think step by step」や「explain your reasoning」といったプロンプトは不要であり、かえって性能を落とす恐れがあると記載されています。また、思考の深さを調整したい場合はプロンプトで指示するのではなく、APIの reasoning_effort パラメータ（low / medium / high）を使用することが推奨されています。
DeepSeek (DeepSeek-R1 ガイド)
R1はZero-shotで最大の推論性能を発揮するように強化学習されています。思考手順をユーザーが過剰にガイドすると、モデル固有の推論パターンと衝突し、望ましい結果が得られにくくなります。

やってはいけない3つのアンチパターン

推論モデルを扱う際に、従来の感覚のまま書いてしまいがちなアンチパターンを3つ整理します。

アンチパターン1：思考ステップの先回り指定

要件定義やアルゴリズム設計の際、思考の順番を事細かに指定してしまうパターンです。

<!-- アンチパターンの例 -->
以下の要件を満たすAPI設計を行ってください。
必ず以下のステップに従って思考してください。
ステップ1: 要件を箇条書きで整理する
ステップ2: 認証方式の候補を3つ挙げて比較する
ステップ3: 最適なデータ構造を検討する
ステップ4: 最終的なエンドポイントを定義する

このような指示を与えると、モデルは本来もっと柔軟に検討すべき観点を無視し、指定されたステップの体裁を整えることに注力してしまいます。思考の手順ではなく、「どのようなAPI仕様が必要なのか」「満たすべき前提制約は何か」という目標条件だけを渡すのが賢明です。

アンチパターン2：大量のFew-Shotによる思考誘導

従来のプロンプトでは、望ましい思考パターンを学習させるために複数の具体例（Few-Shot）を並べることが有効でした。

しかし推論モデルにおいては、長大なFew-Shotを与えることで、例示に含まれるわずかなノイズや特定の解法パターンに強く引っ張られてしまいます。OpenAIもDeepSeekも、推論モデルに対しては基本的に例示なしの「Zero-Shot」から試すことを推奨しています。

アンチパターン3：思考過程と出力フォーマットの混在

「思考プロセスを詳しく記載したうえで、最終結果を有効なJSON形式だけで返してください」というような指示です。

思考の記述と厳密な構造化データの出力を同時に求めると、思考トークンと出力トークンの境界が曖昧になり、JSONパースエラーを起こしやすくなります。たとえばDeepSeek-R1では思考内容が <think> タグとして分離されて出力されますが、ユーザーがプロンプト内で無理に思考過程を本文側に出力させようとすると、タグの整合性や出力スキーマが容易に破損します。推論モデルを使う場合、出力には「結論のJSONのみ」を要求し、考える過程はモデル固有の推論領域に任せるのが鉄則です。

推論モデル時代の「プロンプト断捨離」3原則

では、私たちはどのようにプロンプトを再設計すればよいのでしょうか。基本方針は非常にシンプルで、「思考の指示を削ぎ落とし、境界条件に集中する」ことです。

原則1：「How（考え方）」を捨て、「What（成果物）」を定義する

モデルに「どう考えるか」を指図するのはやめましょう。その代わり、「何を満たす成果物が必要か」というゴールを明確にします。

NG: 「〜について多角的な視点から比較検討し、論理的な思考を経て結論を出して」
OK: 「〜の比較表を作成せよ。比較項目にはコスト、レイテンシ、実装難易度を含めること」

原則2：入力コンテキストの境界を明確にする

思考手順を省く代わりに、入力データの品質と区切りを明確にします。Markdownの見出しやXMLライクなデリミタ（<context> や ### 資料）を活用し、どこが前提条件でどこが依頼内容なのかを明示します。これによってモデルは内部推論の焦点を絞りやすくなります。

原則3：すべてのタスクに推論モデルを使わない

推論モデルは万能ではありません。高度な論理的判断、難解な数学的計算、複雑なコードのデバッグなどには絶大な威力を発揮しますが、文章の要約やフォーマット変換、単純な翻訳には不向きです。

推論が不要なタスクに推論モデルを使うと、簡単な挨拶や要約の前に数秒〜十数秒の思考時間が入り、コストも嵩みます。タスクの性質に応じて、軽量で高速なモデルと推論モデルを明確に使い分けることが不可欠です。

プロンプトのBefore / After比較

実際のプロンプトで、どの程度記述を削ぎ落とせるのかを比較してみます。

従来のプロンプト（Before）

思考のステップや指示語が多く、全体として冗長になっています。

以下のスロークエリ改善のインデックス設計を行ってください。
必ずステップバイステップで論理的に考えてください。

ステップ1: WHERE句・JOIN句のカラム抽出
ステップ2: カーディナリティを考慮した優先順位決定
ステップ3: 複合インデックスの順序検討
ステップ4: 推奨DDLと理由を出力

クエリ: SELECT * FROM orders WHERE user_id = 123 AND status = 'completed';

推論モデル向けプロンプト（After）

思考のステップ指定を完全に削り、入力データと成果物の要件だけを簡潔に定義しています。

以下のスロークエリに対する最適なインデックス設計を行ってください。

# 対象クエリ
SELECT * FROM orders WHERE user_id = 123 AND status = 'completed';

# 出力要件
- 推奨するインデックス作成用のDDL文
- そのインデックス順序を選択した技術的根拠
- 潜在的なトレードオフ（書き込み性能への影響など）

Afterのプロンプトでは、「どう考えるか」を一切指示していません。それでも推論モデルは内部でクエリの実行計画やインデックスのB-tree構造、カーディナリティの偏りを勝手に検討し、最適な順序を導き出してくれます。思考の自由度を残した結果、むしろ回答の質が上がり、出力トークン数も必要最小限に抑えられます。

まとめ

これまでのプロンプトエンジニアリングは、LLMという賢いアシスタントに対して「思考のレールを人間が敷いてあげる作業」でした。「ステップバイステップで考えて」はその象徴的なレールだったと言えます。

しかし推論モデルの登場によって、モデルは自ら最適なレールを敷き、脱線すれば自力で戻れるようになりました。私たちがすべき仕事は、レールを無理に押し付けることではなく、目的地（ゴール）と通過してはならない危険区域（制約条件）を明確に伝えることです。

プロンプトエンジニアリングは決して不要になったわけではありません。「思考プロセスの手取り足取りな指示」から「境界条件と成果物仕様の厳密な設計」へと、その役割が進化したと捉えるべきです。

もし現在運用しているプロンプトに「ステップバイステップで」や「論理的に思考し」といったフレーズが残っているなら、一度それらを削ぎ落としてみてください。推論モデルが本来持っている実力を、より速く、より低コストで引き出せるようになるはずです。