9月25日、claude.devが「Using Claude Code: Spending your effort / claude.dev Blog」と題した記事を公開した。Claude Codeの「エフォート（effort）」機能がどのように動作し、タスクの種類に応じてどの設定を選ぶべきかが、実測データをもとに詳述されている。
エフォートとは何か
Claude Codeの最新モデル（Opus 5.5、Fable 5.1）には、プロンプトキャッシュを壊さずにモデルの思考量を調整できる「エフォート」機能が搭載されている。
ここで「プロンプトキャッシュを壊さない」という特性が重要な意味を持つ。プロンプトキャッシュとは、会話履歴や長い文脈を再利用してAPIコストと応答速度を改善する仕組みだ。従来、思考量を変えるためにシステムプロンプトを書き換えるとキャッシュが無効化されコストが増大するという問題があった。エフォートはこの問題を回避しつつ、モデルへの計算リソース配分を動的に変えられる点で実用上の価値が高い。
エフォートとは、モデルにどれだけのコンピュートを使わせるかの近似値だ。記事ではこんなたとえを使っている——「12時間かけてやれ」と言われたら全力で判断しながら進む。「1時間でやれ」と言われたら最善の初稿を出してイテレーションを想定する。エフォートはこれと同じ考え方で機能する。
/effort コマンドをClaude Code上で使うことで、会話の途中でも切り替えが可能だ。
数字で見るエフォートの効果
記事の核心は、Terminal-Bench 3.0を使った実測結果だ。Terminal-Benchは、ターミナル上での複雑なエンジニアリングタスクを対象としたオープンソースのベンチマークスイートで、GitHubのコミュニティによって整備・公開されている。バージョン3.0は70タスクで構成され、FPGAへの8ビットゲームコンソール実装、Lean 4での数学的定理の形式証明、MoEチェックポイントのマージなど、実務より格段に難しいタスクを含む。
エフォートを上げるほどベンチマークスコアと消費トークン数がともに増加するという曲線が確認されており、問題カテゴリ別のパス率の変化は以下の通りだ（Fable 5.1、低エフォート→最高エフォート）：
| カテゴリ | 低エフォート | 最高エフォート |
|---|---|---|
| セキュリティ | 64% | 87% |
| ハードウェア | 34% | 75% |
| ML | 54% | 73% |
| 科学 | 41% | 61% |
| ソフトウェア | 43% | 56% |
| メディア | 18% | 30% |
| オペレーション | 12% | 22% |
セキュリティとハードウェアで特に差が大きい。一方、メディア・オペレーション系ではエフォートを上げてもあまり変わらない。
「エッジケース」の有無が分岐点
記事で最も具体的なのが、HTMLサニタイザーのタスク（html-js-filter）だ。JavaScriptを埋め込むあらゆる手法を遮断するHTMLサニタイザーを実装するもので、Fable 5.1は低エフォートで5回中1回成功、最高エフォートで5回中5回成功という結果だった。
- 低エフォート（約2分）: フィルターをほぼ一発で書き、手書きの1ページでテストして終了。
- 最高エフォート（約33分）: 初稿を敵対的にレビュー→パーサーのソースコードを読んでバグ確認→クリーンなテストケースを多数実行→標準XSSテストスイートを流す→ランダムドキュメントファズテストを実装。
この差は、エフォートが「作業量」ではなく「検証と判断の深さ」に影響するという事実をよく示している。
同様に、線形計画ソルバー（cli-2ph-simplex）ではOpus 5.5が低エフォートで0/5→高エフォートで5/5、遺伝子セット濃縮解析（gsea-proteomics）では0/5→4/5という結果が出ている。いずれも「エッジケースの発見と対処」が成否を分けている。
なお記事では重要な指摘として、エフォートを上げてもアプローチ自体が間違っている場合は改善しないと明言している。エフォートで減るのは「エッジケースの見落とし」であり、「根本的な方針ミス」は別の問題だ。
通常の開発作業でのエフォートの使い方
記事では、仕様が少ないタスクと詳細な仕様があるタスクを比較した実験も行っている。フィットネストラッカーアプリを「インタビューなし」で依頼した場合、低エフォートでは簡単なログとグラフのみ、最高エフォートではヒートチャートつきの複雑なUIが生成された。一方、詳細な仕様を与えると、エフォートレベルによる差は大幅に縮まるという結果も出ている。
これを踏まえ、記事では新機能開発で筆者が実際に使っているループを紹介している：
- Claudeに仕様を渡し、足りない詳細をインタビューさせる
- 低エフォートで実装させる
- 方向性を確認し、低エフォートでイテレーション
- 高エフォートで検証・テストを実施
エフォートレベルの選択指針
記事が示すルール・オブ・サムは以下の通りだ：
- Low（低）: ブレインストーミング、スケッチ、簡単な変更など、ループに入りたい場合
- Medium（中）: 通常の新機能実装など、日常的なソフトウェアエンジニアリング
- High（高）: バグ修正（既存コードベース）や、検証・エッジケース対応が重要な作業
- Max（最大）: 自律的にアプリ全体を構築・検証させたい場合、セキュリティ脆弱性の発見など
ベンチマーク結果が示す通り、エフォートの効果はタスクの性質に強く依存する。セキュリティやハードウェアのように「見落としが致命的になるドメイン」ではMaxの投資対効果が高い一方、メディア・オペレーション系のタスクではLowやMediumで十分なケースが多い。また、詳細な仕様を事前に与えることでエフォートへの依存度自体を下げられる点も、コスト管理の観点で覚えておく価値がある。
詳細はUsing Claude Code: Spending your effort / claude.dev Blogを参照していただきたい。
