📖
AI/MLシステムの量産体制を目指して（前編：課題と戦略）

バンダイナムコネクサス広報
2024/12/05に公開
 背景・経緯
 MLチームの紹介こんにちは、株式会社バンダイナムコネクサスのデータ戦略部でML（機械学習）チームに所属している山野です。弊社データ戦略部は、グループ最大のデータ戦略部門です。MLチームはMLプロダクト/プロジェクトマネジメント、モデリング、およびMLシステムの開発/運用にスペシャリティを持つメンバーで構成されています。私たちMLチームはこれまで、MLプロダクト開発を一気通貫で担当してきました。過去の案件事例の一つはこちら（レコメンドシステム導入事例）です。

 MLチームのスコープ
青背景部分がMLチームのスコープであり、今回はその中の赤枠で示された部分の役割として実施した内容をまとめました。

 AI/ML技術の進展とその影響近年、AI/ML技術の進歩は目覚ましく、その活用範囲と必要性が急速に広がっています。このため、ML専門チームに限らず、データを活用しようとするあらゆるチームが必然的にAI/MLに取り組むようになっています。さらに、ライブラリやAPIの整備による技術の民主化も、この流れを後押ししています。

 PoCとプロダクション環境のギャップしかし、PoC（概念実証）フェーズでデータ分析担当者のローカル環境で小規模データで一度だけMLモデルを動かすことと、実運用フェーズでプロダクション環境で大規模データで継続的かつ安定的にMLモデルの価値を発揮させることとの間には、大きな壁があります。

 課題解決に向けたMLチームの取り組み私たちMLチームには、上記に関連する相談が頻繁に寄せられるようになりました。そこで、私たちはこれらの課題を解決することで全社のリソースを最大限に活用し、継続的に価値提供するMLシステムを量産していくためにさまざまな取り組みを行ってきました。今回は、その取り組みの一部をご紹介いたします。
※重要な補足として、本記事では簡便さのために「MLのシステム化」と記載していますが、今回の取り組みはMLに限らず、データ分析担当者が開発したコード全般のシステム化を対象としています。

 MLシステム開発/運用の難しさ以下はMicrosoftのUsing MLOps to Bring ML to Productionからの引用です。データ分析担当者のラップトップでモデルが完成したと思ってから、プロダクション環境にモデルをデプロイして運用していくまでには、（意外と）多くのやらなければならないことがあることを示しています。

 そもそもなぜシステム化するのか？
自動化と効率性のため
手動実行は開発者に大きな負担をかけ、効率性に欠けます。一方、システムによる自動実行は人的エラーのリスクを減少させ、運用コストの削減にも寄与します。

再現性と一貫性のため
一度はとある担当者の環境で正常に動作して結果が得られたとしても、「同じ結果が再現できない」という状況が後々問題になることがあります。プロダクション環境ではスクリプトやモデルが常に同じ条件で実行される環境を整えることで、結果の再現性と一貫性を保証する必要があります。CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを適用することで、デプロイや更新を自動化し、変更が一貫して適用されるようにします。

スケーラビリティのため
ローカルまたは単一のサーバー環境では、大量のデータや高頻度のトランザクションに対応することが難しい場合があります。プロダクション環境では必要に応じて計算リソースをスケールアップし、大規模データセットや高頻度のジョブに対応することが求められます。

安定性と信頼性のため
ノートブックは主に開発環境として設計されているため、また手動実行では不整合が発生しやすく信頼性が求められる運用には適していません。プロダクション環境では監視、アラート、フォールトトレランスなどの高い可用性と信頼性が必要です。ジョブが障害で中断した場合でも、自動リトライや障害対応の仕組みを整備する必要があります。

セキュリティとアクセス管理のため
プロダクション環境では、アクセス制御と監査機能を導入し、セキュリティリスクを軽減する必要があります。また、コンプライアンスおよびガバナンスの要求に対応することが求められます。例えば、弊社の場合、グループ会社のデータを取り扱うため、担当者のPCや多くの人が利用する共有サンドボックス環境ではなく、グループ会社・部門ごとなどに適切に分けられたGoogle Cloud Projectなどを使用することが重要です。これにより、セキュリティルールやデータガバナンスを遵守した設計を実現します。

逆に、上記の条件に当てはまらない場合は、システム化は不要かもしれません。

 何をする必要があるのか？例えば下記のような項目を検討する必要があります。

Pythonコードを動かすサーバを1台立てるだけと思われがちですが、実際には意外と多くのやるべきことがあります。特に「この案件は本当にシンプルにこのPythonを動かしてもらうだけだから」という案件に限って、大幅なリファクタリングが必要だったり、連携先システムとの仕様詰めで多くの作業が発生したり、データの扱いを厳密に行うためにプロジェクト分割およびアクセス制御設計が必要だったりします。

 技術的負債との向き合い方特に考慮すべき点は、ワンショットの分析やレポーティングとは異なり、一度システムを作るとそれは「モノ」として残り、運用していく必要があるということです。システムが継続的に自動で働いてくれるという面ではもちろん便利ですが、これは放置して良いというわけではなく、コストが発生しますし、定期的なメンテナンスが必要です。
技術的負債とは、ソフトウェア開発において短期的な利便性やスピードを優先した結果、後になって改善や修正が必要となる作業の積み残しや問題点のことを指します。この負債が積み上がると、次第に維持管理コストの増加・デプロイメントの遅延・チームの士気低下などの問題を引き起こします。単に早く雑に作るだけなら難しくはありませんが、やがて痛い目に遭い、組織の成長を妨げることになります。したがって、組織として技術的負債を極力生まないようにし、継続的に管理し解消していくスキルと文化の醸成が重要で、また第一歩としてはエンジニアと経営者間の情報非対象性を解消する必要があります。

 なぜMLチームが取り組んだのか？データ分析担当者は、データ分析やドメインに関する高度なスペシャリティを持っていますが、一方でMLのシステム化には異なるスキルセットが必要です（下記参照）。このため、データ分析担当者がシステム化までの全工程をカバーするのは難しい状況にあります。また、世の中でもそのようなスキルセットを持つ人材は希少です。したがって、各担当者が自身の専門分野に集中することにより、全社としての生産性を最大化するため、システム開発・運用の領域に関してはMLチームが取り組んでいます。

出展：https://arxiv.org/pdf/2205.02302.pdf

 内製開発組織のメリット少し話はそれますが、今回のようなケースでは特に内製開発組織が統一的に取り組むことが適していると考えています。

クイックな立ち上がりと柔軟な対応ができるから
内製開発組織であれば、PoCがうまくいくかどうかまだわからない段階から、柔軟に連携し始めることができます。小規模から中規模の開発が多く、契約や発注が大きな割合を占める場面でも迅速に対応できます。個別最適でシステムを構築するのではなく、既存の環境や方針を理解して適切に設計することができ、様々な部門との連携もスムーズに行えます。

ナレッジの蓄積・チーム習熟度向上による生産性および品質向上ができるから
案件ごとに検討と対応が必要があるものの、設計の勘所などは横展開できる部分も多いため、組織内にナレッジやスキルを積み上げていって、転用したり統制を高めることができます。これにより、生産性向上および品質の担保がしやすくなります。前の章でも述べた通り、技術的負債の管理や解消のためにも、内製開発は有効です。また、外部ベンダに開発のみを発注すると運用効率化のインセンティブが働きにくく、運用まで個別に発注するのはトータルで見ると効率が悪くなる場合があります。

 今回の取り組みのポイント記事が長くなってきてしまったので詳細は後編記事にまとめますが、ポイントは二つでした。

クイックに構築・運用できるようにした
「機械学習チームの悲劇」と呼ばれる現象があります。これは、PoCが終わった段階でプロダクトへの組み込みを見積もったところ、予想以上の工数がかかることが判明したため、優先度が下がり、結果的に導入されず運用されなくなることを指します。この状況を回避し、またROIの観点からも開発の責務として生産性を極限まで高める必要があります。そのために、テンプレートドキュメントやコード、環境の整備に取り組んできました。さらに、チーム全体のスキル向上や文化の醸成も重要なポイントとなりました。

データ分析担当者とML（MLOps）が協働して開発・運用できるようにした
効率的な開発と継続的な運用を実現するためには、データ分析担当者とML（MLOps）チームが協働することが重要です。分析処理やデータの流れ、そして分析結果がどのように活用されるかをきちんと理解しなければ、最適なアーキテクチャを組むことはできません。モデルが完成したからといって、システム組み込みをウォーターフォール的に進められることは少なく、システム開発中もモデルやコードは並行して変更されます。また、従来のシステムとは異なり、MLシステムは常に変化するデータに基づいて振る舞いが変わるため、運用後も継続的な改善が必要です。そのため、異なるスキルセットと文化を持つチームが協働するための仕組みや、様々な取り組みを行いました。具体的には、Gitベースでの開発フローの導入やCI/CDの整備などが挙げられます。相互理解を深めるための具体的な手段の一つとして、このブログを執筆することも、その一助となればと思っています。

 取り組んでみた結果と今後10月頃から取り組みを始め、すでに複数の分析チームと連携し始め、すでにリリースしたシステムもあります。テキスト分析、時系列分析、需要予測、類似画像検索などなど、今後も全社の総力を上げて推進していく予定です。スピーディに実運用に乗せて施策を価値につなげるとともに、異なるバックボーンを持つメンバーの協働を設計し組織全体で対応する体制を実現しつつあります。しかし、まだまだ改善の余地があるため、引き続きブラッシュアップしていきます。
続編では、今回の取り組みの技術的な詳細をお伝えします。