この記事の対象読者

ChatGPT / Claude / Gemini を日常的に使っているが、プロンプトの書き方に自信がない方
「深呼吸して」「チップあげます」等の噂のテクニックの真偽を知りたい方
推論モデル（o3, Claude拡張思考, Gemini Thinking）と通常モデルの使い分けに悩んでいる方

この記事で得られること

3大LLM（Claude / ChatGPT / Gemini）の公式ドキュメントに基づく、プロンプトテクニックの有効/無効/逆効果の判定
通常モデル vs 推論モデルで効果が真逆になるテクニックの早見表
2024〜2025年の主要研究論文（Wharton大学 Prompting Scienceシリーズ他）の知見
プロンプトの代わりに「設定」や「API機能」で対処すべきケースの整理

この記事で扱わないこと

特定のプロンプトテンプレート集（「コピペで使える100選」的なもの）
画像生成AI（Midjourney, DALL-E等）のプロンプト
エージェント型ワークフローの詳細設計

1. プロンプトエンジニアリングとの出会い
 2. 前提知識の確認
　　 2.1 通常モデルと推論モデル
　　 2.2 Chain-of-Thought（CoT）
　　2.3 Few-shot Prompting
　　2.4 コンテキストエンジニアリング
 3. Cursorで使えるモデル早見表: 推論モデル vs 通常モデル
 4. コンシューマー向けアプリ: 推論モデル vs 通常モデル
 5. アプリではできない、APIだけの制御項目
　　 5.1 ChatGPT / OpenAI APIの場合
　　 5.2 Claude / Anthropic APIの場合
　　 5.3 Gemini / Google APIの場合
 6. テクニック仕分け早見表: 通常モデル vs 推論モデル
 7. 現在も有効な公式推奨テクニック
 8. 死んだテクニック: かつては有効だったが、今は効果が薄れたもの
 9. 逆効果なテクニック: やると性能が下がるもの
 10. プロンプトではなく「設定」でやるべきこと
 11. 構造化プロンプティング: XML / Markdown / JSON / YAML の使いどころ
 12. 学習ロードマップ
 13. まとめ

1. プロンプトエンジニアリングとの出会い

「ChatGPTには『深呼吸して考えて』って言うと賢くなるらしいよ」

2023年、こんな噂がSNSを駆け巡った。実際にGoogle DeepMindの論文で効果が確認され、一時は「魔法の呪文」として広まった。しかし2025年現在、状況は一変している。

私自身、RTX 5090環境でAI開発をしている中で、プロンプトの書き方ひとつでモデルの出力品質が劇的に変わる経験を何度もしてきた。だが同時に、「効くと信じていたテクニックが実は無意味だった」と気づかされる場面も増えた。

最大の転換点は「推論モデル」の登場だ。OpenAIのo1/o3、GoogleのGemini 3 Thinking、AnthropicのClaude拡張思考。これらのモデルでは、従来の定番テクニックが逆効果になる場合がある。

この記事では、Anthropic・OpenAI・Googleの公式ドキュメントと、2024〜2025年の査読済み研究論文を横断調査し、プロンプトテクニックを「効く」「死んだ」「逆効果」に仕分けする。噂や個人の感想ではなく、一次情報だけで判断する。

ここまでで、この記事がどんな内容か掴めたでしょうか。次は、用語を整理しておきましょう。

2. 前提知識の確認

本題に入る前に、この記事で頻出する用語を押さえておく。

2.1 通常モデルと推論モデル

LLMは今、大きく2種類に分かれている。

種類	代表的なモデル	特徴
通常モデル	GPT-4o, Claude Sonnet/Haiku（拡張思考OFF）, Gemini Flash/Pro（thinking OFF）	即座に応答を生成。ユーザーがCoT等で「考え方」を指示すると効果的
推論モデル	o3, o4-mini, Claude Opus/Sonnet（拡張思考ON）, Gemini 3 Pro/Flash（thinking ON）	応答前に内部で推論プロセスを実行。「考え方」は内蔵済み

料理に例えると、通常モデルは「レシピ（考え方）を渡すと忠実に作ってくれるシェフ」、推論モデルは「完成イメージ（ゴール）を伝えれば自分でレシピを考えるシェフ」だ。後者に細かいレシピを渡すと、かえって混乱する。

2.2 Chain-of-Thought（CoT）

「ステップバイステップで考えてください」とモデルに指示し、推論過程を出力させるテクニック。2022年にWei他の論文で提唱され、LLMの推論能力を劇的に向上させた。

2.3 Few-shot Prompting

入出力の例を数個提示してから本題を投げるテクニック。例を示さないのがZero-shot、1個がOne-shot、複数がFew-shot。

2.4 コンテキストエンジニアリング

2025年6月にAndrej Karpathy（元Tesla AI責任者）が提唱した概念。プロンプトの「言い回し」ではなく、何の情報をどの順序でコンテキストウィンドウに配置するかに焦点を当てる。

「『コンテキストエンジニアリング』という用語を『プロンプトエンジニアリング』より好む。人々はプロンプトを短いタスク記述と関連付ける…産業規模のLLMアプリでは、コンテキストエンジニアリングは適切な情報でコンテキストウィンドウを満たす繊細な芸術と科学だ」— Andrej Karpathy, 2025年6月

これらの用語が押さえられたら、まずは「自分が今使っているモデルがどっちなのか」を確認しましょう。

3. Cursorで使えるモデル早見表: 推論モデル vs 通常モデル

自分の使っているモデルが「推論モデル」か「通常モデル」かわからないまま、プロンプトテクニックを語っても意味がない。まずここで確認しよう。

以下はCursor IDEで2026年2月現在選択可能な主要モデルの分類だ。Cursorはモデルセレクターから自由に切り替え可能で、Autoモードではタスクの複雑さに応じて自動選択される。

OpenAI系モデル

