Claude Code 品質劣化の真相｜Anthropic公式ポストモーテムで判明した3つの原因と今やるべきこと

2026年3〜4月にClaude Codeが「賢くなくなった」と感じられたのは、モデルそのものの劣化ではなく、Claude Code側に入った3つの別々の変更が重なったためです。 Anthropicは2026年4月23日（米国時間）の公式ポストモーテムでこれを認め、3件とも4月20日の v2.1.116 までに直したと説明しています。

ただし、話はそこで終わっていません。2026年10月時点では、Claude Codeの既定モデルは Claude Opus 5.5 に変わり、その既定の reasoning effort は、3月の原因①と同じ medium です。また、ポストモーテムの後に報告されたトークン増加の不具合（GitHub Issue #46917）は、10月17日時点でもオープンのままです。

この記事でわかること

• 公式ポストモーテムで特定された3つの原因と、それぞれの期間・対象モデル・修正版
• 「物忘れ」「考えが浅い」「返事が短い」などの症状から原因を引ける早見表
• 公式ブログとchangelogで食い違っている点（effortが戻った日付）
• 2025年9月の前回ポストモーテムとの違いと、「APIなら安全」と言い切れない理由
• 2026年10月時点で確認すべき設定（/effort、リリースチャネル、版の固定）
• ポストモーテム後の使用制限の経緯と、未解決のIssue #46917の現状

こんな方に向けた記事です

• 2026年3〜4月にClaude Codeの品質が落ちたと感じ、何が起きていたのか正確に知りたい開発者
• 社内でClaude Codeを使っている、または導入を検討していて、今回の件をベンダー評価に使いたいチームリーダー
• 「最近また浅くなった気がする」と感じていて、いまの設定を確かめたい方

出典: Anthropic Engineering Blog

まず確認：あなたが感じた違和感はどれか（症状 → 原因 逆引き表）

感じた症状と時期がわかれば、どの原因に当たっていたかはおおよそ絞り込めます。2026年9月下旬以降に「前より浅い」と感じている場合は、不具合ではなく既定値の変更が理由のことがあるため、その行も加えました。

4月16〜20日は、③と（Pro/Maxでは）①が同時に影響していた期間です。複数の症状が重なっていたなら、原因も重なっていた可能性があります。

Anthropic公式ポストモーテムの結論

出典: Anthropic Engineering Blog

公式の結論は「モデルは変わっていない。Claude Code側の3つの変更が重なって品質が落ちた」です。Anthropicは2026年4月23日、エンジニアリングブログに「An update on recent Claude Code quality reports」を公開しました。

1. 意図的に劣化させたことはなく、APIと推論層は影響を受けていない。 公式は「We never intentionally degrade our models」と書き、APIと推論層が無事であることはすぐ確認できたとしています。
2. 影響を受けたのは Claude Code・Claude Agent SDK・Claude Cowork。 公式は「The API was not impacted.」と明記しています。
3. 影響の出方にムラがあった。 3つの変更は、影響したトラフィックの範囲も時期も違っていました。そのため全体としては「広く、まだらな劣化」に見えました。Anthropicは3月初めから報告を調べていましたが、当初は通常の意見のばらつきと区別しにくく、社内利用や評価でも再現しなかったと説明しています。
4. 補填は使用制限のリセット。 4月23日時点で全サブスクライバーの使用制限をリセットしました。金銭の返金は公表されていません。

ここでいう「Claude Code側」とは、モデルを製品として動かすための外側の仕組み（ハーネス）のことです。システムプロンプト、セッション管理、既定値の設定などが含まれます。APIで同じモデルを呼んでも同じ品質が出るのに、Claude Code経由だと品質が落ちる。今回の問題は、この層で起きていました。

3つの原因：何が起きていたのか

3つの原因は「既定のeffortを下げた」「thinkingを消し続けるバグ」「短く答えさせる指示」です。公式の記述をまとめると次のとおりです。

Sonnet 4.6・Opus 4.6・Opus 4.7はいずれも、2026年10月時点ではレガシーモデルです（提供は続いています）。

① reasoning effort デフォルト降格（high → medium）

出典: Anthropic Engineering Blog

