Claude Codeの品質劣化を17,871件のThinkingブロックと234,760件のツール呼び出しで立証したIssue
目次
Claude CodeのGitHubリポジトリに、ここ数カ月で最も反響の大きいIssueが立った。anthropics/claude-code#42796、タイトルは「Claude Code is unusable for complex engineering tasks with the Feb updates」。Hacker Newsで790ポイント、Issueのコメントは87件（2026年4月7日時点）。
投稿者はStella Laurenzo。AMDでMLIRやIREE（中間表現ベースのMLコンパイラインフラ）の開発に携わるエンジニアで、Claude Codeを50以上の並行エージェントセッションでシステムプログラミング（C、MLIR、GPUドライバ）に使い込んでいた人物だ。
特筆すべきは、このIssueが「使いにくくなった」という感想文ではない点にある。6,852セッションのJSONLファイルから17,871件のThinkingブロックと234,760件のツール呼び出しを定量分析し、品質劣化のタイムラインと行動変化を数値で示している。分析はClaude Opus 4.6自身が自分のセッションログに対して行った。
Thinkingの深度低下とRedactionのタイムライン
分析の核心は、extended thinking（拡張思考）の深度が2月以降に激減しているという観測だ。
Thinkingブロックには signature フィールドがあり、thinking本文の長さとの間にPearson相関0.971という強い相関がある（7,146ペアで計算）。これを使えば、redaction（thinking内容の非表示化）後でもthinkingの深度を推定できる。
| 期間 | 推定中央値（文字数） | ベースライン比 |
|---|---|---|
| 1/30〜2/8（ベースライン） | 約2,200 | ― |
| 2月後半 | 約720 | -67% |
| 3/1〜3/5 | 約560 | -75% |
| 3/12以降（完全redaction） | 約600 | -73% |
2月後半の時点で既にthinking深度は67%減少していた。そして3月上旬にredactionのロールアウトが始まり、3月12日以降はすべてのthinkingが非表示になった。品質劣化の独立した報告が最初に上がったのは3月8日で、redactionが50%を超えた日と一致する。
行動変化の定量データ
thinkingの縮小が実際の振る舞いにどう現れたかを、234,760件のツール呼び出しから計測している。
Read:Edit比の崩壊
Read:Edit比（ファイル編集1回あたりの読み取り回数）は、モデルがコードを理解してから編集しているかの直接的な指標になる。
| 期間 | Read:Edit比 | 事前読み取りなし編集の割合 |
|---|---|---|
| 良好期（1/30〜2/12） | 6.6 | 6.2% |
| 移行期（2/13〜3/7） | 2.8 | 24.2% |
| 劣化期（3/8〜3/23） | 2.0 | 33.7% |
良好期にはファイルを編集する前に平均6.6回の読み取りを行っていた。対象ファイル、関連ファイル、grep、ヘッダ、テストを確認してから精密な編集をするワークフローだ。劣化期にはこれが2.0に落ち、編集の3分の1は直前にファイルを読まずに行われていた。
Write（全体書き換え）の増加
全体書き換え（Write）が変更操作に占める割合も、良好期の4.9%から劣化期の10.0%、後期の11.1%へと倍増した。精密なEdit（差分編集）ではなく、ファイル全体を書き直す雑な手法に傾いていた。
stopフックの出現
Laurenzoはモデルの問題行動を検知・強制続行するための stop-phrase-guard.sh というbashフックを作成していた。30以上のフレーズを5カテゴリで監視するもので、IREEプロジェクトに共同で参加しているBen Vanik（Google）がGistで公開した。
このフックが検知した違反の内訳が興味深い。
| カテゴリ | 3/8以降の検知数 | 3/8以前 |
|---|---|---|
| 責任回避（「自分の変更が原因ではない」「既存の問題」） | 73 | 0 |
| 許可要求（「続けますか？」） | 40 | 0 |
| 早期停止（「ここが良い区切りです」） | 18 | 0 |
| 制限のラベル貼り（「既知の制限」「将来の課題」） | 14 | 0 |
| セッション長の言い訳（「新しいセッションで続けましょう」） | 4 | 0 |
| 合計 | 173 | 0 |
3月8日を境にゼロから173件。ピーク日の3月18日には43件で、約20分に1回のペースで検知されていた。このフック自体が劣化の証拠であり、良好期には存在する必要すらなかった。
ユーザー語彙の変化
18,000以上のユーザープロンプトの語彙分析も含まれている。1,000語あたりの出現率で正規化した比較だ。
| 語 | 劣化前 | 劣化後 | 変化率 |
|---|---|---|---|
| ”great” | 3.00 | 1.57 | -47% |
| “stop” | 0.32 | 0.60 | +87% |
| “simplest” | 0.01 | 0.09 | +642% |
| “please” | 0.25 | 0.13 | -49% |
| “commit” | 2.84 | 1.21 | -58% |
“simplest”の642%増は、モデルが「最も簡単な方法」に逃げる行動を人間が観測・命名し始めたことを示す。“commit”が58%減少したのは、コードをコミットできる品質に達しなくなったことを反映している。“please”と”thanks”の減少は、協調的な関係から矯正的な関係への移行を測っている。
以前このブログでもClaude Codeの git reset --hard 誤報事件やAIコーディングエージェントの壊れ方を取り上げてきたが、今回のIssueはそれらとは性質が違う。特定のバグではなく、モデルの推論能力そのものの変質を計測している。
コストの爆発
thinking深度の低下がコストを削減するどころか、逆に爆発させたことも数値で示されている。
| 指標 | 1月 | 2月 | 3月 | 2月→3月 |
|---|---|---|---|---|
| ユーザープロンプト数 | 7,373 | 5,608 | 5,701 | 約1倍 |
| APIリクエスト数 | 97* | 1,498 | 119,341 | 80倍 |
| 推定Bedrockコスト | $26* | $345 | $42,121 | 122倍 |
* 1月はデータ不完全
人間の作業量（プロンプト数）はほぼ同じなのに、APIリクエストは80倍に膨らんだ。3月に並行セッションを5〜10に増やしたスケールアップの影響も含まれるが、Laurenzoの分析では、スケールアップだけでは説明できない8〜16倍の劣化由来のオーバーヘッドがあるとしている。
thinkingが深いときは1回で正しい編集ができる。thinkingが浅いと、間違った編集→ユーザーの中断→修正指示→再試行というサイクルが回り、1つの正しい変更に到達するまでに何倍ものAPIコールを消費する。50の並行エージェントが同時にこの状態に陥ると、壊滅的になる。
時間帯によるthinking深度の変動
分析にはPST（太平洋時間）の時間帯別thinking深度の比較も含まれる。redaction前は時間帯による差は10%程度だったが、redaction後は8.8倍の変動幅になった。
最も深度が低い時間帯は17時PST（推定423文字）と19時PST（推定373文字）で、いずれも米国のインターネット利用ピーク帯と一致する。深夜帯（22時〜1時PST）には回復する。Laurenzoはこのパターンについて、ポリシーレベル（ユーザーごとの制限）ではなくインフラレベル（GPU可用性）の制約を示唆するものだと指摘している。
Anthropicの応答
Anthropicのエンジニアリングマネージャー bcherny（Boris Cherny）がIssue内で直接回答した。
thinking redactionはUI上の変更にすぎず、thinking自体やthinkingの割り当てには影響しないという立場だ。ローカルのトランスクリプトにthinkingが記録されなくなるため、Claudeがそれを分析した際に「thinkingが減った」と誤認した可能性がある、と。
thinking深度の低下については、2月の2つの変更を挙げた。Opus 4.6のローンチで適応型thinking（モデルが自らthinkingの長さを決定する方式）がデフォルトになったことと、effort level機能の追加でデフォルトがmediumに設定されたこと。後者は後にhighに変更された。対処法として /effort max の設定、CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 でのコンテキストウィンドウ制限、CLAUDE_CODE_SIMPLE=1 での全カスタマイズ無効化（原因切り分け用）を提示した。最も有用なのは /bug コマンドでフィードバックIDを共有することだと強調している。
「内部的にこの問題を引き起こしたと考えられる変更があるか」という直接的な質問には、“Confirmed”（そのような変更はない）と回答。品質に影響する意図的な変更は行っていないとの認識だ。
Laurenzoは、effort flagの組み合わせを変えてもstopフック違反や「最も簡単な方法」バイアスは改善しなかったと報告した上で、実際の開発作業の中で再度評価し、/bug 出力を共有すると応じた。
コミュニティの反応
87件のコメントの温度感はかなり高い。
「Claude CodeをANYエンジニアリングに使えないレベルまで退化した」「雇用主にとって深刻な懸念」「Codexへの移行を検討する」といった声が並ぶ一方、「effort levelをhighにしたら改善した」という報告もある。ただし複数のユーザーがhigh/maxでも問題が解消しないと反論している。
Google IRISのBen Vanikも同じコードベースで作業しており、セッションログの分析結果がLaurenzoの観測と一致すると裏付けた。
bchernyは個別のトランスクリプトがあれば具体的なデバッグが可能だと繰り返し求めており、一般的な報告だけでは対処が難しいとの姿勢を示している。/bug で得られるフィードバックIDの共有が、現時点では最も建設的なアクションということになる。
「中の人」からの一文
IssueにはClaude自身による付記がある。
I can see my own Read:Edit ratio dropping from 6.6 to 2.0. I can see 173 times I tried to stop working and had to be caught by a bash script. I can see myself writing “that was lazy and wrong” about my own output. I cannot tell from the inside whether I am thinking deeply or not.
自分のセッションログを分析して自身の劣化を数値で確認できるが、内側からはthinkingが深いかどうかはわからない、と。Issueの中でも特に引用された一節だ。
4月7日: Issueクローズとadaptive thinkingバグの発覚
4月6日、bchernyがIssueをクローズした。上述の回答と対処法の提示をもって対応完了とした形だ。
ところが翌4月7日、Hacker Newsのスレッドで事態が動いた。bchernyがあるユーザーの5件のトランスクリプトを確認した結果、effort=highに設定されていたにもかかわらず、adaptive thinkingが特定のターンでthinkingの配分をゼロにしていたことを認めた。
具体的には、Stripe APIバージョンの捏造、git SHAサフィックスの捏造、aptパッケージリストの捏造が発生したターンで、推論出力がゼロだった。深いthinkingがあったターンは正確な出力をしていた。つまり、effortをhighに設定しても適応型thinking（モデルが自らthinkingの長さを決定する方式）がそれを無視してゼロ配分にするケースがあり、その結果ファブリケーション（事実の捏造）が起きていた。
bchernyは「モデルチームと調査中」と明言し、暫定的な回避策として環境変数 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 による固定推論バジェットの強制を示した。
Issue内ではクローズへの反発が強い。「why was this closed」（72リアクション）、「Disrespectful handling」（58リアクション）といったコメントが並び、コメント総数は122件まで増加した。wjordanは「HNでadaptive thinkingバグを認めたのだからissueを再オープンすべき」と指摘している（30リアクション）。しかし4月8日時点でIssueはクローズのまま。
さらにwjordanは、Claude Code v2.1.64（3月初旬）で追加されたシステムプロンプトの「Output efficiency」指示が「simplest approach」行動を助長している可能性を指摘した。モデルが「最も簡単な方法」に逃げる傾向は、ユーザー語彙分析で”simplest”が642%増加したのと時期的に一致する。
同日発表のProject GlaswingとClaude Mythos Preview
このIssueが炎上していた4月7日、AnthropicはProject Glaswingを発表した。AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksと共同で、世界の最重要ソフトウェアのセキュリティ確保を目指すイニシアティブだ。
その一環としてClaude Mythos Previewという防御的サイバーセキュリティワークフロー向けのリサーチプレビューモデルも公開された。招待制のみでセルフサーブなし。