【株式会社両備システムズ様】クラウドコスト半減、ML基盤構築で開発加速 。スリーシェイクSreake事業部が事業成長を技術で支える。 | 活用事例

今回支援いただいたのは「Financial AlgoTech」という資産運用サービスです。投資信託に近く、投資家様からお預かりした資金を運用して収益を還元する、ヘッジファンドを組成しようとしている段階です。

対象資産はFXで、トレードに対する処理をシステム・AIベースで実行しています。外国為替の取引をAIを用いて全自動で行い、人間の手を使わずにリアルタイムで取引を行うシステムと、裏で自分たちがAIモデルを開発するために用いる開発基盤、データ連携基盤で構成されています。
岡山と東京でエンジニアが6名いまして、AI開発、取引システムの開発、サービス提供（SRE）に従事しています。

サービス開始へ向けて、自己資金による実運用を通じて着実なトラックレコードを構築しております。投資家の皆様にとって魅力的な商品となるよう、モデルの開発と継続的な改良に取り組んでおります。

このサービスは両備システムズにとって新規企画の位置付けで、2021年からこの事業を研究開発的に立ち上げて、現在は取り組みを始めて5年目というステータスです。

> ※ヘッジファンドの設立・投資家の募集は、両備システムズの子会社「株式会社Ryobi AlgoTech Capital」で実施します。2025年現在、組織の機能を段階的に同社へ移管中です。

他のサービスとの大きな違いは、顧客が直接利用するという形ではなく、システム管理・運用管理が中心という点です。トランザクションはほぼなく、為替の市場が開いている月曜日6時から土曜日6時が基本です。週末は止められるので、その間でデプロイなどの対応を行います。

ただし、信頼性、可用性は非常に意識しています。バックエンドだけで構築されているシステムで、扱うデータが相当な頻度で蓄積していきます。1日でレコード250万件のデータが蓄積されていき、AIの推論には最大10年分のデータを使います。処理データが膨大になり、このデータを同じ形式で扱わないといけない、かつリアルタイムでも処理する必要があるという特徴があります。

研究開発段階だったことから、人数が少ない体制で進めていました。研究開発に並行してシステムの稼働もトライアルで始めていたため、保守作業が研究開発を圧迫していました。解決に向けて動いていましたが、トイルが多く、本来集中すべき開発業務に支障が出ていました。
技術的な課題としては、集まったメンバーがAPエンジニアが中心で、研究開発が得意な人間は多かったのですが、インフラ・運用に対する知見が不足している面がありました。その結果、技術的な負債が蓄積していました。

安田から先の課題に対して対応いただけそうな会社としてスリーシェイクさんを紹介されました。GoogleのAIサミットでちょうどスリーシェイクさんの講演を聴いていて、企業としての認知はありました。また、Developers Summitでスリーシェイクの方と会話する機会があり、課題感をご相談したり、コーポレートベンチャーキャピタルのファンドを通じてJAFCO経由でも紹介を受け、Webミーティングをさせていただいたりしました。

他社との比較検討を経て選定したわけではありませんが、スリーシェイクさんの特徴的な強みに惹かれました。
当時、私たちはAWSを主に利用しながらもGoogle Cloudの活用も視野に入れており、特定のクラウドベンダーに依存せず、両プラットフォームに精通した知見を持つスリーシェイクさんの技術力に魅力を感じました。また、既存の6名のチームと密に連携しながら、寄り添った形で支援していただける伴走型のアプローチにも大きな期待を寄せていました。

元々、当社のサービスはAWSを中心に利用していたため、新規サービスでもAWSを利用することを選択しています。ただし、昨年からGoogle Cloudのサービスにも興味を持ち、Gemini、Looker Studio、BigQueryなどのサービスを利用し始めています。
メインの環境はAWSを利用しつつ、BI環境はGoogle Cloudを利用している状況です。

最初は対象サービスの環境を確認させていただいた上で、課題の抽出とヒアリングから始めました。インフラの最適化やモダナイゼーションを目的にプロジェクトに参画しましたが、支援の中でオフィス移転の話や、AWSアカウントを移行する話が上がったため、その辺りをプライオリティを上げて対応することになりました。

