7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Code、ここ2〜3日の不調を調べてみた

7
Last updated at Posted at 2026-04-05

Claude Code、ここ2〜3日の不調を調べてみた

ここ数日、Claude Code を使っていて「なんか遅いし、前より雑になってない?」と感じている方、たぶん自分だけじゃないと思います。

実際どうなのか気になったので、Anthropic のステータスページや GitHub Issues を見て調べてみました。今の状況でどう使えば安定するかもまとめています。


結論

調べた結果、体感の悪化は気のせいではなさそうです。

以下の3つが同時に起きています。

  1. Anthropic 側で障害・エラー率上昇が発生していた
  2. Claude Code の更新に伴う不具合報告が増えていた
  3. 長セッション・1M context・MCP など重い使い方で劣化しやすい

サービス側の不安定さと、重めの運用が重なった結果、ここ数日は特にしんどかった、という状況です。


Anthropic 側で何が起きていたか

ステータスページを見ると、直近で以下の incident があります。

  • 2026年4月3日: Sonnet 4.6 でエラー増加
  • 2026年4月4日: Sonnet 4.6 / Opus 4.6 で広範なエラー率上昇

体感が悪化した時期とそのまま重なります。参考: Anthropic Status

ただ、それだけでもありません。


GitHub Issues の報告もかなり具体的

GitHub の anthropics/claude-code Issues を見ると、最近は具体的な報告がかなり集まっています。

1. レイテンシが異常に高い

「最初のトークンが返るまで 15 秒以上かかる」といった報告があります。
単に重いタスクというわけではなく、前より明らかに初動が遅いという内容です。

2. 使用量の消費が早い

特に 3月下旬〜4月初旬にかけて、
「以前はこんなに減らなかったのに、急に制限に到達するようになった」
という声が増えています。

3. 長いセッションで文脈が静かに壊れる

これがかなり厄介で、最近の Issue では silent context degradation という報告が出ています。
見かけ上はセッションが続いていても、内部では古い tool result などが落ちていて、
ユーザーからは「急に話が通じなくなった」ように見えるという現象です。

「遅い」だけでなく「前提を落とす」「急に雑になる」「深い作業で弱くなる」という違和感は、これでかなり説明がつきます。

4. resume や更新まわりの回帰

更新後に挙動がおかしくなった、resume が壊れた、複数インストールが競合した、といった報告もあります。
最近の不満は印象論だけでなく、CLI の更新やセッション管理の問題として具体的に上がっています


「賢さまで落ちた気がする」の正体

ここは少し掘り下げます。

LLM 系ツールは遅いだけでも不満が出ますが、今回の不満は速度だけの話ではありません。
実際には以下が混ざっています。

  • 応答が遅い
  • 無駄に考えすぎる
  • 前提を落とす
  • 途中から雑になる
  • さっきまで分かっていたコードベースの理解が崩れる

これを全部まとめて「性能悪化」と感じている方が多いのではないでしょうか。

Claude Code の公式 Best Practices でも、コンテキストが膨らむほど性能が落ちることは明記されています。
長い会話や情報の積み増しに対して無限に強いわけではないということです。

最近は 1M context、subagents、MCP、thinking、computer use など便利だけど重い機能が増えています。
できることが増えた反面、雑に使うと崩れやすくもなったということだと思います。

ただ、これは「Claude Code が終わった」という話ではなく、運用を変える必要があるフェーズに入ったということです。


今どう使えば安定するか

ここからが本題です。現実的な対処をまとめます。

1. 長いセッションをやめる

これがいちばん効きます。

以前は1本の長い会話で要件整理から実装まで全部やれていましたが、今はリスクが高いです。

長いセッションでは、

  • 文脈が膨らむ
  • 無駄な履歴が残る
  • 古い前提が混ざる
  • silent degradation の影響を受けやすい

という問題が出やすくなります。

作業ごとに会話を切る方が安定します。

  • セッションA: 要件整理
  • セッションB: 調査
  • セッションC: 実装
  • セッションD: 難所だけ深掘り

区切りのタイミングで /clear を打てば、コンテキストがリセットされます。
前のセッションを再開したい場合は claude --resume でセッション一覧から選べます。

1本で全部やらせるより、短く分けた方が結果的に早いです。

2. 普段は Sonnet、詰まった時だけ Opus

Opus は強いですが、重いです。
直近の incident でも Opus 4.6 は揺れていました。

常用は Sonnet にして、設計比較や本当に難しいバグだけ Opus に切り替える方が、速度・コスト・安定性のバランスが良いです。

モデル切り替えは会話中に /model で可能です。

/model sonnet   # Sonnet に切り替え
/model opus     # Opus に切り替え
/model haiku    # Haiku に切り替え(軽い作業向き)

起動時に指定する場合は claude --model sonnet です。

3. effort を常時 high にしない

thinking や high effort は刺さる場面もありますが、常時使うと遅くなりやすく消費も増えます。

切り替えは /effort コマンドで行います。

/effort low      # 単純修正・検索向き
/effort medium   # 通常実装(デフォルト)
/effort high     # 仕様整理・設計比較
/effort max      # Opus 4.6 限定、そのセッションのみ有効
/effort auto     # デフォルトに戻す

起動時に claude --effort high でも指定できます。

おすすめの使い分けはこんな感じです。

  • 仕様整理・設計比較: high
  • 通常実装: medium
  • 単純修正・検索: low

なお、プロンプトに「もっと考えて」と書いても thinking トークンは増えません。一時的に深く考えさせたい場合はプロンプトに ultrathink と含めると、セッション設定を変えずに1回だけ high effort で動きます(Opus 4.6 / Sonnet 4.6 で利用可能)。

