見出し画像

UiPathからPADへの移行で本当に遅くなるのか？

ITフリーランスおやじ（AIプロダクトデザイナー）

8時間処理がPADで提供できなくなる問題を徹底検証した話

📌 この記事でわかること

  • UiPathからPADに移行すると本当に遅くなるのか

  • どうすればUiPathと同等以上の速度を出せるのか

  • IE環境という最悪の条件でも諦めない方法

  • 実測データに基づく具体的な設定方法

  • どういう方式を採用すればいいのか

🏁 はじまりは「不安」から

社内で8時間かかっているUiPath処理を、PADに移行する話が出た。

すると、こんな声が上がった。

「PADって遅いんでしょ？8時間が24時間になったら提供できないよ」

確かに、ネット上では「PADは遅い」という噂をよく見かける。

でも本当にそうなのか？

検証してみないとわからない。

というわけで、実際に動かして測定してみることにした。

作成したサイトはこんなもの

🐢 第1回戦：PADデフォルト設定は確かに遅かった


まず、PADをデフォルト設定で動かしてみた。

結果：UiPathの約3倍遅い

  • 要素取得が遅い

  • 入力がワンテンポ遅れる

  • 画面遷移のたびに謎の待機時間

体感でも「これは遅い...」と感じるレベル。

このままでは8時間が24時間になる懸念が現実味を帯びてきた。

🔧 第2回戦：パラメータを全部OFFにしたら劇的改善


「PADには細かい設定がたくさんあるらしい」という情報を得て、Webアクションのパラメータを調べてみた。

PADのWebアクション設定項目

PADの「Webページ内のテキストフィールドに入力する」には、こんな設定がある：

⚙️ 物理的にキー入力を行う（デフォルト：ON）

  • 何をするか: キーボードを1文字ずつ叩く動作を再現

  • メリット: 確実

  • デメリット: めちゃくちゃ遅い

⚙️ フォーカスを移動する（デフォルト：ON）

  • 何をするか: 入力後に次の項目へフォーカスを移す

  • メリット: 確実に次に進む

  • デメリット: 余計な待ち時間が発生（1回50-200ms）

⚙️ ページ読み込み待機（デフォルト：ON）

  • 何をするか: ページが完全に読み込まれるまで待つ

  • メリット: 安定する

  • デメリット: 無駄に待たされることが多い

これを全部OFFにしてみた結果


全部オフにしたときの画面

UiPathとほぼ同等の速度まで改善！

UiPath直入力：    1分23秒
PAD全OFF：        1分04秒  ← UiPathより速い！

「PADでもここまで行けるじゃん！」

希望が見えてきた。

🧨 第3回戦：しかし「IE環境」という現実に直面

ここで重大な事実に気づく。

うちの会社、まだIEが現役じゃん...

IE環境の問題点


PADには3つのブラウザ起動モードがある：

  1. 新しいInternet Explorerを起動

  2. 実行中のInternet Explorerに接続

  3. オートメーションブラウザを起動

IEを使う場合、以下の制約がある：

  • ブラウザインスタンスが使えない

  • Webアクションが不安定

  • 拡張機能が動かない

つまり、さっき最適化したWebアクションが本来の性能を発揮できない。

結果として、UI要素（UIA）で操作するしかないという現実に戻された。

😱 第4回戦：UI要素で入力すると文字が入らない地獄



UIAで入力すると、こんな問題が発生：

  • IMEが暴走する

  • 入力が確定しない

  • フォーカスが勝手に外れる

  • 文字が入らない

  • 入っても次に進まない

苦肉の策：Tab送信で強制確定

各入力の後にTabキーを送信することで、

  • IME確定

  • 次の欄へ移動

を強制的に実行する方式を採用した。

🐌 第5回戦：Tab送信を入れたら速度3倍悪化



Tab送信で安定はしたが、新たな問題が発生。

遅くなる理由

  • 毎回IME確定処理（50-100ms）

  • 毎回フォーカス移動（100-200ms）

  • UIAの要素探索が遅い（50-150ms）

これらが積み重なった結果...

UiPath：          1分09秒
PAD UIA Tab送信： 3分09秒  ← UiPathの3倍！

「やっぱり8時間が24時間になる...」

当初の不安が再びよみがえってきた。

⚡ 最終回戦：「シミュレート」をONにしたら奇跡が起きた



もう手詰まりかと思ったそのとき、PADのUI要素入力に**「テキストをシミュレートする」**という設定があることに気づいた。

ダメ元でONにしてみた。

結果：驚異の4倍高速化！

PAD UIA Tab送信：      3分09秒
PAD UIA シミュレート：  40秒  ← 4.7倍速い！

しかもUiPathシミュレート（1分09秒）より速い。

なぜこんなに速いのか？

🔹 IMEをバイパス

  • Win32 APIのSetWindowText()で直接値を書き込む

  • IME変換プロセスを完全スキップ

  • 確定待機時間ゼロ

🔹 フォーカス制御が簡略化

  • 値設定と同時にフォーカス状態を同期

  • 明示的なフォーカス移動が不要

🔹 入力確定が自動化

  • OnChangeイベントを自動トリガー

  • アプリケーション側が即座に認識

🔹 UIAの弱点を回避

  • UIオートメーションの抽象化レイヤーをスキップ

  • Win32 API直接呼び出しで高速化

特に重要なのは「IME確定時間の削減」

日本語環境では、1回50-100msの確定時間がかかる。

10,000件の入力なら、これだけで8-17分の差になる。

🎯 全体の結果まとめ

8時間処理の場合の推定

方式 推定処理時間 UiPath現行 8時間 PAD Web 全OFF 7.2時間（改善） PAD UIA シミュレート 4.8時間（大幅改善！） PAD UIA Tab送信 21.6時間（悪化）

🚫 オートメーションブラウザは使わない方がいい理由


「IE嫌だし、オートメーションブラウザ使えばいいじゃん」

と思うかもしれないが、これには大きなリスクがある。

オートメーションブラウザの問題点

  • PAD内蔵のChromiumエンジンに依存

  • PADアップデートでエンジンが更新される

  • DOM解釈が変わる

  • 要素が取れなくなる

  • クリック位置がズレる

  • 突然動かなくなる

実際にあった事故

PADのマイナーアップデート後、オートメーションブラウザで作ったフローの15%が動作不良になった事例がある。

本番運用では避けるべき。

✅ 結論：PADは遅くない。設定次第で爆速になる。


最も重要な発見

1.PADは本質的に遅いわけではない。設定次第で速くも遅くもなる。
2.IE以外でもUIAを使えばいい。UIAはWEBの 約 1.6 倍速い

実測してみると、\frac{64}{40}=1.6　となった。
関連して調べてみると、
2020年以降、Microsoftは UIA を大幅に改善して、ValuePattern がほぼ100％安定して動くようになった。だから、「UIA＋シミュレートON＝事故る」ケースが普通にあったが今はない。ただし以下の環境は注意が必要。

■ ① UIAの ValuePattern が不完全

  • 一部の input に値が入らない

  • 入力が途中で切れる

  • 変換イベントが発火しない

  • 画面が小さいと UIA が要素を見失う

■ ② IME が強制的に介入するケースがあった

  • 日本語入力欄で ValuePattern が無効化

  • シミュレートONでも IME が勝手に変換

  • 文字化けや欠落が起きる

■ ③ IE の DOM が UIA と干渉してフォーカスが飛ぶ

  • 小さいメニュー

  • iframe

  • ポップアップ

  • hidden input

  • tabindex の癖

こういう環境では、
「全部シミュレートON」はむしろ危険だった。

環境別の推奨設定

🌐 モダンブラウザ（Chrome/Edge）の場合

✅ Webアクションを使う ✅ パラメータを全OFF ✅ ブラウザインスタンスを活用

→ UiPath並みか、それ以上の速度

これは間違い！
この環境下だと普通にUI要素を取ろうとすると自動でWEBアクションでないと使えないUI要素を取得するが、「UI要素を調査する」で取得すればUIAでフローに追加されます。

🌐 IE環境の場合

✅ UI要素（UIA）を使う ✅ シミュレート入力をON ✅ Tab送信は最終手段 ❌ オートメーションブラウザは避ける

→ UiPathより速くなる可能性あり

話は少しそれるけど、ついでにWEBとUIAの違いを見てみよう。

つまり、WEB操作は、DOM操作になるので遅くなりがちなのである。
UIAのほうがOS直で画面構造にも強いので、これを利用しない手はないということだ。

📝 実装のポイント

まとめると、WEBアクションとUIAの2種類はあるけど、UIAのみで100％シミュレートONで何も問題ないので、それ一択でOKです。

Webアクション使用時（モダンブラウザ）

[設定画面で全部OFF推奨]
□ 入力をエミュレートする → OFF
□ 物理的にキー入力 → OFF
□ フォーカス移動 → OFF
□ ページ読み込み待機 → OFF

UI要素使用時（IE環境）

[シミュレートを必ずON]
☑ テキストをシミュレートする → ON

🎓 技術的な学び

IME確定時間が最大のボトルネック

日本語環境では、IME確定処理が処理速度を大きく左右する。

  • 通常入力：1回あたり50-100ms

  • シミュレート：ほぼゼロ

10,000件処理すると：

  • 通常：500-1000秒（8-17分）

  • シミュレート：ほぼ待機なし

この差が業務遂行可能性を左右する。

💡 まとめ

Q: 8時間の処理はPADで提供できるのか？

A: できる。むしろ速くなる可能性もある。

重要なのは

  1. 環境に合わせた設定

  2. パラメータの最適化

  3. シミュレート入力の活用

  4. IME確定時間の削減

これらを理解して実装すれば、PADはUiPathと同等以上のパフォーマンスを発揮する。

「PADは遅い」は誤解。正しくは「デフォルト設定が遅い」だった。

📚 参考資料

  • 図1: 実測性能比較データ

  • 図2: PAD Webアクションパラメータ設定画面

  • 図3: ブラウザ起動モード選択画面

2026年1月 RPA Performance Research Team

🔖 関連記事（予定）

  • PADパラメータ完全ガイド

  • IE環境でのRPA最適化テクニック

  • シミュレート入力の内部動作解説

  • オートメーションブラウザのリスク詳細

この記事は実務での検証結果に基づいています。環境により結果は異なる場合があります。

最後に

動画も作成してみましたので見てみてください。


ちなみにこれを論文ぽくしたのでこちらもよかったらどうぞ


いいなと思ったら応援しよう！