Amazon Bedrock の GPT-5.6 で access_denied が返る原因を調査してみた

はじめに

2026年7月、Amazon Bedrock が OpenAI GPT-5.6（Sol / Terra / Luna）をサポートしました。8月には bedrock-runtime エンドポイントからも呼び出せるようになりました。

https://dev.classmethod.jp/articles/bedrock-openai-gpt56-sol-terra-luna/

https://dev.classmethod.jp/articles/bedrock-runtime-openai-gpt56/

ところが、アカウントによっては、初期状態では GPT-5.6 を呼び出せません。実際に、呼び出すと access_denied が返る状態を確認しました。

ここで切り分ける要因は2つです。AWS 側でモデルがそのアカウントに解放されていない場合と、組織の SCP で Bedrock の利用が拒否されている場合です。前者は AWS に解放してもらうしかなく、後者は SCP を管理する社内の AWS Organizations 管理者へ依頼することになります。どちらも、手元の IAM ポリシーやモデルアクセスの設定を直しても解決しません。

この2つを切り分ける機会があったので紹介します。エラーメッセージだけで切り分けられるかを、OpenAI 互換 API を含む5経路で確かめました。あわせて、それぞれの原因について、誰に何を伝えればよいかを整理しました。

調査内容

us-east-1 で GPT-5.6 Luna を、次の5経路で呼び出しました。

• bedrock-mantle の OpenAI 互換 API（モデルID openai.gpt-5.6-luna）
• bedrock-runtime の OpenAI 互換 API（US Geo の us.openai.gpt-5.6-luna）
• bedrock-runtime の OpenAI 互換 API（Global の global.openai.gpt-5.6-luna）
• bedrock-runtime の Converse（US Geo）
• bedrock-runtime の InvokeModel（US Geo）

はじめの3つは OpenAI SDK から、あとの2つは boto3 から呼び出しました。

AWS Organizations で Bedrock の利用が制限された状態を再現するため、検証用の SCP を作成し、対象のメンバーアカウントに直接アタッチしました。

AWS 側でモデルが解放されていないとき

解放されていなかったときのエラーです。OpenAI 互換の3経路で取得しました。

[
  {
    "target": "mantle / base id",
    "model": "openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "AuthenticationError",
    "error": "Error code: 401 - {'error': {'code': 'access_denied', 'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'param': None, 'type': 'permission_denied_error'}}"
  },
  {
    "target": "runtime / us. geo",
    "model": "us.openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "PermissionDeniedError",
    "error": "Error code: 403 - {'error': {'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}"
  },
  {
    "target": "runtime / global",
    "model": "global.openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "PermissionDeniedError",
    "error": "Error code: 403 - {'error': {'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}"
  }
]

3経路とも code が access_denied、type が permission_denied_error で、メッセージにポリシーの ARN は載りませんでした。ステータスは mantle が 401、runtime の2経路が 403 でした。

呼び出せなかった時点で、モデルの解放状態を bedrock get-foundation-model-availability で確認しました。

{
    "modelId": "openai.gpt-5.6-luna",
    "agreementAvailability": {
        "status": "NOT_AVAILABLE"
    },
    "authorizationStatus": "AUTHORIZED",
    "entitlementAvailability": "AVAILABLE",
    "regionAvailability": "AVAILABLE"
}

agreementAvailability の status だけが NOT_AVAILABLE で、ほかの3項目は AVAILABLE / AUTHORIZED でした。

この結果を見て、bedrock create-foundation-model-agreement でモデルアクセスの契約を締結しました。締結は成功し、agreementAvailability の status も AVAILABLE へ変わりました。4項目すべてが正常な値になりました。それでも、呼び出せない状態は変わりませんでした。

このアカウントでは AWS Enterprise Support を契約しており、サポートケースの起票が可能でした。そこで、モデルの解放を依頼しました。ケースには、対象のアカウント・リージョン・モデルIDと3経路のエラー全文を記載しました。あわせて、Service Quotas が既定値であること、モデルが ACTIVE であること、管理者ロールで呼び出していることも併記しました。起票の翌日にモデルが解放され、同じアカウントで呼び出せるようになりました。

組織の SCP で拒否されたとき

検証用の SCP をアタッチした状態で、同じ5経路で呼び出しました。ポリシーでは、bedrock:* と bedrock-mantle:* の両方を Deny しています。

{
    "Policy": {
        "PolicySummary": {
            "Id": "p-xxxxxxxxx",
            "Arn": "arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx",
            "Type": "SERVICE_CONTROL_POLICY",
            "AwsManaged": false
        },
        "Content": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyBedrockForVerification\",\"Effect\":\"Deny\",\"Action\":[\"bedrock:*\",\"bedrock-mantle:*\"],\"Resource\":\"*\"}]}"
    }
}