• 時期: 2026年3月4日（changelogでは v2.1.68）
• 理由: high だと考える時間が長く、UIが固まったように見えるほど待たされることがあった。その待ち時間を減らすため、既定値を medium に下げた
• 結果: 公式は medium について「slightly lower intelligence」（知能がやや下がる）と書いている。低下幅の数値は公表されていない
• 公式の評価: 「This was the wrong tradeoff.」（判断を誤った）と明記している
• 修正: 公式ブログでは4月7日に差し戻し

公式ブログとchangelogで日付がずれている点に注意が必要です。 ポストモーテムは4月7日に差し戻したと書いています。一方、changelogでは4月7日の v2.1.94 で high に戻ったのは APIキー・Bedrock/Vertex/Foundry・Team・Enterprise です。Pro/Max の Opus 4.6・Sonnet 4.6 が high に戻ったのは v2.1.117（npm公開は4月21日UTC）と読めます。Pro/Maxを使っていた方は、4月21日ごろまで medium だった可能性があります。

reasoning effortは、モデルがどれくらい考えるかを指定する設定です。ただし公式ドキュメントは「厳密なトークン予算ではなく、振る舞いの目安」と説明しています。medium でも難しい問題では考えますが、考える量は減ります。

② セッションキャッシングバグ（thinking履歴の毎ターン消去）

出典: Anthropic Engineering Blog

• 時期: 2026年3月26日〜4月10日
• 本来の狙い: 1時間以上放置したセッションを再開するとき、古いthinkingを1回だけ消して、再開時の待ち時間を減らす
• 実際の動き: バグで、それ以降の毎ターンthinkingを消し続けた（clear_thinking_20251015 ヘッダーと keep:1 の組み合わせ）
• さらに悪い条件: ツールの実行中に追加のメッセージを送ると、おかしくなった状態のまま新しいターンが始まり、いま進めているターンの推論まで捨てられた。Claudeは作業を続けるが、「なぜそうしているか」の記憶がだんだん失われた
• 症状: 物忘れ、同じことの繰り返し、ツール選択がおかしい
• 副作用: キャッシュミスが続いたことが「使用制限の減りが速い」という報告の原因だった、と公式は推定している
• 修正: 4月10日の v2.1.101

見つけるのが遅れた理由も公式に書かれています。社内限定のサーバー側の実験（メッセージキュー関連）と、thinkingの表示に関する別の変更が、ほとんどのCLIセッションでこのバグを隠していました。人によるコードレビュー、自動のコードレビュー、単体テスト・E2Eテスト、自動検証、社内での日常利用をすべて通っており、根本原因の特定には1週間以上かかっています。

なお、原因となったプルリクエストに Code Review を Opus 4.7 で当て直したところ、必要なリポジトリを文脈として渡せば Opus 4.7 はこのバグを見つけ、Opus 4.6 は見つけられなかったと報告されています。

③ 冗長性抑制のシステムプロンプト（≤25語 / ≤100語制約）

• 時期: 2026年4月16日〜4月20日（Opus 4.7のリリースと同じ日に出荷）
• 追加された指示: 「Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.」（ツール呼び出しの間の文章は25語以内、最終回答は必要がない限り100語以内）
• 背景: Opus 4.7は前の世代より文章が長くなりやすい（リリース時に公表済み）。それに備えたプロンプト調整だった。数週間の社内テストと既存の評価では劣化が出なかった
• 結果: 他のプロンプト変更と組み合わさって、コーディング品質が落ちた。調査でシステムプロンプトの行を1行ずつ外して影響を測ったところ、ある評価で Opus 4.6・Opus 4.7 とも3%低下していた
• 修正: 4月20日の v2.1.116 で撤回

「短く答えて」は一見すると無害な指示です。それでもエージェントとして動くモデルでは、作業の途中で考えを言葉にする余地が減り、結果としてコードの質が落ちました。自社でシステムプロンプトを書く場合にも参考になる事例です。

タイムライン：発生から修正・ポストモーテム公開まで

時系列で並べると、①と②が直りかけた4月16日に③が入り、「直ったと思ったらまたおかしい」状態になっていたことがわかります。ポストモーテムの日付は米国時間、バージョンの公開日はnpmの記録（UTC）です。

影響範囲：どの経路を使っていた人がどの問題を踏んだか

公式に書かれているのは「Claude Code・Claude Agent SDK・Claude Coworkに影響し、APIは影響を受けていない」までです。製品ごと・原因ごとに、どの程度影響したかの内訳は公表されていません。そこで、公式に書かれていることと書かれていないことを分けて整理します。

API直利用の開発者が何も感じなかったのは、今回の3件がClaude Code側の設定・実装・プロンプトの変更だったためです。ただし、自前でセッション管理やキャッシュ制御、システムプロンプトを書く場合は、同じ種類のミスを自分で起こす可能性があります。

また、当時のセッションが実際に影響を受けたかどうかを、利用者が後から確かめる方法は公表されていません。②はClaude Codeの実装とAPIヘッダーの組み合わせ、③はシステムプロンプトの問題で、手元のログだけでは判定しきれないためです。

API利用時のコスト管理は、Claude Code コスト最適化完全ガイドで詳しく解説しています。

2025年9月のポストモーテムとの違い：「APIなら安全」とは言い切れない

Anthropicが品質の問題でポストモーテムを出したのは、今回が初めてではありません。2025年9月17日にも「A postmortem of three recent issues」を公開しています。2つを並べると、問題が起きた層が違うことがわかります。

2025年9月はAPIも影響を受け、2026年4月はAPIが無事でした。つまり「API直利用なら品質問題とは無縁」とは言えません。どの経路で使っていても、変更を検知する仕組みと、問題が起きたときに報告する手段を自分の側で持っておくほうが確実です。

AMD Stella Laurenzo氏の独立監査が示した定量的劣化

ポストモーテムの前に、利用者の側から劣化を数字で示したのが、AMDのAIグループのディレクター（The Register報道）である Stella Laurenzo氏です。2026年4月2日に GitHub Issue #42796「Claude Code is unusable for complex engineering tasks with the Feb updates」を起票し、自チームのセッションログを分析した結果を公開しました。このIssueは4月24日、ポストモーテムへのリンクを付けて解決済みとして閉じられています。

• 分析対象: 2026年1月30日〜4月1日のセッションログ。6,852セッションファイル、17,871のthinkingブロック（うち10,725は内容が伏せられた状態）、234,760回のツール呼び出し
• 主な数値（報告者の推定値。Anthropicによる検証はない）:
  • thinkingの長さの中央値が、2月下旬までに約67%減った（約2,200文字→約720文字）
  • 編集1回あたりのファイル読み込みが 6.6回（1月30日〜2月12日）→ 2.0回（3月8日〜3月23日）
  • 事前に読んでいないファイルへの編集が 6.2% → 33.7%
  • 推論のループ（ツール呼び出し1,000回あたり）が 8.2 → 26.6、ユーザーによる割り込みが 0.9 → 11.4

この数値を読むときは、2つの点に注意してください。

1. 期間がポストモーテムと完全には重ならない。 67%減は2月下旬からの話で、ポストモーテムの3原因（3月4日〜4月20日）より前から始まっています。
2. Anthropicと見解が分かれている点がある。 Anthropicの担当者はIssue上で、thinkingを伏せる変更（redact-thinking-2026-02-12 ヘッダー）は表示だけの変更で、思考そのものや予算には影響しないと返答しました。表示は showThinkingSummaries: true で戻せると説明しています。

それでもこの報告は、多くの利用者がばらばらに感じていた違和感を、大量のログから数字で示した点で注目されました。The Registerは、Laurenzo氏のチームは他社のツールに移ったと報じています。

Anthropicが公表した5つの再発防止策

公式の再発防止策は「社内で公開版を使う」「レビューを強くする」「プロンプト変更の管理を厳しくする」「段階的に出す」「説明の場を持つ」の5つです。ポストモーテムの「Going forward」には次のように書かれています。

1. 社内で公開版を使う人を増やす: 新機能のテスト版ではなく、利用者と同じビルドを使う社内スタッフの割合を増やす（全員ではなく「より多くのスタッフ」）
2. Code Reviewツールの改善: 社内のCode Reviewツールを改善して顧客にも提供する。レビューの文脈として、追加のリポジトリを渡せるようにする
3. システムプロンプト変更の管理を厳しくする: 変更のたびにモデル別の幅広い評価を行う。1行ずつ外して影響を測る調査を続ける。プロンプトの変更をレビュー・監査しやすくするツールを作る。モデル固有の変更は対象モデルにだけ効くよう、CLAUDE.mdに指針を加える
4. 様子見期間と段階的な展開: 知能とのトレードオフになりうる変更には、様子見期間（soak period）、より広い評価、段階的なロールアウトを設ける
5. 判断の理由を説明する: Xの @ClaudeDevs とGitHubの集約スレッドで、製品の判断とその理由を説明する

2026年10月時点で何が変わったか

出典: Anthropic公式サイト（Claude Code）

ポストモーテムの時点と比べると、2026年10月17日時点では次の点が変わっています。中でも、既定モデルとその既定effortの変化は、いまClaude Codeを使っている全員に関係します。

Opus 5.5の既定effortは medium

2026年9月22日の v2.1.280 で、Opus 5.5がClaude Codeの既定のOpusになりました。ProとTeam Standardでも、既定モデルがSonnetからOpusに変わっています。そしてOpus 5.5の既定effortは medium です。

これは3月の原因①と同じ値ですが、意味は違います。3月はモデルを変えずに既定値だけを下げた結果、品質が落ちました。今回は、Anthropicが新しいモデルの既定値として medium を公式に選んでいます。APIのドキュメントにも「Opus 5.5 は medium が既定で、Opus 5 以前の Opus は high が既定。effort を省略したリクエストは Opus 5 より1段階低く動く」と書かれています。「Opus 5.5のmediumはOpus 5のhighと同等以上」という説明も見かけますが、公式では確認できていません。

覚えておきたいのは、3月の教訓がそのまま使えることです。「前より浅い」と感じたら、まず /effort を確かめる。 公式ガイダンスでは、難しいコーディングやエージェント作業は high、30分を超える長い作業は xhigh が目安です。なお、Opus 5.5ではthinkingをオフにできず、effortが考える量を調整する主な手段です。

もう一つ注意したいのは、ユーザー設定の最上位に保存した effortLevel がOpus 5.5には効かないことです。v2.1.280では、effortがモデル別に保存される前の値を、Opus 5.5などの新しいモデルに引き継がないようになりました。以前 high を設定したつもりでも、Opus 5.5では medium で始まっていることがあります。

Opus 5.5そのものの性能や料金は、Claude Opus 5.5とはで整理しています。

ポストモーテム後も残る新問題：トークン膨張バグ（GitHub Issue #46917）

出典: GitHub anthropics/claude-code Issue #46917

ポストモーテムの3件とは別に、トークンが増える不具合の報告が2026年10月17日時点でもオープンのままです。Anthropicによる原因の説明や、修正版の告知は確認できていません。

何が起きているか

GitHub Issue #46917「CC v2.1.100+ inflates cache_creation by ~20K tokens vs v2.1.98」は、2026年4月12日に起票されました。ラベルは area:cost・bug・has repro などです。

• 報告の内容: プロキシで計測すると、--print "1+1" の実行で cache_creation_input_tokens が v2.1.98 では約49.7K、v2.1.100 では約69.9Kだった。送ったバイト数は少ないのに、約20K多い
• その後の追記（4月16日）: v2.1.98〜v2.1.110 は約28.5Kにそろった。ただし以前の基準と比べて40〜50%多い状態が全バージョンで残った、と報告者自身が書いている
• ダウングレードの扱い: 以前は「v2.1.98に戻せば直る」とされていたが、報告者自身の追記により、いまは有効な回避策とは言えない
• 原因の仮説: Opus 4.7から入った新しいトークナイザーの影響ではないかというコメントもあるが、確認されていない

「課金が実質4割増えた」という話は利用者の計測に基づく主張で、Anthropicは認めていません。なお、公式ドキュメントでは、Opus 4.7以降のトークナイザーでは1Mトークンに入る英単語が約55.5万語（それ以前のモデルは約75万語）とされています。同じ文章でもトークン数が増えるため、使用量が増えたと感じる理由の一つになりえます。ただし、それがIssue #46917と関係するかはわかっていません。

使っていないコネクタ・MCPサーバーによるトークン消費（別問題）

「使っていないOAuthコネクタが、リクエストごとに約2万トークンを消費している」という話が出回りましたが、元の報告と具体的な数値は確認できていません。確かめやすいのは、仕組みとして当然起きる部分です。接続しているコネクタやMCPサーバーのツール定義は、そのぶん毎回コンテキストに載ります。

1. Claude Codeのセッションで /context を実行し、コンテキストの内訳を見る
2. /mcp で、使っていないMCPサーバーをオフにする
3. claude.aiのコネクタも、使っていないものは外しておく

MCPの設定の詳細は、Claude Code MCP連携ガイドで解説しています。

いま読者がすべきこと：実務チェックリスト（2026年10月時点）

出典: Claude Code Docs「Settings files and precedence」

いまやるべきことは「版を確かめる」「effortを確かめる」「更新の受け方を決める」「不要なツール定義を外す」「当時の成果物を見直す」「おかしければ報告する」の6つです。

1. Claude Codeのバージョンを確認する

claude --version
claude doctor   # 直近の自動更新の結果など、詳しい診断を表示

v2.1.116以上なら、ポストモーテムの3件の修正は入っています。古い場合は更新します。

claude update
# npm でインストールしている場合
npm install -g @anthropic-ai/claude-code@latest

npmでは npm update -g を使わず、sudo npm install -g も避けるよう公式は案内しています。公式が推奨するのはネイティブ版のインストール（curl -fsSL https://claude.ai/install.sh | bash）で、ネイティブ版はバックグラウンドで自動更新されます。Homebrew・WinGet・apt などで入れた場合は、既定では自動更新されません。

2. /effort でいまのreasoning effortを確認する

/effort          # 引数なしでスライダーを表示
/effort high     # 直接指定
/effort auto     # 保存した値を消して、モデルの既定に戻す

設定が効く順番は、①環境変数 CLAUDE_CODE_EFFORT_LEVEL・起動フラグ --effort・セッション内の /effort、②設定ファイル（モデル別に保存した値）、③モデルの既定値、です。スライダーで s を押すと、そのセッションだけの指定になります（v2.1.257以降）。max は設定ファイルに保存できません。プロンプトに ultrathink と書くと、そのターンだけ深く考えるよう指示できます（「think hard」などはキーワードとして扱われません）。

基本操作の全体は、Claude Codeの使い方ガイドを参照してください。

3. 更新の受け方を決める（リリースチャネル・版の固定）

今回のような不具合をすぐに受けたくない場合は、リリースチャネルを stable にする方法があります。stable は「通常1週間ほど前の版で、大きな不具合のある版を飛ばす」と公式に説明されています。/config の Auto-update channel から変えるか、設定ファイルに書きます。

{
  "autoUpdatesChannel": "stable"
}

stable でも不具合がゼロになるわけではありません。また、新しいモデルは stable の版より新しいClaude Codeを必要とすることがあります。チームで版をそろえる方法は、Claude Code チーム導入ガイドでまとめています。

4. 使用量と不要なツール定義を確認する

/usage で使用量と警告を、/context でコンテキストの内訳を確認します。使用量の減りが明らかに速いのに原因がわからない場合は、Issue #46917 の最新の状況も見ておくとよいでしょう。

5. 当時の成果物を見直す

影響期間に作った成果物は、テストが通っていても人の目でもう一度確かめておくと安心です。

Laurenzo氏の報告にある「事前に読んでいないファイルへの編集」は、コンパイルや単体テストを通ってしまうことがあります。差分を読み、意図しない変更がないかを確かめてください。

6. おかしいと感じたら /feedback で報告する

ポストモーテムには、/feedback で報告してくれた利用者のおかげで原因を特定できたと書かれています。違和感があれば、セッション内で /feedback を使うのが一番早い報告手段です。

ポストモーテム後の使用制限の経緯（2026年10月時点）

補填は4月23日の使用制限リセットで、その後は期間限定の+50%を経て、2026年9月14日から週次上限が恒久的に+25%になっています。

