AIとRPAの違いと使い分け｜業務自動化に向く技術の判断基準を解説

2026年3月7日
最終更新: 2026年10月7日

この記事の結論

AIとRPAは役割が異なる技術です。文章を読んで分類や下書きの候補を作る工程にはAI、手順が決まった画面操作にはRPAを検討すると、使い分けを整理できます。

ブログ目次

業務自動化を検討するときは、ツールを選ぶ前に、対象業務の入力、判断、実行、結果確認を分けてください。同じ業務でも、工程ごとに適した方法が異なります。

例えば問い合わせ対応では、本文から用件の分類候補を作る工程にAI、確認済みの分類結果をシステムへ登録する定型操作にRPAを使う構成が考えられます。分類が曖昧な場合や顧客対応への影響が大きい場合は、人が確認してから次の工程へ進めます。

企業様によって最適な形は異なります。既存システムで利用できる接続方法、例外の種類、誤処理の影響を確認し、一つの業務から検証することが大切です。

この記事でわかること

AIとRPAの特徴を、業務のどの工程に当てはめるかという視点で整理します。経営者やDX推進担当者が、最初に試す業務と、運用前に決めるべき確認方法を選ぶための内容です。

AIとRPAの根本的な違い — 決めた手順を実行するRPAと、入力内容に応じて分類や生成の候補を作るAIを比較します。
業務ごとの使い分け — 入力形式、判断基準、例外の扱いから、各工程に適した方法を見極めます。
CRM業務での役割分担 — 顧客情報の参照、登録、文章作成、担当者の承認を分けて考えます。
RPAとAIを組み合わせる方法 — AIの結果を操作へ渡す条件と、実行後の確認方法を整理します。
導入を段階的に進める手順 — 業務の棚卸し、検証、停止理由の見直し、対象範囲の拡張までを確認します。

RPAとAIの違いは処理の仕組みにある

RPAとAIは、どちらも人が行っていた業務を支援しますが、得意な工程が異なります。RPAは事前に決めた手順を実行し、AIは入力された情報をもとに分類、要約、文章の生成などを行います。選定では、処理の速さより先に、入力と判断基準を固定できるかを確認します。

RPAは決められた操作を再現する

RPAは、クリック、文字入力、コピーと貼り付け、ファイルの移動といった画面上の操作を、設定された順番に沿って実行します。「特定の画面を開く」「指定欄の値を取得する」「別のシステムへ入力する」というように、開始条件、操作対象、完了条件を明確にできる業務が候補です。

（出典：デスクトップアプリケーションの自動化）

設定した画面要素を見つけられない場合や、入力値が想定と異なる場合には、処理が止まることがあります。運用前に、どの状態を失敗として記録し、誰が原因を確認して再実行するかを決めておきます。

AIは文脈を踏まえて分類や生成を行う

AIは、文章、画像、音声などの情報を受け取り、分類、要約、生成を行います。問い合わせの担当部門の候補を出す、商談履歴を要約する、顧客情報をもとにメールの下書きを作るといった使い方が考えられます。

入力の表現が揃っていなくても扱える一方、出力が元の情報と一致するとは限りません。分類では「どの結果なら人へ戻すか」、下書きでは「何を参照して内容を確認するか」を先に決めます。対外的なメールや契約に関する文書は、担当者が内容を確認して最終判断を行います。

比較表で見るAIとRPAの違い

