【UiPath】RelayによるAutomation Cloud とオンプレミスの橋渡し

Last updated at 2026-05-22Posted at 2026-05-22

はじめに

本記事では2026年5月12日にリリースされました UiPath Relay のメリットと導入手順、および活用例を紹介します。

RelayはUiPathが提供するSaaS型オートメーションプラットフォームである Automation Cloudとオンプレミスの社内サーバーを容易に橋渡しするためのコンポーネント であり、WindowsまたはLinuxマシンにインストールすることができます。

従来の接続方式と課題

これまでもAutomation Cloudとオンプレミスサーバーの連携はVPN接続やインバウンドアクセス許可によって実現できましたが、導入難易度の高さやセキュリティ懸念によって利用に踏み切れないケースがありました。

VPN接続

概要: オンプレミス側にVPN Gatewayを配置し、Automation Cloud側でVPN設定を行うことによって連携ができます。
課題点: そもそもオンプレミス側VPN Gatewayが設置されていないケースや、設置されていてもIT部門への利用申請のハードルが高いために連携が難しいというケースがあります。

インバウンドアクセス許可

概要: オンプレミス側のDMZセグメントにリバースプロキシを置き、インターネットからのインバウンドアクセスを許可することによって連携ができます。DMZのファイアウォール設定によって Automation Cloudからの送信IP範囲のみを許可するようにフィルター設定することが推奨されます。
課題点: インバウンドアクセス自体がセキュリティポリシー上許容されないケースや、Automation Cloudの送信IP範囲の変更によってフィルターの再設定が必要になるケースがあります。

Relayの利点

Relayは上記課題を解決すべくリリースされたコンポーネントです。Automation Cloud のサービスがVPN や受信ファイアウォールポートの開放なしに、社内ネットワーク内の HTTP / HTTPS エンドポイントへ安全に到達できるようにするブリッジ機能を提供します。

トンネル接続は常にオンプレミスからAutomation Cloudへのアウトバウンド接続で開始します。オンプレミスのネットワーク境界にインバウンドの穴あけは必要ありません。

主要な用語

用語	意味
Relay Group	テナントレベルの論理コンテナで、1 つ以上の Relay Client と、その Client が公開するオンプレミスのエンドポイントを含む
Relay Client	オンプレミスのマシンにインストールする軽量バイナリ(Windows / Linux)でAutomation Cloud へ TLS トンネルを張る役割
オンプレミスエンドポイント	FQDN (または IP) ＋ポートで識別される、社内の HTTP/HTTPS サービスの接続先 (例: `http://ollama.lab.test:11434`)
Relay URL	登録した各エンドポイントに対して UiPath が発行するプライベートなプロキシアドレス。Automation Cloud 側のサービスは、実際のエンドポイントではなくこの Relay URL を指定

現時点の制限

サポートされるのは HTTP ベースの接続のみ (TCP 汎用トンネル用途ではありません。)
Database Hub からの直接利用は現時点で未サポート
Relay Client のサポート OS は Windows / Linux

3方式の比較

ここまで紹介した VPN接続 / インバウンドアクセス許可 / Relay の 3 方式を、導入・運用観点で比較すると次のようになります。

評価軸	VPN接続	インバウンドアクセス許可	UiPath Relay
接続方向	双方向	Automation Cloud → オンプレミス (Inbound)	オンプレミス → Automation Cloud (Outbound)
ファイアウォールへのインバウンド穴あけ	必要 (UDP 500/4500)	必要 (TCP 443 など)	不要 (Outbound 443 のみ)
必要なオンプレ機器	VPN Gateway	DMZ + Reverse Proxy	Relay Client (Windows / Linux 1台以上)
Outbound IP 変更への追従	不要	必要 (ACL 再設定)	不要
セキュリティ部門との合意形成	難 (申請ハードル高)	難 (Inbound 拒否ポリシーに抵触)	易 (Outbound のみで完結)
プロトコル制約	任意のTCP接続	HTTP/HTTPS が中心	HTTP/HTTPS のみ
導入難易度	高	中〜高	低
想定ユースケース	既に Site-to-Site VPN が敷設済みで再利用したい場合	DMZ 運用が確立しており Inbound 接続がポリシー上 OK な場合	社内 HTTP API / LLM を最短で安全にクラウド連携したい場合

本記事でのRelay構成

本記事で構築するRelay構成によって次の接続フローが確立されます。

前提条件

Automation Cloud のテナント管理者権限を保持していること
社内ネットワークに接続先サーバーとしてOllamaをホストするマシンが構築され、FQDN (例: ollama.lab.test) が名前解決できること
Relay Clientとして、同じネットワークセグメントから社内サーバーのエンドポイント (例: http://ollama.lab.test:11434) に到達できる Windows または Linux ホストを準備できること (接続先サーバーと共存可能)
Relay Clientはアウトバウンド接続にて https://cloud.uipath.com と https://{region}-relay.uipath.com に到達できること (詳細はネットワーク要件を参照)

接続先サーバー(Ollama)の準備

ここではオンプレミスの接続先サーバーとしてOllamaを準備する手順について説明します。すでに接続先のWebサーバーなどが準備されている場合にはこのセクションは飛ばしてください。

ローカルLLMをホストするため GPU有りのUbuntu 24.04サーバー にOllamaをインストールします。詳細な手順は次の記事もご覧ください。ここでは要点のみを説明します。

Ubuntu 初期更新と前提パッケージ

Ubuntu にログインし、次のコマンドを順次実行します。

sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y install build-essential curl wget gnupg lsb-release ubuntu-drivers-common zstd unzip

NVIDIA ドライバのインストール

# 推奨ドライバを確認
ubuntu-drivers devices

# 推奨ドライバを一括インストール
sudo ubuntu-drivers install

再ログインして動作確認

nvidia-smi

Ollamaインストール

curl -fsSL https://ollama.com/install.sh | sh

サービス状態を確認します。

systemctl status ollama --no-pager

active (running) になっていれば OKです。

GPUでのローカルLLM動作確認

ここでは Gemma4 をインストールしますが、他のモデルでも代替可能です。

ollama pull gemma4:latest
ollama run gemma4:latest "hello"

別ターミナルを開き nvidia-smi を実行します。ollama プロセスが GPU メモリを使っていれば、Memory-Usageが増加するはずです。

CPU フォールバックになっている場合はNVIDIAのドライバインストールを再度確認し、journalctl -u ollama -e でログを確認してください。

外部アクセス許可

既定値では Ollama はループバック (127.0.0.1:11434) でのみリッスンします。Relay Client を別マシンに配置する場合、Ollama に外部 NIC へのバインドを許可する必要があります。

Ollama がホストされている Ubuntu サーバーに UiPath Relay Client を共存させる場合は、ループバック経由で接続できるため本節の設定は不要です。

systemd の drop-in 設定で OLLAMA_HOST 環境変数を上書きします。

sudo systemctl edit ollama

エディタが開くので、次の内容を追加して保存します。

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

設定を反映してサービスを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl status ollama --no-pager

リッスンポートが *:11434 に変わっていることを確認します。

ss -tlnp | grep 11434

ファイアウォール (ufw) を有効化している場合は、Relay Client を配置するセグメントからのアクセスを許可します。

# 例: 社内セグメント 10.1.0.0/24 からのみ許可
sudo ufw allow from 10.1.0.0/24 to any port 11434 proto tcp

動作確認

Relay Client をインストールするマシンから、ollama.lab.test (FQDNは環境に応じて変更) に対して HTTP API をコールして動作確認を行います。

curl http://ollama.lab.test:11434/api/tags

モデル一覧が取得できればOKです。

Relay セットアップ

Step1. Relay Group 作成

Automation Cloud にサインインして管理に遷移してテナントを選択し、Relay タイルを開きます。

画面右上の Relayを追加 をクリックします。

Relay Group 名と、公開するオンプレミスのエンドポイント (今回は Ollama) を登録します。

名前: Ollama
エンドポイント URL: http://ollama.lab.test:11434
整合性チェックのパス: /api/tags

保存 → 確認ページで 構成を生成 をクリックします。

ここで、後の Step 2 で Relay Client に渡す Relayの構成 (設定値) が生成されます。コピーしてメモしてください。

Step2. Relay Client インストール

オンプレミス側のホスト (Windows または Linux) に、UiPath から提供される Relay Client バイナリを配置します。

Windows / Linux でインストール手順は共通して次の3点です。

バイナリを入手して配置する
Step1 で生成した設定値を渡して起動する
サービスとして常駐していることを確認する

起動すると、Relay Client が Automation Cloud 側へ アウトバウンドのTLSトンネル を張ります。受信ポートを開ける必要はありません。

Windows

Windows に Relay Client をインストールするには、クイックスタートから relay-windows-amd64.zip をダウンロードしてzipを解凍します。

relay.exe を任意のディレクトリ(例: C:\UiPathRelay)に配置し、管理者権限のコマンドプロンプトで次のコマンドを実行します。

relay.exe start --accept-license-agreement --config {Step1で生成された設定値}

インストールが成功すると、自動的に Relay-{GUID} という名前で Windows サービスが生成されます。

services.msc にて Windows サービスが正常に生成され、実行中であることを確認します。

その他、詳細な設定・運用手順はこちらをご覧ください。

Linux

Linux ホスト (本記事では Ollama と同じ Ubuntu 24.04 サーバーに同居させる想定) に Relay Client を導入します。

クイックスタートから relay-linux-amd64.zip のリンクをコピーします。

LinuxマシンにてRelay Clientをダウンロードします。

wget https://download.uipath.com/relay/26.4.0/relay_linux_amd64.zip # コピーしたリンクに置き換え

zip解凍して実行権限を付与します。

unzip relay_linux_amd64.zip
chmod +x relay

Relay Clientをインストールします。

sudo ./relay start --accept-license-agreement --config {Step1で生成された設定値}

インストールが成功すると、自動的に relay-{GUID} という名前で systemdサービスが生成されます。

その他、詳細な設定・運用手順はこちらをご覧ください。

Step3. Relay URLを確認する

Automation CloudにてRelay Group の詳細画面に戻り、各Relayノード (Relay Client) がアクティブになり、登録したエンドポイントで View URL をクリックします。

Relay URLが作成されていることを確認します。

Step4. Integration ServiceでPrivate接続作成

Automation Cloud にてコネクションを作成します。

Orchestrator > Shared など任意フォルダー > コネクション > コネクションを追加 をクリックします。
接続先として OpenAI V1準拠のLLM を選択します。
コネクションを次のように設定し、接続をクリックします。Private を選択することで、Integration Service が Relay 経由でオンプレミスのエンドポイントにルーティングします。
- Connection Type: Private
- Base URL: http://ollama.lab.test:11434/v1
- URL: http://ollama.lab.test:11434
- APIキー: 任意の文字列を指定 (Ollamaは認証不要ですが、コネクター設定上必須フィールドのためダミーの文字列を入力します)

ステータスが接続済みとなることを確認します。

これで Integration Service のコネクターが「Automation Cloud → Relay → オンプレ Ollama」の経路で確立されました。

Relayを利用したワークフロー/Agent開発

ワークフローから呼び出し

Studio WebにてRPAワークフローまたはAPIワークフローを作成し、チャット補完を生成 (OpenAI V1 Compliant LLM) アクティビティにて Step 4で作成したコネクターを選択します。
モデルにて gemma4:latest が選択できることを確認します。
プロンプトにて 自己紹介をして などと入力してデバッグ実行し、応答が返ってくることを確認します。

AgentからのLLM呼び出し

Agent対応モデルの準備

Agent BuilderからLLMを呼び出しをするには、外部ツール (Function Calling) に対応したLLMを選択する必要があります。筆者が試した限りでは GLM-4系のツール呼び出し対応モデルである glm-4.7-flash:latest で動作させることができましたのでその手順を説明します。なお Gemma4 / Qwen3.5 等のモデルではOllamaのFunction Calling実装との互換性の問題により正常に動作しないケースがありました。

Ollamaホストにて ollama run glm-4.7-flash:latest を実行します。GPU 16GBでギリギリ動作しましたので、不要なLLMがあればあらかじめ削除(例: ollama rm gemma4:latest)しておきます。

BYOM設定

Automation Cloudにて独自モデル (BYOM: Bring Your Own Model) を利用するためのLLM設定を行います。LLM設定には次のライセンスが必要となります。最新の情報はこちらをご覧ください。

ユニファイドプライシング: Enterprise Platform、Standard Platform、Basic Platform、App Test Platform Enterprise、App Test Platform Standard。
フレックス: Advanced Platform、Flex Standard Platform。

Automation Cloud > 管理 > AI Trust Layer > LLMの設定 > 設定を追加 をクリックします。

製品: Agents、機能: 設計、評価、デプロイ を選択し、LLM名にて カスタムエイリアスを追加 をクリックします。glm-4.7-flash と指定して追加をクリックします。

APIの種類: OpenAI Chat Completions、コネクタ: OpenAI V1 準拠のLLM、コネクション: {Step4で作成したもの}、LLMの識別子: glm-4.7-flash:latestを選択し テストの設定 をクリックします。

OllamaがLLMをロードするまで時間がかかる可能性があります。画面がフリーズする場合には、しばらく時間をおいてから再試行します。

テストに成功しましたらポップアップの完了をクリックし、保存をクリックして設定を保存します。

Agent BuilderでのBYOM利用

Studio Webにてエージェントのプロジェクトを新規作成します。モデルの設定にて glm-4.7-flash を選択できることを確認します。

デバッグ実行してエージェントから応答が返ってくることを確認します。

トラブルシューティング

Relayが正常に動作しない場合には、まずAutomation Cloud > 管理 > (テナント) > Relay > (Relay Group) でRelayノードとエンドポイントの状態を確認します。
Relayノードにてサービスの状態を確認します。
- Windows: services.mscにて Relay-{GUID} が開始中であることを確認
- Linux: systemctl list-units --type=service --all | grep relay コマンドにて relay-{GUID}.service がactiveであることを確認
Relayノードにてデバッグログを確認します。
- Windows: C:\ProgramData\UiPathRelay\logs\{GUID}\relay.log
- Linux: /var/log/uipath-relay/logs/{GUID}/relay.log

よくあるエラーと対処

症状	原因	対処
Relay Client が接続できない (タイムアウト)	アウトバウンド HTTPS (443) がプロキシやファイアウォールでブロックされている	`https://cloud.uipath.com` および `https://{region}-relay.uipath.com` へのアウトバウンド 443 を許可する
エンドポイントの整合性チェックが失敗する	Relay Client からオンプレミスサーバーへの名前解決ができていない	Relay Client 上で `nslookup ollama.lab.test` や `curl http://ollama.lab.test:11434/api/tags` を実行し、DNS解決とネットワーク到達性を確認する
Integration Service のコネクション作成時に TLS エラーが発生する	オンプレミス側エンドポイントが自己署名証明書を使用している	エンドポイント URL を `http://` (非TLS) で登録するか、Relay Client のホストに CA 証明書をインストールする

その他のトラブルシューティング事例はこちらをご覧ください。

おわりに

本記事ではAutomation Cloudとオンプレミスのサーバーを安全かつ容易に接続するためのUiPath Relayについて説明しました。是非皆さまの環境でもお試しいただけますと幸いです！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up