💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ - 「データを動かさず、モデルを動かす」

2017年4月、Google AI ブログに一本の記事が公開されました。タイトルは「Federated Learning: Collaborative Machine Learning without Centralized Training Data」。Brendan McMahan らは、Gboard(Android キーボード)でユーザーの入力データをサーバーに送らずに、各端末で学習したモデルの更新だけを集約・平均することで、次単語予測モデルを改善したと発表しました。FedAvg(Federated Averaging)アルゴリズムが世に出た瞬間でした。

2024年6月、Apple WWDC で Craig Federighi はさらに衝撃的な舞台を見せました。Private Cloud Compute(PCC) - ユーザーのリクエストが Apple のクラウドサーバーに届く際、サーバーは絶対にそのリクエストの内容を見ることができないように、ハードウェアとソフトウェアを再設計した基盤です。Secure Enclave、Apple Silicon、検証可能なビルド、ユーザーの端末側で検証する certificate transparency まで。「データはサーバーに送るが、サーバーには見せない」という矛盾命題が、実際の製品として出荷されました。

この7年間で、プライバシー保護機械学習(Privacy-Preserving Machine Learning, PPML)は学術的好奇心からビッグテックの基幹インフラへと成長しました。2026年5月時点で、PPML は **5つの技術スタック**の組み合わせで構成されます。

1. **Federated Learning(FL)** - データを動かさず、モデル重みだけを集約

2. **Differential Privacy(DP)** - 「1人が抜けても結果がほぼ同じ」という数学的保証

3. **Homomorphic Encryption(HE)** - 暗号化された状態で演算を実行

4. **Secure Multi-Party Computation(MPC)** - 複数当事者が自身の入力を公開せずに関数を計算

5. **Trusted Execution Environment(TEE)** - ハードウェア分離領域でコードを実行

本記事では、2026年5月時点での各領域の代表的なフレームワーク、実際の運用事例、規制環境を順に見ていきます。

1. PPML が登場した理由 - 4つの圧力

1.1 GDPR(2018)から EU AI Act(2024)まで

2018年5月25日に施行された EU GDPR(General Data Protection Regulation)は、PPML 時代の号砲でした。個人データ処理の6つの合法根拠(同意、契約、法的義務、生命、公共、正当な利益)、忘れられる権利、データ最小化原則。違反時は売上高の4%または2,000万ユーロのいずれか大きい方。

続いて2023-2024年に EU AI Act が成立し、高リスク AI システム(医療、採用、信用評価、法執行)にはデータガバナンス、透明性、人間による監督、頑健性の要件が追加されました。2026年8月から汎用 AI(GPAI)義務が段階的に適用されます。

米国 HIPAA(1996)、韓国 PIPA(個人情報保護法)、日本 APPI(個人情報保護法)、中国 PIPL、カリフォルニア CCPA/CPRA。各国規制が同時に強化され、「全てのデータを一箇所に集めて学習する」という伝統的 ML ワークフローが危うくなりました。

1.2 データサイロと協調学習の渇望

ある病院1施設の MRI 画像だけでは、希少腫瘍検出モデルを学習するには少なすぎます。しかし患者画像を他施設に共有することは、法的にも倫理的にも難しい。銀行も同様 - 不正検知モデルは複数銀行のデータが合わさるほど強力になりますが、取引データは絶対に共有できません。

この「共有したいが共有できない」というデータサイロ問題が、PPML、特に Federated Learning の最大の実用ドライバーです。

1.3 推論時の入力プライバシー

LLM 時代に新たに浮上した問題。ユーザーが ChatGPT に自分のコード、医療記録、財務情報を入力します。OpenAI のサーバーはその入力を平文で見ます。これを防げるか?

- **TEE ベース** - Apple PCC、AWS Nitro Enclaves、Confidential VM

- **FHE ベース** - Zama Concrete-ML で暗号化された入力に対して推論

- **MPC ベース** - CrypTen、EzPC で分散推論

1.4 モデル自体のプライバシー - メンバーシップ推論攻撃

Carlini et al.(2021)は GPT-2 が学習データの一部(メールアドレス、電話番号、医療記録)をそのまま出力できることを示しました。学習済みモデルは「記憶」します。これを防ぐ数学的ツールが Differential Privacy(DP)です。

2. Federated Learning の概念 - FedAvg から FedProx まで

2.1 FedAvg アルゴリズム(McMahan et al., 2017)

FedAvg はシンプルです。各ラウンドで:

1. サーバーがグローバル重み w_t をクライアントに配布

2. クライアント k が自身のデータ D_k で E エポック学習し、w_t^k を生成

3. サーバーが加重平均: w_(t+1) = sum(n_k / n) * w_t^k

4. 次のラウンドへ

+----------+ +----------+ +----------+

| D_1 | | D_2 | | D_3 |

+----+-----+ +----+-----+ +----+-----+

| w_t^1 | w_t^2 | w_t^3

+--------------------+-----+--------------------+----+

+-------+-------+

| Server |

| w_(t+1) = |

| weighted avg |

+---------------+

(全クライアントに配布)

2.2 Cross-Device vs Cross-Silo

**Cross-Device FL** - 数百万台のモバイル端末、毎回一部のみ参加、接続不安定。代表例: Google Gboard、Apple Siri。

**Cross-Silo FL** - 数十の機関(病院、銀行)。安定したインフラ、ほぼ常時参加、ノードあたりのデータが大きい。代表例: NVIDIA FLARE ベースの BraTS、MELLODDY(製薬コンソーシアム)。

| 観点 | Cross-Device | Cross-Silo |

|------|--------------|------------|

| クライアント数 | 1万 - 1億台 | 2 - 100機関 |

| クライアント可用性 | 間欠的、不信頼 | ほぼ常時利用可能 |

| ノードあたりのデータ | 非常に小さい | 非常に大きい |

| 通信コスト | 非常に高い(セルラー) | 比較的安価(専用線) |

| 脅威モデル | honest-but-curious が多数 | 信頼できる機関 |

| 代表フレームワーク | TensorFlow Federated、Flower | NVIDIA FLARE、Flower、OpenFL |

2.3 Non-IID データの挑戦

連合学習最大の難点は **各クライアントのデータ分布が異なる(Non-IID)** ことです。ある病院は小児患者が多く、別の病院は高齢患者が多い。素の FedAvg はこのような環境で発散したり精度が大きく落ちたりします。

これを解決する変種アルゴリズム:

- **FedProx**(Li et al., 2018) - ローカル更新に近接項を追加

- **SCAFFOLD**(Karimireddy et al., 2020) - クライアント別分散補正

- **FedNova**(Wang et al., 2020) - ローカルステップ数の正規化

- **FedAdam / FedAdagrad / FedYogi**(Reddi et al., 2021) - サーバー側適応的オプティマイザ

2.4 セキュア集約(Secure Aggregation)

FedAvg の弱点 - サーバーが各クライアントの w_t^k を見ます。モデル重みから学習データを逆推論する攻撃(model inversion、gradient leakage)が可能です。これを防ぐのが **Secure Aggregation**(Bonawitz et al., 2017)です。

核となる考え方 - 各クライアントが自身の重みに秘密ノイズを加え、全クライアントのノイズを合計するとゼロになるようにペアワイズマスクを共有。サーバーは合計しか見ることができず、個々の貢献は見えません。

3. Flower 1.13 - 最も人気のあるオープンソース FL フレームワーク

3.1 Flower の台頭

Flower(flower.ai)は2020年に Daniel J. Beutel と Taner Topal が始めたオープンソース FL フレームワークです。2022年に Flower Labs Inc. として法人化し、2024-2025年にシリーズ A 資金調達を行いました。2026年5月時点で GitHub スター数は約5,500、最も活発な FL フレームワークの一つです。

Flower の哲学は **フレームワーク中立(framework-agnostic)**。PyTorch、TensorFlow、JAX、Scikit-learn、Hugging Face Transformers など、どの ML ライブラリでもクライアントとしてラップできます。

3.2 Flower 1.13 のコア構造

Flower 1.13(2025年末リリース)は3つのコンポーネントで構成されます。

- **ServerApp** - グローバル学習ロジック(どのクライアントを選ぶか、どの集約アルゴリズムを使うか)

- **ClientApp** - クライアント側の学習/評価ロジック

- **SuperLink + SuperNode** - サーバーとクライアント間の通信バックボーン

Flower 1.13 ClientApp の例

from flwr.client import ClientApp, NumPyClient

from flwr.common import Context

class FlowerClient(NumPyClient):

def __init__(self, net, trainloader, valloader):

self.net = net

self.trainloader = trainloader

self.valloader = valloader

def get_parameters(self, config):

return [val.cpu().numpy() for _, val in self.net.state_dict().items()]

def set_parameters(self, parameters):

params_dict = zip(self.net.state_dict().keys(), parameters)

state_dict = {k: torch.tensor(v) for k, v in params_dict}

self.net.load_state_dict(state_dict, strict=True)

def fit(self, parameters, config):

self.set_parameters(parameters)

train(self.net, self.trainloader, epochs=1)

return self.get_parameters(config={}), len(self.trainloader.dataset), {}

def evaluate(self, parameters, config):

self.set_parameters(parameters)

loss, acc = test(self.net, self.valloader)

return float(loss), len(self.valloader.dataset), {"accuracy": float(acc)}

def client_fn(context: Context):

partition_id = context.node_config["partition-id"]

net = Net()

trainloader, valloader = load_data(partition_id)

return FlowerClient(net, trainloader, valloader).to_client()

app = ClientApp(client_fn=client_fn)

3.3 シミュレーションエンジン

Flower の強力な機能が **シミュレーションモード** です。実際の分散環境なしで、単一マシン上で数千の仮想クライアントをシミュレートできます。Ray をバックエンドに使い、GPU リソースを効率的に分配します。

from flwr.simulation import run_simulation

run_simulation(

server_app=server_app,

client_app=client_app,

num_supernodes=100, # 100個の仮想クライアント

backend_config={"client_resources": {"num_cpus": 2, "num_gpus": 0.1}}

)

この機能のおかげで、研究者はアルゴリズム変更の効果を素早く検証でき、Flower が学術界で愛される理由となっています。

3.4 Flower の戦略(Strategy)

Flower は30以上の集約戦略を組み込みで提供します。

- FedAvg、FedAdagrad、FedYogi、FedAdam、FedProx

- FedAvgM(Momentum)、FedTrimmedAvg、FedMedian

- Krum、Bulyan(ビザンチン耐性)

- FedXgbBagging、FedXgbCyclic(XGBoost 専用)

- DifferentialPrivacyClientSideAdaptiveClipping(DP 統合)

4. NVIDIA FLARE - エンタープライズ FL の標準

4.1 FLARE の位置付け

NVIDIA FLARE(Federated Learning Application Runtime Environment)は、2021年に NVIDIA が医療 AI 子会社 Clara と共に発表した FL フレームワークです。2026年5月時点で 2.5.x シリーズが安定版で、Apache 2.0 ライセンスで提供されます。

FLARE のターゲットは明確 - **エンタープライズ、特にヘルスケアと金融の Cross-Silo FL**。Flower が「柔軟性とシミュレーション」に強いとすれば、FLARE は「運用安定性、セキュリティ、監査証跡」に強い。

4.2 Hub & Spoke アーキテクチャ

FLARE は中央サーバー(FL Server)と複数のクライアント(FL Client)間のハブ&スポーク通信モデルを使います。全通信は mTLS で暗号化され、各サイトは PKI ベース証明書で身元を証明します。

+---------------+

| FL Server |

| (Hub) |

| Aggregator |

+-------+-------+

+---------------+---------------+

| | |

+---+---+ +---+---+ +---+---+

+-------+ +-------+ +-------+

4.3 BraTS 医療コンソーシアム

FLARE の代表的成功事例が **BraTS(Brain Tumor Segmentation Challenge)Federated** です。71の医療機関(米国、欧州、アジア)が参加して脳腫瘍分割モデルを連合学習しました(Pati et al., Nature Communications, 2022)。単一機関のモデルより平均6%精度が向上し、患者データは一つも機関の外に出ませんでした。

