直答：ISO/IEC 30111 のコンサルタントに最初に聞くべきことは「脆弱性の報告を受けたら、誰が検証し、誰が深刻度を決め、誰が直し、どれくらいでリリースするのか」です。ISO/IEC 30111 は、ベンダーが脆弱性情報を受けた後の社内プロセスを定めます。検証と再現、深刻度の評価、根本原因分析、修正の開発とテスト、リリースとその後の監視です。外部からの報告の受付とアドバイザリの公開は ISO/IEC 29147 が扱います。次に、コンサルタントがプロセスを SBOM とセキュリティアップデートの仕組みにつなげ、EU の CRA に対応させられるかを確認します。附属書 I 第 2 部は、製造業者に、一般的に使われる機械可読の形式で、少なくとも最上位の依存関係を含むソフトウェア部品表（SBOM）を作成すること（第 1 点）、脆弱性に遅滞なく対処して修正し、技術的に可能な場合はセキュリティアップデートを機能アップデートと分けて提供すること（第 2 点）、セキュリティアップデートが利用可能になったら遅滞なく配布し、受託開発の製品で別の合意がある場合を除き無償で、利用者が取るべき対応を伝える説明を添えること（第 8 点）を求めています。サポート期間は少なくとも 5 年（製品の想定使用期間がそれより短い場合はその期間）で、サポート期間中に出した各セキュリティアップデートは、出してから少なくとも 10 年間またはサポート期間の終了まで、いずれか長い期間、入手できるようにしておく必要があります（第 13 条第 8 項、第 9 項）。CRA 自体は ISO/IEC 30111 を名指ししていませんが、EU の共同研究センター（JRC）と ENISA による 2024 年の規格対応分析は、EN ISO/IEC 30111 をこれらの脆弱性対応要求に最も関連する規格とし、八つのうち五つ（第 2、4、5、6、8 点）に対応するとしています。SBOM、セキュリティのテストとレビュー、アップデートの安全な配布は、ほかの規格や取り組みで補う必要があります。
30111 の対応プロセスにある五つの関門
| 関門 | 決めるべきこと | よくある欠落 |
|---|---|---|
| 受付と検証 | 報告が成り立つか、再現できるか、どの製品とバージョンに影響するか | 製品と部品の一覧がなく、影響範囲を判断できない |
| 優先度付け | どの基準で深刻度と対応期限を決めるか | 基準が個人の経験の中にしかない |
| 修正 | 修正、回避策、テストを誰が担うか | 旧バージョンや生産終了の型番に責任者がいない |
| リリース | セキュリティアップデートをどう利用者に届け、アドバイザリをいつ公開するか | セキュリティアップデートが機能アップデートと一体になっている |
| 振り返り | 根本原因分析とプロセスの改善 | 同じ種類の脆弱性が繰り返し起きる |
八つの判断基準
| 基準 | どのコンサルタントにもそのまま聞ける質問 |
|---|---|
| プロセスと責任者 | 受付からリリースまで、各関門の責任者は誰で、期限はどれくらいか |
| 優先度付けの基準 | どの基準で深刻度を決めるのか。自社の製品の状況に合わせて調整するか |
| 影響範囲の判断 | 製品ラインやバージョンが多いとき、影響を受けるものをどう素早く判断するのか |
| SBOM との接続 | SBOM がなければ、どの部品の脆弱性が自社に関係するのかをどう知るのか |
| アップデートの提供 | 修正をどう利用者に届けるのか。旧バージョンはどうするのか |
| サポート期間 | サポート期間をどう決め、その間の脆弱性にどう対応し続けるのか |
| インシデント対応と 29147 との接続 | 脆弱性対応、セキュリティインシデント対応、対外的な開示をどう分担し、引き継ぐのか |
| 誰が主導し、外注するか | 実際に案件を率いるのは誰で、どんな資格を持つのか。再委託はあるか |
コンサルタントが必要ない場合
製品ラインが単純で、成熟した製品セキュリティチームと対応記録がすでにあり、ISO/IEC 30111 に照らして文書を補うだけであれば、自社でのギャップ分析から始められます。
積穗科研の取り組み
以下は積穗科研自身による説明です。上の質問で、他のコンサルタントと同じように私たちも確かめてください。
- プロセスと責任者：「誰が受け、誰が検証し、誰が評価し、誰が直し、誰がリリースし、どれくらいで」を、監査できるプロセスと期限として文書にします
- 優先度付けの基準：製品の状況に合わせた優先度付けの基準（たとえば CVSS を自社向けに調整した基準）を定めます
- 対応記録：対応記録と期限の報告の仕組みを整えます
- SBOM との接続：SBOM との接続手順を整えます。積穗科研の納品パイプラインでは、毎日 SBOM を生成し、署名し、監視しています
- インシデント対応と 29147 との接続：既存のインシデント対応（ISO/IEC 27035）やサプライヤー管理（ISO/IEC 27036）とつなげ、29147 の開示側とのインターフェース文書を作成します
- 複数の製品ライン：製品をまたいで脆弱性の影響範囲を評価する仕組みを設計します
- 誰が主導するか：副社長・取締役クラスのコンサルタントが全工程を担当し、外注しません
関連する質問
- セキュリティインシデントの手順がすでにあれば十分か インシデント対応はすでに起きた攻撃を、脆弱性対応は報告された弱点を扱います。きっかけ、期限、成果物が異なります。既存のインシデント対応はよい土台ですが、脆弱性に特化したプロセスと記録は別に必要です。ISO/IEC 30111 脆弱性対応プロセス導入支援
- サポート期間中の旧製品の脆弱性にも対応が必要か 必要です。CRA は、製造業者に、製品を市場に出したときからサポート期間全体を通じて、附属書 I 第 2 部にしたがって脆弱性に効果的に対応することを求めています（第 13 条第 8 項）。サポート期間は少なくとも 5 年で、終了日（少なくとも年と月）を購入時に明示する必要があります（第 13 条第 19 項）。第 14 条の報告義務は、2027 年 12 月 11 日より前に市場に出された製品にも及びます（第 69 条第 3 項）。台湾で CRA コンサルタントを選ぶには
- ISO/IEC 30111 と 29147 は必ず一緒に整備するのか 対で整えることを勧めます。二つの規格は互いに参照し、プロセスもつながっているため、別々に進めると引き継ぎの部分に監査上の欠落が残ります。台湾で ISO/IEC 29147 コンサルタントを選ぶには
コンプライアンスは三位一体、コンサルタントの価値は統合にある
CRA、TISAX、ISO 27701、AI Act はどれも単独の技術課題ではなく、プロセス・セキュリティ技術・法令遵守の三つが同時に成立して初めて完成します。一つだけ補っても、残り二つの欠落は審査・通報・顧客デューデリジェンスの場面で露呈し、結局やり直しになります。
| 側面 | 答えるべき問い | その側面だけ補った場合によくある欠落 |
|---|---|---|
| プロセス（マネジメントシステム） | 誰が、何を、いつ行うか。実施の証拠はどこにあり、どう継続的に改善するか | ツールは揃っているが定期的に運用する人がおらず、審査時に記録が出せない |
| セキュリティ技術 | 管理策をどう設計し、有効性をどう検証するか | 文書は整っているが、システムが実際にはそのとおり動いていない |
| 法令遵守 | どの法規が適用され、自社の役割は何か。期限と罰則は何か | 管理策は作ったが、法規や役割を取り違えており、義務が網羅されていない |
積穗科研のコンサルティングチームはこの三つの側面を同時にカバーし、法規判定からプロセス設計、技術的管理策までを一括で設計します。一つの証拠セットで複数の法規と顧客要求に対応できます。