AdministratorAccessでもBedrockが動かない——モデルアクセス廃止後に詰まる3つの関門

「AdministratorAccess を付けているのに、AccessDenied が消えません」

Bedrock を東京リージョンで動かそうとして、ここで止まりました。IAM を疑って権限を足していくと、かえって原因から遠ざかります。Bedrock には IAM の先に、もう一層あります。

この記事では、AccessDeniedException が出たときに原因を切り分ける方法を整理します。エラーメッセージの文言で3つの関門を見分ける手順と、管理者権限でも通らなかったときに実際に解決したコマンドを記録しました。

この記事で分かること

• Bedrock でモデルを呼ぶまでに通過する3つの関門と、それぞれに対応するエラーメッセージ
• get-foundation-model-availability の4つのフィールドを、どう読んで原因を確定させるか
• 「モデルアクセス」画面が廃止され、有効化の方法がどう変わったか
• AdministratorAccess でも失敗したときに、実際に通った手順
• 一度成功したのに、その後 AccessDeniedException が出始める理由

前提知識

• Amazon Bedrock でモデルを呼び出したことがある（converse または SDK 経由）
• IAM ポリシーの読み書きができる
• AWS CLI でプロファイルを切り替えて操作できる

検証した範囲と、していない範囲

実際に手を動かして確認したのは、次の範囲です。

• 東京リージョン（ap-northeast-1）での bedrock-runtime converse の呼び出しと、返ってきたエラーメッセージ全文
• IAM ポリシー付与の前後でのエラー文言の変化
• get-foundation-model-availability による4フィールドの取得
• list-foundation-model-agreement-offers と create-foundation-model-agreement の実行
• 契約後の agreementAvailability の遷移

していないことも書いておきます。

• 管理者権限で失敗した原因の特定。 後述のとおり AWS 公式は3つの前提条件を挙げていますが、そのどれが欠けていたかまでは確認していません
• Anthropic の First Time Use フォーム提出の検証。 公式ドキュメントに記載がある要件として本文で触れますが、今回は検証していません
• 権限の有無を切り替えた初回呼び出しの再現。 一度有効化すると元に戻せないため、再現実験はしていません

対象モデルは anthropic.claude-sonnet-4-5-20250929-v1:0 と anthropic.claude-haiku-4-5-20251001-v1:0 です。確認はすべて2026年8月に行いました。

それでは、全体像から見ていきます。

Bedrock には3つの関門がある

モデルを呼ぶまでに、性質の違う3つのチェックを通過します。どれで止まっても、返ってくるのは似たようなエラーです。

関門2と関門3はどちらも AccessDeniedException です。ここが厄介なところで、IAM を直しても消えないのは関門3で止まっているからです。

一覧にするとこうなります。

出るエラー	止まっている関門	対処
ValidationException: The provided model identifier is invalid.	関門1（モデルID）	リージョンに存在するIDへ変更する
AccessDeniedException: ... is not authorized to perform: bedrock:InvokeModel	関門2（IAM）	IAM ポリシーを付与する
AccessDeniedException: Model access is denied ... AWS Marketplace actions	関門3（モデルアクセス契約）	モデルの利用契約を締結する

関門1については、前回の記事で扱いました。東京リージョンで us. プレフィックスのモデルIDが通らない話です。

関連記事 Bedrock AgentCoreを東京リージョンで動かす——us.は失敗、global.は動く、jp.を選ぶ理由 シリーズ第1回。ValidationException が出るケースと、推論プロファイルのプレフィックスの違いを扱っています。

この記事では関門2と関門3、特に見分けがつきにくい関門3を掘ります。

エラーメッセージで関門を見分ける

実際に遭遇した順に見ていきます。

関門2で止まっているとき

IAM ポリシーを付与する前は、こう返ってきました。

AccessDeniedException: User: arn:aws:iam::<アカウントID>:user/<ユーザー名> is not
authorized to perform: bedrock:InvokeModel on resource: ...

is not authorized to perform: bedrock:InvokeModel という文言が出ていれば、IAM の話です。 ポリシーを直せば解決します。

関門3で止まっているとき

IAM ポリシーを付与したあと、同じコマンドを実行するとエラーの内容が変わりました。

