Skip to Content
Docs10. LLM 基礎推論モデル(考える時間を使う LLM)

この記事の音声は準備中です。

音声の一覧・再生リストへ

推論モデル(考える時間を使う LLM)

この記事の目的

「応答の前に考える時間を使う」推論モデル(reasoning model)の仕組みの直感と、使いどころ・思考量の制御・プロンプトの変化を、実務判断にできるようになります。ライブラリのあちこちで断片的に触れてきた「thinking」「推論トークン」「reasoning effort」を、1 本にまとめて整理するのが目的です。

対象読者

  • 推論モデルを使うか迷っている、または使っているが「なぜ速い問いで遅く・高くなるのか」を掴みたいエンジニア
  • 「考えさせるモデル」に対して、通常モデルと同じプロンプト・同じ期待で臨んで戸惑っている人

前提知識

本文

概要: 分担と「考える時間」の正体

対象正本本記事
生成の仕組み(次トークン予測)LLM はどうやってテキストを生成するか—
段階的推論(CoT)というプロンプト技法プロンプトエンジニアリングの基礎技法—
どのモデルを選ぶかモデル選定ガイド—
モデル別の具体的な制御方法Claude / OpenAI / Gemini の各ガイド—
推論モデルの仕組みの直感と使いどころ本記事仕組み・効くタスク・思考量制御・overthinking・評価

本記事は 10 章の方針どおり数式を使わず、仕組みの直感と実務判断に絞ります。個別モデルの具体(制御パラメータの名称・思考の見え方)は変化が速いため、モデル別の各プロンプティングガイドと公式ドキュメントに委ねます(TODO)。

仕組みの直感: 答える前に考えを書く

推論モデルは、LLM はどうやってテキストを生成するかで見た「書き出した考察が、以降の予測の条件に加わる」という性質を、製品として組み込んだものです。

  • 通常のモデルでも、指示や例示に応じて中間の考察を書けます
  • 推論モデルは、最終回答の前に中間の推論トークンを使うよう学習・推論処理を調整したモデルです。問題の分解や検証を行う場合がありますが、その手順が常に正しいとは保証されません
  • 段階的推論(chain of thought)を出力するという直感は共通しますが、単にプロンプト技法を内蔵しただけとは限りません。DeepSeek-R1  は、強化学習で検証可能な課題の推論能力を改善した例です

要点は、思考にもトークンを消費することです。推論トークンは通常コストとして課金され、生成に時間がかかります。「考える時間」はタダではありません。

効くタスクと効かないタスク

推論モデルは万能ではなく、向き不向きがあります。

改善を評価する候補少ない思考量との比較が特に必要な候補
多段の推論が要る問題(数学・計画・複雑なデバッグ)単純な事実検索・定型の抽出・分類
検証可能な問題(答えの正しさを確かめられる)低レイテンシが要る対話・大量処理
制約が多く、慎重な検討が要る判断参照先や処理手順が定型化された問い

判断するのは、追加の思考による品質改善が、費用と待ち時間に見合うかです。答えが一意でも数学問題のように推論が必要な場合があり、検索・分類でも制約次第で改善しえます。表だけで採否を決めず、同じ実入力でモデルと思考量を比較します(LLM の能力と限界の由来)。

思考量の制御とコスト・レイテンシ設計

推論モデルでは、どれだけ考えさせるかを制御できるのが一般的です(2026-07 時点)。

  • 思考量の制御: 多くのモデルは「努力(effort)の水準」や「思考の予算」といったパラメータで、考える量を段階的に調整できます。名称・仕様はモデルにより異なります(モデル間の違いと移行(横断比較))
  • コスト・レイテンシとの直結: 思考量を上げるほど、精度は上がりうる一方でトークンコストとレイテンシが増えます。思考量は「精度 ↔ コスト・速度」のつまみです
  • タスクで使い分ける: 難しいタスクには高い思考量を、簡単なタスクには低い思考量(または通常モデル)を割り当てます。全タスクを最大思考量で回すのは、コストの無駄です(レイテンシ最適化・コスト管理)

考えすぎ(overthinking)

思考量を上げれば質が上がる、とは限りません。**考えすぎ(overthinking)**という失敗があります。

  • Chen らの研究  は、対象モデルが単純な問題にも多くの推論資源を使い、追加の便益が小さい場合を報告しています。すべての簡単な問いやモデルで必ず悪化するという結果ではありません
  • 指示が矛盾している・停止条件が曖昧・ツールアクセスが広い場合は、探索量と成功条件を別々に見直します。思考量を増やすことを、曖昧な要件や権限制御の代わりにしません
  • 対策は、思考量を「品質の主ノブ」として上げ続けないことです。タスクに見合った水準を評価で見つけ、上げるのは精度向上が確認できるときだけにします

プロンプトの変化: 必須手順と探索の余地を分ける

推論モデルは、プロンプトの書き方を変えます(プロンプトエンジニアリングの基礎技法の「思考の誘導と推論モデル」の詳解)。

  • 思考指示の効果はモデル別に確かめる: 内部推論を使うモデルに、毎回「ステップバイステップで考えて」と追加する必要があるとは限りません。採用モデルの公式ガイドと自社評価で、指示の有無を比較します
  • 目標・制約・必須手順を明確にする: 計算や調査の探索過程には裁量を持たせられますが、承認・根拠確認・業務規程など守るべき手順は省きません。安全上の条件は実行側でも強制します
  • モデル別に作法が違う: 具体的な制御(思考の促し方・抑え方)はモデルごとに異なります(モデル別の作法は Claude / OpenAI / Gemini の各ガイド)

評価の注意: 思考は見えず、揺れる

推論モデルの評価には固有の注意があります。

  • 思考の非公開: モデルの生の思考は、公開されない・要約でしか見えないことが多いです。「なぜその答えになったか」を思考から追えるとは限りません
  • 再現性: 思考の過程は実行ごとに揺れます。Agent 評価の基礎の複数回実行が、推論モデルではとくに重要です
  • コストと品質を同時に測る: 思考量を変えたときの精度とコスト・レイテンシを両方見ます。「思考量を上げたら精度が 2 ポイント上がったがコストが 3 倍」を見逃さないようにします

実務での注意点

アンチパターン

  • 検索・分類という名称だけで思考量を決める → 制約の複雑さと追加思考の便益を見落とす → 同じ入力で品質・費用・レイテンシを比較する
  • 思考量を常に最大にする → 簡単な問題で overthinking を招き、コスト・レイテンシが暴走する → タスクに見合った思考量を評価で見つける
  • 推論モデルだから必須手順も省く → 承認や業務規程まで裁量に委ねる → 探索の余地と守るべき条件を分ける
  • 通常モデルと同じ低レイテンシを期待する → 思考にトークンと時間を使うため応答が遅い → レイテンシ要件のあるタスクでは思考量を下げるか通常モデルにする
  • 1 回実行で評価する → 思考が揺れるため結果を誤認する → 複数回実行し、コストと品質を同時に測る

チェックリスト

  • 推論モデルを、考える価値のある問題(多段推論・検証可能)に使っている
  • 思考量(effort・予算)をタスクの難易度で使い分けている
  • 思考量を「品質の主ノブ」として上げ続けていない(overthinking を避けている)
  • 目標・制約・出力要件に加え、承認などの必須手順を明示している
  • 思考にもトークンコスト・レイテンシがかかることを見積もりに入れている
  • 複数回実行で評価し、精度とコスト・レイテンシを同時に測っている

関連トピック

参考資料

TODO・未確認事項