生成AIを触っていて、今更ながらちゃんと理解したことがあります。
それが reasoning effort です。
この記事は、自分自身の備忘録も兼ねて、ChatGPTと壁打ちしながら「effortって結局何なのか？」を一つずつ整理した内容をまとめたものです。
普段何となく low や high という言葉は見ていたものの、
effortを上げると、実際に何が増えるのか？
Token代はどう変わるのか？
大型LLMと小型LLMではどう使い分けるのか？
APIではどう指定するのか？
あたりを、きちんと理解できていませんでした。
これまでLLMのコストを考えるときは、
- Input Token
- Output Token
- モデルの単価
くらいを中心に見ていました。
しかしreasoning modelでは、もう一つ重要なものがあります。
**Reasoning Token（推論トークン）**です。
そして effort は、この推論にどの程度の計算量を使うかを調整するパラメータです。
今回整理していて特に面白かったのは、
Modelは「誰に考えてもらうか」、Effortは「その人にどれくらい考えてもらうか」
という2つの軸で考えられることでした。
effortとは
ざっくり言ってしまえば、
LLMに「どれくらい考えさせるか」を指定するパラメータ
です。
例えばOpenAIのreasoning対応モデルでは、モデルによって複数のeffortを指定できます。
GPT-5.6系では、2026年9月時点で次の設定があります。
| effort | イメージ |
|---|---|
none |
推論をほぼ行わない |
low |
軽く考える |
medium |
標準的に考える |
high |
より深く考える |
xhigh |
さらに多く推論する |
max |
最大限の推論量を使う |
ただし、利用できるeffortはモデルによって異なります。
大事なのは、
Highという別の高性能モデルに切り替わるわけではない
ということです。
同じモデルを使ったまま、回答前の推論にどれくらい計算量を割くかを変えています。
ModelとEffortは別の軸
今回、自分の中でかなり理解が進んだのがここでした。
モデルとeffortを、同じ「性能」の話として混ぜて考えてはいけません。
かなり単純化すると、
Model
= 頭そのものの能力
Effort
= その頭にどれくらい考えてもらうか
という違いです。
モデルの能力は単純なパラメータ数だけで決まるわけではなく、
- モデル規模
- 学習方法
- 学習データ
- アーキテクチャ
- 推論能力
などを含めた基礎能力と考えるのがよさそうです。
一方、effortは推論時にどの程度計算量を使わせるかです。
いわゆる test-time compute / inference-time compute の調整に近い考え方です。
東大生に例えると分かりやすかった
自分の場合、人間に例えたらかなり分かりやすくなりました。
あくまで説明のための比喩ですが、
大型LLM
= 東大生
小型LLM
= 一般的な学生
とします。
するとeffortはこうなります。
| 組み合わせ | イメージ |
|---|---|
| Large × Low | 東大生に軽く質問する |
| Large × High | 東大生に「じっくり考えて」とお願いする |
| Small × Low | 一般的な学生に軽く質問する |
| Small × High | 一般的な学生に「時間をかけて考えて」とお願いする |
例えば、
Large × Low
「これどう思う？」
と東大生に聞いて、その場でパッと答えてもらう。
Large × High
「時間を使っていいので、いくつかの可能性を検討して、よく考えて回答してください」
とお願いする。
Small × High
小型モデルであっても、
「もう少しじっくり考えてみて」
と推論量を増やすことで、そのモデルが持っている能力をより引き出せる可能性があります。
この比喩で考えると、
Model = 誰に聞くか
Effort = どれくらい考えてもらうか
という違いがかなり分かりやすくなりました。
エンジンとアクセルとして考えても分かりやすい
もう一つの比喩としては、
Model = エンジン
Effort = アクセル
とも考えられます。
Small Model
= 小型エンジン
Large Model
= 高性能エンジン
Low Effort
= アクセルを軽く踏む
High Effort
= アクセルを深く踏む
なので、
Large × Low
= 高性能エンジンでゆっくり走る
Large × High
= 高性能エンジンの性能をかなり引き出す
Small × High
= 小型エンジンをしっかり回す
というイメージです。
ただし、ここで注意したいのは、
High EffortにしたからSmall ModelがLarge Modelそのものになるわけではない
ということです。
Small Modelが持っていない知識や理解能力まで、effortによって追加されるわけではありません。
あくまで、
そのモデルが持っている能力を、推論時の計算量によってどこまで引き出すか
という話です。
Reasoning Tokenとは
reasoning modelでは、ユーザーに表示される回答を生成する前に内部で推論を行います。
その推論にもTokenが使われます。
例えば、画面に表示される回答が1,000 Tokenだったとしても、
Input 2,000 tokens
Reasoning 10,000 tokens
Final Answer 1,000 tokens
ということがありえます。
つまり、
表示されている回答TokenだけがLLMの計算量ではない
ということです。
OpenAIのResponses APIでは、実際に使用されたReasoning Tokenをusageから確認できます。
usage
├─ input_tokens
└─ output_tokens
└─ output_tokens_details
└─ reasoning_tokens
Reasoning Tokenそのものは画面には表示されませんが、API使用量として存在しています。
effortを上げるとReasoning Tokenが増えやすい
ここまで理解すると、effortとの関係も分かりやすくなります。
つまり、
High effortという高額料金プランがあるわけではありません。
関係としては、
effortを上げる
↓
推論に多くの計算量を使える
↓
Reasoning Tokenが増えやすい
↓
Token消費量が増える
↓
料金も高くなりやすい
となります。
ただし、
low = 1,000 Reasoning Tokens
medium = 5,000 Reasoning Tokens
high = 20,000 Reasoning Tokens
のように固定されているわけではありません。
同じ high であっても、問題が簡単なら比較的少ないReasoning Tokenで終わることもあるでしょうし、複雑な問題ならより多く使う可能性があります。
つまり effort は、
Reasoning Tokenの固定数を指定するパラメータ
ではなく、
どの程度の推論量をモデルに許可・要求するかを調整するパラメータ
として理解するのがよさそうです。
Reasoning Tokenにも料金がかかる
ここも今回ちゃんと理解したポイントでした。
Reasoning Tokenは、
「ユーザーには見えない内部処理だから無料」
ではありません。
OpenAI APIではReasoning Tokenもoutput usageに含まれ、Output Tokenと同じ単価で課金されます。
つまり大まかには、
推論コスト
=
モデルのOutput Token単価
×
Reasoning Token数
です。
これを理解すると、
ModelとEffortの両方が料金に影響する
ことが分かります。
モデルによってReasoning Tokenの単価も違う
例えばGPT-5.6ファミリーでは、2026年9月時点でOutput Token単価は次のようになっています。
| Model | Input / 1M Token | Output / 1M Token |
|---|---|---|
| GPT-5.6 Luna | $0.20 | $1.20 |
| GPT-5.6 Terra | $2.00 | $12.00 |
| GPT-5.6 Sol | $4.00 | $20.00 |
Reasoning TokenはOutput側として課金されるため、仮に10,000 Reasoning Tokensを使用した場合、推論部分だけを単純計算すると、
| Model | 10,000 Reasoning Tokens |
|---|---|
| Luna | 約 $0.012 |
| Terra | 約 $0.12 |
| Sol | 約 $0.20 |
となります。
もちろん実際のAPI料金には、
- Input Token
- Reasoning Token
- 最終回答のOutput Token
- Tool利用料金など
も加わります。
ですが、この表を見ると、
同じ10,000 Reasoning Tokensでも、どのモデルで考えさせるかによって料金が違う
ことが分かります。
Small × High と Large × Low、どちらがいいのか
ここが今回、一番面白いと感じたところです。
例えば、
Small Model × High Effort
vs
Large Model × Low Effort
があります。
先ほどの人間の例なら、
一般的な学生に30分考えてもらう
vs
東大生に数分で答えてもらう
のような比較です。
どちらが良いかは一概には言えません。
例えばあるタスクで、
| 構成 | Quality | Cost | Latency |
|---|---|---|---|
| Small × High | 90 | $ | 遅い |
| Large × Low | 93 | $$ | 速い |
だったとします。
この場合、品質差が小さいならSmall × Highのほうがコスト効率が良いかもしれません。
逆に、
| 構成 | Quality | Cost | Latency |
|---|---|---|---|
| Small × High | 75 | $ | 遅い |
| Large × Low | 95 | $$ | 速い |
なら、Large × Lowを使ったほうが良さそうです。
つまり、
大型モデルを使えば正解
High Effortにすれば正解
ではなく、
Model
×
Effort
×
Quality
×
Cost
×
Latency
を実際のタスクで評価する必要があります。
effortは「自己レビュー機能」なのか？
ここもChatGPTと壁打ちしていて疑問に思ったところです。
High Effortというのは、
回答を作る
↓
自分でレビューする
↓
修正する
↓
もう一度レビューする
というループを増やしているのではないか？
と最初は考えました。
感覚としてはそれほど外れていないと思います。
推論量を増やすことで、
- 別の可能性を検討する
- 条件の矛盾を考える
- 解法を比較する
- 結論を再検討する
といった処理に、より多くの計算量を使える可能性があります。
ただし重要なのは、
High Effort = 必ず自己レビューをN回実行する
という仕様ではないことです。
内部で具体的にどのような推論手順を取るかはモデル側に任されています。
そのため、開発者側から見ると、
High Effort = より多く考える余地をモデルに与える
くらいに捉えるのがよさそうです。
EffortとAgentのReview Loopは別物
ここはAgentを設計するうえで大事だと思いました。
High Effort
LLM内部により多くの推論計算を使わせます。
一方、
Review Loop
こちらはアプリケーション側で、
- Generate
- Review
- Revise
という処理を明示的に行います。
つまり、
Effort
= LLM内部の推論量を増やす
Review Loop
= 外部のオーケストレーションで再評価させる
という違いです。
正確性が非常に重要な処理なら、
Large Model
×
High Effort
×
Reviewer Agent
という組み合わせもあり得ます。
APIではeffortを指定できる
OpenAI Responses APIなら、例えば次のように指定できます。
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-5.6",
input: "このシステムアーキテクチャをレビューしてください",
reasoning: {
effort: "low",
},
});
console.log(response.output_text);
より深く考えさせたいなら、
reasoning: {
effort: "high",
}
と変更できます。
同じモデルであっても、リクエストによってeffortを変更できます。
実際にReasoning Tokenを計測する
実運用ではeffortを設定するだけではなく、
実際に何Token使ったか
を記録したほうがよさそうです。
例えば、
const response = await client.responses.create({
model: "gpt-5.6",
input: prompt,
reasoning: {
effort: "high",
},
});
console.log(
response.usage?.output_tokens_details?.reasoning_tokens
);
のようにusageを見ることで、
Task
Model
Effort
Input Tokens
Reasoning Tokens
Output Tokens
Latency
Cost
Quality
などを記録できます。
これはLLMOpsでも重要なデータになりそうです。
effortと回答の長さは別物
ここも最初は少し混同していました。
effort は、
どれくらい考えるか
です。
一方でverbosityなどは、
どれくらい詳しく回答するか
です。
つまり、
Reasoning Effort
│
└── どれくらい考える？
Verbosity
│
└── どれくらい詳しく回答する？
Max Output Tokens
│
└── 最大出力量はいくつ？
という別の軸です。
そのため、
内部ではしっかり考えるが、ユーザーへの回答は短くする
という構成もできます。
LangChainやADKなら動的に変更できる
ここからエージェント開発として面白くなります。
LangChainなどのオーケストレーション層を使えば、タスクの種類や難易度に応じてeffortを変えられます。
例えば、
| タスク | Model | Effort |
|---|---|---|
| 文書分類 | Small | Low |
| 要約 | Small | Low |
| 通常QA | Small | Medium |
| コードレビュー | Small / Large | Medium |
| 障害原因分析 | Large | High |
| 複雑なアーキテクチャ設計 | Large | High |
といったルーティングが考えられます。
LangChainではreasoning effortをモデル呼び出し時の設定として渡せるため、タスク分類結果に応じて変更できます。
ADKのようなAgent Frameworkでも、モデル呼び出し前の処理やルーティングを使い、タスクに応じてモデルや設定を切り替える設計が可能です。
Model RoutingだけではなくEffort Routing
これまでAgentのコスト最適化というと、
簡単な仕事
↓
Small Model
難しい仕事
↓
Large Model
という Model Routing を考えることが多かったです。
しかしeffortという軸を加えると、選択肢が増えます。
つまり、
Model × Effort × Tool
で実行戦略を決められます。
さらに今回の整理を加えるなら、
Model × Effort × Review Loop
という軸もありそうです。
最初からHighにしないという設計
すべての処理を最初からLarge Model × High Effortで実行したら、品質は高くなりやすい一方、コストもLatencyも増えてしまいます。
そこで、
のようなEscalationも考えられます。
例えば、
Small × Low
↓
品質不足
Small × High
↓
まだ不足
Large × Medium
↓
まだ不足
Large × High
と段階的に上げていく方式です。
これは人間の仕事にも少し似ています。
最初からすべての問題を専門家に1時間考えてもらうのではなく、
- まず軽く判断する
- 難しければ時間をかける
- それでも難しければ、より能力の高い人にエスカレーションする
という形です。
エージェント設計として考えると
今回effortを理解して、自分の中ではAgent実行を次のように捉えるようになりました。
単純に、
「どのLLMを使うか」
だけではなく、
「そのLLMにどれだけ考えさせるか」
までオーケストレーションする。
さらに必要なら、
「回答を別Agentにレビューさせるか」
まで判断する。
これからAgentを作るうえで、この考え方はかなり重要そうです。
コストを見るならReasoning Tokenも観測する
運用するなら、最低でも次の情報は記録してみたいと思いました。
| Metric | 用途 |
|---|---|
| Model | 使用モデル |
| Effort | low / medium / highなど |
| Input Tokens | 入力コスト |
| Reasoning Tokens | 推論コスト |
| Visible Output Tokens | 回答量 |
| Latency | ユーザー体験 |
| Result Quality | 回答品質 |
| Task Type | タスク分類 |
| Review Count | Review Loop回数 |
例えば、
Architecture Review
Model: Large
Effort: High
平均 Reasoning Token: 18,000
Quality: 94
Cost: 高い
だったものを、
Model: Large
Effort: Medium
平均 Reasoning Token: 6,000
Quality: 93
Cost: 大幅低下
とできるなら、Mediumのほうが合理的です。
あるいは、
Small × High
Quality: 92
Cost: $1
Large × Low
Quality: 93
Cost: $5
なら、用途によってはSmall × Highを選ぶこともできます。
つまり、
effortは設定値というより、観測・評価・最適化する対象
として考えたほうがよさそうです。
今回理解したこと
今回の壁打ちを通して、自分の中では最終的にこう整理できました。
| 項目 | 自分なりの理解 |
|---|---|
| Model | 誰に考えてもらうか |
| Model性能 | そのモデルが元々持つ能力 |
| Effort | どれくらいじっくり考えてもらうか |
| Reasoning Token | その「考える」ために消費するToken |
| High Effort | 推論量を増やす方向の設定 |
| Cost | Model単価 × 使用Token量 |
| Small × High | 小型モデルにじっくり考えさせる |
| Large × Low | 高性能モデルに軽く考えさせる |
| Review Loop | 回答後に外部から明示的に再評価する |
| Agent | Model × Effort × Tool × Reviewを最適化 |
特に自分の中でしっくりきたのは、
Modelは「誰に考えてもらうか」、Effortは「どれくらい考えてもらうか」、Costは「その人の単価 × 考えた量」
という整理でした。
かなり乱暴な比喩ですが、理解するには分かりやすかったです。
まとめ
今更ながらreasoning effortをちゃんと理解しました。
最初は単に、
LowよりHighのほうが賢く回答してくれる
くらいの理解でした。
しかし実際には、
Model
↓
そもそもの能力を選ぶ
Effort
↓
推論に使う計算量を選ぶ
Reasoning Token
↓
実際に使った推論量として現れる
Cost
↓
モデルのToken単価 × 使用Token数
Review Loop
↓
必要なら外部からもう一度評価させる
という別々の概念として考えたほうが分かりやすそうです。
そしてAgentを設計するなら、
Task
↓
Difficulty Classification
↓
Model Routing
↓
Effort Routing
↓
Tool Routing
↓
Execution
↓
Evaluation
↓
必要なら
Model / Effort / ReviewをEscalation
という流れが考えられます。
全部をLarge × Highで実行するのではなく、
簡単な処理は安く・速く、必要なところだけ良いモデルに深く考えてもらう
という設計が、品質・コスト・Latencyのバランスを取るうえで重要なのだと思います。
そして最終的には、
Small × Highが良いのか、Large × Lowが良いのかは、実際のタスクでEvalして決める。
ここまで含めて、reasoning effortの使い方なのかなと理解しました。
※この記事は、生成AIの effort について自分が理解した内容を残しておくための備忘録です。内容の整理や疑問点の深掘りは、ChatGPTと壁打ちしながら作成しました。
また、モデル仕様・利用可能なeffort・Token単価などは変更される可能性があります。実際に利用する際は、各サービスの最新ドキュメントをご確認ください。