RPAに使われている技術は元々違う目的のためだった！？

大抵のRPAは人間の操作を模倣して画面操作を行うのに、ユーザーインターフェイスの要素分解を行っています。これは、画面に表示されているボタンやテキストボックスといった「ユーザーコントロール」を要素として認識して、コントロールに対して指令を出す方法です。しかし、これを可能にする技術は、もともとRPAとは違う目的のために作られていました。その内容についてみてみましょう。

目次

健常者でなくても使えるコンピュータを目指す！

パソコンが一部の人のものだけでなくなり、一般に普及してきた段階で、「万人に使いやすいコンピュータ」が仕様として求められるようになってきました。「万人に使いやすい」というのは専門家でない素人でも簡単に扱えるということもありますし、子供からお年寄りまで、わかりやすい簡単なユーザーインターフェイスであること (「ユーザビリティ」が高いこと) が求められました。

また、それだけではなく視力が弱かったり聴力が弱い、手足が不自由といった障碍者の人々でも扱えるような「情報の利用におけるバリアフリー化」を行うための様々な機能が必要になってきました。2006年には「障碍者権利条約」も採択され、アクセシビリティの実装が法律でも義務化されている国も出てきました。

「アクセシビリティ」という考え方

このような「情報の利用におけるバリアフリー化」を促進して利用しやすい製品をつくることを「アクセシビリティに対応する」と言います。これには、単純に「読みやすいフォントを使う」「配色を適切に行う」というものから、「支援技術 (Assistive Technology、AT)」と呼ばれるツールや技術を使ってパソコンにアクセスすることまで含まれます。たとえば、以下のようなツールや方法があります。

• スクリーン拡大鏡
• スクリーンリーダー (テキスト読み上げ)
• ハイコントラスト
• 点字ディスプレイ
• キーボードのみからのアクセス (マウスを使わない)
• マウスジェスチャー、ジョイスティック、トラックボール
• 音声による指示

これらは、ウェブでもソフトウェアでも、画面要素を認識可能、操作可能、理解可能、そして堅牢にする方法をベースに実装されます。

スクリーンリーダーはどうやって画面の文字を読んでいるのか

さて、ここまで来てピンときた方もいるのではないでしょうか。つまりは、「アクセシビリティを確保するためにはパソコンで動いているアプリケーションを他のソフトウェアから認識して情報を読み取ったり操作したりすることができる必要がある」ということになりますね。

スクリーンリーダーが正しく動作するには、ソフトウェアでもウェブページでも、特定のルールに従って画面要素の意味とテキストの中身を抽出できる必要があります。これを行うには、スクリーンリーダーはOSにしかるべきステップで「問い合わせ」を行い、結果を返してもらい、その情報を元に処理をすることになります。

これを行うには、OSやそのうえで動くアプリケーションが、スクリーンリーダーからの「問い合わせ」に適切に対応、回答できるように標準化された方法を実装している必要があります。条約が締結されたり法律で決まっている国もあるくらいですから、この標準化はOSでもカッチリ行われており、その上で動くアプリケーションも「基本」きちんと対応しています。この問い合わせ手段のことを「アクセシビリティAPI」と言います。

RPAにも使える、画面のUI要素分解を支える技術

ここまでアクセシビリティの話でしたが、このようなバックグラウンドがあるため、実はパソコンでも画面操作を使った処理の自動化を精度よく行うことができます。パソコン上で2006～2007年をターゲットにいろいろな標準化が行われてきました。このころはちょうど、「UI Automation」と呼ばれるアクセシビリティAPIが、当時現役のあらゆるバージョンのWindowsや.NET Frameworkに対して利用可能となりました。

また、遡ること10年、前身となるアクセシビリティAPI「MSAA」がリリースされたり、ウェブページから情報を適切に抜き出すための「DOM」の初版がリリースされたりしています。

RPAによる画面操作、キーボード操作では、まさにこれらのAPIや標準を自動化の目的で利用していることになるのですね！このようなアクセシビリティに関する世界的な動きがあったから、パソコンの自動化もより便利になった、と言ってもよいかもしれません。