筆者は Claude Code を日々の業務に使っていますが、設定項目のうち「model」と「effort」は、どちらも上げれば賢くなりそうに見えて、実際に何がどう変わるのかを長らく曖昧なまま使っていました。2026年7月9日、Claude Code チームの Lydia Hallie 氏が、公式開発者アカウント @ClaudeDevs でこの2つの設定の違いを仕組みのレベルから解説するポストを公開しました。本記事はその内容を、Anthropic の API ドキュメントと Claude Code のドキュメントで補いながら整理します。以下に掲載する図版は、いずれも同ポストに掲載されたものです（作図: Anthropic）。

結論 — model は「何を知っているか」、effort は「どれだけ働くか」

設定変わるもの変わらないもの
model応答を担当する訓練済みの「重み」一式（＝知識・能力）と、トークン単価生成されるトークンの量
effort1つのタスクに費やす作業量（思考の長さ、読むファイル数、検証の徹底度）モデルの知識・能力そのもの

元ポストの原題は “Model and effort in Claude Code: knowing more vs. trying harder”（より多く知っていることと、より頑張ること）であり、結論も次の一文に集約されています。

Effort changes how much work Claude does. The model changes what Claude knows.

（effort は Claude がどれだけ働くかを変える。model は Claude が何を知っているかを変える）

以下、それぞれの設定が処理のどの段階に効くのかを順に見ていきます。

model の仕組み — 応答する「重み」を丸ごと入れ替える設定

Enter キーを押すと、Claude Code はメッセージ本文にシステムプロンプト・ツール定義・CLAUDE.md・会話履歴・コンテキスト内のファイルをまとめ、1つの API リクエストとして送信します。model と effort は、このリクエストの中で指定されるパラメータです。

Claude Code が1つのAPIリクエストを組み立てる流れの図。システムプロンプト・ツール定義・CLAUDE.md・会話履歴・ファイル・メッセージが1つのリクエストにまとまり、サーバー側でトークナイザを経てモデルに渡る

図1: すべての入力は1つのAPIリクエストに束ねられ、サーバー側でトークン化されてからモデルに渡る。model と effort はこのリクエスト内の指定項目

モデルがこのテキストをそのまま読むわけではありません。サーバー側で最初に行われるのはトークン化で、テキストは断片に分割され、各断片はモデルの訓練時に固定された語彙（図の例では100,257語）の中の整数に対応づけられます。以降、プロンプトは整数の配列として扱われます。