AccessDeniedException: Model access is denied due to IAM user or service role is not
authorized to perform the required AWS Marketplace actions
(aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe)
to enable access to this model. ...
Your AWS Marketplace subscription for this model cannot be completed at this time.
If you recently fixed this issue, try again after 2 minutes.

ここが分岐点です。 同じ AccessDeniedException ですが、内容が違います。

時点	エラーの中身	止まっている関門
IAM 付与前	not authorized to perform: bedrock:InvokeModel	関門2（IAM）
IAM 付与後	Model access is denied ... AWS Marketplace actions	関門3（モデルアクセス契約）

InvokeModel の関門は通過していて、その先で止まっています。 ここで IAM ポリシーをさらに足しても解決しません。

文言に AWS Marketplace が含まれていたら、IAM ではなく契約の問題だと判断してください。

判断の根拠をもう一段固めたいときは、専用の API があります。

get-foundation-model-availability で確定させる

エラーメッセージだけでは心もとないときは、このコマンドで状態を直接確認できます。

aws bedrock get-foundation-model-availability \
  --model-id anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --region ap-northeast-1

同じアカウント・同じリージョンで、動くモデルと動かないモデルを並べたのが次の表です。

モデル	agreementAvailability	authorizationStatus	entitlementAvailability	regionAvailability
Haiku 4.5（動く）	AVAILABLE	AUTHORIZED	AVAILABLE	AVAILABLE
Sonnet 4.5（動かない）	NOT_AVAILABLE	AUTHORIZED	AVAILABLE	AVAILABLE

4つのうち3つは同じ値です。 違うのは agreementAvailability だけでした。

各フィールドは関門に対応しています。

フィールド	見ているもの	対応する関門
regionAvailability	そのリージョンでモデルが提供されているか	関門1
authorizationStatus	IAM で許可されているか	関門2
agreementAvailability	モデルの利用契約が締結済みか	関門3
entitlementAvailability	利用権があるか	関門3

この表を見れば、IAM もリージョンも問題ないと即座に分かります。契約だけが済んでいませんでした。

なお entitlementAvailability については、モデルアクセス廃止にともなって常に AVAILABLE が返るようになったとQiita の解説記事で指摘されています。実際、今回の計測でも両モデルとも AVAILABLE でした。判断材料としては agreementAvailability を見るのが確実です。

原因が契約だと分かったので、次は有効化しにいきます。ところが、ここで想定が外れました。

「モデルアクセス」画面は廃止されている

当初は「Bedrock コンソールのモデルアクセス画面で有効化する」つもりでいました。その画面はもうありません。

コンソールにはこう表示されます。

Model access page has been retired

Serverless foundation models are now automatically enabled across all AWS commercial regions when first invoked in your account, so you can start using them instantly. You no longer need to manually activate model access through this page. Note that for Anthropic models, first-time users may need to submit use case details. For models served from AWS Marketplace, a user with AWS Marketplace permissions must invoke the model once to enable it account-wide for all users.

有効化の方法が「画面でチェックを入れる」から「権限を持つユーザーが1回呼ぶ」に変わっています。

公式ドキュメントのRequest access to models にも、同じ趣旨が書かれています。

Access to all Amazon Bedrock foundation models is enabled by default with the correct AWS Marketplace permissions in all commercial AWS Regions.

そして、成功のための前提条件が3つ挙げられています。

1. AWS Marketplace 権限: aws-marketplace:Subscribe / aws-marketplace:Unsubscribe / aws-marketplace:ViewSubscriptions
2. Anthropic モデルの First Time Use フォーム: 初回利用者はユースケースの提出が必要
3. 有効な支払い方法: AWS Marketplace の購入に使える支払い方法が設定されていること

日本語の解説記事には旧仕様（モデルアクセス画面での有効化）を前提にしたものが残っています。画面を探して見つからず戸惑ったら、廃止されたと考えてください。

案内どおりなら、権限を持つユーザーで1回呼べば済むはずでした。

AdministratorAccess でも失敗した

AdministratorAccess を持つ管理者ユーザーで、AWS CloudShell から converse を実行しました。

aws bedrock-runtime converse \
  --region ap-northeast-1 \
  --model-id jp.anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --messages '[{"role":"user","content":[{"text":"ok"}]}]' \
  --inference-config '{"maxTokens":8}'