この事例は FL が「理論から臨床現場へ」越境した決定的瞬間でした。

4.4 FLARE の主要機能

- **Job Submission** - 学習ジョブをパッケージ化してサーバーに提出、管理者承認後に実行

- **Provisioning** - サイト別の証明書、設定、セキュリティポリシーを自動生成

- **Privacy Filters** - 重み送信前に DP ノイズ、勾配クリッピング等を自動適用

- **POC(Proof of Concept)モード** - ローカルで素早くマルチサイトシミュレーション

- **NVFlare Dashboard** - 学習進捗、メトリクス、セキュリティイベントの可視化

FLARE Controller(サーバー側)の例

from nvflare.app_common.workflows.fedavg import FedAvg

from nvflare.job_config.fed_job import FedJob

job = FedJob(name="brats_seg")

controller = FedAvg(num_clients=10, num_rounds=20)

job.to_server(controller)

job.to_clients(executor=BraTSExecutor())

job.export("./jobs/brats_seg")

5. TensorFlow Federated(TFF) - Google のシミュレーション優先アプローチ

5.1 TFF のアイデンティティ

TensorFlow Federated(TFF)は、Google が2019年にオープンソース化した FL ライブラリです。ただし Flower や FLARE とは趣が異なります - TFF は **連合アルゴリズムの数学的定義を表現する言語** に近い。実際の分散デプロイより、アルゴリズムシミュレーションと研究が主な用途です。

5.2 2つのレイヤー

- **Federated Core(FC)** - federated_computation、federated_map、federated_aggregate 等の低レベル演算子

- **Federated Learning(FL)API** - FedAvg、FedSGD 等の高レベル API

@tff.federated_computation

def get_average_temperature(client_temperatures):

return tff.federated_mean(client_temperatures)

この宣言的表現のおかげで、TFF はアルゴリズムの通信コスト、収束性、DP 保証を数学的に分析しやすい構造になっています。

5.3 限界と位置

TFF はシミュレーションに強いが、実際のモバイル端末へのデプロイは困難です。Google 社内では別の本番システム(Federated Compute、Federated Compute Platform)が Gboard 等の実サービスを支えています。2026年時点で TFF は主に学術研究用途で、産業界の採用は Flower / FLARE に押されています。

6. PySyft 0.9 と OpenMined - 構造化された透明性

6.1 OpenMined のビジョン

OpenMined は Andrew Trask が2017年に始めた非営利オープンソースコミュニティです。スローガンは **「Answer questions using data you cannot see」** - 見ることのできないデータで質問に答える。この一文に PPML の本質が凝縮されています。

OpenMined の代表プロジェクトは **PySyft** です。PySyft は単なる FL ライブラリではなく、「構造化された透明性(Structured Transparency)」フレームワークです。

6.2 構造化された透明性

伝統的なデータ分析 - 分析者がデータの複製を受け取り、自分のサーバーで分析。データ所有者は分析者が何をしたか制御できません。

PySyft のモデル - データはデータ所有者(Data Owner)の **Domain Server** に残り、分析者(Data Scientist)は「この関数をデータに適用してもよいですか?」というリクエストを送ります。データ所有者は関数をレビューし、結果のみを返します(必要に応じて DP ノイズを追加)。

+----------------+ +------------------+

| Data Scientist | | Data Owner |

| (Jane) | 1. コード + データ | (Hospital) |

| | 参照を提出 | |

| | --------------------> | Domain Server |

| | | (data here) |

| | 2. レビュー/実行/ | |

| | 結果返却 | |

| | <-------------------- | |

+----------------+ +------------------+

6.3 PySyft 0.9 のコア概念

- **Domain** - データ所有者が運用するサーバー。データ、ポリシー、結果アーカイブ

- **Code Request** - データサイエンティストが提出した関数。所有者が承認すると実行

- **Privacy Budget** - 各ユーザーに割り当てられた DP イプシロン上限

- **Mock Data** - 実データと同じスキーマの合成データ。分析者は実データを見ずにコードを書ける

データ所有者側

domain = sy.orchestra.launch(name="hospital", port=8081)

client = domain.login(email="admin@hospital.org", password="...")

実データをドメインにアップロード、mock データは自動生成

asset = sy.Asset(name="patient_mri", data=real_data, mock=mock_data)

dataset = sy.Dataset(name="MRI Study 2026", asset_list=[asset])

client.upload_dataset(dataset)

データサイエンティスト側

ds_client = sy.login(url="https://hospital.openmined.org", email="researcher@univ.edu", password="...")

mri_mock = ds_client.datasets[0].assets[0].mock

@sy.syft_function_single_use(mri=mri_mock)

def compute_tumor_volume(mri):

return mri.mean() # 実際にはもっと複雑な ML モデル

ds_client.code.request_code_execution(compute_tumor_volume)

データ所有者が承認すると実データで実行され、結果のみ返却

6.4 OpenMined エコシステム

PySyft 以外にも OpenMined は様々なツールを作っています。

- **PyDP** - Google DP Library の Python バインディング

- **PSI(Private Set Intersection)** - 2当事者のデータ積集合を露出なしで計算

- **TenSEAL** - Microsoft SEAL の Python バインディング、FHE テンソル演算

- **HAGrid** - PySyft Domain クラスタのデプロイツール

7. Differential Privacy 基礎 - イプシロンとデルタ

7.1 DP の数学的定義

ランダム化アルゴリズム M が (eps, delta)-DP を満たすとは - 1人のデータが異なる2つのデータセット D と D' に対して、全ての出力集合 S について以下が成り立つこと:

`P[M(D) in S] <= exp(eps) * P[M(D') in S] + delta`

直感的には - eps が小さいほど「1人のデータが結果にほとんど影響しない」。delta はその保証が壊れる確率。

典型的な値 - eps は 0.1 から 10 の間、delta は 1/n^1.5 程度(n はデータセットサイズ)。

7.2 Laplace メカニズムと Gaussian メカニズム

最もシンプルな DP メカニズム - 答えにノイズを加える。

True query: f(D) = 平均身長 (cm)

DP answer: f(D) + Lap(sensitivity / eps)

f(D) + N(0, sigma^2)