9月14日の変更について、Anthropicは「いまと比べると、Claude Codeの週次上限は17%減る」と説明しています（BleepingComputer、2026年8月29日）。+50%の期間に慣れていた方は、9月中旬から上限が厳しくなったと感じているかもしれません。5時間ごとの枠は+50%の対象外で、Claude（Web など）やCoworkの上限も変わっていません。

使用制限は5時間の枠と、有料プランの週次上限の2段構えです。Web・デスクトップ・モバイル・Claude Codeで同じ枠を共有し、上限に達した後は usage credits（標準のAPI料金）で使い続けられます。

日本円での比較は、Claude Code料金【日本円換算】とClaude料金を日本円で解説にまとめています。

ベンダー透明性の観点で見た今回の対応

今回の対応は、AIベンダーとしては情報公開が多いほうです。一方で、利用者の側で確かめられないことも残っています。

評価できる点

• 3つの変更の内容・期間・対象モデル・修正版まで公開した
• 原因②が見逃された理由（社内実験がバグを隠していた、レビューやテストをすべて通った）まで書いた
• 公開と同じ日に使用制限をリセットした
• 再発防止策を具体的に書き、@ClaudeDevs とGitHubで説明する場を設けた
• 2025年9月に続き、品質の問題を認めて原因を公開している

残っている課題

• 金銭的な返金はなく、補填は使用制限のリセットだけ
• 当時のセッションが影響を受けたかを、利用者が確かめる方法がない
• 公式ブログとchangelogで、effortが戻った日付の説明がずれている
• Issue #46917には、2026年10月17日時点でAnthropicの見解が示されていない

AIツールを業務で使う側としては、次の点を見ておくと判断しやすくなります。

• 問題が起きたとき、ポストモーテムを公開するか
• 変更とその理由を伝える窓口があるか
• 段階的な展開や様子見期間を運用しているか
• 利用者側で版や更新のタイミングを管理できるか

Claude Codeで作った試作やツールを、社内の実データや既存システムにつないで業務で使う段階では、ベンダー側の変更で挙動が変わっても気づけるように、テスト・版の管理・引き継ぎの資料を開発体制の側で用意しておく必要があります。その段階の進め方は、AIで作ったアプリを開発会社へ引き継ぐにはで整理しています。

セキュリティと安全な運用については、Claude Codeのセキュリティと安全な使い方も参考にしてください。

Claude Codeを使い続けるのがおすすめな方・慎重に検討すべき方

今後もClaude Codeを使い続けるのがおすすめな方

• 問題を公開して説明するベンダーの姿勢を重視する開発者・組織
• /effort やリリースチャネルを自分で設定・管理できる方
• @ClaudeDevs やchangelogを定期的に見て、変更を追える方
• 不具合を見つけたら /feedback で報告し、版を上げ下げして切り分けられる方
• Claude Agent SDKやCoworkなど、Claudeのエージェント機能をまとめて使いたいチーム

慎重な検討が必要な方

• ツール側の変更で品質が揺れることを許容できない業務（今回のような問題は他社のツールでも起こりうる）
• 版の管理や更新のタイミングを決める担当がいない小さなチーム
• 契約上、品質や稼働の保証（SLA）が必須の領域
• Issue #46917のような使用量の問題が解決するまで、費用の見通しを立てにくいと感じる方
• プロンプトや既定値を自社で完全に管理したい組織（この場合はClaude APIと自前のハーネスの組み合わせも選択肢。ただし2025年9月のようにAPI側で問題が起きることもある）

他のツールと比べたい場合は、Claude Code vs GitHub Copilot 徹底比較やCursor vs Claude Code 徹底比較が参考になります。

まとめ

• 2026年3〜4月のClaude Codeの品質劣化は、モデルの劣化ではなく、Claude Code側の3つの変更（①既定effortを medium に、②thinkingを毎ターン消すバグ、③短く答えさせるプロンプト）が重なったものだった
• 3件は2026年4月20日の v2.1.116 までに解消。ただしPro/Maxのeffortが high に戻ったのは、changelog上は v2.1.117（4月21日UTC）
• 影響したのはClaude Code・Agent SDK・Cowork。APIは無事だったが、2025年9月にはAPIも影響を受けており、「APIなら安全」とは言い切れない
• 2026年10月時点の既定モデルはOpus 5.5で、既定effortは medium。浅いと感じたら /effort high などで明示的に上げる
• 業務で安定して使うなら、stable チャネルや版の固定で更新の受け方を決めておく
• Issue #46917は2026年10月17日時点でオープンのまま。v2.1.98へのダウングレードは、もう有効な回避策とは言えない
• 週次上限は9月14日から恒久的に+25%。+50%の期間と比べると約17%減っている

