RPAとAIの違いと、使い分けの基準

用語の混乱が、導入の混乱を生む

本題に入る前に、なぜ用語の整理が重要なのかを確認します。理由は単純で、言葉が曖昧なまま進んだプロジェクトは、期待値が曖昧なまま進むからです。

典型的な失敗パターンはこうです。経営会議で「AIで業務を自動化する」という方針が決まる。しかし現場が本当に困っているのは、毎日の受注データを基幹システムへ転記する作業だった。この作業は手順が完全に決まっており、必要なのはRPA、あるいはもっと単純なマクロです。ところが「AI」という言葉で走り出したために、高機能なAIツールを契約し、判断など一切不要な転記作業に充ててしまう。結果、コストは割高、精度はむしろ不安定、現場は「AIは使えない」という印象だけを持ち帰る。

逆のパターンもあります。問い合わせメールの内容を読んで振り分ける業務を、RPAで自動化しようとするケースです。メールの文面は書き手によって千差万別で、決まった手順では処理できません。ルールを100個書いても101個目の例外が来る。保守に追われた末に、プロジェクトは静かに止まります。

どちらも、技術が悪いのではありません。技術と業務のマッチングを誤っただけです。そしてマッチングを誤る原因は、ほとんどの場合、RPAとAIがそれぞれ何をする技術なのかという最初の仕分けを飛ばしたことにあります。まずここを固めます。

RPAとは：決められた手順を、正確に、疲れずに繰り返す

RPA（Robotic Process Automation）は、人がパソコン上で行う操作を、そのまま再現するソフトウェアです。このシステムにログインし、この画面を開き、この項目をコピーし、別のシステムのこの欄に貼り付け、保存ボタンを押す。人が手順書どおりに行っていた画面操作を、ソフトウェアのロボットが代わりに実行します。

重要なのは、RPAがルールベースの技術だという点です。動きはすべて、事前に人間が定義した手順とルールに従います。「Aの場合はこうする、Bの場合はこうする」という分岐も書けますが、その分岐条件自体を人間が漏れなく定義しておく必要があります。裏を返せば、RPAは定義されていない状況に出会うと、止まるか、誤った処理をするということです。RPA自身が状況を解釈して気を利かせることはありません。

この性質は弱点であると同時に、最大の強みでもあります。定義したとおりにしか動かないということは、定義が正しければ100%正しく動くということです。人間のように疲れて転記を間違えることも、月末の繁忙で処理が遅れることもありません。同じ入力に対しては、何回実行しても必ず同じ結果が返ります。この「再現性」こそがRPAの価値の中核です。

なお、ExcelのマクロやVBA、各種ツールの自動化機能も、思想はRPAと同じルールベースの自動化です。違いは適用範囲で、マクロは特定のアプリケーションの中で完結し、RPAは複数のシステムをまたいだ画面操作を扱えます。Excel内で完結する集計や整形ならマクロで十分であり、わざわざRPAを導入する必要はありません。

AIとは：曖昧な入力を解釈し、判断し、生成する

一方のAI、特に近年の生成AIは、RPAとは根本的に異なる仕事をします。曖昧で定型化されていない入力を解釈し、文脈に応じた判断や文章の生成を行う技術です。

たとえば、取引先から届くメール。「先日の見積りの件、数量を50から80に変えて再送いただけますか。あと納期も1週間前倒しできると助かります」。この一文から、対象案件・変更項目・希望納期を読み取る作業は、決まった手順では書けません。書き手ごとに表現が違い、必要な情報が揃っていないことすらあるからです。人間が「読めばわかる」で処理してきたこの種の解釈を、AIは実用的な精度でこなします。手書き書類の読み取り、問い合わせの分類、報告書の下書き、議事録の要約。いずれも「解釈と生成」の仕事です。

ただし、必ず理解しておくべき性質があります。AIの出力は確率的であり、100%の正確性は保証されないということです。AIは統計的に最も確からしい答えを出す仕組みであって、ルールどおりに動く機械ではありません。100件のうち97件は人間より速く正確に処理しても、残り3件でもっともらしい間違いを含む可能性が常にあります。しかも間違うときも自信ありげな文面で出力されるため、見た目からは誤りを見分けにくい。

