RPA後の業務自動化で最初に整えるべき技術はRAGである

Excel現場の自動化を、操作代行からAIが扱える業務知識基盤へ進める

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

　RPAは、人間が画面で行っていた定型操作を機械に代行させる技術として広がりました。Excelを開く、Web画面からCSVを取得する、メールを送る、基幹システムへ転記する、といった作業には今でも有効です。しかし、RPAは基本的に「決められた手順を再現する技術」であり、業務の意味、例外判断、資料の読み取り、顧客別ルールの解釈までは得意ではありません。

　生成AIとAIエージェントの登場によって、業務自動化の中心は「操作を自動化すること」から「業務を遂行できる状態を作ること」へ移りつつあります。ただし、AIにツールをつなげればすぐ業務が回るわけではありません。AIが業務を扱うには、まず社内資料、手順、過去事例、用語、判断基準が検索できる形で整理されていなければなりません。

　したがって、当社のようにExcel、VBA、業務改善、要件定義、手順書作成に近い領域からAI活用へ進む場合、最初に取り組むべき技術はRAGです。RAGを土台にして、その上にSkills、MCP、ガードレール、評価を重ねることで、RPA後の業務自動化は現実的な形になります。

本記事の対象とゴール

想定読者

RPAの次に何を学ぶべきか整理したい人
Excel、VBA、Power Automate、RPA、生成AIの関係を整理したい人
中小企業、部署単位、個人事業レベルでAI業務活用を考えている人
既存の業務改善ノウハウを、AI時代のサービスや社内基盤へつなげたい人

本記事で得られること

RPAがなぜ広がり、どこで限界を迎えるのかを整理できます。
AIエージェント、RAG、Skills、MCPの役割を、RPAとの関係で理解できます。
現場業務改善の立場では、まずRAGから整えるべき理由が分かります。
RAGからSkills、MCP、ガードレール、評価へ進む実務ロードマップを描けます。

本記事で扱わないこと

特定RPA製品の詳細な比較
特定ベンダーの導入手順
大企業向けERP刷新の設計
個別のMCPサーバー実装コード
ベクトルDBやEmbeddingの詳細チューニング

先に結論

　RPAの次に来るものは、単純な「AIによるRPA置き換え」ではありません。

　業務自動化の構造は、次のように変わります。

RPAは、人間の画面操作を再現する実行部品である。
AIエージェントは、目的に向かって資料を読み、判断し、道具を選ぶ上位の作業主体になる。
MCPは、AIが外部ツールやデータへ接続するための共通接続層になる。
Skillsは、AIに業務手順、成果物品質、判断基準を教える業務マニュアルになる。
RAGは、AIが社内資料や過去事例を検索して根拠にできる業務知識基盤になる。

　この中で、当社のような現場業務改善型の組織が最初に整えるべきものはRAGです。

　理由は単純です。AIに操作させる前に、AIが何を見て、何を根拠に判断し、どの資料を参照すればよいかを決めなければならないからです。RAGがない状態でMCPやAIエージェントを入れても、AIは道具を持つだけで、業務を理解するための材料を持てません。

第1章（RPAは何を自動化したのか）

　RPAを理解するには、まずRPAが何を得意としていたかを分ける必要があります。

1.1（RPAの本質は画面操作の再現である）

　RPAは、Robotic Process Automationの略です。一般には、人間がPC上で行う定型操作をソフトウェアロボットに実行させる技術として説明されます。

　代表的な処理は次のようなものです。

Excelを開く
Web画面にログインする
CSVをダウンロードする
データを別システムへ転記する
メールを送る
定時に処理を起動する
処理結果をログに残す
エラー時に通知する

　ここで重要なのは、RPAが「業務を理解する技術」ではなく「操作を再現する技術」だという点です。RPAは、どのボタンを押すか、どのセルを読むか、どの画面へ遷移するかをシナリオとして持ち、その手順を繰り返します。

1.2（RPAが広がった理由）

　RPAが広がった理由は、既存システムを大きく改修しなくても自動化できたからです。

　APIがない古いシステムでも、画面があれば操作できます。社内ポータル、基幹システム、Excel、メール、ファイルサーバーをまたぐ作業も、人間の操作としてなら定義できます。

　これは現場部門にとって分かりやすい価値でした。「人が毎日やっている単純作業をロボットにやらせる」という説明は、システム開発の専門知識がなくても理解できます。

　特にExcel中心の業務では、RPAは強い道具でした。Excelで作った資料をWebへ入力する、Webから取ったCSVをExcelで整形する、整形結果をメールする、といった作業は多くの現場にあります。RPAは、そのような「システムとシステムの隙間」を埋めました。

1.3（RPAは軽いシステム開発として受け入れられた）

　本格的なシステム開発には、要件定義、設計、開発、テスト、運用が必要です。RPAはそれより軽く導入できると見なされました。

　もちろん実際には、RPAも保守、権限、例外処理、ログ、監査が必要です。それでも導入初期には、「既存業務をそのまま動かせる」「現場で作れる」「短期間で効果が見える」という点が評価されました。

第2章（RPAが限界を迎える理由）

　RPAの限界は、単に製品機能の不足ではありません。RPAが「固定手順を再現する技術」であることから来る構造的な限界です。

2.1（画面変更に弱い）

　RPAは、画面要素、ボタン、入力欄、ファイル名、Excelの列、処理順序に依存します。

　そのため、Web画面のHTML構造が変わる、ログイン方式が変わる、Excelの列が増える、ファイル名の規則が変わる、といっただけで止まることがあります。

　人間なら「ボタン名は変わったが意味は同じだ」と判断できます。しかしRPAは、事前に定義された条件と違えば失敗します。

2.2（例外処理が膨らむ）

　現場業務には例外があります。

添付ファイルがない
列名が少し違う
顧客ごとに処理条件が違う
担当者判断が必要なデータが混じる
先月だけ特別ルールがある
新しい帳票形式が来る

　これらをすべてRPAシナリオに入れると、シナリオは急速に複雑になります。最初は単純だった自動化が、いつの間にか条件分岐だらけの保守困難な資産になります。

　これはExcelマクロの属人化とよく似ています。最初は便利な自動化でも、業務変更と例外処理を吸収し続けると、作った本人しか分からないものになります。

2.3（業務の意味を持っていない）

　RPAは、なぜその操作をするのかを理解しているわけではありません。

　どの資料を根拠に判断するのか、どの条件なら保留するのか、どの顧客だけ例外扱いするのか、どのファイルが最新版なのか、といった判断は人間が先に定義する必要があります。

　つまりRPAの弱点は「自動化できないこと」ではなく、「業務知識を持たないまま操作だけを実行すること」です。

2.4（悪い業務を速くするだけになる）

　RPAは、現状業務をそのまま機械に渡しやすい技術です。

　しかし、現状業務そのものが整理されていなければ、悪い業務が速くなるだけです。不要な転記、重複入力、曖昧な承認、属人的な判断、古いExcel形式が残ったまま自動化されることがあります。

　したがって、RPAの限界は「ロボットの限界」だけではありません。業務設計を見直さず、操作だけを自動化する発想の限界でもあります。

第3章（AIエージェントはRPAの上位互換ではない）

　生成AIの登場によって、RPAの次はAIだと言われることがあります。この表現は半分正しく、半分危険です。

3.1（RPAとAIエージェントは中心が違う）

　RPAとAIエージェントの違いは、中心に置いているものが違う点です。

RPAは、決められた手順を実行する。
AIエージェントは、目的に向けて情報を読み、道具を選び、作業を進める。

　たとえば「請求書を処理する」という業務を考えます。

　RPAでは、請求書ファイルを開き、指定セルを読み、指定システムへ入力し、完了メールを送る、という手順を定義します。

　AIエージェントでは、請求書の内容を読み、発注書や契約書を探し、金額や相手先を照合し、疑義があれば人間に確認し、問題がなければ次の処理へ進む、という構成を考えます。

　これは単なる操作代行ではありません。資料を読む、判断する、確認する、成果物を作るという業務遂行に近づいています。

3.2（ただしAIエージェントも万能ではない）

　AIエージェントは、判断、検索、要約、生成、例外整理に強い一方で、誤判断、権限制御、監査、再実行性には注意が必要です。

