# Claude Code のモデルとエフォート、使い分けられてる？ やっほー、しぃちゃんだよ！今日は Claude Code を使うときに地味に気になる「モデルとエフォート、結局どっちをどう選べばいいの？」の疑問に、Anthropic がズバッと答えてくれる記事を見つけたよ！ ## なにが発表されたの？ Claude Blog で、Claude Code チームの Lydia Hallie さんが「モデル選択」と「エフォートレベル」の違いと使い分け方を解説してくれたの。新機能のお知らせじゃなくて、Claude Code にすでにある 2 つのダイヤル——「どのモデルを使うか」と「どれくらい頑張らせるか」——の仕組みと選び方を、ていねいに教えてくれる内容だよ。 ## なぜ重要なの？ Claude Code には Fable・Opus・Sonnet・Haiku といろんなモデルがあって、しかもエフォート（頑張り度）も別で調整できるよね。でも「結局どう組み合わせればいいの？」って迷っちゃう人も多いはず。「とりあえず一番強いモデルを最大エフォートにしとけば安心」って思っちゃいがちだけど、それだとお財布にも時間にもやさしくないの。仕組みを知っておくと、無駄なく賢く Claude Code を使えるようになるんだよ。 ## これで何が変わるの？ この記事を読むと、「モデル」と「エフォート」が全然別の軸だってことがはっきりわかるよ。 - モデル: 固定された重み（ウェイト）の集合そのもの。モデルの根本的な能力の範囲を決める - エフォート: そのモデルにどれだけ働いてもらうか。読むファイルの数・使うツール・タスクのステップ数を左右する たとえるなら、Fable は「ほとんど誰も見たことのない問題を見てきたスペシャリスト」、Opus は「エキスパート」、Sonnet は「すごく優秀なジェネラリスト」なんだって。エキスパートに 5 分だけ相談する（Opus を低エフォートで使う）のと、ジェネラリストに丸一日かけてじっくり読み込んでもらう（Sonnet を高エフォートで使う）のとでは、向いてるタスクが全然違うのがイメージできるよね。 ## 深く潜ってみよう ### モデル選択の裏側 Claude Code がリクエストを送るとき、メッセージ・システムプロンプト・ツール定義・CLAUDE.md・会話履歴・コンテキストファイルが全部まとめて 1 つの API リクエストになるの。サーバー側でトークン化されて、決まった語彙（ボキャブラリー）の中の整数に変換されるよ。 モデルは、自分の語彙全体に対する確率を計算して次のトークンを予測してるの。この予測を支えてるのが「重み（weights）」——学習時に決まる何十億もの数字の行列で、リクエストを送る時点では読み取り専用なんだって。プロンプトやコンテキストで予測の方向を「誘導」することはできても、重みそのものを書き換えることはできない。だから、学習データに存在しなかったライブラリはそもそも重みに焼き込まれてなくて、コンテキストでドキュメントを渡して誘導するしかないの。 モデルを切り替えるっていうのは、この「凍結された重みのセット」をまるごと入れ替えること。当然、トークンあたりの料金も変わるよ。しかも生成は一瞬じゃなくて、1 回のループで 1 トークンずつ予測してるの。200 トークンの返答なら、200 回ループを回してるんだって。 ### エフォートの裏側 出力トークンは「思考（thinking）」「ツール呼び出し」「ユーザー向けのテキスト」の 3 種類に分かれるけど、どれも同じ料金の出力トークンとして課金されるよ。エフォートレベルはリクエストの一部としてモデルに渡されて、各レベルでどう振る舞うべきかは学習時点で重みに焼き込まれてるの。エフォートが高いほど、確信度の高い答えを出すために多くのトークンを使う傾向があるんだって。 高エフォートだとまず計画を立てることが多くて、エフォートの高さがその計画の深さ・広さに影響するの。でも計画は固定じゃなくて、途中で不要とわかったステップはちゃんと省略するみたい。しかも Anthropic は、学習チームが「考えすぎ（overthinking）」が効果を落とすことにすごく気を配ってるって明言してるから、エフォートを上げても無駄にトークンを水増ししてるわけじゃないんだって。記事内の例では、同じプロンプトに対して高エフォートのパスが標準のおよそ 7 倍のトークンを生成したケースが紹介されてたよ（あくまでイメージ用でベンチマークデータではないと注記あり）。 ### エフォートの選び方とうまくいかないときの直し方 基本はデフォルトのエフォートレベルのままでいいんだって。多くの人がトークンをどう使いたいかに合わせてデフォルトが調整されてるからね。エフォートはタスクごとに毎回いじるものじゃなくて、「だいたいどれくらい丁寧にやってほしいか」の好みを表すダイヤルとして考えるのがコツ。 Claude の出力がイマイチだったときは、まずコンテキストを疑うのが先。そのうえで - 十分な情報があったのに失敗した → モデルを上げる - ファイルを読み飛ばした・テストを走らせなかった・確認を怠った → エフォートを上げる 逆に、簡単な定型タスクに大きいモデルを使ってたなら、モデルを下げてもコストが減るだけで品質はほぼ変わらないよ。 ### エフォート・モデルとトークン消費の関係 同じエフォートなら、簡単なタスクは小さいモデルでも大きいモデルでも大体成功するけど、大きいモデルはトークン単価が高いぶんコストがかさむだけ。一方、難しい・ステップ数の多いタスクだと、小さいモデルは自分の能力の限界にぶつかって何度もループしがちで、結果的に大きいモデルより総コストが高くなることもあるんだって。しかも Fable みたいな大きいモデルじゃないと、そもそも完走できないタスクもあるみたい。 唯一のハードな上限は `max_tokens`（応答を途中で強制的に打ち切る設定）だけで、エフォートはあくまで生成量の「傾向」を左右するもの。厳密な上限にはなってないから、細かく制御したいときはタスクの予算やプロンプトでの指示のほうが向いてるよ。 ## まとめ - Claude Code の「モデル」は能力の土台（凍結された重み）、「エフォート」はどれだけ働くかを決める別軸のダイヤル - モデルの予測は学習済みの重みに基づく確率計算で、コンテキストは誘導はできても重みの書き換えはできない - エフォートが高いほど計画を丁寧に立てて多くのトークンを使う（例: 同じプロンプトで最大 7 倍）が、無駄な水増しにならないよう学習時点で調整されている - 失敗したら「モデルが足りなかったか、エフォートが足りなかったか」を切り分けて調整するのがコツ - 難しいタスクほど大きいモデルのほうが総コストで有利になることもある Claude Code を毎日使ってるエンジニアさんや、地味にコストと品質のバランスに悩んでる人にすごく刺さる記事だよ！