claude ナーフは本当?原因・思考設定と確認方法・対処

claude ナーフは本当?原因・思考設定と確認方法・対処

「claude ナーフ」と検索して、以前より回答が浅い、Claude Codeが途中で止まる、考える時間が短いと感じていませんか。この記事では、利用者の定量報告と公式仕様を分けて、モデル自体の変更・effort設定・利用環境を確認し、今できる対処を整理します。

結論

claude ナーフは公式に一律の弱体化が確定した状態ではなく、思考量の設定、モデル切替、表示変更、利用枠などが重なって「弱くなった」と感じるケースが中心です。effortとモデルIDを確認し、同じ課題で比べれば原因を切り分けて対処できる。

目次 (7)

claude ナーフとは?「弱体化」を指すネット用語

ナーフは、ゲームの強い武器やキャラクターを運営側が弱くする意味から広がった言葉です。「Claudeがナーフされた」という場合は、モデルの知識や能力そのものが落ちたという断定ではなく、以前より回答が浅い、指示を守らない、作業を早く打ち切る、利用上限に達しやすい、といった体感をまとめて表します。

今回の検索結果では、Claude Codeの利用制限と品質低下を扱う総合レポート(https://note.com/delta_ipsilon/n/nae28312e0ee3)、AMDのAI責任者によるセッション分析を紹介した記事(https://smhn.info/202604-claude-code-nerf)、能力低下の議論を解説する記事(https://note.com/cloudavenue/n/n00ed613cd018)が上位に並びました。共通する関心は「本当にモデルが弱くなったのか」「思考量や利用枠が変わったのか」「今の設定で戻せるのか」です。

したがって、ナーフという言葉だけを見て、Anthropicが全ユーザー向けに隠れて性能を下げたと決めつけるのは早計です。まず、観測された事実、公式に説明されている仕様、利用者側の推測を分けて読む必要があります。

本当にナーフされた?確認できる事実と未確定の推測

2026年4月に公開されたGitHub Issueでは、ある開発チームが2026年1月末から4月初めまでの6,852セッション、234,760回のツール呼び出し、17,871個の思考ブロックを分析したと報告しています。コードを読む回数が編集前の平均6.6回から2.0回へ減り、停止を検知するフックの発生も増えた、という内容です。Issue本文は https://github.com/anthropics/claude-code/issues/42796 で確認できます。

この分析は「気のせいだけでは説明しにくい変化が、特定環境のログに現れた」ことを示す材料です。一方で、特定チームの利用履歴であり、すべてのユーザー、すべてのモデル、すべての依頼で同じ変化が起きた証明ではありません。The Registerも同じ報告を紹介していますが、記事ではAnthropic側の回答が当初確認できていないと記されています(https://www.theregister.com/software/2026/04/06/claude-code-has-become-dumber-lazier-amd-director/5228799)。

また、思考ブロックが画面に表示されなくなったことと、内部で考える量が減ったことは同じではありません。表示の省略、思考の長さ、最終回答の品質は別々に測る必要があります。現時点で「Claude全体が一律にナーフされた」と断定するより、「一部の更新や設定変更で、特定の作業の品質が下がった可能性が報告されている」と表現するのが正確です。

「弱くなった」と感じる主な原因

第一に、effortレベルが変わっている可能性があります。Claude Codeの公式ドキュメントでは、effortは課題ごとにどの程度の適応的な推論を行うかを調整する設定と説明されています。低いレベルは速く安く、高いレベルは複雑な課題で深く考える方向に働きます(https://code.claude.com/docs/en/model-config)。同じモデル名でも設定がmediumとhighでは、確認回数や途中で粘る長さが変わり得ます。

第二に、モデル名が同じように見えても実体が変わっている場合があります。opusやsonnetのような別名は、提供元や更新時期によって対応するバージョンが変わります。再現性が必要なら、別名だけでなく実際に選ばれたモデルIDを記録し、必要に応じて完全なモデル名を指定します。公式ドキュメントでも、別名は推奨バージョンへ更新されることが説明されています。

第三に、適応的な推論では、すべての工程を同じ長さで考えるわけではありません。公式説明では、定型的な依頼には速く答え、複雑な工程にはより深い推論を割り当てる仕組みとされています。短い質問では問題がなくても、複数ファイルの修正、長い調査、仕様の厳しいレビューで差が出ることがあります。

第四に、利用枠や自動切替の影響があります。使用量の上限に近づいたとき、応答が遅くなったり、別モデルへ切り替わったり、作業を続けにくくなったりすることがあります。Fable系モデルでは、安全分類に該当した依頼が自動的に別モデルへ切り替わる場合も公式に説明されています。これはモデル全体の弱体化ではなく、依頼や契約条件に応じた処理経路の変更です。

ナーフと感じたときの確認手順

体感だけで原因を一つに決めず、次の順序で確認します。

  1. 実際のモデルを確認する。 Claude Codeのセッションヘッダーや/modelで、選択中のモデル名と提供経路を確認します。opusやsonnetという別名だけでなく、表示されたバージョンをメモしてください。
  2. effortの現在値を確認する。 /effort statusを実行し、low、medium、high、xhigh、maxのどれで動いているかを見ます。利用できる段階はモデルによって異なるため、選択肢にない値を無理に指定しません。
  3. 環境変数の上書きを調べる。 CLAUDE_CODE_EFFORT_LEVELは、公式ドキュメント上で--effortや/effortより優先されます。PowerShellならecho $env:CLAUDE_CODE_EFFORT_LEVEL、macOSやLinuxならecho $CLAUDE_CODE_EFFORT_LEVELで値を確認します。意図しないmediumやlowが入っていれば、設定元を見直します。
  4. 新しいセッションで同じ課題を試す。 長い会話の続きではなく、新規セッションを作り、同じ入力・同じモデル・同じeffortで実行します。会話履歴やコンテキストの蓄積が原因かどうかを切り分けやすくなります。
  5. 品質を数値で記録する。 最初の返答までの時間、完了までの時間、修正回数、必須条件を満たしたかを残します。「浅い」「賢くない」という感想だけでなく、どの条件で失敗したかを記録してください。
  6. 条件を一つずつ変えて再比較する。 effortだけを上げる、モデルだけを固定する、入力を短くする、というように変更を一つに限定します。複数を同時に変えると、どの対処が効いたのか分からなくなります。

Claude Codeのeffortを戻す方法と設定例

一時的に深い推論を試すなら、セッション内で次のコマンドを使います。

/effort high
/effort xhigh
/effort max

maxは最も深い段階ですが、対応モデルが限られ、通常はそのセッションだけに適用されます。公式のコマンド一覧でも、/effortにはauto、high、xhigh、maxなどの選択肢があり、maxはセッション限定と説明されています(https://code.claude.com/docs/en/commands)。まず小さな検証課題で結果を比べてから、本番の長い作業へ広げるのが安全です。

毎回同じeffortで起動したい場合は、環境変数を使う方法があります。PowerShellでは次のように設定してからClaude Codeを起動します。

$env:CLAUDE_CODE_EFFORT_LEVEL = "high"
claude

macOSやLinuxではexport CLAUDE_CODE_EFFORT_LEVEL=highです。ただし、この環境変数は他のeffort指定より優先されるため、設定したままではセッション中の変更が反映されないことがあります。不要になったらPowerShellではRemove-Item Env:CLAUDE_CODE_EFFORT_LEVEL、macOSやLinuxではunset CLAUDE_CODE_EFFORT_LEVELで解除します。値の候補と優先順位は公式の環境変数一覧(https://code.claude.com/docs/en/env-vars)で確認してください。

高いeffortにすれば必ず以前の品質へ戻るわけではありません。消費トークン、待ち時間、プランの利用枠が増える可能性があるため、短い質問まで常にmaxにするのは現実的ではありません。簡単な作業は低め、設計判断や複雑な修正はhigh以上というように、課題の重さで使い分けます。1回だけ深く考えさせたいときは、公式ドキュメントにあるultrathinkの指定も候補になります。

再発させない比較方法|体感を記録に変える

ナーフ疑惑を追うときに重要なのは、SNSの投稿を自分の環境の事実として扱わないことです。次の項目を同じ形式で残すと、モデル更新後の差を比較できます。

  • 実行日とClaude Codeのバージョン
  • モデルID、提供経路、effortレベル
  • 入力文と参照資料の量
  • 最初の返答までの秒数と完了までの秒数
  • 修正依頼の回数、途中停止の有無、最終成果の合否

同じ課題を一度だけ試すと、偶然の揺れや入力の違いを見分けられません。機密情報を含まない短い課題を用意し、条件を固定して複数回比べます。結果が変わっても、すぐに「モデルがナーフされた」とは結論づけず、モデル、effort、会話の長さ、利用枠、ネットワークの順に差を確認します。

Anthropicのモデル非推奨化ページ(https://platform.claude.com/docs/ja/about-claude/model-deprecations)にあるDeprecatedやRetiredは、モデルの提供終了・移行を示す言葉です。品質を意図的に下げたという意味ではありません。利用できるモデルが変わったときは、旧モデルの終了とナーフを混同しないように、変更日と代替モデルを記録しておきましょう。

まとめ

claude ナーフという言葉の背景には、回答品質の体感低下、思考量の変化、利用上限、モデルの切替が混在しています。特定チームのログから有力な変化が報告されている一方、Claude全体が一律に弱体化したと公式に確定したわけではありません。

まずモデルIDとeffortを確認し、環境変数や長い会話による上書きを除きます。そのうえで同じ課題を同じ条件で比較し、必要なときだけhigh・xhigh・maxへ上げます。高い設定は品質を試す手段であり、万能なナーフ解除ではないと理解しておけば、費用と品質のバランスを保ちながら使い続けられます。

参考になったら ♡
Clauder Navi 編集部
@clauder_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。運営方針 は メディアについて をご覧ください。