JP2015005245A - 画像認識による自動操作装置、その方法及びプログラム - Google Patents

Abstract

【課題】操作対象ＡＰや適用対象ＰＣが変化しても対応可能な自動操作エージェントを提供すること。
【解決手段】画像領域分割エンジン１２２を用いて画像領域特定処理を行う画像認識部１０７によるユーザ操作のアクション単位の処理結果を、オブジェクト特定処理を行うコントロール制御部１０１によるユーザ操作のアクション単位の処理結果とともに、スクリプト同期部１１１によりユーザ操作のアクション単位で記録し、当該記録に従って画像認識部１０８及びコントロール制御部１０２を動作させてユーザの操作を再演させ、操作対象を特定結果照会部１１２によりユーザ操作のアクション単位で突き合わせて相互チェックすることで、操作対象ＡＰや適用対象ＰＣの変化による影響を検出する。
【選択図】図２０

Description

本発明は、自動操作エージェントが、複数の設定の異なるコンピュータ（ＰＣ）やＧＵＩプラットフォームで実行される場合、及びバージョンアップにより部分的に変更が加えられた操作対象アプリケーション（ＡＰ）に適用される場合の課題を、画像認識技術を用いて解決するものであり、シナリオや認識ルールを手作業で大幅に変更することなく、これらの差異に適応するための技術に関するものである。

なお、自動操作エージェントは、ＰＣ上でのユーザ（オペレータ）の操作内容をシナリオとして記録・保存するとともに、当該シナリオを開き・再生することで同じ操作内容を後から何度も実行するプログラムである。

≪従来技術≫
＜オペレータエミュレーション方式の説明＞
自動操作エージェントのシナリオ記録・再演の方式として、オペレータエミュレーション方式とオブジェクトアクセス方式との２つに分けられる。

（従来型オペレータエミュレーション方式の定義）
従来技術では、ＰＣのＯＳやウィンドウマネージャなどの入出力デバイスサービスが提供するＡＰＩを介して、ユーザのマウス操作やキーボード操作の入力イベントをフック（受信）及びポスト（送信）することにより、ユーザの操作内容の取得やそれと同じ内容の操作の実行を行っている。これを従来型のオペレータエミュレーション方式と呼ぶこととする。

（操作対象の指定方法に関する従来技術）
上記方式では、ユーザ操作のマウス座標がデータ値として内部的に流通するが、これはスクリーン上の位置を示しているにすぎず、マウスポインタが指しているＧＵＩ要素をエージェントが知るためには、ＧＵＩプラットフォームが提供するＡＰＩを介して、座標値からオブジェクト参照を得る必要がある。

すなわち、オペレータエミュレーション方式における監視内容は、ＰＣとユーザの境界を物理的に構成する入力デバイスの状態であり、ユーザが操作対象として意図したＧＵＩ要素には直接的に対応していない。シナリオにはマウスポインタの座標値が記録され、シナリオに記録された情報を再演する場合、その値をもとにマウス操作を再現するのみである。

エミュレーション操作の実行は、スクリーン上に表示された画像内容、すなわちＧＵＩ要素がどこに位置しているかとは無関係に、スクリーン座標上の位置に対してマウスクリックなどの操作を行う。このため、ＧＵＩ要素の配置が記録時と再演時で変化してしまうと、同じＧＵＩ操作とはならない。

（ウィンドウ内相対座標による代替とその課題）
ウィンドウのサイズを変更しない前提であれば、ウィンドウ左上からの相対座標をマウスクリック位置として記録・再演することにより、ＧＵＩ要素に操作しているのとほぼ同じエミュレーション操作を実行できる。しかしこれでは、ＧＵＩ要素のウィンドウ内配置が記録時と再演時で異なる状態が発生してしまうと、破たんしてしまう。すなわち、本来、ユーザが意図したＧＵＩ操作対象とは関係ない位置や要素をクリックするなど、実行時の状況によっては、本来のＧＵＩ要素に対する自動操作ではなく、意味のない対象に対して動作を実行することがある。

実行時のＧＵＩ要素の位置のずれ、すなわち空間的なずれに柔軟に対処するためには、再演時の各アクション実行の瞬間ごとに、実際の配置に基づいてＧＵＩ要素を識別し、その位置の変化をフィードバックすることが必要である。このようなフィードバックのもととなる情報が存在しないことが、従来型オペレータエミュレーション方式の課題である。

＜オブジェクトアクセス方式の説明＞
（オブジェクトアクセス方式の定義）
オブジェクトアクセス方式は、上記オペレータエミュレーション方式の課題を回避する観点で有用な技術である。

従来技術では、ＰＣのＯＳ、ウィンドウマネージャ、ＧＵＩライブラリ、ＷｅｂブラウザなどのＧＵＩプラットフォームが提供するＡＰＩを介して、ＧＵＩツリーのオブジェクトへのアクセスを行うことにより、ユーザ操作の対象となっているＧＵＩ要素の状態の取得やそれに対する操作の再演を行っている。これをオブジェクトアクセス方式と呼ぶこととする。ＧＵＩプラットフォームの実装に依存する方式ではあるが、ＧＵＩ要素の表示位置のずれや更新タイミングのずれに関係なく、操作の記録・再演が行えるため、上記課題を制限付きながら回避できる。

（オブジェクト要素の指定方法に関する従来技術）
上記方式では、ＧＵＩ要素をハンドル番号やオブジェクト参照（ポインタ）などのプログラム内部で流通するデータで表し、ＡＰＩ引数に使用することで対象にアクセスするが、これらの値は当該プロセスが終了して新たに起動した場合、すなわち他のプロセス実行時には同じ値にならない。つまり当該プロセス実行中以外ではユニーク性が保証されないため、自動操作エージェントが利用するには、そのままではシナリオに記録して後で再生に使用することができない。

プロセスに関係なく不変なＩＤとして流通する値があればそれを使用することが望ましいが、ＯＳ、ウィンドウマネージャ、ＧＵＩライブラリ、Ｗｅｂブラウザのいずれにおいても、そのようなＩＤの統一仕様は存在しない。アクセシビリティの観点から、推奨仕様として規格化・標準化をめざしているものはあるが、実際にはオプショナルな扱いであるため、適用対象のアプリケーションの開発者が意識して提供していない限りはエージェントでそれを利用できない。

以上のように、自動操作エージェントを任意の対象アプリケーションに適用するためには、汎用的に利用できるＧＵＩ要素のＩＤが明示的に存在しないため、それに代わるデータを生成・使用するための技術的な工夫が必要である。

＜特定フィーチャー、特定処理の説明＞
（特定フィーチャーの定義）
このため、一般に自動操作エージェントは、不特定多数のアプリケーションを対象に連携する方法として、ある限定的な条件のもとにおいて異なる実行期間でもユニーク性が保証されるようなデータ（単数又は複数のデータ値の組み合わせ）を生成（適用対象アプリケーション内の操作対象ＧＵＩ要素の属性から取得、あるいは周囲との関係から取得）し、シナリオに記録している。ここでは、これを「ＧＵＩ要素の特定を目的としたデータ」と位置づけ、特定フィーチャーと呼ぶことにする。特定フィーチャーの概念は、オブジェクトアクセス方式か、オペレータエミュレーション方式かに関係なく、上位の概念を表すものとする。

（特定処理の定義）
特定フィーチャーをもとに操作対象を特定する処理としては、一般に複数種類の手法が考えられる。以降では、オブジェクトアクセス方式のための当該処理をオブジェクト特定処理と呼び、詳細に説明する。一方、オペレータエミュレーション方式のための当該処理を画像領域特定処理と呼び、詳細は別途説明する。ここでは、これらを総称して特定処理と呼ぶこととする。

（オブジェクト特定処理の従来技術）
オブジェクト特定処理においては、特定フィーチャーに相当する従来の技術として一般的に２つの方法が用いられている。

（キャプション特定法の定義）
１つはＧＵＩオブジェクトの「キャプション」属性の文字列値で識別する方法である。キャプションとは、ボタンのタイトルやウィンドウのタイトルなど、ＧＵＩ要素がスクリーン上に表示されるときにそこに含まれる文字列で、ユーザが他のＧＵＩ要素との区別をスクリーン上の表示をもとに行う場合の手がかりとなる情報である。このため、キャプションを用いることで、ユーザには分かり易い特定フィーチャーが得られるが、そのユニーク性は基本的に保証されず、特定のアプリケーションやウィンドウにおける特定のＧＵＩオブジェクトに対して使用される。理由は後述する。ここではこれをキャプション特定法と呼ぶ。

（コレクション特定法の定義）
特定フィーチャーに相当するもう１つの方法は、ＧＵＩオブジェクトのコレクション、例えば所定の方法でオブジェクトを列挙したリストをもとに、その中の何番目に位置するか、により識別する方法である。ここでのリストは、ＧＵＩプラットフォームに依存したオブジェクト間関係を参照して得られるもので、例えばWindows（登録商標）のＧＵＩの場合、GetAllControls()によって得られるオブジェクトリストのことである。前記同様、このユニーク性も基本的に保証されず、限定された条件下で使用される。ここではこれをコレクション特定法と呼ぶ。

＜キャプション特定法の具体例とその限定条件＞
以降では、従来技術において、特定フィーチャーがどのように限定的に用いられるか、具体例をもとに説明する。

（キャプション特定法の具体例とその限定条件）
キャプション特定法についてユニーク性が破たんする例としては、複数のウィンドウのそれぞれに「ＯＫ」というボタンが存在する場合が考えられる。この場合、特定のウィンドウ種類に限定して見ればユニークに特定できることが多いため、ウィンドウを他の特定フィーチャーで指定した上で、その内部のＧＵＩ要素に対しての識別に用いることが行われる。注意すべきなのは、指定したウィンドウ配下であっても特定のキャプション以外はユニーク性が保証されない点である。ここでは「ＯＫ」以外のキャプション、例えば「設定」「参照」などは、ファイル名を入力するテキストフィールドの横にそれらが配置されるＵＩデザインのパターンとして、１つのウィンドウ内で複数個所で現れることで、同じキャプションの要素が複数存在する場合がある、ということである。

これと別の例としては、ウィンドウタイトルの一部が現在、そのウィンドウ内で編集しているドキュメント名（ファイル名やＷｅｂページタイトル）となっている場合が考えられる。この場合、特定のアプリケーション種別を指定した上で、その構成要素であるウィンドウのタイトル文字列に対する正規表現マッチ（例えば、Wordの場合、$1をドキュメントファイル名文字列として、"$1- Microsoft（登録商標） Word"となり、InternetExplorer（登録商標）8の場合、$1をページタイトル文字列として、"$1 - Windows Internet Explorer"となる）により識別することが行われる。

注意すべきなのは、指定したアプリケーション種別であっても特定の命名則に従うドキュメント名以外はユニーク性が保証されない点である。ここでは、異なるフォルダに存在する同名ファイルや異なるサイトの同名タイトルページの存在を許すような命名則では、同じタイトルの異なるウィンドウが複数存在する場合がある、ということである。

もちろん、これらの制限をしても、実装依存でユニーク性が破たんする場合があることは大前提となっている。例えば、ボタンの例では、当該ウィンドウの仕様がバージョンアップにより変更される場合をいくらでも（任意に）仮定できる。

具体的には、必要なデータが全て入力されるまでキャプション文字列が「ＯＫ」ではなく「やり直し」と設定され、データが入力完了した時点で動的に変化するなどである。また例えば、IE6の場合、タイトル文字列が"$1 - Microsoft Internet Explorer"となるためにIE8のそれとは異なってしまっている。これは、ウィンドウタイトルもウィンドウオブジェクトのキャプションととらえると、InternetExplorerのバージョンアップにより、キャプションまわりの仕様が変化した場合に相当する。このように、キャプション特定法はもともと適用対象の実装依存を部分的に受け入れているということである。

以上をまとめると、特定するＧＵＩオブジェクトの範囲は、アプリケーション、ウィンドウ、ＧＵＩ要素などのＧＵＩツリーの様々なノードのサブツリーとして指定するとともに、識別対象は「ＯＫ」といったボタンキャプション文字列や「"$1 - Windows Internet Explorer"」といったウィンドウタイトル正規表現として特定のものに限定することが行われる。そしてこれらは、識別対象のＧＵＩ要素が特定のウィンドウ上の特定のキャプション文字列の場合だけ適用可能、あるいはキャプションに相当する実体が特定の命名規則のドキュメント群の場合だけ適用可能、あるいは適用対象のアプリケーションがそのバージョンの違いなども含めて特定の実装内容の場合だけ適用可能、といった限定条件が付随する。

このように、部分的に実装内容依存性・実行時依存性を受け入れながら、ユニーク性が保証される条件下で使用するのが、従来の方法の一般的な位置づけである。

＜コレクション特定法の具体例とその限定条件＞
（ユーザ操作に関係した限定条件の例と実行時依存性の定義）
コレクション特定法についてユニーク性が破たんする例としては、ウィンドウを開くことによってそのタイミングではじめてウィンドウ上に存在するＧＵＩ要素（ＧＵＩオブジェクト）の生成が行われる場合がある。なぜならば、ユーザがウィンドウを開いた順序によって、内部的なＧＵＩオブジェクトのリスト上での位置が異なってくるからである。これは、実行時のユーザ操作の内容の違いによって特定フィーチャーの不変性が破たんする場合といえる。同様のことは、タブパネルを選択したことによってはじめてその内部に存在するＧＵＩ要素の生成が行われるなどでも発生し、ＧＵＩツリーの任意の階層に現れる。また、ある動作ボタンを押すことによってそのタイミングでアプリケーションの内部処理により、ウィンドウやＧＵＩ要素などのＧＵＩオブジェクトの生成・移動・消滅が動的に行われる場合がある。

これらはユーザ操作の順序に依存したものであるが、他にもアプリケーションをとりまく外部条件、例えばコンフィグレーションの設定内容や、データベースの検索結果、ネットワークの通信時間などに依存して、ＧＵＩオブジェクトが動的に再配置される。これは、実行時の状況の違いによって特定フィーチャーの不変性が破たんする場合といえる。前記のユーザ操作の内容の違いも当該の実行時状況の違いも、外部環境の違いという観点では同じに分類される。

ここではこれを実行時依存によるユニーク性の破たんという意味で、実行時依存性と呼ぶ。

（ＧＵＩ仕様に関係した限定条件の例と実装内容依存性の定義）
これとは別の例としては、アプリケーションをWindowsXP（登録商標）上で実行していたときと、Windows7（登録商標）上で実行していたときとで、ＧＵＩプラットフォームの仕様が異なるために、内部的なＧＵＩオブジェクトの生成順序や生成個数が異なる場合がある。これはアプリケーションが同じ実行ファイルであっても、ＧＵＩプラットフォーム内での初期化処理の仕様やＧＵＩツリーの詳細な構造が異なることにより発生する。

ＧＵＩツリーの詳細において構造が異なるとは、ボタンやテキストフィールドなど可視オブジェクトとは別に、それらを配置するパネルとその親パネルの間に、内部処理のために必要な不可視なオブジェクトが新しいＧＵＩプラットフォームで導入されるなどを指す。これらの違いは、実行時依存性がなくても発生するものである。その意味では、アプリケーションのマイナーバージョンアップ等により、内部的な初期化順序が変わる、あるいは新たなＧＵＩオブジェクトが追加されるなどで、ＧＵＩオブジェクトのリスト上での位置が異なってくる場合も、同じに分類される。