Cursor上の表示	分類	備考
GPT-5.3 Codex 🧠	推論モデル	コーディング特化の最新版。🧠付きのみ存在
GPT-5.2 🧠	推論モデル	フラッグシップ。🧠付きのみ存在
o3	推論モデル	推論専用モデル（表示される場合）
o4-mini	推論モデル	o3の軽量版（表示される場合）
GPT-4.1	通常モデル	エージェント的ワークフローに最適化（表示される場合）
GPT-4o	通常モデル	コスト効率の良い汎用モデル（表示される場合）

Anthropic系モデル

Cursor上の表示	分類	備考
Opus 4.6 🧠	推論モデル	最新最上位。常に🧠付きのみ存在
Sonnet 4.5 🧠	推論モデル	思考付き版。深い推論が必要な場面に
Sonnet 4.5	通常モデル	思考なし版。速度とコストのバランス型
Sonnet 4	通常モデル	日常コーディングのワークホース
Haiku 4.5	通常モデル	高速・低コスト。Tab補完に最適

Google系モデル

Cursor上の表示	分類	備考
Gemini 3 Pro 🧠	推論モデル	🧠付きで表示される場合、思考モード
Gemini 2.5 Pro 🧠	推論モデル	大規模コードベースの調査に強い
Gemini 2.5 Flash	通常モデル	高速・低コスト。日常タスク向き

その他のモデル

Cursor上の表示	分類	備考
Composer 1.5 🧠	推論モデル	Cursor独自。エージェント特化+推論
Composer 1	通常モデル	Cursor独自。低レイテンシのエージェント特化
Grok Code Fast 1	通常モデル	xAI製。超高速・低コスト
DeepSeek V3	通常モデル	無料で使えるOSSモデル
DeepSeek R1 🧠	推論モデル	OSS推論モデル。ローカル実行も可能

判断フローチャート

今選んでいるモデルはどっち？
│
├── 🧠マーク付き → 推論モデルとして動作中
│   例: Opus 4.6🧠, Sonnet 4.5🧠, GPT-5.3 Codex🧠, Composer 1.5🧠
│   └── CoT指示は不要、Few-shotは慎重に、シンプルなプロンプトが最適
│
├── 🧠マークなし → 通常モデルとして動作中
│   例: Sonnet 4.5, Sonnet 4, Composer 1
│   └── CoT指示は有効、Few-shotは推奨、構造化プロンプトが効果的
│
└── Auto → Cursorが自動判断（モデルもモードも自動選択）
    └── 基本的には「通常モデル向け」のプロンプトでOK

重要: 🧠マークの意味とMax Modeの違い

Cursorのモデルセレクターには「別のThinkingトグル」は存在しない。代わりに、同じモデルが通常版と🧠（脳みそアイコン）付き版の2つのエントリとしてドロップダウンに並んでいる。🧠付きを選べば推論モデル、🧠なしを選べば通常モデルとして動作する。

2026年2月現在のCursor UIでの実際の表示例:

表示名	🧠	分類
Composer 1.5 🧠	あり	推論モデル
Composer 1	なし	通常モデル
Opus 4.6 🧠	あり	推論モデル
Sonnet 4.5	なし	通常モデル
Sonnet 4.5 🧠	あり	推論モデル
GPT-5.3 Codex 🧠	あり	推論モデル
GPT-5.2 🧠	あり	推論モデル
Sonnet 4	なし	通常モデル

Sonnet 4.5を例にすると、ドロップダウンに「Sonnet 4.5」と「Sonnet 4.5 🧠」の2つが並んでいる。どちらを選ぶかで推論モデルか通常モデルかが決まる。

ではMax Modeは何かというと、これは別のトグルとしてドロップダウン上部に存在する。

機能	何が変わるか	推論モデルになるか
Max Mode	コンテキストウィンドウ拡大（~20K → 200K）、ツールコール無制限、計算リソース増加	ならない
🧠付きモデルの選択	モデルが応答前に内部推論プロセスを実行	なる

🧠付きモデルを選ぶと推論トークンの生成分が加算され、コストが約2倍（2リクエスト分消費）になる点にも注意。

つまり: 推論モデルか通常モデルかを決めるのは「Max Mode」ではなく「🧠マーク付きモデルを選んでいるかどうか」だ。自分がどちらを選んでいるかを意識することが、プロンプト最適化の第一歩になる。

Cursorでのモデル分類が確認できたところで、次は多くの人が日常的に使っているコンシューマー向けアプリのモデル分類も見ていきましょう。

4. コンシューマー向けアプリ: 推論モデル vs 通常モデル

CursorのようなIDE以外にも、ChatGPT・Claude・Geminiの各Webアプリ/モバイルアプリでも「推論モデル」と「通常モデル」の区別は存在する。ここが曖昧なまま「Chain-of-Thoughtが効かない」と悩んでいる人、かなり多いはずだ。

ChatGPT（chatgpt.com / モバイルアプリ）

速報: 2026年2月13日にGPT-4o、GPT-4.1、GPT-4.1 mini、o4-mini、GPT-5（Instant/Thinking）が退役予定。退役後はGPT-5.2が主力モデルとなる。

モデル名	プラン	分類	備考
GPT-5.2 Thinking	Plus / Pro	推論モデル	モデルセレクターで「Thinking」を選択。複雑な問題に対し熟考してから回答
GPT-5.2 Auto	Plus / Pro	ハイブリッド	クエリの複雑さに応じて自動で思考深度を調整。デフォルト設定
GPT-5.2 Instant	Plus / Pro	通常モデル	即座に回答。思考プロセスなし
o3	Plus / Pro	推論モデル	最強の推論モデル。数学・コーディング・科学に特化
o3-pro	Pro のみ	推論モデル	o3にさらに計算リソースを投入した最上位版
GPT-4o	Free（制限あり）/ Plus	通常モデル	2/13退役予定
GPT-4.1	Plus / Pro	通常モデル	コーディング特化。2/13退役予定
o4-mini	Plus / Pro	推論モデル	軽量推論。2/13退役予定

ポイント: GPT-5.2は同じモデルなのに「Instant」「Auto」「Thinking」の3モードで切り替わる。Cursorの🧠マークとは異なり、ChatGPTではモデルセレクター内のモード選択で推論の有無が決まる。

Claude（claude.ai / デスクトップ・モバイルアプリ）

Claude.aiでは「拡張思考（Extended Thinking）」のON/OFFがモデルの推論動作を制御する。

モデル名	プラン	拡張思考	分類	備考
Opus 4.6	Pro / Max	適応型思考（常にON）	推論モデル	最新最上位。タスク複雑度に応じて自動で思考量を調整
Opus 4.5	Pro / Max	適応型思考（常にON）	推論モデル	コーディング・分析のフラッグシップ
Sonnet 4.5	Free / Pro	ON/OFF可能	ハイブリッド	拡張思考ONで推論モデル、OFFで通常モデルとして動作
Sonnet 4	Free / Pro	ON/OFF可能	ハイブリッド	日常利用のバランス型
Haiku 4.5	Free（デフォルト）	なし	通常モデル	高速・無料枠のデフォルト

ポイント: Opus 4.5以降は「適応型思考（Adaptive Thinking）」を搭載。タスクの複雑さに応じて思考量を自動調整するため、ユーザーが明示的にON/OFFする必要がない。一方、Sonnet系は拡張思考のトグルでユーザーが切り替える。

Gemini（gemini.google.com / モバイルアプリ）

GeminiアプリはモデルセレクターのUI表記が独特で、モデル名ではなくモード名で表示される。

UI上の表示	実体のモデル	プラン	分類	備考
Fast	Gemini 3 Flash	全ユーザー	通常モデル	デフォルト。高速で軽快な応答
Thinking	Gemini 3 Flash（思考ON）	全ユーザー	推論モデル	同じFlashだが思考プロセスが有効化
Pro	Gemini 3 Pro	AI Plus / Pro / Ultra	推論モデル	高度な数学・コーディングに最適
Deep Think	Gemini 3 Deep Think	AI Ultra のみ	推論モデル（最上位）	反復的な仮説探索で最も深い推論を実行。結果返却に数分かかる場合あり

ポイント: Geminiは「Fast」と「Thinking」が同じGemini 3 Flashベースだが、思考の有無で別物。ChatGPTのGPT-5.2 Instant/Thinkingと同じ発想だが、Geminiはそれをモード名で明示している点がわかりやすい。

3サービス横断比較

項目	ChatGPT	Claude	Gemini
推論ON/OFFの方法	モード選択（Instant/Auto/Thinking）	拡張思考トグル or 自動（Opus）	モード選択（Fast/Thinking/Pro/Deep Think）
同一モデルの推論切替	GPT-5.2で可能	Sonnet系で可能	Gemini 3 Flashで可能
常時推論モデル	o3, o3-pro	Opus 4.5 / 4.6	Deep Think
無料枠の推論アクセス	なし（Free枠はGPT-4o等のみ）	Sonnet拡張思考は制限あり	Thinking（Flash）は全ユーザー利用可
推論コスト	Thinkingモードは消費メッセージ増	拡張思考ONで応答が長くなりレート制限に影響	Deep Thinkは数分/回の処理時間

結論: どのサービスでも「自分が今、推論モードで使っているのか否か」を意識しないと、プロンプトテクニックの効果を正しく判断できない。

コンシューマー向けアプリの分類も確認できたところで、次は「プロンプトでは手が届かないが、APIなら触れるパラメータ」を整理しておこう。

5. アプリではできない、APIだけの制御項目

プロンプトの書き方をいくら工夫しても、アプリ版では触れないパラメータが存在する。「なんか出力がブレる」「もっと決定的な回答がほしい」「思考量を細かくコントロールしたい」 -- これらはプロンプトテクニックの問題ではなく、APIパラメータの問題だ。

全プロバイダー共通: アプリ版 vs API版の壁

制御項目	アプリ版	API版	なぜ重要か
temperature	触れない	0.0〜2.0で調整可能	出力の多様性/決定性を制御。分析なら低め、創作なら高め
top_p / top_k	触れない	数値で指定可能	サンプリング戦略の微調整。temperatureと組み合わせて出力品質を制御
stop_sequences	触れない	任意の文字列で停止条件を設定	出力の打ち切り位置を精密に制御
max_tokens	触れない（アプリが自動制御）	数値で厳密に指定	出力長の上限を正確にコントロール
system prompt	限定的（Custom Instructions等）	完全に自由に設定可能	モデルの人格・制約・出力形式を根本から制御
structured output	触れない	JSONスキーマで出力形式を強制	後続処理に直結する構造化データを確実に取得
思考量の細粒度制御	モード選択のみ	トークン数やレベルで精密指定	コストと品質のトレードオフを最適化

つまり: アプリ版で「出力がイマイチ」と感じたとき、プロンプトを延々と書き直すより、APIに移行してパラメータを調整した方が根本解決になるケースが多い。

以下、各プロバイダーごとに「APIでしか触れない具体的なパラメータ」を見ていく。

5.1 ChatGPT / OpenAI APIの場合

パラメータ	アプリ版	API版	備考
`temperature`	不可	0.0〜2.0（GPT-4o等）。GPT-5系/o系はデフォルト1.0固定で変更不可	GPT-5は推論モデル扱いでtemperature非対応。400エラーになる
`top_p`	不可	0.0〜1.0（GPT-4o等）。GPT-5系/o系は非対応	temperature同様、推論モデルでは使えない
`reasoning_effort`	Instant/Auto/Thinkingの3択	`none` / `low` / `medium` / `high` / `xhigh` の5段階	アプリの3モードより遥かに細かい制御が可能
`frequency_penalty`	不可	-2.0〜2.0	同じ単語の繰り返しを抑制。GPT-5/o系は非対応
`presence_penalty`	不可	-2.0〜2.0	新しいトピックへの言及を促進。GPT-5/o系は非対応
`logprobs`	不可	トークンごとの対数確率を取得	出力の確信度を数値で確認できる。GPT-5/o系は非対応
`response_format`	不可	`json_object` / `json_schema` で出力形式を強制	パース可能なJSONを確実に返させる
`developer` メッセージ	Custom Instructionsのみ	完全に自由なsystem/developerメッセージ	アプリのCustom Instructionsには文字数制限あり

特筆事項: GPT-5系モデルはtemperature、top_p、frequency_penalty、presence_penaltyがすべて非対応。これはGPT-5が内部的に推論モデルとして動作しているためだ。APIでも制御できないので、出力の多様性はプロンプトの書き方で調整するしかない。

# GPT-5.2でreasoning_effortを細かく制御する例
from openai import OpenAI
client = OpenAI()

response = client.responses.create(
    model="gpt-5.2",
    input=[{"role": "user", "content": "素数の無限性を証明して"}],
    reasoning={"effort": "high"},  # none/low/medium/high/xhigh
    # temperature=0.5,  # これを入れると400エラー!
)

5.2 Claude / Anthropic APIの場合

パラメータ	アプリ版	API版	備考
`temperature`	不可	0.0〜1.0	Claude全モデルで利用可能（OpenAIと違い推論モデルでも使える）
`top_p`	不可	0.0〜1.0	temperatureかtop_pのどちらか一方を調整推奨
`top_k`	不可	整数値で指定	Anthropic独自。上位K個の候補のみからサンプリング
`thinking.budget_tokens`	拡張思考ON/OFFのみ	最低1,024〜最大コンテキスト上限まで数値指定	思考にかけるトークン数を精密に制御
`thinking.type`	ON/OFFトグル	`enabled` / `disabled` / `adaptive`（Opus 4.6推奨）	Opus 4.6ではadaptiveが推奨。手動budget指定は非推奨化予定
`effort`	不可	Opus 4.5/4.6で `low` / `medium` / `high`	適応型思考のeffort制御。budget_tokensの上位互換
`stop_sequences`	不可	任意の停止シーケンスを配列で指定	出力の切れ目を精密に制御
`output_format`	不可	JSONスキーマで構造化出力を強制（Sonnet 4.5, Opus 4.1+）	確実にパース可能なJSONを返させる
プレフィル（Prefill）	不可	assistantロールの最後のメッセージで出力の冒頭を指定	Opus 4.6/Sonnet 4.5では非推奨（deprecated）
`cache_control`	不可	プロンプトキャッシングでコスト90%削減	長いsystem promptの再利用に効果的
コンテキスト管理	不可	`context_management`で古いツール結果や思考ブロックを自動クリア	長い会話のコンテキスト溢れを防止

特筆事項: ClaudeはOpenAIと異なり、拡張思考ON時でもtemperatureを変更できる。ただし、拡張思考ON時はtop_kのみ対応（top_pは使えない）という制約がある。

# Claude APIでthinking budgetを精密制御する例
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # 最低1,024。アプリではこの数値指定ができない
    },
    temperature=0.3,  # 推論モデルでもtemperature調整可能!
    messages=[{"role": "user", "content": "このコードのバグを見つけて"}]
)

5.3 Gemini / Google APIの場合

パラメータ	アプリ版	API版	備考
`temperature`	不可	0.0〜2.0。Gemini 3ではデフォルト1.0推奨、変更すると性能劣化の可能性	公式が「1.0のままにしろ」と明言。ループや性能低下の原因になりうる
`top_p`	不可	0.0〜1.0	nucleus sampling制御
`top_k`	不可	整数値で指定	Google独自にフルサポート
`thinking_level`（Gemini 3系）	Fast/Thinking/Pro/Deep Thinkのモード選択のみ	`minimal` / `low` / `medium` / `high` の4段階	アプリの4モードより細かい制御
`thinking_budget`（Gemini 2.5系）	不可	0〜32,768トークンで数値指定。`-1`で動的	Gemini 3では非推奨。thinking_levelに移行
`max_output_tokens`	不可	数値で厳密に指定	出力トークン数の上限制御
`stop_sequences`	不可	任意の停止文字列を指定	出力の切れ目を制御
`response_mime_type`	不可	`application/json` 等で出力形式を強制	JSONやEnum等の構造化出力
`media_resolution`	不可	`low` / `medium` / `high`	画像・PDF・動画の解像度をトークンコストとトレードオフで制御
`thought_signatures`	不可	APIコール間で推論チェーンを維持	Gemini 3独自。マルチターンで推論の文脈を保持できる

特筆事項: Gemini 3はtemperature 1.0で最適化されており、変更するとループや性能劣化が発生する。公式ドキュメントが明確に「Leave temperature at default 1.0」と記載している。これはGemini 3の推論メカニズムがtemperature 1.0前提で設計されているためだ。

# Gemini 3 APIでthinking_levelを制御する例
from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_KEY")

response = client.models.generate_content(
    model="gemini-3-pro-preview",
    contents="RSA暗号の安全性を数学的に説明して",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(
            thinking_level="high"  # minimal/low/medium/high
        ),
        # temperature=1.0,  # デフォルトのまま変更しないこと!
        max_output_tokens=8192,
    )
)

注意: Gemini 2.5系のthinking_budgetとGemini 3系のthinking_levelは同時に使えない（400エラー）。モデルのバージョンによってパラメータ名が異なる点に要注意。

3社のAPI制約横断まとめ

制約	OpenAI（GPT-5系）	Anthropic（Claude）	Google（Gemini 3）
temperature変更	不可（推論モデル）	可能	可能だが非推奨（1.0固定推奨）
思考量の精密制御	5段階（none〜xhigh）	トークン数で数値指定 or 3段階effort	4段階（minimal〜high）
構造化出力（JSON）	response_format	output_format（Sonnet 4.5+）	response_mime_type
サンプリング制御	GPT-5系は全非対応	temperature + top_k	temperature + top_p + top_k
プレフィル	非対応	Opus 4.6/Sonnet 4.5で非推奨	非対応
推論の文脈維持	自動（内部管理）	thinking blocks保持	thought_signatures（手動循環必須）

