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

Claude APIのservice_tierパラメータは、リクエストをPriority Tier(優先処理枠)に回すか、標準枠だけで処理するかを切り替えます。値はauto(既定)とstandard_onlyの2つです。

service_tier: "priority"のような指定はできません。優先枠に載るかどうかは、組織の契約容量が空いているかで決まります。

前提が1つ変わっています。Priority Tierの容量コミットメントは新規購入が停止しました。既存の契約を持つ組織は契約終了日まで使えますが、これから新しく枠を買うことはできません。

service_tierが選べるのは2値だけ

Anthropicのサービスティアは3つあります。ただしservice_tierで選べるのはこのうち2つの挙動だけです。

Batchは別エンドポイント(Message Batches API)を使って選びます。service_tierに"batch"を渡す書き方はありません。

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"
  }'

パラメータ名はSDKの言語で書き方が変わります。PythonとRubyはservice_tier、TypeScript・Java・PHPはserviceTier、C#とGoはServiceTierです。値はautoとstandard_onlyの2つで、言語が違っても増えません。APIリファレンスでも、この2値だけの列挙型として定義されています。レスポンス側のusage.service_tierはstandard・priority・batchの3値で、リクエストとレスポンスで取りうる値が違う点に注意が要ります。

公式のCLI(ant)では、割り当てられたティアだけを取り出す書き方が示されています。--transform usage.service_tier --raw-outputを付けると、レスポンスのうちusage.service_tierの値だけが出力されます。

"auto"はPriority Tierの容量があればそれを使い、無ければ他の容量で処理します。"standard_only"は、契約があってもPriority Tierの容量を使わせたくないときの値です。

Claudeのティアには2種類ある

「Claude tier」「Anthropic tier」で調べる人が当たる区分は2つあり、別のものです。service_tierが扱うのは優先処理のほうです。

利用ティアの月間支出上限は、Startが500ドル、Buildが1,000ドル、Scaleが20万ドルです。Customに上限はなく、アカウントチームと取り決めます。上げ方はレート制限を上げるティア引き上げにあります。

Priority Tierの契約は何で決まり、どのモデルが外れるか

新規購入の停止後も、既存契約の組織は契約終了日まで利用できます。保証された容量が必要な場合の窓口はセールスへの問い合わせです。

既存契約は次の4要素でできています。

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

コミット容量を超えた分は自動的にStandardへ回ります。エラーにはならず、優先度が下がるだけです。

契約があっても、Priority Tierが使えないモデルがあります。Claude Fable 5.1、Mythos 5.1、Mythos 5、Mythos Preview、Opus 5.5、Opus 5、Sonnet 5.5、Sonnet 5の8つです。現行世代のほとんどが並ぶので、新しいモデルに切り替える前にモデル一覧で対象かどうかを見ておく必要があります。

公式の記述は「除外リストにあるモデル以外のすべてのClaudeモデルが対象」という形です。たとえば、公式のコード例に使われているClaude Opus 4.8は除外リストに無く、対象側に入ります。

除外リストのモデルでは、Priority Tierの枠を使えません。契約の対象モデルを除外リストにある世代へ移す計画なら、更新前に営業へ扱いを確かめておくと安全です。

自分の組織はどこに当たるか

状況は3つに分かれます。どれに当たるかで、service_tierに手を入れる意味が決まります。

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

使い分けに意味があるのは、2行目の状況にある組織だけです。

autoのまま全リクエストを流すと、契約容量が小さい組織では重要度の低い処理に優先枠を先に使われます。優先したい種類のリクエストが決まっているなら、それ以外をstandard_onlyで外す設計が堅実です。

Priority Tier容量の消費レートはトークンの種類で変わる

優先枠に載る条件は、入力側と出力側の両方で容量が足りていることです。片方だけ余っていても、足りない側があればそのリクエストは標準枠で処理されます。

容量は1トークン=1消費ではありません。入力トークンの種類と、データを置く地域で消費の重みが変わります。

この倍率は各トークンの相対的な価格を映したものです。容量の引かれ方は価格に連動するので、US-only inferenceの1.1倍は容量にも同じ倍率で効きます。

