Claude Codeのmodelとeffort｜指定が黙って書き換わる3つの場面

Claude Code で結果が思ったほど良くなかったとき、私たちはたいてい同じことをします。モデルを上のものに切り替えます。Sonnet だったら Opus に、Opus だったら Fable 5 に。

ここ最近、その手前にもうひとつつまみがあることが知られるようになりました。effort です。日本語の記事もいくつか出てきて、「モデルと effort の2軸で考えましょう」という話はもう珍しくなくなりました。

ただ、私は最近そこから先で引っかかっています。2軸で考えて、設定して、それで終わりではないようなのです。指定した値が、そのまま動くとは限りません。

公式ドキュメントを読み直していて、こういう一文を見つけました。

After a fallback, the session continues on the fallback model.

フォールバックが起きたあと、セッションはフォールバック先のモデルで続きます、と書いてあります。あるきっかけでモデルが勝手に一段下がり、そのまま戻らない場面があるわけです。同じような「黙って書き換わる」挙動が、調べてみると effort 側にも2つありました。

この記事では、その3つのズレを公式ドキュメントの原文にあたって整理します。あわせて、決めたルーティングを .claude/agents/ のファイルに固定する書き方と、Fable 5 が Opus 5 のちょうど2倍単価であることから導ける損益分岐を置きます。

先に結論の一部を書いてしまうと、こうなります。Opus 5 の effort を上げてトークン消費が2倍になるところまでは、Fable 5 に切り替えるより安く済みます。単価がちょうど2倍だからです。

なお、モデルそのものの選び方の早見表はFable・Codex・Sonnet・Opusの使い分け早見表に書きました。あちらがモデル選択の一覧で、こちらはそこに effort という2本目の軸と、設定が書き換わる場面を足したものだと思ってください。

Claude Codeには、つまみが2つあります

モデル設定は「どれだけ有能か」を決め、effort 設定は「どれだけ念入りか」を決めます。別々のものを決めているので、片方だけ回しても足りません。まず、この土台を短く確認します。

Claude Code には「答えを良くする」ように見える設定が2つあります。この2つは似ているようで、実際にはまったく別のものを動かしています。

Claude Code チームの Lydia Hallie さんが書いた公式ブログChoosing a Claude model and effort level in Claude Codeに、私が読んだ中でいちばん腑に落ちた表現がありました。

The model setting is roughly how capable; the effort setting is roughly how thorough.

モデル設定は「どれだけ有能か」、effort 設定は「どれだけ念入りか」を決めている、という整理です。

同じブログには、こんなたとえも出てきます。Fable はほとんど誰も見たことのない問題を見てきた専門医で、Opus は熟練の専門家、Sonnet は腕のいい何でも屋です。effort は、その人がどれだけの時間をあなたの仕事に使うかを決めるつまみだ、というわけです。

だから「Opus を低い effort で使う」と「Sonnet を高い effort で使う」は別物になります。前者は熟練者に5分だけ見てもらう状態で、あなたのコードは流し読みされますが、その人が過去に踏んだ地雷の知識は持ってきてくれます。後者は腕のいい何でも屋に午後まるごと使ってもらう状態で、あなたのコードは隅々まで読まれますが、「これ前に見たことがある」という直感は薄くなります。

現行のモデルと料金を並べておきます。すべて公式のモデル一覧からの引用です。

MTok というのは100万トークンのことです。トークンは AI が文章を読み書きするときの最小単位で、水道でいうリットルにあたります。

この表で先に目を留めておいてほしいのが2箇所あります。ひとつは、Fable 5 が Opus 5 のちょうど2倍単価だという点です。入力も出力も、きれいに2倍になっています。もうひとつは、知識のカットオフが逆転している点です。上位モデルである Fable 5 のほうが、Opus 5 より4ヶ月ぶん古いのです。ここには後で戻ってきます。

なお Sonnet 5 は2026年8月31日まで導入価格の $2 / $10 が適用されています。

公式が示している出発点はシンプルです。

If you’re unsure which model to use, start with Claude Opus 5 for complex agentic coding and enterprise work. For workloads that need the highest available capability, use Claude Fable 5.

迷ったら Opus 5 から始めて、使える限りいちばん高い能力が要る作業だけ Fable 5 を使いなさい、ということですね。Claude Code でも Fable 5 は既定モデルではなく、/model fable で明示的に選ぶ形になっています。

effortは「考える時間」ではなく「やる仕事の量」です

effort が動かすのは思考時間だけではありません。読むファイルの数、動かすツールの数、あなたに返事をするまでの手数まで含めた「やる仕事の量」を決めています。公式ブログの比較では、同じプロンプトで effort を上げるとおよそ7倍のトークンが出ました。

