PQC前倒し時代の企業対応: Android・認証基盤を軸にした2029移行ブループリント

Googleの量子耐性暗号（PQC）移行前倒しに関する報道は、PQCが「将来検討」ではなく「今期から準備すべき実務」へ変わったことを示しています。特にAndroid端末群と認証基盤を抱える企業では、2026〜2029を段階移行期間として設計する必要があります。

参考: https://www.itmedia.co.jp/news/articles/2603/26/news108.html

“標準が全部そろってから”では遅い理由

PQC移行を後ろ倒しすると、最後に次の問題が集中します。

一斉更改による運用負荷の急騰
障害時ロールバックの複雑化
例外申請の乱発による統制劣化

理想は、ハイブリッド方式を使って平時から段階的に切り替えることです。

先に作るべきは暗号資産台帳

アルゴリズム選定より先に、どこで暗号を使っているかを可視化します。

端末〜サービス間通信（TLS終端、証明書ピンニング）
アプリ署名・配布経路の真正性
OIDC/SAML/セッショントークンなどID連携
サービスメッシュ・SDK内の鍵交換
長期保管データ（将来解読リスク）

台帳がないと、見える箇所だけ更新して、古い通信経路が残存します。

Android運用で見落としやすい制約

OS更新が遅いロングテール端末
固定実装のサードパーティSDK
ストア審査を含むリリース周期
MDMポリシーとハイブリッド証明書運用の衝突

つまり、サーバ側だけの準備では不十分です。端末ライフサイクルと一体で設計する必要があります。

推奨する3段階移行モデル

Phase 1: ハイブリッド接続の実装（今すぐ）

可能な通信経路でハイブリッド鍵交換を有効化
モバイル回線下で遅延・再送影響を計測
どの暗号スイートで接続されたかを可観測化

Phase 2: 制御プレーン強化（1〜2年）

内部PKIと証明書更新自動化の刷新
メッシュ/ゲートウェイ既定値の更新
CIで暗号設定の準拠チェックを義務化

Phase 3: 旧方式の計画的廃止（目標年次）

非準拠ネゴシエーションの遮断
旧トラストアンカーと例外証明書の失効
リリースゲートで暗号準拠を強制

優先順位は「リスク×業務影響」で決める

2軸で評価すると実装順が明確になります。

暗号露出リスク（認証・決済・規制対象）
業務影響（停止時の売上/運用ダメージ）

高×高から着手することで、限られた移行工数を最大効率で使えます。

性能とUXの同時管理

PQCはハンドシェイクサイズや計算負荷が増える可能性があります。以下をSLOとして監視します。

ログイン遅延の中央値/p95
バッテリー消費増分
パケットロス時の再試行挙動
ピーク時ゲートウェイCPU余力

安全性だけ上げて体験品質を落とすと、現場は例外運用に逃げます。

監査対応は証跡の自動収集で

監査では「何を使っているか」だけでなく「弱い設定をどれだけ早く除去できるか」が問われます。

許可アルゴリズムポリシーの版管理
環境別適用範囲
例外の責任者と期限
失効・ローテーション履歴

この証跡を継続収集できれば、PQC移行は監査負債ではなく統制強化の機会になります。

まとめ

PQC移行は暗号チーム単独プロジェクトではありません。モバイル開発、ID基盤、プラットフォーム運用、監査対応をひとつのロードマップに統合することが成功条件です。将来リスクを下げつつ、現在の運用品質を崩さない設計が重要です。