RPA・通常の自動化・生成AIの役割

RPAは、パソコンで繰り返す操作を、決めた手順に沿って実行する仕組みです。Microsoftのデスクトップフローの説明では、ルールに基づく処理や、アプリの画面要素などを使った操作が紹介されています。画面からデータを取り出し、別の画面へ入力するといった工程が候補になります。

RPAも自動化の一種です。この記事では比較のため、画面操作を中心とするRPAと、データを直接扱う通常のプログラム・既存機能を分けます。RPAにも計算やデータ処理の機能があり、製品によってはAIと組み合わせられるため、明確に別々の製品群という意味ではありません。

生成AIは、指示や材料から文章などを作る技術です。文章の要約や下書きに加え、内容に応じた分類候補を作る用途も考えられます。ただし、自然な文章でも事実や数値が正しいとは限りません。確定した計算結果と、AIが作る説明文を区別します。

工程と入力の状態から選ぶ

次は業務を分けるための目安です。特定製品の対応保証や、費用・効果の優劣を示すものではありません。

方法 候補になる工程・条件 人が確認する点
RPA 操作手順と入力先が決まっており、既存の画面を使って転記・ファイル取得を繰り返す 対象画面、入力先、操作権限、画面変更や途中停止時の処理状況
通常のプログラム・既存機能 項目とルールが決まったデータの計算・集計・照合。ファイルやAPIでデータを扱える 計算式、ルールの版、欠けたデータ、例外、登録済みかどうか
生成AI 自由な文章の分類候補、要約、報告文や返信の下書き 元の資料との一致、分類の妥当性、数値・固有名詞、根拠のない説明
人の判断 ルールが未確定、資料が不足、個別事情を踏まえた承認が必要 何を確定できるか、追加で何を確認するか、誰が責任を持つか

まず、今のツールに必要な機能がないか確認します。決まった計算や条件判定なら、通常の自動化で扱える可能性があります。自由な文章を読む工程が残る場合は、生成AIが候補を作り、人が確認する方法を検討します。

データを直接取得・登録できる連携があるかも調べます。画面操作を使うなら、表示の変更や操作の失敗をどう検知し、どこで止めるかを決めます。APIがあっても、必要な項目・操作・契約・権限が使えるとは限らないので、提供元の最新仕様を確認してください。

検証ラボ：単語による判定から、文章の意味を読む方法へ

2026年10月9日の問い合わせメールの分類と返信下書きの検証ラボでは、短い架空メール6件で初版と修正版をそれぞれ1回実行しました。初版はPythonで単語を順に調べ、最初に一致した分類の定型文を出す方法でした。

ところが、「至急」がない業務停止のメール（LAB-M04）は通常扱いになり、受付時間と返金を尋ねたメール（LAB-M05）は受付時間だけの下書きになりました。単語の有無と最初の一致だけでは、業務への影響と複数の用件を拾えなかったため、修正版では生成AIが本文を読み、分類候補と根拠の原文を残す方法に変えました。業務停止は下書きを作らず優先確認へ回し、二つの質問は受付時間の回答案と返金の判断待ちに分けて残しました。

一方、同じメールの再取り込み（LAB-M06）は、Pythonで同一実行内の message_id を照合し、二つ目の下書きを作らず保留にしました。この試作で選んだのは、文章の理解と分類候補は生成AI、決まった識別子の照合は通常のプログラムという分担です。PythonがAIを呼び出す連携は作っていません。

RPAは検証しておらず、製品の性能比較ではありません。失敗しやすい条件を入れた架空データでの試作で、分類精度や削減効果は測定していません。人による承認・メール送信・本番運用も未実施です。AIの見落としを人が原文で確認する工程は必要で、照合履歴も次の実行には残らないため、実運用の二重返信防止には足りません。詳細な条件・結果・修正内容はリンク先のラボ記事で確認できます。

組み合わせる具体例：月次報告を作る

