「Claudeが急に重くなった」「途中で応答が止まった」「APIを叩いたらタイムアウトで落ちた」——そんな経験はありませんか?
AIを日常業務に組み込み始めると、こうしたパフォーマンスの問題は想像以上のストレスになります。特にClaude Codeでコーディング作業を自動化していたり、社内ツールにClaude APIを組み込んでいたりする場合、タイムアウトが発生した瞬間に業務全体がストップするリスクさえあります。
この記事では、Claudeのレスポンスが遅い・タイムアウトする問題の原因と解決策を、Web版・API版・Claude Code版の3つの利用形態ごとに体系的に解説します。「とりあえず試せる対処法」から「本番システムに組み込める堅牢な設計パターン」まで、段階的に掘り下げていきます。
- 1. まず確認すべき「サービス障害」の見極め方
- 2. レスポンス遅延の5大原因を徹底分析
- 3. Web版(claude.ai)のタイムアウト・遅延を解消する方法
- 4. API利用時のタイムアウト解決・高速化テクニック
- 5. Claude Code利用時の特有の問題と解決法
- 6. 応答速度改善のためのベストプラクティスまとめ
- まとめ:「遅い」は解決できる、そして防げる
1. まず確認すべき「サービス障害」の見極め方
問題の切り分けで最も重要なのは、「自分の環境の問題なのか、Anthropicのサーバー側の問題なのか」を素早く判断することです。ここを間違えると、何時間もローカル環境のトラブルシューティングをしながら、実は向こう側のインフラ障害だった……という最悪のパターンに陥ります。
ステータスページを最初に確認する
Anthropicは公式のステータスページを提供しています。
→ https://status.anthropic.com/ もしくは https://status.claude.com/
実際に2025年3月には、api.anthropic.comへのリクエストがネットワーク経路の問題でタイムアウトするインシデントが発生しており、Anthropicは上流プロバイダーと連携して対応したことが記録されています。このように、サービス障害は定期的に発生するものです。「重い」と思ったらまずここを開く習慣をつけましょう。
モデル単位の部分障害に注意
見落とされがちなのが「モデル単位の部分障害」です。Claude CodeがOpus 4.5でタイムアウトを繰り返していたとき、Sonnetは正常に動作していたというケースが報告されています。プラットフォーム全体がダウンしているわけではなく、特定のモデルだけが応答しなくなる部分障害は珍しくありません。
ステータスページで確認すべきポイントは以下の3点です。
- Claude APIの欄が「Operational(正常)」かどうか
- 個別モデル(Opus / Sonnet / Haiku)のインシデント欄
- 過去24時間のインシデント履歴(断続的な障害の有無)
簡単な疎通確認コマンド
APIを利用している方は、複雑なリクエストの前にまずシンプルな疎通確認を行いましょう。
# Anthropic APIへの簡易疎通確認(curlで実行)
curl -s -o /dev/null -w "%{http_code}" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "Content-Type: application/json" \
https://api.anthropic.com/v1/models
# 200が返れば接続自体は正常
実際のところ、APIエラーの90%はClaudeの再起動や一時的なサーバー問題の自然回復によって5分以内に解決することが多いとされています。焦って複雑な対処をする前に、少し待つのも賢い選択です。
2. レスポンス遅延の5大原因を徹底分析
原因を正しく把握すれば、解決策の優先順位が明確になります。それぞれを詳しく解説します。
原因①:サーバー側の過負荷(ピーク時間帯)
AnthropicのサーバーはAWSなどのクラウドインフラ上に構築されていますが、ユーザーが急増するタイミングでは処理待ちキューが膨らみます。特に米国東海岸の業務時間帯(日本時間では深夜から早朝) が最も混雑しやすいため、日本のエンジニアが深夜に作業していると逆に快適、ということも珍しくありません。
混雑しやすい時間帯の目安(日本時間):
| 日本時間 | 米国時間(ET) | 混雑度の目安 |
|---|---|---|
| 22:00〜翌2:00 | 09:00〜13:00 | 高(米国東海岸の朝) |
| 翌2:00〜翌6:00 | 13:00〜17:00 | 最高(米国全土の業務時間) |
| 6:00〜12:00 | 深夜〜早朝 | 低(オフピーク) |
原因②:モデルの選択(OpusとHaikuの速度差)
モデルによってレスポンス速度は大きく異なります。Anthropicのモデルファミリーでは、Opusは最高の知性を持ち複雑な推論やアーキテクチャ判断に最適な一方、Haikuはシンプルなクエリや素早い繰り返し作業に向いた高速モデルとして位置づけられています。
| モデル | 応答速度 | 得意なタスク | 推奨シーン |
|---|---|---|---|
| Claude Haiku | ★★★ 最速 | 分類・要約・軽い変換 | チャットbot、即時応答が必要なUI |
| Claude Sonnet | ★★☆ 標準 | コーディング・文書作成・分析 | 一般的な開発補助・業務自動化 |
| Claude Opus | ★☆☆ 低速 | 高度な推論・複雑な設計判断 | 重要な意思決定支援・長期プランニング |
速度を重視する場面でOpusを選択するのは、スポーツカーで渋滞の市街地を走るようなものです。タスクに合ったモデルを選ぶことが、体感速度改善の第一歩です。
原因③:コンテキストの肥大化
会話の長さ(コンテキストウィンドウ)が増えるほど、モデルが処理すべきトークン(※テキストのまとまり、単語や文節に相当)が増加し、応答生成に時間がかかります。とくにClaude Codeで長時間作業を続けると、セッション内にコードベース全体の情報が蓄積されて極端に重くなることがあります。
コンテキスト肥大化のサイン:
- 同じような質問なのに以前より明らかに遅い
- Claude Codeで/clearを実行したら速くなった
- APIで同じプロンプトを送っても、会話履歴の長さで速度が変わる
原因④:ネットワーク環境の問題
意外と見落とされるのがローカルのネットワーク環境です。
- VPNの使用:経由ポイントが増えることでレイテンシ(通信の遅延)が増大
- 企業ファイアウォール:
api.anthropic.comの443番ポートが制限されている場合がある - プロキシサーバー:設定の不整合で接続が不安定になる
- DNSの問題:名前解決(URLをIPアドレスに変換する処理)に時間がかかるケース
原因⑤:Claude Code特有の2分タイムアウト問題
Claude Codeには、bashコマンドを2分で自動キャンセルするデフォルト設定があります。この問題はClaude Code v1.0.xで多くのユーザーが直面しており、長時間実行が必要なビルドやテスト実行がキャンセルされる原因となっています。設定ファイルを変更することで延長が可能です。
3. Web版(claude.ai)のタイムアウト・遅延を解消する方法
ブラウザ上でClaudeを使っている方向けの対処法です。
ブラウザ環境を最適化する
まず実施すべき基本的な対処法がいくつかあります。
チェックリスト:
□ ブラウザのキャッシュとCookieを削除 □ 不要なタブを閉じてメモリを解放 □ 広告ブロッカーや拡張機能を一時的に無効化 □ シークレット(プライベート)ウィンドウで試す □ Chrome、Edge、Firefoxなど別ブラウザで試す □ ページをハードリロード(Ctrl+Shift+R)
特にブラウザ拡張機能は要注意です。一部のプロキシ型拡張機能やコンテンツフィルターが、AnthropicへのWebSocket接続を妨害することがあります。
メッセージ内容を最適化する
重いリクエストが原因のタイムアウトは、送信内容の見直しで改善できます。
やってはいけないこと: - 不必要に高解像度の画像を添付する(自動的にトークンを大量消費) - 「これまでの会話を踏まえつつ」という形で冗長な背景情報を毎回添付する - 1回のメッセージに複数の独立したタスクを詰め込む
改善策: - 画像は用途に合った解像度に事前圧縮する - タスクを分割して複数回に分けてやり取りする - 新しいチャットセッションを頻繁に開く(コンテキストのリセット)
軽量モデルへの切り替えを活用する
claude.aiのチャット画面では、会話の途中でもモデルを切り替えることができます。「今この作業にOpusは必要ない」と気づいたらSonnetに切り替えるだけで、体感速度が大幅に改善することがあります。
4. API利用時のタイムアウト解決・高速化テクニック
システムやアプリにClaude APIを組み込んでいる開発者向けの、実践的な実装パターンを解説します。
タイムアウト値を明示的に設定する
デフォルトのタイムアウト値がシステムの要件に合っていないことが多く、特に長文生成を伴うリクエストでは設定値の見直しが必須です。
import anthropic # タイムアウトを明示的に設定(単位:秒) client = anthropic.Anthropic( timeout=120.0 # 長文生成のため120秒に延長 ) # または、リクエストごとに個別設定 response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=2048, messages=[{"role": "user", "content": "詳細なコードレビューをお願いします。\n\n" + code}], timeout=60.0 # このリクエストだけ60秒 )
複雑なリクエストのタイムアウト設定の適切な範囲は、一般的に30〜60秒程度とされており、遅い応答を待ち続けることと、本当の問題を素早く検出することのバランスをとることが重要です。
ストリーミングで体感速度を劇的に改善する
ストリーミング(streaming)とは、AIが応答を一文字ずつリアルタイムで返す方式のことです。全文生成が終わってから一括表示する通常方式に比べ、ユーザーが最初の文字を目にするまでの時間(Time to First Token)が大幅に短縮されます。
import anthropic client = anthropic.Anthropic() # ストリーミングで応答を受け取る with client.messages.stream( model="claude-sonnet-4-20250514", max_tokens=2048, messages=[{"role": "user", "content": "Pythonのデコレータについて詳しく説明してください"}] ) as stream: for text in stream.text_stream: # 生成されるたびにリアルタイム出力 print(text, end="", flush=True)
タイムアウト回避の観点でもストリーミングは有効です。接続が確立され、最初のトークンが届いた時点でタイムアウトカウンターがリセットされるため、長文出力でも途中切断のリスクが減ります。
指数バックオフ付きリトライロジックを実装する
エラー発生時に即座にリトライすると、サーバーが過負荷の場合さらに悪化させます。指数バックオフ(retry間隔を指数的に増やす手法)を使うのが正解です。
import time import anthropic def call_claude_with_retry(client, max_retries=3, **kwargs): """ タイムアウトとサーバーエラーに対するリトライ実装 指数バックオフ(5秒→10秒→20秒)を採用 """ for attempt in range(max_retries): try: return client.messages.create(**kwargs) except anthropic.APITimeoutError as e: if attempt == max_retries - 1: raise # 最終試行でも失敗したら例外を投げる wait_time = 2 ** attempt * 5 # 5秒、10秒、20秒 print(f"タイムアウト発生。{wait_time}秒後にリトライします... (試行 {attempt + 1}/{max_retries})") time.sleep(wait_time) except anthropic.InternalServerError as e: if attempt == max_retries - 1: raise wait_time = 2 ** attempt * 5 print(f"サーバーエラー発生。{wait_time}秒後にリトライします...") time.sleep(wait_time) # 使用例 client = anthropic.Anthropic(timeout=60.0) response = call_claude_with_retry( client, model="claude-sonnet-4-20250514", max_tokens=1024, messages=[{"role": "user", "content": "コードレビューをお願いします"}] )
フォールバック戦略でシステムの可用性を高める
本番システムでは、Anthropic直接APIが落ちたときのフォールバック(代替経路) を用意しておくことで、サービス継続性を確保できます。ClaudeはAWS BedrockやGoogle Cloud Vertex AIからも利用可能なため、それらをバックアップとして組み込む設計が有効です。
def call_claude_with_fallback(prompt: str, **kwargs): """ フォールバック付きのClaude呼び出し 優先順位:Anthropic直接API → AWS Bedrock → Google Vertex AI """ # 1st: Anthropic直接API(最優先) try: return anthropic_client.messages.create( model="claude-sonnet-4-20250514", messages=[{"role": "user", "content": prompt}], **kwargs ) except (anthropic.APITimeoutError, anthropic.InternalServerError) as e: print(f"[警告] Anthropic直接APIが失敗: {e}") # 2nd: AWS Bedrock経由(フォールバック1) try: print("AWS Bedrock経由にフォールバックします...") return call_via_bedrock(prompt, **kwargs) except Exception as e: print(f"[警告] Bedrock経由も失敗: {e}") # 3rd: 最終フォールバック(簡易応答や別モデル) raise RuntimeError("すべてのAPIエンドポイントが応答しませんでした")
パフォーマンス監視を組み込む
Claude APIのレイテンシを継続的に低く保つには、定期的なパフォーマンス監査が重要であり、応答時間を追跡してレイテンシのスパイクを検出し、許容限界を超えた場合にアラートを設定するシステムを構築することが推奨されています。
最低限モニタリングすべき指標は以下の通りです。
| 指標 | 説明 | 警告閾値の目安 |
|---|---|---|
| TTFT(Time to First Token) | 最初の文字が届くまでの時間 | 10秒超で要確認 |
| Total Response Time | 全文生成完了までの時間 | 60秒超で要対策 |
| Timeout Rate | タイムアウト発生率 | 5%超で設計見直し |
| Error Rate | 全エラーの発生率 | 1%超で要調査 |
5. Claude Code利用時の特有の問題と解決法
CLI(コマンドライン)で使うClaude Codeには、Web版やAPIとは異なる特有のタイムアウト問題が存在します。
2分タイムアウト問題を設定ファイルで解除する
Claude Codeはデフォルトでbashコマンドを正確に2分でキャンセルします。これはv1.0.xにおいて多くのユーザーが直面した問題で、設定ファイル(~/.claude/settings.json)を変更することで延長できます。設定変更後はClaudeを完全に再起動する必要があります。
// ~/.claude/settings.json に追記 { "env": { "BASH_DEFAULT_TIMEOUT_MS": "1800000", "BASH_MAX_TIMEOUT_MS": "7200000" } }
設定値の意味:
- BASH_DEFAULT_TIMEOUT_MS: 1,800,000ms = 30分(デフォルト実行タイムアウト)
- BASH_MAX_TIMEOUT_MS: 7,200,000ms = 120分(最大タイムアウト上限)
長時間のビルドやテストスイート全体の実行など、2分を超えるタスクを扱う場合は必須の設定です。
セッションの肥大化を防ぐ定期的なクリア
長時間の作業でClaude Codeが重くなってきたと感じたら、以下のコマンドでコンテキストをリセットできます。
# 現在のコンテキストを全クリア(最も効果的) /clear # 現在のセッション情報を確認 /status # セッションを再開(終了せずに継続したい場合) claude --resume
重要なのは「完全に閉じて再起動する」のと「/clearでリセットする」の違いです。/clearはコンテキストのみリセットしますが、セッション自体は継続します。完全に詰まった場合はCtrl+Cで終了してから再起動する方が確実です。
モデルをオンザフライで切り替える
Claude Codeは/modelコマンドを使ってセッション中にいつでもモデルを変更できます。この切り替えは即座に行われ、会話コンテキストも引き継がれます。Opusが応答しない場合にSonnetに切り替えるのが最も実践的な対処法です。
# 現在のモデルを確認 /model # Sonnet 4.5に切り替え(バランス重視) /model sonnet # Haiku 4.5に切り替え(速度重視) /model haiku # Opusに戻す(問題解決後) /model opus
6. 応答速度改善のためのベストプラクティスまとめ
問題が起きてから対処するのではなく、あらかじめ速度を最大化する設計をしておくことが理想です。
プロンプト設計で速度を最適化する
| 改善項目 | NG例 | OK例 | 改善幅 |
|---|---|---|---|
| 文脈の絞り込み | 「これまでの全会話を踏まえて...」 | 「この関数のみを見て...」 | 大 |
| 出力量の制限 | 「詳しく全部説明して」 | 「100字以内で要点を3つ」 | 大 |
| 画像解像度 | フルHD(1920×1080)を添付 | 640×480に圧縮して添付 | 中 |
| 会話の長さ | 50ターン以上継続 | 10〜15ターンで新規チャット | 中 |
| モデル選択 | すべてOpus | タスクに応じて使い分け | 大 |
運用ルールとして定めるべき項目
チームやプロジェクトで使う場合、以下を運用ルールとして明文化しておくと、メンバー全員が快適に使えます。
- 朝会やデイリーで使う際は軽量モデル(Sonnet)をデフォルトとする
- 深い技術的議論や設計レビューはOpusを使う、ただし時間に余裕のある場面限定
- Claude Codeのセッションは毎日始業時にリセット(
/clear)する習慣をつける - ステータスページへのブックマークを全員のブラウザに設定する
- API組み込みシステムには必ずリトライロジックとタイムアウト設定を実装する
他のAI APIとのパフォーマンス比較
Claudeのタイムアウト問題を理解する上で、他の代表的なAI APIとの比較を知っておくことも有益です。
| AI API | TTFT(目安) | ストリーミング対応 | フォールバック先 | 特記事項 |
|---|---|---|---|---|
| Claude API | 低〜中 | ○ | Bedrock / Vertex AI経由で利用可 | 高負荷時に遅延しやすい |
| OpenAI API | 低〜中 | ○ | Azure OpenAI経由も可 | 料金体系が異なる |
| Gemini API | 低 | ○ | Google Cloud Vertex AI | Google サービスとの統合が強み |
| AWS Bedrock | 低〜中 | ○(一部) | マルチモデル対応 | AWSインフラ上での安定性が高い |
※TTFT = Time to First Token(最初のトークンが返るまでの時間)。環境・モデル・プロンプトにより大きく変動します。
まとめ:「遅い」は解決できる、そして防げる
Claudeのレスポンス遅延やタイムアウト問題は、原因を正しく特定して適切な対処をすれば、ほとんどのケースで解消できます。本記事の要点を振り返りましょう。
問題発生時のファーストアクション: 1. ステータスページ(status.anthropic.com)を確認してサービス障害か判断する 2. モデルを切り替える(特定モデルの部分障害を回避) 3. シンプルなリクエストで疎通確認してネットワークかAPI側かを切り分ける
恒久的な対策: - API利用時はタイムアウト設定・リトライロジック・フォールバックを必ず実装する - Claude Codeのタイムアウト設定(settings.json)を用途に合わせてカスタマイズする - プロンプト設計を見直し、不要なコンテキストを削る習慣をつける - タスクに応じてモデルを使い分け、全部Opusという設定を見直す
AIツールの普及が進む中で、「動かないときどうするか」という知識はエンジニアとしての実務力に直結します。この記事で紹介したノウハウをチーム内で共有し、Claudeをより安定して活用できる環境を整えてみてください。