Claude APIのservice_tier — Priority Tier新規購入停止と使い分け

Claude APIのservice_tierパラメータは、リクエストをPriority Tier(優先処理枠)に回すか標準枠のみにするかを1つの値で切り替えます。値はauto(既定)とstandard_onlyの2つだけです。ここに、2026年に入って変わった前提が1つあります。Priority Tierの容量コミットメントは新規購入が停止しました。既存の契約を持つ組織は契約終了日まで使い続けられますが、これから新しく枠を買うことはできません。

この記事では、service_tierの値ごとの挙動、Priority Tierの容量がどう消費されるか(バーンダウンレート)、レスポンスヘッダーでの適格性判定、そして新規購入停止という前提のもとでこのパラメータをどう扱うべきかを順に見ていきます。

service_tierとは何を切り替えるパラメータか

service_tierはAPIリクエストの優先度を決めるパラメータで、Messages APIのリクエストボディに文字列で渡します。Anthropicは3つのサービスティアを提供しています。

service_tierパラメータで直接選べるのはautoとstandard_onlyの2値だけです。Batchティアは別エンドポイント(Message Batches API)を使う形で選択するため、このパラメータの対象外になります。Messages APIのservice_tierはあくまで同期的なリクエストの優先度を切り替える値であり、非同期でまとめて処理するBatch APIとはエンドポイントもレスポンスの受け取り方も異なります。つまりコードの中でservice_tierに"batch"のような値を指定する使い方は存在せず、Batch処理を使いたい場合はリクエスト自体をMessage Batches APIのエンドポイントへ送る必要があります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude!"}],
    "service_tier": "auto"
  }'

"auto"が既定値です。Priority Tierの容量に余裕があればそちらを使い、無ければStandardへ自動フォールバックします。"standard_only"はPriority Tierの契約があってもあえて使わせたくないとき専用の値です。契約容量を別の重いバッチ処理のために温存したい場合などに使います。

Priority Tierは新規購入停止 — 既存契約はいつまで使えるか

Priority Tierの容量コミットメントは新規購入が停止しています。既存の契約を結んでいる組織は、契約終了日まで従来どおり利用を継続できます。新たに契約を結ぶ手段は用意されておらず、保証された容量が必要な場合はセールスへの問い合わせが公式の唯一の窓口になっています。

このドキュメントページ自体、既存契約者向けの参照用として残されている状態です。新規にservice_tier: "auto"を設定しても、Priority Tierの契約が無い組織ではStandardティアで動くだけで、エラーにはなりません。つまりコードにservice_tierを書くこと自体は、契約の有無にかかわらず安全です。

Priority Tierの契約は次の4要素で構成されます。

• 1分あたりの入力トークン数
• 1分あたりの出力トークン数
• コミット期間(1・3・6・12か月のいずれか)
• 対象モデルのバージョン

コミット容量を超えたリクエストは自動的にStandardティアへフォールバックします。容量超過がエラーになるわけではなく、優先度が下がるだけです。

auto/standard_onlyはどう使い分けるか

autoのまま全リクエストを流すと、契約容量が少ないチームでは重要度の低い処理に優先枠を先に使い切られてしまうことがあります。優先させたいリクエストの種類が決まっているなら、それ以外はstandard_onlyで明示的に外すほうが安全です。

Priority Tier容量の消費レート(バーンダウン)

Priority Tierの容量は、トークンの種類によって消費量(バーンダウンレート)が変わります。均等に1トークン=1消費ではありません。

入力トークン

出力トークン

US-only inferenceの出力トークンも1.1倍消費です。それ以外の出力トークンは1.0倍のまま変わりません。

プロンプトキャッシュの仕組みを併用しているチームほど、この表の影響は大きくなります。キャッシュ読み取りが0.1倍で計上されるのは、Priority Tier容量にとって明確な優遇です。同じ会話を作り込んでキャッシュヒット率を上げるほど、少ない契約容量で多くのリクエストを優先処理に回せます。逆にキャッシュ書き込みは1.25〜2.00倍と重く、TTLを1時間に伸ばすほど消費が増えます。頻繁に更新されるプロンプトを長いTTLでキャッシュすると、書き込みのたびに容量を余分に消費する計算です。

具体的な数値で見ると、10,000トークン分のPriority Tier入力容量を持つ契約で、1時間TTLのキャッシュ書き込みに5,000トークンを使うと、消費レートは2.00倍なので実際には10,000トークン分の容量を消費し、それだけで契約の全量を使い切ります。同じ5,000トークンをキャッシュ読み取り(0.1倍)で処理した場合は500トークン分の消費で済み、残り9,500トークンを他のリクエストに回せます。同じトークン数でも、キャッシュの当たり方次第で容量消費に20倍の差が生まれる計算です。

