公開チェーンで機関の取引を隠すには｜ZK・FHE・TEEの選び方と監査人への開示

ある証券会社が、機関投資家どうしの証券トークンの売買を、公開チェーンの上で決済しようとしています。セキュリティ担当のアーキテクトが最初に聞かれたのは、「取引の中身を他社に見られずに済むのか」でした。

公開チェーンで普通にトークンを送ると、次のものが誰にでも見えます。アドレス、トークンのコントラクト、金額、時刻、呼び出した関数、イベントです。氏名を書かなくても、入出金先、よく知られたカストディのアドレス、繰り返しの型、取引の時刻を組み合わせると、どの法人がどこと取引しているかを推測できることがあります。

送る中身（ペイロード）だけを暗号化しても、送り手、呼び出し先、頻度、暗号文の数や大きさは残ります。それだけで、取引があったことや、取引どうしのつながりは見えてしまいます。

では、何から決めればよいのか。まず、残高、取引相手、金額、契約条件を、誰に見せて誰に隠すのかを決めます。そのうえで方式を選びます。ZK、FHE、TEEは、守れる範囲も、信頼する相手も違います。しかも、上で見たとおり、中身を暗号化してもメタデータからは漏れます。鍵の管理、監査への対応、障害からの復旧も、暗号化とは別に残る仕事です。ですから、暗号の方式と、監査・鍵の管理を一緒に比べます。

以下では、このアーキテクトが設計を進める順に見ていきます。読み終えたときに手元に残るのは、次の5つの成果物です。

1. データの項目×見る人ごとの公開範囲の表と、誰から守るかの想定（脅威モデル）
2. 暗号の部品、チェーン外のシステム、鍵、平文を扱う場所を示すデータの流れ図
3. 支出鍵・閲覧鍵・復号鍵・真正性証明の鍵・資格証明の鍵の持ち主、閾値、更新、復旧の台帳
4. ふだんの処理、選択的開示、障害からの復旧の状態機械と冪等ID
5. プライバシー・性能・監査・復旧を含むPoCの受け入れ試験と測定結果

ZKそのものの基本はゼロ知識証明の基礎で解説しています。

誰に、何を見せて、何を隠すか

見せてよい相手は、データの項目ごとに違います。ですから、要件を「取引を非公開にする」と書くだけでは足りません。データの項目と、見る人を掛け合わせた表を作ります。まず、一般の閲覧者と監査人の2者だけを取り出すと、次のようになります。

取引の当事者、基盤の運営者・バリデーターの列を加えた全体の表は、後半の「実装する人向けの詳細」に載せています。

この表は、事業・法務・規制・情報管理の担当者が決めた公開範囲を、技術の言葉に置き換えるための仕様です。置き換える先は、暗号の方式、権限、保存期間、ログ、復旧の手順です。見る目的、対象の項目、期間、承認する人まで決めて、はじめて受け入れ試験に使えます。

誰から守るのかを、先に決める

中身に触れうるのは、チェーンを外から眺める人だけではありません。少なくとも、次の見る人・攻撃する人を分けて考えます。

• 一般の閲覧者・競合：ブロックエクスプローラー、アーカイブノード、分析サービスから、取引の関係やポジションを推測する。
• バリデーター（検証ノード）・シーケンサー（取引の順番を決めるノード）・リレー（中継ノード）：順番付けや実行の途中で、ペイロード、メモリ、経路の情報に触れうる。
• アプリ・基盤の運営者：API、インデクサー、通知、サポート用のツール、ログ、バックアップに平文を残しうる。
• 取引相手：自分の取引に要る以上に、相手の総残高やほかの取引を推測しうる。
• 監査・規制対応の担当者：正当に見る権限を持つ。一方で、範囲の広すぎる閲覧鍵（view key）や記録の残らない検索は、内部不正の入口になる。
• 鍵やハードウェアを乗っ取った人：閲覧鍵・復号鍵、KMS、利用者の端末、TEE、資格証明の発行者を乗っ取り、暗号の外側から平文を得る。

このように、チェーンの外や途中で平文を扱う人もいます。「チェーンの上では暗号化されている」だけを合格の条件にすると、こうした人を見落とします。それぞれについて、見えてよい平文、見えてよいメタデータ、推測されても構わないこと、乗っ取られたときの被害の上限を決めます。

書き方の例は次のとおりです。「バリデーターは金額を見られないが、取引時刻とコントラクトは見える」。「監査担当者は、案件に結び付く90日間の取引だけを復号できる」。暗号の方式を比べるのは、この想定ができてからです。

ZK・FHE・TEE・許可型は、平文がどこにあるかで比べる

Ethereum Foundationの機関向けプライバシー解説も、ZK、FHE、TEE、プライバシーを重視したL2を、別々の部品として整理しています。暗号の「強さ」を1列に並べても選べません。比べるのは次の3点です。誰が平文を持つか。何を確かめられるか。止まったときにどう戻すか。

要点をまとめると、次のとおりです。

向く処理と弱点は、方式ごとに次のとおりです。

• ZK：向くのは、適格性、保有上限、残高が足りることの確認、中身を隠した送付。弱点は、証明を作る時間、回路の更新、公開した入力・タイミング・サイズからの漏れ。
• FHE：向くのは、暗号化した残高の更新、相殺（ネッティング）、上限・リスクの計算。弱点は、計算の重さ、処理が後から返ってくること、KMS・Gatewayの停止、鍵の更新。
• TEE：向くのは、注文の突き合わせ、オークション、複雑な既存のコード、遅れの許されない処理。弱点は、脆弱性への対応、古い状態への巻き戻し、サイドチャネル（消費電力や時間などから中身を推測する攻撃）、運用者の設定、止まりにくさ。
• 許可型・オフチェーン：向くのは、顔の見える当事者どうしの契約・決済、既存業務とのつなぎ込み。弱点は、参加者の追加、データの移し替え、突き合わせ、運営者・接続先の乗っ取り。

NISTのプライバシー強化暗号（Privacy-Enhancing Cryptography）の整理でも、2つは区別されています。ZKは、秘密の答えを明かさずに知っていることを証明する技術。FHEは、入力と出力の平文を知らずに、目的の計算をする技術です。「FHEはZKより高機能」「ZKはFHEより速い」と、一律に順位は付けられません。証明したいのか、秘密の値を使って計算したいのかで、役割が違います。

ZK：証明が正しいのは、回路に書いた条件についてだけ

ZKで「買い手は適格な投資家で、払える残高があり、取引の後も上限の内にある」と証明したとします。すると、氏名、総残高、ほかのポジションをバリデーターに渡さずに、条件を判定できます。

ただし、証明が正しいのは、回路に書いた条件についてだけです。資格証明の発行者、失効の情報、ルールの版、時刻、資産IDを、証明にきちんと結び付けておく必要があります。そうしないと、古い資格や、別の資産の証明を使い回す余地が残ります。二重使用の防ぎ方や、中身を隠した呼び出しからの漏れ方は、後半で詳しく扱います。

FHE：計算できることと、誰が復号できるかを分けて考える

FHEでは、暗号化した残高のまま、足し算・引き算や比較ができます。たとえば、すべての口座を平文に戻さずに、次のことを計算できます。取引の後の残高が0以上か。参加者ごとの上限の内か。相殺した後に必要な資金はいくらか。

気をつけたいのは、復号できる人がどこかにいることです。表のとおり、FHEでは復号鍵を持つKMSがあり、実装によってはその窓口（Gateway）も別にあります。KMSが止まったときに平文で運用を続けると、プライバシーを破ることになります。ですから、そうした手順は用意しません。具体的な構成例は後半で紹介します。

TEE：速さの代わりに、ハードウェアと運用を信頼する

TEEは、CPUなどの隔離された場所で平文を処理し、外には暗号化した結果や、遠くから確かめられる真正性の証明を返します。既存のコードや複雑な注文の突き合わせを、暗号の回路に書き換えずに動かしやすく、遅れの許されない処理に向きます。

一方で、平文は隔離された場所の中にあります。信頼の範囲に入るのは、ハードウェアのベンダー、ファームウェア、真正性の証明の起点、ノードのイメージ、パッチの当て方、巻き戻しの防止、鍵の渡し方です。真正性の証明が通るだけで安全とはしません。次のことを確かめ続けます。

• 承認したコードの計測値（コードの指紋）か
• 脆弱性のある古い版ではないか
• デバッグの出力・ログ・クラッシュダンプに平文が出ていないか

許可型・オフチェーン：配らないことと、暗号化することは別

許可型の台帳（permissioned ledger）では、参加者が分かっていて、関係者だけに取引データを配れます。関係のない参加者には中身を配らないので、すべてのノードが全体の状態を平文で持つ方式とは、漏れる場所が違います。

ただし、許可された参加者のノード、業務のAPI、データベース、バックアップは平文を持ちます。そこでは、運営者の乗っ取り、内部の不正、誤った権限が主なリスクになります。許可型であることは、中身が秘密であることと同じではないのです。チェーンの外で平文を持つ場合も、チェーン上の記録と業務の記録を、同じ取引IDとハッシュで結びます。書き換え、抜け、送り直しを見つけられるようにするためです。

監査人には、必要な範囲だけを期限付きで見せる

監査人や規制対応の担当者は、正当に見る権限を持っています。ですから、機関の取引で必要なのは、「誰にも見えないこと」ではありません。正当な目的を持つ相手に、必要な範囲だけを、後から確かめられる形で見せられることです。

そのために、鍵を分けます。資産を動かせる支出鍵・署名鍵と、見るだけの閲覧鍵・復号鍵です。さらに、すべての履歴を見られる監査人用の鍵を1本だけ作ることは避けます。見せるときの手順は次のとおりです。

1. 依頼を固める：案件の番号、目的、法律や契約の根拠、対象の口座、項目、期間、依頼した人を、署名を付けて保存する。
2. 複数人で承認する：権限の高い復号は、コンプライアンスとセキュリティなど、別々の役割の人がそろって承認する。
3. 案件ごとに見る権利を出す：対象の暗号文を、受け取る人の一時的な公開鍵で暗号化し直す（再暗号化）。または、対象の記録だけを復号した、署名付きの出力を作る。
4. 元のデータとの対応を付ける：どのチェーン・コントラクト・取引・ルールの版・鍵の版から作ったかを出力に入れ、確かめられるようにする。
5. 見たことを記録する：依頼、承認、復号、ダウンロード、失効、再発行を、追記しかできないログに残す。平文の出力には、期限・保管場所・削除の責任者を決める。

閲覧鍵が漏れても、資産を直接動かされることはありません。それでも、顧客との関係、残高、取引の戦略がまとめて流れ出るおそれがあります。

鍵を更新するときのことも決めます。過去の暗号文を古い鍵で読めなくするのか。暗号化し直すのか。決めた期間だけ、保管用のKMSで復号できるようにするのか。退職・委託の終了・事故のときの失効と、災害のときに複数人の鍵を合わせて戻す手順も、同じ設計の対象です。

適格性の確認では、本人確認（KYC）の元データをチェーンに書かずに済みます。資格証明の発行者が署名した属性から、「この地域のルールの版Rを満たす」という証明だけを決済に渡せます。

BIS Innovation HubのProject Mandalaも、ルールを判定する仕組みと証明を作る仕組みを使い、顧客の元データを見せずに、コンプライアンスの証明を支払いの指図に添える形を実証しています。証明は、法務の担当者が決めたルールを実行した結果です。法令の解釈そのものの代わりにはなりません。

DvPで、片方だけ隠すと何が起きるか

冒頭の証券会社の取引に戻ります。ある運用会社が、別の運用会社から証券トークンを買い、ステーブルコインで払うとします。これをDvP（証券と資金の同時受け渡し）で決済します。

証券の側だけを非公開にしたとしましょう。それでも、同じ時刻に公開の資金の送付があり、特徴のある金額で、同じリレーを通っていたら、相手が誰かを推測できることがあります。逆に、資金の側だけを隠しても同じです。

同時に受け渡す仕組み（原子性）の設計は、証券とステーブルコインのアトミックDvP設計で扱っています。プライバシーの面では、両方の側と業務のメッセージを、同じ脅威モデルで評価します。

同じ機密の実行環境で両方を処理する場合は、次のような流れにできます。

1. 取引ID、資産ID、ルールの版、期限を確定し、外へ出す項目を固める。
2. 売り手は証券の残高と移す権限を、買い手は資金の残高を、中身を見せずに示す。証明か、暗号化したままの条件判定を使う。
3. 両者の適格性の証明と失効の状態を、同じ取引に結び付ける。
4. コントラクトは両方を1回だけ更新し、外には最小限の確定情報だけを出す。
5. 当事者には、自分の前後の状態と相手の受領の記録だけを渡す。監査の案件には、両方を結ぶ署名付きの閲覧データを渡す。
6. 約定、カストディ、会計のシステムには、同じ取引IDとチェーン上の証明を渡す。平文を含む補助の帳簿の権限と保存期間は、別に管理する。

別々の台帳で片方ずつ処理する場合は、台帳をまたぐ証明や、調整役のメッセージそのものが、つながりの手がかりになります。推測を弱める手はあります。金額の埋め草、一定の時間ごとのまとめ処理、使い捨てのアドレス、リレーの分散です。ただし、どれも遅れ・資金繰り・突き合わせの手間を増やします。

参加者の少ない機関の市場では、暗号の方式よりも、参加者の数や特徴のある金額から推測されることがあります。実際のデータの分布を使って、攻撃の試験をします。

鍵・証明・KMSが止まったら、決済の障害として扱う

証明の作成やKMSが止まると、決済そのものが先に進めなくなります。そこで平文に切り替えて続ければ、プライバシーが破れます。ですから、プライバシーの部品が止まることを「表示の機能が止まった」程度には扱わず、決済の状態の管理に組み込みます。止まったからといって、平文に切り替えて決済を続けることはしません。

ほかにも、してはいけないことがあります。

• 証明の作成が時間切れになっても、別のIDで同じ移転を作り直す
• 閲覧鍵が漏れても、支出鍵は無事だからと、ふだんどおり運用を続ける
• 開示の出力とチェーンが合わないとき、手作業で数字を直して出す

証明や復号の結果を返す知らせが途切れても、相手の側では処理が済んでいるかもしれません。ですから、失敗と決めつけません。取引の番号、暗号文、証明、鍵の版、チェーン上の取引を突き合わせます。やり直すときは同じIDを使い、二重の移転と二重の開示を防ぎます。障害ごとの最初の対応と、戻す条件は後半の表にまとめています。

PoCでは、漏れと復旧を試す

PoCで確かめるのは、ふだんの処理の件数ではありません。漏れないか、止まっても戻れるかです。試験は4つのまとまりに分けられます。

漏れの試験

• 公開範囲：一般ノード、バリデーター、シーケンサー、インデクサー、運営者、取引相手、監査人の役割ごとに、見える項目とメタデータが表のとおりか確かめる。
• 不正な証明：残高不足、期限切れの資格証明、別の資産、古いルール、書き換えた公開の入力、使い回した証明をすべて断る。
• 結び付け：特徴のある金額、同じ時刻、ガス代を払った人、リレー、入出金、暗号文の数から取引相手を推測できるかを、実際の分布で測る。
• データの残りかす：アプリのログ、APM（アプリの性能監視の仕組み）、待ち行列、処理できなかったメッセージの置き場、ブラウザの保存領域、サポート画面、バックアップ、クラッシュダンプに平文が残らないか確かめる。

性能の試験

• 平均の処理件数（TPS）だけでなく、証明の作成時間のp95・p99（95％・99％の処理が収まる時間）、FHEの待ち行列、復号の結果が返るまでの時間、TEEの切り替え、決済完了までの時間を測る。

鍵の試験

• 鍵の一生：発行、HSM（鍵を守る専用の機器）・KMSでの保管、閾値の変更、更新、失効、バックアップからの復元、退職した人の削除、過去の記録をもう一度見せることを試す。
• 開示の手順：架空の監査案件で、依頼、2人の承認、期間を限った閲覧、ダウンロード、失効、監査ログまでを、別々の担当者が行う。

障害と更新の試験

• 障害を起こす：証明のサービス、KMSのメンバー、Gateway、TEEのノード、インデクサーを各段階で止め、平文への切り替えや二重の移転なしに戻れるか確かめる。
• 更新：回路、コントラクト、KMS、TEEのイメージ、資格証明のルールを更新し、決済が済んでいない取引と古い暗号文を安全に扱えるか確かめる。

方式ごとの性能は、回路、安全性の設定、ハードウェア、まとめ処理、ネットワーク、コントラクトで変わります。公開されたベンチマークのTPSを、そのまま採用の条件にはしません。自社の取引の分布、開示の頻度、障害の条件で測ります。

ZK、FHE、TEEを同じ処理に重ねると、部品と鍵が増え、止まりにくさ・監査・復旧で気にかける場所も増えます。重ねるほど安全になる、とは限りません。

日本では、どんな検討が進んでいるか

日本の検討でも、「公開しないこと」と「必要な開示」をどう両立させるかが論点になっています。

日本銀行CBDCフォーラムWG4の2025年のディスカッションペーパーは、ふつうのブロックチェーンの送付では、送金の情報を不特定多数が見られるという課題を挙げています。そのうえで、Encrypted ERCの例を紹介しています。残高・送金額を暗号化し、取引の当事者のほかに監査人が履歴を復号できる仕組みです。

金融庁の国際共同研究の報告も、金融分野のトークン化で、プライバシー・銀行秘密のリスクを減らす策を挙げています。ZKなどのプライバシー技術と、許可型ブロックチェーンのアクセス制御です。

ただし、必要な開示と管理は、対象の資産、顧客、業務、保存期間、監督・監査、委託、国をまたぐ移転などで変わります。これらの資料も、特定の構成が国内のすべての業務に合うと保証するものではありません。

法務・規制の担当者が決めた方針を、ルールの版、資格証明、証明する条件、閲覧の範囲、監査ログ、保存期間に組み込みます。方針が変わったら、試験し直せるようにしておきます。

判断を5つの成果物に残す

方式を選ぶ会議の資料だけで終わらせず、冒頭に挙げた5つの成果物を版を付けて管理します。個別の製品を比べるときも、この5点に答えられるかで評価します。

許可型か公開型か、ZKかFHEか、という一問一答では決まりません。最小限だけ公開するデータ、残る信頼、必要な性能、障害のときの業務の続け方を、1つの設計として合わせます。

実装する人向けの詳細

ここからは、この証券会社で仕組みを作るアーキテクトと、セキュリティ・運用の担当者向けの詳しい話です。

公開範囲の表（全体）

方式ごとの鍵と、信頼の範囲

• ZK：資格証明、証明鍵、非公開状態の閲覧鍵・支出鍵を分ける。
• FHE：閾値型KMS（決められた数以上のノードが協力しないと復号できないKMS）、暗号文のアクセス制御リスト（ACL）、復号・再暗号化の承認。
• TEE：隔離領域への鍵の供給、コードの計測値、更新・失効。
• 許可型・オフチェーン：参加者の識別、チャネル・契約の閲覧者、APIの権限。

ZK：公開入力の結び付けと、ヌリファイア

資格証明の発行者、失効情報、ルールの版、時刻、資産IDは、公開入力（証明と一緒に公開する値）かコミットメント（値を隠したまま固定しておく印）に結び付けます。

非公開の状態を持つ方式では、コミットメントやノートを作り、使うときにヌリファイア（nullifier）を公開して二重使用を防ぐ構成があります。Aztecの非公開状態のドキュメントも、ノートの生成・暗号化・配信・発見と、ヌリファイアの調整が必要だと説明しています。

非公開の呼び出しでも、情報は漏れえます。公開関数へのつながり、副作用の数、タイミング、埋め草（パディング）の不足からです。証明がゼロ知識であることだけで、アプリ全体が結び付けられないとは判断しません。

FHE：fhEVMの構成と、レビューの範囲

現行の具体例として、Zamaの公式fhEVMリポジトリの構成があります。チェーン上のコントラクトが暗号化された状態とアクセス制御を持ち、重いFHEの処理をコプロセッサに任せ、Gatewayと閾値型KMSが復号を担います。

そのため設計レビューでは、コントラクトだけでなく次を範囲に入れます。暗号文のアクセス制御リスト、コプロセッサの結果の完全性、KMSの閾値、Gatewayのタイムアウト、復号の要求の承認・監査です。

TEE：機密EVMの例

Oasis Sapphireのドキュメントは、暗号化されたコントラクトの状態と、端から端まで暗号化された取引・呼び出しを持つ機密EVMの例を示しています。

許可型：部分取引だけを配る例

Canton Protocolの公式仕様の案内は、当事者が自分に関係する部分取引だけを見て、シーケンサーやメディエーターは取引の中身を読めない構成を示しています。チェーン外の平文とチェーン上のコミットメントは、同じtransaction_idとハッシュで結びます。

選択的開示とDvPで使うID

開示の依頼はcase_idで管理します。出力には、chain ID、コントラクト、トランザクションハッシュ、コミットメント、ルールの版、鍵の版を含めます。DvPの流れはtrade_idで結び、外へはコミットメント、ヌリファイア、成否、必要最小限の確定情報だけを出します。

障害ごとの初動と復旧の条件

証明や復号のコールバックの応答が失われたときは、privacy_operation_id、trade_id、暗号文のハンドル、証明のハッシュ、鍵の版、チェーン上のトランザクションを照合します。冪等IDは、同じ要求を何度送っても1回分しか処理されないようにする識別子です。

関連する記事

許可型のZK L2という個別の選択肢はzkSync Prividiumの解説、証券トークンの適格性と管理権限はERC-3643の実装設計、証券と資金の同時受け渡しは証券とステーブルコインのアトミックDvP設計で補足しています。オンチェーン金融の全体像はオンチェーン金融の解説、ZKの基本はゼロ知識証明の基礎が入り口です。

XTELAができること

私たちは、取引とデータの流れの整理から、公開範囲の表と脅威モデル、ZK・FHE・TEE・許可型の構成の比較、鍵と権限、選択的開示の手順、状態機械、監視と障害注入までを、PoCとして設計・開発します。貴社の実際の取引の分布で、推測されやすさと性能を測るところまで一緒に進めます。開示の範囲や保存期間の法的な判断は弁護士と連携して進めます。オンチェーンの機関取引のプライバシー要件とPoCの設計を相談したい場合はお問い合わせください。

主要参考資料

• Ethereum Foundation: Blockchain Privacy & Compliance for Institutions
• NIST: Privacy-Enhancing Cryptography
• NIST: Fully-Homomorphic Encryption
• Zama: FHEVM official repository
• Aztec: Private State Variables
• Aztec: Account Keys
• Oasis: Sapphire vs Ethereum
• Canton Network: Canton Protocol Specification
• BIS Innovation Hub: Project Mandala
• 日本銀行CBDCフォーラムWG4: ブロックチェーン取引のプライバシー保護
• 金融庁: 金融セクターにおけるトークン化の進展

資料の確認日と注意

公開された一次情報は2026年8月13日に確認しました。内容は、その時点の情報にもとづく一般的な技術設計の解説です。各方式の実装と成熟度は更新されていきます。個別の業務の法的な分類や、開示・保存の義務はここでは判断できません。本番の設計では最新の仕様を確かめたうえで、法務を含む担当者で公開範囲と受け入れ条件を確定してください。