effortの使い分け

Claude Codeのeffortは、 どう使い分けるか。

公式の見解を軸に、ヘビーユーザーの実感を重ねて、 作業ごとにeffortを決める。

先に結論

  1. 01下書き・すぐ確認する作業low
  2. 02いつもの機能実装medium
  3. 03検証・バグ修正・レビューhigh(効けばxhigh)

2026年9月時点 ・ Opus 5.5 / Fable 5.1

1 / 20
はじめに

公式の説明では、effortは賢さではなく確認の量と任せる範囲を決める。

effortは、作業に使ってよい計算量の目安

lowのとき

人に「1時間で」と頼んだ仕事に近い

  • 要件を満たす版を早く出す
  • 確認は短く済ませる
  • 人と直しながら進める

high〜maxのとき

人に「12時間かけて」と頼んだ仕事に近い

  • 作り込んでから出す
  • 自分で試して確認し直す
  • あいまいな点を自分で決める

effortは時間の指定ではない。人が持ち時間で仕事の進め方を変えるように、effortによって確認の量と自分で決める範囲が変わる。

2 / 20
しくみ

既定はhighで、Opus 5.5だけmedium。

effortはlow〜maxの5種類。既定はClaude Codeでの値

effort
公式の位置づけ
既定になるモデル
アプリでの表記
low
最も効率的
サブエージェント向け
—
Low
medium
バランス型
Opus 5.5
Claude Code・API
Medium
high
課題に必要な分だけ使う
ほかのモデル
Fable 5.1もClaude Codeでは
High
xhigh
長いエージェント作業
30分を超える作業向け
—
Extra high
max
消費に上限を設けない
—
Max
この図をテキストで読む

比較表「effortの5つの値と既定」。3列 × 5行。 【列】 1. 公式の位置づけ 2. 既定になるモデル 3. アプリでの表記 【比較】(観点ごとに) ■ low - 公式の位置づけ: 最も効率的 / サブエージェント向け - 既定になるモデル: — - アプリでの表記: Low ■ medium - 公式の位置づけ: バランス型 - 既定になるモデル: Opus 5.5 / Claude Code・API - アプリでの表記: Medium ■ high - 公式の位置づけ: 課題に必要な分だけ使う - 既定になるモデル: ほかのモデル / Fable 5.1もClaude Codeでは - アプリでの表記: High ■ xhigh - 公式の位置づけ: 長いエージェント作業 / 30分を超える作業向け - 既定になるモデル: — - アプリでの表記: Extra high ■ max - 公式の位置づけ: 消費に上限を設けない - 既定になるモデル: — - アプリでの表記: Max

Fable 5.1は、Claude.aiとCoworkではmediumが既定。effortは思考・本文・ツール呼び出しのすべてに効く。

effortを変えても単価は変わらない。変わるのはトークンの量

3 / 20
公式の計測

上げるほど解ける課題は増え、トークンと時間も増える。

Terminal-Bench 3.0(端末操作の課題集)と、アプリ作りの時間

140→214
370回の試行のうち合格(Fable 5.1)
約3倍
1回あたりのトークン(7.3万→22.2万)
この図をテキストで読む

記録アプリ作りにかかった時間(Opus 5.5・1回)(棒グラフ) 【所要時間】 - low: 1.5 - medium: 4 - high: 11 - max: 67

単位分

合格とトークンはFable 5.1のlowとmaxの比較。時間はOpus 5.5の1回の記録で、xhighは測っていない。

Anthropic社内の計測(1課題5回)。公開ランキングとは一致しない

4 / 20
公式の計測

effortが高いほど、Claudeは自分で試す手順を増やす。

HTMLからJavaScriptを取り除く課題(Fable 5.1)

low

約2分・5回中1回だけ合格

  • 1回で書き上げる
  • 自分で書いた1ページだけで試す
  • 試したら終える

high〜xhigh

約33分・xhighは5回とも合格

  • 下書きを攻撃する側の目で見直す
  • 使う部品のソースを読む
  • 定番の攻撃パターン集で試す
  • ランダムな入力を自動で作って試す

Opus 5.5でも、ストレージのバグ修正はlowで5回とも失敗し、xhighで5回中4回合格した。effortが高いと、先に不具合を再現してから直していた。

合格数はxhigh、手順はhighの1回の記録

5 / 20
公式の計測

テストで拾えないバグは減るが、解釈の取り違えは増える。

Fable 5.1の370回の試行から、失敗5種類の件数を比べる

この図をテキストで読む