Priority Tierに割り当てられたリクエストも、通常のレート制限自体からは免除されません。Priority Tier容量と通常のレート制限の両方を同時に消費し、通常のレート制限を超える場合はリクエストごと拒否されます。Priority Tierは優先度を上げる仕組みであって、レート制限の上限を引き上げる仕組みではありません。

レスポンスヘッダーでPriority Tier適格性を判定する方法

service_tier: "auto"でリクエストを送ると、レスポンスのusageオブジェクトに実際に割り当てられたティアが入ります。

{
  "usage": {
    "input_tokens": 410,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0,
    "output_tokens": 585,
    "service_tier": "priority"
  }
}

Priority Tier契約を持つモデルへautoでリクエストすると、レスポンスヘッダーにも次の情報が付きます。

anthropic-priority-input-tokens-limit: 10000
anthropic-priority-input-tokens-remaining: 9618
anthropic-priority-input-tokens-reset: 2025-01-12T23:11:59Z
anthropic-priority-output-tokens-limit: 10000
anthropic-priority-output-tokens-remaining: 6000
anthropic-priority-output-tokens-reset: 2025-01-12T23:12:21Z

このヘッダーが付いているかどうかで、そのリクエストがPriority Tierの対象になり得たかを判定できます。容量を使い切っていて実際にはStandardへ落ちた場合でも、ヘッダー自体は出ます。usage.service_tierの値と合わせて見ることで、「対象だが枠が無くて落ちた」のか「そもそも対象外だった」のかを切り分けられます。

運用上は、anthropic-priority-input-tokens-remainingとanthropic-priority-output-tokens-remainingを継続的に監視しておくと、契約容量の枯渇を事前に察知できます。残量が閾値を下回った時点でservice_tierをstandard_onlyに切り替える処理を組み込んでおけば、優先度の低いリクエストがPriority Tier容量を使い切ってしまい、本来優先させたい処理までStandardへ落ちるのを防げます。ヘッダーの-resetが示す時刻まで待てば容量は回復するため、閾値運用とリセット時刻の把握はセットで行うのが安全です。

Priority Tierに対応していないモデルがある

Priority Tierは、利用可能な全Claudeモデルで使えるわけではありません。公式ドキュメントでは、Claude Fable 5.1・Claude Mythos 5.1・Claude Mythos 5・Claude Mythos Preview・Claude Opus 5・Claude Sonnet 5が対象外とされています。

対象モデルかどうかはモデル一覧で確認する必要があります。除外リストに最新世代のモデルが並んでいる点は見過ごせません。Priority Tierという仕組み自体が容量コミットメントという運用形態を前提にしており、新しいモデルが出るたびに対応が追いつくとは限らない構造です。新規購入が止まっている今、この対応表が今後更新される優先度は高くなさそうに見えます。

Priority Tierの新規購入停止は529対策の選択肢をどう狭めるか

Priority Tierの新規購入停止と、直近の除外モデルの並びを重ねると、Anthropicが容量コミットメント型の優先処理を積極的に広げるフェーズを終えたと読めます。既存契約者への配慮(契約終了日までの継続利用、ドキュメントの維持)はある一方で、新規の窓口はセールス経由の個別対応に一本化されました。

これは、大口の安定利用者には個別契約で対応し、それ以外のユーザーにはautoの自動フォールバックとstandard_onlyの明示制御という2値のシンプルな運用に寄せる方針の表れです。実際、パラメータ自体の仕様は変わっていません。値も挙動もこれまでどおりで、変わったのは「新規に契約できるかどうか」という入口だけです。既存のコードにservice_tierを書いている実装は、そのまま動き続けます。

529エラー(overloadedエラーの一種)を減らす目的でPriority Tierの新規契約を検討していたチームは、この選択肢が閉じたことになります。代替策としては、リトライとバックオフの実装を丁寧にする、あるいはトラフィックの急増を避けて安定した利用パターンを保つといった、契約に頼らない対処に軸足を移す必要があります。

まとめ

service_tierはauto(既定)とstandard_onlyの2値で、Priority Tier容量を使うかどうかを制御します。パラメータ自体の仕様は変わっていませんが、Priority Tierの容量コミットメントは新規購入が停止し、既存契約者のみ契約終了日まで継続利用できる状態です。キャッシュ読み取りは0.1倍、キャッシュ書き込みは1.25〜2.00倍という消費レートの違いは、Priority Tier契約を持つチームがコストと優先度のバランスを取るうえで無視できない数字です。契約の有無にかかわらず、レスポンスのusage.service_tierとレスポンスヘッダーを見れば、自分のリクエストが実際にどう処理されたかを確認できます。

Priority Tierの契約なしにAPIを使っている場合、service_tierを意識する必要はほとんどありません。既定のautoのまま送信すれば、常にStandardティアで処理されます。