エージェント型 AI のスケーリング: UiPath が AI Hypercomputer 上に高性能 GPU プラットフォームを構築した方法
Abhijeet Rajwade
Senior Customer Engineer, AI Infrastructure
Jason Morrison
Principal for AI Partnerships, UiPath
※この投稿は米国時間 2026 年 8 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
エンタープライズ向けのエージェント型自動化とビジネス オーケストレーションの市場リーダーである UiPath は、業界のエージェント型 AI への移行を先導しています。これにより、同社は自律型エージェントをデプロイして、さまざまなシステムにわたって積極的に推論、意思決定を行い、複雑なビジネス プロセスを実行しています。
単純なタスクの自動化から認知的意思決定エージェントへの移行には、膨大なコンピューティング能力とともに、世界最大規模の企業のニーズに十分な信頼性を備えた強力なインフラストラクチャが必要です。
数百もの GPU を完璧にオーケストレートできることが、単なる研究実験の実施と、グローバルな AI プラットフォームとの構築の違いを生み出します。このようなオーケストレーションを実現するには、費用の急増やレイテンシの急上昇を発生させることなく、大規模なトレーニング ジョブとリアルタイム推論のバランスを取る必要があります。


そのために、UiPath は UiPath IXP を使用した大規模なインテリジェント ドキュメント処理(IDP)をサポートするようインフラストラクチャを再設計し、分離されたクラスタから、共有の Google Cloud GPU フリートへと移行しました。トレーニングには A3 VM インスタンス(NVIDIA H100 GPU)を、推論には G4 VM インスタンス(NVIDIA RTX Pro 6000)を使用してバランスを取っています。このアーキテクチャにより、UiPath は「急激に変動するワークロード」の問題を解決できました。また、予測可能な費用とオープンソース パターンを頼りに、同社のエンジニアリング チームがこのアーキテクチャを自ら複製できるようになりました。
「エンタープライズ向けエージェント型 AI の可能性を最大限に引き出すには、当社の高い目標にふさわしいインフラストラクチャが必要です。Google Cloud は、特殊なモデルをトレーニングしてグローバルにデプロイするために必要な規模と柔軟性を提供してくれます。このパートナーシップにより、高精度のインテリジェントなドキュメント処理と、単にチャットするだけでなく、お客様のビジネス成果を積極的に推進する自律型エージェントを提供できます。」– UiPath、最高技術責任者、Raghu Malpani 氏
背景: 高度な計算
UiPath は、フルスタックの自動化プラットフォームを長年にわたって Google Cloud 上で運用してきましたが、エージェント型 AI の取り組みが拡大するにつれて、インフラストラクチャに関する一連の新たな課題に直面しました。
IDP、コンピュータ ビジョン、LLM を活用した推論などのコア機能には、高度な計算が必要となります。そのため、UiPath のエンジニアリング チームは、ロボットが人間のような明瞭さでインターフェースを「認識」できる LLAMA モデルのグラウンディングを活用しています。また、Qwen アーキテクチャを基盤とする特殊なドキュメント モデルにより、煩雑な実世界の書類から価値あるデータを抽出できます。
これらのモデルは UiPath のクラウド インフラストラクチャ上に存在し、可能な限りレイテンシを短縮することが不可欠です。「優れたデモ」から、費用を急増させることなく信頼性の高い本番環境ツールに移行するには、基盤となるシリコンを再考する必要がありました。
課題: 供給を上回る需要
UiPath のチームが新しいモデルのトレーニングや推論を行う必要があるとき、これまではオンデマンドで GPU ノードをプロビジョニングし、ワークロードの急増または減少に応じてスケールアップまたはスケールダウンしていました。
クラウドの容量が安価で豊富にあり、完全に弾力的であった時代には、これは機能的な戦略でした。しかし、AI への意欲が高まるにつれ、UiPath はこのアプローチでは運用の複雑さに対応できなくなっていることに気づきました。このとき、次の 3 つの新たな課題に直面していました。
-
急激に変動するワークロード: ピーク時の需要に対応できる十分な能力を確保するために、多くの場合、追加の容量を購入せざるを得ませんでした。この容量は、需要が少ない時期にはアイドル状態になり、高価なヘッドルームを無駄にしていました。同社は、計算処理を行っていないシリコンに料金を支払う必要のない、インテリジェントなオンデマンド スケーリングを必要としていました。
-
供給のボトルネック: 大規模なファインチューニングにおいては、8 クラスタの H100 を搭載したゴールド スタンダードのハイエンド A3 VM インスタンスの費用対効果は圧倒的です。しかし、これらのチップは世界的に需要が供給を上回っており、ノードを追加するだけで UiPath が望むスピードでトレーニングの取り組みをスケールすることはほぼ不可能になっています。
-
運用上のオーバーヘッド: UiPath は、地理的な非効率性にも悩まされていました。安定した推論の需要があるということは、複数のリージョンで専用クラスタを維持することで、世界中の顧客向けに低レイテンシを確保する必要があることを意味していました。さらに、トレーニングと推論の両方のために GPU インフラストラクチャを管理することで、運用オーバーヘッドの非効率的なレイヤが追加されました。
解決策: 共有 GPU フリート
こうしたことを踏まえ、UiPath は GPU をプロダクト中心の弾力的なインフラストラクチャではなく、共有の戦略的リソースとして扱うことにしました。
その結果、エンジニアリング チームは、自社の ML サービス(MLS)プラットフォームが管理するプラットフォーム レベルの共有 GPU フリートを設計しました。このフリートは、ワークフロー間で需要のバランスを取りながら、チームと時間枠をまたいで作業を優先順位付けします。日中は、リアルタイム推論や、レイテンシの影響を受けやすいワークロードを処理し、夜間やオフピーク時には、バッチ トレーニングや長時間実行ジョブに自動的に切り替わります。
MLS は、フリートレベルでワークロードを調整することで、インスタンスごとの弾力性に依存することなく、競合を減らしながら使用率を最大化します。また、事前に容量をスケジュールできるため、研究と本番環境の両方のユースケースで予測可能性が向上します。
Google Cloud を選ぶ理由: AI Hypercomputer アーキテクチャ
UiPath は、拡大する規模に対応するために、Google Cloud AI Hypercomputer を活用しました。これは、パフォーマンスが最適化されたハードウェア、オープン ソフトウェア、柔軟な使用量モデルを統合環境に組み込んだシステムレベルのアプローチを提供するものです。AI Hypercomputer は、ハードウェア レイヤとソフトウェア レイヤの間の摩擦も最小限に抑えるため、エンジニアリング チームはインフラストラクチャの管理ではなく、モデルのパフォーマンスに集中できます。


共有フリートモデルの採用を決めた UiPath には、GPU の確実な可用性、競争力のある価格、バースト容量を提供できるクラウド パートナーが必要になりました。そこで、同社は既存の Google Cloud フットプリントを拡大し、高度に特化した AI スタックを Google Kubernetes Engine で実行することにしました。
現在、UiPath は Google Cloud の Dynamic Workload Scheduler(DWS)を活用して、予測可能な容量を利用することで、供給のボトルネックを解消しています。同社は、Google Cloud なら数日単位の通知期間で GPU 容量を確実に確保できることを知っていました。エンジニアリング チームは DWS を使用して、トレーニングの実行を事前にスケジュールして、短時間のバーストのための容量を確保できます。また、不足が発生してから対応するのではなく、容量を計画できるようになりました。UiPath は現在、すべてのトレーニングと、ほとんどの IDP モデル推論ワークロードを Google Cloud で実行しています。
UiPath は、負荷の高いトレーニングとファインチューニングに A3 VM インスタンスを使用していますが、すべてのタスクにそのレベルの能力が必要なわけではありません。そのため、現在は、推論ワークロードの最適化を新たに実現するために、Google Cloud G4 VM インスタンスをデプロイしています。これらのインスタンスは、パフォーマンスと価格のバランスが良く、費用対効果に優れており、UiPath はトレーニング用に予約された高パフォーマンスのクラスタを占有することなく、より軽量な推論タスクを実行できます。
「Google Cloud の共有フリートに移行したことで、運用モデルが変わりました。事後対応型のプロビジョニングから予測可能な高パフォーマンスのエンジンへと移行し、最先端の IDP とエージェント型 AI ワークロードを支えられるようになりました。Dynamic Workload Scheduler などのツールと、A3 インスタンスと G4 インスタンスの組み合わせにより、費用と速度の両方を最適化できる柔軟性が得られました。これにより、エンジニアはコンピューティングを待つのではなく、イノベーションに時間をかけることができます。」- UiPath、AI インフラストラクチャ担当ディレクター、Arthur Wilcke 氏
実用的な検証: 大規模な差別化モデル
Google Cloud GPU に安定してアクセスできるようになったことで、UiPath は高度なモデルを本番環境に導入できるようになりました。また、本番環境の推論を妨げることなく大規模なトレーニング ジョブをスケジュールできるため、研究実験と本番環境の信頼性のバランスを取ることができます。
これにより、UiPath は、構造化されていないさまざまなドキュメントからデータを高精度で抽出する高度な IDP 機能を実現できます。例:
-
Omega Healthcare は、UiPath を使用して 1 億件を超えるトランザクションを 99.5% の精度で自動化し、処理時間を 40% 短縮、反復タスクを月あたり 15,000 時間削減しました。
-
Thermo Fisher Scientific は UiPath を使用して請求書や注文書などの PDF からデータを抽出しています。現在では請求書の 53% を人手を介さずに処理できるようになり、処理時間を 70% 短縮しています。
参考ポイント
UiPath のこれまでの最大の成果は、可用性と信頼性の向上です。ワークロードの移行は今も継続しており、以前の GPU リソースの廃止に伴い、さらなる費用削減が見込まれます。
同様のプラットフォームの構築を検討しているエンジニアリング チームにとって、重要なポイントは次のとおりです。
-
容量の切り離し: ハードウェアを特定のプロダクトに結び付けるのではなく、リソースをプールして使用量の急増を平準化します。
-
事後対応よりもスケジュール設定: DWS などのツールを使用してコンピューティングを事前に予約することで、可用性が保証され、費用が安定します。
-
シリコンのサイズ適正化: トレーニングには A3 VM インスタンスを使用し、推論には G4 VM インスタンスなどの効率的なオプションを選択します。
次のステップ
UiPath は、最近のインフラストラクチャの進化後も、AI イノベーションの次の進化をサポートするために、MLS プラットフォームの改良を続けています。この成功を皆様の組織でも再現するために、以下のリソースをご活用ください。
-
構築: GitHub でエンジニアリング パターンを確認する。
-
最適化: Google Cloud G4 VM インスタンスを使い始める。
-
UiPath - IXP の詳細を確認する。
- AI インフラストラクチャ担当シニア カスタマー エンジニア、Abhijeet Rajwade
- UiPath、AI パートナーシップ担当プリンシパル、Jason Morrison 氏