アカウント移行では、分社化に伴い、AWSアカウントを委譲する必要があったのですが、同対応に併せて、環境別にアカウントを分割し、ガバナンスを効かせるなどの基盤としての下地整備を対応として行っています。また、昨年末からはML基盤整備の話が上がってきたため、開発者体験の向上を目的とした基盤整備をご支援しています。

インフラのIaC化を進めた点ですね。後は先ほどお話したアカウント管理の最適化です。1つのAWSアカウントでStagingやProdなど複数の環境を作成している状況があったため、環境ごとにアカウントを分けることで管理しやすくするのと、監査観点から、ガバナンスを効かせられる基盤整備をまず初めの段階で取り組んでいきました。

クライアントワークでは、お客様が何をしている会社なのかを理解することが重要だと思っています。支援する我々としても、しっかりお客様の業界のドメイン知識を補強しながらご支援する必要があると考えていました。
また、エンジニアが開発業務に集中しやすい環境の整備や、環境整備に係るスキル移転、内製化を参画当初から意識していました。

実際に一緒に手を動かしながら知識移転を行っていくことを意識しました。
AWSの設定を行う時には、両備システムズのインフラ担当の方と一緒に、画面共有をしながらペアプロのような形で作業したりしていましたね。

情報整理には気をつけていました。金融のドメイン知識に対して理解を深めるための用語や言葉の整理に加え、利用する技術の利用目的等をきちんと言語化することで、お互いに認識齟齬が生じないようにしようと配慮していましたね。

両備システムズ様が抱えている課題に対して、同じくらいの深さで理解することが重要と考えていましたので、ヒアリングや場合によっては直接相対しながら対応にあたりました。

もともとご提示いただいた課題点を勘案しつつ、目指すべき形を一緒に模索したり、情報のキャッチアップを進める中で、都度、優先度を協議しながら課題の解消に動いていきました。

運用改善の面では、先程お話をしたAWSアカウントの分離に併せて、IaC化、Control Towerの導入を進めました。また、セキュリティ対策として、Security Hub、GuardDutyを導入し、脆弱性の検出体制を整えました。AWS Budgetsによるコスト管理も導入しています。

あとは、データストアの変更ですね。データ量が膨大なシステムでしたので、RDS（PostgreSQL）のコストが非常に高くなっていました。時系列データが膨れ上がっていく状況に対して、ユースケースをヒアリングしながら、S3の利用を提案しました。オブジェクトストレージをデータストアとして使うと何が起こるのか、システムとして要件を満たせるのかなど、ディスカッションを重ね、最終的にS3に置き換える方向で現在対応を進めています。

技術選定の面で、SageMakerの選定に向けたプロセスは特徴的でしたね。技術選定の際はできる限り広域に、フラットに比較することを意識していました。

以前から使っていたからAWSを選定という形ではなく、AWS（SageMaker）・Google Cloud（VertexAI）・OSS（MLFlow）といった選択肢の中で、今回のユースケースでは現状構成との相性の問題でGoogle Cloudは選択肢から外れましたが、MLFlowについては最後まで色々と検討していました。
SageMaker でのフルマネージド型 MLFlowは多少利用に不便な面もあり、それならば自分たちでホスティングした方が良いのではないか、などギリギリまで検討・協議を行いました。
選定の中ではMLFlowのコミュニティに適宜、質問しながら、最終的にはフルマネージド型 MLFlowの方が運用の負荷も少ないだろうということで、SageMakerを選定しています。マネージドサービスを用いることでバージョンアップ等のインフラ管理が不要となる点がコストメリットがあると考えています。

また、運用や移行性も考えて、MLモデルのサービングにはSageMaker Endpointを使っていません。AI周りは今後の移り変わりも激しいので、ベンダーロックインにならないように、ECSで移行性を確保している状況です。

コンテナ化は当初からの話としてあったので意識していましたね。SageMakerは必要以上にコストが高くなりがちなんですよね。コストやスペックの面も考慮して、最初から全てをSageMakerありきで考えるのではなく、他選択肢も検討した結果として、最終的にはECSになりました。コンテナ化してしまえば、テンプレート化して使いまわせるという利便性もあるので、将来的な部分で移植性なども意識して技術選定できていたのかなと思いますね。

支援期間の序盤でオフィス移転が必要となり、このオフィス移転に伴う一連の対応に苦慮しました。Direct Connectの利用が前提だった環境の中で、オフィスとして独立し、ネットワーク自体も社内から分離する必要がありました。当たり前に使えていたものがなくなるとどうなってしまうのか、という状況からの議論でした。

ベストプラクティスを提案してもらいつつ、折衷案を議論して、Direct Connectをやめる判断をしました。結果として大正解でしたね。2〜3ヶ月でオフィス移転も対応できました。

Direct Connectは利用料金が高く、また、敷設までのリードタイムが長い面もあり、VPNに切り替え、セキュリティグループによるIP制限を講じることで、コストを抑えながら、セキュリティ面を担保する形が実現できたと思います。

ベストプラクティスを加味しながらも、現場の状況も汲んだ提案をしてくれた部分ですね。現実的に無理のないやり方を提案してもらえました。
また、ベンダロックインをしたくないという我々のチームが大切にしている柔軟性にも配慮いただき、スリーシェイクさんの中で議論している場面でも、同じように考えてくれていたのが非常に頼もしく感じていました。

MLOpsに関しては、どこまで対応するか、どういった姿を目指すかと言う期待値のすり合わせが難しかった部分です。
どこをゴールにするかという定義がない中で、まずは想定されるゴールのレベル分けを行い、現状に対して、実現したいゴールがどこに当たるのか？の擦り合わせを行いました。
元々こちらがイメージしていたレベル感だけでは加味できていないニーズがあったりもしましたので、言葉の定義から含めて議論を重ねることで、最終的な方向性を定めることができたと考えています。

具体的には、今回SageMakerを利用してMLOpsを実現していますが、比較的実装難易度が高く、どのようにすれば、利用負荷を下げられるか？という点について議論をさせていただきました。
シンプルさを求めれば求めるほど制約が厳しくなってしまい、どうしてもその制約下では将来発生しうる要件への対応が難しくなってしまう。そのため、難しい手段を取らざるを得なかったところがあります。
モデルサービングにECSを選択したのは上記のような背景からですね。ただ、手段としては多少複雑になるものの、ドキュメント化を行ったり、可能な限りテンプレート化することで、導入後の利用負荷を可能な限り下げられるように努めました。

両備システムズさん側で接してくれている人たち皆さんの考え方が似ていて、そこに助けられた部分はありました。ディスカッションの時間を多く取っていただき、不明点を根気強くご説明いただけたため、実現したいことをイメージしやすかった面があるかと思います。オフィスに伺った際も、2日間集中した時間をいただくなど、とにかくコミュニケーションを多くとっていただきました。

すごくスピーディに各種資料を共有いただけた点は助かりました。AWSアカウントの移行にあたり、パラメータシートなどの既存資料をスピーディに共有いただけたのはもちろんのこと、適宜、必要に応じて、新たな資料を用意していただいたのは、認知負荷の軽減に繋がり、非常に助かった部分です。

ご依頼してから、一週間程度かかるだろうと思っていた資料も次の日に提供いただけたりと、本当に驚きのスピード感で、待ち時間なく作業を進捗させることができました。また、こちらからお願いしていなくても、テキストだけではなくイメージを作成していただき、ドメイン特性的に理解していくのが難しい領域だったので、そういったご配慮は我々の理解を進める上でとても助かりました。

後は内製化の文脈ですね。ディスカッションやペアプロなど、一緒に作業する時間を取っていただき、また、委託先という垣根なくコミュニケーションが取れたおかげで、内製化、知識移管を進めることができました。

組織的にもスピーディに物事を進めていく文化や、お互いに意見を交換しやすい文化が醸成されていると感じています。私はこのプロジェクトに後から参画したのですが、不明点を遠慮することなく質問できる、話を聞いていただける環境がありました。
また、逆に両備システムズ様側からも、不明点はその場で質問していただけたので、スピーディに情報共有や、意思決定ができたと思っています。

これは、EMという立場で副次的に助かった面ですが、開発メンバーとの1on1で話をする中で、メンバーがスリーシェイクさんから、ドメイン知識についてヒアリングを受け、説明を行うプロセス自体が彼らにとって勉強になったという意見をもらいました。スリーシェイクの皆さんがドメイン知識を吸収されるプロセスを目の当たりにしたり、質問され、回答を行うことで、メンバーたちも知識を整理できるという効果がありました。

これからもう少し定量的に見えてくる部分もありますが、アーキテクチャの見直しによって、モデル開発をより効率的に行える状況が作れてくると思います。データへのアクセス性が向上したことによって、非エンジニアメンバーへのデータ活用を促せる状況も整いました。
また、クラウドのランニングコストが全体の50-60%削減する見込みであるというのは非常に大きな効果でした。さらに以前から考えると、もっと削減効果があったと思いますね。

開発者体験の面で、CI/CDが整備され、デプロイがスムーズになりました。セキュリティ・監視の見直しも進み、運用面で安心して作業できるようになって、開発者が開発作業に集中できる状況が実現できています。

伴走支援に関しては、オフィス移転の時には、こちらがあまりインフラ作業をせずに、スリーシェイクさん側にほとんどの作業を実施いただく状況でしたが、最近の作業では両備システムズのメンバーが大部分の作業を実施することができてきており、今回のプロジェクトを通じて、内製化の進展も感じられています。

スリーシェイクさんのスピード感を見たことで、そのスピード感を目標として、組織内でスピード感を求める文化が醸成されたというのがありますね。オフィス移転のタイミングくらいで入った新しいメンバーも、スリーシェイクさんのメンバーとペア作業などを実施して、メキメキと力をつけていたように見えます。

私自身が当時、技術的に明るい領域ではなかったML、AWSアカウント管理の分野で、勉強させてもらえたというのは1エンジニアとしてやりがいがありましたね。一緒に作っていく体験ができたのは初めてでしたし、伴走している感じがありました。

支援領域が広く、伴走型支援でこちらも成長を感じることができました。相互に成長できたという実感があるのがやりがいとして感じる部分ですね。

技術要素としては、IaCを自分たち自身で取り組めないといけないと思っています。生成AIはコード開発と相性がいいため、生成AIの活用も検討しています。AI開発の取り組みにより、開発者体験の向上を図っていきたいと考えています。

企画、構想段階から入っていただき、技術選定の部分等で豊富な知見とノウハウを提供していただけました。内製で開発を進めていく中で陥りがちな視野の狭さを、外部からの新しい視点で補完いただけたことは、技術的な部分だけではなく、今後の組織の成長にも繋げていけると思っています。

メンバーも成長してきていますし、今回のスリーシェイクさんの参画によって安田自身がEMとして成長しているというのも見てとれています。マネジメントの意思決定というのは難しい部分もありますが、今では自分の意思と責任の元で、物事を進められるようになっていると思います。対外的に技術者として折衝するレベルについても、スリーシェイクさんのレベル感になってほしいとメンバーに伝えていて、技術的な面でも良い影響を与えていただいていると感じています。

内製の良い部分と悪い部分というのはあると思っていて、内製という形を続けながらも、今回のように外からの知見や良い影響を継続的に取り入れて活かしていけるような関係性をスリーシェイクさんと築いていけたらなと思います。

今は、サービスのローンチに向けて進んでいく中で、今見えている領域の構築や、自走できる状況はかなり整いました。ただし、技術の革新・発展も早く、我々だけでカバーできる範囲も全てではないので、継続的にご支援いただけると良いなと思っています。

両備システムズとしては、ステークホルダの皆さんと、相互的に高めあっていける持続性のある関係性を目指していますが、スリーシェイクさんには一番それを体現していただいているパートナーだと思っています。

両備システムズ様が、自走できる状況をさらに強化していきたいと考えています。Terraform でリソースを管理できる環境を用意したので、スリーシェイクさん のご支援が終わっても運用が自走できるような環境をさらに充実させていきたいなと思います。

技術的なスキル移転は一定程度進みましたが、今後はより高度な判断や、新しい技術の評価・導入についても内製化できるようなご支援をしていきたいです。

ML分野は特に進歩が早いので、継続的な情報提供や、新しい手法の検証支援なども重要になってくると思います。実験管理や特徴量管理などMLOpsの導入を通して、再現性の向上、開発効率の向上、データに基づく意思決定の迅速化が実現できるように考えていきたいと思います。

両備システムズさんが常に最適な技術選択ができるよう、今後もパートナーとして伴走していきたいです。