効果レベル（effort）を実測する：xhighは4.4倍考えて、短い答えを返した
Claude Codeのeffortレベルを実際に測りました。同じ質問をlowとxhighで投げたところ、xhighは4.4倍のトークンを消費しながら、lowより短い回答を返しました。測定データと、そこから導いた使い分けの基準を書きます。
Claude Codeには、思考の深さを調整する effort（効果レベル） という設定があります。
「複雑なタスクには高いレベル、簡単なタスクには低いレベル」——そう説明されますし、私もそう理解していました。ただ、具体的に何がどれだけ変わるのかを測ったことがありませんでした。
測りました。結果が予想と違ったので、そこから書きます。
結論：実測データ
同じプロンプトを low と xhigh で投げ、所要時間・出力トークン・ターン数を記録しました。
| タスク | effort | 実時間 | API時間 | 出力トークン | ターン数 | 回答の文字数 |
|---|---|---|---|---|---|---|
| 単純な説明 | low |
17秒 | 6.6秒 | 216 | 2 | 172字 |
| 単純な説明 | xhigh |
18秒 | 6.5秒 | 230 | 2 | 185字 |
| 設計の判断 | low |
69秒 | 52.0秒 | 2,675 | 5 | 1,639字 |
| 設計の判断 | xhigh |
308秒 | 205.8秒 | 11,803 | 18 | 1,569字 |
3つ、読み取れることがあります。
- 単純なタスクでは、レベルを上げてもほぼ何も変わりません（17秒 → 18秒）
- 判断を伴うタスクでは、4.5倍の時間がかかります（69秒 → 308秒）
- xhighは4.4倍のトークンを使いながら、lowより短い答えを返しました（11,803トークン → 1,569字）
3番目が一番重要です。順に説明します。
effortとは何か
まず公式の定義です。
Effort levels control adaptive reasoning, which lets the model decide whether and how much to think on each step based on task complexity. Lower effort is faster and cheaper for straightforward tasks, while higher effort provides deeper reasoning for complex problems.
「モデルが各ステップで、タスクの複雑さに応じて、考えるかどうかとどれだけ考えるかを決める」仕組みです。固定の思考予算を与えるのではなく、モデル側が判断します。
使えるレベルはモデルによって異なります。
| モデル | 使えるレベル |
|---|---|
| Opus 5 / Sonnet 5 / Opus 4.8 / Opus 4.7 / Fable 5 | low medium high xhigh max |
| Opus 4.6 / Sonnet 4.6 | low medium high max |
既定は high です（Opus 4.7のみ xhigh）。対応していないレベルを指定した場合は、その下で一番高いレベルに落ちます。たとえば Opus 4.6 に xhigh を指定すると high として動きます。
測り方
再現できるように書いておきます。--output-format json を付けると、所要時間とトークン数がJSONで返ってきます。
claude -p "<プロンプト>" --effort low --output-format json返ってくるJSONの主要な項目です。
{
"duration_api_ms": 6569,
"num_turns": 2,
"total_cost_usd": 0.1219,
"usage": {
"output_tokens": 216,
"cache_read_input_tokens": 26541,
"cache_creation_input_tokens": 27571
},
"result": "..."
}投げた2つのプロンプトです。同じファイルを対象にして、質問の性質だけを変えました。
【単純な説明】
src/lib/cluster.ts を読んで、getRelated 関数が何をしているか2行で説明してください。
【設計の判断】
src/lib/cluster.ts を読んで、この設計の弱点を挙げ、
記事が200本に増えたときに何が問題になるか、根拠つきで指摘してください。環境は Claude Opus 5、対象は実際に運用しているサイトのソースです。
結果1：単純なタスクでは差が出ません
まず単純な説明タスクです。
| effort | 実時間 | 出力トークン | ターン数 |
|---|---|---|---|
low |
17秒 | 216 | 2 |
xhigh |
18秒 | 230 | 2 |
ほぼ同じです。 時間差は1秒、トークン差は14です。誤差の範囲と言っていいでしょう。
これは公式の説明どおりの挙動です。effortは「必ずこれだけ考えろ」という指示ではなく、「どれだけ考えてよいか」の上限に近いものです。簡単だと判断すれば、xhigh でも深く考えません。
つまり、今回試した単純なタスクでは「念のため高くしておく」ことによる実害を観測しませんでした。コストもほとんど変わりませんでした。問題は次です。
結果2：判断タスクでは4.5倍の時間
設計の弱点を指摘させるタスクです。
| effort | 実時間 | API時間 | 出力トークン | ターン数 |
|---|---|---|---|---|
low |
69秒 | 52.0秒 | 2,675 | 5 |
xhigh |
308秒 | 205.8秒 | 11,803 | 18 |
5分かかりました。 対話しながら使うと、これは長く感じます。
注目すべきはターン数です。5ターンから18ターンに増えています。ターンが増えるということは、ツールを呼んだ回数が増えているということです。ファイルを読み、周辺を確認し、また読む。xhigh は自分で確かめに行きます。
low は5ターンで答えを出しました。つまり、ほぼ読んだものだけで判断しています。
結果3：4.4倍考えて、短い答えを返しました
ここが一番意外でした。
| effort | 出力トークン | 回答の文字数 |
|---|---|---|
low |
2,675 | 1,639字 |
xhigh |
11,803 | 1,569字 |
トークンは4.4倍なのに、回答は短くなっています。
差の9,128トークンはどこへ行ったのか。ターン数が2から18へ増えていることから、思考とツール呼び出しに使われたと推測できます（内訳を分解して測ってはいません）。少なくとも出力には現れていません。
これが意味するのは、effortを上げても「回答が丁寧になる」わけではないということです。上がるのは、答えを出す前に確かめる回数です。
私は正直、xhigh にすれば「より詳しく書いてくれる」と思っていました。逆でした。 よく調べたぶん、余計なことを書かずに絞って返してきます。
中身も見比べました
両方の回答を読み比べると、指摘の質が違いました。
lowの指摘 — コードを読めば分かる範囲の一般論が中心xhighの指摘 — 実際に周辺ファイルを確認したうえでの、この設計固有の問題
短いのに、密度が高い。文字数は品質の指標になりません。
何に使い分けるか
実測から導いた基準です。従来「タスクの複雑さで決める」と説明されますが、測ってみるともう少し具体的に言えます。
| 判断軸 | 低いレベルでよい | 高いレベルにする |
|---|---|---|
| 答えが1箇所を見れば決まるか | 決まる | 複数を突き合わせる必要がある |
| 間違えたときのコスト | すぐ気づいて直せる | 気づかず先へ進んでしまう |
| 待てる時間 | 対話中で待てない | 席を外せる |
言い換えると、**effortを上げるのは「自分で確かめに行ってほしいとき」**です。
具体的には次のようになります。
低めでよいもの
- タイポ修正、変数名のリネーム
- 既存パターンの横展開
- 「このファイルは何をしているか」という説明
- ドキュメントの文章修正
高めにするもの
- アーキテクチャに影響する設計判断
- 複数ファイルにまたがるリファクタリング
- 原因が分かっていないバグの調査
- 「この方針で問題ないか」というレビュー
段階的に上げるもの
バグ調査は二段構えが効きます。まず低いレベルで当たりをつけ、怪しい箇所が2〜3箇所に絞れてから上げます。最初から xhigh で全体を精査させると、今回の実測どおり5分待つことになります。
設定する
いくつか方法があります。
# 起動時に指定する（そのセッションだけ）
claude --effort xhigh
# セッション中に変える
/effort # スライダーが出る
/effort medium # 直接指定
/effort auto # モデルの既定へ戻す設定ファイルに書けば既定にできます。
{
"effortLevel": "high"
}max と ultracode は設定ファイルに書けません（セッション限定のため）。環境変数 CLAUDE_CODE_EFFORT_LEVEL は他のすべてより優先されます。
スキルやサブエージェントのfrontmatterに effort を書くと、それが動いている間だけ上書きできます。軽い調査はサブエージェントに low で回し、本体は high のまま、という使い分けができます。
ひとつのターンだけ深く考えさせる
セッションの設定を変えずに、その1回だけ深く考えてほしいときは ultrathink という語をプロンプトのどこかに入れます。
Include
ultrathinkanywhere in your prompt to request deeper reasoning on that turn without changing your session effort setting. Claude Code recognizes the keyword and adds an in-context instruction. The effort level sent to the API is unchanged. Other phrases such as “think”, “think hard”, and “think more” are passed through as ordinary prompt text and are not recognized as keywords.（出典: Model configuration）
注意点が2つあります。
- APIに送るeffortレベルは変わりません。 プロンプトに指示が足されるだけです
thinkthink hardthink moreはキーワードとして認識されません。 ただの文章として渡ります
「think hard と書けば深く考える」という話をよく見かけますが、Claude Codeが認識するのは ultrathink だけです。
測定の限界
正直に書いておきます。
- 各条件1回ずつしか測っていません。 ばらつきは検証していません
- コストはキャッシュの状態に左右されます。 表に載せた時間とトークン数のほうが信頼できます
- モデルは Opus 5 です。 effortの尺度はモデルごとに較正されているため、同じレベル名でも別のモデルでは同じ値を意味しません（これは公式に明記されています）
- タスクは2種類だけです
それでも、**「単純タスクでは差が出ない」「判断タスクでは4倍以上違う」「トークンが増えても出力は長くならない」**という3点は、傾向として再現しそうだと考えています。ただしこれは2タスク・各1回からの仮説であり、検証済みの一般則ではありません。
まとめ
effortは「出力の丁寧さ」を上げる設定ではありませんでした。上がるのは答えを出す前に確かめる回数です。
実測すると、こうなります。
- 単純なタスクでは、上げてもほぼ何も変わらない（17秒 → 18秒）
- 判断タスクでは、4.5倍の時間と4.4倍のトークンを使う
- それでも回答は短くなる。 増えたぶんは思考と調査に消える
だから使い分けの基準は「複雑さ」ではなく、**「自分で確かめに行ってほしいか」**です。1箇所を見れば決まる質問に高いレベルを与えても、待ち時間が増えただけでした（今回試した範囲では）。
Claude Codeの導入と基本設定は個人開発者のためのClaude Code完全ガイドにまとめています。
この記事の実測環境
| 項目 | 内容 |
|---|---|
| モデル | Claude Opus 5 |
| 測定日 | 2026-08-03 |
| 測定方法 | claude -p "<prompt>" --effort <level> --output-format json |
| 対象 | 実運用中のAstroサイトのソース（src/lib/cluster.ts） |
| 試行回数 | 各条件1回 |