機械学習基盤のアーキテクチャ特集　〜8社の設計意図と今後の展望〜

株式会社ABEJA

ABEJA Insight for Retailについて

ABEJA Insight for Retailは、お客様の店舗訪問から購入までの行動をデータから分析する、ABEJAが提供するDXツールです。店舗にIoTデバイス（カメラや来客カウンター等）を設置し、取得データを顧客企業に提供することで小売店舗の運営を支援しています。「リアル世界のGoogleAnalytics」をご想像いただけるとわかりやすいかもしれません。ABEJAが取得・提供するデータは、日々の店舗の改善活動や意思決定場面で利用していただいています。
ABEJA Insight for Retailにおける機械学習の適用領域は大きく分けて２つあります。１つは非構造化データに対する機械学習（例：カメラ画像からの人物検出）、もう一つが構造化データに対する機械学習（売上・来店人数等の時系列データの予測・クラスタリング）です。どちらも顧客企業がデータを可視化・分析する為に必要な領域になります。今回は、構造化データに対するデータ処理および機械学習について解説します。
※ABEJA Insight for Retailは、「ABEJA Platform」のアプリケーションの一つです「ABEJA　Platform」は、ABEJAが提供する、DXの実行に必要なプロセスを提供し・安定的な運用を行うソフトウェア群です。

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

• 大規模なデータ集計を低コストかつ効率よく行う土壌(BigQuery利用)
  

カウンティングイベントやPOSトランザクションを合計すると、現時点で数億レコードのデータが存在しています。適切にパーティションを切ることでスキャン量を抑えつつ、大規模なデータ分析が可能な土壌を整えています。

• 誰でもロジック品質・安定性を評価できる土壌(SRE系ツールの充実化)
  

サーバーメトリクス、アプリケーションログ、例外エラー等を蓄積し、チーム内で可視化・分析できるようにしています。ソフトウェアエンジニアやMLエンジニアが同じツールで、ロジックの品質やパフォーマンスを評価できる体制を作っています。

• MLエンジニアのロジックアップデートを支援(GitOpsの採用)
  

前まではリポジトリやサービス毎にCI/CDを設定し、ロジックのデプロイを行っていました。リポジトリ毎にブランチ運用戦略が異なったり、考慮しないといけないクセがあるなど、MLエンジニア視点だと触りにくい部分がありました。Gitopsの採用により、必要な変更をマージするだけで、APIや集計・MLロジックの差し替えがしやすくなりました。

現在の課題と今後の改善予定

• よりデータガバナンスを担保する仕組みの強化
  

主にデータ品質管理の話になります。故障したIoTデバイスが含まれている場合、データ提供や学習に影響が出ます。数値データに大きな影響を及ぼす社会的事象も要ケアです。例えば、COVID-19による緊急事態宣言中のデータは、ほぼ外れ値で学習に使えませんでした。データ品質をより担保できる仕組みを今後は検討していきたいと考えています。

• BigQueryのパーティション数制限問題(地味な困りごと)
  

BigQueryの１つのJOBが処理できるパーティション数には制限が存在します。2024年7月現在では4,000パーティションが上限となっています。例えば、BigQueryのパーティションを日付で区切る場合、約11年分(4,000/365=10.95…)のデータしか一度に分析することができません。内部的に回避方法はいくつかありますが、LongTermなデータを分析が必要なケースにおいて地味に困るシーンがあります。

◆執筆：CTO室プラットフォームグループ　グループマネージャー 　大田黒 紘之 @xecus

【サービス公式サイト】
https://www.abejainc.com/insight-retail-main

【株式会社ABEJAのエンジニア求人】
　＜本記事該当ポジション＞
【フルリモ/フレックス】AIプロダクトの成長を加速させるソフトウェアエンジニア募集（ミドル）
【フルリモ/フレックス】AIプロダクトの成長を加速させるソフトウェアエンジニア募集（シニア）

