M01-「自動化」の主導権はAIへ。RPAエンジニアが今知るべきAgentとSkillの関係性

はじめに

私はこれまで、RPA（UiPath / Power Automate）やVBAといった固定スクリプト型の自動化技術を中心に、企業の業務改善・DX推進に関わってきました。

しかしここ1〜2年、「AI Agent」「LLM」「自律型オーケストレーション」といった概念が急速に広まり、自動化の前提そのものが変わりつつあります。

生成AIの活用が進む中、RPAエンジニアである私たちは大きな転換点にいます。
クライアントからの要望は「定型業務の自動化」から、 「AIに自律的にシステムを操作させたい」 というフェーズへ移行しつつあるからです。

本記事の目的は、以下の2点を明確にすることです。

1. これからの自動化アーキテクチャの中核となる 「AI Agent（脳）」 と 「Skill（手）」 の決定的な違い。
2. その中で、既存の RPA技術（UiPath/Power Automate） が果たすべき新たな役割と、RPAエンジニアのキャリア戦略。

1. 定義と構造：「AI Agent」と「Skill」の違い

多くの議論で混同されがちなこの2つの概念を、システム開発の視点で再定義します。
Difyのようなオーケストレーションツールや、Claude Codeのような自律型アシスタントをイメージすると分かりやすいでしょう。

AI Agent（エージェント）とは

• 定義: 「脳」および「司令塔」。
• 役割: 曖昧なゴール（目的）に対し、推論（Reasoning） を行い、手順を計画（Planning） し、適切な道具を選んで実行する主体。
• 特徴:
  • 確率的（Probabilistic）: 同じ指示でも、状況や文脈（Context）に応じて異なるアプローチを選択できる。
  • 自律性: エラーが発生しても、人間へ即座にエスカレーションせず、「別の方法を試す」「検索して調べる」といった 自己復旧（Self-Correction） を試みる。

Skill（スキル / Tool）とは

• 定義: 「手」および「道具」。
• 役割: Agentが外部の世界（データベース、Web、レガシーシステム）にアクセスし、操作するためのインターフェース。
• 特徴:
  • 決定論的（Deterministic）: 特定の入力に対して、必ず決まった出力を返す（API、関数、スクリプト）。
  • 受動的: Agentから呼び出されない限り、自ら動くことはない。

両者の比較まとめ

比較項目	AI Agent (脳)	Skill (手/道具)
主な技術	LLM (Claude, GPT), Bedrock Agents, LangGraph	RPA (UiPath, Power Automate), API, SQL
動作原理	推論・確率的 (Probabilistic)	ルールベース・決定的 (Deterministic)
入力データ	自然言語 (曖昧さを含む)	構造化データ (JSON, 引数)
エラー対応	状況判断し、迂回策を考える (ReAct)	エラーを返し、停止する
制御フロー	動的生成 (Dynamic Planning)	固定 (Hard-coded)

2. 制御構造の逆転：RPAは「フローの主」から「Skill」へ

これまで私たちRPAエンジニアは、「人間が描いたフローチャート通りに動くロボット」を作ってきました。しかし、Agent時代のアーキテクチャでは主従関係が逆転します。

Before: 従来のRPA（Hard-coded Flow）

従来のRPAは、人間が事前に設計した 「固定されたレール」 の上を走ります。 AI（OCRや分類モデル）を使う場合でも、それはRPAという大きなフローチャートの中の「1つの部品」として呼び出されるに過ぎません。

• 主導権: 人間（開発者が書いたコード）
• 弱点: 想定外の事象（ポップアップ、データ不備）が発生すると、例外処理がなければ即停止する。

After: Agent型アーキテクチャ（Probabilistic Flow）

これからのアーキテクチャは逆です。AI Agent（脳）が主導権を握り、必要に応じてRPA（手）を呼び出します。
Agentは「ReAct（Reasoning + Acting）」と呼ばれるループ構造の中で、状況を都度判断しながら動きます。

• 主導権: AI Agent（プロンプトによる指示に基づく自律判断）
• 強み: RPA（Skill）がエラーを返した場合でも、Agentが 「読み取りに失敗したか。では検索方法を変えて再実行しよう」 と自律的に判断し、リカバリーを試みることができます。

この構造において、RPAは「自律的な判断」をAIに委譲し、代わりに 「絶対に失敗しない実行能力」 を提供することに特化します。

3. RPAエンジニアの生存戦略：最強の「Skill Architect」へ

「AIがコードを書く時代に、RPAエンジニアは不要になるのか？」
私の答えはNOです。むしろ、「信頼性の高いAgent」を作るための鍵はRPAエンジニアが握っています。

なぜRPAエンジニアが必要なのか？

AI（LLM）は論理的な推論は得意ですが、企業の 「業務プロセスの泥臭さ」 を知りません。

• 「このレガシーシステムはAPIがない」
• 「画面Aと画面Bでデータの整合性が取れていない」
• 「特定の時間帯だけ処理が重くなる」

こうしたシステムごとの「癖」や「制約」を吸収し、Agentがいつでも叩ける クリーンなSkill（API/Wrapper） として提供できるのは、現場の業務フローと例外を知り尽くしたRPAエンジニアだけです。

目指すべきキャリア：Automation Architect

これからは、単にUiPathのワークフローを作るだけでなく、以下のスキルセットを持つ 「Skill Architect（Automation Architect）」 への転換が求められます。

1. API設計力: Agentが使いやすい粒度でRPAを部品化する設計能力（OpenAPI/Swagger）。
2. 接続技術: AWS LambdaやAPI Gatewayを用い、AgentとRPAをつなぐ実装力。
3. 業務抽象化力: 複雑な業務プロセスを整理し、「どこをAIに判断させ、どこをRPAで縛るか」を切り分けるアーキテクト視点。

まとめ

• AI Agentは、自律的に思考し計画する「脳」である。
• Skillは、確実な実行を担う「手」であり、RPAはこの領域で最強の道具となる。
• RPAエンジニアは、AIに指示される側の「下請け」になるのではない。優秀な脳（Agent）がその能力を最大限発揮できるような、「最高の身体（Skill）」を設計・提供するアーキテクトへと進化する時が来ています。

Next Step
次回は、私が現在自己学習を進めている 「AWS Certified AI Practitioner」 について、学習を通して得た知見やキャッチアップの内容をシェアする記事を投稿する予定です。