プライバシーエンジニアリング技術標準化の欧米比較

プライバシーエンジニアリング技術
標準化の欧米比較
(2023年2月13日)
Cloud Security Alliance
Health Information Management WG

AGENDA
1. Cloud Security Alliance 「医療の相互運用性」
2. 米国のプライバシーエンジニアリング技術標準化に向けた取
組
3. 欧州のプライバシーエンジニアリング技術標準化に向けた取
組
4. Q&A／ディスカッション
2

AGENDA
1. Cloud Security Alliance 「医療の相互運用性」
1-1. 相互運用性とは？
1-2. 電子健康記録(EHR)のユースケース
1-3. 医療機器のユースケース
1-4. 米国の医療における相互運用性の現状
1-5. クラウドにおける医療の相互運用性
3

4
1. Cloud Security Alliance「医療の相互運用性」
(2022年9月26日発行)
(https://cloudsecurityalliance.org/artifacts/healthcare-interoperability/)
[構成]
・謝辞
・要約
・イントロダクション
・相互運用性
・相互運用性の現状
・クラウドにおける相互運用性
・今後の進め方
・結論
・参考文献
出典：CSA Health Information Management WG 「Healthcare Interoperability」（2022年9月26日）

5
1-1. 相互運用性とは？
• 相互運用性
• 情報を交換し、交換した情報を利用するための2つ以上のシステムま
たは
コンポーネントの能力
• 異なるタイプの情報通信技術（ICT）システムが、読み取り可能で使
えるフォーマットで、データを正確に、効率的に、一貫して交換する
能力
• 相互運用性のレベル
レベル内容
レベル1：基礎的システムまたはアプリケーションが、安全にデータを伝達し、他からのデータを受け
取るための
相互接続性を定義する
レベル2：構造的解釈のためのデータフィールドのレベルなど、データ交換のフォーマット、構文、組
織を定義する
レベル3：意味的公に入手可能な値設定やコーディングの語彙からの標準化された定義を持つデータ要
素の利用など、共通の基本的モデルやデータの成文化のために提供し、理解の共有や
ユーザーに対する
意味を提供する
レベル4：組織的組織や主体、個人の内部や相互間の、安全で、継ぎ目のない、タイムリーなデータ通

6
1-2. 電子健康記録(EHR)のユースケース
• 医療機関は、異なるEHRを利用する可能性がある他の医療機関に記録を送付する機能が必要である。
データの構造と完全性を維持しながら、この種の転送を遂行しなければならない。
• 外部ソースからのEHRコピーの要求と、オリジナルの詳細を保持するような標準的なフォーマットに
よる記録の返却。
• 標準的なフォーマットによるHIEへの情報提供により、医療機関が他の医療機関からの患者記録の閲
覧を可能にする。これには、患者の病歴を有する医療機関が含まれ、アウトカムの改善における重要
な要因となる。
出典：CSA Health
Information Management
WG 「Healthcare
Interoperability」
（2022年9月26日）
(https://cloudsecurityallian
ce.org/artifacts/healthcare
-interoperability/)
薬剤部
放射線科
臨床検査部
病院EHR
事務部EHR
病院医療機器
ウェアラブル医
療機器/IoMT
公的医療記録
患者ケアデータ分析
ポピュレー
ションヘルス
患者情報
医療プロバイ
ダー
医療提供組織
公衆衛生機関
患者

7
1-3. 医療機器のユースケース
• IHE(Integrating Healthcare Enterprise) 患者ケアデバイス(PCD)
医療機器由来ユースケース推奨機器要覧
1. 医療機器における
シームレスな変更
2. データと設定のキャプチャ
3. 確立された監視制御
4. 自律的な患者の治療法
5. ケアの継続性を通じた
データフロー
6. 機器構成のキャプチャ
7. ブラックボックスレコーダー

8
1-4. 米国の医療における相互運用性の現状
• 米国のイノベーション促進法制と相互運用性の経済インセンティブ
(https://cloudsecurityalliance.org/artifacts/healthcare-interoperability/)を基に作成
保健福祉省(HHS)国家医療IT調整室(OCN)
「2020-2025年連邦医療IT戦略計画」
(2020年10月30日)
「21世紀治療法」
(2016年12月13日)
「国家医療IT調整室（ONC）
21世紀治療法最終規則（ONC規則）」
(2020年3月9日)
「メディケア・メディケイド・サービス・セ
ンター(CMS)相互運用性および患者アクセス
最終規則
(CMS規則)」(2020年3月9日)
・標準規格としてHL7 FHIR 4.0.1版を採用
・APIの利用を支援
・患者アクセスAPI経由で請求・照合データ
の
患者による利用（PHR）を可能にする
＊APIエコノミー型ビジネスモデルの
導入

9
1-5. クラウドにおける医療の相互運用性(1)
• 相互運用性のあるシステムを構築するために必要な要素
• 共通のデータスキーム
• 病院が大量のリアルワールドデータを共通のデータスキームにもたらすメカニズム
• 共通のデータスキームに対する質問に答えるメカニズム

10
1-5. クラウドにおける医療の相互運用性(2)
• 相互運用性は、プライバシー／セキュリティの観点から、医療機関がク
ラウド
サービスに対するニーズを判断する際に重要である
• FHIRの標準化されたAPIで統合することによって、データをモバイル機器やWebポータルに素早
く転送する
ことができる
• FHIRは、APIにおけるデータ交換向け基盤としてRESTを利用するので、RESTFul HTTP APIコマ
ンドを介してリクエストすることができる
• FHIR APIを利用するサードパーティアプリケーションは、EHRに統合することによって、医療機
関のワーク
フローに直接送り込むことが可能となる
• FHIR向けAPIの特性により、EHRからの臨床データや、臨床医・患者ダッシュボード、遠隔モニ
タリング
プログラム、医療機関の外部にあるデータベースを統合・正規化し、機械学習を適用するツール
として利用することができる
• セキュリティインテリジェンス機能で保護対象保健情報(PHI)を保護することができる
• データは、APIインスタンス毎に、独自のデータベースに分離して保護される
• FHIR向けAPIは、階層型の多層防御と先進的なデータからの脅威保護機能を展開できる

AGENDA
2. 米国のプライバシーエンジニアリング技術標準化に向けた取
組
2-1. 米国NISTのプライバシーエンジニアリング標準化に向けた取組
2-2. 米国保健福祉省の非識別化方法の標準化に向けた取組
2-3. 米国大統領府のプライバシー強化技術の標準化に向けた取組
11

12
2-1. 米国NISTのプライバシーエンジニアリング標準化に向けた取組(1)
• 米国立標準技術研究所(NIST)「SP 800-122 個人識別情報の機密性を
保護するためのガイド」(2010年4月6日)
（https://csrc.nist.gov/publications/detail/sp/800-122/final）
• 個人識別情報（PII）
• (1) 名前、社会保障番号、生年月日・出生地、母親の旧姓、生体記録など、個
人の
アイデンティティを識別または追跡するために利用できるようなあらゆる情報
• (2) 医療、教育、金融、雇用情報など、個人に紐づけしたまたは紐づけ可能な
その他の情報を含む、機関が維持する固有に関するすべての情報
• PIIの機密性を保護する対策
対策内容
運用上の保護策 1. ポリシーと手順の構築
2. 認識、トレーニング、教育
プライバシー固有の
保護策
1. PIIの利用、収集、保持の最小化
2. プライバシー影響度評価の実行
3. 情報の非識別化
4. 情報の匿名化

13
• 米国NISTプライバシーエンジニアリングプログラム(PAP)「IR 8062 連
邦政府システムにおけるプライバシーエンジニアリングとリスクマネジ
メントの導入」
(2017年1月4日)（https://csrc.nist.gov/publications/detail/nistir/8062/final）
• プライバシーエンジニアリング
• 個人に個人識別情報(PII)を処理する際にシステムから生じる、受容できない結果をもたらす
問題を
起こし得る状況を免れることに焦点を当てた、システムエンジニアリングの専門分野を意味す
る
• 連邦政府システムにおけるプライバシーエンジニアリングの構成要素
構成要素内容
法律、規制、公正情報実務諸原則(FIPPs) -プライバシー要求事項
リスクモデル -リスク評価
プライバシーエンジニアリングとセキュリ
ティの目標
-システム機能／要求事項のマッピング
-システムが要求事項を満たし、リスクに取り組んでいるこ
との評価
リスクマネジメントフレームワーク -コントロールの選定など
プライバシー影響度評価 -特定されたリスク
-展開されたコントロール

14
• プライバシーエンジニアリングの目標
• 米国NIST「NISTプライバシーフレームワーク1.0版」(2020年1月16日)
（https://www.nist.gov/news-events/news/2020/01/nist-releases-version-10-privacy-framework）
目標内容
予測可能性（Predictability） -個人やオーナー、運用者による個人識別情報（PII）および情報
システムによる処理についての信頼できる想定を可能にする
管理性（Manageability） -PIIのきめの細かい管理（変更、削除、選択的解除など）のための機能
を提供する
非関連性（Disassociability） -システムの運用的要求事項を越えて個人やデバイスに関連付けることな
く、PIIまたはイベントの処理を可能にする
目標 NISTプライバシーフレームワークの管理項目
予測可能性（Predictability）特定（Identify-P）、統治（Govern-P）、制御（Control-P）、通知
（Communicate-P）、防御（Protect-P）
管理性（Manageability）特定（Identify-P）、統治（Govern-P）、制御（Control-P）
非関連性（Disassociability）特定（Identify-P）、統治（Govern-P）、制御（Control-P）

15
2-1. 米国NISTのプライバシーエンジニアリング標準化に向けた取組(４)
• 米国NIST「人工知能リスクマネジメントフレームワーク（AI-RMF）第
1.0版」
(2023年1月26日)（https://www.nist.gov/news-events/news/2023/01/nist-risk-management-framework-aims-
improve-trustworthiness-artificial）
• AIのリスクと信頼性の特徴
1. 妥当性があり信頼できる
2. 安全性がある
3. セキュアで強靭性がある
4. 説明責任と透明性がある
5. 説明可能であり翻訳可能である
6. プライバシーが強化されている
7. 公平性がある - 有害なバイアスが管理されている
• AI向けのプライバシー強化技術が、プライバシー強化型AIシステムの設計をサ
ポートできる
• 少量のデータのような特別な状況下では、プライバシー強化技術が正確性の低下

16
2-2. 米国保健福祉省の非識別化方法の標準化に向けた取組(1)
• 米保健福祉省(HHS)公民権室(OCR)「医療保険の携行性と責任に関する
法律(HIPAA)プライバシー規則に準拠した保護対象保健情報の非識別化
方法に関するガイダンス」(2020年6月8日)
（https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html）
• 非識別化された保護対象保健情報(PHI)
• 個人を識別しない保健情報で、その情報が個人を識別するために利用可能であ
ると
信じるに足る相当な基盤が無いもの
• 保護対象保健情報の非識別化方法
• 統計手法による「専門家による
決定(Expert Determination)」
方式
• 直接識別子を取り除く「セーフハーバー
(Safe Harbor)」方式
出典：HHS「Guidance Regarding Methods for De-identification of Protected
Health Information in Accordance with the Health Insurance Portability and
Accountability Act (HIPAA) Privacy Rule」（2020年6月8日）
（https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.htm）

17
2-2. 米国保健福祉省の非識別化方法の標準化に向けた取組(2)
• 非識別化方法の例
• 摂動(Perturbation)：
データセットをランダム化することによってセンシティブなデータを見えない
ようにする、
• マルチパーティ計算方式：
データを秘密裏に分散させた上で演算処理を行う暗号化手法
• 差分プライバシー(Differential Privacy)：
計算処理上の負荷とノイズのある結果を加えながらセキュアなことを証明する
• k-匿名化(k-anonymity)：
間接識別子(準識別子)がk個以上存在するようにすることで個人が特定される
リスクを低減する
• データセットにおける一意性と母集団における一意性との関係
出典：HHS「Guidance Regarding Methods for De-identification of
Protected Health Information in Accordance with the Health
Insurance Portability and Accountability Act (HIPAA) Privacy
Rule」（2020年6月8日）（https://www.hhs.gov/hipaa/for-
professionals/privacy/special-topics/de-identification/index.htm）

18
2-3. 米国大統領府のプライバシー強化技術の標準化に向けた取組(1)
• 米国大統領府科学技術政策局(OSTP)「プライバシー強化技術の進化に関
する情報提供依頼書(RFI)」(2022年6月9日)
（https://www.federalregister.gov/documents/2022/06/09/2022-12432/request-for-information-on-advancing-privacy-
enhancing-technologies）
• プライバシー強化技術(PETs)：
このRFIのスコープ内にある、プライバシーを保護する幅広い技術
• 非関連性や機密性を維持しながら、参加主体の間でのデータ共有・分析を可能
にする一連の技術やアプローチを説明したプライバシー保護データ共有・分析
に関心がある
• PETsの例
• 秘匿マルチパーティ計算(MPC)
• 準同型暗号
• ゼロ知識証明
• 連合学習
• セキュアエンクレーブ
• 差分プライバシー

19
• PFIを通じて求める情報
1. PETsを進化させるような特定の研究機会
2. PETsに関する特定の技術的観点または限界
3. 特にPETsの採用からの恩恵を受けるような分析に係る特定のセクター、適用
または
タイプ
4. PETsを進化させるために利用、修正または導入が可能な特定の規制または当
局
5. PETsを進化させるために利用、修正または導入が可能な特定の法律
6. 上記以外で、PETsを進化させるために利用、修正または導入が可能な特定の
メカニズム
7. PETsの採用に関連するリスク
8. PETsの採用に有益な既存のベストプラクティス
9. 上記以外で、PETsの採用に対する既存の障壁
10.PETsの採用に関連したその他の情報

20
• 米国政府・英国政府「米英両国が金融犯罪や公衆衛生上の緊急事態に取
組むためのプライバシー強化技術に関するイノベーション・プライズ・
チャレンジを開催」(2022年7月20日)
（https://www.whitehouse.gov/ostp/news-updates/2022/07/20/u-s-and-u-k-launch-innovation-prize-challenges-in-privacy-
enhancing-technologies-to-tackle-financial-crime-and-public-health-emergencies/）
• 米国側はOSTP、米国立科学財団(NSF)、NISTが省庁間イニシアティ
ブを主導し、英国側はデータ倫理イノベーション・センターが主導す
る
• テーマ：
• トラック1：金融犯罪防止の変革
• トラック2：パンデミック対応機能強化のための予測
• 11月10日、第１フェーズの入賞者12チームを発表
• 現在、入賞チームは、第２フェーズにおけるプロトタイプ開発に取組
んでいる

AGENDA
3. 欧州のプライバシーエンジニアリング技術標準化に向けた取
組
3-1. 欧州のプライバシーバイデザイン／デフォルトに向けた取組
3-2. 欧州のデータ保護エンジニアリングに向けた取組
3-3. 欧州のデータ共有エンジニアリングに向けた取組
21

22
3-1. 欧州のプライバシーバイデザイン／デフォルトに向けた取組
• 欧州連合(EU)「一般データ保護規則(GDPR)第25条」(2020年10月20
日)
（https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0
_en.pdf）
• 「データ保護バイデザイン」、「データ保護バイデフォルト」
1. 技術水準、実装費用、取扱いの性質、範囲、過程及び目的並びに取扱いによって引きこされる
自然人の権利及び自由に対する様々な蓋然性と深刻度のリスクを考慮に入れた上で、管理者は、
本規則の要件に
適合するものとし、かつ、データ主体の権利を保護するため、取扱いの方法を決定する時点及び
取扱いそれ自体の時点の両時点において、データの最小化のようなデータ保護の基本原則を効果
的な態様で実装し、その取扱いの中に必要な保護措置を統合するために設計された、仮名化のよ
うな、適切な技術的措置及び組織的措置を実装する。
2. 管理者は、その取扱いの個々の特定の目的のために必要な個人データのみが取扱われることを
デフォルトで確保するための適切な技術的措置及び組織的措置を実装する。この義務は、収集さ
れる個人データの
分量、その取扱いの範囲、その記録保存期間及びアクセス可能性に適用される。とりわけ、その
ような措置は、個人データが、その個人の関与なく、不特定の自然人からアクセス可能なものと
されないことをデフォルトで
確保する。
3. 第42条により承認された認証方法は、本条の第1 項及び第2 項に定める要件の充足を証明す
るための要素として用いることができる

23
3-2. 欧州のデータ保護エンジニアリングに向けた取組(1)
• 欧州連合サイバーセキュリティ庁（ENISA)「データ保護エンジニアリン
グ
- 理論から実践へ」(2022年1月27日)
（https://www.enisa.europa.eu/publications/data-protection-engineering）
• [構成](1)
1. イントロダクション
1.1 データ保護バイデザイン
1.2 スコープと目的
1.3 文書の構成
2. データ保護エンジニアリング
2.1 データ保護バイデザインからデー
タ保護
エンジニアリングへ
2.2 DPIAとの関係
2.3 プライバシー強化技術
3. 匿名化と仮名化
3.1 匿名化
3.2 k-匿名化
3.3 差分プライバシー
4. データマスキングとプライバシー保護計算
4.1 準同型暗号
4.2 秘匿マルチパーティ計算
4.3 信頼できる実行環境
4.4 プライベート情報検索
4.5 合成データ
5. アクセス、通信とストレージ
5.1 通信チャネル
5.2 プライバシー保護ストレージ
5.3 プライバシー強化型アクセス制御、認証、
認可

24
• [構成](2)
6. 透明性、明瞭性とユーザー制御ツール
6.1 プライバシーポリシー
6.2 プライバシーアイコン
6.3 粘り強いポリシー
6.4 プライバシープレファレンスシグ
ナル
6.5 プライバシーダッシュボード
6.6 コンセント管理
6.7 コンセント収集
6.8 コンセント管理システム
6.9 アクセスの権利の行使
6.10 消去の権利、訂正の権利の行使
7. 結論
7.1最も適用可能な技術の明確化
7.2 最先端の設定
7.3 法令遵守の明示と保証の提供
8. 参考文献

25
• データ保護エンジニアリングとプライバシー強化技術(PETs)
・データ保護エンジニアリング：
データ保護バイデザイン／バイデフォルトの一部として捉えられる。それは、特
別なデータ
保護原則を満たすために適切な技術的・組織的対策の選定、展開、構成をサポー
トする
ことを目的としており、最終的にはデータ主体の権利や自由の保護に寄与するも
のである。データ保護影響度評価（DPIA）は、GDPRに基づいて導入された要
求事項の1つで
あり、データ保護バイデザイン／バイデフォルトアプローチの一部として捉えら
れる。
・プライバシー強化技術（PETs）：
情報システムの機能性を失うことなく、個人データを消去または低減したり、個
人データの
不必要および／または望まれない処理を防止したりすることによって、プライバ
シーを保護
するようなICT対策の首尾一貫したシステムである。PETsは、データ保護原則お
よびGDPR第25条の責務の充足に向けたビルディングブロックとして、またデー

26
• プライバシー強化技術(PETs)からみたカテゴリー：
カテゴリー内容
真実保護
（Truth-
preserving）
プライバシーエンジニアリングの目標は、識別力を低減しながらデータの正
確性を保持することにある。この目標は、たとえば、データのきめの細かさ
(例．生年月日から年齢まで)を薄めることによって達成できる。このように
して、データは依然として正確だが、
最小化された方法であり、危機に瀕した時の目的には適切だ。暗号化は、逆
方向に
適用された場合、プロセスに不確実性をもたらすことなく、オリジナルデー
タを完全に保存するので、真実保護技術と見なされる場合がある。
明瞭性保護
（Intelligibility-
preserving）
本当のデータ主体の属性を公開することなく、管理者にとって意味のある
フォーマットでデータが維持される。たとえば、入院日へのオフセットの導
入は、年月日のフォーマットを維持するが、識別された患者の本当のデータ
とのリンクを破る。また、ノイズの付加は、データの外観や操作感を変える
ことなく、本当のデータに機密性の保護策を提供するので、明瞭性保護技術
となる。
操作可能技術数学的・論理学的操作(例．総和、比較)は、アプリケーションの結果に実行

27
• プライバシー保護ストレージの目的：
• 保存した個人データの機密性を保護する
• 侵害が発生した場合、データ管理者(Controller)に情報を告知する
• プライバシー保護ストレージ適用のレベル：
i. ストレージレベルの暗号化
ii. データベースレベルの暗号化
iii. アプリケーションレベルの暗号化
出典：European Union
Agency for Cybersecurity
(ENISA)「Data Protection
Engineering」
(2022年1月27日)
（https://www.enisa.eur
opa.eu/publications/data
-protection-engineering）

28
3-3. 欧州のデータ共有エンジニアリングに向けた取組(1)
• 欧州連合サイバーセキュリティ庁（ENISA)「個人データ共有エンジニア
リング」(2023年1月27日)
（https://www.enisa.europa.eu/news/protecting-data-can-we-engineer-data-sharing）
• [構成](1)
1. イントロダクション
1.1 関連EU立法イニシアティブ
1.2 データ保護エンジニアリングの役割
1.3 スコープと目的
1.4 文書の構成
2. 保健医療セクターにおけるデータ共有プラ
クティス
2.1 ユーザー制御型個人データ共有
2.1.1 属性ベース暗号化
2.2.2 プロキシ再暗号化
2.2 医療機関による医療・研究目的の保健
医療データ共有
2.2.1 ポリモーフィック暗号と仮名化
3. サードパーティサービスを利用したデータ共有
3.1 モバイルプッシュ通知
3.1.1 匿名通知プロトコル(プロキシ利用)
3.1.2 エンドツーエンド暗号化
3.1.3 設計戦略
3.2 認証中のデータ共有
3.2.1 オンラインプラットフォームへの属
性
ベースアクセスの関連性

