Claude Codeが3月から4月にかけて"忘れっぽく""反復的"になっていた原因が、Anthropic公式 postmortem で全公開された。

3つのバグが重なっていて、特に衝撃的だったのは「冗長性削減のためのプロンプト1行」が評価で3%の性能低下を引き起こしていたこと。

この記事では一次情報を読み込み、自分のClaude Code環境にどう反映するかまで落とす。

この記事でわかること

Claude Codeが2026年3-4月に品質劣化していた3つの具体的なバグ
どの期間にどのモデル(Sonnet 4.6 / Opus 4.6 / 4.7)が影響を受けたか
「テキストは25語以下」というプロンプト1行で3%性能が落ちた理由
Anthropicの再発防止策から学べる、自分のプロンプト・エージェント運用の改善点
いまClaude Code v2.1.116以降にアップデートしているか確認する手順

対象読者

Claude Code を業務で毎日使っているエンジニア
「3月以降なんかClaudeが調子悪い気がする」と感じていた人
AI エージェントの品質管理・モニタリング設計を考えている人
プロンプトエンジニアリングを真面目にやっている人

何が起きていたのかタイムライン

Anthropic が 2026-04-23 に公開した postmortem (anthropic.com/engineering/april-23-postmortem) によると、Claude Code・Claude Agent SDK・Claude Cowork で発生した品質劣化の原因は 3つのバグが時系列で重なっていた ことだ。API 単体（Messages API を直接叩く形）への影響は無かったが、Claude Code を含む上位プロダクトには影響した。

期間	出来事
3/4 〜 4/7	バグ①(推論レベルのデフォルト変更) が稼働中
3/26 〜 4/10	バグ②(キャッシュ最適化の実装不具合) が稼働中
4/16 〜 4/20	バグ③(冗長性削減プロンプト) が稼働中
4/20 (v2.1.116)	全バグ修正・完全解決
4/23	postmortem 公開

これを見て自分が一番驚いたのは「3つのバグが別個に走っていた」ことだ。1つのバグなら影響を切り分けやすいが、3つが時間差で重なると「ユーザーごと・タスクごとにバラバラの不調が出る」状態になる。Hacker News で 926 ポイントを集めて議論されたのも納得で、「不調」を再現できないからこそ評価が割れる。

実際に自分も3月後半から「Claude Code が同じツールを連続で叩く」「思考過程が短く感じる」と感じていた。最初は「自分のプロンプトが悪いのかな」と思って 5 時間くらい設定を弄ったが、結論としては自分のプロンプトのせいではなかった。

バグ① 推論努力レベルのデフォルト変更

何が変わったか

Opus 4.6 で「思考時間が長すぎてUI が凍結する」という問題への対処として、推論努力レベル(effortパラメータ)のデフォルトを high から medium に変更した。これは UI レイヤー側の変更で、ユーザーには見えない。

期間は 2026-03-04 〜 2026-04-07、影響モデルは Sonnet 4.6 と Opus 4.6。修正は 4/7 にロールバック（high に戻された）。

ユーザー側で見えた症状

症状: 「Claudeが不十分に思える」
具体例: コーディングタスクで考えが浅い・選択肢を1つしか挙げない

ぶっちゃけ、effort のデフォルト値はユーザーには公開されていない設定なので、これが変わった瞬間に「なんかClaudeが軽い」と感じても原因に辿り着くのは無理だ。透明性のあるバグじゃない。

自分の手元で気づけたか

postmortem を読んで自分の作業ログを git log で振り返ってみると、3月10-15日頃に「もう少し考えてくれ」とプロンプトに追記した跡があった。当時は「自分が悪い」と思って書き足していたが、実は effort=medium がデフォルトだったせいだ。

💡 Tips: 自分のプロンプトに「もう少し考えて」「step by step で」を後から追加した記録があれば、それは内部設定変更を疑うサインかもしれない。

バグ② キャッシュ最適化の実装不具合