maxで減る失敗と、増える失敗(前後比較) 【○ low → ● max】 - テストで拾えないバグ: 40 → 14 - 不完全な修正: 31 → 10 - 要件の読み違い: 45 → 26 - 分野のルールの誤り: 32 → 24 - 解釈の取り違え: 25 → 47

単位回

テストで拾えないバグや不完全な修正(この資料でいう見落とし)は減った。解釈の取り違えは25→47に増えた。

分類はモデルによる判定。方針の誤りは上げても減らない(ブログ)

6 / 20
公式の計測

分野によって、effortの効き方は大きく違う。

Terminal-Bench 3.0の分野別の合格率(Fable 5.1)

この図をテキストで読む

分野別の合格率(低いeffort → 高いeffort)(前後比較) 【○ 低いeffort → ● 高いeffort】 - セキュリティ: 64 → 87 - ハードウェア: 34 → 75 - 機械学習: 54 → 73 - 科学: 41 → 61 - ソフトウェア: 43 → 56 - メディア: 18 → 30 - 業務処理: 12 → 22

単位%

例外の多いハードウェアは合格率が2倍以上に伸びた。規則を読み解く業務処理は、上げても2割台にとどまる。

低いはlow・medium、高いはhigh以上をまとめた値

7 / 20
公式の計測

仕様が薄いほど、effortで出来上がりが大きく変わる。

Opus 5.5に、同じ作業をeffortだけ変えて頼んだ

頼み方
low
max
あいまいな依頼
記録アプリを作って
記録とグラフだけ
1.5分
作り込んだアプリ
67分・ヒートマップ付き
方向だけ決めた依頼
設定画面の再設計
考えが伝わる試作
1分
実物に近い画面の試作
28分・操作の流れつき
詳しい仕様
人が質問に答えて作った
見た目も実装もmaxに近い
16分
細部を整理した
79分
この図をテキストで読む

比較表「頼み方ごとの出来上がり」。2列 × 3行。 【列】 1. low 2. max 【比較】(観点ごとに) ■ あいまいな依頼 - low: 記録とグラフだけ / 1.5分 - max: 作り込んだアプリ / 67分・ヒートマップ付き ■ 方向だけ決めた依頼 - low: 考えが伝わる試作 / 1分 - max: 実物に近い画面の試作 / 28分・操作の流れつき ■ 詳しい仕様 - low: 見た目も実装もmaxに近い / 16分 - max: 細部を整理した / 79分

直しながら決めたいならlowが早い。一度で完成に近づけたいときだけ上げる。

所要時間は1回の記録

8 / 20
公式の計測

日常のコーディングは、mediumで十分なことが多い。

SWE-bench Pro(コード修正の課題集)、Opus 5.5

effort
合格率の差
費用
向く場面
low
約8ポイント低い
約0.3倍
機械的な作業
名前の一括変更など
medium
Opus 5.5の既定
約2.5ポイント低い
約0.7倍
範囲の明確な日常作業
まずここから
high
基準
1倍
mediumで行き詰まったとき
xhigh
約1.4ポイント高い
2.5倍
効果を測れた作業だけ
maxも同じく測ってから
この図をテキストで読む

比較表「highを1とした合格率と費用」。3列 × 4行。 【列】 1. 合格率の差 2. 費用 3. 向く場面 【比較】(観点ごとに) ■ low - 合格率の差: 約8ポイント低い - 費用: 約0.3倍 - 向く場面: 機械的な作業 / 名前の一括変更など ■ medium - 合格率の差: 約2.5ポイント低い - 費用: 約0.7倍 - 向く場面: 範囲の明確な日常作業 / まずここから ■ high - 合格率の差: 基準 - 費用: 1倍 - 向く場面: mediumで行き詰まったとき ■ xhigh - 合格率の差: 約1.4ポイント高い - 費用: 2.5倍 - 向く場面: 効果を測れた作業だけ / maxも同じく測ってから

調査や知的作業では差がさらに小さく、lowでも1〜3ポイント減で費用が3〜5割下がった(前の世代のFable 5で測定)。

差は合格率のポイント差。Anthropic社内の計測

9 / 20
公式の計測

結果を確かめられるなら、lowで解いて失敗だけhighでやり直す。

SWE-bench Pro、Opus 5.5。1課題あたりの合格率と費用

すべてhighで解く
95.3%
合格率

1課題あたり約$0.29。

lowで解き、失敗だけhigh
費用は約6割
約97%
合格率

1課題あたり約$0.17。

highでやり直した分
13%
lowで失敗した課題

失敗を見つけるテストが要る。この分は2回分の時間がかかる。

失敗した課題に2回目の挑戦がある分、合格率も少し上がった。費用は約6割で済んだ。

