原典: Using Claude Code: Spending your effort
一行要約
effort はどれだけ検証しエッジケースを試し、自分の判断を使うかを調整する。見えないエッジケースが多い作業（ハードウェア・セキュリティ・コードレビュー）ほど上げる価値があり、上げても取り組み方そのものの誤りは直らない。普段の機能開発は「インタビュー → low で実装 → 確認 → high で検証」。
要点
effort とは何か
At a high level, effort gives the model an approximation of how much compute you want it to spend on the task. … Claude will always try and do your task reasonably, but higher effort will involve Claude taking more independent action for judgement and verification.
大まかに言えば、effort はそのタスクにどれだけ計算を使ってほしいかの目安をモデルに与える。……Claude はいつでもタスクを妥当にこなそうとするが、effort を上げると、判断と検証のために Claude が自分から取る行動が増える。
12時間あると言われれば徹底的にやり、1時間なら要件を満たす最善版を出して後で詰める —— effort もそう捉える。
具体的なタスクで（Opus 5.5）
- 仕様のゆるい作り物（「フィットネス記録アプリを作って」）—— effort でアプリの作り込みが大きく変わり、Claude が途中で下す選択も増える（low 1.5分・medium 4分・high 11分・max 67分）
- ある程度決まった設計（
/configメニューの作り直し）—— どれも同じ発想（サブメニューと検索の改善）。low（1分）は発想が伝わるスケッチ、max（28分）は Claude Code らしい見た目のモックと複数の流れの説明。著者はここでは low で Claude の考えを掴むほうを好む - 詳しい仕様を渡したもの —— モデルの振る舞いはずっと似通い、設計も実装も似たものになった（low 16分〜max 79分）
Low effort allows Claude to respond quickly with a starting point, higher effort levels will get more work done but Claude will also make more assumptions on my behalf.
low なら Claude は出発点をすぐに返す。高い effort はより多くの仕事をするが、Claude が自分の代わりに置く前提も増える。
難しいタスクで（Terminal-Bench 3.0）
My main takeaway from reading the Terminal-Bench 3.0 results was that higher effort is best for tasks with lots of hidden edge cases.
Terminal-Bench 3.0 の結果を読んでの一番の結論は、高い effort が最も効くのは、隠れたエッジケースの多いタスクだということである。
- HTML サニタイザ（
html-js-filter）: Fable 5.1 は low で 1/5、xhigh で 5/5。low は約2分で1回書いて1ページで試すだけ、high は約33分で、最初の案を敵対的にレビューし、パーサのソースを読み、標準の XSS テストを走らせ、ランダム文書の fuzzer まで書いた - effort を上げると「エッジケースの見落とし」による失敗は減るが、「取り組み方の誤り」による失敗は直らない
- 分野別の通過率（Fable 5.1。分野ごとの件数が少ないので、低い effort は各モデルの低い2段、高い effort は高い3段を合算した値）: セキュリティ 64% → 87%、ハードウェア 34% → 75%、ML 54% → 73%、科学 41% → 61%、ソフトウェア 43% → 56%、メディア 18% → 30%、運用 12% → 22%
- Opus 5.5 が low で落ち high で通った例は、どれも検証の差 —— low ではビルドや再現より先にコードを直し、新しいテストが元のバグを捕まえるかを確かめなかった。high ではクラッシュを先に再現し、圧縮しない参照実装に対するランダムテストを書き、未完成の修正でテストが落ちることを確かめた
- GSEA の例では、high はデータの前処理を2通り試し、有意な処理の一覧が変わるのに気づいて理由を調べた。ユーザーが関与していれば聞いたかもしれないが、関与していないなら high のほうが良い
数字の注記（原典）: 社内の実行、タスクごとに5回。Fable 5.1 は本番の安全介入をオフにして走らせた（Claude 製品では Fable 5.1 の安全機構が一部のセキュリティ依頼を Opus に回す）。セキュリティのタスクはインターネット無し。公開リーダーボードや発表の数字とは合わない。
Claude Code での使い分け（著者の目安）
| effort | 使うとき |
|---|---|
| low | 速い応答で関与し続けたいとき。ブレスト、スケッチ、簡単な変更 |
| medium | 普段のソフトウェアエンジニアリングの大半。新機能の実装 |
| high | 検証が大事、エッジケースがある。既存コードベースのバグ修正 |
| max | 難しい問題を完全に自律で解かせたいとき。アプリを端から端まで作って検証、重要なソフトウェアの脆弱性探し |
そのまま使える具体例
機能開発のループ（著者が使っているもの）:
- 仕様を渡し、足りない点を Claude にインタビューさせる
- low で実装する
- 要点が合っているかを確認し、必要なら low で詰める
- high で検証とテストをする
/effort（会話の途中でも Claude Code で effort を変えられる）
原典で言及されている関連文書
（原典は他の sources へのリンクを持たない）