CMEK(顧客管理暗号鍵)は日本企業の暗号鍵管理要件を満たすか

CMEKは日本企業の暗号鍵管理要件を満たすか

結論から言うと、CMEK(Customer-Managed Encryption Keys)は「鍵の管理主体を自社に置く」という要件は満たしますが、「データを日本国内に置く」という要件は満たしません。この2つは別の規制軸であり、日本企業がCMEKを評価するときに最も混同しやすいポイントです。

CMEKは、AWS KMS・Google Cloud KMS・Azure Key Vaultのいずれかで発行した暗号鍵をAnthropicに渡し、ワークスペースのデータ保管時暗号化にその鍵を使わせる仕組みです。鍵のローテーション・監査・失効(revocation)はすべて自社側が握り続けます。Anthropicが鍵に対して行った操作(データキーのラップ/アンラップ等)は自社のクラウド事業者の監査ログに記録されます。有効化はAnthropicアカウントチームへの申請が必要なオプトイン機能で、Claude PlatformではOrganization Admin、Claude EnterpriseではOwner/Primary Ownerのみが設定できます。

CMEKが保護するデータと、対象外のまま残るデータ

CMEKを有効化すると、Claude Platformではメッセージ内容・ファイル・MCP/ツール設定・Claude Managed Agentsのデータが自社鍵で暗号化されます。Claude Enterpriseではチャット内容・添付ファイル・Claude Code(CLI)のメッセージ内容・Cowork(Claude Desktop)・ローカルセッションのトランスクリプトなどが対象です。バックアップやスナップショットも鍵を継承します。

一方で、次のデータは自社鍵の対象外のままAnthropic管理鍵で暗号化され続けます。

さらにCMEKを有効化すると、一部機能自体が無効化されるか大きく仕様変更されます。Claude Consoleのプレイグラウンド、生の本文を返すCompliance APIの一部、Claude Enterpriseでは会話履歴検索・Project knowledge検索(RAG)・監査ログのエクスポートなどです。RAGが無効化されると、プロジェクトのナレッジは検索されずに会話コンテキストへ直接読み込まれる方式に切り替わるため、読み込めるナレッジ量が実質的に減少します。機能別の無効化リストの全量はClaude CMEKの機能制限一覧にまとめています。CMEKを評価するときは「鍵管理要件を満たすか」と同じ重みで「業務で使っている機能が制限を受けないか」も確認が必要です。

「暗号鍵管理」と「データの保存地域」は別の規制軸

ここが本記事の核心です。公式ドキュメントは次のように明記しています。

つまりCMEKを有効化しても、データそのものの処理・保管はAnthropicの米国インフラで行われる点は変わりません。CMEKが変えるのは「暗号鍵を誰が管理するか」であって、「データがどの国のインフラで処理されるか」ではないのです。

日本企業がFISC(金融情報システムセンター)の安全対策基準や、重要インフラ事業者向けの内部統制で「自社が鍵管理を掌握していること」を求められている場合、CMEKはその要件に技術的に対応できます。しかし個人情報保護法の越境移転規制や、業界ガイドラインが「データの国内保管」そのものを求めている場合は、CMEKだけでは要件を満たせません。データの保存地域そのものを検討する場合は、Claudeのworkspace geoが日本企業のデータローカライゼーション要件を満たすかを合わせて確認してください。

CMEK対応のAPIとツールの範囲

CMEKが暗号化の対象にできるのは、次のClaude PlatformのAPIとツールです。導入前に、自社が使う機能がこの範囲に含まれているかを確認してください。

対応API: Messages、Models、Files、Batch、Skills、Claude Managed Agents

対応ツール・機能: Web検索、Webフェッチ、コード実行、Bashツール、テキストエディタツール、MCPコネクタ、構造化出力(Claude FableおよびClaude MythosモデルではCMEK組織で非対応)、Advisorツール、コンピュータ操作、ブラウザ操作、コンテキスト管理

有効化の前提条件として、ゼロデータリテンション(ZDR)設定との併用が許可されている点も確認事項に入ります。CMEKはClaude Platform・Claude Enterpriseのいずれでも、ZDR設定と組み合わせて使えます。

CMEKでもAnthropicがデータを保持する3つの例外ケース

CMEKを有効化しても、次の3つの狭い例外に該当する場合は、Anthropicが自社鍵の外側(Anthropic管理鍵)で特定の記録を保持することがあります。

1. 法律で記録の保持が義務づけられている場合(例: 米国法18 U.S.C. § 2258Aに基づくNCMECへの報告対象)
2. 重大な危害の切迫したリスクがある場合(化学・生物・放射性物質・核兵器の開発、サイバー攻撃、暴力の差し迫った脅威など)
3. Anthropicの商用利用規約(またはこれに相当する契約条項)の違反があった場合

