バンダイナムコネクサス／TechBlogPublicationへの投稿
📖

AI/MLシステムの量産体制を目指して（後編：アプローチと実践）

kyamano
に公開
機械学習
自動化
データサイエンス
MLOps
tech

はじめに

こんにちは、株式会社バンダイナムコネクサスの山野です。

本記事はこちらの記事の後編です。前編では、次のような課題感を共有しました。

  • PoCで得られたモデルのビジネス効果は見込めているが、いざシステム化しようとすると工数やコストが膨大になり、プロジェクトが止まってしまう（機械学習チームの悲劇）
  • AI/MLシステムは完成しても運用フェーズでアップデートが必要になりがちで、ウォーターフォール的に一度作って終わりにはできない（なんなら開発中にも、精度改善のため・また本番アーキテクチャを踏まえた継続的なモデルアップデートが必要）
  • データサイエンティストとエンジニアとの連携不足から、PoCと本番運用のギャップが埋まらない（ここが最も開発工数・期間と品質を左右することが多い）

後編となる本記事では、これらの課題を乗り越えるために私たちが「クイックにシステム開発・運用できるようにした」「データサイエンティストとエンジニア（ML/MLOpsエンジニア）が協働して開発・運用できるようにした」アプローチをご紹介します。

これらの取り組みにより、「モデルの完成」と「システムへの組み込み」をスムーズにつなぎ、最小限の工数かつ適切な品質で早期にリリース。さらには継続改善できる状態を目指しています。

以下の順番で、具体的な取り組みを解説していきます。

  • 前提：PoCから本番運用への流れ
    1. ドキュメントテンプレートの整備
    1. アーキテクチャの共通化とテンプレート活用
    1. CI/CDの導入
    1. 組織連携とスキル育成

前提：PoCから本番運用への流れ

本記事の前提として、私たちはPoC開始から本番運用・継続改善に至るまでを以下のように進めています。

これらの流れの全体像をデータサイエンティスト・エンジニア双方が理解し、案件や実際にアサインされたメンバーのスキルセット（たいていグラデーションがある）に応じて柔軟に分担して連携していく必要があります。

## 1. 企画フェーズ：Business Understanding & Problem Framing
1. **ビジネス課題の明確化**
2. **AI/MLモデル・システムによるソリューションのROI検討、予算獲得**

## 2. PoCフェーズ：Data Acquisition, Understanding & Modeling
1. **PoC計画立て**
2. **分析/開発環境のセットアップ**
3. **データ分析**
4. **モデル開発・評価**
5. **PoC結果報告**

## 3. 開発フェーズ：System Design & Deployment
1. **システム化計画（タスク洗い出し・工数見積もり・ROI検討・体制と役割分担整理）**
2. **要求定義・要件定義（業務フロー・機能/非機能要件・データ連携仕様）**
3. **設計：システムアーキテクチャ設計**
4. **開発：PoCモジュール動作確認**
5. **開発：開発環境準備（Google Cloud Project, Terraform Cloud, GitHub）**
6. **開発：CI/CD環境構築**
7. **開発：データ/MLパイプライン・API開発**
8. **開発：クラウド環境構築・動作確認**
9. **開発：モニタリング・ロギング・バックアップ設定**
10. **テスト：単体テスト・統合テスト・負荷テスト・UAT・ABテスト**
11. **運用設計・引き継ぎ：アカウント設定、運用ドキュメント作成（ユーザ、運用担当者）、引き継ぎ**

## 4. 運用フェーズ：Monitoring & Continuous Improvement
1. **監視・モニタリング（継続的な評価と改善）**
2. **障害対応**
3. **脆弱性対応・アップデート**
4. **定期運用作業（アカウント棚卸し、パフォーマンス測定、キャパシティプランニング）**
5. **問い合わせ・サポート対応**

1. ドキュメントテンプレートの整備：知見を蓄積し、スピードと品質を両立する

私たちのチームでは、システムの実装にいきなり着手するのではなく、ビジネス要求の整理・システム化要件の明確化・初期設計の共有を目的としたドキュメントテンプレートをいくつか用意し、それに沿って初期フェーズを進めるようにしています。