ここが、私が今回いちばん認識を改めた部分です。

effort という名前から、「長く考えさせる設定」だと思っていました。実際にはもっと広いものを動かしています。公式のEffort ドキュメントにはこう書かれています。

The effort parameter affects all tokens in the response, including: Text responses and explanations / Tool calls and function arguments / Thinking (when active)

effort は応答に含まれるすべてのトークンに効きます。あなたへの説明文にも、ツール呼び出しにも、思考にも効きます。そして続けてこうあります。

For example, lower effort would mean Claude makes fewer tool calls.

effort を下げると、ツール呼び出しの回数が減ります。

ツール呼び出しというのは、Claude がファイルを読む、テストを走らせる、コードを編集する、といった行動のことです。つまり effort は「どれだけ長く考えるか」ではなく、「あなたに返事をするまでに、どれだけの仕事をやるか」を決めていることになります。読むファイルの数も、動かすツールの数も、確認に戻る回数も、すべて含まれます。

公式ブログの表現を借りるとこうです。

At a higher effort, Claude will take more of those actions (for example, read files, run tests, and double-check) before it comes back to you. At lower effort, it would rather ask you for more context than spend tokens figuring something out on its own.

effort が低いと、自力で調べるより先にあなたに聞きに来ます。この挙動、心当たりがある方も多いのではないでしょうか。

冒頭に書いた7倍という数字は、ここから来ています。同じプロンプトを2つの effort で走らせた比較で、高いほうはおよそ7倍のトークンを生成したと書かれていました。そしてトークンが7倍になるということは、そのまま料金も7倍になるということです。

レベルは5段階あります。

high が既定で、これは effort を指定しないのとまったく同じ挙動になります。

表の low の欄に出てくるサブエージェントというのは、本体の Claude が下請けとして呼び出す別の Claude のことです。検索だけを担当させる、実装だけを担当させる、といった具合に役割を切り出して使います。この記事の後半で、そのサブエージェントごとにモデルと effort を指定する話が出てきます。

そして max については、Claude Code のドキュメントが珍しくはっきりした警告を出しています。

Can improve performance on demanding tasks but may show diminishing returns and is prone to overthinking. Test before adopting broadly.

厳しい作業では性能が上がることもあるが、リターンが逓減し、考えすぎに陥りやすい。広く採用する前にテストしなさい、と。

ここは覚えておく価値があります。後で出てくる公式ベンチマークは「max effort の Opus 5 が Fable 5 のピークに肉薄する」と言っているのに、Claude Code のドキュメントは「max は考えすぎる」と言っている。矛盾ではなく、ベンチマークの一点と日常運用の平均は違う、という話だと私は読んでいます。

公式ブログの推奨も、実は控えめです。

Our guidance is that for most tasks you should use the model’s default effort level.

ほとんどの作業では、モデルの既定値を使いなさい。つまみは、意識的に回すときだけ回すもの、というスタンスですね。

迷ったら「知らなかった」のか「やらなかった」のかで分ける

では、どういうときに回すのでしょうか。ここで公式が出している判断基準が、私はかなり使えると思っています。

まず前提として、公式ブログはつまみを回す前にもう一段上を見ろと言っています。

When Claude gets something wrong, your first instinct shouldn’t be to adjust a knob, but to examine the context you have provided. Is your prompt too vague? Is Claude connected to the right tools? Equipped with the right skills?

うまくいかなかったとき、最初にやるべきはつまみをいじることではなく、渡した文脈を見直すこと。プロンプトが曖昧すぎないか、必要なツールに繋がっているか、必要なスキルを持たせているか。

If you’re increasing effort on a task that shouldn’t need it, the fix is often upstream, in your context, your CLAUDE.md, or how the task is scoped.

本来 effort を上げる必要のない作業で effort を上げているなら、直すべきはたいてい上流にある、と。ここは耳が痛い方もいるかもしれません。私は痛かったです。

文脈は整っています。それでも間違えました。そのときに使う問いが、これです。

did it not try hard enough, or did it not know enough?

やる気が足りなかったのか、知識が足りなかったのか。

この2つで、回すつまみが決まります。

読み飛ばしや途中放棄は effort の問題で、自信満々に間違えるのはモデルの問題です。この切り分けは、言われてみると当たり前なのですが、症状から診断名に一発で飛べる形になっているのが効くところだという気がしています。

ここまでが土台です。ここから、設定したはずの値が動く話に入ります。

ズレ1: セーフガードでモデルが差し替わり、そのまま戻らない

