RPA が画面変更で止まる理由と、止まりにくい自動化の作り方

朝、出社するとロボットが止まっていた。調べると、取引先の Web システムのボタンの位置が少し変わっていた。RPA を運用している現場では、よく聞く話です。

この記事では、RPA のロボットが画面の変更で止まる仕組みと原因を整理し、止まりにくく、止まってもすぐに直せる自動化の作り方を解説します。特定の製品に限らず、Web システムを操作する自動化に共通する考え方です。

RPA は画面をどう見ているか

RPA のロボットは、人が画面で行う操作を手順として記録し、同じ手順を再生します。そのとき、操作する対象（ボタンや入力欄）を次のような手がかりで特定します。

画面上の座標：「左から 320 ピクセル、上から 180 ピクセルの位置をクリック」
画像：「この見た目のボタンを探してクリック」
画面の要素の情報：Web ページの HTML に含まれる ID、名前、XPath や CSS セレクタ

座標や画像より、要素の情報を使うほうが変更に強いとされています。ただ、どの手がかりも「記録した時点の画面」を前提にしています。前提が崩れると、ロボットは対象を見つけられずに止まります。

止まる原因は大きく 5 つ

1. 画面のデザインや項目の変更

Web システムの改修で、ボタンの位置、要素の ID、項目の並びが変わるケースです。利用者から見ればほとんど同じ画面でも、ロボットが頼りにしている手がかりが変わっていれば止まります。取引先や外部のサービスが提供する Web システムは、変更の予定を事前に知らされないことも多く、ある日突然止まります。

2. 想定していない画面が出る

お知らせのポップアップ、パスワード変更の案内、メンテナンス中の画面、追加の認証など、記録したときにはなかった画面が割り込むケースです。人なら閉じて先に進めますが、ロボットは次の操作の対象が見つからずに止まります。

3. 表示の遅れ

画面の読み込みが、ロボットが待つように設定された時間より遅いと、まだ表示されていない要素を操作しようとして失敗します。月末や朝の時間帯など、システムが混み合うときだけ止まるロボットは、この原因であることが多いです。

4. データの例外

空欄の項目、想定より長い値、存在しない取引先コードなど、記録したときと違うデータが来るケースです。画面は変わっていなくても、入力が弾かれたり、想定外の画面に進んだりして止まります。

5. 動かす環境の変化

ブラウザの更新、画面の解像度や拡大率の変更、ロボット用アカウントのパスワードの期限切れなど、ロボットを動かす側の変化でも止まります。

止まることより困るのは「直せない」こと

画面の変更は、どんな自動化でも避けられません。現場で本当に困るのは、止まったあとです。

作った人しか直せない：ロボットの中身がわかるのは作った担当者だけで、異動や退職のあとは誰も直せない
止まったことに気づかない：誰にも知らせが届かず、処理されていない業務が数日後に見つかる
途中までの処理をどうするか：半分まで入力したところで止まり、残りを手作業で補うか、最初からやり直すかを判断しなければならない
全体を誰も把握していない：部門ごとに作られたロボットが、いくつあり、どれが止まっているのかがわからない

止まりにくくする工夫と同じくらい、止まったときにすぐ気づいて直せる仕組みが大切です。

止まりにくく、直しやすい自動化の設計

公式の連携があれば、画面操作より優先する

API、CSV のダウンロード、データ連携のサービスが用意されているなら、画面を操作するより変更に強く、速く、確実です。画面の自動操作は、ほかの方法がない業務に絞るのが基本です。サービスの利用規約で自動操作が認められているかも、あわせて確認します。

変わりにくい手がかりで対象を指定する

座標や画像より、要素の情報を使います。要素の情報でも、自動で振られる ID のように変わりやすいものより、「ログイン ID」のような画面上の見出しや役割で指定するほうが、改修の影響を受けにくくなります。

「待つ」と「確かめる」を手順に入れる

操作の前に、対象が表示されるまで待ちます。操作のあとには、期待した画面に進んだかを確かめます。確かめる手順があると、止まった場所と理由がはっきりし、誤った入力のまま先に進むこともなくなります。

例外と判断は人に回す

想定外のデータや、判断が必要な場面をロボットにすべて任せる必要はありません。条件に合わないものは人の確認に回す、登録の前に承認をはさむ、と決めておくと、ロボットが無理に進んで誤った処理をすることを防げます。

止まったら、すぐ知らせる

失敗したら担当者に通知が届くようにし、止まった画面のスクリーンショットとログを残します。何が起きたかを画面で確かめられると、原因の調査にかかる時間が大きく変わります。

途中からやり直せるように手順を分ける

手順をいくつかのステップに分け、止まったステップから再開できるようにします。完了したステップをもう一度実行しても問題が起きないようにしておくと、やり直しの判断が簡単になります。

手順を、誰でも読める形で残す

何のために、どの画面で、何をしているのか。手順が業務の言葉で読めれば、作った人以外でも直せます。変更の履歴が残っていれば、いつから動きが変わったのかもたどれます。

AI が画面を読んで操作する、という選択肢

最近は、手順を文章で書き、AI がその都度画面を読んで操作する自動化も使えるようになりました。「ログイン ID の欄に入力する」と書けば、AI が画面の中からその欄を探して入力します。座標や要素の名前を記録しないため、ボタンの位置が変わった、項目が一つ増えた、といった小さな変更では手順を書き直さずに済みます。

一方で、弱点もあります。

費用と時間：操作のたびに AI モデルを使うため、利用料がかかり、1 操作ごとに時間もかかります。大量の定型操作を高速に繰り返す業務は、従来の RPA のほうが向いています
確認の仕組みが必要：AI の判断は毎回同じになるとは限りません。登録や送信の前には、確かめる手順や人の承認を組み合わせます
大きな刷新には対応が必要：画面の流れそのものが変わる大規模な刷新では、手順の見直しが必要です
データの扱い：画面の表示内容が AI モデルの提供者に送られます。使うモデルと、送ってよい情報を事前に決めておきます
対象外のサイト：利用規約で自動操作が禁止されているサイトや、CAPTCHA（画像認証）があるサイトは対象外です

止まりやすい Web 業務は AI の画面操作に、大量で安定した操作は従来の RPA や API に、と使い分けるのが現実的です。

Kitewell での作り方

Descarty の Kitewell は、ここまでの考え方をもとに設計した業務自動化ソフトウェアです。

手順は言葉で書く：「ページを開く」「入力する」「確かめる」といった手順を並べると、AI が Chrome を操作します。パスワードは名前で参照し、AI には値を見せません
止まったら、止まった所から：失敗したステップはスクリーンショットとログとともに表示されます。修正したら、失敗したステップ以降だけをやり直し、完了したステップの結果はそのまま使います
会話で直す：止まったステップの画面から、AI アシスタントに原因を相談できます。修正の提案は差分を確認してから適用します
判断は人が承認する：どのステップにも承認を設定でき、誰がいつ判断したかが記録に残ります
知らせる：失敗や承認待ちを、Mac、メール、Slack、Microsoft Teams などに通知します

RPA との違いと移行の進め方は「脱RPA」で、業界・部門ごとの例は「活用例」で紹介しています。

まとめ

RPA は記録した時点の画面を前提に動くため、画面の変更、想定外の画面、表示の遅れ、データの例外、環境の変化で止まる
困るのは止まることより、直せない、気づかない、途中からやり直せないこと
公式の連携を優先し、変わりにくい手がかりで対象を指定し、待つ・確かめる・人に回す・知らせる・途中から再開する、を設計に入れる
手順を文章で書き、AI が画面を読んで操作する方法は、小さな画面変更に強い。費用、速さ、確認の仕組み、データの扱いを踏まえて使い分ける