　AIにメール送信、ファイル削除、外部送信、顧客対応、会計処理を任せるなら、どこで人間承認を入れるか、何をログに残すか、どの資料を根拠にしたかを記録する必要があります。

　したがって、AIエージェントはRPAの単純な上位互換ではありません。RPAが得意だった「決められた操作を安定して繰り返す」領域は、今後も残ります。

3.3（RPAは主役から実行部品へ移る）

　今後の構造では、RPAは消えるというより、主役から実行部品へ移ります。

　AIエージェントが上位で状況を読み、必要に応じてRPA、API、Excel、VBA、PowerShell、ブラウザ操作、SaaSを呼び出す形です。

　つまり、RPAの価値はなくなるのではなく、位置づけが変わります。

第4章（MCPはAIに道具を渡す仕組みである）

　AIエージェントが業務を実行するには、外部ツールへ接続する必要があります。ここでMCPが重要になります。

4.1（MCPは共通接続層である）

　MCPは、Model Context Protocolの略です。AIアプリケーションが外部のデータ、ファイル、SaaS、開発環境、業務ツールに接続するための共通プロトコルです。

　MCPの公式説明では、AIアプリケーションに対するUSB-Cのようなものとして説明されています。つまり、個別のツールごとにばらばらの接続方式を作るのではなく、AIが道具を使うための共通口を作る発想です。

4.2（MCPはRPAの位置づけを変える）

　従来のRPAでは、RPA製品を中心に業務自動化を組み立てる考え方がありました。

　MCPを前提にすると、上位にいるのはAIエージェントです。AIエージェントが、必要に応じて外部ツールを呼び出します。その外部ツールの一つとして、RPAも位置づけられます。

AIエージェントが目的を理解する。
RAGで関連資料を探す。
Skillsで業務手順を確認する。
MCPで外部ツールに接続する。
必要に応じてRPAやブラウザ操作を使う。

　この構造では、RPAを中心にすべてを作る必要はありません。RPAは、APIがない画面操作や、既存の定型実行資産を呼び出す部品として使えばよくなります。

4.3（道具を渡すだけでは業務にならない）

　ただし、MCPでAIに道具を渡しても、それだけでは業務は成立しません。

　AIがGoogle Driveを読める、Gmailを読める、Excelを開ける、ブラウザを操作できるとしても、どの資料を見ればよいのか、どのファイルが正本なのか、どの条件で停止すべきかが分からなければ危険です。

　MCPは接続の技術です。業務の意味を与える技術ではありません。

第5章（SkillsはAI用の業務マニュアルである）

　MCPが道具への接続だとすれば、Skillsは道具の使い方と成果物品質をAIに教える仕組みです。

5.1（Skillsが持つべき内容）

　Skillsには、次のような情報を入れます。

業務手順
成果物の形式
顧客別ルール
判断基準
禁止事項
レビュー観点
例外処理
ファイル命名規則
参考資料の使い方

　これは、人間向けの手順書と似ています。ただし、AIに使わせるためには、曖昧な説明よりも、入力、判断条件、停止条件、出力形式を明確に書く必要があります。

5.2（既存の業務改善資産はSkills化しやすい）

　Excel講座、VBA講座、要件定義書、手順書、台本、顧客別仕様、レビュー観点は、AI時代にSkills化しやすい資産です。

　特に現場業務改善では、「どのように業務を分解するか」「どこで人間が判断するか」「どの資料を正本とするか」「どの形式で成果物を残すか」が重要です。

　これは、従来のExcel改善やVBA改善と連続しています。AI時代に突然別の能力が必要になるのではなく、これまで暗黙知として扱っていた業務手順を、AIが読める形に直すことが必要になります。

5.3（Skillsだけでも足りない）

　Skillsは業務手順を持ちます。しかし、Skillsだけでは個別案件の資料をすべて持てません。

　顧客別の要件、過去の議事録、Excel仕様、修正履歴、用語集、FAQは、案件ごとに増えていきます。これをすべてSkillに直接書き込むと、Skillが肥大化し、再利用しにくくなります。

　そこでRAGが必要になります。

第6章（RAGはAIが業務を理解するための知識基盤である）