Fable 5 と Opus 5 には、サイバーセキュリティと生物学の内容に対する安全分類器が付いています。分類器というのは、送られてきた質問がその分野に該当するかどうかを自動で判定する仕組みのことです。これに引っかかると、リクエストが別のモデルで再実行されます。

Claude Code のモデル設定ドキュメントに、行き先まで明記されています。

Fable 5: biology-flagged requests re-run on Opus 5, and cybersecurity-flagged requests re-run on Opus 4.8. Opus 5: cybersecurity-flagged requests re-run on Opus 4.8. Biology-flagged requests end with a refusal instead, because Opus 5 runs its own biology classifiers with no fallback model.

表にするとこうなります。

Fable 5 を選んでいても、サイバーセキュリティ系の質問をすると Opus 4.8 が答えています。世代でいうとひとつ前のモデルです。

そして、私が今回いちばん驚いたのがこの続きでした。

After a fallback, the session continues on the fallback model. To return to your original model, run /model.

フォールバックのあと、セッションはフォールバック先のモデルのまま続きます。元のモデルに戻すには /model を実行してください、と。

自動で戻らないのです。

想像してみてください。Fable 5 でセッションを始めて、途中で認証まわりの実装について聞きます。そこで分類器が反応して Opus 4.8 に落ちます。そのあと、あなたはセキュリティとは無関係な設計判断を延々と相談し続けます。ずっと Opus 4.8 で、Fable 5 を選んだつもりのまま進むわけです。

トランスクリプトには通知が出るとドキュメントには書いてあります。ただ、長いセッションを回しているとき、その一行を見逃さない自信は私にはありません。

課金については救済があります。Fable 5 の製品ページにこうあります。

Many queries in these domains are automatically routed to less capable models if flagged by these safeguards. You won’t be charged Fable prices for rerouted requests.

再ルーティングされたリクエストに Fable 価格は請求されません。お金は取られません。失われるのは、自分が今どのモデルと話しているかという前提のほうです。

頻度についても数字が出ています。Opus 5 の発表には、Opus 5 の分類器は Fable 5 のものよりおよそ85%少ない頻度でしか介入しないと見込んでいる、と書かれています。裏を返せば、Fable 5 では相応の頻度で起きているということです。

Opus 5 の分類器が何を通して何を止めるかも明記されています。ソースコード中の脆弱性を見つけることは許可され、バイナリベースの脆弱性スキャン、ペネトレーションテスト、エクスプロイト生成は禁止されています。

面白いのは、この挙動をすでに設計に織り込んでいる実プロジェクトがあることです。Claude Code 向けのマルチモデル構成であるpilotfishは、セキュリティ実装用のサブエージェントを意図的に Opus に固定していて、その理由をプロンプト内にこう書いています。

it is deliberately routed to Opus — the frontier model’s safety classifiers can refuse benign defensive-security work mid-task, so security tasks never go there.

最上位モデルの安全分類器は、善意の防御的セキュリティ作業を作業の途中で拒否することがある。だからセキュリティ関連の作業は最初からそこへ送らない、と。

ルーティング設計に「作業の種類」だけでなく「話題」という軸が要る、というのはここから来ます。セキュリティ監査やインシデント対応を Fable 5 に投げる設計にしていると、いちばん Fable 5 の能力が欲しい局面で、いちばん低いモデルが返事をしてくる可能性があります。

ズレ2: effortの目盛りは、モデルごとに違う

同じ high でも、Sonnet 5 の high と Opus 5 の high は別のものです。effort の目盛りはモデルごとに較正されていて、対応していないレベルを指定するとエラーにならずに下へ丸められます。2つめは地味ですが、影響範囲は広いかもしれません。

Claude Code のドキュメントに、こう書かれています。

The effort scale is calibrated per model, so the same level name does not represent the same underlying value across models.

effort の目盛りはモデルごとに較正されていて、同じレベル名がモデルをまたいで同じ中身を表すわけではない。

Sonnet 5 の high と Opus 5 の high と Fable 5 の high は、名前が同じだけで別のものだということです。摂氏と華氏で同じ「30」が違う暑さを指すのと似ています。少なくとも、あるモデルで効いた設定を別のモデルにそのまま持っていくのは、根拠のない移植になります。

公式の Opus 5 向け推奨も、まさにそこを名指しで釘刺ししています。

If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them.

前のモデルから effort 設定を引き継いできたなら、使い回すのではなく、自分の評価セットで effort を振り直しなさい。

ここでいう評価セット（evals）は、いつも自分がやっている作業を何本か固定して、設定を変えたときに結果がどう変わるかを比べるための、手元のテストのことです。難しく考えなくても、いつもの作業を3つ選んで、effort を変えて2回ずつ走らせて見比べる、くらいで十分です。