費用は1課題あたりの平均(米ドル)

10 / 20
使い分け

effortは、確認の要否と、どこまで任せるかで選ぶ。

Anthropicのブログの目安に、xhighを書き足した

effort
向く場面
作業の例
low
人がすぐ確認できる
考えを出す・下書き・簡単な変更
medium
範囲がはっきりしている
新しい機能の実装
high
確認が欠かせない
既存コードのバグ修正
xhigh
highでは足りない
長い自律作業・広いレビュー
max
人が途中で入れない
重要なソフトの脆弱性探し
この図をテキストで読む

比較表「作業ごとのeffortの目安」。2列 × 5行。 【列】 1. 向く場面 2. 作業の例 【比較】(観点ごとに) ■ low - 向く場面: 人がすぐ確認できる - 作業の例: 考えを出す・下書き・簡単な変更 ■ medium - 向く場面: 範囲がはっきりしている - 作業の例: 新しい機能の実装 ■ high - 向く場面: 確認が欠かせない - 作業の例: 既存コードのバグ修正 ■ xhigh - 向く場面: highでは足りない - 作業の例: 長い自律作業・広いレビュー ■ max - 向く場面: 人が途中で入れない - 作業の例: 重要なソフトの脆弱性探し

迷ったらmediumから始め、足りないときだけ上げる。

xhighは目安に無いが、公式の検証例ではhighの上で使う

11 / 20
使い分け

機能開発は軽めのeffortで作り、方針は人、細部はhighが見る。

Anthropicのブログが勧める4つの手順

  1. 質問させる

    仕様を渡し、足りない点をClaudeに聞かせる。

    • 解釈が割れる点をここで決める
  2. low〜mediumで作る

    最初の版を作らせる。範囲が明確ならmedium。

    • 人が各段階で確認できる
  3. 人が確認する

    狙いどおりかを見て、同じeffortのまま直す。

    • 方針の誤りはここで拾う
  4. highで検証する

    テストと例外の確認を任せる。

    • 見落としをここで減らす

effortで直らない方針の誤りは人が拾い、effortが効く見落としはhighに任せる分担になる。

ブログはlow、Xの投稿はlow〜mediumで作ると書く

12 / 20
ヘビーユーザーの実感

普段はmedium、上げるのは見落としが事故になる仕事だけ。

2026年9月の投稿。小さな計測を含む

ほとんどmedium
開発者個人の投稿
medium
普段のeffort

Opus 5.5では、ほとんどの作業をmediumで行うと投稿(Boris Cherny)。

mediumとhighは同点
実測
15回とも合格
medium・highとも

自作5題を各3回。1題40秒と87秒(Qiita)。

危険度で決める
運用
low・high
UI・認証

UIの調整はlow、認証やデータ同期はhigh(X)。xhighは最初の計画だけ、という投稿も。

個人の実感と小さな計測。公式の見解とは分けて読む

13 / 20
ヘビーユーザーの実感

上げすぎや置き忘れで、浅い答えや利用枠の枯渇が起きる。

個人の報告。利用枠はプランの利用上限のこと

長いのに浅い

xhighをmediumに下げたら品質が上がった(Zenn)。

品質
枠が10分で尽きる

Fable 5.1のxhighでサブエージェントが10体以上動き、5時間枠が10分足らずで尽きた(Reddit)。

費用
不要なテストが増える

maxが余計なテストや防御を足す(Reddit)。

品質
maxが残っていた

環境変数のmaxが画面の設定より優先されていた(Zenn)。

設定

起きやすさはモデルとプランで変わる

14 / 20
ヘビーユーザーの実感

賢さとmaxの価値は見方が分かれ、利用枠は公式に記載が無い。

公式の見解とヘビーユーザーの声を並べる

論点
公式の見解
ヘビーユーザーの声
effortを上げると賢くなるか
確認の量と、自分の判断で進める範囲が増える
意見が割れる
「知能が上がる」と「長いのに浅い」
maxの価値
完全に任せる難題に使う
モデルで差が大きい
xhigh→maxの追加費用はOpus 5で+6%、Sonnet 5で+132%
利用枠の減り方
ブログには記載なし
effortだけで決まらない
モデルと並列の数も効く
この図をテキストで読む

比較表「見方が分かれる点と、公式に無い点」。2列 × 3行。 【列】 1. 公式の見解 2. ヘビーユーザーの声 【比較】(観点ごとに) ■ effortを上げると賢くなるか - 公式の見解: 確認の量と、自分の判断で進める範囲が増える - ヘビーユーザーの声: 意見が割れる / 「知能が上がる」と「長いのに浅い」 ■ maxの価値 - 公式の見解: 完全に任せる難題に使う - ヘビーユーザーの声: モデルで差が大きい / xhigh→maxの追加費用はOpus 5で+6%、Sonnet 5で+132% ■ 利用枠の減り方 - 公式の見解: ブログには記載なし - ヘビーユーザーの声: effortだけで決まらない / モデルと並列の数も効く