29
• [構成](2)
4. データ主体の権利行使に関する考慮事項
4.1 データ主体とデータ仲介者の相互作用
4.1.1 目的の制限
4.1.2 実装面
4.2 データ仲介者とデータ有効活用者の相互
作用
4.2.1 データのリクエストとデータのレス
ポンス
4.3 データ仲介者のデータ管理
4.3.1 コンセントの範囲と目的の制限
4.3.2 仲介者内の相互作用
4.3.3 ロギングとレポーティング
4.3.4 プライバシー保護データ選定
4.4 データ利他主義
5. 結論
参考文献

30
• 保健医療セクターにおけるデータ共有プラクティス
• 非対称暗号化を介したユーザー制御型データ共有のケース
• 同一データが複数の主体間で共有される場合、ユーザーは、関連す
る主体の公開鍵で暗号化して、同じデータを何度も共有する必要が
ある
出典：European Union Agency for Cybersecurity (ENISA)「Engineering Personal Data Sharing」
(2023年1月27日)（https://www.enisa.europa.eu/news/protecting-data-can-we-engineer-data-sharing）

31
• 属性ベース暗号化(ABE)のケース
• 医師が一度ABE復号鍵を受け取れば、ユーザーが定義したアクセス
ポリシーを満たしたデータをローカルで復号できる
*ユーザーが、データに関する意思決定を行える状態にあることは
不可避
*クラウドプロバイダーは、通信に関連するメタデータを収集する