結論: 「プロンプトの書き方」と「パラメータの調整」は別のレイヤーだ。アプリ版で限界を感じたらAPI移行を検討しよう。特に構造化出力、思考量制御、サンプリング調整はAPIでしか手が届かない領域であり、プロンプトテクニックでは代替できない。

API版とアプリ版の違いが確認できたところで、いよいよ本題の「テクニック仕分け表」を見ていきましょう。

6. テクニック仕分け早見表: 通常モデル vs 推論モデル

この表がこの記事の核心だ。ブックマーク推奨。

同じテクニックでも、どちらのモデルに使うかで効果が真逆になる場合がある。

テクニック	通常モデル	推論モデル	根拠（出典）
明確で具体的な指示	有効	有効	3社共通の普遍的原則
Few-shot（例示）	有効	注意	OpenAI公式「まずゼロショットを試せ」¹
Chain-of-Thought（「ステップバイステップで考えて」）	有効（4〜14%改善）	逆効果の場合あり	OpenAI「パフォーマンスを妨げる場合がある」¹ / Google「複雑なプロンプトエンジニアリングは不要」²
ロール/ペルソナ設定	有効	軽めが有効	Anthropic「重厚な設定より目標提示が効果的」³
出力フォーマット指定	有効	有効	両タイプで有効。推論モデルではAPI機能を優先
XMLタグによる構造化	有効	有効	Claude・Gemini 3が推奨⁴²
Markdown見出し構造化	有効	有効	OpenAIが最も強く推奨⁵
ネガティブ指示（「〜しないで」）	効果薄い	逆効果の場合あり	3社共通で「すること」を指示すべき⁶
感情的プロンプト（「深呼吸して」「これは重要」）	効果薄れた	効果なし	2025年研究で効果減衰確認⁷ / Google Vertex AIは除去を推奨⁸
チップ・報酬（「100ドルあげます」）	効果なし	効果なし	Wharton大学の実証研究で「有意な効果なし」⁹
脅迫（「間違えたらクビ」）	効果なし	効果なし	同上⁹
過度な丁寧さ（please多用）	影響最小限	影響最小限	有効・有害が拮抗しウォッシュアウト¹⁰
temperature変更	有効（用途に応じて）	注意	Gemini 3「デフォルト1.0を変更しないことを強く推奨」²
System Prompt	有効	有効（名称変更あり）	OpenAI o-seriesでは`developer` messageに変更¹
Prefill（応答の事前入力）	有効（Claude 3.x）	使用不可（Claude 4+）	Claude 4以降は400エラー¹¹
推論制御パラメータ	該当なし	有効	reasoning_effort, thinking_level等で思考の深さ制御
JSON形式での長文入力	有効	性能低下	GPT-4.1ガイド「長文にJSONは特に性能が悪い」⁵
プロンプトチェーン（タスク分割）	有効	有効	両タイプで有効。推論モデルでは各ステップをシンプルに

凡例

有効 = 公式推奨 or 実証研究で効果確認
注意/効果薄い = 条件次第 or 効果が不安定
逆効果/効果なし = 公式非推奨 or 実証研究で否定

この表から読み取るべき最重要ポイント

推論モデルでは「余計なお世話」が逆効果になる。

CoTの手動指示、過剰なFew-shot、複雑なロール設定。通常モデルでは効果的だったこれらが、推論モデルでは干渉を起こす。推論モデルは既に内部で推論プロセスを実行しているため、外部からの「考え方の指示」がノイズになる。

推論モデルには**「何を達成したいか」を明確に伝え、「どう考えるか」は任せる**のが正解だ。

基本的な仕分けが理解できたところで、各テクニックの詳細を見ていきましょう。

7. 現在も有効な公式推奨テクニック

4.1 明確で具体的な指示 -- 全社が満場一致で推奨

3社すべてが一貫して推奨する、最も基本かつ最も重要なテクニック。

Anthropic（公式ドキュメント）:

"Think of Claude as a brilliant but new employee (with amnesia) who needs explicit instructions."
（Claudeを、記憶喪失の優秀な新入社員だと考えてください。明示的な指示が必要です。）

ゴールデンルールとして:

"Show your prompt to a colleague with minimal context of what you need done, and see if they can follow it."
（あなたのプロンプトを、タスクの文脈を最小限しか知らない同僚に見せてください。その同僚が混乱するなら、Claudeも混乱するでしょう。）

OpenAI（プロンプトエンジニアリングガイド）:

"The less the model has to guess at what you want, the more likely you'll get it."
（モデルが推測する余地が少ないほど、望む回答が得られる可能性が高くなります。）

GPT-4.1ガイド（2025年4月14日）ではさらに踏み込んで:

"GPT-4.1 has been trained to follow instructions more closely and more literally than its predecessors."
（GPT-4.1は前世代のモデルよりも指示をより忠実に、より文字通りに実行するよう訓練されています。）

Google（プロンプト設計戦略、2026年1月8日更新）:

"The most efficient way to customize model behavior is to provide clear, specific instructions."
（モデルの動作をカスタマイズする最も効率的な方法は、明確で具体的な指示を提供することです。）

4.2 Few-shot Prompting -- 通常モデルでは鉄板、推論モデルでは慎重に

通常モデルでは3社が揃って推奨する。Anthropicは「3〜5個の多様で関連性のある例を含めてください」、Googleは最も強い推奨を行い「プロンプトには常にFew-shot例を含めることを推奨します」としている。

ただしGoogleは同時に「例が多すぎるとモデルがオーバーフィットする可能性がある」と警告する。

推論モデルでは状況が異なる。OpenAIの推論モデルベストプラクティスでは明確に:

"Try zero-shot first, then add few-shot examples only if needed."
（まずゼロショットを試し、必要な場合にのみFew-shotを使用してください。）

4.3 Chain-of-Thought -- 最も「場合による」テクニック

通常モデルでは依然として有効。Wharton大学の研究によると平均4〜14%の改善が確認されている。AnthropicのCoTガイドでも推奨されている。

推論モデルでは不要、場合によっては逆効果。

OpenAI（推論モデルベストプラクティス）:

