ZcashのShielded Pool、Unified Address、Viewing Keyを解説
透明なpoolとSapling・Orchardの違い、Unified Addressからwalletがreceiverを選ぶ仕組み、Viewing Keyで見える情報とその範囲を説明します。
このガイドの内容Poolは台帳上の状態であり、資産を預かる事業者ではない
短い要約
Zcashはすべての送金を自動で隠すわけではありません。透明poolのアドレスと価値の流れは公開されます。一方、SaplingとOrchardのshielded poolはnoteの詳細を暗号化し、公開commitmentとnullifierを使ってコンセンサスを検証します。Unified Addressには複数種類のreceiverを含められます。個々の支払いのプライバシーは、送信側walletがどのreceiverを選ぶか、価値がどのpoolを通るかで変わります。
Poolは台帳上の状態であり、資産を預かる事業者ではない
Zcashのpoolは、取引所や預金を保管する会社ではなく、コンセンサスルールで管理される価値の状態です。透明poolではUTXOが公開されます。chainを読む人は、どのoutputが作られ、後続のどのtransactionがそれを消費し、いくらが見えるかを確認できます。アドレスだけで法的な身元が分かるわけではありませんが、公開記録からアドレスの利用や価値の移動を結び付けられる場合があります。
shielded poolは、可視のUTXOではなくnoteで価値を表します。networkは暗号化されたnoteデータ、commitment tree、pool残高の検証情報を記録します。proofにより、通常の観察者に受取人やnoteの金額をtransparent outputのように見せずに、コンセンサスが妥当性、価値の保存、二重支払いの防止を検証できます。Zcash Protocol Specificationは両方の方式を説明しています。
現在のSapling・Orchardと、新たな価値を追加できないSproutを区別する
SaplingとOrchardは別々のshielded poolであり、protocolとnote commitment treeも異なります。残高を単一の交換可能な状態として扱うことはできません。SproutはZcashで最初に導入されたshielded protocolです。ZIP 211が有効になって以降、Sprout poolへ新しい価値を追加できませんが、過去のSprout transactionはchain履歴に残っています。
networkの状態には日付が必要です。公式ZIP indexによると、Mainnetで最新の確定upgradeはNU6.2で、2026年6月3日にblock 3,364,600で有効になりました。一時的な脆弱性対策の後、NU6.2では修正済みのcircuitルールとともにOrchard actionが再び有効になりました。NU6.3とIronwood poolはまだdraft提案で、現在のMainnetルールではありません。ZIP 257、ZIP index、draft ZIP 258を参照してください。
暗号化されたnoteデータと公開commitmentは役割が異なる
shielded noteは、pool内の価値と受取人の支出権限を結び付けます。値、受取人の詳細、memoは暗号化され、対応する受信情報を持つwalletだけが読み取れるようになっています。chainにはnoteの平文ではなく、暗号化データとnoteへのcommitmentが記録されます。commitmentがあれば内容を公開せずに検証できます。
noteを支出するとき、transactionは対応するnullifierを明らかにします。支出する側はnoteを知っていることを証明し、nullifierを公開します。networkはそれが過去に使われていないことを確認します。観察者にはnullifierとcommitment treeが見えますが、どの過去のcommitmentと対応するかは特定できない設計です。これにより二重支払いを防ぎつつ、すべてのコンセンサス情報を秘密にする必要はありません。SaplingとOrchardは異なる暗号方式とproofでこの基本設計を実現し、支出には対応する秘密の権限が必要です。
Unified Addressは複数種類のreceiverをまとめる
Unified Address(UA)は、Orchard、Sapling、transparent P2SH、transparent P2PKHのreceiverを含められる1つのencoded stringです。有効なRevision 0 UAには、少なくとも1つのshielded receiverが必要です。stringは意図的に人間が見て内容を判別できない形式で、含まれるreceiver typeを外観から読み取れません。ZIP 316では有効なRevision 0と提案中のRevision 2を区別しています。
送信側walletはすべてのreceiverに送金するわけではありません。Revision 0の優先順位はOrchard、Sapling、transparent P2SH、transparent P2PKHの順です。senderはwalletが対応するreceiverのうち、最も優先順位が高いものを使う必要があります。Orchardに対応していればOrchardを選び、Orchardには未対応でもSaplingに対応していればSaplingを選べます。実際に使われるpoolは、表示されたaddress stringだけでなく送信側walletの機能に左右されます。
Revision 2のdraftでは、shielded専用addressのzuとtransparent receiverを含められる形式のtuが提案されています。公式ZIP indexではRevision 2はまだdraftです。これらのprefixを、一般的な稼働中Mainnet UA形式として扱わないでください。送金前にwalletの確認画面でaddress type、network、選択されたreceiverを確かめましょう。
Poolの境界をまたぐと価値の流れが再び見える場合がある
transparentからshieldedへの送金(t→z)では、公開UTXOを消費してSaplingまたはOrchardのnoteを作れます。chainの観察者にはtransparent input、transparent poolの変化、shielded poolへ入る純額が見えます。ただし、通常のshielded受取アドレスやnoteごとの金額を、transparent UTXOのように読むことはできません。shielded poolに価値を移す際にも、pool境界の情報は残ります。
逆方向(z→t)では、transparent outputのアドレスと金額が公開され、shielded pool内の対応する価値変化も観察できる場合があります。同じpool内でnoteを作るshielded paymentは受取人と金額を隠せることがありますが、SaplingとOrchardの間の送金ではpoolごとの残高変化が手がかりになります。境界上の公開値だけで特定の人物や過去のnoteが分かるわけではありませんが、金額、時刻、外部記録と照合される可能性があります。
アドレスがshieldedかどうかだけでなく、価値の出発点と通過したpoolも確認してください。取引所からの出金、店舗への支払い、金額や時刻が分かる個人間送金は、公開された境界情報と照合される場合があります。これだけで全てのnoteの所有者や内部経路が分かるわけではありませんが、候補を絞る材料にはなります。

