大きいモデル（Fable など）を選べば、Sonnet より賢い答えが返る——これは本当です。では「エフォートを上げる」とは何なのか。多くの人は「Claude が答える前により長く考える」ことだと思っています。でも、それは半分しか合っていません。この記事のゴールはひとつ。「モデルは何を知っているか、エフォートはどれだけ頑張るか」という一本の軸を、あなたの手に馴染ませることです。

• 0設定
  答えを左右する独立したダイヤル
• 0倍
  高エフォートが生むトークン量の差
• 0タイプ
  専門家・エキスパート・ジェネラリスト

user@sinyblog:~/article ❯ 01_intro.md90秒ダイジェスト：2つの設定は別々の問いに答える

結論から言います。Claude Code の「モデル」と「エフォート」は、どちらも出力の質に効きますが、答えている問いが違います。モデルは「どれだけ賢いか（何を知っているか）」を決め、エフォートは「どれだけ徹底的に取り組むか（どれだけ頑張るか）」を決めます。片方は能力、もう片方は労力。これが記事全体を貫く一本の軸です。

「大きいモデルは小さいモデルより賢い」という直感は正しく、実際 Anthropic の最大級モデルは業界標準ベンチマークでより高い能力を示します。一方で「エフォートを上げる＝考える時間が伸びるだけ」という直感は不正確です。エフォートが左右するのは思考時間だけでなく、Claude がその依頼全体にどれだけの作業を投じるか——読むファイルの数、検証の回数、あなたに確認を返す前に多段タスクをどこまで押し進めるか——までを含みます。

user@sinyblog:~/article ❯ 02_effort_is_not_time.mdエフォートは「考える時間」ではない

最初に、いちばん誤解されやすいポイントを潰しておきます。エフォートは「思考時間」を意味しません。エフォートが制御するのは、Claude があなたの依頼に対して行う作業の総量です。それには考える長さも含まれますが、それだけではありません。次の3つも同じダイヤルの内側にあります。

1. どれだけファイルを読むか：関連コードをどこまで自力で開いて確かめるか。
2. どれだけ検証するか：テストを走らせたり、出した答えを二度見したりするか。
3. どこまで自走するか：あなたに確認を返す前に、多段タスクをどこまで押し進めるか。

高エフォートでは、Claude はあなたに戻ってくる前に、こうしたアクション（ファイルを読む、テストを走らせる、ダブルチェックする）をより多く取ります。低エフォートでは、トークンを使って自力で突き止めるより、あなたに追加の文脈を尋ねる方を好みます。つまりエフォートは「Claude がどれだけ一人で頑張り切るか」のツマミなのです。

なぜモデルとエフォートがこんなにも別物なのか。それを本当に理解するには、Enter を押した瞬間にサーバー側で何が起きているのかを、いちど覗いておくのが近道です。次章から、モデルの内部へ潜ります。

user@sinyblog:~/article ❯ 03_press_enter.mdモデル選択の正体①：Enter を押した瞬間

モデル設定が実際に何を制御しているのか。それを掴むには、いちばん最初——あなたが Enter を押した瞬間から始めるのが分かりやすいです。

Claude Code は、あなたのメッセージを、システムプロンプト・ツール定義・あなたの CLAUDE.md・会話履歴・コンテキストに入っているファイルとひとまとめにします。これら全部が、1つのリクエストとして API に送られます。Claude Code が抱えているものは、すべて1つの API リクエストに詰め込まれる、というわけです。

あなたのメッセージ
  + システムプロンプト
  + ツール定義（Read / Edit / Bash ...）
  + CLAUDE.md
  + 会話履歴
  + コンテキスト内のファイル
  + エフォートレベル          <- これも一緒に送られる（後述）
  ─────────────────────────
  = 1つの API リクエスト  -->  サーバーへ

ただし、モデルはこれらを「文章そのもの」としては一切見ていません。サーバーで最初に起きるのはトークン化（tokenization）——テキストが細かい断片に分割され、各断片がモデルの訓練時に決められた固定の語彙表（vocabulary）にもとづく整数へと変換される処理です。ここが、次章の核心になります。

user@sinyblog:~/article ❯ 04_tokenize.mdモデル選択の正体②：トークン化と次トークン予測