モデルが替わると、同じlow・highでも中身が変わる。前の世代の感覚を持ち込まず、測り直す。

増分はClaude Code内の見積もりをRedditで読み解いた値

15 / 20
設定

effortは/effortで切り替え、効かないときは環境変数を疑う。

Claude Codeでの指定方法と、効く範囲

方法
効く範囲
書き方の例
/effortコマンド
会話の中で
既定として保存
選択画面でsを押すとそのセッションだけ
/effort high
起動時の指定
--effort
そのセッションだけ
claude --effort low
環境変数
CLAUDE_CODE_EFFORT_LEVEL
最優先
画面や/effortより強い
CLAUDE_CODE_EFFORT_LEVEL=medium
設定ファイル
settings.json
モデルごとの保存値
modelSettings
スキル・サブエージェント
定義の先頭
実行中だけ上書き
省略すると親のeffortを継ぐ
effort: high
この図をテキストで読む

比較表「指定方法と効く範囲」。2列 × 5行。 【列】 1. 効く範囲 2. 書き方の例 【比較】(観点ごとに) ■ /effortコマンド - 効く範囲: 既定として保存 / 選択画面でsを押すとそのセッションだけ - 書き方の例: /effort high ■ 起動時の指定 - 効く範囲: そのセッションだけ - 書き方の例: claude --effort low ■ 環境変数 - 効く範囲: 最優先 / 画面や/effortより強い - 書き方の例: CLAUDE_CODE_EFFORT_LEVEL=medium ■ 設定ファイル - 効く範囲: モデルごとの保存値 - 書き方の例: modelSettings ■ スキル・サブエージェント - 効く範囲: 実行中だけ上書き / 省略すると親のeffortを継ぐ - 書き方の例: effort: high

途中でeffortを変えると、多くのモデルはキャッシュを作り直す。Opus 5.5とFable 5.1は、APIキーかサブスクリプションならキャッシュを保つ。

maxは環境変数で指定した場合を除き、そのセッション限り

16 / 20
実践例

複雑な業務の機能は、mediumで作り、high〜xhighで検証する。

請求・入金や在庫の引当など、規則の多い業務機能を想定

工程
effort
ねらい
仕様を詰める
low〜medium
質問させて、人が決める
計算の規則・例外・締め日
実装
medium
通常の機能実装
規則が多いのでlowは避ける
検証・テスト
high〜xhigh
例外を探させる
境界値・合計の一致・二重実行
レビュー
xhigh
見落としを減らす
見落としの代償が大きい
この図をテキストで読む

比較表「工程ごとのeffort」。2列 × 4行。 【列】 1. effort 2. ねらい 【比較】(観点ごとに) ■ 仕様を詰める - effort: low〜medium - ねらい: 質問させて、人が決める / 計算の規則・例外・締め日 ■ 実装 - effort: medium - ねらい: 通常の機能実装 / 規則が多いのでlowは避ける ■ 検証・テスト - effort: high〜xhigh - ねらい: 例外を探させる / 境界値・合計の一致・二重実行 ■ レビュー - effort: xhigh - ねらい: 見落としを減らす / 見落としの代償が大きい

端数処理や引当の順序など、どちらでも筋が通る規則はeffortを上げても決まらない。先に人が決める。

この資料の提案。公式の目安と利用者の実感から組み立てた

17 / 20
まとめ

effortを選ぶ前に、仕様と確認の方法を用意する。

公式の見解とヘビーユーザーの実感から選んだ5つの実践

普段はmedium

足りないときだけ上げる。2〜3つの値を別のセッションで比べ、xhighとmaxは効果を測れた作業だけ。

上げるのは検証

例外・セキュリティ・既存コードのバグ。

解釈は人が決める

上げると、取り違えがむしろ増える。

失敗だけやり直す

テストがあれば、lowで解き失敗だけhighでやり直すと安い。

親のeffortを継がせない

サブエージェントにはeffortとモデルを指定する。

18 / 20
付録

数値と設定は変わるので、公式ページで確かめてほしい。

Anthropicのブログ

公式ドキュメント

確認日:2026年9月26日

19 / 20
付録

ヘビーユーザーの声は、次の投稿と記事から引いた。

個人の投稿は2026年9月時点のもの

20 / 20