速度が勝敗を分ける業務
ある日、お客様からこんなご依頼を受けました。
「webページでチケット購入を、発売時間ピッタリに行いたい。」
一見するとシンプルな依頼に聞こえますが、そのwebページは、時間ちょうどにアクセスを行ったとしても、すぐに完売してしまうような超人気ページでした。そうなると、求められるものはただ一つ―処理速度です。
人間の手作業では間に合わない、ミリ秒単位で勝負が決まるような状況。そこでRKシリーズの処理速度を最適化し、人間の反応速度をはるかに超える高速処理を実現する必要がありました。
今回は、この実体験を通じて学んだRKシリーズの処理速度最適化について、どの認識方式が最速か、どう使い分けるべきかを詳しく解説します。
RKシリーズの3つの認識方式と速度特性
RKシリーズで画面要素を認識する方法には、大きく以下の3種類があります。それぞれの方式には、速度面で明確な違いがあります。
速度ランキング
| 順位 | 認識方式 | 速度 | 特徴 |
|---|---|---|---|
| 1位 | 画像認識 | 最速 | 画面に表示された瞬間に反応 |
| 2位 | HTML要素認識 | 中速 | ページ読み込み+要素探索処理あり |
| 3位 | UI要素認識 | 標準 | アプリケーション層の探索処理あり |
1位:画像認識―目視を超える驚異の反応速度
画像認識は、RKシリーズの中で圧倒的に最速の認識方式です。その速度は、人間の動体視力をはるかに超えるレベルに達しています。
実際の体感
チケット購入の自動化シナリオで画像認識を活用した際の体験をお話しします。
画像が画面に表示された瞬間に反応し、本来は目視をベースに処理が動作しますが、私の動体視力が追い付かないほどの速度で処理が完了していました。
画面に要素がパッと表示され、私が瞬きをしたその瞬間には、その処理はすでに終了し、画像は画面から消えていた―そんな状況でした。
なぜここまで速いのか
画像認識の仕組み上、画面のピクセルデータを直接参照し、設定した画像パターンと一致する箇所を高速スキャンします。ブラウザのDOMツリーを解析したり、アプリケーションのUI要素を探索したりする必要がないため、余計な中間処理が発生しません。
画面に表示されているものを、そのままのビジュアル情報として認識するため、表示された瞬間に反応できるのです。
キーエンスだからこその精度
画像認識の精度の高さは、RKシリーズならではの強みです。画像が部分的に変化したり、背景にノイズがあったりする状況でも、安定して認識できる精度を持っています。
実際に、私はUiPathやPower Automateなど他のRPAツールも触っていますが、画像認識の性能は全く異なるレベルです。RKシリーズの画像認識は、実務で「使える」精度と速度の両立を実現しています。
2位:HTML要素認識―安定性と速度のバランス
HTML要素認識は、Webブラウザ上の要素をHTMLのタグ・属性・構造から特定する方式です。
処理の流れ
HTML要素認識では、以下のステップを経て要素を特定します。
- Webページの読み込み完了を待つ
- ブラウザのDOMツリーを構築・解析する
- 指定したXPathやセレクタで要素を探索する
- 要素が見つかったら対象の処理を実行する
このように、ページの読み込みとDOM解析、要素探索という中間処理が発生するため、画像認識に比べて処理速度は劣ります。
向いている場面
HTML要素認識は、速度ではなく動作の安定性を重視する場面で最適です。
- ページ構造が変わらない社内業務システム
- 要素の位置や見た目が動的に変化する画面
- 複数の似た見た目の要素から特定のものを正確に選ぶ必要がある場面
- 長期にわたって安定稼働させたい定常業務
3位:UI要素認識―アプリケーション層での堅牢な認識
UI要素認識は、WindowsアプリケーションのボタンやテキストボックスなどのUI要素を、OSレベルで認識する方式です。
処理の流れ
UI要素認識でも、以下のステップが必要になります。
- 対象アプリケーションのウィンドウを探索する
- ウィンドウ内のUI要素ツリーを構築する
- 指定したプロパティ(名前、ID、クラスなど)で要素を特定する
- 要素が見つかったら対象の処理を実行する
アプリケーション層の探索処理が加わるため、速度面では画像認識・HTML要素認識に比べてやや劣ります。
向いている場面
UI要素認識は、以下のような場面でその真価を発揮します。
- 画面に表示されていない要素(スクロールで隠れている等)も操作できる場面
- アプリケーションのウィンドウ構成が変動する場面
- 画像認識では判別が難しい類似UIが多数ある場面
3つの認識方式を比較する
| 観点 | 画像認識 | HTML要素認識 | UI要素認識 |
|---|---|---|---|
| 処理速度 | 最速 | 中速 | 標準 |
| 動作安定性 | 表示に依存 | 高い | 標準 |
| 視認性の要否 | 画面に表示必須 | 非表示でも可 | 画面に表示必須 |
| メンテナンス性 | 画面変更に弱い | 構造変更に弱い | 構造変化に弱い |
| 最適な用途 | 高速反応が必要な場面 要素が不安定な場面 | Web業務の定常処理 | Windowsアプリ操作 |
業務の目的とアプリ特性を考慮した使い分け
処理速度の最適化において重要なのは、「どの認識方式が最速か」だけを考えるのではなく、業務の目的と操作したいアプリの特性を加味して、適切な認識方式を選択することです。
速度最優先の場面:画像認識を選択
以下のような場面では、画像認識が最適です。
- 発売開始と同時の購入処理(チケット、限定商品など)
- 画面に表示された瞬間にクリックする必要があるミニゲームや抽選
- 在庫の残り僅かな商品の確保
- 競合他社との処理速度勝負が発生する場面
安定性最優先の場面:HTML要素認識を選択
以下のような場面では、HTML要素認識が最適です。
- 社内業務システムでの定型的なデータ入力
- 複数ページをまたいだWebスクレイピング
- エラーハンドリングが重要な帳票処理
- 夜間バッチ処理などの無人運用
柔軟性最優先の場面:UI要素認識を選択
以下のような場面では、UI要素認識が最適です。
- Windowsアプリケーションの自動化
- 画面レイアウトが変更されても要素を追従したい場面
- 複数のデスクトップアプリを連携させる業務
速度を犠牲にしないハイブリッド設計
実際のシナリオ設計では、3つの認識方式を組み合わせる「ハイブリッド設計」が効果的です。
具体例:チケット購入シナリオの設計
冒頭で紹介したチケット購入のシナリオでは、以下のように使い分けました。
- 発売前の待機フェーズ:HTML要素認識で「購入ボタン」の出現を監視(ページ構造は安定しているため)
- 発売直後のクリックフェーズ:画像認識でボタンが表示された瞬間に反応(速度最優先)
- 購入フォームの入力フェーズ:HTML要素認識でフォーム要素を安定して入力(正確性優先)
このように、シナリオ内の各フェーズに応じて最適な認識方式を切り替えることで、速度と安定性の両立を実現できます。
処理速度をさらに上げるテクニック
認識方式の選択に加えて、以下のテクニックでも処理速度を向上させることができます。
1. 待機時間の最適化
「待機」処理の時間設定は、速度に大きく影響します。過剰な待機時間は処理を遅らせ、不足した待機時間はエラーを引き起こします。対象アプリケーションの応答時間を計測し、最適な待機時間を設定しましょう。
2. 認識範囲の絞り込み
画像認識では、認識範囲をできる限り狭く設定することで、スキャン時間を短縮できます。全画面をスキャンするのではなく、対象画像を限定領域で指定しましょう。
3. 不要な処理の削除
シナリオ内に、実際には不要な「待機」や「ログ出力」が入っていないか見直しましょう。特に過去のデバッグ用に追加した処理が残っているケースはよくあります。
4. マシンスペックの最適化
RPAシナリオの実行環境(CPU、メモリ、ディスク速度)も処理速度に影響します。画像認識のような重い処理を多用するシナリオでは、実行マシンのスペック向上も検討しましょう。
まとめ
RKシリーズの処理速度を最適化するためには、3つの認識方式の特性を理解し、業務の目的に応じた使い分けが重要です。
- 画像認識:最速。画面に表示された瞬間に反応。速度が勝敗を分ける場面で最適。
- HTML要素認識:中速。Webページの読み込みとDOM解析が必要。安定性を重視するWeb業務で最適。
- UI要素認識:標準。アプリケーション層の探索処理が必要。Windowsアプリの柔軟な操作に最適。
速度だけでなく、業務の目的や操作するアプリケーションの特性を加味して、最適な認識方式を選択し、必要に応じてハイブリッド設計を取り入れることで、より効果的な業務自動化を実現できます。
処理速度の最適化でお悩みの場合や、どの認識方式が適切か判断に迷う場合は、ぜひRKパートナーズまでご相談ください。貴社の業務特性に最適なシナリオ設計を支援させていただきます。