4. 調査と実装を分離する

Claude Code は調査と実装を混ぜると散らかりやすいです。

たとえば、

  • 「このコードベースを把握して」
  • 「影響範囲を洗って」
  • 「じゃあ修正して」
  • 「ついでにテストも見て」
  • 「あ、別件のログも読んで」

こういう流れは会話としては自然ですが、最近は崩れやすくなっています。

探索は探索で終わらせて、実装は別会話にする。 これだけでかなり安定します。

5. MCP を盛りすぎない

MCP は便利ですが、常時いろいろつなぐと当然重くなります。
changelog や実践知を見ても、MCP 接続や起動時 fetch まわりは性能に影響しやすいです。

本当に今必要なものだけつなぎましょう。
Slack、GitHub、Notion、ブラウザ、ファイル系を全部常時有効にしている場合は見直した方がいいかもしれません。

接続中の MCP サーバーは /mcp で確認できます。不要なものはプロジェクトの .mcp.json~/.claude.json から削除すれば外れます。

6. 1M context を過信しない

1M context は魅力的ですが、長大文脈だから安心とは言い切れません。

大きいコンテキストは万能ではなく、むしろ長い作業の劣化を見えにくくすることもあります。
必要な情報だけを短く持ち込む方が安定しやすいです。

7. /clear, /compact, /resume を使いこなす

地味ですが大事です。

コマンド 用途 使いどころ
/clear コンテキストを全リセット 別の話題に入るとき
/compact 会話を要約して圧縮 セッションが重くなってきたとき
/compact APIの変更だけ残して 指示付きで圧縮 特定の情報だけ残したいとき
claude --resume 過去のセッションを再開 前の作業を続けたいとき
claude --continue 直前のセッションを再開 さっきの続きをやりたいとき

惰性で会話を延命するとだんだん質が落ちます。最近は特にそう感じます。

8. CLAUDE.md を整備する

CLAUDE.md はセッション開始時に毎回読み込まれるファイルで、コードスタイルやビルドコマンドなどを書いておくと Claude の精度が上がります。

まだ作っていない場合は /init で自動生成できます。

/init    # プロジェクト構造を分析して CLAUDE.md を自動生成

ただし、CLAUDE.md が長すぎると逆効果です。コンテキストを圧迫して、肝心な指示が埋もれます。公式ドキュメントでも 200 行以内が推奨されています。

現在読み込まれている CLAUDE.md を確認するには /memory コマンドが使えます。

/memory   # ロードされている CLAUDE.md ファイルの一覧を表示

CLAUDE.md 専用のバリデーションコマンドは今のところありません。ただし /doctor を使えば、設定ファイル全般(settings.json の書式エラー、MCP 設定、CLAUDE.md のサイズ警告など)をまとめてチェックできます。

/doctor   # インストール状態・設定・MCP・コンテキスト使用量などを診断

CLAUDE.md を書くときのポイント:

  • Claude が自力で推測できることは書かない(言語の一般的な慣習など)
  • Claude に間違えてほしくないことだけ書く(ビルドコマンド、テストの流し方、命名規則など)
  • 長くなりすぎたら定期的に削る

9. /simplify で最後にチェックする

実装が終わったら、コミット前に /simplify を実行するのがおすすめです。

/simplify

このコマンドは、直近の変更ファイルに対して以下の3つの観点でレビューし、問題があればそのまま修正してくれます。

  • コード再利用: 重複や共通化できる箇所がないか
  • 品質: バグやアンチパターンがないか
  • 効率: 無駄な処理や改善できる箇所がないか

特定の観点に絞りたい場合は引数を付けられます。

/simplify メモリ効率に注目して
/simplify エラーハンドリングを見て

不安定な時期ほど Claude が雑なコードを書きやすいので、コミット前のワンクッションとして入れておくと事故が減ります。


注意: どこまで言い切れるか

一応、記事としての線引きも整理しておきます。

言えること

  • ここ数日で体感悪化を感じた人は多そう
  • 公式 incident と時期が重なっている
  • GitHub Issues でも不具合報告が集中している
  • 長セッション運用は今かなりリスクが高い
  • 運用を変えるとだいぶマシになる

断定できないこと

  • 「原因はこれで確定」
  • 「Anthropic が改悪した」
  • 「意図的に品質を落としている」
  • 「必ずこの設定で直る」

状況証拠はかなり揃っていますが、単一原因を断定できるほどの公開情報はありません


自分が今やっている運用

しばらくは以下のような運用で使っていくつもりです。

  1. 普段は Sonnet
  2. Opus は設計比較か難所だけ
  3. high effort は常用しない
  4. 1タスク1会話を徹底する
  5. 探索と実装を分ける
  6. 使わない MCP は切る
  7. 会話が重くなったらすぐ切る

**Claude Code をうまく使うコツは「全部やらせること」ではなく「壊れる前に区切ること」**になってきていると思います。

できることは増えましたが、そのぶん丁寧に使い分ける必要が出てきた感じです。


おわりに

正直、ここ数日は結構イラっとする場面が多かったです。
ただ、それでも Claude Code には助けられている場面が多いのも事実です。

便利だからこそ安定してほしいし、今後も使い続けたいツールなので、早めに落ち着いてくれるといいなと思っています。


参考にした情報源

  • Anthropic Status
  • Claude Code official docs:
    • Best Practices
    • Subagents
    • Settings / Environment variables
    • Release Notes
    • Troubleshooting
  • GitHub Issues (anthropics/claude-code)
    • latency increase
    • max plan exhaustion
    • silent context degradation
    • update / resume regressions

参考リンク

7
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?