これらの影響は、ＧＵＩオブジェクトのリストの前方で発生し、後続の順がずれると全体に及ぶが、リストの後方で発生すると、ごく一部に抑制される。この意味では、アプリケーション依存であり、これは、アプリケーションの実装内容の違いによって不変性が破たんする場合に分類される。

ここではこれを実装内容依存によるユニーク性の破たんという意味で、実装内容依存性と呼ぶ。

（コレクション特定法の限定条件のまとめ）
コレクション特定法は、GetAllControls()のように、特定のＧＵＩオブジェクト配下のツリーノードを集めるため、特定のウィンドウ上のＧＵＩ要素を識別するために用いられるのが一般的である。

これは、従来技術において、仮に、ＧＵＩツリー上の上位の要素を指定すると、スクリーン上のＧＵＩオブジェクト全てを範囲にできるが、ユーザの操作やＧＵＩオブジェクトの生成・移動・削除がどこかで発生する可能性が高くなるため、リスト上の順序がずれるなど、影響が広範囲におよび、識別の基準として使いものにならない。また、指定するウィンドウが非常に多くのＧＵＩ要素を含む場合も同様である。従って、GetAllControls()で集める範囲はできるだけ狭くする必要がある。

また、集める範囲を狭くするだけではなく、対象の実装内容に応じて、そのツリーの所定の範囲のみを操作対象とし、動的変化やバージョンアップの影響を受け難いコレクションを選んで適用することが行われる。すなわち、ＧＵＩツリー上の動的変更が行われることが、実装内容から分かっているＧＵＩクラスを避けてそれ以外を特定するのであれば、コレクションから操作対象のＧＵＩクラスだけを抽出して絞り込むことで、不変性が保たれる。

前記の実行時依存性や実装内容依存性が破たんしない範囲を指定して（できるだけ下位ツリーを選択する、あるいはＧＵＩクラスでさらに限定するなど）、限定的に用いるという点では、コレクション特定法もキャプション特定法と同じである。

＜画像利用の説明＞
（キャプション特定法の課題）
キャプション特定法の前記のような使用方法において、識別対象から除外せざるを得ないケースは実用を考えると意外と多い。具体的には、まず、もともと固定的なキャプションを持たないテキストフィールドやコンボボックスなどを識別することができない。また、先に述べたように、同じキャプションの要素が複数存在する場合や、キャプション文字列値が動的に変化する場合や、アプリケーションのバージョン違い等で仕様が変化した場合など、限定条件から外れる場合は、識別することができない。

自動操作エージェントによりＧＵＩ操作の自動化を幅広く行おうとした場合、上記に該当する箇所に遭遇する可能性は高くなる。これはキャプション特定法の実用上の課題となっている。

（コレクション特定法の課題）
コレクション特定法の前記のような使用方法において、限定条件から外れているか（違反していないか）どうかがユーザからは分かり難い。具体的には、ＵＩの見た目からＧＵＩオブジェクトのツリーを正確に把握することはできず、また特定処理の内部の動きがユーザには分かり易くイメージできないため、シナリオに記録された特定フィーチャーが意図したＧＵＩ要素を特定できるかどうか、実際に処理を動かしてみないと分からない。

自動操作エージェントを幅広いエンドユーザが自分自身で使用する場合、上記のようなブラックボックスとしての側面は障害となる。これはコレクション特定法の実用上の課題となっている。

（オブジェクト特定処理の課題）
以上をふまえると、オブジェクト特定処理に共通の課題として次のことが考えられる。一般にユーザはスクリーン上に出力された画像内容を視覚的にとらえ、ＧＵＩ要素の画面上の幾何的な配置関係によって複数の要素を識別している側面がある。そこでは、実行時依存、実装内容依存で、ＧＵＩ要素の生成順序や、内部的なオブジェクト参照リスト、キャプションの重複状況などが変化しても、視覚的に位置関係が変わらなければ、同じ要素と識別されると考えられる。ＧＵＩレイアウトがこのようなユーザ側の傾向を前提としてデザインされる点は、どんなアプリケーション、どんなＧＵＩプラットフォームでも共通していると考えられ、普遍的な性質である。キャプション特定法・コレクション特定法をはじめとする一般的なオブジェクト特定処理では、このようなＧＵＩ要素の配置関係についての普遍的な性質を利用したフィードバックは存在しなかった。

（オペレータエミュレーション方式とオブジェクトアクセス方式の併用）
従来の技術では、ユニーク性が保証される範囲で限定的にオブジェクトアクセス方式を用い、これが使えない操作部分については、オペレータエミュレーション方式を用いるのが一般的である。２つの方式が混合したシナリオの記録・再演が可能なエージェントフレームワークを提供することで、適用対象の汎用性と操作内容の実用性が高くなる。しかしながら、要求される汎用性や実用性のレベルが高くなると、オペレータエミュレーション方式であっても、各種限定条件や実行時依存性、実装内容依存性の制限は、相対的に重要な課題となってくる。

（画像をもとにした操作対象特定（画像領域特定処理）の必要性）
もともと従来型オペレータエミュレーション方式では、ユーザからＰＣへの入力だけが扱われており、ＰＣからユーザへの出力が利用されていない。すなわち、オペレータエミュレーション方式における、特定フィーチャーの実現方法は従来技術としては存在していないことを意味する。一般に、ユーザにとってＰＣからの出力として、スクリーンに表示される画像内容が最も重要である。ユーザと同じように、画像内容から、そこに現れているＧＵＩ要素を識別したり、逆にシナリオに保持されている情報から画面上のＧＵＩ要素を特定したりすることができれば、実行時依存性だけではなく実装内容依存性の観点でも有用である。

以下では従来技術による具体例を説明する。

（画像認識の応用の従来技術による具体例）
従来技術では、ＰＣスクリーン上に描画されたＧＵＩ要素を画像テンプレートマッチングなどの画像処理技術によって、その存在や位置を特定する方法が用いられている。これによると、適用する場面や状況が好ましい場合（限定条件の範囲内）であれば、基本的に実装依存性に影響されずに、スクリーン上のＧＵＩの見た目に基づいて複数のＧＵＩ要素を見分け、それが描画される矩形領域上でのマウス操作を通してＧＵＩ操作が可能である。限定条件の詳細については、後述するものとして、まずは具体的な処理方法について説明する。

画像テンプレートマッチングを応用する場合は、一般的に、操作記録時に実際の適用対象アプリケーション上のボタン要素のイメージデータをキャプチャし、得られたデータをテンプレートとして指定する方法が用いられる。操作再演時に当該アプリケーションのウィンドウのイメージデータをキャプチャし、得られたデータを比較対象イメージとして指定するとともに、テンプレートマッチングアルゴリズムにより、このイメージ上から記録時のボタン要素と同じ画像部分の相対座標値を取得することで、当該要素の識別・特定が可能である。

（画像領域特定処理の定義）
このように画像内における座標値により、ＧＵＩ要素の識別・特定を行う処理は、実際にはＧＵＩプラットフォーム実装に依存するために、適用箇所ごとに対応が必要となる。ここでは上記処理を一般化した方式を画像領域特定処理と呼ぶ。画像領域特定処理は、ユーザが目でスクリーン上の描画内容を認識し、操作対象のＧＵＩ要素が描画されている領域にマウスポインタを移動する操作に相当する。当該のマウスポインタ位置、すなわち画像上の領域を対象として、クリックする操作をエミュレーション実行することで、当該の領域を占めるＧＵＩ要素に関連づいた操作（例えば、ボタンであればボタンプッシュアクションなど）を行うのと同じ過程を、ソフトウェア的に実行可能とする。

（適応型オペレータエミュレーション方式の定義）
従来型のオペレータエミュレーション方式は、操作ログとして得られたマウス入力の位置をそのまま、あるいはウィンドウ内相対位置に変換して実行する。これに対して、操作位置を画像内容に適応させるために、画像領域特定処理により得られた領域を操作対象として扱い、マウスのエミュレーション操作における位置座標を操作対象を表すデータとして実行する方式が考えられる。ここではこれを、適応型オペレータエミュレーション方式と呼ぶ。

（オブジェクト特定処理と画像領域特定処理の差異）
オブジェクトアクセス方式のオブジェクト特定処理と、適応型オペレータエミュレーション方式の画像領域特定処理は、対応関係にある。２つの違いは、
(1)オブジェクト特定処理
ＧＵＩ要素に対応する情報：ＧＵＩ要素のＡＰ内部のオブジェクト
ＧＵＩ要素を指定するデータ：ＧＵＩ要素のＡＰ内部のオブジェクト参照
ＧＵＩ要素の特定フィーチャー：キャプチャ文字列またはコレクション情報
(2)画像領域特定処理
ＧＵＩ要素に対応する情報：ＧＵＩ要素のスクリーン上の矩形領域
ＧＵＩ要素を指定するデータ：ＧＵＩ要素のスクリーン上の矩形座標値
ＧＵＩ要素の特定フィーチャー：画像テンプレートマッチアルゴリズムの引数データ
と整理できる。

これらから大きく２つの長所を挙げることができる。

（画像領域特定処理の長所）
この方式の１つめの長所として、ＧＵＩプラットフォームの実装に対して独立である点が挙げられる。これは、ＧＵＩ要素に対応する情報やそれを指定するデータが、スクリーン上で扱われるものであり、ユーザに対する視覚的な出力を行う全てのソフトウェアは、これらを共通的に持つためである。オブジェクトアクセス方式では、このような扱いができない場合があり、例えば、Flashなど内部アクセスが不可能なＧＵＩ実装や、RemoteDesktopなど実体が遠隔に存在するＧＵＩ構成など、がこれに相当する。

この方式の２つめの長所として、ユーザの識別方法に近く処理内部の動きをイメージし易い点が挙げられる。オブジェクトアクセス方式では、ＡＰ内部のオブジェクトを対象としており、その存在や状況をユーザが直接的に知ることはできない。また、オブジェクトを指定するために、ＡＰ内部のポインタ値を使用するが、ユーザが直接的にその対応を知ることはできない。一方、スクリーン上で扱われる情報は、ユーザが自分自身でＡＰを操作する場合に普段から触れているものであり、その取扱いはもちろん、問題が生じたときの分析・究明も、特別な予備知識なしに誰でも可能である。

このように、画面表示内容の解釈と入力デバイスの操作をソフトウェア的に実現する方式は、オブジェクト特定処理のように操作対象のＧＵＩプラットフォーム実装に依存しないため、従来の自動操作方式に対して汎用性の高い方法である。それと同時に、キャプション特定法のように、適用対象ＡＰの実装内容によりキャプションを持たない要素やユニークな存在でない要素を避ける必要性がなく、コレクション特定法のように、ソフトウェアによる自動操作の過程がユーザに分かり難いといった障害がないため、従来の自動操作ツールの複雑化・特殊化に対して、高いユーザビリティ・ユーティリティを提供できるというメリットがある。

＜画像認識の適用要件＞
以上では、ＧＵＩ要素の特定を行う観点から画像を扱う考え方を説明し、優位性を示した。以下では、処理目的を幅広くとらえ、画像を利用した自動操作に関する従来技術の観点から、改めて考え方を説明し、適用要件を示す。

（画像認識の不確実性を前提とした、画像認識応用の要件）
ビットマップデータなどの画像からの認識過程は、一般にパターン認識や確率計算の過程が含まれ、結果の確実性については、当該アルゴリズム以外にも、画像内容や要求精度に大きく依存する。ここでは、ブラックボックス（学習ベース）型アルゴリズムとホワイトボックス（ルールベース）型アルゴリズムに分類する。そして、自動操作エージェントに適用する場合の実用性の観点から、前者は除外し、後者を採用する。これは画像認識の技術領域を応用する際の要件である。

ブラックボックス（学習ベース）型アルゴリズムとは、ニューラルネットワークなどのような学習を必要とする方法である。これらは、利用目的や取扱いデータの範囲に応じて、教師情報の学習に膨大な時間が必要であり、処理実行して得られた認識結果に対して理由説明や部分修正が困難であるなど、実用の観点で不可避な問題を有する。

ホワイトボックス（ルールベース）型アルゴリズムとは、ユーザや開発者が明示的に定義したルールに基づく認識方法、具体的には本件出願人による「画像領域分割エンジン」に関する特許出願（特願２０１２−１５０４５９）（以下、先願）を活用した方法である。先願は、画像領域の分割パターンをルールとして指定する方法であり、適用対象の多様性や認識目標の複雑性に応じてルール定義を行い、それを幅広い利用目的に汎用的に適用できる。また、ルールの明示的な改善・修正が、開発者だけではなくユーザ自身の手によっても可能である。

（エージェント内利用の要件）
「画像領域分割エンジン」に相当する従来技術としては、先に挙げたとおり、画像テンプレートマッチなどの画像認識技術をアドホックに応用した自動操作エージェント実装がある。画像テンプレートマッチではなく、画像領域特定処理に用いることにより解消される課題の多くは、先願の明細書に記載されているところである。ここではそれ以外に、画像テンプレートマッチに代えて「画像領域分割エンジン」を導入しても、別途対応が必要となる２つの要件を説明する。この両方を実用性の高い方法で実現することが、エージェント内で画像認識の技術領域を利用する際の要件である。

画像認識の応用においては、ルール作成当初に想定した適用対象や当初設定した認識目標が、実際の適用・運用の過程で変化することは十分想定されるため、ルールを実運用しながら適合度を精緻化することが好ましい。先願の「画像領域分割エンジン」では、ルール定義をユーザでも行える手段を提供しているが、自動操作エージェントを使用する場合には、さらに幅広い運用性を考慮する必要がある。本発明はこのような使い方を積極的・効率的に推進できるよう、使用者であるユーザのルール修正を支援する仕組みの提供を目的とし、そこで発生する諸問題を解消する必要がある。

画像認識をアドホックに応用することの課題は以下の通りである。自動操作における特定の処理目的で画像認識を利用すると、その処理箇所は操作の記録・再演の中では実現できず、シナリオの編集手段に基づいて、仮想的な操作アクションとして組み入れる必要がある。なぜならば、画像認識処理で指定する必要のあるパラメータは、認識アルゴリズムに依存して多様に考えられ、その設定内容をユーザ操作の例示をもとにして決定することは困難だからである。

本来、操作の記録・再演の枠組みで全ての自動実行内容を統一的に扱うところを、このように特別な扱いの処理として画像認識を導入すると、自動操作エージェントのシナリオの保守性やシナリオとエージェント内部実装との分離性を低下させてしまう。分離性を維持したまま、幅広い用途と拡張性を担保するフレームワークが必要である。画像領域特定処理として「画像領域分割エンジン」を応用することが求められる。

＜画像領域分割エンジンの適用＞
（ＧＵＩ要素の外観変化への対応）
一般に、画像認識処理をルールに基づいて実現する場合、様々なルール形式が考えられる。特に、画像領域を特定する形式でルールが指定される処理が画像領域特定処理であり、「画像領域分割エンジン」はそれらの中の１つの方式であるが、この方式を使用する利点は、ＧＵＩ要素の画像上の見た目（外観）が変化しても、テンプレート画像を差し替えるだけで対応できる点である。これは、ＧＵＩ要素の間の幾何制約的な位置関係が変わらなければ画像領域分割ルールの制約条件を変える必要はないことを意味する。これに対して、テンプレート画像は幾何制約中にあらわれる基準位置を適用対象画像によって特定する働きをし、ＧＵＩ要素の外観に依存する。

すなわち、ルールにおいて、幾何制約条件とテンプレート画像の役割は明確に分離されている。これはＧＵＩのルックアンドフィールが変化しても、内部的な処理方式を変える必要がないという観点で、従来のルールベースの画像認識方法に対して根本的に異なっている。

前記のとおり、自動操作エージェントへの画像認識の導入にあたっては、シナリオの保守性やシナリオとエージェント内部実装との分離性を維持したまま、幅広い用途と拡張性を担保するフレームワークが期待されており、「画像領域分割エンジン」はそのフレームワークに組み込む処理要素として要求を満たすと期待される。しかし、そのフレームワーク自体の具体的な実現方法は存在しなかった。

（ルックアンドフィール変更の課題）
「画像領域分割エンジン」のメリットとして、適用対象のルックアンドフィールが変化しても分割パターンが変化しなければ、テンプレート画像の差し替えのみでルールの変更なしに対応できることを説明した。しかし、テンプレート画像を差し替える対応自体は別の観点（ツール全体としての運用性）では問題を生じる。

それは、ルックアンドフィールの変化が画面全体に及ぶケースへの対応である。画面全体に及ぶケースとは例えば、ウィンドウマネージャやＧＵＩライブラリのバージョンアップに伴い、画面全体のルックアンドフィールが変化する場合である。あるいは、同じバージョン内においてもユーザの好みに応じて画面全体のルックアンドフィールを変更できる機能が提供されることがあるので、それにより変化する場合もある。

このような外観変化は、自動操作エージェントで作成したシナリオを多様なＰＣ環境で実行する場合に、頻繁に生じる状況である。有用なシナリオを幅広く活用するにあたり、ルックアンドフィールの違いによる動作正常性への影響検知や、その違いに対処するためのルール修正作業が必要であるが、環境の多様性に応じて稼働が増大することが課題となる。

仮にこれが、企業内システムにおけるミッションクリティカルな案件であれば、組織全体の取り組みとして人的リソースを投入することで、ある程度対処可能な範囲ではある。しかし、現場や個人の裁量における軽微であるが種類の多い自動化案件であれば、環境の違いを超えたシナリオ共有を最初からあきらめてしまう要因として、無視できない。このような状況の解消は、自動操作エージェントの適用範囲を拡大する上では、重要な要求条件と考えられる。

＜自動操作を扱うソリューションの一般的な課題＞
自動操作によるバッチ実行の場合のトラブルに対しては、誤った処理の影響範囲を追跡し、必要な場合は外部データの修正をしなければならないなど、運用上の課題がある。これに対してエージェント自身が出力するプログラム動作ログは、プログラム内部の状態を開発者向けに記録したものであり、エンドユーザがそれをもとに原因究明するのは実際的に不可能である。エンドユーザが見ても、そこから自動実行の内容を理解したり、操作全体の状況を把握したりが容易に、例えば視覚的表現や直感的操作を通して、行える情報を提供することが課題である。

また、ユーザの操作イベントをログ化し、履歴として保存するツールを用いることが考えられるが、自動操作エージェントの再演をログ化する場合、シナリオ内の実行位置とログの対応位置が直接的に分からないことが課題である。

＜ウィンドウに対する特定処理の一般的な課題＞
（ＧＵＩ要素の分類）
一般に、ＧＵＩ要素は大きく２種類に分類される。１つはボタン、コンボボックス、テキストフィールドなどであり、ここでは「コントロール」と呼ぶ。もう１つは、タイトルバーを有し、ムーブ・リサイズ（スタイル指定により可否）が可能なトップレベルウィンドウ（フレームウィンドウやダイアログボックス）であり、ここでは単に「ウィンドウ」と呼ぶ。以上の呼び方は、ＧＵＩプラットフォームの種類によって定義されている用語と概念の対応が異なるので注意が必要である。例えば、swing（Java（登録商標））においては、コントロールをコンポーネントと呼んでいる。また、MFCや.netにおいては、ウィンドウは画面上に矩形領域を占める広範なオブジェクトに対応し、コントロールもその一種に相当する。

（ウィンドウの扱い）
これまでの説明では、ＧＵＩ要素として、コントロールとウィンドウを特に区別せずに記述してきたが、自動操作の従来技術においては、これら２つの扱いは明確に分かれているのが一般的である。すなわち、エージェントが操作対象の座標位置を知る場合に、ウィンドウはその種別によらず当該ＰＣ上のウィンドウマネージャのＡＰＩを共通で使用できるのに対し、コントロールはウィンドウマネージャではなくＧＵＩプラットフォームごとにＡＰＩが異なり、プラットフォーム種別によっては非公開のものもある。

このため、ウィンドウについては、ＧＵＩプラットフォーム種別への実装依存性を許容し、ＡＰＩを介してその座標値やウィンドウタイトル、ウィンドウスタイルなどの内部データを取得することが行われる。つまり、ウィンドウについては、オブジェクトアクセス方式の特定フィーチャーによりオブジェクト特定処理を実行し、得られたウィンドウを基準として、その配下のコントロールの特定処理を別の方式で行う、という構成がとられる。

この構成は、コントロールをオペレータエミュレーション方式（画像領域特定処理）で特定する場合にも共通している。すなわち、マウスのクリック操作位置が、ウィンドウの移動によって影響を受けないように、当該コントロールを含むウィンドウの特定フィーチャーを別途保持しておき、オブジェクトアクセス方式によるウィンドウ特定を行う。そして、当該ウィンドウのスクリーン画面上の矩形座標をＧＵＩプラットフォーム依存のＡＰＩを介して取得し、当該矩形座標内における相対座標によってマウスクリック位置の座標を表現する。これは、シナリオの記録時も再演時も共通して行われるため、ウィンドウがスクリーン上でどの位置に置かれていても、ウィンドウ内部のコントロールの相対位置が不変であれば、意図した自動操作が実現できる。

（ウィンドウの特定処理の課題）
ウィンドウの特定には、オブジェクトアクセス方式のキャプション特定法が用いられることが多い。具体的には、ウィンドウタイトルの文字列を正規表現で文字列マッチングをとる方法が使われる。キャプション特定法の限定条件で説明したとおり、タイトルが特定の命名規則の場合だけ適用可能という制限がある。特定したい対象が予めどのような命名規則に従うか定められない場合や、同じ正規表現で本来、区別すべき複数のウィンドウタイトルがマッチしてしまう場合は、従来のウィンドウの特定処理で対応できない。これに対しては、コントロールの場合と同様、画像からウィンドウを特定できることが望ましい。しかしながらウィンドウの存在有無や座標位置を、画像内容から認識することは技術的に困難である。

これに対しては、先願の「画像領域分割エンジン」の適用事例の１つとして、ウィンドウ画像をもとに複数の候補から意図した対象ウィンドウを識別する方法が示されている。即ち、「これに対して本発明では、ルールをマスク領域の特定用とは別に、ウィンドウ種別の特定用のものを用意し、それらを対象画像に適用してみて、制約条件を満足する解が存在するかどうかで、探しているウィンドウか否かを判定することができる。」という記述の部分である。

この方法は、デスクトップ画像からウィンドウの存在や座標位置を求めるのではなく、オブジェクトアクセス方式を部分的に利用して、デスクトップ上のウィンドウオブジェクトの列挙を行う。これらは特定する対象ウィンドウの候補であり、これら候補の中から求めるウィンドウをその画像内容をもとに識別する。画像内容は、ウィンドウオブジェクトへの参照（ポインタやハンドル）を引数として、ウィンドウマネージャに対しＧＵＩプラットフォーム依存のＡＰＩを介して取得依頼することができ、一般的な方法として利用できる。

しかしながら、ウィンドウマネージャをRemoteDesktopなどの仮想デスクトップ環境から利用する場合、デスクトップ全体をビットマップデータとして受信し表示するため、ウィンドウ個々を上記のようなオブジェクトアクセス方式で特定することができない。画像内容からウィンドウそのものの存在を認識する必要があり、ウィンドウの重なり状態などによっては、特定処理が期待したように働かない状況が容易に発生し得る。実行時の特定処理の失敗に対して、特定結果の多重確認により失敗の見逃しを防止することや、失敗したときの状況確認や原因分析を実行直後だけではなく、後で詳細に分析できるよう履歴化することが重要である。

≪課題≫
従来技術の中で画像認識技術を自動操作エージェントに利用するアプローチは優れた面が多いが、前章で説明した要素技術の具体例と個々の課題から、エージェントへの適用にあたって次の課題があることがわかる。

（課題１：アルゴリズムの特性による特定処理結果の誤りの可能性）
（課題１−１：ＧＵＩの相互位置関係の変化による、画像領域特定の失敗の可能性）
エージェントに入力される画像内容によっては、画像認識アルゴリズムが誤った結果を返す可能性が常にある。これは、画像領域特定処理のように、画像内容について人の認識過程を模倣したパターン処理を行うアプローチにおいて不可避である。ここではこれを「画像認識の不確実性」と呼ぶ。

（課題１−２：ＡＰの実装内容の変化による、オブジェクト特定の失敗の可能性）
同様にＡＰの実行時状況としてユーザ操作内容や外部データ内容など環境が変わると、オブジェクト特定を失敗する場合がある。これらはオブジェクト特定処理の限定条件から、対象や環境が逸脱することにより発生する事象として一般化できる。つまり当初想定した場合から外れた、想定外の場合にある状態を意味する。これは、オブジェクト特定処理のように、実行時依存性や実装内容依存性を考慮した上で、アルゴリズムやルールが適正に動作する状況を前提としたアプローチにおいて不可避である。ここではこれを「限定条件の不確実性」と呼ぶ。

（課題２：適用対象や適用環境の変動による、特定フィーチャーの無効化）
（課題２−１：ＧＵＩのルックアンドフィールの変更による、テンプレート画像の無効化）
ＧＵＩプラットフォームのバージョンアップや起動オプションの切り替えにより、ルックアンドフィールが一部あるいは全部について変化してしまう場合がある。また、WindowsOSのカスタマイズ機能（例えば、Windows7の「ウィンドウの色とデザイン」、WindowsXPの「画面のプロパティ／テーマ」など）によりユーザが変更を行うことによってもルックアンドフィールが変化してしまう場合がある。多くの場合、ＧＵＩ要素間の相互の位置関係が一定のパターンを維持しているが、画像認識対象となるＧＵＩの見た目が変わってしまう。パターンとのマッチングを行うルールはそのまま使えても、個々の見た目と結びついたデータ、特に画像マッチング処理のテンプレート画像については、変化に応じて変える必要がある。そのままの特定フィーチャーでは、変動後に対しては使えないことになる。

（課題２−２：実行状況や実装内容の変更による、ＧＵＩコレクション内の順序指定の無効化）
先に説明したように、ユーザ操作の順序により実行状況が変わったり、適用対象ＡＰのバージョンアップやＧＵＩプラットフォームのバージョンアップなど実装内容が変わると、ＧＵＩコレクション内の順序が変わる可能性がある。当該順序上、何番目に存在するかでオブジェクトを特定するコレクション方式については、そのままの特定フィーチャーでは、変動があった場合に使えないことになる。

（課題２−３：バーチャル環境での、ＧＵＩコレクションやテンプレート画像の無効化）
RemoteDesktopや仮想マシンなどのバーチャル環境のデスクトップ領域は、ホストＯＳ上のウィンドウマネージャにおいては、１つの大きなウィンドウとして存在し、その内部は１つの画像データが全面に表示された状態となっている。つまりユーザからは視覚的に存在するが、その内部実装は当該ウィンドウマネージャ内に存在せず、別の場所あるいは別の形態で存在する。従って、オブジェクトアクセスの対象となるＧＵＩ要素オブジェクトは、当該ウィンドウマネージャからＡＰＩを介してアクセスすることはできず、ＧＵＩコレクションそのものが取得できない。この場合も、コレクション方式の特定フィーチャーが使えないことを意味する。

一方、画像ベースについても、バーチャル環境へのログイン環境の条件が異なる場合（WindowsOSのカスタマイズ機能の設定の違いや、ディスプレイ環境による色数の違い、RemoteDesktopなどの遠隔ログイン時の通信条件に応じたオプションの違いなど）により、ルックアンドフィールの違いが発生する可能性がある。この場合も、そのままの特定フィーチャー（テンプレート画像）が使えないことを意味する。

（課題３：適用対象の変動に対応するための、特定フィーチャーの差し替えの困難性）
上記で挙げたような変動が仮に発生した場合、変動後の新しい特定フィーチャーを用意して、もとのシナリオ上で差し替える必要がある。例えば、ＧＵＩのルックアンドフィールが変わった場合、対象のＡＰを起動して、もとのシナリオと同じ操作内容を手動で実行し、ウィンドウ画像をキャプチャし直す必要がある。一方、実行状況や実装内容が変わった場合、キャプション方式かコレクション方式の特定フィーチャーを取り直す必要がある。両者とも、操作の記録モードで共通シナリオと個別シナリオを同時に記録するにしてもシナリオに条件分岐やループが存在すると、その部分については編集操作が必要である。これらの手作業は手数が多いだけではなく、内容が煩雑で間違い易く、多くの時間と労力、十分な習熟と技能を要する。

（課題４：ユーザがエージェントのミスをみすごす潜在的可能性）
オブジェクト特定処理または画像領域特定処理の誤った結果をもとにして、意図しない自動実行が継続される可能性は常に存在し、これを防ぐ完全な対策は一般に存在しない。重要なのは、特定処理の誤りや意図しない自動実行の発生そのものではなく、その発生をユーザが気付かない場合が常に起こり得る点である。これは、特定結果の誤りはそれ自体では判断できず、その特定結果をもとに自動操作することにより発生したエラーから間接的にしか判断できないからである。

仮にこのエラーをエージェント実行中にユーザが発見しても、画像領域特定結果の誤りは当該の瞬間より前に発生しており、さらにその内容はプログラム内部の状態を直接的に見ることができない。このため、事実関係をユーザ自身が具体的に把握する手段が存在しない。エージェントをバッチ的に実行させている場合は、実行結果やエージェントログからしか現象を知ることができないため、さらに状況は厳しい。

（課題５：再現し難い状況での、画像領域特定フィーチャー作成の困難性）
特定フィーチャーの作成には、実際にその状況の画面キャプチャ画像を取得する必要があるため、外部環境との関係により稀にしか再現しない状況や、再現に手数がかかる状況については、例え少量であっても、ユーザにとってその作成は著しく困難となる。

（課題６：画像領域特定フィーチャーのテストデバッグの困難性）
実際に問題を起こした画像領域特定フィーチャーの修正方法を検討したり、修正後の動作を確認したりするには、それに似た状況を条件を変えて再現する必要があり、多くの手間と時間がかかる。

さらに、ルックアンドフィールの変更により、誤動作の疑いはシナリオ全体に及ぶが、具体的にどの操作がどのように影響を受けるかを、１つ１つ調べるのは大変な稼働がかかる。また、全ての箇所を漏れなく正しく修正できるとは限らず、修正漏れや修正間違いを防止することは困難である。