　＜その他エンジニアポジション＞
https://findy-code.io/companies/203/jobs

コミューン株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

コミューンでは、あらゆる組織とひとのコミュニケーションをなめらかにするコミュニティサクセスプラットフォーム「Commune」を提供しています。

こちらの機械学習基盤のアーキテクチャは、エンドユーザーに提供している推薦システムにおける構成となっています。コミューンでは、本体アプリケーション含めてGoogle Cloud を採用しており、機械学習システムもそれに合わせる形でGoogle Cloud の各種マネージドサービスを採用することにしました。

エンドユーザーに行う推薦として、関連した投稿を出すレコメンドやユーザー毎にパーソナライズしたレコメンドを行うために、Google Cloud のVertex AI Pipelines を用いて機械学習パイプラインを構築しています。Vertex AI Pipelines はコンポーネント単位で実行管理することができるため、コンポーネント毎のマシンスペックの割り当て、適切な粒度での処理の分割、再利用性などがしやすく少人数で開発や運用をするには良いサービスだと感じています。その機械学習パイプラインを定期実行する方法として、Cloud Scheduler + Cloud Functions でパイプライントリガーを実装しました。工夫として、新しくサービスを提供する企業が増えた場合に自動的にそれを検知し、対象となるテナントの自動追加を行い、実行すべき機械学習パイプラインを制御しています。

もう1つ機械学習基盤の特徴は、本体アプリケーションとのインターフェースとして機械学習用のAPI すなわちML-API を用意しているところです。ML-API の役割としては、バッチにより生成された推薦リストをリクエストに応じて取り出して、本体アプリケーションに返すことはもちろんですが、AB テスト時のテナント・ユーザー振り分けを行ったり、モデル改善や効果検証に必要なログ出力をML-API からも行ったり、必要に応じて推薦リストのフィルタリングやハンドリングを行ったりする役割も担っています。

現在の課題と今後の改善予定

現在、機械学習パイプラインでのモデル作成における実験基盤があまり整備されていないというのが課題の1つです。Vertex AI Experiments に一部パラメータ等を保存していますが、保存すべきメトリクスが不十分だったり、保存した結果を上手く活用することができていない状況です。例えば、推薦システムでは、推薦リストの多様性等を考慮するためにメトリクスを計算し、偏りがあればモデル改善のヒントにするといったアクションを取れますが、そういったことはまだできていません。そのため実験基盤の選定や何をメトリクスとして記録すべきかなどから議論していく必要があります。

他には、機械学習システムの信頼性に対する取り組みが不足していることが課題としてあります。検証中や実装中の機械学習機能はどんどん増えているものの、それらの機能群が安定して価値を出し続けるための用意は十分とは言えません。また、信頼性と言っても様々な観点があるかと思いますが、特に”モニタリング”を通したシステム、データ、モデルの状態を正しく把握することに努めるべきだと感じています。何かしらシグナルがあった時にいち早くそれに気づき、その原因を理解し、改善のためのアクションを起こせないようでは十分とは言えないと考えています。まずは最低限行っているシステムモニタリングのレベルを引き上げるべく、可視化している結果を分析したり、自分達の肌感覚と定量の数値を擦り合わせたり（正常な状態や上手く動いているといった状態を理解して定義）していきたいです。今後はSRE for ML やML Reliability Engineering のような動きをしていけると良いなと考えています。

◆執筆：プロダクト&データ部 ML/DS チームテックリードマネージャー 柏木正隆 @asteriam_fp

【サービス公式サイト】
https://commune.co.jp/

【コミューン株式会社のエンジニア求人】
Analytics engineer/アナリティクスエンジニア 等
https://findy-code.io/companies/1193/jobs

株式会社ディー・エヌ・エー

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

