隠す・分ける・示すを組み合わせる — 予習ノート

講義は 4 部構成。① ZK / MPC / FHE を整理して目的指向で合成する → ② アプリケーション紹介（zkVM / zkTLS / zkML / zkEmail / PIR / World ID）→ ③ 要件定義（設計フロー・ライブラリ・性能・プライバシー・法律）→ ④ ホワイトボードセッション。

これまでの週は「1 つの道具の中身」でした。今週は「道具を選んで組む」側に立ちます。実装時の注意点（性能・セキュリティ・プライバシー・法律）は第 3 部（カード 31〜34）でまとめて扱います。

Trusted Third Party（各人が秘密を「信頼する誰か」に預ける）→ Mathematically Trustworthy Protocol（信頼を暗号プロトコルに置き換える）。Programmable Cryptography が目指すのはこの置換。

Nick Szabo の「The God Protocols」（1997）が出発点です。全員が秘密を預けられる神様がいれば、秘密入札も匿名投票も一瞬で済む。その神様の役を、誰も信頼せずに数学で果たすのが ZK・MPC・FHE です。

ドリルで見る形: ドリル A の 2 人は、どちらも w の全体を持たないまま証明を組みます（誰も神様にならない）。ドリル C は「預かり所」に何を見せずに済むかを追います。

HTTPS / DKIM などで既に署名済みのデータを、zkSNARK で検証しながら任意の宛先形式へ変換できる。既存サービスの移行を待たずに相互運用が成り立つ。

ここが「応用」の入口です。世の中のデータは、すでに誰かが署名しています（Web サーバの TLS、メールの DKIM、パスポートの IC チップ）。その署名を回路の中で検証すれば、「Google がこのメールを送ったと保証している内容のうち、この 1 項目だけを示す」ができる。zkEmail・zkTLS・POD2（補遺）は全部この形です。

special-purpose = 1 つの操作だけを暗号的に保証（署名 / range proof / group signature）。programmable = 暗号の中で汎用計算ができる（ZK / MPC / FHE / Witness Encryption / iO）。

Week 1 の署名や Week 2 の秘密分散は「1 つの操作」でした。汎用計算ができるようになると、「何を保証するか」を回路（プログラム）で自由に書ける。だから今週は数式ではなく設計が主題になります。

3 つは位相（誰が誰と何をやり取りするか）で覚える。各セルの保証は「無料ではない」対価で、組み合わせれば全部解決、は誤り。

信頼前提の行が設計の要です。FHE は「Server を信頼」と書いてある — 中身は見えないが、正しく計算したかは分からない。MPC は「t 未満の共謀」までしか守れない。この 2 つの穴が、カード 8 の合成パターン②（Verifiable FHE）と⑥（co-SNARK）を生みます。

各アプリは、暗号プリミティブどうし、または既存システムとの合成として現れる。

この週のドリルと宿題は ⑥ と ②、それに zkVM: ドリル A / 宿題 co-snark-prove が ⑥（分ける + 示す）、ドリル B / 宿題 zkvm-exploit が zkVM（実行を示す）、GW① の模範解が ②（隠す + 示す）。3 つの合成の「+」の部分を、それぞれ 1 行の Python で通します。

ZK = 検証可能な配線（wire）、FHE-MPC = 秘匿計算 CPU、ORAM = 高速な暗号 state、Ethereum = 社会規模のハードディスク。「zkSNARK 単体で何ができるか」ではなく、統合スタックとして何が作れるかを問う。

コンピュータの部品に見立てた図です。配線（結果を運ぶ = 正しさの証明）、CPU（秘密のまま計算）、記憶（アクセスパターンも隠す）、ディスク（誰でも読める公開台帳）。この見立てが、カード 29 の「欲しい成果物から選ぶ」決定木の土台になります。

Tornado Cash（匿名ミキサー）／ zkVM（任意プログラムの実行を、回路を手書きせず証明）／ zkEVM（EVM 実行を証明して L1 を圧縮）／ leanVM（耐量子署名 leanXMSS を zkVM で再帰集約）／ zkEmail（DKIM 署名を ZK 検証）／ zkML（モデル推論の正しさを ZK 証明）。

6 つのうち、この節で Tornado Cash を、次の節で zkVM と leanVM を深掘りします。zkEVM・zkEmail・zkML は「zkVM の上に作られた用途特化」として、カード 15 で位置づけられます。

User A が 1 ETH と commitment C を預入アドレス（公開）から送る。同じ固定額の預入が 1 本の Merkle 木に集まり、どれが誰の C か埋もれる。無関係な新アドレス A′ が証明 π を出して 1 ETH を受け取る。

預入:  A ──(1 ETH + C)──▶ プール（Merkle 木: root ← C₁, C, C₃, C₄）
       note (k, r) は手元だけ・秘密
引出:  A′ ──(π)──▶ プール ──(1 ETH)──▶ A′
       A ↔ A′ のリンクを暗号的に断ち切る

匿名集合（anonymity set）は「自分と見分けがつかない人の集まり」です。木に葉が n 枚あれば、引き出した人は n 人のうちの誰か。預入者が増えるほど大きく育ちます。

ドリル C の 2〜4 行目: C = h(k, r) → leaves.index(C) → root。「木に入っている」を根 1 つで表せることが、この 3 行で見えます。

commitment + nullifier + Merkle membership で預入と引出のリンクを暗号的に断つ。ただし匿名性は暗号の外 = 使い方で決まる。

① 預入   乱数を 2 つ: secret k（秘密）、nullifier r（後で二重引出を防ぐ）
         commitment C = H(k, r) を提出、1 ETH を送金。k, r はチェーンに出さない
② 匿名集合  commitments の Merkle 木。預入者が増えるほど大きい
③ 引出   新アドレス A′ から zk-SNARK で証明:
           ▸ k, r を知る葉 C が木に存在（membership）
           ▸ nullifierHash = H(r) を公開
         nullifierHash 既出なら拒否 = 二重引出を防止。リレイヤーがガス代を肩代わり

暗号が保証すること: 預入 C と引出は数学的に連結不可（zero-knowledge）。漏れるのは「木のどれかの葉」まで。nullifierHash で二重引出を阻止（soundness）。

運用次第で漏れる情報: タイミング相関、関連アドレスの再利用、金額・ガス・リレイヤーの痕跡、過疎なプールで匿名集合が実質縮む。使用パターンのクラスタ分析で、Tornado Cash 取引のうち $2.3B 相当が身元特定可能と報告されています（arXiv 2510.09433）。暗号保証 ≠ 実用プライバシー。

ドリル C の 6〜8 行目: nh = h(r) を公開し、spent に入れ、2 回目は nh in spent が True で拒否。k は最後まで一度も出てきません — それが「どれかは言わない」の中身です。

Solidity verifier = ZK 証明システムの検証アルゴリズムを Solidity コントラクトとして実装したもの。π と public inputs を渡すと on-chain で検証し、結果に応じて状態遷移をトリガーする。Tornado Cash のコントラクトがまさにこれ。

① Prover   witness を使って計算を実行し π を生成。witness は誰にも見せない
② Verifier コントラクトが π と public inputs を受け取り verify ✓/✗
           $ snarkjs zkey export solidityverifier circuit.zkey Verifier.sol
           人は回路（circom）だけ書き、verifier は機械生成
③ Chain    verify ✓ なら状態遷移（払出・認証・集約）。全ノードが同じ検証を独立に再実行

Public Verifiability: ブロックチェーンは誰でも検証できる公開台帳なので、中央の信頼者が要りません。ZK の「正しさ」が、数学的事実から合意形成の基盤へ変わる。

設計の含意: 「proof を誰が・どこで検証するか」は primitive 選択と同じくらい重要。オンチェーン検証 = gas cost という実コストが伴います（カード 32 の「0.93 KB の Groth16 が今も優位」に直結）。

Rust / C の普通のプログラム → RISC-V などの VM ISA にコンパイル → 実行トレース（1 命令ずつ記録）→ 算術化して STARK/SNARK で prove → 小さな proof を再実行せず検証。on-chain でも安価。

Week 4 までの ZK は「回路を手で書く」でした。zkVM は「CPU の 1 ステップが正しい」という制約を 1 回だけ書いておき、どんなプログラムもその CPU の上で走らせれば証明できる、という発想です。zkEVM・zkEmail・zkML はいずれもこの上に作られた用途特化（スライド 15）。

宿題 zkvm-exploit の立ち位置: zkVM 本体は動かしません。書くのは「zkVM の中で走る guest プログラム」（guest_main）と、「何を公開し、何を witness に残すか」（public_claim）。Proof of Exploit = 「このプログラムには攻撃が存在する」を、攻撃入力そのものは見せずに示す。

trace T ∈ Fⁿˣʷ（n ステップ × w 列: pc・レジスタ・メモリ操作・フラグ）。∀i: C(T[i], T[i+1]) = 0（隣接行が ISA 規則に従う）と、T[0] = init・out(T[n−1]) = y（境界）。正しい実行 ⟷ 全行で制約多項式が 0。

① 実行 → トレース表   エミュレータが 1 命令ずつ実行し、各ステップの VM 状態を 1 行に記録
② 算術化（AIR）        各列を有限体上の多項式とみなし、「正しい実行」を多項式の恒等式に帰着
                        隣接行制約 + 境界制約が、評価領域の全点で 0 になるか
③ 証明（STARK/SNARK）  多項式コミット + 検査で恒等式を簡潔に証明。verify は数点の評価のみ
   単変数系: 商多項式 + FRI（Week 4）   多変数系: hypercube 上の sumcheck（Jolt / WHIR → LeanVM）

要点: 証明者はネイティブ実行の 10³〜10⁶ 倍重い。continuations / precompiles / recursion / GPU proving で実用化が進む。検証側は一貫して軽い。

ドリル B の 6〜9 行目がこのスライドの最小版です。trace は「16 ビットの合計」1 列だけ、隣接行制約は (trace[i] + c[i]) % M − trace[i+1] の 1 種類、境界制約は「先頭は 0」「末尾 ≤ CAP」。表を 1 か所書き換えると残差が 65535 になって捕まる。制約が全部 0 であることが、証明の中身です。

各 validator は毎スロット、ブロックに署名する。量子計算機が BLS 署名（楕円曲線）を破るため、ハッシュベースの耐量子署名 leanXMSS への置換が必須。leanXMSS は 1 個 ~3,000 B（BLS は 96 B）で単純加算で集約できない → zkVM が全署名の検証を 1 つの小さな proof に再帰集約（約 250 倍圧縮）。

なぜ zkEVM ではないのか: ① 対象が違う — zkEVM は実行層、要るのは合意層の署名集約。② zkEVM は楕円曲線依存で量子脆弱。PQC 移行の VM がそれでは本末転倒。③ 速度と形式検証のため ISA は最小。

橋: 「verify ∘ verify ∘ …」の再帰集約は、Week 4 の「証明の証明」（recursion）そのものです。1 つの proof が「4 つの署名検証がすべて通った」を表す。

レジスタは FP / PC のみ（AP なし）、メモリは read-only、ISA は ADD / MUL / DEREF / JUMP の 4 命令だけ。無駄をそぎ落とした設計。

命令が 4 つしかない理由は、カード 17 の「隣接行制約」の数がそのまま証明コストになるからです。命令が少ないほど制約も少なく、形式検証もしやすい。ドリル B の VM は命令 1 つ（16 ビット加算）で、その極端な例です。

実行を複数のテーブルに分け、lookup で Memory に束ね、GKR で結合して証明する。1 サイクルわずか 5 要素のみコミット。多項式コミットは WHIR。

Week 4 の PLONK では 1 つの大きな表に全部を入れました。LeanVM は表を役割ごとに分けて（4 テーブル）、表どうしの整合を lookup（Logup*）で取ります。コミットする量が減るので証明者が軽くなる。

zkTLS（ZK + MPC）= Web2 の API レスポンスを第三者検証可能に（TLSNotary / vlayer / Reclaim）。PIR（FHE）= どのインデックスを引いたか隠して取得。World ID（co-SNARK）= 虹彩コードの一意性を秘匿したまま検証。Verifiable FHE（FHE + ZK）= 暗号文のまま計算を委託し、結果の正当性も検証。

PIR（Private Information Retrieval）は「図書館で何を借りたか司書にも知られずに本を借りる」です。RPC やライトクライアントが「どのアカウントの残高を見たか」を隠すのに使います。zkTLS は、TLS 通信の中身を MPC で秘密分散したまま処理して「このサーバがこう返した」を証明する — カード 5 の「署名済みデータのアダプタ」の TLS 版です。

Orb スキャン → iris code 化 → 一意性を判定し、検証済み人間の集合（Merkle 木）へ登録。

問題は「一意性判定」です。新しい虹彩コードを、既登録の数百万件と照合しなければならない。しかし虹彩コードは究極の個人情報で、平文で持ちたくない。ここで MPC と co-SNARK が要ります。

World ID は単一プリミティブではなく、秘匿照合（MPC）・検証可能性（co-SNARK）・匿名性（Semaphore）の合成。

① Orb スキャン（専用 HW）  虹彩から人間性と一意性を読み取る
② iris code 化              生画像は破棄。一意性判定用のコードのみ残す
③ 一意性チェック（MPC）      iris code を秘密分散し、平文を誰も見ずに既登録と照合
④ 計算の検証可能性（co-SNARK） 照合が正しく行われたことを公開検証可能に（TACEO:Proof, 2025）
⑤ 匿名クレデンシャル（Semaphore） 身元を隠して「検証済み人間」を証明し、二重使用を防止

発行後のプライバシー（⑤）: Semaphore は検証済み人間の Merkle 木に「匿名で」所属を証明する — Tornado Cash と同じ commitment + nullifier + membership です。nullifier は (user × app × action) ごとに決定的だが紐付け不可なので、本人を特定せずに「1 人 1 アクション」を強制し、アプリ横断トラッキングを防ぐ。World ID 4.0 は分散 OPRF で nullifier を計算し one-time-use 等で強化（生体情報の規制議論は継続）。

ドリル C とのつながり: ⑤ はドリル C の 10 行がそのまま当てはまります。葉が「預かり証」から「検証済み人間の commitment」に変わるだけ。

witness を秘密分散して配る（各 party は自分の share だけ、誰も w 全体を知らない）→ MPC で協調 prove（線形な MSM・FFT はローカル = 無料、乗算だけ通信ラウンド）→ open で π を得る。single-prover と byte-identical な 1 proof。検証者・vk・proof サイズは無変更。

分散  [w] ← Share(w)          誰も w 全体を持たない（N 者へ秘密分散）
MPC   Prove(pk, x; [w])        線形（MSM・FFT）= ローカル / 乗算のみ通信
open  π ← Open(A, B, C)        single-prover と byte-identical
verify Verify(vk, x, π)        検証側は何も変えなくてよい

「線形はローカル、乗算だけ通信」の理由: share の足し算・定数倍は、各自が自分の share に同じ計算をするだけで、結果の share になります。掛け算はそうならない（share 同士の積は積の share ではない）。だから掛け算のときだけ Beaver triple で 1 往復する。証明生成の大半（MSM・FFT）は線形なので、通信は少なくて済みます。

ドリル A の 5〜12 行目がこの 3 段です。A_sh = [5, 8]（線形 = 手元）→ share 同士の積は (21, 27) で不一致（掛け算は手元では無理）→ Beaver で (d, e) = (8, 8) を公開 → z = [27, 0] → open 27。宿題では linear_combination_shares（5〜7 行目）と mpc_prove（9〜12 行目）。

FHE が守るのはデータ機密だけ。「正しく計算したか」は別問題。そこに ZK で計算の正しさを足すのが Verifiable FHE。

ユーザが秘密データ x を E(x) にしてサーバへ。サーバは中身を見ずに f を評価して E(f(x)) を返す。ここまでが Week 5。問題は、サーバが f ではなく g を計算していても、ユーザは復号するまで分からず、復号しても「これが f(x) か」を確かめる手段がないことです。

enc → eval → prove₁（ユーザ: 暗号文が正しく作られている）→ prove₂（サーバ: c′ = Eval(f, c)）→ verify。証明者が違う点が要。

enc:    c ← Enc(pk, x)                             ユーザが暗号化（中身は秘匿）
eval:   c′ ← Eval(f, c)                            サーバが暗号文のまま f を評価（FHE）
prove₁: π_wf ← ZKProve{ ∃x, r : c = Enc(pk, x; r) ∧ noise 範囲内 }   ユーザ。x を隠す → ZK 必須
prove₂: π_eval ← Prove{ c′ = Eval(f, c) }         サーバ。秘密なし → succinct で十分
verify: Dec(sk, c′) = f(x) かつ Verify(π_wf, π_eval) = ⊤   機密性 + 正しさ を同時に

注（講義が強調した点）: π_eval に zero-knowledge 性は必須ではありません。c, c′, f は公開で、隠す witness が無い。本質は succinctness — 再実行より安く検証できること。SNARK / STARK で十分。ZK が要るのは π_wf（平文 x を隠す）と、サーバがモデル重み等を秘匿する場合。

コスト: FHE の bootstrapping と ZK 証明生成が支配的で重い。回路バグは soundness を壊すので検証が要る（カード 33）。

Week 5 との橋: π_wf の「noise 範囲内」は、Week 5 ドリル A の「ノイズが Δ/2 を超えると復号が壊れる」そのものです。ユーザが正しい範囲のノイズで暗号化したことを、ノイズの値を見せずに証明する。GW①（カード 36・41）の模範解がこれ。

問いは 5 つ。欲しい成果物は「証明」か「計算結果」か？ witness（秘密）は誰が持つ（単独 / 複数者）？ 証明対象は回路か任意プログラムか？ 誰が計算する（複数者で共同 / 第三者に委託）？ その計算の正しさも証明したいか？

欲しいのは証明
  witness は単独 ── 回路      → 回路 DSL（Circom / Noir / halo2）
                 └ 任意プログラム → zkVM（RISC0 / SP1 / Jolt）
  witness は複数者（分散）      → co-SNARK
欲しいのは計算結果
  複数者で共同計算              → MPC
  第三者に委託 ── 正しさは不要  → FHE
             └ 正しさも証明したい → Verifiable FHE

使い方: 上から順に答えるだけで 1 つに決まります。GW①「医療データを見せずに AI 診断、正しさも確認したい」→ 計算結果 → 第三者に委託 → 正しさも → Verifiable FHE。宿題 co-snark-prove → 証明 → 複数者 → co-SNARK。宿題 zkvm-exploit → 証明 → 単独 → 任意プログラム → zkVM。

ZK: Circom + snarkjs（回路 DSL + Groth16 / Plonk、最も普及）。zkVM: RISC0（RISC-V トレースを STARK で証明、Groth16 に変換してオンチェーン検証）。co-SNARK: co-snarks（TACEO、Circom 回路を coSNARK 化、World ID の基盤）。Threshold FHE: threshold-fhe（Zama、TFHE の復号鍵を MPC で分散管理、FHEVM の KMS 基盤）。Verifiable FHE: EagleEye（FHE 演算トレースを Plonk 系制約に変換して証明）。

選定基準: trusted setup の要否 / 言語エコシステム / 想定用途で選ぶ。Groth16 は回路ごとに trusted setup が要るが proof が最小（0.93 KB）。Plonk・STARK 系は setup 不要か汎用だが proof が大きい。カード 32 の実測に続きます。

4 つの観点。パフォーマンス（ZK: prover 重い・verify 軽い／ MPC: 通信ラウンドが支配的／ FHE: bootstrapping が支配的）、セキュリティ（ZK: soundness と zero-knowledge は別物／ MPC: 閾値超の共謀で漏れる／ FHE: 機密性のみ）、プライバシー（メタデータ・タイミング・利用パターン、MPC の出力そのもの、FHE のアクセスパターン）、法律・規制（OFAC 制裁・マネロン規制・GDPR・年齢確認義務）。

soundness と zero-knowledge は別物、がこの節の鍵です。soundness = 偽の主張が通らない。zero-knowledge = 秘密が漏れない。片方だけ壊れることがあり、Zcash（カード 33）で壊れたのは soundness でした。

同じ 3 つの主張（パスポート検証・WebAuthn・OPRF）を、同じ端末で Circom + Groth16 / Noir + Barretenberg / ProveKit v1 の 3 方式に証明させた実測。手元の端末で証明を作ることが現実的なコストに収まりつつある。

教訓: 速くなった代わりに proof が重くなった。手元での証明生成は実用域に入ったが、その proof をオンチェーンで検証するなら 0.93 KB の Groth16 が今も優位。「一番速い方式」は存在せず、証明を誰がどこで検証するかで方式が決まる（カード 14 の設計の含意）。出典は ProveKit チーム自身の計測で、第三者の追試ではない点は講義も注記しています。

halo2 回路の制約漏れ 1 行が soundness を破り、無制限・検出不能な偽造を可能にした（2026 年発覚）。壊れたのは soundness で、zero-knowledge ではない。

- let base = assign_advice(cs, || g_d)?;              // witness するだけ、g_d との一致を制約しない
+ let base = copy_advice(cs, || g_d, g_d_upstream)?;  // g_d と一致することを制約（copy constraint）

何が起きたか: base point が制約なし → 任意の値を witness 可能 → nk を偽造者が自由選択 → ivk = Commit(ak, nk, rivk) を偽造 → 同一 note に複数 nullifier → 無制限偽造 / 二重支払いが検知不能（秘匿取引）。05-29 に Taylor Hornby が AI 支援監査（Claude Opus 4.8）で発見。人手監査は 4 年間見逃していた。06-02 緊急ソフトフォーク、06-03 NU6.2 で回路を修正。

教訓: 回路の制約漏れは 1 行でも致命的。秘匿性ゆえ過去の悪用有無は暗号学的に検証不能。

ドリル C の 9 行目: 偽造者が r2 を持ってきたとき (h(r2) in spent, h(k, r2) == C) は (False, False)。左が False なので使用済み検査は素通り。右が False なのは当然で、偽造者は r2 と C を結ぶつもりがない。回路が「C = h(k, r) を満たす r で nullifier を作った」を要求していればここで止まり、要求していなければ左の False だけで 2 回目が通る。Orchard の assign_advice は「witness を置くだけで結びつきを制約しない」— 同じ形です。

プライバシー技術は、設計・デプロイ・運用する人が規制の対象になりうる。プロトコルと開発者は別々に裁かれている。

2022-08  米 OFAC が Tornado Cash を制裁指定（コントラクトアドレスを SDN リスト化）。蘭で開発者 Pertsev 逮捕
2023-08  米 DOJ が Storm / Semenov を訴追（マネロン共謀・制裁違反・無登録送金業）
2024-05  蘭裁判所が Pertsev をマネロン幇助で有罪、禁錮 5 年 4 か月
2024-11  米第 5 巡回区 Van Loon v. Treasury: 不変のスマートコントラクトは「財産」でなく OFAC は越権 → 2025-03 制裁解除
2025-08  Storm に無登録送金業で有罪評決。マネロン・制裁違反は評決不一致で一部 mistrial
2026-09  Storm は未量刑、不一致の 2 罪状は 2026-10 に再審理予定。Pertsev は条件付き釈放で控訴審係属中

設計上の論点: プロトコルへの制裁は解除され、Tornado Cash の利用自体は違法ではなくなった。一方で開発者個人の刑事責任は今も係争中。コードは中立でも運用主体は問われうる。送金業ライセンス・制裁コンプライアンス・不変コントラクトの法的扱いを、設計段階で織り込む必要がある（2026-09 時点、流動的）。

お題: ユーザが自分の医療データをクラウドの AI に診断させたい。クラウドにも第三者にも生データを見せたくない。さらに「診断が正しく計算された」ことを本人が確認したい。この要件を満たすスタックを設計せよ。

1. 要件を言語化（アクター / 秘匿入力 / 公開出力 / 信頼境界）
2. 各 primitive が何を保証するかを思い出し、要件を満たす組み合わせを自分で選ぶ
3. ユーザーフローを書き出す（誰が → 何を → どの primitive を通り → 境界を越えるのは何か、時系列で）
4. 落とし穴を 1 つ（性能 / soundness / メタデータ / 規制）

Q. 発表（各 1 分）: ユーザーフローを見比べ、「なぜ Verifiable FHE / なぜ MPC / なぜ TEE」を 1 文で説明できるか。

予習でやっておくこと: カード 29 の決定木を上から答える。「欲しいのは計算結果 → 第三者に委託 → 正しさも証明したい」で 1 つに決まります。次に「MPC だとなぜ不利か」「TEE だとなぜ不利か」を、カード 7 の信頼前提の行から 1 文ずつ。

生データを渡さず、診断の正しさまで確認する。Verifiable FHE = FHE + ZK が両方の要件を同時に満たす。

① ユーザ（患者）  医療データ D を FHE 公開鍵で暗号化し Enc(D) だけをクラウドへ。D はローカル
② クラウド AI     暗号文のまま推論 f を評価し Enc(f(D)) を返す。同時に「c に正しく f を評価した」証明 π を生成
③ ユーザ（検証）  Enc(f(D)) を復号して診断結果 + π を検証。データ機密（FHE）と計算の正しさ（ZK）を同時に確認
信頼境界          クラウドは信頼しない。境界を越えるのは Enc(D) と Enc(f(D)) + π だけ

なぜこの組み合わせ: FHE 単体はデータ機密のみで「正しく計算したか」は保証しない → ZK を重ねた Verifiable FHE で埋める。MPC / TEE は信頼前提とコストで不利。

落とし穴: 性能（FHE の bootstrapping が支配的）／ soundness（Verifiable FHE の回路バグ、カード 33）／ メタデータ（誰がいつ診断したかは隠れない、カード 13）／ 規制（医療データ = GDPR・HIPAA、カード 34）。