同じ AWS Marketplace actions のエラーで失敗しました。

AdministratorAccess には Marketplace 系のアクションも含まれます。そこで、思いつく原因を順に潰していきました。

疑った原因	結果
SCP による制限	❌ このアカウントは AWS Organizations に所属していない
MFA 未設定で DenyAllWithoutMfa が発火	❌ セキュリティキーが登録済み
IAM 権限不足	❌ AdministratorAccess を付与済み
モデルアクセス契約の未締結	✅ これが原因

前の3つは除外できましたが、なぜ管理者権限で呼んでも契約が成立しなかったのかは、特定できていません。 公式が挙げる3つの前提のうち、Marketplace 権限は満たしていたはずなので、残る2つ（FTU フォーム、支払い方法）のどちらかだった可能性はあります。ただし確認していないので、断定はできません。

実際に通った手順

解決したのは、明示的にサブスクリプションを作る API でした。

公式ドキュメントの「Manage model access using SDK and CLI」には、この経路が5段階の手順として整理されています。

Step	API	備考
1	ListFoundationModelAgreementOffers	オファーと offerToken を取得
2	PutUseCaseForModelAccess	Anthropic モデルのみ必須。アカウントまたは組織ごとに1回
3	CreateFoundationModelAgreement	契約を作成
4	GetFoundationModelAvailability	状態を確認
5	DeleteFoundationModelAgreement	任意。契約を削除

今回実行したのは Step 1 と Step 3 です。Step 2 は通していませんが契約は成立しました。このアカウントでは以前にユースケースの提出が済んでいた可能性がありますが、確認していないため断定はできません。Anthropic モデルを新規のアカウントで使う場合は、Step 2 が必要になります。

まずオファートークンを取得します。

TOKEN=$(aws bedrock list-foundation-model-agreement-offers \
  --model-id anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --region ap-northeast-1 \
  --query 'offers[0].offerToken' --output text)

そのトークンを使って契約を作成します。

aws bedrock create-foundation-model-agreement \
  --model-id anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --offer-token "$TOKEN" \
  --region ap-northeast-1

返ってきたのはこれだけです。

{ "modelId": "anthropic.claude-sonnet-4-5-20250929-v1:0" }

素っ気ない応答ですが、これで契約が成立しました。

課金を伴う操作なので、いきなり create を叩かず、list-foundation-model-agreement-offers の出力を一度読んでおくことをおすすめします。--offer-type ALL を付けるとプライベートオファーも含めて返ります（既定は PUBLIC です）。

なおこれらのコマンドには AWS CLI のバージョン要件があります。 公式ドキュメントには「require AWS CLI version 2.27.42 or later」と明記されています。古い CLI では list-foundation-model-agreement-offers 自体が存在しないので、aws --version を先に確認してください。

なお 東京リージョンで契約したところ、大阪リージョン（ap-northeast-3）にも同時に反映されました。 両リージョンとも agreementAvailability が遷移しています。

これは公式ドキュメントの記述とも整合します。

If an identity has already subscribed to a model in one AWS Region, the model becomes available for the identity to request access in all AWS Regions in which the model is available, even if aws-marketplace:Subscribe is denied for other Regions.

1つのリージョンで契約すれば、そのモデルが提供されている他のリージョンでも利用できるようになるという仕様です。jp. の推論プロファイルは東京と大阪の両方にルーティングされるため、これは都合のよい挙動でした。

契約は通りましたが、すぐには動きませんでした。

一度成功してから失敗し始めるのはなぜか

検証中、説明のつかない挙動に遭遇しました。1回だけ成功して、その直後から3回連続で失敗したのです。

当初はこれを「原因不明」として記録に残していました。今回この記事を書くにあたって公式ドキュメントを読み直したところ、該当する記述が見つかりました。

When you invoke a third-party model for the first time in your account, Amazon Bedrock automatically initiates the subscription process in the background. During this setup period (up to 15 minutes), your API calls may succeed temporarily while the subscription is being finalized. If any prerequisites are missing, the subscription attempt fails and subsequent API calls will return AccessDeniedException.

要約すると、こうなります。

• サードパーティモデルの初回呼び出しで、バックグラウンドで契約処理が始まる
• そのセットアップ期間（最大15分）は、契約が完了する前でも一時的に成功することがある
• 前提条件が欠けていれば契約処理は失敗し、以降の呼び出しは AccessDeniedException になる

