はじめに

RPAに限らずパソコンを操作する時の前提として、そのアプリケーションのウィンドウがアクティブ¹状態になっている必要があります。

ウィンドウを最小化したままではキーボードやマウスでアプリの操作ができないのは当然ですが、画面が表示されている場合でもデスクトップに複数のウィンドウを表示していたりすると、時々「あれ、入力できないな？²」と言うことがあったり、ボタンをクリックしても反応しなかった³ということありませんか？

私はブラウザを左右に2つ並べて作業することが多いのですが、時々「Ctrl＋W」操作で そっちじゃない 方のタブを閉じてしまうことがあります。

RPAは通常__必要なアプリを順番に操作する__ため、人と違い複数アプリで同時並行に作業することも、違うアプリを操作してしまうこともないのですが、まれにロボットがアプリを見失って空振ることがあります。

ではそれはなぜ起こってしまうのか、回避する方法はないのか、順を追って見ていきましょう。

「ウィンドウがフォーカスされる事によってアクティブになる」という意味でどちらも特に区別せず同意として使っています。

DAは不安定？

以前⁴はそういうこともありましたが、v10.4以降で__DAが不安定と感じたことはありません。__
v10.4 を使い始めた当初は確かに何回かタイムアウトエラーで止まることもありましたが、原因を調査すると旧バージョンで仕込んだ多くの固定のWait（”特定の秒数が経過したとき”）によるタイミング問題が殆どで、適切にガードチョイスを修正したことで解消しました。

とはいえガードチョイスの仕組みを理解して使っている人は少ないようで、提供側にはこの辺りのサポートをより厚くお願いしたいですね。

一方でアプリ／OSの特定の挙動については__不安定__が不可避なものもあるので、どんなことが起こり得るのかを知っておくことで適切に対応していければと思います。
（解決策はいつも技術によるものだけではないのだよ。）

アプリ外のシステム通知によりフォーカスが外れてしまうケース

ロボット専用の端末が用意されている場合にはほとんど意識する必要はないケースですが、業務PCと兼用で使用している場合にはシステム側の通知情報が画面前面に飛び出してきたり、管理用のプログラムが起動して一瞬マウスのフォーカスを奪ったりと強制的にアプリを非アクティブな状態にしてしまうことがあります。

当然このようなタイミングでロボットが動いていると、マウス操作やキー操作が空振る原因になるとともに、エラーが発生したあとで原因を探ろうと思っても、まさにシステム通知によりフォーカスが奪われる瞬間をリアルタイムで見ない限りは 不安定だなぁ という結論以外に上司やエンドユーザーへ説明をするのは難しいかもしれません。

アプリの特性によりフォーカスが外れてしまうケース

これについてはロボット専用端末を用意してもアプリ自体の特性なので__起こりうること__として対応する必要があります。

以下は実際に遭遇したケース。挙動が特徴的だなぁという感じもしますが、古いSSOの仕組みとしてそういう会社も多いのでは？とか思います。

1. IEでポータルログイン
2. ポータルからアプリを選択
3. 新しいウィンドウが立ち上がり起動処理開始（プログレスバーを表示するウィンドウが併せて起動）
4. 起動処理の中で何回かウィンドウが現れたり、消えたり
5. 起動処理が終了してアプリのトップ画面が表示。

ロボットの作りとして単純に「アプリの起動」→「ガードチョイスで画面表示の確認」→「メニュー選択」と進めていましたが、どうも時々不定期で「メニュー選択」を空振ってしまう。

デバッグしながら注意深く見ていく中で、__エラーになる回はアプリ起動後にトップ画面ウィンドウがアクティブになっていない（タイトルバーが下のような状態になっていた）__ことに気づきました。

なかなか見落とすレベルですが、ウインドウがアクティブ（操作可能な状態）な時は下のようにタイトルバーの文字が濃い色で表示されます。

フォーカスが外れてしまった時の対応方法

ウィンドウからフォーカスが外れ非アクティブな状態になってしまうと、ロボットに限らずマウス操作やキーボード操作などをアプリが受け付けられないため（別のアクティブになっているアプリケーションに対し入力イベントが向くため）、必ずウィンドウにフォーカスを当ててアクティブな状態にする必要があります。

前段でも触れたように__フォーカスが外れて空振ってしまうのは結構稀なケース__なので画面操作の前提として考えるのは大げさ。実際にこのような事象に遭遇したときの対応方法として頭の片隅に置いておけばいいレベルだと思います。

フォーカスが外れた状態では必ずロボットが空振りするのかというとそれは違い、多くのアプリはフォーカスが外れていてもロボットが実行時にフォーカスして正常に動作させます。
実際の空振りの状態を動画に撮ってこの記事に載せようと色々と非アクティブ状態を作り出して実験しましたが、私が操作できるアプリにいおいては全て問題なく実行時にフォーカスを取得して正常に動作してしまいました。。。

1. ウィンドウのタイトルバーをクリックしてから画面操作をする

v10.7 までのDAを使う場合にはこの方法になります。
ただし不意にウィンドウが最小化されてしまうような場合にはタスクバーをクリックしてウィンドウを前面に表示するなど別の方法を取る必要があります。
（そんなエクストリームな状況は聞いたことがないけど。）

2. アプリケーションレベルで有効なフォーカスアクションを使う

v11.1 から使えるようになった機能で、オンラインマニュアルを引用すると以下のように説明されています。

Desktop Automation ステップアクション > フォーカス
これは、選択したアプリケーションをフォーカスするアプリケーションレベルのステップです。このステップを使用して、たとえば、最小化された状態で開始したアプリケーションを最前面に表示することができます。このステップは、リモートデバイス上のアプリケーションで使用できます。

開いているウィンドウのタブから右クリックで「アプリケーションアクション」>「フォーカス」と選択出来ます。

マニュアルの記述を見ると、フォーカスアクション自体は今回の使い方用というよりは最小化したアプリケーションウィンドウを表示するためのアクションのようですね。

まとめ

今回の例は非常に稀なケースを取り上げてみました。
しかし非常に稀なケースゆえに、運悪くそういった事態に遭遇すると参ってしまいます。

ロボットは気合で作るのではなく、教養として仕組みを理解したうえで誰にでも作りやすい。そうなってほしいですね。

続き（コンポーネント編）はこちら

関連記事を追加しました。

アプリケーションのウィンドウが画面最前に表示され他状態で、かつカーソルが点滅しているなど入力可能な状態を言います。 ↩
同時に開いている別のアプリにキーボード操作の命令が送られていて反応しなかったり、違うアプリの方に文字を書き込んでしまったり。 ↩
アプリケーション内のボタンに対するクリック命令ではなく、アプリケーション自体に対するクリックイベントとして処理され、単にクリックしたアプリにフォーカスが移るだけ。など。 ↩
v10.3 の前半バージョンまでは DAS に不具合があり、長時間の連続稼働やCPU負荷の高いPCでの実行の際にまれにDASのアイコンがグレーになってしまいサービスがダウンしてしまうこともありましたが、v10.3.0.7 で修正されて以降は動作もかなり安定しており、長時間の実行でもDAがダウンしてしまうなどの不安定な事象は一切発生していません。 ↩