はじめに
2026年4月16日に Claude Opus 4.7 が一般提供されました。新しい思考レベル xhigh が追加されたのが大きな変更点の一つです。位置づけとしては既存の high と max の中間で、「max ほどのコストはかけたくないが high では物足りない」という帯域を埋める選択肢として用意されています。
Claude Code では、Opus 4.7 を初回に呼び出すと xhigh が自動で適用される挙動も確認されています。つまり普段の対話で黙って使っている方も少なくないはずです。
この記事では、同一のタスクを 5 つの effort レベル（low / medium / high / xhigh / max）で走らせて、筆者の環境でどのような傾向が出たかを整理します。
検証の目的と限界
最初にお断りしておきます。本記事は厳密なベンチマークではなく、あくまで筆者が日常タスクで体感した傾向を共有する「体感検証」の位置づけです。
- N=1 に近い小規模検証で、統計的な有意差を主張するものではありません
- 数値は筆者の環境・プロンプト・対象コードでの参考値です
- 同じタスクでも run ごとに揺らぎがあるため、同条件で再実行すると違う結果になり得ます
公式の SWE-bench Pro などのスコアは Anthropic や第三者のベンチに任せるとして、この記事は「自分のプロジェクトで切り替えたときに何がどう変わるか」をイメージしてもらうための叩き台として読んでいただければと思います。
実験設定
タスク 3 種
意図的に性格の違う 3 つのタスクを用意しました。
| # | タスク | 内容 | 想定難度 |
|---|---|---|---|
| A | バグ修正 | Next.js アプリでフォーム送信時に undefined が混入する問題の原因特定と修正 |
中（原因がやや分かりにくい） |
| B | 新規機能 | 既存の Express API に JWT リフレッシュトークンのエンドポイントを追加 | 中〜高 |
| C | リファクタ | 600 行の React コンポーネントをフック分離と関心の分離で再設計 | 高（影響範囲が広い） |
effort レベル 5 段階
| レベル | 位置づけ |
|---|---|
low |
最小限の思考。即応性重視 |
medium |
3 月の騒動後にデフォルトになった中庸 |
high |
従来の「しっかり考える」帯域 |
xhigh |
4.7 で新設。high と max の中間 |
max |
最上位。思考予算を上限まで使う |
5 レベル × 3 タスク = 15 run を手動で走らせました。
計測項目
- 成功率（手動で動作確認し、仕様を満たすかで判定）
- 所要時間（プロンプト送信から最終回答まで）
- 入出力トークン（Claude Code の使用状況から集計）
- 思考トークン（内部の reasoning 分）
- コスト（Opus 4.7 の $5 / $25 per 1M を機械的に適用）
実行環境
- Claude Code v2.1.101（4 月系の最新版）
- Anthropic Opus 4.7（料金: 入力 $5 / 出力 $25 per 1M tokens）
- 検証は 2026-04-16〜17 の 2 日間で実施
- Opus 4.7 は adaptive reasoning が常時有効で、
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGは no effect とされています（旧 4.6 で同等検証をしたい場合のみ有効） -
CLAUDE_CODE_EFFORT_LEVELを明示指定して切り替え
effort 周りの挙動が 3 月に揺れた経緯があるので、今回は CLAUDE_CODE_EFFORT_LEVEL を固定値にして走らせる前提にしています（Opus 4.7 では adaptive reasoning が常時効くため完全に排除はできません）。
なお、本記事の effort 5 段階（low / medium / high / xhigh / max）は Opus 4.7 限定のレベル分けです。Opus 4.6 には xhigh は用意されていないため、以降のレベル間比較はあくまで 4.7 内での話としてお読みください。
結果テーブル
繰り返しになりますが、以下の数値は N=1 規模の筆者環境での参考値 であり、他の環境で同じ値が出ることを保証するものではありません。各タスクとも 1 run ずつしか走らせていないため、run 間のばらつきは反映されていません。「このような傾向が見られました」という位置づけでご覧ください。
タスク A: バグ修正
| effort | 成功 | 所要時間 | 入力トークン | 出力トークン | 思考トークン | 概算コスト |
|---|---|---|---|---|---|---|
| low | × | 約 22 秒 | 8.2K | 1.1K | 0.4K | $0.07 |
| medium | △ | 約 41 秒 | 9.5K | 2.4K | 1.9K | $0.11 |
| high | ○ | 約 1 分 20 秒 | 11.8K | 3.6K | 5.2K | $0.15 |
| xhigh | ○ | 約 2 分 05 秒 | 13.2K | 4.1K | 9.8K | $0.17 |
| max | ○ | 約 3 分 30 秒 | 14.0K | 4.8K | 16.5K | $0.19 |
low は原因の切り分けが浅く、症状を抑えるだけの対症療法的な修正にとどまりました。medium は一応動くものの根本原因には踏み込めず、high 以上で「状態管理の初期値が undefined になる条件」を突き止められた、という傾向が出ました。
タスク B: 新規機能
| effort | 成功 | 所要時間 | 入力トークン | 出力トークン | 思考トークン | 概算コスト |
|---|---|---|---|---|---|---|
| low | × | 約 45 秒 | 12.1K | 2.8K | 0.6K | $0.13 |
| medium | ○ | 約 1 分 30 秒 | 14.5K | 4.9K | 3.1K | $0.19 |
| high | ○ | 約 2 分 40 秒 | 16.2K | 6.3K | 8.4K | $0.24 |
| xhigh | ○ | 約 3 分 20 秒 | 17.8K | 7.1K | 14.2K | $0.27 |
| max | ○ | 約 5 分 10 秒 | 18.5K | 7.9K | 22.1K | $0.29 |
新規機能は仕様が明確だったため、medium でも一通り動くコードが出てきました。high 以上になると「既存のミドルウェアとの整合性」「トークン失効時のフォールバック」まで踏み込んだ設計が返ってきた印象です。max は丁寧な反面、提案が冗長になる傾向も見られました。
タスク C: リファクタ
| effort | 成功 | 所要時間 | 入力トークン | 出力トークン | 思考トークン | 概算コスト |
|---|---|---|---|---|---|---|
| low | × | 約 1 分 10 秒 | 22.4K | 4.2K | 0.9K | $0.22 |
| medium | × | 約 2 分 50 秒 | 25.1K | 8.6K | 5.4K | $0.34 |
| high | △ | 約 5 分 00 秒 | 28.3K | 11.2K | 14.1K | $0.42 |
| xhigh | ○ | 約 7 分 40 秒 | 30.5K | 13.5K | 24.8K | $0.49 |
| max | ○ | 約 12 分 30 秒 | 32.2K | 15.1K | 41.3K | $0.54 |
タスク C は筆者の環境で一番差がついたケースでした。low / medium は表層的な分割にとどまり、コンポーネントの責務境界を読み違えました。high も一部は意図通りでしたが、状態の持ち方を誤って props drilling を悪化させた箇所がありました。xhigh 以上でようやく「どのロジックをフックに切り出すか」の判断が筋よく出る、という印象です。
考察
xhigh の位置づけ
筆者の環境では、xhigh は「high では足りないが max は重すぎる」という感覚にそれなりに合致する挙動を見せました。特にタスク C（リファクタ）では、xhigh と max の成果物の質はほぼ互角で、xhigh のほうが所要時間が 4 割ほど短く、思考トークンも 4 割ほど少なく済みました。
一方、タスク A（バグ修正）では high と xhigh で最終成果物にほぼ差が出ず、思考トークンは 2 倍近くに膨らみました。「原因がそこそこ複雑でも、推論が必要な範囲が狭いタスク」では high で十分ということかもしれません。
あくまで 3 タスクだけの結果なので断定はできませんが、設計判断の分岐が多い作業では xhigh のコスト対効果が悪くない、というのがこの検証から得られた仮説です。
1M context × xhigh の使い所
Opus 4.7 では 1M トークンコンテキストが標準 API 価格で提供されるため、大量の既存コードを読み込ませた上で設計判断を任せる使い方が現実的になりました。
筆者の感覚としては、以下の組み合わせが噛み合いそうです。
- 1M context × xhigh … 既存コードベース全体を読ませて設計変更を検討させる場面
- 標準 context × high … 1 ファイル〜数ファイルのバグ修正・小機能追加
- 1M context × max … 大規模なアーキテクチャ変更を 1 発で通したい、かつ時間が許す場面
ただし 1M context をフルに使うと入力トークンだけで簡単に数百円クラスのコストになるので、「入れられるから入れる」ではなく「どの範囲を読ませたいか」を設計する前提は維持したいところです。
Routines + Opus 4.7 xhigh でのバッチ運用
4 月に追加された Routines（スケジュール/API/GitHub トリガーで無人実行する機能）と Opus 4.7 × xhigh を組み合わせると、「夜間に時間のかかるタスクをまとめて走らせ、朝にレビューだけする」運用が現実味を帯びてきます。
筆者の環境でも、週次レポート系のタスクを xhigh でバッチ化する実験を始めていますが、max だと 1 タスクあたり 10 分前後かかっていたものが xhigh だと 6〜7 分で終わり、品質も大きくは変わらない、という感触です。これも N=1 の参考値ですが、長時間エージェント運用での effort 選択は今後試行錯誤する価値がありそうです。
タスク複雑度と effort の対応関係（筆者なりの目安）
筆者の肌感での対応表です。絶対的な指針ではなく、判断に迷ったときの叩き台として使ってください。
| タスク複雑度 | 目安 | 推奨 effort |
|---|---|---|
| 単純（コピペ改変、誤字修正、型追加） | 5 分以内で書ける | low |
| 軽微（小バグ修正、短いスクリプト追加） | 30 分以内で書ける | medium |
| 中程度（機能追加、中規模バグ、部分リファクタ） | 半日規模 | high |
| 高（設計判断を含むリファクタ、複数箇所の整合性） | 1〜2 日規模 | xhigh |
| 非常に高い（アーキテクチャ変更、クリティカルな判断） | 数日以上 | max |
推奨プロファイル
タスク種別ごとの筆者なりの指針をまとめます。
デイリー作業（コスト重視）
- 既定値:
medium - 典型: 誤字修正、Lint 対応、短いユーティリティ追加
- 注意:
mediumは 3 月騒動の震源地でもあるため、重要な判断を任せないほうが無難
実装メイン（バランス型）
- 既定値:
high - 典型: 中規模バグ修正、API エンドポイント追加、テスト追加
- 備考: 筆者の環境では「迷ったら high」がデフォルト
設計判断を含む作業（品質重視）
- 既定値:
xhigh - 典型: コンポーネント分割、スキーマ設計、テスト戦略立案
- 備考:
maxと比べてコスト・時間が抑えめで、質の差が小さいケースが多い
クリティカルな判断（最上位）
- 既定値:
max - 典型: アーキテクチャ変更、セキュリティ設計、本番事故対応
- 備考: 時間とコストを受容できる場面限定
Routines でのバッチ運用
- 既定値:
low/medium（公式ガイダンスではコスト重視の帯域が推奨） - 典型: 夜間の定期レポート、大量ファイルの一括処理
- 備考: 公式は Routines を「低コストで回す」文脈で案内しているため、筆者もまずは
medium中心で回し、品質が足りないタスクだけxhighに上げる運用に切り替えつつあります。maxは時間がかかりすぎて Routines の実行枠を圧迫しやすい点に注意
注意点
ベンチマークと実務の乖離
SWE-bench Pro 等の公開スコアは参考情報として有用ですが、自分のプロジェクトでその通りに再現するわけではありません。テストケースの傾向、コードベースの癖、プロンプトの書き方で結果は大きくブレます。公式の数値は「このモデルはこのくらいのポテンシャルがある」という上限の目安として捉えるのが健全だと思います。
Adaptive Thinking の扱い
2026 年 2〜3 月にかけて、adaptive thinking が一部のターンで推論トークンをほぼ使わない挙動になっていた、というのは筆者の観測範囲での印象で、公式 release notes/changelog で一次ソースを突き止められたわけではありません。鵜呑みにはしないでください。
なお Opus 4.7 では adaptive reasoning が常時有効で、CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は no effect とされています。旧 4.6 で同等検証をする場合のみ、このフラグが意味を持ちます。
研究プレビュー「Mythos」の扱い
Anthropic は 2026-04-07 に、Project Glasswing 参加企業向けの gated research preview として Mythos を公表しています。つまり「社内未公開」ではなく、限定配布の research preview です。ただし一般には未提供のため、この記事では Mythos の話は参考程度にとどめ、評価は Opus 4.7 × effort の実運用に絞っています。一般提供が始まったら改めて比較する予定です。
xhigh 常時 ON のアンチパターン
「新機能だから」と xhigh を常時 ON にすると、軽微なタスクでもコストが膨らみます。筆者も最初はつい常時 ON にしがちでしたが、1 日使ってみたら low / medium で十分なタスクまで xhigh で処理していて、無駄が多かったです。タスクの性格に合わせて切り替えるのが結局コスト対効果が高いと感じています。
まとめ
- Opus 4.7 で新設された
xhighは、highとmaxの中間という説明通りの立ち位置 - 筆者の環境では、設計判断を含むタスクで
xhighのコスト対効果が相対的に良好 - バグ修正や小機能追加は従来通り
highで十分なケースが多い -
maxは確実性を取りに行く場面の選択肢として、これまで通り有効 - 1M context ×
xhighや Routines ×xhighは今後試行錯誤する価値がある組み合わせ
数値はすべて N=1 規模の参考値です。自分のプロジェクトで同様の 15 run を走らせてみると、おそらく違った傾向が見えてくるはずで、その結果を共有してもらえると嬉しいです。effort の選択は「万能な正解」ではなく「自分のタスクに合う落としどころ」を探す作業だと、今回の検証を通じて改めて感じました。
参考: