Claude Code Bedrock IAM設定とクロスリージョン推論プロファイルの組み方

Claude CodeをBedrockで動かす最小ポリシーには、モデル呼び出しのbedrock:InvokeModel系2つと推論プロファイル解決のbedrock:ListInferenceProfiles・bedrock:GetInferenceProfileの4つが基本です。これに、Bedrock経由の呼び出しに限る条件付きでMarketplace購読の2アクションが加わります。リージョンはAWS_REGION(未設定ならAWS_DEFAULT_REGION、AWSプロファイルのregionの順)で決まります。us-*ならus.、eu-*ならeu.、ap-*ならapac.、GovCloudではus-gov.のプレフィックスが優先されます。

Claude CodeがBedrockで求めるIAM権限

Claude CodeをAmazon Bedrock経由で使うとき、料金や認証方式より先につまずくのがIAM権限です。/setup-bedrockウィザードや環境変数で接続先を設定しても、IAMポリシーが足りなければモデル呼び出しそのものが失敗します。Amazon Q DeveloperからClaude Codeへ切り替える場合のIAM移行手順はAmazon Q Developerからの移行ガイドにまとめています。

Claude Codeが実行時に呼ぶAPIのうち、推論プロファイルを解決するbedrock:ListInferenceProfilesとbedrock:GetInferenceProfileは、解決経路を左右します。クロスリージョン推論プロファイルを使う構成では、プロファイル一覧を取得できるかどうかで可用性チェックの有無が変わり、取得できない場合は可用性を確認せずプレフィックスをそのまま適用します(詳しくは後述)。

IAMポリシーの最小構成

公式が示す最小ポリシーは次の形です。モデル呼び出しと推論プロファイル解決に加えて、Marketplace購読のアクション(aws-marketplace:ViewSubscriptions・aws-marketplace:Subscribe)も、Bedrock経由の呼び出しに限る条件付きで最小ポリシーに入っています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    },
    {
      "Sid": "AllowMarketplaceSubscription",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
      }
    }
  ]
}

Resourceはワイルドカードで書かれていますが、社内ポリシーで絞りたい場合、公式はResourceを特定の推論プロファイルARNに限定できるとしています。AWS Organizationsを使っているなら、管理アカウントからPutUseCaseForModelAccess APIを1回呼ぶだけで、子アカウントへのモデル利用許諾が自動的に広がります。この呼び出しにはbedrock:PutUseCaseForModelAccess権限が要ります。

次は絞り込みの一例で、使わせたいモデルのプロファイルARNだけを列挙する形です。クロスリージョンのプロファイルは別リージョンの基盤モデルも使うため、実際に通るかはアカウントの構成で確かめてください。

{
  "Effect": "Allow",
  "Action": [
    "bedrock:InvokeModel",
    "bedrock:InvokeModelWithResponseStream",
    "bedrock:ListInferenceProfiles",
    "bedrock:GetInferenceProfile"
  ],
  "Resource": [
    "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-opus-5-5",
    "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-6"
  ]
}

bedrock:GetInferenceProfileは、アプリケーション推論プロファイルARNをその裏側にある基盤モデルへ解決するために使われます。この解決結果でリクエスト形式(モデルごとのAPIの呼び出し方)を選んでいるため、単なる付随権限ではなく解決経路そのものに関わります。

bedrock:GetInferenceProfileを外すとどうなるか。この権限が無くても致命的なエラーにはなりません。Claude Codeはリクエスト形式を自動で切り替えて1回リトライし、結果的にリクエストは成功します。ただし新しいモデルごとに往復が1回増えるので、権限を付ければこのリトライは消えます。影響が出やすいのは、AWS_BEARER_TOKEN_BEDROCKで認証する構成です。トークンのポリシーはフルのIAMロールより狭いのが普通だからです。

専用のAWSアカウントをClaude Code用に切り分けておくと、コスト追跡とアクセス制御の両方が扱いやすくなります。請求まわりはBedrock経由の料金が直接APIとどう違うかで比べられます。

クロスリージョン推論プロファイルの仕組み

BedrockのInvoke APIを使うとき、Claude Codeは組み込みのデフォルトモデルをクロスリージョン推論プロファイルIDに解決します。プロファイルIDにはリージョン系統を示すプレフィックスが付き、Claude Codeが解決先のAWSリージョンごとに優先するプレフィックスは次の通りです。

プレフィックスの元になる「解決先のAWSリージョン」自体は、AWS_REGION→AWS_DEFAULT_REGION→アクティブなAWSプロファイルのregion(認証情報ファイル→設定ファイルの順)→us-east-1の順で決まります。いずれかの値がリージョン名の形をしていない場合はその値を無視し、次の順位に進みます。想定と違うプレフィックスが選ばれているときは、/statusで解決済みのリージョンを確認できます。AWSの設定ファイル由来のときは、出所も併記されます。