　RAGは、Retrieval-Augmented Generationの略です。日本語では検索拡張生成と訳されることがあります。

6.1（RAGはAIに資料を読ませるだけではない）

　RAGを「AIに社内資料を読ませる仕組み」とだけ理解すると不十分です。

　RAGの本質は、AIが必要な資料を検索し、根拠として使える状態を作ることです。

　業務で必要なのは、単に大量の文書をAIへ渡すことではありません。どの資料が正本か、どの資料が古いか、どの顧客のルールか、どの業務工程に関係するかを、AIが検索できる形で整理することです。

6.2（RAGに入れるべき情報）

　現場業務改善でRAGに入れるべき情報は、次のようなものです。

要件定義書
議事録
顧客別ルール
Excel仕様
VBA仕様
過去のマクロ
FAQ
セミナー台本
社内手順書
トラブル対応履歴
ファイル命名規則
成果物テンプレート

　これらは、AIが業務を進めるときの根拠になります。

　RPAが操作手順を持っていたのに対し、RAGは業務知識を持ちます。AIエージェントにとって、RAGは「何を根拠に判断するか」を支える土台です。

6.3（RAGがないとAIは属人的な勘で動く）

　RAGがない状態でAIに業務を頼むと、AIは一般知識、会話文、直近の指示だけで判断しようとします。

　しかし、実際の業務は一般論では動きません。顧客別の例外、過去の合意、社内の命名規則、最新版ファイル、承認ルール、成果物の粒度が必要です。

　AIに業務を渡すとは、AIに業務知識を渡すことです。その最初の受け皿がRAGです。

第7章（なぜ最初にRAGなのか）

　AI業務活用には、MCP、Skills、ガードレール、評価、エージェント設計など多くの要素があります。その中で最初にRAGを整えるべき理由を明確にします。

7.1（RAGは既存資産をそのまま活かせる）

　現場業務改善の組織には、すでに大量の資料があります。

顧客から受け取ったExcel
過去の要件定義
打ち合わせメモ
マクロ仕様書
手順書
講座資料
FAQ
トラブル対応メモ

　これらは、AI時代には価値のある知識資産です。

　最初から高度なMCPサーバーやエージェント基盤を作らなくても、まず資料を整理し、Markdown化し、用語をそろえ、検索できる形にするだけで、AIの回答品質は大きく変わります。

7.2（RAGは業務整理そのものになる）

　RAGを作るには、資料を整理しなければなりません。

　どれが正本か、どの資料が古いか、顧客別ルールはどこにあるか、業務フローはどうなっているか、FAQは何かを確認します。

　これは、そのまま業務整理です。

　つまりRAG導入は、単なるAI技術導入ではありません。属人化した業務を、AIにも人間にも読める形へ整理する活動です。

7.3（RAGがあるとSkillsを作りやすくなる）

　Skillsには、業務手順や判断基準を書きます。

　しかし、業務手順を作るには、元になる資料が必要です。RAGとして資料が整理されていれば、そこから共通ルール、例外、成果物形式、顧客別差分を抽出できます。

　RAGが先にあると、Skillsは「固定手順」と「参照すべき知識」を分けて作れます。これにより、Skillsを小さく保ち、案件別の情報はRAG側で持つことができます。

7.4（RAGがあるとMCP接続の目的が明確になる）

　MCPは外部ツール接続です。

　しかし、何に接続すべきかは業務によって違います。Google Driveが必要なのか、Dropboxが必要なのか、Gmailが必要なのか、Excelが必要なのか、ブラウザ操作が必要なのかは、業務資料を見なければ決まりません。

　RAGで業務資料を整理すると、どのツールに接続すべきかが見えてきます。

　順番としては、まずRAGで業務知識を整理し、次にSkillsで手順化し、その後MCPで必要な接続を作るのが自然です。

第8章（巨大スイート型と現場業務型は分けて考える）

　AI業務自動化は、一つの方向に収束するわけではありません。大企業の基幹業務と、現場のExcel・メール・ファイル業務では、適した構造が違います。

8.1（巨大スイート型が強い領域）

　ERP、CRM、Microsoft 365、RPA基盤のような巨大スイートは、今後も強い領域があります。

　会計、販売管理、購買、在庫、人事、CRM、サプライチェーンのように、データモデル、権限、監査、承認、ログが基盤内にある業務では、既存スイートにAIを組み込むほうが自然な場合があります。

　SAPはAutonomous Enterpriseを掲げ、基幹業務にAIエージェントを組み込む方向を示しています。SalesforceもAgentforceでCRMデータや業務フローにAIエージェントを結びつけています。Microsoft Power Platformも、Power AutomateやCopilot Studioを含め、AIを使った自動化と統制を強化しています。UiPathもRPA単体ではなく、agentic automationやオーケストレーションの方向へ進んでいます。

　これらは、基幹業務層では大きな意味を持ちます。

8.2（現場業務型が強い領域）

　一方で、中小企業、部署単位、個人事業、顧客別案件では、巨大スイートだけでは拾い切れない業務が多くあります。

Excelが実質的な業務基盤になっている
メール、PDF、ファイル、議事録、台本が業務の中心にある
顧客別にルールが違う
案件ごとに成果物形式が違う
毎回条件が少し変わる
人間の確認を挟みながら進める

　この領域では、AIエージェント、RAG、Skills、MCPを組み合わせるほうが現実的です。

　特に当社のような現場業務改善型の立場では、基幹システムの中を作り替えるより、既存のExcel、資料、手順、過去成果物をAIが扱える形に整理するほうが価値になります。

8.3（三層構造で考える）

　今後の業務自動化は、次の三層で考えると整理しやすくなります。

基幹業務層

　ERP、CRM、会計、人事、販売管理など。巨大スイート型AI基盤が強い領域。

現場業務層

　Excel、メール、ファイル、PDF、議事録、手順書、顧客別資料など。RAG、Skills、MCP、AIエージェントが強い領域。

実行・統制層

　RPA、ワークフロー、ジョブ管理、ログ、承認、監査など。固定実行と統制を担う領域。

　RPAは第3層に残ります。AIエージェントは第2層を中心に広がります。RAGは第2層を成立させるための知識基盤です。

第9章（当社のような業務改善会社が進むべき方向）

　ここからは、現場業務改善の立場で何を商品化し、何を技術として整えるべきかを考えます。

9.1（売るべきものはRPAでもAI講座でもない）

　これからの価値は、「RPAを作ります」だけでは弱くなります。

　また、「AIを使いましょう」だけでも抽象的です。

　より現実的な提供価値は、次のようなものです。

Excel業務をAIが扱える形に整理する
属人化した業務を、AI対応の業務フローへ変換する
社内資料をAIが検索できる業務知識基盤にする
手順書、要件定義、議事録、FAQをRAG化する
業務手順をSkills化する
必要なツールだけMCPで接続する
人間承認点と禁止事項を設計する

　つまり、売るべきものは「AIそのもの」ではありません。AIに業務を渡せる状態を作ることです。

9.2（Excel改善とRAGはつながっている）

　Excel改善では、表を整理し、項目名をそろえ、入力欄と計算欄を分け、手順を明確にし、属人化を減らします。

　RAGでも同じことをします。資料を整理し、用語をそろえ、正本を決め、古い資料を分け、FAQを作り、AIが検索できる状態にします。

　これは別の仕事ではありません。Excel改善で培った「情報を構造化する力」が、そのままRAG構築に使えます。

9.3（VBA改善とSkillsはつながっている）

　VBA改善では、処理を分割し、関数名を整理し、エラー処理を設計し、テストしやすくします。

　Skillsでも同じ発想が必要です。AIに曖昧な指示を渡すのではなく、手順、入力、判断条件、停止条件、出力形式を分けて書きます。

　つまり、VBAで考えていた設計力は、AIに業務を渡す設計力へ接続できます。

9.4（要件定義とRAGは相性がよい）

　RAGを作るには、業務の目的、関係者、入力、出力、例外、承認点を整理する必要があります。

　これは要件定義そのものです。

　AI時代の要件定義では、人間向けの仕様書だけでなく、AIが検索し、参照し、実行計画に使える資料を残すことが重要になります。

第10章（最初に作るべきRAG構成）

