思考深度をタスクに合わせる（Matching Thinking Depth to the Task）
思考量は無料ではない — 深く考えるほどトークンを吐き、費用と遅延に変わる。だが一つの深さを全部のタスクに当てれば、易しい仕事では払いすぎ、難所では考えが足りない。下げる話であると同時に、上げる話である。
問題
誤字を1つ直す指示にも、アーキテクチャの分岐を決める指示にも、エージェントは同じ深さで考える。既定の思考量は、一つの段に固定されているからである。ところがタスクの難しさは一つではない。
易しい側では考えすぎた分が費用と遅延に変わり（深度を上げるほど thinking tokens が増え、AI クレジット消費と遅延の両方が増えることは公式が明記している — 公式、VS Code。出典は具体例節）、難しい側では足りない分が誤った設計として残る。どちらも損失だが、痛み方が違う。
払いすぎは請求書に出るので、放っておいても気づく。考え足りないほうは、間違った答えが平然と返ってくるだけなので、気づく手がかりがない。
コンテキスト
適用する条件:
- タスクの難易度に幅がある — 同じリポジトリ、同じ一日のうちに、雑務と難所が混ざる
- 費用や遅延が実際に気になっている — 深度は支出であり、支出が気にならないなら調整する動機もない
- 難所で明らかに考えが足りていない — これが「上げる側」の適用条件である。下げる側だけが本パターンではない
適用しないケース:
- ⚠ 既定で足りているとき。 公式は「For most use cases, the defaults work well」「For most tasks, the defaults are sufficient」と、2つの別々の資料で明言している（公式、VS Code。出典は具体例節）。本パターンは「常に調整せよ」ではない。 既定を動かす理由が言えないなら動かさない
- 道具の自動判定が届いている領域。 既定のままでも、目の前の一手の複雑さに応じて考える量が自動で加減される面がある（公式、VS Code。出典は具体例節）。そこへ手で介入しても、うまくいけば同じ結果、外せば悪化する
- そもそもつまみが無いとき。 推論モデルでなければ、深度を選ぶ UI 自体が現れない面がある（公式、VS Code。出典は具体例節）
隣接パターンとの境界:
- 前置きを壊さない（キャッシュ） — ⚠ 本パターンが動かすつまみは、同パターンが「開始前に固定せよ」と名指しする物そのものである。 公式のキャッシュ助言は、セッション中に reasoning effort を切り替えるとキャッシュが作り直されると逐語で書いている（公式、VS Code。出典は具体例節）
- 委譲の損益分岐 — 同パターンは誰にやらせるかの値札、本パターンはどれだけ考えさせるかの値札。交点はサブエージェント単位の段の指定である（具体例節）
- 計画の先制検証 — 同パターンは計画を実行前に検証する型。本パターンから見れば、そこは公式が深度を上げてよい場面として名指しした2つのうちの一方（architectural planning）に当たる位相である（公式、VS Code。出典は具体例節）
- 読み捨ての隔離 — どこで読むかが同パターン、そこでどれだけ考えさせるかが本パターンである。隔離した先の深度は、主と別に決められる（具体例節）
解決
なぜ効くのか。思考深度は設定ではなく支出である。 つまみを一段上げることは、設定を変えることではなく、毎リクエストの支払いを増やすことである。公式が因果として書いているのはこの向きだけである — 深度を上げれば thinking tokens が増え、クレジット消費と遅延が増える（公式、VS Code。出典は具体例節）。
支出である以上、一つの値に固定するのが最も損になる。 図の対角線が「合っている」線である。難しいタスクほど、割に合う深度も上がる。ところが既定は一本の縦線である — 難易度が動いても深度は動かない。縦線と対角線が交わるのは一点だけであり、つまり固定の既定が当たっているのはちょうどその難しさのタスクだけである。それ以外はすべて対角線から外れている。
外れ方は2つあり、痛み方が非対称である。 右下（易しいのに深い）は費用と遅延の無駄になる。左上（難しいのに浅い）は品質の損失になる。本パターンが「節約の型」だと誤読されるのは、右下の損失だけが請求書に出るからである。 左上の損失は、間違った答えが普通の顔で返ってくる形をしていて、測る手立てがない。測れる損失だけを見て最適化すれば、測れない損失のほうへ寄っていく。
ここまでなら「タスクごとに手で選べ」で話は終わる。ところが、道具は既にこれを部分的にやっている。 既定のままでも、目の前の一手の複雑さに応じて考える量がある程度は自動で加減され、公式は「たいていの用途では既定でうまくいく」と明言している（公式、VS Code。出典は具体例節）。「常に手で最適化せよ」と書くことは、この 公式 と正面衝突する。 本パターンの守備範囲は、そこまで広くない。
残るのは、自動判定が構造上見ていないところである。自動判定が見ると公式が書いているのは、目の前の一手の複雑さである。見ていないのは:
- 位相 — いまが計画なのか実装なのかは、一手には書かれていない。計画の誤りは後続のすべてに波及するが、その波及は目の前の要求の複雑さには現れない
- 代償 — 「この関数の名前を全体で変えて」は、要求として単純で、間違えたときの被害が大きい。複雑さと重大さは、別の量である
- 構造 — 同じ段を何十ものサブエージェントに配れば、段の差はその数だけ掛かる。一手ごとの判定は、その掛け算を見ていない
つまり本パターンは、一手より大きい単位で深度を決めることである。合わせる相手は「この要求」ではなく、位相・代償・構造である。そこが自動判定の届かない場所であり、同時に、人間しか知らない情報が乗っている場所でもある。
トレードオフ
利点
- 難所に思考を寄せられる。 全部に薄く配るのをやめれば、同じ支出で難所に厚く配れる。公式が「上げてよい場面」として名指ししているのは architectural planning と multi-step debugging の2つであり（公式、VS Code。出典は具体例節）、どちらも一手ではなく位相の名前である。
- 易しい作業で費用と遅延を払わずに済む。 深度は費用だけでなく遅延にも効く（公式、VS Code。出典は具体例節）。雑務の速さは、支出の帳尻とは別に、そのまま体感に返る。
代償
- 切り替えは前置きを壊す。 公式のキャッシュ助言は、セッション中に reasoning effort を切り替えるとキャッシュが作り直されると名指ししている（公式、VS Code。出典は具体例節）。本パターンのつまみは、キャッシュの側から見れば「開始前に固定すべきもの」の筆頭に挙がっている。 頻繁に上げ下げすれば、節約した分を前置きの再計算で失いうる。本カタログはこの緊張を解かない — 解けると書ける根拠を持っていない。
- 支出の増加は確実で、改善は条件付きである。 本カタログが引いた範囲の 公式 は、費用の側を因果で書く（深度 ↑ → thinking tokens ↑ → クレジット消費 ↑）。一方、品質の側は「genuinely complex なタスクにだけ上げよ」という条件付きの助言にとどまる。上げれば良くなる、という因果では書かれていない。 上げる判断は、この非対称を承知の上で行う。
GitHub Copilot での具体例
Copilot は単一の製品ではない。思考深度のつまみは VS Code と Copilot CLI の双方にあるが、呼称も、指定する場所も、段の上限も、面によって違う。
VS Code — モデルピッカーから選ぶ
出典: Language models（取得日: 2026-07-16）公式:
Some models support configurable thinking effort, which controls how much reasoning the model applies to each request.
〔訳〕一部のモデルは設定可能な thinking effort をサポートしており、これがモデルが各リクエストに適用する推論の量を制御する。
By default, VS Code sets recommended effort levels and has adaptive reasoning enabled, where the model dynamically determines how much to think based on the complexity of each request. For most use cases, the defaults work well.
〔訳〕既定では、VS Code は推奨の effort レベルを設定し、adaptive reasoning を有効にしている。これによりモデルは各リクエストの複雑さに基づいてどれだけ考えるかを動的に決める。たいていの用途では既定でうまくいく。
Higher thinking effort produces more thinking tokens, which increases AI credit consumption. Only increase thinking effort for genuinely complex tasks.
〔訳〕thinking effort を高くするほど thinking tokens が増え、AI クレジット消費が増える。本当に複雑なタスクにだけ thinking effort を上げること。
Non-reasoning models, such as GPT-4.1 and GPT-4o, do not show the thinking effort submenu.
〔訳〕GPT-4.1 や GPT-4o のような非推論モデルには、thinking effort のサブメニューが表示されない。
VS Code はこれを thinking effort と呼び、設定はモデルピッカーの Thinking Effort サブメニューから行う（原文は設定項目としての指定を deprecated と述べ、モデルピッカーから直接設定するよう指示している）。推論モデルでなければ、そのサブメニュー自体が出ない。
既定では adaptive reasoning が有効で、モデルが各リクエストの複雑さに応じて考える量を決める。「解決」で述べた自動判定がこれである — 公式が「見て決める」と書いている対象は the complexity of each request、目の前の一手であって、位相でも代償でもない。費用のほうは因果で書かれている（深度 ↑ → thinking tokens ↑ → AI クレジット消費 ↑）が、品質は「genuinely complex なタスクにだけ上げよ」という条件付きの助言にとどまる。この非対称は「トレードオフ」で扱う。
VS Code — 費用のどこに効き、どこで上げてよいか
出典: Language models（Agents concepts）（取得日: 2026-07-16）公式:
Different models consume AI credits at different rates, based on the model and the number of tokens processed. More capable models cost more per token, while lighter models extend your usage further.
〔訳〕異なるモデルは、そのモデルと処理されるトークン数に応じて、異なるレートで AI クレジットを消費する。より高性能なモデルはトークンあたりの費用が高く、より軽量なモデルは利用可能量をより長く延ばす。
Other factors also affect credit consumption, such as thinking effort (higher effort produces more thinking tokens), context window size, and tool usage. Prompt caching lowers the effective cost of a request by reusing tokens from a previous one.
〔訳〕クレジット消費には他の要因も影響する。thinking effort(effort が高いほど thinking tokens が増える)、コンテキストウィンドウのサイズ、ツール使用などである。Prompt caching は、直前のリクエストのトークンを再利用することで、リクエストの実効費用を下げる。
費用の本体はモデル単価 × 処理トークン数であり、thinking effort はそこに効く要因の一つである（other factors ... such as）。コンテキスト長とツール使用が同列に並んでいる。深度だけが費用を決めるわけではない — 深度を下げても、コンテキストが膨らんでいれば費用は下がらない。本パターンだけで費用の話が閉じると読まないこと。
出典: Optimize your AI usage（取得日: 2026-07-16）公式:
Higher effort levels produce more thinking tokens, which increases both latency and credit consumption. VS Code sets default effort levels based on evaluations and has adaptive reasoning enabled ... For most tasks, the defaults are sufficient. Only increase thinking effort for genuinely complex problems like architectural planning or multi-step debugging.
〔訳〕effort レベルを高くするほど thinking tokens が増え、遅延とクレジット消費の両方が増える。VS Code は評価に基づいて既定の effort レベルを設定しており、adaptive reasoning を有効にしている……たいていのタスクでは既定で十分である。architectural planning や multi-step debugging のような本当に複雑な問題にだけ、thinking effort を上げること。
深度は費用と遅延の両方に効く。「たいていは既定で十分」が、前掲とは別の資料で二度目に現れる。そして上げてよい場面として名指しされているのは architectural planning と multi-step debugging — どちらも一手の名前ではなく、位相の名前である。 公式の助言そのものが、一手より大きい単位を指している。
VS Code — キャッシュ側から見た、同じつまみ
出典: Cache Explorer（取得日: 2026-07-16）公式:
- Lock in settings before you start: Switching the model, reasoning effort, context size, or the enabled tools and MCP servers during a session rebuilds the cache. Choose them upfront, or use auto model selection, which switches models only at cache boundaries.
〔訳〕開始前に設定を固定する: セッション中にモデル・reasoning effort・コンテキストサイズ・有効なツールや MCP サーバーを切り替えるとキャッシュが作り直される。それらは事前に選ぶか、キャッシュの境界でのみモデルを切り替える auto model selection を使う。
本パターンが動かすつまみが、逐語で名指しされている（Switching the model, reasoning effort, ...）。セッション中に切り替えればキャッシュは作り直される。公式の助言は「開始前に選べ」（Choose them upfront）である。「タスクに合わせて変える」と「開始前に固定する」は、同じセッションの中では両立しない。
Copilot CLI — フラグは max まで、設定キーは xhigh まで
出典: CLI command reference（取得日: 2026-07-16）公式:
|
--effort=LEVEL,--reasoning-effort=LEVEL| Set the reasoning effort level (low,medium,high,xhigh,max).maxis the highest-depth tier for Anthropic models. |〔訳〕
--effort/--reasoning-effortフラグで reasoning effort レベル(low・medium・high・xhigh・max)を設定できる。maxは Anthropic 系モデル向けの最深レベルである。
対する設定キー（出典: CLI config dir reference、取得日: 2026-07-16）公式:
|
effortLevel|string|"medium"| Reasoning effort level for extended thinking:"low","medium","high", or"xhigh". Higher levels use more compute. |〔訳〕設定キー
effortLevel(既定値"medium")は、extended thinking の reasoning effort レベルを"low"・"medium"・"high"・"xhigh"から指定する。レベルが高いほど計算量が増える。
CLI はこれを reasoning effort と呼ぶ。同じ製品の中で、起動時のフラグは5段を挙げて max を受理し、設定キーは4段しか挙げていない（既定は "medium"）。なお CLI 面での費用の言い方は「Higher levels use more compute」〔訳: レベルが高いほど計算量を多く使う〕であり、VS Code 面の thinking tokens とクレジットの因果とは、別の書かれ方をしている。
AI クレジットの説明も、面が変われば変わる（出典: Running tasks in parallel with the /fleet command、取得日: 2026-07-16）公式:
GitHub AI Credits usage: When you submit a prompt in the CLI and Copilot interacts with the selected large language model (LLM) to generate a response, this consumes GitHub AI Credits. More interactions with the LLM result in a higher consumption of GitHub AI Credits.
〔訳〕GitHub AI Credits の使用: CLI でプロンプトを送信し、Copilot が選択された大規模言語モデル(LLM)とやり取りして応答を生成すると、GitHub AI Credits が消費される。LLM とのやり取りが多いほど、GitHub AI Credits の消費は増える。
CLI 面で公式が挙げる消費の経路は LLM とのやり取りの回数、VS Code 面が挙げるのは thinking tokens である。矛盾ではない — 本カタログはこれを、処理トークンが増える経路を別の側から述べたものと読む。ただし面を伏せて「AI クレジットは thinking tokens に連動する」と一般化すると、どちらの原文とも一致しない記述になる。 深度で費用が動くと公式が書いているのは、確認できた範囲では VS Code 面である。
Claude Code との比較 — 似ているが、同じではない
他ツールの対応物を、ツール名と出典を明記した比較として置く。Claude Code は Copilot CLI と同じ effortLevel という設定キー名を使う（出典: Model configuration、取得日: 2026-07-16）公式:
Settings: set
effortLeveltolow,medium,high, orxhighin your settings file.maxandultracodeare session-only and are not accepted here〔訳〕設定: 設定ファイルで
effortLevelにlow・medium・high・xhighのいずれかを設定する。maxとultracodeはセッション限りであり、ここには設定できない。
設定キーの名前が同じ、段の集合も同じ、最上段が設定ファイルに入らないところまで同じである。別のベンダーの別の製品が、ここまで同じ形をしている。しかし「同じ構造」と一括りにすると、Claude Code について不正確になる 公式:
maxprovides the deepest reasoning with no constraint on token spending and applies to the current session only, except when set through theCLAUDE_CODE_EFFORT_LEVELenvironment variable.〔訳〕
maxはトークン支出に制約のない最も深い推論を提供し、現在のセッションのみに適用される。ただし環境変数CLAUDE_CODE_EFFORT_LEVEL経由で設定した場合は例外となる。
共通で言えるのは「設定ファイルには最上段を書けない」までである
Copilot CLI の設定キーは low〜xhigh の4段を列挙する形で、Claude Code の設定キーは max を名指しで排除する形（are not accepted here）で、同じ上限に着地している。ここまでは共通の事実として書ける。
その先が違う。 Claude Code の max は「セッション限り」に例外が明示されている — 環境変数 CLAUDE_CODE_EFFORT_LEVEL 経由なら、そうではなくなる。したがって**「最上段は実行時のみ」と両ツールをまとめて書くと、Claude Code について誤りになる。**
同じ設定キー名を持つ2製品ですら、上限の外し方が違う。「似ている」と「同じ」の間には、原文1文ぶんの距離がある。
面による違い
| 面 | 公式の呼称 | どこで段を選ぶか |
|---|---|---|
| VS Code | thinking effort（キャッシュの資料では reasoning effort） | モデルピッカーの Thinking Effort サブメニュー。推論モデルでなければサブメニューが出ない |
| Copilot CLI | reasoning effort | 起動時のフラグ（max まで受理）／設定キー effortLevel（xhigh まで・既定 medium） |
| Claude Code（他ツール比較） | effortLevel / effort | 設定ファイル（xhigh まで）／環境変数（max の例外）／skill・subagent の frontmatter |
機構としては同じ「思考の量を段で選ぶ」でありながら、呼称も、指定する場所も、段の上限も違う。「Copilot では effort を設定できる」という一括りの記述は、この差を残らず消してしまう。
サブエージェント単位で段を変える
「一手より大きい単位で深度を決める」という「解決」の主張に、2つのツールが別々に機構を与えている。Copilot CLI（上記 config dir reference）公式:
|
subagents.agents|object|{}| Per-agent model configuration, keyed by agent name. Each value is an object with optionalmodel(string),effortLevel(string), andcontextTier("default","long_context", or"inherit") fields. Set any field to"inherit"to use the parent session's value at dispatch time. … |〔訳〕設定キー
subagents.agentsは、エージェント名をキーとするエージェント単位のモデル設定である。各値はmodel・effortLevel・contextTier("default"・"long_context"・"inherit")を任意で持つオブジェクトで、いずれかのフィールドを"inherit"にすると、ディスパッチ時点の親セッションの値を使う。
Claude Code（上記 model-config）公式:
Skill and subagent frontmatter: set
effortin a skill or subagent markdown file to override the effort level when that skill or subagent runs〔訳〕Skill と subagent の frontmatter: skill または subagent の markdown ファイルで
effortを設定すると、その skill や subagent が実行されるときの effort レベルを上書きできる。
深度をセッションに一つ持つのではなく、役割ごとに持たせる形である。 調べ物のエージェントは浅く、設計を任せるエージェントは深く、と書ける。道具固有の芸ではなく、別々のベンダーの2製品で同じ形が成立している箇所である。
別名
| 呼称 | 出典 |
|---|---|
| Reasoning effort | 一次 — Copilot CLI 公式の呼称（フラグ --reasoning-effort、設定キー effortLevel）。VS Code のキャッシュの資料もこの語を使う（出典は具体例節） |
| Thinking effort | 一次 — VS Code 公式の呼称（モデルピッカーの Thinking Effort サブメニュー）（出典は具体例節） |
| Adaptive reasoning | 一次 — VS Code 公式の呼称。⚠ ただし道具が自動でやることの名であり、本パターンの名ではない（下記）（出典は具体例節） |
| 思考深度をタスクに合わせる / Matching Thinking Depth to the Task | 記述 — 本カタログの記述的呼称であり、一次資料に出典は無い |
同じ概念に、面ごとに違う一次呼称がある。 Copilot CLI は reasoning effort、VS Code は thinking effort と呼ぶ。⚠ ただし面できれいに分かれてもいない — VS Code の docs 自身が、モデルの資料では thinking effort と書き、キャッシュの資料では reasoning effort と書いている（いずれも具体例節）。読者にとっての実用上の意味は一つである: 検索する語を、一つに決め打ちしない。
adaptive reasoning を本パターンの別名にしない。 これは道具が自動で段を加減する挙動の名であり、公式は既定で有効だと書いている（具体例節）。本パターンは人が、一手より大きい単位で段を決める実践である。両者は競合しない — 自動判定は目の前の一手を見ており、本パターンは位相・代償・構造を見る。名前を混ぜると、「adaptive reasoning が有効だから、この実践は済んでいる」という誤読になる。
同じ理由で、公式が名前を与えているのはつまみ（thinking effort / reasoning effort）までである。「そのつまみを、位相と代償に合わせて選ぶ」という実践には、確認できた範囲で確立した呼称が無い。つまみの名を実践の名として流用すると、「effort を設定できる＝この実践をしている」という誤解になる。既定のまま一段に固定していても、つまみは設定されている。
関連
- 前置きを壊さない（キャッシュ） — 本パターンが動かすつまみを、同パターンは「開始前に固定せよ」と言う。公式のキャッシュ助言が reasoning effort を名指しでキャッシュの作り直し要因に挙げている（具体例節）。正面から緊張し、本カタログはこの緊張を解かない
- 委譲の損益分岐 — 同パターンは誰にやらせるかの値札、本パターンはどれだけ考えさせるかの値札。交点はサブエージェント単位の段の指定であり、2つのツールが機構を持っている（具体例節）
- 計画の先制検証 — 同パターンは計画を実行前に検証する型。本パターンから見れば、そこは公式が深度を上げてよい場面として名指しした2つのうちの一方（architectural planning）に当たる位相である（具体例節）
- 読み捨ての隔離 — どこで読むかが同パターン、そこでどれだけ考えさせるかが本パターン。隔離した先の深度は主と別に決められ、その機構は2つのツールにある（具体例節）
- まず次に読むなら 委譲の損益分岐 — 思考の値札を見たら、次は委譲の値札を見る番である