以下は役割分担を説明する想定例です。RPAの導入実績や、効果を測定した事例ではありません。

  1. 実績データを取得する。 既存ツールの書き出しやAPIを確認します。画面操作が必要なら、RPAで決まった取得手順を実行する方法も候補にします。
  2. データを検査し、集計する。 通常のプログラムで必要な項目、重複、対象期間を確認し、決めた計算式を使います。欠けや例外は確認待ちにします。
  3. 報告文の下書きを作る。 入力が許可された集計結果を材料に、生成AIが文章案を作ります。材料にない原因や成果を推測で補わないようにします。
  4. 担当者が確認・承認する。 対象期間、数値、説明の根拠、共有先を確認し、必要な修正をしてから報告を確定します。

一つの業務でも、取得はRPA、計算は通常のプログラム、文章は生成AIという組み合わせが考えられます。取得が既存機能だけで足りるなら、RPAを追加する必要はありません。

公開事例：評価の計算と所見の下書きを分ける

ルールに沿った評価の算出と対象者の抽出は、PythonとClaude APIを使った導入事例です。実績データを検査し、基準値や例外条件に沿って評価を算出します。評価の計算にはAIを使わず、月次レポートの所見の下書きだけをAIが作ります。

データの欠けや例外がある拠点は「要確認」とし、自動では評価を確定しません。実案件で開発した仕組みを架空データで再現して公開しています。RPAの導入事例ではなく、通常のプログラムとAIの役割分担を示す例です。

始める前に決める確認と停止の条件

最初は一つの作業に絞り、入力から出力までの手順を書き出します。方法を選ぶときは、自動処理にかかる時間だけでなく、人が確認・修正する手間も含めて比べます。

  • 入力： 対象の期間・項目・形式を決め、欠けや重複がある場合の担当者を決める。AIへ渡す情報は、社内の許可と利用サービスの条件を確認する。
  • 処理： 計算ルールや画面が変わったときの見直し担当を決める。想定外の入力や、不明な分類は無理に確定せず確認待ちにする。
  • 確定・送信： 下書きと確定を分け、金額・評価・宛先など影響の大きい項目を担当者が確認する。
  • 再開： 処理済み・確認待ち・未処理を区別する。途中で止まったら、すでに登録・送信されたものを確認してから再実行し、二重処理を防ぐ。

生成AIだけでなく、RPAや通常のプログラムも、入力先やルールが誤っていれば誤処理につながります。接続できないときの手動手順と、修正・保守を担当する人も用意します。顧客情報の扱いは、生成AIに入力する前の確認手順をご覧ください。

手動利用・連携と、製品選びは分けて考える

ここで比べたのは、工程ごとの役割です。生成AIを人が画面で使うか、APIで業務につなぐかは、手動利用とAPI連携の選び方で解説しています。

既存製品の標準機能へ業務を合わせるか、独自の仕組みを作るかは、SaaS導入と個別自動化の選び方をご覧ください。いずれも、今のツールで足りる範囲を確かめてから、残る工程を検討します。

hirostaの支援範囲・料金はサービス・料金、既存ツールの連携や改修はシステム開発にまとめています。製品や方式が決まっていなくても、困りごとから相談できます。

表計算の中で計算・転記・文章の分類を分担する方法は、関数・Apps Script・生成AIによる集計自動化の選び方をご覧ください。

よくある質問

Q. RPAと生成AIの違いは何ですか？ RPAは決めた手順に沿う画面操作などを自動化し、生成AIは文章の分類候補や要約・下書きを作る用途が候補になります。計算・集計には通常のプログラムも含めて、工程ごとに選びます。

Q. 生成AIがあればRPAは不要になりますか？ 業務によります。文章の下書きを作れても、必要なデータの取得や既存画面への入力が残る場合があります。前後の工程を確認し、既存機能・通常の連携・RPAを組み合わせるか判断します。

Q. 決まった計算にも生成AIを使うべきですか？ 計算式や条件が明確なら、通常のプログラムや既存ツールの機能が候補です。公開している評価計算の事例でも、計算にはAIを使わず、所見の下書きだけにAIを使っています。

Q. 自動化すれば人の確認は不要ですか？ 不要とは限りません。入力の欠け、例外、AIの分類や文章の誤り、登録先・宛先を確認する工程が必要です。確認できないものは止め、送信や重要な確定を誰が承認するか決めます。