Cached accessibility-tree control and code-enforced verification for design entry through a desktop application's user interface

ソフトウェアの世界には、人間がコンピュータと対話する方法と、機械同士が互いに通信する方法との間に、根強い隔たりが存在します。人間はグラフィカルなインターフェースを使用し、画面上に現れるボタンをクリックしたり、ボックスに文字を入力したりします。しかし、機械は多くの場合、視覚的なレイヤーを完全にバイパスして、基盤となるコードに直接コマンドを送信するという、直接的で構造化された言語を好みます。ソフトウェアにこの直接的な言語が欠けている場合、そのソフトウェアは自動化ツールにとって「ブラックボックス」となります。これは、ソフトウェアボットが画面上の人間の動作を模倣して反復的なタスクを実行するように訓練される分野である、ロボティック・プロセス・オートメーション（RPA）における共通の障害です。課題は二重にあります。第一に、ボットは複雑で変化し続けるウィンドウの風景の中で、正しいボタンやメニュー項目を見つけなければなりません。第二に、今行ったアクションが実際に機能したかどうかを知る必要があります。直接的な通信手段がない場合、ボットは本質的に盲目であり、クリックが正しい場所に当たったのか、あるいは期待通りに新しいウィンドウが表示されたのかを推測することしかできません。

ティアゴ・ミランダ・デ・レオという研究者は、Mozaik Enterpriseという人気のWindowsアプリケーションを使用して、特定の複雑なタスク、すなわちキッチンキャビネットの設計を自動化するシステムを構築することで、この問題に取り組みました。このソフトウェアは、外部プログラムが直接通信するための手段を提供していないため、研究者のシステムは、まさに人間が行うのと同様に、ユーザーインターフェースを介して完全に操作しなければなりませんでした。このシステムは、自動化の2つの主要な問題、すなわち「制御」と「正確性」を解決するように設計されました。制御を扱うために、システムはまずアプリケーションのインターフェース全体の構造をマッピングし、あらゆるボタンやメニューがどこにあるのかというメンタルマップを作成することに時間を費やしました。一旦このマップが構築されると、システムは探索をやめ、キャッシュされた座標リストに基づいて行動し、インターフェース要素の既知の位置を直接クリックしました。正確性を扱うために、システムはビジョンモデルを使用して設計図を「読み取り」、その後、コンピュータが要求通りに実際に構築できたかどうかを検証するために、厳格に記述された事前定義のコードルールを使用しました。最終的な判断を下したのは人工知能ではなく、コードでした。

この実験の結果は、有望なスピードと重大な限界の両面を示しました。システムはアプリケーションのインターフェースのマッピングに成功し、約1,000個の異なる要素を特定し、そのうち約600個の座標を保存しました。システムがソフトウェア内の異なるタブを切り替えようとした際、タブを探すこととキャッシュされた場所をクリックすることの差は歴然でした。標準的な方法でタブを見つけるには29秒から57秒かかり、そのプロセスではアプリケーションの内部構造を毎回検索する必要がありました。しかし、一度場所がキャッシュされると、同じタブへの切り替えは3分の1秒未満で完了しました。これは、安定した環境においては、毎回探し回るよりも、物事の場所を記憶しておく方が遥かに効率的であることを示しました。

しかし、システムの適応能力は脆弱でした。キャッシュされた位置は、マップ作成時にウィンドウのサイズと形状が正確であったことに紐付けられていました。もしウィンドウのサイズが変わったり、画面解像度が異なったりすれば、キャッシュされた座標は間違った場所を指すことになり、システムは失敗します。研究者は、システムが自動的に自己修復できないことを発見しました。レイアウトが変化した場合、マップ全体を最初から作り直さなければなりません。さらに、システムはクリックが実際に機能したかどうかを確認しませんでした。画面を再度見ることはキャッシュの目的を損なうため、システムはアプリケーションが応答しなかったとしても、成功したと報告してしまいます。

設計図と一致しているかをチェックするシステムの検証部分は、理論上はうまく機能しましたが、実践においては困難に直面しました。システムは、データに意図的にエラーを注入した500件の合成ケースを用いてテストされました。これらのテストにおいて、コードは欠落したキャビネットや誤った家電製品のタイプといった意図的なエラーをすべて正しく特定し、誤報を出すこともありませんでした。要求事項に合致しない設計を、システムは正常に拒否しました。しかし、実際の未スクリプトのキャビネット製作試行に対してシステムをテストしたところ、結果は不明瞭でした。フルデザインを構築するための5回の記録された試行はすべて初期段階で失敗し、最終製品を検証する前に停止しました。ログによれば、システムは構築すべきキャビネットの数を正しく数えることができず、即座に停止したことが示されました。研究者は、システムが多様な現実世界の図面に対してテストされておらず、記録された数少ない実世界の試行は不完全であったと指摘しました。

この研究はまた、このプロセスにおける人工知能の役割を浮き彫りにしました。システムは設計図を解釈するためにAIモデルを使用しましたが、構築が成功したかどうかの最終決定はコードに委ねられました。この分離は意図的なものでした。コードが厳格な門番として機能し、AIの解釈がハードルールに照らしてチェックされるようにするためです。研究者は、AIは図面を記述できるものの、結果を自ら判断させることは信頼できないことを発見しました。システムは、もしAIが間違いを犯しても、コードがそれを検知できるように設計されていました。しかし、記録によれば、現実世界の数少ない試行において、システムはAIの記述が最終結果と比較される段階に到達する前に失敗していました。

結局のところ、この研究は、機械と直接話すことを拒むソフトウェアを自動化する際に何が可能であるかについて、明確な展望を提供しています。インターフェースを一度マッピングし、その記憶に基づいて行動するというアプローチは高速で効果的ですが、脆いものでもあります。それは、ソフトウェアがマップ作成時と全く同じ見た目である限りにおいてのみ機能します。システムは、コードによるチェックが結果を確実に検証できることを証明しましたが、同時に、インターフェースの変化に対処したり、エラーから回復したりする堅牢な方法がなければ、自動化が動的な環境において人間を置き換えることはできないことも示しました。研究者は、この手法は特定のバージョンのソフトウェアと特定のマシンに対しては機能するものの、あらゆるアプリケーションに対する一般的な解決策ではないと結論付けました。このシステムはあくまで概念実証であり、直接的なアクセスがなくても自動化が可能であることを示していますが、同時に、そのようなシステムを現実世界で十分に堅牢にする難しさをも浮き彫りにしています。