これが一番技術的に面白い。

技術的な原因

Claude API には clear_thinking_20251015 というベータヘッダーがあり、コンテキストキャッシュの効率化のため「セッションが1時間以上アイドルだったら、過去の thinking ブロックを削除する」機能が実装されている。

clear_thinking_20251015: keep:1

の組み合わせで、本来は 「直近1ターンの思考だけ残し、古いものを1度だけ削除」 する想定だった。ところが実装バグで、全ターンで反復的に削除が走る 状態になっていた。

つまりキャッシュヒットを最大化するために残しておきたい thinking ブロックが、毎ターンで虐殺されていた。結果としてモデルが「自分が直前にどう考えたか」を忘れる。

症状

- 「Claudeが忘れっぽい」
- 「同じツールを反復的に呼ぶ」  
- 「奇妙なツール選択をする」
- 使用制限(レート/トークン枠)が予想より早く消費される

3つ目の「使用制限が早く消費される」のはキャッシュヒット率が下がっていたからだ。キャッシュミスが増えると入力トークンが本価格で計上されるので、$200プランの Max ユーザーでも「あれ、今月もう80%使ってる」状態になる。

期間は 2026-03-26 〜 2026-04-10、修正は v2.1.101。影響は Sonnet 4.6 と Opus 4.6。

自分の手元で観測できたサイン

このバグは「セッションが1時間以上アイドル」が条件なので、自分の使い方に当てはまる：

朝コーディング → 昼会議 → 夕方再開、というパターン
ターミナルを開きっぱなしで放置するスタイル

実際に 3 月末から 4 月頭にかけて、自分のClaude Code セッションが「続きから始めたら同じ確認質問を繰り返してくる」事象が増えていた。当時は「セッション長すぎたかな」と思って /compact を頻繁に叩いていたが、これも postmortem 後に振り返ると別の原因だった可能性が高い。

💡 Tips: もし /compact を 1 日に 3 回以上叩いている時期があったなら、それは Claude が忘れていたのではなくバグ②の症状だった可能性がある。

バグ③ 冗長性削減用システムプロンプト

これが個人的には一番衝撃だった。

何が起きたか

「Claude が冗長すぎる出力をする」という社内フィードバックを受けて、システムプロンプトに以下の制約を追加した：

テキスト制限:
- ツール呼び出し間のテキスト: 25語以下
- 最終応答: 100語以下

このプロンプト 1 行（実質 2 行）を入れた結果、コーディングベンチマーク評価で 3% の性能低下 が観測された。

期間は 2026-04-16 〜 2026-04-20、修正は 4/20 にリバート。影響は Sonnet 4.6・Opus 4.6・Opus 4.7 にも及んでいた（Opus 4.7 は 4/16 リリースなので、リリース直後から影響を受けていたことになる）。

なぜ性能が下がったのか

postmortem では具体的なメカニズムまでは書かれていないが、自分の理解では以下の連鎖が起きたはずだ：

「テキストは25語以下」という強い制約 → モデルが思考の途中で打ち切る癖がつく
ツール呼び出し間の自己内省が短くなる → 計画の修正タイミングが減る
コーディングタスクは「直前の出力を見て次の手を決める」反復作業 → 内省が短いと判断ミスが連鎖する

つまり、ユーザーへの表示文言を短くしようとしたら、モデル自身の思考プロセスまで短くなってしまった という構図だ。

この事例から学ぶプロンプトの重み

自分でも CLAUDE.md やシステムプロンプトを書くときに「短く」「結論を先に」という指示を入れがちだが、それがコーディング性能を下げる可能性がある ことが Anthropic の社内評価で実証されたわけだ。3% という数字は地味に見えるが、コーディングベンチマークで3%は大きい。

参考までに、自分の CLAUDE.md を見てみたら：

## 応答スタイル
- 結論を先に。挨拶・前置き・進捗の逐一報告は不要
- ツール呼び出し間のテキストは25語以内。最終応答は100語以内を目安に