"Prompting for 'think step by step' or 'explain your reasoning' is unnecessary and can sometimes hinder performance."
（「ステップバイステップで考えて」や「推論を説明して」とプロンプトすることは不要であり、パフォーマンスを妨げる場合がある。）

Google（Gemini 3 Developer Guide、2026年1月29日更新）:

"Complex prompt engineering that you may have used to force Chain-of-Thought in earlier models is unnecessary. Set thinking_level: 'high' and simplify your prompt."
（以前のモデルでChain-of-Thoughtを強制するために使っていた複雑なプロンプトエンジニアリングは不要です。thinking_level: "high"を設定してプロンプトをシンプルにしてください。）

Wharton大学のPrompting Science Report 2（2025年6月）では、Gemini Flash 2.5でCoT指示によりパフォーマンスが3.3%低下したことが報告されている。

4.4 ロール/ペルソナ設定 -- 効くが「盛りすぎ」に注意

Anthropicはsystemパラメータによるロール付与を推奨するが、2025年11月のブログでは:

"Modern models are sophisticated enough that heavy persona engineering is often unnecessary. 'You are a helpful assistant' may work better than 'You are a world-renowned expert who speaks only in technical jargon and never makes mistakes.'"
（現代のモデルは十分に洗練されているため、重厚なロール設定は多くの場合不要です。「あなたは親切なアシスタントです」は、「あなたは世界的に有名な専門家で、技術用語のみで話し、間違いは絶対にしません」よりも良い場合が多い。）

OpenAIもGPT-4.1ガイドで推論モデルを「上級の同僚」に喩え、「目標を与えて、詳細は任せてください」という姿勢を推奨している。

4.5 出力フォーマット指定 -- プロンプトよりAPI機能の時代へ

出力フォーマットの指定は3社共通で強く推奨されるが、プロンプト内での指示からAPI機能へ移行が進んでいる。

プロバイダー	API機能	説明
OpenAI	Structured Outputs	「JSON modeの進化版。可能な限りこちらを使用してください」
Google	`response_json_schema`	JSON Schemaで出力形式を保証
Anthropic	`output_config.format`	Claude 4+で導入。Prefillの代替

実装方法がわかったので、次は「かつて有効だった」テクニックの真偽を見ていきます。

8. 死んだテクニック: かつては有効だったが、今は効果が薄れたもの

5.1 「深呼吸して」等の感情的プロンプト

かつて: 2023年、EmotionPrompt論文（Li, Wang他、NeurIPS採択）がBIG-BenchベンチマークでCoTに加えて感情的刺激を与えると最大115%の改善を報告。Google DeepMindのOPRO論文でも「Take a deep breath and work on this problem step by step」がPaLM 2の算数で80.2%を達成（通常のCoTは71.8%）。

今: Dobariya & Kumar（2025年10月）は:

"More advanced LLMs likely process emotional expressions as just string tokens, not as meaningful semantic payloads."
（より高度なLLMは感情的表現を意味的なペイロードではなく、単なる文字列として処理する可能性がある。）

Google Vertex AIは公式に除去を推奨:（公式ドキュメント）

"Remove prompt language that uses emotional appeals, flattery, or artificial pressure."
（感情的なアピール、お世辞、人為的なプレッシャーを使用するプロンプトの言語を除去してください。）

5.2 チップ・脅迫系プロンプト

かつて: 2024年初頭、「ChatGPTにチップを渡すと品質が上がる」がSNSで話題に。Max Woolfの2024年2月の分析ではGPT-3.5でチップ額（$500〜$100K）の効果を統計検証したが、一貫性がなく、「世界平和」「天国への入場」などの抽象的インセンティブが金銭チップを上回る不合理な結果も出た。

今: Wharton大学のPrompting Science Report 3（2025年8月）がGPQAとMMLU-Proベンチマークで厳密に検証:

"Threatening or tipping models does not generally have a significant effect on benchmark performance."
（モデルを脅迫またはチップで報酬を与えることは、ベンチマークパフォーマンスに一般的に有意な影響を与えない。）

Google共同創業者Sergey Brinが2025年5月に「モデルは脅迫すると良い結果を出す」と述べた主張を、この論文が直接反証した形だ。

OpenAIもGPT-4.1ガイドで明記:

"You generally do not need to use ALL-CAPS or incentives like tips or bribes."
（ALL-CAPSやチップ・賄賂などのインセンティブを使用する必要は一般的にありません。）

5.3 過度な丁寧さ（please, thank you）

Wharton大学のPrompting Science Report 1（2025年3月）がGPT-4oとGPT-4o-miniで各条件100回試行した結果:

"The effects of politeness are inconsistent — sometimes helpful, sometimes harmful. At the individual question level effects may exist, but they wash out in aggregate."
（丁寧さの効果は一貫性がなく、時に有効で時に有害。個別の質問レベルでは効果があっても、集計するとウォッシュアウトする。）

さらにDobariya & Kumar（2025年）の追加検証では、GPT-4oで最も無礼なプロンプトが最高正解率（84.8%）を記録し、最も丁寧なプロンプト（80.8%）を上回った。ただし大規模テストでは差が統計的有意性を失った。

結論: 中立的なトーンで十分。丁寧にしても無礼にしても、出力品質は変わらない。

「死んだテクニック」の検証結果を確認したところで、次は「逆効果」になるテクニックを見ていきます。

9. 逆効果なテクニック: やると性能が下がるもの

6.1 ネガティブ指示の乱用（「〜しないでください」）

3社すべてが明確に非推奨。

AnthropicのClaude 4ベストプラクティスで社員のZack Wittenは:

"Being too emphatic about what not to do can create a reverse psychology effect."
（何をしてはいけないかを強く言いすぎると、逆心理効果でかえってその行動を助長することがある。）

具体例:

NG	OK
「マークダウンを使わないでください」	「あなたの回答はスムーズに流れる散文の段落で構成してください」
「専門用語を使わないで」	「高校生にもわかる言葉で説明して」
「長文にしないで」	「200文字以内で回答して」

