上限引き上げは歓迎すべき変更だが、アプリケーションのスロットリングを外してよいという意味ではない。レート制限はリクエスト数、入力トークン、出力トークンなど複数軸で適用され、モデルごとの利用が同時進行する。新tierの表示と実際の処理能力を負荷試験で結び付ける必要がある。
何が変わったか
Claude APIのusage tierがStart・Build・Scaleへ統合され、SonnetとHaikuのレート制限が各tierでOpusと同水準へ変更された
| 項目 | 内容 |
|---|---|
| 対象 | Claude API |
| API・機能 | Rate Limits API |
| 変更種別 | API変更 |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来の複数usage tierはStart、Build、Scaleへ整理された。Anthropicは多くの組織が高いtierへ移り、下がる組織はなく、変更作業は不要としている。SonnetとHaikuの上限も同tierのOpusと揃うが、組織固有のConsole表示が正本である。
誰に影響するか
ピーク時に429を受けるオンライン処理、複数モデルをfallbackするルーター、長文入力、並列Agent、バッチ前処理に影響する。固定値をコードへ埋め込んだシステムや、旧tier名を監視ラベルに使うダッシュボードは更新が必要になる。
期限
強制移行作業はなく、変更は既に適用済みである。旧tier名を前提にした監視・文書だけは早期に修正する。
必要な対応
Consoleの表示値を取得し、リクエスト数だけでなく入力・出力トークンの制限を監視する。429ではretry-after等を尊重し、指数バックオフとジッターを使う。急激なトラフィック増加による加速制限を避け、段階的に負荷を上げる。
実装・移行手順
- 現在のtierと全モデルの上限を記録する
- 旧tier名を使用する設定・アラート・Runbookを検索する
- 代表ワークロードでRPM・入力TPM・出力TPMを計測する
- キューと同時実行数を最も厳しい軸に合わせる
- 429・タイムアウト・fallbackを負荷試験する
- 増枠分を恒久SLOへ反映する前に数日間観測する
失敗しやすい点
公表された一般説明だけで自社上限を決める、429を即時再試行して集中させる、モデル変更で別プールになると決めつける、平均値だけでピークを設計することが失敗につながる。
リスク
新上限を使い切る設計による急激な費用増、キュー解放による下流過負荷、旧tier名称の監視欠落がある。
評価方法
- モデル別RPM・ITPM・OTPM
- 429率
- 再試行成功率
- キュー待ち時間
- P95レイテンシー
- 時間当たり費用
- fallback発生率
ロールバック
同時実行数と送信レートを旧設定へ戻し、増枠利用を停止する。tier名称の表示変更は戻さず、監視上の閾値だけを保守的な値へ戻す。
編集部分析
増枠は性能改善ではなく、組織が利用できる供給上限の変更である。品質やモデル速度は別に評価し、容量増をコスト増へ直結させない制御が必要になる。
実務チェックリスト
- [ ] Consoleの実上限を確認した
- [ ] 旧tier名を削除した
- [ ] 全制限軸を監視した
- [ ] バックオフとジッターを実装した
- [ ] 負荷を段階的に増やした
- [ ] 費用アラートを更新した