AI RPAとは？RPA×生成AIの組み合わせ方と導入判断

AI RPAは、RPAの画面操作に、生成AIなどによる読み取り・分類・文章生成を組み合わせる考え方です。ひと言で分ければ、AIが判断を補い、RPAが決めた操作を実行する仕組みです。

ただし、AIを足せば自動化の範囲が際限なく広がるわけではありません。既存RPAへ判断工程を加えるのか、新しい仕組みとして導入するのか。対象業務、誤りの影響、運用担当まで見て決める必要があります。

AI RPAとは？RPAに生成AIを加えると変わること

RPAは、入力、転記、クリック、ダウンロードなど、人がパソコンで行う定型操作を再現します。あらかじめ手順を定め、そのルールに沿って動くのが基本です。

本記事ではAI RPAを、生成AIや機械学習が画面や文章の読み取り、対象の特定、分類、抽出、文章生成を担い、RPAが入力、クリック、転記へつなぐ仕組みと定義します。変わるのは、これまで人が受け持っていた入力前の判断を、一部フローへ組み込める点です。

従来RPAの実装方式は一つではありません。HTMLやDOMのセレクタ、UI要素の認識、画像認識など、製品や対象画面によって異なります。比較では製品名や呼称より、どの判断をAIが担い、どの操作をRPAが担うかを見ます。

RPAと生成AIを組み合わせる3つの型

組み合わせ方は、AIが何を受け取り、何をRPAへ渡すかで分けます。複数の型を一つのフローに入れる場合も、工程ごとに分解しておくと、出力の誤りと画面操作の停止を切り分けやすくなります。

読み取り・分類を入力へつなぐ

文章や書類から必要な項目を抽出し、分類結果に応じて入力先を決める型です。たとえば見積情報から必要項目を取り出し、RPAが業務画面へ転記する流れが考えられます。抽出できない項目を推測で埋めず、人へ戻す条件を先に決めます。

文章生成・判断補助を業務フローへ入れる

単純な転記の前後に、文章を生み出す工程を置く型です。リサーチデータから提案資料の構成を考える、履歴書から面接で深掘りする質問を生成するといった処理が該当します。生成結果の影響が大きい業務では、人の確認後に次の操作へ進めます。

画面を認識して操作へつなげる

AIが画面を読み、対象を特定した結果を入力やクリックへつなぐ型です。APIが用意されていない画面も検討対象になりますが、認証方式、利用規約、画面の条件によって対応可否は変わります。対象画面を使った事前確認が欠かせません。

今のRPAを拡張するか、新しく導入するか

すでにRPAを使っている企業と、これから自動化を始める企業では、出発点が違います。既存資産があるから拡張、新規だから一体型、と機械的に決めるものでもありません。対象業務ごとに、今ある手順を残す価値と、判断工程を含めて設計し直す負担を比べます。

既存利用者は、まず手作業で残っている「読む・分ける・文章を整える」工程を洗い出します。今のRPAが安定しているなら、操作部分を残して判断部分だけを検証する余地があります。

これから選ぶ人は、製品の機能数から入らず、業務の入口と出口を決めます。APIで連携が完結するなら別の連携手段も候補です。画面入力を含み、入力前に分類や抽出が必要なら、AI RPAを比較対象にします。

AI RPAに向く業務・向かない業務

向き不向きは、件数の多さだけでは決まりません。手順の定型度、判断の曖昧さ、誤りが起きたときの影響、APIの有無、人の承認を置けるかを一緒に見ます。

候補にしやすいのは、繰り返し発生し、基本の流れが決まっている業務です。入力前の分類や抽出が必要で、APIだけでは完結せず、判断できない場合に人へ戻せるなら、組み合わせる意味が見えやすくなります。

一方、例外ばかりで手順を定められない業務、誤入力後の影響が大きいのに承認を置けない業務、操作対象を特定できなくても処理を続ける必要がある業務は向きません。外部サイトの利用規約で自動操作が認められていない場合も、技術的に動かせるかとは別に対象外です。

件数が少なく、設定や監視にかかる工数の方が大きい業務も、導入しない判断があり得ます。手作業を残す、API連携を使う、判断だけAIで補助するなど、自動化範囲を狭めて比べます。

業務例で見るAI・RPA・人の役割分担

詳しく見るのは、Pigeon Workflowの公式ヘルプで紹介されているATS入力です。見積転記と問い合わせ処理は、役割分担を示すための想定例として短く整理します。

候補者情報をATSへ入力する公開例

入力

候補者情報

AI

入力に必要な情報を読み取る

RPA

ATSへ候補者情報を入力する

人の承認

対象業務や画面の条件に応じて確認箇所を決める

停止条件

対象を特定できない、または認証を求められた場合

この例では、入力結果を通知する流れも紹介されています。自社で同じ構成が使えるかは、対象サービスの認証方式や利用規約、画面の条件を確認して判断します。

見積情報を業務画面へ転記する想定例

入力→AI→RPA：見積の内容から必要項目を抽出し、業務画面へ入力します。

承認・停止条件：影響の大きい項目や不明な項目は人が確認し、必要項目や入力先を特定できなければ停止します。

問い合わせを仕分けて入力する想定例

入力→AI→RPA：問い合わせ文を分類して必要な情報を抽出し、分類結果に応じた画面へ入力します。

承認・停止条件：誤りの影響が大きい判断は人が確認し、分類や処理先を特定できなければ停止します。

PoCで確認する精度・費用・運用条件

PoCでは、正常なデータが一度通るかだけを見ません。先に合格条件と中止条件を置き、AIの出力、RPAの操作、例外時の人の対応を分けて記録します。目標値と社内の時間単価は、各社が対象業務に合わせて決める変数です。

• 削減効果額＝削減時間×社内の時間単価
• 月間総費用＝利用料＋運用工数×社内の時間単価＋初期費用の月割り
• 判断＝削減効果額−月間総費用

製品を選ぶときの確認項目

機能名の多さではなく、実際の画面で動くか、止まった後に状況を追えるかを確認します。料金も月額だけで比べず、設定、監視、人の確認を含めて見ます。

画面変更後の復旧、属人化、保守台帳などRPA全般の運用設計は、RPA導入の失敗原因と保守の考え方で詳しく扱っています。本記事では重複を避け、AIを加えたことで増える確認項目に絞りました。

Pigeon Workflowで確認できる範囲

該当する型

Pigeon WorkflowはAI RPAを備え、APIのない業務システムへの入力も自動化の対象にできます。前述の3つの型では、AIによる読み取り・分類や文章生成をRPAの画面操作へつなぐ使い方に当たります。

Pigeon Workflowの公式サイトでは、ATSへの候補者情報の入力、リサーチデータから提案資料の構成を考える処理、履歴書から面接で深掘りする質問を生成する処理が紹介されています。ATS自動入力の設定はプログラミング不要と案内されています。

対象画面ごとに確認する条件

AIブラウザ操作の活用例を確認したうえで、自社の対象サービスの認証方式、利用規約、画面の条件を整理します。最新の料金、利用条件、試し方は製品ページで確認できます。

個別デモで確認する事項

対象業務や操作画面の条件を伝え、対応可否と設定方法、運用条件を確認します。運営会社の株式会社ロフタルは、所定の登録範囲でISO/IEC 27001（ISMS）認証を取得しています。

よくある質問

まとめ

最初に選ぶのは製品ではなく、検証する業務です。入力、AIの判断、RPAの操作、人の承認、停止条件を書き出し、小さな範囲で動作と運用を確かめます。