JP2024014066A - 制御プログラム、制御方法および制御装置 - Google Patents

Abstract

【課題】トラブルの解決にかかる時間を短縮化することを課題とする。【解決手段】ロボットは、所定の操作を実行し、所定の操作を実行すると、所定の操作による操作対象の撮像および所定の操作により発生する操作データの取得を実行する。ロボットは、撮像された操作対象に関する撮像データおよび取得された操作データを記憶部に保存する。【選択図】図１

Description

本発明は、制御プログラム、制御方法および制御装置に関する。

ＲＰＡ（Robotic Process Automation）技術を使用し、人手により実施していた業務を自動化または効率化する業務改善や業務改革が進んでいる。ＲＰＡは、ＲＰＡ用の開発環境を用いてＲＰＡロボット（以下、ロボットと記載する）を生成し、生成したロボットを実行させることにより、予め規定した業務をロボットに代行させる。ロボットの処理を開発環境で開発、動作検証、テストを行った後、実際にユーザの業務を代行させる本番環境に、開発したロボットのプロセスを配備し、ロボットを運用することが一般的である。

ロボットの開発会社等は、ロボットの運用者に対して、ロボットの運用および保守の支援サービスを提供している。例えば、開発会社等は、支援サービスとして、顧客のＲＰＡシステムやロボットに対して処理修正、処理追加の実装、バージョンアップを含むメンテナンスやエンハンスを提供する。そして、開発会社等は、トラブルが発生した際に、顧客からメール等でＱ＆Ａを受け付け、顧客内トラブルの解決を支援する。また、開発会社等は、ＲＰＡ検証環境内でのトラブル事象再現、トラブルの解決手段の調査や検証を行い、トラブル解決に向けた支援も行う。

国際公開第２０１８／１５１３０３号

しかしながら、上記支援サービスでは、運用者側のトラブルの認識違い等により、運用者側から提供されるトラブル時の情報に不足や漏れが発生し、トラブル事象を再現することができず、トラブルの解決が長期化することがある。

一つの側面では、トラブルの解決にかかる時間を短縮化することができる制御プログラム、制御方法および制御装置を提供することを目的とする。

第１の案では、制御プログラムは、コンピュータに、所定の操作を実行し、前記所定の操作を実行すると、前記所定の操作による操作対象の撮像および前記所定の操作により発生する操作データの取得を実行し、撮像された前記操作対象に関する撮像データおよび取得された前記操作データを記憶部に保存する、処理を実行させることを特徴とする。

一実施形態によれば、トラブルの解決にかかる時間を短縮化することができる。

図１は、実施例１にかかるロボット制御システムの全体構成例を説明する図である。 図２は、実施例１にかかるロボット制御システムにおけるエラー対応を説明する図である。 図３は、実施例１にかかるロボットの機能構成を示す機能ブロック図である。 図４は、操作管理ＤＢを説明する図である。 図５は、通知情報管理ＤＢを説明する図である。 図６は、エラー発生時の採取処理を説明する図である。 図７は、実施例１にかかるロボット制御システムが実行する処理の流れを示すフローチャートである。 図８は、実施例２にかかるロボットの機能構成を示す機能ブロック図である。 図９は、操作時刻管理ＤＢを説明する図である。 図１０は、実施例２にかかる処理を説明する図である。 図１１は、実施例２にかかるロボット制御システムが実行する処理の流れを示すフローチャートである。 図１２は、ハードウェア構成例を説明する図である。

以下に、本願の開示する制御プログラム、制御方法および制御装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

（全体構成）
図１は、実施例１にかかるロボット制御システムの全体構成例を説明する図である。図１に示すように、ロボット制御システムは、ＲＰＡ（Robotic Process Automation）技術が適用されたロボット５０を有し、ロボット５０がＲＰＡによる自動操作対象リソース９０に関する操作（ＲＰＡ操作）を自動実行するシステムである。

ロボット５０は、開発段階で、ロボット開発者により実施例１で説明する機能が実装された制御装置の一例であり、開発完了後に本番環境に配備される。すなわち、ロボット５０は、ＲＰＡロボットのエージェントアプリケーションがインストールされ、ＲＰＡ操作を実行する。

例えば、ロボット５０は、ロボット運用者が使用するコンピュータから、実行リクエスト（命令）を受信し、ＲＰＡによる自動操作対象リソース９０に関する操作を実行する。例えば、ＲＰＡによる自動操作対象リソースとは、Ｗｅｂサイト、社内外サイト、デスクトップアプリケーションなどの予め操作対象として指定されたリソースである。ＲＰＡによる自動操作対象リソースに関する操作とは、これらのリソースに対するアクセスや所定情報の検索などを含むモニタリングや定期チェックなどの定期的に行われる操作である。

ロボットの開発会社等は、ロボットの運用者に対して、ロボットの運用および保守の支援サービスを提供しているが、運用者側のトラブルの認識違い等により、運用者側から提供されるトラブル時の情報に不足や漏れが発生し、トラブル事象を再現することができず、トラブルの解決が長期化することがある。