mantle 経路のエラー全文です。

Error code: 403 - {'error': {'code': 'access_denied', 'message': 'User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock-mantle:CreateInference on resource: arn:aws:bedrock-mantle:us-east-1:123456789012:project/default with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx', 'param': None, 'type': 'permission_denied_error'}}

bedrock-runtime の OpenAI 互換 API（US Geo）では、次のエラーになりました。

Error code: 401 - {'error': {'message': 'User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.openai.gpt-5.6-luna with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}

Global 経路はモデルIDだけが異なり、メッセージ本文とステータスは US Geo と同じでした。ネイティブ API の Converse と InvokeModel では、メッセージ本文は US Geo と同じでも、ステータスは 403 でした。5経路すべてで、拒否したポリシーの ARN がメッセージ末尾に載りました。

AccessDeniedException (HTTP 403)
User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.openai.gpt-5.6-luna with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx

SCP を適用する前と、デタッチして削除した後は、いずれも5経路すべてが正常に応答しました。同一アカウント・同一スクリプトで実行しており、結果を変えたのは SCP の有無だけです。

メッセージに ARN が載るようになったのは、2026年1月21日のアップデートです。同一アカウント・同一組織の場合に限ります。対象はサービスコントロールポリシー（SCP）とリソースコントロールポリシー（RCP）のほか、アイデンティティベースポリシー、セッションポリシー、権限境界です。

https://aws.amazon.com/about-aws/whats-new/2026/01/additional-policy-details-access-denied-error/

以前はポリシーの種別までしか分からず、同じ種別のポリシーが複数あると原因を絞り込めませんでした。この追加情報は AWS の各サービスに段階的に提供されます。ARN があれば、管理者は該当ポリシーを直接開けるため、心当たりのあるポリシーを順に確認する必要がありません。

5経路の比較

SCP を適用した状態での5経路の結果です。

参照されるアクションとリソースは経路で異なりました。mantle のエラーはアクションに bedrock-mantle:CreateInference、リソースに project/default を挙げていました。runtime のエラーはアクションに bedrock:InvokeModel、リソースに推論プロファイルを挙げていました。

AWS 側の未解放と SCP 拒否を並べると、次のようになります。

code と type は、OpenAI 互換の3経路で両者とも一致しました。ネイティブ API では、どちらも 403 AccessDeniedException でした。OpenAI 互換 API では、ステータスコードの 401 と 403 の出方が逆でした。ステータスコードだけを見ると誤読します。

判別材料として残るのは、メッセージ本文です。with an explicit deny in a service control policy とポリシーの ARN があれば SCP 由来です。is not available for this account なら AWS 側の未解放です。get-foundation-model-availability の戻り値は判別に使えません。4項目すべてが正常でも、呼び出せないことがあります。

OpenAI 互換 API のエラー応答でも、error.message に IAM のメッセージがそのまま入り、末尾に ARN が載りました。判別に必要な情報は落ちていません。

誰に何を伝えるか

原因によって、依頼先と伝える情報が異なります。

AWS 側の未解放

メッセージに is not available for this account が含まれる場合です。

• 依頼先: AWS サポート（Amazon Bedrock のケース）
• 伝える情報: 対象のアカウント・リージョン・モデルID、エラー全文、自分側の設定に問題がないことの確認結果

SCP 由来

メッセージに with an explicit deny in a service control policy とポリシーの ARN が含まれる場合です。

• 依頼先: 社内の AWS Organizations 管理者
• 伝える情報: メッセージ全文（ポリシーの ARN と、参照されたアクション・リソースを含む）、呼び出したモデルIDとリージョン、使った経路

まとめ

SCP による拒否では、拒否したポリシーの ARN と explicit deny の文言がメッセージ本文に載りました。OpenAI 互換 API のエラー応答でも、この情報は落ちませんでした。AWS 側の未解放では、今回観測した5経路のどのメッセージにも ARN は載りませんでした。返ってきたのは、モデルがこのアカウントで利用できないという文言だけです。code と type は両者で一致し、ステータスコードの 401 と 403 は経路ごとに逆転するため、見るべきはメッセージ本文です。

GPT-5.6 を利用できない場合は、まずエラーメッセージ本文を確認してください。with an explicit deny in a service control policy とポリシーの ARN は SCP 由来、is not available for this account は AWS 側の未解放を示す手がかりです。

エラーメッセージに含まれる情報と、対象のアカウント・リージョン・モデルID、利用した経路、確認済みの設定状況を依頼先へ伝えてください。利用制限の解除に向けた調査を進めやすくなります。