契約では法律を上書きできない：データ主権は契約ではなくアーキテクチャで実現すべき理由

はじめに

クラウドサービスのベンダー契約には必ずデータ保護に関する条項が含まれています。たとえば、機密保持条項、データ処理契約、データの保存先や転送先に関する約束などです。これらの条項は重要であり、どの組織もこれらがない契約に署名すべきではありません。しかし、これらの条項では、裁判所や政府機関がベンダーに対して保有データの提出を合法的に強制した場合に発生する事態を変えることはできません。

このギャップこそが、法務・コンプライアンス部門を事後的に驚かせる原因です。契約は署名した2者間を拘束します。一方、合法的な強制命令は、ベンダーを命令を発行した第三者（当局）に拘束させ、その義務はベンダーの顧客に事前の許可を求めるものではありません。両者が衝突した場合、法律が優先され、契約のデータ保護条項は善意の証拠にはなっても防御策にはなりません。本記事では、データ主権のコミットメントは契約上ではなくアーキテクチャ上で担保される必要がある理由と、その違いが実務でどのように現れるかを解説します。

ポイント1：ベンダーの契約上の約束は、そのベンダーに対して出された合法的な強制命令を上書きすることはできません。裁判所や当局が合法的に開示を強制する場合、ベンダーの遵守義務は顧客との合意内容とは独立して発生します。

ポイント2：契約は2者間を拘束しますが、法的強制は契約が及ばない第三者が関与します。データ処理契約は、ベンダーと政府当局間の法的手続きにおいて効力を持ちません。

ポイント3：ベンダーが復号鍵を保有している場合、その鍵の使用を強制されることがあります。プロバイダーが技術的に顧客データを復号できる場合、その能力自体が合法的な命令の対象となります。

ポイント4：ベンダーの技術的な対応能力を排除すれば、リスク自体を完全に排除できます。ベンダーが命令を受けてもデータを復号できない場合、命令によって開示されるのは暗号文のみで、可読な情報は開示されません。

ポイント5：主権コミットメントには、契約上の文言だけでなくアーキテクチャによる担保が必要です。インフラ設計によって担保されるコミットメントは、どんな文書の内容にも左右されません。

要約

法務・コンプライアンス部門は、ベンダーの契約上のデータ保護コミットメントを、無許可のデータ漏洩に対する主な防御策とみなすことがよくあります。しかし、この前提は合法的な強制命令が発生した瞬間に崩れます。なぜなら、その命令はベンダーと第三者当局間に義務を生じさせ、顧客契約ではそれを上書きできないからです。唯一信頼できる防御策は技術的なものです。つまり、ベンダーが有効な命令に従っても可読データを提供できないアーキテクチャを構築することです。これにより、データ主権は交渉による契約条項から、導入時に組み込むべき本質的な特性へと再定義されます。

契約上のデータ保護コミットメントが構造的に持つ限界

契約は、2者間の義務についての合意です。データ処理契約や機密保持条項、マスターサービス契約における主権コミットメントも、すべてこの2者間の関係内で機能します。これらはいずれも、署名していない第三者を拘束することはできません。そして、ベンダーに合法的な命令を出す政府当局はまさにそのような第三者です。

合法的な強制命令が実際に変えるもの

ベンダーに対して管轄権を持つ当局が、ベンダーの保有・管理・支配下にあるデータの開示を合法的に命じる場合、ベンダーの遵守義務はその管轄の法律に基づいて発生します。これは、米国クラウド法（US CLOUD Act）などの法律の根本原則と同じです。ベンダーが顧客の契約上の期待を守ろうとして有効な命令に抵抗すれば、ベンダー自身が独自の法的リスクにさらされます。実際には、合理的なベンダーは命令に従い、その結果生じる顧客関係の問題は別途対応します。契約が失敗したのは、ベンダーの不注意ではなく、そもそもこの種の義務に対抗できる立場に契約がなかったためです。

このリスクが暗号鍵の管理に集中する理由