それらのテンプレートを通じて、以下のような関係者との認識合わせが可能になります。（図は、私たちが業務システムへML APIを提供するパターン）

関係者との認識のズレや手戻りを最小限に抑えることができれば、結果として開発工数の削減や品質向上につながります。運用フェーズに入ってからも、事前の要件や設計の記録があるおかげで、障害対応や改善施策に迅速に取り組めます。

また、私たちのプロジェクトは大規模なシステムを数ヶ月かけて作るといったケースよりも、PoCの成果を素早く施策化するためのスモールスタート案件が多く、様々な担当者やステークホルダーと頻繁に関わることが珍しくありません。

テンプレートはチェックリスト的な役割も担っており、限られた時間の中でも、関係者間で必要な検討事項を漏れなく確認・決定できるようになりました。さらに、案件で得られた知見をテンプレートに還元することで、品質の積み上げと再利用性の向上を実現しています。

最近では、LLMとの協働に向けて、テンプレートの構成や表現を最適化しやすい土台を整備しようとしています。

ここからは、私たちが特に重要だと考えているドキュメントテンプレートとその活用方法を3つ紹介します。

1-1. 工数見積もりのテンプレート

  • プロジェクトのできるだけ早い段階からエンジニアを巻き込み、工数見積もりとリスクの洗い出しを行うことで、タスク・優先度・工数・技術的難易度・アサイン可否といった要素を把握し、ROIや不確実性を可視化しています。これにより、「やる／やらない」の判断を迅速かつ合理的に下せるようになり、円滑なプロジェクト進行が可能になります。
  • 案件ごと・タスクごとの予実（予定と実績）を蓄積し、次の見積もりに活かしています。過去の実績から得られた定量データをもとに、次回以降の見積もり精度を高める仕組みを整備しています。最近では複数の案件を通じて、開発フェーズごとの所要工数やリスク傾向も把握できるようになってきました。
  • 運用フェーズの工数見積もりも極めて重要です。運用保守は見積もりが難しいにもかかわらず、ランニングコストにシビアな制約がつきやすい領域です。特に障害対応や問い合わせなどの非定型業務は、担当者のスキルやシステム理解度により大きくブレが生じます。また、人材の流動性が高い組織では、そのリスクも加味する必要があります。ここで重要なのは、「理想的な保守」を実現するための工数を積み上げるのではなく、許容される予算やROIをベースに現実的な保守レベルを定義し、関係者との合意を得ることです。定型作業の自動化、障害対応のSLA範囲明確化などを通じて、無理のない運用体制を構築することが肝となります。
  • 見積もり・提案の段階で、リスクの洗い出しと共有も徹底しています。システム化による効果や狙いを提示するのと同時に、技術的・運用的なリスクの可視化と説明も欠かせません。これにより、関係者の認識が揃い、プロジェクト全体が現実的な期待値で進行しやすくなります。

1-2. PoCヒアリングシートとコード受領要件テンプレートの整備

PoCコードのプロダクション化は工数はきちんと見積もっておく必要がありますし、入念な確認が不可欠です。

PoCコードをそのままコンテナで定期実行すればよいケースはほとんどなく、多くの場合でデータ連携やコード構造に大幅なリファクタリングが必要となるからです。

例えば以下のような状態がよくあるのではないでしょうか。

  • パッケージ管理がされていない（requirements.txtやpyproject.tomlがない）

  • 実行環境の前提が曖昧で、再現性が保証されていない

  • 入力データを手動でCSVからヒューリスティックに準備している

    → 本番ではデータパイプラインを構築し、マートを自動生成する必要がある

  • 日付などのパラメータがベタ書き、差分ではなく全量推論になっている

  • ノートブックを上から順番に実行すればいいわけではない、記載されていない手動手順が必要

  • 本番のデータ量では非機能要件を満たせない

これらはPoC時には許容されても、本番環境への移行において大きな工数とリスクを生む原因になります。特に、コアロジック以外の部分はほぼ書き直しになることも珍しくありません。それを防ぐためには、背景・ロジック・前提条件など、PoCの文脈を正確に把握することが重要です。

