ZKP、MPC、FHE 如何從「學習」走向「實作」：參加 Advanced Cryptography Program 2026 看高功能密碼實作的難點
ZKP・MPC・FHEを「学ぶ」から「作る」へ ――Advanced Cryptography Program 2026に参加して見えた、高機能暗号実装の難しさ
Advanced Cryptography Program 2026 透過為期 7 週的課程、工作坊及成果製作，帶領參加者從學習 ZKP、MPC、FHE 走向實際實作。課程涵蓋 Shamir 秘密分享、zkSNARK 相關數學、FHE 及多種密碼技術的組合應用，並以工作坊探討如何設計和檢驗證明。Demo Day 有 21 名登台者發表成果。
ゼロ知識証明（Zero-Knowledge Proof：ZKP）、マルチパーティ計算（Multi-Party Computation：MPC）、完全準同型暗号（Fully Homomorphic Encryption：FHE）――。
プライバシー保護や暗号資産・ブロックチェーン開発をはじめ、近年はこうした高機能暗号を応用する研究や開発が活発になっています。
筆者もこれまで、Ethereumを中心に応用が進むZKPや、FHEなどの高機能暗号について取材・記事執筆を続けてきました。例えばZKPについては、秘匿したい情報そのものを相手へ明かすことなく、その情報に関係する特定の主張が正しいことを証明できる暗号技術として紹介してきました。またEthereumでは、プライバシー保護だけでなく、zkRollupなどのスケーリング技術にもZKPが応用されています。
しかし、こうした技術について「何ができるのか」を理解することと、自分でコードを書き、実際のシステムへ組み込むことには違いがあります。
2026年夏、筆者は東京大学ブロックチェーンイノベーション寄附講座「暗号×ブロックチェーンSG」の一環として開催された「Advanced Cryptography Program 2026」に参加しました。
本プログラムは、8月1日にWeek1であるProgrammable Cryptoから始まり、MPC、ZKP、FHE、Advanced Topicsへと進み、最終週のDemo Dayで成果物を発表する7週間の構成です。主催者による募集時の案内でも、数学的な基礎や暗号理論を学ぶだけでなく、実装まで進めるプログラムとして説明されています。
講義の一部は、Merkle JapanのYouTubeチャンネルでも順次公開されており、本稿執筆時点ではWeek2〜4の講義動画を視聴できます。
本稿では、各週の講義やワークショップ、そして筆者自身がDemo Dayへ向けて成果物を制作した過程を振り返りながら、高機能暗号を「知る」段階から「使う」段階へ進むと、どのような課題が見えてくるのかを紹介します。
ZKP・MPC・FHEを「Programmable Cryptography」として学ぶ
Week1：高機能暗号をプログラミングで扱う
Week1では、プログラム全体の導入として、ZKP、MPC、FHEなどを「Programmable Cryptography」という枠組みで捉え、今後学んでいく技術全体の見取り図が示されました。
初回の講義では数式やアルゴリズムそのものは扱わず、ZKP、MPC、FHEといった高機能暗号をプログラミングによって扱えるエンジニアを育成するという、本プログラムの目的や方向性が中心に説明されました。
以降は、それぞれの暗号技術について、講義だけでなくワークショップや実装課題も交えながら学習を進めていきます。
Week2：MPCとShamir秘密分散
Week2のテーマはMPCです。
MPCとは、複数の参加者がそれぞれ保持する秘密情報を互いに公開することなく、共同で計算を行うための技術です。
講義では秘密分散も扱われ、その1つとしてShamirの秘密分散法が紹介されました。
Shamir秘密分散では、secret（秘密にしたい値）を多項式の切片 q(0) に置き、各partyにはshare（各参加者に配る、多項式上の点に対応する分散片）を渡します。次数 k−1 の多項式であれば、k個のshareが集まることでsecretを復元できますが、k−1個以下では多項式を一意に決めることができません。
例えば「3-of-5」であれば、5人へshareを配布し、そのうち3人分が集まった場合にsecretを復元できる、ということになります。
Week3：zkSNARKを理解するための数学とSchnorr
Week3では、zkSNARKを理解するための道具立てとして、有限体、多項式、楕円曲線・離散対数、commitmentなどを順番に取り上げました。
まず有限体では、例えば7を法とする
𝔽7={0,1,2,3,4,5,6}
のような「余りの世界」での計算から始まります。素数を法とする有限体では、0以外の値について逆元が存在するため、割り算も扱えることが説明されています。
さらに楕円曲線では、曲線上の点に対して「足し算」を定義し、点を繰り返し加算するスカラー倍と、その結果から元のスカラーを求めることが困難である離散対数問題へ進みます。
その後に扱われたのがSchnorrの対話型プロトコルです。
Schnorrでは、prover（証明者）が秘密 x をverifier（検証者）へ直接渡すことなく、
y=gx
となる x を知っていることを証明します。以降、本稿ではproverを「証明者」、verifierを「検証者」と表記します。
さらにFiat–Shamir変換では、検証者がランダムに生成していたchallengeをhashから生成することで、対話を必要としないproofへ変換していきます。Week3の教材では、SchnorrにFiat–Shamir変換を適用した非対話版まで具体的に説明されています。
Week4：「証明」と「ゼロ知識性」を分けて考える
Week4では、さらに「証明とは何か」「ゼロ知識性とは何か」を分けて考えます。
完全性（Completeness）や健全性（Soundness）といった証明システムが満たすべき性質を整理し、GKR、STARK、PLONKなどの証明スキームを取り上げた後、それぞれへゼロ知識性を追加する方法へ進みました。
教材のまとめでは、「ゼロ知識証明 := 証明 + ゼロ知識性」と整理されています。
この整理は、これまで筆者がZKPを取材してきた際の理解を、もう一段掘り下げる内容でもありました。
ZKPは一般的に、秘匿したい情報そのものを検証者へ明かさずに、その情報に関連する特定の主張が正しいことを証明できる技術として紹介されます。そのため、「情報を秘匿するための技術」と捉えられることも少なくありません。
しかし、ZKPの利用目的が常にプライバシー保護にあるわけではありません。
例えばEthereumでは、ZKPは以前からプライバシー保護技術として研究されてきましたが、現在はzkRollupなど、トランザクション処理が正しく行われたことを効率的に検証するスケーリング技術にも応用されています。筆者も過去の記事で、この点を取り上げています。
Week4の講演でも、まず証明システムそのものを扱い、その後に「証明スキームのゼロ知識化」が説明されています。
つまり「正しい計算が行われたことを証明する」という機能と、その証明の過程で「必要以上の情報を検証者へ明らかにしない」というゼロ知識性は、分けて整理されています。
なおWeek4の終盤では、同じ系統の証明方式でも実装によって構成が異なる例として、GKR系のVirgo／LibraやJolt、STARK系のRedshift、PLONK系のHalo2やPlonky2／Plonky3なども紹介されています。
ただし、これらは「ゼロ知識性を利用しないプロダクト」の例として紹介されたものではありません。講義では別途、ZKPを利用していると説明されるプロダクトでも、利用目的によっては秘匿そのものより「証明」の機能が中心となる場合がある、という趣旨の説明がありました。
暗号資産やブロックチェーン関連のプロダクトでは、「ZKPを利用している」と説明されていても、その使われ方は一様ではありません。秘密情報を明かさずに証明するというゼロ知識性まで含めて利用する場合もあれば、計算や状態が正しいことを検証するためのProofとしての役割が中心となる場合もあります。
そのため、ZKPを採用しているという情報だけでなく、そのプロダクトで「何を証明しているのか」「どの情報を秘匿する必要があるのか」まで確認することで、ZKPが実際にどのような目的で使われているのかを把握しやすくなります。
Week5：FHEで「暗号化したまま計算する」
Week5ではFHEがテーマとなりました。
FHEとは、暗号化されたデータを復号することなく、そのまま計算できる暗号技術です。筆者も過去の記事で、FHEを含む準同型暗号について「暗号化したデータを復号しないままデータ分析などの処理に利用できる暗号方式」として紹介しました。
公開されているカリキュラムでは、Week5で格子暗号やLWE問題などを扱い、FHEの仕組みへ進む構成とされています。
ここまでのプログラムでは、MPCでは「複数者が秘密を公開せずに共同計算する」、ZKPでは「主張や計算の正しさを証明する」、FHEでは「データを暗号化したまま計算する」という、それぞれ異なる性質を持つ高機能暗号を扱ってきたことになります。
Week6：高機能暗号を組み合わせた実装事例を見る
Week6では、これらの暗号技術が実際のサービスやプロダクトへどのように組み込まれているのか、さまざまな事例が紹介されました。
公開カリキュラム上でも、Week6はvFHEやzkVMなどを扱う「Advanced Topics」と位置付けられています。
Week6の講義では、ZKP、MPC、FHEをそれぞれ独立した技術として見るだけでなく、単独では不足する性質を別の暗号技術で補う構成も取り上げられました。例えば、FHEによる秘匿計算に計算の正しさを検証する仕組みを加えるVerifiable FHE、MPCとZKを組み合わせるco-SNARK、プログラムの実行結果を証明するzkVMなどです。
ここからは、一つの暗号技術だけを理解するというより、それぞれ異なる性質を持つ暗号技術をどのような場面で使い分け、必要に応じて組み合わせるのか、という観点が重要になっていきます。
講義後のワークショップで暗号技術の使い方を考える
本プログラムでは、各週の講義後に、受講生同士でチームを組んでワークショップを行う時間も設けられていました。
講義で学んだ暗号技術を題材に、「この技術を使って何を実現できるのか」「実際のサービスへ組み込む場合にはどのような構成になるのか」などを、他の受講者と相談しながら考えていきます。
単に講義内容を復習するだけではなく、自分たちで仕組みを考えたり、別のチームが考えた方法の問題点を探したりする点も特徴的でした。
数独を使って完全性・健全性・ゼロ知識性を確認する
Week3のワークショップでは、数独を題材にZKPの性質を考えました。
講義で学んだ完全性、健全性、ゼロ知識性を、数字を書いたカードなどを使ったゲームとして確認します。教材でも「グループワーク」として数独を用いた課題が示されています。
数独を正しく解いた証明者が、完成した数独の答えそのものを検証者へすべて明かすことなく、「ルールに従って正しく解いている」ことを納得してもらうには、どのような手順にすればよいのか。チームごとに証明方法を考えました。
さらに、各チームが証明方法を作るだけでワークショップは終わりません。
別のチームが考えた証明方法について、「不正な答えでも検証を通過できないか」「カードの見せ方などから数独の答えを推測できないか」といった抜け穴を探す対戦も行われました。
証明方法を設計する側だけではなく、それを破ろうとする側にも回ることで、「正しい解であれば検証を通過できるか」「不正な解を受理してしまう余地はないか」「検証によって必要以上の情報が漏れないか」といった観点を実際に確認できます。
講義で学んだ完全性、健全性、ゼロ知識性を、証明プロトコルを設計・検証する際の条件として確認できるワークショップになっていました。
AIエージェントを題材に「ZK, or not ZK」を考える
Week4の最後には、「ZK, or not ZK」と題したワークショップが行われました。
教材ではケーススタディとして、AIエージェントの運用実績を、顧客データなどの機密情報を渡すことなく、外部の保険会社へ証明するシステムを設計する課題が示されています。
検討事項としては、運用実績をどのような指標で測るのか、その実績をどのように証明するのか、機密データをどう秘匿するのか、誰や何を信頼するのかというトラストモデルなどが挙げられていました。
実際のワークショップでは、各チームで具体的なケースを考えながら議論します。
筆者のチームでは、予約代行を行うAIエージェントを題材にしました。ただし、限られた時間の中で、何を実績として扱い、何を保険会社へ証明し、どのデータを秘匿するのかを、一つの構成へ整理するのは簡単ではありませんでした。
前述したように、ZKPでは「証明」と「ゼロ知識性」を分けて考えることができます。
そのため、具体的なシステムを考える際には、まず何を証明する必要があるのかを整理し、その証明に用いる情報のうち、どこまでを検証者へ見せる必要があるのかを検討します。
このワークショップは、講義で扱った「証明」と「ゼロ知識性」の違いを、具体的なサービスを題材に考える機会にもなりました。
Verifiable FHEで「秘匿」と「検証」を組み合わせる
Week6では、複数の高機能暗号を組み合わせる例の一つとして、Verifiable FHE（vFHE）も取り上げられました。
FHEでは、データを暗号化した状態のまま計算できます。
一方、ユーザーから見れば、計算対象のデータをサーバーへ秘匿できたとしても、サーバーが本当に指定された計算を実行したのかという別の問題が残ります。
例えば、ユーザーが持つデータを x、暗号化を E、実行したい処理を F とすれば、
E(x)
をサーバーへ渡し、FHEによって
E(F(x))
を計算してもらうことが考えられます。
しかし、結果が暗号化されているだけでは、サーバーが本当に F を適用したのか、別の処理へ差し替えていないのかをユーザー側から確認するという課題が残ります。
Verifiable FHEでは、こうしたFHEによる秘匿計算と、計算の正しさを検証するProofを組み合わせることを考えます。
この講義内容を踏まえ、ワークショップで筆者のチームは、Verifiable FHEを利用したAI診断サービスを検討しました。
想定したのは、医療データのような機微な情報をユーザー側で暗号化し、クラウド上のAIサービスで処理する構成です。
FHEによって医療データそのものをサーバーへ見せることなくAIモデルを実行し、さらにProofを付加することで、ユーザーが「指定した処理が行われたこと」も検証できないかを議論しました。
データを秘匿したまま計算することと、その計算が正しかったことを証明することは別の問題です。用途に応じて複数の高機能暗号を組み合わせるという考え方を、具体的なサービスに当てはめて検討する機会になりました。
暗号技術だけでは「入力データが正しい」とは証明できない
ワークショップを通じてもう一つ考えることになったのが、暗号技術で保証できる範囲です。
ZKPでは、ある計算や主張が条件を満たしていることをProofによって検証できます。MPCでは、複数者が秘密を直接公開することなく共同計算できます。FHEでは、暗号化されたデータを復号せずに計算できます。
一方、これらの暗号技術を利用しても、「入力として使ったデータ自体が現実世界の事実を正しく記録している」ことまで自動的に証明できるわけではありません。
例えば、企業システムで生成されたログを使ってZKPを生成するとします。
Proofによって、「入力されたログに対して決められた計算を正しく行った」ことを確認できたとしても、Proofを作る前に都合の悪いログが削除されていれば、そもそもの入力が現実の状態を正確に表していない可能性があります。
そのため、実際のサービスでは高機能暗号だけでなく、ログ生成元の電子署名、改ざんを困難にする保存基盤、外部タイムスタンプ、アクセス制御など、周辺の仕組みも含めて設計する必要があります。つまり、暗号方式そのものだけでなく、「誰を、何を信頼するシステムなのか」というトラストモデルも考える必要があります。
こうした点を講義やワークショップで考えていく中で、筆者は「記録の内容を秘匿しながら、後から改ざんされていないことを確認し、必要な場合だけ複数者の承認によって開示する仕組み」を題材にできないかと考えるようになりました。この問題意識が、最終週のDemo Dayで制作した企業監査データ保全PoCの着想にもつながりました。
Demo Dayで企業監査データ保全のPoCを作る
プログラムの最後にはDemo Dayが行われ、受講生がそれまでの講義や学習をもとに制作した成果物を発表しました。
筆者がテーマとして選んだのは、企業の監査データ保全です。
企業の内部監査や内部調査で扱うログには、いくつかの相反する要求があります。
後から改ざんされていないことを確認できる必要がある一方で、個人情報や調査対象者に関する情報を、誰でも自由に閲覧できる状態にはできません。
また、一人の管理者だけが秘匿データを開示できる仕組みにすると、その管理者による内部不正や隠蔽への耐性という別の問題も生じます。
そこで作成したのが、企業監査データ保全のPoC「AuditGuard」です。
Week2で扱ったShamir秘密分散、Week3で扱ったHash／Merkle commitment、Schnorr型Proof of Knowledge、Fiat–Shamirなどを組み合わせました。
デモでは、まず複数の架空監査ログをhash化し、Merkle treeによって1つのMerkle rootへまとめます。保存後にログの内容を書き換えると、元のMerkle rootとの検証に失敗するため、改ざんを検出できます。
また、監査データを開くためのrelease keyをShamir秘密分散によって5つのshareへ分割し、そのうち3つが集まった場合に復元できる3-of-5の構成にしました。
さらに、各shareについてSchnorr型Proof of Knowledgeを使い、対応するshareを知っていることを簡易的に検証しています。
ただし、これは学習内容を確認するためのPoCであり、実際の企業データを保護できる完成した製品ではありません。
監査データの暗号化には簡易的な自作処理を利用しており、ShamirやSchnorrも小さなパラメータで動作を確認できるようにしています。
また、実際に3人の承認者がそれぞれ別の端末から操作するのではなく、Pythonプログラム内でP1、P3、P5という3者が承認した状態を模擬し、3つのshareを同一プロセスへ集めてrelease keyを復元しています。
実運用を考えるのであれば、暗号化方式、threshold cryptography、proof system、鍵管理、監査ログの保存基盤などを、実用的な実装へ置き換える必要があります。
成果物を作る過程では、講義で個別に学んだ技術を、一つのシステムの中でどのような役割に割り当てるのかを考えることになりました。Merkle commitmentは何を固定するために使うのか、Shamir秘密分散によるshareは誰が持つのか、Schnorrでは何を証明するのかといった点を整理することで、それぞれの技術の役割も具体的になりました。
高機能暗号を「使う」ために必要だったこと
今回のプログラムで特に難しかったのは、それぞれの暗号技術の特徴を知ることよりも、実際の問題にどう当てはめるかを考えることでした。
同じZKPでも、秘匿したい情報や証明したい内容によって使い方は変わります。MPCやFHEについても同様で、何を秘密にし、誰と計算し、どこまで検証したいのかによって必要な構成は異なります。
講義やワークショップ、Demo Dayでの成果物制作を通じて、「この技術を使っている」という説明だけでなく、「その技術によって何を解決しているのか」を確認する必要があることを、あらためて意識するようになりました。
「わからないこと」を具体的にする学習へ
Advanced Cryptography Program 2026を終えたからといって、ZKP、MPC、FHEを自由に設計・実装できるようになったわけではありません。
有限体や楕円曲線などの数学、ZKのProof Systemごとの違い、MPCやthreshold cryptographyのセキュリティモデル、FHEの各方式や実装など、理解を深める必要がある分野は数多くあります。
一方で、今回のプログラムを通じて、今後どのような知識を学ぶ必要があるのかは以前より具体的になりました。
筆者は以前の記事でも、高機能暗号を理解するためには、多項式、有限体、楕円曲線、ペアリング、合同算術などの数学的知識が重要であることを取り上げています。
今回のプログラムでは、そのような数学を講義で確認するだけでなく、小さな実装を動かし、ワークショップで他の参加者とシステム構成を考え、最後には自分でもPoCを作成しました。
これまで個別の「高度な暗号技術」として見ていたZKP、MPC、FHEを、どの問題に、どの性質を使うのかという観点から考える機会になりました。
Advanced Cryptography Program 2026のDemo Dayは7週間の一区切りとなりました。
筆者としても、ここで暗号技術の学習を終えるのではなく、今回見つかった理解不足を一つずつ補いながら、引き続き高機能暗号の開発動向を追っていきたいと考えています。
來源：gihyo.jp · gihyo.jp