sensitivity は1人のデータが抜けたり追加されたりするときに関数値が変わりうる最大値。ノイズ量は sensitivity / eps に比例します。

7.3 Composition

複数の DP クエリを同じデータセットに実行すると、プライバシー損失が累積します。Basic composition - eps の単純和。Advanced composition - sqrt(k * log(1/delta)) * eps 程度。Renyi DP、zCDP のような高度な会計手法はより正確な累積値を与えます。

7.4 Apple の DP 導入(2017)

Apple は iOS 10(2016)からキーボード使用統計、絵文字頻度、Safari クラッシュレポート等に Local DP を適用しました。Local DP はユーザー端末でデータにノイズを加えてサーバーに送る方式。eps 値が一般的に 4-8 程度と比較的大きいが、データ自体がサーバーに平文で到達しないという保証があります。

これは DP が学術概念からビッグテックの運用ツールへ越境した最初の事例の一つでした。

7.5 米国 Census 2020

米国国勢調査局は2020年の人口調査結果発表に (eps=19.61) Central DP を適用しました。1世帯が異なる場合に統計結果がほぼ同じであることの保証。学術界で激しい議論がありました(統計精度とプライバシーのトレードオフ)が、DP が政府統計の標準として位置付けられる契機になりました。

8. Opacus 1.5 - Meta の PyTorch DP ライブラリ

8.1 DP-SGD アルゴリズム

DP を ML 学習に適用する標準的方法が **DP-SGD(Differentially Private Stochastic Gradient Descent)**(Abadi et al., 2016)です。核心的な違いは per-sample gradient clipping とノイズ追加。

For each minibatch:

for each sample x_i in batch:

g_i = compute gradient of L(theta, x_i)

g_i = g_i * min(1, C / ||g_i||) # per-sample clipping

g_bar = (sum g_i + N(0, sigma^2 * C^2 * I)) / batch_size

theta = theta - lr * g_bar

こうすることで、1サンプルが抜けたときの最終モデルへの影響が sigma ノイズで隠されます。

8.2 Opacus の登場

Opacus は Meta(旧 Facebook)AI Research が2020年に公開した PyTorch DP ライブラリです。PyTorch 標準オプティマイザを1行のコードで DP-SGD に変えることが核心的価値でした。

from opacus import PrivacyEngine

model = MyModel()

optimizer = torch.optim.SGD(model.parameters(), lr=0.05)

data_loader = torch.utils.data.DataLoader(...)

privacy_engine = PrivacyEngine()

model, optimizer, data_loader = privacy_engine.make_private_with_epsilon(

module=model,

optimizer=optimizer,

data_loader=data_loader,

target_epsilon=2.0,

target_delta=1e-5,

epochs=20,

max_grad_norm=1.0,

)

以降は通常通り学習

for epoch in range(20):

for x, y in data_loader:

optimizer.zero_grad()

loss = criterion(model(x), y)

loss.backward()

optimizer.step()

print(f"Final eps: {privacy_engine.get_epsilon(delta=1e-5)}")

8.3 Opacus 1.5(2025-2026)の改善

- **Per-sample gradient の GPU 効率化** - GhostClip、Functorch 活用

- **LLM ファインチューニング対応** - LoRA ベース DP fine-tuning

- **Distributed DP-SGD** - マルチ GPU/ノードでの正確なプライバシー会計

- **RDP/zCDP 会計者** - より正確な eps 計算

8.4 DP-SGD の精度コスト

DP-SGD は無料ではありません。eps=1-3 程度の強いプライバシー保証を実現するには、通常 1-5 パーセントポイントの精度低下があります。より多くのデータ、より大きなバッチ、より長い学習がこのコストを減らす主な処方箋です。

9. OpenDP 0.10 - Harvard の Rust ベース DP コア

9.1 OpenDP の差別化点

OpenDP は Harvard 大学と Microsoft が共同で開始したプロジェクトで、**数学的に検証された DP メカニズムライブラリ** を目標としています。Opacus が「ML 学習への DP 適用」に焦点を絞っているとすれば、OpenDP は「統計クエリ、分析、データリリースへの DP 適用」が主力です。

OpenDP の核心は **Rust で書かれたコアメカニズムに Python/R バインディング** を提供する構造。メモリ安全性と数学的正確性を同時に捉えようとする試みです。

9.2 OpenDP のビルダーパターン

dp.enable_features("contrib")

eps=1.0 の保証下で平均計算

input_domain = dp.vector_domain(dp.atom_domain(T=float, bounds=(0.0, 200.0)))

input_metric = dp.symmetric_distance()

trans_mean = (

input_domain >> input_metric >>

dp.t.then_clamp((0.0, 200.0)) >>

dp.t.then_sum() >>

dp.t.then_division_with_size(n=1000)

)

meas = trans_mean >> dp.m.then_laplace(scale=0.2)

heights = [165.0, 170.5] # ユーザー身長リスト

private_mean = meas(heights)

print(f"DP mean height: {private_mean}, eps spent: {meas.map(d_in=1)}")

OpenDP のオブジェクトは **Transformation** と **Measurement** に分かれ、各オブジェクトは自分自身のプライバシー/安定性 boundary を数学的に証明します。

9.3 PSI 統合と SmartNoise

OpenDP は Microsoft の SmartNoise SDK のバックエンドとしても使われます。SmartNoise は SQL クエリに自動で DP を適用するツール。WHERE/GROUP BY/JOIN クエリを解析して sensitivity を自動計算し、ノイズを追加します。

10. Google DP Library と JAX-Privacy

10.1 Google DP Library

Google は2019年に自社の C++ Differential Privacy Library をオープンソース化しました。主要アルゴリズムは Laplace/Gaussian メカニズム、BoundedSum、BoundedMean、Count、Quantile 等。Go、Java、C++、Python バインディングがあり、PipelineDP という Apache Beam ベース分散 DP 処理器もあります。

Apache Beam パイプラインで DP 統計を算出

dp_engine = pipeline_dp.DPEngine(

pipeline_dp.NaiveBudgetAccountant(total_epsilon=1.0, total_delta=1e-7),

pipeline_dp.BeamBackend(),

)