こうした課題に対応するために、私たちは次のような仕組みを整えています。

  • PoCヒアリングシート：

    PoCの目的・入出力・評価方法などを明文化し、エンジニアが引き継げるようにする

  • PoCコード受領要件のテンプレート：

    受領時に満たしておいてほしい最低限の形式や構成を明記。他の人の環境でも動く状態を担保する

  • 共通実行環境とCIによる自動チェック（詳細は後続）：

    実行環境の統一（Docker + uv）や、Lint/テストのCI導入によって、コードの状態を機械的に確認する

1-3. 要件定義フェーズドキュメント（業務フロー、機能/非機能要件定義）のテンプレート

  • PoCの段階では、まず「モデルの精度が出るかどうか」を検証することが中心ですが、実際にシステムとして業務に組み込まれ、ビジネス価値を生むためには、精度以外にも多くの観点での要件整理が必要です。
  • ありがちな失敗として、PoCで得られたコードをそのまま自動化すればよいと考え、すぐに本番化に着手してしまうケースがあります。しかし、業務フロー・セキュリティ・運用体制といった要素が未定義のままでは、使われないシステムになったり、後から大きな手戻りが発生するリスクがあります。単にPoCコードを動かすのではなく、「価値を継続的に届ける仕組みを設計する」という視点が求められます。ここでは以下のような観点を明文化し、フローチャートや要件定義書に落とし込んでいきます。
    • データはどこでどのように生成・収集されるか
    • モデル推論はどのタイミング・どんな条件で実行されるか
    • 推論結果はどのように業務へ組み込まれ、誰が使うのか
    • 継続的な改善や保守は誰がどう担うのか
  • 非機能要件にも着目します。PoCでは意識されにくい非機能要件（例：処理時間、スケーラビリティ、実行コスト）は、本番化において重大な制約条件となることがよくあります。例えば「PoCでは全件のコサイン類似度計算だったが本番ではベクトルDBによる最近傍検索に切り替える必要がある」「精度1%の向上と引き換えに、実行時間が2倍・コストが1.5倍になる場合、どちらを選ぶべきか考える必要がある」等がありえます。モデルの選定や再設計を、アーキテクチャレベルでトレードオフ込みで判断する必要があります。
  • 最近はあらゆるタスクでLLMを活用する流れになっていますが、LLMの特性ゆえに、要件定義フェーズの質がより重要になります。従来のルールベースやスクリプトベースのシステムと違い、LLMは出力の不確実性が高いため、何をもって「正しい」「成功」とみなすかという合意がないまま進めるとトラブルを招きやすくなります。要件を明確にすることで、LLMの「ブラックボックス性」をシステム化の中で扱えるレベルに緩和することができます。
  • 要件がすべて揃ったからといって、一度に全機能を作り込むのではなく、まずはMVP（Minimum Viable Product）として必要最低限の価値を届け、その後段階的に拡張していくべきケースもあります。何を最初に作るか、どこまで作り込むかを明確にすることも、要件定義フェーズで行うべき重要な判断の一つです。「今やるべきこと」と「後回しにできること」の線引きがうまくできると、スピードと柔軟性のあるプロダクト開発が実現します。

2. アーキテクチャの共通化とテンプレート活用：再発明せず高速・高品質に立ち上げる仕組み

AI/MLプロジェクトを進める際に、毎回技術選定を行い、アーキテクチャをゼロから設計・構築していては立ち上げスピードが遅くなりますし、品質の向上や知見の蓄積も進みません。また、プロジェクトごとにインフラやCI/CDパイプライン等がバラバラに構築されてしまうと、技術的・運用的な負債が雪だるま式に増加していきます。プロジェクトやモデルの数が増えるにつれ、「保守がつらい」「他案件に入った時のキャッチアップコストがかかる」という状態に陥ることも少なくありません。そこで必要なのが、プロジェクト数が増えても運用コストが膨らみにくい仕組みを作ることです。

2-1. 標準アーキテクチャ構成の策定

基本方針として、私たちはセキュリティと運用性を考慮し、案件ごとにGoogle Cloud Projectを分離。疎結合を保ち、他案件との“相乗り”構成を避けるようにしています。インフラは極力サーバーレス構成とし、コストや管理負荷を抑えます。

