はじめに — think step by step って、まだ条件反射で書いてませんか？
プロンプトの最後に、こう書いてないでしょうか。
最後に、ステップバイステップで考えてください。
Let's think step by step.
正直に言うと、ちょっと前まではこれが「正解」でした。AIに考える手順を踏ませると、答えの精度が上がる。だから僕らはみんな、おまじないみたいにこの一文を足してきた。
でも、いまの 推論モデル（Reasoning Models） に対しては、この一文がむしろ 逆効果になることがある 。そう聞くと、ちょっとびっくりしませんか。
なんでだと思います？
理由はシンプルで、推論モデルは 「答える前に、頭の中で勝手に考えてくれる」 ようになったからなんです。考える手順を外から指図しなくても、内部で下書きをして、見直して、それから答えを出す。だから「ステップバイステップで考えて」と言うのは、もう自分で段取りできる同僚に、わざわざ「まず手を洗って、次に材料を切って…」と耳元で言い続けるようなもの。ありがた迷惑、というやつです。
ここで本当に大事になってきたのは、プロンプトの細かい言い回しよりも、「どのAIに、どれくらい考えさせるか」を自分で設計すること だと思うんです。速いけど浅いモードもあれば、遅いけど深いモードもある。そのつまみを、タスクごとに回す。
この記事では、
- 「速いAI」と「考えるAI」って、そもそも何が違うのか
- 「考える時間」を選ぶつまみ（reasoning effort / thinking budget）の正体
- 推論モデル向けにプロンプトをどう書き換えるか
- 「考えすぎ」で逆に間違える、という最近わかってきた落とし穴
- タスクを努力レベルに振り分ける、そのまま使えるルーティング設計
を、AI開発にまだ慣れていない方でも追えるように、用語をひとつずつ噛み砕きながら書いていきます。コード例とプロンプト例も、コピペして試せる粒度で置いておきますね。
⚠️ この記事のAPIパラメータ名や設定値は、2026年6月時点の各社ドキュメントを参照した例 です。モデルのバージョンが上がると名前も既定値も変わります。実装前に必ず各社の公式ドキュメントで最新を確認してください。「考え方の枠組み」のほうを持ち帰ってもらえると、長く使えるはずです。
「速いAI」と「考えるAI」は、同じ家族の二人
まず、いちばん土台のところから。
AIのモデルには、ざっくり 二つのタイプ がいると思ってください。
ひとつは、即答型 。質問されたら、ほぼ間を置かずにパッと答える。チャットでサクサク会話できるのはこのタイプです。
もうひとつが、今回の主役、熟考型 = 推論モデル（Reasoning Models） 。こっちは、答える前にいったん 「頭の中で考える時間」 を取ります。質問を受けて、すぐ口を開かずに、内部で「えーと、まずここがこうで、いや待てよ、こっちの可能性もあるな」と下書きをして、検討してから、ようやく答えを返す。
この「頭の中の下書き」のことを、内部思考（thinking / reasoning） と呼びます。そして、答える前にこの考える時間をたっぷり使うやり方を、業界では test-time compute（テストタイム・コンピュート） と言ったりします。直訳すると「推論時の計算」。要は 「答える瞬間に、考えるための計算をどれだけ追加するか」 という話です。難しそうな名前ですけど、中身は「即答するか、ちょっと考え込んでから答えるか」、それだけのことなんです。
身近な例で言うと、職場の二人の同僚を想像してみてください。
- 即答さん: 「これどう思う？」と聞いたら、0.5秒で「あ、それはAでいいと思います」。速い。会話が弾む。ただ、込み入った問題だと、勢いで答えて外すこともある。
- 熟考さん: 同じ質問に「うーん…ちょっと待ってくださいね」と腕を組んで黙り込む。30秒後に「整理すると、論点は3つあって、結論はBです。理由は…」と返してくる。遅い。でも、難しい問題ほど頼りになる。
どっちが偉い、という話じゃないんです。雑談に熟考さんを呼ぶと話が進まないし、経営判断を即答さんだけに任せると怖い 。適材適所、というだけ。
ここで一つ、初めての方が引っかかりやすいポイントを補足します。推論モデルが見せてくれる「考えた跡」、いわゆる 思考トレース（thinking trace） は、デバッグの参考にはなるけど、そのまま信じきっていい監査記録ではありません 。要約されていたり、実際の内部処理と完全に一致しない場合もある。「ふむふむ、こう考えたのね」と眺める分にはいいけれど、「このトレースに書いてあるから絶対正しい」とまでは思わないほうが安全です。このへんは後半の落とし穴でもう一度触れますね。
| 即答型モデル | 熟考型 = 推論モデル | |
|---|---|---|
| 答えるまでの速さ | 速い（低レイテンシ） | 遅い（考える分だけ待つ） |
| コスト | 安いことが多い | 思考のぶんトークンが増えて高くなりがち |
| 得意なこと | 雑談・要約・分類・整形・定型処理 | 多段の推論・難しいデバッグ・設計・長文の整合性チェック |
| 苦手なこと | 込み入った論理・長い手順 | 単純作業（むしろ考えすぎて遅い・外すことも） |
この章のまとめ: 推論モデル＝「答える前に頭の中で下書きしてから答えるAI」。速い即答型と、遅いけど深い熟考型。どっちを呼ぶかが、最初の分かれ道。
「考える時間」を選べる時代になった — 努力のダイヤルの正体
ここからが面白いところです。
少し前までは、「即答型モデル」と「推論モデル」は、別々の製品として選ぶものでした。でも今は、同じモデルの中で「どれくらい考えさせるか」をこっちで指定できる ようになってきています。
僕はこれを 「努力のダイヤル」 と呼んでいます。オーディオのボリュームつまみみたいに、「考える深さ」を低・中・高…と回せるイメージです。低くすれば速くて安い、高くすれば深いけど遅くて高い。
各社で名前は違いますが、考え方は同じです。2026年6月時点の例を並べてみますね。
| 提供元 | つまみの名前（例） | 指定の仕方（例） | メモ |
|---|---|---|---|
| OpenAI（GPT-5系 / GPT-5.5 など） | reasoning_effort |
none / minimal / low / medium / high / xhigh
|
モデルにより使える値が違う。多くで medium あたりが既定。低いほど速く安い |
| Anthropic（Claude） | 拡張思考（thinking） |
budget_tokens（考えるのに使う上限トークン、max_tokens 未満）。新しめの世代では effort（low/medium/high/max 系）も |
思考トレースを要約で見られるのが特徴 |
| Google（Gemini） | thinking_budget |
数値（トークン上限）。-1 で動的（モデルにお任せ）、0 で思考オフ。レベル指定もあり |
既定で動的なモデルが多い |
ここで一番大事な感覚は、「努力は、タダじゃない」 ということです。
熟考さんに30秒考えてもらうと、その30秒ぶんの「考えた言葉」が裏で生成されています。これが 思考トークン で、ふつうにあなたのAPI利用料として課金されるんです。しかも、考えるぶんだけ返事が遅くなる。つまり高いeffortは 「品質を上げる代わりに、お金と時間を払う」 トレードオフ。
だから、ダイヤルを回すときの問いはいつもこうです。
このタスクは、追加でお金と時間を払ってでも、深く考えさせる価値があるか？
雑な分類タスクに high を当てるのは、コンビニにお弁当を買いに行くのにタクシーで往復するようなもの。着くは着くけど、もったいない。逆に、本番のDBスキーマ設計を minimal で即答させるのは、大事な契約書を1秒で書かせるようなもので、これはこれで怖い。
最初の値の決め方としては、
- まずは既定値（多くは
mediumか動的）から始める - 自分のタスクで品質を測ってみる
- 品質が足りない時だけ effort を上げる／速度やコストが気になる時は下げる
という順番がおすすめです。最初から全力（最大effort）に張り付けない。これだけで、無駄な出費とイライラする待ち時間がだいぶ減ります。
この章のまとめ: 「考える深さ」はこっちで選べるダイヤル。でも深く考えさせるほど、トークン代と待ち時間を払う。既定から始めて、必要な時だけ回す。
推論モデルへのプロンプトは「足し算」じゃなくて「引き算」
さて、冒頭の think step by step に話を戻します。
即答型モデルの時代、僕らは プロンプトに「考える手順」を足す ことで精度を上げてきました。「ステップバイステップで」「まず根拠を挙げてから結論を」「いったん深呼吸して」…いわゆる Chain-of-Thought（思考の連鎖、略してCoT） ですね。手順を声に出させることで、モデルが論理を踏み外しにくくなる、という技です。
ところが推論モデルは、その「手順を踏む」工程を 内部で勝手にやってくれる 。だから外から「考えて」と指図すると、
- すでにやってることを二重に指示することになって、冗長
- モデル本来の考え方を、こっちの稚拙な手順で縛ってしまう
- 結果、精度がむしろ落ちることがある
という話になります。OpenAIの推論モデル向けの推奨でも、はっきり 「CoT的な指示（"think step by step" など）は使うな、プロンプトはシンプルに直接的に」 と書かれています（2026年時点）。
つまり、推論モデルへのプロンプトは 「足し算」ではなく「引き算」 。手順を足すのをやめて、ゴール・制約・出力形式 だけをくっきり渡す。「どう考えるか」はモデルに任せて、「何を達成してほしいか」「守ってほしいルール」「どんな形で出してほしいか」 に集中するわけです。
具体例で見てみましょう。
❌ Before（即答型時代のクセが残ったプロンプト）
あなたは優秀なエンジニアです。以下のコードのバグを探してください。
まず、コードを1行ずつ丁寧に読んでください。
次に、考えられる原因をステップバイステップで列挙してください。
それから、深呼吸して、もう一度見直してください。
最後に、慎重に結論を出してください。
[コード]
✅ After（推論モデル向けに引き算したプロンプト）
<task>
次のコードには、特定の入力でクラッシュするバグが1つある。
原因と修正案を示す。
</task>
<constraints>
- 出力は「原因」「該当行」「修正案（差分）」の3項目に分ける
- 推測ではなく、コード上の根拠を該当行とともに示す
</constraints>
<code>
[ここにコード]
</code>
違い、わかりますか。Afterは 「どう考えろ」を一切言っていない 。代わりに、<task> <constraints> <code> という 区切りタグ で「指示」と「材料」をきれいに分けています。この区切り（Markdownの見出しでもXMLっぽいタグでもいい）が、モデルにとって「ここからが命令、ここからが対象データ」の目印になって、誤読を減らしてくれるんです。
ただ、ここで早とちりしないでほしいんです。心配性な僕からひとこと注意を。
これは「推論モデルに対しては」の話です。 世の中の全プロンプトからCoTを消せ、という意味ではありません。即答型モデルを使っているとき、あるいは「あえて手順を踏ませて、その過程を見せてほしい」とき（教育用途や、人間がレビューする前提のとき）は、CoTは今でも立派に有効です。使っているモデルが熟考型かどうかで、足すか引くかを切り替える。そこだけ間違えなければ大丈夫です。
この章のまとめ: 推論モデルには手順を「足さない」。ゴール・制約・出力形式を、区切りで整理して渡す。CoTを消すのは「推論モデルに対しては」の限定ルール。
「考えすぎ」で逆に間違える — inverse scaling という落とし穴
ここまで読むと、「じゃあ難しいタスクは全部 high でいいじゃん」と思うかもしれません。僕も最初そう思ってました。
でも、ここに最近わかってきた、けっこう大事な落とし穴があるんです。
考えさせればさせるほど、精度が上がるとは限らない。 むしろ、考える時間を増やすと 逆に成績が落ちる タスクがある、というのが研究でも示されてきました。
少し名前を出しておくと、Anthropicのチームが中心になった論文「Inverse Scaling in Test-Time Compute」（arXiv:2507.14417、2025年）では、推論を長くするほど精度が下がるタスクを実際に作って見せています。「inverse scaling（逆スケーリング）」というのは、普通は増やせば良くなるはずのもの（考える時間）を増やしたのに、逆に悪くなる という意味です。
何が起きるかというと、
- 正しかった最初の直感を、考えすぎて自分で疑い始める（人間でもありますよね、考え込んで答えを変えて間違えるやつ）
- 無関係な情報や引っかけに固執して、深掘りする方向を間違える
- 長く考えるほど、途中の小さなミスが連鎖して大きくズレる
他にも「Evaluating Over and Underthinking in LLMs」（arXiv:2508.13141、2025年）という研究では、単純な質問に対して700トークン以上も「考えて」、それでいて精度は上がらない（むしろ下がる） ケースが報告されています。簡単な質問には、即答型のほうがよっぽど効率的だった、と。
これ、すごく示唆的だと思うんです。「全力で考える」が常に正義じゃない。 簡単なタスクに高effortを当てるのは、お金と時間を払って、わざわざ精度を下げにいっている可能性すらある。
だからこそ、各社のモデルは 「適応的思考（adaptive thinking）」 ——簡単な問いには勝手に少なく考え、難しい問いには多く考える——という方向に進化しています。そして僕ら使う側がやるべきことは、その適応をさらに助けてあげること。つまり、タスクの難しさに合わせて、努力を配分する設計 です。
この章のまとめ: 高effort＝常に高精度、ではない。簡単なタスクに考えさせすぎると、逆に外す（inverse scaling）。だから「努力をタスクに合わせて配る」設計が要る。
タスクを「努力レベル」に振り分ける — ルーティング設計
ここが、この記事のいちばんの実務パートです。
「考える深さ」をタスクごとに変える、その振り分けのことを ルーティング（routing） と呼びます。荷物を仕分けるイメージですね。来たタスクを見て、「これは即答型でいい」「これは高effortの熟考型へ」と振り分ける。
まず、振り分けの判断軸を持っておくと迷いません。僕が使っているのはこの5つです。
| 判断軸 | 問い | 高effort寄りになる条件 |
|---|---|---|
| 多段性 | 答えに何ステップの推論が要る？ | ステップが多い・依存関係が複雑 |
| 曖昧さ | 問いや仕様がどれだけ曖昧？ | 解釈の余地が大きい・前提が不明 |
| 失敗コスト | 間違えたら何が起きる？ | 本番影響・お金・信用に関わる |
| レイテンシ要件 | どれくらい速さが要る？ | 速さ最優先なら低effort側へ |
| 検証可能性 | 答えを後で確かめられる？ | 検証しにくいほど慎重に（＝高effort寄り） |
この軸でざっくり眺めると、タスクは自然とこんな感じに並びます。
| 努力レベル（例） | 向くタスク | 理由 |
|---|---|---|
minimal / low
|
分類・タグ付け・整形・短い要約・定型抽出 | 単純。考えさせるほど遅く・高く・むしろ外す |
medium（既定） |
通常の実装補助・コードレビュー一次対応・中くらいの要約・ドキュメント生成 | 多くの実務はここで足りる |
high |
アーキテクチャ設計・難しいバグの原因究明・複数ファイルの整合性チェック・移行計画 | 多段で曖昧で失敗コストが高い |
max（稀） |
新規性の高い難問・どうしても精度が要る一発勝負 | コストと時間を払う価値があるときだけ |
ポイントは、「迷ったら medium から始めて、足りない時だけ上げる」 。最初から high に固定しないこと。前の章で見たとおり、簡単なタスクへの過剰な努力は逆効果になりうるので。
そしてもうひとつ、忘れちゃいけない線引き。「どのダイヤルをどう回すか」を決めるのは、人間の仕事 です。AIに「君にどれくらい考えてほしい？」と聞くのは、本質的に変ですよね。努力の配分は設計判断で、ここは人間が握る。AIはそのダイヤルの中で、実際に手を動かして考える係。この役割分担が、たぶん一番大事なところです。
この章のまとめ: 5つの軸（多段性・曖昧さ・失敗コスト・レイテンシ・検証可能性）でタスクを努力レベルに振り分ける。既定から始めて必要な時だけ上げる。ダイヤルを決めるのは人間。
コードで実装する — effort切り替えとルーター
考え方がわかったら、あとは実装です。難しくありません。「タスクの種類を見て、effortを選んで、呼ぶ」だけ。
何度も言いますが、下のコードのパラメータ名・値は 2026年6月時点の例 です。最新は各社の公式ドキュメントで確認してください。雰囲気と構造を持って帰ってもらえれば十分です。コード内の
user_idなどは全部ダミーです。
まずは、努力レベルを切り替えながらモデルを呼ぶイメージ（OpenAI系のResponses APIふう・Python）。
from openai import OpenAI
client = OpenAI()
def ask(task_prompt: str, effort: str = "medium") -> str:
"""task_prompt を、指定した reasoning effort で推論モデルに渡す。
effort は "minimal" / "low" / "medium" / "high" などを想定（モデル依存）。
"""
resp = client.responses.create(
model="gpt-5.5", # 例。使えるモデルは環境に合わせて
reasoning={"effort": effort}, # ← これが「考える深さ」のダイヤル
input=task_prompt,
)
return resp.output_text
# 簡単な分類は浅く、設計レビューは深く
label = ask("次の問い合わせを bug/feature/question に分類して: 「ログインできない」", effort="minimal")
review = ask("次の設計案のリスクと代替案を3点で: ...", effort="high")
次に、Anthropic（Claude）の拡張思考で「考える上限トークン」を渡すイメージ。
import anthropic
client = anthropic.Anthropic()
def ask_claude(task_prompt: str, thinking_budget: int = 4000) -> str:
"""thinking_budget = 内部思考に使ってよい上限トークン（max_tokens 未満にする）。
深く考えさせたいタスクほど大きく、単純タスクは小さく（または拡張思考オフ）。
"""
msg = client.messages.create(
model="claude-opus-4-x", # 例。実際のモデル名は公式docで確認
max_tokens=8000,
thinking={"type": "enabled", "budget_tokens": thinking_budget},
messages=[{"role": "user", "content": task_prompt}],
)
# 返却には思考トレースと最終回答が含まれる。最終回答テキストだけ取り出す
return "".join(b.text for b in msg.content if b.type == "text")
そして本命、ルーター関数 。タスクの種類を受け取って、努力レベルを決めて、呼び分けます。判定ロジックは「まず素朴に」で十分。育てていけばいいんです。
from dataclasses import dataclass
@dataclass
class Task:
kind: str # "classify" / "summarize" / "implement" / "design" / "debug"
high_stakes: bool # 失敗コストが高い（本番影響・課金・公開など）か
latency_critical: bool # 速さ最優先か（オートコンプリート・音声など）
def choose_effort(task: Task) -> str:
"""タスクから reasoning effort を決める素朴なルーター。
迷ったら medium。簡単なものは下げ、難しい/高リスクは上げる。
"""
# 速さ最優先のパスは、まず低effortから
if task.latency_critical:
return "low"
# 単純作業は考えさせすぎない（overthinking 回避）
if task.kind in ("classify", "extract", "format"):
return "minimal"
# 設計・難デバッグ・高リスクは深く
if task.kind in ("design", "debug") or task.high_stakes:
return "high"
# それ以外（通常の実装・要約など）は既定
return "medium"
# 使う側はタスクを記述するだけ。ダイヤルの決定はここに集約される
effort = choose_effort(Task(kind="classify", high_stakes=False, latency_critical=False))
# → "minimal"
このルーターの良いところは、「どのタスクにどれだけ考えさせるか」の判断が、コードの1か所に集まる こと。あちこちのプロンプトに effort="high" が散らばっていると、後で「なんでここ高いんだっけ？」が誰にもわからなくなる。ダイヤルの設計図を1枚にまとめておく、という発想です。
最後に、地味だけど一番効く一言を。effortを変えたら、必ず「品質・コスト・レイテンシ」の3つを測ってください。 「なんとなく high のほうが賢そう」で決めない。簡単な評価でいいので、
# 擬似コード: 同じタスクを effort 違いで回して比べる
for effort in ["minimal", "medium", "high"]:
result = ask(task_prompt, effort=effort)
score = my_eval(result) # 自分のタスク用の採点（正解率など）
print(effort, score, result_tokens, latency_ms)
# → 品質がサチる（頭打ちになる）effort が見つかったら、それが最適点
こうやって「品質が頭打ちになる手前のeffort」を見つけると、払いすぎも、考えさせなさすぎも避けられます。これは前に書いた評価駆動（Eval-Driven）の考え方とも地続きですね。
この章のまとめ: effort切替は「種類を見て選んで呼ぶ」だけ。判断はルーター1か所に集約。変えたら品質・コスト・レイテンシを必ず測る。
そのまま使えるプロンプト例3本
ここは持ち帰り用です。コピペして、[ ] のところだけ埋めて使ってください。どれも 最終判断は人間がする 前提で書いてあります。
プロンプト①: このタスクにどれだけ考えさせるべきか（ルーティング判定）
あなたはAIシステムの設計レビュアーです。
次のタスクについて、推論努力（reasoning effort）の推奨レベルを判定してください。
# 判定軸（各を low/mid/high で評価）
- 多段性（必要な推論ステップ数）
- 曖昧さ（仕様や問いの不確かさ）
- 失敗コスト（間違えたときの影響）
- レイテンシ要件（速さの必要性）
- 検証可能性（答えを後で確かめられるか）
# 対象タスク
[ここにタスクの説明]
# 出力形式
- 各軸の評価（low/mid/high）と一言の根拠
- 推奨 effort（minimal / low / medium / high のいずれか）
- 「ただし最終判断は人間が行う」前提で、判断に迷う点を1つ挙げる
プロンプト②: 即答型クセのプロンプトを推論モデル向けに引き算する
次のプロンプトは、手順を細かく指示する「足し算型」になっています。
推論モデル向けに、内部思考に任せる「引き算型」へ書き換えてください。
# ルール
- "ステップバイステップ" などの思考手順の指示は削除する
- 残すのは「ゴール」「制約」「出力形式」だけにする
- 指示と入力データを、区切り（見出しまたはタグ）で明確に分離する
- 意味を変えない。情報は減らさず、手順指示だけを削る
# 元のプロンプト
[ここに既存プロンプト]
# 出力
- 書き換え後のプロンプト
- 削った要素と、その理由（なぜ推論モデルには不要か）
プロンプト③: effort方針のレビュー（考えすぎ・払いすぎの検知）
あなたはコスト意識の高いSREです。
次の「タスク種別 → effort 設定」の一覧をレビューしてください。
# 観点
- 単純タスクに高い effort を当てていないか（overthinking / コスト過多のリスク）
- 高リスク・多段タスクに低い effort を当てて精度不足になっていないか
- レイテンシが重要な経路に高 effort が紛れていないか
# 現状の設定
[タスク種別と effort の一覧をここに貼る]
# 出力形式
- 見直しを推奨する行と、推奨 effort、理由
- 変更前に必ず計測すべき指標（品質・コスト・レイテンシ）の提案
- 判断が分かれる項目は「人間が決める」と明記する
やりがちな落とし穴6つと、撤退ライン
僕や周りがハマった（ハマりそうになった）やつを、対策つきで並べておきます。
- とりあえず全部マックスeffort → コストとレイテンシが静かに膨らむ。しかも簡単なタスクではむしろ精度が落ちることも。対策: 既定（medium／動的）から始め、品質が足りない時だけ上げる。
- 簡単なタスクに高effortを当てる → inverse scalingで逆に外す。対策: 分類・整形・抽出は minimal/low に固定。
- 推論モデルにCoTを盛る → 「ステップバイステップで」を足して、冗長化＆精度低下。対策: 推論モデルでは手順指示を引き算。CoTは即答型や「過程を見せたい時」に限定。
- 思考トークンの課金とレイテンシを見ていない → 月末に請求を見て青ざめる。対策: effort別にトークン数と応答時間をログに乗せ、定期的に眺める（このへんは可観測性の話と地続き）。
- 思考トレースを鵜呑みにする → 「こう考えたと書いてあるから正しい」と誤解。トレースは要約された説明であって、完全な監査証跡ではない。対策: トレースは参考に留め、最終的な正しさは出力そのものと、別の検証（テスト・人間レビュー）で確かめる。
- effort設定がコード中に散らかる → どこがなぜ高いのか誰も追えない。対策: ルーター関数や設定ファイル1か所に集約し、「なぜこのeffortか」をコメントで残す。
そして、撤退ライン（ここまで来たら一回立ち止まる、という線）も決めておくと安心です。
- effortを上げても品質が改善しない（頭打ち）なら、それ以上上げるのをやめる。問題はモデルの努力量ではなく、プロンプトやコンテキストの設計にある合図。
- コストやレイテンシが許容を超えたら、そのタスクは低effort＋人間レビューの組み合わせに切り替える。
- 失敗が不可逆（本番DB・課金・公開・削除）なタスクは、effortが何であろうと必ず人間の承認ゲートを通す。考える深さの問題ではなく、止められるかの問題なので。
人間とAIの役割分担
最後に、この記事全体を1枚に畳むと、役割分担はこうなります。
| 領域 | 人間が握る | AIに任せる |
|---|---|---|
| モデル選択 | 即答型か推論モデルか、何を使うか決める | 選ばれたモデルで応答を生成する |
| 努力の配分 | どのタスクにどれだけ考えさせるか（ダイヤル設計） | その範囲内で実際に考える |
| プロンプト | ゴール・制約・出力形式を定義する | 形式に沿って中身を埋める |
| 品質評価 | 何を「良い」とするか基準を決める | 候補を出す・自己点検する |
| 検証 | 最終的な正しさを判断する | 根拠やテスト材料を提示する |
| 不可逆な操作 | 承認・停止の最終権限を持つ | 提案までにとどめる |
見てのとおり、「何を・なぜ」は人間、「どう」はAI という線で、きれいに分かれます。努力のダイヤルを設計するのは、まさに「何を・なぜ」の側。ここを手放さないことが、AIに振り回されずにAIを活かすコツだと思うんです。
おわりに — 努力の配分は、未来の自分への思いやり
ここまで、長い記事を読んでくださってありがとうございます。
最後に、ちょっとだけ抽象度を上げた話をさせてください。
「どのAIに、どれだけ考えさせるか」を設計する、という今日のテーマ。これって突き詰めると、「考えるという資源を、どこに配るか」 の話なんですよね。考える力にも、お金にも、時間にも、限りがある。だから全部に全力を注ぐんじゃなくて、本当に深く考える価値があるところに、ちゃんと努力を寄せる 。それ以外は、軽やかに速く片付ける。
これは、AIの設定の話だけじゃなくて、僕らの働き方そのものにも効く考え方だなと思っています。簡単な仕事に必要以上に悩んで時間を溶かすより、ここぞというところに頭を使う。AIに「考えさせない勇気」を持てる人は、たぶん自分の時間の使い方も上手な人です。
そして、こうやって「タスクごとの努力レベル」をルーター1枚に書き出しておくことは、未来の自分とチームへの置き手紙 になります。半年後の自分が「なんでここ high なんだっけ？」と悩まずに済む。新しく入った人が、設計図を見れば判断軸を引き継げる。これって、ちょっとした思いやりだと思うんです。明日の自分が、今日の自分に「あざっす」と言える。そういう小さな積み重ねが、長く効いてくる。
作るコストがどんどん下がっていく時代だからこそ、差がつくのは 「どう作るか」より「何を・どこまで・なぜやるか」を設計する力 のほうかなと。努力のダイヤルを設計するというのは、その力の、すごく具体的な練習台なんだと思います。
最後に、今日からの一歩を4つだけ。
-
いま使っているプロンプトから
think step by step系の一文を1つ消してみる（推論モデルを使っているなら） - 自分のタスクを1つ選んで、effortを minimal / medium / high で回し、品質・コスト・速さを比べる
- 「タスク種別 → effort」の対応を、メモでいいので1枚に書き出す
- 不可逆な操作には、effortと関係なく人間の承認ゲートを置く
小さく試して、自分のタスクで測ってみてください。ダイヤルの最適点は、人それぞれ・タスクそれぞれなので。
それでは、また次の記事で。読んでくれて、あざっす。
この記事の参考にした一次情報・研究（2026年6月時点）:
- OpenAI / Anthropic / Google 各社の reasoning・extended thinking・thinking のドキュメント
- 「Inverse Scaling in Test-Time Compute」(arXiv:2507.14417)
- 「Evaluating Over and Underthinking in LLMs」(arXiv:2508.13141)
- 「Stop Overthinking: A Survey on Efficient Reasoning for LLMs」
※APIの仕様は更新が速い領域です。実装前に必ず最新の公式ドキュメントで確認してください。