params = pipeline_dp.AggregateParams(

metrics=[pipeline_dp.Metrics.COUNT, pipeline_dp.Metrics.MEAN],

max_partitions_contributed=3,

max_contributions_per_partition=2,

)

dp_result = dp_engine.aggregate(pcollection, params, data_extractors)

10.2 JAX-Privacy

DeepMind が作った JAX ベース DP ライブラリ。大規模モデル(特に LLM)学習時に Opacus より効率的なベクトル化を提供します。2024-2025年に DeepMind は JAX-Privacy で学習した DP 言語モデルの結果を多数発表しました。

10.3 Google RAPPOR

Local DP の産業界初の大型適用事例。Chrome ブラウザでユーザーがどのホームページをデフォルトに使うかの統計を収集する際、各ユーザーの回答にビット単位でノイズを加え、サーバーは個別ユーザーの答えを知ることができないようにしました。2014年発表。

11. Homomorphic Encryption の概念 - CKKS、BFV、TFHE

11.1 FHE の約束

Fully Homomorphic Encryption(FHE)は「暗号文に対して直接演算を実行すると、その結果を復号したときに平文に対する演算結果と同じになる」という性質を持つ暗号システムです。1978年に Rivest et al. が可能性を提起し、2009年に Craig Gentry が最初の具体的実装を発表。

FHE の約束 - クライアントがデータを暗号化してサーバーに送り、サーバーはデータを見ずに演算を実行し、暗号化された結果を返す。クライアントだけが復号可能。**究極の外注計算**。

11.2 主要なスキーム

| スキーム | 特徴 | 適した用途 |

|----------|------|------------|

| BGV(2012) | 整数平文 | 整数演算、SQL 集計 |

| BFV(2012) | 整数平文、多項式スロット | SIMD 整数演算 |

| CKKS(2017) | 近似浮動小数点 | ML 推論、統計 |

| TFHE(2016) | ビット単位、高速ブートストラッピング | 任意回路、比較、条件分岐 |

| FHEW(2014) | TFHE の前身 | 単一ビット演算 |

ML 推論には主に CKKS(浮動小数点、近似演算)か TFHE(任意回路)が使われます。

11.3 Bootstrapping

FHE の核心的挑戦 - 演算を重ねるほど暗号文のノイズが累積し、結局復号できなくなる時点が来ます。ブートストラッピングは「暗号文を自分自身を復号する回路に通してノイズをリセット」する魔法のような技法です。コストが非常に高い(ミリ秒から秒単位)が、無制限の深さの回路を可能にします。

TFHE はブートストラッピングが高速(ミリ秒)で、全ゲートごとにブートストラッピングする「Programmable Bootstrapping(PBS)」戦略を取ります。これが Zama Concrete の核心です。

12. Zama Concrete - FHE コンパイラの新時代

12.1 Zama と Concrete

Zama は2020年にパリで設立された FHE 専門企業です。CEO は Rand Hindi、CTO は Pascal Paillier(Paillier 暗号の Paillier 本人)。2024年シリーズ A で 7,300万ドルを調達しました。主力製品は **Concrete** という FHE コンパイラ。

伝統的に FHE ライブラリ(SEAL、OpenFHE)は「この関数を FHE で直接書き直してください」という低レベル API を提供してきました。Zama Concrete の革命 - **通常の Python/Rust コードを FHE に自動コンパイル** します。

12.2 Concrete Python

from concrete import fhe

@fhe.compiler({"x": "encrypted", "y": "encrypted"})

def add_mul(x, y):

return (x + y) * 2

inputset = [(i, i) for i in range(10)]

circuit = add_mul.compile(inputset)

鍵生成

circuit.keygen()

クライアント側 - 入力暗号化

encrypted_input = circuit.encrypt(5, 7)

サーバー側 - 暗号文上で演算

encrypted_result = circuit.run(encrypted_input)

クライアント側 - 復号

decrypted = circuit.decrypt(encrypted_result)

print(decrypted) # 24

このシンプルさが Zama の強みです。開発者は FHE の数学を知る必要がありません。

12.3 Concrete-ML

ML モデルを FHE にコンパイルする高レベルライブラリ。scikit-learn 互換 API を提供します。

from concrete.ml.sklearn import LogisticRegression as ConcreteLogReg

from sklearn.datasets import load_iris

X, y = load_iris(return_X_y=True)

model = ConcreteLogReg(n_bits=8)

model.fit(X, y)

FHE 回路にコンパイル

model.compile(X)

推論(平文)

y_pred = model.predict(X)

推論(FHE)

y_pred_fhe = model.predict(X, fhe="execute")

対応モデル - Linear/Logistic Regression、Random Forest、XGBoost、Decision Tree、小規模ニューラルネットワーク。2025-2026年には ViT のようなトランスフォーマーモデルの部分 FHE 推論(特にアテンション部分)もデモとして公開されました。

12.4 TFHE-rs

Concrete のバックエンドである TFHE-rs は Rust で書かれた TFHE ライブラリです。2025年に GPU アクセラレーションが追加され、ブール演算と整数演算の両方をサポートします。

use tfhe::{ConfigBuilder, generate_keys, FheUint8, prelude::*};

let config = ConfigBuilder::default().build();

let (client_key, server_key) = generate_keys(config);

set_server_key(server_key);

let a = FheUint8::encrypt(150u8, &client_key);

let b = FheUint8::encrypt(100u8, &client_key);

let sum = &a + &b;

let decrypted: u8 = sum.decrypt(&client_key);

12.5 fhEVM - ブロックチェーン上の FHE

Zama のもう一つの興味深い取り組みが **fhEVM** - イーサリアム互換 EVM に FHE データ型(euint8、ebool 等)を追加したチェーンです。非公開トランザクション、非公開投票、非公開 DeFi がスマートコントラクトで可能になります。

13. Microsoft SEAL、IBM HElib、OpenFHE、Lattigo

13.1 Microsoft SEAL 4.1

Microsoft Research が作った C++ HE ライブラリ。BFV と CKKS をサポートします。2024年に 4.1 バージョンが発表され、長らく学術界と産業界の標準の一つでした。Python バインディングは OpenMined の TenSEAL が人気。