以下が、よく使う標準構成の例です。

  • 前処理 / ETL：

    Dataformを使用し、SQLベースでデータ変換を管理

  • 推論処理：

    • バッチ：Workflows → Cloud Run jobs
    • API：Cloud Load Balancing + Cloud Run（アクセス制御は IAP） + FastAPI

  • モニタリングとアラート：

    Cloud Monitoring + Cloud Logging を活用し、Slack連携で通知

バッチ推論として推論結果をBigQueryに出力し、他のシステムがその結果を参照することもあれば、同期推論としてAPIサーバにモデルをロードしてリアルタイムの推論リクエストを受け付けることもあります。

2-2. 共通テンプレートを用意する・初期セットアップの自動化

Google Cloud Project 作成後の初期セットアップも自動化しています。以下を一括で整備できるテンプレートと仕組みを整えました。プロジェクトごとのカスタマイズは、共通構成の上に積み上げていくようにしています。

  • 基盤セットアップ：
    • Google Cloud, Terraform Cloud, GitHub Actions を連携。Service Account, Workload Identity などの権限構成も含めてIaCで管理
  • 開発テンプレート（cookiecutter）：
    • Terraform
    • Dockerfile
    • Python実行環境（uv）
    • MLパイプラインとAPIのコードベース

構成のポイントと設計思想は以下のとおりです。

  • MLパイプラインとAPIのコード構成は、案件固有のロジックと共通部を明確に分離する
    • 機能単位で Cloud, Container, Integration (パイプライン), IO (ファイル・BQ), Logic (前処理・学習・推論) の層で整理
    • APIはオニオンアーキテクチャを採用し、ドメインとインフラの依存を明確に分離
  • CI/CD整備済みでスタートできる環境を用意する
    • Terraform のplan/apply、コンテナビルド、Pythonのテストなどがテンプレートに含まれており、データサイエンティストも、ローカル検証 → クラウドへのデプロイ → 実行・改善のサイクルを自力で回せるよう支援

3. CI/CDの導入：分業と継続的改善を支える接着剤

AI/MLシステムの開発において、「PoCまではデータサイエンティスト、本番システム開発以降はエンジニアが担当する」といったウォーターフォール的な分業体制は、現実にはなかなか成立しません。PoC終了後も、モデル精度の改善や特徴量の追加、ビジネス要件の変化への対応が継続し、開発中はもちろん、リリース後もモデルは更新され続けることになります。

さらに、モデルアーキテクチャやデータ処理の設計と、インフラやAPIのパフォーマンス要件は相互に密接に関係しており、分業では対応が困難です。特に、生成AIを活用するシステムではアップデートサイクルが非常に速く、モデル本体や周辺機能を頻繁に差し替える必要があるケースも増えています。

こうした前提のもとでは、「エンジニアがデプロイまでをすべて担う」ような体制には限界があります。むしろ、データサイエンティストとエンジニアが密に連携し、コードの修正 → テスト → デプロイを継続的かつ協調的に回せる仕組みを構築することが、スピーディかつ安定した開発サイクルの鍵となります。

3-1. Gitベースで共同開発・レビュー

データサイエンティストとエンジニアが連携して開発を進めるために、私たちは同じGitリポジトリでコードを共同管理しています。GitHubを利用し、ブランチを切ってPull Requestベースで開発を進める、いわゆる GitHub Flow を基本としています。仕組みとして気を付けているのは以下の3点です。

  • データサイエンティストがモデルのロジックや前処理コードを修正した場合、エンジニアがすぐに確認・レビューできる仕組みにしています。
  • 逆に、インフラ設定やAPI側の変更があった場合には、データサイエンティストが挙動の違いやモデル入力の変化に気づけるようにしています。
  • 修正内容によっては、相互にレビューし合うことが重要です。片方だけでは持ちえない視点、検出できないリスクがあるためです。

同じコードベースを複数人で保守する以上、コード管理ツールとレビューフローの徹底が前提になります。競合によるデグレや、動かないコードの混入を防ぐための最低限の仕組みです。

3-2. CI/CDの導入

