RPAと生成AIの違いは「工程のどこに使うか」で決まる：1つの業務をルール・AI・人に分けて見る

「RPAと生成AIは何が違うのか。うちの業務にはどちらを入れるべきか」。比べ始めると、機能の説明は見つかっても、自社の業務に当てはめたところで決めきれなくなることがあります。両者は優劣の関係ではなく、得意な「工程」が違います。業務をひとまとまりのまま見ていると、選べなくなるのかもしれません。この記事は、業務改善を担当する経営者や情報システム担当者が、1つの業務を工程に分け、ルール処理・AI・人の担当を決めるまでの考え方を、例で示すものです。特定の製品の比較や推奨はしません。

仕事の流れ全体を再設計する考え方は、AI業務設計・業務AXにまとめています。ここでは、RPAと生成AIの違いを入口にして、1つの業務の工程の分け方に絞ります。

まず、言葉を整理する

RPAとは、人がパソコンで行っている決まった手順（入力、転記、ファイルの保存、通知など）を、あらかじめ定めたとおりにソフトウェアに実行させる仕組みです。

生成AIとは、指示や渡した資料をもとに、文章の要約・分類・下書きなどを作る仕組みです。

違いは「出力に何を求めるか」に出る

見る点	RPA	生成AI
動き方	決めた手順を、そのとおり実行する	渡された内容を読み取り、文章などを作る
同じ入力のとき	同じ結果になる前提で組む	毎回同じ結果になるとは限らない
向いている工程	手順が書き切れる転記・登録・保存・通知	形が一定でない文章を読む・整理する・下書きする
間違い方	手順にない入力で止まる。または想定外の入力にも手順どおり進む	もっともらしい文面のまま、内容を誤る
向いていない工程	内容の解釈や、手順にない状況の判断	毎回同じ結果が必要な処理、取り消しにくい操作の最終実行

表は一般的な整理です。実際の動きは、製品や設定によって異なります。

どちらが上かではなく、「この工程で、何を求めるか」で選びます。そのため、比較の単位を業務全体から工程に下ろします。

工程ごとに当てはめる4つの問い

工程の1つひとつに、次の4つを順に問います。

1. 手順を、迷わず文章で書き切れるか。書き切れるなら、ルール処理の候補です。
2. 入力は決まった形か。メール本文のように形が一定でないなら、読み取りや整理でAIの出番が出ます。
3. 結果は毎回同じでなければならないか、下書きで足りるか。同じ結果が必須ならルール処理、下書きで足りるならAIが使えます。
4. 間違えたとき、取り戻せるか。送信、登録、支払いのように取り戻しにくい操作の手前には、ルール処理でもAIでも、人の確認を置きます。

問い1から3で「ルール・AI」の候補が決まり、問い4で「人が見る場所」が決まります。この順に当てはめると、RPAか生成AIかという二択ではなく、ルール・AI・人の3つに分ける形になります。

例：見積依頼メールへの回答を、工程に分ける（架空）

書き方を示すために、仮の業務を分けてみます。取引先から届く見積依頼のメールに、回答を送るまでの流れです。実在の業務ではなく、あくまで例です。実際の工程は、担当者の言葉で書き出してください。

工程	内容	担当	分けた理由
受け取りと記録	受信したメールと添付を所定の場所に保存し、依頼管理表に行を作る	ルール処理	手順が書き切れ、毎回同じ結果でよい
依頼内容の読み取り	本文から、品目・数量・希望納期などを項目に整理する	AI（候補を出す）	文面の形が一定でない
読み取り結果の確認	整理された項目を、原文と見比べて直す	人	整理の誤りが、後ろの工程の土台になる
取引先の照合	取引先一覧と突き合わせる	ルール処理	一致か不一致かで決まる
価格・納期の判断	回答する内容を決める	人	社内の判断と責任が伴う
回答メールの下書き	決めた内容を使って、文面案を作る	AI	下書きで足り、人が直す前提にできる
送信前の確認	文面と添付を見て、送ってよいものに印を付ける	人	送信は取り戻しにくい
送信と記録	印の付いたものだけ送信し、管理表を更新する	ルール処理	印のない案件は動かさない

例外が出たときの戻し先

例外	戻し先	添えるもの
項目が読み取れない、または欠けている	その依頼の担当者	欠けた項目と、原文の位置
取引先が一覧と一致しない	担当者	一致しなかった名称。新規の取引先の扱いは社内で決める
想定外の添付や依頼の形式	担当者	受信したメールそのもの

この例では、ルール処理の工程はRPAのほか、メールソフトの機能やAPI連携でも足りる場合があります。生成AIが担うのは、読み取りと下書きの2つの工程です。人は、確認と判断の工程を持ちます。工程に分けると、「RPAか生成AIか」を決める前に、そもそもどこに人が必要かが見えてきます。

確認の置き方：AIの直後と、戻せない操作の手前

例では、人が見る場所を2か所にしています。

• AIが整理した項目が、後ろの工程の土台になる前（読み取り結果の確認）
• 送信のように、取り戻しにくい操作の前（送信前の確認）

見る場所が決まっていると、何を見ればよいかも決まります。読み取り結果の確認では原文と合っているか、送信前の確認では文面と添付が決めた内容どおりかを見ます。また、確認の印がなければルール処理が動かない形にしておくと、確認を飛ばして送られる事態を避けられます。

判断条件：工程に分けて考えるのが向いている業務

向いている業務：

• 担当者が、いまの流れを工程ごとに話して書き出せる
• 工程ごとに、入力と出力を言える
• AIの出力を人が見て、直す余地がある

工程に分けるのを先に延ばしたほうがよい業務：

• 例外がほとんどで、判断の基準が担当者の頭の中にしかない
• 取り消せない操作の前に、人が確認できる設計にできない
• 扱う情報を、どのAIやサービスに渡してよいかが、社内で決まっていない

個人情報や機密情報の取り扱いは、この記事では決めません。社内の規程の確認や、必要に応じて専門家への相談に分けて進めてください。

工程に分ける進め方（実装手順）

1. 対象業務を1つに絞る。「見積依頼への回答」のように、始まりと終わりが言える仕事を選びます。
2. 担当者に流れを話してもらい、工程に分けて書き出す。誰が、何を見て、何をするかを残します。
3. 工程ごとに4つの問いを当てはめ、ルール処理・AI・人を仮に置く。迷う工程は、いったん人の側に置きます。
4. 人が見る場所を決める。AIの出力が土台になる前と、取り戻せない操作の前を、先に押さえます。
5. 例外の戻し先を、工程ごとに決める。止まる条件、渡す相手、添える情報を書きます。
6. 小さな範囲で試し、直した内容と戻った案件を見て、分担を見直す。

ステップ3と4は、実際に仕事をしている担当者の知識がなければ埋まりません。手順の紙を作る人と、仕事をする人が同じ場に集まって進めてください。

うまくいかないパターン

• 業務全体を1つのツールに任せる前提で、RPAか生成AIかを先に決める
• 生成AIの出力を、人の確認なしに、送信や登録のルール処理へ流す
• すべての工程で人が見直す設計になり、どこを見るべきかが決まらない
• 例外の戻し先がなく、止まった案件がたまる
• 試した結果を反映せず、最初の分け方のまま固定する
• 画面や帳票、手順が変わったときに、ルール処理の側を直す担当が決まっていない

WITHPROJECTSの進め方

WITHPROJECTSでは、業務のAI化を、要件整理、設計、PoC、受入試験、運用改善の工程で進めます。 設計の工程では、AI・決まった処理（コード）・API・人に、役割を分けます。AIが担う部分と、人が判断する部分を分けて設計することを基本にしています。

外部に任せる場合の条件は業務AI化の委託先の選び方に、依頼前の社内の整理はAI導入の見積もりを頼む前に、社内で整理しておく5つのことにあります。

次の一歩

RPAと生成AIのどちらを使うかを、自社の業務の工程に分けて整理したい方は、個別相談の予約へお進みください。（個別相談会（30分）の予約ページへ移動します）