Claude Codeのエフォートの選び方は、どこまで口を出したいかで決める

出典: Anthropicが明かした、強さレベルの選び方（12分完全攻略）（広川万雄）

言いよどみは省いています

動画は問題提起から始まります（0:00）。多くの人が「高いほどいい」と思い込み、低いは使わず、いつも高いのまま。自分の画面も、そうなっていないでしょうか？

1:01 から広川さんは、5段のエフォートを、Opus・Sonnet・Haiku というモデルの賢さとは別の「手間」の話として分けます。

広川さん（動画の中で・1:12〜）

エフォート（強さ）が決めるのは、Claudeがその作業にどれだけ時間と手間をかけるかです。

同じモデルでも、段が高いほど、たくさん読んで試し、何度も確かめてから返す。12時間なら1人でやり切り、1時間なら最初の版を出して直す、という Thariq さんの記事の例えも、この話の土台です。

広川さん（動画の中で・1:52〜）

つまりエフォートは、自分がどれだけ作業に関わりたいかを決めるつまみでもあります。

画面には5目盛りのゲージが出て、左端が「自分が決める」、右端が「Claude が決める」。段は、どこまで作業の中にいたいかの目盛りでもあるわけです。

広川さん（動画の中で・2:47〜）

Anthropicはもう1つとても大事なことを見つけています。悪い指示文は、エフォートを上げても治らないということです。

2:47 で広川さんは、別の発見として、指示文が悪ければ段を上げても結果は良くならない、と話します。

2:56 からは「低い」で、使いどころは、Claude と何度も確かめながら進める時、作業が簡単な時、高いで作った物を仕上げる時。

広川さん（動画の中で・3:29〜）

低いは、ただの知能の低いモードだと思っている人がまだ多いですが、そんなことはありません。

低いは、考える力を落とした段ではありません。頼んだことだけをやり、それ以上はしない段なので、作業がいくつかに分かれる時は簡単なチェックリストを渡す。

段の名前は、賢さの順位ではありません。どこまで任せるかの目盛りです。

私なら、エフォートを選ぶ前に、この作業で私がどこまで口を出したいかを先に決めます。口を出したい作業ほど、段の名前より先に、自分がどこで見に戻るかを決めておく。

3月10日に公開したClaude Code の effort 設定（AIの思考量）を、コンテンツの種類ごとに使い分けた私の記事に、こう書きました。この3月の記事は max まで含めた使い分けで、いまの運用とは違います。

私の記事より（Claude Code の effort 設定（AIの思考量）を、コンテンツの種類ごとに使い分けた私の記事（2026年3月10日））

lowだから手抜き、ではないということ。lowは「考えなくていいことを考えない」ということです。

低い段を選ぶのは、手を抜くためではない。今は要らない検討をAIに背負わせない、という選び方です。

そのぶん、どこを確かめるかは人が持つ。私には、ここがこの章の芯です！

5:01 からは「中」。Thariq さんは普段の仕事のほとんどを中で回している、と広川さんは紹介します。公式 Docs でも、Opus 5.5 の初めの設定は中。

中が合うよくある作業5つは、毎日書くもの、作り直し、会議のまとめ、いつもの報告、手早い調べもの。

広川さん（動画の中で・6:04〜）

リディアさんは、中の仕上がりが良くない時も、すぐにレベルを上げないように言っています。まずは渡した情報や指示文を見直します。

広川さんがリディアさんの話として紹介する助言で、指示文を先に見直す向きは、第1章の 2:47 の話と同じ向き。この助言の出どころは、第5章で原典と並べます。

上げる前に、いま自分がどの段で動いているかを見ます。違う答えが出たら、渡した背景・意図・設定を見る。これは私の見立てで、公式の助言ではありません。

9月24日、私は Opus 5.5 の既定の強さを、設定ファイルと、使っているAI管理ツールの Opus 5.5 用の設定の2か所で、medium にそろえました。直す前にAIにどう思うかと問いかけ、2か所とも medium に直す案を選んだのは私。実際の書き換えは、AIが行いました。

10月29日に私が公開したOpus 5.5 は medium から始める、と整理した動画記事に、9月24日の記録を書きました。

私の記事より（Opus 5.5 のモデルの使い分けを動画から整理した記事の中の、9月24日の記録（記事は2026年10月29日公開））