…という記述があった。postmortemで判明したNG設定とほぼ同じだ。これは見直す必要がある。

⚠️ 注意: 自分の CLAUDE.md やシステムプロンプトに「ツール呼び出し間は X 語以内」「短く」を強く書きすぎていないか確認した方がいい。短くしたいなら「冗長な前置きは不要」程度に留めて、思考の長さは縛らない方が安全。

なぜ検出が遅れたのか

postmortem で印象的なのは「Anthropic の内部評価では再現しなかった」という告白だ。

検出を妨げた要因

3月初旬の初期報告は「通常の変動」と区別がつかなかった
- ベンチマークスコアの揺れは数%出るのが普通で、最初のシグナルは埋もれた
バグ②は「1時間以上アイドル」が条件のレアケース
- 内部で動かしている自動評価セットは連続実行なので、このバグが発火しない
思考表示の別変更がマスキング効果を持っていた
- 内部実験でメッセージキューイング関連の変更が走っていて、症状が薄められた
internal usage と production の乖離
- 内部で使っているClaudeと、ユーザーが本番で叩くClaudeのバージョン・設定が完全に揃っていなかった

3 番目の「マスキング効果」が一番怖い。別の変更が偶然バグを隠していた ということで、これを事前に検出するのはほぼ無理だ。

自分の業務に置き換えると

自分が AIエージェントを業務に組み込むときも、この検出失敗パターンは他人事じゃない。例えば：

A/B テストで指標が動いたとき「季節要因？」「ユーザー層が変わった？」と判断を保留する → 実は実装バグ
内部評価環境と本番環境の差分（モデルバージョン、温度、tools リスト）が放置されている
ある変更が別の変更を隠している

「再現しないバグは存在しないバグ」と扱った瞬間に detection delay が始まる。Anthropic ですらこのトラップにかかっているので、自分の規模だともっと起きやすい。

Anthropicの再発防止策から学べること

postmortem の終盤で、Anthropic は再発防止策を6つ挙げている。これは AI エージェント運用の教科書として読める。

1. スタッフが本番ビルドと同じ Claude を使う

スタッフは production と同じバージョン・設定の Claude を日常業務で使う

dogfooding の徹底だ。自分の場合だと、Claude Code をローカルで使う際にbeta版や experimental flag を有効化していると、逆に「本番ユーザーが見ている景色」と乖離する。いつ何のバージョンを使っているか可視化 することが第一歩。

実際の確認コマンド：

terminal

# Claude Code バージョン確認
claude --version

# 期待: v2.1.116 以降 (postmortem で完全修正されたバージョン)

2. システムプロンプト変更は「モデル別・全評価セット」で実行

全モデル(Sonnet 4.x / Opus 4.x / Opus 4.7) × 全評価セットで回す

バグ③(冗長性削減プロンプト)が見逃されたのは、特定モデル・特定タスクでしか影響が出なかった からだ。回帰テスト的に全パターン実行する仕組みが必要になる。

自分の ~/.claude/CLAUDE.md を変更したときも、最低限「コーディング系・調査系・要約系」の3 種類で動かして体感差を取る方が安全。

3. アブレーション分析（プロンプトの各行の影響を測定）

プロンプトの 1 行を削除/追加して、評価スコアの変化を測る

これは結構ハードルが高いが、CLAUDE.md を 10 行ずつ削除して同じタスクを走らせると、どの行がどれだけ効いているか定量化できる。プロンプトの各行に Pull Request 的な単位を割り当てる発想 だ。

4. 段階的ロールアウト・ソーク期間の導入

一気に全ユーザーに展開せず、段階的に広げて様子を見る

これは Web サービス開発では当たり前のフィーチャーフラグ運用だが、AI モデル/プロンプトの世界でも同じ仕組みが必要、ということだ。プロンプト変更にもカナリアリリースが要る。

5. Code Review ツールの改善

複数リポジトリを文脈として追加して PR レビューする

