公開日 2025/06/09更新日 2025/06/09

Cloud Run・Vertex AI を活用した最適化システム開発をスケールさせる基盤戦略

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

本記事は、株式会社 ALGO ARTIS の藤原秀平さんによる寄稿です。計画業務を最適化する業務システムの開発・運用に取り組む中で得た知見をもとに、Google Cloud 上で Cloud Run・Vertex AI などを活用して、少人数の開発体制でも高い運用効率と信頼性を両立させる技術基盤の構築方法を紹介します。

はじめに

ALGO ARTIS は「社会基盤の最適化」というミッションを掲げ、様々な計画業務の効率化に取り組んでいます。
発電所に燃料を運ぶための船の運用計画を立てたり、工場などの生産計画を作ったりという、社会を支えるシステムを開発しています。

Optium 導入事例

たとえば配船ならば、必要な物資を運搬しつつ、船や港の利用条件のような様々な制約を守らなければなりません。
そして、それらの制約を満たしつつ費用最小化などの目的を達成する計画を作成します。
このような計画作成業務はベテラン社員が多くの時間と労力をかけないとできない職人技です。

ALGO ARTIS は、この計画作成業務を最適化アルゴリズムによって自動化し、それを組み込んだ業務システムを開発しています。

最適化基盤のスケール戦略

ALGO ARTIS では当初案件ごとにシステムを構築していましたが、この状態からいかに共通化して開発をスケールさせていくかが課題でした。

工場の生産計画と配船計画では必要とされるのは全く別のサービスのように思われるかもしれません。
しかし、計画最適化システムに要求される仕組みは共通する部分も多くあります。
たとえば、以下は最適化システムを使った典型的な業務フローのひとつです。

必要な業務データをアップロードする
Web UI 上でのデータを閲覧・編集する
最適化機能で計画を自動生成する
Web UI 上で生成された計画を人間が閲覧・編集して最終決定とする
完成した計画をダウンロードして業務に利用する

大雑把な流れは共通ですが、この中で特に案件に合わせて個別に作り込むことを要求されるのが最適化アルゴリズムと UI の 2 つです。
入力データや作りたい計画が違えばアルゴリズムは当然変わってきますし、ここを作り込めるアルゴリズムエンジニアの層の厚さが ALGO ARTIS の強みでもあります。
それでも実際には自動生成された計画がそのまま採用されることは稀で、大抵は自動生成されたものをベースに人が編集することで業務の効率化を達成します。
そのため、計画を可視化して編集するための UI を案件に合わせて作り込むこともサービスの価値に直結する重要なポイントでした。

したがって、我々の基盤には アーキテクチャは共通化して開発・運用を効率化しつつ、手軽にアルゴリズムや UI を差し替えられること が要求されました。

基盤のアーキテクチャ

基盤を取り巻く開発には次のような役割が存在します。

案件ごとの最適化アルゴリズムを実装するアルゴリズムエンジニア
案件ごとの UI を実装するフロントエンドエンジニア
基盤の実装を担当するチーム

ここで最適化案件を効率良く進めるために我々が目指したのは次のような形です。

三者が異なるリリースサイクルで開発して素早く試行錯誤できる
フロントエンドエンジニアとアルゴリズムエンジニアで案件を完遂できる
その他の要素を基盤で引き受ける

そこで、以下の図のようにアルゴリズムや UI を基盤と切り離し、基盤から独立したリリースサイクルを持てるようなアーキテクチャを Google Cloud 上で実現しました。

会員限定コンテンツ無料登録してアーキテクチャを見る
アルゴリズムのリリースは Artifact Registry へ Docker イメージを push、UI の追加はコードを Cloud Storage へアップロードすることで完了します。

また、全体を通して基盤には Cloud Run などのサーバーレスなサービスを利用しています。

【編集部による基礎知識の解説✏️】
Cloud Run は、Google Cloud が提供するマネージドなサーバーレス実行環境です。コンテナイメージをデプロイするだけでスケーラブルに処理を実行できます。インフラ管理を必要とせず、リクエスト単位でスケールするため、スタートアップのような少人数体制でも高可用性を確保できることが大きな利点です。

「サーバーレスなもので足りるのであればそれを使う」はクラウドの基本ということもありますが、ALGO ARTIS の場合は特に以下の点を考慮しての判断です。

スタートアップのため少人数での開発・運用となる
それでいて顧客の事業のコアとなる業務やデータを預かることになるため高い信頼性が求められる

ここからは、技術選定も含めてもう少し詳細に見ていきましょう。

最適化機能のアーキテクチャ

最適化は時間がかかる処理であるため、以下の図のように Vertex AI を使った非同期なコンテナジョブとして動作します。

会員限定コンテンツ無料登録してアーキテクチャを見る
Vertex AI は機械学習の訓練にも使われるサービスのため、最適化にも十分なマシンスペックを確保して基盤の負荷を気にすることなくジョブを実行できます。

【編集部による基礎知識の解説✏️】
Vertex AI は一般的に機械学習モデルのトレーニングや推論に使われるマネージドサービスですが、高性能な計算リソースを利用したジョブ管理機能も備えているため、最適化処理のように計算量の多いバッチタスクにも適しています。

