Claude Media
Claude CodeのBedrockサービスティア — flex・priority・reservedの違いと設定
Claude CodeTips

Claude CodeのBedrockサービスティア — flex・priority・reservedの違いと設定

Bedrock経由のClaude Codeでflex・priority・defaultを選ぶ環境変数と、reservedティアだけ指定方法が違う理由、4ティアの違いを解説します。

読了目安 約9分

Amazon BedrockでClaude Codeを使うとき、ANTHROPIC_BEDROCK_SERVICE_TIER という環境変数でリクエストごとのサービスティアを指定できます。値は default ・ flex ・ priority の3種類で、コストとレイテンシーのどちらを優先するかを選ぶ設定です。Claude Codeはこの値を X-Amzn-Bedrock-Service-Tier ヘッダーとしてBedrockへのリクエストごとに送ります。環境変数リファレンスにも同じ変数の行があり、値は同じ3種類です。

サービスティアとは何を切り替える設定か

Bedrockのサービスティアは、AWSが推論リクエスト向けに用意した提供水準です。AWS側のティアはReserved・Priority・Standard・Flexの4つです。Claude Codeの環境変数が受け付けるのは、このうち priority ・ default(Standardに対応)・ flex の3つです。Reservedだけは環境変数では指定できず、別の経路で使います(後述)。

ティアClaude Codeでの指定事前予約特徴
defaultClaude Codeでの指定default(未設定でも同じ)事前予約不要特徴Standardで処理。日常的な文書処理や生成向け
flexClaude Codeでの指定flex事前予約不要特徴処理に時間がかかってよい用途向けで、料金に割引がある。モデル評価・要約・エージェント的なワークフロー向け
priorityClaude Codeでの指定priority事前予約不要特徴応答が最も速く、標準のオンデマンド料金に上乗せがある。顧客向け業務フロー向け
reservedClaude Codeでの指定環境変数では指定不可事前予約必要特徴1か月か3か月の容量予約。AWSのアカウント担当へ問い合わせて契約する

PriorityのリクエストはStandardやFlexよりも優先して処理されます。割引率や上乗せ率の具体的な数値はAWSの料金ページに載る値で、モデルごとに確認します。Claude Codeが担うのはヘッダーを付けてリクエストを送るところまでで、割り当てと料金への反映はBedrock側の処理です。

3つのティアは、モデルごとのオンデマンドのクォータ(利用上限)を共有します。priority に切り替えても、別枠の上限が増えるわけではありません。

設定のしかた

環境変数を1つ設定するだけです。Amazon Bedrock自体を有効にする CLAUDE_CODE_USE_BEDROCK=1 と組み合わせて使います。

export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_BEDROCK_SERVICE_TIER=priority
claude

対話的なログインウィザードは、claude 起動時に3rd-party platform → Amazon Bedrockを選ぶか、/setup-bedrock で開きます。扱うのは認証方式・リージョン・モデルのピン留めです。サービスティアは対象外なので、手動で環境変数を追加するか、設定ファイルの env ブロックに書きます。

プロジェクト単位の設定ファイルに書いておけば、リポジトリを開いた全員に同じティアを配れます。チームでティアの方針を揃えたい場合はこちらが近道です。

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "ANTHROPIC_BEDROCK_SERVICE_TIER": "priority"
  }
}

対応状況はモデルとリージョンで変わる

ティアの対応状況は、モデルとAWSリージョンの組み合わせによって変わります。あるモデルでは3ティアすべて選べても、別のモデルやリージョンでは flex が使えない、といった差が起こり得ます。AWSのBedrockユーザーガイドは、対応ティアを「Models at a glance」でモデルごとに調べる構成です。

予約容量を使うなら設定はARNに一本化する

プロビジョンドスループットで予約容量を確保している場合は、ANTHROPIC_BEDROCK_SERVICE_TIER を使いません。予約容量に対応するARNをそのままモデルIDに指定します。ANTHROPIC_MODEL や modelOverrides にARNを渡す構成で、モデルの指定が容量の指定を兼ねます。

「都度リクエストで速度を選ぶ」のが default / flex / priority のオンデマンド方式、「あらかじめ確保した容量を使い切る」のがプロビジョンドスループットです。課金の仕組みが別なので、1つの設定に混ぜて考えると追いにくくなります。

AWS側のサービスティアにもReservedがあり、こちらはAWSのアカウント担当に問い合わせて契約する形で、1か月または3か月の期間で容量を確保します。予約を超えたぶんはStandardへあふれる仕様です。Claude Codeの環境変数が受け付ける値は3種類だけなので、reserved は指定できません。

Reservedの容量は、入出力のトークン毎分(tokens-per-minute)を別々に割り当てて見積もります。見積もりに使う消費量にはInputTokenCountに加えてCacheWriteInputTokensも含まれます。プロンプトキャッシュを使う構成では、CloudWatchで両方のメトリクスを合算して必要量を出します。AWSは稼働率99.5%を目標にしており、課金はAWSのアカウント担当者を通して解約するまで続きます。

