
多くの企業が人工知能 (AI) の可能性に気が付いた時点で、機械学習オペレーション (MLOps) をビジネス戦略に導入する競争が始まりました。しかし、現実世界への機械学習 (ML) の統合は簡単ではなく、開発と導入の間に大きなギャップがあることが明らかになりました。実際に、ガートナーの調査によると、AI と ML の 85% が実稼働に到達していません。
このブログ シリーズでは、DevOps のベスト プラクティスと MLOps を融合し、従来のソフトウェア開発と ML のギャップを埋めて企業の競争力を高め、データに基づいて意思決定を改善する重要性について説明します。パート 1 では、DevOps と MLOps のパイプラインがそれぞれ独立していることで生じる課題を明らかにし、統合の重要性について解説します。3 部構成の最初となる本ブログ記事の目標は、現状を維持し続けることでどんなリスクがあるのかについてお伝えすることを目指しています。
独立したパイプラインの課題
従来、DevOps と MLOps は別々のワークフロー、ツール、目標で活動してきました。残念ながら、DevOps と MLOps のパイプラインを別々に維持するというこの傾向は、多くの非効率性と冗長性をもたらし、ソフトウェア配信に悪影響を及ぼします。
1. ワークフロー統合の非効率性
DevOps パイプラインは、継続的インテグレーション/継続的デリバリー (CI/CD) や運用の信頼性を重視し、ソフトウェア開発ライフサイクル (SDLC) を最適化するように設計されています。従来の SDLC とモデル開発の SDLC には重複する部分がありますが、MLOps パイプラインには、データの前処理、モデルのトレーニング、実験、デプロイなどの独自の段階が含まれており、専用のツールとワークフローが必要です。この明確な分離により、ML モデルを従来のソフトウェア アプリケーションに統合するときにボトルネックが発生します。
たとえば、データ サイエンティストは Jupyter ノートブックで作業し、ソフトウェア エンジニアは Jenkins や GitLab CI などの CI/CD ツールを使用します。ML モデルをアプリケーション全体に統合するには、既存の DevOps フレームワークに適合する方法でモデルを変換、検証、デプロイする必要があるため、多くの場合、手動のプロセスが必要になります。また、このプロセスはエラーが発生することが多くあります。
2. ツールとリソースの冗長性
DevOps と MLOps はどちらも自動化、バージョン管理、デプロイという同様の目標を持っていますが、それぞれ別のツールとプロセスに依存しています。DevOps では通常、Docker、Kubernetes、Terraform などのツールが活用されますが、MLOps では MLflow、Kubeflow、TensorFlow Serving などの ML 固有のツールが使用されることがあります。これらには、統一されたツールがないため、チームは同じ結果を達成するために何度も作業を繰り返すことになります。
たとえば、DevOps でのバージョン管理は通常、Git などのソース コントロール システムを使用しますが、MLOps ではデータセットとモデルに対して追加のバージョン管理が使用される場合があります。この冗長性により、両方のチームがバージョン管理、再現性、追跡という本質的に同様の目的で異なるシステムを維持する必要があるため、インフラストラクチャ、管理、コストの点で不要なオーバーヘッドが発生します。
3. チーム間の相乗効果の欠如
DevOps パイプラインと MLOps パイプラインの統合が不十分なため、エンジニアリング、データ サイエンス、運用の各チーム間にサイロも生じます。これらのサイロにより、コミュニケーション不足、目標の不一致、デプロイの遅延が発生します。データ サイエンティストは、ソフトウェア エンジニアや DevOps との一貫したコラボレーションがないため、モデルを本番環境に対応させるのが大変な場合もあります。
さらに、ML モデルは標準のソフトウェア成果物として扱われないため、DevOps パイプラインで一般的なテスト、セキュリティ スキャン、品質保証の重要な手順を省略する可能性があります。一貫性の欠如は、品質の問題、本番環境での予期しないモデルの動作、チーム間の信頼の欠如につながる可能性があります。
4. 導入の課題と反復サイクルの遅延
DevOps と MLOps の分離状態は、デプロイの速度と柔軟性にも影響します。従来の DevOps 環境では、CI/CD によって頻繁で信頼性の高いソフトウェア更新が保証されます。しかし、ML では、モデルのデプロイには再トレーニング、検証、場合によっては統合の再設計が必要です。この不一致により、各パイプラインが個別に動作し、検証チェックと承認のセットが異なるため、反復サイクルが遅くなります。
たとえば、エンジニアリング チームは新しい機能をリリースする準備ができているかもしれませんが、更新された ML モデルが必要な場合は、再トレーニングと広範なテストを含む別の MLOps ワークフローのためにリリースが遅れる可能性があります。これにより、機械学習コンポーネントに依存する機能の市場投入までの時間が長くなります。
5. 一貫性と追跡可能性を維持することの難しさ
DevOps と MLOps の構成が別々になっていると、ソフトウェア システム全体でバージョン管理、監査、追跡可能性に対する一貫したアプローチを維持することが難しくなります。一般的な DevOps パイプラインでは、コードの変更は追跡され、簡単に監査できます。対照的に、ML モデルにはトレーニング データ、ハイパーパラメーター、実験などの複雑さが増し、これらは多くの場合、異なるログ記録メカニズムを持つ別のシステムにあります。
エンドツーエンドのトレーサビリティが欠如しているため、運用環境での問題のトラブルシューティングはより複雑になります。たとえば、モデルが予期しない動作をした場合、問題がトレーニング データ、モデル バージョン、またはコードベースの特定の部分にあるかどうかを追跡することは、統合されたパイプラインがないと面倒になる可能性があります。

統合のケース: DevOps と MLOps を統合する理由
ご覧のとおり、サイロ化された DevOps および MLOps パイプラインを維持すると、非効率性、冗長性、チーム間のコラボレーションの欠如が生じ、リリースの遅延や一貫性のないプラクティスにつながります。これらのパイプラインを単一のまとまりのあるソフトウェア サプライ チェーンに統合すると、一貫性がもたらされ、冗長な作業の削減やチーム間のコラボレーションが改善され、これらの課題に対処するのに役立ちます。
DevOps と MLOps の共通の最終目標
DevOps と MLOps は、迅速な配信、自動化、信頼性という同じ包括的な目標を共有しています。DevOps は従来のソフトウェア開発に重点を置き、MLOps は機械学習ワークフローに重点を置いているため、重点を置く領域は異なりますが、その中核となる目的は次の点で一致しています。
- 迅速なデリバリー
- DevOps と MLOps はどちらも、頻繁な反復リリースを可能にして市場投入までの時間を短縮することを目指しています。DevOps は継続的な統合とコード変更の配信を通じて迅速なデリバリーを実現しますが、MLOps はモデルの開発、トレーニング、デプロイのサイクルを迅速化することを目指しています。
- DevOps の迅速な配信により、新しいソフトウェア機能が可能な限り迅速に出荷されます。同様に、MLOps では、精度や動作が改善された更新されたモデルを配信できるため、企業はデータやビジネス ニーズの変化に迅速に対応できます。
- 自動化
- 自動化は、手動による介入を減らし、人的エラーの可能性を最小限に抑えるため、両方の実践の中心となります。DevOps は、ソフトウェアのテスト、構築、デプロイを自動化して、一貫性、効率性、信頼性を確保します。
- MLOps では、自動化も同様に重要です。データの取り込み、モデルのトレーニング、ハイパーパラメーターの調整、およびデプロイメントを自動化することで、データ サイエンティストは反復的なタスクの処理ではなく、実験やモデルのパフォーマンスの向上に集中できるようになります。MLOps の自動化により再現性も確保されます。これは、運用環境で ML モデルを管理するために重要です。
- 信頼性
- DevOps と MLOps はどちらも、運用環境における信頼性を重視しています。DevOps では、自動テスト、監視、インフラストラクチャをコードとして使用するなどの手法を使用して、ソフトウェアの安定性を維持し、ダウンタイムを軽減します。
- MLOps は、デプロイされたモデルの信頼性を維持し、変化する環境でも期待どおりの動作保証を目的としています。モデルの監視、自動再トレーニング、ドリフト検出などのプラクティスは、ML システムが長期にわたって堅牢で信頼できる状態を維持することを保証する MLOps の一部です。
ソフトウェア サプライ チェーンにおける ML モデルを成果物として扱う
従来の DevOps では、バイナリ、ライブラリ、構成ファイルなどのすべてのソフトウェア コンポーネントを成果物として扱うという概念が定着しています。これらの成果物は、まとまりのあるソフトウェア サプライ チェーンの一部として、さまざまな環境 (ステージング、本番環境など) を通じてバージョン管理、テスト、およびプロモーションされます。同じアプローチを ML モデルに適用すると、ワークフローを大幅に合理化し、部門間のコラボレーションを改善できます。ML モデルを成果物として扱うことの主な利点は次の 4 つです。
1. すべての成果物の統一されたビューを作成する
ML モデルを成果物として扱うということは、成果物リポジトリや CI/CD パイプラインなど、他のソフトウェア コンポーネントに使用されるのと同じシステムに統合することを意味します。このアプローチにより、コード、バイナリ、構成と同じ方法でモデルをバージョン管理、追跡、管理できます。すべての成果物を統一されたビューで表示することで一貫性が確保され、追跡可能性が向上し、ソフトウェア サプライ チェーン全体の制御を維持しやすくなります。
たとえば、コードと並行してモデルをバージョン管理すると、新しい機能がリリースされたときに、その機能の使用に対応するモデル バージョンが適切に文書化され、再現可能になります。これにより、混乱が軽減され、誤解がなくなり、どのバージョンのモデルとコードがシームレスに連携するかをチームが識別できるようになります。
2. ワークフローの自動化を合理化
ML モデルを大規模なソフトウェア サプライ チェーンに統合することで、DevOps で見られる自動化のメリットが MLOps にも拡張されます。モデルのトレーニング、検証、デプロイのプロセスを自動化することで、従来のソフトウェア配信で使用される CI/CD パイプラインと同様に、ML 成果物は、データの前処理から最終的なデプロイまでの一連の自動化されたステップを踏めます。
この統合により、ソフトウェア エンジニアが ML モデルに影響するコード変更をプッシュすると、同じ CI/CD システムでモデルの再トレーニング、検証、およびデプロイメントをトリガーできます。既存の自動化インフラストラクチャの活用で、組織は不要な手動手順を増やさず、ソフトウェアとモデルのすべてのコンポーネントを含むエンドツーエンドの配信を実現できます。
3. チーム間のコラボレーションを強化
DevOps パイプラインと MLOps パイプラインを別々に維持する際の大きな課題は、データ サイエンス、エンジニアリング、DevOps チーム間の連携が欠如していることです。ML モデルを大規模なソフトウェア サプライ チェーン内の成果物として扱うことで、プロセスを標準化し、ツールを共有することで、コラボレーションが促進されます。全員が同じインフラストラクチャを使用すると、コンポーネントが開発、テスト、デプロイを通じてどのように移動するかについて共通の理解が得られるため、コミュニケーションが向上します。
たとえば、統合パイプラインがモデル成果物のパッケージ化とリリースを自動的に処理するため、データ サイエンティストはデプロイメントのニュアンスを気にすることなく、高品質のモデルの開発に集中できます。一方、エンジニアはモデルをより広範なアプリケーションのコンポーネントとして扱い、ソフトウェアの他の部分と同様にバージョン管理およびテストできます。この共有された視点により、より効率的な引き継ぎが可能になり、チーム間の摩擦が軽減され、プロジェクト目標の整合性が確保されます。
4. コンプライアンス、セキュリティ、ガバナンスの向上
モデルがソフトウェア サプライ チェーンの標準成果物として扱われると、他のソフトウェア コンポーネントと同じセキュリティ チェック、コンプライアンス レビュー、ガバナンス プロトコルを受けることができます。DevSecOpsの原則 (ソフトウェア ライフサイクルのあらゆる部分にセキュリティを組み込む) を ML モデルに拡張して、組織のセキュリティ ポリシーに準拠して検証、テスト、デプロイできるようになりました。
モデルがビジネス オペレーションにますます不可欠になるにつれて、これは特に重要になります。モデルを脆弱性スキャンや品質検証、コンプライアンス管理することで、組織は AI/ML を本番環境に導入する際のリスクを軽減できます。

まとめ
ML モデルを大規模なソフトウェア サプライ チェーン内の成果物として扱うことで、DevOps と MLOps を分離する従来のアプローチが、統合されたまとまりのあるプロセスに変わります。この統合により、すべての成果物に対して既存の CI/CD パイプラインを活用してワークフローを合理化だけでなく、プロセスとインフラストラクチャの標準化やコラボレーション強化を実現し、コードとモデルにおいて品質、信頼性、セキュリティで同じ基準を満たすことを保証します。
DevOps と MLOps を単一のソフトウェア サプライ チェーンに統合することで、組織は迅速な配信、自動化、信頼性という共通の目標をより効果的に達成し、アプリケーション コードから機械学習モデルまで、ソフトウェアの全範囲をビルド、テスト、デプロイするための効率的で安全な環境を構築できます。本記事の続きとなるパート 2 では、統合ソフトウェア サプライ チェーンの利点と機会について説明します。
DevOps と MLOps において統一されたツールをお探しであれば、JFrog Platform がおすすめです。JFrog Platform は 1 つのプラットフォームでエンドツーエンドの可視性、セキュリティ、制御の機能を提供し、信頼性の高いリリースの配信を自動化します。
記事参照: Breaking Silos: Unifying DevOps and MLOps into a Cohesive Software Supply Chain – Part 1
世界の人気ソフトウェアを提供するエクセルソフトのメールニュース登録はこちらから。