UiPath DevCon India 2026 に参加してきたのでレポを書いていきます。今回は「Coding Agent for Managing Automation Deployments」編です。
テーマはズバリ、自動化を作ったあとの世界に Coding Agent をどう活かすか、です。コードを書くだけが Coding Agent の仕事じゃないぞ、という話。
目次
- 運用フェーズは永遠に続く問題
- 新しい統合 CLI が爆誕！！
- Skills：Coding Agent への道案内
- 認証・監査、人間と同じ仕組みで担保
- dev → staging、1 プロンプトでいけるんですか！？
- 「成功」に見えたジョブが実は失敗していた件！！
- 要点まとめ
- おわりに
運用フェーズは永遠に続く問題
まず、自動化のライフサイクル全体を示すスライドから入りました。
計画・構築・テスト・デプロイ・運用という流れのうち、これまで Coding Agent が注目されてきたのは「構築」フェーズでした。でも構築フェーズって、終わりがあるじゃないですか。一方、運用フェーズは自動化が生きている限りずっと続きますし、対象の数も増え続けます。
「構築にかかる時間は短く有限です。一方、運用中に得られる改善効果は時間とともに積み重なっていきます。」
この非対称性こそが今回のキモです。Coding Agent が運用・管理領域でも活躍できれば、その恩恵は構築フェーズよりもはるかに大きくなる——というわけです。
Coding Agentで想定される活用シナリオは大きく3分類に分かれます。
デプロイ領域
- ソリューションのデプロイとユーザーへのアクセス付与
- プロセスパッケージの新バージョンへのアップグレード
- パッケージのロールバック
運用領域
- 障害の分析とサービス復旧
- リソースのプロビジョニング確認
- トリガー状態や実行状況のチェック
管理・ガバナンス領域
- ユーザーの Organization へのオンボーディング
- 特定フォルダや自動化へのアクセス権付与
- ライセンス割り当て
どれも「わかるわかる、これ毎回手作業でやってた」ってやつばっかりです。
新しい統合 CLI が爆誕！！
これらをぜんぶカバーするために UiPath が作ったのが、新しい統合 CLI です。
従来もコマンドラインツールは存在していたんですが、各ツールがバラバラでドキュメントも不十分という状況でした。新しい CLI はその課題をまるっと解消しています。
- 統一されたコマンド呼び出し方式:一貫した構文で全操作が可能
- 整備されたドキュメント:製品内ドキュメントにも対応
- カバー範囲が広い:構築・テスト・デプロイ・運用(ジョブ監視・フォルダ管理・マシン管理・ランタイム・リソース・実行管理)まで一気通貫
そして、この CLI は npm で公開されました。 「数日前にリリースされた」と発表した瞬間、会場がざわっとしましたね。
「もし私が皆さんの立場なら、すぐにダウンロードして試してみるでしょう。」
自分もさっそく試してみるつもりです。
Skills:Coding Agent への道案内
CLI がいくら整備されていても、Coding Agent が「どのコマンドをどの順番で呼べばいいか」を知らなければ意味ないですよね。そこで UiPath が用意したのが skills の仕組みです。
Skills とは、主要なシナリオ(デプロイ・ロールバック・ユーザー管理など)に対応した一連のインストラクションセットです。CLI をインストールする際、合わせてインストールするオプションが提示されます。インストールされた skills は、Coding Agent が作業を開始するときに「Loading skills...」として読み込まれ、今のタスクに必要な知識が自動的に供給される仕組みです。
デモ中に、公開リポジトリを画面で確認しながら説明してくれたんですが、メインの skill が他の sub-skill を参照するネスト構造になっていて、各アクションに必要な情報だけが都度ロードされるためコンテキストが肥大化しない設計になっています。これはイカつい設計ですね。
認証・監査、人間と同じ仕組みで担保
強力なツールが公開されたとき「エージェントが勝手に何かしてしまわないか」って心配になるじゃないですか。この点を明確に説明してくれています。
認証の共有:CLI(および Coding Agent 経由の操作)は、人間がプラットフォームで操作するときと同じ認証方式を使用します。別枠の特権アクセスは存在しません。
監査ログへの記録:すべての操作が監査ログに残ります。何が起きたか、そのとき誰がコントロールしていたかを常に確認できます。
OS 権限の尊重:デモ中、Robot のインストール時に Windows UAC のダイアログが表示されました。スピーカーはこれを意図的に見せていました。
「エージェントが私の許可を求めています。これを省略するように設定することもできます。しかし設定しなければ、エージェントは自然に許可を求めてきます。オペレーティングシステムの同じガバナンスと権限システムが適用されます。」
エージェントが何をするかは常に人間が決める——その原則をアーキテクチャレベルで担保しているのが印象的でした。
Dev → Staging、1 プロンプトでいけるんですか!?
最初のデモは、管理者が「ある自動化を開発テナントから staging テナントに移行する」というシナリオです。
対象は「three-way matching voice processing」というソリューションパッケージ。スピーカーはターミナルに以下の内容のプロンプトを入力
「three-way matching voice processing ソリューションを開発テナントから staging テナントに移行し、accounting フォルダ配下にデプロイし、Robot の link voice を割り当て、Gmail アカウントを Automation User として割り当て、PM for accounting のマシンも割り当てる」
Coding Agent は一連のアクションを実行し始めました。
- dev テナントと staging テナントを特定
- 利用可能なソリューションを確認
- ソリューションを一方から他方へ移行
- accounting フォルダへのデプロイ
- Robot・Gmail アカウント・マシンの割り当て
処理の途中で「Loading skills...」と表示されて、CLI コマンドが適切に選択されていく様子が確認できました。テナントをまたぐ処理では認証状態の確認も自動的に行われていて、これは普通にすごいです。
処理が完了すると、accounting フォルダ配下に three-way matching input ソリューションが正常にインストールされ、Robot と Gmail アカウント、適切なマシンの割り当てまで確認できました。
1 プロンプトでここまでやるんかい!! ってなりますよね。
「成功」に見えたジョブが実は失敗していた件!!
2つ目のデモは、日常的な運用監視のシナリオです。
スピーカーは staging 環境で稼働中のソリューションに対し、「過去 6 時間の実行状況を確認してほしい」と Coding Agent に依頼。
「staging の onboarding ソリューションは過去 6 時間どのように実行されましたか?」
Orchestrator の UI 上では「成功」と表示されているジョブです。でも、Coding Agent はより深く調査しました。
分析結果は想定外のものでした。
- ジョブは表面上は成功と報告されている
- しかし、そのジョブが処理するキューを確認すると、多数のトランザクションが失敗していた
「見かけ上の成功・実態上の失敗」という状況を Coding Agent が自力で発見して、さらに原因の特定と解決策まで提案してくれたんです。
「特定のバージョンでこの問題が発生したことを特定し、以前の正常動作していたバージョンへのロールバックを提案してくれました。」
ロールバックを承認すると、Coding Agent は処理を実行。最終的にロールバックが正常に完了しました。ミスってるときって精神的にキツイから、自動でやってもらえたら崇めるレベルだよね。
セッション中には、エラーが発生した場面もありました。でも Alex はこれを「悪いことではない」と説明しています。
「Coding Agent は自己評価を行い、誤った解決策を提示した場合に気づくことができます。正しいコマンド構文を再度確認しながら進めます。また、自分のミスや皆さんの指示から学習していきます。」
要点まとめ
| トピック | 内容 |
|---|---|
| 新しい統合 CLI | npm で公開済み。構築・テスト・デプロイ・運用を一本のツールでカバー |
| Skills | CLI とともにインストールできるインストラクションセット。主要シナリオを事前定義 |
| 認証・監査 | 人間と同じ認証を共有。すべての操作が監査ログに記録される |
| デモ 1 | dev テナントから staging テナントへの自動移行・リソース割り当てを一括実行 |
| デモ 2 | ジョブは成功表示でも内部のキュートランザクション失敗を検出し、ロールバックを提案・実行 |
| ガバナンス | UAC 等 OS 権限も尊重。エージェントが勝手に動かない設計 |
| エラー対応 | Coding Agent は自己評価し、失敗から学習して再試行する |
おわりに
というわけで、「Coding Agent for Managing Automation Deployments」セッションのレポでした。
自分自身、UiPath の運用管理に関わる中で、デプロイ後のトラブル対応・バージョン管理・権限設定といった作業に多くの時間を費やしてきました。「運用フェーズの時間は構築フェーズよりもはるかに長い」 という指摘は、身をもって実感しているところです。
Coding Agent がこれらの作業を「理解して実行できる」ようになれば、開発者が本来注力すべき設計・改善の時間を大幅に確保できる。そういう未来、楽しみです。
デモ中にいくつかの操作がうまくいかない場面もあって、スピーカー自身「まだ調整が必要」と認めていましたが、統合 CLI と skills という基盤が整ったことで実用化への道筋は明確になったと感じます。
みんな Coding Agent に運用を任せてハッピーになろう!!
次回は別セッションのレポを書いていきます。お楽しみに!