プロンプトキャッシュを使うチームほど、この差は大きく出ます。キャッシュ読み取りは0.1倍しか引かれないので、キャッシュが当たるほど少ない容量で多くのリクエストを優先処理に回せます。逆に1時間TTLの書き込みは2倍で、更新の多いプロンプトを長く保持すると書き込みのたびに容量が減ります。

数字で見ます。入力容量が10,000トークンの契約で、1時間TTLのキャッシュ書き込みを5,000トークン行うと、5,000×2.00で10,000トークン分の容量を消費します。契約の全量がこの1回で尽きます。同じ5,000トークンをキャッシュ読み取りで処理した場合は5,000×0.1で500トークン分です。残りの9,500トークンは他のリクエストに使えます。同じトークン数でも、キャッシュの当たり方で消費に20倍の差が出ます。

契約容量の見積もりにも、この倍率を使います。1分あたりの入力容量が100,000トークンの契約を例にします。ある1分間に、5分TTLのキャッシュ書き込み20,000トークン、キャッシュ読み取り60,000トークン、通常の入力10,000トークンが流れたとします。消費は20,000×1.25=25,000、60,000×0.1=6,000、10,000×1.0=10,000で、合計41,000トークン分です。生のトークン数は90,000なので、素朴に足すと容量を2倍以上多く見積もることになります。

キャッシュ読み取りの比率が高い構成ほど、素のトークン数より消費が小さく収まります。逆にキャッシュ書き込みが多いと、見かけの量より早く枠が減ります。

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

どのティアで処理されたかを見分ける

処理されたティアはレスポンスのusage.service_tierに入ります。値はstandard・priority・batchのいずれかで、nullの場合もあります。

import anthropic
 
client = anthropic.Anthropic()
 
message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude!"}],
    service_tier="auto",
)
print(message.usage.service_tier)  # standard / priority / batch / None

契約のあるモデルにautoで送ると、レスポンスヘッダーにもanthropic-priority-input-tokens-limit・-remaining・-resetと、出力側の同名3本が付きます。

リクエストごとにusage.service_tierをログに残しておくと、優先枠で処理された割合を後から数えられます。標準枠に落ちた時間帯があれば、容量の枯渇か対象外モデルかを、次の順で切り分けられます。

処理の割り当てに疑問が残るときは、全レスポンスに付くrequest-idヘッダー(req_で始まる値)を控えておきます。エラー本文のrequest_idフィールドにも同じ値が入り、サポートへ問い合わせるときに、そのリクエストを特定する手がかりになります。

529を減らす手段が契約の外にもある

Priority Tierの目的は、ピーク時の「server overloaded」エラーを減らすことです。購入できなくなった今、同じ目的には契約に頼らない手段で近づくことになります。

エラー一覧では、529はoverloaded_errorで、APIが一時的に過負荷のときに返ります。全ユーザーの高トラフィック時に起こるとされています。500のapi_errorも、指数バックオフで再試行する対象です。公式SDKは接続エラー・レート制限・5xxエラーを、指数バックオフで既定2回まで自動再試行します。retry-afterヘッダーがあればそれに従います。回数はmax_retries(TypeScript・Java・PHPはmaxRetries、C#はMaxRetries、Goはoption.WithMaxRetries)で変えられます。

もう1つ、使用量が急に増えた組織では429が加速度制限で出ることがあります。トラフィックを段階的に増やし、利用パターンを一定に保つのが公式の回避策です。429と529の見分け方は429と529の切り分けで扱っています。

待てる処理はMessage Batches APIに回す選択肢もあります。料金は標準価格の50%です。多くのバッチは1時間以内に終わりますが、24時間以内に処理が終わらなければ期限切れになり、その分は課金されません。1バッチの上限は10万リクエストか256MBのどちらか早い方で、結果は作成から29日間ダウンロードできます。優先度ではなく待ち時間とコストを取る方向の手段です。

リトライで解決しない429もあります。月次の支出上限に達した429にはretry-afterヘッダーが付かず、SDKの自動再試行を重ねても、アクセスが再開するまで失敗し続けます。自分で設定した支出上限は、400のinvalid_request_errorで返ります。

まとめ

契約がある組織は、usage.service_tierとヘッダーで実際の割り当てを記録しておくと、枠の枯渇と対象外モデルを後から切り分けられます。超過分を標準枠に流すか止めるかは、standard_onlyを使うかどうかで自分で決められます。