9月24日の記録。私は、Opus 5.5 の既定の強さ（effort）を medium にそろえました。設定に effort が xhigh のまま残っていて、強さを決めずに起動した Claude は xhigh で動いていたからです。

この話は、指示文を見直した話ではありません。強さを決めずに起動すると、設定に残っていた段（xhigh）で動いていた、という話です。

11月10日に私が公開したFable 5.2 の公式ガイド解説動画を整理した記事に、10月1日の朝までの設定点検を書いています。

10月1日の朝までに、私はAIに頼んで、使っているモデルと effort の設定を全部点検してもらいました。設定の抜けは10件。強さを決めていないと公式の既定で high で動く Sonnet 5.5 には、medium が明示されました。ここでいう既定の high は、API で effort を書かない時の公式の初めの設定の話で、Claude Code そのものの初期値の話ではありません。

書いていない設定は、無いわけではありません。既定のまま動いているんです！

6:27 からは3段目の「高い」です。出番は2つ。間違えると本当に困る時と、例外が多い作業です。契約書の条件や、決算の報告書の数字がその例に並びます。

広川さん（動画の中で・6:34〜）

つまり高いは、間違えると本当に困る時に使います。お金を失う、信頼を失う、間違った数字で何かを決めてしまう、といった時です。

間違いが、そのままお金や信用の傷になる場面の段。画面の業務委託契約書では、第5条の検収後120日以内の支払いと、第9条の途中解約で残りの期間の全額が違約金になる条文が、赤で強調されます。

6:48 からのデータ分析の例では、低いが1つのやり方で毎回間違え、高いは2つのやり方を試してズレに気づき、5回中4回正解でした。

広川さん（動画の中で・7:06〜）

実はThariqさん自身がこのやり方です。最初の段階は低いで作り、低いのままやり取りを重ね最後に全部を確かめる時だけ高いに切り替えます。

作る間は低いで軽く回し、最後の確かめの1回だけ高いに上げる順番。引用の「やり取りを重ね」は、元の表記「やり方を重ね」を、画面のスライドが「やり取りを重ねる」と書いているので、スライドの表記に合わせて直した所です。

広川さん（動画の中で・8:44〜）

大事なのは、作業の長さより、どれだけ判断や確かめが必要かです。

長い仕事だから高い、ではない。決まりに従うだけの作業は、上げても一番よくはならなかった、と広川さんは続けます。

確かめる手間をAIに寄せても、最後の味見は人が持ちます。

私なら、高いにするのは、人が最後に見る前に、AIにも確かめさせたい所だけにします。数字の照らし合わせや、契約書の危ない条文。AIが確かめた物を、最後に人が1回見る順番です。AIに確かめさせる所と、人が最後に見る所を分ける。

確かめる手間を高いに任せたあと、最後の1回は誰が持ちますか？

高いは、人の確かめを消すための段ではありません。人の確かめを軽くするための段です！

8:46 からは最後の2段、「超高」と「最大」。Thariq さんがこの2つを使うのは、こちらが何も口を出していない時だけ、と広川さんは紹介します。

条件は、全部当てはまる時だけ。何時間か席を外して質問に答えられない。作業がとても長くて難しい。質が、時間や使用量の上限より大事。1つも当てはまらなければ、おそらく高いでよい、という線です。

向く例は、1年分の通話と問い合わせから解約理由を調べる長い調べもの、50ページの契約書のサイン前チェック、1発で一番の仕上がりが欲しい投資家向け資料です。

広川さん（動画の中で・10:43〜）

この動画を見ているほとんどの人にとって、最大を使うことは滅多にないはずです。

最大は、ふだんの仕事ではほとんど出番がない段。料金がかなり増える割に質があまり上がらず、考えすぎて結果が悪くなることもある、と広川さんは話します。

10:49 からの「迷ったら4つの質問」は、最初に「はい」になった所で止める形で、①やり取りが多いか簡単な作業→低い、②見えない間違いでお金・お客さん・判断を失うか→高い、③長くて難しく大事な作業を任せて席を外すか→超高か最大、④それ以外→中（Opus 5.5 の初めの設定）。超高と最大を使う条件も含めて、この4つは広川さんのまとめで、原典の文ではありません。

広川さん（動画の中で・11:15〜）