（参考技術の問題点）
ここで、ＲＰＡロボット５０の実行時のエラーによりトラブルが発生した場合に、顧客自体が完全に再現手順を把握できていないこともあり、以下の理由により、詳細な再現手順が不明確となることがある。

例えば、サービス提供元でトラブル調査を行うにあたり、顧客環境内で発生したトラブル情報や環境情報等を元にトラブルの再現から事象確認と、エラー情報の詳細確認からトラブルの解決方法の検討と、根本原因究明と、解決方法による解決確認と、顧客への解決方法の回答、の手順が行われる。しかし、顧客側からの情報提供が不足している場合や、顧客自体がトラブル発生の再現手順や情報に誤解がある場合は、上記手順を行う前提が崩れてしまう。つまり、顧客側がトラブル情報を正確に採取できない限り、正しいトラブル解決方法の回答ができず、かつ顧客トラブル解決に至らない。トラブル解決が難航するケースでは、顧客自体がトラブルの再現手順を正確に把握できず、サポート側での調査やトラブル再現、解決方法の検討や回答が遅延することが原因となる。

このようなことから、近年では、ロボット５０の開発や運用環境のサポートを行う状況下において、トラブルの詳細な再現手順を明確化させる手法が要求されている。ところが、トラブルの詳細な再現手順を明確化させる手法を難しくさせる理由として、ＲＰＡ固有の問題も上げられる。

例えば、トラブル事象の再現時において、再現時の考慮事項が「ＲＰＡの処理」に閉じていない。つまり、ロボット５０の処理や操作の設定が行われたソースコード等の調査がデバッグでは解決できない。ロボット５０（ＲＰＡ）は、外部のシステム、アプリケーション、Ｗｅｂサイト等を直接操作することを前提としたソフトウェアのエージェントアプリケーションである。ロボット５０の運用や保守時において発生したトラブルは、そのロボット５０が操作対象とする全ての外部システム、アプリケーション、Ｗｅｂサイトの影響を受ける可能性がある。従って、ロボット５０の運用および保守時のトラブル解決は、一般的なアプリケーションやシステム等のトラブル解決よりも難航する可能性が高い。

ここで、ＲＰＡ固有の問題点の具体例を説明する。例えば、ＲＰＡロボットでシステムＡの自動操作を行っているケースを例に挙げる。ここでシステムＡの「××ボタン」をクリックする処理について、このクリック処理は特定のブラウザの特定のバージョンであれば動作するが、それ以外のブラウザもしくは他バージョンを使用していると動作しないと仮定する。保守時において、保守者がブラウザを変更ないしバージョンアップすると、システムＡの「××ボタン」をクリックする処理が正常稼働せずにエラーが発生する。ここで、保守者はブラウザのバージョンアップが直接的なトラブル影響原因と想定し、解決方法の回答を支援サービス者に連絡するが、「ＲＰＡ」の支援サービス者は上記システムＡの「××ボタン」の仕様についてはこの段階では把握できないため、トラブル解決が難航する。なぜなら、この事象の根本原因は、システムＡの構築者ないしは運用者しかわからないためである。

（参考技術の改善策）
上記ＲＰＡ固有の課題を解決する手法として、（１）ＲＰＡ製品のログ等の情報採取ツールを使用する手法、（２）ロボットの操作対象システムの運用者に問い合わせる手法、（３）トラブルが発生した顧客環境のシステムで再現調査および検証を行う手法が知られている。

（１）について、ＲＰＡ製品では、ロボットやシステムから出力されるログファイル、及びその他の情報採取ツールが提供されている場合がある。この情報採取ツールを使用することにより、ロボットのトラブル発生時の情報採取を円滑かつ自動的に行わせる。

（２）について、ＲＰＡロボットの操作エラーが発生した対象システムの運用者に仕様を問い合わせし確認するが、システム仕様が公開されている場合、公開情報を調査する。（３）について、実際にトラブルが発生した顧客環境（ロボット動作環境）を直接または間接で使用させてもらい、トラブルの再現調査および検証を行う。

ところが、上記（１）、（２）、（３）についても以下の課題がある。（１）についての課題は、ＲＰＡ製品のログ等の情報採取ツールを使用しても、トラブルの再現手順に関する情報自体は得られないことである。あくまでも、ロボットのログ情報やロボットの動作環境情報のみしか採取できない。

（２）についての課題は、顧客がサポートサービス員に問い合わせを行う際に、システムの仕様影響によるトラブル発生と想定しない場合、本対処の実施優先度が下がるため、結果的にトラブル調査が難航することである。また、初期調査の段階では、ＲＰＡ製品がエラー原因か、システム仕様影響がエラー原因かの判断は顧客には困難であるため、実質初期対処でこの方法を取ることができないことである。

（３）についての課題は、トラブル調査において最終的に採用する方法であり、初期調査段階では顧客運用への影響等から実施できないことであり、また、顧客環境固有のトラブル発生要因が生じていることを特定できない限り、顧客運用影響から採用されないことである。

上述したように、いずれの手法（１）、（２）、（３）を用いたとしても、上記問題点を端的に解決できず、トラブルの解決にかかる時間を短縮化できるとは言い難い。

（実施例１の説明）
上記問題点に対して、実施例１にかかるロボット５０は、所定の操作を実行し、所定の操作を実行すると、所定の操作による操作対象の撮像および所定の操作により発生する操作データの取得を実行する。そして、ロボット５０は、撮像された操作対象に関する撮像データおよび取得された操作データを記憶部に保存する。

図２を用いて具体的に説明する。図２は、実施例１にかかるロボット制御システムにおけるエラー対応を説明する図である。図２に示すように、ロボット５０は、ロボット運用者の指示操作やスケジュールによる自動実行により、自動化対象９０に対する所定の操作を実行する（Ｓ１）。

そして、ロボット５０は、所定の操作が実行されると、所定の操作による操作対象の撮像および所定の操作により発生する操作データの取得を実行する（Ｓ２）。例えば、ロボット５０は、エラー発生に備えて、ロボット５０がＷｅｂサイトから検索結果を取得するための一連の操作の動画データを撮像し、Ｗｅｂサイトのキャプチャ画像を撮像し、エラーが発生する前から操作が完了するまでに出力されたログデータを取得し、エラーの発生箇所を示すＵＲＬ（Uniform Resource Locator）などを採取する。

続いて、ロボット５０は、撮像された操作対象に関する撮像データおよび採取された操作データを記憶部に保存する（Ｓ３）。例えば、ロボット５０は、エラーを特定する情報に対応付けて、一連の操作の動画データ、Ｗｅｂサイトのキャプチャ画像し、ログデータを取得し、エラーの発生箇所を示すＵＲＬを保存する。

その後、ロボット５０は、エラーの発生およびエラー情報の採取完了をロボット開発者、ロボット運用者、サポートサービス員などの関係者に通知し、関係者が収集された情報を用いてエラー解析を実行する（Ｓ４）。

つまり、ロボット５０は、ＲＰＡ操作の実行過程において、エラーが発生した前後の外部リソース９０の操作過程情報を自動的に取得することで、エラー発生時のロボットの外部リソース操作履歴及びエラー発生に関与した外部リソース情報を全て採取する。この結果、ロボット５０は、トラブル時の情報に不足や漏れを抑制し、トラブル事象の再現を短時間で適切に実行できる情報を提供することで、トラブルの解決にかかる時間を短縮化することができる。

（機能構成）
図３は、実施例１にかかるロボット５０の機能構成を示す機能ブロック図である。図３に示すように、ロボット５０は、通信部５１、出力部５２、記憶部５３、制御部６０を有する。

通信部５１は、他の装置の間の通信を制御する処理部であり、例えば通信インタフェースなどにより実現される。例えば、通信部５１は、ロボット運用者から命令（実行リクエスト）を受信し、関係者に各種情報やエラー通知などを送信する。

出力部５２は、各種情報を表示出力する処理部である。例えば、出力部５２は、ロボット５０がＲＰＡによる自動操作対象リソース９０に関する操作対象であるＷｅｂサイト等を表示する。

記憶部５３は、各種データや制御部６０が実行するプログラムなどを記憶する処理部であり、例えばメモリやハードディスクなどにより実現される。この記憶部５３は、操作管理ＤＢ５４、通知情報管理ＤＢ５５、採取結果ＤＢ５６を記憶する。

操作管理ＤＢ５４は、ＲＰＡ操作に関する情報を記憶するデータベースである。具体的には、操作管理ＤＢ５４は、ＧＵＩ操作の内容および操作対象を記憶する。図４は、操作管理ＤＢ５４を説明する図である。図４に示すように、操作管理ＤＢ５４は、「プロセスＩＤ、ＧＵＩ操作ＩＤ、ＧＵＩ操作処理、ＧＵＩ詳細情報」を対応付けて記憶する。

ここで記憶される「プロセスＩＤ」は、プロセスを識別する情報である。「ＧＵＩ操作ＩＤ」は、ＲＰＡ操作の一例であるＧＵＩ操作を識別する情報である。「ＧＵＩ操作処理」は、ＧＵＩ操作の処理内容を示す情報である。「ＧＵＩ詳細情報」は、ＧＵＩ操作の具体的な処理内容を示す情報である。図４の例では、プロセスＩＤ＝１が付与されたＧＵＩ操作ＩＤ＝１のＧＵＩ操作は、ＨＴＭＬ（Hyper Text Markup Language）アプリの「ｃｈ.ｅｘｅ」を実行して「タイトル＝ｔｅｓｔ」のＷｅｂサイトを表示し、ＳＰＡＮタグで指定される「ｔｅｓｔ１．ｔａｇ」をＲＰＡ操作対象のエレメント（ａａｎａｍｅ）として選択し、選択した「ｔｅｓｔ１．ｔａｇ」の「クリック操作」を実行する操作であることが定義されている。

