推論モデルへの指示は簡潔でいい。ただし「仕様」を削ると精度は0%まで落ちた

「AIに仕事を頼むときは、できるだけ細かく指示したほうがいい」

そう聞いたことがある方は多いと思います。手順を1つずつ書き、「まず〜、次に〜」と段取りまで指定する。多くのプロンプト解説記事がこの方法を勧めています。

ただ、この前提が当てはまらない場面があります。モデルによっては、手順を細かく書いても結果が変わらない、あるいは逆効果になることがあります。

ではどこまで削ってよいのか。気になったので、実際に試して測ってみました。

公式は「手順は不要、ゴールは具体的に」と言っている

最近のAIモデルには、回答する前に内部で考えるプロセスを持つものがあります。人間でいえば、すぐ口を開くのではなく、頭の中で筋道を立ててから話すようなイメージです。

OpenAI はこうしたモデル向けの注意点を公式ドキュメントに挙げています。

• 「ステップバイステップで考えて」といった指示は不要（内部で推論するため）
• プロンプトは簡潔かつ直接的に書くほうがよい
• 例示（few-shot）も多くの場合は不要
• ただしゴールについては非常に具体的に書くこと

出典: Reasoning best practices | OpenAI API

注目したいのは最後です。「手順は書くな」と言いながら「ゴールは具体的に」とも言っています。 「何も細かく書くな」という話ではありません。この線引きが実際どう効くのかを確かめました。

実際に測ってみた

なぜGeminiを使ったか

Google の Gemini には、思考プロセスのON/OFFを同じモデルで切り替えられる設定があります。

{
  "contents": [{ "parts": [{ "text": "（プロンプト）" }] }],
  "generationConfig": {
    "thinkingConfig": { "thinkingBudget": 0 }
  }
}

thinkingBudget に 0 を指定すれば思考なし、正の値（今回は 8192）を指定すれば思考ありになります。同じモデルのまま切り替えられるのが重要でした。推論モデルと通常モデルを比べると、差が「思考の有無」によるものか「モデルの地力の違い」によるものか分けられません。同一モデルなら地力が固定されるので、思考の有無だけを取り出せます。

なお最新の gemini-3.6-flash では thinkingBudget: 0 が400エラーになり、思考を切れなくなっていました。今回は ON/OFF 両方に対応している gemini-3.5-flash を使っています。

使った問題

6人の並び順を条件から特定する論理パズルです。実際に使ったものをそのまま載せます。

A〜Fの6人が横一列に並んでいます。次の条件をすべて満たす並び順を求めてください。
- AとDの間にはちょうど1人いる
- DはFより右にいる
- BはDより左にいる
- BとCの間にはちょうど4人いる
- BとEは隣り合っている

正解は BEAFDC の1通りです。正解が機械的に判定できるので、出力の良し悪しに私の主観が入りません。

正解が1通りであることの確認

問題を作ったら、全720通り（6の階乗）を総当たりして解が1個であることを確認しています。これをやらないと、複数の正解がある問題で「不正解」と誤判定してしまいます。

from itertools import permutations

def count_solutions(conds):
    n = 0
    for p in permutations("ABCDEF"):
        pos = {c: i + 1 for i, c in enumerate(p)}
        if all(f(pos) for f in conds):
            n += 1
    return n

# 例: 「AとDの間にちょうど1人」→ abs(pos['A'] - pos['D']) == 2

実際、最初に手作りした問題は解が3個あり、そのままでは検証に使えませんでした。

比較した3パターン

A案（手順を細かく指定）

以下の手順に厳密に従って解いてください。
1. まず全ての条件を箇条書きで整理する
2. 次に考えられる配置をすべて列挙する
3. 各条件を1つずつ適用して候補を絞り込む
4. 残った候補が条件をすべて満たすか検算する
5. 最後に答えを出力する

最終行に必ず「答え: XXXXXX」の形式（6文字の英大文字）で記載してください。

（問題文）

B案（ゴールと制約だけ）

（問題文）

最終行に必ず「答え: XXXXXX」の形式（6文字の英大文字）で記載してください。

違いは5ステップの手順を書くかどうかだけです。問題の条件と出力形式の指定は、両案とも同じだけ渡しています。

C案（仕様を削る） は、B案から条件を2つ削除したものです。

