Claude が応答しない・遅い・途中で止まるときの切り分けと対処

アプリのストア掲載文を十数言語ぶん翻訳していた夕方、Claude の返答がぴたりと止まりました。カーソルは点滅したまま、エラーも出ません。私は「混んでいるのだろう」と決めつけて十五分ほど待ち——結局、原因は自分の側で開きっぱなしにしていた古いタブのセッション切れでした。

待った時間より、原因を見に行かなかったことのほうが悔しかったのを覚えています。あの十五分は、切り分けの順番さえ決めていれば一分で済んだのかもしれません。それ以来、止まったときは「どこが止まったのか」を先に決めてから手を動かすようにしております。

ここからは、その切り分けの順番を、私の運用で実際に効いた順に書き残します。ブラウザで使う方も、Claude Code や API を無人で回している方も、同じ順番で辿れるはずです。

応答しないとき、最初に見る三つの場所

止まった瞬間にいちばんやりがちなのは、同じプロンプトを何度も送り直すことです。これは切り分けの情報を増やさないうえ、後述するレート制限を自分で引き寄せてしまいます。

見る場所は三つに絞れます。サービス側、ブラウザ側、そしてアカウント側です。

サービス側 — まず公式ステータスを一度だけ確認する

Anthropic の公式ステータスページを開き、障害やメンテナンスの表示がないかを見ます。ここに黄色や赤の表示があれば、手元でできることはほぼありません。

私は、別のブラウザや端末から同じ症状が出るかを一度だけ試して、出るなら待つ、と決めています。復旧を待つあいだに別の作業へ移れるかどうかで、その日の疲れ方がまるで違うのです。

ブラウザ側 — 古いタブとセッションを疑う

冒頭の私の失敗がこれでした。長く開いたままのタブは、セッションが切れていても画面はそのままに見えます。

キャッシュとクッキーの削除は効く場面もありますが、私は最後に回しています。他のサイトのログインまで巻き込むわりに、切り分けとして得られる情報が少ないからです。

アカウント側 — ログイン状態とプランの状態

ログアウトして入り直すこと、そしてアカウント設定でプランや支払いの状態に警告が出ていないかを見ること。この二つで、アカウント起因の停止はほぼ判別できます。

サービス側でもブラウザ側でもアカウント側でもない、という結論になったときだけ、次の「遅い」の切り分けへ進みます。

遅いときに、順に確かめること

「応答しない」と「遅い」は、待てば返ってくるかどうかで分かれます。遅いだけなら、原因は入力の重さ、モデルと拡張思考の設定、回線、そして混雑の四つのどれかに落ち着くことが多いのです。

入力の重さ

画像を何枚も添えた、長い PDF を複数つけた、数千行のコードを丸ごと貼った——こうした入力は、それだけで最初の一文字が返るまでの時間を押し上げます。

私が翻訳作業で学んだのは、一度に渡す量を減らすほうが、合計時間まで短くなることでした。十数言語をひとつのプロンプトに詰めるより、三言語ずつに分けたほうが、やり直しも含めて早く終わったのです。

モデルと拡張思考

モデル選択で重いモデルを選び、さらに拡張思考（Extended Thinking）を有効にしていると、考えている時間がそのまま待ち時間になります。急ぎの下書きや要約なら、軽いモデルに切り替え、拡張思考を切るだけで体感が変わります。

古いモデルほど遅い、とは限りません。私は「重い仕事は重いモデルで、下ごしらえは軽いモデルで」と分けるようにしてから、待たされる場面がずいぶん減りました。

回線

別のサイトが普通に開くか、動画が止まらずに再生できるかを見れば十分です。VPN を使っているなら、いったん切って試すのも切り分けのひとつです。

混雑時間帯は、自分で測る

「何時が混む」という一般論は、私の環境ではあまり当てになりませんでした。時差も、使っているモデルも、人によって違うからです。

そこで私は、API で最初の一文字が返るまでの時間（time to first token）を一日数回だけ記録するようにしました。数日ぶんの記録があれば、自分にとっての混雑時間が見えてきます。

import csv
import time
from datetime import datetime
from anthropic import Anthropic
 
# 計測専用なので自動再試行は切り、素の応答時間だけを見る
client = Anthropic(api_key="YOUR_API_KEY", timeout=60.0, max_retries=0)
 
