社内システムの監査で「通信は暗号化されていますか」と聞かれ、「TLS で暗号化しています」と答える。これで通っていたやり取りに、ここ1〜2年で追加の問いが付くようになりました。「そのデータは何年保管しますか」です。
この2つが組み合わさると、答えが変わります。今日の暗号で守られた通信を今日盗んでも読めませんが、保存しておいて将来の計算機で復号する、という手口が前提に入ったからです。 設計図、契約書、人事情報、医療記録のように保管期間が10年を超えるものは、いま暗号化していても「将来読まれない」保証がありません。
大企業の話に聞こえますが、実際に効いてくるのは取引先から要件として降りてくる形です。
「今盗って、後で読む」が現実の脅威として扱われ始めた
ポスト量子暗号への移行が急がれている理由は、量子計算機が明日完成するからではありません。保存しておけば後で読める、という性質のほうが問題だからです。
現在広く使われている公開鍵暗号は、十分な規模の量子計算機があれば破れる、という前提で標準化作業が進んでいます。米国 NIST は移行の指針を公開しており、金融・医療・公共分野を中心に、調達要件へ反映され始めています。
日本の中小企業にとって現実的な影響は次の順で来ます。
- 取引先のセキュリティチェックシートに項目が増える。 「ポスト量子暗号への移行計画がありますか」という設問が入る
- 公共・金融系の案件で要件化される。 システム開発の仕様書に暗号方式が明記される
- 自社の判断で移行する。 ここに至るのは最後です
つまり、多くの会社にとっては自発的な技術投資ではなく、答えられないと困る質問への準備です。この位置づけを間違えると、今やるべきでない範囲まで手を広げることになります。
移行の順番は「寿命の長いデータ」から
移行というと、まず TLS を新しい方式に切り替える話から入りがちです。実際には逆で、認可の仕組みより、長く生きるデータのほうが優先度が高いという整理になっています。
理由は単純です。今日のログインセッションは数時間で失効します。いま盗まれても、10年後に復号できた頃には何の価値もありません。一方、契約書ファイルや設計データは10年後も価値があります。
| データの種類 | 寿命 | 移行優先度 |
|---|---|---|
| 保管文書・設計データ・人事記録 | 5〜30年 | 高 |
| サービス間の認証トークン・API キー | 数ヶ月〜数年 | 中 |
| ログインセッション | 数時間 | 低 |
真ん中の「サービス間の認証トークン」は見落とされがちです。利用者のログインセッションと違い、システム同士をつなぐ認証情報は数年単位で更新されないまま動き続けていることがあります。棚卸しの際は、ここを一緒に見てください。
実装は、思ったより手前まで来ている
「新しい暗号方式に対応するには、専用のライブラリを入れて検証して……」という想像より、実際の作業は軽くなりつつあります。
Java の場合、JDK 24 以降であれば、格子ベースの鍵カプセル化方式（ML-KEM）と署名方式（ML-DSA）を、標準の暗号 API から追加ライブラリなしで呼べます。 つまり移行作業の相当部分が「JDK を上げる」に置き換わります。
InfoQ が整理している Spring Boot 向けの実装パターンは4つで、いずれも既存構成を大きく壊さずに入る範囲です。
- サービス間でやり取りするデータ本体の暗号化
- データベースの特定カラムの暗号化
- 長期保存する文書への署名
- サービス間トークンの署名方式の切り替え
ここで注意すべき点が1つ挙げられています。カラムを新しい方式で暗号化すること自体は難しくない。難しいのは、その鍵をアプリケーションのメモリ上に置かない設計にすることです。鍵がプロセス内に平文で存在すれば、暗号方式を新しくしても守れる範囲は変わりません。移行の議論が方式の名前だけで進んでいるときは、鍵の置き場所を必ず確認してください。
中小企業が今やるべき範囲
全部やる必要はありません。現時点で費用対効果が見合うのは次の3つです。
1つ目は、暗号の棚卸し。 自社システムがどこで何の暗号を使っているかの一覧を作ります。TLS、データベース暗号化、ファイル保管、外部 API との認証。これがないと移行計画は書けませんし、チェックシートに答えるにも結局この一覧が必要になります。
2つ目は、保管期間の確認。 各データが何年保管されるかを整理します。1つ目と突き合わせれば、優先順位は自動的に決まります。
3つ目は、実行環境の更新計画。 Java なら JDK、その他の言語でも同様に、新しい方式が標準で入ってくるバージョンに上げられる状態を作っておく。ここが止まっていると、必要になった時点で手が出せません。業務システムの保守費用を見直すタイミングがあれば、この更新計画を一緒に載せておくのが現実的です。
逆に、今すぐ全システムの暗号方式を切り替えるのは、多くの中小企業にとって早すぎます。 標準や実装は動いている最中で、先に切り替えたものを後で直す作業が発生し得ます。
「対応しています」と言えるようになるまで
セキュリティチェックシートで問われたときに書けることは、実務上は次の水準で足ります。
- 自社システムで使用している暗号方式を把握している
- データごとの保管期間を把握している
- 移行の優先順位と、着手時期の目安がある
「移行完了しています」ではなく「計画があります」で通る段階です。逆に、一覧も計画もない状態で「検討中です」と書くと、次の質問で詰まります。
証明書の更新作業が短期化して運用が変わったときと構図は同じです。サーバー証明書の管理がそうだったように、一覧がある会社は対応でき、ない会社は毎回慌てるという差になって表れます。
次にやること
まず、自社の主要システムで使っている暗号の一覧を1枚作ってください。 完璧である必要はありません。「どこで、何を、何のために暗号化しているか」が3行ずつ書ければ十分です。
そのうえで、保管期間が10年を超えるデータがあるかを確認してください。 あるなら、そこが最初に移行を検討する対象です。なければ、当面は実行環境の更新計画だけで足ります。
既存システムの暗号構成の棚卸し、実行環境の更新計画、セキュリティ要件への対応については、グリームハブの開発・AI・自動化のご相談で承っています。システム構成と取引先要件によって必要な範囲が変わるため、個別にご相談ください。お問い合わせからどうぞ。
