Claude CodeをAmazon Bedrockで動かす：環境変数・モデルID・社内統制の設定手順

「Claude Code、便利そうだから入れていい？」と社内で聞いたら、情シスから返ってきたのは「APIキーはどこに保存されるの？ログは？請求は誰の口座？」でした。

僕の環境は全部AWSアカウントの統制下にあって、外部SaaSにAPIキーを置くだけで稟議が一段増えます。Anthropicに直接つなぐ個人利用なら一瞬なのに、会社のルールに乗せた瞬間、話が止まる。あの感覚、わかる人いると思います。

抜け道は意外と地味でした。Claude Codeは、バックエンドをAnthropicの直接APIからAmazon Bedrockに丸ごと切り替えられます。認証はAWSのIAMロール、ログはCloudWatch、請求はいつものAWS請求にまとまる。新しい鍵を増やさずに、既存のAWS統制にClaude Codeを丸ごと乗せられるわけです。

この記事は、その切り替えを「環境変数1つで終わり」では済まさず、モデルアクセス申請・リージョン・モデルID・IAM・コスト管理まで、社内に説明できる粒度でまとめます。2026年6月7日時点の公式ドキュメントを基準にしていますが、モデルIDと対応リージョンと料金は変わるので、最後は必ず公式で確認してください。

この記事の要点

• Claude Codeは CLAUDE_CODE_USE_BEDROCK=1 と AWS_REGION で、AnthropicAPIではなくBedrock経由でClaudeを呼ぶようになる。新しいAPIキーは不要で、認証はAWSの仕組みに乗る。
• 最短ルートは claude を起動して「3rd-party platform」→「Amazon Bedrock」を選ぶログインウィザード。チーム配布やCIなら環境変数で手動設定する。
• AnthropicモデルはAWSアカウントごとに「First Time Use（用途申告）フォーム」の提出が一度だけ必要。これを忘れると AccessDeniedException で止まる。
• モデルIDは固定値で覚えず、us. で始まるクロスリージョン推論プロファイルIDを環境変数で指定し、チーム配布時はバージョンを固定（pin）する。
• 料金・対応リージョン・最新モデルIDは変動するので、断言せずAWS公式の料金表とモデル一覧で確認する。

Bedrock経由にすると何が変わるのか

ふだんのClaude Codeは、起動するとAnthropicのサーバーに直接つなぎます。ログインもAnthropic側のアカウント。これを「直接API」と呼びます。

Bedrock経由にすると、つなぎ先が自分のAWSアカウントの中に変わります。Bedrockは、ClaudeのようなモデルをAWSの認証・権限・ログ・請求の仕組みに乗せて呼び出すためのマネージドサービスです。要するに、モデルそのものはAnthropic製のまま、入口だけAWSの正面玄関に付け替えるイメージです。

社内統制の目線だと、これで効く点が3つあります。

観点	直接API	Bedrock経由
認証	Anthropicのアカウント/APIキー	AWSのIAMロール・SSO・一時認証情報
ログ	Anthropic側に依存	CloudWatch Logs / S3に集約できる
請求	Anthropicへの別請求	いつものAWS請求に合流
ネットワーク	外部SaaSへ直接	VPCエンドポイント等のAWS統制下に置ける
安全柵	プロンプト側で工夫	Bedrock Guardrailsをヘッダで適用可能

逆に、Bedrock経由には制約もあります。公式が明記しているのは次の3つです。先に知っておくと事故りません。

• /logout コマンドが使えません。認証をAWS側に委ねているためです。
• WebSearchツールがBedrockでは使えません。Claude Codeの中からのウェブ検索に頼っているワークフローは見直しが要ります。
• Claude CodeはBedrockの Invoke API を使い、Converse APIは使いません（独自アプリをConverseで書くのとは別の話です）。

「とりあえず動けばいい」なら直接APIで十分です。Bedrockに寄せる価値が出るのは、まさに冒頭の情シスの質問に答えないといけない会社ユースケースなんですね。

まず通すべき関門：モデルアクセス申請

コードより先に詰まるのが、ここです。僕も最初、環境変数だけ設定して claude を叩いて AccessDeniedException を食らいました。原因はモデル側の準備不足でした。

AWS公式によると、Bedrockの基盤モデルは、適切なAWS Marketplace権限があれば既定で有効になっています。ただしAnthropicモデルだけは別で、初回利用時に「First Time Use（FTU）フォーム」の提出が一度だけ必須です。これはアカウントごと（AWS Organizations配下なら管理アカウントで一度）に必要で、用途の説明とウェブサイトURLを求められます。個人開発者なら、会社サイトの代わりにGitHubプロフィールやポートフォリオのURLでも通ります。