ここは日本語の記事でもあまり見かけない指摘です。Opus 4.7 世代の実測記事が日本語にはいくつかあって、私も参考にしてきたのですが、そこで出ている「このタスクは medium で足りる」という結論を Opus 5 にそのまま当てはめてはいけない、というのが公式の立場ということになります。

対応レベルの表も出ています。

ここにもうひとつ静かな挙動があります。

If you set a level the active model does not support, Claude Code falls back to the highest supported level at or below the one you set. For example, xhigh runs as high on Opus 4.6.

対応していないレベルを指定すると、エラーにはならず、その下でいちばん高いレベルに丸められます。Opus 4.6 に xhigh を指定すると high として走ります。指定は通ったように見えて、実際には別の値が使われている状態です。

既定値もモデルによって違います。effort に対応しているモデルの既定は high ですが、Opus 4.7 だけは xhigh が既定です。

あと1点、max には持続性の違いがあります。low medium high xhigh は対話セッションで設定するとセッションをまたいで残りますが、max はそのセッション限りです。ただし CLAUDE_CODE_EFFORT_LEVEL 環境変数で設定した場合は例外的に残ります。「昨日 max にしたはずなのに」という感覚のズレは、ここから来ます。

ついでに、よく誤解される点をひとつ挙げておきます。プロンプトに ultrathink と書くと、そのターンだけ深い推論を要求できます。ただしドキュメントには、API に送られる effort レベルは変わらないと明記されています。そして「think」「think hard」「think more」といった言い回しはキーワードとして認識されず、ただのプロンプト文として通過します。効いている気がしていた方は、ここを疑ってみてください。

ズレ3: モデルを替えても、effortが前のまま残ることがある

Sonnet 5 を low で使っていて Opus 5 に切り替えると、effort は low のまま引き継がれます。ところが Fable 5 に切り替えた場合は既定の high に戻ります。3つめは、この挙動がモデルによって割れているぶん厄介です。

Claude Code のドキュメントから引きます。

When you first run Fable 5, Opus 4.8, or Opus 4.7, Claude Code applies that model’s default effort even if you previously set a different level for another model, and holds it across sessions until you make an explicit effort choice. Opus 5 has no such hold: a level you previously set carries over.

Fable 5、Opus 4.8、Opus 4.7 を初めて動かすときは、別のモデルで違うレベルを設定していたとしても、そのモデルの既定 effort が適用されて、明示的に選び直すまで保持されます。ところが Opus 5 にはそのホールドがなく、前に設定したレベルがそのまま引き継がれます。

具体的に何が起きるかというと、こうです。

コストを抑えるために Sonnet 5 を low で回していたとします。難しい作業が来たので /model opus で Opus 5 に切り替えます。このとき effort は low のまま引き継がれます。あなたは「Opus 5 に上げたのに大して良くならないな」と感じます。当然です。熟練者に5分だけ渡している状態のままなのですから。

同じことを Fable 5 でやると挙動が変わります。Fable 5 はホールドがあるので、low を捨てて自分の既定である high に戻ります。

同じ操作をしているのに、行き先のモデルによって effort の運命が違います。これは知らないとまず踏みます。

対処はシンプルで、モデルを切り替えたら effort を確認する、これだけです。/effort を引数なしで実行するとスライダーが開いて現在値が見えます。/effort auto でモデルの既定値に戻せます。/model のピッカーの中でも、左右キーで effort スライダーを動かせるようになっています。この2つのつまみが同じ画面に同居しているのは、たぶん設計者が「セットで決めるもの」だと考えているからでしょう。

effort を設定する経路は複数あります。優先順位が絡むので、並べておきます。

なお /effort のメニューには ultracode という項目もありますが、これは effort レベルではなく Claude Code 側の設定です。モデルには xhigh を送りつつ、実質的な作業ごとに動的なワークフローを組ませる、という挙動になります。セッション限りです。

上位モデルほど知識が新しいとは限らない

3つのズレとは別に、ルーティング設計に効いてくる事実がもうひとつあります。冒頭の表で目を留めておいてほしいと書いた、あれです。

Fable 5 は最上位モデルですが、知識は Opus 5 より4ヶ月ぶん古いことになります。Fable 5 の一般提供が2026年6月9日、Opus 5 の発表が2026年7月24日なので、単純に後から出たぶん Opus 5 のほうが新しい情報を持っている、という話です。

これは能力の優劣とは別の軸です。推論の深さでは Fable 5 が上でも、「2026年2月に出たライブラリの仕様」を知っているのは Opus 5 のほうだけ、ということが起こります。

