【UiPath】インフラ観点から見た Coding Agents の実力

はじめに

先日 UiPath for Coding Agents が 発表されました。Claude Code や Codex といったコーディングエージェントに UiPath Agent Skills をインストールし、対話しながら UiPath プラットフォーム上のアプリケーションを開発できる仕組みです。

本記事では UiPath for Coding Agents の概要を整理した上で、インフラエンジニアである私が実際に手を動かしてアプリを 1 つ作ってみた体験をもとに、良いと感じたところと、現時点での課題 の両面で率直な感想を述べたいと思います。

本記事の内容は 2026年6月11日 時点の開発検証結果です。UiPath CLI / Agent Skills、各コーディングエージェント、Coded Apps / Coded Agents の仕様は今後変わる可能性があります。

Coding Agents で出来ること

UiPath for Coding Agents の第一印象は 「RPA だけを作るためのものではない」 ということです。

UiPath Skills は Claude Code・Codex・Cursor・GitHub Copilot など主要なコーディングエージェントに対応しており、インストールすると UiPath プラットフォームの開発・運用ノウハウがコーディングエージェント側に組み込まれます。対象は従来のRPAに限定されません。

• RPA: 従来のロボットによる業務自動化
• Web アプリケーション: Coded Apps
• エージェント: Coded Agents
• ビジネスワークフロー: Maestro (BPMN ワークフロー / オーケストレーション)

つまり、フロントエンドの Web アプリから、バックエンドの AI エージェント、タスクを自動化する RPA、業務全体を統合するワークフローまで UiPath Automation Cloudという 1 つのプラットフォーム上で扱う ことができます。

この「1つでまとめて扱える」という点が、後述する本記事のポイントになります。

開発の「その先」も考える

新しい開発ツールを評価するとき、どうしても「どれだけ速く・楽に作れるか」に目が行きがちです。しかし実運用を見据えると 作った後の運用・保守管理 こそが重要になります。

ここに UiPath for Coding Agents の大きなメリットがあると私は考えています。UiPath では、Web アプリ、エージェント、RPA、シークレット、ストレージを Automation Cloud 上のサービスである Orchestrator を中心に管理できます。

仮に同じものを AWS や Azure 上で構成しようとすると、機能ごとに別々のサービスを組み合わせることになります。

構成要素	AWS の例	Azure の例	UiPath
Webアプリ	Amplify / App Runner / ECS	App Service / Static Web Apps	Coded Apps
エージェント	Lambda / ECS / Bedrock AgentCore	Azure Functions / AI Foundry	Coded Agents (プロセス)
RPA	該当なし	Power Automate	RPA (プロセス)
業務ワークフロー	Step Functions	Logic Apps	Maestro
シークレット	Secrets Manager	Key Vault	アセット
ストレージ	S3	Azure Blob Storage	ストレージバケット

AWS や Azure では、複数のサービスをそれぞれホストし、個別にデプロイし、サービス間の連携を設計し、運用・保守する必要があります。 当然、それぞれに適切な権限設定も求められます。サービスが増えるほど、連携と管理の手間は積み上がっていきます。

一方 UiPath では、Automation Cloud 上のOrchestratorという単一のサービス内で Coded Apps、Coded Agents、ストレージバケット、アセットをすべて扱うことができます。またMaestroによって設計された業務フローはエージェンティックプロセスとしてOrchestratorにデプロイして実行・管理できます。

実際のデプロイ単位は App と Agent で分かれますが、認証、フォルダー、リソース、CLI 操作を共通のプラットフォームで統合されているため、運用・保守の見通しが良くなります。

UiPath for Coding Agents の本質的な価値は、「速く作れること」だけではありません。UiPathでは同じプラットフォーム上で開発し、デプロイし、保守できるというライフサイクル全体の一貫性こそが、インフラ観点で私が最も評価したいポイントです。

実際に Coding Agents を使ってみる

ここからは実際に開発していきます。題材は、私が実際に社内で開発して運用しているものに近いものです。

今回は Slack の勤怠連絡メッセージをもとに、チームメンバーの休暇予定をカレンダーにマッピングして表示するアプリ を作ってみます。

