RPAと生成AIの使い分け｜MicrosoftとUiPathの公開文書で読む

「自動化」という一語で、性質の違う二つのものが呼ばれています。決めた手順のとおりに動かすものと、入力の中身を読ませて出力を作らせるものです。どちらに任せるかで、作ったあとに見ておく場所が変わります。

先に結論を書きます。この二つは、止まり方が違います。画面を操作して動かす自動化は、相手のアプリやWebページの構造が変わると動かなくなります。止まるので、止まった事実には気づけます。いっぽう生成AIに読み取りや文章を任せた部分は、入力が変わっても止まりません。出力は返ってきます。誤っていても返ってきます。

この違いは好みの問題ではなく、提供元の公開ドキュメントに書かれている仕様から出てきます。この記事では、MicrosoftがPower AutomateとCopilot Studioについて公開しているページ、UiPathが公開しているRPAの説明を読み、どこまでを手順で書き切り、どこから生成AIに任せるかを切り分けます。最後に、社内の取り決めへ書く項目まで落とします。

扱うのは公開文書に書かれている範囲だけです。費用とライセンスの条件、導入によって何時間減るかといった効果の数値は扱いません。参照したページに記載がないか、この記事では確認していないためです。確認日は2026年11月4日です。製品の仕様は改定されるため、採用の前には各ページの現在の記載を確認してください。

公開文書は「自動化」を三つに分けている

Power Automateの「フローの種類」のページは、自動化を三つに分けています。クラウドフロー、デスクトップフロー、そして生成アクション（プレビュー）です。「各タイプのフローは特定のシナリオ向けに設計されており、個別に、または他のフローと組み合わせて使用することができます」と書かれています。

この三分割は、そのまま判断の軸になります。相手のサービスへコネクタで届くならクラウドフロー、画面しか入口がないならデスクトップフロー、手順そのものをAIに選ばせるなら生成アクション、という順で読めます。

同じページの説明を、そのまま並べると違いがはっきりします。

種類	公開文書の説明	この記事での呼び方
クラウドフロー	「自動化を自動的に、即座に、またはスケジュールを介してトリガーする場合は、クラウド フローを作成します」	ルールとコネクタで動かす
デスクトップフロー	「デスクトップ フローを使用して、Web またはデスクトップ上のタスクを自動化します」	画面を操作して動かす
生成アクション（プレビュー）	「アクションの意図のみを指定し、入力、コンテキスト、意図に基づいて適切なアクション セットを正しい順序で AI に選択させる」	手順そのものをAIに選ばせる

いわゆるRPAは、二段目のデスクトップフローの位置にあります。「デスクトップ フローの概要」のページは、デスクトップフローを「Power Automate の既存のロボティック プロセス オートメーション (RPA) 機能を拡張し、デスクトップで繰り返されるすべてのプロセスを自動化することを可能にします」と説明し、対象を「ワークステーションで単純または複雑なルールベースのタスクを実行するすべてのユーザー」としています。ルールベースという語が、この段の性質をそのまま表しています。

RPAは「画面を操作できること」に価値がある

UiPathの公式サイトは、RPAを次のように説明しています。「software robots handle repetitive, rule-based tasks like entering data, moving files, or processing transactions—quickly and accurately」。くり返しの、ルールで書ける作業を、速く正確に片づけるものだという位置づけです。そのやり方についても「mimicking human actions in interacting with screens and systems」と書いています。人が画面に対して行っている操作を、そのままなぞるという説明です。

画面を操作するという性質は、弱点のように読めますが、同時にこの手段しか持っていない強みでもあります。Microsoftのページは、自動化できる相手として「ターミナル エミュレーター、最新の Web やデスクトップ アプリケーション、Excel ファイル、フォルダーなど」を挙げ、レガシー アプリケーションを含めています。操作の手段としては「アプリケーション UI 要素、画像、または座標を使用して、コンピューターと対話できます」と書かれています。

つまり、相手にAPIが用意されていなくても手が届きます。社内に残っている古い業務システム、取引先から渡される固定様式の帳票、ベンダーが連携の口を開けていないソフト。こうした相手に対しては、コネクタを介した自動化が成り立ちません。ここがデスクトップフローの領分です。業務自動化そのものの考え方はAIによる業務自動化とは？導入の判断と進め方を解説で整理しています。

画面に依存するとは、具体的に何に依存するのか

「UI 要素を使用して自動化する」のページを読むと、依存先がもう少し細かく分かります。冒頭に「デスクトップ フローでは UI 要素を使用してアプリケーションや Web ページを操作するため、画像認識や絶対座標を使用する必要はありません」とあります。先の概要ページで挙げられていた画像や座標は使えますが、既定の方法はUI要素の指定です。ここを混同すると、後の話が合わなくなります。

ではUI要素の指定とは何か。同ページは「各セレクターは、アプリケーションまたは Web ページの UI 要素の階層構造を表す複数の要素で構成されます。各要素の属性はそれを一意に記述し、他の要素と区別します」と書いています。画面の中の位置を覚えているのではなく、要素の階層と属性で「これだ」と指しているわけです。

指定の方式は三つ挙げられています。新しいUIフレームワークで作られたアプリに推奨されるUIAセレクター、UIAの要素を公開しないレガシー アプリケーション向けのMSAAセレクター、そして標準のUIAでは要素に届かない場合に使うUIA3 Rawセレクターです。レガシー対応の説明に「MSAA は UIA ほど詳細と構造を提供しませんが、UIA を使用できない環境で自動化を有効にするために不可欠です」とあり、古い相手ほど指定が粗くなることが読み取れます。

注目したいのは、同じページが指定が外れる前提で手当てを用意している点です。「ユーザーは、UI 要素のセレクターを複数作成できます。セレクターが失敗するたびに、Power Automate は定義された順序で次のセレクターを使用します」という記載があります。さらに、要素のテキストに基づく指定について「これらのテキストに基づくセレクターは、より信頼性が高く、将来のアプリケーションまたは Web ページ構造変更に対して対応できます」と書かれています。

将来の構造変更という言葉が、公式の文書に出てきているということです。画面は変わるものとして扱われています。ブラウザーについても具体的な注意があり、Webページ上でデスクトップ側のUI要素を取った場合は「Web の対応する要素ほど信頼性が低く、ブラウザのバージョンなどのブラウザ アプリケーションの詳細に影響される」と明記されています。

生成AIに任せた部分は、止まらずに間違う

もう一方を見ます。Copilot Studioの「プロンプトの概要」は、プロンプトを「主に自然言語の指示で構成され、生成AIモデルにタスクを実行するよう指示します」と説明しています。向く仕事として挙がっているのは「コンテンツの要約、データの分類、エンティティの抽出、言語翻訳、感情の評価、苦情への対応策定」です。例として、会社のメールからアクション項目を選び出すプロンプトを作り、それをワークフローで使ってメール処理を組む形が示されています。

同じページには「決定論的な自動化にAIアクションを組み込む」という言い方も出てきます。全体は決まった手順で動かし、その一部にAIの判断を差し込むという構図です。置き換えではありません。

そして「人間による監視」という節が立っています。ここが設計上もっとも重い記載です。「このようなモデルは膨大なデータで訓練され、誤りやバイアスを含むことがあります。オンライン投稿、顧客への送信、ビジネス判断の参考にする前に、人間がコンテンツを確認すべきです」と書かれています。提供元が、確認の手順を前提として示しているわけです。

二つを並べると、監視の置き場所が逆になることが分かります。画面を操作する自動化は、壊れたときに処理が進まなくなります。放っておいても異常は表に出ます。だから見ておくべきなのは「止まった」という連絡が誰に届くかです。

生成AIを挟んだ部分はそうなりません。出力は常に返ってきます。要約は作られ、分類は付き、下書きはできあがります。それが正しいかどうかは、出力の形からは分かりません。見ておくべきなのは、送信や公開や判断の前に、誰がどの観点で中身を見るかです。

境界は「手順で書き切れるか」で引く

では自社の作業をどちらに振るか。公開文書が例として挙げている作業を並べると、分かれ目が見えます。

公開文書が挙げている作業	性質	任せ方
ドキュメントをファイルとフォルダーの操作で整理する	手順が一定	画面またはコネクタの操作で書き切る
Webサイトからデータを抽出してExcelファイルに格納する	手順が一定・相手の画面に依存	画面を操作する自動化
ERPシステムでのデータ入力	手順が一定・相手がレガシーなことがある	画面を操作する自動化
コンテンツの要約、データの分類、エンティティの抽出	入力の書きぶりが毎回違う	プロンプトで任せ、出力を人が確認する
言語翻訳、感情の評価、苦情への対応策定	正解が一つに決まらない	プロンプトで任せ、出力を人が確認する

マーケティングの現場に置き換えると、広告の管理画面から数字を落として決まった表に貼る作業は上の側です。手順が決まっていて、同じ入力に同じ結果が返ることを前提にできます。いっぽう、問い合わせの本文を読んで種類を振り分ける、長い回答を要約して共有する、レビューの文面から不満の対象を拾う、といった作業は下の側です。入力の書きぶりが毎回違うため、条件分岐で書き切れません。

注意したいのは、分類という言葉が両側に現れることです。「件名に特定の語を含むなら営業部へ」で足りるなら、それはルールで書けます。本文を読んで意図を判定しなければならないなら、生成AIの側です。判断の分かれ目は作業の名前ではなく、入力の形式が揃っているかどうかにあります。社内の呼び名と実際の判定基準を切り分ける作業は、リードの引き渡し基準でも同じ形で出てきます。こちらはMQLの定義は自社で決めるで扱いました。

AIが手順を選ぶようになっても、実行する層は残る

AIエージェントが手順まで組み立てるようになると、ルールで書く部分は消えるのでしょうか。UiPathの説明は、そうは書いていません。「RPA has emerged to become an essential capability for agentic automation—a new form of automation that leverages intelligent AI agents」とし、両者の関係を「Working alongside AI agents, RPA robots play a complementary role in the execution stack, delivering tasks quickly, efficiently, predictably, and securely」と説明しています。実行の層としては補完関係にあるという整理です。

ここで使われている predictably という語は読みどころです。AIエージェントが決めた内容を、予測できるかたちで実際のシステムへ反映する役が要る、と読めます。同社は「RPA will remain essential by providing the reliable execution layer for AI-driven automation strategies」とも書いています。これは提供元の見通しであって、検証された結論ではありません。そのうえで、層が分かれるという構図は、Microsoftの側の記載とも矛盾しません。

Microsoftの生成アクションは、現時点ではプレビューと明記されています。AI Builderのページには、プレビュー機能について「プレビュー機能は運用環境向けではなく、機能が制限されている可能性があります」という注記があり、「管理者は、Power Platform 管理センターを使用して、各自の環境でのプレビュー機能の利用可能性を制御できます」とも書かれています。手順をAIに選ばせる形は用意されつつありますが、本番に載せる前提の機能としては案内されていません。

したがって、いま決めるべきなのは「どちらに寄せるか」ではありません。層ごとに担当を決めることです。読み取りと判断をAIに寄せ、実行は手順の側に置き、その間に人の確認を挟む。エージェントに権限をどこまで渡すかという論点はAIエージェントをマーケティングに活用する方法｜できることと導入で扱っています。広告のデータへAIをつなぐ公式の入口が整い始めた動きは広告データにAIエージェントの正面入口。SnapとGoogleの公式MCPサーバーにまとめました。

社内の取り決めに書く六項目

公開文書の記載から、社内文書に落とせる項目を並べ替えます。ツールを選ぶ前に書けるものばかりです。

最初に書くのは、実行の形です。コネクタで届く相手なのか、画面を操作するしかない相手なのかを、作業ごとに分けて書きます。ここを曖昧にしたまま道具を選ぶと、API連携で済む作業まで画面操作で組むことになり、壊れやすい部分を自分で増やします。

二つめは、画面に依存している箇所の一覧です。どのアプリの、どの要素に依存しているのかを書き出し、そのアプリの更新を誰が知らせるかまで決めます。公開文書が構造変更を前提にしているなら、変更の連絡経路を持っていないほうが例外です。

三つめは、指定の代替です。セレクターを複数持たせられること、失敗したら定義順で次が使われること、テキストに基づく指定が構造変更に対応できるとされていること。これは記載されている機能なので、使うかどうかを決めておけば済みます。

四つめが、出力の確認です。これだけは省けません。公開・送信・判断の前に、誰が、何を見るのか。文面の体裁ではなく、事実関係と数値のどこを突き合わせるのかまで書きます。確認の観点を書かないと、確認という工程名だけが残ります。

五つめは、プレビュー機能の扱いです。運用に載せる機能と、試すだけの機能を分けて書きます。管理者側で環境ごとに切り替えられるため、線を引く場所は決められます。

六つめは、止まったときの通知先です。画面操作の側は止まることで知らせてくれますが、通知が誰にも届かなければ気づくのは数日後になります。あわせて、止まらずに誤った出力が出た場合の報告経路も同じ場所に書いておきます。性質の違う二つの異常を、一つの文書で受けられるようにするためです。

公開文書で確認できなかったこと

参照したページの記載だけで書いているため、空欄をそのまま残します。

費用とライセンスの条件は扱っていません。価格ページへの案内はありますが、金額の記載をこの記事では確認していないため、数値を書きません。

構造の変更でどれくらいの頻度で止まるのか、止まった場合の復旧にどれだけかかるのかは、参照した範囲に記載がありません。生成AIの出力がどの程度正しいかを示す数値も、同じく記載がありません。精度に触れている箇所は、誤りやバイアスを含むことがあるという注意だけです。

有人と無人の実行モードの違い、必要な環境の条件も扱っていません。別のページに分かれており、今回は参照していません。UiPathについては定義のページだけを読んでおり、製品の機能ごとの仕様は確認していません。日本語の文書や日本語の問い合わせ文に対する精度についても、記載を確認できませんでした。

導入によって何時間減るか、人員が何人分浮くかという効果の数値は、この記事では一切示しません。公開文書にない数値だからです。海外企業が公開しているマーケティングの考え方は海外企業のマーケティングにまとめています。

まとめ

RPAと生成AIは、同じ「自動化」の言葉で呼ばれていても、依存しているものが違います。前者は画面のUI要素の指定に依存し、後者はモデルの出力に依存します。

そこから、壊れ方の違いが出てきます。画面側は止まります。アプリやWebページの構造が変われば指定が外れ、処理が進まなくなります。公開文書はそれを前提に、セレクターを複数持たせる方法と、テキストに基づく指定を案内しています。生成AI側は止まりません。誤っていても出力は返るため、確認の手順がなければ誤りはそのまま下流へ流れます。提供元の文書も、公開・送信・判断の前に人が確認すべきだと明記しています。

切り分けの基準は、入力の形式が揃っているかどうかです。揃っているなら手順で書き切り、揃っていないなら生成AIに任せて、出力を人が見る。手順そのものをAIに選ばせる形はプレビューとして用意され始めていますが、運用環境向けではないと注記されています。

決めるのはツールの前です。実行の形、依存箇所の一覧、指定の代替、出力の確認者と観点、プレビュー機能の扱い、通知先の六つを社内文書に書けば、どの製品を選んでも運用の形は崩れません。確認日は2026年11月4日です。