UiPath DevCon Tokyo に登壇しました。来られなかった方へ、15分の中身をぜんぶ置いておきます

7月29日、UiPath DevCon Tokyo の Agentic Automation How-To トラックで登壇してきました。セッション名は 「開発」だけじゃない ― 運用現場で効くCoding Agent活用術。

前の記事で「内容は書きません。ここで書いたら明日聞く意味がなくなるので」と書きました。もう終わったので、書きます。会場に来られなかった方が、この記事だけで持ち帰れる粒度で。

先にセッションの約束を再掲します。

コードは1行も書きません
開発者でなくても大丈夫です
Agent が実際に作ったものを、スクリーンショットではなく実物でお見せします

3つ目は記事でも守ります。Agent が作った設計書の実物を、記事の最後で公開しています。プロンプトも全文載せるので、そのまま真似できます。

なぜ「運用」の話をしたのか

Coding Agent の話題、よく聞きますよね。ただ、よく聞くのはだいたい「開発を速くする」話です。コードを書く速度、テスト、作り直し。どれも本当です。

でも、思い出してください。私たちの現場の時間は、ほとんどが運用フェーズです。作るより、回す・直す・引き継ぐ時間のほうが、ずっと長い。しかも、そこにいるのは開発者じゃない人も多い。

じゃあ、そこで Coding Agent は使えないのか？——使えるんです。運用では、「読む」と「測る」 で効きます。この2つの動詞が、セッションの背骨でした。

お断り：UiPath for Coding Agents について

「UiPath for Coding Agents」は今後リリース予定の機能なので、ご存じなくて当然です。1つだけ押さえておいてほしいのは、「UiPath Skills」——いわば AI 向けの、UiPath の取扱説明書——が公開されて、AI が UiPath のことを"正確に"分かるようになったこと。今回の話は全部、この上に乗っています。

（製品自体の解説は、当日私の直後にあった公式セッション「あなたの隣のもう一人の開発者、UiPath for Coding Agentsが拓く新時代」が本命でした。）

CASE 1「読む」：ワークフローを読ませたら、設計書ができた

ある質問

会場でこう聞きました。「うちのワークフローは、作った人が今も全員社内にいて、ドキュメントも完備されています——という方、手を挙げてもらえますか？」

誰も挙げませんでした。ですよね。作った人はもういない、ドキュメントもない、でも毎日動いている。中身がブラックボックス化したワークフロー、きっとあなたのお手元にもあります。

手を入れる前に、まず"読む"。これが運用の入口です。

プロンプトは、これだけ

このワークフロー（.xaml）を読んで、
引き継ぎ用の設計書をExcelで作って。
実際に動かして画面を確認しながら、
手順は実画面のスクショつきで。
不明点は推測せず質問して。

見てのとおり、かなりざっくりです。シートの構成も書式も指定していません。ポイントは2つだけ。

成果物を指定する——「引き継ぎ用の設計書を Excel で」
「実際に動かして画面を確認しながら」——読ませるだけじゃなく、ライブで確かめさせる

2つ目の一文が、後で効いてきます。

出てきたもの

題材は UiPath Academy の演習ワークフロー「Exercise_Advanced_UIAutomation」。ACME サイトの従業員情報を取得して Web フォームへ転記・送信するだけの簡単なもので、ドキュメントなし・Main.xaml が1本あるだけの状態です。

読ませたら、数分で Excel 7シートの設計書が出てきました。プロセス概要、変数定義、15ステップの処理フロー表。

…と、ここまでは正直「まあ、これくらい AI ならやるよね」の範囲だと思うんです。本領は、ここからです。

Agent 自身で動き、撮って、赤枠までつけた

設計書の中に「実行ステップ」というシートがあります。これ、Agent がブラウザでこのワークフローを"自分で"実行しながら作ったものです。さっきのプロンプトの「実際に動かして画面を確認しながら」——あの一文の結果が、これです。

実画面のスクリーンショットに、操作対象の赤枠、手順の解説。私はスクショを1枚も撮っていません。 Agent が一人でやりました。

このシートを初めて見たとき、正直、ちょっと引きました。「あ、これ、仕事なくなるかも」と思って。前の記事で「検証していて一度ゾッとした瞬間があった」と書いたのは、これのことです。

でも冷静に考えると——スクショを撮って、貼って、赤枠で囲んで、説明を書く。あれ、そもそも人間がやる仕事じゃなかったんですよ。手順書づくりの"あの作業"は、まるごと Agent の仕事になりました。

駄目押し：「所見」まで言ってきた

残りのシートには、フローチャートと——ここが一番面白いんですが——「所見」 が入っていました。頼んでもいないのに、全部で10件。

「本来繰り返す前提の"足場"だけが残っていて、ループが未実装ですよ」
「例外処理がないので、本番化には Try-Catch／Retry Scope が要りますよ」
「フォーム入力が位置依存なので、項目の並び替えに脆弱ですよ」

生意気じゃないですか。で、悔しいことに、だいたい正しいんですよ。

念のため補足すると、題材は演習教材なので、シンプルに作ってあるのは正しいんです。面白いのは、Agent もそこを分かっていること。所見には「教材としてはこれで正しい。ただ、本番化するならここを直す」という書き分けまでしてありました。そこまで空気読めるのか、と。

ただし。 この指摘が正しいか、どう直すかを見極めるのは、人の仕事です。生成物は鵜呑みにしない。CASE 1 は、ここまでセットで持ち帰ってください。

Before / After とコツ

Before：資料を人力で読み解く——半日〜数日
After：下書き生成——数分。人は確認・追記だけ

コツは小さく試すこと。いきなりフォルダ丸ごとではなく、まず1ファイル読ませて精度を確認してから広げる。これで失敗しません。

CASE 2「測る」：ログを渡したら、レポートができた

今日2回目の「手が挙がらないやつ」

ロボット、動いてはいるけれど——どの部署が、どのプロセスで、どれだけ使っているか、即答できますか？

会場では、これも手が挙がりませんでした（私も即答できなかったので、安心してください）。

"合鍵"を1本渡すだけ

私がやったのは、Orchestrator の読み取り専用の"合鍵"（認証情報）を1本渡しただけ。あとは Agent が自分でログを取りに行きます。ログのダウンロードすら、していません。

Orchestratorの直近30日の
稼働ログを調べて、RPAの稼働状況
レポートをスライドにまとめて。
部署ごとの利用時間は必ず入れて。
他に必要そうな分析があれば、
それも加えて。

CASE 1 と同じノリです。集計の軸と出力形式を指定する。ただ、今回は1つ足しています。最後の 「他に必要そうな分析があれば、それも加えて」。人が思いつく範囲に縛らず、余白を渡す。——この一文が、後で効いてきます（2回目）。

ちなみに、Orchestrator の画面でも数字は見られます。ただ、決まった見方しかできない。自由な切り口で束ねて、レポートまで作ってくれるのが Agent の仕事です。

出てきたもの

実際の直近30日分の稼働ログ——ロボット4台、6,828ジョブ、68プロセス——から、グラフ・表つきのレポートが数分で出てきました。

部署別の実行時間。うちは使った部署ごとに費用を分担する運用をしているので、この数字がそのまま按分の根拠になります。誰がどれだけ使ったかが見えると、コストの話が揉めなくなります。

そして——時間帯ごとに、ロボットが上限に張り付いている様子（朝9〜11時に混雑が集中、ピーク稼働83%）。これ、私は頼んでいません。プロンプト最後の「他に必要そうな分析があれば」——あの一文から、Agent が自分で加えてきた分析です。人間が見落としていた視点が、向こうから出てくる。

もう1つ面白かったのが失敗の深掘りです。一番失敗の多いプロセスを Agent が調べたら、失敗21件のうち81%は、自動化の不具合ではなく「多重起動ガード」——同じ処理の二重起動を防ぐ安全装置——による自動終了でした。直すべきものと、そうでないものが切り分けられた。

数字が見えると、次のアクションが決まる。これが「測る」の価値です。

応用

同じ要領で応用が効きます。一番のおすすめは、「先月と比べて何が変わった？」と一言聞くだけの比較分析。決まったダッシュボードと違って、聞き方は自由です。時間帯別の混雑・空き、長期間動いていないプロセスの洗い出し——本当にアイディア次第、全部同じやり方でできます。

まとめ：明日の第一歩

Coding Agent は、"開発"だけじゃない。運用では「読む」と「測る」で効きます。

明日の第一歩は2つ。どちらか1つで構いません。

中身が分からないワークフローを1つ、Agent に読ませてみる
ロボットの稼働ログを、その場で可視化してみる

慣れてきたら、同じやり方は「落ちたワークフローを直す」運用デバッグにも効きます。読む、測る、の次は、直す、へ。

最後に、ひとつ本音を

設計書を Agent が作ったのを見て気づいたのは——ボトルネックは AI じゃなくて、私自身だった、ということです。「自分で読んだ方が早い」「自分で書いた方が正確」。そのプライドが、一番 AI の速度を邪魔していました。

逆に、「他に必要そうなら加えて」と余白を渡したら、頼んでもいない分析が返ってきた。AI の邪魔をしないことが、プラスアルファの価値を生むんです。

だから、いまの私の結論はシンプルです。

"AI は呼吸"。頭で考える前に、まず AI へ渡す。理解は AI の出力からで十分。

開発を速くする、の"その先"。運用現場こそ、Coding Agent の伸びしろがあります。

お土産：設計書の実物、公開中

壇上で QR コードから配ったものと同じです。今日お見せした設計書——スクショではなく実物を、そのまま公開しています。

業務プロセス設計書｜Google スプレッドシート

（閲覧のみ・ログイン不要です）

7シート全部入っています。特に見てほしいのは 「実行ステップ(実画面)」 のシート。Agent が自分で動かして、撮って、赤枠をつけたやつです。記事中のプロンプトと一緒に持ち帰って、そのまま真似してください。

おわりに

会場で声をかけてくださった皆さん、ありがとうございました。「手が挙がらないやつ」に2回付き合ってくれた皆さんも。

質問・感想はコメントか X へどうぞ。Coding Agent の話、いつでもしましょう。

X: @hash1moUI