やることはシンプルです。

1. IAMに必要な権限（後述）を付ける。
2. Amazon Bedrockコンソール を開く。
3. 「Model catalog（モデルカタログ）」からAnthropicのモデルを選ぶ。
4. 表示される用途申告フォームを送信する。送信直後にアクセスが付与されます。

ここで自分のアカウントとリージョンで実際にどのClaudeモデルが呼べるかを、コマンドで確認しておきます。Claude CodeはInvoke APIで推論プロファイル経由の呼び出しになるので、推論プロファイル一覧も見ておくと後で楽です。

export AWS_REGION=us-east-1

# このリージョンで使えるAnthropicモデル一覧
aws bedrock list-foundation-models \
  --region "$AWS_REGION" \
  --query "modelSummaries[?providerName=='Anthropic'].[modelId,modelName]" \
  --output table

# クロスリージョン推論プロファイル（us. で始まるID）の確認
aws bedrock list-inference-profiles \
  --region "$AWS_REGION" \
  --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'anthropic')].[inferenceProfileId,status]" \
  --output table

注意点を1つ。AccessDeniedException の原因はFTUフォーム未提出だけではありません。AWS Marketplace権限（aws-marketplace:Subscribe など）、有効な支払い方法、組織のSCPによるブロック、これらが欠けても同じエラーになります。自動サブスクリプションの確定には最大15分かかる場合があるとも公式は書いています。コードを疑う前に、この4点を先に潰してください。

最短ルート：ログインウィザードで切り替える

個人や検証用なら、環境変数を手で書く必要すらありません。Claude Codeにウィザードが入っています。

claude

ログインプロンプトで「3rd-party platform」を選び、続けて「Amazon Bedrock」を選ぶだけ。あとはウィザードが、AWSへの認証方法（~/.aws から見つかったプロファイル、Bedrock APIキー、アクセスキー＆シークレット、環境にある認証情報のいずれか）を聞いてきます。

ウィザードは賢くて、リージョンを拾い、あなたのアカウントで実際に呼べるClaudeモデルを検証し、それをpin（固定）するところまでやってくれます。結果はユーザー設定ファイルの env ブロックに書き込まれるので、自分で環境変数をexportする必要はありません。

設定をやり直したくなったら、いつでも次で同じウィザードを開けます。

/setup-bedrock

ここで認証情報・リージョン・モデルpinを変更できます。「とりあえず自分のマシンで動かしたい」なら、この章だけで完結します。次章からは、チーム配布やCI向けに「中身を理解して手で設定する」話に入ります。

手で設定する：環境変数を理解する

CIや社内一括配布では、ウィザードではなく環境変数で固定したくなります。Claude Codeは標準のAWS SDK認証チェーンを使うので、認証情報は普通のAWS流儀で渡せます。

まず認証情報。次のいずれかでOKです。

# 方法A: AWS CLIで設定済みのプロファイルを使う
aws configure

# 方法B: アクセスキーを環境変数で渡す（一時認証情報なら SESSION_TOKEN も）
export AWS_ACCESS_KEY_ID=your-access-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-access-key
export AWS_SESSION_TOKEN=your-session-token

# 方法C: SSOプロファイル（企業環境ではこれが多い）
aws sso login --profile=your-profile-name
export AWS_PROFILE=your-profile-name

# 方法D: Bedrock APIキーだけで簡易認証
export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key

次がClaude Code本体のスイッチです。コピペで動く最小セットがこれです。

# Bedrockバックエンドを有効化
export CLAUDE_CODE_USE_BEDROCK=1

# リージョンは必須。Claude Codeは .aws の config からは読まない
export AWS_REGION=us-east-1

# 起動確認（プロバイダ表示を見る）
claude
/status

ここで覚えておくべき落とし穴を1つ。AWS_REGION は必須の環境変数で、Claude Codeはこの値を .aws/config からは読みません。「プロファイルにリージョン書いたのに動かない」はだいたいこれです。

主要な環境変数を表で整理します。