このリスクが具体化するポイントは、暗号鍵の管理です。ベンダーが顧客データの復号に必要な鍵を保有している場合、その復号能力自体が合法的な命令の対象となります。命令はベンダーに新たな能力を求める必要はなく、既存の能力を使うよう強制するだけで十分です。だからこそ、鍵の管理が、単なる暗号化の有無以上に、強制命令で実際に引き出せるものを決定します。

ベンダーの復号能力を排除することでギャップを埋める方法

リスクがベンダーの技術的な能力に集中するのであれば、解決策もそこに集中します。組織は有効な法的命令を交渉で回避することはできませんが、その命令に従っても利用価値のあるものが得られないようにすることは可能です。

鍵のない暗号文は可読データではない

顧客が自身の暗号鍵を保有し、通常はベンダーのインフラ内ではなくハードウェアセキュリティモジュールと連携して管理している場合、ベンダーは自ら復号できない暗号化データのみを保有することになります。ベンダーが保有するデータの提出を命じられても、命令には従っていますが、提出できるのは暗号文だけです。そもそもベンダーの手元に可読データは存在していません。

これは方針ではなくアーキテクチャ上の事実である理由

この違いが重要なのは、ベンダーの意図や法務部門の主張、開示命令への抵抗意志に依存しないからです。純粋に、ベンダーが技術的にデータを復号できるかどうかというエンジニアリング上の事実に依存します。方針によるコミットメントは、法的圧力下で撤回・再解釈・上書きされる可能性がありますが、システムの技術的制約は、そもそも能力が存在しないため、ベンダーが議論で覆せるものではありません。

法的圧力でも覆せない主権コミットメントの構築

法務・コンプライアンス部門にとって、これはベンダーのデータ保護主張を評価する際のデューデリジェンスの観点を再定義します。問うべきは契約の約束内容だけでなく、その約束と矛盾する有効な法的命令が届いた場合に何が起きるかです。ベンダーは可読な顧客データを開示できる技術的手段を保持しているのか、それともその能力自体が完全に排除されているのか。これを判断するには、契約書だけでなく、導入アーキテクチャや鍵管理モデルも併せて確認する必要があります。なぜなら、強制命令以外の場面（責任分担、違反通知、監査権、日常の運用義務など）では契約も依然として重要だからです。契約が唯一代替できないのは、主権が実際に試されるその瞬間におけるアーキテクチャです。

データコントロールプレーンによる主権コミットメントの担保

データコントロールプレーンは、鍵管理や導入先の管轄をアーキテクチャの特性として組み込むことで、このギャップを解消します。これにより、法的命令で回避できる契約条項ではなく、システム設計そのものが担保となります。メール、ファイル共有、API、AIエージェントなど、あらゆるチャネルでの送信・共有・アクセスを制御し、そのインフラの管轄や鍵管理をベンダーではなく顧客がコントロールします。

Kiteworksは、顧客所有の暗号鍵をハードウェアセキュリティモジュール経由で統合するため、将来どんな法的命令が出されてもベンダー自身が顧客データを復号できません。導入はシングルテナントアーキテクチャで運用され、組織はオンプレミス、自社クラウドテナンシー、専用ホスティングインスタンスのいずれかを選択できるため、インフラの管轄はベンダーのデフォルトではなく顧客自身が決定します。その基盤の上で、データ認識型のゼロトラスト制御がすべての送信・共有・アクセスを強制し、すべての操作は改ざん不可能かつ制限のない監査ログに記録され、SIEMツールに直接連携されます。これにより、法務・コンプライアンス部門は、どの時点でも契約文言に依存しない実際の制御状況を記録として確認できます。

主権コミットメントが法的圧力下でも維持されるかを契約に頼るのではなく、この基準で自社の状況を検証したい組織は、get back in CTRL ― 顧客主導の鍵管理と導入管轄が既存のベンダー関係にどう適用できるかをぜひご覧ください。