最低容量は入力が100,000トークン毎分、出力が10,000トークン毎分です。料金は1,000トークン毎分あたりの固定額で、月単位で請求されます。

priority を指定してもReservedの容量は消費されません。

Bedrockのサービスティアと直接APIの優先度ティアは別物

Anthropicの直接APIにも「サービスティア」という概念がありますが、仕組みはBedrockとは別です。

くらべる

Bedrock経由と直接API、どちらの話か

ANTHROPIC_BEDROCK_SERVICE_TIER

Bedrock経由

値は default ・ flex ・ priority。リクエスト単位で指定でき、Priorityも事前の予約は要りません。

service_tierパラメータ

直接API

値は auto と standard_only の2つで、リクエストで指定できる値に priority はありません。Priority Tierで処理されたかは、レスポンスの usage.service_tier に出ます。

直接APIのPriority Tier容量コミットメントは、現在は新規購入ができません。既存の契約を持つ組織だけが、契約終了日まで使い続けられます。auto を指定すると、Priority Tier容量があればそちらを、なければ標準容量を使います。

値の名前に priority が共通して出てくるため、直接API向けの情報をBedrock環境へそのまま当てはめる誤りが起きやすい組み合わせです。Bedrock経由でClaude Codeを使っているなら、読むのは直接APIのサービスティアではなくBedrock側の仕様です。

Guardrailsとの関係

サービスティアのヘッダーは、Claude Codeが ANTHROPIC_BEDROCK_SERVICE_TIER の値から自動で組み立てて送ります。Bedrock Guardrailsのヘッダーは、ANTHROPIC_CUSTOM_HEADERS に自分で書き込む設定です。付き方が違う別々のヘッダーなので、組み立ての責任範囲は分かれています。

Bedrockの認証方式やモデルのピン留めなど、連携の設定全体はClaude Code BedrockセットアップやAWS BedrockのClaude料金でも扱っています。Invoke APIとは別の経路であるMantleエンドポイントは、ネイティブのAnthropic API形状でリクエストを送り、CLAUDE_CODE_USE_MANTLE で有効にします。IAMアクションは bedrock-mantle: プレフィックスで、bedrock: のアクションは対象外です。

選んだティアが実際に使われたかをAWS側で確かめる

指定と実際の処理は一致するとは限りません。AWSのドキュメントによると、処理されたリクエストのサービスティアはAPIレスポンスとAWS CloudTrailのイベントに残ります。CloudWatchメトリクスには、ModelId・ServiceTier・ResolvedServiceTierというディメンションがあります。実際に処理を担ったティアを示すのは、ResolvedServiceTierです。

手順

priorityが効いたかを確かめる流れ

  1. 1

    Claude Code側で指定する

    ANTHROPIC_BEDROCK_SERVICE_TIER=priority を設定して通常どおり使います。

  2. 2

    CloudWatchでModelIdを絞る

    使っているモデルのメトリクスを開き、ServiceTierとResolvedServiceTierを並べて見ます。

  3. 3

    食い違いを探す

    ResolvedServiceTierがpriority以外なら、指定が実際には反映されていません。

Bedrockで検証するときは、体感の応答速度だけで判断せず、CloudWatch側の数値を見ます。

ティアごとにIAMでアクセスを絞る

ティアごとの許可はAWS側のIAMで決まり、Claude Codeの設定ファイルでは決まりません。既定では、Bedrockの権限を持つユーザーにpriority・default・flexのすべてが使えます。明示的にDenyしない限り全ティアが使える方式です。絞るときは、bedrock:ServiceTier 条件キーを使ったIAMポリシーで特定のティアをDenyします。AWSのDenyの例は対象アクションに bedrock:InvokeModel を使い、priorityだけを拒否するなら条件値を ["priority"] にします。4つのティアをすべてDenyするポリシーは、利用者にティアを指定させず、システムの既定の挙動に固定したいときに使う例として載っています。

設定ファイルで全員に priority を配る前に、そのロールに bedrock:ServiceTier のDenyがかかっていないかをAWS側で調べます。

CI/CDのバッチ処理でflexを使う実例

非対話のバッチジョブでコストを抑えたい場合、CI環境で flex を指定する構成が典型です。GitHub ActionsでBedrockに接続する設定と組み合わせれば、ワークフローの環境変数に1行足すだけで済みます。

env:
  CLAUDE_CODE_USE_BEDROCK: '1'
  AWS_REGION: us-east-1
  ANTHROPIC_BEDROCK_SERVICE_TIER: flex

人が待つ対話的な端末では priority、待たされても困らないCI/CDの非対話ジョブでは flex。まずはこの二択から使い分けを始めます。

まとめ

設定は1行で済みますが、効くかどうかはモデル・リージョン・IAMの3か所で決まります。Claude Code側の設定だけを見ていても分かりません。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →