ClaudeをBedrock経由で使うための認証方法まとめ

本記事は夏休みクラウド自由研究2026 8/5付の記事です。

こんにちは。SCSKのすぐろです。

今回はClaude(CLI/Desktop)をAmazon Bedrock経由で使う際に、選択可能なAWSへの認証方法がいくつかあるのでユースケース別に整理してみました。

まず結論
前提: 設定はどこに書かれるのか
モデルIDはどこで確認するか
① aws login
② aws sso login
③ Bedrock APIキー（短期）
④ Bedrock APIキー（長期）
⑤ AssumeRole（IAMロールの引き受け）
⑥ IAMユーザーの長期アクセスキー（非推奨・最終手段）
Claude Code側の共通設定まとめ
Claude Desktopの設定まとめ
参考資料

まず結論

ユースケース	使う方法
IAM Identity Center（組織インスタンス）が使えない、または個人利用で、静的なアクセスキーを使わずコマンド一つで認証を通したい	① aws login
IAM Identity Center（組織インスタンス）が使える／既存のADなどの社内アカウントでAWSにもログインしたい	② aws sso login
一番手軽に試したい・短時間だけ使いたい	③ Bedrock APIキー（短期）
検証用に、期限を決めて使い回せるキーを用意したい	④ Bedrock APIキー（長期）
会社やチームでAWSアカウント・権限を分けて使わせたい	⑤ AssumeRole（IAMロールの引き受け）
上記が使えない環境で、どうしても他に手段がない	⑥ IAMユーザーの長期アクセスキー（非推奨）

ちなみにClaude CLI（Claude Code）には、認証を自動でセットアップしてくれるウィザードが付いています。どれを選ぶにしても、まずはこのウィザードに任せるのが一番簡単です。

claude

と入力して起動し、ログイン方法を選ぶ画面で「3rd-party platform」→「Amazon Bedrock」を選ぶと、使いたい認証方法を選ぶだけで設定が完了します（設定ファイルへの書き込みも自動でやってくれます）。すでにClaudeにログイン済みの場合は /setup-bedrock と入力すると同じウィザードが開きます。

以下では、それぞれの認証方法の中身・メリット・デメリットを見ていきます。

前提: 設定はどこに書かれるのか

ClaudeをBedrock経由で使う設定は、役割が異なる2つのファイルに分かれています。

ファイル	役割
`~/.aws/credentials` と `~/.aws/config`	AWSへの認証情報・リージョンなどを書く場所（Windowsは`C:\Users\<ユーザー名>\.aws\`）。AWS CLI/SDK全般が共通で読む設定で、Claude専用のものではありません。
`~/.claude/settings.json`	Claude Code用の設定。Bedrockを使うことの指定、使うAWSプロファイル名、モデルIDなどを書きます。

ウィザード（/setup-bedrock）を使えば、これらのファイルへの書き込みは自動で行われるので、基本的に手で編集する必要はありません。ただ「何が書かれているか」を知っておくと、エラーが出たときに原因を追いやすくなります。

モデルIDはどこで確認するか

使いたいモデルのモデルID（地理推論ID、グローバル推論ID）は、 Amazon Bedrockのモデルカード（例: Claude Sonnet 5のページ）から確認できます。「プログラムによるアクセス」や「地理推論の詳細」「グローバル推論の詳細」の項目に、us.anthropic.claude-sonnet-5 のような実際に設定ファイルへ書き込むIDが記載されています。

地理推論IDとグローバル推論IDの違い

Bedrockの推論オプションには、モデルカードによると以下の3種類があります。

種類	説明	IDの例
リージョン内	厳格なコンプライアンスのため、リクエストを1つのリージョン内に保持する	`anthropic.claude-sonnet-5`
地理クロスリージョン	データレジデンシーを尊重しながらスループットを向上させるため、地域（米国、欧州など）内のリージョンを横断する	`us.anthropic.claude-sonnet-5`（米国内）、`eu.anthropic.claude-sonnet-5`（欧州内）など
グローバルクロスリージョン	レジデンシーの制約がない場合に、世界中のどこにでもルーティングして最大スループットを実現する	`global.anthropic.claude-sonnet-5`

地理推論ID（us./eu./au.などの接頭辞）: 同じ地域内の複数リージョンにルーティングされる。データが特定の地域（例: 米国内）から出ないという制約を保ちながら、単一リージョンより高いスループットが得られる。
グローバル推論ID（global.接頭辞）: 世界中のどこかにルーティングされる。地域の制約が無い代わりに、最もスループットが高くなりやすい。

データの保存場所に制約がある場合は地理推論ID、制約が無くスループットを優先したい場合はグローバル推論IDを選ぶ、という基準で選ぶとよいです。どのリージョンが実際にルーティング先になるかは、モデルカードの「地理推論の詳細」「グローバル推論の詳細」に一覧があります。

IAMユーザーの権限（Model access/AWS Marketplaceの権限）次第では、モデルカードに記載されていても呼び出せないモデルがあります。必要な前提条件は Request access to models（公式）に記載されています。

① aws login

AWSマネジメントコンソールと同じ方法（ID/パスワード＋MFA）でブラウザからログインし、一時的な認証情報を自動で取得する方式です。静的なアクセスキーを保存せずに済みます。

どんな仕組みか

コマンドを実行するとブラウザが開き、普段コンソールにログインする方法でサインインするだけです。裏側で短期間だけ有効な認証情報が発行され、パソコンに保存されます。

設定方法

aws login --profile bedrock-login

--profileの後ろの名前（ここではbedrock-login）は任意のプロファイル名です。好きな名前を付けられます。実行するとブラウザが開くので、コンソールと同じ方法でログインします。セッションが切れた場合は、同じコマンドを再度実行してログインし直します。

プロファイル設定例（~/.aws/config）

コマンドを実行すると、以下の内容が自動で書き込まれます（手で書く必要はありません）。

[profile bedrock-login]
region = us-east-1
login_session = arn:aws:iam::123456789012:user/username

注意: このプロファイルを使う場合、Claude Code/Desktopを起動する前に次のコマンドでログインしてセッションを取得しましょう。
aws login --profile bedrock-login
セッションが切れた状態でClaudeを起動すると認証エラーになるので、エラーが出たらまずこれを実行してから起動し直してください。

メリット

静的なアクセスキーをファイルに保存しない
MFA（2段階認証）が必須のアカウントでも、ブラウザログインの中でMFAが完了するので別途コード入力が不要
コマンド一発＋ブラウザでのログインだけで完了する

デメリット

認証は最大12時間で切れる。切れたら aws login をもう一度実行する必要がある
ブラウザを開ける環境が必要（社内ネットワーク等でブラウザが使えない場合は工夫が必要）
利用にはAWS CLIの新しいバージョン（v2.32以上）が必要
使う前に、IAMユーザーへの権限付与が必要（次項で説明）

必要なIAM権限

aws loginでBedrockまで使えるようにするには、IAMユーザーに2種類の権限が必要です。

aws loginを実行するための権限: AWS管理ポリシーのSignInLocalDevelopmentAccessをIAMユーザーにアタッチします。このポリシーは、ブラウザ認証でOAuth 2.0の認可コードを取得する権限と、そのコードをアクセストークン・リフレッシュトークンに交換する権限を許可するもので、 AWS公式ドキュメントにその内容が説明されています。このポリシーが無いと、aws loginコマンド自体がエラーになります。
Bedrockを呼び出すための権限: aws loginが通っても、それだけではBedrockは呼べません。別途Bedrockの利用権限を付与する必要があります。必要なアクションはユースケースによって異なるので、 Amazon Bedrock用のAWS管理ポリシー一覧を参照し、 AmazonBedrockFullAccessやAmazonBedrockLimitedAccessなどを出発点にして必要な範囲に絞り込むとよいです。

Claude Desktopの設定

Claude Desktopでは、aws loginで作ったプロファイルを「AWSプロファイル名」に指定する クラウドベンダープロファイルという方式で使います。Claude Desktopアプリの左下から「サードパーティ推論の設定」画面に遷移し、”接続”から設定できます。
※ほかの認証方法も同様に設定できます

項目	値
推論リクエストの送信先	Bedrock
AWSリージョン	Bedrockランタイムエンドポイントのリージョン（例: `ap-northeast-1`）
認証情報の種類	クラウドベンダープロファイル
AWSプロファイル名	（任意入力）`aws login`で作ったプロファイル名（例: `bedrock-login`）
AWSの設定ディレクトリ	（任意入力）`.aws` のフルパスを指定する（例: `C:\Users\<ユーザー名>\.aws\`）
AWS CLIのパス	（任意入力）aws CLIの`aws.exe`コマンドのフルパスを指定する（例: `C:\Program Files\Amazon\AWSCLIV2\aws.exe`）
カスタム推論ヘッダー	（任意入力）

Claude CLIの設定

CLIの場合は、~/.claude/settings.jsonに使うプロファイル名を書いておくと、毎回--profileを指定せずに済みます。

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "AWS_PROFILE": "bedrock-login"
  }
}

これを書いておけば、セッションが有効な間はclaudeと入力するだけで起動できます。セッションが切れたときだけaws login --profile bedrock-loginを再度実行してください。

おすすめのユースケース

IAM Identity Centerが使えない環境で、静的なアクセスキーを使わずにBedrockへの認証を通したい場合など。

② aws sso login

会社が「IAM Identity Center」（以前はAWS SSOと呼ばれていた仕組み）を導入している場合に使う方法です。 ①のaws loginと似ていますが、AWS IAM Identity Centerの組織インスタンスを利用できないと使うことができない点が違います。

設定方法

初回のみプロファイルを作成:
```
aws configure sso
```
SSOの開始URL（例: https://xxxx.awsapps.com/start）などを入力します。

以降はログインするだけ:

aws sso login --profile 作成したプロファイル名

プロファイル設定例（~/.aws/config）

aws configure sso で対話的に作ることもできますが、直接ファイルに書いてもかまいません。 [profile bedrock-dev]のbedrock-devは任意のプロファイル名で、好きな名前に変えてかまいません。

[profile bedrock-dev]
region = ap-northeast-1
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id = 123456789012
sso_role_name = ClaudeCoworkAccess

sso_start_url / sso_region: IAM Identity Centerのポータル情報
sso_account_id / sso_role_name: どのAWSアカウントの、どの権限セット（ロール）を使うか

注意: ①aws loginと同様にこのプロファイルを使う場合でも、Claude Code/Desktopを起動する前に次のコマンドでログインしてセッションを取得しましょう。
aws sso login --profile bedrock-dev
セッションが切れた状態でClaudeを起動すると認証エラーになるので、エラーが出たらまずこれを実行してから起動し直してください。

メリット

パスワードや秘密の鍵をファイルに保存しない
「誰がどのAWSアカウントを使えるか」を一元管理できる
複数のAWSアカウントを1つのログインで使い分けられる

デメリット

IAM Identity Centerの”組織インスタンス”を利用できないと使えない（アカウントインスタンスでは利用できない）
参考資料：https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/identity-center-instances.html
①と同様、最大12時間ほどで認証が切れて再ログインが必要

必要なIAM権限

aws sso login自体は、IAM Identity Centerにサインインできるユーザーであれば誰でも実行できます。実際にBedrockが使えるかどうかは、ログイン先の**許可セット（Permission set）**にBedrockの利用権限が含まれているかどうかで決まります。

許可セットの権限は、Amazon Bedrock用のAWS管理ポリシー一覧にあるAmazonBedrockFullAccessやAmazonBedrockLimitedAccessなどを組み込む形で設定する必要があります。Bedrockの呼び出しでエラーになった場合は、自分のIAMユーザーではなく「割り当てられている許可セットにBedrock権限が入っているか」を確認してください。

Claude Desktopの設定

Claude Desktopには、AWS CLIを使わずアプリ内でIAM Identity Centerにサインインできる インタラクティブサインインという方式があります（公式ドキュメントより）。「サードパーティ推論の設定」画面から設定します。

項目	値
推論リクエストの送信先	Bedrock
サインインセッションの有効期間	（任意入力）
AWSリージョン	Bedrockランタイムエンドポイントのリージョン（例: `ap-northeast-1`）
認証情報の種類	インタラクティブサインイン
Bedrock ベース URL	（任意入力）
Bedrockサービスティア	デフォルトは（オンデマンド）必要に応じてflexかpriorityに変更
AWS SSO スタート URL	IAM Identity Centerのアクセスポータルの URL（例: `https://d-xxxxxxxxxx.awsapps.com/start`）
AWS SSOリージョン	IAM Identity Centerのホームリージョン
AWS SSOアカウントID	IAM Identity Centerでユーザーに割り当てられた12桁のAWSアカウントID
AWS SSOロール名	上記のアカウントで`bedrock:InvokeModel*`を許可するIAM Identity Centerのパーミッションセット名
カスタム推論ヘッダー	（任意入力）

4つの必須入力SSO項目をすべて設定すると、Cowork（Claude Desktopのチャット）を開いたときに「Sign in with AWS (AWSでサインイン)」の画面が表示されます。

ボタンを押すとブラウザでIAM Identity Centerのサインイン画面が開き、承認するとアプリに戻ります。

AWS CLIのインストールは不要です。一度サインインすれば、セッションが切れるまで再ログインは不要です。

Claude CLIの設定

CLIの場合は、②の設定方法で作った通常のaws sso login用プロファイルを使います。 ~/.claude/settings.jsonに以下を書いておきます。

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "ap-northeast-1",
    "AWS_PROFILE": "bedrock-dev"
  }
}

セッションが切れたらaws sso login --profile bedrock-devを実行してからclaudeを起動してください。

おすすめのユースケース

IAM Identity Centerの組織インスタンスを利用可能な場合やユーザーをIAM Identity Centerで一元管理している場合、既存のADなどの社内アカウントでAWSにもログインしたい場合など。

③ Bedrock APIキー（短期）

AWSの認証情報一式（アクセスキーやログイン）を使わず、1つの文字列（トークン）だけで Bedrockを呼び出せるようにする、Bedrock専用のシンプルな認証方法です。AWS公式も本番利用に適した方法として案内しています。

設定方法

Amazon Bedrockコンソールにログイン
左メニューの「API keys」→「Short-term API keys」タブ→「Generate short-term API keys」
発行された文字列（トークン）をコピー
環境変数として設定:
```
# Bedrockコンソールの画面には、コマンドプロンプト（cmd.exe）用の`set`コマンドが表示されます。
# PowerShellにそのまま貼りつけてもBedrockが読む環境変数には設定されないので、以下のように書き換えてください。

# コマンドプロンプト（cmd）の場合
set AWS_BEARER_TOKEN_BEDROCK=コピーした文字列

# PowerShellの場合
$env:AWS_BEARER_TOKEN_BEDROCK = "コピーした文字列"

# 永続化する場合(cmdでもPowerShellでも同様)
setx AWS_BEARER_TOKEN_BEDROCK "コピーした文字列"
```
※このトークンは有効期限12時間の短期キーなので永続化すると、期限切れの古いトークンがレジストリに残り続け、12時間後には「設定されているのに使えない」という混乱の元になります。setxで永続化するより、使うたびにset …や$env:…でその場だけ設定する方が実用的です

またはClaude Codeのセットアップウィザードで「Amazon Bedrock API key」を選び、貼り付けるだけでも問題ありません。その場合は ~/.claude/settings.json に自動で保存されます。

メリット

AWSの認証情報一式を用意する必要がなく、トークン1つだけで済むので設定が簡単
コンソールにログインできれば誰でもすぐ発行できる
ログ(CloudTrail)にトークンの値自体は残らない

デメリット

有効期限は「12時間」またはコンソールにログインしていた残り時間のうち短い方まで。切れたら再発行が必要
発行したリージョンでしか使えない
Bedrock以外のAWSサービスには使えない（Bedrock専用）

必要なIAM権限

短期キーは、発行に使ったIAMプリンシパル（コンソールにログインしているIAMユーザーやロール）が持つ権限を、そのまま引き継ぐ仕組みです（AWS公式ドキュメントより）。つまり、Bedrockコンソールにログインしている自分自身が、すでにBedrockを呼び出せる権限（AWS管理ポリシーのAmazonBedrockFullAccessや AmazonBedrockLimitedAccessなど）を持っていないと、発行したキーもBedrockを呼び出せません。新しく別の権限を用意する必要はなく、「今ログインしている自分にBedrock権限があるか」がポイントです。

Claude Desktopの設定

Claude Desktopでは、発行したトークンをそのままAWSベアラートークン欄に貼り付けます。「AWSベアラートークン」＝ここで発行したBedrock APIキーの文字列そのもの（IAMユーザーのアクセスキーID/シークレットキーとは別物）です。「サードパーティ推論の設定」画面から設定します。

項目	値
推論リクエストの送信先	Bedrock
AWSリージョン	Bedrockランタイムエンドポイントのリージョン
認証情報の種類	静的APIキー
Bedrock ベース URL	（任意入力）
Bedrockサービスティア	デフォルトは（オンデマンド）必要に応じてflexかpriorityに変更
AWSベアラートークン	発行したBedrock APIキーの文字列
カスタム推論ヘッダー	（任意入力）

トークン(APIキー)を入れて保存するだけで使えます。AWS CLIのインストールも、プロファイルの設定も不要です。モデルの一覧欄は空欄でも、アカウントから使えるモデルを自動検出してくれます。

Claude CLIの設定

CLIの場合は、環境変数AWS_BEARER_TOKEN_BEDROCKにトークンを設定するだけで使えます。 ~/.claude/settings.jsonに書いておくこともできます。

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "AWS_BEARER_TOKEN_BEDROCK": "発行したBedrock APIキーの文字列"
  }
}

おすすめのユースケース

とにかく一番手軽にBedrockを試したい場合。個人の検証や、短時間だけ使うケースに向いています。

④ Bedrock APIキー（長期）

③の短期キーと同じ「トークン1つだけ」の仕組みですが、有効期限を自分で決められる版です。発行すると裏側で専用のIAMユーザーが自動的に作られ、そのユーザーに紐づくキーとして発行されます。

設定方法

Amazon Bedrockコンソールにログイン
左メニューの「API keys」→「Long-term API keys」タブ→「Generate long-term API keys」
有効期限（例: 90日後）を選択して生成
③と同じ方法で環境変数AWS_BEARER_TOKEN_BEDROCKに設定する

※長期キーは手動削除も可能です

※キー削除の際にはキーを所有するIAMユーザー(自動作成)も削除しましょう

メリット
- 有効期限を自分で決められるので、③のように12時間ごとに再発行する必要がなく、「一定期間使い回せるキー」を用意したい場合に扱いやすい
- ③と同様、トークン1つだけで設定できるシンプルさがある
- 発行後もIAMコンソールから権限を調整できる（紐づくIAMユーザーのポリシーを編集する）
デメリット
- キー自体が長期間有効なシークレットになるため、①〜③に比べると漏洩時のリスクが大きい
- AWS公式も「本番運用ではなく検証目的での利用」を推奨している
- 発行するたびに専用のIAMユーザーが作られるため、使わなくなったキー・ユーザーの棚卸しが必要になる

必要なIAM権限

長期キーを発行するには、iam:CreateServiceSpecificCredentialという権限が必要です（AWS公式ドキュメントより）。

発行手順の中で権限（ポリシー）を選ぶ画面が出てくるので、そこでBedrockの利用権限（AmazonBedrockLimitedAccessなど）を選んでおけば、追加の設定は不要です。コンソールから発行できない場合は、自分のIAMユーザーにiam:CreateServiceSpecificCredentialが付与されているか確認してください。

Claude Desktop / Claude CLIの設定

発行したトークンの使い方は③（短期キー）と同じです。Claude Desktopでは「AWSベアラートークン」欄にトークンを貼り付け、CLIでは環境変数AWS_BEARER_TOKEN_BEDROCKに設定してください。詳しい設定項目は③の「Claude Desktopの設定」「Claude CLIの設定」を参照してください。

おすすめのユースケース

期限を決めた上で複数環境で使い回すキーを用意したい場合。本番の恒常運用に使う場合は、③（短期キー）に定期的に切り替える運用と組み合わせるのが望ましいです。

Claude CoworkのScheduled tasks(スケジュール済みタスク)を利用したい場合は有効な選択肢になります(認証切れでスケジュール実行できないということが起こりにくいため)。ただし、長期間一つのキーを使いまわすこと自体好ましくないため、定期的にローテーションするような運用を取り入れるようにしましょう。

⑤ AssumeRole（IAMロールの引き受け）

すでに持っている認証情報（①〜④・⑥のいずれか）を使って、目的に応じた別のIAMロールを一時的に借りる仕組みです。個人のセットアップ時点では意識しなくてよいですが、チーム/組織で権限を分けたい場合に選択肢になります。以下は実際に手元で動作確認した設定・手順です。

どんな仕組みか

ベースとなる認証情報が必要です。取得方法は①aws login、②aws sso login、⑥静的アクセスキーなど何でもかまいません。条件は「対象のIAMロールに対してsts:AssumeRoleできる権限を持っていること」だけです。
そのベースの認証情報を使って、実際にBedrockを呼ぶ権限を持つ別のIAMロールを一時的に引き受けます。
ロール側には「誰が引き受けられるか」を決める信頼ポリシーを設定しておく必要があります。

必要なIAM権限

必要な権限は2種類あり、それぞれ設定する場所が異なります。

ベースの認証情報側: 対象のIAMロールに対してsts:AssumeRoleを実行できる権限。
IAMロール側: Bedrockを呼び出す権限（許可ポリシー）。 Amazon Bedrock用のAWS管理ポリシー一覧にあるAmazonBedrockFullAccessやAmazonBedrockLimitedAccessなどをアタッチしておきます。

さらに、ロール側には「誰が引き受けられるか」を決める信頼ポリシーの設定も必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/username" },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAMコンソールでロールを開き、「信頼関係」タブ→「信頼ポリシーを編集」で設定します。

設定方法（~/.aws/config）

bedrock-login・bedrock-roleはどちらも任意のプロファイル名で、好きな名前に変えて問題ありません。

# ベースとなる認証情報を持つプロファイル（今回はaws loginを使う例）
[profile bedrock-login]
region = us-east-1
login_session = arn:aws:iam::123456789012:user/username

# 実際にClaudeが使うプロファイル
[profile bedrock-role]
role_arn = arn:aws:iam::123456789012:role/BedrockAccessRole
source_profile = bedrock-login
region = us-east-1

bedrock-login: ベースの認証情報を持つプロファイル。ここはaws loginのプロファイルでも、 aws sso loginのプロファイルでも、⑥のように静的アクセスキーを書いたプロファイルでも問題ありません。 sts:AssumeRoleの権限さえ持っていれば、取得方法は問いません。（login_sessionの行はaws login実行時に自動で書き込まれるので手で書く必要はありません。静的キーを使う場合はここにaws_access_key_id等が代わりに入ります）
bedrock-role: 実際にClaudeが使うプロファイル。source_profileで上記のプロファイルを指定し、 role_arnで引き受けたいロールを指定するだけです。

~/.aws/credentialsには何も書かなくて大丈夫です（ベース側を静的キーにする場合はそちらに書きます）。

Claude Code CLIで認証を通す流れ

① ベースのプロファイルで認証を通す
   (aws loginならブラウザでMFA込みログイン／aws sso loginならSSOログイン／静的キーなら発行済みならそのまま使える)
② $env:AWS_PROFILE = "bedrock-role"   (ロールを引き受けるプロファイルを指定)
③ claude                              (起動、ClaudeがBedrock経由で使える)

①の操作は、ベースにどの認証方式を使うかで変わります（aws loginならaws login --profile bedrock-loginをセッション切れ時のみ実行）。 ~/.claude/settings.jsonに"AWS_PROFILE": "bedrock-role"を書いておけば②も毎回不要になります。

Claude Desktopの設定

Claude Desktopでも、ロールを引き受ける側のプロファイル（bedrock-role）を「AWSプロファイル名」に指定すれば、①と同じクラウドベンダープロファイル方式で使えます。

項目	値
推論リクエストの送信先	Bedrock
AWSリージョン	Bedrockランタイムエンドポイントのリージョン
認証情報の種類	クラウドベンダープロファイル
AWSプロファイル名	`bedrock-role`（ロールを引き受けるプロファイル）

ベース側のセッションが切れている場合は、先にターミナルで認証を通してから起動してください。

IAMユーザーに直接権限を持たせる場合とのメリット比較

	IAMユーザーに直接Bedrock権限	IAMロールを経由(AssumeRole)
普段の認証情報自体の権限	Bedrockの強い権限を持ち続ける	「ロールを引き受けられる」権限だけ持つ
権限の見直し・剥奪	ユーザーのポリシーを直接編集	ロールを無効化/削除するだけで、他の権限に影響しない
強い権限を使うタイミング	常時強い権限を持っている状態	使うときだけ一時的に引き受ける
複数人・複数用途での使い回し	ユーザーごとに個別設定	同じロールを複数のユーザー/チームに割り当て可能
CloudTrailでの追跡	誰が使ったか埋没しやすい	`role_session_name`でセッション単位に追跡できる

メリット

ベースの認証情報自体は「ロールを引き受けられる」という薄い権限だけを持たせ、実際にBedrockを呼べる強い権限はロール側にのみ持たせる、という権限分離ができます（最小権限の原則）
クロスアカウント（検証用/本番用など別アカウント間）でのアクセスができる
複数のAWSアカウントがある場合、source_profileはそのまま、role_arnだけ切り替えて使い分けられる
一度プロファイルを設定すれば、AWS CLI/SDKが自動でロールの引き受けと更新を行う
Bedrockアクセスを止めたいときは、ロール側の信頼ポリシーを外すかロールを無効化するだけで済み、ユーザー側の設定を触らずに管理できる

デメリット

ベースとなる認証情報（①〜④・⑥のいずれか）が別途必要

おすすめのユースケース

会社で「個人の認証情報には最小権限しか与えず、業務ごとに用意されたロールを使わせる」という運用ルールがある場合
検証環境と本番環境でAWSアカウントが分かれていて、1つの認証情報から複数アカウントのBedrockを使い分けたい場合
監査上、「誰が」ではなく「どの業務ロールで」Bedrockを使ったかを記録したい場合　など

個人でBedrockを単純に試すだけであれば、①のaws loginだけで十分で、通常は不要です。

⑥ IAMユーザーの長期アクセスキー（非推奨・最終手段）

aws_access_key_id と aws_secret_access_key という2つの文字列を直接~/.aws/credentialsに書き込む、昔からある古典的な方法です。

設定方法

IAMコンソールでアクセスキーを発行
aws configure を実行し、聞かれる項目に入力する（自動的に~/.aws/credentialsに保存される）

プロファイル設定例

bedrock-devは任意のプロファイル名で、好きな名前に変えて問題ありません。

# ~/.aws/config
[profile bedrock-dev]
region = ap-northeast-1

# ~/.aws/credentials
[bedrock-dev]
aws_access_key_id = AKIAxxxxxxxxxxxxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

リージョンの設定はconfig側、キー自体はcredentials側と、2つのファイルに分かれて保存される点に注意してください。

メリット

設定がシンプルで、古いツールでも確実に動く
有効期限がないので、切れて再認証する手間がない

デメリット

有効期限がない＝漏洩したときのリスクが一番大きい。ファイルに平文で残り続けます
手動で無効化しない限り使われ続けてしまう
AWS公式も、可能な限り期限付きの方法（①〜④）を使うよう推奨している

必要なIAM権限

アクセスキーを発行したIAMユーザー自身に、Bedrockを呼び出す権限を直接アタッチしておく必要があります。 Amazon Bedrock用のAWS管理ポリシー一覧にあるAmazonBedrockFullAccessやAmazonBedrockLimitedAccessなどをそのユーザーにアタッチしてください。

Claude Desktop / Claude CLIの設定

アクセスキーを書いたプロファイル（例: bedrock-dev）を、①と同じクラウドベンダープロファイル方式で指定します。 Claude Desktopでは「認証情報の種類」を「クラウドベンダープロファイル」にし、「AWSプロファイル名」にbedrock-dev（設定したプロファイル名）を指定してください。CLIでは~/.claude/settings.jsonの AWS_PROFILEに同じプロファイル名を書きます。アクセスキーに有効期限がないため、セッション切れによる再ログインは発生しません（その分リスクが残る点は前述の通りです）。

おすすめのユースケース

基本的には選ぶべきではありません。①〜④がどうしても使えない環境でのみ、一時的な代替として検討してください。使い終わったら忘れずにIAMコンソールから無効化・削除しましょう。

Claude Code側の共通設定まとめ

各セクションで紹介した~/.claude/settings.jsonの設定を、認証方法別に一覧にまとめました。ウィザード（/setup-bedrock）を使えば自動で書き込まれるので、通常は手で編集する必要はありません。

認証方法	`AWS_PROFILE`	`AWS_BEARER_TOKEN_BEDROCK`
①`aws login` / ②`aws sso login` / ⑤AssumeRole / ⑥アクセスキー	プロファイル名を指定	不要
③④Bedrock APIキー	不要	発行したトークンを指定

CLAUDE_CODE_USE_BEDROCK: "1"とAWS_REGIONはどの認証方法でも共通で必要です。

Claude Desktopの設定まとめ

Claude Desktopの「サードパーティ推論の設定」で選ぶ認証情報の種類は、認証方法によって以下のように対応します。

認証方法	認証情報の種類	主な入力項目
①`aws login` / ⑤AssumeRole / ⑥アクセスキー	クラウドベンダープロファイル	AWSプロファイル名
②`aws sso login`	インタラクティブサインイン	AWS SSOスタートURL / リージョン / アカウントID / ロール名
③④Bedrock APIキー	静的APIキー	AWSベアラートークン（発行したAPIキーの文字列）

詳しい入力項目は各セクションの「Claude Desktopの設定」を参照してください。

参考資料

Claude Code on Amazon Bedrock（公式）
Deploy Claude Desktop on 3P with Amazon Bedrock（公式）（Claude Desktopの認証設定）
Amazon Bedrockのモデルカード（例: Claude Sonnet 5）（モデルID・地理推論ID・グローバル推論IDの確認）
Request access to models（モデル呼び出しに必要なIAM権限）
Login for AWS local development using console credentials（aws login）
Configuring IAM Identity Center authentication with the AWS CLI（aws sso login）
Amazon Bedrock API keys
How Amazon Bedrock API keys work
Using an IAM role in the AWS CLI（AssumeRole・MFAプロファイルの動作）
Assuming a role with web identity or OpenID Connect（AssumeRole）
Alternatives to long-term access keys