京セラの協働ロボットAI、顧客ごとにデータを分ける3年がかりのクラウド基盤づくり

出発点にあったのは、生産年齢人口の減少にともなう生産現場の人手不足です。人と同じスペースで作業できる協働ロボットをAIで知能化し、段取り替えが頻繁に発生する多品種少量生産の工程でも使えるようにする、というのが事業の狙いでした。ただし現場でAIモデルを安定して動かすには、照明の変動といった環境の揺らぎに追従し続ける必要があり、そのためにロボットから送られてくる現場データには顧客の機密が含まれます。

編集部の見立てでは、この事業の難所はロボットを賢くする技術そのものではなく、顧客の秘密を預かりながらモデルを学習させ続ける「器」をどう設計するかにありました。学習を回すほど複数の顧客の機密データがクラウド側に集まり、一度の事故で及ぶ範囲も広がっていきます。しかも開発チームにとってGoogle Cloudでの構築はほぼ初めてで、AWS側でも複数アカウントを統合管理する知見が求められる状態でした。技術的な課題と、サービスとして売るための信頼設計とが地続きになっていた点が、この事例の起点だと考えられます。

クラウドを一つに統一せず、機能ごとに得意な方を割り当てた設計が、この開発の土台になっています。データ管理やロボットへの指示は、マネージドサービスが豊富で開発を速く進められるAWS、機械学習はGPUを有効に使えるGoogle Cloudという分担です。後者では、GPUを常時抱え込むと高コストになるという事情から、必要な量だけ計算資源を増減させるオートスケールを、コンテナをまとめて動かすGoogle Kubernetes Engine（GKE）で組んでいます。基盤を一つに寄せたほうが管理は楽になるのが通例ですが、GPUをどれだけ無駄なく回せるかがサブスクリプション型サービスの原価に直結する以上、運用の手間を引き受けてでも分ける判断には筋が通っています。

顧客ごとにAWSアカウントを分け、データを論理的に切り離す方式も、信頼を先に設計した選択でした。まとめて管理する仕組みには既製のAWS Control Towerという選択肢もありましたが、技術選定当時の自分たちには過剰で柔軟性に欠けると判断し、AWS Organizationsで組み立てる道を選んでいます。ベストプラクティスを参照しつつ管理用アカウントの構成を自社のドメインに合わせて設計した点、そして顧客が増えるほどクラスタの費用が膨らむと分かった段階で、2023年にクラスタを顧客アカウントの外へ出し、Assume Roleで各アカウントのサービスやデータへ接続するマルチテナント構成へ切り替えた点。ここには、初期設計を守り抜くより運用の現実に合わせて作り替えるという判断が表れています。

学習データを作る側まで手を入れたことも見落とせません。3D CADデータからさまざまな条件で画像を自動生成する合成画像生成ツールは、もともとオンプレミスで動く一体型のアプリケーションでしたが、役割ごとに分割してコンテナ化し、GKE上で動くよう作り直されました。ほぼ作り直しに近く開発に9カ月を要した回り道ですが、モデルの頑健さはデータオーグメンテーション（学習用データの水増し・拡張）の量と質に左右されるため、推論側ではなく供給側を強くする発想は理にかなっています。

プロジェクトは2020年10月に始まり、2023年11月のサービスリリースに至りました。2024年1月時点で京セラ社内での利用が始まっており、外部企業からもいくつかの引き合いが寄せられています。途中で実施した管理画面のマルチテナント化は、既存アプリケーションに大きな影響を与えることなく2カ月で切り替えが完了しました。合成画像生成ツールのクラウド化では、多くのAIエンジニアが同時並行で利用できるようになり、データ生成時間も短縮されています。WebアプリでのFirebase活用による開発工数の大幅短縮と運用負荷の軽減も、あわせて生まれた効果です。