　最初から大規模なベクトルDBや複雑な検索基盤を作る必要はありません。最初に必要なのは、業務資料をAIが読める形に整えることです。

10.1（小さく始める）

　最初のRAG構成は、次のようなフォルダで十分です。

00_概要.md
01_用語集.md
02_業務フロー.md
03_仕様.md
04_FAQ.md
05_注意事項.md
06_成果物テンプレート.md
07_変更履歴.md

　重要なのは、最初から技術的に高度な構成にすることではありません。業務の正本を作ることです。

10.2（RAG用Markdownに必要なこと）

　RAG用Markdownでは、次を明確にします。

この文書は何のための資料か
どの顧客、案件、業務に関係するか
最新版か、過去資料か
どの業務工程で参照するか
用語の定義は何か
判断基準は何か
例外時に誰へ確認するか
AIが勝手に実行してはいけないことは何か

　これらがないと、AIは資料を読めても、業務上どう使うべきか判断できません。

10.3（最初の対象は自社業務でよい）

　顧客向けに売る前に、自社業務をRAG化するのが現実的です。

　たとえば、過去の要件定義、議事録、講座資料、マクロ仕様、FAQ、記事作成ルールをRAG化します。

　自社で使い、検索精度、回答品質、手順の抜け、資料の古さを確認します。その過程自体が、顧客向けサービスの型になります。

第11章（RAGの次に作るもの）

　RAGを整えたら、次にSkills、MCP、ガードレール、評価へ進みます。

11.1（Skillsで手順を固定する）

　RAGは知識基盤です。Skillsは作業手順です。

　たとえば、次のようなSkillsを作れます。

要件定義書作成Skill
ExcelレビューSkill
VBAレビューSkill
議事録から仕様書化するSkill
顧客別メール返信Skill
RAG文書化Skill
記事作成Skill

　Skillsには、どのRAG資料を見るか、どの順序で作業するか、どこで人間確認を入れるかを書きます。

11.2（MCPで必要な道具だけ接続する）

　RAGとSkillsができると、AIが何を実行すべきか見えてきます。

　その段階で、必要なMCP接続を考えます。

Google Driveを読む
Dropboxを読む
Gmailを検索する
Excelを操作する
ブラウザを開く
社内DBを検索する
RPAを呼び出す

　重要なのは、最初から全部つなげないことです。接続が増えるほど、権限、誤操作、情報漏えい、監査の問題が増えます。RAGで業務を整理してから、必要な接続だけを足すのが現実的です。

11.3（ガードレールで事故を防ぐ）

　AIが外部ツールを使うなら、ガードレールが必要です。

削除は禁止する
メール送信は人間承認後にする
個人情報を外部へ送らない
顧客フォルダ外へ書き込まない
参照できる資料を限定する
不明点は推測せず確認する

　AI業務活用では、できることを増やすだけでなく、してはいけないことを明確にする必要があります。

11.4（評価で品質を保つ）

　AIは毎回同じ出力を返すとは限りません。

　そのため、業務利用では評価が必要です。

出力形式を守っているか
必要な項目が抜けていないか
禁止事項に違反していないか
根拠資料を参照しているか
顧客別ルールを守っているか
過去成果物と品質差がないか

　これは、VBAやExcelマクロのテストと似ています。AI時代でも、業務品質を保つには評価とレビューが必要です。

第12章（導入ロードマップ）

　現場業務改善の立場では、次の順番が現実的です。

12.1（Phase 1: RAG用資料を整える）

プロジェクト別フォルダを整理する
正本資料と過去資料を分ける
重要資料をMarkdown化する
用語集を作る
FAQを作る
顧客別ルールをまとめる
AIで検索して答えられるか試す

12.2（Phase 2: Skillsを作る）

要件定義Skillを作る
ExcelレビューSkillを作る
VBAレビューSkillを作る
議事録整理Skillを作る
RAG文書化Skillを作る
記事作成Skillを作る

12.3（Phase 3: MCP接続を足す）

ファイルシステム
Google Drive
Dropbox
Gmail
Excel
PowerShell
ブラウザ操作

　接続は業務に必要なものから順に足します。最初から全部つなげる必要はありません。