DeNAでは多くの機械学習プロジェクトがありますが、プロジェクトの数に対し、システムの開発運用を担う機械学習エンジニアやSREを少なく抑えて運用しています。各案件に深く入り込んで設計、実装、運用を担当する機械学習エンジニアと、幅広くサービス開発、運用の生産性、品質を高めるための実装、運用を行うSREが計約10名ほど在籍しています。このメンバーで数十件の機械学習プロジェクトを運用しながら、新規のプロジェクトの設計や実装を行います。少人数で効率的に多くの機械学習システムを開発、運用するために、DeNAでは上記のようなアーキテクチャの機械学習システムを設計しました。
まず、機械学習システムの学習フェーズにおいては、Vertex AI Pipelinesを活用しています。これにより、機械学習の一連の工程を統合し、自動化しています。このワークフローは、テンプレート化された実装やTerraformモジュールを利用して簡単にデプロイできるため、機械学習エンジニアはその案件固有の実装に集中できます。モデルの推論が事前に行えるような場合では、このワークフローでモデル推論までを行います。例えばモバゲーのアセット検索のプロジェクトでは、検索対象のデータは更新の頻度が少なく、利用者のリクエストの度ではなく事前に推論ができるため、Vertex AI Pipelines上でモデル推論を行っています。
一方、モデルの推論が事前に行えない場合には、SREが開発している自社開発の機械学習モデル推論プラットフォーム 「Hekatoncheir」を用いてWeb API形式でモデルをサービングします。この基盤でも実装や運用の標準化を図り、少人数で多数のサービスを運用できるようにしています。例えばPocochaのAIを用いた審査効率化の取り組みのプロジェクトでは、プラットフォームの健全性の担保のため、違反行為はなるべく早く検知する必要があります。そのため、Web API形式でモデルをサービングし、お客様の行動から随時違反行為を検知できるようにしています。

現在の課題と今後の改善予定

一部の古い機械学習プロジェクトの学習フェーズでは、手動での学習、評価、ワークフローのデプロイなどが残っています。まずはインターフェースを変えずに、古いシステムを現在のアーキテクチャのように変えていき、属人性をなくしたり、チーム全体の認知負荷を低くしたりしていきたいです。
また、機械学習モデル推論プラットフォームにおいて、現在 Triton Inference Serverを用いた機械学習モデルの推論のみを行うサーバーと、前処理と後処理を行うサーバーに分割を進めています。これによりスループットが改善し、GKEのコストを抑えることができます。こちらも一部の案件ではすでに導入済みですが、今後置き換えを進めていきたいです。


◆執筆：ソリューション本部データ統括部データ基盤部MLエンジニアリンググループ 　玉木竜二　@tamaki_730

【DeNA × AI 公式サイト】
https://dena.ai/

【株式会社ディー・エヌ・エーのエンジニア求人】
【事業横断】AI案件のプロジェクトマネージャー　等
https://herp.careers/v1/denacareer/requisition-groups/e39b56aa-5120-477f-9f28-29ec286b9dcf

FastLabel株式会社

FastLabelについて

FastLabelは、AI開発の各プロセスに存在するリソース・仕組みの不足をワンストップで解決するAIインフラを提供し、持続可能なAI開発・運用を実現するプラットフォームです。その中でも今回は、FastLabelの中で推論・学習が関わる機能を支えるアーキテクチャついて解説します。

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

FastLabelでは、AWSのSageMakerを用いて機械学習（ML）モデルのトレーニングと推論が可能なアプリケーションを開発しています。SageMakerは、MLモデルを運用するためのマネージドサービスであり、インフラの設定・管理が不要で、導入コストが低く、比較的使いやすいサービスです。
アプリケーションサーバーからSageMakerのトレーニングジョブを起動し、学習が完了するとEventBridgeからSQSにメッセージを送信します。SQSからBatchサーバーにメッセージを送り、学習済みモデルの情報をDBに保存します。SageMakerをアプリケーションに組み込んでいる企業は少なく、トレーニングジョブのステータスを検知してアプリケーションサーバーに通知する仕組みは、FastLabel特有のアーキテクチャです。

現在の課題と今後の改善予定

SageMakerを利用することでインフラ管理の手間が省け、開発速度が向上したり、運用コストが低下しています。しかし、利用料金が高いと感じることもあります。そのため、EC2などを使用したSageMakerに依存しないMLモデルの学習環境の構築を検討しています。
学習データやモデルのファイル配置、パラメータの指定方法はSageMakerの制約に依存している部分が多く、他のクラウドサービスへの移行が必要になった場合、修正コストが大きくなります。Dockerイメージの移行方法を含め、より良い方法を模索しています。

◆執筆：開発部モデル開発グループ マネージャー 爲西貴大　@ttarkkaru922

【サービス公式サイト】
https://fastlabel.ai/

【FastLabel株式会社のエンジニア求人】
《売上成長率500%》日本産業をDX！急成長SaaSスタートアップのエンジニア組織の価値をリードするVPoEを募集【リモート・フレックス】 等
https://findy-code.io/companies/1031/jobs

GO株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

タクシーアプリ『GO』は、時間帯や天候によって大きくトラフィックが変動するサービスです。
そのため、タクシーアプリ『GO』の機械学習基盤では、ユーザーの需要量に大きな変動をもたらす天候や交通情報などのリアルタイムデータを活用するために、FeatureStore基盤を整備しています。上図の「共有Redis」がその役割を担っています。
他のマイクロサービスから直近のリアルタイムデータを継続的に収集し、FeatureStoreに蓄積します。これにより、常に最新のデータに基づいて推論が可能となっています。
また、過去の統計値とリアルタイムデータを組み合わせることで、中長期のトレンドと短期のトレンドの両方に追従できる予測モデルを構築しています。

現在の課題と今後の改善予定

現在、複数のサービスが共通のRedisを参照しているため、単一障害点となっており、マイクロサービスの原則に反しています。Redisがダウンした場合、全てのサービスに影響が及ぶリスクがあります。
この課題を解決するために、Redisを個別のマイクロサービスとして分離して疎結合にし、フォールバック処理を加えることで、他のサービスへの影響を最小限に抑える予定です。
また、Redisの冗長化やフェイルオーバー構成の強化も検討しています。

◆執筆：GO株式会社 開発本部 AI技術開発部 データプラットフォームグループ　鈴木隆史

【サービス公式サイト】
https://go.goinc.jp/

【GO株式会社のエンジニア求人】
【フルリモート】CVエンジニア募集｜ドライブレコーダー画像を用いた事故防止サービスおよび地図更新研究向けCV開発 #AI #画像認識 #交通安全 #スーパーフレックス #Kaggler 等
https://findy-code.io/companies/795/jobs

株式会社LayerX

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

バクラク事業では、日々の経理担当者の業務や現場の稟議や経費精算作業において、圧倒的に使いやすくワクワクするような体験作りを目指しています。バクラクでは法人の支出に関わる作業をサポートするサービス群を提供しており、請求書受取・請求書発行・稟議経費精算・法人カード・電子帳簿保存法対応ストレージサービスなどがあります。
その中で、AI-OCR機能という機械学習を活用した機能が、バクラクの提供する全てのサービスで利用されています。今回はそのアーキテクチャを紹介したいと思います。

AI-OCR API

AI-OCR機能はバクラクの各サービスから独立して存在します。AI-OCR APIは各サービスからのファイルに関する情報を含むリクエストを受けると、5秒以内にそのサービスで利用する項目（例：取引先名・書類日付・支払金額・支払期日・振込先口座など）を読み取りその結果を各サービスにレスポンスとして返します。
AI-OCRの内部の処理は大きく前処理・推論・後処理から構成され、それぞれのタスクはAI-OCR WorkerとSQSで非同期処理することで突発的にリクエストが増えてもスケールしやすくしています。
書類データを扱う処理は内部データが欠損していることもしばしばあり、予期せぬ挙動が発生しうるため、ファイルを開くような処理はAPIやworkerで処理せず、Lambda関数に逃して処理することでpanicやメモリ領域を大量に使う処理が発生してしまっても他のリクエストには影響しないようにしています。

機械学習パイプライン

機械学習モデルはVertex AI Pipelinesを用いた実験パイプラインで作成されています。Vertex AI Pipelinesを選んだ背景としては、メンバーの知見があったからという理由もありますが、フルマネージドでサーバーレスに動作するためインフラを持たなくていい、というのが今のフェーズのチーム規模の要件に合致していると感じたためです。また、OSSであるKubeflow Pipelinesを用いて実装できるため、汎用性が高いと感じました。
学習に使用するデータは、各プロダクトの書類データやアノテーション結果などをBigQueryにインポートしており、BigQuery内で機械学習モデルに入力するための前処理などが完結するように工夫しています。
プロダクトの本番環境はAWS上で構築されているため、APIはSageMaker Endpointのカスタムコンテナで提供しています。少し工夫している点として、前処理・後処理などのCPUで動作する部分とGPUで推論する部分を分けているところがあります。このようにすることで、CPU、GPUのどちらかがボトルネックになった際に、それぞれの要件に合わせてスケールアウトさせることを可能にしています。また、GPU推論にはTriton Inference Serverを用いており、TensorRTのモデルをデプロイすることで低レイテンシを実現しています。

現在の課題と今後の改善予定

AI-OCR API

AI-OCRのAPIは非同期処理によって大量のリクエストにも対応できるようにしていますが、実はAPIは一定時間ポーリングしたのち、処理が終わらない場合はそれ以降は処理がまだ途中であってもタイムアウトとしてクライアントにリクエストを返すような同期的な挙動をしています。したがって、非同期処理の良さをうまく使いきれないのが現状です。
今後は同期処理すべきものと非同期処理すべきものを見極めた上で処理の方法を変え、それぞれの恩恵を十分に受けられるようなアーキテクチャを目指したいと思っています。たとえばリアルタイム性を求められないが数万件のリクエストを捌きたいというニーズと、数十枚を即時でデータ化して欲しいというニーズがある場合、同じAPIで処理するのではなく、同期と非同期APIをそれぞれ用意してあげると効率よく処理できるのではないかと考えています。

機械学習パイプライン

まず、実験パイプラインの話だと実験の高速化が課題になっています。一定VertexAI Pipelinesでキャッシュ機能などを自作し効率化は図っていますが、事業の成長に伴って扱えるデータも指数関数的に増加しており、単純に全てのデータを用いてしまうと非効率な学習・評価になってしまいます。まず、データに立ち返ってどういう問題を解くべきか、どういう評価をするべきか、をしっかり考えた上で、事業成長に対してスケールできるような実験パイプラインの構築を行っていく予定です。
また、コンパウンドプロダクトならではの悩みかもしれないですが、プロダクトが増えていくことによって、AI-OCR APIが呼び出される箇所が多くなり、プロダクトに対して必要な読み取り項目も増えてきています。今後、増加する項目に応じて複数のモデルを運用していく可能性もあり、どこまでの処理を共通化するか、どのように運用するか、などを考慮したML基盤を構築する必要性が出てくると思っています。まずは、モノレポ的な開発体制を取っていくことでそのような課題を解決していこうと考えています。

◆執筆：
北岡知晃　バクラク事業部 機械学習グループ ソフトウェアエンジニア　@tapioca_pudd
島越直人　バクラク事業部 機械学習グループ テックリード　@nt_4o54

Sansan株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

Sansan の R&D では独自の OCR を開発しており、機械学習が利用されています。上記の図は、この開発で利用している MLOps を例にして記載しています。

