ZDR（ゼロデータ保持）とは
「保存しない」側の約束を、既定か申請制かで整理した第7回。ZOAと対で読むページです。
解説を読む →ZOA（ゼロオペレーターアクセス）とは — 「保存しない」と「見られない」は別の約束
用語説明 第9回。第7回の ZDR（ゼロデータ保持） と第8回の データの4要件 で、ZOAは「見せない」＝サービス運営者側の人間が中身にアクセスできないこととして一度だけ登場しました。 このページはそこを深掘りします。ZDRが「保存の話」なら、ZOAは「人のアクセスの話」です。保存していなくても処理の途中で見ることは理論上でき、逆に30日保存していても運営者が復号できなければ中身は読めません。2つは独立した約束で、片方を満たしてももう片方は満たしません。 ここでは、アクセスを止める仕組みを① 手続き ② 鍵 ③ 実行環境の3層に分け、各社が公開している逐語で「何が既定で、何が申請制か」を並べます。
ZOA（ゼロオペレーターアクセス）＝ サービスを運営している側の人間が、あなたのデータを復号・閲覧できないという約束。
1. ZOAが防ぐもの・防がないもの
このページで「オペレーター（運営者）」というときは、クラウド事業者＝サービスを提供する側の運用担当者・サポートエンジニア・基盤管理者を指します（例: AWS の運用担当者）。攻撃者や他テナントの話ではありません。一方、そのクラウドを使う企業側の担当者（自社の情報システム部門・運用チームなど）は別の主体で、ZOA が約束する対象ではありません。つまり ZOA は「提供者側の人間が悪意を持つ場合まで含めて、そもそも読めないようにする」という設計目標で、自社側の担当者が読めるかどうかは、自社の権限設計・鍵管理の話になります。
| 問い | ZOAが答える範囲 | 注意点 |
|---|---|---|
| クラウド事業者（運営者）の社員は中身を読めるか | 読めない（設計上・手続き上） | 「読めない」の担保方法は、手続き／鍵／実行環境の3通りあり、強度が違います。 |
| 自社（そのクラウドを使う企業）の運用担当者は読めるか | ZOAの対象外 | 別の主体です。社内の権限設計次第で読めます。ZOAは「提供者側が読めない」約束で、社内の担当者が読めるかどうかは別の問題です。 |
| 第三者のモデル提供元は読めるか | 経由サービスによって別途明記される | AWSは Bedrock について「Model providers don't have any access to those accounts. Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions.」と書いています。「クラウド事業者（運営者）」と「モデル提供元」は別の主体です。 |
| データを保存しているか | 答えない（ZDRの担当） | 保存期間はZDRの話。ZOAは0日でも30日でも成立し得ます。 |
| 学習に使われるか | 答えない（契約条項の担当） | 学習への利用は契約側の条項です（第8回の「学ばせない」）。 |
| 法令に基づく開示請求には耐えるか | 提供元のポリシー次第 | ZOAで中身が読めない設計なら、そもそも提出できる平文が存在しない、という主張になります。ただし提供元の公表内容の範囲でしか確認できません。 |
← 横にスクロールできます →
2. 「保存しない（ZDR）」と「見られない（ZOA）」は別の約束
混同が生まれるのは、両方を1つの文で説明しているベンダーが多いからです。しかし、約束の中身はまったく違います。
| 観点 | ZDR（保存しない） | ZOA（見られない） |
|---|---|---|
| 対象 | 保存されたデータ（保存期間） | 人のアクセス（誰が復号・閲覧できるか） |
| 技術的な場所 | ストレージ・ログ | 鍵・実行環境・承認プロセス |
| よくある設定方法 | アカウント／プロジェクト／リクエスト単位の保持モード | 顧客管理鍵の利用、承認フローの有効化、機密コンピューティングの構成 |
| 破れたときに起きること | データが残る（期間は提供元次第） | 残ったデータを担当者が読める（保存の有無とは無関係） |
| 代表的な落とし穴 | 既定で保持される／例外モデルがある | 既定で有効なわけではない・緊急時の例外がある |
← 横にスクロールできます →
“Amazon Bedrock uses a zero operator access (ZOA) data security model. This means no operators of the service can access model input or output. Also, Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs.”
— AWS 公式ドキュメント「Amazon Bedrock abuse detection」（2026-09-27 取得）
ZDR側には「by default」という但し書きが付き、さらに保持が必要なモデルの例外リストが続きます。対してZOA側の記述には、この種の但し書きも例外リストもありません。ただし、これは「ZOAなら人手が一切入らない」という意味ではありません。AWSはBedrockのZOAを「サービスのオペレーターはモデル入出力にアクセスできない」と説明する一方で、保持モードにはAWS内の人手レビューのために入出力を保持する aws_review を用意しています（逐語は下の「3. アクセスを止める3つの層」で引用）。ZOAは「運営者がアクセスできない」という約束、保持モードは「保存するかどうか」という別レイヤーの設定で、ZOAの記述だけから個別のモードに人手レビューがないとは判断できません。「既定の状態が何か」は要件ごとに別々に確認する必要があります。
3. アクセスを止める3つの層
各社のドキュメントを読むと、アクセスを止める手段は3つの層に整理できます。層によって「何を根拠に止めているか」が違います。
← 横にスクロールできます →
4. 鍵管理の3段階 — CMK / BYOK / HYOK
「暗号化しているから運営者は読めない」は、鍵を誰が持っているかを確認しないと成り立ちません。用語が似ていて混同しやすいので、3段階に分けます。
| 項目 | CMK（カスタマー管理キー） | BYOK（Bring Your Own Key） | HYOK（Hold Your Own Key） |
|---|---|---|---|
| 鍵素材の生成 | 提供者のKMS／HSMが生成 | 顧客が生成して持ち込む | 顧客が自分の環境で生成・保持 |
| 鍵素材の保管場所 | 提供者のKMS／HSM内 | 提供者のKMS内（持ち込み後） | 提供者の外（顧客のHSM／鍵管理システム） |
| 暗号演算を行う主体 | 提供者 | 提供者 | 顧客側の鍵管理システム（提供者は毎回問い合わせる） |
| 顧客ができること | 利用者・権限・削除の管理 | 失効・有効期限の設定、即時削除 | 提供者の外で鍵を止められる（復号要求を拒否できる） |
| 提供者が理論上復号できるか | できる（権限を持つ） | できる（鍵素材がKMS内にある） | できない設計（鍵素材が外に出ない） |
| 代表的な実装名 | AWS KMS カスタマー管理キー / Google CMEK / Azure Key Vault | AWS KMS の鍵素材インポート / Azure Managed HSM へのBYOKインポート | AWS KMS External Key Store（XKS）/ Google Cloud EKM / Azure Managed HSM の外部鍵管理 |
← 横にスクロールできます →
HYOKの逐語（AWS KMS External Key Store）
“Encryption and decryption operations that use a KMS key in an external key store are performed by your external key manager using your cryptographic key material, a feature known as hold your own keys (HYOKs).”
“AWS KMS never interacts directly with your external key manager, and cannot create, view, manage, or delete your keys. Instead, AWS KMS interacts only with external key store proxy (XKS proxy) software that you provide.”
“Your cryptographic key material never leaves your external key manager.” — AWS KMS 開発者ガイド「External key stores」（2026-10-01 取得）
“AWS KMS never interacts directly with your external key manager, and cannot create, view, manage, or delete your keys. Instead, AWS KMS interacts only with external key store proxy (XKS proxy) software that you provide.”
“Your cryptographic key material never leaves your external key manager.” — AWS KMS 開発者ガイド「External key stores」（2026-10-01 取得）
BYOKの逐語（鍵素材を持ち込む）
“When you create a KMS key, by default, AWS KMS generates the key material for that KMS key. But you can create a KMS key without key material and then import your own key material into that KMS key, a feature often known as ‘bring your own key’ (BYOK).”
“You can set an expiration time on import or call DeleteImportedKeyMaterial to revoke access immediately.” — AWS KMS 開発者ガイド「Importing key material」「Key stores」（2026-10-01 確認）
“You can set an expiration time on import or call DeleteImportedKeyMaterial to revoke access immediately.” — AWS KMS 開発者ガイド「Importing key material」「Key stores」（2026-10-01 確認）
HYOKの逐語（Microsoft / Google Cloud）
“Keys are generated and stored in a single-tenant, FIPS 140-3 Level 3 HSM that only you control: Microsoft has no access to your key material, and you govern who can use each key.”
“Microsoft can’t decrypt your key material or recover your HSM cluster without it.”
“The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.”
“The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it.” — Azure 公式ブログ「External key management for Azure Managed HSM」（2026-10-01 取得）
“Microsoft can’t decrypt your key material or recover your HSM cluster without it.”
“The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.”
“The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it.” — Azure 公式ブログ「External key management for Azure Managed HSM」（2026-10-01 取得）
“Data encrypted using a Cloud EKM key can’t be decrypted without both the external key material and the internal key material.”
“With Cloud EKM, you can use keys that you manage within a supported external key management partner to protect data within Google Cloud.” — Google Cloud ドキュメント「Cloud External Key Manager」（2026-10-01 取得）
“With Cloud EKM, you can use keys that you manage within a supported external key management partner to protect data within Google Cloud.” — Google Cloud ドキュメント「Cloud External Key Manager」（2026-10-01 取得）
⚠️ HYOKの引き換え条件: 鍵素材を外に置くということは、暗号演算のたびにあなたの側のシステムが応答する必要があるということです。自社HSMが落ちれば、クラウド側のサービスも復号できません。可用性・レイテンシ・運用責任（バックアップ、パッチ、障害対応）はあなた側に移ります。AWSのXKSでも「AWS KMS interacts only with external key store proxy (XKS proxy) software that you provide」と、プロキシの提供者・運用者が顧客側であることが明記されています。「最強の設定」ではなく「責任を引き受ける設定」です。
5. 「利用者の操作なしにアクセスできない」ことをどう担保するか
鍵の層と実行環境の層は技術の話ですが、現実のクラウドでは「クラウド事業者側の運用担当者がどうしても触る必要がある場面」があります（障害調査・不正利用の調査など。そのクラウドを使う企業側の担当者の話ではありません）。そこで第1層＝承認フローが効きます。「顧客が承認しないと入れない」という仕組みです。
| 提供元 | 仕組み | 顧客が握るもの | 例外・注意 |
|---|---|---|---|
| Microsoft（Azure） | Customer Lockbox | アクセス要求の承認・拒否 | 要求は顧客のキューに4日残り、過ぎると自動的に失効しアクセスは付与されません。緊急時（break glass）はロックボックスが発動しないと公式に明記されています。 |
| Google Cloud | Access Approval ＋ Access Transparency ＋ Key Access Justifications（KAJ） | 人によるアクセスの承認と、暗号鍵へのアクセス要求ごとの承認・拒否 | KAJはKAJの対象として登録した顧客管理鍵（CMEK）について、各アクセス要求（復号などの暗号操作）ごとに「理由コード」を発行し、顧客のポリシーで可否を決められます。理由コードの種類によっては拒否すると可用性が下がるもの（例: GOOGLE_INITIATED_SERVICE）があります。 |
| Anthropic | controlled access path（管理されたアクセス経路） | —（レビューの発生条件が限定される） | 逐語では「自動の信頼安全性システムがフラグを立てた場合に限り、管理されたアクセス経路でのみ人間がレビューできる」という構造です。 |
| OpenAI | ZDR with Private Safety Processing（PSP）／ Enterprise Key Management（EKM） | 復号に必要な権限と鍵の承認 | 安全レビュー時に人間が読める経路を新たに作らないことが原則として明記され、復号はハードウェア検証された専用ランタイムで行う設計です。 |
| AWS（Bedrock） | ZOA モデル ＋ 保持モード（none 等） | 保持モードの選択（アカウント／プロジェクト／リージョン単位） | 保持モードにはaws_review（AWSによる人間レビューのために保持するモード）が存在します。保持モードは別レイヤーの設定で、aws_review を選べばAWS内での人手レビューが入り得ます。ZOAの記述だけから「人手は一切入れない」と結論しないでください。 |
← 横にスクロールできます →
逐語で確認する
“In those rare circumstances where Microsoft requires such access, Customer Lockbox for Microsoft Azure provides an interface for your organization to review and approve or reject customer data access requests.”
“The request remains in the customer queue for four days. After this time, the access request automatically expires and no access is granted to Microsoft engineers.”
“Approve: The Microsoft engineer receives access for the duration specified in the request details …”
“Deny: Customer Lockbox rejects the elevated access request by the Microsoft engineer and takes no further action.” — Microsoft Learn「Customer Lockbox for Microsoft Azure」（2026-10-01 取得）
“The request remains in the customer queue for four days. After this time, the access request automatically expires and no access is granted to Microsoft engineers.”
“Approve: The Microsoft engineer receives access for the duration specified in the request details …”
“Deny: Customer Lockbox rejects the elevated access request by the Microsoft engineer and takes no further action.” — Microsoft Learn「Customer Lockbox for Microsoft Azure」（2026-10-01 取得）
“Access Approval lets you authorize requests from Google personnel to access Customer Data, Access Transparency helps you discover information about when Customer Data is accessed, and Key Access Justifications provides key access control for all interactions with at-rest Customer Data that is encrypted by a customer-managed key.”
“Key Access Justifications lets you set a policy on Cloud KMS keys to view, approve, and deny key access requests depending on the provided justification code.”
“Support tickets typically don’t require this access and our frontline support personnel don’t have this access.” — Google Cloud ドキュメント「Overview of Key Access Justifications」「View and act on justifications」（2026-10-01 取得）
“Key Access Justifications lets you set a policy on Cloud KMS keys to view, approve, and deny key access requests depending on the provided justification code.”
“Support tickets typically don’t require this access and our frontline support personnel don’t have this access.” — Google Cloud ドキュメント「Overview of Key Access Justifications」「View and act on justifications」（2026-10-01 取得）
“Safety review must not create a new way for OpenAI personnel to read protected customer content. Encrypted customer content is decrypted in an approved, hardware-attested safety runtime that disables human access. Only bounded safety signals and operational metadata leave the PSP protected review in plaintext.”
“The Safety Review Runtime, a hardware-attested computing environment that disables human access, is designed to be the only workload that can decrypt customer content.” — OpenAI 開発者ドキュメント「ZDR with Private Safety Processing」（2026-10-01 取得）
“The Safety Review Runtime, a hardware-attested computing environment that disables human access, is designed to be the only workload that can decrypt customer content.” — OpenAI 開発者ドキュメント「ZDR with Private Safety Processing」（2026-10-01 取得）
“By default, no Anthropic personnel can read your retained conversations. Human review can occur only through a controlled access path … when content is flagged by our automated trust and safety systems”
— Anthropic サポート「Data retention practices for covered models」（2026-09-27 取得）
“This mode allows your inputs and outputs to be retained for human review by AWS. Review is carried out by AWS within the AWS boundary — the model provider does not review your content”
— AWS 公式ドキュメント「Amazon Bedrock data retention」（
aws_review モードの説明・2026-09-27 取得）
⚠️ 「承認フローがある＝必ず承認が要る」ではありません。Microsoft は Customer Lockbox が発動しない例として、逐語で「Emergency scenarios that fall outside of standard operating procedures and require urgent action from Microsoft to restore access to online services or to prevent corruption or loss of customer data, or to investigate a security or abuse incident. … These “break glass” events are rare …」と書いています。ZOAは「絶対に人が入れない」ではなく「通常運用では人が入れない＋例外の条件が明示されている」と理解するのが正確です。例外の条件そのものが公開されている点に、確認する価値があります。
6. ベンダー別の提供状況（提供有無・対象・有効化方法）
「提供されているか」「どのサービスが対象か」「どうやって有効にするか」を分けて並べます。提供有無が確認できなかったものは未確認としています。
| 提供元 | 提供有無 | 対象サービス（確認できた範囲） | 有効化方法 |
|---|---|---|---|
| AWS | ZOA：あり（Bedrockのデータセキュリティモデルとして明記）／ HYOK：あり（KMS External Key Store） |
ZOAは Amazon Bedrock。HYOKは AWS KMS の外部キーストア。BedrockがXKS（HYOK）に対応しているかは本調査では未確認。 | Bedrockのデータ保持モードを設定（アカウント／プロジェクト／リージョン単位、新規はinheritが既定）。HYOKはKMSで外部キーストアを作成し、自社のXKSプロキシを用意。 |
| Microsoft（Azure） | 手続き：あり（Customer Lockbox）／ 鍵：あり（Managed HSM・Cloud HSM）／ 実行環境：あり（機密コンピューティング） |
Customer Lockbox は Azure サービス。Managed HSM は FIPS 140-3 Level 3 のシングルテナントHSM。Microsoft Foundry 上のモデルに Customer Lockbox がどこまで適用されるかは未確認。 | Customer Lockbox は対象サービスで有効化すると、以降のアクセス要求が顧客承認制に。鍵は Managed HSM を作成し、ローカルRBACとオフライン保持のクォーラムで運用。実行環境は機密コンピューティングを有効化して正しく構成する。 |
| Google Cloud | 手続き：あり（Access Approval / Access Transparency）／ 鍵：あり（Cloud EKM・CMEK）／ 鍵アクセス制御：あり（Key Access Justifications） |
Cloud EKM は外部鍵管理パートナー経由。Vertex AI 上のモデル呼び出しに KAJ が全面的に適用されるかは未確認。 | Access Approval を有効化して人のアクセスを承認制に。KAJは顧客管理鍵（CMEK）にポリシーを設定し、理由コードごとに可否を決める。外部鍵ならパートナー側のポリシーでも強制可能。 |
| OpenAI | 鍵：あり（Enterprise Key Management）／ 安全レビュー：あり（ZDR with Private Safety Processing）／ 実行環境：プレビュー（Private Inference・2026年秋予定） |
APIプラットフォーム。EKMは顧客の外部KMSの鍵で暗号化。PSPは顧客管理ストレージ＋顧客管理のEKM承認を前提とします。 | 本調査で確認した範囲では、いずれも既定では有効にならず、設定・確認が必要です。EKMは外部KMSの鍵での暗号化、PSPはZDR承認済みの組織が顧客管理ストレージの登録・検証を行って設定します。Private Inference はプレビューです。 |
| Anthropic | アクセス経路の制限：あり（controlled access path）／ ZDR：あり（申請制）／ カスタマー管理鍵：未確認 |
Claude API（第一者提供）。第一者提供でカスタマー管理鍵／HYOK が用意されているかは、本調査では公式記載を確認できませんでした。Bedrock / Vertex 経由なら各クラウドの鍵管理を使うことになります。 | ZDRはアカウント担当者経由で申請。ただし第7回で扱ったように、保持が必須のモデル（Covered Models）はZDRの対象外です。 |
← 横にスクロールできます →
💡 「未確認」を空欄にしていない理由: 「書いていない＝提供していない」と読まれると誤情報になります。逆に「提供しているはず」と推測して書くのも誤情報です。確認できた範囲と、できなかった範囲を分けて示すのが当サイトの方針です。
7. 混同しやすい3つの誤解
- 「ZDRにしたから、運営者にも見られない」
- 別の約束です。ZDRは保存しないこと、ZOAは人がアクセスできないこと。処理中のメモリ上の平文を守るのは第3層（実行環境）の仕事で、保持モードの設定では変わりません。両方を別々に確認してください。
- 「暗号化しているから、運営者も中身は読めない」
- 鍵を誰が持っているか次第です。CMKでも鍵素材は提供者のKMS内にあり、復号を実行するのは提供者側の基盤です。「提供者の人間が復号できない」ことの保証にはなりません。HYOKまで進めて初めて「鍵素材が提供者の外に出ない」と言えます（AWSの逐語:「Your cryptographic key material never leaves your external key manager.」）。
- 「HYOKにすれば全部解決する」
- 引き換え条件があります。外部鍵を使う構成では暗号演算のたびに顧客側システムへの依存が生まれ、その可用性・レイテンシ・運用責任は顧客側に移ります。またHYOKは「鍵素材を外に置く」話であって、処理中のメモリ（第3層）を守る話ではありません。層が違います。
8. 契約前に確認する5項目
- 「ZOA」という語が、どの層を指しているかを提供元のドキュメントで特定する。手続きの話なのか、鍵の話なのか、実行環境の話なのかで、あなたがやるべき設定が変わります。
- ZDRとZOAを別々に確認する。ZDRの問いは「既定で保持するか／申請制か／例外モデルはどれか」。ZOAの問いは「既定でどう制御されているか／承認フローはあるか／例外条件は何か」。
- 鍵の層の到達点を決める。CMKで足りるのか、鍵素材を外に置く必要があるのか（HYOK）。HYOKを選ぶなら、自社側の可用性・運用体制まで含めて設計します。
- 「人のアクセス」の承認フローを、実際に有効化して確認する。ドキュメントに載っていることと、あなたのテナント／プロジェクトで有効になっていることは別です。
- 緊急時の例外条件を読む。Microsoftの「break glass」、Googleの理由コード、AWSの
aws_reviewのように、例外の条件は各社が公開しています。例外を知らずに「絶対に人が入れない」と説明すると、監査で崩れます。
9. よくある質問
- ZOAとZDR、どちらが強い保護ですか
- 強弱ではなく守っている対象が違います。ZDRは「残さない」、ZOAは「人に見せない」。片方だけでは説明できない事故があります（保存していなくても処理中に見られた／保存しているが誰も復号できない）。両方を別々に確認するのが正解です。
- 機密コンピューティングを使えば、運営者は絶対に見られませんか
- Azureの公式表現は条件付きです。逐語で「When Azure confidential computing is enabled and properly configured, Microsoft can’t access unencrypted customer data.」——有効化して正しく構成した場合という条件が明記されています。既定でそうなるわけではなく、設定の確認が必要です。なお、AzureのConfidential VM FAQには「Azure doesn’t have operating procedures for granting confidential VM access to its employees, even if a customer authorizes the access.」という記載もあります。
- 「ZOA」という言葉を使っているのはどこですか
- 本調査で定義文として確認できたのはAWS（Amazon Bedrock）です。Microsoftは「operator access」をリスクとして扱い、Customer Lockbox・機密コンピューティング・Managed HSMの組み合わせで説明しています。Google Cloudは「Google personnelによるアクセスの承認」という言い方で、Access Approval / Access Transparency / KAJの3つに分けて説明しています。同じ目的を、各社が別の語で説明している状態です。
- ZOAを自社の監査資料にどう書けばよいですか
- 「ZOA対応」ではなく、「どの層で何を有効化したか」を書くのが安全です。例: 「保持モードは
none」「鍵はCMK」「人のアクセスは承認フローを有効化（例外条件は提供元ドキュメントの◯◯に記載）」——この形なら、後で条件が変わっても説明が破綻しません。
- 料金は上がりますか
- 本調査ではZOA関連の設定に伴う料金改定の記載は確認していません。ただしHYOKは外部のHSM／鍵管理システムの運用コストが別途かかり、提供元側でも専用機能として提供されることがあります。提供元の料金ページは別途確認してください（当サイトでは料金比較を更新しています）。
補足: モデルサイズの「◯B（Active ◯B）」という表記
モデルの紹介で「320B（18B Active）」のような書き方を見かけます。これはモデルの大きさを表すパラメータ数の表記で、B は 10億（billion）の意味です。同じ「B」でも、2つは別のものを指しています。
- 総パラメータ数（例: 320B）＝モデルが持っている重みの合計。モデルのファイルサイズや、動かすのに必要なメモリの目安になります。
- Active（例: 18B Active）＝1つのトークンを出力するときに実際に計算へ使われるパラメータ数。専門家の分岐を持つ構造（MoE）のモデルでは、全体の一部だけが毎回使われます。
つまり「320B（18B Active）」は「320B 全部を毎回使うわけではない」という意味です。総数は載せられるか（メモリ）に、Active は計算量・速度・コストに効いてくることが多く、総数が同じでも Active が違えば体感速度は変わります（実際の速度・コストは、モデル構造や提供環境にも左右されます）。当サイトでは、モデル提供元が公表した数値のみを掲載し、非公開の内訳は推測しません。
関連ページ
出典
- AWS「Amazon Bedrock abuse detection」— ZOA と ZDR の定義（docs.aws.amazon.com・2026-09-27 取得）
- AWS「Data protection」「Data retention」— モデル提供元の非アクセス、保持モード（
none/aws_review等）（docs.aws.amazon.com） - AWS KMS「External key stores」「Importing key material」「Key stores」— HYOK と BYOK の定義（docs.aws.amazon.com・2026-10-01 取得）
- Microsoft Learn「Customer Lockbox for Microsoft Azure」— 承認・拒否・4日の失効・break glass 例外（learn.microsoft.com・2026-10-01 取得）
- Microsoft Learn「Azure Confidential Computing Overview」「Confidential VM FAQ」（learn.microsoft.com・2026-10-01 取得）
- Microsoft Azure 公式ブログ「External key management for Azure Managed HSM」— Microsoftがキー素材にアクセスできないこと、クォーラム、外部鍵がMicrosoft基盤を通らないこと（azure.microsoft.com・2026-10-01 取得）
- Google Cloud「Overview of Key Access Justifications」— Access Approval / Access Transparency / KAJ の役割分担（docs.cloud.google.com・2026-10-01 取得）
- Google Cloud「Cloud External Key Manager」（docs.cloud.google.com・2026-10-01 取得）
- OpenAI「ZDR with Private Safety Processing」— 安全レビューが人間のアクセス経路を作らないこと、hardware-attested runtime（developers.openai.com・2026-10-01 取得）
- OpenAI「Register interest in OpenAI Private Intelligence」— Private Inference はプレビュー（confidential computing と検証可能なコントロールの組み合わせ）（openai.com・2026-10-01 確認）
- OpenAI「Data controls in the OpenAI platform」— Enterprise Key Management（developers.openai.com）
- Anthropic「Data retention practices for covered models」— 既定では担当者が読めないこと、管理されたアクセス経路（support.claude.com・2026-09-27 取得）
※ 逐語の日本語訳は当サイトによる要約・補足であり、原文は各リンク先をご確認ください。原文が正です。
⚠️ 免責事項
- 本ページの内容は各社公式ドキュメントを2026-10-01（一部 2026-09-27）に確認したものです。仕様・提供条件は予告なく変わります。契約前に必ず公式ページをご確認ください。
- 本ページは法的助言ではありません。監査・契約・規制対応の判断は、各社との契約書・DPAと専門家の確認に基づいて行ってください。
- 「未確認」とした項目（AWS BedrockのXKS対応、Microsoft Foundry上のモデルへのCustomer Lockbox適用範囲、Vertex AIへのKAJ適用範囲、Anthropic第一者提供のカスタマー管理鍵）は、確認でき次第更新します。
- 本サイトは情報提供目的であり、特定プロバイダーの推薦・代理ではありません。