Google（プロンプト設計戦略）も同様に、「俳句を疑問文で終えないで」より「俳句は常に断定文で終えてください」の方が効果的と例示している。

6.2 推論モデルへのCoT指示（前述の通り）

繰り返しになるが、これは最も多くの人がハマる罠なので強調する。

推論モデルでは「考え方の指示」が干渉を起こす。「ステップバイステップで考えて」をo3やGemini 3 Thinkingに送ると、内蔵の推論プロセスとユーザーの指示が衝突し、かえって品質が下がる。

6.3 Gemini 3でのtemperature変更

Google（Gemini 3 Developer Guide）:

"We strongly recommend leaving the temperature at the default value of 1.0 when using Gemini 3 models."
（Gemini 3モデルを使用する際、temperatureをデフォルト値の1.0のままにすることを強く推奨します。）

temperatureを1.0未満に設定すると、ループや性能劣化などの予期しない動作を引き起こす可能性があると警告されている。

6.4 Claude 4+でのPrefill

AnthropicのClaude 3.xまでは、アシスタント応答の先頭を事前入力する「Prefill」が出力制御の定番テクニックだった。しかしClaude 4以降では400エラーが返る破壊的変更が行われた（マイグレーションガイド）。

代替手段: output_config.formatまたは構造化出力機能を使用する。

6.5 長文コンテキストでのJSON形式入力

OpenAIのGPT-4.1ガイド:

"JSON performed particularly poorly for long-document inputs."
（JSONは長文ドキュメント入力に特に性能が悪かった。）

代わりにXML形式（<doc id='1' title='...'>内容</doc>）やMarkdown形式が推奨されている。

逆効果テクニックの地雷原を回避できたところで、「プロンプトではなく設定でやるべきこと」を整理しましょう。

10. プロンプトではなく「設定」でやるべきこと

各プロバイダーは、プロンプト内の工夫ではなく、プラットフォーム機能やAPIパラメータで制御すべき領域を拡大している。毎回プロンプトに書くのではなく、一度設定すれば全会話に適用される仕組みを活用すべきだ。

7.1 各社の設定機能

# OpenAI
custom_gpts: 反復タスクの指示を保存し、専用ボットとして公開
custom_instructions: 全会話に適用される設定（トーン、出力形式等）
memory: 会話間での情報保持
structured_outputs: JSON出力の型安全な保証（プロンプトでの指示不要に）
prompt_caching: "レイテンシー最大80%、入力トークンコスト最大90%削減"

# Anthropic
claude_projects: 関連文書をプロジェクト単位で管理
system_prompt: ロール設定とツール定義に使用
memory: コンテキスト認識と自然に組み合わせ
prompt_generator: Consoleでプロンプトテンプレートを自動生成
prompt_improver: 既存プロンプトの品質を自動改善

# Google
gems: ペルソナ・タスク・制約・フォーマットの4領域で指示を保存
ai_studio_system_instructions: 反復的なテストと改善が可能
thinking_level: "low" / "medium" / "high" で推論の深さを制御

7.2 「毎回書く」 vs 「一度設定する」の判断基準

内容	毎回書く	一度設定する
タスク固有の指示	○
出力言語・トーン		○（Custom Instructions / Projects）
出力のJSON形式		○（Structured Outputs / response_schema）
ロール/ペルソナ		○（System Prompt / Gems）
過去の会話文脈		○（Memory / Projects）
参考資料の提供	○（都度変わる場合）	○（Projects / RAG）

7.3 APIパラメータ比較表

パラメータ	OpenAI	Anthropic	Google
temperature	0〜2	0〜1（デフォルト1.0）	0〜2（Gemini 3は1.0から変更非推奨）
top_p	核サンプリング	Claude 4+でtemperatureと同時使用不可	デフォルト0.95
推論制御	reasoning_effort（low/med/high/xhigh）	adaptive thinking + effort	thinking_level（minimal〜high）
出力形式	Structured Outputs, verbosity	output_config.format	response_json_schema
キャッシュ	Prompt Caching（コスト90%削減）	Prompt Caching	Context Caching

ここまでで設定の使い分けがわかったところで、構造化プロンプティングの各社対応を確認しましょう。

11. 構造化プロンプティング: XML / Markdown / JSON / YAML の使いどころ

8.1 各社の推奨構造化記法

記法	Claude（Anthropic）	ChatGPT（OpenAI）	Gemini（Google）
XML	従来の最推奨→ 優先度低下中	「よく機能する」長文で推奨	Gemini 3で公式推奨
Markdown	出力に影響する旨の言及	最推奨	推奨（XMLと並列）
JSON	出力形式としてのみ推奨	長文入力には非推奨	API機能での出力制御を推奨
YAML	明示的な推奨なし	「Few-shotをまとめるのに使える」程度	明示的な推奨なし

8.2 XML: Claudeの十八番、だが風向きが変わりつつある

Anthropicは長年XMLタグ（<instructions>, <example>, <document>等）を強く推奨してきた。しかし2025年11月のブログで:

"XML tags were once a recommended way to add structure and clarity to prompts... Modern models have improved in their ability to understand structure without XML tags. For most use cases, clear headings, whitespace, and explicit language are sufficient."
（XMLタグはかつてプロンプトに構造と明確さを加える推奨手法でした…現代のモデルはXMLタグなしでも構造を理解する能力が向上しています。ほとんどのユースケースでは、明確な見出し、空白、明示的な言語で十分です。）

とはいえ、複雑なプロンプト（API利用、大量の参考資料の注入等）ではXMLの効果は依然として健在だ。

8.3 Markdown: OpenAIが最も推す「第一選択」

OpenAIのGPT-4.1ガイドでは:

"We recommend starting with Markdown. Use Markdown titles for major sections and subsections."
（まずMarkdownから始めることを推奨します。メジャーセクションとサブセクションにMarkdownタイトルを使用してください。）

推奨構造:

# Role and Objective（役割と目的）
# Instructions（指示）
## Sub-categories（サブカテゴリ）
# Reasoning Steps（推論ステップ）
# Output Format（出力形式）
# Examples（例）
# Context（コンテキスト）

8.4 JSON: 出力制御はAPI機能へ、入力には不向き

JSONはLLMにとって馴染み深い形式だが、入力として使う場合の限界がGPT-4.1ガイドで明らかにされた。長文ドキュメントのコンテキスト注入にはXMLかMarkdownを使うべきだ。

出力としてのJSON制御は、プロンプトで「JSONで出力して」と書くよりも、各社のAPI機能を使う方が確実:

# OpenAI - Structured Outputs
response = client.chat.completions.create(
    model="gpt-4o",
    response_format={"type": "json_schema", "json_schema": {...}}
)

# Google - Structured Output
response = model.generate_content(
    prompt,
    generation_config={"response_mime_type": "application/json",
                       "response_json_schema": {...}}
)

8.5 実務的な選び方フローチャート

プロンプトの構造化が必要？
├── Claude APIを使っている → XMLタグ（複雑な場合）or Markdown見出し（シンプルな場合）
├── OpenAI APIを使っている → Markdown見出し（第一選択）、長文コンテキストならXML
├── Gemini APIを使っている → XMLタグ or Markdown見出し（一貫していればどちらでも）
└── Web UIで日常利用 → Markdown見出し（最も汎用的）

出力をJSON形式にしたい？
├── API利用 → Structured Outputs / response_json_schema を使う
└── Web UI → プロンプトで「JSON形式で出力して」と明記（構造は具体的に指定）

構造化プロンプティングの選び方がわかったところで、最新の研究動向と「プロンプトエンジニアリングの未来」を確認しましょう。

12. 学習ロードマップ

この記事を読んだ後、次のステップとして以下をおすすめする。

初級者向け（まずはここから）

Anthropic プロンプトエンジニアリング概要 — 最も体系的な入門
OpenAI プロンプトエンジニアリングガイド — 6つの戦術が簡潔にまとまっている
Google プロンプト設計戦略 — Few-shotとCoTの基本

中級者向け（実践に進む）

OpenAI GPT-4.1 Prompting Guide — エージェント的ワークフローとシステムプロンプト設計
Anthropic Claude 4ベストプラクティス — Claude 4世代の最適化手法
Google Gemini 3 Developer Guide — Thinking機能とThought Signatures

上級者向け（さらに深く）

The Prompt Report — 58のプロンプティングテクニックの体系的サーベイ
Wharton Prompting Science Reports — 厳密な実証研究シリーズ
Andrej Karpathyの「コンテキストエンジニアリング」概念 — プロンプトの先にある世界

13. まとめ

この記事では、3大LLMの公式ドキュメントと2024〜2025年の主要研究論文に基づき、プロンプトテクニックを「有効」「無効」「逆効果」に仕分けした。

通常モデルと推論モデルで最適解が異なる — 推論モデルにはCoT指示やFew-shotが逆効果になりうる
チップ・脅迫・感情的アピールは2025年の実証研究で効果なしと確定 — 都市伝説に惑わされないこと
「プロンプトの言い回し」から「コンテキストエンジニアリング」へ — 何の情報をどの順序で提供するかが本質

私の所感

正直なところ、私自身もつい最近まで「深呼吸して」とか「これは私のキャリアにとって重要です」みたいなフレーズをプロンプトに入れていた。効いている気がしていたのは、おそらく確証バイアスだったのだろう。

プロンプトエンジニアリングは「死んだ」わけではないが、独立したスキルから、あらゆるAI関連作業に組み込まれる基礎スキルに変わった。「呪文の達人」を目指すのではなく、「何をどう伝えるか」という本質的なコミュニケーション能力を磨く方が、モデルの世代交代にも耐えうる投資になる。

そしてもう一つ確かなことがある。この記事の内容も、半年後には更新が必要になるだろう。LLMの進化速度は、どんなベストプラクティスよりも速い。

参考文献

公式ドキュメント

研究論文

Li, Wang他, "Large Language Models Understand and Can Be Enhanced by Emotional Stimuli", NeurIPS 2023
Meincke, Mollick他, "Prompting Science Report 2: The Decreasing Value of Chain of Thought", Wharton GAIL, 2025年6月
Schulhoff他, "The Prompt Report: A Systematic Survey of Prompt Engineering Techniques", arXiv, 2024年6月（v6: 2025年2月更新）
Battle & Gollapudi, "The Unreasonable Effectiveness of Eccentric Automatic Prompts", arXiv, 2024年2月

その他の参考情報

OpenAI, "Prompt engineering", OpenAI API Docs
Anthropic, "Be clear, direct, and detailed", Claude Docs
Google, "Prompt design strategies", Gemini API Docs
Max Woolf, "Does Offering ChatGPT a Tip Cause it to Generate Better Text?", 2024年2月

OpenAI, "Reasoning best practices", OpenAI API Docs ↩ ↩² ↩³
Google, "Gemini 3 Developer Guide", Google AI for Developers, 2026年1月29日更新 ↩ ↩² ↩³
Anthropic, "Prompt engineering best practices", Claude Blog, 2025年11月 ↩
Anthropic, "Use XML tags to structure your prompts", Claude Docs ↩
OpenAI, "GPT-4.1 Prompting Guide", OpenAI Cookbook, 2025年4月14日 ↩ ↩²
Anthropic, "Claude 4 best practices", Claude Docs ↩
Dobariya & Kumar, "Mind Your Tone: Investigating How Prompt Politeness Affects LLM Accuracy", arXiv, 2025年10月 ↩
Google Cloud, "Overview of prompting strategies", Vertex AI Docs ↩
Meincke, Mollick, Mollick & Shapiro, "Prompting Science Report 3", SSRN, 2025年8月 ↩ ↩²
Meincke, Mollick他, "Prompting Science Report 1: Prompt Engineering is Complicated and Contingent", arXiv, 2025年3月 ↩
Anthropic, "Migration guide - Migrating to Claude 4", Claude Docs ↩