トークン化を具体的に見てみましょう。テキストは断片に切られ、それぞれが固定語彙の整数に対応づけられます。たとえば const は 1978 に、await は 4293 に、といった具合です（数値は説明用の例）。ここから先、あなたのプロンプトは整数の配列になります。

"const x = await"

 const    x     =    await
 1978    712   289   4293      <- IDは説明用の例

モデルの仕事は、この整数配列を受け取り、次にどのトークンが来るかを予測することです。やり方はこうです。語彙表にあるすべてのトークンについて確率を計算し、上位から選ぶ。たとえば const x = await の後なら、よく訓練されたモデルは fetch に高い確率を（とても起こりそう）、banana にはほぼゼロの確率を（まず起こらない）割り当てます。

user@sinyblog:~/article ❯ 05_weights.md重み（パラメータ）は凍結されている

では、入力トークンをその確率へ変換しているのは何か。答えは重み（weights、パラメータとも呼ぶ）です。これは巨大な行列に整理された、数十億個の数値の集まり。1つのトークンを予測するために、モデルはあなたの入力をこれらの行列に通し（長い行列積の連鎖）、最後に出てくる確率を読み取ります。モデルが「知っている」ことのすべては、この重みの中に宿っています。

各モデルの重みは訓練時に決まり、あなたがリクエストを送る頃には読み取り専用（read-only）です。あなたのプロンプトも、CLAUDE.md も、コンテキストも、この重みを1ビットたりとも変えません。もし「推論（inference）」という言葉に出会ったことがあるなら、意味はこれだけ——訓練が終わったモデルを、重みを固定したまま使うことです。

プロンプト（整数配列）
      │
      ▼
 ┌───────────────┐
 │  重み（固定・読み取り専用）  │   <- 訓練で確定。プロンプトでは変わらない
 └───────────────┘
      │
      ▼
 次トークンの確率が出てくる

TypeScript のこと、人気フレームワークのこと、その他あらゆる一般的なプログラミング知識——それらはすべて、訓練時にこの重みへ焼き込まれたものです。だから、Claude が実在しない API を自信満々に呼ぶ（ハルシネーション）とき、それは「検索に失敗した」のではありません。重みが、訓練パターンから見て尤もらしいトークン列を生成してしまった結果なのです。

user@sinyblog:~/article ❯ 06_steering.mdコンテキストは「操縦」であって「教育」ではない

「重みは変わらない」と聞くと、じゃあコンテキストを渡す意味は？と思うかもしれません。ここが重要です。あなたのプロンプトやコンテキストは、それでも予測を操縦（steering）できます。実際のコードを Claude の目の前に置くのは操縦であり、これは非常によく効きます。ただし——重みそのものには何も足していません。

たとえば、モデルの訓練時にまだ存在しなかったライブラリは、重みの中にありません。ドキュメントをコンテキストに入れれば Claude はそれを使いますが、それは操縦であって、教育ではない。Claude の応答はその1回のリクエストの間だけ影響を受け、土台のモデルは何も保持しません。次のセッションでは、また同じドキュメントを渡す必要があります。

では結局、モデルを変えると何が起きるのか。答えはシンプルです。あなたのリクエストを処理する「凍結された重みのセット」を丸ごと入れ替える——それがモデル設定の正体です。

user@sinyblog:~/article ❯ 07_autoregression.md1トークンずつ：生成ループと料金の正体

モデルは、答え全体を一度に生成するわけではありません。1トークンを予測し、それを配列の末尾に追加し、また全体の計算をやり直して次の1トークンを得る。この繰り返しです。つまり200トークンの応答は、重みを通る200回の独立したパス。あなたの待ち時間の大半と、出力コストの大半は、このループから生まれます。