比較項目	RPA	AI
処理の基盤	事前に設定した手順と分岐	入力内容に応じた分類・生成
入力	項目や形式を特定できるデータ	文章など形式が揃わない情報も対象
例外処理	設定した分岐や停止条件に従う	例外の判定候補を出し、人が確認する
導入の速さ	対象画面、手順、例外の検証範囲による	評価基準、参照情報、確認体制の準備による
メンテナンス	画面や業務手順の変更時に影響を確認する	参照情報や出力品質の変化を確認する
コスト構造	利用料、開発、実行環境、保守を確認する	利用料、設計、出力確認、運用を確認する
学習コスト	フロー設計と例外対応の知識が必要	指示の設計と出力評価の知識が必要
処理の基盤	ルール（if-then）	パターン認識・推論
入力	構造化データ（定型フォーマット）	非構造化データも対応（テキスト・画像・音声）
例外処理	ルール外はエラー停止	文脈に応じて判断・対応
導入の速さ	数日〜数週間	数時間〜数週間
メンテナンス	UI変更のたびに修正が必要	モデル更新で自動的に改善されることもある
コスト構造	ライセンス料（年間数十万〜数百万円）	API利用料（従量課金）
学習コスト	フロー設計の知識が必要	プロンプト設計の知識が必要

この表は比較の出発点です。まず固定できる入力と操作を確認し、次に文章を読む判断工程を切り出します。RPAの停止条件やAIの出力を確認する担当者を決められない場合は、導入範囲を広げる前に業務手順を整理します。

RPAが得意な業務とAIが得意な業務

業務名だけでRPAかAIかを決めず、入力、判断、実行に分解します。同じ請求業務や営業業務でも、決まった項目の転記と自由記述の判定では適する方法が異なります。

次の表は、文章を読む工程にAIを検討できる例です。実際に適用する際は、参照できる情報と、担当者が結果を確認する方法を確かめます。

業務例	AIが適している理由
メール文面の作成・返信	相手や文脈に応じた下書きの候補を作れる
問い合わせの分類・ルーティング	文章から用件を読み取り、振り分け先の候補を出せる
契約書・提案書のドラフト作成	参照情報と指定した条件に沿って下書きを作れる
顧客データの分析・インサイト抽出	記述内容の整理や、確認すべき傾向の候補出しに使える
コンテンツの品質チェック	文脈を踏まえて確認箇所の候補を挙げられる
メール文面の作成・返信	相手や文脈に応じた文面を生成できる
問い合わせの分類・ルーティング	自然言語の意図を理解し、適切な担当に振り分けられる
契約書・提案書のドラフト作成	テンプレートではなく、状況に応じた文書を生成できる
顧客データの分析・インサイト抽出	構造化されていないデータからパターンを見つけられる
コンテンツの品質チェック	ルールだけでなく、文脈に基づいた品質評価ができる

いずれもAIの結果をそのまま採用する前提ではありません。特に返信、契約書、提案書では、参照情報、対象顧客、表現を担当者が確認します。確認に必要な情報を提示できなければ、次の工程へ渡さず差し戻します。

RPAが向いている定型業務

RPAは、手順、入力場所、出力形式を決められる業務に向いています。担当者が行う操作を書き出し、判断を挟まず同じ条件で進められる部分を探します。

業務例	RPAが適している理由
基幹システム間のデータ転記	項目の対応関係と転記先を決められる
請求書データの会計システム入力	確認済みの項目を指定欄へ入力できる
定期レポートの作成・配信	取得元、出力形式、配信条件を定められる
人事システムの勤怠データ集計	集計対象と転記手順を定められる
Web上の定点情報収集	対象ページと取得項目を指定できる
基幹システム間のデータ転記	フォーマットが固定されており、ルール通りに転記するだけ
請求書データの会計システム入力	定型フォーマットの数値を正確にコピーする
定期レポートの作成・配信	決まったデータソースから決まったフォーマットで出力する
人事システムの勤怠データ集計	毎月同じ手順で集計・転記する
Web上の定点情報収集	決まったURLから決まった項目を取得する

表中の業務でも、入力元の形式が揃っているか、転記前に人が内容を判断していないかを確かめます。形式が異なるデータや対象外のレコードが混じる場合は、通常処理から分け、担当者が確認できる状態にします。

AIが向いている判断を伴う業務

AIは、入力内容を読まなければ次の処理を決められない工程で検討します。文章の分類、要約、下書き、記述内容の整理など、人が情報を読んで候補を作っていた工程が対象です。

業務例	AIが向いている理由	人が判断する部分
問い合わせの分類	表現が異なる文章から用件の候補を出せる	重要顧客や判断困難な内容の振り分け
メールの下書き	顧客情報や過去のやり取りを参照した案を作れる	送信可否と最終的な表現
商談履歴の要約	複数の記録から確認すべき要点を整理できる	次回提案や営業方針
失注理由の分類	自由記述を共通カテゴリーへ整理する候補を出せる	分類軸の定義と改善施策
文書の品質確認	文脈を踏まえて不足や不整合の候補を探せる	採用する修正内容
問い合わせの分類	表現が異なる文章から意図を読み取れる	重要顧客や判断困難な内容の振り分け
メールの下書き	顧客情報や過去のやり取りを反映できる	送信可否と最終的な表現
商談履歴の要約	複数の記録から要点を整理できる	次回提案や営業方針
失注理由の分類	自由記述を共通カテゴリーへ整理できる	分類軸の定義と改善施策
文書の品質確認	文脈を踏まえて不足や不整合を探せる	採用する修正内容

AIの出力がもっともらしく見えても、元の情報と一致するとは限りません。参照するデータを決め、担当者が元情報と照らして確認できるようにします。判断に迷う結果が続く場合は、入力情報や分類基準を見直してから適用範囲を広げます。

どちらでも対応できる業務の分け方

一つの業務をRPAかAIのどちらかだけで処理する必要はありません。例えば受信メールの処理では、AIが本文の分類候補を出し、確認済みの分類結果に応じてRPAがフォルダ移動やシステム登録を行う形が考えられます。

判断の分かれ目は次のとおりです。

入力欄と転記先を固定できる場合は、RPAによる操作を検討します。
自由記述を読んで分類する場合は、AIによる候補作成を検討します。
AIの結果によって処理先が変わる場合は、渡す項目、確認担当者、実行を保留する条件を決めます。
誤った処理が顧客対応や金額へ影響する場合は、実行前に人の承認を置きます。

工程ごとの入力と出力が書き出せたら、実際の業務データで例外を確認します。例外を担当者へ戻せることを確かめてから、次の工程との接続を検討します。

CRM業務では一元管理から自動化を考える

顧客情報を使う業務では、AIやRPAがどの情報を参照し、どこへ結果を記録するかを先に決めます。参照元と更新先が曖昧な場合は、自動化する操作より先に情報の管理方法を整理します。

最初にCRMへデータを集約する

転記を自動化する前に、顧客情報の参照元と更新先を整理します。

まず、どの情報をCRMのコンタクト、会社、取引へ保存するかを決めます。そのうえで、外部システムからの定型データ取得にRPA、API連携、インポートのどれを使えるか確認します。候補が複数ある場合は、必要な項目を取得できるか、重複時にどう扱うか、登録結果をどう確認するかを同じ条件で比べます。

入力項目は、営業プロセスやレポートでの用途に沿って定めます。項目の意味や更新担当者が曖昧なままでは、AIが参照する情報も確認しにくくなります。

AIは分類と下書きを担当する

CRMに必要な情報が揃えば、AIによる問い合わせ分類やフォローアップメールの下書きを検討できます。Breezeを使う場合も、参照対象、更新対象、人が確認する時点を先に定義します。

以下の画面は、Breezeが製品レコードを一括更新する前に対象と操作内容を確認し、更新後の値を表示した例です。確認すべき箇所は、対象レコード、変更する項目、実行後の値です。

Breezeが製品レコードの一括更新内容と結果を表示している画面

複数レコードを扱う処理では、対象範囲と更新項目を実行前に確認し、実行後の値も確かめます。対象を特定できない場合や、想定外の項目が変更対象に含まれる場合は、実行を保留します。

重要顧客への連絡や契約・金額に関わる文章では、AIは情報整理と下書きを担い、送信可否は担当者が判断します。

