「さっきまで快適だったのに、急に Claude Code が遅い」「コマンドを叩いても繋がらない」「なんだか以前より頭が悪くなった気がする」。実務で毎日使っていると、こうした体感の変化に必ず一度はぶつかります。やっかいなのは、原因が 1 つではなく、サーバー側の障害・自分の環境・セッションの状態・指示の質という複数のレイヤーにまたがっている点です。
闇雲にアプリを再起動しても、原因が別のレイヤーにあれば改善しません。この記事では、FIXIT が複数プロジェクトで Claude Code を日常運用する中で固まってきた切り分けの順番を、上流から順にたどれる形でまとめます。まずは「自分のせいなのか、サーバーのせいなのか」を 1 分で判断するところから始めます。
まず確認 — 障害なのか環境なのかの切り分け
トラブルに気づいたら、最初にやるべきは細かい設定いじりではなく、問題が自分の手元にあるのか外側にあるのかの大まかな仕分けです。判断材料は次の 3 つを順に見るだけで十分です。
ひとつ目は再現性。同じ操作を 2〜3 回繰り返して、毎回同じ症状が出るのか、ときどき直るのかを見ます。間欠的に直る場合はネットワークやサーバー側の負荷変動が疑わしく、毎回同じ場所で必ず止まる場合は手元の設定・特定のツール・特定のファイルが原因の可能性が高くなります。
ふたつ目はスコープ。症状が出るのは特定のプロジェクトだけなのか、別ディレクトリで新規セッションを開いても同じなのかを確認します。新規セッションでは快適なら、原因はそのプロジェクト固有の設定やコンテキストにあります。どこで開いても遅いなら、より上流のアカウント・ネットワーク・サーバー側を疑います。
みっつ目は時間軸。「昨日まで普通だった」のか「ここ数時間だけ」なのか。直近で変わったこと、つまり自分が設定を変えた・MCP を追加した・アップデートが入った、あるいは公式側のメンテナンスや障害があったかを思い出します。
この 3 点で当たりをつけると、以降のチェックを無駄なく進められます。間欠的でスコープが広く、自分は何も変えていないなら、後述の公式ステータス確認を真っ先に見るべきです。逆に特定プロジェクトでだけ毎回遅いなら、コンテキストや MCP の問題に絞り込めます。
繋がらない・タイムアウトするときのチェックリスト
「繋がらない」は症状としては一括りでも、原因は認証・ネットワーク・プロキシ・サーバー側のいずれかにほぼ収れんします。上から順に潰していくのが速いです。
最初に疑うのは認証の期限切れです。ログインセッションは永続ではないので、しばらく放置したマシンや、久しぶりに開いた環境では再ログインが必要になることがあります。401 や認証関連のエラー文言が出ているなら、一度ログアウトして再ログインするだけで直るケースが多数です。
次にネットワーク経路です。社内ネットワークや VPN 配下では、プロキシやファイアウォールが API への通信をブロックしていることがあります。ブラウザでは普通に Web が見えていても、CLI からの API 通信だけが弾かれている状況は珍しくありません。HTTP_PROXY / HTTPS_PROXY といった環境変数が意図通り設定されているか、VPN を一時的に切ると繋がるか、テザリングなど別回線で試すと繋がるかを確認すると、ネットワークが原因かどうかを一発で切り分けられます。
タイムアウトが頻発する場合は、1 回のリクエストで大きすぎる処理をさせていないかを疑います。巨大なファイル全体を読ませる、数十ファイルを一気に編集させるといった重い指示は、応答が返る前に切れることがあります。指示を分割し、対象ファイルを絞るだけで安定することが多いです。
これらを潰しても直らず、かつ別マシンや別回線でも同じなら、手元ではなくサーバー側の問題と判断して切り分けを上流へ移します。なお、初回セットアップ段階で繋がらない場合は環境構築自体に抜けがあることが多いので、Claude Code のセットアップ手順を一度なぞって認証とパスの通り方を確認するのが近道です。
応答が遅いときに効く設定とコンテキスト整理
繋がってはいるが遅い、という場合に体感を最も左右するのが「いま会話に積み上がっているコンテキストの量」です。長時間まわしたセッションは、過去のやり取り・読み込んだファイル・ツールの実行結果がどんどん蓄積し、毎ターン処理するトークンが膨らみます。これが応答の遅さと、後述する「劣化」の感覚の最大の原因です。
手早く効く対処は、会話履歴をリセットして要点だけを引き継ぐことです。タスクの区切りで一度クリアし、必要な前提を短くまとめて新しいセッションに渡すと、応答速度がはっきり戻ります。長い 1 セッションを引っ張るより、論理的なタスク単位でセッションを切る運用に切り替えるのが根本対策になります。
読み込ませるファイルの粒度も効きます。「このディレクトリを全部見て」と丸投げするより、関係するファイルや関数を名指しで指定するほうが、無駄な読み込みが減って速くなります。巨大なログやビルド成果物、node_modules のようなディレクトリを誤って探索対象に含めていないかも見直す価値があります。
設定面では、タスクの重さに対して過剰な思考量を要求していないかを確認します。単純な置換や定型作業にまで高い effort を割り当てると、毎回じっくり考え込んで遅くなります。重い設計判断には厚く、機械的な作業には軽く、とメリハリをつけるだけで全体のテンポが変わります。effort や Fast mode の使い分けはOpus 4.8 を使いこなす要点で具体的に整理しているので、速度と品質のバランスを詰めたいときに合わせて参照してください。
「劣化した」と感じる原因 — モデル・effort・指示の質
「最近 Claude Code が劣化した」という体感は、実際にはモデルそのものが劣化しているケースより、運用側の条件が変わっていることのほうが圧倒的に多いです。原因を分解すると、だいたい次のどれかに当てはまります。
ひとつは、先ほどのコンテキスト肥大です。会話が長くなると、本当に大事な指示が大量の過去ログに埋もれ、AI が古い文脈や無関係な情報に引っ張られて精度が落ちます。「同じことを頼んでいるのに最近ズレた答えが返る」と感じたら、まずセッションが長くなりすぎていないかを疑ってください。新しいセッションで同じ依頼をして改善するなら、原因はモデルではなくコンテキストです。
ふたつ目は、思考量の設定です。軽い設定のまま難しい設計判断を任せると、当然ながら浅い答えになりがちです。逆も同じで、設定を変えたことを忘れて「劣化した」と感じている場合があります。直近で effort やモデルの選択を変えていないかを振り返るとよいです。
みっつ目、そして最も見落とされがちなのが指示の質です。長く使っていると依頼がだんだん雑になり、「いい感じにして」「さっきの続き」のような曖昧な指示が増えます。前提・制約・期待する出力形式が欠けた指示は、誰が書いても結果がブレます。具体的なゴール、触ってよい範囲、守るべきルールを明示し直すだけで、体感品質はかなり戻ります。プロジェクト共通の前提は CLAUDE.md に書いておくと毎回伝え直す必要がなくなり、品質が安定します。
切り分けの順番としては、まず新規セッションで再現するかを見て、しなければコンテキスト要因、するなら設定か指示の質を疑う、という流れが効率的です。
MCP / hooks が原因で重くなるケースと切り分け
MCP サーバーや hooks を組み込むと実務は大きく加速しますが、これらは速度・安定性のトラブル源になりやすいポイントでもあります。「特定のプロジェクトでだけ起動が遅い」「ツール一覧の読み込みで待たされる」「ときどき固まる」といった症状が出たら、まずここを疑います。
MCP は接続しているサーバーの数とレスポンスに引きずられます。応答の遅い、あるいは落ちている外部サーバーが 1 つ混じっているだけで、初期化や一覧取得で待たされて全体が重く感じます。切り分けは単純で、設定から MCP を一時的に全部外して起動してみることです。これで快適に戻るなら、原因は MCP 側で確定します。あとは 1 つずつ戻して、どのサーバーが犯人かを特定します。普段使わない接続先は思い切って外しておくのが、安定運用の素直な手です。
hooks は、各処理の前後で自動実行されるスクリプトです。ここに重い lint やテスト、ビルドを仕込んでいると、操作のたびに待ち時間が発生します。「編集するたびに引っかかる感じがする」なら、発火している hook が重い処理をしていないか、対象範囲が広すぎないかを見直します。hook が異常終了して処理を止めているパターンもあるので、エラー出力に hook 名が出ていないかも確認します。
MCP と hooks のどちらが原因かは、片方ずつ無効化して再現を見るのが結局いちばん速い切り分けです。設定や具体的な組み方を詰めたいときはClaude Code に MCP をつなぐ実務パターンも合わせて参照すると、どこを軽くすべきかの判断がつけやすくなります。
公式の障害情報・ステータスの確認先
ここまでの切り分けで「手元には問題がない」と判断できたら、サーバー側の障害を確認します。自分でいくら設定をいじっても、サービス側が落ちていれば直りようがないので、早めにここへ立ち戻れるかどうかが時間の使い方を分けます。
最優先で見るのは公式のステータスページです。Anthropic はサービスの稼働状況やインシデント、メンテナンス予定を公開しており、API やコンソールに障害があるときはここに反映されます。応答エラーやタイムアウトが広く出ている時間帯は、まずステータスを開いて進行中のインシデントがないかを確認するのが鉄則です。インシデントが立っていれば、こちらにできることは復旧を待つことだけだと割り切れます。
公式リリースノートやアップデート情報も確認先として有効です。「昨日まで動いていた挙動が変わった」ときは、障害ではなくバージョンアップに伴う仕様変更ということがあります。CLI のバージョンを最新に上げる、あるいは既知の不具合が報告されていないかを見ると、原因の見当がつきます。
判断の順序を整理すると、症状が広範囲かつ間欠的でステータスにインシデントがある場合はサーバー側起因と確定し、待つ。ステータスは正常なのに自分だけ症状が出る場合は、手元の環境・コンテキスト・設定に戻って切り分けを続ける。この分岐をはっきり持っておくと、復旧待ちでよい場面で延々と設定をいじり続ける、という時間の浪費を避けられます。
再発を防ぐ運用の工夫 (CLAUDE.md・セッション分割)
トラブルが起きるたびに切り分けをやり直すのは消耗します。FIXIT で実務に組み込んでいる、再発そのものを減らす運用の工夫を 2 つ紹介します。
ひとつはセッションを意識的に区切ることです。前述のとおり、遅さと劣化感の多くはコンテキスト肥大が原因なので、1 つのセッションを延々と引っ張らず、機能単位やタスク単位で区切るのを習慣にします。タスクが一段落したら、現状と次にやることを数行でメモに残してから新しいセッションを開く。この「引き継ぎメモ」の運用が定着すると、長セッション起因のトラブルはほとんど起きなくなります。
もうひとつは CLAUDE.md の整備です。プロジェクトの前提・コマンド・守るべきルールをここにまとめておけば、毎回のセッションで AI が同じ文脈を共有でき、指示の質が安定して品質のブレが減ります。ただし書きすぎると読み込みトークンが増えて逆に遅くなるので、要点に絞り、詳細は別ドキュメントへ切り出すのがコツです。
予防的なメンテナンスとしては、使わなくなった MCP 接続や重い hooks を定期的に棚卸しすることも効きます。「とりあえず入れたまま」の設定が積み重なると、起動の遅さや不安定さの温床になります。月に一度、設定を見直して不要なものを落とすだけで、体感の快適さは長く保てます。
まとめ
Claude Code の「遅い・繋がらない・劣化した」は、まず自分の手元かサーバー側かを切り分け、繋がらない系は認証とネットワークから、遅さと劣化感はコンテキスト肥大から疑うのが基本の流れです。手元に問題がなければ公式ステータスを確認して復旧を待つ。そして、セッションの区切りと CLAUDE.md の整備で再発を抑える。この順番を持っておけば、多くのトラブルは数分で原因の見当がつきます。
よくある質問 (FAQ)
Q. Claude Code が急に遅くなったとき、まず何をすればいいですか?
A. 一度新しいセッションを開いて同じ作業を試してください。それで速くなるなら、長時間まわしたセッションにコンテキストが溜まりすぎたことが原因です。タスクの区切りで会話をリセットし、必要な前提だけを短くまとめて引き継ぐ運用に切り替えると安定します。どの環境でも同じように遅い場合は、手元ではなくサーバー側やネットワークの可能性が高いので、公式のステータスページを確認してください。
Q. 「繋がらない」エラーが出ます。どこから疑えばいいですか?
A. 認証、ネットワーク、サーバー側の順に見るのが効率的です。まずログインセッションの期限切れを疑って再ログインを試し、次に VPN やプロキシが API 通信を弾いていないかを別回線などで確認します。それでも繋がらず、別マシンでも同じ症状なら手元の問題ではないと判断し、公式ステータスでインシデントが起きていないかを確認してください。
Q. モデルが「劣化した」と感じます。本当に性能が落ちたのでしょうか?
A. 多くは運用側の条件変化が原因です。会話が長くなって大事な指示が過去ログに埋もれている、思考量の設定を変えたことを忘れている、依頼が曖昧になっている、のいずれかであることがほとんどです。新しいセッションで具体的な指示を出し直すと改善することが多いので、まずそれを試してください。プロジェクト共通の前提を CLAUDE.md に書いておくと、指示の質が安定して劣化感を抑えられます。
このあたりの切り分けに毎回時間を取られていたり、AI 駆動開発をチームの標準運用として安定させたいときは、FIXIT が実プロジェクトで使っている進め方をそのまま相談できます。導入や運用設計の相談は お問い合わせ からどうぞ。