Claude Codeの全体像は、Claude Codeとはで解説しています。

FAQ

Q1. Claude Codeで使われていたモデル（Sonnet 4.6 / Opus 4.6 / Opus 4.7）は劣化していたのですか？

公式の説明では、劣化していません。Anthropicは、意図的にモデルを劣化させたことはなく、APIと推論層は影響を受けていないとすぐ確認できたと書いています。APIで同じモデルを呼んだ場合の品質は変わっておらず、Claude Code側の設定と実装が原因でした。

Q2. 返金はありますか？

金銭的な返金は公表されていません。ポストモーテムに補填として書かれているのは、2026年4月23日時点での全サブスクライバーの使用制限リセットだけです。

Q3. 2026年3〜4月に何も感じなかった場合も、見直しは必要ですか？

影響の出方にムラがあったと公式が書いているため、感じなかった人がいるのは自然です。ただ、利用者が後から影響の有無を確かめる方法は公表されていません。業務の重要なコードを3月26日〜4月10日や4月16日〜20日に作っていたなら、差分のレビューだけでもしておくと安心です。

Q4. API経由なら、今後も同じ問題は起きませんか？

今回の3件は起きませんでしたが、API経由なら今後も安全とは言えません。2025年8〜9月には、インフラ層のバグでAPIを含む広い範囲で品質が落ちています。また、自前でシステムプロンプトやキャッシュ制御を書く場合は、今回と同じ種類のミスを自分で起こす可能性があります。

Q5. Claude.ai（Webチャット版）にも影響はあったのですか？

ポストモーテムに書かれているのは「Claude Code・Claude Agent SDK・Claude Coworkに影響し、APIは影響を受けていない」までです。Claude.aiのチャットについては触れられていないため、影響の有無はわかりません。

Q6. 最近「また浅くなった」と感じます。不具合ですか？

2026年9月下旬以降なら、不具合ではなく既定値の変化かもしれません。Claude Codeの既定モデルはOpus 5.5になり、その既定effortは medium です。/effort で現在の値を見て、難しい作業では high か xhigh を指定してみてください。それでも明らかにおかしい場合は、/feedback で報告するのが確実です。

Q7. 以前 high を設定したのに、Opus 5.5では medium になっているのはなぜですか？

v2.1.280から、effortはモデル別に保存されるようになりました。それ以前に保存した値は、Opus 5.5などの新しいモデルに引き継がれません。ユーザー設定の最上位にある effortLevel もOpus 5.5には効かないため、Opus 5.5を使った状態で改めて /effort high を指定する必要があります。

Q8. /effort ではどのレベルを選べますか？

Opus 5.5・Sonnet 5.5・Haiku 5.5・Opus 5・Sonnet 5・Opus 4.8・Opus 4.7では、low・medium・high・xhigh・max の5段階です。Opus 4.6・Sonnet 4.6には xhigh がなく、指定すると high で動きます。max は設定ファイルに保存できないため、使うたびに指定します。

Q9. 同じことがまた起きる可能性はありますか？

ゼロではありません。Anthropicは、様子見期間の導入やプロンプト変更の管理強化を打ち出していますが、ツール側の変更で品質が揺れるリスクはどのAIツールにもあります。利用者の側では、stable チャネルにする、組織で版の範囲を決める、@ClaudeDevs や公式の変更履歴を見る、といった備えが役に立ちます。

Q10. Issue #46917 の対策として、v2.1.98にダウングレードすべきですか？

おすすめしません。報告者自身が2026年4月16日に、古い版でも以前の基準より多い状態が残ったと追記しており、ダウングレードで直るとは言えなくなっています。古い版に戻すと、ポストモーテムの3件の修正（v2.1.101・v2.1.116）も失います。使用量が気になる場合は、/usage と /context で内訳を確かめ、Claude Code コスト最適化完全ガイドの方法で減らすほうが現実的です。