こんにちは、Lena です。去年のある時期、2週間ずっと正常に動いていた workflow をじっと見つめていたら、突然……止まりました。有用な error もなく、明らかな原因もない。タスクは 80% 完了していて、agent はただ黙り込んでしまった。
その後の数時間、私はずっと自分のコードが原因だと思い込んでいました。違いました。Claude の usage limit でした——しかも、自分が引っかかると思っていたものとは別のものでした。
この経験がきっかけで、考え始めました。それまで見てきた troubleshooting のほとんどは、「Claude が落ちた」をひとつの問題として扱っていました。でもログを眺めていると、まったく異なる3つの事象が互いに混同されていることに気づき始めたのです。そして、それらを区別できるようになった途端、修復方法はずっと明確になりました。
これがその整理です——始める前に手元にあったらよかったのに、と思うものです。
Claude が制限に達したりダウンしたりしたとき、実際に何が起きているのか
最初にじっくり考える価値があるのは、Claude の障害がすべて同じ種類の障害ではないということです。
Rate Limits（レート制限） vs Usage Caps（使用量上限） vs Outages（サービス停止）
これらは3つの別々の問題であり、原因もエラーの特徴も修復方法も異なります。混同すると時間を無駄にします。
Rate limits（レート制限） は、リクエストと token に対する1分あたりの制約です。rate limit は使用している usage tier（使用ティア）に依存し、3つの主要指標で測定されます：requests per minute (RPM)、tokens per minute (TPM)、そして場合によっては daily token quotas（日次 token 割り当て）。これらを超えると、HTTP 429 Too Many Requests が返されます。これは throughput の問題です——短い時間枠の中で、あまりにも多く、あまりにも速くリクエストしているということです。
Usage caps（使用量上限） は異なります。Claude Code rate limits は、3つの独立した重複する制約からなるシステムとして動作しており、dashboard に表示されるパーセンテージはそのうち1つしか反映していません。Anthropic console で日次使用量が 6% 残っているのを見て、すべて大丈夫だと思っていても、壁にぶつかることがあります——消費し尽くしたのが per-minute token ceiling（1分あたりの token 上限）であって、daily のものではないからです。微妙ですが重要な違いです。
Outages（サービス停止） はまったく別のカテゴリです。529 Service Unavailable は、Anthropic のサーバーがシステムレベルで負荷を受けていることを意味します。529 error はあなたのせいではありません——Anthropic のサーバーが全ユーザーにわたる高トラフィックを受けたときに発生し、拒否された 529 リクエストは課金にカウントされません。529 をコードの最適化で修復することはできません。待って、back off して、Anthropic のステータスページで incident の更新を確認してください。
この区別がなぜこれほど重要なのか：誤った診断は誤った修復につながるからです。実際には一時的な outage だったものに対して API tier をアップグレードしようとする人を見てきました。また、本当に必要だったのは異なるリクエストパターンだったのに、429 が「自然に解決する」のを辛抱強く待っている人も見てきました。
各障害モードが Agent ワークフローに与える影響
Chat interface は、Claude が制限に達したとき、わりと寛容です。メッセージが表示され、少し待って、もう一度試せばいい。
Agent workflows はそうはいきません。Claude Code は、API に1つの prompt を送って応答を待つのではありません。各インタラクションは、system prompt、蓄積された会話履歴、context に取り込まれたファイル内容、そして tool-use tokens を含む multi-turn conversation です。一見シンプルな「このファイルを編集して」というコマンドでも、完全な context が組み立てられると、1回の API call で 50,000〜150,000 tokens を消費する可能性があります。
この環境での rate limit hit は retry loops（リトライループ） を引き起こします。agent はリクエストを送り続け、すべてが失敗し、すべてが quota にカウントされる tokens を消費します。Usage cap hit はタスクの途中で実行を停止させることがあり、それが cap の問題だという明確なシグナルがないこともあります。そして outages は、私が silent failures（サイレント障害）と呼んでいるものを引き起こします：tool call がハングし、タイムアウトし、設定によっては有用な情報が何もログに残りません。
あのスタックした workflow で不快な数時間を過ごしたのは、まさにこれが原因でした。Agent が rate limit に引っかかり、backoff なしの retry loop に入り、私が気づく前に残りの token budget を使い果たしてしまったのです。
各障害モードに対する即時の修復
Rate Limit Hit：まず止血する
最も効果的な即時修復は、exponential backoff with jitter（指数バックオフ＋ジッター）です。考え方はこうです：各 retry は前回の2倍の時間待ち、小さなランダムなオフセット（jitter）を加えて、複数の client からの burst retries を分散させます。
jitter の部分は見落とされがちですが、重要です。これがないと、複数の worker や並列の agent thread がすべて同じ rate limit に引っかかり、まったく同じ間隔でリトライすると、各 retry cycle で burst 問題を再現してしまいます。問題を解決しているのではなく、固定オフセット分だけ先送りしているだけです。
シンプルでずっと役に立っている Python パターンがあります：
import time, random
from anthropic import Anthropic, RateLimitError
def call_with_backoff(client, messages, max_retries=5):
for attempt in range(max_retries):
try:
return client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=messages
)
except RateLimitError as e:
if attempt == max_retries - 1:
raise
base_wait = min(2 ** attempt, 60)
wait_time = base_wait + (random.random() * base_wait * 0.1)
time.sleep(wait_time)
補足ですが、Anthropic 公式 Python SDK にはデフォルトで組み込みの retry logic が含まれています。429 エラーに対して最大2回、exponential backoff でリトライします。本番の agent workflows でより高い耐障害性が求められる場合は、通常、より高い max_retries 値と独自の jitter ロジックを設定する必要があります。
リトライ以外では、並列度を下げることです。5つの agent threads が同時に Claude API calls を発行し、rate limit が 50 RPM で token pool が共有されている場合、衝突はほぼ確実です。リクエストをずらし、可能な限り batch 処理し、並列実行が throughput と線形にスケールするとは考えないでください。
Usage Cap Hit：ゼロからやり直さない
タスクの途中で cap に当たるのは、最もフラストレーションの溜まる障害モードのひとつです。なぜなら、cap hit の前に完了した作業は通常まだ有効だからです。修復は再起動ではなく、状態を保存して再開することです。
サブスクリプションプランで、本番 workflows で頻繁に caps に当たっている場合、Batch API を使えば大量のリクエストを非同期で処理でき、input と output の両方の tokens に対して 50% の割引が適用されます。レイテンシに敏感でないタスクでは、実質的な容量を大幅に拡張できます。大きな system prompt や繰り返しの context がある場合は、Prompt caching の実装が価値あります：cached tokens のコストは標準の input tokens のほんの一部で、同じ context が繰り返し送信される長い agent session では、この節約はすぐに積み上がります。
usage cap が構造的なミスマッチである場合——現在の tier が提供する以上の throughput が本当に必要な場合——tier の決定をする前に docs.anthropic.com/en/api/rate-limits で現在の plan limits を確認してください。これらの数値は予告なく変更されます。
Outage への対処：グレースフルに劣化させる
Outages に対する核心的なパターンは、circuit breakers（サーキットブレーカー）と graceful degradation（グレースフルデグラデーション）です。
Circuit breaker パターンには3つの状態があります：Closed（正常稼働）、Open（障害を検知——リクエスト停止）、Half-Open（サービスが回復したかテスト中）。Claude API との統合に適用すると：連続 N 回の失敗後、circuit が開いてリクエストの送信を停止します。タイムアウト期間後、1つの probe request（探査リクエスト）を許可します。それが成功すれば、circuit は再び閉じます。
retry との重要な振る舞いの違い：retries は個別のリクエスト失敗を処理し、circuit breakers はシステム的な障害を処理するということです。Claude が 20 分間ダウンしている場合、その間に agent が 400 回の失敗した API calls を行うのは望ましくありません。パターンを検知し、試行を止め、作業をキューに入れ、サービスが回復したら再開する——そうあるべきです。
Agent ワークフローにレジリエンスを組み込む
ここからが面白いところです——少なくとも私にとっては。上記の即時修復は止血です。このセクションでは、そもそも出血しないようにする方法を扱います。
Fallback Model Routing（フォールバックモデルルーティング）
Claude が利用できないとき、fallback model endpoint があれば、agent は完全に停止するのではなく、機能を低下させながら動作を続けられます。実践的な形はこうです：メインの workflow は Claude にルーティングし、529 や circuit breaker の発動が起きたら、リスクの低いサブタスクを secondary model にルーティングしつつ、critical-path の作業は Claude の復帰を待ってキューに入れます。
これは単純な差し替えではありません。モデルごとに tool call の挙動、context のフォーマット、出力の一貫性が異なります。私の提案は、狭い範囲の fallback から始めることです：agent workflow の中で本当にモデルに依存しない部分（summarization、simple classification、format conversion）を特定し、まずそれらを fallback にルーティングしてください。複雑な推理や tool-heavy なステップはキューに残しましょう。
multi-provider routing と適切な fallback ロジックについては、Portkey の LLM gateway が詳しくパターンを解説しています。retries、fallbacks、circuit breakers をレイヤードシステムとして組み合わせるアプローチは、本番の信頼性を構築するなら一読の価値があります。
Checkpoint and Resume Patterns（チェックポイントと再開のパターン）
正直に言うと、この部分はまだ完全には整理できていません。でも方向性は明確です：agent state は task boundaries（タスク境界）でシリアライズ可能でなければならないということです。
基本的な形：Claude API call の前に、現在の agent state——タスクの進捗、完了したステップ、中間出力——を永続ストレージにシリアライズします。呼び出しが失敗して circuit breaker が開いた場合、最初からやり直すのではなく、復帰用の checkpoint が手元にあります。
より難しいのは、ステップ間に依存関係がある agentic workflows で「task boundaries」をどう定義するかです。私が見つけた最もクリーンなアプローチは、各 tool call を潜在的な checkpoint として扱うことです。粒度が細かすぎると感じるかもしれませんが、checkpoints をマージする方が、復旧ポイントのない部分的に完了したマルチステップタスクを解きほぐすよりずっと簡単です。
クリティカルパスとバックグラウンドタスクの分離
すべての agent task に同じ可用性の保証が必要なわけではありません。バックグラウンドタスク——ロギング、要約、低優先度の分析——は、Claude が数分あるいは数時間利用できなくても許容できます。 クリティカルパスのタスクはそうはいきません。
これを明示的にモデリングすることで、異なるレジリエンスプロファイルを設計できます：クリティカルパスには積極的な retry ロジック、fallback models、circuit breaker モニタリングを。バックグラウンドタスクには焦らずキューに入れ、retry の圧力をかけない。これだけで Claude usage limits からのノイズは大幅に減ります。すべての失敗した API call を同じ緊急度で扱わなくなるからです。
より深い問題：すべての Workaround が再発明され続けている
ずっと気になっていることがあります。
Claude ベースの workflows を構築している十分な数の人々と話した結果、あるパターンに気づきました。誰かが exponential backoff の問題を解決する。うまく実装する。動く。そして3ヶ月後、チームメイトが新しいプロジェクトを始め、同じ 429 errors にぶつかり、再び解決する——少し違うやり方で、少し違うファイルに、少し違う形で。最初の解決策は決して伝わらなかった。
Checkpoint patterns、circuit breaker configurations、fallback routing logic も同じです。グローバルな retry counter はすべての tools を単一の障害ドメインとして扱います。1つの tool が劣化すると、他のすべての tool の budget を消耗します。誰かがこれを発見し、per-tool circuit breakers を構築しますが、それは1つのプロジェクトの codebase に留まり、ドキュメント化されず、まったく同じ問題に遭遇する次のプロジェクトからは参照されません。
これはコードの問題ではありません。knowledge structure（知識構造）の問題です。検証済みの fallback strategy は、チャットログや忘れ去られる使い捨てスクリプトではなく、agent capability とともに移動する再利用可能な形で存在すべきです。
これに対する完全な答えはまだ持っていません。ずっと考え続けています。
FAQ
Claude の現在の API ユーザー向け rate limits はどのくらいですか？
これらは変動するため、アーキテクチャの決定をする前に公式の Anthropic rate limits ドキュメントで確認してください。おおまかな参考として：limits は tier ベース（Tier 1 から Tier 4）で、RPM、ITPM、OTPM で測定され、支出のしきい値を満たすとより上位の tier がアンロックされます。Tier 1 は控えめなスタート、Tier 4 はかなり余裕があります。2025 年の記事の数値はすでに古くなっている可能性が高いです。
本番の agent workflow で Claude の outages にどう対処すればいいですか？
Circuit breakers が適切なパターンです。連続障害がしきい値に達したら circuit を開き、open 状態では作業をキューに入れ、タイムアウト後に探査し、サービスが回復したら閉じます。監視の中で status.anthropic.com を確認し、局所的な問題とプラットフォーム全体の incident を区別してください。
Claude が利用できないとき、最適な fallback model は何ですか？
万能の答えはありません。agent が何をしているかによります。Structured output のタスクでは、ほとんどの主要モデルがそれなりにうまく処理できます。複雑な tool-use chains やマルチステップの推論では、fallback の品質低下がより顕著になります。まず workflow の中で本当にモデルに依存しない狭い範囲を特定し、そこから fallback にルーティングしてください。
Claude の障害でタスクがゼロからやり直しにならないよう、agent state を保存するにはどうすればいいですか？
各 Claude API call の前に、task boundaries で agent state をシリアライズしてください。最低限：完了したステップ、中間出力、task graph における現在位置。粒度の問題はより難しいですが、より頻繁な checkpoints の方に倒してください。ストレージは安い。2時間の agent task を再実行するのは安くありません。
Agent が失敗した retries で tokens を燃やし続けるのを止めるにはどうすればいいですか？
2つのことです：exponential backoff with jitter（retries が同期的な burst を作らないように）と、circuit breakers（システム的な障害が retry budget を消費し続けないように）。Anthropic Python SDK にはベーシックな retry logic が組み込まれています。デフォルトに頼るのではなく、明示的に設定してください。並列処理がある本番システムでは、per-tool または per-operation の circuit breakers を追加して、1つの劣化した endpoint が retry budget 全体を消耗しないようにしてください。
この領域の発展はおそらくこれからも追い続けるでしょう。Limit と resilience patterns はまだ公の場で模索されている段階だと感じていますし、長時間稼働する agentic workflows にとって最もクリーンな形がどういうものか、まだ完全に見えたとは思っていません。でも3つの障害モードの区別——少なくともその部分は、かなり固まってきたと感じています。