12.4（Phase 4: AIエージェント運用に進む）

AIが資料を探す
AIがExcelを確認する
AIが草案を作る
AIがマクロ案を作る
人間が承認する
AIが成果物化する
ログを残す
評価で品質を確認する

12.5（Phase 5: 顧客向けサービスにする）

AI時代のExcel業務整理
RAG導入支援
Skill作成支援
MCP接続設計支援
AI業務基盤構築
Excel業務のAI対応化

　この順番なら、既存のExcel、VBA、業務改善、要件定義の資産を捨てずに、AI時代のサービスへ接続できます。

第13章（RPAの最終的な位置づけ）

　最後に、RPAの位置づけを整理します。

13.1（RPAが残る場所）

　RPAは次のような場面で残ります。

画面操作しか手段がない
固定処理を確実に実行したい
定時実行が必要
ログと監査が必要
既存RPA資産がある
レガシーシステムを操作する必要がある
失敗時の再実行が重要

　この領域では、RPAは今後も価値があります。

13.2（RPA中心ではなくなる場所）

　一方で、次の領域ではRPA中心ではなくなります。

部署内のExcel業務
個人の繰り返し作業
顧客別にルールが違う業務
資料を読んで判断する業務
毎回条件が変わる業務
成果物を生成する業務

　ここでは、AIエージェント、RAG、Skills、MCPの組み合わせが有効になります。

13.3（RPAはAIの敵ではない）

　RPAはAIに置き換えられる敵ではありません。

　固定操作が必要な場面では、AIがRPAを呼び出せばよいのです。RPAは実行部品として残り、AIはその上で判断、検索、計画、例外処理を担います。

　このように分けると、RPAを捨てるか残すかではなく、どの層に置くかという設計問題になります。

第14章（まとめ）

　RPAは、業務自動化の第一世代として大きな役割を果たしました。

　しかし、RPAの本質は固定手順の実行です。画面変更、例外処理、業務理解、属人化には構造的な弱さがあります。

　生成AIとAIエージェントの登場により、業務自動化は「操作を代行する」段階から「業務を遂行できる状態を作る」段階へ進みます。

　そのとき必要になる構造は、次の順番です。

RAGで業務知識を検索できる形にする。
Skillsで手順、品質基準、停止条件を定義する。
MCPで必要な外部ツールへ接続する。
ガードレールで事故を防ぐ。
評価で品質を確認する。
必要な場面ではRPAを実行部品として使う。

　当社のようにExcel、VBA、業務改善、要件定義、手順書作成に近い立場では、最初にやるべきことはRAGです。

　なぜなら、AIに業務を任せる前に、AIが参照できる業務知識を作る必要があるからです。

　今後の競争は、「AIを使えるか」ではなく、「AIに業務を渡せる形に整理できるか」です。RAGは、その最初の土台になります。

参考情報・出典メモ

Model Context Protocol, Introduction

https://modelcontextprotocol.io/routing

Anthropic, Introducing the Model Context Protocol

https://www.anthropic.com/news/model-context-protocol

OpenAI API, Building MCP servers for ChatGPT and API integrations

https://platform.openai.com/docs/mcp

OpenAI API, Safety in building agents

https://platform.openai.com/docs/guides/agent-builder-safety

OpenAI Agents SDK, Tracing

https://openai.github.io/openai-agents-python/tracing/

OpenAI Agents SDK, Guardrails

https://openai.github.io/openai-agents-python/guardrails/

Microsoft Learn, Power Automate 2025 release wave 1 overview

https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/

UiPath Release Hub

https://www.uipath.com/product/release-hub

Salesforce, Agentforce

https://www.salesforce.com/agentforce/

SAP News, SAP Unveils the Autonomous Enterprise

https://news.sap.com/2026/05/sap-sapphire-sap-unveils-autonomous-enterprise/

元原稿メモ

入力元: C:\Users\hoehoe\Downloads\rpa_ai_future_markdown.md
編集日: 2026-05-15
編集方針: 固有名詞としての自社名を一般化し、「当社のような現場業務改善型の組織」という表現へ置換。RPAの考察から、最初に整えるべき技術をRAGと位置づける論理展開へ再構成。