環境変数	役割
CLAUDE_CODE_USE_BEDROCK	1 でBedrockバックエンドを有効化
AWS_REGION	呼び出しリージョン（必須）
ANTHROPIC_MODEL	使う主モデルのID（推論プロファイルIDまたはARN）
ANTHROPIC_DEFAULT_OPUS_MODEL	opus エイリアスの解決先を上書き
ANTHROPIC_DEFAULT_SONNET_MODEL	sonnet エイリアスの解決先を上書き
ANTHROPIC_DEFAULT_HAIKU_MODEL	背景タスク用の軽量モデルを指定
DISABLE_PROMPT_CACHING	1 でプロンプトキャッシュを無効化
ANTHROPIC_BEDROCK_SERVICE_TIER	default/flex/priority でコストと遅延を調整

リージョンとモデルIDの決め方

ここがBedrockならではのつまずきポイントなので、1章まるごと割きます。

Bedrockでは、Claudeを呼ぶときにクロスリージョン推論プロファイルIDを使うのが基本です。これは us.anthropic.claude-... のように us. で始まるIDで、複数リージョンに負荷を分散してくれる仕組みです。素のファウンデーションモデルIDを直接指定すると「on-demand throughput isn’t supported」エラーが出ることがあり、その場合は推論プロファイルIDに切り替えます。

チームに配るなら、モデルバージョンのpin（固定）が事実上必須です。理由は公式の警告どおりで、sonnet や opus のエイリアスはClaude CodeのBedrock向け既定値に解決され、それが最新リリースに遅れていたり、あなたのアカウントでまだ有効化されていなかったりするからです。pinしておけば「いつ新モデルに乗り換えるか」を自分で制御できます。

# クロスリージョン推論プロファイルIDでバージョンを固定する例
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'

# 主モデルを直接指定したいとき
export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-6'

# 組織のアプリケーション推論プロファイルARNを使う場合
export ANTHROPIC_MODEL='arn:aws:bedrock:us-east-2:your-account-id:application-inference-profile/your-model-id'

上のモデルIDは「書き方の例」であって、永久に正しい値ではありません。最新の正しいIDは Models overview（モデル一覧） と、自分のアカウントで叩いた list-inference-profiles の結果で確認してください。記事のコピペで固定するのが一番やりがちな失敗です。

背景タスク（セッションタイトル生成など）について1つ補足します。Claude Codeは通常Haikuクラスの軽量モデルを背景タスクに使いますが、BedrockではHaikuが全アカウント・全リージョンで有効とは限らないため、既定では主モデルを流用します。背景タスクをHaikuにしたいなら、ANTHROPIC_DEFAULT_HAIKU_MODEL に自分のアカウントで使えるIDを明示します。

IAMと設定ファイル

社内に出すなら、認証情報をシェルにexportしっぱなしにせず、設定ファイルに寄せたほうが安全です。AWS_PROFILE のような値を他プロセスに漏らさずに済みます。

まずIAMポリシー。Claude Codeに必要な最小権限は公式が例を出しています。

{
  "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 を特定の推論プロファイルARNに絞れば、さらに締められます。最小権限の考え方はClaude Code × AWS IAMガイドで扱った設計と同じで、「使うモデルとプロファイルだけ許可する」が基本です。

次に設定ファイル。SSOの自動再認証や、Guardrails（安全柵）のヘッダはここに書きます。ユーザー設定ファイルの env ブロックに入れる例です。

{
  "awsAuthRefresh": "aws sso login --profile myprofile",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "AWS_PROFILE": "myprofile",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-4-6",
    "ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: your-guardrail-id\nX-Amzn-Bedrock-GuardrailVersion: 1"
  }
}

awsAuthRefresh は、Claude Codeが認証情報の期限切れを検知したときだけ走り、ブラウザSSOフローに向いています。ただし企業VPNやTLSインスペクションのプロキシ環境だと、SSOのブラウザ往復が中断されて無限ループになることがあります。その場合は awsAuthRefresh を消して、claude 起動前に手で aws sso login を済ませるのが安定します。

Guardrailsを使うなら、Bedrockコンソールで作成してバージョンを発行し、上のように X-Amzn-Bedrock-GuardrailIdentifier と X-Amzn-Bedrock-GuardrailVersion ヘッダで適用します。クロスリージョン推論プロファイルを使うなら、Guardrail側でもCross-Region inferenceを有効にしておきます。

なお、起動時にClaude Codeは「指定モデルが自分のアカウントで呼べるか」を検証します（この挙動はClaude Code v2.1.94以降が必要）。pinしたバージョンが古く、より新しい版が使えるなら更新を促してきますし、pinなしで既定が使えないときは前バージョンに一時フォールバックして通知を出します。

コストとクォータを社内で説明できる形にする

最後はお金とレート制限の話です。会社で使うなら、ここを言語化できないと続きません。