コンタクトから請求までの全体フローに置く

顧客情報を扱う一連の業務を見渡し、各工程で誰が判断し、どのシステムが記録するかを決めます。次の表を使う際は、自社の業務に該当する行を選び、実行前に確認する項目を書き加えてください。

業務段階	RPAやAPIが担う処理	AIが担う処理	人が担う判断
コンタクト登録	定型データの取得と登録	自由記述の分類	重複や対象外データの扱い
営業対応	タスク作成や定型通知	履歴要約、メール下書き	優先順位と送信可否
取引管理	外部情報の同期	商談内容の整理	ステージと受注見込み
顧客対応	チケット登録や担当通知	問い合わせ分類、回答案	例外対応と最終回答
請求連携	確定情報の転記	不整合候補の抽出	金額や契約条件の確定

この役割分担は設計例です。実際には利用中のシステムと業務ルールを確認し、必要な工程に絞って適用します。特に請求連携では、金額や契約条件を人が確定し、転記後に元情報と登録結果を照合できることを次の工程へ進む条件にします。

AIとRPAを選ぶための判断基準

選定では、処理件数に加えて、手順、入力形式、例外、接続方法、誤処理の影響を確認します。順番に見れば、技術を選ぶ前に整理すべき業務ルールも明らかになります。

ルールと入力形式を確認する

最初に、担当者が行っている処理を書き出します。「データを登録する」という大きな単位ではなく、「ファイルを開く」「顧客番号を探す」「入力先を選ぶ」「登録結果を確認する」という工程へ分けます。

次に、各工程を次の基準で分類します。

確認項目	該当する場合の選択
入力形式と操作手順が固定されている	RPAの候補
自由記述を読んで分類する	AIの候補
通常処理は固定だが例外の判定がある	判定基準を定め、AIとRPAの役割を検討
通常処理は固定だが例外の判定がある	AIで判定し、RPAで実行
判断基準を担当者が説明できない	自動化前に業務ルールを整理
誤処理による影響が大きい	人の承認を含む半自動化

担当者ごとに手順が異なる場合は、まず違いが生じる条件を確認します。共通の手順と例外時の扱いを決められた工程から検証し、判断基準が曖昧な工程は自動化の対象から一旦外します。

APIの有無と例外の種類を確認する

対象システムで必要な操作をAPIから実行できる場合は、API連携も候補になります。画面操作を使う場合は、画面変更による影響と保守方法を確認します。APIの有無だけで決めず、必要な取得・登録・更新に対応しているかを調べます。

例外は、入力不足、形式不一致、重複、対象レコードなし、権限不足などに分けます。それぞれについて「自動で再処理できる条件」「人が判断する条件」「処理を止める条件」を決めます。例外の記録先は、CRMなど実際に担当者が確認できる場所に定めます。

判断マトリクスで選択する

業務の状態	選択肢	選ぶ理由
手順が固定され、例外が少ない	RPA	同じ操作を設定した条件で繰り返せるため
入力が文章で、分類や要約が必要	AI	内容を読んで候補を作る工程があるため
AIの判定後に定型操作を行う	AIとRPA	判定結果の確認と実行を分けられるため
APIで対象操作が提供されている	API連携とAI	必要な取得・登録・更新を組み合わせて検討できるため
判断基準が未整理	業務設計を先行	出力を評価する基準を決める必要があるため
手順が固定され、例外が少ない	RPA	同じ操作を繰り返せるため
入力が文章で、分類や要約が必要	AI	文脈を踏まえた処理が必要なため
AIの判定後に定型操作を行う	AIとRPA	判断と実行を分離できるため
APIで対象操作が提供されている	API連携とAI	画面操作を介さず処理できるため
判断基準が未整理	業務設計を先行	自動化するルールを定義できないため
誤処理の影響が大きい	人の承認を含む構成	実行前に対象と内容を判断するため

表の選択肢は検討の出発点です。文章の分類だけなら、実行先との接続を急ぐ必要はありません。分類結果を人が確認できることを確かめたうえで、登録や通知など次の工程を接続するか判断します。

AIとRPAを組み合わせる自動化設計

AIとRPAを組み合わせる場合は、収集、判断、実行、記録の各工程で入力と出力を決めます。処理が止まったときに、どの工程を担当者が確認するかも設計に含めます。

代表的な組み合わせパターン

パターン	構造	適用例
AI判断 → RPA実行	AIが判断候補を出し、確認後にRPAが操作を実行	請求書の仕分け候補 → 確認済み情報の会計システム入力
RPA収集 → AI分析	RPAが指定データを収集し、AIが内容を整理	定点情報の収集 → 変化の確認箇所を整理
AI生成 → RPA配信	AIが下書きを作り、承認後にRPAが配信操作を実行	メール下書き → 宛先と内容の確認 → 配信
RPA監視 → AI対応	RPAが指定した状態を確認し、AIが対応案を作成	システムの状態確認 → 異常時の初動案作成
AI判断 → RPA実行	AIが判断し、RPAがシステム操作を実行	請求書の自動仕分け → 会計システム入力
RPA収集 → AI分析	RPAがデータを収集し、AIが分析・レポート	競合価格の定点収集 → トレンド分析
AI生成 → RPA配信	AIがコンテンツを生成し、RPAが配信	パーソナライズメール生成 → スケジュール配信
RPA監視 → AI対応	RPAがシステムを監視し、異常時にAIが対応	サーバー監視 → 障害時の初動対応

これらは工程を分けるための例です。請求書の仕分け結果、対外的な配信内容、障害時の対応内容などは、影響に応じて人による確認を入れます。AIの結果を次の工程へ渡す前に、必要な項目が揃い、対象を特定できるかを確かめます。条件を満たさなければ実行を保留し、担当者へ戻します。

MCPでAIと外部システムを接続する

MCP（Model Context Protocol）を活用する場合は、AIへ渡す情報と、AIから利用する操作を分けて設計します。参照を許す範囲、実行を許す範囲、人の確認が必要な操作を明確にします。（出典：Model Context Protocol Server Features Overview）

HubSpotやfreeeなどのシステムで必要なAPI操作を利用できる場合は、MCPを介した接続も検討対象です。その際は、AIに利用を許す操作、実行前の確認、実行後の結果確認を決めます。

APIで扱えない操作や、画面からしか操作できない工程があれば、その工程にRPAを使うか検討します。接続方法は、対象システムで実際に利用できる機能と権限を確認して選びます。

AIエージェントの処理を組み立てる方法は、エージェンティック・ワークフロー設計｜AIが自律的に動く業務プロセスの作り方でも解説しています。

人の承認を業務フローへ組み込む

AIに情報収集、分類、要約、下書きを任せる場合も、顧客への対応や実行可否を人が判断する工程を設けられます。承認が必要な処理は、誤処理が起きたときの影響から決めます。

承認時には、処理対象、更新項目、変更前後の値、参照した情報を担当者が確認できるようにします。判断に必要な情報が足りなければ、実行せずに差し戻します。承認後も、実際に記録された値や送信結果を確認します。

コストと運用負荷は保守まで含めて比較する

導入時の費用だけでは、運用開始後の修正や品質管理にかかる負担を比較できません。RPAでは操作対象の変更や実行環境、AIでは出力の確認や参照データの管理を含めて検討します。

コスト構造の違い

以下の表は金額の相場ではなく、見積もりで確認する項目を整理したものです。同じ業務範囲を対象に、初期設定、利用中の費用、担当者の確認作業、変更時の対応を並べて比較してください。