1番覚えて欲しいのは、エフォートは質を決めるつまみではないということです。かける時間と、自分がどれだけ関わりたいかを決めるつまみです。

エフォートは仕上がりの良し悪しより、かける時間と関わり方を決めるもの、という言い切り。原典との合い方は、次の章の話。

私なら、最大にするのは、その仕事の持ち主をAI1人に決めて、口を出さない時だけです。口を出したいなら、最大にはしません。最大は、任せきる時の段。

私なら、いちばん上の段で安心を買うより、質問で段を決めて、積み減らす方を選びます。

迷ったら中から始めて、結果を見て上げ下げする。この順番なら、上げた分の待ち時間を、上げる理由がある所だけで払えます。

いま一番高い段で回している仕事は、本当に席を外して任せられているでしょうか？持ち主は1人です！

ここでは、動画の言葉と原典の文を、一致する所も食い違いも含めて並べます。動画の題は「Anthropicが明かした」で始まりますが、元は Thariq さんの記事と公式 Docs です。動画が「Anthropic の試し」と呼ぶ所は Thariq さん個人の記事で、副題は「my own tests」。

広川さん（動画の中で・3:36〜）

Anthropicの試しでは、同じ簡単なデザインの直しが、低いでは1分、最大では28分かかり、仕上がりはほとんど同じでした。

動画は、低いで1分、最大で28分、仕上がりはほとんど同じと話します（3:36）。原典の題材は /config メニューの作り直しで、低いは1分の対話式スケッチ、最大は28分の Claude Code によく似たモックアップと、時間は一致し、仕上がりは食い違います。

動画の「ほとんど同じ」に近いのは、原典の別の課題。仕様を細かく渡したほうで、低いが16分、最大が79分、仕上がりが似ていました。

広川さんは、エフォートは仕上がりの良し悪しではなく、かける時間と関わり方を決めるものだ、と言い切ります。原典では、簡単な作業なら質はほぼ変わらずこの言い切りと合いますが、難しい作業では段を上げると合格が増える例があり、「質はほぼ変わらない」は簡単な作業での話。Opus 5.5 の Terminal-Bench 3.0 で5回やって合格した数は、クラッシュ報告から保存エンジンのバグを直す課題が低いで0/5・超高で4/5、Python で CLI の線形計画ソルバーを書く課題が低いで0/5・高いで5/5です。

リディアさんの発言は、動画にあって原典に無い文。公式 Docs の Opus 4.7 の項は、深い推論が要る問題で浅い推論が出たらエフォートを上げる、と書いていて、向きが逆です。

動画の「最大は質があまり上がらない」は、公式 Docs の Fable 5.2 と Opus 4.7 の項の文で、Opus 5.5 の項とは別。Thariq さんの記事の Fable 5.1 は、各段370試行のうち、低いは140件、最大は214件が合格です。

4つの質問と、超高・最大を使う条件は、原典に無い動画側のまとめ。低いで回して最後に高いに上げる順番も、原典ではこの前に Claude に質問させて抜けを聞き出す工程が1つ付き、動画はそれを3段にまとめた形。

動画の言葉を事実として写す前に、原典を読んで確かめます。段ごとの差を私の作業で比べた記録は、手元にありません。だから、この章の数字は原典の文のまま。

違う所は、どちらが正しいかを決めるより、動画の言葉と原典の文を並べて、自分で読める形にしておきたいんです。解説は入口。

次に誰かの解説を読む時、元の記事はどこにあるでしょうか？

広川さんの話の芯は、エフォートは賢さではなく、かける手間と、自分がどれだけ関わりたいかを決めるつまみだ、ということ。5段は、その関わり方の目盛りなんです。

段の名前より先に、この作業への私の関わり方を置く。いちばん伝えたいのは、ここです。

まずは、いま使っている段を、画面の表示か設定ファイルで1か所だけ確かめてみてください。何も書いていなければ、既定のまま動いています。毎日頼む作業の中で、いちばん口を出したくないのは、どれでしょうか？

本編の動画も、ぜひ観てみてください。11分58秒の中には、この記事で拾いきれなかったスライドの図と、広川さんの話しぶりが入っています。第5章を手元に置いて観ると、どこが広川さんのまとめで、どこが原典の文かが見えてくるはず。