Claudeが「遅い・雑・高い」になった原因を切り分ける — effort・モデル・コンテキスト長の3層ガイド
「最近のClaude、なんか雑じゃない？」
2026年4月に入ってから、この声がX・Reddit・開発者コミュニティで急増しました。
Fortune誌は4月14日にヘビーユーザーの不満を報じ、Redditでは「Opus 4.7 is not an upgrade but a serious regression」という投稿に2,300以上のUpvoteが集まっています。
私自身、最近のClaudeを触っていて「いつも丁寧にやってくれていた作業を端折っている」と感じる場面が増えました。
ただ、よく調べてみるとこの問題は1つの原因ではなく、3つの別々の問題が同時に起きているというのが実態です。
それぞれに対処法が違うので、まず原因を切り分けることが先決です。
この記事ではその3層を整理して、タスクに応じた最適な設定まで落とし込みます。
3つの層で切り分ける
「遅い・雑・高い」と感じる原因は、だいたいこの3つのどれかに該当します。
層1: effort設定が下がっている — 思考の深さ自体が浅くなっている
層2: モデルが知らない間に変わっている — Opus 4.7への自動切替で体感が変わった
層3: コンテキストが長すぎる — 1Mを使っているが中盤の情報が抜け落ちている
順番に見ていきます。
層1: effort設定 — 3月に「思考の深さ」がこっそり下がっていた
何が起きたのか
時系列で整理するとこうなります。
3月3日: AnthropicがClaude Opus 4.6のデフォルトeffortを high → medium に変更
4月7日: ユーザーの不満を受け、API/Bedrock/Vertex/Foundry/Team/Enterpriseで medium → high に戻した
4月16日: Opus 4.7リリースと同時に、default effortが xhigh に設定された（全プラン）
3月の変更理由はシンプルで、「Claudeがトークンを使いすぎる」というフィードバックに応えたものでした。
つまりAnthropicは、速度・コストを優先して「思考の深さ」をデフォルトで下げていたわけです。
問題は、この変更がアナウンスされずに入った点です。
ユーザーからすれば「急に雑になった」と感じるのは当然で、この1ヶ月の不満のかなりの部分はここから来ています。
5段階のeffort levelと実測値
現在のClaude Codeには5段階のeffortがあります。
Opus 4.7でのベンチマーク実測値と合わせて見るとこうなります。
low — 速度重視。チャット・単純な質問向け
medium — コスト・速度・性能のバランス型（3月のデフォルト）
high — 高い知能が必要なタスク向け（4月のデフォルト）
xhigh — 複雑なエージェント作業向け。Opus 4.7で約71%の性能、約100kトークン消費
max — 最高性能。約74.5%の性能、200k+トークン消費
ここで注目すべきは、xhigh → max の性能差はわずか3%なのに、トークン消費はほぼ倍という点です。
「max使っておけば間違いない」は間違いで、ほとんどのタスクではxhighで十分です。
low → max だと最大10倍以上のトークン差が出るので、「常にmaxにする」運用はMaxプランの枠を一瞬で溶かします。
今すぐ直す3つの方法
Claude Codeで試せる方法は3つあります。
1. `/effort` でスライダーを開く
/effort引数なしで実行すると、左右の矢印キーでレベルを選べるインタラクティブなスライダーが開きます。
Enterで確定。
2. レベル名で直接指定する
/effort high
/effort xhigh
/effort maxこれが一番速い。
設定はセッションをまたいで保持されます（maxだけは現行セッションのみ）。
3. `/effort auto` でモデルデフォルトに戻す
/effort auto「いじり過ぎてわからなくなった」時のリセット用。
永続化したい場合
毎回設定するのが面倒なら、2つの方法があります。
`~/.claude/settings.json` に書く方法。
{
"effortLevel": "xhigh"
}あるいは環境変数で指定する方法。
# bash / zsh
export CLAUDE_CODE_EFFORT_LEVEL=xhigh# PowerShell
$env:CLAUDE_CODE_EFFORT_LEVEL = "xhigh"優先順位は、環境変数 → settings.json → モデルデフォルトの順です。
環境変数が最強なので、CIなどタスクごとに切り替えたい場面ではこちらが便利です。
注意点として、max effortはsettings.jsonで永続化できない不具合が現時点で残っています（GitHub Issue #33937）。
maxを永続化したい場合は環境変数を使ってください。
層2: モデル選択 — Opus 4.7に知らない間に変わっているかも
プランによって体験が違う
Opus 4.7は4月16日にリリースされましたが、デフォルトモデルになるタイミングはプランごとに違います。
Max / Team Premium: 4月16日から即座にOpus 4.7がデフォルト
Pro / API / Enterprise pay-as-you-go: 4月23日までSonnet 4.6がデフォルト
つまり、Max/Team Premiumユーザーは知らない間にOpus 4.7に切り替わっていて、「挙動が変わった」と感じているケースが多いわけです。
Opus 4.7の強みと弱み
強み:
SWE-bench Verified: 80.8% → 87.6%（約7ポイント改善）
SWE-bench Pro: 53.4% → 64.3%（GPT-5.4の57.7%、Gemini 3.1 Proの54.2%を上回る）
画像解像度がOpus 4.6の3倍以上
adaptive thinking（質問の難易度に応じて考える時間を自動調整する機能）の強化
弱み:
新tokenizerで同じテキストでも1.0〜1.35倍のトークン消費（最大35%増）
長文コンテキストで "lost in the middle"問題が悪化（中盤の情報を見落とす）
adaptive reasoningが時々「浅い思考」になる不具合
リリース直後にSNSで「Legendarily bad」と言われる事例複数（strawberryの「p」を2つと答える、履歴書の学校名を勝手に書き換える等）
要するに、コーディングベンチマーク上は確実に進化している一方で、それ以外のタスクではOpus 4.6より劣化しているケースがあるということです。
SNSで反発の声が集中しているのはこのギャップが理由で、「コード書かせる分には強いが、日常会話や長文処理では逆にひどくなった」という体感に繋がっています。
Opus vs Sonnet の実力差
私自身、「作り物はOpus、簡単な質問はSonnet」という使い分けをしていますが、これはベンチマーク的にも裏付けがあります。
コーディング総合スコア: Opus 4.7 = 72.9 / Sonnet 4.6 = 66.4
BenchLM総合: Opus 4.7 = 97 / Sonnet 4.6 = 85
価格: Opus $5/$25 per M tokens（約750円/3,750円） vs Sonnet $3/$15（約450円/2,250円）
コーディングで10点近い差があるので、「Sonnetで作ったコードが中途半端に感じる」のは気のせいではありません。
一方、価格差は約1.7倍。
作り物をOpus、質問や軽い作業をSonnetに振り分けるのは、費用対効果としても合理的です。
使い分け基準
ざっくりこういう振り分けが実用的です。
Opus 4.7 を使う場面: 新規コードの生成、複雑なリファクタリング、設計判断、複数ファイルを横断する作業、AIが自律的にツールを呼び出しながら進めるタスク（Agentic Loop）
Sonnet 4.6 を使う場面: チャット的な質問、単発のコード修正、文書の要約、コードレビューの初期チェック、軽いdebug
Opus 4.6（まだ使える場合）を使う場面: 長文ドキュメントの処理（4.7の"lost in middle"を回避）
Claude Codeでモデルを切り替えるには `/model` コマンドを使います。
層3: コンテキスト長 — 1Mの罠
1Mは「使える」けど「賢くなる」わけではない
Opus 4.7は1M（100万）トークンのコンテキストに対応しています。
これだけ聞くと「大きなコードベースを全部食わせれば賢く判断してくれる」と思いがちですが、実態は違います。
GitHub Issue #34685 で報告されている通り、Claude Opus 4.6でも40%地点から自己申告で性能劣化が始まり、48%地点で再セッション開始を推奨するような挙動が出ます。
Opus 4.7ではこの"lost in the middle"問題がむしろ悪化しています。
具体的に何が起きるかというと。
長いコードベースで中盤にあるファイルの詳細を誤認する
長い会話の最初に指示したルールを後半で忘れる
長文ドキュメントのQ&Aで、中盤の情報を根拠にした質問に答えられない
1Mは「長くできる」であって、「長くしても同じ精度が出る」ではない、ということです。
コンテキスト節約術
実用的には、コンテキストが40%を超えたらセッションを切る判断をした方が結果がよくなります。
Claude Codeで使えるテクニック。
`/compact` で会話を圧縮する。これまでの会話をClaude自身が要約して、新しいコンテキストにまとめ直してくれる。要点は残したまま使用量を削減できる
`/clear` で完全にリセットする。会話履歴を全部消して新しいセッションで始める。タスクが切り替わるときに使う
CLAUDE.md に前提を書いて短く始める。毎回同じ説明をしないで済む
大きなファイルを全文貼るのではなく、関連する関数だけ抜粋する
「1Mあるから大丈夫」ではなく、「200k程度で収める方が結果的に速くて正確」と考えた方がいいでしょう。
タスク別の実戦ガイド
ここまでの3層を組み合わせると、タスクごとに最適な設定が見えてきます。
パターンA: 新機能の実装・複雑なコード生成（重視: 品質）
モデル: Opus 4.7
effort: xhigh（maxまで上げても3%しか変わらない）
コンテキスト: 関連ファイルのみを渡す（200k以内目安）
一言: 作り物の本命設定。トークン消費は覚悟する
パターンB: 軽い質問・既存コードの意味を聞く（重視: 速度とコスト）
モデル: Sonnet 4.6
effort: medium
コンテキスト: 該当箇所のみ
一言: Maxプランの枠を温存する日常運用。Opusを呼ぶほどではない質問はここ
パターンC: 長文ドキュメントの要約・分析（重視: 長文処理の安定性）
モデル: Sonnet 4.6（Opus 4.7の"lost in middle"を避ける）
effort: high
コンテキスト: できれば章ごとに分割して渡す
一言: 1Mに頼らない。長文こそ分割して処理
パターンD: 複雑なリファクタ・設計変更（重視: 深い推論）
モデル: Opus 4.7
effort: max（ここは例外的にmaxの価値あり）
コンテキスト: 変更対象と周辺依存のみ
一言: 設計判断はケチらない。maxのトークン消費も許容する場面
「遅い・雑」を感じたときの診断チェックリスト
実際に違和感を感じたら、この順で確認すると原因が特定しやすいです。
[ ] `/effort` で現在のレベルを確認したか（mediumになっていないか）
[ ] `/model` で現在のモデルを確認したか（知らない間にOpus 4.7に変わっていないか）
[ ] コンテキスト使用量が40%を超えていないか
[ ] CLAUDE.mdに前提を書いているか（毎回説明していないか）
[ ] Max/Team Premiumユーザーの場合、Opus 4.7特有の挙動（"laziness"、adaptive reasoningの不具合）に該当していないか
1つずつ潰していけば、だいたいどれかに引っかかります。
まとめ
今回の「Claudeが遅い・雑・高い」問題を整理すると、こうなります。
4月の不満の多くは effort default変更（3月→4月の流れ） と Opus 4.7への自動切替 の複合要因
effort は xhigh で多くのタスクはOK。max は性能3%のために倍のトークンを払う行為
モデルは Opus 4.7は作り物に強く、Sonnet 4.6は日常運用に強い。使い分けが正解
1Mコンテキストは**「長くできる」のであって「長くしても賢い」ではない**。40%を超えたら切る判断を
ヘビーユーザーほど、自分のタスクに合わせて3層を調整する意識が効いてきます。
「なんとなくmax・Opus・1Mを盛っておく」が一番トークンを無駄にする運用なので、そこは気をつけたいところです。
来週にはGPT-5.5/6 "Spud"が出るかもしれません。
Anthropicが続けて改善パッチを出してくる可能性もあるので、設定はその都度見直すのがよさそうです。
この記事が参考になったら、「スキ」を押していただけると励みになります。
Claude Codeや関連ツールの実践記事を書いていますので、フォローもぜひ！