13.2 IBM HElib

IBM Research が2013年から開発している BGV/CKKS ライブラリ。ブートストラッピング最適化で有名です。Shai Halevi と Victor Shoup が主導。

13.3 OpenFHE 1.2(旧 PALISADE)

2022年に PALISADE プロジェクトがより広範な協業形態として再出発した結果。BFV、BGV、CKKS、FHEW、TFHE まで全てサポートする最も包括的なライブラリ。Duality Technologies、Intel、Samsung、NJIT 等が参加します。2026年5月時点で 1.2.x が安定版。

13.4 Lattigo - スイス Tune Insight の Go ライブラリ

EPFL スピンオフの Tune Insight が作った Go ベース HE ライブラリ。BFV、CKKS、そして Multiparty HE(複数当事者鍵)をサポートします。Go エコシステムで高速な性能を見せます。

13.5 ライブラリ比較

| ライブラリ | 言語 | 主要スキーム | 強み |

|------------|------|-------------|------|

14. Secure Multi-Party Computation の概念

14.1 Yao の Garbled Circuits(1986)

Andrew Yao の百万長者問題 - 「2人の百万長者は誰の財産が多いか知りたいが、各自の正確な財産は公開したくない」。Yao はブール回路を「garbled」形態にして、一方が回路を評価し、他方が入力を oblivious transfer で受け取る 2-party プロトコルを提案しました。

14.2 GMW プロトコル(1987)

Goldreich、Micali、Wigderson は任意の数の当事者(n-party)で動作する秘密分散ベース MPC を提案しました。各ビットを XOR 秘密分散で分け持ち、AND/XOR ゲートを処理します。

14.3 SPDZ(2012)とその後継

SPDZ(Damgard et al., 2012)は悪意的攻撃者(malicious adversary)に強い MPC プロトコル。前処理段階で Beaver triple のような相関ランダム性を生成し、オンライン段階で高速に演算します。その後 SPDZ2、MASCOT、Overdrive 等の変種が出ました。

14.4 セキュリティモデル

- **Semi-honest(Honest-but-curious)** - プロトコルには従うがメッセージから情報を抽出しようとする。最も弱いモデル。

- **Malicious** - 任意にプロトコルを違反する。最も強いセキュリティ要求。

- **Covert** - 違反しても一定確率で検出されれば満足。

15. CrypTen、MP-SPDZ、EzPC - PPML 用 MPC フレームワーク

15.1 CrypTen(Meta/Facebook)

Facebook AI Research が2020年に公開した PyTorch ベース MPC ライブラリ。PyTorch テンソルを secret-shared テンソルとしてラップし、ML ワークロードをほぼそのまま MPC 上で実行できるようにしました。

crypten.init()

2つの当事者がそれぞれテンソルを作り

x_party0 = torch.tensor([1.0, 2.0, 3.0])

CrypTen テンソルに変換(自動的に secret-shared)

x_enc = crypten.cryptensor(x_party0, src=0)

y_enc = crypten.cryptensor([4.0, 5.0, 6.0], src=1)

MPC 上で演算

z_enc = x_enc + y_enc

結果復号(双方が同意した場合)

z = z_enc.get_plain_text()

print(z) # tensor([5., 7., 9.])

CrypTen は意図的に semi-honest セキュリティモデルのみサポートします。高速で使いやすい代わりに、攻撃者が嘘をつかないという仮定に依存。

15.2 MP-SPDZ

ブリストル大学の Marcel Keller が主導する MPC フレームワーク。30以上のプロトコル(semi-honest、malicious、dishonest majority、honest majority)をサポートする、事実上 MPC の百科事典。学術ベンチマークでよく使われます。

15.3 EzPC(Microsoft Research India)

EzPC は「Easy Secure Multi-party Computation」の略。C スタイルのコードを自動的に secure 2-party プロトコルにコンパイルします。CrypTFlow はその上の ML コンパイラで、TensorFlow モデルを MPC に変換します。2023-2025年に BERT のようなトランスフォーマーモデルを MPC 推論する SIGMA、BumbleBee のような後継作業が発表されました。

15.4 MPC の通信コスト問題

MPC の最大のコストは演算ではなく **通信** です。AND ゲートごとに oblivious transfer ラウンドが必要で、これがミリ秒単位の RTT を累積させます。結果として MPC ML 推論は同じモデルの平文推論より 100倍から 10,000倍遅くなる可能性があります。

16. TEE - ハードウェア分離の道

16.1 Intel SGX とその危機

Intel Software Guard Extensions(SGX)は2015年に導入された x86 命令セット。CPU 内部に分離された enclave を作り、コードとデータをホスト OS、ハイパーバイザー、さらには BIOS からも保護します。一時は confidential computing の標準でした。

しかし2018年以降、Foreshadow、Spectre、Plundervolt、AEPIC Leak 等の一連のサイドチャネル脆弱性が発見され、SGX のセキュリティモデルが疑問視されるようになりました。Intel は2021年にクライアント CPU から SGX を削除し始め、サーバー CPU では SGX-DCAP を通じてリモート attestation を強化しました。

16.2 AMD SEV-SNP

AMD の Secure Encrypted Virtualization-Secure Nested Paging は VM 全体を暗号化します。SGX が enclave 単位なら SEV は VM 単位。AWS、Azure、GCP の confidential VM 製品が SEV-SNP ベースです。

16.3 Apple Private Cloud Compute(2024)

Apple が2024年 WWDC で発表した PCC は TEE 史上最も野心的なシステムの一つです。核心的アイディア -

- **カスタム Apple Silicon サーバー** - Secure Enclave が鍵管理

- **Stateless ノード** - リクエスト処理後に全データを即時破棄、永続保存なし

- **Code transparency** - ノードで実行される全コードのハッシュを公開透明性ログに掲載

- **End-to-end attestation** - ユーザー端末が PCC ノードの測定値を検証

- **No privileged access** - Apple 社員でさえノード内部データにアクセス不可

2025年から Apple Intelligence の一部大規模モデルリクエストが PCC を通じて処理されます。ユーザーデータが Apple サーバーに行くことはありますが、Apple はそれを見ることができない構造です。

16.4 AWS Nitro Enclaves

