Claude Code には、出力を「より良くする」ように見える 2 つの設定があります。モデルと努力レベルです。しかし、これらは実際に出力に何をもたらすのでしょうか？そして、別のモデルを使うべきか、それとも単に努力レベルを変更すべきか、どう判断すればよいのでしょうか？
「Fable のような大規模なモデルを選べば Sonnet よりも賢い出力が得られる」「努力レベルを上げれば、Claude が回答する前に長く考える時間が増える」と考えるのは簡単です。
前者の前提は正しいです。業界標準のベンチマークによると、最大規模のモデルはより高性能です。
しかし、努力とは単なる「思考時間」以上の意味を持ちます。努力は、Claude がリクエスト全体に対してどれだけの作業を行うかを制御します。それには思考時間も含まれますが、次の要素も含まれます。
- 読み取るファイルの数
- 検証の量
- 多段階のタスクをどこまで進めてからユーザーに確認を取るか
努力が高い場合、Claude はこれらのアクション（ファイルの読み取り、テストの実行、再確認）をより多く行ってから回答を返します。努力が低い場合、Claude はトークンを消費して自分で解決するよりも、むしろユーザーに追加のコンテキストを求める傾向があります。
モデル選択の仕組み
モデル設定が実際に何を制御しているかを理解するには、エンターキーを押した瞬間から、最初から考えるとよいでしょう。
Claude Code は、ユーザーのメッセージをシステムプロンプト、ツール定義、CLAUDE.md、会話履歴、コンテキスト内のファイルとともにまとめます。これらすべてが 1 つのリクエストとして API に送信されます。
Claude Code が持つすべての情報が 1 つの API リクエストに詰め込まれます。サーバー上では、テキストがモデルに到達する前にトークン化されます。
ただし、モデルはそれらをプレーンテキストとして見ることはありません。サーバーで最初に行われるのはトークン化です。テキストが断片に分割され、各断片がモデルのトレーニング時に使用された固定語彙の整数にマッピングされます。const は 1978 に、await は 4293 にマッピングされるかもしれません。ここから先は、ユーザーのプロンプトは整数の配列です。
トークナイザーはテキストを断片に分割し、各断片を固定語彙の整数にマッピングします。上の行の各チャンクがトークン ID（下の行）になります。ID は説明用です。
モデルの役割は、その配列を受け取り、次に来るトークンを予測することです。これは、語彙内のすべてのトークンに対して確率を計算し、上位から選択することで行われます。"const x = await" の後では、適切にトレーニングされたモデルは "fetch" に高い確率（非常に可能性が高い）を、"banana" にほぼゼロの確率（ほとんど可能性がない）を割り当てます。
モデルの予測は、語彙内のすべてのトークンに対する確率です。トップの推測と無関係な推測との差は非常に大きいです。
入力トークンをこれらの確率に変換するのは、重み（パラメーターとも呼ばれます）です。数十億の数値が大きな行列に編成されています。1 つのトークンを予測するために、モデルは入力を行列に通し（長い行列乗算の連鎖）、最後に確率を読み取ります。重みには、モデルが「知っている」すべての情報が格納されています。
各モデルの重みはトレーニング中に設定され、ユーザーがリクエストを送信する時点では読み取り専用です。プロンプト、CLAUDE.md、コンテキストのいずれも重みを変更しません。「推論」という言葉に出会ったことがあれば、それはトレーニングが完了した後のモデルを、固定された重みで使用することを意味します。
プロンプトが入力され、確率が出力されます。途中の重みは変わりません。
Claude が TypeScript、人気のフレームワーク、その他の一般的なプログラミング知識について知っていることはすべて、トレーニング時にこれらの重みにエンコードされました。
プロンプトとコンテキストは依然として予測を方向付けることができます。実際のコードを Claude の前に置くことは方向付けであり、非常に効果的です。ただし、これによって重み自体に何かが追加されるわけではありません。
トレーニング時点で存在しなかったライブラリは、重みの中にありません。ドキュメントをコンテキストに入れれば Claude はそれを使用しますが、それは方向付けであり、学習ではありません。Claude の応答はその 1 つのリクエストにのみ影響し、基盤となるモデルは何も保持しません。
Claude が存在しない API を自信満々に呼び出す（幻覚）場合、それは重みがトレーニングパターンからもっともらしく見えるトークンシーケンスを生成しているのであり、検索の失敗ではありません。
では、モデルを変更すると実際に何が起こるのでしょうか？それは、どの固定重みのセットがリクエストを処理するかを交換することです。
モデルは一度に全体の回答を生成するわけではありません。1 つのトークンを予測し、それをシーケンスに追加し、全体の計算を再度実行して次のトークンを取得します。200 トークンの応答は、重みを通る 200 回の個別のパスです。このループが、待機時間（および出力コスト）の大部分を占めます。
シーケンスは 1 ステップで正確に 1 トークンずつ増加します。モデルは毎回配列全体を再読み取りして、次に来るものを予測します。
モデル設定は、どの重みがリクエストを処理するかを決定し、各出力トークンのコストも決定します。
設定が決定しないのは、生成されるトークンの数です。この数は、同じプロンプトであっても、Claude が行う作業量に応じて大きく変動します。
そして、まさにそれを努力が制御します。
努力の仕組み
Claude Code がタスクに取り組んでいる間、生成されるトークンはいくつかのカテゴリに分類されます。
- 思考: アクションの前後でストリーミングされる推論。
- ツール呼び出し: Read や Edit などのツールとその引数を指定する構造化ブロック。Claude Code が解析して実行します。
- ユーザーへのテキスト: 計画、進捗状況の更新、最後の要約。
これらはすべて、同じループからの通常の出力トークンであり、同じレートで課金されます。たとえば、思考トークンは他の出力トークンとまったく同じように生成され、そのターンの残りの間コンテキストに残ります。
Claude がコードの作成に移る頃には、その以前の推論は入力の一部になっており、読み取ったファイルと同じように扱われます。
Claude の出力はすべてトークンです。思考、ツール呼び出し、ユーザーへのテキストはすべて同じループから生成されます。
では、努力はこれをどのように変えるのでしょうか？努力レベルは、リクエストの一部としてモデルに送信され、プロンプトと一緒に送られます。モデルは各努力レベルでどのように振る舞うかを理解するようにトレーニングされており、その学習された振る舞いは固定された重みに組み込まれています。
リクエストが到着すると、努力はモデルが応答するもう 1 つの入力にすぎず、プロンプトテキストに応答するのと同じ方法です。これにより、Claude がタスクを完了したと見なす前に必要となる徹底さと確実性の度合いが設定されます。これは毎ターン評価され、より高い信頼度に達するにはより多くのトークンが必要になります。
同じプロンプト、2 つの努力レベル。高い努力のパスは、より高い信頼度の回答に到達するために、約 7 倍のトークンを生成します。
努力レベルが高い場合、Claude はしばしば計画を作成することから始め、努力レベルはその計画の深さと広さに影響を与えます。しかし、計画は固定されているわけではありません。Claude はアクションから結果を得るにつれて、進捗状況と蓄積された結果に対する確実性の度合いのイメージを更新します。
3 つの仮説をデバッグする計画のステップ 1 でバグが見つかった場合、「仮説 2 と 3 を調査する」は不要になるかもしれません。Claude は通常、これを明示的に述べ（例：「最初のチェックで見つかったため、残りのチェックは不要です」）、先に進みます。これは Claude Code でタスクリストが実行中に修正される際に見られます。
努力が高いと、Claude は見つけた回答を検証したり、飛ばせたはずの仮説を調査したりと、再確認する可能性が高くなります。ただし、単純なタスクで努力レベルが上がっているからといって、人為的に使用量が増えることは通常ありません。「考えすぎ」は、当社のチームがモデルトレーニング中に特に監視している現象であり、効果を低下させるためです。
努力レベルの選択
ほとんどのタスクでは、モデルのデフォルトの努力レベルを使用してください。デフォルトは、Claude がほとんどの人がタスクに費やしたいと思う量にトークン使用量を調整するレベルです。
努力は、Claude がどれだけ懸命に、どれだけ長く作業するかに対する手動オーバーライドと考えてください。自分のドメインや作業の種類に基づいて、徹底性や速度に強い好みがある場合に意図的に使用し、タスクごとの決定ではなく、一般的な設定として扱ってください。
Opus 4.8 のローンチ後の実用的な注意点：当社のテストでは、Opus 4.8 のデフォルトの努力設定は、Opus 4.7 のデフォルトの努力設定と同じタスクで同程度のトークン数でより良い結果を生成します。
Claude が間違えた場合の変更方法
Claude が何かを間違えた場合、最初に考えるべきは設定の変更ではありません。与えたコンテキストを確認することです。プロンプトが曖昧すぎませんか？Claude は適切なツールに接続されていますか？適切なスキルを持っていますか？
努力を必要としないタスクで努力を増やしている場合、修正は通常上流、つまりコンテキスト、CLAUDE.md、またはタスクの範囲の決め方にあります。
しかし、明確なコンテキストを与えたにもかかわらず、Claude が依然として間違える場合があります。そのときに自問すべき質問は次のとおりです。「十分に試みなかったのか、それとも十分に知らなかったのか？」
モデル：問題が難しすぎた
微妙なバグ、馴染みのないドメイン、アーキテクチャの判断など、問題が真に難しい場合に、より大きなモデルを選びます。より小さなモデルが、どんなにコンテキストを与えても自信満々に間違える場合に必要なのは、より大きなモデルです。
より大きなモデルは、曖昧さの処理にも優れています。小さなモデルでは、実行を指示する具体的な指示が成功のためのより良いレシピになります。
作業が日常的な場合（正確に記述できる編集、機械的な変更、すでにコンテキスト内にあるコードに関する質問）は、より小さなモデルを選びます。タスクに必要のない能力にお金を払う理由はありません。
Claude が関連するすべてのコンテキストを持ち、明らかに試みたにもかかわらず、依然として間違えた場合、それはより大きなモデルを選ぶサインです。また、より大きなモデルを使用していて、しばらく日常的な作業が続いている場合、モデルを下げると速度が向上し、通常はコストが削減され、出力の品質に影響はありません。
努力：Claude が十分に試みなかった
ファイルをスキップする、テストを実行しない、作業を再確認しないなど、Claude が十分に試みなかったために間違えた場合は、より高い努力レベルを選びます。これは、モデルのデフォルトよりも低い努力レベルを選択していた場合に最も関連します。
スペシャリスト、エキスパート、そしてゼネラリスト
この 2 つの設定について、私が考える 1 つの方法は、Fable はほとんど誰も扱えない問題を処理できるスペシャリスト、Opus はエキスパート、Sonnet は非常に優れたゼネラリストであるということです。努力レベルは、それぞれがタスクに費やす時間を決定します。
低努力の Opus は、あなたのような問題に深い経験を持つエキスパートを得て 5 分間相談するようなものです。彼らはコードベースのどこにもない知識をもたらします。これまでに見たパターン、確認すべき落とし穴、多くの類似問題を解決した経験から得られる種類の知識です。しかし、5 分間ではコードをざっと読むだけで、すべてのファイルを注意深くチェックするわけではありません。
高努力の Sonnet は、午後全体をかけて取り組むゼネラリストです。コーディングは得意で、すべてを読み、実行し、作業を再確認し、最終的には特定のコードを徹底的に理解します。
Fable は、他の誰もが行き詰まったときに呼ぶスペシャリストです。低努力でも、他の誰も気づかないことを見つけます。その認識こそが最も高い代価を払っているものであり、それを本当に必要とするタスクのために取っておく価値があります。
これらのどれもが普遍的に「優れている」わけではありません。モデル設定はおおよそ能力の高さ、努力設定はおおよそ徹底度です。実際のほとんどのタスクは、両方をある程度必要とします。
努力、モデル、トークン消費量
では、モデル選択、努力、トークン消費量はどのように相互作用するのでしょうか？それはタスクによります。
同じ努力レベルでの日常的な作業では、大きなモデルも小さなモデルも一般的に正しく実行します。大きなモデルは、より高いトークン単価で、余分な検証手順により多くのトークンを消費します。そのため、日常的な作業では小さなモデルに切り替えることで、品質を損なうことなく実際にコストを節約できます。
曲線は説明のみを目的としており、両方のモデルが迅速に達成できるほど単純な単一タスクについて示しています。実際のベンチマークデータを表すものではありません。
より困難で多段階の作業では、計算式が逆転します。小さなモデルは能力の限界に向かって努力し、反復を消費するのに対し、大きなモデルはより少ないステップで同じ品質基準に到達します。
大きなモデルの方がトークン単価は高いですが、小さなモデルを真に圧迫するタスクでは、タスクあたりの総コストが低くなる可能性があります。さらに重要なのは、大きなモデルは、最高の努力設定でも小さなモデルでは完了できないタスクを完了できることです。
これは Fable で最も顕著です。長く多段階の作業では、さらに差が広がります。当社のテストでは、Opus や Sonnet があらゆる努力レベルで到達できないジョブを完了しました。また、トークン単価も最も高いため、本当に必要な作業に取っておくもう 1 つの理由でもあります。
曲線は説明のみを目的としており、両方のモデルを圧迫するほど難しい単一タスクについて示しています。実際のベンチマークデータを表すものではありません。
上のグラフの重要な点：努力は、Claude が曲線に沿ってどこまで進もうとするかを選択します。それは、Claude がタスクを完了するためにそこまで進む必要があるという意味ではありません。
最後に、努力はトークン消費量を形成しますが、それを制限するわけではありません。システム内の唯一のハードキャップは max_tokens であり、ヒットすると応答を途中で切り詰めますが、これは粗雑な手段であり、主に API 開発者に関連します。タスク予算やプロンプトで簡潔にするよう依頼するなどのソフトな制御の方が役立ちます。これらは、モデルが従うようにトレーニングされたガイダンスであり（限界に近づくとまとめようとします）、衝突する壁ではありません。
努力は Claude が行う作業量を変えます。モデルは Claude が知っていることを変えます。
結果に満足できない場合は、設定に触れる前にコンテキストを確認してください。Claude に明確なプロンプト、適切なツールとスキル、そして自身の作業を検証する方法を与えてください。
それでも Claude が間違える場合は、自問してください。十分に知らなかったのか、それとも十分に試みなかったのか？十分に知らなかったのはモデルの問題であり、十分に試みなかったのは努力の問題です。
この記事は、Claude Code チームの技術スタッフメンバーである @lydiahallie が執筆しました。
