PQC（耐量子暗号）移行の話をシステム部門に持ち込むと、ほぼ必ず返ってくる反応があります。「それ、今やる必要あるの？」
私たちはこの問いに、何度も答えてきました。うまく答えられなかったこともあります。この記事では、実際に言われた言葉、通じなかった説明、通じた説明、そして最終的に相手を動かしたものを、順番に書きます。
相手は主に、システム部門・基盤部門の管理職や実務責任者でした。彼らが求めていたのは「必要性」の講義ではなく、次年度に何を予算化し、どこまで実施すれば説明責任を果たせるのかという、きわめて具体的な答えでした。
実際に言われた3つの言葉
説明の場で返ってきた反応は、おおむね次の3つに集約されます。
- 「2030年頃からやればいいのでは」
- 「対応製品がそろってから調べればよいのでは」
- 「PQC対応が終わったら、クリプト・インベントリは捨ててよいのでは」
クリプト・インベントリ（暗号インベントリ）とは、自社のどのシステムが、どこで、どの暗号方式を使っているかを洗い出した台帳のことです。PQC移行は、この台帳づくりから始まります（暗号スキャンの現場の記事）。
ここで強調しておきたいのは、これらが無知や怠慢から出た反応ではないことです。どれも半分は正しい。大規模な量子コンピュータの実用化時期は誰にも断言できず、製品側の対応はまだ途上で、台帳の維持には人手がかかります。だから「その認識は間違っています」と正面から返しても、相手は動きません。相手が本当に聞いているのは、「いつ・何を・どこまでやるのか」だからです。
通じなかった説明——技術論と、危機感
最初のころ、私たちの説明は2つの型のどちらかに寄っていました。どちらも通じませんでした。
- *ひとつは、技術論から入る説明です。**耐量子のアルゴリズムはどれか、暗号スイートをどう構成するか、ハイブリッド方式とは何か。正確に説明しようとするほど、議論は「対象範囲はどこまでか」「どの方式を採るか」という細部に流れていきます。話が終わるころには、「結局、何をいつ決めればいいのか」という経営判断との接続が切れていました。技術の話は判断の材料として後で必要になりますが、入口に置くと出口を見失わせます。
- *もうひとつは、危機感を前面に出す説明です。**HNDL——Harvest Now, Decrypt Later、つまり今のうちに暗号化された通信を大量に盗んでおき、量子コンピュータが実用化された後に解読する攻撃——の話や、各国の規制・ガイドラインの動向を並べて、「待ったなし」を伝える型です。
これは着手の理由にはなります。しかし危機感だけを渡すと、相手は「では、全部すぐに対応するのか」という過剰な結論に飛びます。そして予算も人も足りないことに気づき、「無理だから、やはり後で」に戻ってしまう。危機感は、着手の順番と範囲を決めてくれません。実務上の答えになっていなかったのです。
通じた切り分け——今やることと、更改に合わせてやること
転機になったのは、説明の中心を一つの切り分けに絞ったことでした。
- *今やるのは「全システムをPQCへ切り替えること」ではない。今やるのは対象の把握と優先順位付けで、実際の移行は、製品の成熟度とシステム更改のタイミングに合わせる。**
この切り分けは、相手の3つの反応のうち2つに同時に答えます。「2030年からでいいのでは」には、移行そのものは急がなくてよい、と同意できる。「製品がそろってからでは」にも、実移行は製品を待ってよい、と同意できる。そのうえで、「ただし、把握と計画は今でないと間に合わない」と続けられます。
このとき最も効いたのが、道路のたとえでした。
- *更改を待たずに一度改修し、その直後の更改でもう一度改修するのは、同じ道路を短期間に二度掘り返すようなものです。**だから、今すぐ全面移行はしない。しかし、次の更改で一緒に埋めるためには、掘る場所と順番を今のうちに決めておかなければならない。だから、今から計画する。
この一言で、「今から計画する理由」と「今すぐ全面移行しない理由」を、同時に説明できました。相反するように聞こえる2つの主張が、一つの絵に収まったのです。
3つ目の反応——「終わったら台帳を捨ててよいか」——にも、ここから答えられます。捨てません。暗号方式には寿命があり、過去にもハッシュ関数や短い鍵長のRSAが段階的に退役してきました（ハッシュ関数の記事）。PQC移行は「最後の入れ替え」ではなく、暗号を入れ替えられる組織になる最初の機会です。台帳はそのための恒久的な設備であって、一度きりの調査資料ではありません。
実作業に分解すると、時間が見える
切り分けに納得してもらえても、「把握と計画は今でないと間に合わない」の部分には根拠が要ります。ここで効いたのは、PQC対応を実作業に分解して見せることでした。
- 暗号の所在確認——どのシステムのどの通信・保存・署名に、どの暗号が使われているか。RSAだけでなく楕円曲線暗号も対象です。スキャンツールを回す前の段取りに時間がかかります
- ベンダー・外部接続先との調整——自社だけでは決められません。パッケージ製品の対応時期、取引先や決済網など外部との接続における方式の合意。相手の都合で1年単位の時間が動きます
- 性能検証——耐量子の方式は鍵や署名のサイズが大きく、通信量や処理時間に影響します。本番条件での検証が要ります
- 更改計画への組み込み——次の基盤更改やシステム刷新の要件に、PQC対応を織り込む。更改の要件定義が始まってからでは遅く、その前に入れておく必要があります
こう並べると、方式が固まってから始めても、短期間では終わらないことが見えてきます。
そして、問いの立て方が変わります。「量子コンピュータがいつ完成するか」ではなく、自社の棚卸し・予算化・更改・外部調整に何年必要かを起点に逆算するのです。仮に次の基盤更改が3年後なら、その要件定義は1年以上前に始まる。要件に入れるには、その前にベンダーと接続先の対応状況を確認しておく必要があり、確認するには、その前に自社の暗号の所在を把握していなければならない。こう遡ると、着手の時期は「今」になります。これは未来の技術論を、現在の経営課題に変換する手続きです。
決め手はロードマップだった
最終的に相手を動かしたのは、一枚のロードマップでした。
内容は単純です。リスクの高いシステムから現状把握を始め、実際の移行は、更改時期・製品の対応状況・外部接続先の状況に合わせて配置する。リスクの高低は、扱う情報の秘匿期間の長さ（HNDLの実害の大きさ）と、外部との接続の多さで決めます。
これは、リスクと経済合理性を両立させた計画です。全部を今やるのでも、全部を後回しにするのでもなく、「把握は前倒し、移行は更改に同期」という形で、掘り返しを一度に抑えます。
そして、ロードマップは相手が本当に求めていたものに答えていました。システム部門・基盤部門の責任者が必要としていたのは、必要性の説得ではなく、次年度に何を予算化するかと、どこまでやれば「把握している」と説明できるかの2つです。ロードマップの初年度に置いたのは、次の項目でした。
- 優先度の高いシステムからのクリプト・インベントリ作成
- 優先順位付けの基準（秘匿期間・外部接続・更改時期）の文書化
- 主要ベンダーへの対応時期の照会と、外部接続先への確認
- 次期更改計画への要件としての組み込み
ここまでやれば、監査や経営に対して「自社の暗号の所在と優先順位を把握しており、移行は更改計画に組み込み済み」と説明できる。このラインが見えたことで、予算の話が前に進みました。
この答え方の限界
この記事の答え方は、万能ではありません。書いておくべき限界が4つあります。
- *第一に、私たちが向き合ったのは経営層本人ではなく、システム部門・基盤部門の責任者です。**「今すぐ移行する必要はない。ただし今すぐ始める必要はある」という答えは、彼らが経営に持ち帰る言葉として組み立てたものです。経営層に直接説明する場では、別の翻訳が要るかもしれません。その反応を、私たちは間接的にしか知りません。
- *第二に、「更改に合わせる」が通用しないケースがあります。**数十年単位で秘匿が必要な情報を扱う通信は、HNDLの実害がそのまま出るため、更改を待たずに前倒しする判断があり得ます。次の更改が10年先の基幹システムや、外部接続先が多く調整に長期間かかる領域も同様です。ロードマップは固定の答えではなく、リスク評価の結果として形が変わります。
- *第三に、逆の場合もあります。**業務システムのほとんどがSaaSで、自社で暗号を実装していない会社では、やるべきことは「利用サービスの対応方針を確認し、記録する」に近く、この記事ほど重い話にはなりません。自社の状況を過大に見積もる必要はありません。
- *第四に、製品の成熟度の見立ては動きます。**標準化は済みましたが（NISTのPQC標準化の記事）、製品や接続先の対応には業界差があり、来年には前提が変わっているかもしれません。ロードマップは年1回は見直す前提で作るものです。
読者への持ち帰り——問いを入れ替える
経営への答え方として、私たちが最も実態に近いと考えている表現はこれです。
- *「今すぐ移行する必要はない。ただし、次の更改で手遅れにならないよう、今すぐ対象把握と計画策定を始める必要がある。」**
この一文が成り立つ根拠は、量子コンピュータの完成時期の予測ではありません。自社の作業に何年かかるかという、自社の側の事実です。問いを「量子はいつ来るのか」から「自社は何年かかるのか」に入れ替えると、議論は未来の技術論から現在の経営課題に変わり、予算と期限を持った計画として扱えるようになります。
手始めに、次の3つを書き出してみてください。
- 次の基盤更改・システム刷新はいつか
- 外部と暗号方式を合わせる必要がある接続先は何社あるか
- 自社の暗号の所在を把握するのに、何か月かかりそうか（棚卸しの実務）
この3つの数字から逆算した日付が、「いつやるの？」への、自社にとっての答えです。量子コンピュータが暗号を破る仕組みそのものはShorのアルゴリズムの記事に譲ります。ここで必要なのは、その日付を待つことではなく、自社の日付を決めることでした。
