サイロ化した組織の隙間を狙う

従来のDevSecOpsは通用しない？　AIの弱点を突く脅威への最適解「MLSecOps」

企業におけるAI活用が拡大する中、意思決定の不透明性や未知の脅威という新たな脆弱性が浮上している。従来のソフトウェア開発の常識だけでは防げない特有のリスクに対し、どのような枠組みで立ち向かえばよいのか。

公開 2026年06月15日 05時01分

[TechTargetジャパン]

印刷する

　企業の業務プロセスにおいて、機械学習（ML）などのAI技術活用が急速に進む中、新たなセキュリティリスクが浮上している。従来のソフトウェアとは異なり、AIモデルは動的に振る舞い、その意思決定プロセスは不透明になりがちだ。学習データやモデルは継続的に進化するため、一度セキュリティ対策を施せば済むものではなく、ライフサイクル全体を通じた適応型の防御戦略が求められている。

　こうした課題を解決する手段として登場したのが「MLSecOps」だ。これは、ソフトウェア開発において定着した「DevSecOps」の知見を、MLモデルの開発・運用ライフサイクルに拡張した概念を指す。MLSecOpsの導入によって、MLモデルの開発者やセキュリティ担当者、運用チームが責任を共有し、開発の初期段階からリスクを特定、軽減可能になる。

　しかし、ソフトウェアのセキュリティには精通していても、ML特有の脅威やデータ管理手法に対しては知見が不足しているセキュリティ担当者は少なくない。データサイエンティストやMLエンジニアも、バージョン管理や脆弱（ぜいじゃく）性の修正といった従来のDevOpsの教訓を十分に理解していない場合がある。

　複雑化するAIモデルのセキュリティに対し、どのようなツールやフレームワークを用いれば堅牢（けんろう）なシステムを構築できるのか。

AIの防御策はなぜ“後付け”になるのか？

併せて読みたいお薦め記事

AIモデルの開発にセキュリティを組み込む

　本稿は、2025年11月に開催されたセキュリティイベント「Open Source SecurityCon」におけるセッション「Applying DevSecOps Lessons To MLSecOps」の内容を基に解説する。セッションには、Dell Technologiesのディスティングイッシュトエンジニアであり、オープンソースソフトウェア（OSS）の安全利用を目指す団体OpenSSF（Open Source Security Foundation）のAI/MLワーキンググループと連携して活動するサラ・エバンス氏が登壇した。

　エバンス氏は、OpenSSFが公開したMLSecOpsに関するホワイトペーパーを基に、DevSecOpsからMLSecOpsへの移行手順を説明した。このホワイトペーパーは、通信機器ベンダーEricssonが通信業界向けに作成したMLSecOpsの論文をベースとし、さまざまな業界で広く利用できる汎用（はんよう）的な参考資料としてOpenSSFで共同執筆されたものだ。以下に、その中核となる技術的なポイントを解説する。

1．「インフィニティループ」の拡張と責任共有

　DevOpsの概念を象徴する図として、開発（Dev）と運用（Ops）が無限軌道を描く「インフィニティループ」が知られている。エバンス氏らは、この従来のループ構造をAI分野に合わせて再定義した。AIアプリケーションでは、ソースコードだけではなく「データ」と「モデル」が重要な構成要素になるためだ。

　ホワイトペーパーは、データを収集・処理するループと、MLモデルを学習・評価するループを、従来のコード中心のループと連携させる新たな参照アーキテクチャを提示している（図）。これによって、どのプロセスでどのようなセキュリティ統制が必要になるかが視覚的に整理される。

図　Data、ML、DevOpsのループ構造に、Ericssonの参照アーキテクチャの9つのステージをマッピングした図（出典：OpenSSFのホワイトペーパー）《クリックで拡大》

　この新しいループを回す上で欠かせないのが、ペルソナ（役割）の明確化だ。従来のDevOpsにおける開発者や運用者に加え、データサイエンティスト、データエンジニア、MLエンジニアといった新たなペルソナが追加された。結果として、サイロ化（孤立）しがちなデータサイエンス部門とセキュリティ部門、運用部門の間に橋渡しが行われ、セキュリティが組織全体の「共有された責任」として機能する体制が整備される。

2．既存のセキュリティツールと脅威モデルの連携

　「MLモデルに対する脅威は多岐にわたるが、一から新しい概念を学ぶ必要はない」とエバンス氏は指摘する。ホワイトペーパーの工夫として、OSSコミュニティーのOWASP（Open Worldwide Application Security Project）が定義するMLおよびLLM（大規模言語モデル）向けの10大脅威リストを採用している点が挙げられる。

　このOWASPの脅威リストを先述の参照アーキテクチャ上にマッピングすることで、ライフサイクルの「どの段階で」「どのような脅威が」発生し得るかを理解できるよう工夫されている。重要なのは、これらの脅威に対するセキュリティコントロールとして、既存のオープンソースツール群をどのように適用できるかを示した点だ。

　例えば、ソフトウェアサプライチェーンの安全性を確保するフレームワークである「SLSA」や、セキュリティスコアを算出する「Scorecard」、アーティファクトの署名をする「Sigstore」などが、MLパイプラインの各段階にマッピングされている。

　注目すべきはSigstoreの活用だ。ソフトウェアのコード署名という概念を応用し、「OpenSSF Model Signing Schema」（MSS）と呼ばれる仕組みを通じて、デプロイ前にMLモデル自体に署名し、その出自と完全性を検証することが可能になっている。このように、ソフトウェアセキュリティの領域で培われた堅牢なツール群を、MLの文脈へと転用するアプローチが提示されている。

3．AIセキュリティの未来：分散から集約へ

　セッションの結びとして、AI技術の急激な進化に対するセキュリティコミュニティーの在り方について展望が語られた。生成AIに対するセキュリティ手法が確立されつつある中、すでに自律的に行動するAIエージェントの台頭という新たな波が押し寄せている。

　AIに関する技術革新や標準化の議論は、OSS管理団体のLinux FoundationやCloud Native Computing Foundation（CNCF）など、さまざまな場所で同時多発的に進行している。ここで生じるのが、「AI専用の新たなセキュリティ団体を設立すべきかどうか」という議論だ。

　エバンス氏の見解は明確だ。「AIモデルは既存のソフトウェアシステムに構築されているため、全く新しいセキュリティ団体を一から作り直す必要はない」という。すでに安定して稼働しているOpenSSFのような既存のセキュリティインフラを収束点とし、そこで培われた知見と仕組みの上にAIセキュリティを集約していくべきだと同氏は強調する。

　DevSecOpsの歴史が証明するように、セキュリティは後付けではなく、設計段階から組み込まれるべきだ。MLSecOpsという新たなアプローチは、AI技術がもたらす未知のリスクに対する現実的かつ実践的な道しるべになる。

本稿は、CNCFが2025年11月25日に公開した動画「Applying DevSecOps Lessons To MLSecOps - Sarah Evans, Dell Technologies」を基に作成しました。

印刷する