なお、操作管理ＤＢ５４は、図４に示した情報以外にも、実行頻度などを記憶することもできる。例えば、操作管理ＤＢ５４は、「プロセスＩＤ＝１」に対して、「実行頻度＝毎日１３：００」などをさらに記憶することもできる。つまり、操作管理ＤＢ５４は、スケジュールにより自動実行のための情報を記憶することもできる。

通知情報管理ＤＢ５５は、エラー発生の通知やエラー情報の取得完了などの通知先を記憶するデータベースである。図５は、通知情報管理ＤＢ５５を説明する図である。図５に示すように、通知情報管理ＤＢ５５は、「ＩＤ、プロセスＩＤ、通知先メールアドレス」を対応付けて記憶する。

ここで記憶される「ＩＤ」は、通知情報管理ＤＢ５５内のレコードを識別する情報である。「プロセスＩＤ」は、プロセスを識別する情報である。「通知先メールアドレス」は、管理者等のメールアドレスである。図５の例では、プロセスＩＤ＝１のＲＰＡ操作でエラーが発生した場合の通知先が「ａａａ＠ｘｘｘ．ｃｏｍ」であることが定義されている。なお、「通知先メールアドレス」以外にも電話番号やＳＮＳ（Social Networking Service）の番号のように、様々な連絡先を採用することができる。

採取結果ＤＢ５６は、ＲＰＡ操作時に採取された各種データであって、エラーが発生したＲＰＡ操作時の採取結果を記憶するデータベースである。例えば、採取結果ＤＢ５６は、ＲＰＡ操作またはエラーごとに、ロボット５０がＷｅｂサイトから検索結果を取得するための一連の操作さ撮像された動画データし、Ｗｅｂサイトのキャプチャ画像、エラーが発生する前から操作が完了するまでに出力されたログデータ、エラーの発生箇所を示すＵＲＬなどを記憶する。

制御部６０は、ロボット５０全体を司る処理部であり、例えばプロセッサなどにより実現される。この制御部６０は、操作実行部６１、エラー検知部６２、採取部６３、通知部６４を有する。なお、操作実行部６１、エラー検知部６２、採取部６３、通知部６４は、プロセッサが有する電子回路やプロセッサが実行するプロセスなどにより実現される。

操作実行部６１は、ＲＰＡ操作を実行する処理部である。具体的には、操作実行部６１は、操作管理ＤＢ５４に記憶される情報、または、図示しないロボット５０を遠隔操作するＲＰＡサーバからの実行リクエストにしたがって、ＲＰＡ操作として外部リソース９０に対するＧＵＩ操作を実行する。例えば、操作実行部６１は、プロセスＩＤ＝１の実行リクエストを受信した場合、図４に示す「クリック操作」を実行する。なお、操作実行部６１は、実行結果を記憶部に記憶させたり、予め指定された指定先に通知したりする。

エラー検知部６２は、ＲＰＡ操作実行時のエラー発生を検知する処理部である。例えば、エラー検知部６２は、ＲＰＡ操作実行時に、操作対象のリソース９０からの応答によりエラーを検知すると、エラー発生を採取部６３に通知する。なお、エラー検知部６２は、ＲＰＡ操作実行時に、ロボット５０へのログインエラー、ロボット５０のメモリ不足、ロボット５０のＲＰＡ操作の読み取りエラーなどを含むロボット５０内のエラーも検知する。すなわち、エラー検知部６２は、ロボット５０自体のエラー、ＲＰＡ操作自体のエラー、操作対象のリソース９０側のエラーなどエラー種別に関係なく検知する。

採取部６３は、ＲＰＡ操作実行中に、外部リソース９０に対するＲＰＡ操作の過程の撮像、および、ＲＰＡ操作で発生するログ情報の取得を実行する処理部である。例えば、採取部６３は、ＧＵＩ操作で発生する各画面の遷移過程の動画と遷移過程における各画面の撮像、および、ログ情報の取得を実行する。そして、採取部６３は、エラー検知部６２によりエラー発生が検知され後、ＲＰＡ操作が終了すると、動画の撮像や画像の撮像を終了し、採取された各データを採取結果ＤＢ５６に格納する。なお、採取部６３は、ＲＰＡ操作がエラー検知部６２によりエラー発生が検知されずに正常終了した場合、動画の撮像や画像の撮像を終了し、採取された各データを削除する。

図６は、エラー発生時の採取処理を説明する図である。図６に示すように、時刻Ｔ０で、操作実行部６１がＷｅｂサイトＡにアクセスし、時刻Ｔ１で、操作実行部６１がクリック操作（ＲＰＡ操作）を実行する。そして、時刻Ｔ２で、エラー検知部６２によりエラーが検出され、その後の時刻Ｔ７まで操作実行部６１によりダブルクリック操作（ＲＰＡ操作）が実行される。