コスト項目	内容	目安
API利用料	利用するサービスの料金体系と処理量に応じた費用	対象業務の処理量と契約条件で確認
プロンプト設計	指示内容、参照情報、評価基準の設計	設計と検証を担当する範囲で確認
品質管理	出力の確認、差し戻し、記録の運用	担当者の確認作業と運用方法で確認
モデル更新対応	出力や利用条件の変化に伴う再確認	利用中のサービスと業務への影響で確認
API利用料	LLMのトークン消費量に応じた従量課金	月額数千円〜数万円（処理量による）
プロンプト設計	ワークフロー・プロンプトの初期設計	数日〜数週間の人的工数
品質管理	出力の品質チェック体制構築	初期構築に数週間
モデル更新対応	AIモデルの仕様変更への対応	不定期（数ヶ月に1回程度）

コスト項目	内容	目安
ライセンス料	製品・契約形態に応じた利用料	契約条件と利用範囲で確認
開発費	フロー設計・実装	対象画面、分岐、例外対応の範囲で確認
メンテナンス費	画面変更対応・エラー修正	保守契約に含まれる作業と担当範囲で確認
インフラ費	実行環境（サーバー/クラウド）	必要な実行環境と運用条件で確認
ライセンス料	年間サブスクリプション	料金は契約内容をご確認ください
開発費	フロー設計・実装	1フローあたり数十万円
メンテナンス費	UI変更対応・エラー修正	対応範囲と費用は見積もりで確認
インフラ費	実行環境（サーバー/クラウド）	月額数万〜数十万円

見積もりを比べる際は、同じ作業をどこまで含めるかを揃えます。例えば、例外時の調査を社内担当者が行う案と、保守契約に含める案では、提示された利用料だけを比較できません。

費用対効果を検討するときは、処理時間に加え、担当者の確認時間、修正時間、停止時の復旧作業を記録します。導入前後を同じ項目で比べ、確認や復旧の負担が増える工程は、処理方法や対象範囲を見直します。

監視と担当範囲を決める

自動化した処理について、実行結果を誰が確認し、例外を誰へ渡し、どの条件で停止するかを決めます。

RPAでは、対象画面が開けない、入力欄が見つからない、認証が切れるといった状態を記録します。AIでは、分類できない、根拠が不足している、不適切な内容を生成したといった状態を確認できるようにします。

完了した処理とともに、担当者へ戻した例外の内容も整理します。同じ例外が繰り返される場合は、入力項目、判断基準、操作手順のどこに原因があるかを確認し、修正後に再度検証します。

自動化に向かない業務もある

手順が頻繁に変わり、判断基準を説明できず、入力データも揃っていない場合は、業務整理から始めます。担当者が実際に何を見て判断しているかを明らかにし、共通の基準を決められる工程から自動化を検討します。

顧客への重要な連絡、契約条件、金額、営業戦略の決定では、人の判断を工程に残します。AIやRPAには、情報整理、候補の提示、承認済み内容の登録など、役割を定めて使います。

スモールスタートで導入範囲を広げる

最初は一つの業務を選び、担当者が入力と結果を確認できる範囲で検証します。業務ルールの問題とシステム上の問題を分けて記録すると、次に何を直すべきか判断できます。

業務を棚卸しする

現在の手作業について、入力元、担当者の判断、操作、出力先、結果の確認方法を書き出します。

棚卸しした業務は、次の三つに分類します。

固定された操作だけで完了する業務
文章や状況を読んで判断する業務
判断と固定操作が連続する業務

判断基準を説明できない業務は、まず担当者の判断例を集めてルールを整理します。入力と完了条件を明確にできた工程から、RPA、AI、組み合わせの候補を選びます。

一つの業務で検証する

最初の対象には、入力と出力が明確で、担当者が結果を元情報と照合できる業務を選びます。定型転記ならRPA、問い合わせ分類や要約ならAIを試すなど、工程ごとに結果を評価します。

