ミスが起きたとき、まず疑うのは「モデルが賢くないせいだ」だった。だが公式ブログが整理していたのは、モデル選択とは別にエフォート（作業量）というもう1本のダイヤルがある、という話だった。
「モデルを変える」と「エフォートを上げる」を混同しない判断軸と、ミスの原因を『知識不足』か『手抜き』かで診断してから調整するという、Claude Codeチーム自身の運用フレーム。
以前の記事で「探す・数える・集める・要約するは安いモデル、書く・直す・判断するは既定モデル」というタスクの動詞でモデル単価を分けるルールを運用に組み込んだ。これはこれで効いた。だが、ミスが起きたときの対処法は、実はもう1段別の話だった。
「答えが雑になった」「ファイルを読み飛ばしている」——こうした不満が出るたびに、反射的に「もっと賢いモデルに変えよう」としていた。だが公式ブログ「Choosing a Claude model and effort level in Claude Code」を読むと、これは半分しか正しくない対処だと分かる。モデル選択とエフォートレベルは、そもそも別のレバーとして設計されている。
この2つを同じ「賢さ」の話として混同すると、無駄な変更を繰り返すことになる。
モデルを選ぶという行為は、訓練時に固定された知識ベースと能力範囲を丸ごと選び直すことに等しい。公式の言葉を借りれば「モデルの重みは訓練時に設定され、実運用では読み取り専用。プロンプトやコンテキストはこれを変更しない」。つまりモデルを変えても、そのモデルが元々知らないことは知らないままだ。
一方エフォートは「考える時間だけでなく、読むファイル数、検証の程度、複数ステップタスクの進捗度合いに影響する」と説明されている。同じモデルのままでも、エフォートを上げれば「ファイルをもっと読む」「テストをちゃんと実行する」「途中で切り上げない」という挙動に変わる。
ここが核心。ミスの原因が「そのモデルが知らないこと」ならモデルを変えるしかない。だがミスの原因が「知っているのに手を抜いた」なら、変えるべきはモデルではなくエフォート。この2つを同じ棚で扱うと、的外れな変更を繰り返す。
公式ブログは、モデルの違いをこんな比喩で説明している。Fableは誰も見たことがないような問題を見た経験を持つ専門家、Opusは経験豊富な専門家、Sonnetは優秀な一般人——同じ問題を渡しても、見たことのある引き出しの数が違う、というイメージだ。
この比喩を踏まえた使い分けの推奨がこちら。
そして公式は「ほとんどのタスクではモデルのデフォルトエフォートレベルを使うべき」とも念を押している。エフォートは万能の底上げボタンではなく、ミスの原因が努力不足だと診断できたときだけ上げる調整弁として扱う、というのが趣旨に近い。
手元の運用は元々「動詞でモデル単価を分ける」というモデル軸1本だけのルールだった。今回の整理を踏まえると、同じCLAUDE.md上にもう1本、エフォート軸の判断を足すのが自然だ。
# モデル軸（既存ルール）：タスクの動詞で単価を分ける
探す・数える・集める・要約する → 軽量モデル
書く・直す・濃い検証 → 既定モデル
# エフォート軸（今回の追加）：ミスの原因で調整する
原因が「知らない」 → モデルを上げる
原因が「手を抜いた」 → 同じモデルのままエフォートを上げるポイントは、ミスが起きるたびにこの2行を思い出し直すことではなく、「まず原因を診断してから、どちらのダイヤルを回すか決める」という手順自体を先に固定してしまうことにある。診断を飛ばして反射的にモデルを上げる癖が一番のコスト増だった。
「モデルを上げる」は、実は一番コストの高い選択肢でもある。