「AIは間違えるから業務では使えない」という結論に飛ぶのは早計です。人間の作業にもミスはあり、その前提で確認や承認のフローが組まれてきました。AIも同じです。問うべきは「間違えるかどうか」ではなく、「間違いを許容できる業務か、間違いを検出する仕組みを組めるか」。この視点が、後述する使い分けの基準に直結します。

整理すると、両者の違いは次の一文に集約されます。RPAは決められたことを間違いなく実行する技術、AIは決められていないことを解釈して判断する技術。得意分野が正反対だからこそ、比較して優劣を論じる対象ではなく、業務の性質に応じて使い分ける対象なのです。

使い分けの基準：入力の定型度 × 判断の有無で4象限に分ける

では、目の前の業務にどちらを使うべきか。判断の物差しは2つです。第1に入力の定型度。業務に入ってくるデータの形式が毎回同じか、バラバラか。第2に判断の有無。処理の途中に、内容を解釈して対応を変える工程が入るか。この2軸を掛け合わせると、業務は4つの象限に仕分けられます。

各象限を補足します。

• 定型入力 × 判断なし — 純粋な定型作業。ここにAIを使うのは過剰投資であり、精度面でも不利です。ルールベースで組めば100%動くものを、わざわざ確率的な技術に置き換える理由はありません
• 定型入力 × 判断あり — たとえば「金額が一定以上なら上長承認に回す」といった業務。この種の判断は、基準を明文化すればただの分岐ルールになります。まずルール化を試み、明文化しきれない部分だけAIに任せます
• 非定型入力 × 判断なし — 入力の形式さえ揃えば、あとは決まった処理という業務。AIに「読み取りと構造化」だけをさせ、以降はRPAで処理する組み合わせ型が正解です
• 非定型入力 × 判断あり — 解釈と判断そのものが業務の中身。RPAでは原理的に対応できず、AIの活用を検討する領域です。ただし後述のとおり、最終判断を人に残す設計が前提になります

この表の使い方として重要な注意があります。仕分けの単位は「業務」ではなく「工程」です。一つの業務の中に、定型の工程と非定型の工程が混在しているのが普通だからです。「受注処理」という業務を丸ごとどちらかに当てはめるのではなく、「注文の受領→内容の確認→システム入力→納期回答」と工程に分解し、工程ごとにこの表へ当てはめてください。実務での使い分けは、必ずこの解像度で行います。

実務の主戦場は「AIとRPAの組み合わせ」にある

工程分解の視点を持つと、見えてくることがあります。実務で効果の大きい自動化の多くは、RPA単独でもAI単独でもなく、両者をつないだパイプラインだということです。

典型例を挙げます。取引先から届く注文が、メール本文だったりFAXだったり添付の書式だったりと、形式がバラバラな会社は珍しくありません。従来この業務が自動化できなかったのは、入口が非定型だったからです。ここに両者を組み合わせます。

1. AIが解釈する — 届いたメールやFAXの読み取りデータから、品名・数量・希望納期・届け先といった必要項目をAIが抽出し、決まった形式のデータに構造化する
2. 人が確認する — 抽出結果を担当者が画面で確認する。AIの読み取りに誤りがあればここで修正する。1件あたり数十秒の確認作業
3. RPAが入力する — 確認済みの構造化データを、RPAが基幹システムへ転記する。この工程は完全な定型作業なので、ルールベースで100%正確に処理できる

この構成の要点は、それぞれの技術を得意な工程だけに使っていることです。曖昧さの処理はAIに、正確な反復はRPAに、そして最終的な責任の担保は人に。どこか一つの技術ですべてを賄おうとした瞬間に、この設計は崩れます。全部AIに任せれば転記の正確性が確率頼みになり、全部RPAでやろうとすれば入口の非定型さで詰まります。

同じ構造は多くの業務に応用できます。請求書の受領処理（AIが読み取り→人が確認→RPAが会計システムへ入力）、問い合わせ対応（AIが分類と回答下書き→人が確認・送信→RPAが対応履歴を記録）、採用応募の受付（AIが応募情報を構造化→RPAが管理表へ登録）。「AIかRPAか」という二者択一の問いを立てている段階から、「どの工程にどちらを置くか」という設計の問いに進めるかどうかが、成果の分かれ目です。

選定の落とし穴と、精度要件という最後の物差し

使い分けの基準を持っていても、実際の選定では2つの落とし穴が待っています。

第1の落とし穴は、RPAで済む業務にAIを使う過剰です。AIの注目度が高い時期には、「せっかくならAIで」という空気が生まれます。しかし定型作業に対してAIは、コストが割高なだけでなく、確率的な出力ゆえに「たまに間違える転記係」になりかねません。決まった手順で組めるものは、枯れたルールベースで組む。地味ですが、これが正解です。

第2の落とし穴は、AIが必要な業務にRPAを無理に当てる無理です。非定型な入力や判断をルールの積み増しでカバーしようとすると、例外条件が際限なく増えていきます。導入時に50本だったルールが1年後に300本になり、誰も全体を把握できず、業務が少し変わるたびにロボットが止まる。いわゆる保守地獄です。ルールの本数が増え続けているRPAは、そもそもRPAに向かない業務を担わされているサインだと考えてください。

そして、どちらを使うかの最後の物差しになるのが精度要件です。その業務は、どこまでの間違いを許容できるのか。

特に金銭や契約に直結する処理は、AIの精度がどれだけ上がっても、確率的な仕組みに最終出力を委ねるべきではありません。ルールベースで組み、人の確認を残す。一方、下書きや分類のように「人が最後に手を入れる前提」の業務は、AIの多少の揺れが問題にならず、スピードの恩恵を最大限受けられます。求める精度から逆算して技術を選ぶ。この順序を守るだけで、選定の失敗は大きく減ります。

境界線は動き続ける。出発点は用語ではなく自社の業務

最後に、この記事の整理を長持ちさせるための視点を一つ加えます。RPAとAIの境界線は、固定されたものではないということです。

数年前まで「非定型だからAIでも難しい」とされた手書き文字の読み取りは、いまや実用水準にあります。RPA製品の側にもAIによる画面認識や例外処理の補助が組み込まれ始め、AIの側は操作の自動実行へと守備範囲を広げています。両者は互いの領域に染み出しながら融合しつつあり、「これはRPAの仕事、これはAIの仕事」という線引きは、今後も動き続けます。今日「できない」と判定した業務が、1〜2年後には現実的なコストで自動化の対象に入ってくる。この前提で、見送った業務も定期的に再評価すべきです。

境界が動き続けるからこそ、特定のツール名や製品カテゴリを起点に検討を始めるべきではありません。ツールの機能は毎年変わりますが、「この業務の入力は定型か」「判断は入るか」「どこまでの精度が必要か」という自社業務の性質は、そう簡単には変わらないからです。業務の性質の把握は、技術が入れ替わっても使い回せる資産になります。

整理します。RPAは決められた手順を100%正確に繰り返す技術であり、判断はしません。AIは曖昧な入力を解釈して判断・生成する技術であり、出力は確率的です。使い分けは「入力の定型度×判断の有無」の4象限で工程単位に仕分け、実務の主戦場は両者の組み合わせにあります。迷ったら精度要件に立ち返る。1件のミスも許されないならルールベース＋人の確認、揺れを許容できるならAI。

明日からできる最初の一歩は、ツールの資料請求ではありません。自社で時間を取られている業務を一つ選び、工程に分解して、各工程に「入力は定型か」「判断が入るか」の2つの問いを当ててみることです。この仕分けが済んでいれば、ベンダーの提案を受ける立場から、要件を提示する立場に変わります。技術の言葉に振り回されず、自社の業務の性質から出発する。それが、RPAとAIの違いを理解することの、実務上の意味です。