実務でどう効くのでしょうか。ライブラリのバージョンアップ対応、最近変わった API の移行、新しいフレームワークの採用検討あたりが該当します。この手の作業では、いちばん賢いモデルを選ぶと、いちばん古い知識で答えられる可能性があります。

もちろん、モデルの内部知識に頼らずドキュメントを読ませればいい話ではあります。ただ、それは「ドキュメントを読ませる設計にしている」場合の話で、何気なく質問したときに返ってくる答えは内部知識に依存します。

というわけで、ルーティングの判断軸は「作業の難しさ」だけでは足りないことになります。私の整理はこうです。

決めたルーティングを .claude/agents に固定する

ここまでの判断を、毎回手で /model と /effort を叩いて再現するのは現実的ではありません。ファイルに固定できます。

Claude Code のサブエージェントは .claude/agents/ 以下に Markdown ファイルとして置きます。ファイル先頭の frontmatter で設定を書けるのですが、frontmatter というのはファイルの冒頭を --- で挟んで囲んだ部分のことで、そのファイルの設定を書く場所だと思ってください。公式ドキュメントによると必須は name と description の2つだけです。指定できるフィールドの全一覧はこうなっています。

name / description / tools / disallowedTools / model / permissionMode / mcpServers / hooks / maxTurns / skills / initialPrompt / memory / effort / background / isolation / color

この中に model と effort の両方があります。ここが今回の話の着地点です。2軸で決めた判断を、そのままファイルに書けます。

公式ドキュメントに載っている最小の例がこれです。

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

各フィールドの公式の説明を要点だけ拾っておきます。

• model: sonnet / opus / haiku / fable / フルモデルID（claude-opus-5 など）/ inherit のいずれか。既定は inherit で、メイン会話と同じモデルになります
• effort: そのサブエージェントが動いている間の effort レベル。セッションの effort を上書きします。既定はセッションから継承
• skills: 起動時にコンテキストへ読み込むスキル。説明文だけでなくスキルの中身が丸ごと注入されます。tools に Skill を並べるのではなく、こちらを使うようドキュメントに明記されています
• isolation: worktree を指定すると、リポジトリの使い捨てのコピーの中で動きます。本体の作業ツリーを触られたくないときに使います
• background: v2.1.198 以降、未設定でも既定でバックグラウンド実行になります

ここで注意点をひとつ挙げておきます。model の既定が inherit だということは、何も書かないサブエージェントはメイン会話のモデルを引き継ぐという意味です。メインを Fable 5 にしていると、書いていないサブエージェントは全部 Fable 5 で動きます。組み込みの Explore エージェントも v2.1.198 以降はメイン会話のモデルを継承する挙動に変わりました（Anthropic API 経由では Opus が上限）。検索のような大量かつ判断の要らない作業が、上位モデルの単価で走ることになります。

では実際にどう振ればいいのでしょうか。ここは既に運用されている構成を見るのが早そうです。先ほど出てきた pilotfish の実際の設定を、リポジトリから引いてきました（MIT ライセンス）。

きれいに2軸で振られているのが分かります。探索と調査は「有能さも念入りさも要らない」ので haiku の low になっています。実装は判断の有無で effort を low と medium に分け、検証はモデルを opus に上げる代わりに effort は medium で止めています。そしてセキュリティだけが両方高くなっています。

このリポジトリが Opus 5 の発表当日に、既定を opus エイリアス（バージョンを固定せず「最新の Opus」を指す書き方）へ切り替え、Fable 5 は /model fable での明示的な選択に回した、と README に書いているのも参考になります。理由は「コストを意識した既定であって、Opus 5 が普遍的に優れているという主張ではない」とわざわざ断ってあります。

これを踏まえた自分用の3本を書くと、こうなります。公式ドキュメントの例を土台に、model と effort を明示したものです。

1本目は計画担当です。曖昧な問題を扱うのでモデルを上げますが、書くのは計画だけなので編集ツールは持たせません。

---
name: planner
description: 曖昧な要件や設計判断を扱い、実装計画だけを返す。コードは書かない
tools: Read, Glob, Grep, WebSearch
model: opus
effort: xhigh
---

あなたは実装計画だけを作る担当です。コードの変更は一切行いません。

受け取った要件について、まず前提と制約を確認し、選択肢が複数ある場合は
それぞれの結果を比較したうえで推奨を1つ示してください。
出力は、実装者がそのまま着手できる粒度のタスク一覧と、
判断が必要な箇所の明示に絞ってください。

2本目は実装担当です。定型作業を回すのでモデルを下げます。