プレフィックスは「優先」であって強制ではありません。プロファイル一覧を取得できるかどうかで、解決の流れが分かれます。

逆にプロファイル一覧の取得ができない構成では、可用性を確認せずプレフィックスをそのまま適用します。権限が無くて一覧を取得できない場合も、ここに入ると考えられます。該当リージョンにそのプレフィックスのプロファイルが有効化されていないと、リクエストは400エラーで失敗します。

リージョンプレフィックスを環境変数で切り替える

組み込みのデフォルトモデルは変えず、優先プレフィックスだけ変更したい場合はANTHROPIC_BEDROCK_REGION_PREFIXを設定します。v2.1.224以降で利用でき、有効な値はus / eu / apac / jp / au / globalの6つです。

export ANTHROPIC_BEDROCK_REGION_PREFIX=global
# us-*リージョンでも、プライマリモデルは
# us.anthropic.claude-opus-5-5 ではなく
# global.anthropic.claude-opus-5-5 に解決される

アカウントにglobal.プロファイルだけを有効化していて、Claude Codeがリージョンから導出する地理系プレフィックスと噛み合わないときに使う設定です。無効な値を指定するとリージョン由来の優先プレフィックスへ静かにフォールバックし、AWS GovCloudリージョンでは変数の値にかかわらず常にus-gov.が使われます。自分でARNやプロファイルIDを直接指定した場合、Claude Codeはそれを書き換えません。

ピン留めしないと、更新のたびに既定モデルが変わる

Bedrockでの既定モデルはClaude Codeのバージョンに紐づいています。v2.1.287で動かしている環境でも、ここ数バージョンで既定は3回入れ替わりました。

見落としやすいのは費用です。主モデルを固定していない環境は、v2.1.207以降に更新した時点からOpus単価で課金されます。Sonnet 4.5を主モデルに保つならANTHROPIC_MODELにフルのモデルIDを入れます。ANTHROPIC_DEFAULT_SONNET_MODELで既定のSonnetを指定していてANTHROPIC_DEFAULT_OPUS_MODELを設定していない環境は、そのSonnetが既定のままです。

また、ピン留めが無いとopusやsonnetのエイリアスが組み込みの既定に解決され、アカウントでまだ有効化されていないモデルに当たって起動時フォールバックが起きます。ピン留めは次の3変数で行います。

export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'

このIDはus.のクロスリージョン推論プロファイルプレフィックスを使っています。別リージョン系統や、組織専用のアプリケーション推論プロファイルを使う場合はプレフィックスやARNをそこに合わせます。

ANTHROPIC_BEDROCK_REGION_PREFIXを使うと、組み込みの既定は残したまま優先プレフィックスだけが変わります。たとえばopusエイリアスは、ANTHROPIC_DEFAULT_OPUS_MODELで固定すれば指定したIDそのものに、ANTHROPIC_BEDROCK_REGION_PREFIX=euならeu.anthropic.claude-opus-5-5に解決されます。

同じモデルファミリーの複数バージョンを/modelピッカーに並べ、それぞれ別のアプリケーション推論プロファイルARNへ振り分けたい場合は、ANTHROPIC_DEFAULT_*_MODELではなく設定ファイルのmodelOverridesを使います。

{
  "modelOverrides": {
    "claude-opus-4-7": "arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/opus-47-prod",
    "claude-opus-4-6": "arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/opus-46-prod",
    "claude-opus-4-5-20251101": "arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/opus-45-prod"
  }
}

ユーザーが/modelでいずれかのバージョンを選ぶと、Claude Codeはこのマッピング先のARNでBedrockを呼びます。オーバーライドが無いバージョンは、組み込みのBedrockモデルIDか起動時に見つかった一致プロファイルにフォールバックします。

ただしアプリケーション推論プロファイルARNを指すピンは、次節のピン更新提案の対象外です。管理者が管理するARNのため、更新提案をスキップします。

起動時にモデルの可用性をどう確認しているか

Claude CodeはBedrock接続時、起動のたびに使用予定のモデルがアカウントで呼び出せるかを検証します。ピン留めしたモデルバージョンより新しいバージョンがアカウントで呼び出せる場合、ピンの更新を提案します。承諾すると新しいモデルIDがユーザー設定ファイルに書き込まれ、Claude Codeが再起動します。拒否した場合、次にデフォルトバージョンが変わるまで同じ提案は繰り返されません。

ピン留めしていない状態でデフォルトモデルがアカウントで使えない場合は、そのセッション限定でフォールバックが働きます。まず旧バージョンを試し、Opusモデルが1つも使えなければデフォルトのSonnetモデルに切り替わります。このフォールバックはセッションをまたいで保存されないため、常に同じバージョンで動かしたいなら該当モデルをアカウントで有効化するか、明示的にピン留めして固定します。

