Claude CMEKのエラーと検証失敗の原因 — cmek_key_disabledの切り分け
cmek_key_disabled・network_blocked・unreachableの違いと、AWS KMS・Google Cloud KMS・Azure Key Vaultで検証が通らない原因を症状別にたどります。
まず症状を2つに分ける
CMEK(顧客管理暗号鍵)まわりの不具合は、鍵を登録する段階で止まるか、登録後にリクエストが失敗するかの2通りに分かれます。切り分けの起点はここです。
Claude ConsoleのVerify、claude.aiのAdd、Admin APIのvalidate呼び出しは、どれも同じ検証を走らせます。失敗すると、Claude ConsoleではConnection failedと表示されます。原因はKMSの種類ごとに違うので、AWS KMS・Google Cloud KMS・Azure Key Vaultの順に見ていきます。
登録後の失敗は、エラーコードが手がかりになります。cmek_key_disabled、cmek_key_network_blocked、cmek_key_unreachable の3つです。
一方、CMEKを有効にすると止まる機能があります。機能が急に使えなくなった場合は、エラーではなく仕様の可能性があるため、CMEKの機能制限一覧を先に確かめてください。
症状と最初に見る場所
登録・検証で失敗する
KMSごとの原因表へ進みます。AWS KMSはキーポリシーの条件、Google Cloud KMSはラベルと組織ポリシー、Azure Key Vaultはタグとネットワーク規則が主な疑いどころです。
登録後にリクエストが400で失敗する
cmek_key_disabledかcmek_key_network_blockedです。鍵の状態、Anthropicへのアクセス権、IP制限の順に確認します。登録後にリクエストが503で失敗する
cmek_key_unreachableです。鍵に到達できていない状態で、再試行が前提のエラーです。
登録後にリクエストが失敗するとき
cmek_key_disabledは「KMSが拒否した」エラー
メッセージは「Customer-managed encryption key is disabled or revoked. Re-enable the key to restore access.」で、ステータスは400です。名前にdisabledとありますが、鍵が無効化されているケースだけを指すわけではありません。KMSがAnthropicの呼び出しを拒否した状態全般が、このコードで返ります。
確認する順番は次のとおりです。
- 鍵そのものが無効になっていないか
- Anthropicのアクセス権が外されていないか。必要な権限は、Claude Consoleの設定ページに表示されます
- AWS KMSの場合、キーポリシーに列挙したワークスペースに、失敗しているワークスペースが入っているか
- AWS KMSの場合、IP条件がAnthropicの送信元IPアドレスを締め出していないか
3つ目は見落としやすい原因です。ワークスペースを足すたびに、キーポリシーの compartment_uuid 条件へその分の識別子を足す必要があります。追加を忘れると、そのワークスペースのリクエストが拒否される原因になります。ワークスペース単位の書き方はAWS KMSでの設定手順にまとめています。
4つ目のIP条件は、Anthropicが公表している送信元IPの範囲を許可していれば解消します。一覧と登録の考え方は固定IP一覧と許可登録の手順にあります。
落とし穴
無効化は反映までに最大1時間かかる
鍵を無効にする、またはAnthropicのアクセス権を外すと、変更が効くまでに最大1時間かかり、その間に処理中だったリクエストは成功することがあります。「無効にした直後は動いていたのに、しばらくして400になった」という動きは、この遅延で説明がつきます。
原因を直してアクセスが戻ると、鍵が保護しているデータへ再び届きます。ただし戻らないものが2つあります。
- 鍵が無効だった間に失敗したリクエストは、自動では再試行されません
- 鍵を無効にしても、保持期間のカウントは止まりません
つまり、止まっていた時間の分だけ、保持期間は進んでいます。失敗したリクエストは、呼び出し側で投げ直します。
cmek_key_network_blockedは鍵が無事でも起きる
こちらも400で、メッセージにはKMSのネットワークアクセス制御(KMSのファイアウォールやIP許可リストなど)に阻まれたと書かれています。鍵自体は正常でも発生します。対処は、Anthropicが公表しているIPアドレスをKMS側のネットワーク規則で許可することです。
cmek_key_disabled の4つ目の原因(AWS KMSのIP条件)と近く、見分けにくい組み合わせです。コードが network_blocked ならまず経路を、disabled ならまず鍵とポリシーを疑う、という順で切り分けると無駄が出ません。
cmek_key_unreachableは再試行する
ステータスは503です。Anthropicが鍵に届かなかったことを示し、KMS側の障害時などに出ます。Messages APIなら、時間を置いてリクエストを再送します。Message Batches APIは、鍵が使えるようになるかバッチが期限切れになるまで、Anthropic側で再試行します。
鍵を保管するリクエストが対象なので、Claude Enterpriseではチャットや音声モードのメッセージも失敗します。再試行しても続く場合は、KMS側で鍵が利用可能かを確認し、それでも直らなければAnthropicへ連絡する流れです。
登録後の失敗を切り分ける
- Qステータスは503ですか?答えが400なら次へ答えがはい
cmek_key_unreachableです。しばらくして再送し、続くならKMSの稼働状況を確認します。 - Qコードは cmek_key_network_blocked ですか?答えがcmek_key_disabledなら次へ答えがはい
KMSのネットワーク規則に、Anthropicの公表IPを許可します。
- Q鍵は有効で、Anthropicのアクセス権も残っていますか?答えがどちらかが外れています答えがはい
有効化とアクセス権の復元が先です。
AWS KMSならポリシーとIP条件を確認
失敗するワークスペースが compartment_uuid に入っているか、IP条件が送信元を弾いていないかを見ます。
検証が通らない原因はKMSごとに違う
AWS KMS
原因は3つに絞れます。
| 原因 | 直し方 |
|---|---|
| 組織IDの誤り | 直し方org_uuid 条件に、Anthropicの組織IDから org_ を除いたUUIDを入れる |
| ワークスペースの未記載 | 直し方compartment_uuid 条件に、鍵を紐づける全ワークスペースの識別子を並べる |
| IAMでアクセスを渡している | 直し方AnthropicのロールへのアクセスをIAMではなくキーポリシー本体に書く |
現状のキーポリシーは、次のコマンドで取り出して確認します。
aws kms get-key-policy \
--region <REGION> \
--key-id <KEY_ARN> \
--policy-name default出力の中で、org_uuid と compartment_uuid の値が、Consoleに表示される値と一致しているかを見比べてください。
すでにデータを保護している鍵のポリシーを差し替える場合は、既存データを復号するための文を足す必要があります。条件には、その鍵が現在つながっている、または過去につながっていた全ワークスペースの識別子を入れます。次は、その文の形です(<COMPARTMENT_UUID> は置き換えます)。
{
"Sid": "AllowAnthropicCMEKDecryptExistingData",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::915198916910:role/anthropic-cmek-client-us"
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:anthropic:compartment_uuid": ["<COMPARTMENT_UUID>"]
}
}
}条件に入れるのは、現在と過去のすべてのワークスペースです。
Google Cloud KMS
| 原因 | 直し方 |
|---|---|
| 組織ラベルの誤り | 直し方鍵に組織ラベルを付け、値はAnthropicの組織IDを小文字にしたものにする |
| ドメイン制限共有 | 直し方この組織ポリシーがAnthropicのサービスアカウントへの付与を阻むため、例外を追加する |
| 鍵バージョンの無効化・破棄 | 直し方プライマリバージョンを有効にする |
付与の状態は、gcloud kms keys get-iam-policy で確認できます。鍵名・プロジェクト・ロケーション・キーリングを指定します。
gcloud kms keys get-iam-policy <your-key-name> \
--project=<your-project-id> \
--location=<region> \
--keyring=<your-keyring-name>ドメイン制限共有の組織ポリシーが有効だと、Anthropicのサービスアカウントへの付与が阻まれます。例外を足さない限り、検証は通りません。設定手順はGoogle Cloud KMSでの設定を参照してください。
Azure Key Vault
| 原因 | 直し方 |
|---|---|
| 組織タグの誤り | 直し方鍵の現行バージョンに組織タグを付ける |
| ロール割り当てが未反映 | 直し方新しい割り当ては反映まで数分かかるため、待って再実行する |
| Vaultのネットワーク規則 | 直し方Anthropicが必要とするVault設定に照らして規則を見直す |
タグは「鍵」ではなく「鍵の現行バージョン」に付ける点に注意が要ります。ロール割り当ての遅延は、設定直後に検証を押して失敗したときの典型的な原因で、焦って設定をいじり直す前に数分待つのが先です。手順はAzure Key Vaultでの設定にあります。
Claude Platform on AWSでは保存時に失敗する
Claude Platform on AWSにはVerifyの段階がありません。鍵の不備は、ワークスペースに鍵を付けて保存する時点で表面化します。
| 原因 | 直し方 |
|---|---|
| キーポリシーの不一致 | 直し方get-key-policy で取り出し、セットアップページのポリシーと突き合わせる |
| 条件の不一致 | 直し方EncryptionContext や aws:SourceArn の条件に、このワークスペースを含める |
| 鍵の状態・場所 | 直し方鍵が有効で、単一リージョンで、ワークスペースと同じAWSアカウント・リージョンにあること |
| 権限不足 | 直し方操作中のプリンシパルに kms:DescribeKey・kms:Encrypt・kms:Decrypt を付ける |
それでも通らないときは、鍵のあるアカウントのCloudTrailで、拒否された kms: イベントを探します。呼び出したプリンシパルと、暗号処理なら暗号化コンテキストが載っています。原因を直したら、もう一度Saveを押します。Claude Platform on AWS全体の位置づけはClaude Platform on AWSの解説を参照してください。
鍵を付ける操作そのものが断られるとき
検証以前に、画面や操作が断られる場合があります。
断られる操作と原因
CMEK keys can only be attached to workspaces ... inference data retention enabled
ZDR(ゼロデータ保持)の組織では、鍵を付けられません。CMEKは保存データの暗号化なので、データを保存するワークスペースが前提だからです。先にそのワークスペースをStandard data retention(30日)へ切り替えます。
ワークスペースにEncryption keyの設定がない
データを保持するワークスペースにしか出ない項目です。ZDR組織の既定ワークスペースは切り替えられないため、別のワークスペースを使います。
Encryption keysの節がない
Claude ConsoleのData retentionページで、上部のドロップダウンからOrganizationを選びます。それでも出なければ、ロールに権限がないか、組織でCMEKが有効になっていません。有効化はAnthropicのアカウントチームが行います。
This workspace already has a different external key attached.
ワークスペースの鍵は差し替えられません。別の鍵を使うなら、新しいワークスペースを作ります。
データ保持の切り替えは一方通行です。鍵を付けたあとは、そのワークスペースの保持を止められません。ZDRに戻したいときは、新しいワークスペースを作って通信を移します。切り替えの前に、この点を確かめてください。
claude.aiで鍵を追加して「The encryption key couldn’t be added.」と出た場合は、鍵の検証が失敗しています。上のKMS別の表で原因を探し、直したらAdd keyをもう一度押します。ダイアログには前回の入力が残っているので、チェックボックスを選んでContinue、Addと進めば再試行できます。
CloudTrailに出る拒否ログは異常ではない
Claude PlatformとClaude Enterpriseでは、鍵の検証、ワークスペースへの紐づけ、claude.aiでの鍵の表示のたびに、Anthropicが鍵の状態を確かめます。この確認1回ごとに、アクセス拒否のエラーが4件、CloudTrailへ記録されます。想定された動作で、障害ではありません。
監視アラートに引っかかるのを避けたい場合は、次の3つの値を全部満たすイベントだけを除外します。
requestParameters.encryptionContext.associatedDataがY21lay12YWxpZGF0aW9uuserIdentity.accountIdが915198916910resources.ARNが自分の鍵のARN(arn:aws:kms:<REGION>:<AWS_ACCOUNT_ID>:key/<KEY_ID>)
1つ目の値は、Base64をデコードすると cmek-validation という文字列です。ただし、1つ目だけで除外してはいけません。この値は誰でも設定できるため、1つ目だけでは判定の根拠になりません。3つを組み合わせて、Anthropicの検証だけを選び出します。
切り分けで迷ったときの指針
エラーの出る場所とコードから考えると、確認先は決まります。
- 登録時に失敗する: KMS別の表
- 400で
cmek_key_disabled: 鍵の状態、Anthropicのアクセス権、ワークスペースの記載漏れ、IP条件 - 400で
cmek_key_network_blocked: KMS側のネットワーク規則とAnthropicのIP - 503で
cmek_key_unreachable: 再試行とKMSの稼働確認
表に当てはまる原因が見つからない場合は、Anthropicのアカウントチームに連絡する流れになります。連絡のときは、失敗した操作、エラーコード、CloudTrailで見つけた拒否イベントを添えると、切り分けが早く進みます。CMEKの全体像と保護される範囲はCMEKの概要にあります。