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の再発防止策から学べること
- 自分のClaude Code環境を点検する
- まとめ
何が起きていたのかタイムライン
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 を有効化していると、逆に「本番ユーザーが見ている景色」と乖離する。いつ何のバージョンを使っているか可視化 することが第一歩。
実際の確認コマンド：
# 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 で履歴管理し、レビューを義務化する
これは自分でも導入できる：
# 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: バージョン確認
# 自分のClaude Codeバージョン
claude --version
# 出力例:
# Claude Code 2.1.86 (Claude Code)
v2.1.116 以降が postmortem で完全修正されたバージョン。それより古ければアップデート必須。
# アップデート方法 (Mac/Linux)
curl -fsSL https://claude.ai/install.sh | bash
自分の環境は 2.1.86 だったので、まさにこの記事を書きながらアップデートした。
Step 2: CLAUDE.md の冗長性削減指示を見直す
# 「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: キャッシュ動作の体感確認
# 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 でも起きるんだから自分のところでも起きる」と認識を改めるのが、たぶん一番大きな収穫だった。
参考ソース: