ベンダーのPQC対応をどう確かめるか ― タイSECの量子リスク・ガイドに沿った質問、優先順位、TOR・契約条項
タイSECの量子リスク・ガイド第7章とツール4に沿い、ベンダーへのPQC質問、優先順位の付け方、TORの6項目を整理。契約更新前のベンダー確認に。
ベンダーのPQC対応をどう確かめるか ― タイSECの量子リスク・ガイドに沿った質問、優先順位、TOR・契約条項
架空の例です。タイの証券会社のIT部門が、バックオフィス・システムのベンダーに量子リスクへの備えを問い合わせました。返信は「当社製品はPQCに対応済みです」の一行だけ。チームはそれをリスク登録簿に添付し、案件を閉じました。
タイ証券取引委員会(SEC)が2569年(2026年)9月に公表した量子リスク・ガバナンスの手引き(以下、ガイド)に照らすと、これでは足りません。サプライチェーン・リスクを扱う第7章は、対応済みの一言で済ませず証拠を求めるよう勧めています(22ページ)。
耐量子計算機暗号(PQC)は、従来型コンピュータと量子コンピュータの双方による攻撃に耐えるよう設計された暗号です(38ページ)。TOR(Terms of Reference)は、業務の範囲を定める文書を指します(22〜23ページ)。
要点: ベンダーを影響度で順位付けし、バージョン、規格、試験結果、制約、利用可能日を示す証拠を求める。条件は選定前にTORへ書き込み、重要な契約更新の前に主要ベンダーの状況を1枚で取締役会に示す。
なお、ガイドは法令ではなく指針です。ガイド自身が法的な要件ではないと明記しており(PDF 2ページ)、期限も課していません。ガイド全体の構成は本シリーズのメイン記事にまとめています。
自社の準備だけでは足りない理由
クラウド、パッケージソフト、売買・決済システム、鍵保護装置、証明書、外部接続は、いずれも外部事業者の暗号の上で動いています。ガイドは、主要な事業者の移行が遅れれば、自社の準備が整っていてもリスクが残り、サービスを提供できなくなるおそれもあると指摘します。リスクは事業者に移りません。明確な回答がなければ、リスクとして記録し、フォローアップ日を決めるよう勧めています(22ページ)。
第5章も、暗号利用の台帳(CBOM)にはクラウド、API、ベンダー製機器など自社が直接管理しないものを含めるべきだとしています(17ページ)。資産台帳の見直しについては、資産管理とランサムウェア対策の記事も参考になります。CBOMの始め方はCBOMとクリプト・アジリティの記事で解説しています。
まず順位付け:詳しく確認すべきベンダーはどこか
ガイドは、サービスの重要度や事業への影響に応じて評価の厳しさを調整せず、全事業者に同じ評価を行うことを避けるよう勧めています(23ページ)。まずクラウド、基幹システム、売買・決済システム、証明書事業者、鍵管理装置、API接続先など、遅れが事業に大きく響く事業者から始め、複数の要素で順位を付けます(22ページ)。公開Webサイトの認証局もここに入ります。外部に何を公開しているか不明なら、外部アタックサーフェスの把握から始めるとよいでしょう。右列は筆者による例で、ガイドの記載ではありません。
| ガイドの要素(22ページ) | 資本市場での例 |
|---|
| サービスの重要度 | 注文の受付・回送、決済・受渡し |
| 事業者がアクセスするデータ | KYCファイル、長期保存する顧客の売買記録 |
| デジタル署名・本人確認の利用 | オンライン口座開設、取引確認書への署名 |
| 事業者を切り替える難しさ | 全社の業務に結び付いた基幹システム |
| 事業者が製品更新に要する期間 | ファームウェア更新や交換が必要な機器 |
ガイドは各要素の重みを定めていません。優先順位の付け方は、自社のリスクに応じて決めてください。目指すのは、相手の遅れがそのまま自社の遅れになるベンダーの短いリストです。
ベンダーに送る質問
22ページは、事業者について最低限知るべき5項目を挙げています。23ページは、CBOM未作成や営業秘密の制約により、完全なCBOMを入手できる相手が一部の事業者に限られる場合があると説明し、代わりにリスク評価に必要な最低限の情報を定めるよう勧めています。例は、暗号アルゴリズムの役割、対応規格、製品バージョン、更新予定、自社で対応すべき部分です。両方を7つの質問にまとめました(中央の列は筆者の表現)。
| ベンダーへの質問 | 求める証拠 | ページ |
|---|
| 1. どの製品バージョンがどの規格に対応しているか | バージョン名と規格番号 | 22, 23 |
| 2. 製品内で暗号は何に使われているか | 鍵交換、署名など | 23 |
| 3. ソフトウェア、ファームウェア、機器の変更は必要か | 更新で済むか、機器交換か | 22 |
| 4. どのシステムで試験したか | 試験結果と試験環境 | 22 |
| 5. 性能と互換性の制約は何か | 速度や接続先システムへの影響 | 22 |
| 6. 実際に使えるのはいつか | 製品バージョンに紐づく日付 | 22, 23 |
| 7. 自社で対応すべき部分はどこか | 設定変更、証明書の再発行など | 23 |
zcr製品の料金は料金ページへ。
質問1では規格番号を求めましょう。ガイドはNISTのFIPS 203〜205を最初のPQC規格としています(9、38ページ)。2024年8月13日に公表したNISTによれば、FIPS 203は共有秘密鍵を確立するML-KEM、FIPS 204(ML-DSA)とFIPS 205(SLH-DSA)は署名の規格です。これらの名称はNISTによるもので、ガイドには出てきません。
CISA、NSA、NISTのQuantum-Readinessファクトシート(2023年8月)は、製品に組み込まれた暗号は検出ツールで見つからない場合があるため、ベンダーに一覧を求めるべきだとし、PQC更新の時期、方法、想定費用の確認も促しています。
回答の読み方:確認済み、一部確認、未確認
付録กのツール4は、各ベンダーのPQC対応計画を確認済み・一部確認・未確認で記録し、対応可能日を記入する様式です(36ページ)。区分の定義はありませんが、第7章の2つ目の問いが目安になります。証拠に製品バージョン、対応規格、試験結果、顧客側の対応、利用可能日がすべてそろっているかを問うものです(24ページ)。
筆者の提案であり、ガイドの定義ではありません。5項目は情報の不足を確認するために使い、担当者が証拠、製品バージョン、試験範囲、自社システムでの利用可能日を確認してから状況を判断してください。項目が埋まっているだけでは、対応準備を確認したことにはなりません。この基準についてのご相談は私たちのチームへ。ベンダー評価の実作業はパートナーを通じて提供します。
回答は23ページが勧めるとおりCBOMと結び付け、どのベンダーの遅れがどのシステムに響くかを見えるようにします。
TOR・契約・契約更新
ガイドは、すべての新規調達で要件定義の段階からPQCとクリプト・アジリティへの対応を基準に含める方針を取締役会が定めるよう勧めています。調達・法務・システム所有部門が共同で担当し、方針の実施状況を取締役会へ定期的に報告することも勧めています(22ページ)。
重要なサービスについては、TORまたは契約の条件が少なくとも次の6項目を含むべきだとしています(22〜23ページ)。
- ベンダーが対応すべき規格と製品
- 納期と製品の更新計画
- ベンダーが計画を変更する場合の事前通知
- 共同での試験
- 情報を求める権利、またはレビューを行う権利
- ベンダーが期日までに提供できない場合の対応方針
条件の厳しさはサービスの重要度に合わせるべきだとしています。示されているのは項目で、契約文言は各社の法務部門の仕事です。先にベンダーを選んでPQCの交渉を後回しにすると交渉力が弱まるおそれがある、という注意もあります(23ページ)。
既存ベンダーでは契約更新が機会です。ツール4は経営陣が取りまとめて確認し、ツール3と同じ報告サイクルかつ重要な契約更新の前に提出するもので、更新日の欄と契約条件の見直しという選択肢があります(36ページ)。第9章は移行計画と契約更新サイクルの結び付きを(28ページ)、第5章は更新時のCBOM更新の仕組みを問うています(19ページ)。筆者からの実務上の提案として、契約更新を機に調達・法務部門で6項目を見直し、サービスの重要度に応じて条件を調整してください。
代替策:ベンダーが間に合わないと言う前に決めておく
23ページは、主要な事業者の代替策と判断ポイントを事前に定めた証拠を求めるよう取締役会に勧めています。選択肢の例は、利用データやサービスの限定、接続の分離、暫定措置、製品更新の前倒し、代替事業者の準備で、それぞれの影響、費用、期間、決裁者を事前に評価します。ガイドは、業界での協力によって評価の重複を減らせる可能性があるとしています。複数社が同じ事業者に依存する場合には、協力を検討する余地があります。
ツール4:取締役会が見るべき1枚
ツール4は、移行の遅れが重要なシステムやサービスに響く主要ベンダーを1ページにまとめる様式です(36ページ)。計画上の主な制約と取締役会への要請事項の欄に加え、表は5列です。
| 列 | 記入内容 |
|---|
| ベンダー・事業者名 | 名称、担当者 |
| 依存するシステムと依存度 | システム名、高・中・低 |
| PQC対応計画と対応可能日 | 確認済み・一部確認・未確認、日付 |
| 間に合わない場合の影響・代替策・契約更新日 | 影響、代替策、更新日 |
| 緊急度と提案事項 | 高・中・低、期限の設定、代替策の承認、契約条件の見直し、リスク受容の検討 |
注意点として、ツール4の記入例は架空の会社で、ツール3のダッシュボード例にあるベンダーへの期限も例示です。ガイドはこれらの数値がSECの要件や期待ではないと注記しています(34ページ)。様式だけを使い、期限は自社で決めてください。
よくある質問
SECはベンダーのPQC対応に期限を設けていますか?
いいえ。ガイドにある2026〜2035年はタイ国家サイバーセキュリティ庁(NCSA)の枠組み案によるもので、ガイドは各社が整合を検討し得るという書き方です(2、27ページ)。
ベンダーがCBOMを出さない場合は?
最低限の情報を求め(23ページ)、それでも回答がなければリスクとして記録し、フォローアップ日を決めます(22ページ)。
今月から始めること
- 契約台帳から5つの要素で主要ベンダーを絞り込む
- 自社で決めた回答期限を付けて7つの質問を送る
- 回答をツール4の形式で記録し、CBOMと結び付ける
- 更新日を並べ、TORの6項目を調達・法務に渡す
- ベンダーのPQC計画とは別に、開発チームがnpm、PyPI、Go、Mavenから取り込むソフトウェア依存関係の出所も確認してください。zcrXのサプライチェーン・ポスチャーは、Agentを導入したホストとビルドシステムで、依存関係の出所を暗号学的な証明またはAgentによる証明で検証し、Agentのないホストは安全とみなさず未計測と表示します。対象はソフトウェアの依存関係で、ベンダーのPQC計画ではないため、1〜4は引き続き貴社とパートナーの仕事です。zcrXの測定範囲は、PQC移行準備のページにまとめています。
本シリーズの関連記事: タイSEC量子ガイドの取締役向け解説 ・ CBOMとクリプト・アジリティ
お問い合わせ
どのベンダーから確認を始めるべきか、お気軽にご相談ください。無料でご相談いただけます。zcrが提供するのはソフトウェアで、評価、導入、移行計画の実作業はパートナーを通じて提供します。
出典
- タイ証券取引委員会(SEC)IT リスク監督・検査部門 — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท、2569年(2026年)9月(タイ語)— 第7章(22〜24ページ)、付録กツール3〜4(34、36ページ)、第5章(17、19ページ)、第9章(27〜28ページ)、位置付けに関する記載(PDF 2ページ)。2026年10月27日閲覧
- CISA、NSA、NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography(2023年8月21日) — 製品に組み込まれた暗号、更新時期と費用の確認。2026年10月27日閲覧
- NIST — FIPS 203、FIPS 204、FIPS 205 — 規格名、アルゴリズム名、2024年8月13日の公表日。2026年10月27日閲覧