def probe(model: str = "claude-sonnet-4-6") -> tuple[float, float]:
    """最初のトークンまでの秒数と、全体の秒数を返す"""
    t0 = time.monotonic()
    first = None
    with client.messages.stream(
        model=model,
        max_tokens=64,
        messages=[{"role": "user", "content": "OK とだけ返してください。"}],
    ) as stream:
        for _ in stream.text_stream:
            if first is None:
                first = time.monotonic() - t0
    return (first or 0.0), time.monotonic() - t0
 
if __name__ == "__main__":
    ttft, total = probe()
    with open("latency_log.csv", "a", newline="") as f:
        csv.writer(f).writerow([datetime.now().isoformat(timespec="minutes"), f"{ttft:.2f}", f"{total:.2f}"])
    print(f"first token: {ttft:.2f}s / total: {total:.2f}s")

max_retries=0 にしているのは、再試行で見かけの時間がならされてしまうと、計測の意味がなくなるからです。ストリーミングで最初の一文字を取るのは、合計時間より混雑を素直に反映するのがこの数字だからです。

このスクリプトを朝・昼・夜に一度ずつ動かして一週間ためると、自分の生活時間に重なる「遅い帯」が一目で分かります。私はその帯に、待ちが苦にならない作業を寄せるようにしております。

回答が途中で切れるとき

途中で止まる症状は、出力の上限、接続の断、ブラウザの不調の三つに分かれます。見分け方は簡単で、止まった直後に「続けてください」で続きが出るかどうかです。

続きが出るなら出力の上限です。長い成果物は「まず目次だけ」「次に一章ずつ」と分けて頼むほうが、結果的に手直しも少なくなります。

続きが出ず、画面の下や開発者ツールの Network タブに失敗した通信が残っているなら接続の断です。回線を戻して、同じプロンプトを一度だけ送り直します。

ブラウザ全体が重い、タブが落ちる、という場合はブラウザ側です。タブを減らし、ブラウザを更新し、それでも駄目ならアプリ版や別ブラウザへ逃がします。

Claude Code で「進まない」とき

ブラウザとは違い、Claude Code では止まる原因がエージェントの動作そのものに潜んでいることがあります。私が実際に踏んだのは次の三つです。

Auto Mode が承認待ちで固まる

確認ダイアログが何度も出て先へ進まない、あるいは「停止を試みています」のまま動かないことがあります。多くは、実行しようとしたコマンドが要確認と判定され、承認を待っている状態です。

まず、いまどのツール実行で待っているのかをログで確かめます。テスト実行やビルドのように許可して差し支えないものなら、/permissions で許可リストに加えると、以降は同種の確認で止まらなくなります。

承認の輪から抜けられないときは、Esc で中断してから「このディレクトリ内の◯◯だけ自動で実行してよい」と範囲を狭めて言い直すと安定します。広い権限で押し切るより、必要な操作だけを一段ずつ許すほうが、結局は早いのです。

編集ツールが失敗して止まる

「対象の文字列が見つからない」「複数一致する」で編集が失敗し、そこで処理が止まることがあります。原因の大半は、編集前にファイルの最新内容を読めていないか、置換対象が一意でないことです。

編集前に該当ファイルを読み直させ、置換したい箇所を前後の行ごと長めに指定して一意にします。インデントや全角・半角の空白が実ファイルと一文字違うだけでも失敗するので、貼り付け時の表記ゆれには気をつけております。

書き込み不可で止まる場合は、対象が読み取り専用になっていないか、別のプロセスが握っていないかを見ます。

MCP サーバーに繋がらない

サーバーが立ち上がらない、ツールが一覧に出ない、接続がタイムアウトする——この三つの症状は、設定と起動順の問題がほとんどです。

claude mcp list で各サーバーの状態を確認し、failed なら設定ファイルのコマンドのパスや引数が実環境と合っているかを見直します。相対パスや未インストールの実行ファイルを指していると、その場で失敗します。

起動はするのにツールが使えないときは Claude Code を再起動して読み込み直します。OAuth 付きのサーバーはトークンの期限切れで突然繋がらなくなることがあるので、再認証も切り分けに加えておくと安心です。

ブラウザ・アプリごとの癖

Chrome — 拡張機能を疑う

シークレットウィンドウで動くのに通常ウィンドウで止まるなら、拡張機能の干渉です。広告ブロッカーや翻訳系の拡張機能をいったん全部切り、一つずつ戻して犯人を探します。

Safari — サイトデータとコンテンツブロッカー