CSAM(児童への性的虐待に関する素材)のスクリーニングを除き、保持には人間のレビュー担当者による明示的な判断が必要です。保持が発生するたびに、理由コードを伴うイベントがCompliance APIのActivity Feedに記録されます。日本企業がCMEKの保護範囲を評価する際は、「鍵を自社が管理していれば一切の例外がない」という理解ではなく、この3ケースを認識したうえで契約・社内規程に反映しておくのが実務的です。

評価すべき3つの軸で切り分ける

CMEKの規制適合性を評価するときは、次の3軸で分けて確認すると混同を避けられます。

自社の要求事項がどの軸に属するかを先に切り分けることで、CMEKの導入だけで対応が完結するのか、データレジデンシー面の追加対応(または導入見送り)が要るのかを判断できます。

鍵管理サービスへのアクセス制御も確認事項に入る

CMEKはAnthropic側の標準パブリックIP範囲からKMSを呼び出す設計です。自社のKMSでIPベースのアクセス制限をかけている場合は、公式ドキュメントの「IP addresses」ページに記載されたアドレスを許可リストに追加する必要があります。Claude Platform on AWSでは事情が異なり、IPベースの制限に頼らず、AWS KMSのキーポリシーでアクセス範囲を絞る方式が案内されています。

Claude Platform on AWSはCMEKの中でも例外的な扱いです。AWS KMSキーのみに対応し、Google Cloud KMSやAzure Key Vaultのキーは登録できません。米国リージョン限定という制約も適用されず、代わりにキーはワークスペースと同じAWSアカウント・同じリージョンの単一リージョンKMSキーである必要があり、キーポリシーはAnthropicのIAMロールではなくAWSのサービスプリンシパルにアクセス権を付与する形になります。別建ての検証ステップは無く、ワークスペースへの鍵の紐づけ自体が暗号化・復号のラウンドトリップを実行するため、鍵ポリシーの設定ミスは登録時ではなく紐づけ時に表面化します。日本のAWS利用企業がCMEKを検討する場合、この「Claude Platform on AWSは例外」という区分を理解しておかないと、他の2つのKMSプロバイダー向けの手順を誤って適用してしまうおそれがあります。

CMEKの不可逆性というリスク管理上の論点

CMEKにはもう一つ、日本企業のリスク管理部門が見落としやすい制約があります。一度ワークスペースに鍵を紐づけると、取り外しや別の鍵への切り替えができません。異なる鍵に変更したい場合は新しいワークスペースを作成してデータを移行する必要があります。さらに鍵を失効・削除すると、そのワークスペースのCMEK対象データは復旧不能になります。Anthropicは鍵の複製を保持しないため、鍵の誤削除や設定ミスがそのまま永続的なデータ損失につながります。

加えてClaude Platformでは、鍵を紐づけると同時にワークスペースのデータ保持設定もロックされます。30日保持で運用を始めた後にゼロデータリテンション(ZDR)へ切り替えたくなっても、既存ワークスペースの設定変更では戻せず、新しいワークスペースを作成し直す必要があります。前段で触れたZDRとの併用可否は「導入時にどちらを選べるか」の話であり、「後から変更できるか」は別の制約として押さえておく必要があります。

鍵失効時の挙動と復旧手順の有無

失効は最大1時間(キャッシュTTL)で反映されます。Compliance APIのローカルセッション書き起こし取得エンドポイントでは、鍵が使用不能な場合コンテンツの代わりに503エラーを返す設計です。Anthropic側に鍵のバックアップや復旧経路はなく、鍵管理サービス側でのバックアップ・アクセス権限管理が事実上の生命線になります。

事業継続計画(BCP)の観点では、CMEKは「鍵を失えばデータを失う」というトレードオフを伴う機能です。金融機関がCMEKを稟議にかける際は、暗号鍵管理要件を満たすメリットと、鍵の管理体制(バックアップ・アクセス権限・二重チェック)を強化するコストの両方を並記する必要があります。

まとめ

CMEKは「暗号鍵の管理主体を自社に置く」という日本企業の規制要件には技術的に対応できる機能です。クラウド事業者の監査ログとCompliance APIのActivity Feedが監査証跡を、KMS側のアクセス制御が鍵の掌握を担保します。一方で、データの処理・保管は現状米国リージョンに固定されており、データの国内保存そのものを求める要件はCMEKでは満たせません。加えて鍵の不可逆性という運用リスクも伴います。導入判断は「鍵管理主体」「監査証跡」「データ所在地」の3軸に分けて評価し、データ所在地が要件に含まれる場合は別途の対応(または要件側の再確認)が必要になります。