AWS の Nitro ハイパーバイザー上に作られる分離された仮想マシン。EC2 インスタンスの一部 vCPU/メモリを切り出して enclave とし、親 EC2 とは vsock でのみ通信します。Nitro Security Module は KMS と統合され、attestation ベース鍵リリースを提供します。医療、金融分野の confidential ワークロードで人気。

16.5 NVIDIA H100/H200 Confidential Compute

2023年から NVIDIA GPU も confidential computing 機能を備え始めました。H100/H200 GPU では CPU 側が SEV-SNP/TDX、GPU は独自の confidential モードで動作し、GPU メモリも暗号化されます。LLM 推論を TEE で動かせるようになった最初の GPU 世代です。

17. 実運用事例 - ビッグテックから日韓金融まで

17.1 Google Gboard

最も有名な FL 事例。Android Gboard キーボードはユーザーの入力データをサーバーに送らずに、次単語予測、絵文字推薦、音声認識モデルを学習します。毎日数百万台の端末が夜間充電中に学習に参加します。Secure Aggregation で個別勾配も保護されます。

17.2 Apple

- Siri 音声認識向上に FL

- 絵文字推薦に Local DP

- 2024年から Apple Intelligence と PCC

17.3 BraTS Federated と医療

NVIDIA FLARE ベースの BraTS Federated は71の医療機関協業で脳腫瘍分割モデルを学習しました(Pati et al., 2022)。以降、NVIDIA Clara FL は胸部 X 線、病理学、コロナ診断等の様々な協業学習事例を作っています。

17.4 MELLODDY

10の世界的製薬企業(Janssen、Bayer、GSK、Novartis、AstraZeneca 等)が IMI(Innovative Medicines Initiative)の支援で2019-2022年に進めた連合学習プロジェクト。各社の化合物-タンパク質活性データを共有せずに薬効予測モデルを共同学習しました。結果として予測精度が単一企業モデルより向上し、データは1バイトも企業外に出ませんでした。

17.5 韓国金融機関の FL/MPC 適用

2023-2025年に韓国で仮名情報結合とデータ結合専門機関制度が活性化し、FL と MPC が金融実務に入りました。

- 新韓銀行、国民銀行、ウリ銀行は結合専門機関(金融保安院、NICE 等)を通じたデータ結合で信用評価モデルを協業しています。

- NAVER Cloud は金融機関向け FL プラットフォームを提供しています。

- 通信会社(SKT、KT、LGU+)とカード会社が PSI ベースの広告効率測定に参加中。

17.6 日本 NTT R&D と金融

NTT 研究所は BFV ベース HE を活用して日本の金融機関の不正検知協業モデルを PoC 段階で進めました。APPI(個人情報保護法)下で仮名データを活用した共同分析が可能ですが、その中でも HE/MPC を活用して追加保護層を作る試みです。2024-2025年に NTT データ、三菱 UFJ、みずほ等が様々な PoC を進めています。

18. 規制環境 - GDPR、HIPAA、EU AI Act、K-PIPA、APPI

18.1 GDPR と PPML

GDPR Article 25(data protection by design and by default)は PPML 技法を事実上推奨しています。Article 32(security)と一緒に読むと、「必要に応じて仮名化、暗号化、匿名化技法を適用しなければならない」という義務と解釈されます。

特に GDPR Recital 26 が明示する「匿名化されたデータは GDPR の適用対象ではない」という点が重要です。よく適用された DP や FHE は GDPR 義務をかなりの部分免除される可能性があります(法的解釈は事例別)。

18.2 HIPAA Safe Harbor と Expert Determination

米国 HIPAA は医療データの非識別化方法として2つを定義します。(1) Safe Harbor - 18個の識別子削除。(2) Expert Determination - 統計専門家のリスク評価。DP ベース非識別化は Expert Determination 経路で認められる事例が増えています。

18.3 EU AI Act と PPML

2024年発効の EU AI Act は高リスク AI(医療、採用、信用評価、法執行、教育)システムに対してデータガバナンス(Article 10)、頑健性と正確性(Article 15)、人間による監督(Article 14)要件を課します。データガバナンス要件は PPML 技法採用の強いインセンティブとなります。

18.4 韓国 PIPA と仮名情報

2020年改正 PIPA(個人情報保護法)は **仮名情報** 概念を導入しました。追加情報なしには特定個人を識別できないように処理された情報で、統計作成、科学研究、公益記録保存目的では同意なしに活用可能です。仮名処理基準は PIPC(個人情報保護委員会)告示に従い、k-匿名性、l-多様性、t-近接性のような技法が使われます。2023年から DP も推奨技法に含まれ始めました。

18.5 日本 APPI

日本の個人情報保護法(APPI)は2022年改正で **匿名加工情報** と **仮名加工情報** の2つを明確化しました。匿名加工情報は同意なしに第三者提供可能、仮名加工情報は内部分析用のみ。PPC(個人情報保護委員会)がガイドラインを提供します。

18.6 比較サマリー

| 規制 | 地域 | 主な PPML 関連条項 |

|------|------|--------------------|

| GDPR | EU | Art 25 (by design)、Recital 26 (匿名化) |

| HIPAA | US | Safe Harbor、Expert Determination |

| EU AI Act | EU | Art 10 (データガバナンス)、高リスク AI |

| CCPA/CPRA | カリフォルニア | Sensitive Personal Information カテゴリ |

| PIPA | 韓国 | 仮名情報、結合専門機関 |

| APPI | 日本 | 匿名加工情報、仮名加工情報 |

| PIPL | 中国 | 分離同意、データ越境セキュリティ評価 |

19. PPML 導入チェックリスト - どこから始めるか

19.1 脅威モデルの定義

まず誰から何を守るか明確にします。

- 外部攻撃者からの学習データ保護 - DP が核

- 他の協業機関からの自社データ保護 - FL + Secure Aggregation

- クラウド事業者からの全データ/モデル保護 - TEE または FHE

- 分析者からの raw データ保護 - PySyft のような structured transparency

19.2 精度-プライバシー-効率のトライアングル

PPML 技法は本質的にトレードオフです。

|------|--------------|------------------|------------------|

