長い間、テクノロジーに関する意思決定は、おなじみの問いによって評価されてきました。より速いか。より安いか。スケールできるか。チームの生産性を高められるか。
それらの問いは今でも重要です。ですが、もはやそれだけでは十分ではありません。
組織が外部のインフラ、プラットフォーム、そしてますます外部のAIモデルに依存するようになると、まず先に立つのは、より厳しい問いです。条件が変わったら何が起きるのか? アクセスのコストが上がったり、制限されたり、政治的リスクにさらされたり、規制当局、取締役会、顧客に説明しにくくなったりしたら、何が起きるのでしょうか。
それが、ITとAIにおける主権の問いです。
これは単にデータがどこに置かれているかという話ではありません。より広い意味でのコントロールの問題です。誰がシステムを検査できるのか、停止させられるのか、アクセスを強制できるのか、ルールを変えられるのか、あるいは離脱を難しくできるのか。さらに、説明責任の問題でもあります。何か問題が起きたとき、最終的に責任を負うのは誰なのでしょうか。
デジタル主権に単一の世界共通の定義はありません。法域によって重視する側面は異なります。法的な及ぶ範囲、インフラへの依存、データのコントロール、運用上のレジリエンス、プロバイダーの集中、そしてますます重要になっているAIモデル層への統制です。共通しているのは、理念よりも実務に根ざしているという点です。
主権とは、組織が最も依存するデジタル能力に対して、実質的なコントロールを維持する力のことです。
だからといって、すべての国や企業があらゆるものを自前で構築しなければならないわけではありません。重要なのは、どの依存が許容でき、どの依存が危険なのか、そしてどのようなコントロールを社内に残すべきか、あるいは契約上強制可能でなければならないのかを把握することです。
主権は自給自足ではない
主権はしばしば、自給自足やデータ所在地と混同されます。しかし、そのどちらも問題の全体像を捉えてはいません。
企業は適切な法域にデータを保管していても、周辺のプラットフォームからの離脱が難しかったり、プロバイダーが依然として外国の法的要求に従う立場にあったり、重要な業務フローに組み込まれたAIシステムを顧客が監査したり影響を及ぼしたりできなかったりすれば、なおリスクにさらされる可能性があります。
AIはこの違いをさらに切迫したものにしています。モデルは単なる別のソフトウェア部品ではありません。組織がどのように文章を書き、検索し、分類し、顧客を支援し、情報を分析し、意思決定するかを左右しうる存在です。そうなると、依存はスタックの上位層へと移ります。もはや問題は、機械がどこで動くかだけではありません。仕事の中にある知性を、誰が形づくるのかということなのです。
多くの組織は、こうしたことを日常的な運用の場面で実感しています。あるプロバイダーが価格を変更し、成り立っていたユースケースが突然高くつくようになる。モデルの更新で出力が変わり、社内ワークフローの再調整が必要になる。法務やコンプライアンスのチームがデータの取り扱いについて率直な質問をしても、返ってくるのは曖昧な答えだ。調達部門は、柔軟だと思われていたアーキテクチャが、実際には置き換えに多大なコストと時間を要することに気づく。
地政学的な危機は必要ありません。ありふれた依存だけで十分です。
法的な言い回しは異なっても、世界的な議論
用語が異なる地域であっても、この問題は世界的なものです。
米国では、この懸念は digital sovereignty という表現よりも、連邦認可や国家安全保障上の統制という形で語られることが多いです。FedRAMP は、連邦政府機関が利用するクラウドサービスを評価し、認可し、継続的に監視するための標準化されたアプローチを提供しています。各機関は、ワークロードをクラウドに移した後もその責任を負い続け、防衛分野の環境ではさらに追加要件が課されます。
英国では、この問題は運用レジリエンスとシステム全体の依存という観点から捉えられる傾向があります。イングランド銀行、PRA、FCA は、外部プロバイダーで大規模な障害が発生すると、単一の企業だけでなく、より広い金融システム全体にリスクをもたらしうるとして、Critical Third Parties 制度を整備しました。
カナダの Protected B 情報向けクラウド管理プロファイルは、説明責任の原則を明確にしています。責任はクラウドプロバイダーに委任できても、引き渡したからといって説明責任がなくなるわけではありません。
インドでは、決済システムのデータに対するデータ・ローカライゼーション要件と、規制対象事業者が外部委託した IT やクラウドの取り決めについて引き続き責任を負うべきだという考え方が組み合わされています。シンガポールはクラウド導入を歓迎する一方で、それを適切に統治されるべきアウトソーシングとして扱っています。オーストラリア、ブラジル、南アフリカも同様に、この問題を運用レジリエンス、サービスプロバイダー・リスク、監督当局のアクセス、データガバナンス、戦略的インフラという観点から捉えています。
このパターンは明白です。主権は、ヨーロッパ特有のニッチな関心事ではありません。デジタルへの依存が戦略的な問題になったという事実に対する、広範な対応なのです。
なぜヨーロッパのアプローチが重要なのか
ヨーロッパは、この概念を調達と評価のフレームワークへと落とし込むことで、多くの法域よりも一歩先へ進めてきました。
欧州委員会の Cloud Sovereignty Framework は、主権クラウドのプロバイダーを8つの目的に沿って評価します。すなわち、戦略、法務・管轄、データと AI、運用、サプライチェーン、技術、セキュリティとコンプライアンス、そして環境面です。ここでは、相互補完的な2つの仕組みが用いられます。
- Sovereignty Effectiveness Assurance Level (SEAL): 各目的に対する最低保証水準。
- Overall sovereignty score: 必要な SEAL の閾値を満たした提案を重み付けして比較するための総合スコア。
この違いは重要です。全体の SEAL は、各目的のうち関連する項目で達成された最も低い水準によって決まります。したがって、ある重要領域に深刻な弱点が1つあるだけで、他の領域でどれほど強みがあっても、プロバイダー全体の水準は制限されうるのです。一方、スコアの役割は異なります。これは、すでに最低閾値をクリアした提案同士を見分けるためのものです。
レベルは閾値のロジックであり、スコアは比較のロジックである。
委員会のガイダンスでは、調達機関が調達案件ごとに必要な最低 SEAL を設定し、そのうえでスコアを使って適格な提案を比較できる余地が与えられています。2026年の主権クラウド調達では、プロバイダーに少なくとも SEAL-2 への到達が求められました。このフレームワークは主権に段階があることも認めており、SEAL-2 はデータ主権、SEAL-3 はデジタル・レジリエンス、SEAL-4 は完全なデジタル主権に対応づけられています。
最高レベルは、意図的に厳しいものとして設計されています。委員会は、現在のヨーロッパの状況では、サプライチェーン、とりわけハードウェアやチップへの依存が続いているため、完全な主権の実現はなお難しいと指摘しています。これは、二項対立的な考え方を正すうえで有益です。あるサービスは、考えうる最も強い主権の定義を満たしていなくても、組織の主権上の態勢を改善しうるのです。
だからこそ、このフレームワークは単なるチェックリスト以上のものなのです。調達、エンジニアリング、法務レビュー、制度上の説明責任という現実にさらされても、この概念が成り立つことを求めます。
これが規制業種を超えて重要である理由
銀行、通信事業者、防衛組織、医療システム、公的機関は、規制によって利害の大きさが可視化されるため、こうした圧力を先に感じる傾向があります。しかし、その根底にある脆弱性は、はるかに広く存在しています。
生産分析を単一のハイパースケーラーのリージョンに依存している製造業者、主要機能を一つのモデルプロバイダーを軸に構築してきたソフトウェア企業、外部のアイデンティティ基盤に依存する小売業者、あるいは研究や管理業務にサードパーティ製のAIツールを組み込んでいる大学は、いずれも同じ問題の異なる形に直面しています。
リスクの一部は地政学的なものです。輸出規制、制裁、国家安全保障上の介入、国境をまたぐ法的要求は、多くの組織が想定していた以上に、技術スタックの深い層にまで及び得ます。もう一つは構造的な問題です。少数の企業が、世界のクラウド、プラットフォーム、アイデンティティ、AIの能力の大きな割合を支えています。そうした企業の能力はしばしば非常に優れています。だからこそ、依存は深くなり得るのです。
AIはこの問題をいっそう先鋭化させます。なぜなら、外部サービスが内部能力へと変わるからです。モデルがサポート業務のワークフロー、文書作成、検索、コンプライアンス審査、あるいはプロダクト体験に織り込まれると、それは組織が考え、運営する方法の一部になります。その層を監査し、統治し、あるいは置き換えることが難しいなら、その依存はもはや単なる技術的なものではありません。経営上かつ戦略上の問題になります。
ソブリンティという視点が見せてくれるもの
ソブリンティは、完全な独立を求めるものではなく、判断の規律として捉えるのが最も適切です。
有益な問いは、組織がすべてをコントロールしているかどうかではありません。実際、それができる組織はほとんどありません。よりよい問いはこうです。どのソブリンティ目標が最も弱く、なぜそうなのか。
制約となっている要因は、所有権とガバナンスでしょうか。法的エクスポージャーでしょうか。データ管理でしょうか。運用上の依存でしょうか。サプライチェーンの脆弱性でしょうか。技術的ロックインでしょうか。それともAIレイヤーそのものでしょうか。
それが見えるようになれば、対応は具体的になります。より強い監査権と退出権が必要な組織もあります。特定のデータやワークロードについて、より厳格な管轄上の制限が必要な組織もあります。コストが増えるとしても、選択した機能についてはクラウドプロバイダーやモデルプロバイダーをまたいで移植可能な状態を保つ組織もあるでしょう。一方で、レジリエンス、説明責任、競争優位を左右するシステムについてはより強い統制を維持しつつ、重要度の低い領域では管理された依存を受け入れる組織もあります。
それがソブリンティという視点の価値です。これは、単一の政治的結論を示したり、劇的な技術的自立を求めたりするものではありません。組織に対して、最も弱い関連目標を特定し、なぜそれが弱いのかを理解し、そのエクスポージャーが許容可能かどうかを判断するための、規律ある方法を与えるのです。
この問いは今や、インフラ、データ、そしてますますAIにも当てはまります。
出典
- 欧州委員会: Sovereign Cloud Framework の解説 (2026)
- 欧州委員会: Cloud Sovereignty Framework — 実施ガイダンス (2026)
- 欧州委員会: 欧州委員会、戦略的調達を通じてクラウド主権を推進 (2026)
- APRA: CPG 230 オペレーショナル・リスク管理
- 米国一般調達局: クラウドセキュリティ
- イングランド銀行、PRA、FCA: 英国金融セクターにおける重要な第三者
- カナダ政府: クラウドベースの GC サービス向けセキュリティ管理プロファイル
- インド準備銀行: 決済システムデータの保存に関する FAQ
- インド準備銀行(商業銀行 — アウトソーシングにおけるリスク管理)指令、2025
- シンガポール金融管理局: クラウド
- ブラジル中央銀行: Resolução CMN nº 4.893
- 南アフリカ政府: データとクラウドに関する国家政策 (2024)

