計画策定を「最適化」するALGO ARTISの挑戦

株式会社ALGO ARTISの藤原 秀平です。「多様な最適化サービス開発をスケールさせる共通基盤とチーム構成」と題して、プラットフォーム化で何を共通化したのか、それによって開発・運用はどう変わったのかについてお話しします。後半では、プラットフォーム化における苦労と現在抱えている課題を皆さんと共有できればと思っております。

本題に入る前にALGO ARTISについてご紹介させてください。私たちは「ビジョン：社会基盤の最適化」「ミッション：計画の困難を卓越した技術と徹底した誠実さによって解消する」を掲げ、計画の困難を解消することを目指しています。

計画の困難を解消するとはどういうことなのか、電力会社が燃料を船で発電所に運ぶための計画を立てる仕事を例として説明いたします。

一見そんなに大変ではないように思うかもしれませんが、実際は想像以上に大変な仕事です。例えば、発電所では燃料の在庫が一定ラインを下回って停電するといった事態は必ず避けなくてはいけません。しかし、燃料の在庫が多すぎると現場が困ってしまいます。船には使用可能な隻数や石炭在庫量などの制約が多く、燃料には様々な種類がある上に時期によって価格が異なります。

そんな中で、どの燃料をどの船でどの発電所に運ぶのか、計画を立てるのは非常に難しいですよね。そして多くの現場では、業務に詳しいベテランが、Excelとにらめっこしながら長年の経験と勘で計画を立てています。そうなると、属人化してしまいますし、そもそも人間が計画を立てるのには限界があります。我々は、こういった計画を立てる業務をサポートするためのWebアプリケーションを各企業向けにカスタマイズして提供していました。

なお、配船計画を例に挙げましたが、プロセス系や組立系における生産計画、輸送や配送の計画、公共交通機関における運行・保守計画など、クライアントの事業領域は多岐にわたります。

こちらはデモ用の画面（工場の生産計画）です。横軸が工場のラインで、ガントチャートでいつ・何を・どれほど作るのか、を表しています。この画面を人が修正して、計画を立てることができるわけです。最大の特徴は右上の「最適化」ボタンで、これを押すと計画が自動で生成されます。生成された計画をそのまま使うのはもちろん、それをベースに自分たちで調整することも可能です。

受託ビジネスの課題解決を目指し、プラットフォーム化を推進

ここからはプラットフォームの話をします。プラットフォームを開発した理由は、ALGO ARTISとして解決したい課題があったからです。それが何かというと「事業がなかなかスケールしない」というものでした。

当初はクライアントの業務に合わせてカスタマイズするスタイルで、異なる小さいサービスをたくさん作っていました。そのため、案件ごとに人をアサインする必要があり、運用が属人化していました。また、一度開発が終わって運用に入ったシステムは改修するのが難しく、最新の機能を届けられないという課題もありました。

受託に近いビジネスモデルの場合、ある程度は仕方のないことかもしれません。しかし、ALGO ARTISの場合は、事業の範囲は広いものの「計画の最適化」という軸は共通です。それならば、うまく共通化できる部分があるのではないかと考えました。

というわけで、共通化に向けた取り組みを始めることにしたのですが、これがなかなか簡単なことではありませんでした。全てを共通化できるわけではなく、クライアントの業務に合わせた細かい作り込みが必須な部分があるからです。そこで、個別の作り込みが必須の部分と共通化できる部分を切り分けて考えることにしました。

ドメインの共通軸を特定し「個別最適」と「共通基盤」を切り分け

こちらは、最適化アルゴリズムを使ったシステムの典型的なアーキテクチャの1つです。

ユーザーが「最適化ボタン」を押すと、バックエンドへリクエストが送信されます。最適化アルゴリズムは機械学習ほどではないものの重たい処理であるため、バックエンドではなく非同期ジョブとして実行します。

具体的には、Vertex AI上で最適化アルゴリズムが実行されると、結果がCloud Storageへ出力され、Cloud Pub/Sub経由でバックエンド側に通知されます。その後、バックエンドがCloud Storageから結果を取り出し、必要な情報をデータベースに格納することで、ユーザーは最適化された計画を見られるようになる、という仕組みです。

この中で個別の作り込みが必須になるのは、フロントエンドとアルゴリズムの2つ。それ以外の部分は、ある程度共通化できるだろうと考えました。

もう少し詳しく見ていきましょう。フロントエンドとアルゴリズムについて、個別の作り込みが必須になるのは、言われてみれば当たり前の話です。ALGO ARTISのクライアントには、工場の生産計画を立てる人もいれば、船の配船計画を立てる人もいます。その2人が同じ画面でいいわけがありません。アルゴリズムも同様で、工場の生産計画を立てるアルゴリズムと配船計画を立てるアルゴリズムが同じでいいわけがないと。

