現在の量子コンピューターがBitcoinやEthereumの署名鍵を直ちに解読できるとは確認されていません。ただし移行には年単位の準備が要るため、慌てて売買するのではなく、公式実装へ移れる状態を今から整えるのが答えです。
- この記事で分かること:量子脅威の読み方、NIST標準の役割、EthereumとAlgorandの対応範囲、立場別の準備手順。
- 個人利用者:「量子脅威が狙うもの」「層別評価」「実務手順」の個人ラベルを中心に読むと、鍵とウォレットの確認事項が分かります。
- 開発・事業担当者:「NIST標準」「単純置換できない理由」「実務手順」の事業者・運営側ラベルで、設計と移行計画を確認できます。
量子計算の研究値、現実の装置、ブロックチェーンの設計、利用者の鍵管理は別の論点です。本稿は初心者向けの判断軸と事業者向けの実務を分け、どの層が対応済みで何が残るかを整理します。特定の暗号資産の購入・売却を勧めるものではありません。
量子コンピューターは今すぐブロックチェーンを破るのか

暗号方式の移行には、仕様策定、実装、監査、ウォレット対応、利用者の鍵更新、合意形成の変更まで長い時間がかかります。そこで研究上の脅威と現行機の能力を区別しながら、準備を先行させます。
現在の暗号資産が直ちに危険とはいえない理由
量子攻撃の説明では、Shorのアルゴリズムが楕円曲線暗号やRSAを理論上破れることと、今日の装置で実行できることが混同されがちです。実行には、十分な数の高品質な論理量子ビット、膨大な量子ゲートを正しく処理する能力、誤り訂正、安定した運転時間が必要です。アルゴリズムが知られているだけでは、秘密鍵を取り出せません。
したがって、短い見出しの「量子ブレークスルー」だけで資産の緊急移動を判断するのは危険です。確認すべきなのは、対象がRSAの因数分解なのか、256ビット楕円曲線の離散対数なのか、示された数が論理量子ビットか物理量子ビットか、誤り率や実行時間をどのように仮定したかです。研究結果は移行を急ぐ材料にはなっても、攻撃が実行された証明ではありません。
ECDLP-256解読の資源見積もりはどう変わったか
公開鍵から秘密鍵を推定できるほど強力な攻撃が実現すると、攻撃者は所有者になりすまして送金へ署名できます。ECDLP-256とは、256ビットの楕円曲線暗号(ECC)が安全性の根拠とする離散対数問題で、この不正送金に直結する論点です。
Google Researchが2026年3月に公表した研究は、ECDLP-256を解く二つの回路案について、1200未満または1450未満の論理量子ビットという見積もりを示しました。別の解説では、一定の仮定の下で必要な物理量子ビットを50万未満とし、従来の見積もりに比べて約20分の1としています。いずれも現行機がその攻撃能力を持つという数字ではありません。
重要なのは、これは条件付きの資源推計であり、現在50万個の物理量子ビットを並べれば直ちに鍵を解けるという意味ではないことです。回路、誤り訂正方式、物理ゲートの品質、処理速度などの仮定が変われば結果も変わります。それでも推計が大きく縮んだことは、移行に使える猶予を当然視すべきでない理由になります。
論理量子ビットと物理量子ビットを混同しない
まなぶ「クリプ先生、1200量子ビットの機械ができたら、もう署名を破れるんですか?」
クリプ「その1200は誤り訂正された“論理量子ビット”の見積もりなんだ。実機の“物理量子ビット”とは一対一ではなく、品質や誤り訂正の負担も確かめる必要があるよ。」
物理量子ビットは装置上の素子で、ノイズや誤りの影響を受けます。論理量子ビットは、多数の物理量子ビットと誤り訂正を組み合わせ、計算に使える信頼性を持たせた単位です。両者の換算は固定ではありません。ハードウェアの誤り率や採用する符号によって、必要な物理資源は変わります。
ニュースを読むときは、「量子ビット数が増えた」という一項目だけでなく、論理か物理か、エラー訂正済みか、目的の回路を最後まで動かせるかを見ます。この区別を保てば、脅威を過小評価することも、研究値を現行機の攻撃能力と誤認することも避けられます。
量子脅威が狙うのは公開鍵暗号とデジタル署名
ブロックチェーンの記録そのものを魔法のように書き換えるのが量子攻撃ではありません。中心的な懸念は、公開鍵から秘密鍵を求め、正当な所有者になりすまして署名できる可能性です。基礎は公開鍵と秘密鍵の仕組み、保管面は秘密鍵の管理方法も参照してください。
ShorのアルゴリズムがECCとRSAに与える影響
十分に強力な量子コンピューターでShorのアルゴリズムを実行できれば、RSAが依存する因数分解や、ECCが依存する離散対数問題を効率的に解けると考えられています。NIST NCCoEも、ECCやRSAを利用する公開鍵暗号は将来の暗号解読能力を持つ量子コンピューターの影響を受け得るため、移行準備が必要だと説明しています。
一方、ハッシュ関数、共通鍵暗号、公開鍵署名は同じ仕組みではありません。「現在使われる暗号がすべて同時に無効になる」とまとめず、対象方式と用途を確認する必要があります。ブロックチェーンでは、取引の認証に使うデジタル署名が特に直接的な論点です。
ECDSAとBLSに依存する署名の弱点
Ethereumの公式ロードマップは、実行層の利用者口座がECDSA、合意層の検証者がBLS署名に依存していることを説明しています。どちらも楕円曲線暗号に基づくため、十分な量子計算能力が実現すれば影響を受けます。利用者の送金署名だけを置き換えても、検証者の署名が従来方式のままなら、チェーン全体の移行は完了していません。
ここで大切なのは「弱点が理論上ある」と「今、署名が偽造できる」を分けることです。前者は設計変更を始める理由であり、後者は現実の攻撃能力に関する主張です。公式資料は研究体制と移行経路を示していますが、Ethereumが完全な耐量子チェーンへ移行済みだとはしていません。
公開鍵が露出した口座を優先して考える理由
量子攻撃が秘密鍵を導くには、通常、対応する公開鍵が必要です。アドレスが公開鍵のハッシュとして表され、支出するまで公開鍵を直接見せない設計では、未使用口座と、すでに取引を署名して公開鍵がチェーン上へ現れた口座で状況が異なります。ただし、方式や口座設計はチェーンごとに違うため、「未使用なら絶対安全」という一般化もできません。
実務では、残高の大小だけでなく、公開鍵がすでに露出しているか、同じ鍵を長期に再利用しているか、署名方式を更新できるか、所有者が鍵を操作できるかを調べます。休眠口座や紛失鍵の資産は、所有者自身が新方式へ署名して移せないため、技術とガバナンスが交差する難題になります。
耐量子化はチェーン全体を層ごとに考える

「このチェーンは耐量子」という一文だけでは、何が守られているか判断できません。最低でも、口座の取引署名、検証者の合意署名、参加者選択に使うVRF、過去の履歴を外部へ証明する仕組みを分けます。一つの層への対策は重要ですが、他の層の弱点を自動的には解消しません。
口座の署名を量子攻撃から守る
口座層の目的は、秘密鍵を持つ本人だけが資産移動を承認できる状態を保つことです。耐量子署名を使える新しい口座形式を用意し、古い口座から安全に移せる経路を作る必要があります。署名方式だけでなく、アドレスの作り方、鍵生成、バックアップ、ハードウェアウォレット、マルチシグ、復旧手順も変化します。
公式対応前に非公式な変換ツールへ秘密鍵やシードフレーズを入力する行為は、量子攻撃より先に通常の窃取を招きかねません。利用者が行う移行は、対応するプロトコル、監査済みの実装、正式なウォレット手順が揃った後に、少額で確認しながら進めるのが基本です。
合意形成とVRFの依存関係を見直す
合意層では、検証者の投票やブロック提案を認証する署名を評価します。さらに、誰を提案者や委員に選ぶかを暗号学的に決めるVRF(検証可能ランダム関数)がECCへ依存する場合、口座署名だけを耐量子化しても残存リスクになります。攻撃者が合意参加者になりすませる設計上の余地があれば、個々の口座だけではチェーンを守れません。
合意方式の変更は、ネットワーク全体が同じルールを採用する必要があり、ウォレットの追加機能より調整範囲が広くなります。性能、メッセージ量、検証時間、実装の成熟度を検証し、必要ならハードフォークを通じて切り替える計画が要ります。
履歴証明だけでは現在の資産を守れない
まなぶ「過去の台帳を耐量子の証明で固定できたら、口座も全部守られるんですよね?」
クリプ「履歴が改ざんされにくいことと、今の口座から不正送金されないことは別なんだ。履歴・口座・合意形成を一層ずつ確認しよう。」
Algorandの説明は、過去の履歴、現在の口座、将来の合意形成という三層で問題を整理しています。State Proofsが耐量子方式で過去の状態を証明できても、現在の口座が従来署名を使い続ければ、その口座の制御は別途守る必要があります。同様に、口座が安全でも合意用VRFがECC依存なら、完全移行とはいえません。
製品やプロジェクトの説明を読むときは、「耐量子技術を採用」という名称ではなく、守る対象、メインネットでの稼働状況、標準や監査、従来方式との共存期間、未解決部分を表にして確認すると誤解が減ります。
NIST標準の耐量子暗号は何を解決するのか
NISTは2024年8月に、ML-KEM、ML-DSA、SLH-DSAをそれぞれFIPS 203、204、205として公開しました。初心者がまず押さえる対比は、ML-KEMは通信の鍵共有、ML-DSAとSLH-DSAは署名という役割の違いです。事業者は標準名だけでなく、利用箇所と実装条件を対応させます。
ML-KEMは署名ではなく鍵共有の標準
ML-KEMは鍵カプセル化メカニズムです。通信相手と安全な共有秘密を確立する用途に使われ、取引を承認した本人を証明するデジタル署名そのものではありません。そのため、通信路をML-KEMで保護しただけで、ECDSA口座の量子リスクが消えるわけではありません。
ブロックチェーン事業者には通信、API、内部システム、バックアップなど鍵共有が必要な場所もあります。そこでML-KEMは重要ですが、口座や合意の認証には署名規格を別に選ぶ必要があります。「PQC対応」という説明を見たら、鍵共有と署名のどちらを指すか確認します。
ML-DSAとSLH-DSAという二つの署名選択肢
ML-DSAは格子問題を基盤にするデジタル署名で、FIPS 204として標準化されました。SLH-DSAはハッシュベースで状態を持たない署名で、FIPS 205です。異なる数学的な基盤を持つ選択肢があることは、用途、性能、リスク分散を考えるうえで意味があります。
ただし「NIST標準だから、どのブロックチェーンにもそのまま最適」とは限りません。公開鍵と署名のサイズ、検証コスト、集約のしやすさ、ハードウェア対応、実装時のサイドチャネル対策などが異なります。標準への準拠と、チェーン上で安全かつ効率的に運用できることは、別々に検証します。
補足:追加署名方式の評価が続く理由
NISTが確定標準を出した後も、追加デジタル署名方式の評価は続いています。これは確定済み標準が直ちに無効だという意味ではありません。署名サイズ、検証速度、異なる数学的基盤など、ML-DSAを補完する特性を持つ方式を増やし、幅広い用途へ対応するためです。
また、候補方式が撤回されたニュースを、確定済みのML-KEMやML-DSAまで破られたと読み替えてはいけません。候補、標準、利用中の実装を区別し、どの方式のどの版に問題があったのかを確認します。暗号アジリティが必要なのは、標準化後も研究と実装の知見が更新されるからです。
耐量子暗号への切り替えが単純な置換で済まない理由
従来の署名関数名をPQCの関数名へ差し替えるだけでは移行できません。トランザクションの容量、ブロックの処理量、検証者の計算負荷、鍵の保管、外部ライブラリ、ハードウェア、監査手順まで影響が広がります。互換性を維持しながら段階的に切り替える設計が必要です。
鍵と署名の大型化が性能に与える影響
耐量子署名は、現在広く使われる楕円曲線署名と比べ、公開鍵や署名が大きくなる場合があります。Algorandのロードマップも、Falcon署名がEd25519より大きいという制約を明示しています。取引一件の増加が小さく見えても、ネットワーク全体ではブロック容量、伝播時間、保管量、手数料設計に影響します。
また、署名をまとめて検証する仕組みや、ゼロ知識証明を介して検証負荷を抑える研究も関係します。Ethereum Foundationが複数の耐量子署名集約や新しい合意クライアントを支援しているのは、アルゴリズムの安全性だけでなく、チェーン上での実用性を解く必要があるためです。
補足:新実装の欠陥とサイドチャネルに備える
数学的に耐量子と評価される方式でも、実装が秘密情報に応じて処理時間やメモリアクセスを変えれば、サイドチャネルから鍵情報が漏れるおそれがあります。乱数生成、鍵の削除、エラー処理、依存ライブラリにも通常のソフトウェア脆弱性が入り得ます。
したがって移行では、標準名だけでなく、利用する実装の版、監査、テストベクトル、鍵生成環境、ハードウェア対応、更新方法を管理します。新方式へ一斉に切り替え、後戻りできなくするより、限定環境で測定し、問題時に切り戻せる段階を置く方が運用リスクを管理しやすくなります。
暗号アジリティとハイブリッド移行を組み込む

まなぶ「暗号アジリティって、いちばん強い暗号を一度選ぶことですか?」
クリプ「一度きりの選択ではなく、方式を安全に追加・交換・廃止できる設計のことだよ。将来の標準変更にも備えられるんだ。」
暗号アジリティとは、特定方式をコードや口座へ固定せず、識別子、検証ルール、鍵更新、互換期間を設計して、別方式へ切り替えられる能力です。新しい脆弱性や標準変更が起きたとき、チェーン全体を作り直さずに対応するための土台になります。
ハイブリッド方式では、従来暗号とPQCの両方を使い、移行初期に新方式だけへ依存するリスクを抑えます。Metaの移行事例は、暗号資産の棚卸しや外部依存の管理とともに、成熟途上の方式に備えてハイブリッドを優先する考えを示しています。ただし署名やデータが増えるため、性能と複雑性の代償も評価が必要です。
EthereumとAlgorandの耐量子ロードマップを比較する
これは投資優劣ではなく、2026年9月23日時点の公式資料に基づく実装範囲の比較です。Ethereumの基礎はEthereumとBitcoinの違い、合意層はPoSの仕組みも参照してください。
| 比較軸 | Ethereum | Algorand |
|---|---|---|
| 口座署名 | ECDSA依存。AAと暗号アジリティを移行経路として研究 | Falcon-1024口座をメインネット導入 |
| 合意署名 | BLS依存。検証後のハードフォークを計画 | 広範な量子耐性へ向け移行途上 |
| VRF | 公式資料上の主な比較対象は合意署名 | ECC依存が残り、耐量子VRFを研究中 |
| 履歴証明 | この資料群では個別の導入済み機能を確認せず | FalconベースのState Proofsを運用 |
| 本番導入 | 完全移行前。研究・devnet・仕様検討 | 口座と履歴証明は一部導入済み |
| 残課題 | 方式確定、性能、既存口座、合意層移行 | 既存口座、ウォレット対応、VRF・合意形成 |
Ethereumはアカウント抽象化を署名移行の経路にする
Ethereumの2026年優先課題では、ネイティブなアカウント抽象化(AA)が、ECDSAだけに固定された認証から別の署名方式へ移る自然な経路になり得ると説明されています。口座が認証ロジックを柔軟に持てれば、耐量子署名を追加し、利用者が鍵を更新する設計を取り込みやすくなります。
ただし、AAという言葉だけで耐量子化が完了するわけではありません。採用する署名方式、検証コスト、既存口座からの移行、ウォレットUI、紛失鍵や休眠口座の扱いを決める必要があります。ロードマップは経路を示すもので、全利用者の移行完了を保証するものではありません。
Ethereumの合意層は検証後のハードフォークを想定する
Ethereum Foundationの2026年9月の方針は、実行層で暗号アジリティを整え、合意層では十分に検証した耐量子方式をハードフォークで導入する計画を示しています。合意層は全検証者の相互運用に関わるため、候補を追加するだけではなく、ネットワーク全体のルール変更が必要です。
専任研究、週次devnet、署名集約、新クライアントへの支援は準備の具体性を示しますが、本番ネットワークが完全移行済みという証拠ではありません。今後は、仕様の確定、実装間の一致、性能測定、監査、フォーク時期、利用者向けの鍵移行手順を別々に確認します。
AlgorandはFalcon口座をメインネットに導入した
Algorand Foundationの進捗ページによれば、Falcon-1024を使う耐量子口座は、Algorand v5.0.0の承認後、2026年8月にメインネットで稼働しました。SDKやウォレット側の対応を含め、口座署名の選択肢を実装へ進めた点は具体的です。
一方、PQC口座を作れることと、既存の全口座が移行済みであることは違います。利用者が公式対応ウォレットを使い、鍵を安全に作成・保管し、必要な資産を正式手順で移す工程が残ります。署名サイズやマルチシグ対応などの運用制約も確認が必要です。ウォレットの基本的な選択肢はウォレットの種類と選び方で整理しています。
Algorandに残るVRFと合意形成の課題
Algorandの公式資料は、現在の合意形成で使うVRFがなおECCに依存し、耐量子VRFは研究・移行途上であることを示しています。つまり、Falcon口座とState Proofsがあっても、チェーンの全層が量子耐性を得たとはいえません。公式ロードマップは2027年末までの広範な量子耐性を目標にしていますが、目標年は保証ではなく、研究、監査、ガバナンス承認に左右されます。
この事例から学べるのは、先行実装を過小評価も過大評価もしない読み方です。「何もしていない」わけではなく、「完全に解決済み」でもありません。機能名、稼働環境、対象層、残存依存、次のマイルストーンを並べると、進捗を具体的に比較できます。
組織と利用者が今から進める耐量子移行の手順

実務の第一歩は、特定銘柄への売買や、未確認ツールへの鍵入力ではありません。自分たちがどの暗号をどこで使い、鍵を更新できるかを把握することです。NCSCは大規模組織向けに、2028年までの計画、2031年までの高優先度移行、2035年までの全面移行という目安を示しています。これは全ブロックチェーン共通の期限ではありませんが、棚卸しから始める段階設計の参考になります。
対象別:暗号方式と鍵の利用箇所を棚卸しする
【ウォレット・事業者】ウォレット、カストディ、取引承認、バリデーター、ノード間通信、API、VPN、証明書、バックアップ、コード署名、供給業者を一覧にします。それぞれについて、アルゴリズム、鍵長、ライブラリ、保管場所、所有者、更新期限、データを守る必要がある期間を記録します。ブロックチェーン上の署名だけに絞ると、運用基盤の依存を見落とします。
【個人利用者】使っているチェーンとウォレット、ハードウェアウォレットの機種、同じアドレスや鍵の再利用、復元用シードの保管、公式更新情報の確認先を整理します。秘密鍵やシードフレーズそのものを表計算やクラウドへ書き出す必要はありません。棚卸しは「鍵の所在と更新方法」を管理するもので、秘密情報を露出させる作業ではありません。
対象共通:公開鍵露出と更新困難性で優先順位を付ける
優先度は、保有額だけで決めません。公開鍵が露出しているか、同じ鍵を長期間使うか、資産や署名の有効期間が長いか、更新に全利用者の操作が必要か、ハードフォークが必要か、代替実装があるかを評価します。更新が難しく影響の大きい箇所ほど、早く設計と試験を始めます。
「今収集して後で解読する」問題は、長期間秘密にしたい通信データで特に重要です。対して公開台帳の口座署名では、将来公開鍵から秘密鍵を導かれ、資産を動かされる問題が中心になります。同じ量子脅威でも、守る対象と時間軸が違うため、対策を一括りにしません。
事業者・運営側:製品とガバナンスの計画を確認する
【ウォレット・事業者】ウォレット提供者には、対応予定の署名方式、既存端末の更新可否、鍵生成とバックアップ、移行トランザクション、手数料、マルチシグ、復旧方法を確認します。カストディやクラウド、HSM、ライブラリの提供者についても、製品のロードマップ、サポート期間、監査、障害時の責任分担を調べます。
【プロトコル運営側】仕様提案、テストネットまたはdevnet、監査、ガバナンス投票、ハードフォーク、旧方式の停止条件を追います。公式ブログに目標年が書かれていても、自動的に実装されるわけではありません。NCSCのワークショップ報告が示すように、PQC移行は技術だけでなく、予算、長寿命機器、供給網、経営支援を含む組織課題です。
対象共通:公式実装を検証しながら段階的に移行する
- 検証環境を作る:標準準拠の実装と公式テスト環境で、鍵生成、署名、検証、復旧、性能を測ります。
- ハイブリッドまたは限定導入を試す:重要度の低い経路から始め、従来方式との相互運用と監視を確認します。
- 正式手順を文書化する:対象口座、承認者、バックアップ、ロールバック、問い合わせ先、フィッシング対策を明確にします。
- 段階的に本番へ広げる:少額・少数から開始し、署名失敗、手数料、遅延、ウォレット表示を監視します。
- 旧方式の終了条件を決める:十分な移行率と検証を確認し、ガバナンス手続きを経て旧方式を制限または廃止します。
利用者に公式な移行機能がまだ提供されていない段階では、秘密鍵を第三者へ渡したり、非公式トークンへ交換したりしないことが重要です。Circle Researchも、鍵の棚卸し、鍵更新、PQC対応ウォレットの準備を挙げていますが、具体的な操作は各チェーンとウォレットの正式な案内に従う必要があります。
まとめ:急いで売買するより、移行できる状態を作る
- 今しないこと:見出しだけで資産を売買せず、非公式ツールへ秘密鍵やシードフレーズを入力しません。
- 今確認すること:利用中のチェーンとウォレット、公開鍵の露出、鍵の再利用、更新可否、公式情報の確認先を棚卸しします。
- 公式機能が出たらすること:仕様、監査、対応端末、復旧手順を確認し、少額・少数から段階的に移行します。
技術の進展と投資価値は別です。本稿は技術・運用情報であり、特定の金融商品の売買を推奨しません。資産操作は各プロジェクトと利用サービスの正式な案内を確認してください。
