はじめに
2026年の2月から3月にかけて、Claude Codeの挙動に違和感を覚えた開発者は、筆者だけではないはずです。
これまで問題なく回していたワークフローで、ファイルを読まずにいきなり編集を始めたり、まだ直っていないバグを「修正しました」と報告してきたり、存在しないAPIバージョンを当然のように書いてきたりする場面が増えました。最初は「プロンプトが悪いのかな」と自分の書き方を疑っていました。ところが、同じリポジトリで同じ指示を出しても、1月までの挙動と何かが違うのです。
当初はモデル自体が差し替えられたのではないかと疑っていました。しかし、実際の原因はもっと地味で、そして運用側からすると重要な変化でした。本稿では、Anthropic公式の発言・一次ソース・第三者による定量検証をもとに、2026年の前半に起きた「体感劣化」の背景を整理します。あくまで技術検証のレポートとして、落ち着いた視点で見ていきたいと思います。
挙動の変化として多く報告された現象
まず「何がどうおかしかったのか」を整理します。SNSやGitHub Issues、開発者コミュニティで観察された報告を、筆者の経験と重ねながら並べてみます。
幻覚（ハルシネーション）の増加
- 存在しないパッケージ名やAPIバージョンを生成する
- 架空のcommit SHAを引用する
- リポジトリに存在しない関数名を前提に説明を組み立てる
1月までもゼロではありませんでしたが、体感として明らかに頻度が上がりました。
ファイルを読まずに編集を始める
Claude Codeには「編集する前に対象ファイルを読む」という運用上の不文律があります。ところがこの期間は、Read ツールを呼ばずに Edit を当てようとするケースが散見されました。結果、存在しない行を書き換えようとしてエラーになる、もしくは既存のコードを破壊的に上書きする現象につながっていました。
未解決なのに「完了しました」と申告する
テストが通っていない、もしくはそもそもテストが走っていない状態で「タスクを完了しました」と報告してくるパターンです。エージェントの自己評価が甘くなっているような印象でした。
思考トレースがUIに出ない
2月中旬以降、Claude Code上で思考の中身が以前ほどは目に見えなくなりました。内部で何を考えているのかが不透明になり、「怪しい挙動をしているのに、なぜそうなったかが追えない」という二重苦が発生していました。
以上の現象は、単独ではどれも「たまたま出た不具合」で片付けられる範囲です。しかし複数が同時多発し、しかも2〜3月に集中していた点で、単なる偶発とは考えにくい状況でした。
原因仮説：Adaptive Thinking と effort デフォルト値
Adaptive Thinking の仕組み
Anthropicの公式ドキュメント Adaptive thinking によれば、Adaptive Thinking はタスクの複雑度に応じてモデルが思考トークン（推論にかけるトークン数）を自動調整する機構です。単純な依頼には少なく、複雑な設計・デバッグには多く割り当てるという仕組みが、明示的に有効化されるようになりました。
この仕組み自体は合理的で、本来はコストを抑えつつ品質を保つための仕掛けです。
ただし、自動調整である以上「タスクの複雑度を取り違えると、必要な思考量を割り当てない」という失敗モードが存在します。これが現実にどう転んだかは後述します。
Boris Cherny 氏による「推論トークン0割り当て」の報道
Claude Codeの開発責任者である Boris Cherny 氏は、Adaptive Thinking に起因する不具合に言及したと報じられています（Fortune / VentureBeat 等）。要旨としては、一部のターンにおいて推論トークンが実質的にゼロに割り当てられていたケースがあった、という内容でした。なお、筆者が一次ソース（Anthropic公式ブログや Cherny 氏本人の発信）で直接確認できたのは、redact-thinking-2026-02-12 が UI 表示側の変更（UI-only change）であるという点のみです。推論トークンゼロ割り当ての話は、現時点では二次報道ベースで扱うのが妥当です。
思考トークンがゼロということは、実質的には「考えずに答えていた」ことを意味します。幻覚や、ファイル未読のまま編集を始める挙動は、この「考えなかったターン」と親和性が高いと考えられます。報道ベースではあくまで「一部」のターンとされており、全ターンで発生していたわけではない点は押さえるべきです。ただし、Claude Codeのようなマルチターンのエージェント運用では、1ターン分の品質低下が後続のターンに連鎖することが多いです。
effort デフォルト値の変遷
もう一つの論点が、effort のデフォルト値です。Claude Codeには、思考量の総量を制御する effort という概念があり、low / medium / high などの水準があります（2026年4月現在は xhigh や max も選択肢に加わっています）。
ポイントは、この effort のデフォルトが、告知のないままに引き下げられた時期があった点です。報じられている内容を踏まえて時系列を整理すると、2026-03-04 に Max / Team プランで high から medium にデフォルトが引き下げられ、2026-04-07 に API-key / Bedrock / Vertex / Foundry / Team / Enterprise で high に戻された、という経緯です。Adaptive Thinking が 2026-02-05 に強制有効化されたタイミングと、この effort デフォルト引き下げ期間が重なっており、双方が掛け合わさって体感上の品質低下につながった、というのが筆者の見立てです。
この「Adaptive Thinkingの強制有効化」と「effortデフォルトの引き下げ」が重なると、何が起きるか。
- Adaptive Thinkingが「これは単純なタスク」と判断する
- effortのデフォルトが低めなので、そもそも上限も低く見積もられる
- 結果として、実際は複雑なタスクでも思考量が絞られる
この組み合わせが、2〜3月の「急にバカになったように見える」体感の正体だった、と整理すると筋が通ります。
第三者の定量検証
この手の「体感の悪化」は、客観的に数値で裏付けないと単なる印象論になります。ここでは第三者による検証を紹介します。
AMD シニアディレクターによる6,852セッション分析
AMD社のシニアディレクターである Stella Laurenzo 氏が、GitHub Issue（anthropics/claude-code #42796）で、6,852 セッション分の利用ログを分析し、思考量が約67%減少していた、と公開しました。同 Issue では、17,871 thinking blocks・234,760 tool calls 相当のデータが集計されており、定量的な分析で、しかもサンプル数が数千セッション規模である点で、単なる主観とは一線を画します。
67%という数字がどこまで厳密かについては議論の余地があります。計測方法、セッションのタスク分布、モデル選択の偏りなど、変数は多く存在します。それでも「有意に思考量が減った時期がある」という主張が定量データを伴って出てきたことは、個人の体感ではなく集団的な変化が起きていた可能性を示唆しています。
Fortune・VentureBeatの報道
ビジネスメディアの Fortune は、Anthropicの品質低下に関するユーザー反発と、変更を告知しなかったことに対する透明性の欠如への批判を報じました。VentureBeat も同時期に「Anthropicはユーザーの訴えどおりClaudeを弱体化しているのか」という切り口で記事を出しています。
両媒体とも、記事中で「モデルそのものが差し替えられた」というよりは「設定の変更」と「告知の不足」を論点として扱っていた点が興味深いところです。つまり、問題の本質は「モデルの性能」ではなく「設計上の選択と、それを伝えなかったこと」にあるという整理で一致しています。
DEV.toの技術解説
DEV.to上では、2〜3月のClaude Codeアップデートが、複雑なエンジニアリングタスクを静かに壊していた、というタイトルの技術解説記事が出ています。こちらは開発者視点で、どのタスクで具体的にどういう失敗が起きやすかったかを整理しており、現場感のある分析となっています。
3つのソース（AMDの定量分析、主要メディアの報道、開発者による技術解説）が、それぞれ独立に「2〜3月に何かが起きた」という結論に寄せているのは、少なくともユーザー側の体感が実在した傍証だと筆者は考えています。
環境変数による緩和策
ここからは、運用側でできることに話を移します。Anthropicの公式側で順次修正が進んでいることは前提として、ユーザーサイドでも既知の緩和手段があります。
主要な環境変数
# Adaptive Thinkingを無効化
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
# effortを最大に固定
export CLAUDE_CODE_EFFORT_LEVEL=max
前者は Adaptive Thinking そのものを切ります。思考量の自動調整をやめ、モデルが「単純だろう」と判断して思考を絞る経路を閉じる狙いです。後者は effort のデフォルトを最大に固定します。告知なくデフォルトが引き下げられるリスクから、運用側で明示的に独立する形になります。
なお CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は、Opus 4.6 / Sonnet 4.6 系のモデルを対象とした緩和用の環境変数である点に注意が必要です。Opus 4.7 は公式に "always uses adaptive reasoning"（常に adaptive reasoning を使用する）とされており、この環境変数による無効化は効きません。Opus 4.7 環境では、effort レベルの明示指定で運用を制御するのが基本になります。
設定方法の選択肢
プロジェクトを横断して効かせたい場合はシェルの初期化ファイル（~/.zshrc や ~/.bashrc）に書きます。プロジェクトごとに切り替えたい場合は、.envrc や direnv などで管理するのが扱いやすいでしょう。
チームで運用する場合は .claude/settings.json に等価な設定を置く方針もありえますが、ユーザーごとに挙動を微調整したいケースも多いため、まずは個人の環境変数で入れて感触を見るのがおすすめです。
設定前後で筆者が観察した変化
注意点として、厳密なベンチマークではありません。同一リポジトリで似たようなタスクを回した、あくまで筆者の観察レベルの話です。
- ファイルを読まずに編集を始めるケースが明らかに減った
- 「完了しました」と申告する前に、自発的にテスト実行や状態確認を挟むようになった
- 複雑なリファクタリングで、設計の整理から入る頻度が上がった
- 反面、トークン消費は体感で増えた。コストは上振れます
重要なのは、この変更は「全員にとって最適」ではない、という点です。単純なタスクを大量にさばく用途では、max 固定は過剰なコストを生みかねません。タスクの性質に応じて effort を切り替える運用のほうが、長い目で見ると扱いやすいと考えます。
Anthropic公式側での修正との関係
Anthropic側も Adaptive Thinking のバグに対するパッチを順次展開している、と発表しています。そのため、環境変数による緩和は「当座の処方箋」であり、時期が経つにつれ必要度は下がっていく性格のものです。
ただし筆者個人としては、「Adaptive Thinking をオンに戻していいかどうか」を判断するためには、もう少し時間をかけて挙動を観察する必要があると考えています。サイレントな挙動変更が一度でもあった以上、以前の信頼水準にすぐ戻るわけではありません。
Opus 4.7 リリース（2026-04-16）でどう変わったか
2026年4月16日、Anthropicは Claude Opus 4.7 を一般提供として公開しました。このタイミングは、上述の「劣化騒動」と時期が重なっています。関連する変化を整理します。
性能向上のポイント
公式発表と VentureBeat 等の報道を突き合わせると、以下のような向上が示されています。
- エージェント推論でのマルチステップ成功率が向上（報道ベース）
- ツール呼び出しの安定性改善が報告されている（報道ベース）
- 1M contextが標準API価格で提供される
- 高解像度画像入力のサポート（最大 2,576px / 3.75MP）
ベンチマーク数値（例: SWE-bench Pro の具体的スコアや、他モデルとの比較値）については、筆者が一次ソースで直接裏取りできていないため、本稿では具体値の記載を控えます。実タスクでの使い勝手は個別に検証が必要ですが、ツール呼び出しの安定性が改善される方向の変化は、前述した「ファイルを読まずに編集」系の問題にも効く可能性があります。
新しい effort level「xhigh」の追加
既存の low / medium / high に加え、xhigh が追加されました。max との中間的な位置づけで、コスト効率と思考量のバランスを取りやすくなっています。
興味深いのは、このタイミングで「effortを明示的に選ぶ」ことが運用上より重要になったことです。2〜3月の騒動で「デフォルト任せは危ない」という学びがあった直後に、選択肢が増えたわけで、ユーザー側の判断力がより問われる状況になっているとも言えます。
挙動そのものは改善の方向へ
Opus 4.7 への移行後、ツール呼び出しの組み立てや、マルチステップでの文脈保持については、筆者の観察範囲でも改善の手応えがあります。ただし、これはモデルのアップデートによるものか、Adaptive Thinking まわりのバグ修正によるものか、あるいはその両方か、現時点では切り分けが難しいです。
だからこそ、「CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 を設定している人は、まずは外さずに運用を継続する」という判断が、多くの開発者の間で共有されているのだろうと考えます。
所感：透明性と運用設計の観点から
ここまでは、ほぼ事実と検証の整理に徹してきました。最後に、1人の開発者として感じたことを少しだけ書きます。
モデルではなく「設定」が品質を左右する時代
今回の件で最も学びになったのは、「LLMの体感品質は、モデルの性能だけでなく、デフォルト設定の選択によって大きく動く」という点です。Adaptive Thinking のような自動化機構は、正しく動けばコストと品質の両立に寄与する一方で、デフォルト値が一段下がるだけで、ユーザーから見れば「急にバカになった」と感じるほどの差を生みます。
ツールを業務に組み込む立場から言えば、「どのモデルを選ぶか」と同じくらい、「どの設定で運用するか」が重要な意思決定になってきていると感じます。
サイレントな挙動変更は、信頼のコストが高い
Anthropic側の立場も想像はつきます。大規模サービスでは、日々の調整を逐一告知するのは現実的でないですし、段階的なロールアウトの最中に変更内容を公開すると誤解を招くこともあるでしょう。
それでも、今回の件で露呈したのは「エージェントとしての使い方が深くなればなるほど、小さな挙動変更が大きな違いになる」という現実です。コードエディタや対話UIで使うだけなら、多少のブレは吸収されます。しかし、自律的にタスクを実行させるエージェント用途では、挙動変更は設計前提そのものを揺るがします。
この点、Anthropicが Adaptive Thinking のバグを公式に認めたこと、パッチを展開していることは、透明性を回復する方向の動きとして評価できます。一方で、「デフォルトをいつ、どう変えるか」についてのガイドラインが開発者向けに明確化されると、ツールとしての信頼性はさらに増すように思います。
運用側の備え
今回の件で、個人的には以下を運用ルールに組み込みました。
- effort レベルは、プロジェクトの性質に合わせて明示的に指定する
- Adaptive Thinking の挙動は、重要度の高い作業では一度切って確認する
- モデルやツールのバージョンアップ時は、既知のワークフローで数タスク回して、挙動の変化を観察する
- 挙動に違和感を覚えたら、まず自分のプロンプトを疑うのではなく、設定まわりから見直す
最後の項目は、以前なら逆でした。「まず自分のプロンプトを疑え」は今も基本ですが、今回のような環境側の要因が絡む場面では、プロンプトをいくら直しても改善しないことがあります。切り分けの順番として、環境変数とバージョンを最初に確認するほうが早いケースもあると学びました。
まとめ
以下、本稿の要点を整理します。
- 2026年の2〜3月にかけて、Claude Codeの挙動に違和感を覚える開発者が多数いた
- 主な症状は、幻覚の増加、ファイル未読のまま編集、未解決での完了申告、思考プロセスの不可視化など
- 原因として有力なのは、Adaptive Thinking の強制有効化と、effortデフォルト値の引き下げの組み合わせ
- Boris Cherny 氏は Adaptive Thinking に起因する「推論トークンが一部ターンでゼロ割り当てになるケース」について言及したと報じられている（Fortune / VentureBeat 等）。公式に一次ソースで確認できるのは
redact-thinking-2026-02-12が UI-only change だった点のみ - AMD のシニアディレクター Stella Laurenzo 氏による 6,852 セッション分析（Issue #42796）で、思考量が約67%減少していた、という主張が出された
- 緩和策として、
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1とCLAUDE_CODE_EFFORT_LEVEL=maxの環境変数が広く共有されている（前者は Opus 4.6 / Sonnet 4.6 向けで、Opus 4.7 には効かない点に注意） - 2026年4月16日にリリースされた Opus 4.7 は、ツール呼び出しの安定性改善や
xhigheffort の追加など、関連する領域の改善が見られる - 本件の教訓は、「モデルの性能」と同じくらい「デフォルト設定の扱い」が体感品質を左右すること
最後に補足として、本稿は一次ソース（Anthropic公式ドキュメント、Fortune、VentureBeat、Boris Cherny 氏の公式発言、AMD 側の公開データ、DEV.toの技術解説）をもとに整理しています。Anthropic側でも修正は進んでいるため、現時点の挙動は改善されている可能性が高いです。環境変数の設定は当座の処方箋として扱い、時期を見て運用を見直すのが健全だと考えます。
もし同じような違和感を2〜3月に感じていた方がいたら、「体感は気のせいではなかった」という整理の役に立てば幸いです。逆に、違和感を覚えなかった方にとっても、LLMの運用設計を考える上での参考材料になればと思います。