Claude Code Bedrockサービスティア — コストと速度を環境変数で切り替える

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

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

Amazon Bedrockのサービスティアは、AWSがInvoke API向けに用意した3段階の提供水準です。同じモデル・同じプロンプトでも、選んだティアによって単価とレイテンシーの傾向が変わります。一般的な傾向として、優先度を上げるほど料金は上がり応答は速くなるトレードオフです。

どのティアが実際にどれだけ速くなるか、どれだけ安くなるかという数値はAWS側の裁量で、Anthropicの公式ドキュメントには載っていません。Claude Codeが担うのはヘッダーを付けてリクエストを送るところまでで、実際の割り当てや料金への反映はBedrock側の実装です。

設定のしかた

環境変数を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)はこの変数を扱いません。ウィザードの範囲は認証方式・リージョン・モデルのピン留めに限られるため、サービスティアを使いたい場合は手動で環境変数を追加するか、ユーザー設定ファイル(~/.claude/settings.json の env ブロックなど)に書き足します。組織配布では設定ファイル経由のほうが、端末ごとに環境変数を設定し直す手間を避けられます。プロジェクト単位の設定ファイルに書いておけば、リポジトリを開いた全員に同じティアを配れるので、チームでティアの方針を揃えたい場合はこちらが近道です。

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

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

ティアの対応状況は、モデルとAWSリージョンの組み合わせによって変わります。あるモデルでは3ティアすべて選べても、別のモデルやリージョンでは flex が使えない、といった差が実際に起こり得ます。

対応外のティアを指定した場合にClaude Code側がどう振る舞うか(エラーになるのか、標準ティアへ自動でフォールバックするのか)は、公式ドキュメントに明記がありません。想定外の挙動を避けるには、事前確認を省かないことが実務上の近道です。

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

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

つまり「どのくらいの応答速度がほしいか」を都度リクエストで選ぶのが default / flex / priority のオンデマンド方式で、「あらかじめ確保した容量をそのまま使い切る」のがプロビジョンドスループットです。両者はBedrock側の別の課金モデルなので、混在させて考えないほうが設定を追いやすくなります。

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

紛らわしい点として、Anthropicの直接APIにも「サービスティア」という概念があります。名前は似ていますが、仕組みはBedrock側とまったく別です。

直接APIの service_tier パラメータが受け付ける値は auto と standard_only の2つで、priority は値としては存在しません。Priority Tierは容量コミットメント契約を結んだ組織だけが対象になる仕組みで、auto を指定するとPriority Tier容量が使える場合はそちらへ、なければ標準ティアへ自動でフォールバックします。入力トークンと出力トークンの消費レートも、キャッシュ読み書きの種類ごとに細かく決まっており、Bedrockの flex / priority のような単純な二択・三択ではありません。

一方、Bedrockの ANTHROPIC_BEDROCK_SERVICE_TIER はAWS側が独自に用意した仕組みで、容量コミットメント契約は前提になりません。値の名前に priority が共通して出てくるため、直接API向けの情報をBedrock環境にそのまま当てはめてしまう誤りが起きやすい組み合わせです。Bedrock経由でClaude Codeを使っているなら、参照すべきは直接APIのサービスティアではなく、Amazon Bedrock側のサービスティアの仕様だと覚えておくと迷いません。

Guardrails・Mantleエンドポイントとの組み合わせ

サービスティアのヘッダーは、Claude Codeが ANTHROPIC_BEDROCK_SERVICE_TIER の値から自動で組み立てて送るものです。これに対してBedrock Guardrailsのヘッダーは、ANTHROPIC_CUSTOM_HEADERS に自分で書き込む設定です。送信の仕組みが違うだけで、両者は別々のヘッダーとして共存でき、サービスティアを指定しながらGuardrailsも併用する構成に支障はありません。

Amazon Bedrockには、Invoke APIとは別にMantleエンドポイントという選択肢もあります。ネイティブのAnthropic API形状でリクエストを送る経路で、CLAUDE_CODE_USE_MANTLE を設定して有効にします。ただし、Mantle経由でも ANTHROPIC_BEDROCK_SERVICE_TIER が同じように効くかどうかは、公式ドキュメントのService tiers節では明記されていません。Mantleを使う構成でサービスティアも指定したい場合は、想定どおりに反映されているかを個別に確かめておくのが無難です。

Bedrockの認証方式やモデルのピン留めなど、連携の設定全体はClaude Code BedrockセットアップやAWS BedrockのClaude料金でも扱っています。

選んだティアが実際に反映されたかは確認できない

直接APIでは、レスポンスの usage オブジェクトに service_tier フィールドが含まれ、どのティアが実際に割り当てられたかをレスポンスから読み取れます。Amazon BedrockのInvoke APIをClaude Code経由で使う場合、同等のフィールドが返ってくるという記載は公式ドキュメントにありません。ANTHROPIC_BEDROCK_SERVICE_TIER を priority に設定しても、そのリクエストが実際に優先処理されたのかをClaude Code側から確かめる手立ては用意されていないことになります。挙動の違いを検証したいなら、体感の応答速度に加えて、AWS側のCloudWatchメトリクスのようなBedrockのモニタリング機能を併用するのが現実的です。

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。まずはこの二択から使い分けを始めると迷いにくくなります。

変数を設定しなければ、Claude Codeは X-Amzn-Bedrock-Service-Tier ヘッダーそのものをリクエストに含めません。省略時にBedrock側がどのティアとして扱うかは、AWSの既定動作に委ねられます。

まとめ

ANTHROPIC_BEDROCK_SERVICE_TIER は、Amazon Bedrock経由でClaude Codeを使うときにコストとレイテンシーのバランスを選ぶ環境変数です。default ・ flex ・ priority の3値を、CLAUDE_CODE_USE_BEDROCK=1 と組み合わせて設定するだけで、実際の割り当てはAWS側のBedrockが担います。対応状況はモデルとリージョンで変わるため本番投入前の確認が欠かせず、予約容量を使う構成ではこの変数自体を使わずARNをモデルIDに指定します。直接APIの service_tier パラメータとは名前が似ているだけで仕組みは別物なので、Bedrock環境の設定を調べるときはBedrock側のドキュメントを当たるのが近道です。

よくある質問

flexティアを使うとどれくらい応答が遅くなりますか

具体的な数値はAWS側の裁量で決まり、Anthropicの公式ドキュメントには記載がありません。コストを抑えたい非対話のバッチ処理から試し、実測で許容できる範囲かを確認するのが確実です。

Bedrock APIキー(AWS_BEARER_TOKEN_BEDROCK)で認証していても使えますか

使えます。サービスティアの指定は認証方式とは独立した設定で、フルAWS認証・Bedrock APIキーのどちらでも同じ環境変数が有効です。

1Mトークンのコンテキストウィンドウと同時に設定できますか

できます。1Mコンテキストウィンドウはモデル選択に関わる設定(対象モデルの利用や、モデルIDへの [1m] 付加)で、サービスティアはリクエストごとの優先度に関わる設定です。互いに独立した軸なので、両方を同時に指定しても競合しません。