A〜Fの6人が横一列に並んでいます。次の条件をすべて満たす並び順を求めてください。
- AとDの間にはちょうど1人いる
- DはFより右にいる
- BはDより左にいる

削った結果、解が1個から56個に増えました。つまり正解を一意に導けない状態です。手順ではなく仕様が欠けると何が起きるかを見るための条件です。

試行回数

問題3問 × 各3回 = 9試行を、条件ごとに実施しました。

結果1：手順を書いても、結果は変わらなかった

まったく同じでした。 一方で、出力量には差が出ました。

手順を指定すると、5ステップをモデルが律儀に書き出します。内部で考えているのに同じ内容を出力にも書かせる状態で、結果が同じならコストと待ち時間の面で不利です。

結果2：思考OFFにしても、大きくは変わらなかった

思考を切っても正答率はほぼ維持されました。ただし出力量は倍近く増えています（手順あり1,799トークン / 手順なし934トークン）。手順を書かせた分だけ長くなる傾向は、思考のON/OFFに関わらず共通でした。

結果3：ただし「仕様」を削ると壊れる

手順を削ってよいなら、どこまで削れるのか。今度は条件（仕様）の方を削りました。

崩壊しました。 削ったのは条件2つだけです。それだけで正解が一意に定まらなくなりました。思考OFFでも1/9（11%）まで落ちました。

わかったこと：「手順」と「仕様」は別物

「AIに細かく指示するな」ではありません。手順は要らないが、仕様と制約は必須です。

ここを混同すると危険です。「推論モデルには簡潔でいい」と聞いて要件まで曖昧にすると、結果は目に見えて悪化します。OpenAI公式が「手順は不要」と言いつつ「ゴールは具体的に」と書いているのも同じ趣旨でしょう。削ってよいのは過程であって、目的地や制約ではありません。

開発現場での線引き

この区別は実務でそのまま使えます。

ある開発案件で、利用者が蓄積したデータを集計し、その要約文を自動生成する機能を実装しました。要約が集計結果と食い違うことが許されないデータだったため正確性は絶対条件ですが、文章の組み立て方まで規定すると、内容によらず似た文面しか出てこなくなります。

そこで「守らせたいこと」と「任せたいこと」を分けました。

出力形式は、返答の構造をあらかじめ定義できる仕組み（Structured Outputs）で保証しています。形式が崩れないことは、プロンプトではなく仕組みで担保するという判断です。今回の検証結果は、この線引きを裏づけるものになりました。

覚えるより、試し方を持つ

モデルごとの癖を全部覚える必要はありません。押さえるのは「考えてから答えるタイプか」「長文が得意か」「ツールを使う前提か」程度の大分類で足ります。細部は更新のたびに変わりますが、この3軸は比較的長持ちします。

そのうえで有効なのが、知識ではなく「試し方」を持っておくことです。

今回の検証は特別な環境を用意したわけではなく、同じ問題を指示の書き方だけ変えて投げただけです。費用は全部で130円ほどでした。

• A案：手順を細かく指定した指示
• B案：ゴールと制約だけを伝えた指示
• C案：制約を一部省いた指示

実際の業務データで数回ずつ試し、回答の質だけでなく出力量や所要時間も含めて比べる。この方法なら、モデルが新しくなっても同じやり方が使えます。

うまくいかないときも原因を絞り込めます。「A案は駄目でB案で改善した」ならモデルの性質を知る手がかりですし、逆にどちらも変わらなければ、問題はプロンプト以外にあります。

今回の検証の限界

数字を出した以上、どこまで言えるかも書いておきます。

• 論理パズル1種類での結果です。文章生成や要約では傾向が異なる可能性があります
• 1モデル（Gemini 3.5 Flash）での結果です。他社でも同じとは限りません
• 各条件9回の試行です。統計的な有意差を主張できる規模ではありません

「こう決まっている」ではなく「弊社で試したらこうなった」として読んでいただければと思います。そして気になったら、ご自身の業務データで同じ比較をしてみてください。それがこの記事でいちばんお伝えしたいことです。

まとめ

• 手順を細かく書いても、考えるタイプでは結果が変わらなかった（100% → 100%）
• 手順を書くと出力量が2倍以上になり、コストと速度では不利になる
• 思考を切っても正答率は大きく変わらなかったが、出力量は約2倍になった
• ただし仕様や制約を削ると精度は崩壊した（100% → 0%）
• 削ってよいのは手順であって、仕様ではない