SaMDサイバーセキュリティ対応PMの仕事。脆弱性管理と市販後保守を担う医療DX

「このSBOM、コンポーネントが1,200点あるんですが、脆弱性が公表されるたびに全部洗い直すんですか」。ある医療機器ベンチャーのPMから、僕はそう相談を受けたことがあります。

結論から言うと、答えは半分イエスです。SaMD(Software as a Medical Device、プログラム医療機器)のPMは、承認申請の一時点だけでなく製品が市場にある限りサイバーセキュリティ対応を続ける役目を負います。厚生労働省は2023年3月、医療機器プログラムの承認審査においてサイバーセキュリティに関する情報提出を求める運用を明確化しており、以降PMDAへの照会事項のうちセキュリティ関連が占める比率は、僕の体感値で3〜4割まで上がりました。「ハードウェアの医療機器じゃないから関係ないと思っていたら大間違いでした」と、先ほどのPMは振り返っていました。今日はこの仕事の中身を、制度の話から現場の泥臭い部分まで分解していきます。

1. なぜSaMDにサイバーセキュリティ対応が必須になったのか

制度の流れを押さえておきます。厚生労働省は2023年3月、医療機器プログラムの製造販売承認申請に際してサイバーセキュリティに関する情報の提出を求める運用を明確化しました。同じ頃、IMDRF(国際医療機器規制当局フォーラム)もSBOMに関する原則文書を公表し、部品構成の透明化という考え方が各国規制当局で足並みを揃え始めています。米国ではFDAが連邦食品・医薬品・化粧品法にSection 524Bを追加し、2023年3月29日から通信機能を持つ「サイバー機器」に対してSBOM提出などのサイバーセキュリティ情報を承認申請の必須要件としました。

僕がこの流れで重要だと考えているのは、これが「セキュリティ担当部門の仕事」ではなく「承認スケジュールを左右するPM業務」に変わった点です。従来はQA・薬事チームが臨床評価やQMS(品質マネジメントシステム)対応を主導し、PMはスケジュールを管理する立場でした。ところが2023年以降は、セキュリティ要件の不備がそのまま照会事項となり承認が数ヶ月遅れる案件が体感で増えており、PM自身がセキュリティ成果物の中身を理解していないと進行管理が成立しなくなっています。

2. 承認申請までにPMが揃える具体的な成果物

実務では、従来のSaMD開発資料に加えて次のような成果物を用意することになります。

この中でPMが特に苦労するのがSBOMです。案件の規模にもよりますが、僕が関わった案件ではコンポーネント数が1,000点前後に及び、そのうち開発チームが把握していないOSS(オープンソースソフトウェア)由来の間接依存が2〜3割含まれていることも珍しくありません。承認前の準備期間は体感で6ヶ月〜1年ほど見ておく必要があり、この期間の大半をセキュリティ成果物の精度を上げる作業に割く案件も出てきています。

3. 市販後(PMS)で発生する脆弱性対応という終わらない仕事

承認が取れて終わりではないのが、この仕事の一番の特徴だと僕は考えています。製品が市場に出ている間、つまり製品ライフサイクル全体(体感で3〜7年程度)にわたって、新しく公表される脆弱性情報を監視し、自社製品への影響を評価し続ける必要があります。

一般的な脆弱性対応の慣行では、影響の有無を判断する一次対応の目安は72時間以内、深刻度を示すCVSSスコアが7.0以上の脆弱性は優先対応の対象とされることが多いです。実際のパッチリリースは、僕の体感では平常時は四半期に1回程度のサイクルで計画的に行い、緊急性の高い脆弱性が見つかった場合は数週間以内に臨時パッチを出す、という二段構えの運用になっている案件が多いです。

ここでPMが担う実務は、開発チームへの指示出しだけではありません。パッチ適用によって既存の臨床性能や有効性が変わらないことを確認する回帰試験の範囲を決め、必要に応じて薬事チームと軽微変更か一部変更承認かの判断をすり合わせる、という規制対応そのものが仕事の中心になります。

4. 現場でよくある衝突とその対処法

僕がこれまで見てきた中でよく起きるのが、開発チームの機能追加優先度とセキュリティ対応の優先度がぶつかる場面です。「次のリリースで新機能を出したいのに、脆弱性対応で工数が取られる」という声は、僕の体感ではほぼ全ての案件で一度は出ます。

もう一つ厄介なのが、サプライヤー管理です。ある案件では、製品に組み込んでいたOSSライブラリに脆弱性が公表されたものの、そのライブラリのメンテナンス元がすでに開発を停止しており、修正パッチが提供されない状態に陥りました。結局、代替ライブラリへの置き換えという想定外の追加開発が発生し、当初1ヶ月で終わるはずだった対応が3ヶ月かかりました。この経験から僕は、SBOMを作る段階でメンテナンス状況(最終更新日・コミット頻度)まで確認項目に入れておくことをお勧めしています。単に一覧を作るだけでは、いざという時に使えない資料になってしまうからです。

対処法としては、脆弱性対応にあらかじめ工数の一定割合(体感で開発リソースの1〜2割程度)を恒常的に確保しておく、リリース計画とは別建てでセキュリティパッチ用のリリーストレインを設けておく、という運用を早い段階から関係者に合意してもらうことが有効だと考えています。

5. PMに求められるスキルと転身ルート

この領域で評価されるPMのバックグラウンドは、大きく分けて二つあります。一つはITセキュリティ経験者で、CVE(共通脆弱性識別子)やCVSSの読み方、脆弱性管理の実務に馴染みがあるタイプです。もう一つはQMS経験者で、IEC 62304やISO 13485といった医療機器ソフトウェアの規格に沿った文書管理に慣れているタイプです。

僕の体感では、この両方を高いレベルで持つ人はまだ少なく、片方の経験を軸にもう片方をキャッチアップしていく転身ルートが現実的です。ITセキュリティ出身者であれば、QMS文書の作法とPMDA審査プロセスの流れを覚えること、QMS出身者であれば、SBOMツールやCVSSスコアリングの基礎を押さえることが最初の一歩になります。CISSP(公認情報システムセキュリティ専門家)などの資格は必須ではありませんが、開発チームやセキュリティ担当との会話の共通言語として持っておくと話が早い、というのが実感です。

6. 案件動向と年収の体感値

案件動向としては、SaMD関連の求人でセキュリティ要件対応の経験を明記する案件が増えてきている、というのが僕の肌感覚です。数値化されたデータは持ち合わせていませんが、面談でセキュリティ対応の実務経験を聞かれる頻度は明らかに上がっています。

年収について僕の体感値でお話しすると、一般的なSaMD PMの年収レンジは650万〜850万円程度である一方、サイバーセキュリティ対応の実務経験を持つPMは750万〜950万円程度と、100万円前後上乗せされる印象があります。これはあくまで僕がこれまで見聞きした範囲の体感値であり、企業規模や製品の通信機能の有無によって幅は大きく変動します。転職を考える際は、この体感値を一つの目安にしつつ、実際の求人票でセキュリティ対応の範囲がどこまで含まれるかを面談で確認することをお勧めします。

(結論)

SaMDのサイバーセキュリティ対応は、2023年の制度整備を境に「専門部署の仕事」から「PMが理解して進行管理すべき仕事」に変わりました。承認前にはSBOMや脆弱性管理計画書といった成果物を整え、承認後は製品ライフサイクル全体にわたって脆弱性対応を続ける、という息の長い仕事です。開発優先度との衝突やサプライヤー管理の難しさといった泥臭い場面も多いですが、その分だけ経験者は少なく、僕の体感では年収面でも相応の評価がついてきています。皆さんいかがでしたでしょうか。では今日もがんばりましょう。