検証中は、完了した処理だけでなく、停止した理由、担当者が修正した内容、判断に迷った出力も記録します。入力や設定を直せば再処理できるものと、人へ戻すべきものを分けます。例外の扱いと結果確認の方法が定まってから、実際の運用範囲を広げます。

必要な前後工程へ拡張する

一つの業務で運用方法が固まったら、必要に応じて前後の工程へ広げます。例えば問い合わせ分類から始めた場合は、分類結果を担当者が確認できることを確かめ、次に担当者への通知や対応履歴の記録へ接続するか検討します。

顧客情報を扱う工程では、CRMに何を記録し、担当者がどの結果を確認するかを決めます。新たに接続する工程でも、実行前の条件、例外時の戻し先、実行後の確認方法を定めます。

AIエージェントによる業務自動化の全体像は、AIエージェントで業務自動化｜導入メリットと活用事例を解説でも紹介しています。

よくある質問

RPAを導入済みの場合はAIへ切り替えるべきですか？

まず現在のRPAで停止する工程と、その原因を確認します。画面操作は安定していて、自由記述の分類だけを担当者が行っているなら、その分類工程にAIを試す方法があります。

切り替えを検討する場合は、現在の保守作業、例外の内容、結果を確認する担当者を整理します。同じ操作をAPIで実行できるなら、必要な項目と権限を確認し、その工程の接続方法も比較します。

AIのほうがRPAより導入しやすいですか？

導入の難しさは対象業務によって変わります。文章の下書きや要約をAIで試す場合も、業務に使うには出力の評価基準、参照情報、担当者の確認方法が必要です。

RPAでは操作手順に加え、画面変更や実行環境への対応を考えます。試したい工程の入力、出力、例外を書き出し、必要な準備と運用中の確認作業を比べて選びます。

RPAはAIエージェントに置き換わりますか？

工程ごとに必要な操作と接続方法を確認して判断します。対象操作をAPIから実行できる場合は、AIとAPIを組み合わせる方法を検討できます。画面操作が必要な工程ではRPAが候補になります。

既存のRPAについては、停止理由、保守負荷、実行結果の確認方法を整理します。別の方法を試す場合も、同じ業務データで結果と例外の扱いを比較してから切り替えを判断します。

AIによるメール送信まで自動化してよいですか？

AIは分類や下書きに利用できます。対外的な送信では、誤送信や内容の誤りによる影響を考え、担当者が宛先と文面を確認する工程を設けます。重要顧客や契約・金額に関わる連絡では、送信可否も人が判断します。

送信前に宛先、件名、本文、参照した顧客情報を確認できなければ、送信を保留します。送信後は結果を確認し、対応履歴を必要な記録先へ残します。

まとめ

AIとRPAを選ぶには、業務の入力、判断、実行を分けて考えます。固定された操作にはRPA、文章の分類や要約にはAIが候補です。システムとの接続にはAPIも含めて比較し、誤処理の影響に応じて人の承認を組み込みます。

AIとRPAを選ぶ要点

手順と入力形式が固定されている処理にはRPAを検討します。
自由記述の分類、要約、下書きにはAIを検討します。
AIの結果を定型操作へ渡す場合は、受け渡す条件と結果の確認方法を決めます。
APIが利用できる操作は、必要な機能と権限を確認して画面操作と比較します。
顧客対応や金額に影響する処理には、人の承認を組み込みます。
顧客情報を扱う場合は、CRMで参照する情報と記録する結果を定めます。

まずは一つの業務の分解から始める

まずは、自動化したい業務を一つ選び、次の順番で整理してください。

入力元、処理内容、出力先、例外、最終判断者を書き出します。
固定操作、文章を読む工程、人が決める工程を分けます。
担当者が結果を確認できる範囲で試し、停止理由と修正内容を記録します。
例外の扱いと実行後の確認方法が定まったら、前後の工程へ広げるか判断します。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。

記事の内容を、そのまま実務に落とし込みたい方向け

無料で相談する資料をダウンロード

株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

著者情報

今枝 / Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。