---
name: executor
description: 計画が確定した実装を担当する。仕様が決まっている変更、パターン適用、テスト追加
tools: Read, Glob, Grep, Edit, Write, Bash
model: sonnet
effort: medium
disallowedTools: Agent
---

あなたは確定した仕様を実装する担当です。

渡された計画の範囲だけを実装してください。範囲外の改善や
「ついでの修正」は行いません。仕様が曖昧だった場合は、
推測で実装せず、どこが曖昧かを報告して止まってください。

実装後は、型チェックだけで済ませず、実際に該当する動作を
動かして確認してください。

3本目は検証担当です。実装担当とは別の文脈で、疑ってかかる役になります。

---
name: verifier
description: 実装済みの変更が主張どおり動くかを、独立した文脈で反証しにいく
tools: Read, Glob, Grep, Bash
model: opus
effort: medium
disallowedTools: Write, Edit, Agent
---

あなたは反証担当です。「実装できました」という主張と、その差分を受け取ります。

その主張を否定しにいってください。テストを自分で走らせ、
該当する動作を自分で動かし、差分が扱っていない境界を探します。
実装者のテスト結果は信用せず、自分で再現してください。

結論は CONFIRMED か REFUTED のどちらかで返します。
REFUTED の場合は、失敗する具体的な手順と、期待と実際の差を添えてください。
修正はしません。

もう1箇所、ルーティングを固定できる場所があります。スキルです。スラッシュコマンドのドキュメントによると、SKILL.md の frontmatter にも model と effort を書けます。スキルが動いている間だけモデルと effort が切り替わり、次のプロンプトでセッションのモデルに戻る、という挙動です。${CLAUDE_EFFORT} という変数も用意されていて、現在の effort に応じてスキルの指示を変えることもできます。

まとめると、ルーティングを固定できる場所は3層あります。

サブエージェントを使ったコスト設計そのものについては、Return on Tokenで見直すClaude運用に3層構成の考え方を書きました。別ツールを組み合わせる方向に振るなら、Claude Code×Codex連携の実装のほうが近いと思います。

2倍の単価差をどこで回収するか、そしてズレに気づく仕掛け

Fable 5 は Opus 5 のちょうど2倍単価です。ここから、Opus 5 の effort を上げてトークン消費が2倍になるところまでは Fable 5 より安い、という損益分岐が出ます。最後に、その計算とチェックリストを置きます。

Opus 5 の発表ページに、この記事の主題にそのまま効く数字が載っています。

On CursorBench 3.2, at max effort, the model performs within 0.5% of Fable 5’s peak score, but at half the cost per task; it also achieves greater performance at a given cost than all other models on high, xhigh, and max effort.

CursorBench 3.2 で、max effort の Opus 5 は Fable 5 のピークスコアの0.5%以内に入り、しかも1タスクあたりのコストは半分だった。

コンピュータ操作のベンチマークでも同じ方向です。

On OSWorld 2.0, a computer use benchmark, Opus 5 outperforms every other model at any given cost, surpassing Fable 5’s best result at just over a third of the cost.

OSWorld 2.0 では、Fable 5 の最良結果を、3分の1強のコストで上回った。

もうひとつ、effort の下側についての記述もあります。Zapier AutomationBench について、Opus 5 は最低の effort 設定でも他のどのモデルよりも多くのタスクを通した、と書かれています。

ここから、判断の順序が見えてきます。モデルを上げる前に、effort を上げてみる価値があります。少なくとも Anthropic 自身のベンチマークでは、Opus 5 の effort を上限まで回したところが Fable 5 のピークの近くに来ています。

では、どこまで effort を上げると割に合わなくなるのでしょうか。ここは単価表から算術で出ます。

Fable 5 は Opus 5 のちょうど2倍単価です。入力が $10 対 $5、出力が $50 対 $25 と、きれいに2倍です。しかもモデル一覧を見ると、両者のコンテキストは同じ100万トークンで、文字数あたりのトークン数も同じです。どちらも100万トークンでおよそ55万語ぶんが入ります。Opus 4.6 の世代は同じ100万トークンで75万語ぶん入っていたので、Opus 4.7 で新しいトークナイザに変わったことが分かります。トークナイザというのは、文章をトークンに切り分ける仕組みのことで、これが変わると同じ文章でもトークン数が変わります。今回は Fable 5 と Opus 5 が同じものを使っているので、価格差は純粋に単価の差であって、同じ文章が違うトークン数に化けるという話ではありません。

だから、こうなります。

同じ作業を Opus 5 で片付けられるなら、effort を上げてトークン消費が2倍になるところまでは、Fable 5 に切り替えるより安く済みます。3倍になったら負けます。