Viewing Keyは閲覧を許可するが、支出権限は与えない
ZIP 316では、Viewing Keyはアドレスへの支払いを見るために必要な情報と定義されています。Full Viewing Key(FVK)は、そのアドレスからの支払いに関する情報も見られます。FVKからIncoming Viewing Key(IVK)を導出でき、IVKからaddressを導出できます。Unified Viewing Keyは複数protocolのViewing Key項目をまとめます。
Viewing Keyだけでは支出に署名できません。支出には別のspending keyまたは署名システムが必要です。ただしViewing Keyは公開してよい情報ではありません。鍵の種類とwalletの実装により、確認できるtransactionの範囲が決まります。account単位の鍵は、1つの受取アドレスより多くの情報を明かす場合があります。会計担当者やサービスと共有する前に、対象範囲、保存期間、削除方法、他のアドレスとの組み合わせを確認してください。
Viewing Keyが、もともと公開されていた情報を消すことはありません。transparent input/output、金額、時刻は鍵がなくても分析できます。一方、必要なpoolに対応していないexplorerやwalletでは、chainに記録されたshielded transactionが表示されないことがあります。「アプリに表示されない」ことと「chainに存在しない」ことは別です。
Shielded transactionでもすべてのつながりが隠れるわけではない
見える情報はpoolとreceiver typeによって変わります。完全にtransparentな資金移動ではアドレス、金額、UTXO間の関係が分かります。shielded paymentはnoteの受取人と価値を暗号化しますが、commitment、nullifier、時刻、protocolデータはchainに残ります。pool境界、walletの対応pool、既知の支払い時刻、取引所の記録、共有されたViewing Keyがそれぞれ手がかりになることがあります。
Unified Addressを使っても、すべての支払いがOrchardになるとは限りません。receiverの選択はwalletのversion、設定、実装、transaction pathによって変わることがあります。addressを貼り付けただけでプライバシーを判断せず、送金前のpreviewまたはtransaction結果を確認してください。[Moneroのプライバシーガイド](/learn/ja/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained)は別の設計を扱い、[Bitcoinのアドレス再利用ガイド](/learn/ja/bitcoin-address-reuse-privacy-transaction-linkability-explained)は透明な台帳と比較します。
network privacyも別の層です。RPC provider、light-wallet server、取引所、決済サービスはtransactionの作成やrelay要求を観察し、IPアドレス、account、時刻をchain外で保存する場合があります。暗号学的proofがサービスのログを自動で消すわけではありません。絶対的な匿名性をうたうのではなく、誰がmetadataを受け取り、どう保存するか確認しましょう。
アドレスとtransactionの結果をあわせて確認する
まずwalletが意図したMainnetまたはTestnetに接続していることを確認します。支払い確認画面で、相手がUnified Addressを提示したか、walletがどのreceiverを選ぶかを確認してください。UA stringからreceiverの種類は見分けられません。walletに表示されたpool、金額、memo、feeを読みます。shielded paymentを求められたのにpreviewがtransparent outputを示す場合は、送信前に両方のwalletのprotocol対応状況を確認してください。
既存のtransactionを調べるには、transaction IDとnetworkを照合し、inputとoutputにどのpoolが含まれるかを確認します。transparent addressと金額は公開explorerに表示されますが、対応していないtoolではnoteの詳細が出ない場合があります。Viewing Keyが必要なら理由と開示される情報を確認し、spending keyやViewing Keyを見知らぬサイトに入力しないでください。custodialとnon-custodial walletのガイドでは署名の責任についても説明しています。
「shielded addressを使ったから完全に秘密だ」「explorerに値が表示されないから送金は起きていない」と決めつけないでください。wallet履歴、network、transaction ID、chainの状態、confirmation、閲覧権限はそれぞれ別の事実です。相手に受け取り確認が必要なら、受取側walletが該当poolに対応し、同期済みかも確認しましょう。
仮の支払いでreceiver選択と公開情報を追う
Leeがtransparent UTXOから、Orchard、Sapling、transparent receiverを含むUnified Address Revision 0へ1.25 ZECを送るとします。この金額は説明用であり、fee rateやwalletの初期設定を示しません。LeeのwalletがOrchardに対応していれば、ZIP 316の優先順位ルールによりOrchard receiverを選びます。公開chainにはtransparent inputと、shielded poolに入る純額などの境界情報が残りますが、受取人のshielded note addressと金額は通常の公開outputのようには表示されません。
LeeのwalletがOrchardに対応せずSaplingに対応していれば、Saplingを選べます。shielded poolに一切対応しないwalletでも、addressと支払い形式にtransparent receiverがあれば利用できます。Revision 0 UAにはshielded receiverが必要ですが、senderが選ぶのはwalletの対応するreceiverだけです。同じUAでもwalletの機能次第で異なるpoolが使われ、公開される境界情報も変わる可能性があります。
最後に、受取人が会計サービスにViewing Keyを別途共有すると、そのサービスは鍵の範囲内のshielded activityを見られることがあります。walletの受領表示、explorerにnote詳細がないこと、chainにコンセンサスに沿ってtransactionが記録されたことは、別々の事実です。Unified Addressは複数世代のprotocol間の互換性を高めますが、完全なプライバシーを保証せず、receiverの選択、鍵管理、network情報の露出に関する責任も引き受けません。
一次プロトコル資料
よくある質問
Q1Zcashのすべてのtransactionでアドレスと金額は隠れますか?
いいえ。透明poolのtransactionでは公開UTXO、アドレス、金額が見えます。Unified Addressには複数のreceiverが含まれるため、送信側walletがどれを選んだか確認してください。
Q2Unified AddressにOrchardが含まれていれば、必ずOrchardで受け取りますか?
送信側walletがOrchardに対応し、そのreceiverを含むRevision 0 UAを処理する場合、ZIP 316の優先順位ではOrchardを選びます。walletによって対応receiverが違うため、送金previewを確認してください。
Q3Viewing Keyで資金を移動できますか?
いいえ。Viewing Keyは範囲内のtransaction情報を読むためのものです。支出には別のspending keyまたは署名権限が必要ですが、Viewing Keyも個人情報を見せるため安全に管理してください。
出典
問題を報告
この記事のリンクを含むメールを準備します。送信すると Mark に報告が届きます
クイックチェック
記事を読み終えたら、3問で確認しましょう
問題 01
shielded noteがchainに記録されたとき、通常の観察者に見えるものは何ですか?
答えを選ぶと解説を確認できます