Zcash NU7とは？テストネット稼働、25秒化・NSM・v4廃止を解説

「ZcashのNU7で送金は必ず25秒で完了するのか」「ZEC保有者は今すぐ何か操作すべきか」と気になっている人もいるでしょう。NU7は2026年10月4日に公開テストネットで有効化されましたが、25秒は完了の保証ではなく、一般利用者が直ちに資金を移す段階でもありません。

• 現在地：公開テストネットでは稼働済み、メインネットは未確定です。
• 主な変更：25秒ブロック、シールド処理上限、NSM、version 4取引廃止です。
• 利用者の対応：ウォレットや取引所の公式告知を確認し、非公式な移行案内には秘密鍵を渡しません。

一般のZEC保有者は、25秒化、手数料の扱い、利用者向けチェックリストを読めば要点をつかめます。ウォレット・取引所・ノードの担当者は、互換性と末尾の運用者向けチェックリストも確認してください。この記事は、確定した仕様と未確定の日程を分けて解説するもので、ZECの価格や投資成果を予測するものではありません。

Zcash NU7は10月4日に公開テストネットで有効化

NU7は2026年10月4日、Zcash公開テストネットのブロック高4,465,026で有効化されました。事前の工程表では10月6日が見込まれていましたが、実際の発動条件はカレンダー上の時刻ではなくブロック高です。ブロックが想定より早く積み上がれば、暦日の予測より先に条件へ到達することがあります。

予定日ではなくブロック高4,465,026で発動

ネットワークアップグレードは、参加者が同じ規則へ切り替わる境界を明確にする必要があります。NU7では、テストネットが4,465,026番目のブロックへ到達した時点がその境界でした。「10月4日に運営者がスイッチを押した」というより、対応ソフトウェアがあらかじめ組み込まれた高さを認識して新ルールへ移った、と捉えると分かりやすいでしょう。

日付とブロック高を区別することは、メインネットの情報を読む際にも重要です。目標日だけが示されていても、有効化高が決まっていなければ、ノードが実際に規則を切り替える条件は完成していません。運用者はニュースの見出しだけでなく、配備仕様と対応リリースに記載された高さを照合する必要があります。

ZebraとZakuraが同じ有効化高に対応

Zcash FoundationのZebra 7.0.0-rc.0は、NU7のテストネット対応候補版として公開されました。別実装のZakuraでも、変更履歴にテストネット高4,465,026が設定されています。複数実装が同じ高さと同じ合意規則を扱うことは、異なるソフトウェア同士が一つのチェーンを検証するための前提です。

ただし、候補版はメインネット向けの更新指示と同義ではありません。Zebraの案内は、テストネット運用者には更新を促す一方、メインネット運用者にはまだ更新を求めていませんでした。利用環境がテストネットかメインネットか、ノード実装がZebraかZakuraか、正式版か候補版かを分けて確認してください。

テストネット稼働は本番の安全性を保証しない

テストネットは、新しい規則を実際のブロック生成や取引処理の中で試すための環境です。実装間の不一致、同期負荷、取引の受理条件、運用手順などを本番前に検証できます。一方で、テストネットでブロックが進んだという事実だけでは、メインネットでも障害なく動くことや、すべての事業者が準備を終えたことまでは証明できません。

NU7はブロック頻度、難易度計算、手数料配分、取引形式、P2P互換性を同時に変えます。候補版に追加修正が入る可能性もあります。したがって、テストネット稼働は重要な節目ですが、「本番移行が確定した」「安全性が保証された」と読み替えないことが大切です。

NU7とは？4つの変更を先に確認

変更	要点	主な対象
25秒ブロック	目標間隔を75秒から25秒へ短縮	全利用者
処理上限	シールド処理の最大量をブロック単位で制限	ウォレット・ノード
NSM	手数料の60%を一時的に流通から外し、将来の報酬へ回す	利用者・採掘者
v4取引廃止	古いversion 4形式をNU7後は無効化	ウォレット・取引所

ZIPは「Zcash Improvement Proposal」の略で、変更の目的や合意規則を記録する仕様文書です。NU7の中心はZIP 218、235、237、2003で、配備範囲はZIP 259に整理されています。25秒化によりブロック数を時計代わりにしていた補助金や取引期限も調整されるため、単なる高速化ではありません。

