まず結論

effortは「この作業にどれだけ力をかけるか」をClaudeに伝える設定です。この記事のデータと図表は、AnthropicのThariqによる記事「Using Claude Code: Spending your effort」（Xの原文、claude.devのインタラクティブ版）に基づいています。選び方や例は、小企鵝が初心者によくある作業に合わせて整理しました。

急いでいるなら、この図だけ見れば十分です。

どのeffortを使えばよい？

effortで何が変わる？

友人に書類を見てもらう場面を想像してください。「ざっと見て」と頼めば、友人は全体に目を通して返してくれます。「明日印刷に出すから、念入りに見て」と頼めば、一語ずつ確認し、気になる表現も直してくれるでしょう。effortは、この頼み方にあたります。Thariqの観察によると、Claudeが自分でどれだけ検証し、境界ケースをテストし、代わりに判断するかを調整します。

境界ケース（edge case）とは、普段は起きないものの、起きると問題につながる特殊な状況です。たとえば、空の入力、極端に大きなファイル、見慣れない記号などです。

effortを高くすると、主に2つの変化があります。Claudeが自分で何度も確認し、代わりにより多くの判断をします。 前者はたいてい役立ちますが、後者は自分で主導権を持ちたいかどうかによります。

タスクに当てはめて選ぶ

手元の作業が、次のどれに近いか考えてみましょう。

段階こんなタスクコスト
low誤字の修正、短い文章の書き直し、アイデアを出し合う待ち時間が短く、tokenの使用量も比較的少ない
medium書かれた仕様に沿って、既存ツールに機能を追加する待ち時間とtokenの使用量は中程度
high特定の条件でだけ起きるバグを修正する待ち時間が明らかに長くなり、tokenも大幅に増える
max小さなツール一式をClaudeに任せ、自分はそばで見守らない待ち時間が長く、tokenの使用量も比較的多い

表にないxhighはhighとmaxの間です。highより丁寧に作業してほしいものの、maxほど長く待ちたくないときに使えます。

tokenは、AIがテキストを処理するための計算単位です。おおまかには文字数のようなものと考えられます。使用量が増えるほど費用がかかり、プランの上限にも早く達します。段階は最初に決めきる必要はありません。Claude Codeで/effortと入力すれば、会話の途中でも切り替えられます。

どのくらい時間が変わるのでしょうか。Thariqが「個人用のフィットネス記録アプリを作る」という同じ指示で試したところ、lowでは約1.5分、maxでは約67分かかり、maxではClaudeが自分で追加した機能もかなり増えました。

同じ指示にかかる時間

effortを高くするのが向いているとき

判断のために、次の3つを考えてみましょう。

  1. 失敗したときの代償は大きいか？
  2. 特殊な状況がどれだけ隠れているか？
  3. 自分がそばで見ていて、すぐに修正を伝えるか？

最初の2つに「大きい」「多い」と答え、3つ目に「いいえ」と答えたなら、effortを高くする価値があります。逆に、簡単で確認しやすく、自分が最初から最後まで見ていられる作業なら、lowかmediumで十分です。待ち時間を増やしても、得られるものはあまりありません。

ThariqがTerminal-Bench 3.0（コミュニティが問題を作成したテストセット）の結果を分析したところ、同じ傾向が見られました。たとえば、JavaScriptを埋め込むあらゆる方法を防ぐHTMLフィルターを書く問題では、Fable 5.1はlowで5回中1回しか成功しませんでしたが、xhighでは5回すべて成功しました。分野ごとに見ると、Fable 5.1をlowから最高effortまで上げたときの合格率は次のとおりです。

effortを高くすると差が出やすい作業

セキュリティ（64% → 87%）とハードウェア（34% → 75%）は伸びが大きく、どちらも繰り返し検証することが重要です。運用（12% → 22%）とメディア（18% → 30%）の伸びは比較的小さくなっています。テストの運用問題は、規定に沿って会社の月末貿易統計申告を完了させるものでした。小企鵝の見立てでは、手順どおりに進める作業は、確認を何度も重ねても効果は限られるようです。

effortを高くしても解決できないこと

effortで主に強化されるのは確認作業です。方向性の間違いを修正できるとは限りません。Thariqは投稿への返信で、要件が非常に曖昧な場合を除き、effortが違ってもClaudeはほぼ同じ道筋をたどると説明しています。分析でも、effortを高くすると境界ケースを見落とした失敗は減りますが、最初に方法を間違えると、高くしても取り戻せないと指摘しています。

effortを高くすると何が改善する？

Fable 5.1はlowとmaxでそれぞれ370回試され、合格数、テストで見つからなかったバグ、要件の見落としはいずれも改善しました。一方、「要件に2通りの解釈があり、間違ったほうを選んだ」ケースは25回から47回に増えました。effortが高いほど、Claudeは自分で仮定を置くようになります。要件が曖昧なままでは、effortを高くしても正しい解釈を自動で選べません。 間違った解釈を選べば、時間をかけて間違ったものを作ることになります。

対策は自分でできます。

  • 「完成した状態」を具体的に書きます。たとえば、どの画面が必要か、データをどこに保存するかを指定します。
  • Claudeが独自に機能を足さないよう、やらないことを列挙します。
  • 1つの文に2通りの解釈があると気づいたら、どちらにするか自分で決めて書き込みます。
  • まずlowかmediumで初版を作り、方向性が合っていると確認してから、最後にhighへ切り替えて十分に検証します（Thariqも新機能を作るときはこのように切り替えています）。

Thariqはまた、詳しい仕様（spec）を書いてから、異なるモデルやeffortに作業を頼むと、各バージョンの成果がかなり近くなることも確認しました。まず要件を明確に書き、それからeffortを決めましょう。

小企鵝のまとめ

小企鵝はAIチームに作業を分担させており、effortはおおよそ次のように使い分けています。

  • 毎日の調整と作業の割り振り：high
  • 書かれた仕様に沿った定型的な開発：medium
  • 戦略やシステム設計の判断：xhigh

これはThariqの記事を読んでから、改めて割り当てたものです。effortで得られるのは確認作業であり、方向性は明確な要件で決まります。仕様が明確な作業ならmediumで十分です。effortを高くすべきなのは、失敗の代償が大きく、特殊な状況も多い作業です。

関連記事

参考資料