データサイエンティストとエンジニアの緊密な協力をサポートし、品質を保証しながら頻繁に変更をリリースするため、CI/CDパイプラインを構築・運用しています。具体的には、以下のような要素を組み込んでいます。

  • GitHub Actions による自動処理の実行
    • Lint、ユニットテスト、Dockerビルド、Terraformを用いたGoogle Cloudリソースのデプロイ等を実施しています。
  • 生成AI（LLM）によるコードの自動レビュー（導入検証中）
    • Pull Request 作成時に、生成AIがコードの可読性・セキュリティ・ロジックの妥当性をレビューコメントとして提示します。
    • 過去のPR履歴やレビュー傾向の情報も活用し、レビュー品質の向上とレビュー時間の短縮を両立する仕組みを構築中です。
    • 今後は、テストケースの自動生成やデータ変化の検知、推論品質の自動チェックといった領域まで、AIとCI/CDの統合をさらに進めていく予定です。

加えて、データサイエンティストが自律的に開発・改善できる環境を整えることも、継続的な開発を支える重要な要素と考えています。そのため、以下のような運用整備も進めています。

  • Gitのマージ操作だけでテスト・デプロイまで完了できる仕組み
    • DockerコマンドやTerraform、Cloud環境の詳細を把握せずとも、CI/CDパイプラインが裏側で処理を自動化することで、安全にデプロイまで進められるようにしています。
    • テストやパイプライン構築の初期段階では、エンジニアがサポートしながら徐々に自走できるように育成しています。
  • CIによるテスト通過を、データサイエンティストの責任範囲とする運用
    • mainブランチに動作しないコードがマージされないよう、コード修正 → テスト通過 → マージというフローを徹底しています。
    • テストが通らないコードスニペットから意図を読み取り、整合性を取ってプロダクションコードに仕上げるのは、エンジニアにとって非常に負担の重い作業です。こうした負荷を避けるためにも、テスト駆動でコードを整える文化を根付かせることが重要です。

4. 組織連携とスキル育成：領域を越えて協働するために

データサイエンティストとエンジニアは、求められるスキルセットや文化が大きく異なるため、お互いの業務や苦労が見えにくくなりがちです。その結果、「なぜそんなに時間がかかるの？」「そのタスクはそちら側では？」といったすれ違いが生じ、プロジェクト全体の推進力が損なわれてしまうこともあります。

AI/MLシステムは、データやモデルの変化に常に対応し続けなければならないため、ウォーターフォール的な縦割り組織では立ち行かなくなります。

チーム全体で一気通貫の体制を組み、アジャイル的に協働できる環境が、開発スピードと品質の両立と向上に繋がります。

4-1. 定期的なミーティングや勉強会で相互理解を深める

勉強会や、ざっくばらんなディスカッションの場を設け、各メンバーが自分の得意領域以外の背景や制約を理解する機会を増やしました。

理想としては1人のメンバーがデータサイエンスライフサイクル全体を担当できる状態が望ましいですが、現実には深い専門性が求められる領域も多くあります。そこで重要になるのが、スキルのグラデーションを前提に、お互いの領域を尊重し理解し合うことです。それにより、境界をまたいだ自然な協働が可能になります。

4-2. 環境と仕組みを整備し、越境を支援する

たとえば、初期段階ではエンジニアがコードベースを主導的に整備しますが、徐々にデータサイエンティストが改修やデプロイも担えるよう、段階的な業務移行をしていきます。

また、スキルのギャップを埋める手段としてAIコーディングアシストの活用も重要です。AIコーディングアシストを安全かつ最大限効率的に活用できるように、ツール選定やガイドライン、ドキュメントの整備も進行中です。今はまさに過渡期だからこそ、実験的に試しながらチームに合う形を模索していく姿勢が重要だと考えています。

まとめ

上記をはじめとする取り組みを粘り強く回し、継続的に改善していくことで、PoCと本番運用の間に立ちはだかる壁は徐々に低くなると思っています。「モデルができたらすぐにプロダクト導入できる」「データサイエンスをビジネス価値へ直結させ続ける」――。そんな文化を組織に根付かせ、AI/MLシステムのビジネスインパクトを最大化することを私たちは目指していきます。

バンダイナムコネクサス／TechBlog
バンダイナムコネクサス／TechBlogPublication

Discussion