＜画像領域分割エンジンの課題＞
（課題７：ルール修正の稼働が大きいことによる技術的な取扱いの困難性）
画像認識ルールの適用対象となる画像内容（ＵＩ配置）のパターンが、実際の適用・運用の過程で変化することは十分想定されるため、ルールを実運用しながら適合度を精緻化する必要があるが、通常はその作業稼働が大きく現実的に困難であり、エンドユーザにとってはルール変更の影響を類推できず、技術的に取扱いが困難である。

（課題８：アクションごとの異なる扱いによる保守の困難性）
操作対象特定のために画像認識を利用する場合も、その処理箇所は操作の記録・再演の中では統一的に扱う必要があるが、通常は他の操作アクションとは異なる扱いをアドホックに行うためシナリオの保守性が低下してしまう。

そのほか、個別の要素技術について従来から本来的に有する課題として、
（個別課題１：エンドユーザが自動実行の履歴を容易に把握する手段の必要性）
（個別課題２：ルックアンドフィール変更（見た目の変化が全体に及ぶ）への対応の必要性）
（個別課題３：ウィンドウの存在有無や座標位置を画像内容から認識することの困難性）
がある。それぞれ詳細は≪従来の技術≫の章を参照。

＜基本的なアイディア＞
本発明は大きく３つの特徴からなる。第１に、適用対象の変動に対する補償を目的とした、画像領域特定処理とオブジェクト特定処理の併用である。第２に、画像領域特定のルールの定義・修正・試験を目的とした、画面キャプチャ画像とマウス操作イベントからなる操作ログの蓄積である。第３に、複数の方式、複数の操作記録の間での対応アクションの比較・変更を目的とした、対応関係情報の保持とアクションエディタ（編集設定手段）の提供である。以下ではそれぞれについて概要を説明し、具体的機能を挙げる。

〈特定処理の２方式併用〉
画像認識技術を用いてＰＣスクリーン上に描画されたＧＵＩ要素を操作対象として認識する方法（画像領域特定処理）と、ＧＵＩプラットフォームのＡＰＩを介してＧＵＩオブジェクトにアクセスする従来の方法（オブジェクト特定処理）と、を両方組み合わせた機能を提供する。

（２つの特定処理の差異）
両方を組み合わせた機能とは、以下に示す各々の長所を補完的に用い、一方が変動しても他方で補償する考え方に基づく。

従来技術による特定処理（オブジェクト特定処理）に使用する特定フィーチャーは、適用対象ＡＰの実装内容が変化しない限り、ルックアンドフィールやＧＵＩレイアウトルールの変化に対して、不変な特定フィーチャーである。

画像認識技術による特定処理（画像領域特定処理）に使用する特定フィーチャーは、ルックアンドフィールやＧＵＩレイアウトルールが変化しない限り、適用対象ＡＰの実装内容の変動に対して、不変な特定フィーチャーである。

（個別シナリオと共通シナリオ）
ここでは、オブジェクトアクセス方式の特定処理（オブジェクト特定処理）と操作処理だけで構成されたシナリオを個別シナリオと呼び、オペレータエミュレーション方式の特定処理（画像領域特定処理）と操作処理だけで構成されたシナリオを共通シナリオと呼ぶものとする。

提供機能の具体的内容は、以下の通りである。

（提供機能の具体的内容（特定処理））
提供機能１：図１に示すように、操作の記録時に前述した個別シナリオ及び共通シナリオの２種類のシナリオを並行して記録する。それにより、操作の再演時に２種類のシナリオの処理結果を突き合わせることで相互チェックを行い、適用対象の変動（ルックアンドフィールやＧＵＩレイアウトルール、実装内容）などによりシナリオが意図した動作を再演できていない可能性を検出する手段を提供する。

提供機能２：図２（ａ）（ｂ）に示すように、シナリオの再演を個別シナリオか共通シナリオかどちらか、ユーザが指定した方だけを使用して実行する。このとき、相互チェックを無視できるようにすることで、適用対象の変動があってもユーザ判断により適正な側のシナリオを選択的に使用する手段を提供する。

提供機能３：図３、図４に示すように、ユーザの指定により、再演時の動作をもとにユーザが操作を記録するのと同じように、新しい個別シナリオ・共通シナリオの組を生成・保存する。このとき、提供機能２と本機能を同時に動作可能とし、適正な側のシナリオから他方のシナリオを自動生成する手段を提供する。

〈操作ログ蓄積の活用〉
画像領域特定処理は、画面出力とマウス入力を受け付ける全てのＡＰに共通的に適用できる点で、オブジェクト特定処理に対して汎用性が高い。また、特定処理の入力と出力が、画像と座標という実装独立の形式であるためにＧＵＩプラットフォーム種別に関係なく統一化が可能であり、比較的処理が軽いためにバックグラウンドでログを取得し、履歴として蓄積することも可能である。これを利用して、画像領域特定のルール（画像領域分割ルール）の定義・修正・試験を、過去に遡って実施できるだけではなく、蓄積したログを移動することで、実際には当該環境で起動できない適用対象やその場での再現が困難な適用状況など、大規模運用におけるメンテナンス効率化に活用できる。

提供機能の具体的な内容は以下の通りである。

（提供機能の具体的内容（操作ログ））
提供機能４：図５に示すように、操作の記録時、操作の実行時、いずれにおいてもユーザの指示もしくはエージェントの自動的判断により、実行中の操作を操作ログリポジトリに記録する。そして、過去に遡って任意の操作箇所とその前後を閲覧したり、操作対象が同じＡＰやＧＵＩ要素に対する操作ログを閲覧する手段を提供する。

提供機能５：図６に示すように、蓄積した操作ログリポジトリから過去の操作と画像を参照し、共通シナリオを自動生成する手段を提供する。また、得られた共通シナリオから提供機能３を動作させることで、過去の操作履歴に相当する２種類のシナリオを自動生成する手段を提供する。

提供機能６：図７に示すように、蓄積した操作ログリポジトリから過去の操作と画像を参照し、ユーザが画像認識技術の特定ルールの定義を作成・修正する際に、前記参照を疑似データとして、試験する手段を提供する。このとき、過去の大量の操作ログから所定の検索手段により選択した任意のアクション集合について、試験を一括して行う手段を提供する。

〈編集設定手段の整理〉
（提供機能の具体的内容（編集設定手段））
提供機能７：実行中シナリオもしくは閲覧中の操作ログの再演時シナリオの参照位置ノードを特定し、それに対応する２方式のアクションについて、それぞれの特定フィーチャーを個別に編集する所定のエディタ画面を表示する。

提供機能８：上記ノードについて、２方式のアクションの操作処理及び特定処理の設定を共通に編集する所定のエディタ画面を表示するとともに、当該アクションの未定義状態や操作処理内容に応じて、操作処理の方式間代替の設定手段を提供する。

本発明によれば、画像認識の不確実性やルール定義の適宜改善を前提とし、誤動作の疑いがある場合に即時かつ確実に検知し、ログ記録もしくは異常停止によりユーザに通知することができる。また、操作対象ＡＰのルックアンドフィールの変更があった場合に、エージェント動作への影響（特定結果の不一致）を常に監視し、影響が現れた場合はそれを確実に検知できる。また、操作対象ＡＰのマイナーバージョンアップがあった場合に、特定結果の不一致を常に監視し、影響が現れた場合はそれを検知できる。

本発明の自動操作エージェントの動作原理を示す説明図（提供機能１） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能２） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能３） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能３） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能４） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能５） 本発明の自動操作エージェントの動作原理を示す説明図（提供機能６） 従来の自動操作エージェントのハードウェア構成図 従来の自動操作エージェントの機能構成図 従来の自動操作エージェントの動作フローの全体図 従来の自動操作エージェントの記録モードの動作フロー 従来の自動操作エージェントの編集モードの動作フロー 従来の自動操作エージェントの再演モードの動作フロー 従来の自動操作エージェントの再演モードの画面図 従来の自動操作エージェントの記録・編集モードの画面図 従来の操作パラメータ編集パネルの画面図 従来の対象パラメータ編集パネル（コントロール対象）の画面図 従来の対象パラメータ編集パネル（相対位置対象）の画面図 本発明の自動操作エージェントのハードウェア構成図 本発明の自動操作エージェントの機能構成図 本発明の自動操作エージェントの動作フローの全体図 ルール定義エディタのＧＵＩ（メイン）画面図 本発明の対象パラメータ編集パネル（相対位置対象）の画面図 本発明におけるアクション再演処理のフレームワークを示す説明図 本発明におけるアクションデータのスキーマを示す説明図 本発明におけるスクリプトファイルのデータ形式を示す説明図

≪従来の自動操作エージェント≫
＜ハードウェア構成（装置構成）＞
従来技術から想定される自動操作エージェントのハードウェア構成を図８に示す。

自動操作エージェント１０は、自動操作の対象となる操作対象アプリケーション２０とともに同じコンピュータ１のオペレーティングシステム（ＯＳ）３０上で実行される。両者の情報交換の確立方法としては、操作対象アプリケーション２０が単独で起動しているところへ、自動操作エージェント１０を別途起動し、ＯＳ３０のＡＰＩを介してプロセス間の情報交換経路を取得しても良いし（一般にアタッチ操作と呼ぶ）、自動操作エージェント１０を先に起動しておき、操作対象アプリケーション２０を子プロセスとして起動して、得られるプロセスハンドル等を使用して情報交換経路を取得しても良い。これらソフトウェアは、一般的なコンピュータ１における内部メモリ２上に保持され、システムバス３を介してＣＰＵ４及び下記の周辺機器と接続されている。

当該コンピュータ１には、出力装置としてディスプレイ（表示装置）５が接続されており、オペレータへＧＵＩなどの視覚情報の表示を行うことができる。また、入力装置６としてマウスやキーボードが接続されており、オペレータからマウスポインタの移動やマウスクリックの操作などを行うことができる。

また、当該コンピュータ１には、外部記憶装置としてハードディスク７等が接続されており、自動操作エージェント１０は、操作対象アプリケーション２０の種類や自動操作させたい作業内容などに応じて、自動操作スクリプトファイル４０を外部記憶装置７に保存及び読み込みができる。

＜ソフトウェア構成（機能構成）＞
〈全体〉
従来技術から想定される自動操作エージェント１０の機能構成を図９に示す。エージェントはオペレーティングシステム対向ＩＦを介して、操作対象ＡＰの状態やユーザ操作のイベントを取得する。状態やイベントの取得方法は、その対象の種類によって異なるＡＰＩや異なる手順となる。このため、ＧＵＩプラットフォーム種別等に応じて、異なるコントロール制御部（コントロール特定処理を実行）１１が複数存在する。これらのモジュールは、エージェントが対応するＧＵＩプラットフォームを拡張するためにアダプタとしてプラグイン可能な構成となっている。

一方、当該ＯＳ上のウィンドウマネージャに対応して、ウィンドウの境界枠の位置や状態を取得するウィンドウ制御部（ウィンドウ特定処理を実行）１２が存在する。また、ユーザの入力をマウス・キーボードなどの機器操作レベルで取得するマウス・キーボード制御部（座標位置指定処理を実行）１３が存在する。また、ユーザへの出力をスクリーン表示の画像内容レベルで取得する画像認識部（画像領域特定処理を実行）１４が存在する。以上のアダプタは、スクリプト制御部１５によって統括されている。スクリプト制御部１５は、エージェントがスクリプトファイル４０からメモリ２上に取り込んだ（あるいは作業用として一時的に生成した）スクリプト情報にアクセスする。

スクリプト情報をユーザが編集する手段としてエディタ機能部（シナリオエディタ）１６が存在する。また、エージェントの動作状態全体を制御するために、記録・実行制御部１７が存在する。記録・実行制御部１７は、スクリプト制御部１５を管理するとともに、エディタ機能部１６のＵＩやエージェントの動作状態を変更するＵＩ（図には示されていない）をユーザに対して提示する。

〈画像認識部〉
従来技術における画像認識部１４は基本的なテンプレートマッチ機能を提供する従来技術の構成を示している。複雑なルール設定などは存在せず、単純にクリックしたい位置の画像断片や、識別させたいウィンドウが含む画像断片を適用する。

〈スクリプト形式と編集手段〉
（自動操作スクリプトの役割）
自動操作スクリプトファイル４０は、エージェント１０が記録モードで生成し、編集モードで変更し、再生モードで参照するファイルである。エージェント１０は記録モードで、操作対象に対するユーザの操作内容をもとに、スクリプトを生成し、ファイル形式で保存する。編集モードで、ユーザに対して、スクリプトの内容を手動で編集し、ループや条件分岐などの制御構造を定義する手段を提供する。再生モードで、指定されたスクリプトの内容を解釈し、自動操作を実行する。

（自動操作スクリプトの構成）
スクリプトファイル４０は、操作シナリオ情報と対象プロファイル情報の部分からなる。

（操作シナリオの構成）
操作シナリオ情報は、複数のアクションを保持し、自動実行の制御構造のなかにこれらのアクションを関連付けている。アクションは操作実行の最小単位であり、操作対象の識別子（対象識別子）、作用種別の識別子（作用識別子）、作用パラメータからなる。

（対象プロファイルの構成）
対象プロファイル情報は、外部環境から操作対象やその関連対象、すなわち実体要素を特定・識別する手がかりとなるデータ、つまりフィーチャーを定義している部分である。特定された操作対象は、エージェント内部で流通する対象識別子によって操作シナリオ情報の部分から参照される。

（スクリプトの編集手段）
従来技術におけるプロファイル情報は、操作対象のコントロールを特定するためにコントロール制御部１１が参照する情報としてコントロールフィーチャーを保持する。ウィンドウを特定する場合も同様である。これらはシナリオ情報の補足的な扱いなので、シナリオエディタ１６の内部に閲覧・編集の機能が限定的に提供される。すなわち、シナリオエディタ１６がスクリプト全体の編集をカバーしている。具体的な画面事例は後述する。

〈動作フローと操作手順〉
従来の自動操作エージェント１０の動作フローの全体を図１０に示す。自動操作エージェント１０は記録モード、編集モード、再演モードのいずれかで実行される。エージェント１０を制御するためのＧＵＩ画面が提供され、ユーザは３つのモードを任意に切り替えることができる。

記録モードではシナリオ情報に該当の操作内容と操作対象が記録される。記録モードの動作フローを図１１に示す。記録モードではエージェント１０は、バックグラウンドの処理として、ユーザが対象アプリケーションに対して行うマウス操作やキーボード操作を監視し、イベントが発生するごとに操作イベントキューに追加する。

エージェント１０は、記録モードを開始すると、まず編集モードで選択中だったノードを記録位置に初期化する。何も選択されていない場合は、シナリオの開始ノードを記録位置に初期化する（ｓ１１）。その後、ループを実行する（ｓ１２）。ループは停止ボタンがユーザによって押されるまで継続される。エージェント１０はループによって一定間隔で操作イベントキューを参照し（ｓ１３）、要素が存在する場合は、その操作イベントデータを取り出し（ｓ１４）、操作対象の特定情報を実際のウィンドウやコントロールから取得し（ｓ１５）、シナリオの記録位置にアクションノードを挿入して、これを次の記録位置として更新する（ｓ１６）。

編集モードでは前記シナリオ情報の保存と読込のほか、前記ＧＵＩ画面で表示されるシナリオ情報を、従来のワークフロー図（WfMCやPBMN）を模倣した方法でユーザが編集する手段をエージェント１０が提供する。編集モードの動作フローを図１２に示す。

エージェント１０は、編集モードにおいては、何も定義されていないシナリオを保持して初期化する（ｓ２１）。その後、ループを実行する（ｓ２２）。ループ中、別のモードへの切り替え指示を受け付けると当該モードへの移行を行う（ｓ２３〜ｓ２６）。それ以外のシナリオエディタ上での操作は、いわゆるワークフローエディタと同様のユーザ対話操作を受け付ける（ｓ２７，ｓ２８）。詳細は、後述の画面説明で言及する。

再演モードでは前記シナリオ情報を解釈し、記録時と同じ内容、同じ順序の操作を対象アプリケーション２０に対してエージェント１０がユーザに代わり自動実行する。編集モードの動作フローを図６に示す。

エージェント１０は、再演モードを開始すると、まずシナリオの開始ノードを実行位置に初期化する（ｓ３１）。その後、ループを実行する（ｓ３２）。ループは停止ボタンがユーザによって押されるか、シナリオの終了ノードに到達し次の実行位置のアクションがなくなるまで継続される（ｓ３３）。エージェント１０はシナリオから実行位置のアクションを取り出し（ｓ３４）、その中の特定情報をもとに操作対象のウィンドウやコントロールを特定し（ｓ３５）、それに対してアクションを実行する（ｓ３６）。

〈画面事例〉
（全体制御ＵＩと再演モード画面）
エージェントによる自動操作を行っている状況の画面を図１４に示す。左側の２つのウィンドウは、操作対象アプリケーションのＧＵＩを表している。右側の１つのウィンドウは、再演モードにおけるエージェントの制御画面である。当該ウィンドウには、操作シナリオの内容がフローチャートの形式で表示され、現在の自動実行のインストラクションポインタ位置をハイライトで強調するなど、ユーザの利便性を向上する工夫が行われている。これは、別途のユーザ指示やオプション設定やエージェントビルド時指定によって省略されていても良い。当該ウィンドウの上部にはユーザによって読み込まれたシナリオファイル名が表示されており、左のボタンにより別のファイルを読み込むことができる。また、その下の停止ボタン（「■」のアイコン）によって、シナリオの実行を停止し、編集モードに移行することができる。また、実行ボタン（「→」のアイコン）によって再演モードに入りシナリオ最初からもしくは前回中断の継続位置から実行する。

（定義エディタと記録・編集モード画面）
エージェントによる操作記録もしくはシナリオ編集を行っている状況の画面を図１５に示す。ユーザは、ワークフロー図１５０１において、ワークフローエディタの図形操作によって、制御構造を閲覧編集できる。また、予め用意されたアクションや特殊な機能は、ワークフロー図１５０１の左のパレットからノードアイコンをドラッグして、図中に配置することにより、当該の要素をシナリオに組み込むことができる。後に述べる画像認識機能など、ユーザの操作の例示ではシナリオ作成ができない機能は、これらパレットから作成する。

記録ボタン１５０２を押下することにより、記録モードに移行する。記録モードでは、ユーザが操作対象ウィンドウに対する操作を行うことで、イベント取得を行い、得られた内容に基づいてシナリオ１５０１上にアクションノードが追加される。対象選択ボタン１５０３を押下すると、適用対象ウィンドウの変更を受け付ける状態となる。ユーザがマウスを移動し任意のウィンドウ上で静止すると、当該ウィンドウの境界がハイライト表示される。この状態でマウスをドラッグあるいはクリックすると、当該ウィンドウを所有するアプリケーションが以降の記録モードでの操作対象になる。但し、当該機能は記録対象となるアプリケーションをユーザの意図により限定する目的で提供されるものであって、記録対象を複数に設定したい場合や全てのアプリケーションを対象にする場合は、適宜用いられるものである。以上は、記録モード及びエージェントの動作モードに関する全体制御にかかわるＧＵＩである。

一方、編集モードにおける既出のフローチャート編集以外の操作を説明する。ワークフロー図上の任意のノードを選択し、編集ボタン１５０４を押下することによって、当該ノードに相当する操作内容について閲覧・変更することができる。さらに、編集ボタン１５０５を押下することによって、当該ノードに対応する操作対象について詳細情報を閲覧・変更することができる。

（操作内容の閲覧・変更）
編集ボタン１５０４を押下することによって、当該ノードに相当する操作内容について閲覧・変更することができる。操作パラメータ編集パネルを図１６に示す。この画面は様々な操作種別に対して共通の画面設計を採用している。具体的には、例えばボタン押下アクションの場合は、特にパラメータは指定しない。また、チェックボックス操作の場合は、チェックをオンにするかオフにするかのブール値を指定する。また、テキストフィールド入力の場合は、入力する文字列値を指定する。さらに、ＧＵＩコントロールに対する操作だけではなく、低レベル入出力についてもこの画面で閲覧・変更する。マウスクリックアクションの場合は、右マウスボタンか左マウスボタンかの違いや、シングルクリックかダブルクリックかの違いなどをパラメータで指定する。操作種別に応じて当該画面の「＜パラメータ１＞」等のラベルを適切なパラメータ名称で表示したり、指定の必要がないパラメータはテキスト入力をディスエイブルとしたり、といった工夫は考えられる。

（マウスクリック座標値の扱い）
なお、この従来技術の実施例においては、本発明の内容を説明し易くするため、マウスのクリック座標を、当該画面ではなく前記の操作対象についての編集画面で扱う。すなわち、クリック座標については、マウスの操作内容としてではなく、疑似的に操作対象として表す点に注意する。但し、このような実施例としても、マウス入力の操作記録に関する構成や動作は、一般に知られている仕様（クリック座標値をマウスの操作内容として扱う画面設計）と本質的に同等である。

以上は、操作対象をコントロールではなく、それよりも粗いウィンドウの粒度としてアクセスし、さらにその内部の相対座標をオペレータエミュレーション方式で自動操作する方法である。これは、ウィンドウ内部のＧＵＩ種別がエージェントに組み込まれたアダプタで対応できず、オブジェクトアクセス方式で自動操作できない場合をカバーする観点から重要である。

（操作対象の閲覧・編集）
前記マウスクリック座標値の扱いを踏まえ、操作対象の閲覧・編集には２種類の対象パラメータ編集ウィンドウを提供する。

コントロールを操作対象とするアクションを選択状態にして、編集ボタン１５０４を押下した場合は、図１７に示す対象パラメータ編集パネル（コントロール対象）の画面が開く。この場合、「＜対象種別＞」フィールドには、「コントロールオブジェクト」が表示される。対象パラメータとしては、ウィンドウタイトル、クラス名、プロセス名、コントロール名、ウィンドウ内通番、などが閲覧・編集できる。また、パラメータ編集パネルの右半分には、スクリーン画面上に表示される視覚的な構成上のどの要素に対応するかが強調表示される。これは、内部実装におけるオブジェクトは一般にデバッガ等を使用しない限り、ユーザが直接把握することはできないので、実用上重要である。

ウィンドウ内の相対位置を操作対象とするアクション（＝マウスクリック）の場合は、図１８に示す対象パラメータ編集パネル（相対位置対象）の画面が開く。この場合、「＜対象種別＞」フィールドには、「ウィンドウ内相対位置」が表示される。対象パラメータとしては、ウィンドウタイトル、クラス名、プロセス名、相対Ｘ座標、相対Ｙ座標が閲覧・編集できる。また、パラメータ編集パネルの右半分には、ウィンドウ内のどの相対位置が対象となっているかを示すためにキャプチャ画像上の１点が強調表示される。

＜本発明との比較に関わる詳細な動作＞
〈シナリオの記録と再演の動作〉
（操作シナリオにおける記録モード動作）
自動操作エージェント１０は記録モードにおいて、操作イベントを検知するたびにそれがどの操作対象に関するものなのかを特定する処理を実行する。WindowsOSにおける操作イベント検知手段（Windows Message）やそのほか一般的なイベントの仕様として、イベントデータの中に操作対象オブジェクトのアドレスやハンドル（オブジェクト参照）が含まれる。エージェントはオブジェクト参照をもとに、操作対象の特定に必要な情報（特定フィーチャー）を、ＯＳのＡＰＩを介してオブジェクト実体に問い合わせ、取得する。

（操作シナリオにおける再生モード動作）
自動操作エージェント１０は再演モードにおいて、現在実行アクションの操作の操作対象の特定フィーチャーを、適切な制御部に送信する。当該制御部配下の特定処理が、コントロール要素のオブジェクト参照をＯＳから取得する。それらフィジカルデータを、スクリプト制御部１５は記録・実行制御部１７と連携して、現在実行アクションの作用種別識別子に応じて、関連付けられたパラメータを適切な作用処理を配下に有する制御部に送信する。記録・実行制御部１７は、関連付けられたパラメータに実行後の状態を取得・反映し、スクリプト制御部１５と記録・実行制御部１７に実行完了を通知する。

〈オペレータエミュレーションの実施形態〉
図１８でも触れたように、アクションのうち、マウスクリックなどの入力操作をそのままアクション化したものは、オペレータエミュレーション方式に相当する。ウィンドウ移動などによる影響を考慮し、当該方式を単独で用いるのではなく、ウィンドウに関してはオブジェクトアクセス方式で取得し、その内部のコントロールに関してはウィンドウ内部の相対座標で位置を決定する。

このように従来の方法では、コントロールが実際にどのように描画されているかに関係なく一方的に相対座標で位置を決定しており、画像内容によるフィードバックがかかっていない。すなわち、オペレータエミュレーション方式において操作対象の特定を行っていない。

また、オペレータエミュレーション方式単独ではなく、ウィンドウ要素については部分的にオブジェクトアクセス方式を組み合わせて用いている。すなわち、オペレータエミュレーション方式の操作対象特定を取り入れたとしても、オブジェクトアクセス方式の課題がウィンドウ要素の特定において影響することは逃れられない。

なお、画像マッチングなどの画像認識手法を従来技術で導入している例としては、図１５の自動操作エージェントの記録・編集モードの画面のパレットから、単純にボタン画像などを指定して、その位置をクリックするなどの形態が存在する。これは［特許文献１］に指摘されているリサイズやレイアウトなどの変動に対処できない。

以上をまとめると、オペレータエミュレーション方式における特定処理は、
・もともと従来の方法では存在しない
・既存の画像マッチ機能はアドホックな埋め込み方で一貫性がない
・仮に画像マッチを取り入れてもウィンドウ内のコントロール特定のみで一般性がない
というように、フレームワークとしての対応ができていないことがわかる。

≪本発明の自動操作エージェント≫
＜ハードウェア構成（装置構成）＞
本発明による自動操作エージェントのハードウェア構成を図１９に示す。従来技術に対する差異として、本発明による自動操作エージェント１００及び自動操作スクリプトファイル４００が用いられる他、操作ログファイル５０及び試験結果ファイル６０が外部記憶装置７に配置される。

＜ソフトウェア構成（機能構成）＞
〈全体〉
また本発明による自動操作エージェント１００の機能構成を図２０に示す。従来技術に対する差異として、以下が挙げられる。

（従来の基本機能群の独立化）
従来のコントロール制御部、ウィンドウ制御部、マウス・キーボード制御部及び画像認識部の基本機能群が、記録モード用及び再演モード用の別々のインスタンスとして、即ちコントロール制御部１０１，１０２、ウィンドウ制御部１０３，１０４、マウス・キーボード制御部１０５，１０６及び画像認識部１０７，１０８として配置される。

また、従来のスクリプト制御部及び記録・実行制御部が記録スクリプト制御部１０９と再演スクリプト制御部１１０とに分けて配置される。

記録スクリプト制御部１０９と再演スクリプト制御部１１０との間をスクリプト同期部１１１が結ぶ形で配置される。再演モードのアダプタ群、具体的にはコントロール制御部１０２、ウィンドウ制御部１０４、マウス・キーボード制御部１０６及び画像認識部１０８を、特定結果照会部１１２、特定結果変換部１１３、操作内容変換部１１４が統括する形で配置される。

（スクリプト同期部）
スクリプト同期部１１１は、記録モードで、アクション記録ごとに個別シナリオと共通シナリオの対応するノードに対しシナリオノード識別子を発行・通知する。

（特定結果照会部）
特定結果照会部１１２は、再演モードで、アクション実行ごとにオブジェクト特定処理と画像領域特定処理の結果を突き合わせる。異なる操作対象を示している場合は、再演スクリプト制御部１１０に通知し、再演スクリプト制御部１１０はシナリオの再演を停止させる。

（特定結果変換部）
特定結果変換部１１３は、オブジェクト参照を画像領域に変換することにより、オブジェクトアクセス方式の特定処理をオペレータエミュレーション方式の特定処理の代わりとして使用できる。また、個別ＧＵＩプラットフォームの制御アダプタに所定のＡＰＩが存在すれば、逆の方向への代替使用も可能となる。

（操作内容変換部）
操作内容変換部１１４は、オブジェクトＡＰＩ呼び出しをマウスクリックエミュレーションに変換することにより、オペレータエミュレーション方式の操作処理をオブジェクトアクセス方式の操作処理の代わりとして使用できる。また、個別ＧＵＩプラットフォームの制御アダプタに所定のＡＰＩが存在すれば、逆の方向への代替使用も可能となる。

（操作ログ取得・再生ＩＦ）
記録モードのオペレータエミュレーション方式に関わるアダプタ、すなわちマウス・キーボード制御部１０５及び画像認識部１０７とオペレーティングシステム対向ＩＦとの間には、操作ログ取得ＩＦ１１５が配置され、再演モードのオペレータエミュレーション方式に関わるアダプタ、すなわちマウス・キーボード制御部１０６及び画像認識部１０８とオペレーティングシステム対向ＩＦとの間には操作ログ再生ＩＦ１１６が配置される。

操作ログ取得ＩＦ１１５から取得した操作ログは操作ログリポジトリ１１７に蓄積される。また逆に、操作ログリポジトリ１１７内の操作ログをもとに、前記アダプタに対して、疑似的に操作イベントをポストし、操作ログ再生ＩＦ１１６及びオペレーティングシステム対向ＩＦを介して実際にユーザが操作をしているかのように見せる。

操作ログリポジトリ１１７と操作ログ取得・再生ＩＦ１１５，１１６を統括・制御する役割として操作ログブラウザ１１８が配置される。操作ログブラウザ１１８はユーザに対して、操作ログリポジトリ１１７内を検索し取得した操作ログを閲覧したり、そこから指定した操作ログで疑似イベントを発生するよう指示したりを可能とする、エージェントＵＩを提供する。

（操作ログリポジトリ）
操作ログリポジトリ１１７には、複数の操作ログセッションが含まれる。操作ログセッションは、当該操作ログを取得したセッションの状況を表すデータをヘッダとして保持する。ヘッダには、ログ取得環境とログ取得状況の情報が格納される。ログ取得情報には、アーキテクチャ種別（実端末か仮想端末か）、端末構成（ＯＳ設定、入力機器構成）、ディスプレイ構成（単数または複数について、サイズ、境界の絶対座標値、色数など）、ＯＳ種別、ウィンドウマネージャ種別、ルックアンドフィール種別を含む。ログ取得状況には、取得開始日時、取得終了日時、ユーザ名を含む。

操作ログには、操作時刻とマウスクリックイベントと画面キャプチャ画像のセットが複数格納される。画面キャプチャ画像はログデータの中に直接埋め込んでも良いし、別途画像ファイルとして保存してそのファイル名を埋め込んでも良いし、別途データベースに保存してその検索キーを埋め込んでも良い。マウスクリックイベントには、スクリーン絶対座標系におけるクリック位置座標と右ボタン又は左ボタンの種別とボタンアップ又はダウンの区別とを含む。また、クリック位置直下のウィンドウ境界の絶対座標値も含む。

（画像認識試験部）
操作ログ上の情報をもとに画像領域特定処理のシミュレーションテストを行う画像認識試験部１１９を有する。ユーザは試験設定を行った後、当該画像認識試験部１１９に処理を依頼することで、試験のバッチ処理を行う。バッチ処理では、画像認識部１０７，１０８と同様な画像認識部１２０を用いて、複数のキャプチャ画像に対して画像領域分割ルールを適用し、その結果を試験結果格納部１２１に蓄積していく。試験結果格納部１２１には、前記試験で得られた、各アクションについて当該の画像領域特定フィーチャーに対する特定結果が保持される。本機能は、動作フローの試験再演モードに相当する。詳細な説明は省略する。

〈画像認識部〉
画像認識部１０７，１０８，１２０は、画像領域特定処理を呼び出し、画像領域特定処理は、画像領域分割エンジン１２２，１２３，１２４を呼び出すよう機能配置される。従来技術の画像認識部は、通常のユーザ操作に対応するアクションではなく、予めエージェントに具備された特別なアクション（記録モードではなく、編集画面のパレットから生成される）として提供されていた。本発明では、エンジンに入力されるデータ（ルールとラベル）をもとに画像領域を特定する処理として扱われる。すなわち、シナリオ上のアクションとして他と同じく特定フィーチャーをもとに処理される。エンジンとの接続、特定フィーチャーの形式、ルールエディタの詳細は後述する。

〈スクリプト形式と編集手段〉
従来技術のプロファイル情報に加えて、端末や環境に関するプロファイル情報が追加される。具体的には、プロセス、ウィンドウ、コントロールのハンドルＩＤごとに、ライブラリ種別、ルックアンドフィール種別を含む。そのほか、フォント種別、ポイント数、描画色、背景色、などを含んでも良い。これらは、エージェント内部で流通する識別子と後述の特定フィーチャーに関連付けられる。これらプロファイル情報は、操作ログのプロファイル情報と比較するために保持される。２つを比較することによって、画像領域特定フィーチャーが適用対象と適合しているかどうかの、参考情報を得ることができる。比較は自動で行うのではなくユーザの指示により目視で行う利用形態も考慮している。

スクリプト内部のプロファイル情報に、ウィンドウ画像フィーチャー、コントロール画像フィーチャーが配置される。そして、画像フィーチャーを編集する手段として、分割ルールエディタが配置される。なお、図中における違いとして、エディタの機能が階層化されているが、これは設計上の施策であり、発明内容とは関係ない。

具体的には、従来の図では、シナリオを編集する手段としてシナリオエディタが提供されており、その一部として対象パラメータ設定画面が提供されているが、本発明の図では、各種フィーチャーを編集する機能が充実することから、スクリプト全体を読み込み、編集手段を提供するスクリプトエディタ１３０の部分機能として、シナリオエディタ１３１とプロファイルエディタ１３２が配置され、プロファイルエディタの下位機能として分割ルールエディタ１３３が配置される。プロファイルエディタの画面は、従来の対象パラメータ設定画面である。

〈動作フローと操作手順〉
本発明の自動操作エージェントの動作フローの全体を図２１に示す。記録モード、編集モード、再演モードがそれぞれ個別のスレッドを有し、独立に動作状態を有する。また、後述の操作ログ及び画像認識試験の関連機能についても、それぞれ個別のスレッドを有し、独立の動作状態を有する。すなわち、操作ログは取得、閲覧、再生を、画像認識試験は試験結果閲覧、試験実行を、それぞれ別々に機能させることができる。

本発明では、従来と異なり、複数の機能を同時並行で動作させる。そのため、システム全体でとり得る状態の組み合わせは多くなる。ユーザの操作手順として全てを示すことは行わず、本発明の効果に関係する部分に関して説明する。

エージェント起動時は、各スレッドは開始ノードから遷移する最初の状態にある。この基本状態から可能な、本実施例におけるユーザの操作手順を６つ提示する。それぞれについて各状態は次のように遷移する。

提供機能１（記録操作）：記録シナリオを指定し、記録モードに移行する。ユーザの操作事例をシナリオに記録する。停止ボタン押下を契機に記録シナリオ指定の状態に戻る。

提供機能２（再演操作）：再演シナリオを指定し、再演モードに移行する。操作対象ＡＰをエージェント１００が自動操作する。停止ボタン押下もしくはシナリオ上の終了ノードへの到達を契機に再演シナリオ指定の状態に戻る。

提供機能３（再演転写操作）：再演シナリオを指定し、そのファイル名をもとに転写先の記録シナリオ指定が自動的に設定される。ユーザは「機能３（再演転写操作）」のボタンを押下する。これを契機に記録シナリオ指定から記録モードへ、また再演シナリオ指定から再演モードへ、２つのスレッドが同時に移行する。操作対象ＡＰをエージェント１００が自動操作するとともに、その画面とマウス操作をもとに転写先シナリオが記録される。停止ボタン押下もしくはシナリオ上の終了ノードへの到達を契機に、再演シナリオ指定及び記録シナリオ指定の状態に２つのスレッドが同時に戻る。

提供機能４（ログ取得操作）：取得ログファイル名を自動もしくは手動で指定する。ユーザは「機能４（ログ取得操作）」のチェックボタンをＯＮにした上で「機能１（記録操作）」もしくは「機能２（再演操作）」と同じ操作を行う。これを契機に、取得ログ指定からログ再生モードへ、機能１もしくは機能２はそれぞれ所定の機能状態へと遷移する。機能１もしくは機能２が停止したことを契機に、取得ログ指定の状態に戻る。

提供機能５（ログ転写操作）：再演ログファイル名を手動で指定する。ユーザは、「機能５（ログ転写操作）」のボタンを押下する。これを契機に再生ログ指定からログ再生モードへ、また記録シナリオ指定から記録モードへ移行する。転写操作の停止ボタン押下か記録モード停止ボタン押下を契機に、それぞれ再生ログ指定及び記録シナリオ指定の状態に２つのスレッドが同時に戻る。

提供機能６（ログ試験操作）：ユーザは、試験設定を行った上で試験開始ボタンを押下する。これを契機に試験実行の状態に移行する。試験停止ボタン押下か、試験実行終了を契機に、試験設定の状態に戻る。

ある機能が実行中であっても、並行して実行可能な他の機能については、ユーザに使用することが許可される。例えば、試験結果閲覧の機能は、他の機能がいずれの状態にあっても利用できる。特に長時間、バッチ処理的に自動実行される機能モードをバックグラウンドジョブとして扱ったり、複数の閲覧編集機能を同時に操作して相互にデータの流通を行ったりすることで、ユーザにとって利便性の高い環境を提供できる。上記機能１〜６を実現するにあたり、機能の競合が起きないように、エージェントのＵＩ上のボタン有効・無効の制御と関連する状態遷移の整合をとる必要がある。これらは設計上の施策であるので詳細な説明は省略する。

〈画面事例〉
従来の構成に加えて、ルール分割エディタ、操作ログブラウザ、試験結果ブラウザを有する。

（ルールエディタ）
ルール定義エディタのＧＵＩ（メイン）画面の具体例を図２２に示す。このパネル上では、画像イメージが背景となっており、その上でユーザは図形エディタと同様のマウス操作により矩形を生成配置・移動・リサイズ・削除することができる。この操作によって分割矩形をルール定義の一部として入力する。分割矩形をダブルクリックで選択すると、図２３に示すような分割矩形のパラメータ編集ウィンドウが開く。分割矩形をシングルクリックで選択すると、既に上記ウィンドウが開いている場合は、その内容が選択しているものについての情報に更新される。

これらルール定義データに対しては、ルール名を設定できる。ユーザは図２２のルール名称フィールド２２０１に直接入力することで設定を実施でき、その時点で当該シナリオ内に同じルール名が存在すれば、そのルールデータを他のノードと共有することができる。すなわち、既存のルールデータを読み込んで図形エディタを開く。新しい名前であれば空のルールデータにより図形エディタを開く。

なお、上記図形エディタ上で定義されたルールデータは、編集中のシナリオファイルに含める形で保存されるほか、ユーザの指定によりエージェントがスクリプトごとではなく定常的に参照する操作対象特定ルールファイルに保存することも可能である。シナリオファイル内も操作対象特定ルールファイル内も、そこから読み込まれたルールデータは、スクリプト情報保持部に保持され、再演モードにおいて画像認識部の画像領域特定処理部を経由して、画像領域分割エンジンに送信される。

（操作ログブラウザ）
ユーザに対して、操作ログリポジトリ１１７の内容を任意の検索機能等を使って閲覧する手段を提供する機能及び画面である。ログ閲覧モードに相当する。詳細な説明は省略する。

（試験結果ブラウザ）
ユーザに対して、画像認識試験結果を閲覧する手段を提供する機能及び画面である。試験結果閲覧モードに相当する。詳細な説明は省略する。

＜本発明の詳細な動作＞
〈画像領域特定処理の詳細〉
（画像領域分割エンジンの適用）
本発明では、ウィンドウ画像の内容をパターン認識することで、操作対象ＧＵＩ要素をマウスにより選択可能とするために、画像領域分割エンジンを使用する。画像領域分割エンジンの詳細については先願に示されている。当該エンジンに対しては、予め定められたルールと適用対象の画像領域を入力し、画像内容に応じて相互の関係制約を満たしながら移動可能な複数の区画に分割した結果が出力される。当該ＧＵＩ要素が占める矩形を含む区画を、ウィンドウサイズや内部レイアウトの動的な変動に追随させることで、汎用的なエンジンを画像上の所定の領域の特定に使用している。

（画像領域特定フィーチャー）
取得した矩形領域の内部にマウスポインタを移動することで、オブジェクトアクセス方式と同様に操作対象を実行時に特定し、これに対してオペレータエミュレーション方式によるクリック操作を実行する。すなわち、当該の矩形領域の座標と大きさは、特定すべき対象を画像領域上で指示するデータである。よって、エンジンに入力されるルールは、特定フィーチャー（画像領域特定フィーチャー）の一種であるといえる。

（ルールとラベルのセット型）
分割された矩形にはルール定義内でラベルが付与される。特定したい領域に特別な予約ラベル（例えば「target」など）をつける方法もあるが、１つのルールで得られる複数の分割領域に任意のラベルをつけ、指定したいコントロールに相当するルール定義内のラベルを同時に指定する方法もある。後者は、ルールとラベルのセットによって、特定フィーチャーとなる。後者のほうが、１つのルールで複数のコントロールの特定フィーチャーをつくりだせるため、実用的である。

（分割失敗の場合の考え方）
ウィンドウ内部のＵＩ配置が大きく変化してしまった場合に、画像領域分割が指定されたルール定義のものでは解を得られず、特定に失敗する状況は原理的に常に起こりうる。これは、ルールから対象を特定するに際して、定義作成の当初に想定した範囲の変化ではない場合に相当する。しかし、この状況になったからといって、同じタイトルで同じインスタンスにも拘わらずＧＵＩの見た目が大きく変わってしまった、とは結論できない。全く異なるインスタンスがたまたま同時に存在し一方を他方に取り違えた、という状況も考えなければならない。これは、ウィンドウに適用するルールを選択する時点で、通常はタイトルによって区別しているにも拘わらず、異なるＧＵＩを持つ２つのインスタンスが不幸にも同じタイトルであったなどのケースである。

（ウィンドウ特定への応用）
さらに、自動操作の実行時にデスクトップ上に存在する複数のウィンドウから操作対象ウィンドウを検索する場合、ウィンドウタイトルとウィンドウクラスとプロセス情報をもとにするが、同じウィンドウタイトルの画面が複数発生するなど、これらウィンドウ特定情報がうまく機能しない場合がある。このとき、ウィンドウ内部の画像領域分割のルール定義をウィンドウ特定情報の１つとして利用できる。すなわち、複数の画像領域分割ルール定義をウィンドウ識別子と組にして自動実行シナリオファイルもしくは操作対象特定ルールファイルに保持しておき、特定結果がわからない新たなウィンドウが出現したらば、そのウィンドウ画像に対して保持しているルールを優先度順に適用し、最初に分割処理を成功したもの（領域分割の解が得られたもの）の識別子を採用することが考えられる。また、単に優先度順とするのではなく、ソルバーで得られた解の目的変数の重み付き総和（目的関数）が最も小さいものを採用したり、他の特定情報（ウィンドウやコントロールのタイトル（キャプション）やクラス名（ロール属性）など）を組み合わせたり、と段階的な範囲の絞りこみに基づく識別処理を行うことでユーザの意図に近い判定内容とすることが考えられる。

〈ノード識別子とスクリプト間連携〉
（ノード識別子）
スクリプト同期部１１１を介して、ノード識別子を流通することにより、異なるスクリプト（シナリオ）の対応位置をとりながら、複数の機能を連携させることができる。具体的には以下を行う。

個別シナリオと共通シナリオを同時に記録する場合（例えば提供機能１）、個別シナリオ内のオブジェクトアクセス方式アクションのノードと、共通シナリオ内のノードが、同じノード識別子となるようにシナリオを生成する。

再演モードで実際の操作対象ＡＰを自動操作しながら、それを記録モードで再度記録する、すなわち転写を行う場合（例えば提供機能２）、転写元シナリオと転写先シナリオで対応するノードが、同じノード識別子となるように転写先のノード識別子を設定する。

また、これらの対応によって、副次的に以下の効果が得られる。

シナリオ編集により制御構造を変更した場合、その内容を個別シナリオ、共通シナリオで同じになるように同期をとることができる。

オブジェクトアクセス方式とオペレータエミュレーション方式の２種類のアクションが生成もしくは正常機能できず、一方だけが保持されている場合、当該識別子をキーとして、次の対応ができる。

(1) エージェントがアクション単位でユーザによる例示操作を受け入れるため、シナリオ上の位置を指定し内部モジュール間で共有できる。

(2) アクション単位でユーザによるルールの比較編集を可能とするため、複数のシナリオ間の同じ位置を指定しエディタに読み込める。

（ノード識別子の効果の事例）
以下では、上記構成によって得られる効果の事例を説明する。

例えば、ルックアンドフィールの変更により、オブジェクトアクセス方式だけを有効にしてシナリオを再演している途中で、当該シナリオのあるノードにさしかかったところで、前記方式のアクションを保持していないために、そこで再演が停止したとする。エージェントは、ユーザにルックアンドフィール変更前の操作ログ画面を提示し、同じ操作を新しいＡＰに対して手動で実行するよう警告ダイアログ等で要望する。ユーザが当該アクションを新しいＡＰ上で操作したマウス位置と画面キャプチャを受け取り、新しいオペレータエミュレーション方式のアクションを生成し、シナリオの当該ノードに追加する。以降の再演では、オブジェクトアクセス方式を優先しながら必要に応じオペレータエミュレーション方式を使用する設定を行うことにより、問題となったアクションで停止せずに再演を行うことができる（事例１）。

また例えば、対象ＡＰのバージョンアップで内部実装が変更され、オブジェクトのコレクション内順序が変化したことにより、オペレータエミュレーション方式だけを有効にして再演し、新しいシナリオを並行して記録したとする（転写モード）。転写元シナリオのあるノードにさしかかったところで、前記方式のアクションを保持していなために、そこで転写が停止したとする。エージェントは、事例１と同様、ユーザにマイナーバージョンアップ前の操作ログ画面を提示し、同じ操作を新しいＡＰに対して手動で実行するよう警告ダイアログ等で要望する。ユーザが新しいＡＰ上で操作した内容を、エージェントは記録モードにより受け取り、転写先シナリオの当該ノードに２つの方式のアクションを生成する（事例２）。

また例えば、画像領域分割ルール（画像領域特定フィーチャー）を操作ログ内の画面画像に適用して一括テストし、不具合が見つかった場合に、当該のシナリオの当該のノードをエディタで閲覧してルール内容を確認し、必要な修正を行う。当該シナリオに別途経緯でもととなったシナリオが存在する場合、そのなかから同じノード識別子の特定フィーチャーを参照し、エディタ上でルール定義を閲覧したりコピーしたりして、元の定義内容を取り入れることができる（事例３）。

もととなったシナリオとは、前記事例１のようにルックアンドフィールの変更に対応したときの、以前のシナリオを指す。事例１と同じように、新しい画像領域特定フィーチャーを定義したとして、ユーザ操作からの自動生成されるデフォルトの特定フィーチャーが単純すぎて、実際の画像にそのままでは適用できない場合が考えられる。そこで、もとのシナリオの画像領域分割ルールのフレームをコピーし、そのフレームに組み合わせるテンプレート画像を新しいルックアンドフィールのＡＰから取り直す操作を、ルールエディタ上で行うことで、容易に対応が可能である（事例３−１）。

あるいはまた、もととなったシナリオとは、前記事例２のようにシナリオの転写作業において、事例２のオブジェクトのコレクション内順序ではなくＧＵＩのルックアンドフィールの変化に対応したときの、以前のシナリオを指す。前記と同様、転写により自動生成されるデフォルトの特定フィーチャーでは単純すぎて対応できない場合が考えられる。そこで、当該のアクションについてもとのシナリオのルールをエディタ上で閲覧、コピーすることにより、容易に対応が可能である（事例３−２）。

〈操作ログへの識別子挿入〉
再演モードや記録モードの実行中に、同時に操作ログを取得する場合、当該実行時点のシナリオ上のノードとの対応を操作ログ中に記録していく。具体的には、再演もしくは記録の対象となっているシナリオのシナリオ識別子と実行中のノードのノード識別子を、現在実行アクションの切り替わりを契機に、当該操作ログに出力する。これはスクリプト同期部を介して行われる。

〈特定処理を共通化〉
ルールエディタでは、２種類のルール定義の手段をユーザに提供する。これらはアクションに関する次の２つのカテゴリに対応している。

画像アクションでは、従来のオブジェクトアクセス方式のアクションを、オペレータエミュレーション方式のアクションに置き換える。但し、直接的に置き換えられるアクションは一部のＧＵＩ要素に限られる。すなわち、第１のカテゴリは、マウスクリック１回で実行できるアクションである。例えば、ボタンの押下やチェックの選択である。

そのほかのアクションは部分的な置き換えになる。これが第２のカテゴリである。例えば、テキストフィールドのように文字列値の設定・取得が伴うアクションである。これは一部がマウスクリックでは置き換えられない。またコンボボックスやリストビューなどの選択アクションである。これらは矢印キー押下や複数のマウス操作をともなう。そして、選択肢の内容や前後のフォーカス状態が処理に関係し、それら処理方法が操作対象コントロールの種別に依存して変わるため、特に置き換えが難しい。

ルールエディタで提供するルール定義の手段を、各カテゴリごとに説明する。

まず、第１のカテゴリ、すなわち直接的に置き換え可能なアクションに対しては、オペレータエミュレーション方式によるマウスクリック操作で代替する。クリック対象の領域は、オブジェクト特定処理の結果得られるオブジェクト参照から計算する。これはオブジェクト参照を引数としてウィンドウマネージャやＯＳが提供するＡＰＩを呼び出すことで、当該オブジェクトが描画されている境界矩形のスクリーン上の絶対座標値が得られるので、その中心点をクリック対象とすれば良い。

一方、第２のカテゴリ、すなわち部分的に置き換え可能なアクションに対しては、従来技術と同様、オブジェクトアクセス方式で操作記録・操作再演をする機能を使用しながら、オブジェクト参照の取得方法だけを画像領域特定処理で代替する。すなわち上記ＡＰＩを呼び出し、同じ要領でオブジェクト特定処理の特定フィーチャーを画像領域特定処理の特定フィーチャーに置き換える。再演モードにおいては、前記の特定フィーチャー（画像領域特定）をもとに、画像領域特定処理の特定フィーチャーで一旦、画像領域を取得し、上記ＡＰＩとは逆操作のＡＰＩを呼び出すことで、その座標位置からオブジェクト参照を得る。当該のオブジェクト参照を使用して、操作実行のみ従来の方法（オブジェクトアクセス方式）で実行する。

図２４に本発明におけるアクション再演処理のフレームワークを、図２５に本発明におけるアクションデータのスキーマを、図２６に本発明におけるスクリプトファイルのデータ形式をそれぞれ示す。

＜作業実施例＞
（実施例１）（提供機能１に対応）
提供機能１により、オブジェクトベースと画像ベースの特定結果を突き合わせながらシナリオを実行し、異なる場合は異常停止させる。

（実施例２−１）（提供機能２に対応）
提供機能２により、マイナーバージョンアップが頻繁なＧＵＩに追随できるよう画像ベースで使用する。

（実施例２−２）（提供機能２に対応）
提供機能２により、ルックアンドフィールが異なるＧＵＩに追随できるようオブジェクトベースで使用する。

（実施例２−３）（提供機能２に対応）
提供機能２により、ネイティブ環境で作成したスクリプトをバーチャル環境に適用できるよう画像ベースで使用する。

（実施例３−１）（提供機能３に対応）
提供機能３により、実施例２−１で使用していた画像ベースシナリオ（共通シナリオ）からオブジェクトベースシナリオ（個別シナリオ）を作成する。

（実施例３−２）（提供機能３に対応）
提供機能３により、実施例２−２で使用していたオブジェクトベースシナリオ（個別シナリオ）から画像ベースシナリオ（共通シナリオ）を作成する。

（実施例４）（提供機能４に対応）
実施例１（提供機能１）で異常停止ではなくエラー出力後に処理を継続するようなシナリオを準備し、それにより大量オーダーをバッチ処理する。後に、提供機能４の操作ログリポジトリにおいて、特定エラーが無いか確認し、有れば当該操作箇所を含む前後の履歴を閲覧し、影響や原因を特定する。

（実施例５）（提供機能５に対応）
実施例４で、シナリオ作成時には想定外だった警告ウィンドウが表示される等で失敗している場合、当該ウィンドウの承認ボタンを押すなどの復帰動作を追加で自動化するため、提供機能５により履歴として残っている画像データをもとに共通シナリオを追加修正する。

（実施例６）（提供機能６に対応）
実施例５で、画像領域特定ルールを修正・改善した場合、提供機能６により、過去の当該シナリオ実行の履歴と同じ特定動作をするかどうかを確認する自動試験（回帰試験）を行う。試験結果に問題がある場合は、実施例４により当該操作箇所を含む前後の履歴を閲覧し、過去との互換性を維持するようルールを修正し、再度試験を行う。

（実施例７−１）（提供機能７に対応）
実施例１において、シナリオ実行中に異常停止した場合、手動で修正できるよう特定フィーチャーのエディタを起動する。このとき、両方の特定フィーチャーの情報を参照することで、実際の環境で手動で同じ内容の操作を記録し直したり、直接エディタ上でアクションを作成編集することができる。

（実施例７−２）（提供機能７に対応）
実施例２（２−１〜２−３）において、シナリオ実行中に、必要な特定方式のアクション定義が存在しない場合、手動で定義できるよう特定フィーチャーのエディタを起動する。このとき、他方の特定フィーチャーの情報を参照することで、実施例７−１と同様の作業ができる。

（実施例７−３）（提供機能７に対応）
実施例１〜３において、当該シナリオの過去の実行時の操作ログを参照することで、当該実行時の操作ログ上の画像とイベントを参照することができる。

（実施例７−４）（提供機能７に対応）
実施例４〜６において、操作ログ上の所定の箇所でシナリオ編集が必要な場合、当該箇所に対応するノードの特定フィーチャーについてエディタを起動する。このとき、特定フィーチャーの情報や、当該ノード及び当該操作ログの両方の画像とイベントを参照することで、実施例７（７−１〜７−３）と同様の作業ができる。

（実施例７−５）（提供機能７に対応）
実施例７−１〜７−４において、シナリオ中の異常停止箇所に対して、特定フィーチャーのエディタを起動する場合に、当該ノードのオブジェクト特定フィーチャーと画像領域特定フィーチャーについてそれぞれ所定の編集画面を開くことで、比較・修正することができる。

（実施例７−６）（提供機能７に対応）
実施例７−１〜７−４において、同様に当該ノードのオブジェクト特定フィーチャーと画像領域特定フィーチャーについてそれぞれ所定の編集画面を開き、未定義のフィーチャーについては当該画面上で新規作成することができる。

（実施例８）（提供機能８に対応）
実施例７−１〜７−６において、当該ノードのアクションが第１のカテゴリ（エミュレーション操作処理によって直接的に置き換え可能なアクション）の場合、操作処理はオブジェクトのＡＰＩを呼ぶ処理から、それに等価なエミュレーション操作処理に変換される。また、第２のカテゴリ（部分的に置き換え可能なアクション）の場合、操作処理はオブジェクトＡＰＩを呼ぶ処理のまま残され、再演時には画像領域特定の結果がオブジェクト参照に変換され実行される。以上はオブジェクトアクセス方式からオペレータエミュレーション方式に変換する場合であるが、逆の変換についても同様の処理が行われる。

（そのほか組み合わせの任意性を示す実施例）
（実施例９）
実施例５のあと、共通シナリオをネイティブ環境で実行し、実施例３−１と同じ方法で、共通シナリオに対応する個別シナリオも自動生成する。復帰動作が長い場合、操作ログの履歴から自動的にシナリオが得られ、手間が省ける。

（実施例１０）
実施例９がバーチャル環境上の場合、ネイティブ環境の端末に移動して個別シナリオの自動生成を行う。すなわち、仮想ＰＣやRemoteDesktopであっても、操作ログをもとにして自動生成をして、共通シナリオをまず作成し、それをネイティブ環境に持ち込んで、実施例３−１で個別シナリオも自動生成する。操作ログをバーチャル環境からネイティブ環境に持ち込むよりも、簡単に作業ができる。

≪発明によって生じる効果≫
＜実施例上の効果＞
提供機能１〜３による作業実施例１〜３に示されているように課題１〜３が解決される。すなわち、次の効果がある。

（効果１）エージェント自身が特定処理の特定結果を突き合わせながらシナリオを実行するので、特定結果の誤りの可能性があれば異常停止することができる。

（効果２）適用対象や適用環境の変動があっても、特定フィーチャーのどちらか使える方で再演ができる。対応できないアクションでは停止し、ユーザ操作を促すか、その場で操作アクションを作成し、作業を続行できる。

（効果３）特定フィーチャーの差し替えのために手作業で操作記録をやり直さなくても、どちらか一方のシナリオから他方のシナリオを自動的に記録できる。対応できないアクションでは停止し、ユーザ操作を促すか、その場で操作アクションを作成し、記録を続行できる。

提供機能４〜６による作業実施例４〜６に示されているように課題４〜６が解決される。すなわち、次の効果がある。

（効果４）ユーザがエージェントのミスを見過ごしても、シナリオ再演時の操作ログ履歴を閲覧し、過去に遡って任意場面の前後を確認することで、影響や原因を特定することができる。

（効果５）操作ログ履歴の画像データから、過去に遡って任意場面における共通シナリオを作成でき、再現し難い操作状況でも特定フィーチャーを容易に定義できる。

（効果６）過去の当該シナリオ実行の履歴と同じ特定動作をするかどうかを確認する自動試験を行い、特定フィーチャーのテストデバッグを簡易化できる。

画像領域特定処理として画像領域分割エンジンを本発明を用いて使用することによる効果として以下がある。提供機能２、３、５、６による作業実施例７、８に示されているように課題７、８が解決される。すなわち次の効果がある。

（効果７）再演時もしくは履歴中における特定結果不整合や実行不具合あるいはアクション未定義のシナリオ位置で、適宜にルールエディタを使って編集できるため、画像内容（ＵＩ配置）のパターンが実際の適用・運用の過程で変化する場合でも、ルール修正の稼働を抑制できる。

（効果８）画像領域特定処理をオブジェクト特定処理と統一的に扱うため、アクション単位でオペレータエミュレーション方式とオブジェクトアクセス方式を対応づけて両方保持することができるとともに、特定処理と操作処理を任意の組み合わせで記録・再演するため、シナリオの保守を容易化できる。

そのほか、個別の要素技術における副次的効果として以下がある。

（副次的効果１）エンドユーザが作業の履歴を容易に把握できる。

これは、効果４の一部であるが、自動実行の再演時も記録時も、手動による操作時も、統一的に履歴化できることから、通常の手動作業からシナリオ化すべき部分を抽出したり、既に使用されているシナリオの部分を再利用するあるいは手作業となっていた部分をシナリオに追加する、といった観点でも有用である。

（副次的効果２）ウィンドウの識別を画像ベースで行うことができる。

これは、効果８をウィンドウ制御部に適用した場合に得られる。従来技術では、ウィンドウとコントロールを別々に扱い、それぞれにアドホックな画像認識ルールを適用するアプローチであったため、操作対象やエージェントの実装にシナリオ全体が依存したものになってしまっていた。本発明では、ウィンドウの特定もコントロールの特定と同じく、画像内容からユーザが判断する過程に近い画像領域分割ルールを適用することにより、同じフレームワークで処理することが可能となるため、シナリオの保守性が向上する。

＜実用上の効果＞
（実用上の観点１）
従来の自動操作エージェントの運用においては、適用対象や実行状況によって稀に意図しない動作が行われる場合があった。さらにエージェント動作に画像認識技術を応用する場合は、パターン認識の不確実性の状況から、想定できない画像内容に対して意図しない認識結果が導出される可能性があった。画像認識技術を応用した自動操作エージェントを業務端末の自動実行等の用途に使う場合、仮に上記の不具合が生じても業務に致命的な影響を与えないようなフォロー手段が提供されることが重要である。このような観点で、本発明の構成を用いることにより、以下の実用上の効果が得られる。

（実用上の効果１）
画像認識の不確実性やルール定義の適宜改善を前提とし、誤動作の疑いがある場合に即時かつ確実に検知し、ログ記録もしくは異常停止によりユーザに通知することができる（提供機能１）。さらに、その状況や要因をその場で分析、もしくは事後及び別のＰＣ上にてオフラインで分析（提供機能４）、することができる。また、仮に不具合が生じた場合に、ルール定義を再検討・試行・試験できる使用環境が利用できる（提供機能６）。

具体的には、実行中のシナリオが画像認識すなわちルール適用の過程で当初想定された画像領域と異なる結果となっていないかをユーザが意識しなくても、実運用において常にその場で自動的に検知しユーザ自身がどこで問題が生じたかを簡易に把握（実施例１）することが可能である。仮に問題の影響が大きい場合は、過去の操作ログあるいは他の端末の事例をオフラインで詳細に（実施例４）調査可能である。また、操作ログ上の画像を使用することで、画像認識ルールの修正案を作ることや任意の状況に試すことが容易であるため、最終的な改善内容に対する回帰テストなどを少ない作業稼働で短時間に実施できるため、ルール定義内容の品質管理を確実化・効率化できる（実施例６）。

（実用上の観点２）
自動操作エージェントを大規模な組織で運用すると、有用なシナリオを複数の部署で利用したい場合が考えられる。適用されるＰＣの環境や部署単位・個人単位の環境設定の違いにより、ルックアンドフィールの差異などが発生する場合が考えられる。これらの条件を自動操作エージェントのためだけに全て統一するのは現実的ではなく、また他のＡＰへの影響等を考えると技術的にも困難である。当該のシナリオを使用する場合だけ、このような差異を検知し、必要な環境設定に対してだけシナリオを適合させることが求められる。このような観点で本発明の構成を用いることにより、以下の実用上の効果が得られる。

（実用上の効果２）
適用対象ＡＰのルックアンドフィールの変更があった場合に、エージェント動作への影響（特定結果の不一致）を常に監視し、影響が現れた場合はそれを確実に検知できる（提供機能１）。また、仮にルックアンドフィールの変更の影響が生じた場合に、ユーザ自身がテンプレート画像を差し替えた同じ内容のシナリオの再作成を効率よく行え（提供機能３）、さらにその修正後シナリオの回帰テストを省稼働、短時間で完了し、テスト結果の記録・整理により高信頼・高効率な品質管理ができる（提供機能６）。

具体的には、実行中のシナリオが当初想定されたルックアンドフィールと異なる対象かどうかをユーザが意識しなくても、実運用において常に全ての端末環境上で実行時チェック（実施例１）を行うことが可能である。また、仮に影響が検知された場合は、ユーザが指定することにより、オブジェクトベースでシナリオを動作させながら共通シナリオを作成することができる（実施例３）。得られた共通シナリオを過去の自動操作時の操作ログに適用し、操作対象の特定結果を比較することにより、意図した修正ができているかを確認することができる（実施例６）。

（実用上の観点３）
自動操作エージェントを長期間にわたって運用すると、有用なシナリオを継続的に利用したい場合が考えられる。適用対象ＡＰのバージョンアップにより、内部仕様が部分的に変化したものの、ＧＵＩ要素の構成やシナリオ上の操作順序に大きな変化がない場合、シナリオをこれに対応させるために、全ての箇所の修正要否を調査し、実際に修正作業を行うのは大きな稼働がかかる。マイナーバージョンアップなどのように小さな変化であれば、それに見合った稼働におさえることが求められる。このような観点で本発明の構成を用いることにより、以下の実用上の効果が得られる。

（実用上の効果３）
適用対象ＡＰのマイナーバージョンアップがあった場合に、「実用上の効果２」と同様に、特定結果の不一致を常に監視し、影響が現れた場合はそれを検知する（提供機能１）。また、仮にマイナーバージョンアップの影響が生じた場合に、ユーザ自身が新たな特定フィーチャーによる同じシナリオの再作成を効率よく行うことができる（提供機能３）。

具体的には、実行中のシナリオが当初想定された内部オブジェクト構成とは異なる対象に適用され、特定処理に影響が表れていないかを、ユーザが意識しなくても実運用において常に全ての端末環境上で実行時チェック（実施例１）を行うことが可能である。また、影響が検知された場合は、ユーザが指定することにより、画像ベースでシナリオを動作させながら個別シナリオを作成することができる（実施例３）。

（実用上の観点４）
適用対象ＡＰを通常の端末上でシナリオ記録し、画像ベースでもオブジェクトベースでもいずれでも実行可能であったとする。当該シナリオをバーチャル環境内の同じＡＰに適用する必要が生じた場合、シナリオを修正することなく画像ベースで実行することが求められる。さらに、バーチャル環境内での画像ベースでの実行中に、シナリオ作成当初は想定していなかった警告ダイアログが出現した場合、当該ダイアログの確認ボタンを押下し、必要な対処操作を行う内容のシナリオの追加を、画像ベースで行うことができれば有用である。さらに、このように作成した追加部分はオブジェクトベースのアクションが未定義なため、通常の端末上での実行機会を得た際に、当該オブジェクトベースのアクションを作成することができれば有用である。このような観点で本発明の構成を用いることにより、以下の実用上の効果が得られる。

（実用上の効果４）
通常の端末で記録したシナリオをバーチャル環境の中のＡＰに外から適用する場合、自動操作エージェントに画像ベースでの動作を指定して、自動操作を実行する（提供機能２）。また、実行中もしくは操作ログ履歴において画像領域特定結果が意図した対象になっていない場合、シナリオ上の当該ノードに対応するアクションの特定フィーチャー（画像領域分割ルール）をエディタで編集し（提供機能７）、新しいルールの回帰テストを操作ログ履歴上で行うことで機能の互換性を確認し品質を担保する。

具体的には、通常の端末で記録したシナリオを実行する際に、画像ベースのアクションを優先するようユーザが指定することにより、バーチャル環境の中のＡＰに適用することができる（実施例２）。当該シナリオを実行中に、操作対象の特定が意図したものと違っていることにユーザが気付いた場合、その時点でのシナリオ上のアクションの特定フィーチャーのエディタ画面をユーザが開き、ルール内容を確認することができる。ユーザはルールの内容を閲覧するのみではなく、過去の操作ログ上の任意の画像に適用するなどで振る舞いを確認でき、必要があれば同様のシナリオ実行時の他のログを調べ、特定結果を比較したり、そのときの画像に適用するなどで網羅的な調査が可能である（実施例７）。

（実用上の観点５）
自動操作エージェントの特徴として、自動化が必要な作業に対して、それに従事しているユーザ自身がシナリオを作成し、利用・改良を行うことで、ボトムアップな業務効率化に役立つ点が挙げられる。また、熟練ユーザのシナリオや改善効果の高いシナリオを複数のユーザに展開・共有し、それに対する改良を組織的に行うことで、業務の標準化に役立つ点が挙げられる。この特徴を活用するためには、エージェントの利用に不慣れなユーザでもシナリオや特定ルールを、実際の操作ログや画面キャプチャをもとに作成できること、修正が必要な個所の調査や当該箇所の修正手段が直接的に提供されることが求められる。このような観点で本発明の構成を用いることにより、以下の実用上の効果が得られる。

（実用上の効果５）
企業内の業務において、人数が少なく多拠点に分散している業務に熟練したユーザの知見をシナリオの策定に反映し、組織的にシナリオを作成・管理するために、過去の他端末の操作ログを活用して、共通シナリオを作成することができる（提供機能５）。また、複数の端末での使用で、ルックアンドフィールが異なる設定となっている端末環境があった場合や、組織間や長期間の運用で、部分的に異なる内部実装のマイナーバージョンが存在する対象ＡＰがあった場合、共通シナリオの試用や改善を短期サイクルで実施するために、当該シナリオの一部が展開先環境で実行できないときは、当該環境上でのユーザが適宜にアクション単位での再作成・再修正ができる（提供機能８）。

具体的には、例えば、業務主管がネイティブな端末環境で適用対象のＡＰを実行でき、業務ユーザが遠隔デスクトップ上で当該ＡＰを実行できる運用環境を想定する。業務主管が基本となるシナリオ案をネイティブ環境で作成し、各現場に展開する。現場ユーザは画像ベースで仮想デスクトップ上における試用を行い、業務的なトラブル事例の操作ログを一定期間蓄積し、業務主管に集約する。業務主管では、得られた操作ログから画像を参照することで、シナリオへの追加修正を効率よく行うことができる（実施例５）。特に画像ベースでのルール作成のために逐一当該ウィンドウが現れる箇所まで対象ＡＰを操作する必要がないため、状況の再現が難しい場合に有効である。各組織からの知見を集約したシナリオを、各現場に改善後のシナリオを展開し、各環境でのテスト及び業務観点のレビューを行う。この際、業務主管のネイティブ環境で実行することで、シナリオをオブジェクトベースで作成し直し、さらに展開先の各環境にあわせて画像ベースで修正する必要があるが、全てのアクションについて完全に変換を完了する必要はなく、重要な部分を優先してアクション単位で展開先への適合化を行い、未対応の部分は方式間での代替もしくは手動対応により、シナリオを実行することができる（実施例８）。

なお、本発明の装置はコンピュータとプログラムによっても実現でき、当該プログラムは記録媒体に記録して提供することも、ネットワークを通じて提供することも可能である。

１：コンピュータ、２：内部メモリ、３：システムバス、４：ＣＰＵ、５：表示装置、６：入力装置、７：ハードディスク（記憶装置）、２０：操作対象アプリケーション、３０：オペレーティングシステム（ＯＳ）、５０：操作ログファイル、６０：試験結果ファイル、１００：自動操作エージェント、４００：自動操作スクリプトファイル、
１０１，１０２：コントロール制御部、１０３，１０４：ウィンドウ制御部、１０５，１０６：マウス・キーボード制御部、１０７，１０８，１２０：画像認識部、
１０９：記録スクリプト制御部、１１０：再演スクリプト制御部、１１１：スクリプト同期部、１１２：特定結果照会部、１１３：特定結果変換部、１１４：操作内容変換部、１１５：操作ログ取得ＩＦ、１１６：操作ログ再生ＩＦ、１１７：操作ログリポジトリ、１１８：操作ログブラウザ、１１９：画像認識試験部、１２１：試験結果格納部、１２２，１２３，１２４：画像領域分割エンジン、１２５：試験結果ブラウザ、
１３０：スクリプトエディタ、１３１：シナリオエディタ、１３２：プロファイルエディタ、１３３：分割ルールエディタ。

特開平１１−３２７９５５号公報 特許第４３８１４３６号公報

Claims (10)

1. コンピュータ上で動作する操作対象アプリケーションのＧＵＩに対するユーザの操作をシナリオとして記録するとともに、当該シナリオを再生することで前記操作対象アプリケーションのＧＵＩに対するユーザの操作をコンピュータ上で再演する装置であって、
   ＧＵＩプラットフォームのＡＰＩを介して操作画面上のＧＵＩオブジェクトにアクセスするオブジェクト特定処理を行う第１の手段と、
   画像認識技術を用いて操作画面上のＧＵＩ要素を操作対象として認識する画像領域特定処理を行う第２の手段と、
   ユーザ操作のアクション単位を示す識別子を発行する第３の手段と、
   第１の手段によるユーザ操作のアクション単位の処理結果を個別シナリオとして前記識別子とともに記録し、且つ第２の手段によるユーザ操作のアクション単位の処理結果を共通シナリオとして前記識別子とともに記録する第４の手段と、
   第１の手段を前記個別シナリオに従って動作させるとともに第２の手段を前記共通シナリオに従って動作させてユーザの操作を再演させ、第１の手段及び第２の手段による操作対象をユーザ操作のアクション単位で突き合わせて相互チェックする第５の手段と、
   を備えた
   ことを特徴とする画像認識による自動操作装置。
2. 前記に加え、
   ユーザの指定に従い、個別シナリオ又は共通シナリオのいずれか一方のみにより、第１又は第２の手段によってユーザの操作の再演を実行させる第６の手段、を備えた
   ことを特徴とする請求項１に記載の画像認識による自動操作装置。
3. 前記に加え、
   記録モード並びに再演モードにそれぞれ対応させた前記第１及び第２の手段を設けるとともに、
   ユーザの指定に従い、個別シナリオ又は共通シナリオのいずれか一方のみにより、再演モードに対応する第１又は第２の手段によってユーザの操作の再演を実行させると同時に、記録モードに対応する第１の手段によるユーザ操作のアクション単位の処理結果を新たな個別シナリオとして前記識別子とともに記録し、且つ記録モードに対応する第２の手段によるユーザ操作のアクション単位の処理結果を新たな共通シナリオとして前記識別子とともに記録する第７の手段、を備えた
   ことを特徴とする請求項２に記載の画像認識による自動操作装置。
4. 前記に加え、
   記録モード並びに再演モードにおけるマウス操作時の画面キャプチャ画像及びマウス操作イベントを少なくとも含む操作ログを蓄積する第８の手段、を備えた
   ことを特徴とする請求項１乃至３のいずれかに記載の画像認識による自動操作装置。
5. 前記に加え、
   前記蓄積した操作ログから過去の画面キャプチャ画像及びマウス操作を参照し、共通シナリオを自動生成する第９の手段、を備えた
   ことを特徴とする請求項４に記載の画像認識による自動操作装置。
6. 前記に加え、
   前記蓄積した操作ログをもとに画像領域特定処理のシミュレーションテストを行う第１０の手段、を備えた
   ことを特徴とする請求項５に記載の画像認識による自動操作装置。
7. 前記に加え、
   オブジェクト参照を画像領域に変換する第１１の手段、を備えた
   ことを特徴とする請求項４に記載の画像認識による自動操作装置。
8. 前記に加え、
   オブジェクトＡＰＩ呼び出しをマウスクリックエミュレーションに変換する第１２の手段、を備えた
   ことを特徴とする請求項７に記載の画像認識による自動操作装置。
9. コンピュータ上で動作する操作対象アプリケーションのＧＵＩに対するユーザの操作をシナリオとして記録するとともに、当該シナリオを再生することで前記操作対象アプリケーションのＧＵＩに対するユーザの操作をコンピュータ上で再演する方法であって、
   前記コンピュータ又は前記コンピュータにネットワークを介して接続された他のコンピュータが、
   ＧＵＩプラットフォームのＡＰＩを介して操作画面上のＧＵＩオブジェクトにアクセスするオブジェクト特定処理手段と、画像認識技術を用いて操作画面上のＧＵＩ要素を操作対象として認識する画像領域特定処理手段とを用いて、
   オブジェクト特定処理手段によるユーザ操作のアクション単位の処理結果を個別シナリオとしてユーザ操作のアクション単位を示す識別子とともに記録し、且つ画像領域特定処理手段によるユーザ操作のアクション単位の処理結果を共通シナリオとして前記識別子とともに記録する工程と、
   オブジェクト特定処理手段を前記個別シナリオに従って動作させるとともに画像領域特定処理手段を前記共通シナリオに従って動作させてユーザの操作を再演させる工程と、
   オブジェクト特定処理手段及び画像領域特定処理手段による操作対象をユーザ操作のアクション単位で突き合わせて相互チェックする工程とを備えた
   ことを特徴とする画像認識による自動操作方法。
10. コンピュータを、請求項１乃至８のいずれかに記載の装置の各手段として機能させるためのプログラム。

Images