WorkHQ登場前夜：「RPA or AI」ではなく、「RPA&AI」という考え方

TasukuHasegawa — Thu, 02 Apr 2026 05:20:46 GMT

みなさん、こんにちは！カスタマーサクセスの長谷川です。

前回の投稿では、「“RPAの得意領域の外側”に効率化ニーズが広がってきている」というお話をしました。

今回は、その「効率化ニーズの広がり」が、実際の現場でどのように現れているのか。そして、それらにどうアプローチしていくことが理想なのかをもう一歩深く整理していきたいと思います。

　＜シリーズ一覧＞

RPAだけでは捉えきれなくなってきた業務の変化とは？
「RPA or AI」ではなく、「RPA&AI」という考え方（今回）
WorkHQとは？WorkHQで何ができるの？（4月上旬予定）
WorkHQの活用イメージ（4月中旬予定）
WorkHQリリースのお知らせ（4月下旬予定）

■RPA単体では対応が難しい業務の具体例
「RPA単体では対応が難しい業務」とは、具体的にどういったものが考えられるでしょうか？典型的な想定ケースを元に整理してみます。

	ケース1	ケース2	ケース3
業務ケース	問い合わせ内容の理解・振り分け業務（例：社内問い合わせ、顧客からの問い合わせ）	申請内容の妥当性判断業務（例：人事／購買／経費申請など）	複数情報を統合した総合判断業務（例：与信判断、顧客対応可否判断、在庫可否判断など）
業務処理のフローイメージ	ユーザーからメール/チャットが届く内容を読み、要点を理解し、問い合わせ内容の種別を判断必要に応じて、過去履歴や関連情報を検索初期回答を草案し、担当者に引き継ぐ	申請書を読み込む添付資料の内容と突合する条件に応じて判断項目を変動させて判断問題なければ申請を進める不備があれば差し戻す	システムAで属性を確認システムBで状態を確認システムCで過去履歴を参照条件の組み合わせで結論を最適なものに変える
なぜRPAだけでは対応が難しい？	文章の表記揺れなどにより、IF分岐での対応に限界がある問い合わせ内容の“意図”を解釈する必要がある（判断決定のためのルール化が困難）過去履歴や関連情報を参照しないと判断できないケースがある担当者ごとに判断が微妙に異なり、標準化が難しい	申請内容・添付資料の形式がバラバラで、固定ルールに落とし込みにくい判断に“前提情報”の確認が必要不備の理由が多岐にわたり、例外処理の設計が肥大化しやすい “判断の理由”を説明する必要があり、ブラックボックス化が許容されない	システムA/B/Cの情報を“組み合わせたうえで”判断が必要判断基準が“状況依存”で、RPAに必要な“固定ロジック”へ落とし込めない参照システムの仕様変更があるとロボ全体を見直す必要がある

■「RPAで対応しきれない業務」の共通特性
いくつかの業務を見ていくと、共通する特徴が見えてきます。

内容や文脈の理解・判断が必要になる
ケースに応じて処理手順が変わる
複数の情報源から情報を集約する必要がある
人の確認や調整が工程に含まれる
ルール変更や例外が頻繁に発生する

これらの業務は、一見すると“人がやるしかない”ように見えます。

ただ実際に中身を分解してみると、内容理解・分類・一次判断といった工程は、AIに任せられる余地があるケースも少なくありません。こうした工程をAIが補助することで、RPAと組み合わせた自動化が現実的な選択肢として見えてきます。

■では、どうアプローチするべきなのか？
RPAでの対応が進んだ先に残るのは、多くが「判断」「調整」「例外」など、人が担ってきた領域です。
これらにどう向き合うべきか、ここではアプローチの考え方を3つに整理します。

--------------------------
①いちタスクではなく、「業務全体の流れを前提」に設計する
RPAの前後には、判断・確認・情報準備など、人の介在ポイントが必ず残ります。まずは業務全体の流れを棚卸しし、以下を可視化することが重要です。

どこで判断が行われているのか
どこで調整や引き継ぎが発生しているのか

これにより、RPAをどこで使うべきか、AIをどこに組み込むべきかといった、業務全体の最適化方針が初めて明確になります。
--------------------------
②判断・分類など「ロジック化しづらい工程」に、AIを適切に組み込む
RPAが苦手とするのは、以下のような特性を持つ工程です。

判断材料が揺れること
形式が一定でないこと
分岐が無限に増えること

この領域には、AIを以下のような役割で補助的に組み込むアプローチが適しているのではないでしょうか。

内容の理解
分類・整理
要点の抽出
一次判断案の提示

“AIが揺れる情報を整理し、人が最終判断を行う”

この役割分担を取ることで、RPAが苦手だった非定型部分を補完でき、業務フロー全体としての自動化の幅が大きく広がります。
--------------------------
③RPA・AI・人を“連携させる設計”を行う
RPA・AI・人がそれぞれバラバラに動くと、工程間の“切れ目”で処理が止まりがちです。

理想は、以下のような状態です。

AIが理解・判断を補助し
RPAが実行を担い
人が最終判断や例外を処理し
それらが一つの業務フローとして連動する

この“つながる運用”が実現すると、RPAの運用を担うみなさまにとっては次のような実務メリットが生まれます。

工程の切れ目で止まらなくなり、業務全体のリードタイムが短縮される
RPA前後の人的作業が減り、“RPAの効果が出にくい構造”が解消される
例外対応が整理され、保守工数が大きく減る
業務変更時の影響範囲が明確になり、修正の負担が減る

RPA・AI・人を業務プロセス全体の中で連携させることで、RPA単体では届かなかった領域まで含めた最適化が可能になります。

その結果、業務全体としての効率化が進み、RPAの価値をこれまで以上に引き出せるようになります。
--------------------------

まとめると、「RPA or AI」や「RPA to AI」という単一の選択を考えるのではなく、「RPA＆AI」をどう設計するかがキーポイントと言えるでしょう。

■ 次回は「WorkHQとは？」へ
今回整理した“RPAでは届きにくい領域”とそのアプローチに対して、私たちは新しい選択肢としてBlue Prism WorkHQを準備しています。

次回は、Blue Prism WorkHQが生まれた背景、そして今回挙げたような課題にどのように応えていくのか、次回から少しずつご紹介できればと思います。

ぜひ、引き続きお付き合いいただけますと嬉しいです！
※Likeで応援いただけると励みになります！

	ケース1	ケース2	ケース3
業務ケース	問い合わせ内容の理解・振り分け業務（例：社内問い合わせ、顧客からの問い合わせ）	申請内容の妥当性判断業務（例：人事／購買／経費申請など）	複数情報を統合した総合判断業務（例：与信判断、顧客対応可否判断、在庫可否判断など）
業務処理のフローイメージ	ユーザーからメール/チャットが届く内容を読み、要点を理解し、問い合わせ内容の種別を判断必要に応じて、過去履歴や関連情報を検索初期回答を草案し、担当者に引き継ぐ	申請書を読み込む添付資料の内容と突合する条件に応じて判断項目を変動させて判断問題なければ申請を進める不備があれば差し戻す	システムAで属性を確認システムBで状態を確認システムCで過去履歴を参照条件の組み合わせで結論を最適なものに変える
なぜRPAだけでは対応が難しい？	文章の表記揺れなどにより、IF分岐での対応に限界がある問い合わせ内容の“意図”を解釈する必要がある（判断決定のためのルール化が困難）過去履歴や関連情報を参照しないと判断できないケースがある担当者ごとに判断が微妙に異なり、標準化が難しい	申請内容・添付資料の形式がバラバラで、固定ルールに落とし込みにくい判断に“前提情報”の確認が必要不備の理由が多岐にわたり、例外処理の設計が肥大化しやすい “判断の理由”を説明する必要があり、ブラックボックス化が許容されない	システムA/B/Cの情報を“組み合わせたうえで”判断が必要判断基準が“状況依存”で、RPAに必要な“固定ロジック”へ落とし込めない参照システムの仕様変更があるとロボ全体を見直す必要がある

topic WorkHQ登場前夜：「RPA or AI」ではなく、「RPA&AI」という考え方 in Japan Community

WorkHQ登場前夜：「RPA or AI」ではなく、「RPA&AI」という考え方