[const x = await]              --> 予測: fetch
[const x = await fetch]        --> 予測: (
[const x = await fetch(]       --> 予測: url
...

1トークン生成するたびに配列は「1つだけ」伸び、
モデルは毎回その全体を読み直して次を予測する。
=> 200トークンの応答 = 重みを通る 200 回のパス

ここから、モデル設定が本当に決めていることが2つ見えてきます。第一に、どの重みがリクエストを処理するか。第二に、出力トークン1個あたりの単価。大きいモデルほど1トークンが高価です。

逆に、モデル設定が決めていないものがあります。それは「何トークン生成されるか」。この数は、同じプロンプトでも大きくばらつきます。何によって？——Claude がどれだけの作業をすると決めたか、によって。そして、それを制御しているのが、ほかでもないエフォートです。

user@sinyblog:~/article ❯ 08_effort_tokens.mdエフォートの正体①：出力トークンの3つの顔

Claude Code がタスクに取り組んでいる間、生成されるトークンはいくつかの種類に分かれます。見た目は違えど、正体はどれも同じループから出てくる同じ出力トークンで、同じ単価で課金されます。

重要なのは、思考トークンも他の出力トークンとまったく同じように生成され、そのターンの残りの間ずっとコンテキストに残るという点です。Claude がコードを書く段になる頃には、それまでの推論は「読んだファイル」と同じように入力の一部になっています。思考・ツール呼び出し・あなたへのテキスト——すべては同じループから生まれる、地続きのトークンなのです。

user@sinyblog:~/article ❯ 09_effort_behavior.mdエフォートの正体②：確信に達するまでの粘り

ではエフォートは、これらをどう変えるのか。エフォートレベルは、あなたのプロンプトと並んでリクエストの一部としてモデルに送られます。モデルは各エフォートレベルでどう振る舞うべきかを訓練で学んでおり、その学習済みの挙動は凍結された重みに焼き込まれています。

つまりリクエストが届いたとき、エフォートはモデルが反応するもう1つの入力にすぎません——プロンプト本文に反応するのと同じように反応するのです。エフォートが設定するのは、タスクを「完了」とみなす前に、Claude がどれだけ徹底的で、どれだけ確信を持っている必要があるか。これが毎ターン天秤にかけられ、そしてより高い確信に達するには、より多くのトークンが要ります。

低エフォート  ─ 少ないトークンで手早く着地
              （不確かなら自力で掘らず、あなたに文脈を尋ねる）

高エフォート  ─ 約7倍のトークンを生成して
              より高い確信の答えに到達
              （計画→ファイル読込→検証→確認）

高エフォートでは、Claude はしばしば計画（プラン）を立てるところから始め、エフォートレベルがその計画の深さと広さに影響します。ただし、計画は固定ではありません。アクションの結果が返ってくるたびに、Claude は「どこまで進んだか」「積み上がった結果にどれだけ確信があるか」という自分の見取り図を更新します。

たとえば3つの仮説を立てたデバッグ計画で、ステップ1がバグを見つけたら、「仮説2と3を調べる」はもう不要かもしれません。Claude はたいていそれを明示し（例：「最初のチェックで見つかったので、残りのチェックは不要」）、先へスキップします。Claude Code でタスクリストが実行中に書き換わるのを見たことがあるなら、それがこの現象です。

user@sinyblog:~/article ❯ 10_pick_effort.mdエフォートレベルの選び方

ほとんどのタスクでは、モデルの既定（デフォルト）エフォートを使ってください。デフォルトは、Claude がトークン使用量を「そのタスクに大半の人が費やしたいと思う量」にスケールさせる水準です。多くの場合、これがいちばん釣り合いが取れています。^[2]

エフォートは、Claude がどれだけ強く・長く働くかの手動オーバーライドだと考えてください。あなたの領域や仕事のタイプから「徹底性」または「速度」に強いこだわりがあるときに、意図的に手を伸ばす。そしてこれは、タスクごとに毎回いじる判断ではなく、全体的な好み（general preference）として扱うのが正解です。

user@sinyblog:~/article ❯ 11_when_wrong.md間違えたとき、どちらを変えるか

Claude が何かを間違えたとき、あなたの最初の衝動は「設定を変えること」であってはいけません。まず見るべきは、あなたが与えたコンテキストです。プロンプトは曖昧すぎないか？ Claude は正しいツールに繋がっているか？ 適切なスキルを持っているか？

必要ないはずのタスクでエフォートを上げようとしているなら、たいてい直すべきは上流——あなたのコンテキスト、CLAUDE.md、タスクのスコープの切り方です。ここを整えないまま設定だけ回しても、根本は解決しません。

では、明確なコンテキストを与えても、なお Claude が間違えたとしましょう。そのとき自問すべき問いは、たった1つです。「頑張りが足りなかったのか、それとも知識が足りなかったのか？」

Model（問題が難しすぎた）：微妙なバグ、不慣れなドメイン、アーキテクチャの決定——問題が本当に難しいときは、大きいモデルを選びます。どれだけ文脈を与えても小さいモデルが自信満々に間違えるなら、それは大きいモデルの出番。大きいモデルは曖昧さの扱いも上手です。逆に小さいモデルでは、実行を細かく方向づける具体的な指示が成功のレシピになります。

Effort（頑張りが足りなかった）：スキップ・未検証・見直し不足で間違えたなら、エフォートを上げます。これは特に、デフォルトより低いエフォートを選んでいた場合に効いてきます。適切な文脈があり、明らかに努力していて、それでも間違えた——そのときが、より大きなモデルへ切り替えるサインです。

user@sinyblog:~/article ❯ 12_metaphor.md専門家・エキスパート・ジェネラリスト

2つの設定をイメージで掴む、いい喩えがあります。Fable は、ほぼ誰も扱えない問題を捌ける「専門家（スペシャリスト）」。Opus は「エキスパート」。Sonnet は本当に優秀な「ジェネラリスト」。そしてエフォートレベルは、彼らの誰があなたのタスクにどれだけの時間を費やすかを決めます。

どれも普遍的に「優れている」わけではありません。モデル設定はおおよそ「どれだけ有能か」、エフォート設定はおおよそ「どれだけ徹底的か」。そして現実のタスクの多くは、その両方をいくらか必要とします。だから Fable は「皆が行き詰まったとき」に取っておくのが賢い。その識別力こそ、最も高くつく部分だからです。

user@sinyblog:~/article ❯ 13_cost.mdEffort × Model × トークン消費の相互作用

では、モデル選択・エフォート・トークン消費は、どう絡み合うのか。答えは「タスク次第」です。2つのケースで正反対のことが起きます。

ルーチンワークの場合：同じエフォートなら、大きいモデルも小さいモデルもたいてい正解します。ただし大きいモデルは、余分な検証ステップでより多くのトークンを、しかも高い単価で消費します。だからこそ、ルーチンな区間では小さいモデルに落とすと、品質を落とさずに実費を節約できます。

難しい多段タスクの場合：式が反転します。小さいモデルは自分の能力の限界へ向かって反復を燃やしながら力尽くで進むしかなく、大きいモデルは同じ品質基準により少ないステップで到達します。トークン単価は大きいモデルの方が高いのに、小さいモデルを本当に引き伸ばすタスクでは、タスクあたりの総コストが逆に安くなることすらあります。そして何より重要なのは——大きいモデルは、小さいモデルが最高エフォートでも終わらせられないタスクを終わらせられることです。

これが最も顕著なのが Fable です。長い多段作業でこそ最も先へ抜け出し、Anthropic のテストでは、Opus や Sonnet がどのエフォートでも到達できなかったジョブを完了させました。同時にトークン単価も最も高い——これが、本当に必要な仕事のために取っておくべきもう1つの理由です。

user@sinyblog:~/article ❯ 99_summary.mdまとめ

長い旅でしたが、掴むべきことは驚くほど少数です。エフォートは Claude がどれだけ作業するかを変え、モデルは Claude が何を知っているかを変える。結果に不満なとき、どちらかの設定に触れる前に、まずコンテキストを点検してください——明快なプロンプト、正しいツールとスキル、そして自分の仕事を検証する手段を Claude に与えること。

1. 2つは別の問いに答える。モデル＝どれだけ賢いか（何を知っているか）、エフォート＝どれだけ徹底的か（どれだけ頑張るか）。混同しない。
2. まず上流を疑う。間違えたら設定より先に、プロンプト・CLAUDE.md・ツール・スキル・スコープを見直す。多くの不具合はここで直る。
3. 切り分けの問いは1つ。「知識が足りなかったのか（→Model を大きく）、頑張りが足りなかったのか（→Effort を上げる）」。ルーチンが続くなら Model を下げて速度とコストを取り戻す。

Fable はスペシャリスト、Opus はエキスパート、Sonnet は優秀なジェネラリスト。そしてエフォートは、その誰かがあなたのタスクにどれだけの時間を注ぐかのツマミ。この地図さえ手元にあれば、次に「答えがイマイチだ」と感じた瞬間、あなたは正しいダイヤルへ迷わず手を伸ばせます。