Column コラム

世界的には新型コロナウイルスの影響によるリモートワークや人手不足への対応として、さらに日本では諸外国に比べて事務的業務の生産性が低いといった、危機感の高まりを受けた働き改革を筆頭に、RPAやソフトウェアロボット（以下、「ボット」とする）の活用場面は大きな広がりを見せており、身近な存在になってきています。ここでは、混同されがちな言葉の違いや、RPAやボットにできること・苦手なこと、運用上の注意点を解説します。

AIと RPA・ボットの違い

はじめに、よく混同されがちなAI、RPA、ボットについてそれぞれの定義や特徴を整理し、活用場面や実例などを交えて紹介します。

AI

人工知能と呼ばれ、人間の思考回路をコンピュータ上で疑似的に再現したソフトウェアのことを指します。AIは膨大なデータやトレンドから自律判断、類推ができるのが大きな特徴です。一般的なソフトウェアでは自身が思考し判断することはできず、プログラミングでルール化されたこと以外のことは処理ができません。一方で、AIは人間が持つ思考回路に近いデータ処理手順を再現しているため、過去のデータや経験から学習し、判断や類推、予測といった、教えられたこと以外の処理を可能としています。

将来的にはAIによるシンギュラリティ（技術的特異点）が訪れ、AIが人間の能力を上回るといった見方もあります。しかしながら、現時点でのAIはまだ万能ではなく、ある特定の問題解決用途に特化しています。とくに、画像認識や、数理処理、最適化などは得意としていますが、全く関係のない事柄からヒントを見つける“ひらめき”や、0から1を作り出すような“創造作業”などは苦手としています。また、意外にもAIは白黒2択で正答を出すことも苦手としており、同じデータをインプットしても、導き出されるアウトプットは毎回少しずつ異なるケースが多くあります。

RPA

RPAは多くの場合、ソフトウェアや後述のボットによる業務自動化技術を意味します。特に、紙媒体や手作業、個人管理が主流だった事務的作業の自動化に関するソフトウェアやクラウドサービスが多く利用され始めています。

例として、

1．名刺管理、顧客管理　電子化・クラウド化
2．領収書管理、請求書管理、経費精算　電子化
3．受発注管理、生産計画、進捗管理　横断的システム化
4．図面管理・技術管理　情報システム化(PDM)
などが挙げられます。

日本は諸外国に比べ、一つの企業での平均勤続年数が長い傾向があり、“人に仕事がつく”状態が多く見受けられます。好意的にはその仕事に対するプロフェッショナル、職人とも見ることはできますが、不確実性や多様性が高まる現代において、BCPや組織の柔軟性を確保する観点では、業務が属人化されることは逆にリスクにもなり得ます。データ入力や計算、ファイリングなど直接付加価値を生まない間接業務やルーティン業務ですら、ベテランが高い賃金で行っているなど、日本のホワイトカラー職種の生産性が低いと評される一因となっています。それを改善するために現在、RPAが大きく注目されています。

また、古くは、ある程度ルール化、ルーティン化されている入力作業や計算作業を、オフィスソフトのマクロ機能を用いて、オンプレミスで限定的に自動処理させる手法が一般的でしたが、最近ではリモートワークやオフィスの人数制限により、部署内外で業務横断的に場所を問わずデータを共有・処理できることのニーズが高まり、クラウド系のRPA活用が一気に広がりを見せています。

ソフトウェアロボット（ボット）

ボットとはロボットから派生したワードで、工場で稼働しているようなハードウェアをもつロボットに対して、ソフトウェア上で稼働するロボットをボットと呼ぶ傾向があります。もともとはマルウェアのように、遠隔で自動動作するようなプログラミングされたソフトウェアが根源になっていますが、特にソフトウェアの中で対話型のユーザーインターフェースに組み込まれるケースが多くみられます。

最近では、
1． アシスタントボット（Apple社のSiri、Google社のGoogleアシスタント、Amazon社のAlexaなど）
2． チャットボット（FAQ自動返答、SNSサポート、業務チャットなど）
3． トレードボット（株式、FX、暗号通貨などの自動売買システムなど）
といった分野での導入が広まっています。

ボットの“頭脳”がAIなのか、マクロなのか、ハイブリッド型なのかなどによって多少性質が異なりますが、共通しているのは、本来コンピュータ言語でコーディングをしなければならないようなデータ処理を、ボットをインターフェースにすることにより、事前定義された構造化データだけではなく、音声や映像といった非構造化データを用いた対話的なデータ処理を可能としていることです。

ボット自体は高度で複雑なプログラミングによって成り立っており、ユーザーインターフェースが平易になることによって、AIやRPAをパッケージとして運用、活用できるようにしていると言えます。

RPA・ボットができること、苦手なこと

一般的にRPAやボットはAIと異なり自律的な判断能力を持たないので、教えていないことは処理できません。RPA・ボットの得意分野・苦手分野を整理し、適材適所での利用を考慮する必要性があります。

・RPAやボットができること、得意なこと
ルール化された定型作業（伝票処理、給与処理、データ入力など）
データ収集・分析・共有（名刺管理、Web検索、BIツールなど）

・RPAやボットができないこと、苦手なこと

イレギュラーな事象や変化への柔軟な対応（フォーマットが異なる業務、未知のデータなど）
思考や判断が必要となる処理（最適化、文意の解釈、状況判断、設計など）

あくまでも“現時点では”ですが、RPA・ボットができることは、ルール化・ルーティン化された業務の自動化がメインです。そのため、どこまで自動化するかの「適用検討＝ゴールの設定」が非常に重要となります。そのことを関係者が理解していないがために、PoC貧乏と呼ばれる、概念実証の繰り返しだけでプロジェクトが頓挫し、現場導入まで至らず、結果、投資失敗となるケースが多くあります。

RPA・ボットの導入を頓挫させないための考え方

少々乱暴な言い方にはなりますが、多少の人為的なミスは許容できても機械やシステムのミスは許容せず、現場に中途半端なモノの導入は一切認めないといった考え方が、日本の製造業では強いと言えるでしょう。
それは高い品質意識の裏返しではありますが、現場のデジタル化を阻害する一因になっていると言えます。

また、業務の一部だけデジタル化するのは例外を作ることになるため、業務ルーティンを崩し、現場に余計なストレスを強いることにもなります。エンジニアとしてはパラメータを変えながら仮導入と検証をしているつもりでも、現場としてはゴールが見えない中で、その都度異なるルールを押し付けられる印象を受け、これが繰り返されると現場がデジタル嫌いに陥り、負の連鎖となります。

発展途上のデジタル技術に精度100％を求めすぎることが、自らの首を絞め、プロジェクトが頓挫する原因になることを関係者が理解し、ゴールを共有しましょう。経営層、管理層、現場、エンジニアが考える正解や正義は異なるため、根回しをしつつバランスを取りながら完成へ近づくプロジェクトマネジメントが必要だと言えます。

とはいえ、デジタル主体の変革の中で、RPA・ボットが担う役割はとても大きく、今後もさらに高性能化、知能化が進み、今できないことも、当たり前のようにできるようになると考えられます。そういった理由から、陳腐化の早いデジタル技術に対して大掛かりな投資を行うのもリスクになりえますが、現時点で100％自動化できないからと言って二の足を踏むのは、デジタル社会でのビジネスチャンスや利益を失う結果にもつながりかねません。
そのため、まずはできるところから地ならしをして、デジタル化を着実に推進するスモールスタートでキックオフする企業が増えています。

RPA・ボットの運用の注意点

次に導入後のトラブルを避け、投資効果を最大化するために、RPA・ボットを業務上で運用するうえで、注意すべき点を整理します。

業務標準化の必要性

繰り返しにはなりますが、RPA・ボットを運用するうえで重要になるのはルール化・ルーティン化です。「人によって業務フローが異なる」「取引先によって帳票類がバラバラ」のように作業パターンが増えれば増えるほど、RPA・ボットに教えなければいけないルールや分岐条件が複雑になり、導入までに手間と工数を必要とします。複雑なシステムはそれだけ保守や改修も複雑になります。

したがって、RPA・ボット導入前にどこまで業務標準化できるかが、イニシャルからランニングまでのトータルコストや、享受できるメリットを左右することになります。

トラブル時の業務バックアップ体制整備

ソフトウェアの性質上、想定しない条件下でバグが潜んでいる場合が大いに考えられます。また、クラウド環境を使用する場合には、ネットワーク障害やサイバー攻撃によるシステム停止リスクに備え、単にデータバックアップだけでなく、業務バックアップ体制が必須と言えます。特に、最近では多くの企業でAWSやAzureといった基幹ITプラットフォームから派生・連携したサービスを利用しています。そのため、一度ネットワーク障害が発生すると波及範囲が広く、復旧まで長い時間を要する恐れがあります。

対応策としては、業務を止めないように、「オンプレミスだけでもシステムが動かせる状態」「一時的に人手に戻すことができる状態」といった、BCPやリスクヘッジを十分に検討する必要があります。

ベンダーロックインの回避

特に、自社にIT部門が無く、外部ベンダーよりシステムを購入する場合、以下のようなリスクが考えられます。

・そのベンダーしかシステムの保守保全ができず、ブラックボックス化してしまう。ベンダーの廃業や合併、統廃合などによってサポートが受けられなくなる。
・すべてを一つのシステムに依存してしまい、更新時や改修時に他のシステムやサービスに移行できない、ガラパゴス化してしまう。

その状態をベンダーロックインと呼びますが、それを回避するにはベンダーに丸投げしないプロジェクトマネジメントと人材育成が必要です。

近年、大手企業を中心に、毎年数千人単位でのIT人材の採用・育成が進んでいますが、慢性的にIT人材は不足しており、中小企業でも人材育成によってITシステムを維持管理できるIT人材の確保は必須となります。

まとめ

今後のデジタル社会を迎えるにあたり、アナログな定型業務をデジタル化することは、現時点で直接的なメリットが少ないとしても、DXによるサプライチェーンやエンジニアリングチェーンの全体最適化を図るうえで重要な要素であると言えます。
デジタル化において日本は周回遅れと言われることもあります。しかし逆に言えば、アナログであっても改善や効率化が進んできていたとも言えます。そのため、今までの良さも残しつつ、アナログの弱点を補う形でデジタル化を進めるのが日本らしいデジタル化の姿と言えるのではないでしょうか。

執筆者プロフィール
伊藤 慶太
技術士(機械部門　専門：加工・ファクトリーオートメーション及び産業機械)
大学卒業後、生産設備メーカーでNC加工業務や半導体関連設備の機械設計業務を経験。
現在は、産業用機器メーカーの生産技術職としてIE(Industrial　Engineering)手法をベースに、生産工程自動化設備の計画・設計やIT・IoT活用などよるファクトリーオートメーション業務に広く携わる。