これは Anthropic 社内ツールの話だが、要するに「コンテキストの不足が品質劣化のキッカケになる」という普遍的な学び。自分の Claude Code 運用でも、関連する ~/.claude/skills/ や別 worktree のファイルを context として渡しているか見直すきっかけになる。

6. プロンプト変更の監査・レビュー強化

プロンプト変更を git で履歴管理し、レビューを義務化する

これは自分でも導入できる：

terminal

# CLAUDE.md と skills/ の変更履歴を継続的に記録
cd ~/.claude
git init
git add CLAUDE.md skills/ scheduled-tasks/
git commit -m "snapshot: claude config 2026-04-29"

プロンプトを「コード」として扱う発想が、本格的に必要なフェーズに入ったと言える。

自分のClaude Code環境を点検する

Step 1: バージョン確認

terminal

# 自分のClaude Codeバージョン
claude --version

# 出力例:
# Claude Code 2.1.86 (Claude Code)

v2.1.116 以降が postmortem で完全修正されたバージョン。それより古ければアップデート必須。

terminal

# アップデート方法 (Mac/Linux)
curl -fsSL https://claude.ai/install.sh | bash

自分の環境は 2.1.86 だったので、まさにこの記事を書きながらアップデートした。

Step 2: CLAUDE.md の冗長性削減指示を見直す

terminal

# 「25語以下」「100語以下」のような強い文字数制約が入っていないか確認
grep -nE "[0-9]+[語字]?以(下|内)|短く|簡潔に" ~/.claude/CLAUDE.md

ヒットしたら、その行を次の形に緩めるか削除する：

- ツール呼び出し間のテキストは25語以内。最終応答は100語以内を目安に
+ 冗長な前置き・進捗の逐一報告は避ける。簡潔さは内容の正確性を上回らない

「短くしたい」気持ちと「思考を縛らない」気持ちの両立が大事。

Step 3: `effort` パラメータの確認

Claude Code v2.1.x 系では /effort コマンドで思考レベルを切り替えられる：

/effort high   # 思考時間多め (Opus推奨)
/effort medium # バランス
/effort low    # 速度重視

複雑なタスクには high を明示的に指定する習慣をつけるといい。デフォルト値が将来また変わる可能性があるので、重要なコーディング作業では明示する 方が安全。

Step 4: キャッシュ動作の体感確認

terminal

# 1時間以上空けてセッション再開した時、Claudeが「直前の議論」を覚えているか確認
# v2.1.116 以降ならOK、古いバージョンだと忘れる

具体的には、複雑なタスクの途中で長めの中断を挟み、再開時に「さっき決めた方針はどうなった？」と聞いてみる。覚えていればキャッシュバグは解消されている。

まとめ

今日からやること

今日 (5分): claude --version で v2.1.116 以降か確認。古ければアップデート
今日 (10分): ~/.claude/CLAUDE.md を grep して「短く」「N語以下」系の強い制約を緩める
今週 (30分): ~/.claude/ を git 管理下に置き、プロンプト変更の履歴を取り始める
今月 (2時間): アブレーション分析の真似事として、CLAUDE.md を半分にしてコーディング体感が変わるか試す

この postmortem から学んだ核心

3つのバグはどれも「良かれと思って入れた最適化」が裏目に出ている。effort=mediumへの変更は UI 凍結を防ぐため、キャッシュ削除はトークン効率化のため、冗長性削減プロンプトは出力簡潔化のため。全部、ユーザーのためだった。それが結果としてユーザー体験を悪化させた。

これは AI を業務に組み込む全エンジニアにとって他人事じゃない。「最適化のつもりが性能を下げる」パターンは、自分のCLAUDE.md にも、自分が書く Hooks にも、Skill の設計にも潜んでいる。

postmortem を読んで「Anthropic でも起きるんだから自分のところでも起きる」と認識を改めるのが、たぶん一番大きな収穫だった。

参考ソース: