1人1アプリから標準化へ：Vertex AIを活用したMLOps推進 / Shibuya_AI_4

2026年2月16日に開催された「渋谷 Biz × AI: ビジネスにおける AI 利活用 事例勉強会 第4回」の登壇資料です。
https://sansan.connpass.com/event/380668/

▼関連資料
ビズリーチの 「企業向けレコメンド」機能について
https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-3

Two-Tower モデルで実現する 検索リランキング
https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-2

生成AIの利活用を加速させるための取り組み「prAIrie-dog」
https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-1

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

▼ビズリーチAI 特設サイト
https://www.bizreach.co.jp/ai

Transcript

1. 1人1アプリから標準化へ： Vertex AIを活用したMLOps推進 プロダクト本部 データプロダクト部 AIプラットフォームグループ 内村 優太
2. 自己紹介 2 内村 優太 2021年新卒で通信キャリアに入社 2024年7月からビズリーチで主にAI Platform開発/運用に取り組む ランニング、登山、SF小説 経歴 趣味
3. 事業紹介 3 転職市場のデータと社員データをリアルタイムかつ一元的に集積・分析し 社内の人材マッチングや採用戦略に活かすことが、最適な人的資本経営につながる 私たちが描く未来
4. 1. MLOpsについて 2. これまでの開発体制 3. 目指す姿 4. MLOpsプラットフォーム構築 5. まとめ アジェンダ 4
5. MLOpsについて
6. MLOpsのHow to, best practiceは既にあるので今回は触れません。 改善サイクルを回すことが大切！ MLOps 6 Machine Learning - Model - Data Development - Create - Verify - Package Operation - Release - Configure - Monitor
7. これまでの開発体制
8. モデルの検証から実装までをスピード感を持って行うことができる体制 - AIの価値を証明し早く世に出すことを目的 - 広い領域に対して探索的に機能を実装 - メンバーはスポット的な形でプロダクト機能開発に入る AI機能開発：0->1フェーズ 8 コラボレーション

9. コンテナ内部で学習/推論/結果出力を実行 - シンプルなインフラ基盤でアプリに応じて柔軟な処理 - 開発環境で確認した動作をそのままプロダクト環境で再現 - 開発者が慣れ親しんだ方法で開発が可能 1人1機能を開発 9
10. 開発・運用する機能の数が増えていく - 運用するアプリ数が増えるのに比例してコンテナ、リポジトリが増加 - メンバーが入れ替わる中で実装者がいないアプリも多くなる AI機能開発：1->10フェーズ 10 開発中のアプリ 運用中のアプリ 開発メンバーが 不在になったアプリ
11. - アプリ側で記述するコード量が多く、理解するのに時間がかかる - 処理がステップに切り分けられていないため、中間生成物の確認ができない バッチコンテナのブラックボックス化 11 似ている処理でも 機能ごとに独立して実行 各ステップの モニタリングが しづらい
12. 出来ていた点 - インフラの共通化 - 継続的トレーニング - 継続的なデリバリ AI機能開発：1->10フェーズのMLOps 12 出来ていなかった点 - 処理のパイプライン化 - モデルの自動評価 - データの質的モニタリング 起こったこと - 既存アプリの技術的な負債化 - 品質の管理不足 - 属人化
13. 出来ていた点 - インフラの共通化 - 継続的トレーニング - 継続的なデリバリ AI機能開発：1->10フェーズのMLOps 13 出来ていなかった点 - 処理のパイプライン化 - モデルの自動評価 - データの質的モニタリング 起こったこと - 既存アプリの技術的な負債化 - 運用コストの増大 - 品質の管理不足 改善サイクルを回せない！！
14. 目指す姿
15. AI機能開発：10->100フェーズ 15 Raw Data 予測結果 Feature Store Model Registry アプリ固有の実装は最小限に 特徴パイプライン 学習パイプライン 推論パイプライン 品質管理 複雑な特徴変換の一元化 扱う機能が増える中でスケールさせるための土台構築を目指す - 品質管理 - 処理の標準化
16. MLOpsプラットフォーム構築
17. AIプロダクトの開発/運用を横串で改善していく AIプラットフォームチーム誕生 17 Raw Data 予測結果 Feature Store Model Registry 特徴パイプライン 学習パイプライン 推論パイプライン アプリの固有 ロジックに注力 共通部分の 開発/運用に注力
18. MLワークフローの自動化基盤 - 自動化　　： データ処理・学習・デプロイを一本のパイプラインとして表現 - サーバレス： Google管理のサーバーレス環境（Kubeflow等）で実行 - 再現性　　： 「いつ・どのデータで・何を作ったか」というリネージを自動で記録・可視化 　 Vertex AI Pipelineとは？ 18 ワークフロー コンポーネント：ワークフロー内の1処理 データセット：実体はGCSに保存 モデル：Model Registryに登録されたモデル
19. MLのフローはテンプレートパイプラインとして提供 - 開発者はモデルのロジック部分のみを実装 - それ以外の部分は標準化されたパイプラインにパラメータとして値を渡す 処理の標準化：共通テンプレート 19 提供しているテンプレート例
20. モデルに関連した情報の一括管理 - モデルのバージョニング - image+model fileの組み合わせ - モデルの評価管理 品質管理：モデルレジストリの利用 20
21. まとめ
22. As Isで出ていた課題と解決 22 属人化 処理の重複 モニタリング 品質管理 標準化 パイプラインテンプレート モデルレジストリ プラットフォームチーム 課題 ToBe やったこと リネージ
23. 今はMLOpsを進めるプラットフォームができた状態 改善サイクルを回すことが大切！ MLOpsの今後 23 Machine Learning - Model - Data Development - Create - Verify - Package Operation - Release - Configure - Monitor 既存アプリのVertex AI移行 ML運用のさらなる 自動化/高度化 取得可能になった メトリクスの利用
25. Appendix
26. アプリ間での統一性がなく属人化が加速 - アプリごとに異なる実装/インターフェース - コンテナ内の処理がブラックボックス化 属人化 26 各機能、実装を深く知っているのは 1人だけという状況に
27. 実装の速さと各アプリごとの独立性を重視して1アプリ1リポジトリで開発 - 実装の独立性を担保 - アプリごとに高速に検証/開発を回せる 1機能1リポジトリ 27 アプリA/リポジトリ アプリB/リポジトリ
28. 処理の標準化：アプリの開発フロー 28 ロジック実装 - コアとなるロジックのみ実装 - 学習は前処理後のデータがinput - 推論時のIFはAPI テンプレートの利用 - 既存のテンプレートを利用 - 共通処理はパラメータのみ 最終パイプライン実装 - モデル固有の処理コンポーネント を作成 - 推論結果の連携先への保存など
29. モデルのロジック以外の部分の処理はコンポーネント化 - データ取得 - モデル評価 - モデル登録 処理の標準化：共通コンポーネント　 29