32
• プロキシ再暗号化(PRE)のケース
• PREにより、ユーザー制御型データ共有モデルにおいて暗号化を強
制する
アクセス制御を実現する
＊クラウドプロバイダーは、通信に関連するメタデータを収集する

33
• ポリモーフィック暗号と仮名化(PEP)のケース
• 患者の識別子は、トランスクリプターが、データ共有の受け手とコ
ンテキストまたは目的によって、異なる仮名に転送される。個々の
仮名は、ポリモーフィック暗号化されたデータとともに、各受け手
に伝達される。
出典：European Union Agency for
Cybersecurity (ENISA)「Engineering
Personal Data Sharing」
(2023年1月27日)
（https://www.enisa.europa.eu/new
s/protecting-data-can-we-engineer-
data-sharing）

34
プライバシーエンジニアリング技術標準化の欧米比較
ヘルスデータ利活用とコンセント管理：
オプトイン Vs. オプトアウト Vs. ルールなし
出典：European Commission
「Assessment of the EU Member
States’ rules on health data in the
light of GDPR」
（2021年2月12日）
(https://health.ec.europa.eu/syst
em/files/2021-
02/ms_rules_health-
data_en_0.pdf)
出典：Clinovations Government + Health「State HIE Consent Policies: Opt-In or Opt-Out」
（2016年9月更新） (https://www.healthit.gov/sites/default/files/State%20HIE%20Opt-
In%20vs%20Opt-Out%20Policy%20Research_09-30-16_Final.pdf)

35
• 4. Q&A／ディスカッショ
ン

プライバシーエンジニアリング技術標準化の欧米比較

Recommended

Recommended

More Related Content

Similar to プライバシーエンジニアリング技術標準化の欧米比較

Similar to プライバシーエンジニアリング技術標準化の欧米比較 (20)

More from Eiji Sasahara, Ph.D., MBA 笹原英司

More from Eiji Sasahara, Ph.D., MBA 笹原英司 (20)

プライバシーエンジニアリング技術標準化の欧米比較