この記事の目次
「Claude Codeのレート制限」は何を指しているのか
一口に「レート制限」と言っても、性質の異なる2種類が混ざっている。ひとつはPro・Max・Teamなどサブスクリプションプランの利用上限、もうひとつはAPIの従量課金プランにおけるレート制限で、まずどちらの話をしているかを分けないと対処法も変わってくる。
両者を並べると次のようになる。
| 区分 | 対象 | 単位 | 超過時に起きること |
|---|---|---|---|
| サブスクリプション上限（5時間ウィンドウ） | Pro・Max・Team | 直近5時間のローリング | 一時的に利用不可、時間経過で自動回復 |
| サブスクリプション上限（週次累積） | Pro・Max・Team | 7日間のローリング累積 | 週内の残り期間は利用が制限されやすい |
| APIレート制限（RPM/ITPM/OTPM） | API従量課金 | 分単位のリクエスト数・トークン数 | 429エラーが返り、待機やリトライで対処 |
サブスクリプション（Pro/Max/Team）の利用上限とは
サブスクリプションには「直近5時間」の使用量を見る短いウィンドウと、「直近7日間」の累積を見る長いウィンドウの二層構造がある。5時間ウィンドウは時間が経てば自然に回復するのに対し、週次の累積上限に達すると回復までの時間が長くなりやすい。どちらに近づいているかは、後述する/usageコマンドで確認できる。
APIの従量課金プランにおけるレート制限とは
API従量課金では、1分あたりのリクエスト数（RPM）、1分あたりの入力トークン数（ITPM）、1分あたりの出力トークン数（OTPM）という3つの軸それぞれに上限が設定されている。具体的な数値はプランや契約内容によって変わるため、正確な値は公式ドキュメントの自分のアカウントページで確認するのが確実だ。この仕組みの詳細な設計上の注意点は後半（チームやAPI経由の自動化ではレート制限をどう設計すべきか）でまとめて扱う。
プランごとの料金そのものを比較したい場合は、Claude Codeの料金プラン比較に一覧がある。本記事では料金表は扱わず、見直すタイミングの判断軸だけを後述する。
今、自分が受けている制限はどのタイプか
制限の種類は、エラーメッセージの文言と/usageコマンドの表示を見比べれば見分けられる。サブスクリプションの上限とAPIの429エラーでは、返ってくるメッセージも対処の方向性もまったく違う。
5時間ウィンドウ制限のサイン
「しばらくしてからまた試してください」といった趣旨の案内とともに、直近の利用が急に止まる場合はこのタイプが疑わしい。/usageコマンドを打つと、現在の5時間ウィンドウ内での消費状況が表示されるので、そこで残量を確認できる。数時間待てば再開できることが多い。
週次（7日間）上限のサイン
5時間待っても状況が変わらない、あるいは/usageで週次の枠がほぼ埋まっていると表示される場合は、こちらに該当する。週の後半にまとめて重い作業をしていると起きやすく、回復まで数日単位の待ち時間が発生することもある。
APIレート制限（429など）のサイン
エラーコードとして429が明示的に返ってくる場合は、サブスクリプションではなくAPI側の従量課金レート制限に触れている。CI/CDや複数人でのAPIキー共有時に起きやすい現象で、これは後半で扱う設計の話につながる。
エラーの分類全体を体系的に把握したい場合はClaude Codeのエラー原因の切り分け方、ログから状況を確認する手順はClaude Codeのエラーログの確認方法に譲る。
サブスクリプション利用中に制限へ近づいたらどうすればいいか
制限に近づいたときにまず見直すべきは、待つか諦めるかではなく「なぜその消費量になっているか」であり、コンテキストの持ち方とモデルの選び方を変えるだけで余裕が生まれることが多い。
コンテキストを圧縮して消費を抑える
会話が長くなるほど、Claude Codeは過去のやり取りを保持したまま処理するためトークン消費が増えていく。/clearは会話履歴を完全にリセットし、/compactは要点を残しながら圧縮する。タスクの区切りで/clear、長いタスクの途中で文脈を保ちたいときは/compact、という使い分けが基本になる。圧縮の仕組みそのものの詳しい解説はClaude Codeのコンテキストウィンドウの仕組みにまとめてある。
モデルを使い分けて消費を抑える
複雑な設計判断が必要な作業にはOpus、通常のコーディング作業にはSonnet、単純な確認作業にはHaikuというように、タスクの重さに応じてモデルを切り替えると消費量を抑えられる。どのタスクにどのモデルが向くかという判断軸はClaude Codeのモデルの違いと使い分けで詳しく扱っている。
制限にかかったときの待機・再開の考え方
5時間ウィンドウの制限は待てば解けるが、週次の累積上限は数日単位で業務が止まる可能性がある。締め切りが近い作業を抱えている場合、待機を選ぶか、後述するプラン見直しを検討するかを早めに判断したほうがよい。CLAUDE.mdの肥大化がコンテキスト消費を押し上げていることもあるため、CLAUDE.mdの書き方も合わせて確認しておくと再発を防ぎやすい。
プランの見直しを検討すべきタイミングはいつか
判断軸は「制限に達する頻度」「業務への影響度」「現在のプランで足りているか」の3つで、この3つのどれか2つ以上が悪化していれば見直しを検討する目安になる。
たとえば5時間ウィンドウの制限には週に1度も触れないが週次上限には毎週触れている場合、単発の使い方ではなく継続的な作業量そのものがプランの想定を超えている可能性が高い。逆に、特定の日だけ集中的に使って制限にかかる場合は、使い方の分散で解決できることもある。
チームやAPI経由の自動化ではレート制限をどう設計すべきか
チームやCI/CDでClaude Codeを使う場合は、個人利用とは違い複数のリクエストが同時に走るため、RPM・ITPM・OTPMのどれが先に上限に触れるかを事前に把握しておく必要がある。
複数人でAPIキーを共有する際に起きること
同じAPIキーを複数人、あるいは複数のツールで共有していると、個々の利用者は軽く使っているつもりでも合算のリクエスト数が上限に達してしまうことがある。利用者ごとにキーを分ける、あるいは用途ごとに利用量を可視化する仕組みを用意しておくと、原因の切り分けがしやすくなる。APIキーの発行や管理の基本はClaude CodeのAPIキーの管理方法で解説している。
CI/CD（GitHub Actionsなど）に組み込む際の注意点
CI/CDのパイプラインに組み込むと、プルリクエストのたびにClaude Codeが自動実行されるため、思った以上の頻度でAPIを呼び出すことになりやすい。同時実行数を制限したり、重い処理を特定のトリガーだけに絞ったりすることで、レート制限に触れる頻度を下げられる。具体的な組み込み手順はClaude CodeのGitHub Actions連携、法人・企業単位での導入設計はClaude Codeの企業導入ガイドを参照してほしい。
複数アカウントの利用や制限の回避策は選択肢になるか
制限を回避する目的で複数アカウントを使い分けるような手段は、利用規約に抵触するリスクがあるため推奨しない立場を取る。
規約の解釈は時期によって更新されることがあるため、この記事では具体的な回避テクニックは扱わず、判断に迷う場合は公式の利用規約を自分で確認することをすすめる。制限と向き合う前提として、まずは規約の範囲内でできる使い方の見直しから検討するのが妥当だろう。
まとめ：制限と付き合い続けるために次に学ぶこと
レート制限は突然降ってくる障害というより、日々の使い方の設計がそのまま数字に表れたものだと捉えると、対処の方向性が見えやすくなる。コンテキストの持ち方、モデルの選び方、チームでの運用設計のどこかを変えれば、同じ作業量でも制限への近づき方は変わってくる。
対症療法として/clearや/compactを使いこなすだけでなく、コンテキスト管理やエージェント運用そのものを体系的に学びたい場合は、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」（lab.no-wave.jp）という選択肢もある。自分の手で使い方を組み立てられるようになるための学びの場として位置づけられている。