Ethereum zkAPIは本当に匿名？2026年10月19日時点の仕組み・稼働状況

Ethereum zkAPIは、AIへの質問内容を誰にも見えなくする仕組みではありません。中心となる機能は、ETHなどの預入・支払い主体と、個々のAPI利用との結び付きを弱めることです。

2026年10月19日時点の結論：2026年10月1日にmainnet利用可能と発表された旧稼働版は、版と退出手順を照合できた場合に限って少額で試す対象です。一方、concession exitを含むrevision 3は、本番鍵・新vault・外部レビュー・本番展開が未完了とされる開発版であり、一般利用の資金は入れません。

「匿名AI」とだけ理解すると、実際には見える情報を見落とします。本記事では、預入から精算、出金までをたどり、自分が隠したい情報にzkAPIが合うかを判断できるように整理します。検証日：2026年10月19日。更新時は稼働版、対象commit、本番配備、監査範囲を一次資料で再検証します。

Ethereum zkAPIとは何か

Ethereum FoundationとOpen Anonymityが発表した仕組み

zkAPIは、Ethereum FoundationがOpen Anonymityと構築し、2026年10月1日に発表したAPI利用のための支払いプライバシー技術です。利用者が資金を預け、その残高を使う権利があることをゼロ知識証明で示し、短時間だけ使えるAPIキーを受け取る流れを採ります。対象例としてAI APIが分かりやすく示されていますが、発想自体は利用量に応じて課金するAPIへ広げられます。

ここでEthereumの役割は、AIモデルを動かすことではありません。預入を記録し、退出を処理するvaultと呼ばれるスマートコントラクトの基盤になることです。APIの認可や利用量の精算にはサーバーが関わり、実際の推論はOpenRouterなどの推論事業者が担います。一つの主体がすべてを処理するサービスではなく、端末、zkAPIサーバー、推論事業者、Ethereum上のvaultが役割を分担します。

ETHを預けてAPI利用クレジットを得る基本像

利用者はまずvaultへETHを預け、端末内にprivate noteと呼ばれる秘密情報を保持します。このnoteをそのままサーバーへ渡すのではなく、正当な預入に基づく残高を持ち、今回の上限額を支払えることを証明します。サーバーは証明を検証し、利用上限のある短期APIキーを発行します。API利用後は実使用量に応じた精算が行われ、残高の新しい状態が作られます。

「クレジット」は銀行預金や価格の安定したポイントを意味しません。現行開発版の記帳単位はnative ETHのgwei整数で、ドル表示は参考値です。ETH価格が変われば法定通貨換算の価値も変わり得ます。資金を置く以上、プライバシーだけでなく価格変動、ガス代、出金可能性も判断材料になります。

zkAPIが匿名化するのは支払いと利用の紐付け

預入元と個々のAPIリクエストを切り離す

通常の有料APIでは、アカウント、決済情報、長期APIキー、利用履歴が同じ顧客記録へ集まりやすくなります。zkAPIは、一度の預入で得た秘密状態から利用ごとの証明を作り、預入トランザクションを毎回のAPIリクエストへ直接提示しない設計です。サーバーは、利用者の氏名や元のnoteを知る代わりに、条件を満たす有効な証明かを確認します。

この性質を「unlinkability（リンク困難性）」として捉えると誤解が減ります。支払える正当な利用者だと検証しつつ、どの預入noteに由来するかを認可のたびに明かさないことが目標です。ただし、同じ接続元や特徴的な利用パターンが繰り返されれば、別の観測情報から同一人物らしいと推測される余地は残ります。

プロンプトや応答そのものを暗号化する仕組みではない

短期キーを受け取った後、利用者は推論事業者へプロンプトを送り、応答を受け取ります。通信中はHTTPSで保護されても、処理を行う推論事業者は入力内容を読む必要があります。zkAPIのゼロ知識証明は、推論事業者に内容を見せずにAIを実行する暗号計算ではありません。

氏名、メールアドレス、勤務先、未公開コード、顧客情報などをプロンプトへ書けば、その情報自体が識別子になります。支払い元とのリンクが弱くても、内容から本人や組織が分かる可能性があります。機密情報を入力してよいかは、推論事業者の保存方針、学習利用、ログ保持、規約を別途確認しなければなりません。

預入から短期APIキー発行・精算までの仕組み

1. ETHを預ける：vaultへ預入し、端末で秘密のnoteを保持する。
2. 端末で証明する：note自体を明かさず、残高と利用権があることを示す。
3. 短期キーを得る：金額と期限に上限があるleaseとAPIキーを受け取る。
4. 推論事業者へ送る：プロンプトは認可サーバーではなく推論先へ送る。
5. 実使用量を精算する：通常は利用量、確認不能時は予約上限で確定し得る。
6. 残高更新・出金：新しい残高状態へ進み、対応版の手順でETHを引き出す。

端末で証明を作り上限付きの短期キーを取得する

ブラウザSDKやローカルクライアントは、noteの秘密、現在残高、状態更新に必要な情報を端末側で扱います。利用者がAPI利用を始めると、端末は「有効な預入に属する残高があり、今回予約する上限を差し引いても条件を満たす」ことを示す証明を生成します。秘密そのものを開示せず、成立させたい条件だけを検証可能にするのがゼロ知識証明の役割です。

サーバーは証明を検証し、金額と有効期間に上限を設けたlease（利用枠）と短期キーを返します。長期の個人アカウント用キーを共有する設計とは異なり、漏えい時の利用範囲を限定しやすい一方、短期キーだから内容まで匿名になるわけではありません。キーの権限、上限、有効期限を画面で確認する必要があります。

プロンプトは認可経路を通さず推論事業者へ送る

設計上、支払いを認可するzkAPIサーバーへの経路と、プロンプトを推論事業者へ送る経路は分離されています。認可側は証明と利用枠を扱い、プロンプトを受け取らない構成を目指します。推論事業者側は短期キーを検証して処理を実行するため、質問と応答を見る一方、元の預入noteを当然に知るわけではありません。

ただし、役割分担は「誰にも全体像が見えない」と自動的に保証するものではありません。運営者間のログ照合、同一IP、時刻、通信量、ブラウザやクライアント固有の特徴が相関の手掛かりになり得ます。プライバシーを評価するときは、プロトコルが渡すデータだけでなく、実際のネットワークとログ運用まで見ます。

利用量の確定後に残高を更新する

利用後、サーバーは短期キーの実使用量を取得して精算し、端末は支出後の残高状態へ進みます。状態を順番に消費することで、同じ残高を複数回使うことを防ぎます。キーが端末へ届かなかった場合はゼロ精算となる設計が記載されていますが、利用量が不明なまま精算期限へ達した場合は、予約した支出上限で精算され得ます。

したがって「使った分だけ」という説明だけでなく、失敗時の扱いが重要です。通信断、推論先の障害、利用量照会の失敗、端末ジャーナルの不整合が起きた場合に、いくら確定し、再試行や回復をどう行うかを確認します。上限は単なる表示ではなく、不確実な精算時に負担し得る最大額として慎重に設定すべき項目です。

ゼロ知識証明と二重使用防止の設計

技術者向け：回路・状態管理・vaultの詳細

まなぶ「ゼロ知識証明なら、残高を見せずに何でも安全にできるんですか？」

クリプ「証明できるのは回路に書かれた条件だけだよ。実装、鍵、サーバー運用、通信経路の安全性はそれぞれ別に確かめよう。」

Groth16で残高と利用権を証明する

現行仕様はGroth16というゼロ知識証明方式をBN254曲線上で使い、PoseidonハッシュやBaby-JubJub署名などを組み合わせます。request回路は、秘密のnoteと残高状態が公開された条件に整合し、今回の利用を認可できることを証明します。withdrawal回路は出金に必要な別の条件を証明します。名称が同じ「証明」でも、目的と公開入力は同一ではありません。

初心者が押さえるべきなのは、暗号方式の名前より境界です。証明は「正しい秘密を持つ」「計算規則どおりに残高を更新した」といった回路内の命題を検証します。基礎用語はゼロ知識証明の解説でも確認できます。プロンプトに個人情報がないこと、端末にマルウェアがないこと、推論事業者がログを保存しないことまでは証明しません。

note bindingとstate-anchor chainで状態の流用を防ぐ

匿名クレジットでは、同じ残高を二重に使わせないことが必要です。note bindingは署名済みの残高状態を特定の預入noteのMerkle証明へ結び付け、別noteへの流用を防ぐ目的で導入されています。state-anchor chainは、前の状態から次の状態へ連続して進む関係を作り、古い残高状態を再び正当なものとして提示しにくくします。

これは口座番号を毎回明かして中央台帳だけで残高を引く方法とは異なります。しかし秘密状態の紛失、バックアップの不整合、古いクライアントへの巻き戻しは利用者側の回復問題になります。SDKが持つjournalや回復手順、複数端末で同じwalletを扱う際の制約を、実際に資金を預ける前に確認する必要があります。

vaultが預入noteと退出状態を管理する

Ethereum上のvaultは預入noteをMerkle treeへ登録し、既知のrootを基に出金証明を検証します。現行仕様には深さ32のnote treeが記載され、過去に記録されたrootもwithdrawal proofに利用できる設計です。オンチェーンには預入・退出に必要な状態が置かれますが、個々のプロンプトを記録する仕組みではありません。

スマートコントラクトがあるから無条件に資金が安全というわけではありません。回路と検証鍵が正しく対応しているか、配備コードが公開仕様と一致するか、管理権限やoracleがどう設定されるかを確かめます。コントラクトの脆弱性や設定ミス、信頼できるsetupの未完了は、匿名性とは別の資金リスクです。

一般利用者は、証明方式の名称よりも「利用中の回路・鍵・vaultが同じリリースか」「回復と出金を再現できるか」を判断してください。対応関係を公式情報で照合できないなら入金しません。

zkAPIでも隠せない情報と再識別リスク

API事業者にはプロンプトと応答が見える

推論事業者は、サービスを提供するためにプロンプトを受け取り、生成した応答を返します。支払い認可サーバーがプロンプトを扱わない設計でも、推論先から内容が隠れるわけではありません。会話履歴を毎回送るアプリなら、過去の入力もまとめて見える可能性があります。

入力前に、直接識別子、準識別子、機密本文を分けて考えます。氏名やメールは直接識別子です。職種、地域、珍しい案件、固有のコード断片は、組み合わせによって本人を絞る準識別子になり得ます。必要なら一般化、伏字、架空データへの置換を行い、それでも処理目的を満たせるか検討します。

IP・利用時刻・トークン量から相関され得る

標準の直接HTTPS接続では、接続先は送信元IPと接続時刻を観測できます。ネットワーク事業者やDNSの構成によって見える範囲も異なります。また、リクエストと応答の大きさ、トークン量、連続する間隔は、別のログにある行動と照合する手掛かりになり得ます。

たとえば、預入直後に一度だけ特徴的な量のAPIを使うと、暗号学的なリンクがなくても時刻と量から候補が狭まる可能性があります。これは「証明が破られた」こととは違い、周辺情報を突き合わせる相関攻撃です。匿名性を強く必要とする用途では、利用人数の多さ、時間のばらつき、通信経路も脅威モデルへ含めます。

文体や会話履歴から本人を推測される余地がある

人は専門用語、句読点、言い回し、話題の選び方に癖があります。公開済みの文章と同じ特徴や、本人しか知らない出来事を入力すれば、支払い情報がなくても推測され得ます。同じ会話IDや長い履歴を再利用すれば、複数セッション同士も結び付きやすくなります。

したがって「ウォレットアドレスを見せない」と「誰であるか分からない」は同義ではありません。守りたい相手が推論事業者なのか、支払い処理者なのか、外部の通信観測者なのかでも必要な対策は変わります。すべての相手に対する完全匿名を一つの機能へ期待しないことが重要です。

Torとcover trafficで補える範囲

直接HTTPSとTor経由で露出情報が変わる

Torは通信を複数の中継へ通し、接続先から元のIPを見えにくくする選択肢です。zkAPIの支払いリンク分離とは別の層で、通信元を守る役割があります。直接HTTPSでは推論先に利用者側IPが届きますが、正しくTorを使えば推論先が見る接続元は通常Tor出口側になります。

ただしTorを使っただけで内容が隠れたり、ログイン情報が消えたりはしません。プロンプトに本人情報を書けば識別され得ます。Tor外へ迂回する通信、DNS漏えい、設定不備、ブラウザ指紋、入口と出口の大規模な時間相関なども考慮が必要です。遅延や接続失敗が増える可能性も、実用面の条件になります。

cover trafficは初期状態で無効

現行clientdの資料には、実通信がない時間にもダミー通信を混ぜ、利用時刻の特徴を弱めるnative Tor cover traffic機能が説明されています。しかし初期状態では無効です。利用にはTorの設定に加え、ダミーアクセスを許可された静的URLなどの条件があります。

ダミー通信は帯域、接続回数、相手側負荷を増やします。許可なく第三者サービスへ送るべきではありません。また、一定間隔のcover traffic自体が固有パターンになる可能性や、実通信の量まで十分に隠せない可能性があります。「機能が存在する」と「自分の構成で有効に働いている」を分け、ログと設定を確認します。

追加対策を使っても完全匿名にはならない

支払いリンクの分離、Tor、cover traffic、入力内容の匿名化は、それぞれ異なる観測面を減らします。組み合わせれば情報露出を抑えられる可能性はありますが、失敗点も増えます。どれか一つが外れたときに何が見えるかを表にすると判断しやすくなります。

対策	主に減らす情報	残る代表例
zkAPI	預入・支払い主体と個々の利用の直接リンク	プロンプト、応答、IP、時刻
Tor	接続先から見た元IP	入力内容、利用時刻、通信量
cover traffic	実利用の時刻パターン	内容、設定不備、長期的な相関
入力の一般化	内容中の識別手掛かり	文体、必要上残す情報、周辺ログ

旧稼働版と開発中revision 3を区別する

比較項目	発表時の旧稼働版	revision 3
稼働状況	2026年10月1日にmainnet利用可能と発表	現行mainで開発中、本番未配備
主な退出方式	利用中の旧版手順に従う	concession exitを設計・実装
本番鍵・vault	実際の接続先を個別照合	production proving keysと新vaultが未準備
監査状況	利用版と監査対象の一致を要確認	外部レビュー等が未完了
取るべき態度	版と退出を再現できれば少額テストに限定	一般利用の資金を入れない

mainnet稼働の説明が指す版を確認する

Ethereum Foundationの2026年10月1日の発表は、当時のzkAPIがmainnetで利用可能だと説明しています。一方、2026年10月16日時点のリポジトリREADMEは、concession-exitを含む移行版についてproduction proving keysと新しいvaultが未準備だと記載しています。二つは矛盾と決めつけるのではなく、指している版と段階が違うと読む必要があります。

利用画面のブランド名だけでは版を特定できません。接続するchain ID、vaultアドレス、サーバーURL、クライアントのcommit、配布manifest、回路IDを確認します。古い稼働版の説明を新しい開発版の保証として使ったり、開発版の未配備を理由に旧版も一切動かないと結論づけたりしないことが大切です。

revision 3はproduction setupと本番vaultが未準備

revision 3は、運営者が協力しない場合のconcession exitを含む設計です。実装やローカル受入試験が存在しても、調査資料ではMPC setup、外部レビュー、Sepoliaでの訓練、本番展開が未完了とされています。ローカルAnvilのE2E試験も実在部品を通しますが、providerや価格feedなどにmockを含み、本番安全性の保証ではありません。

trusted setupでは、証明鍵の生成過程が重要です。開発用鍵でテストが通ることと、複数参加者によるproduction ceremonyを経た鍵が安全に配布されることは別です。公開リポジトリであることも独立監査の完了を意味しません。release buildが開発鍵を拒否する仕組みを含め、配備手順が期待どおりか確認します。

concession exitにはchallengerの継続運用が要る

concession exitは、運営者が通常の出金へ協力しない場合にも退出経路を用意する考え方です。ただし「コントラクトさえ配れば自動的に安全」ではありません。不正または古い状態による退出を期限内に検知し、defeatなどの処理を行うchallengerの継続運用が安全性に関わります。

利用者は、誰がchallengerを運用し、停止をどう監視し、期限を逃した場合に何が起きるかを確認します。indexerが正しいチェーン状態を取り込み、oracle、署名鍵、永続データが整合することも必要です。運営者非協力への対策が、別の常時監視役へ依存する点を脅威モデルへ含めます。

0系では互換性が保証されない

リポジトリのversioning文書はmajor version 0の間、interface、wire形式、保存形式、設定がどのリリースでも変わり得ると説明しています。自動更新でクライアントだけ新しくなれば、サーバー、回路、vaultと合わず、残高回復や出金に影響する可能性があります。

試す場合はバージョン番号だけでなくcommitを固定し、manifestの署名やcode hashを照合します。秘密状態とjournalは、対応バージョンが分かる形で安全にバックアップします。更新前にはCHANGELOGで移行手順、破壊的変更、旧版からの退出方法を読み、少額のテストと回復確認を先に行います。

利用前に確認したいチェックリスト

脅威モデルと隠したい情報を定義する

最初に「誰から、何を、どの期間隠したいか」を一文で書きます。支払い処理者から個々の質問履歴を切り離したいのか、推論事業者へ元IPを見せたくないのか、質問内容そのものを処理者にも見せたくないのかで、zkAPIの適合度は変わります。最後の目的は通常のzkAPIだけでは満たせません。

• 支払いリンクだけが対象なら、預入と利用の相関条件を確認する。
• 接続元も対象なら、Tor経路と漏えい時のfail-closed動作を確認する。
• 内容も対象なら、送信前の匿名化や別方式を検討する。
• 強い攻撃者を想定するなら、時刻・量・複数運営者のログ照合を含める。

ETH価格変動・ガス代・精算上限を確認する

残高はETH建てであり、ドル固定ではありません。入金時と利用時でETH価格が変われば、同じgwei残高でも法定通貨換算額は変わります。預入と出金にはEthereumのガス代がかかり得ます。仕組みはEthereumのガス代の解説で確認できます。画面のドル表示だけで予算を決めず、元のETH量、価格参照元、更新時刻、手数料の負担主体を見ます。

短期キーの支出上限は、通信障害などで利用量が確定しないときに精算額となり得ます。必要以上に大きな上限を設定しないこと、ゼロ精算・上限精算の条件を理解すること、端数や最低出金額の扱いを確認することが重要です。価格変動や技術リスクを伴うため、生活資金を置く場所として断定的に勧められるものではありません。

出金経路と運営者非協力時の手順を確認する

通常出金では何をサーバーから受け取り、どの証明を作り、どのアドレスへ送れるかを確認します。出金先がETHを受け取れること、秘密鍵を自分で管理できること、ガスの準備があることも必要です。保管方法はウォレットの種類と選び方も参考になります。誤ったチェーンやアドレスへの送付は、プロトコルの匿名性では救済できません。操作前に暗号資産を安全に送る手順も確認してください。

運営者が停止した場合は、利用中の版にconcession exitが実際に配備されているかを確認します。設計書が存在するだけでは利用できません。待機期間、申請期限、challengerの状態、必要データのバックアップを事前に把握し、サービス停止後に初めて手順を探す状況を避けます。

commit・manifest・code hash・回路IDを固定する

利用前に記録する項目は、クライアントのバージョンとcommit、配布manifest、vaultアドレスとcode hash、request・withdrawalの回路ID、proving keyとverification keyの識別子、接続サーバーです。これらが一組として対応しなければ、正しい証明を作れない、別の契約へ資金を預ける、更新後に状態を読めないといった問題が起こり得ます。

公式配布元と署名を照合し、検索広告や第三者リンクだけを入口にしないでください。更新時には記録を上書きせず、旧版の識別情報と移行結果を残します。まずテスト環境や失っても生活へ影響しない範囲で、預入、API利用、回復、出金を一巡させると、操作と依存先を確認できます。

監査・trusted setup・規約と地域規制を確認する

監査報告がある場合は、対象commit、回路、コントラクト、対象外項目、修正状況を読みます。「監査済み」という表示だけでは、現在使う版が範囲内か分かりません。trusted setupは参加者、手順、成果物のハッシュ、配布経路を確認します。revision 3については調査時点で外部レビューなどが未完了であり、将来の完了を前提に判断しません。

プライバシー技術を使っても、API提供者の利用規約、制裁対応、AML、地域ごとの法令上の義務は消えません。匿名性を不正利用の免責と捉えないでください。法人で使う場合は、機密情報、個人データ、ログ保存、委託先管理について社内ルールや専門家の確認も必要です。

質問	合格条件	満たさない場合
何を誰から隠すか	支払い・内容・IP・時刻を分けて説明できる	用途を決めるまで使わない
損失上限はいくらか	ETH価格、ガス、上限精算を含め許容額内	上限を下げ、少額テストだけにする
出金を再現できるか	通常時の出金を少額で完了し、必要データを保存済み	追加入金しない
版の一式が一致するか	公式情報でcommit、manifest、vault、code hash、回路IDが一致	入金しない
安全性の根拠が版と一致するか	本番setupと監査の対象commit・範囲を照合できる	本番利用せず試験用途に限定
非協力時に退出できるか	配備済み手順、期限、challenger状態を確認し訓練済み	失って困る資金を入れない
規約・組織ルールに合うか	API規約、地域規制、社内ルールを満たす	利用を止め専門家へ確認

まとめ：2026年10月19日時点では版を照合し、少額で判断する

zkAPIの適否は「匿名か否か」の二択ではなく、守りたい情報と観測者で決まります。旧稼働版を試す場合も、公式情報で版の一式と退出手順を照合し、預入から回復・出金までを少額で一巡させてください。revision 3は本番準備と外部レビューを確認できるまで一般利用の資金を入れないのが安全側の判断です。