東京都千代田区西神田2丁目1番地8号 Bonheur西神田 BLDG. 12F

Copyright 2019 PLAY Inc. All rights reserved.

  • Gobun Takagi

EUCユーザー向け・RPAを安全に使うために

概要


 RPAソフトウェアを使うと、いままで手作業で行っていた様々な業務を、自動化することが可能となります。

 これにより、RPAソフトウェアを使いこなせるユーザーは、1人で、従来の数人分や数十人分の単純業務を(PCに作業させることによって)遂行できるようになります。


 しかし、ここに落とし穴もあります。RPAを使う上で「やってはいけないこと」が見落とされてしまうリスクです。

 「やってはいけない」と書くと漠然としていますが、業務が止まったり、データに不整合が起きるなどだけでなく、内容によっては、同僚や取引先、あるいは他人に迷惑をかけたり、最悪の場合、法的責任を負わされる可能性もあります。


 本稿では、よくありがちな「RPAを実装する上で、やってはいけないこと・留意すべきこと」について記載しようと思います。



Webサイトの利用規約や表記に気をつける


 Webサイトによっては、RPAを含む、自動操作による情報収集を禁止していることがあります。有名なところでは、Amazon.com (日本の Amazon.co.jp も含まれます)や、Yahoo! ファイナンス、あるいは各種SNS(TwitterやFacebook等)です。

 これらのWebサイトをRPAによってスクレイピング・自動操作をした場合、それによりWebサイトに被害を与えてしまい、損害賠償を請求される可能性があります。

 たとえば過度なアクセスによるサーバー負荷という被害や、自動で複数の情報の読み込み・書き込みをしていた場合に、内容によっては、システムへの不正アクセスとみなされるリスクがあります。

刑法 第168条の2 1.正当な理由がないのに、人の電子計算機における実行の用に供する目的で、次に掲げる電磁的記録その他の記録を作成し、又は提供した者は、三年以下の懲役又は五十万円以下の罰金に処する。

1.人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録

2.前号に掲げるもののほか、同号の不正な指令を記述した電磁的記録その他の記録

2.正当な理由がないのに、前項第一号に掲げる電磁的記録を人の電子計算機における実行の用に供した者も、同項と同様とする。

3.前項の罪の未遂は、罰する。


 また、いわゆるスクレイピングで収集するデータそのものも、場合によっては著作権で保護されている可能性があることに注意が必要です。

 著作権法12条の2には「データベースでその情報の選択又は体系的な構成によつて創作性を有するものは、著作物として保護する。」と記載されています。Web上で公開されているデータの一覧などについても、ものによっては該当する可能性が高いと考えられます。

 この場合、RPAでスクレイピングすることの是非だけでなく、その後、スクレイピングしたデータの利用形態によっては、また別の問題が発生する可能性があります。たとえば、スクレイピングで集めたデータを何かしらのレポートとして、顧客にそのまま提出するような場合ですね。

 上記のような用途に引っかかる不安があれば、事前に法務部門や、弁護士に相談することをお勧めします。


 ほかに、利用規約ではありませんが、よく自動操作による操作を回避するための機能(たとえばOCRでは読みにくい形の文字を入力したり、特定のカテゴリの写真を選択するもの、など)を設定しているWebサイトがあります。

 これらはWebサイト管理者の、自動操作による処理を認めていないという意思表示と見ることもできますので、そういった表示が行われるサイトをRPAで操作することは、控えるべきでしょう。不正な利用とみなされれば、上記のような法的責任を負う可能性があります。 


 

リトライ処理・多重実行に気を付ける


 特にWebサイトを処理する場合、RPAソフトウェアの設定や、処理フローの作成で リトライ処理を組み込むことがあります。

 特にオンラインの処理では、PCや回線の一時的な高負荷や、データの量によって、想定時間内に処理が終わらず、正しく画面が表示されない・・・といったことが、どうしても発生しがちです。そういった処理を確実に行うため、リトライは有効な手段の1つです。


 しかし、リトライを一度に連発してしまうと、通信先のサーバーに意図せぬ負荷をかけてしまうことがあります。悪意がなくとも、いわゆるDoS攻撃の状態になってしまうのです。  そのため、特にWebサイトや、ネットワーク先にログインするシステムを使う際は、リトライ処理の間に適宜、処理間隔を設定するようにしましょう。


 また、組織内のRPA普及に伴い、RPAソフトウェアの導入台数をだんだん増やすことがあります。ソフトウェアによっては、処理内容をそれぞれの端末に分散してくれることがあります。

 しかし、ここで注意しないといけないのは、たとえば「従来は、1台の端末で20回繰り返していたWebアクセス」が、「20台の端末から同時に1回行われる」ような形式になり、結果として、Webサイト側の過負荷が起きる可能性があります。 (それ以外に、Webサイト側で処理するべきデータを、複数同時に投入する結果、業務手順に想定されていない、何かしらの不整合が起きる可能性もあります)


 上記のような観点も踏まえて、リトライ処理の設計は、慎重に行われる必要があります。

 

RPAで行う処理の法律との関係性を確認する


 法律との関係性、と書くと重く感じられますが、要するに「作業の内容によっては法律に準拠する必要がある」ことです。

 たとえば、RPAで勤怠管理のデータを元に、勤務時間の処理をすることは、ユースケースとして少なくないと思います。  さて、勤怠管理にITが導入される以前は、タイムカードや台帳などをベースに、手計算で残業時間が処理されていました。その場合、たとえば分単位を四捨五入して、10分単位に丸める、等は一定の合理性があるとして、認められてきた経緯があります。(法律に厳密に則るなら、残業時間は1分・1秒でも計算されなければならない、とも言えてしまいますが、そこまでの厳密な計算は非現実的だったからです) 


 さて、コンピューターのシステムやRPAを併用して勤怠管理が行える場合、「勤怠時間を丸める処理が必要か?」という観点が出てきます。

 単純な処理の数で言えば、入力されている時間をAs-Isで処理するほうが、中途半端な丸め(切り捨て・切り上げや四捨五入)が不要になるからです。

 これはRPA導入の方法論でもよく語られることですが、現状の業務方法を完全にそのまま自動化するわけではなく、必要な部分は合理化していく必要があることにも、合致します。


 つまり、その中で、勤務時間の例のように、合理化を行わない(従来通りの丸め処理を行う)と、逆に、関連する法律の趣旨から逸れてしまい、ともすればコンプライアンス違反が生じてしまう可能性があります。

 すべてにおいて一々、法律のチェックを行うのは困難だとは思います。しかし、社内業務という狭い範囲だけでなく、もう少し外側にある社会のルールもあわせた視野を持つことで、思わぬところで「やってはいけない処理をやっていた」という事態が起きるのを回避できます。



最後に


 RPAを覚える・使いこなすことで、人間1人あたりの生産性をあげたり、遂行できる業務・作業量を大幅に広げることができます。

 その反面、従来は意識していなかった部分にも気を付けないと、思わぬトラブルの原因になりかねません。

 組織や関係者、取引相手などだけでなく、自身の身を守るためにも、RPAを用いる上でのリテラシーを学んでいく必要があります。 

16回の閲覧