| Plain FL(no SecAgg) | ほぼなし | 中 | 低 |

| FL + SecAgg | ほぼなし | 中 | 中 |

| FL + DP | 1-5pp 損失 | 中 | 高 |

| TEE | なし | ほぼなし | ハードウェア信頼仮定 |

19.3 推奨スタート地点

- **小規模協業** - Flower(シミュレーション -> 実運用)

- **医療/金融コンソーシアム** - NVIDIA FLARE

- **DP が必要な学習** - Opacus(既に PyTorch ならば)

- **DP 統計リリース** - OpenDP / SmartNoise / PipelineDP

- **クラウド LLM 推論保護** - TEE(Apple PCC モデル)、Confidential VM

- **暗号化推論** - Concrete-ML(簡単)または SEAL/OpenFHE(上級)

19.4 運用面

- DP 会計(privacy accountant)は実行ごとに累積されなければなりません。データセット別 eps 上限ポリシー必須。

- モデル自体のメタデータ漏洩防止(model serialization 時にクライアント情報削除)。

- attestation ログ保管 - TEE 使用時にどのコード/ファームウェアバージョンだったか事後監査可能でなければならない。

- 鍵管理は KMS/HSM に委任。FHE 秘密鍵が漏洩すると全てが崩壊します。

20. 2026年の展望 - PPML は標準になるか

20.1 LLM 時代の PPML 再定義

ChatGPT、Claude、Gemini がユーザー入力を見る問題は 2024-2026年に PPML を再注目させました。Apple PCC は最初の大規模運用事例で、他のビッグテックも同様の confidential AI 基盤を作っています。2026年5月時点で -

- Microsoft Azure Confidential AI - SEV-SNP + GPU TEE

- Google Cloud Confidential GKE - AMD SEV / Intel TDX

- AWS Nitro Enclaves + EC2 H100 confidential instances

- Anthropic Constellation(Confidential Workloads)

20.2 FHE アクセラレーションハードウェア

FHE の 100-10,000倍の性能ペナルティを克服するための ASIC が登場しています。

- Optalysys(英国) - 光学 FHE アクセラレータ

- Cornami - FHE 専用チップ

- Niobium Microsystems - DPRIVE(DARPA)プログラム ASIC

- Intel Centaurus(DARPA DPRIVE)

これらが量産化されると FHE のコストが 10-100倍下がる可能性があります。

20.3 ZK + FHE + MPC の融合

zk-SNARK(ゼロ知識証明)技術がブロックチェーンの発展のおかげで急速に成熟しました。これと FHE/MPC を組み合わせたシステムが登場中 - zkML、FHE on chain(fhEVM)、MPC with attested integrity。PPML と web3 の境界が曖昧になっています。

20.4 標準化の取り組み

- IEEE P3652.1 - FL 標準

- ISO/IEC 27559 - 非識別化ガイド

- ISO/IEC 4922 - Secure Multi-Party Computation

- IETF PPM(Privacy Preserving Measurement) - Prio3 等の LSPS 標準

20.5 市場規模

Markets and Markets、Gartner、IDC 等は PPML/Confidential Computing 市場が2026年に100億ドル規模に成長し、CAGR 50% 以上と推定しています。最大の牽引役は LLM 時代の入力プライバシー要求。

20.6 結びに - データが動かない時代

10年前の「ビッグデータ」時代のモットーは「データを集めよ」でした。2026年 PPML 時代のモットーは正反対 - **「データはそのままに、答えだけを持って来い」**。Federated Learning はモデルを動かし、Differential Privacy は答えに安全性を加え、Homomorphic Encryption は暗号化されたまま答えを作り、MPC は複数当事者を協業させ、TEE はハードウェア分離でそれを強制します。

この5つの技術は互いに排他的ではありません。実際のシステムは通常 2-3個を組み合わせます - FL + DP + Secure Aggregation、TEE + FHE、MPC + DP。どの組み合わせが正しいかは脅威モデル、精度要求、通信予算、規制環境によって異なります。

確かなのは - データを動かさずに協業し、学習し、推論する時代が既に始まったということです。

参考資料

- Flower Labs - https://flower.ai/

- Flower 1.13 Documentation - https://flower.ai/docs/framework/

- NVIDIA FLARE GitHub - https://github.com/NVIDIA/NVFlare

- NVIDIA FLARE Documentation - https://nvflare.readthedocs.io/

- TensorFlow Federated - https://www.tensorflow.org/federated

- OpenMined PySyft - https://github.com/OpenMined/PySyft

- OpenMined.org - https://www.openmined.org/

- Opacus (PyTorch DP) - https://opacus.ai/

- OpenDP - https://opendp.org/

- Google DP Library - https://github.com/google/differential-privacy

- Microsoft SmartNoise - https://smartnoise.org/

- Zama Concrete - https://www.zama.ai/concrete

- Concrete-ML - https://docs.zama.ai/concrete-ml

- TFHE-rs - https://github.com/zama-ai/tfhe-rs

- Microsoft SEAL - https://github.com/microsoft/SEAL

- OpenFHE - https://www.openfhe.org/

- IBM HElib - https://github.com/homenc/HElib

- Lattigo - https://github.com/tuneinsight/lattigo

- CrypTen (Facebook) - https://crypten.ai/

- MP-SPDZ - https://github.com/data61/MP-SPDZ

- EzPC (Microsoft Research) - https://github.com/mpc-msri/EzPC

- Apple Private Cloud Compute - https://security.apple.com/blog/private-cloud-compute/

- AWS Nitro Enclaves - https://aws.amazon.com/ec2/nitro/nitro-enclaves/

- Confidential Computing Consortium - https://confidentialcomputing.io/

- McMahan et al., FedAvg (2017) - https://arxiv.org/abs/1602.05629

- Abadi et al., DP-SGD (2016) - https://arxiv.org/abs/1607.00133

- Pati et al., BraTS Federated (Nature Communications 2022) - https://www.nature.com/articles/s41467-022-33407-5

- EU AI Act - https://artificialintelligenceact.eu/

- Korea PIPA - https://www.pipc.go.kr/

- Japan APPI / PPC - https://www.ppc.go.jp/