多様な最適化サービス開発をスケールさせる 共通基盤とチーム構成 アーキテクチャカンファレンス 2025 藤原 秀平 

藤原 秀平 ● ソフトウェアエンジニア（プラットフォームチーム） ● ALGO ARTIS ⼊社以前は機械学習屋 ○ データサイエンティスト‧MLOps エンジニア ● 学⽣時代は数理最適化が専⾨ ● Google Developer Expert (Machine Learning, Google Cloud) ⾃⼰紹介 

● 会社紹介 ● ALGO ARTIS のプラットフォーム ○ Platform によって何を共通化したか ○ Platform によって開発‧運⽤はどう変わったか ● プラットフォーム開発の難しいところ ⽬次 

会社概要 

株式会社 ALGO ARTIS 

計画策定における課題 計画を⽴てるのは⾮常に複雑なパズルを解くようなもの 多⼤な時間がかかるうえ、⼤量の制約条件を考慮しつつ効率の良い計画を⽴てるのは困難 海外から国内の発電所に向けて ⽯炭を船で運ぶ計画を⽴てる ⽬的 制約条件 (⼀例) 船着き場の数 ⽯炭購⼊⽇契約 ⽯炭在庫量 船の隻数 評価指標 (⼀例) 船の積載量 運賃‧滞船料 ⽯炭価格 航路距離 極めて複雑な組合せ最適化問題 

ALGO ARTIS の事業領域 配船計画 輸送/配送計画 プロセス系 ⽣産計画 資源/燃料貯蔵計画 組⽴系 ⽣産計画 運⾏/保守計画 サプライチェーンのさまざまな計画業務が対象 

ALGO ARTIS が提供するサービスの例（⼯場の⽣産計画） 計画を⾃動⽣成する最適化機能 ⼈⼿で計画を修正しやすい Web UI 

事例 現場で便利に活⽤され続けることにこだわったものづくり 

ALGO ARTIS のプラットフォーム 

受託に近いビジネスモデルでは異なる⼩さなサービスをたくさん作ることになるので ● サイロ化して開発がスケールしない ○ 運⽤も属⼈化する ● そもそも⼗分な数の案件（テナント）に対応するだけの開発者を揃えることが困難 ○ 採⽤が追いつかない ● 運⽤開始後のサービスに継続的な改善を届けることが難しい ○ 作りっぱなしになりがち 事業をスケールさせることの難しさ 

⼀定は仕⽅がないのでは…？ ● 完全に異なるサービスを複数作るのであればおそらくそう ● ALGO ARTIS の事業の範囲は広いが、計画の最適化という軸は共通 → 共通化できる部分があるはず 事業をスケールさせることの難しさ 

とは⾔ったものの、簡単ではない ● 最適な計画を作るサービスといっても分野は様々 ○ 資材を運ぶための配船計画 ○ ⼯場の⽣産計画 ● それぞれ顧客の業務に合わせた細かい作り込みが必須 ○ 最適化システムは開発をスケールさせるのが難しいと⾔われる所以 それでもチャレンジするという決断をした結果のプラットフォーム 事業をスケールさせることの難しさ 

データ永続化 最適化システムの典型的な構成 顧客に合わせた作り込みが重要になるのはどこか？ Frontend Cloud Run Backend Cloud Run Algorithm Vertex AI Cloud Pub/Sub Database Cloud Firestore Cloud Storage ● 個社別の作り込みが必須になるのはアルゴリズムとフロントエンド ● 共通化が⾒込めそうなのはそれ以外 ○ バックエンド‧インフラ‧認証認可‧etc... 

アルゴリズム ● 領域が違えば作りたい計画も 最適化アルゴリズムも全く異なる フロントエンド ● アルゴリズムと同様の理由 ● 計画を⾃動で作ることとと同じくらい ⼿動で作りやすいことも重要 個別の作り込みの重要性 

図が書けている時点で、ある程度は最適化システムの型というものが存在している ● どの案件でもクラウドインフラのレベルでのアーキテクチャは⼤差ない ○ バックエンドに要求される機能も同様 ● 認証‧認可やセキュリティ⾯の対応を集約できる恩恵は⼤きい ○ 社内全体で⽔準を合わせなければならないポイント 共通化の恩恵 データ永続化 Frontend Cloud Run Backend Cloud Run Algorithm Vertex AI Cloud Pub/Sub Database Cloud Firestore Cloud Storage ● プラットフォームのアップデートを 各テナントに継続的に届けられる ● 監視‧運⽤を集約できる 

アーキテクチャ Frontend Cloud Run Backend Cloud Run Algorithm Vertex AI Cloud Pub/Sub Database Cloud Firestore Algorithm Image Container Registry Input / Output Cloud Storage Frontend Code Cloud Storage ● アルゴリズムは Docker イメージ単位で差し替え ● ⼊出⼒のスキーマが揃っていれば何でも OK Auth0 ● テナントごとの UI を Cloud Storage 経由で配信 ● データアクセスの I/F とローカル開発ツールも提供 ● 社内では Frontend Addon と呼ばれる機能 

個別案件の開発がアルゴリズムエンジニアと フロントエンドエンジニアで完結する体制へ ● 個別案件 ○ アルゴリズムエンジニア: 1~2 ⼈ ○ フロントエンドエンジニア: 1~2 ⼈ ● プラットフォーム ○ 現在は 6 ⼈ + 業務委託メンバー プラットフォームを活⽤するチーム構成 個別案件 アルゴリズム フロントエンド バックエンド プラットフォームチーム インフラ 個別案件チーム アルゴリズム フロントエンド フロントエンド バックエンド インフラ 案件が増えるほど効率が良くなっていく構成に！ 

プラットフォームの開発の難しいところ 

プラットフォームを作るならプラットフォームチームが必要 ● 何を当たり前のことを…？ ● なぜ必要なのか、どのタイミングで必要なのか⾔語化できますか？ 実は ALGO ARTIS にはプラットフォームはあるけどチームは無い時期が存在していた プラットフォームチームができるまで 

正確にはプラットフォームそのものに責任を持つオーナーがいないと破綻します ● 機能を追加する⼈はいるが、追加しない意思決定をする⼈が不在になる ● 案件を成功させたい担当者とプラットフォームを必要⼗分に保ちたいオーナーで 適切に綱引きをしないといけない ○ ここ意思決定が⾟いのはプラットフォーム永遠の悩み チームがないとプラットフォーム作りは破綻します Platform 案件 A に必要な機能を ⾜します 案件 B に必要な機能を ⾜します いいよ ダメです 

案件をこなして知⾒を得ないと適切なプラットフォームの設計は難しいが… ● プラットフォームなしで個別に作るほどサイロ化は進む ○ 後でプラットフォームに載せ替えよう、というのはかなり⼤変 ○ プラットフォーム化が早すぎると必要な機能を読み違える おそらく完璧なタイミングというのは存在しない（と思う） ● どのタイミングでも「早すぎた」か「遅すぎた」のどちらかで後悔する ● その⼆択で⾔うなら ALGO ARTIS は「早すぎた」寄り ○ 初期の数案件を除いてほとんどがプラットフォーム上で提供している プラットフォーム化に踏み切るタイミング 

当初の想定 ● 計画の最適化‧評価は時間がかかるケースもあるので⾮同期ジョブが適切 ● クライアント側で重い処理をやらせるべきではない ● UI 実装とアルゴリズム実装を極⼒疎結合に 初期設計から変化したこと Backend Cloud Run Algorithm Vertex AI Cloud Pub/Sub 計画の最適化‧評価を実⾏すると ⾮同期のジョブが発⾏される 評価はレスポンスが命なのでクライアントで実⾏したい ● 最近のアルゴリズムエンジニアは TypeScript 書けちゃうのでフロントで実装 ● Wasm によるクライアントでの評価実⾏を促進 最適化‧評価の実⾏環境は適切に選択できるのが理想 

External Service 当初の想定 ● 外部とのデータ連携をコンテナジョブに切り離す ● 社内で Connect Addon と呼ばれる機能 初期設計から変化したこと Backend Cloud Run Cloud Pub/Sub Connect Addon Cloud Run Jobs Email Input / Output Cloud Storage 実際の使われ⽅ ● 任意の処理をコンテナジョブに切り離す ● プラットフォームのコア部分を変えずに機能追加 ○ 実装を各案件に委ねやすい ○ 後戻りしやすい機能追加の仕組みを実現 Scheduled Trigger Cloud Scheduler External System 

必要な機能が固まり切ってない中で案件とプラットフォーム開発を並⾏するのは無茶も伴う ● 後から考えた⼯夫‧拡張で乗り越える場⾯も多い ○ 汎⽤的に設計しているので対応⼒があるとも捉えられる ○ 「こう使って欲しい」という強いコンセプト性が⾜りないとも捉えられる プラットフォーム化をもう少し待てば楽をできたか？ ● そういうわけではない ● 今でもシングルテナントの管理‧運⽤は⼤変 ○ 機能追加も個別にやっている プラットフォーム化のタイミングを振り返って 

ログやデータが⼀箇所に集約されて管理しやすいように思える？ ● 複数テナントのログが混在するので権限管理が煩雑になる ● 特に ALGO ARTIS は担当案件以外の情報が⾒えてはいけないので⾮常に気を遣う ログ‧データの管理の課題 Log Collection Cloud Logging Log Streaming Cloud Pub/Sub Database Cloud Firestore On-Call Datadog Dashboard Looker Studio Tenant 1 Raw Logs BigQuery Table Backend Cloud Run Tenant 2 Tenant 3 Frontend Cloud Run Logs (Tenant1) BigQuery View Logs (Tenant2) BigQuery View Logs (Tenant3) BigQuery View 

多様な領域をまとめて扱う以上ここは避けられない ● 領域を絞れば SaaS 化できそうなものはある → 化学⽣産の領域では SaaS として Planium を提供 ● UI を統⼀してアルゴリズムは簡易的なもので共通化 結局アルゴリズムと UI 開発がボトルネックになるのでは 

Optium, Planium の 2 種類のプランを顧客に合わせて提供 ● Optium: UI とアルゴリズムを個別に作り込む従来の形 ● Planium: SaaS として同じサービスを複数顧客に提供 いずれもプラットフォーム上で開発 Optium, Planium Platform Tenant (Optium) Planium Tenant Tenant (Optium) Tenant (Optium) Tenant Tenant 

まとめ 

● プラットフォームによってフロントとアルゴリズムの開発で案件が完結する体制を整えた ○ 開発‧運⽤の⼯数を⼤幅に圧縮 ● フロントエンドとアルゴリズムの開発で案件をこなせるように ○ それに合わせたチーム構成‧アサイン ● 共通化の難しさには今も向き合い続けている ● 質問‧議論歓迎です ○ ぜひブースまで来てください！！ まとめ 

質問‧議論など歓迎です。 ぜひブースまでお越しください！ ブース番号は ブースの宣伝 12 

No content