似たようなサービスとしては Cloud Run Jobs が存在していますが、最適化のような重い処理には Vertex AI が向いているでしょう。一方で起動に少し時間が掛かるという欠点もあるため、最適化以外の非同期なジョブでは Cloud Run Jobs を利用するという形で使い分けています。

データの入出力は Google Cloud Storage を介して行い、入出力データのフォーマットさえ合っていれば最適化ジョブのコンテナは簡単に差し替えが可能です。
Docker イメージは Artifact Registry で管理しているので、アルゴリズムエンジニアが新しいイメージを Artifact Registry に push するだけで基盤と独立してリリースできます。

【編集部による基礎知識の解説✏️】
Artifact Registry は Google Cloud 上で提供されるコンテナイメージなどのアーティファクト管理サービスです。チームごとにアクセス制御を設定でき、セキュアかつ効率的なリリース管理が可能。CI/CD パイプラインとの連携も容易です。

UI 周りのアーキテクチャ

基盤にはデータのアップロードなど最低限の UI のみが用意されており、開発者はフロントエンドのコードをアップロードすることでここに任意の UI を追加できます。
もちろん、フロントエンドのコードをアップロードするための UI も基盤側であらかじめ用意されています。
アップロードされたフロントエンドのコードは Cloud Storage に保存され、必要に応じてユーザーへ配信されます。
基盤側には計画データなどにアクセスするためのインターフェースが用意されており、フロントエンドエンジニアはそれらのデータを可視化して顧客が閲覧・編集しやすい UI を作ることに集中できます。

実は、初めは基盤と同じ git リポジトリ内にディレクトリを切って案件ごとの UI のコードを入れるという開発体制でした。
各ディレクトリ下で独立に開発を進められるよう配慮はされていたものの、リリースに関しては以下のような問題がありました。

案件担当チームは実装した UI をリリースするのに基盤チームへ依頼する必要がある
基盤チームは案件の進捗に合わせて望まないタイミングでのリリースを強要される
UI 部分の差分だけをリリースすることが難しい

今ではこれらの問題が解決し、リリースサイクルが大幅に改善しました。

それ以外を基盤で共通化する恩恵

最適化アルゴリズムと UI を案件ごとに外付けしつつ

サーバーサイドのロジック全般
インフラ全般
Firestore や Cloud Storage などによるデータの永続化
Auth0 による認証・認可
データアップロードなど一部の共通 UI

など、それ以外の全てを基盤が一手に引き受けています。

【編集部による基礎知識の解説✏️】
Firestore はスキーマレスな NoSQL データベースで、柔軟なデータ構造を持つ業務アプリケーションに適しています。一方、Cloud Storage は大容量のファイル管理に特化したオブジェクトストレージで、CSV や画像、フロントエンドのバンドルなど、あらゆるファイルの格納と配信に利用されます。
Auth0 は、認証・認可の処理を専門に担う外部サービスです。Google や GitHub といった ID プロバイダーとの連携や、ロールベースのアクセス制御も簡単に実装できます。柔軟かつ信頼性の高い認証基盤を、工数をかけずに導入できる利点があります。

こうして共通基盤上で複数の案件をこなすことで案件担当者は UI とアルゴリズムに集中できるため開発が効率化されるのはもちろんのこと、他にも様々なメリットがあります。

たとえば我々は重要な顧客データを取り扱うため、セキュリティ面には十分に注意を払う必要があります。
認証認可にも信頼性が高く柔軟な要望に応えられることを評価して Auth0 を採用しました。
こうした取り組みを個別に担当者に任せるのではなく基盤が受け持つことで、全ての案件に反映させて信頼性を担保できます。

運用面を考えたときに、個別に作ることによる属人化を回避できるのも重要なポイントです。
それに加えて、ALGO ARTIS では一度開発を完了した案件でも作りっぱなしにはせず、基盤のアップデートによって継続的な改善を顧客に届けたいという思いがありました。

まとめ

多様な最適化案件を 1 つの基盤で上手く共通化するというのは非常に難しい取り組みで、私自身も当初は本当にそれが可能なのか正直なところ半信半疑でした。
実際、社内では無理に共通化せず個別に作ることを許容した方が良いのではないかという議論もありました。

しかし、最適化を使ったビジネスをスケールさせるというのは今までも多くの企業が直面していた困難であり、ALGO ARTIS だけでなく業界全体としても大きな意味のあるチャレンジだと思っています。

これが本当に上手いやり方だったのか分かるのは、もっと後になって振り返ったときでしょう。
それでも、少なくとも今 ALGO ARTIS 社内ではこの基盤がないと業務が回らないくらいには欠かせない存在になっています。

執筆者プロフィール

藤原秀平
SNS: https://x.com/shuhei_fujiwara
GitHub: https://github.com/sfujiwara
Google Cloud Platform のトレーナーからデータサイエンティスト、MLOpsエンジニアを経て、現在は数理最適化やそれに付随するソフトウェアエンジニアリングに従事している。Google Developer Expert (Machine Learning)。