じげんにおけるVertex AI Pipelinesの導入事例

ツール導入前の課題

機械学習モデルはリリースして終わりではなく、継続的な精度維持が不可欠です。しかし、当時はモデルの再学習やデプロイをすべて手動で行っていたため、以下のような課題が顕在化していました：

• 再現性の欠如：ノートブック中心の運用で、学習条件や評価指標の管理が煩雑。過去のモデルの再現が困難でした。
• 属人性のリスク：特定メンバーに依存した運用で、引き継ぎが難しく、休職・退職時に対応できないリスクがありました。
• 高い運用コスト：手動によるモデル構築・デプロイに時間がかかり、ABテストの頻度増加にリソースが追いつかなくなっていました。
• 分業の難しさ：コードが一貫化されておらず、他メンバーが部分的に作業を引き継ぐのが困難でした。
• 品質管理の不徹底：ノートブックベースの開発により、レビューやCI/CDが機能せず、コードの品質にばらつきがありました。

プロジェクト数が増える中、このままではスケールに限界があると判断し、持続可能な運用基盤の構築が急務となっていました。

どのような状態を目指していたか

目指したのは、 「最小限の工数で、MLの価値を持続的に発揮できる運用体制」 です。 Vertex AI Pipelinesの導入を通じて、以下の状態を実現することを目的としました：

• 再現性の確保：すべての実験を記録・復元可能にし、ABテスト後もスムーズに再学習・再デプロイが可能な体制。
• 属人化の解消：標準化されたコードと開発フローにより、誰でも運用・引き継ぎができる状態。
• MLパイプラインの自動化：モデルの学習・評価・デプロイを自動化し、開発効率と実行速度を向上。
• スケーラブルなチーム運営：処理をモジュール化し、役割に応じた分業が可能な仕組み。
• 品質と保守性の向上：リポジトリ運用とlinter・レビュー体制を整え、コードの一貫性と品質を担保。

インフラとしてGCPを利用していたため、他のサービスとの連携が容易で、導入コストが低かった。

どのような成果が得られたか

• レビュー文化の醸成とコード品質の向上：ノートブック中心の開発からソースコード管理に移行したことで、Pull Requestベースのレビューが可能になり、コードの可読性や保守性が大きく向上。実行前にレビュワーがバグを早期に発見できる体制が整いました。
• 分業体制の実現と学習コストの削減：パイプラインにより処理が明確にコンポーネント化され、各メンバーが特定の処理だけを担当できるようになりました。これにより、新規メンバーでも機能改善に参加しやすくなり、チーム全体の開発効率が向上しました。
• 実行の自動化と開発の安定性向上：従来のノートブック実行に依存した手動プロセスから脱却し、パイプラインを通じて一貫した処理が可能に。人為的なミスや実行漏れを防ぎ、再現性の高い開発・検証フローを実現できるようになりました。

Vertex AI PipelinesでKubeflow v2 SDKを用いた実装例が少なく、公式ドキュメントを読み込みながら手探りで進める必要がありました。

Kubeflow v2 SDKを用いた機械学習パイプラインの構築については、弊社テックブログでも紹介していますので、ご参考になれば幸いです！！ https://overs.zigexn.co.jp/technology/11235/

現状だと学習モデルを改善してABテストを実施することに注力していますが、今後学習モデルがある程度確立したら、モデル学習からデプロイまでの手順を自動的に定期実行できる方向で進めていきたいと考えています。最終的にはGitHub Actionsを導入して、パイプラインで定期的に実行されて出てきた指標が問題なければ上長が判断してデプロイする運用にできると理想だと思います。

また、複数のサービスを横展開していく上である程度共通して利用される前処理や後処理も確立されてきたため、それらをサービス共通のパッケージとして提供して呼び出せる方式にするのも良いかもしれません。