そこで、これらは個別に作り込むことが必要であり、それが大きな価値につながる部分だと考えました。特にアルゴリズムに関しては、ALGO ARTISは優秀なアルゴリズムエンジニアが多く在籍しておりますので、個別に作り込めるというのは会社としての強みでもあります。

共通化できる部分についても見ていきます。こちらの右下にあるのは、最適化アルゴリズムを使ったシステムの典型的なアーキテクチャの図としてご紹介したものです。この図が描けている時点で、配船のためのシステムであっても、工場の生産計画のためのシステムであっても、クラウドインフラレベルのアーキテクチャであれば共通化できるはずだと考えました。また、幸いなことにバックエンドで要求される機能にも大きな差はなかったため、アルゴリズムとフロントエンド以外の部分は共通化できると判断しました。

共通化するとどのようないいことがあるのかというと、単純に開発工数が削減できます。認証認可やセキュリティに関わる部分も共通化されるとうれしいポイントです。社内全体で水準を合わせる必要がある部分ですし、1箇所に集約されていると、安心してシステムを開発できますよね。また、プラットフォームにすることで、受託に近いビジネスモデルでは難しかった「最新の機能をユーザーに届ける」ことができるようになります。

このような背景があり、フロントエンドとアルゴリズムをカスタマイズできる形にして、残りを共通化するというプラットフォームを開発しました。

非同期ジョブとFrontend Addonによるシステム構成

もう少し踏み込んで、プラットフォームのアーキテクチャについてもお話しします。

アルゴリズムについて、非同期のジョブはコンテナジョブとして実行されており、基本的にはDockerイメージで管理されています。入出力のスキーマが揃っていれば、異なるDocker イメージでも別のアルゴリズムに差し替えられます。

フロントエンドには少し複雑な部分もありますが、プラットフォームが提供する共通のUIと、案件ごとに追加したいUIをそれぞれに管理しています。共通のUIはCloud Runでホスティングするような形で、追加したいUIは必要なものをビルドしてCloud Storageにアップロードしておくと、そこから配信できるようになっています。

とても簡単に説明しましたが、追加したUIから必要なデータにアクセスできるように、細かく作り込んでいます。社内ではFrontend Addonと呼ばれており、開発ツールも用意されていて、なかなかしっかり作り込まれている部分です。

プラットフォーム化によって生まれたチーム構成の変化

フロントエンドとアルゴリズムが差し替え可能なプラットフォームを作ることで、我々の開発体制がどのように変わったのか。

以前は個別のシステムを開発していたため、案件が入ってくるごとに、アルゴリズム、フロントエンド、バックエンド、インフラとそれぞれのエンジニアをアサインしなければなりませんでした。

現在はプラットフォームチームが誕生し、そこにフロントエンド、バックエンド、インフラのエンジニアがアサインされています。新しい案件が来た際には、アルゴリズムエンジニアとフロントエンドエンジニアだけをアサインします。その2人が差し替え分を実装して、デプロイすればクライアントにシステムを届けられるという形です。

図では個別案件チームが1つしかないため、4人から5人に増えて損しているようにも見えますが、実際には個別案件チームがたくさんあります。案件が増えるほどアルゴリズムとフロントエンドのエンジニアを確保しなくてはいけませんが、プラットフォームチームは線形に増やす必要がないため、開発を効率的にスケールさせられる体制を実現できました。

メリットだけではない？プラットフォーム化における苦労話

ここまでのお話しで「何の苦もなくプラットフォームができて、ただ幸せになった」と見えるかもしれませんが、実際には様々な苦労がありました。ここからは、そういった苦労話や現在も抱えている問題について、皆さんと共有できればと思っております。

まず、我々がプラットフォーム開発を通して最初に得た教訓は「プラットフォームを作るならプラットフォームチームが必要」だということです。

「何を当たり前のことを言っているんだ？」と思われるかもしれませんが、実はALGO ARTISにはプラットフォームがあるもののプラットフォームチームがない時期がありました。これの何がまずいのかと言いますと、プラットフォームに責任を持つオーナーが不在だと、プラットフォーム作りが破綻してしまうのです。

ALGO ARTISではプラットフォームチームがない場合、各案件を担当している人がコントリビュートする形となります。各担当者の一番の優先事項は自分の案件の成功であり、機能を加えたいと思うことはあれど、機能を加えるのを止める理由はありません。各担当者がそれぞれに必要な機能を足していくと、プラットフォームが肥大化して、運用が難しくなり、破綻します。

そのため、プラットフォームを必要十分に保つオーナー（プラットフォームチーム）が、各案件の担当者と綱引きをしなくては、プラットフォーム開発は成り立たないわけです。

先ほどもお話しした通り、現在のALGO ARTISにはプラットフォームチームがあり、彼らが図のような役割を担っています。この役割には精神的な負担も付き纏いますが、共通化する以上は必要不可欠な存在です。

プラットフォーム化に踏み切るベストなタイミングはない

もう1つ、プラットフォーム化において重要だと感じたのは、踏み切るタイミングです。これは皆さんも悩みの種なのではないでしょうか。

ALGO ARTISの場合は、できるだけ多くの案件を経験して必要な機能を把握した上でプラットフォームを開発するのが理想でした。しかし、プラットフォームがない状態で、個別に開発されたシステムが増えていくと、運用が破綻してしまう可能性もあります。とはいえ、早ければいいというものではありません。早すぎると必要な機能を読み違える可能性が高まるからです。

では、どのタイミングがいいのか？　これは私個人の意見ではありますが、完璧なタイミングは存在しないのではないかと考えています。どのようなタイミングであっても「早すぎた or 遅すぎた」のどちらかで後悔すると思います。なんなら、両方の意味で後悔することもあるかもしれません。

その上で、ALGO ARTISがプラットフォーム化に踏み切るタイミングは非常に早かったと思います。実際に、個別に開発したものは最初の数件だけで、ほとんどはプラットフォーム上で開発されています。

決断の早さゆえに対応せざるを得なかった設計の変化

ここからは、プラットフォーム化するタイミングが早かったがゆえに起きたことを共有します。

1つ目は、初期設計からの変化です。

先ほど「最適化アルゴリズムは重たい処理であるため、非同期ジョブで回している」とお話ししたと思います。実は、これは“半分本当で半分嘘”です。最適アルゴリズムの処理は時間がかかるケースもありますが、意外と早くできるケースも多くあります。最適化の実行処理が軽い場合はレスポンスを早く回したい、最適化ジョブの一部分を切り出してレスポンスを早くしたいというケースもあります。

そのため、現在はアルゴリズムやアルゴリズムの一部分の処理についてはフロントエンドで実装しています。ただ、フロントエンドと非同期ジョブで同じロジックが動くため、二重管理になるという問題があります。この対応策として、Wasmを使ってクライアントでの評価実行を促進する試みが社内で進められています。

また、よくある話ですが、作った機能が想定とは異なる使われ方をすることもありました。ALGO ARTISでは、データ連携のために非同期ジョブの仕組みを開発しましたが、蓋を開けてみるとメール送信など様々な用途に活用されていました。そのため現在は、任意のバッチ処理を外付けで追加するための機能として定着しています。

このように、想定外のことが発生します。我々は汎用的に設計していたこともあり、後から考えた工夫・拡張で乗り越えられました。しかし「こういったユースケースで使ってほしい」というコンセプト性が足りないとも言えます。反省すべき点をまとめるのが難しいポイントだと感じています。

とはいえ、プラットフォーム化するタイミングがもう少し遅ければ良かったのかというと、そうは思いません。初期の頃に開発した個別案件はプラットフォームに乗っていませんし、そこの運用にはかなり苦労しています。プラットフォームがなければ開発できなかったような案件もたくさんあるため、やはりプラットフォーム化のタイミングに正解はないのだと思います。

余談ですが、プラットフォーム化によりログやデータが集約され、監視の利便性が向上しました。一方で、各案件の担当者にログやデータを共有する際の権限設定では難しい部分もあり、運用が煩雑になっています。

対策として、BigQueryを経由してログを仕分けし、適切に権限を割り振ることで対応しています。まだ課題も多く、プラットフォーム化して良かった部分、悪かった部分の両方を実感しているところです。

個別カスタマイズ（Optium）とSaaS（Planium）の2種類を提供

プラットフォームを作ったことで開発を効率的にスケールさせられる体制を実現できたとお話ししました。しかし、アルゴリズムエンジニアとフロントエンドエンジニアを案件ごとに確保しなくてはいけないという点が、いつかボトルネックになるという課題が残っています。

アルゴリズムエンジニアとフロントエンドエンジニアが何もしなくても案件を回せるようにしたい、それはSaaS化したい、とイコールだと言えます。そこで、ALGO ARTISでは「Planium」というSaaSも開発しています。「個別に作り込む必要があると言っていたじゃん」とツッコまれるかもしれませんが、領域を適切に絞り込めばSaaSにできるものもあるよね、という発想です。

SaaSについてはシリーズ化しようとして考えており、その第一弾が「Planium｜化学」という化学系の生産計画を管理するサービスです。

現在は、UIとアルゴリズムを個別に作り込む「Optium」、SaaSとして同じサービスを複数のクライアントに提供する「Planium」といった2種類のプランをクライアントに合わせて提供しており、どちらもプラットフォーム上で開発しています。

プラットフォーム化で生まれた課題と向き合っていく

最後にまとめます。ここまでお話した通り、我々はプラットフォームを作ることによって、フロントエンドとアルゴリズムを開発すれば案件が完結する体制を整えることができました。それにより、開発・運用の工数を大幅に圧縮することにも成功しました。とはいえ、共通化には難しい面もあり、現在も様々な課題に直面しています。

本日はご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。