補足：検討過程には任意の資金除外を扱うZIP 233や、発行を滑らかにするZIP 234もありましたが、現行NU7の採用仕様ではありません。コミュニティ投票は範囲を絞る判断材料であり、最終的な適用範囲は最新の配備ZIPと対応ソフトウェアで判断します。

75秒から25秒への短縮で確認待ちはどう変わるか

ZIP 218は、目標ブロック間隔を75秒から25秒へ短縮します。目標値どおりに進むと仮定すれば、次のブロックへ取引が入るまでの期待待ち時間は25秒となり、時間当たりのブロック数は単純計算で3倍です。ただし、25秒は各ブロックが必ず25秒ちょうどで作られるという保証ではありません。

短い比較例：1確認までの目標間隔は従来の75秒から25秒になります。一方、仮にサービスが6確認を求めても「必ず150秒で完了」とは言えません。ブロック生成にはばらつきがあり、サービスがNU7後も同じ確認数を維持するか、確認数を見直すかも各社の判断だからです。初回確認、サービス所定の確認数、取引を覆しにくいとみなす最終性は別の概念です。

初回確認の期待待ち時間は25秒に短縮

利用者にとって最も分かりやすい変化は、初回確認を待つ時間の短縮です。取引が次のブロックに含まれれば、未確認状態から一段進むまでの平均的な待ち時間は短くなります。ただし、取引の伝播状況、手数料、ノードの状態、ブロック生成のばらつきにより、実際の時間は前後します。

また、「初回確認が速い」ことと「最終的な安全性の判断が3倍速い」ことは同じではありません。サービスが入金完了とみなす確認数は、再編成リスクや運用方針に応じて設定されます。取引所や決済サービスがNU7後に必要確認数を変更するかは、それぞれの公式案内を確認してください。

時間当たりブロック数は単純計算で3倍

75秒から25秒への変更は、同じ1時間に作られるブロックの目標数が3倍になることを意味します。これは確認機会を増やす一方、ブロックヘッダーや伝播処理、同期確認などをより高い頻度で行うことも意味します。個々のブロックを小さく保つ対策がなければ、ノードや軽量クライアントの負担が増えやすくなります。

さらに、補助金や期限を単純に「1ブロック当たり」で据え置くと、実時間で見た発行や有効期間が変化してしまいます。そのため、NU7では各ブロック補助金、取引期限差、資金ストリームの期間など、ブロック数を時計代わりに使っていた規則も調整対象になります。

難易度平均窓を17から102ブロックへ拡大

ブロック生成間隔は採掘能力の変動を受けるため、ネットワークは難易度を調整します。25秒化に合わせ、難易度の平均窓は17ブロックから102ブロックへ拡大されます。ブロック間隔を3分の1にしたからといって、平均窓のブロック数を単純に3倍へするだけではなく、短期変動への安定性も踏まえた仕様です。

ブロックが短い間隔で伝わるほど、同じ親ブロックから複数の候補が生まれる機会や、遠いピア（ネットワーク上で直接通信する相手ノード）への到達前に次のブロックが見つかる可能性も意識する必要があります。ZIP 218は速度の利点だけでなく、フォーク（同じ親から一時的に複数のチェーン候補が生じること）の発生率や同期負荷を設計上の論点として扱っています。

シールド処理上限で同期負荷の増大を抑える

Zcashのシールド取引は、送付元・送付先・金額などを公開台帳上で見えにくくする取引で、プライバシー保護のためのゼロ知識証明を用います。ブロック頻度が3倍になれば、同じ大きさの処理を各ブロックへ無制限に詰め込める設計では、単位時間当たりの検証・同期負荷も大きくなり得ます。NU7はこの問題に対し、シールド系の処理量へブロック単位の上限を設けます。

Orchardは1ブロック330アクションが上限

実装情報では、現在の主要なシールド方式であるOrchard（オーチャード）は1ブロック当たり330アクションが上限です。アクションは、シールド取引の処理量を数える単位として捉えられます。単純な「取引件数」とは一致しないため、330件の送金という意味ではありません。一つの取引が複数の論理アクションを含む場合があります。

上限がシールド同期の負荷を抑える仕組み

上限には、最悪時の処理量を予測可能にする役割があります。ノードは受け取ったブロックの規則適合性を検証し、軽量ウォレット向けの仕組みもシールド関連データを扱います。ブロックごとの上限があれば、25秒ごとに到来し得る処理の最大規模を抑え、ピア同期や帯域への急激な負荷を緩和できます。

これは通常時のすべての問題を消す仕組みではなく、負荷に境界を設ける仕組みです。利用が集中して上限へ近づけば、取引が次のブロックへ持ち越される可能性があります。速度を評価するときは、目標間隔だけでなく、各ブロックが許容する処理量とネットワーク全体の伝播能力を合わせて見る必要があります。

25秒化後も残るフォーク・同期・帯域の課題

処理上限があっても、ブロックの受信と検証は従来より頻繁になります。地理的に離れたピア、性能が低い機器、不安定な回線では、短い間隔が同期余裕を小さくする可能性があります。軽量ウォレット側も、更新されたサーバーとの互換性やデータ取得量を検証する必要があります。

テストネットで確認したいのは、ブロックが生成されるかだけではありません。実装間で同じブロックを有効と判定するか、追従が遅れたノードが回復できるか、ウォレットが正しい残高を表示するか、負荷時にフォーク率がどう推移するかといった運用面も対象です。

手数料の60%は焼却ではなくNSMへ一時移転

ZIP 235では、ブロックに含まれる取引手数料合計の40%を採掘者へ渡し、60%を流通から一時的に除外します。この60%はNetwork Sustainability Mechanismの準備金として将来の発行へ回す設計であり、永久焼却と表現するのは不正確です。

採掘者に40%、NSM準備金に60%を配分

従来、取引手数料は採掘者収入の一部になります。NU7ではその全額ではなく40%が採掘者へ渡り、残る60%は直ちに使える流通量から外れます。例えば比率を理解する際は、手数料全体を100とした場合に40と60へ分かれる、と考えれば十分です。ここからZEC価格や採掘採算を機械的に予測することはできません。

採掘者の手数料収入はこの配分によって減りますが、影響は実際の手数料水準やブロック補助金などにも左右されます。調査資料も、将来の手数料水準によって比率の再検討が必要になる可能性をリスクとして挙げています。固定比率があらゆる環境で永続的に最適だと保証されたわけではありません。

60%分を永久焼却と呼べない理由

暗号資産で「焼却」や「バーン」は、一般に資産を永久に利用不能にする仕組みを指します。NU7の60%分は将来再発行する前提なので、永久消滅ではありません。流通供給から一時的に外れることと、総供給の権利が永遠に失われることを区別してください。

この違いは経済的な説明にも影響します。「60%が毎回消えるので希少性が恒久的に高まる」といった説明は、将来の再発行を無視しています。一方、「何も変わらない」という説明も、現在の採掘者配分と流通タイミングが変わるため正確ではありません。短期の流通除外と将来の報酬化を一組で捉えます。

アクション比例の手数料が計算の前提

Zcashの標準手数料はZIP 317で、論理アクション数に比例する方式が示されています。したがって、NU7の60%配分を理解するときも、単純な送金件数だけで手数料を考えないことが重要です。取引の構成によって論理アクション数が異なり、標準手数料の計算へ反映されます。

ウォレットが表示する手数料は、利用者が実際に支払う入口です。その後、ブロックへ含まれた手数料合計が合意規則に従って配分されます。利用者が送金時に60%を別途追加で支払うという意味ではなく、支払われた手数料の行き先が分けられる仕組みです。

NSMは将来の報酬と半減周期をどう両立するか

ZIP 237は、25秒化後も約4年の半減周期を維持しながら、NSM準備金を将来のブロック報酬として再発行する方式を定めます。ブロック数が同じ時間内に3倍になるため、1ブロック当たりの補助金を調整しなければ、時間当たりの発行量が変わってしまいます。

将来再発行は2031年2月の開始を想定

調査資料では、NSM準備金の将来再発行は2031年2月の開始を想定しています。ただし、公開時点のZIP 259では再発行高が未解決事項に含まれています。年月の想定と、合意規則へ埋め込まれる正確なブロック高を同一視してはいけません。

このため、「2031年2月の特定日に必ず開始する」と断定するのではなく、現行設計がその時期を想定していると理解するのが適切です。最終的には、更新された配備仕様と実装に設定された再発行高を確認する必要があります。

各ブロック補助金を調整して時間当たり発行を保つ

25秒ごとに従来と同額の補助金を発行すれば、75秒間に発行される量は単純に増えてしまいます。そこで、ブロック間隔の短縮に応じて1ブロック当たりの補助金を調整し、実時間で見た発行ペースと半減周期を維持します。ブロック高だけを比較すると数値の進み方が変わるため、期間を読む際は秒や年月へ置き換えて考える必要があります。

NSM準備金からの再発行も、この補助金計算の中で扱われます。準備金残高と再発行計算について実装同士が一致しなければ、同じブロックを有効とするかどうかが分かれ、合意分岐につながり得ます。複数実装でのテストが重要なのはこのためです。

発行平滑化ではなく半減維持方式を採用

発行平滑化は、急な半減を避けて発行量を徐々に減らす別案です。しかし、NU7はZIP 234の平滑化ではなく、ZIP 237の半減維持方式を採用します。「NSMを導入するから半減がなくなる」という説明は誤りです。約4年周期の半減という枠組みを保ちながら、準備金を将来報酬へ組み込む設計です。

経済設計を比較するときは、手数料をいつ流通から外すか、いつ戻すか、通常の補助金をどう減らすかを別々に確認します。名称だけでデフレ的、インフレ的と決めつけず、配備された式と開始高を基準に評価する姿勢が必要です。

v4取引廃止とプロトコル更新が運用者に与える影響

NU7以降、version 4取引は合意上無効になります。加えて、古いP2Pプロトコル版を使うピアの切断や、既定の取引期限差の変更が運用上の論点です。ノードだけでなく、取引を作成するウォレット、入出金を処理する取引所、軽量クライアント用サーバーも互換性を確認する必要があります。

version 4取引は合意上無効になる

合意上無効になるとは、NU7の規則を適用するノードがv4取引を有効な取引として受け入れないことです。過去の取引履歴が消えるという意味ではなく、更新後に新たにv4形式を作成・中継しようとする仕組みが問題になります。

利用者は、自分で取引バージョンを設定していなくても、ウォレットやサービスがどの形式を生成するかの影響を受けます。運用者は、取引作成、署名、中継、入出金監視の各部分が新ルールへ対応しているかをテストしてください。未対応なら、送信エラーや入出金停止などにつながり得ます。

旧プロトコルのピアは切断対象になる

P2Pネットワークでは、ノード同士が対応プロトコル版を知らせ合います。更新後、現エポック未満のプロトコル版を使うピアは切断対象です。これは互換性のない規則を話すノードが混在し続けることを避ける仕組みですが、更新が遅れたノードにとっては接続先を失うリスクになります。

ノード管理者は、ソフトウェアの起動だけでなく、同期高、接続ピア、ログ、RPC応答を確認する必要があります。取引所などでは、入出金を一時停止して更新するか、冗長ノードを順に更新するかといった運用計画も必要です。本番有効化高が決まってから慌てないよう、対応版と試験結果を事前に整理します。

取引期限差を120ブロックにして約50分を維持

取引期限は、取引がいつまでも未確定のまま残ることを避けるための境界です。従来の既定期限差40ブロックを25秒環境でそのまま使うと、実時間は約3分の1になります。そこで、120ブロックへ増やし、実時間で約50分を維持することが推奨されています。

これは、ブロック数が3倍になる変化に合わせて実時間を保つ分かりやすい例です。ただし、推奨される既定値と、合意上絶対に必要な値は区別して読む必要があります。ウォレットやサービスは、自らの期限設定が更新後に意図した時間となるかを確認してください。

終了済みzcashdではなく現行実装の版を確認

旧zcashdは終了が案内され、移行先としてZebra、Zakura、Zalletなどが示されています。NU7対応を調べる際に、終了済み実装の古い手順を参照すると、必要な版や運用方法を誤るおそれがあります。現在利用しているノード、ウォレット、関連ライブラリの組み合わせを棚卸ししてください。

一般利用者は、ウォレットや取引所の公式な対応告知を確認し、秘密鍵や復元情報を求める非公式な案内に反応しないことが基本です。技術更新を口実にした「ZECを移せば増える」といった案内に根拠はありません。操作前には暗号資産を安全に送金する手順と暗号資産詐欺の対策も確認してください。

11月5日はメインネット確定日ではない

NU7の工程表では、2026年10月20日に最終判断を行い、11月5日をメインネット有効化の目標日としています。しかし、記事公開時点でメインネット有効化高は設定されていません。目標日、最終判断日、有効化高はそれぞれ役割が違います。

10月20日の最終判断を前提とする目標日

10月20日は、テストネットで得られた結果や実装準備を踏まえ、予定どおり進めるかを判断する節目です。11月5日はその判断が肯定的であることを前提にした目標であり、無条件に到来する施行日ではありません。問題が見つかれば、候補版、工程、有効化条件が変わる可能性があります。

第三者報道や提出書類も11月5日を目標として扱い、予定どおり有効化・稼働する保証がない点を示しています。予定を伝える際は「11月5日に実施される」ではなく、「10月20日の判断を前提に11月5日を目標としている」と条件を残す必要があります。

メインネット有効化高は未設定

ZebraのNU7マイルストーンでは、メインネット有効化高を設定するタスクが未完了でした。ZIP 259でも、有効化高、再発行高、最小プロトコル版などが未解決事項として残っています。進捗率が高いことと、配備パラメータが最終確定していることは別です。

テストネットでは4,465,026という明確な高さがありましたが、同じ数値がメインネットへ使われるわけではありません。チェーンが異なればブロック高も異なります。運用判断では、ネットワーク名と有効化高を必ず一組で確認してください。

一般利用者向けチェックリスト

• アプリ更新：利用中のウォレット公式サイトやアプリストアで、NU7対応版と更新の要否を確認します。
• 入出金停止：取引所がメンテナンス中なら、再開告知まで送金を繰り返しません。送金時はネットワークとアドレスを照合し、可能なら少額で試します。
• 秘密鍵を渡さない：運営やサポートを名乗る相手にも、秘密鍵やシードフレーズを共有しません。NU7対応を理由に資金移動を迫る非公式案内は無視します。

一般利用者がノードの有効化高や通信プロトコルを自分で設定する必要は通常ありません。必要な操作はサービスごとに異なるため、SNSの断片的な投稿ではなく、利用先の公式告知を基準にします。NU7の実施はZECの購入や売却を勧める材料ではなく、技術更新と価格判断も分けて考えてください。

事業者・ノード運用者向けチェックリスト

• 対応版と有効化高：ZIP 259、ZebraまたはZakuraの正式リリースを照合し、候補版を本番用の正式版と取り違えません。
• 通信条件：最小プロトコル版を確認します。プロトコル版はノード間通信の世代番号、エポックは同じ合意規則が有効な期間です。
• 試験：v4取引の拒否、120ブロックの取引期限、シールド同期、入出金と残高表示をテストネットや検証環境で確認します。RPCはソフトウェア同士がノードへ照会・操作するための窓口なので、応答形式を使う連携システムも試験対象です。
• 復旧手順：更新前バックアップ、監視項目、停止判断、以前の版へ戻す条件を文書化します。複数ノードが同じチェーン高へ追従しているか比較し、一時的な分岐後にチェーンが選び直される再編成も監視します。

不具合が疑われる場合は、取引ID、ソフトウェア版、接続ネットワーク、観測したブロック高、ログの時刻を記録します。配備ZIPで合意条件、正式リリースで対応版、利用サービスの告知で停止時間を確認する順序にすると、古い「対応予定」と最新の確定情報を混同しにくくなります。三者が一致しない場合は目標日だけで本番投入せず、更新された公式案内を待ちます。

障害の切り分けでは、まず自社ノードだけの問題か、接続先を含む広い問題かを確認します。同じ取引を繰り返し送ると二重処理の判断が難しくなるため、取引IDとノードの応答を確認するまでは再送を急ぎません。テストネット用資産とメインネット上のZECは別物であり、テスト手順をそのまま本番へ適用しないことも重要です。

一般利用者も、残高表示が遅いだけなのか、取引が未確認なのか、取引所が入出金を停止しているのかを分けて確認しましょう。画面表示だけで資金消失と決めつけず、公式の障害情報とブロック確認状況を照合します。ただし、確認のために秘密鍵を外部サイトへ入力する必要はありません。

まとめ：NU7で押さえる3点

1. NU7は公開テストネットで稼働済みですが、メインネット移行は未確定です。
2. 25秒化は初回確認の機会を増やしますが、送金完了時間を保証するものではありません。
3. 一般利用者は公式のアプリ・入出金案内、運用者は対応版・有効化高・試験・復旧手順を確認します。