観測した挙動と一致します。1回目は自動有効化のフローが走って応答が返り、しかし契約は完成せず、以降は弾かれていた、という流れです。

「一度動いたのに動かなくなった」は仕様の範囲内でした。ここでコードを疑い始めると、時間を大きく失います。

契約を作ったあとにも、似た待ち時間があります。

After granting the necessary permissions, it may take up to 2 minutes for the subscription to complete. During this time, API calls may continue to return AccessDeniedException.

実際、create-foundation-model-agreement の直後は agreementAvailability が NOT_AVAILABLE から PENDING を経て AVAILABLE へ遷移しました。そして AVAILABLE になった直後の1回は、まだ失敗しました。 2回目以降は安定しています。

エラーメッセージ末尾の「If you recently fixed this issue, try again after 2 minutes」は、そのままの意味でした。直したのに失敗したら、2分待ってから再試行してください。

ここまでで動くようになりましたが、権限をどう配るかという設計の話が残ります。

検証用ユーザーに Subscribe を与えない

aws-marketplace:Subscribe は、購読すなわち課金コミットを伴いうる権限です。読み取り中心の検証用ユーザーに恒久的に付けるべきではありません。

公式ドキュメントには、この権限がいつまで必要かが明記されています。

Users don't need AWS Marketplace subscription permissions to invoke models after they've been enabled. These permissions are only required the first time a model is being used in an account.

アカウントで1回有効化すれば、以降の呼び出しに Marketplace 権限は要りません。

したがって、こういう分担が最小権限にかないます。

誰が	何をするか	必要な権限
管理者	モデルを1回だけ有効化する	Marketplace 権限（一時的）
検証用ユーザー	以降のモデル呼び出し	bedrock:InvokeModel のみ

検証用ユーザーに Subscribe を付けて回るより、管理者が最初に1回通しておくほうが安全です。有効化はアカウント単位なので、一度やれば全ユーザーが恩恵を受けます。

jp. の推論プロファイルを使う場合、宛先は東京と大阪の2リージョンです。先ほど書いたとおり今回は東京での契約が大阪にも反映されましたが、心配なら両リージョンで確認しておくと確実です。

まとめ

Bedrock でモデルを呼ぶまでに、性質の違う3つの関門があります。モデルIDがそのリージョンに存在するか、IAM で許可されているか、そしてモデルの利用契約が済んでいるかです。関門2と関門3はどちらも AccessDeniedException を返すため、IAM を直しても消えないという状況が起きます。エラー文言に AWS Marketplace が含まれていたら、それは権限ではなく契約の問題です。

切り分けを確実にするなら get-foundation-model-availability を使ってください。今回のケースでは、動くモデルと動かないモデルで4フィールドのうち3つが同じ値で、agreementAvailability だけが違いました。

「モデルアクセス」画面は廃止され、有効化は「権限を持つユーザーが1回呼ぶ」方式に変わっています。ただし AdministratorAccess で呼んでも通らないことがあります。そのときは list-foundation-model-agreement-offers と create-foundation-model-agreement で明示的に契約を作れば解決します。一度成功してから失敗し始めるのは、公式ドキュメントが説明している仕様の範囲内です。

まずは aws bedrock get-foundation-model-availability を実行してみてください。使いたいモデルと、すでに動いているモデルの両方に対して叩き、4つのフィールドを見比べます。どのフィールドが違うかで、次に何を直すべきかが決まります。権限の配り方まで含めて設計を整理したい場合は、サービス概要に判断の目安をまとめています。

参考文献

• Request access to models — Amazon Bedrock ユーザーガイド — モデルアクセスの前提条件、初回呼び出し時の自動契約、最大15分の暫定成功についての記述
• Add or remove access to Amazon Bedrock foundation models — SDK / CLI からモデルアクセスを管理する方法
• Amazon Bedrock のモデルアクセス廃止に関しておさえておくとよいこと — 廃止にともなう entitlementAvailability の挙動変化と PutUseCaseForModelAccess の解説
• [Bedrock]「モデルアクセス」の廃止後のモデル使用時の同意作業に関して — 廃止後の同意作業について