アクセスできないと判定したモデルは、そのマシンに最長1日記憶されます。その間の起動は、Bedrockへ再確認せずにそのモデルを飛ばします。現行の既定モデルについては、前回の確認から10分たつと起動時に確認し直すので、管理者が再度有効化した既定モデルは戻ってきます。記憶そのものを切るにはCLAUDE_CODE_SKIP_MODEL_ACCESS_MEMORY=1を設定します。

セッション中にモデルへのアクセスを失った場合も、リクエストを失敗させ続けず別モデルへ切り替わります。画面にはSwitched to <fallback> because <model> is not availableと出ます。切り替わるのは、ピン留めしていない階層に限られます。--fallback-modelはこの切り替えを置き換える仕組みで、v2.1.287のclaude --helpではカンマ区切りで複数のモデルを渡し、順に試すと説明されています。切り替えず失敗させたいときはCLAUDE_CODE_DISABLE_MODEL_ACCESS_FALLBACK=1です。ただしフォールバックのチェーンを設定している環境では、チェーンも外さないと切り替えが残ります。

--modelやANTHROPIC_MODELでセッションごとに特定のSonnet/Opusバージョンを指定した場合は扱いが変わります。その指定が該当エイリアスのセッション内ピンとして働き、置き換えた組み込みデフォルトの可用性チェック自体をスキップして、フォールバック通知なしにそのモデルで起動します。逆にopusのようなエイリアスや、Claude Codeが認識しないモデルID(アプリケーション推論プロファイルARNなど)はピンとして扱われません。

Mantleエンドポイントでは別のIAMアクションが要る

ここまでのbedrock:のポリシーは、Mantleエンドポイントを使うときには効きません。Mantleのアクションはbedrock-mantle:という別の接頭辞で、推論にbedrock-mantle:CreateInference、トークン数の計算にbedrock-mantle:CountTokensが要ります。

Mantleが返す403と400は、エラー文に何が書かれているかで原因が分かれます。

Guardrailsを併用するときの1点

Bedrock Guardrailsでコンテンツフィルタリングを組んでいる環境では、クロスリージョン推論プロファイルを使う設定に合わせてGuardrail側でも「Cross-Region inference」を有効にする必要があります。Guardrailが応答を途中でブロックしたときは、それまでに流れたテキストが残り、Guardrailに設定したブロック時のメッセージで返信が終わります。

よくあるつまずき

• ListInferenceProfilesだけ付け忘れる: InvokeModel系だけ許可してプロファイル系を外すと、プロファイル一覧を取得できず、可用性チェックなしでプレフィックスを適用する経路に入ると考えられる。該当プロファイルが無い場合は400エラーになる
• リージョンとSSOのリージョンを混同する: sso_regionとBedrockを呼ぶリージョンは別物。IAM Identity Centerが別リージョンにあるプロファイルは、v2.1.207でBedrock側のリージョンに上書きされ、Session token not found or invalidで認証に失敗した。v2.1.208で修正済み。発症時の具体的な切り分け手順は「Session token not found」— Bedrockでの原因と直し方で扱っています
• ANTHROPIC_BEDROCK_REGION_PREFIXに無効な値を渡す: us / eu / apac / jp / au / global以外の文字列を入れても即座にエラーにはならず、リージョン由来の優先プレフィックスへ静かにフォールバックする。意図した振り分けになっているかは/statusで確認する
• on-demand throughput isn't supportedが出る: モデルを推論プロファイルIDで指定していないときのエラー。us.anthropic.claude-...のようなプロファイルIDに替える。Claude CodeはBedrockのInvoke APIを使い、Converse APIには対応しない
• ゲートウェイ越しにストリーミングが壊れる: ゲートウェイがContent-Typeをtext/event-streamなどに書き換えると、Bedrock streaming response has content-typeで始まるエラーになる。BedrockはInvokeModelWithResponseStreamの応答をapplication/vnd.amazon.eventstreamで返すので、本文とヘッダーを無加工で転送させる。ヘッダーを落としたうえでSSEに変換する構成では、各応答が完成してから表示される遅い経路に落ちる。この場合はCLAUDE_CODE_DISABLE_BEDROCK_CONTENT_TYPE_DEFAULT=1でSSEとして読ませる
• modelOverridesとピン留め変数を両方設定して混乱する: 単一のモデルファミリーを1つの推論プロファイルに固定するだけならANTHROPIC_DEFAULT_*_MODELで足りる。複数バージョンを併存させたい場合だけmodelOverridesに切り替える

まとめ

IAMは、モデル呼び出しに加えてListInferenceProfiles・GetInferenceProfile・Marketplace購読まで揃えておくと、プレフィックスの解決も起動時チェックも想定どおりに動きます。複数ユーザーへ配るなら、モデルはピン留めして更新による既定の入れ替わりと単価の変化を避け、複数バージョンを併存させたいときだけmodelOverridesを使います。