まず、 MLOps を進める理由です。導入を進めることで機械学習システムの開発から運用までのサイクルが改善・効率化され、ビジネス価値が最大化されることを期待しています。
機械学習システムの開発において避けられないのは、データ収集・前処理・学習です。ここでは AWS の SageMaker Processing と SageMaker Training を利用しています。SageMaker を使用することで、データ収集からモデル学習まで属人的でない再現性のある環境を提供できます。再現性のある環境は、デプロイまで一貫したワークフローの構築を可能にしています。
Sansan では研究員とエンジニアのロールが分かれていますが、ワークフローを標準化することにより連携がスムーズになり、サービスのリリースサイクルが短縮されています。
さらに、実験管理ツールを導入することで、学習の経過が可視化され、意思決定がしやすくなっています。過去のパラメータなども確認できるため、チームのコラボレーションや再現性を高められています。

現在の課題と今後の改善予定

Sansan の R&D はさまざまな事業へシステムを提供しています。各事業で異なるクラウド環境やアカウントで運用しています。機械学習システムが徐々に増えるなか、対象事業それぞれに局所最適化して運用しているのが実情で、 MLOps において標準化は進んでいません。

モデル作成のためのデータ収集、学習、評価のパイプラインを標準化することはもちろん、推論結果が誤っている情報を抽出して再度学習に利用するフローも構築し、機械学習システムが自動で改善されていく仕組みを実現したいと考えています。

◆執筆：技術本部 研究開発部 アーキテクトグループ 鷹箸 孝典

【サービス公式サイト】
https://jp.sansan.com/

【Sansan株式会社のエンジニア求人】
【リモートOK / フレックス】研究開発部門 データエンジニア ［全社横断データ分析基盤］ 等
https://findy-code.io/companies/173/jobs

ファインディ株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

ファインディが開発している「転職サービスFindy」のユーザー様に提供している推薦システムのモデル学習と推論において、上記のような学習・推論自動化パイプラインを構築しています。モデルの自動学習にはGoogle CloudのVertex AI Pipelines、モデルの推論にはAWSのElastic Container Service(ECS)のバッチ実行を採用しました。
技術採用の背景や意図として、モデル学習のパイプラインを構築するにあたり、弊社ではサービス運用によって取得したデータをBigQueryに蓄積していることから、同一クラウドサービス上で簡易に実装することのできるVertex AI Pipelinesを採用することにしました。また、GitHub Actions Workflowと連携させた事で、常に学習パイプラインのコードを最新の状態に保ちつつ、週に1度のモデル更新も自動で起動するよう工夫しました。 そのおかげで、基本的にモデルの更新には人手が全くかからない状態を実現できました。
モデル推論は、ファインディのサービス基盤がAWS上に構築されている事から、AWS上で簡易にバッチとしてタスクを実行する事ができるECSを採用しました。週次での学習パイプラインが実行された際に、最新の学習済みモデルを保持した推論用コンテナを同時に作成しており、そのコンテナの受け渡しだけで済むので、運用コストをグッと抑えることができています。コンテナの受け渡しも、GitHub Actions Workflowで実現しています。

現在の課題と今後の改善予定

社内に存在するその他の機械学習プロジェクトにおいても、上記アーキテクチャによるモデルの学習・推論を実現する事で、運用コストが抑えられる取り組みがいくつかありますが、現状は推論システム専用の構築にしてしまっているので、横展開が追いついていない点が現在の課題です。
今後は、本アーキテクチャを横展開し、社内で運用される機械学習プロジェクトに徐々に適応していきたいと考えています。

◆執筆：ファインディ株式会社　CTO室データソリューションチーム　笹野翔太　@Edyyyyon

【サービス公式サイト】
https://findy-code.io/

【ファインディ株式会社のエンジニア求人】
アルゴリズムの力でエンジニアスキルや開発生産性を可視化する機械学習エンジニアを募集！ 等
https://findy-code.io/companies/164/jobs