この場合、採取部６３は、ＲＰＡ操作の開始と同時に、動画を撮像するカメラを起動し、エラー発生後のＧＵＩ操作で発生する各画面の遷移過程の動画データを採取する。例えば、採取部６３は、時刻Ｔ１のクリック操作から、エラー発生後の時刻Ｔ２を含むＲＰＡ操作が終了する時刻Ｔ７までに実行される一連の操作および表示画面を含む動画を撮像して動画データを採取する（図６の（ａ）参照）。

また、採取部６３は、画像を撮像するカメラを起動し、ＰＲＡ操作開始後の各ＧＵＩ操作で発生する各画面の画像データを採取する。例えば、採取部６３は、時刻Ｔ１のクリック操作の画面、時刻Ｔ３で出力されるエラー画面Ｂ、時刻Ｔ４でダブルクリック操作後の時刻Ｔ５で出力されるエラー画面Ｃ、時刻Ｔ６で操作実行部６１がＲＰＡ操作を終了した後の時刻Ｔ７で出力される終了画面Ｄを撮像して画像データを採取する。

また、採取部６３は、時刻Ｔ２のエラー発生に伴い出力されるログＡ２、時刻Ｔ３のエラー画面Ｂの表示に伴い出力されるログＡ３、時刻Ｔ４のダブルクリック操作に伴い出力されるログＡ４、リトライ後の時刻Ｔ５のエラー画面Ｃの表示に伴い出力されるログＡ５、時刻Ｔ６のＲＰＡ操作終了に伴い出力されるログＡ６、時刻Ｔ７の終了画面の出力に伴い出力されるログＡ７を採取する。さらに、採取部６３は、エラー発生の起点となったＲＰＡ操作（クリック操作）実行に伴い時刻Ｔ１で出力されたログＡ１も採取する。

すなわち、採取部６３は、ＲＰＡ固有要因として、単純に「ＲＰＡのロボットエージェント、及びその上で動作するプロセス」の処理過程情報を採取するわけではなく、ＲＰＡが外部リソース９０の操作を実施するがゆえに、内部アプリケーションのログおよび内部アプリケーション以外のログ情報も取得する。そして、採取部６３は、採取された各データを採取結果ＤＢ５６に格納し、採取が完了したことを通知部６４に通知する。

ここで、ＲＰＡ操作の動画撮像について更なる工夫について説明する。ロボット５０に対して、特定システムにブラウザでアクセスしてログインし、特定の画面遷移を経て、特定のデータ登録処理を行う操作を自動化させた場合に、動画の撮像だけでは画面遷移速度が速すぎる場合や画像撮像では局所的な情報採取にしかなりかねない場合がある。例えば、ＲＰＡでは数ミリ秒単位でのシステム操作が可能であるため、動画撮像による画面確認や記録が追い付かないケースがある。したがって、動画データやキャプチャ画像データの採取だけでは採取しきれない情報を、トラブル時の情報採取時に限り実行可能な採取ツールを具現化する要求される。また、開発環境上でデバッガを使用して動作確認する手法も存在するが、運用環境上での動作方法でなければエラーを再現できないケースもあり、適切な手法とは言い難い。

そこで、実施例１にかかるロボット５０の採取部６３は、ＧＵＩ操作中にエラーが発生した場合に、ＧＵＩ操作の操作速度を低下させ、操作速度を低下させた状態で、各画面の遷移過程の動画の撮像と遷移過程における各画面の撮像を実行する。

具体的には、採取部６３は、動画の撮像に際し、撮像時に画面遷移が高速すぎるがゆえに操作過程情報の確認が行えないケースを鑑み、ロボット５０の実行モードを切り替え、画面遷移操作を目視確認可能なレベルにスローダウンさせる処理を実行する。処理の切り替えは、外部引数により指定可能とする。例えば、ロボット５０は、デバッグモードで実行させるために、外部引数により処理の切り替えを実現する。同様に、採取部６３は、通常は採取しないログも上記デバッグモードでの実行時のみ採取する方式を取ることにより、通常のロボット５０の実行時は不要なログ出力や処理速度低下を防ぎつつ、トラブル調査時の情報確認を容易化させる。

通知部６４は、各種情報をＲＰＡの関係者に通知する処理部である。具体的には、通知部６４は、プロセスＩＤ＝１のＧＵＩ操作でエラーが発生した場合、図５にしたがって「ａａａ＠ｘｘｘ．ｃｏｍ」にエラー情報等が送信される。例えば、通知部６４は、エラー検知部６２によりエラーが検知されると、エラーが発生したことをロボット開発者、ロボット運用者、サポートサービス員などの関係者に通知する。また、通知部６４は、採取部６３によるエラー情報の採取が完了すると、採取完了を示す通知または採取された各種データをロボット開発者、ロボット運用者、サポートサービス員などの関係者に通知する。

（処理の流れ）
図７は、実施例１にかかるロボット制御システムが実行する処理の流れを示すフローチャートである。図７に示すように、ロボット５０の操作実行部６１は、実行リクエストを受信すると（Ｓ１０１）、実行リクエストにトラブル情報採取処理用の外部引数が設定されているか否かを判定する（Ｓ１０２）。なお、トラブル情報採取処理用の外部引数は、実行リクエストではなく、操作管理ＤＢ５４にプロセスＩＤに対応付けて記憶されていてもよい。

ここで、操作実行部６１は、実行リクエストにトラブル情報採取処理用の外部引数が設定されていない場合（Ｓ１０２：Ｎｏ）、通常のロボット操作（ＲＰＡ操作）を実行する（Ｓ１０３）。

一方、操作実行部６１は、実行リクエストにトラブル情報採取処理用の外部引数が設定されている場合（Ｓ１０２：Ｙｅｓ）、通常のロボット操作を実行し、エラー処理を実行する（Ｓ１０４）。具体的には、エラー検知部６２は、ＧＵＩ操作の開始と同時に、ＧＵＩ操作で発生する各画面の遷移過程の動画データの採取、遷移過程における各画面の画面データの採取、および、ログ情報の取得を実行する。

その後、エラー検知部６２がエラー発生を検知し、ＲＰＡ操作が終了すると（Ｓ１０５：Ｙｅｓ）、採取部６３は、エラー処理を終了する（Ｓ１０６）。具体的には、エラー検知部６２は、ＧＵＩ操作で発生する各画面の遷移過程の動画データの採取、遷移過程における各画面の画面データの採取、および、ログ情報の取得を終了する。

そして、採取部６３は、エラー処理で得られた各種データを採取結果ＤＢ５６に保存する（Ｓ１０７）。また、通知部６４は、採取された各種データを関係者に通知する（Ｓ１０８）。

（効果）
上述したように、ロボット５０は、運用中に実行エラーなどのトラブルが発生した場合、外部引数を設定した上でエラー処理を実行する。例えば、ロボット５０は、画面操作処理部分のスローダウン、操作過程の画面キャプチャの撮像、ロボット起動中の動画撮像、操作証跡を示すログを採取する。したがって、ロボット５０は、通常運用時のロボット５０の処理速度やログ出力量を変更することなく、エラー調査時のみエラー調査に必要となるロボット５０の外部リソース操作の過程の情報を採取することができる。この結果、ロボット５０は、トラブル時の情報に不足や漏れを抑制し、トラブル事象の再現を短時間で適切に実行できる情報を提供することで、トラブルの解決にかかる時間を短縮化することができる。

また、ロボット５０は、採取されたエラー情報を、ロボット実行者、ロボット運用者、サポートサービス員などの関係者にメール等で通知する。この結果、ロボット５０は、エラー情報を遅滞なく通知することができ、トラブルの解決にかかる時間の更なる短縮化を実現することができる。

ところで、エラー発生時刻と、スローダウン後の操作の録画開始時刻とは、別々に管理されることから、複数のエラーが短時間で発生した場合など、動画データとエラー処理との対応付けが煩雑になることがある。

そこで、実施例２では、ロボット５０が、動画撮像の開始時刻を別途管理し、ロボット５０によるＧＵＩ操作のスローダウン処理開始後のＧＵＩ操作のログ出力時刻と動画データ内のＧＵＩ操作の時刻との紐づけを実行する。

図８は、実施例２にかかるロボット５０の機能構成を示す機能ブロック図である。図８に示す機能ブロック図において、実施例１と異なる点は、操作時刻管理ＤＢ５７を有している点である。

操作時刻管理ＤＢ５７は、動画撮影開始時の実際の時刻、および、ＧＵＩ操作とエラー発生時のログ出力時において、動画撮影開始時刻からの経過時間を保存するデータベースである。図９は、操作時刻管理ＤＢ５７を説明する図である。図９に示すように、操作時刻管理ＤＢ５７は、「ＩＤ、ＧＵＩ操作ＩＤ、実時刻、相対時刻」を対応付けて記憶する。

ここで記憶される「ＩＤ」は、操作時刻管理ＤＢ５７内のレコードを識別する情報である。「プロセスＩＤ」は、プロセスを識別する情報である。「実時刻」は、ＧＵＩ操作が実行された実際の時刻である。「相対時刻」は、エラー処理の動画データの撮像開始からの相対時刻である。図９の例では、ＧＵＩ操作ＩＤ＝１のＧＵＩ操作が、「2022/1/1 00：30：30」に実行され、これが録画データの録画開始から「00：00：30」に該当することが示されている。

例えば、ログは、通常、特定の標準時刻に沿って日時が出力されるが、採取部６３は、動画撮像の開始時刻、及び撮像時刻からの経過時間を別途管理し、動画撮像の開始時刻から経過時間を加算する。これにより、動画データ内の特定のＧＵＩ操作がどの操作ログと紐づいているかを判断可能とさせる。また、ログ情報には、ＧＵＩ操作の処理情報、操作機能情報、ロボット５０のソース情報と対象のログが紐づけ可能な情報を出力させる。

上記により、動画データの再生中の特定の再生時間と、ログの時刻とを比較することにより、動画データ内の画面操作がログのどの出力結果（操作ログ）と紐づいているかを判定可能とさせる。例えば、繰り返し同一画面を操作する処理の実行時に、どの操作ログがどのタイミングの動画内の画面操作と紐づいているか判断が難しい場合に特に有効である。

図１０は、実施例２にかかる処理を説明する図である。採取部６３は、動画撮像の開始時点における実際の時刻を記録しておく。その後、採取部６３は、ＧＵＩ操作およびエラー発生等のイベント発生時に出力されるログ時刻と、動画撮像の開始時刻からの経過時間を比較することにより、ログ情報と動画データの時刻情報を一致させる。

例えば、図１０に示すように、採取部６３は、ロボット５０のプロセスが開始された時点で動画撮像処理を開始し、同時に開始時点での実際の時刻の保存を行う。つまり、採取部６３は、動画データ内の「00：00」時刻と実際の動画撮像の開始時刻「2022/1/1 12：00：00」時刻を内部処理として一致した時刻であると管理する。

その後、動画データ内の時刻表記で「01：00」に特定のＧＵＩ操作Ａが実施され、ログが出力されたとする。この場合、採取部６３は、ログの実際の出力時刻「2022/1/1 12：01：00」と、動画撮像の開始時刻「2022/1/1 12：00：00」に動画データ内の経過時刻「01：00」を加算した時刻とを一致させて管理することができる。

さらにその後、動画データ内の時刻表記で「01：00」にエラーが発生し、ログが出力されたとする。この場合、採取部６３は、ログの実際の出力時刻「2022/1/1 12：03：00」と、動画撮像の開始時刻「2022/1/1 12：00：00」に動画データ内の経過時刻「03：00」を加算した時刻とを一致させて管理する。これらの結果、採取部６３は、動画データ内の時刻とログの紐づけ（実際時刻情報から関連付け）が可能となる。

図１１は、実施例２にかかるロボット制御システムが実行する処理の流れを示すフローチャートである。図１１に示すように、ロボット５０の操作実行部６１は、実行リクエストを受信すると（Ｓ２０１）、実行リクエストにトラブル情報採取処理用の外部引数が設定されているか否かを判定する（Ｓ２０２）。

ここで、操作実行部６１は、実行リクエストにトラブル情報採取処理用の外部引数が設定されていない場合（Ｓ２０２：Ｎｏ）、通常のロボット操作を実行する（Ｓ２０３）。

一方、操作実行部６１は、実行リクエストにトラブル情報採取処理用の外部引数が設定されている場合（Ｓ２０２：Ｙｅｓ）、通常のロボット操作を実行し、エラー処理を実行する（Ｓ２０４）。

その後、エラー検知部６２がエラー発生し、ＲＰＡ操作が終了すると（Ｓ２０５：Ｙｅｓ）、採取部６３は、エラー処理を終了する（Ｓ２０６）。続いて、採取部６３は、各種データを採取結果ＤＢ５６に保存し（Ｓ２０７）、ログ出力時刻と動画撮像の開始時刻からの経過時間情報とを元に、動画データの時刻とログ情報の出力時刻との紐づけを実行する（Ｓ２０８）。また、通知部６４は、採取された各種データを関係者に通知する（Ｓ２０９）。

上述したように、実施例２にかかるロボット５０は、動画撮像の開始時刻を別途管理し、ロボット５０によるＧＵＩ操作のスローダウン処理開始後のＧＵＩ操作のログ出力時刻と動画データ内のＧＵＩ操作の時刻との紐づけを実行することができる。この結果、ロボット５０は、複数のエラーが短時間で発生した場合であっても、動画データとエラー処理とを容易に対応付けることができるので、関係者の負担を軽減し、トラブル解決にかかる時間の短縮化に貢献できる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

（数値等）
上記実施例で用いたＤＢ例、数値例、プロセス数、プロセス名、リクエストや命令の名称等は、あくまで一例であり、任意に変更することができる。また、各フローチャートで説明した処理の流れも矛盾のない範囲内で適宜変更することができる。

（制御対象）
上記実施例では、ＲＰＡロボット５０を例にして説明したが、これに限定されるものではなく、例えば外部装置（マスタ）からの指示により、命令や処理を実行する各種装置（エージェントアプリケーション）を対象とすることができる。

（システム）
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（ハードウェア）
図１２は、ハードウェア構成例を説明する図である。図１２に示すように、ロボット５０は、通信装置５０ａ、表示装置５０ｂ、ＨＤＤ（Hard Disk Drive）５０ｃ、メモリ５０ｄ、プロセッサ５０ｅを有する。また、図１２に示した各部は、バス等で相互に接続される。

通信装置５０ａは、ネットワークインタフェースカードなどであり、他の装置との通信を行う。表示装置５０ｂは、ＲＰＡ操作対象などの各種情報を表示出力する装置であり、例えばディスプレイやタッチパネルなどである。ＨＤＤ５０ｃは、図３に示した機能を動作させるプログラムやＤＢを記憶する。

プロセッサ５０ｅは、図３に示した各処理部と同様の処理を実行するプログラムをＨＤＤ５０ｃ等から読み出してメモリ５０ｄに展開することで、図３等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、ロボット５０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ５０ｅは、操作実行部６１、エラー検知部６２、採取部６３、通知部６４等と同様の機能を有するプログラムをＨＤＤ５０ｃ等から読み出す。そして、プロセッサ５０ｅは、操作実行部６１、エラー検知部６２、採取部６３、通知部６４等と同様の処理を実行するプロセスを実行する。

このように、ロボット５０は、プログラムを読み出して実行することで情報処理方法を実行する情報処理装置として動作する。また、ロボット５０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、ロボット５０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、上記実施例が同様に適用されてもよい。

このプログラムは、インターネットなどのネットワークを介して配布されてもよい。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行されてもよい。

５０ ロボット
５１ 通信部
５２ 出力部
５３ 記憶部
５４ 操作管理ＤＢ
５５ 通知情報管理ＤＢ
５６ 採取結果ＤＢ
６０ 制御部
６１ 操作実行部
６２ エラー検知部
６３ 採取部
６４ 通知部

Claims (7)

1. コンピュータに、
   所定の操作を実行し、
   前記所定の操作を実行すると、前記所定の操作による操作対象の撮像および前記所定の操作により発生する操作データの取得を実行し、
   撮像された前記操作対象に関する撮像データおよび取得された前記操作データを記憶部に保存する、
   処理を実行させることを特徴とする制御プログラム。
2. 前記コンピュータは、ＲＰＡ（Robotic Process Automation）技術を適用したＲＰＡロボットであり、
   前記所定の操作は、前記ＲＰＡ技術を用いて前記操作対象を操作するＲＰＡ操作であり、
   前記実行する処理は、外部リソースに対する指定された前記ＲＰＡ操作を実行し、
   前記実行する処理は、前記外部リソースに対する前記ＲＰＡ操作の過程の撮像、および、前記ＲＰＡ操作で発生するログ情報の取得を実行し、
   前記保存する処理は、前記ＲＰＡ操作の過程が撮像された撮像データ、および、前記ＲＰＡ操作のログ情報を前記記憶部に保存する、
   ことを特徴とする請求項１に記載の制御プログラム。
3. 前記実行する処理は、前記ＲＰＡ操作として前記外部リソースに対するＧＵＩ（Graphical User Interface）操作を実行し、
   前記実行する処理は、前記ＧＵＩ操作で発生する各画面の遷移過程の動画と前記遷移過程における各画面の撮像、および、前記ログ情報の取得を実行し、
   前記保存する処理は、前記各画面の遷移過程の動画データと前記各画面の画像データを含む前記撮像データ、および、前記ログ情報を前記記憶部に保存する、
   ことを特徴とする請求項２に記載の制御プログラム。
4. 前記実行する処理は、
   前記ＧＵＩ操作中にエラーが発生した場合に、前記ＧＵＩ操作の操作速度を低下させ、
   前記操作速度を低下させた状態で、前記各画面の遷移過程の動画の撮像と前記遷移過程における各画面の撮像を実行する、
   ことを特徴とする請求項３に記載の制御プログラム。
5. 前記実行する処理は、
   前記各画面の遷移過程の動画および前記遷移過程における各画面の撮像を開始した開始時刻と、前記ＧＵＩ操作の開始から前記ログ情報の出力までに要した経過時間とを取得し、
   前記保存する処理は、
   前記開始時刻に前記経過時間を加算した時刻に基づき、前記ＧＵＩ操作の操作時刻と前記ログ情報とを関連付ける、
   ことを特徴とする請求項４に記載の制御プログラム。
6. コンピュータが、
   所定の操作を実行し、
   前記所定の操作を実行すると、前記所定の操作による操作対象の撮像および前記所定の操作により発生する操作データの取得を実行し、
   撮像された前記操作対象に関する撮像データおよび取得された前記操作データを記憶部に保存する、
   処理を実行させることを特徴とする制御方法。
7. 所定の操作を実行し、
   前記所定の操作を実行すると、前記所定の操作による操作対象の撮像および前記所定の操作により発生する操作データの取得を実行し、
   撮像された前記操作対象に関する撮像データおよび取得された前記操作データを記憶部に保存する、
   制御部を有することを特徴とする制御装置。

Images