各チームメンバーは原則として前もってチームのSlackチャンネルで休暇予定を投稿しますが、何週間も前だと見落としやすくなりますし、メッセージフォーマットが統一されていないと一元把握が困難です。従来のSlack投稿の利便性を損なわずにメンバーの休暇予定を可視化するのがこのアプリの目的です。

設計

レイヤー	採用技術
フロントエンド	Coded Apps (TypeScript / React)
バックエンド	Coded Agents (Python)
オブジェクトストレージ	ストレージバケット
シークレット管理	アセット

Slack メッセージから勤怠連絡を取り込んで休暇予定として構造化するのが Coded Agents、休暇予定やチーム定義を保存するのが ストレージバケット、それをカレンダー UI として見せるのが Coded Apps という分担です。Slack APIをコールするためのBot Tokenは アセット から取得します。

連携の流れを図示すると、次のようになります。

今回の構成では Coded Agents と Coded Apps は別パッケージとしてデプロイしますが、同じ Orchestrator のフォルダー、同じ ストレージバケット、単一 CLI (uip) 操作で扱えるため、利用者目線では 1 つのアプリケーション群として管理できます。

環境準備

まずは開発環境を整えます。

Node.js / Python / uv

Coded Apps 側では Node.js、Coded Agents 側では Python と uv を使います。今回の開発では Node.js 20 以降、Python 3.11 以降を前提にしました。

node -v
npm -v
python --version
uv --version

コーディングエージェントのインストール

利用するコーディングエージェントをインストールします。本記事では Claude Code と Codex を例にします。

Claude Code

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# macOS / Linux / WSL
curl -fsSL https://claude.ai/install.sh | bash

インストール後は claude --version で確認できます。Claude Code利用にはClaudeサブスクリプションまたはAmazon Bedrockアクセスキーなどで認証します。詳細は Claude Code のセットアップ手順 を確認してください。

Codex

# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

# macOS / Linux
curl -fsSL https://chatgpt.com/codex/install.sh | sh

インストール後は codex --version で確認できます。Codex利用にはChatGPT アカウントまたは OpenAI API key などで認証します。詳細は Codex Quickstart を確認してください。

UiPath CLI / Agent Skills のインストール

続いて UiPath CLI をインストールし、バージョンを確認します。

npm install -g @uipath/cli
uip --version

最後に、利用するコーディングエージェントへ UiPath Skills をインストールします。--agent で対象のエージェントを指定します。

# Claude Code の場合
uip skills install --agent claude

# Codex の場合
uip skills install --agent codex

uip skills install --help を実行すると、対応しているエージェントや --local オプションの扱いを確認できます。エージェントによってグローバル導入かプロジェクトローカル導入かが変わるため、チーム開発ではここを最初にそろえておくと安心です。

これでコーディングエージェントが UiPath Agent Skillsを理解した状態になります。

開発

コーディングエージェントを起動し、プロンプトで開発を依頼します。ここでは Claude Code を利用します。プロジェクトディレクトリを作成し claude で起動します。

開発のポイントは 最初 Plan モード(Shift+Tab切り替え)で起動し、要件を固めてから開発に入る ことです。いきなり実装させるのではなく、まず設計を詰めてから着手したほうが手戻りを減らすことができます。

モデルや思考深度は、利用するエージェントに応じて調整します。Claude Code では /model や /effort、Codex では /model などで調整できます。

次にアプリケーションの要件をコーディングエージェントに伝えます。今回は次のようなプロンプトで指示しました。

UiPath Skillsを使って次の要件に合うWebアプリを設計してください。

- Slackの特定チャンネルでチームメンバーの勤怠連絡のメッセージをCoded Agentsで
  処理し、構造化してOrchestratorストレージバケットに保存します。タイムゾーンは日本時間、勤怠は全休(full)・午前休(am)・午後休(pm)を区別すること。
- Slack APIのBot TokenをOrchestratorアセットのシークレット値から取得すること。
- Coded Appsでメンバーの全休・午前休・午後休を区別してカレンダー表示します。ボタンクリックでCoded Agentsを実行してデータ更新できるようにすること。
- Coded Appsの表示では事前にAutomation Cloudの認証をすること。
- 複数チームとチャンネルを事前に定義してストレージバケットに保存します。チームごとに表示を切り替えできるようにすること。

要件が曖昧な点は質問してください。

要件はややおおざっぱですが、ひとまずこのまま実行して設計を開始してみます。あいまいな部分についてはコーディングエージェントがいくつか質問を返して要件をすり合わせてくれます。

今回の設計では、Slack 連携で Integration Service を使わず Slack API を直接呼び出すよう指示しています。理由は、過去の Slack メッセージを読むために OAuthスコープとしてconversations.history を使いたいからです。既定の Slack コネクターだけで今回の要件を満たすことが難しかったため、Coded Agents から Slack API を直接呼び出す設計にしました。

しばらくするとコーディングエージェントが設計書を作成します。内容をレビューし気になる点があれば設計段階でフィードバックします。ここを省略すると後々フロントエンドとバックエンド両方の修正が必要となる可能性が高くなるため、しっかりレビューします。

問題なければ Yes, and use auto mode を選択して、実装に進みます。実装中は、依存関係ライブラリーのインストールや CLI 実行で承認を求められることがあります。何を実行しようとしているかを確認し、必要なものだけ承認します。

アプリ初期設定

実装が完了しましたら、生成された README.md や説明文に従ってアプリ設定を行います。

以降で利用するリソース名はコーディングエージェントの実装によって異なる可能性があるため、現在の実装に合わせて適宜読み替えてください。

今回の実装では、主に次のリソースを利用します。リソースの構成や設定方法で不明点があればコーディングエージェントに質問すると良いでしょう。

リソース	用途
SlackBotToken	Slack Bot Token を保存するCredential型アセット
AttendanceBucket	チーム定義と勤怠データを保存する ストレージバケット
config/teams.json	チームと Slack チャンネル ID の定義
data/attendance.<team_key>.json	Coded Agents が生成する勤怠データ

teams.json は、README に記載されたフォーマットに従って作成します。Slack チャンネル ID は Slack のチャンネル詳細画面から取得できます。複数チーム定義できる設計ですが、ここでは1チームの設定に留めます。

{
  "teams": [
    {
      "key": "ts1",
      "name": "テクニカルサービス1部",
      "channels": [ 
        "C0B9BE41DE0"
      ]
    }
  ]
}

ストレージバケットに config\teams.json としてアップロードします。(実装により異なる可能性がありますが、"config"のようなフォルダーパスは手入力します)

外部アプリケーション

Coded Apps から Orchestrator API を呼び出すため、Automation Cloud で外部アプリケーションを作成します。

Automation Cloud > 管理 > 外部アプリケーション > アプリケーションを追加 から、非機密アプリケーションを作成します。スコープ追加では、リソースとして Orchestrator API Access を選択し、今回のアプリに必要なユーザースコープを追加します。

• OR.Buckets.Read
• OR.Execution.Read
• OR.Jobs

Coded Apps はストレージバケット上のファイルを読み取り、Coded Agentsをプロセスとして認識し、ジョブ起動とポーリングを行います。一方、Slack Bot Token の読み取りは Coded Agents 側で行うため、Coded Apps からアセットを直接参照する必要はありません。

ローカル開発用のリダイレクト URL は Vite (Coded Appsが利用しているビルドツール) の既定に合わせて http://localhost:5173 を指定します。Coded Apps をデプロイした後は、本番 URL もリダイレクト URL に追加します。

取得したアプリIDと設定したスコープは、Coded Apps の uipath.json と .env に設定します。

Slack アプリ作成

Slack アプリ管理画面 から Create New App を選択し、新しいアプリを作成します。ここでは例として uipath-calendar-app という名前にします。

OAuth & Permissions で、利用するチャンネル種別に応じた scope を追加します。パブリックチャンネル、プライベートチャンネル、DM、グループDM を広く扱えるようにする場合は、次の scope を設定します。

• channels:history
• channels:read
• groups:history
• groups:read
• im:history
• im:read
• mpim:history
• mpim:read
• users:read
• users:read.email

Install App からワークスペースへSlackアプリをインストールします。管理者の承認が必要になることもあります。発行された Bot User OAuth Token (xoxb-...) は Orchestrator の SlackBotToken Credential 型アセット に保存します。

最後に対象の Slack チャンネルで次のスラッシュコマンドを実行して、アプリをチャンネルへ招待します。

/invite @uipath-calendar-app

デプロイ

開発した Coded Agents と Coded Apps を Automation Cloud にデプロイします。まずは別ターミナルを開いて UiPath CLI でログインします。

# 組織・テナントを指定してログイン
uip login --organization <org_name> -t <tenant_name>

組織やテナントを覚えていない場合は、対話的に選択することもできます。

# ブラウザ認証後、テナントを対話的に選択
uip login --it

今回の構成では、Coded Agents と Coded Apps をぞれぞれデプロイする必要があります。自分で CLI を実行することもできますが、コーディングエージェントに「まとめてデプロイして」と指示するのが簡単です。デプロイ先のOrchestratorフォルダーを必要に応じて指定します。Sharedフォルダーまたはそのサブフォルダーを指定するのが簡単です。

Coded Agents 側は、おおむね次の流れです。CLIはコーディングエージェントが実行するため人間による手動実行は原則不要です。

cd AttendanceAgent
uv sync
uip codedagent setup --force
uip codedagent init
uip codedagent deploy --folder "Attendance"

Coded Apps 側は、おおむね次の流れです。こちらも人間による手動実行は原則不要です。

cd attendance-app
npm install
npm run build
uip codedapp pack dist -n attendance-app --version 1.0.0
uip codedapp publish
uip codedapp deploy -n attendance-app --folder-key <folder-key>

デプロイ中にエラーが発生した場合は、エラー内容をそのままコーディングエージェントに渡して修正を依頼できます。完全に自動で解決できるとは限りませんが、ログの読み取り、設定ファイルの修正、再実行まで任せられる場面は多いです。

テスト

デプロイが完了しましたら Coded Apps の URL が発行されますのでコピーします。

このURLを先ほど作成した外部アプリケーションのリダイレクトURLに追加します。コーディングエージェントが自動的に追加していることもありますが念のため確認します。

次にブラウザーで Coded Apps の URL を開いて動作を確認します。事前に Automation Cloud の認証を挟む設計にしているため、最初に認証画面が表示されますのでログインを実行し、カレンダーが表示されることを確認します。もしエラーが出てしまう場合には、エラーメッセージをコーディングエージェントに伝えて修正を依頼します。

URLにアクセスしても何も表示されないときは Orchestrator > (デプロイ先フォルダー) > オートメーション > アプリに Coded Appsがデプロイされていることを確認します。今後再デプロイした時のバージョンアップ・ロールバックもこの画面から行うことができます。

Coded Apps画面上のデータ更新ボタンをクリックしてCoded Agentsを実行し、カレンダーにチームメンバーの勤怠情報が表示されることを確認します。

Coded Agentsの実行結果はOrchestrator > (デプロイ先フォルダー) > オートメーション > ジョブから確認します。TraceによってLLMがSlackメッセージをどのように構造化データに変換しているか見ることができます。

細かい部分まで全体をテストすると次の点が気になりました。

• 「本日お休み」の投稿で日付を誤って判断していた。エージェント実行日ではなく、Slack 投稿日時を基準にすべきだった。
• カレンダー上で「本日」が分かりづらかった。
• 週末をまたぐ休暇で土日にも勤怠情報が表示された。営業日のみに絞った方が見やすい。
• Coded Agentsが古い言語モデル (gpt-4o-2024-11-20) を使っていた。
• 説明文が多く、UI の表示領域を圧迫していた。

機能改善

一通り動かしたところで、追加で手を入れたくなる点が次々と出てきます。コーディングエージェントの真価は、このような 反復的な改善 で発揮されます。

既存のコードベースを理解したうえで差分を当ててくれるため、初回開発よりもむしろ改善フェーズのほうが快適なケースもあります。

私が実際に依頼した改善点は次の通りです。

- 「本日お休み」の場合の日付が正しくありません。Slack投稿日時を元にして。
- UiPathChatの言語モデルを環境変数で指定できるようにし、既定値はgpt-4.1-mini-2025-04-14にして。
- カレンダーで土日の枠を残した状態で勤怠情報は非表示にして。
- 「Slackの勤怠連絡を構造化して表示します（全休 / 午前休 / 午後休）。」と「対象チャンネル: *」のテキストは不要です。
- カレンダーで本日が目立つように枠で囲って。色は #FA4616 にして。
- 矢印キー←・→で先月・来月を切り替え、Tキーで今月にジャンプできるようにして。
- 勤怠情報を一から再取得できるように、リセットする機能を追加して。

この結果、Coded Agents 側では LLM_MODEL 環境変数でSlack勤怠メッセージの構造化に利用するLLMを指定できるようになりました。Coded Apps 側では、「本日」の強調、週末などのUI改善、キーボード操作、リセット機能などを追加しました。

改善版のUIはこのようになりました。

良かった点・課題・所要時間

今回の開発体験を通じて個人的に感じた良かった点と課題についてまとめてみました。

良かった点

フロントエンド (Coded Apps) とバックエンド (Coded Agents) を同じプロジェクト内で作成できたため、ストレージバケット・アセットや Orchestrator フォルダーを介した連携を一貫して設計できました。

仕様変更を伝える際にも 「これはフロントエンド？バックエンド？それとも両方？」と細かく切り分けなくても コーディングエージェント側が既存コードを読んで、必要な場所に修正を入れてくれました。もちろんテストは必要ですが、実装の分担を人間が毎回細かく指示しなくてよいのは大きな利点です。

また UiPath Agent Skills があることで、Coded Agents / Coded Apps / Orchestrator リソースの前提知識を毎回プロンプトで説明する必要がなくなります。これは地味ですが、実際に使うと痒い所に手が届く感じがします。

現時点での課題

今回の開発時点では Coded Apps の公開範囲や認証まわりは自分で意識して実装する必要がありました 。プライベートアプリとして Automation Cloud 認証を前段で必須にできる選択肢が標準で用意されると、業務アプリとしては安全性が高まると感じます。

もう一点 Coded Apps のアクセスログなど監視・監査寄りの機能も自前実装が必要 でした。Orchestrator 側から一般的な Web アプリのアクセスログをそのまま見る機能は現状ないため、必要であれば「アクセスログをストレージバケットに日次で保存して」といった要件を追加して、監視まわりの機能をアプリ側に実装する必要があります。

このあたりは今後製品側の成熟やテナント設定によって状況が変わる可能性があります。少なくとも本格運用前には、認証テストと監視のしやすさを自分のテナントで確認しておくべきだと感じました。

開発にかかった時間概算

今回の開発では、それぞれの作業で次の時間を要しました。

作業	所要時間
プラン作成	5 分
初期実装	50 分
アプリ設定 & デプロイ	15 分
テスト 1 回目	15 分
仕様変更実装 & 再デプロイ	30 分
テスト 2 回目	5 分

合計すると約2時間です。もちろん実装前のアイデア出しは別途時間が必要ですし、初期実装後も仕様変更とテストを何回繰り返すかによって所要時間は大きく変わります。あくまで今回の題材での目安として捉えていただければと思います。

おわりに

本記事では、UiPath for Coding Agents を使って Slack 勤怠連絡カレンダーアプリを実際に開発し、デプロイ、テスト、改善まで一通り体験してみました。

触ってみて改めて感じたのは、UiPath for Coding Agents の強みは「速く作れること」そのものよりも「作ったその先」にあるということです。

Web アプリ・エージェント・RPA・ワークフローを同じプラットフォームの考え方で扱い、Automation Cloud / Orchestrator のリソースと組み合わせて運用できる、このライフサイクル全体の一貫性は、複数のクラウドサービスをつなぎ合わせる構成にはない明確なメリットでした。

一方で、認証や監視など非機能要件寄りの機能は、今回の開発では自前実装が必要でした。これらが標準機能としてより自然に使えるようになれば、業務アプリとしての運用はさらに楽になり、安全性も向上するはずです。

とはいえ、コーディングエージェントと UiPath プラットフォームの組み合わせは、まだ登場したばかりです。今後の進化に期待しつつ、まずは皆さんも一度、手元で試してみてはいかがでしょうか？

最後までお読みいただき、ありがとうございました！