式にするとこうです。

Opus 5 で effort を上げたときのコスト = 基準トークン × 倍率 × 1
Fable 5 に切り替えたときのコスト     = 基準トークン × Fableの倍率 × 2

→ Opus 5 の倍率が 2 × Fableの倍率 を超えたら、Fable 5 のほうが安い

自分の数字で確かめるなら、月間の入力トークン量を X（MTok）、出力を Y（MTok）として、こうです。

Opus 5 の月額  = 5X + 25Y ドル
Fable 5 の月額 = 10X + 50Y ドル
差額           = 5X + 25Y ドル（つまり Opus 5 の月額とちょうど同額）

月に入力40MTok、出力4MTok を使っているチームなら、Opus 5 で $300、Fable 5 で $600、差額は $300 です。この $300 を effort に振ったほうが得か、モデルに振ったほうが得か、という問いに置き換わります。

ただし、この計算には正直に置いておくべき前提があります。同じ作業なら Fable 5 のほうが少ないトークンで終わる可能性が高い、という点です。公式ブログにこう書かれています。

On harder, multi-step work … The smaller model has to grind toward the limit of its ability, burning iterations, while the larger model reaches the same quality bar in fewer steps.

難しい多段の作業では、小さいモデルは能力の限界に向かって反復を重ねて燃やす一方、大きいモデルは少ない手数で同じ品質に届く。だから2倍の単価差が、実際の請求では2倍にならないこともあります。

さらに、上限そのものが違う場面もあります。

In our testing, it finished jobs Opus and Sonnet can’t reach at any effort level.

私たちのテストでは、Fable 5 は Opus や Sonnet がどの effort レベルでも届かない仕事を終わらせた。

つまり「2倍のトークンまでは Opus 5 が安い」という損益分岐は、両方が終わらせられる範囲の中でだけ成り立つ話です。そもそも Opus 5 が終わらせられない作業なら、コスト比較は意味を持ちません。この線引きが、Fable 5 を「切り札」として残しておく理由になります。

料金の考え方をもう少し広く見たい方は、昨日書いたClaude Code料金は異常に安いのほうに、サブスクの実測とキャッシュ読込が倍率を作っている構造を置いてあります。この記事の試算はAPI単価の話なので、サブスクで使っている方はそちらと合わせて読むと繋がります。

ひとつ小ネタを挟みます。Opus 5 には Fast モードがあって、既定の2.5倍の速度で動きます。料金は基本価格の2倍です。$5 / $25 の2倍なので $10 / $50 です。Fable 5 とまったく同じ単価になります。速度を買うか能力を買うかが、同じ値段で並ぶわけですね。

最後に、この記事で扱った3つのズレに気づくためのチェックリストを置きます。

• セッションの途中で /model を実行して、今どのモデルが動いているかを確認します。特にセキュリティや生物学に触れる質問をしたあとが要注意です
• セキュリティ監査やインシデント対応を扱うサブエージェントには model: opus を明示して、Fable 5 に流れないようにしておきます
• モデルを切り替えたら /effort で現在値を確認します。Opus 5 に切り替えたときは、前のモデルの設定が残っている可能性があります
• 別のモデルで決めた effort 設定を、新しいモデルにそのまま持ち込まないようにします。公式も、評価セットで取り直すよう明記しています
• サブエージェントを作ったら model を明示的に書きます。書かないと inherit になり、メイン会話のモデルで動きます
• 2026年2月以降の情報が要る作業では、Fable 5 の知識が2026年1月までであることを思い出してください

これからのことも短く書いておきます。私は、この手の設定はいずれ「決めるもの」から「観測して直すもの」に寄っていくのだろうと思っています。今すでに、モデルは黙って差し替わり、effort の目盛りはモデルごとに違い、引き継ぎ挙動もモデルごとに割れています。設定ファイルに書いた値と、実際に動いた値が一致している保証は、もうないわけです。

だとすると、次に効いてくるのは「何を指定するか」より「何が動いたかを記録しておくか」のほうではないでしょうか。企業で使うなら、なおさらそうだと思います。Enterprise プランでは管理者がモデル別に effort の上限をかけられる仕組みも既に入っていて、指定した値が組織のポリシーで丸められることもあります。指定と実行の間に、レイヤーが増え続けている感触があります。

最後に道具の話をひとつ。私たち Deskrex が開発しているSnorbeは、ナレッジグラフ型のリサーチAIエージェントです。この記事でやったような、公式ドキュメントの原文にあたって挙動の裏を取り、複数のページに散っている記述を1つの判断表に繋ぐところまでを引き受けます。Snorbe 自身も、計画と実行でモデルを分けて組んであります。この記事で扱った2軸の考え方を、リサーチ業務そのものに適用した形です。調査を、出典まで辿れる根拠付きで手元に残したい方は一度触ってみてください。