料金は固定値で覚えないでください。単価はモデルとリージョンで変わります。必ず Amazon Bedrock Pricing（料金表） で、自分が使うモデルとリージョンの最新単価を確認します。記事や古いメモの価格表を信じると、見積もりが普通にずれます。

そのうえで、コストを抑える実務的なレバーは次のあたりです。

• モデルを用途で分ける。 分類・抽出・短い整形は軽いモデル、設計レビューや長文は高性能モデル、というふうにpinを使い分けます。
• サービスティアでコストと遅延を調整する。 ANTHROPIC_BEDROCK_SERVICE_TIER を flex にするとコスト寄り、priority にすると遅延寄りになります（ティアの可否はモデルとリージョン依存）。
• プロンプトキャッシュを意識する。 長い固定システムプロンプトを毎回送るなら効きます。逆に毎回変わる短い文脈では効果が薄いので、必要なら DISABLE_PROMPT_CACHING=1 で切ります。リージョンによってはキャッシュ自体が使えないこともあります。
• 請求をチーム単位で見える化する。 専用のAWSアカウントをClaude Code用に切ると、コスト追跡とアクセス制御が一気に楽になる、と公式も推奨しています。

クォータ（レート制限）に当たったときの動きも先に決めておきます。トークン消費とクォータの考え方は Bedrock token burndown and quotas にまとまっています。リージョンでスロットリングが厳しいなら、クロスリージョン推論プロファイルで分散させるか、AWS_REGION を供給に余裕のあるリージョンへ寄せるのが現実解です。コスト最適化の全体像はClaude CodeのAPIコスト削減ガイド、設定変更を後から追えるようにする作業証跡は検証レシートワークフローと合わせると、社内レビューに耐える形になります。

よくある質問

Q. Bedrock経由だと、いつものClaude Codeと使い勝手は変わりますか？ ほとんど同じです。コマンドもワークフローもそのまま。違いは、認証がAWS側になるため /logout が使えないことと、WebSearchツールがBedrockでは使えないことです。現在のバックエンドは /status で確認できます。

Q. APIキーを新しく発行しないといけませんか？ いいえ。aws configure やSSO、IAMロールなど既存のAWS認証をそのまま使えます。鍵を増やしたくない場合は、これがBedrock経由の一番のメリットです。簡易にやりたいなら AWS_BEARER_TOKEN_BEDROCK（Bedrock APIキー）という選択肢もあります。

Q. AccessDeniedException が出ます。何を見ればいいですか？ まずAnthropicモデルのFirst Time Useフォームを提出済みか確認します。次にAWS Marketplace権限、支払い方法、組織のSCPによるブロックを順に潰します。自動サブスクリプションの確定に最大15分かかる場合がある点にも注意します。

Q. モデルIDはどれを指定すればいいですか？ 記事の値をそのままコピペしないでください。us. で始まるクロスリージョン推論プロファイルIDが基本で、正しいIDは公式のモデル一覧と、自分のアカウントで叩いた aws bedrock list-inference-profiles の結果で確認します。チーム配布時はバージョンをpinします。

Q. 料金は結局いくらですか？ モデルとリージョンで変わるので、この記事では断言しません。Bedrockの料金表で対象モデルの最新単価を見るのが唯一の正解です。コストはモデルの使い分け、サービスティア、プロンプトキャッシュで調整できます。

実際に試した結果

自分の環境でAnthropic直接APIからBedrock経由に切り替えてみて、一番効いたのは「コードを書くこと」ではなく設定を環境変数とIAMに分けて言語化したことでした。CLAUDE_CODE_USE_BEDROCK=1 と AWS_REGION だけでバックエンドは切り替わりますが、情シスを納得させたのはそこではなく、IAMポリシーで呼べるモデルを絞り、env ブロックでGuardrailを付け、請求を専用アカウントに寄せた、という説明可能な構成のほうでした。

つまずきは全部モデル側で起きました。AccessDeniedException は3回踏みましたが、どれもコードのバグではなく、FTUフォーム未提出かMarketplace権限不足。コードを疑う前にモデルアクセスを確認する、という順番を身体で覚えたのが収穫です。

社内のAWS統制下でClaudeやClaude Codeを使うなら、Bedrock経由は遠回りに見えて結局いちばん通しやすい道でした。自分の構成に合わせたIAMレビューやpin戦略、CLAUDE.mdまで整えたい場合は、商品一覧のテンプレートやClaude Code研修・導入相談が次の入口になります。最後にもう一度だけ。モデルID・対応リージョン・料金は変わるので、本番に入れる前に必ず公式で確認してください。