---
id: 7
title: トラステッドコンピューティング・フレームワーク：ZK・TEE・MPC は検証可能 AI でどう役割を分けるか
slug: trusted-computing-framework
date: 2026/08/12
summary: ゼロ知識証明、信頼実行環境、マルチパーティ計算がそれぞれ何を証明し、何を信頼し、どこにコストを負うのか。そしてそれらが互いを置き換えるのではなく、オンチェーンの決済やコンピュートネットワークとどう組み合わさるのか。関連するエンジニアリング目標の読み方も整理します。
keywords: ゼロ知識証明,TEE,MPC,検証可能AI,Bitroot
heroImage: /images/community-bg.png
---

チェーンは「状態がルールに従って更新されること」を保証できますが、「オフチェーンで行われた行列積がすり替えられていないこと」を自動的に保証するわけではありません。検証可能 AI は、計算を検証可能な境界の内側に置こうとします。ZK、TEE、MPC はしばしば三点セットのスローガンとして語られますが、より有用なのは、それぞれが信頼の根拠を数学・ハードウェア・しきい値の正直さのどこに置くのかを切り分け、学習の受け入れ、低遅延の機密推論、鍵と共同統計のどれに向くのかを見極めることです。

## 問題定義：何を証明するのか

AI ワークロードでは、証明または保護の対象としてよく挙がるものがあります。

- **完全性**：出力が、主張されたモデルと入力から実際に生成された（またはポリシーを満たす）こと。
- **機密性**：入力、重み、中間活性化が実行ノードから見えないこと。
- **可用性**：一部のノードが落ちても署名や復元が成功すること（しきい値方式）。

この三つすべてで最適な技術はほとんどありません。組み合わせが常態です。スタック上の役割分担は[分散型 AI スタック](/ja/blog/aibitrootweb3ai)を参照してください。信頼ギャップの棚卸しは[Web3 と AI の融合](/ja/blog/web3-ai-convergence)です。

## ゼロ知識証明：数学で検証できるが、回路は高コスト

ZK は、検証者がすべての計算を再実行したり秘密の入力を見たりすることなく、命題が真であることを確認できるようにするものです。オンチェーンとの相性が良いのは検証が比較的安価な点（特に SNARK 系）で、難しいのは証明生成と回路設計です。

- **zk-SNARK**：証明が小さく検証が速い。方式によっては信頼されたセットアップが必要で、MPC セレモニーによって単一当事者への信頼を下げられます。
- **zk-STARK**：信頼されたセットアップが不要で、耐量子性の物語に寄り、証明は大きくなり、コスト曲線も異なります。

大規模モデルでは「推論全体の ZK」は依然として非経済的なことが多く、より現実的なのは、重要な制約（コンプライアンス規則、集計統計、モデルハッシュの束縛）を回路化すること、あるいはサンプリング／折り畳み後の計算を証明することです。性能値は回路とアクセラレータに大きく依存するため、普遍的な SLA ではなくエンジニアリング目標として扱ってください。ZK 検証コントラクトを並列 EVM 上で動かすと、決済・検証のスループットは改善しますが、証明生成が魔法のように安くなるわけではありません。

## TEE：境界をハードウェアに沈め、チップとサプライチェーンを信頼する

TEE（SGX、TrustZone、SEV など）は、隔離実行とリモートアテステーションを使い、ユーザーがコードが主張された enclave／セキュアワールドで動いたことを確認できるようにします。遅延に敏感な推論、鍵操作、ZK のコストを全部は払いたくない機密性の用途に向きます。

コストには、性能オーバーヘッド、メモリ／API の制約、サイドチャネル、サプライチェーンリスク、可搬性を損なうベンダーロックインが含まれます。誠実な実践は**最小 TCB**、つまり鍵と機密スライスだけを TEE に入れ、残りは通常環境に置き、チャレンジとログハッシュを組み合わせることです。コンピュートネットワークがどう受け入れを接続するかは[分散 GPU とエッジコンピュート](/ja/blog/gpuai)を参照してください。

リモートアテステーション自体も状態機械に入れる必要があります。有効期限、ベンダーの失効リスト、「誤ったコードを証明してしまった」場合のガバナンスは、TEE バッジを貼ったからといって消えるものではありません。

## MPC：誰も全体の平文を見ずに、当事者が一緒に計算する

MPC（秘密分散など）は、各当事者が入力の全体を明かさずに共同計算できるようにします。典型的な用途は次のとおりです。

- **しきい値鍵**：秘密鍵を分割し、署名を集約し、完全な鍵をどこにも置かない。
- **共同統計／連合的な更新**：生データセットではなく、勾配や集計値を共有する。
- **重み分散推論**：権利設計につながります。[AI 資産の権利](/ja/blog/ai-data-ownership)を参照してください。

通信ラウンドと計算の膨張がコストの大半を占めます。当事者数と敵対者モデル（半正直か悪意か）によって実現可能性は大きく変わります。MPC は「デフォルトで暗号化されたクラウド」ではなく、当事者がデータを集中させることを拒む高価値な場面のための道具です。

## 積み上げるのではなく、組み合わせる

| 必要な性質 | 優先しやすい手段 | 主なコスト |
|-------------------|--------------|-----------|
| 公開検証可能で、検証者が軽量 | ZK | 証明生成と回路 |
| 低遅延の機密推論 | TEE（+ 監査／チャレンジ） | ハードウェア信頼とサイドチャネル |
| 複数当事者の入力を集中させない | MPC | 通信とプロトコル複雑性 |
| 決済と紛争 | オンチェーンコントラクト + 証明／コミットメント | 確定遅延と gas |

チェーン（特に並列 EVM の決済レイヤー）が担うのはジョブの状態機械と支払いであり、上記の暗号技術を置き換えるものではありません。アーキテクチャは[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)を参照してください。軽いジョブと重いジョブのハイブリッドな振り分けは[AI ネイティブ・ブロックチェーン](/ja/blog/ai-native-blockchain)。テストネットでの確認と TPS は決済基盤を説明するもので、読み方は[性能指標の用語集](/ja/blog/performance-metrics-glossary)です。

## 脅威モデルを選定に書き込む

選ぶ前に、敵対者が実行者ノードの OS を制御できるか、証明者を買収できるか、秘密をどれだけの期間保つ必要があるか、検証者のハードウェア予算はいくらかを明らかにします。ホストが掌握され得る一方でリモートアテステーションの偽造が難しい場合、TEE は有効です。長期間の公開再検証には ZK が向きます。当事者が平文を決して共有しないなら、MPC はほぼ避けられません。「エンタープライズ級セキュリティ」を単一のスコアにすると、比較不能な次元が隠れます。エージェントに関するギャップは[Web3 と AI の融合](/ja/blog/web3-ai-convergence)を参照してください。

運用では、誰が証明し、誰が検証するのかも明記する必要があります。実行者による自己証明か、独立した証明市場か、プロトコルが抽選する再計算か。役割が曖昧だと、TEE のアテステーションも ZK 証明も見せかけになります。証明検証トランザクションは決済スループットを消費します。並列 EVM はそれらのトランザクションが追いつくのを助けますが、証明生成の漸近計算量を下げるわけではありません。スタック上の位置づけは[分散型 AI スタック](/ja/blog/aibitrootweb3ai)を参照してください。

回路と enclave のコードにもバージョン管理が必要です。古い証明回路、ローテーションされていない測定値、ベンダーのマイクロコード変更は、昨日通っていた検証パスを今日壊し得ます。バージョンハッシュはジョブのメタデータに入れ、[AI データの所有権](/ja/blog/ai-data-ownership)の成果物バージョン管理と揃えるべきです。

## 脅威モデルは製品ブリーフに書く

同じ ZK／TEE／MPC の組み合わせでも、半正直な敵対者と悪意ある敵対者では意味が変わります。敵対者の能力を書かずに技術名詞だけ並べた資料では、読者は「検証可能」がどれほど強いのか判断できません。少なくとも、実行者が入力を隠せるか、共謀できるか、証明の有効期限と鍵ローテーションをどう扱うか、オンチェーンの紛争ウィンドウを誰が進めるかを明示すべきです。

AI 推論市場では、日常の遅延を TEE や抽選再計算で抑え、高価値の決済にはより強い証明を使い、学習ジョブは勾配ごとの完全な ZK ではなくチェックポイント、冗長性、経済的スラッシングに頼る、という妥協がよくあります。ハイブリッドな振り分けは[AI ネイティブ・ブロックチェーン](/ja/blog/ai-native-blockchain)、決済レイヤーの役割は[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)を参照してください。

## コスト会計：「どれだけ安全か」だけで順位づけしない

選定はしばしばセキュリティのランキングに平坦化されます。より有用なのは、ジョブあたりの証明コスト、遅延のパーセンタイル、失敗時の人手介入コストです。TEE は p50 遅延で勝ってもサプライチェーン監査で負けることがあり、ZK は公開検証性で勝っても証明生成の待ち行列で負けることがあり、MPC はデータを集中させない点で勝っても運用負担で負けることがあります。

これら三つのコストを一つの表に置き、決済の gas と確定遅延を足してから、その AI ワークフローが経済的に反復可能かを判断してください。用語は[性能指標の用語集](/ja/blog/performance-metrics-glossary)、コンピュートのライフサイクルは[分散 GPU とエッジコンピュート](/ja/blog/gpuai)を参照してください。

検証可能 AI が成熟するのは、失敗や紛争に対して、信頼がどこに錨を下ろしているか、証拠がどう提出されるか、オンチェーン状態がどう収束するかに答えられるようになったときです。それらが欠けていれば、フレームワークはスライドのままです。

## 決済レイヤーとのインターフェース契約

証明、アテステーション引用、MPC 署名は最終的にコントラクトが理解できる入力にならなければなりません。どのフィールドをオンチェーンに置くか、どれがコミットメントのみか、検証失敗時にジョブ状態がどう遷移するか、期限切れの証明が自動的に無効化されるかを合意します。インターフェースが曖昧だと、強い暗号技術もアプリ層の「手動確認」で薄められます。並列 EVM はそれらの遷移を高速にしますが、証明そのものを生成するわけではありません。

## まとめ

トラステッドコンピューティング・フレームワークの価値は、AI コンピュートに対して議論可能な完全性と機密性の選択肢を、選択肢ごとの信頼前提を明示したうえで提供することです。銀の弾丸はありません。あるのは脅威モデルに基づく選定だけです。ZK／TEE／MPC を「エンタープライズ向けワンクリックセキュリティ」と書く主張は、次のように言い換えるべきです。つまり、明示された前提のもとで特定のリスクが小さくなる、という主張です。本記事は投資助言ではありません。

## 関連記事

- [分散型 AI スタック](/ja/blog/aibitrootweb3ai)
- [分散 GPU とエッジコンピュート](/ja/blog/gpuai)
- [Web3 と AI の融合](/ja/blog/web3-ai-convergence)
