AWS_BEARER_TOKEN_BEDROCKとは — BedrockをAPIキーで認証する変数
AWS_BEARER_TOKEN_BEDROCKはAmazon Bedrock APIキーでClaude Codeを認証する環境変数です。フルAWS認証との違い、設定方法、注意点をまとめます。
AWS_BEARER_TOKEN_BEDROCK は、Amazon Bedrock APIキー1本でClaude Codeを認証する環境変数です。アクセスキーとシークレット、セッショントークン、AWSプロファイルといったフルセットのAWS認証情報を組まずに済み、CI環境やスクリプトでの配布に向いています。Claude Code v1.0.51で追加され、Amazon Bedrock経由の認証方式の1つです。
他の認証方式と何が違うか
Claude CodeがAmazon Bedrockに接続する認証方式は5つあります。AWS_BEARER_TOKEN_BEDROCK はそのうちの1つで、他の4つとは仕組みそのものが異なります。
| 方式 | 必要なもの | 向く場面 |
|---|---|---|
AWS CLI設定(aws configure) | 必要なものアクセスキーとシークレット | 向く場面個人の開発端末 |
| 環境変数(アクセスキー) | 必要なものAWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN | 向く場面CI・一時的な認証 |
| 環境変数(SSOプロファイル) | 必要なものAWS_PROFILE + aws sso login | 向く場面組織のSSO環境 |
| AWS Management Console認証 | 必要なものaws login | 向く場面ブラウザ経由のサインイン |
| Bedrock APIキー | 必要なものAWS_BEARER_TOKEN_BEDROCK 1つ | 向く場面フルAWS認証情報を配りたくない場面 |
上4つはAWSのデフォルト認証プロバイダーチェーンを経由します。Claude Codeはこのチェーンを1度だけ解決してメモリー上に保持し、有効期限の5分前まで、あるいは期限の情報を持たない場合は1時間まで使い回します。API側からの認証エラーが起きるとキャッシュをクリアして再解決する仕組みです(v2.1.207以降)。
Bedrock APIキーはこのチェーンを経由しません。キー自体が認証情報そのものとして扱われるため、チェーンの解決プロセスもキャッシュの対象からも外れます。この違いが実務上の利点と制約の両方につながります。
設定のしかた
Amazon Bedrock APIキーは、AWS側で発行します。Bedrockコンソールの画面でAPIキーを発行し、表示された値を控えておく、という流れです。アクセスキーとシークレット、セッショントークンをそれぞれ個別に用意して組み合わせる必要はなく、控えたキー1つだけを扱えば済みます。取得したキーを環境変数として渡すだけで設定が完了します。詳しい仕組みはBedrock APIキーに関するAWSの解説にまとまっています。
export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key
export CLAUDE_CODE_USE_BEDROCK=1
claude手動設定やCI・スクリプトでの一括配布では、AWS_BEARER_TOKEN_BEDROCK に加えて CLAUDE_CODE_USE_BEDROCK=1 を必ず一緒に設定します。前者は認証情報、後者はAmazon Bedrockを使うこと自体を有効にするフラグで、役割が別だからです。リージョンを明示したい場合は AWS_REGION も併せて設定します。
対話的に設定したい場合は、claude 起動時のログインプロンプトで3rd-party platform → Amazon Bedrockを選ぶウィザードでも、認証方式の選択肢の1つとしてBedrock APIキーが用意されています。ウィザードを使うと ~/.claude/settings.json の env ブロックに結果が保存され、以後は環境変数を手で管理する必要がなくなります。
{
"env": {
"AWS_BEARER_TOKEN_BEDROCK": "your-bedrock-api-key",
"CLAUDE_CODE_USE_BEDROCK": "1"
}
}クレデンシャルキャッシュの対象外という制約
Amazon BedrockのフルAWS認証(アクセスキーやSSOプロファイル)は、前述のとおりクレデンシャルチェーンをキャッシュして使い回します。この仕組みが持つ60秒のチェーン解決タイムアウトや、環境変数 CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS によるタイムアウト延長も、チェーンを経由する認証方式だけが対象です。
Bedrock APIキーはこのチェーン自体を通らないため、AWS default-chain credential resolve timed out というエラー(AWS default-chain credential resolve timed outの対処参照)の対象にもなりません。credential_process コマンドが応答を待って固まる、インスタンスメタデータサービス(IMDS)への問い合わせが返らない、といったチェーン特有のトラブルを構造的に避けられるのが、Bedrock APIキーを選ぶ実務上の利点です。
一方で、キャッシュ対象外という性質は逆方向にも働きます。CLAUDE_CODE_SKIP_AWS_CRED_CACHE はキャッシュを無効化してチェーンを毎回解決し直す設定ですが、これはチェーンを使う認証方式にのみ意味を持つ変数で、Bedrock APIキーには関係しません。
IAM権限が絞られやすい点に注意
Bedrock APIキーの認証情報は、フルIAMロールと比べてポリシーが狭く発行されることが多い運用です。bedrock:GetInferenceProfile 権限が欠けていると、挙動が変わります。この権限は、Claude Codeがアプリケーション推論プロファイルARNを背後の基盤モデルへ解決するために使われるものです。
権限が無いとどうなるかというと、リクエストが失敗するわけではありません。Claude Codeは別のリクエスト形式で1回だけ自動的に再試行し、結果としてリクエストは成功します。ただし新しいモデルを使うたびに余分な往復が発生します。再試行を避けたい場合は権限を付与します。この状況が最も起こりやすいのがBedrock APIキーでの運用です。フルIAMロールより狭いポリシーで発行される構成が多いためです。
Bedrock連携全体の環境変数を見る
Amazon Bedrockを有効にする一連の環境変数の全体像です。
# Bedrock連携を有効化
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
# 認証(5方式のいずれか。ここではBedrock APIキー)
export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key
# 任意: small/fastモデルのリージョンを個別指定
export ANTHROPIC_SMALL_FAST_MODEL_AWS_REGION=us-west-2リージョンの解決順序は AWS_REGION → AWS_DEFAULT_REGION → AWSプロファイルのregion → us-east-1 の順です(v2.1.172以降)。設定できているかは /status で確認できます。
Claude Platform on AWSとの関係
似た名前の製品に、AWS上で提供されるClaude Platform on AWSがあります。名前だけを見ると混同しやすいものの、これはAmazon Bedrockとは別のプロダクトで、有効化には CLAUDE_CODE_USE_ANTHROPIC_AWS という別の変数を使います。リージョン解決の優先順位はAmazon Bedrockと同じ仕組みに揃えられていますが、認証まわりの環境変数はAmazon Bedrock向けのものとは別立てです。AWS_BEARER_TOKEN_BEDROCK という名前に「Bedrock」が含まれているとおり、この変数はAmazon Bedrock専用で、Claude Platform on AWSやGoogle Cloud's Agent Platform、Microsoft Foundryといった他のプロバイダー経由の認証には使えません。名前の似た製品を併用する構成では、どの変数がどのプロバイダー向けかを取り違えないことが設定ミスを防ぐ近道です。
Amazon BedrockのClaude料金と直接APIの違い
Bedrock経由の利用は、認証方式だけでなく課金体系も直接APIとは別です。トークン単価やリージョンごとの提供状況、直接契約との比較はAWS BedrockのClaude料金にまとめています。Bedrock全体の設定手順やモデルバージョンの固定はClaude Code環境変数リファレンスでも扱っています。
よくある質問
AWS_BEARER_TOKEN_BEDROCKだけ設定すればAmazon Bedrockを使えますか
いいえ。CLAUDE_CODE_USE_BEDROCK=1 を併せて設定する必要があります。対話的なログインウィザードを使う場合は、選択した認証方式に応じて必要な設定がまとめて保存されるため、この点を意識せずに済みます。
アクセスキー認証からBedrock APIキーに切り替えると挙動は変わりますか
クレデンシャルの解決経路が変わります。アクセスキーやSSOプロファイルはAWSのデフォルト認証プロバイダーチェーンを経由してキャッシュされますが、Bedrock APIキーはチェーンを経由せず、キャッシュの対象にもなりません。チェーン解決に起因するタイムアウトやエラーを避けられる一方、CLAUDE_CODE_SKIP_AWS_CRED_CACHE のようなチェーン向けの制御変数は効きません。
Mantleエンドポイントでも使えますか
Mantleエンドポイントは同じAWS認証情報とIAM権限を使う仕組みとして案内されています。認証方式そのものを切り替えるものではないため、Bedrock APIキーで認証した状態からMantleへ切り替えることも構成として成立します。
CLAUDE_CODE_SKIP_BEDROCK_AUTHとの違いは何ですか
役割が逆です。AWS_BEARER_TOKEN_BEDROCK はAmazon Bedrockへの認証情報そのものを渡す変数で、CLAUDE_CODE_SKIP_BEDROCK_AUTH はLLMゲートウェイ経由の利用などでAWS認証そのものをスキップするための変数です。v2.1.96では、この2つの変数を使う構成で403エラー「Authorization header is missing」が起きるリグレッションが一時発生し、その後修正されています。
まとめ
AWS_BEARER_TOKEN_BEDROCK は、フルAWS認証情報を組まずにAmazon Bedrock経由でClaude Codeを認証するための環境変数です。CLAUDE_CODE_USE_BEDROCK=1 と組み合わせて設定し、AWSのデフォルト認証プロバイダーチェーンを経由しないぶん、チェーン特有のタイムアウトやキャッシュの対象外になります。IAM権限がフルロールより狭く発行されやすい運用形態でもあるため、bedrock:GetInferenceProfile のような細かな権限の有無が、余分なリクエスト往復として表面化しやすい点は覚えておく価値があります。
CI・スクリプトでの一括配布に向く反面、個々の開発端末ではSSOプロファイルの方が扱いやすい場面もあります。どちらを選ぶかは、認証情報を配る相手が人か自動化されたパイプラインかで判断すると迷いにくくなります。