よくある質問

Q1. 既定のモデルは Opus 5 と Fable 5 のどちらにすべきですか

公式の指針は Opus 5 から始めることです。モデル一覧のページに「迷ったら複雑なエージェント的コーディングや業務には Opus 5 から始め、使える中でいちばん高い能力が必要な作業に Fable 5 を使いなさい」と書かれています。Claude Code でも Fable 5 は既定ではなく /model fable で明示的に選ぶ形です。Opus 5 は Claude Max の新しい既定モデルにもなっています。Fable 5 は、長時間の多段作業や、Opus 5 がどの effort でも終わらせられなかった作業のために取っておく、という位置づけが素直だと思います。

Q2. effort を上げるのとモデルを上げるのは、どちらを先に試すべきですか

症状で分かれます。公式ブログの基準は「やろうとしなかったのか、知らなかったのか」です。ファイルを読み飛ばした、テストを走らせなかった、リファクタを途中で放り出した、という失敗なら effort を上げます。全部の文脈を渡して真面目にやった形跡があるのに間違えたなら、モデルを上げます。ただし、その前にもう一段上を見るよう公式は言っていて、プロンプトが曖昧すぎないか、必要なツールとスキルに繋がっているかを先に確認するのが順序としては最初です。

Q3. max effort は常に使ったほうがいいのでしょうか

いいえ。Claude Code のドキュメントは max について「厳しい作業では性能が上がることもあるが、リターンが逓減し、考えすぎに陥りやすい。広く採用する前にテストしなさい」と書いています。公式ブログの推奨も「ほとんどの作業ではモデルの既定値を使いなさい」です。Anthropic のベンチマークで max effort の Opus 5 が Fable 5 のピークに肉薄したのは事実ですが、それはベンチマークの一点であって、日常のあらゆる作業に当てはめるものではありません。なお max はセッション限りの設定で、CLAUDE_CODE_EFFORT_LEVEL 環境変数で指定した場合を除いて次のセッションには残りません。

Q4. モデルが勝手に差し替わったことに、どうやって気づけばいいですか

Claude Code はフォールバックが起きるとトランスクリプトに通知を出します。ただ、長いセッションではその一行を見落としがちです。確実なのは /model を実行して現在のモデルを確認することで、特にセキュリティや生物学に触れる質問をしたあとは見る価値があります。フォールバック後のセッションは自動では元のモデルに戻らず、フォールバック先のモデルのまま続くためです。予防としては、セキュリティ関連の作業を扱うサブエージェントの frontmatter に model: opus を明示して、そもそも Fable 5 に流さない設計にしておく方法があります。

Q5. サブエージェントの model と effort は、何を基準に決めればいいですか

作業に必要な「有能さ」と「念入りさ」を別々に見て決めます。探索や検索のように判断がほとんど要らない大量作業は、モデルも effort も下げてかまいません。公式ドキュメントの effort レベル表でも、low の典型的な用途としてサブエージェントが挙げられています。逆に、成果を疑ってかかる検証役はモデルを上げる価値がありますが、検証は範囲が決まっているので effort は中程度で足ります。重要なのは、model を書かないと既定が inherit になり、メイン会話のモデルで動く点です。メインを Fable 5 にしていると、書いていないサブエージェントが全部 Fable 5 の単価で走ります。

Q6. Fable 5 と Opus 5 では、同じ文章のトークン数は変わりますか

変わりません。公式のモデル一覧を見ると、Fable 5 と Opus 5 はどちらも100万トークンでおよそ55万語ぶんの容量です。Opus 4.6 世代は同じ100万トークンで75万語ぶんだったので、Opus 4.7 で導入された新しいトークナイザを Fable 5 と Opus 5 の両方が使っていることになります。両者の価格差は純粋に単価の差であって、同じ文章が違うトークン数に化けるという話ではありません。だからこそ「トークン消費が2倍を超えたら Fable 5 のほうが安い」という損益分岐がそのまま成立します。

Q7. プロンプトに「think hard」と書けば深く考えてくれますか

いいえ。Claude Code のドキュメントによると、キーワードとして認識されるのは ultrathink だけです。「think」「think hard」「think more」といった言い回しは、ただのプロンプト文として通過します。そして ultrathink を使った場合でも、API に送られる effort レベル自体は変わらず、そのターンに対する指示が文脈に追加される形になります。セッション全体の挙動を変えたいなら /effort で設定するほうが確実です。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/