Safari では、設定のプライバシーから claude.ai のサイトデータだけを削除して開き直すと戻ることがあります。コンテンツブロッカーを入れている場合は、claude.ai だけ除外してみるのが先です。

iOS / Android アプリ

ストアで最新版に更新し、それでも駄目なら一度削除して入れ直します。急ぎのときは、ブラウザ版で代用しつつ、あとでアプリ側を直すほうが手が止まりません。

無人の処理で「止まった」を見抜く

手元で対話している間は、遅くても待てば済みます。けれど Claude をスケジュール実行や API のバッチに組み込むと、話が変わります。返ってこない一回が、誰も見ていない時間に処理全体を止めてしまうからです。

私自身、個人開発でサイトの運用処理やアプリのバックエンドをスケジュール実行に任せています。以前、API 呼び出しが一度ハングしただけで、朝のうちに走るはずだった処理がまるごと止まっていたことがありました。エラーすら出ず、ログには「開始」とだけ残っていたのです。あの無音がいちばん怖いのだと、いまも感じています。

三つの状態を分ける

• 遅い：時間はかかるものの、最後には返ってきます。入力が長いか、サーバーが混んでいるかのどちらかです
• ハング：いつまでも返ってきません。切れた接続を握ったまま待ち続けている状態です
• レート制限：429 が返り、明示的に拒否されています。待てば回復します

対話なら「遅い」と「ハング」は体感で分けられますが、無人の処理ではコードに分けさせる必要があります。

待ち続けず、上限を決め、超えたら記録して、決めた回数だけやり直します。 私の自動処理は、この一文を守るようにしてから静かに止まることがなくなりました。

SDK の timeout と自動再試行を使い切る

Python SDK には、この線引きを支える仕組みが最初から入っています。timeout は一回の要求を待つ上限で、max_retries は接続エラー・408・409・429・5xx に対する自動再試行の回数です（既定は 2 回で、指数バックオフと retry-after ヘッダーを尊重します）。

import time
import anthropic
from anthropic import Anthropic
 
# 一回の要求は 60 秒まで待つ。一時的な失敗は SDK が 3 回まで自動で再試行する
client = Anthropic(api_key="YOUR_API_KEY", timeout=60.0, max_retries=3)
 
def ask(prompt: str, model: str = "claude-sonnet-4-6") -> str:
    """ハングを例外として表に出し、握りつぶさずに呼び出し元へ返す"""
    try:
        resp = client.messages.create(
            model=model,
            max_tokens=1024,
            messages=[{"role": "user", "content": prompt}],
        )
        return resp.content[0].text
    except anthropic.RateLimitError as e:
        # 自動再試行を使い切ってなお 429 なら、待ち時間を記録して上へ返す
        retry_after = e.response.headers.get("retry-after", "unknown")
        raise RuntimeError(f"rate limited (retry-after={retry_after}s)") from e
    except anthropic.APITimeoutError as e:
        # 60 秒 × 再試行ぶん待っても返らなかった。ここで止まったと残す
        raise RuntimeError("request timed out after retries") from e
    except anthropic.APIConnectionError as e:
        raise RuntimeError("could not reach the API") from e
 
if __name__ == "__main__":
    t0 = time.monotonic()
    try:
        print(ask("この文を一言で要約してください。"))
    finally:
        print(f"elapsed: {time.monotonic() - t0:.1f}s")

以前の私は、for ループで自前の再試行を書き、そのなかで timeout を渡し忘れていました。SDK の再試行と自前の再試行が重なって、失敗一回あたりの待ち時間が想定の三倍に膨らんでいたのです。いまは自前のループを捨て、max_retries に任せて、例外の種類ごとに「何が起きたか」だけを記録しています。

もうひとつ、長い出力を非ストリーミングで頼むと、SDK が「ストリーミングを使うように」と要求そのものを止めることがあります。大きな max_tokens を渡すときは、最初から client.messages.stream に寄せておくと、この落とし穴を踏みません。

止まったなら、止まったと残す

それでも駄目なときに raise しているのは意図的です。無人の処理で「失敗を黙って飲み込む」ことが、いちばん見つけにくい不具合になります。止まったのなら、止まったとログに残しておく——翌朝それを読むだけで、何を直せばよいかが決まります。

まず一つだけ、今日やること

止まったときに送り直す前に、ステータスページを一度だけ見ること。これだけを癖にしていただければと思います。

無人で回している方は、Anthropic(timeout=60.0, max_retries=3) の一行を加えて、明日の朝のログを読み返してみてください。私もそこから始めました。