「const x = await fetch(」がトークンに分割され、各トークンが語彙表の整数IDに対応づけられる図

図2: トークナイザはテキストを断片に分割し、固定語彙の整数IDへ対応づける（図中のIDは説明用の例示）

モデルの仕事は、この配列に続く「次の1トークン」を予測することです。語彙にあるすべてのトークンに確率を割り当て、上位から選びます。

「const x = await」の次に来るトークンの確率分布。fetch が0.62、Promise が0.14、banana はほぼ0

図3: 予測は語彙の全トークンに対する確率として出力される。文脈に合うトークンと無関係なトークンの差は極めて大きい

入力トークンをこの確率に変換しているのが「重み（パラメータ）」——巨大な行列に整理された数十億個の数値です。重みは訓練時に定まり、リクエストを送る時点では読み取り専用です。プロンプトや CLAUDE.md、コンテキストに入れた資料が重みを書き換えることはありません。これらができるのは予測の「操縦」であり、その1リクエスト限りの影響にとどまります。訓練時に存在しなかったライブラリの知識は重みの中になく、ドキュメントをコンテキストに与えれば使えるものの、モデルが何かを記憶として保持するわけではありません。実在しない API を自信を持って呼び出す現象（ハルシネーション）も、検索の失敗ではなく「訓練パターン上もっともらしいトークン列」を重みが生成した結果として説明されます。

入力トークンが重み（数十億の数値、訓練後は読み取り専用）を通って次トークンの確率になる図。モデルを変えることは重み一式を変えること

図4: プロンプトが入り、確率が出る。中間にある重みは訓練後は変化せず、「model を変える」とはこの一式を丸ごと入れ替えること

また、モデルは応答を一度に生成するのではなく、1トークン予測しては配列に追加し、概念的にはそれまでに生成された文脈を踏まえて次を予測する、という繰り返しで出力します（実装上は KV キャッシュにより、過去のトークンをそのたびに計算し直しているわけではありません）。200トークンの応答は重みを200回通す計算であり、待ち時間と出力コストの大半はこのループに由来します。

1トークンずつ生成が進むループの図。step 1で fetch、step 2で (、step 3で url と、配列が1トークンずつ伸びていく

図5: 出力は1ステップ1トークン。概念的には、それまでに生成された文脈を踏まえて次のトークンを予測する

まとめると、model の設定が決めるのは「どの重み一式がリクエストを処理するか」と「出力トークンの単価」です。一方で「何トークン生成されるか」は決めません。同じプロンプトでも生成量は大きく変わりえます——それを左右するのが effort です。

effort の仕組み — 作業量を決める、もう一つの入力

Claude Code が作業中に生成するトークンは、思考（行動の前後に流れる推論）、ツール呼び出し（Read や Edit といったツール名と引数の構造化ブロック）、ユーザーへのテキスト（計画・経過・要約）の3種類に分けられますが、いずれも同じループから生成される通常の出力トークンであり、同じ単価で課金されます。思考の内容自体はユーザー向けの画面には表示されませんが、Claude Code の内部処理としてはツール呼び出しや推論過程の制御に使われる出力トークンであり、その分の消費は発生します。

思考・ツール呼び出し・ユーザーへのテキストがすべて同じ重みから同じループで生成されることを示す図

図6: 思考もツール呼び出しも本文も、同じループから生まれる同じ出力トークン。違いは「トークンが何を言っているか」だけ

effort はこの生成量を左右します。実装としては、effort レベルはプロンプトと並んでリクエストの一部としてモデルに送られる入力であり（API では output_config.effort。low・medium・high・xhigh・max の5段階で、high が既定＝未指定と同じ挙動です1）、各レベルでどう振る舞うかはモデルの訓練を通じて重みに焼き込まれています。効果は「思考時間」にとどまりません。元ポストは、effort が制御するものとして思考の長さに加えて次の3点を挙げています。

  • 何ファイル読むか
  • どれだけ検証するか（テストの実行、見直し）
  • ユーザーに確認を挟まず、複数ステップの作業をどこまで進めるか

低い effort では、Claude は自力でトークンを費やして調べるより、ユーザーに文脈を尋ねる方を選びやすくなります。高い effort では、タスクを完了と見なすまでに要求される徹底度と確信度が上がり、その確信に到達するために多くのトークンが費やされます。

同じ「失敗するテストを直して」というタスクの低effort版（テストを読む→考える→修正、約400トークン）と高effort版（テスト・ソース・設定を読む→考える→修正→テスト実行→再確認、約2,800トークン）の比較図

図7: 同じプロンプトでも、高 effort は読む・検証する工程が増え、この説明用の例では約7倍のトークンを使って、より確信度の高い答えに到達する（トークン数は例示）

API ドキュメントはこの性質を「effort は挙動のシグナルであって、厳密なトークン予算ではない」と説明しています1。高い effort でも計画は固定されず、途中の結果を受けて進捗と確信度の見積もりが更新され、不要になった手順は明示的にスキップされます（Claude Code でタスクリストが実行中に改訂されるのがこの現れです)。逆に、単純なタスクで effort を上げても消費を人為的に膨らませることはしない設計で、「考えすぎ（overthinking）」は効果を下げる要因として訓練時に監視されている、と元ポストは述べています。

なお、effort レベルの尺度はモデルごとに較正されており、同じ「high」という名前がモデル間で同じ値を表すわけではありません2。

間違えたとき、どちらを変えるか

元ポストがまず勧めるのは、設定を触る前に与えたコンテキストを疑うことです。プロンプトが曖昧でないか、適切なツールやスキルにつながっているか、作業を自己検証する手段があるか——effort を上げたくなるタスクの多くは、原因がこうした上流にあります。

そのうえで、明確なコンテキストを与えてもなお間違える場合の判断基準が「知らなかったのか、頑張らなかったのか」です。

「Claude が間違えた」から始まる判断フローチャート。ファイルを読み飛ばした等なら effort を上げる（トークンは増えるが重みは同じ）、すべて読んで明らかに努力したのに自信満々に間違うならより大きいモデルへ（重みが変われば能力が変わる）。どちらでもなければ入力（コンテキスト・CLAUDE.md・タスクの切り方）を直す

図8: 判断フロー。「頑張らなかった」なら effort、「知らなかった」なら model、どちらでもなければ入力を直す

  • model を変えるべき場合（知らなかった）: 微妙なバグ、不慣れなドメイン、アーキテクチャ判断など問題自体が難しく、どれだけコンテキストを与えても小さいモデルが自信を持って間違え続けるとき。曖昧さの処理も大きいモデルの方が得意で、小さいモデルには実行手順まで具体的に指示する方が成功しやすいとされています
  • effort を変えるべき場合（頑張らなかった）: ファイルを読み飛ばした、テストを実行しなかった、確認を怠ったといった「手の抜き方」で間違えたとき。特に、モデルの既定より低い effort を設定していた場合に該当します
  • 逆に、記述どおりに実行できる編集や機械的な変更、すでにコンテキストにあるコードへの質問といった定型作業では、小さいモデルに下げても品質は落ちず、速度とコストが改善します

スペシャリスト・エキスパート・ジェネラリスト

元ポストは2つの設定の関係を人にたとえています。Fable はほとんど誰も解けない問題を扱うスペシャリスト、Opus はエキスパート、Sonnet は優秀なジェネラリストであり、effort はその人がタスクに使う持ち時間にあたります。低 effort の Opus は「類似の問題を数多く解いてきた専門家との5分間」であり、コードベースにない経験則を持ち込む一方、全ファイルの丁寧な精読はしません。高 effort の Sonnet は「午後をまるごと使えるジェネラリスト」であり、すべてを読み、実行し、二重に確認して、対象のコードを深く理解します。どちらが常に優れているということはなく、model はおおよそ「どれだけ有能か」、effort はおおよそ「どれだけ徹底するか」に対応します。

effort の選び方について、元ポストは大半のタスクでモデルの既定レベルのままにすることを勧めています。既定は「そのタスクに大半の人が費やしたい量」に消費が釣り合うよう調整されており、effort の変更はタスクごとの操作ではなく、自分の領域や仕事の性質に基づく全般的な好みの上書きとして使うのがよい、という位置づけです。たとえば、普段から大規模なコードベースの修正やテスト込みの作業を任せるなら高め、短い質問や定型編集が多いなら低め、という考え方になります。

コストとの関係 — 曲線を選ぶのが model、どこまで進むかが effort

model・effort・トークン消費の関係は、タスクの難易度で逆転します。定型的な作業では、同じ effort なら大小どちらのモデルも正解に達し、大きいモデルは検証を余分に行うぶん消費が多く、単価も高くつきます。

簡単なタスクでの品質×消費トークンの曲線。大小のモデルとも立ち上がりですぐ品質上限に達し、以降のトークンは二重チェックに使われる

図9: 簡単なタスクでは両モデルの曲線が収束する。これ以降のトークンが買うのは品質ではなく二重チェック（曲線は実測データではなく説明用の概念図）

一方、複数ステップにわたる難しい作業では関係が反転します。小さいモデルは能力の限界に向かって反復を重ねて消費がかさみ、大きいモデルは少ないステップで同じ品質水準に到達します。単価は高くても、タスク単位の総コストはむしろ安くなりえます。さらに重要な点として、大きいモデルは小さいモデルが effort を最大にしても完了できないタスクを完了できます。元ポストによれば、この差は Fable 5 で最も顕著で、社内のテストでは Opus や Sonnet がどの effort でも到達できない作業を完遂したとされています（それが最高のトークン単価の理由でもあり、本当に必要な作業に取っておくことが勧められています）。

難しいタスクでの品質×消費トークンの曲線。モデルが曲線の形を決め、effortはその曲線上をどこまで右に進むかを決める

図10: 難しいタスクでは曲線そのものが分かれる。model が曲線を選び、effort はその曲線上をどこまで進むかを決める（曲線は実測データではなく説明用の概念図）

最後に、effort はトークン消費を方向づけますが、上限として制限するわけではありません。システム上唯一のハードキャップは max_tokens で、これは到達すると応答を途中で打ち切る鈍い手段であり、主に API 開発者向けです。実用上は、タスク予算の指定やプロンプトで簡潔さを求めるといった、モデルが従うよう訓練された緩やかな制御（上限が近づくと切り上げに向かう）の方が有用とされています。

Claude Code での設定方法

Claude Code のドキュメント2によれば、2つの設定は次のように操作します。

  • model: /model で切り替えます。選択画面では左右キーで effort スライダーも同時に調整できます
  • effort: /effort で対話的に設定するか、起動時の --effort フラグ、設定ファイルの effortLevel などで指定します。既定は Fable 5・Sonnet 5・Opus 4.8・Opus 4.6・Sonnet 4.6 で high、Opus 4.7 で xhigh です
  • モデルが対応しないレベルを指定した場合は、それ以下で最も高い対応レベルに丸められます
  • プロンプトに ultrathink と書くと、セッションの effort 設定を変えずにそのターンだけ深い推論を求められます

なお、元ポストには Opus 4.8 に関する実務的な注記もあります。社内テストでは、Opus 4.8 の既定 effort は、同じタスクに対して Opus 4.7 の既定 effort とほぼ同量のトークンでより良い結果を出したとされています。

まとめ

  • model を変えることは、応答を担当する訓練済みの「重み」一式を丸ごと入れ替えることです。知識・能力とトークン単価が変わりますが、生成されるトークン量は決まりません
  • effort は思考時間だけでなく、読むファイル数・検証の徹底度・確認を挟まず進む距離を含む作業量の制御です。API ではプロンプトと並ぶリクエストの一部として送られ、挙動のシグナルであって厳密なトークン予算ではありません
  • 結果に不満があるときは、設定より先にコンテキスト（プロンプトの明確さ・ツール・自己検証の手段）を疑います
  • それでも間違えるなら「知らなかったのか、頑張らなかったのか」。知識不足なら model を、努力不足なら effort を変えます
  • 定型作業では小さいモデルが安く、難しい複数ステップの作業では大きいモデルの方がタスク単位で安くなりえます。effort は基本的にモデルの既定のままでよく、変えるなら全般的な好みとして扱います

参考

参考文献

  1. Effort — Claude Platform Docs。output_config.effort の指定方法、5段階のレベル、“Effort is a behavioral signal, not a strict token budget.”（effort は挙動のシグナルであって、厳密なトークン予算ではない）との注記など。 ↩ ↩2

  2. Model configuration — Claude Code Docs。effort レベルの尺度がモデルごとに較正されている旨（“The effort scale is calibrated per model”）、/effort・/model の操作方法、モデル別の既定値など。 ↩ ↩2