ストーリー
田
田中VPoE
「To-Be設計が完了した。ここからは実装フェーズだ。NetShop社にはすでに一部でRPA（UiPath）が導入されている。新たにAIを導入する際、RPAとAIをどう組み合わせるかが鍵になる。」
あなた
「RPAとAIは別物ですよね？どう使い分ければいいのでしょう？」
あ
田
田中VPoE
「RPAは『ルール通りに画面操作を自動化する』もの、AIは『データから判断・生成する』ものだ。この2つを組み合わせると、RPAだけでは対応できなかった知的業務の自動化が可能になる。」
RPAとAIの違いと使い分け
基本的な違い
| 比較軸 | RPA | AI |
|---|---|---|
| 得意なこと | 画面操作、データ転記、定型処理 | 判断、分類、生成、予測 |
| 処理方式 | ルールベース（if-then） | データ駆動（学習） |
| 柔軟性 | 低い（画面が変わると動かない） | 高い（パターンを学習） |
| 導入コスト | 低〜中 | 中〜高 |
| 対象業務 | 構造化された定型業務 | 非構造化データ、判断業務 |
| メンテナンス | 画面変更時に修正必要 | モデル精度の定期監視 |
使い分けの判断フロー
<業務の特性は?>
├── ルールが100%明確 + 画面操作中心 → RPA単独
├── ルールが80%明確 + 一部判断あり → RPA + AI
├── 非構造化データの処理 → AI単独
└── 判断 + 画面操作の両方 → AI + RPA統合RPA×AI統合アーキテクチャ
3つの統合パターン
パターン1: AIフロント + RPAバック
[非構造化データ] → [AI: 判断・分類・抽出] → [構造化データ] → [RPA: システム入力]
例: AI-OCRが請求書を読み取り → RPAが経理システムに入力パターン2: RPAフロント + AIミドル + RPAバック
[RPA: データ収集] → [AI: 分析・判断] → [RPA: 結果を入力・配信]
例: RPAがCSVダウンロード → AIが異常値分析 → RPAがレポート配信パターン3: AIオーケストレーション
[AI: 全体制御・判断]
├── [RPA: タスクA実行]
├── [API: タスクB実行]
└── [AI: タスクC実行]
例: AIが請求書処理全体を制御し、RPAでシステム操作、AIで判断を実行NetShop社での適用
| 業務 | 統合パターン | RPA担当 | AI担当 |
|---|---|---|---|
| 請求書処理 | AIフロント + RPAバック | 経理システムへのデータ入力 | OCR読み取り、照合判断 |
| 問い合わせ対応 | AIオーケストレーション | Zendeskチケット操作 | NLP理解、回答生成 |
| レポート作成 | RPAフロント + AIミドル + RPAバック | データ収集、レポート配信 | 分析、コメント生成 |
統合アーキテクチャの設計
システム構成図
[フロントエンド]
├── AIダッシュボード（処理状況の可視化）
└── 承認画面（人間の介入ポイント）
[ミドルウェア]
├── AIオーケストレーター（全体制御）
├── APIゲートウェイ（外部システム連携）
└── メッセージキュー（非同期処理）
[AI層]
├── AI-OCRサービス
├── NLP/分類サービス
├── LLM（回答生成・要約）
└── 異常検知サービス
[RPA層]
├── 経理システム操作ボット
├── Zendesk操作ボット
└── レポート配信ボット
[データ層]
├── 統合データプラットフォーム
├── AIモデルストレージ
└── 処理ログDB技術選定のポイント
| 要素 | 選択肢 | NetShop社の選定 | 理由 |
|---|---|---|---|
| RPA | UiPath / Automation Anywhere / Power Automate | UiPath（既存） | 既存資産の活用 |
| AI-OCR | Google Document AI / Azure Form Recognizer / 自社開発 | Google Document AI | GCP基盤との親和性 |
| LLM | GPT-4 / Claude / Gemini | Claude API | 日本語精度とコスト |
| オーケストレーション | Airflow / Step Functions / Temporal | Cloud Composer（Airflow） | GCP基盤との親和性 |
| メッセージキュー | Cloud Pub/Sub / SQS / Kafka | Cloud Pub/Sub | GCP基盤との親和性 |
統合時の注意点
よくある落とし穴
| 落とし穴 | 原因 | 対策 |
|---|---|---|
| RPAとAIの処理速度の不整合 | AIのレスポンスが遅くRPAがタイムアウト | 非同期処理 + メッセージキューの導入 |
| エラーハンドリングの不統一 | RPAとAIで異なるエラー処理 | 統一的なエラーハンドリング基盤 |
| データ形式の不整合 | AIの出力をRPAが解釈できない | 中間データ形式の標準化（JSON等） |
| 監視の分断 | RPAとAIを別々に監視 | 統合監視ダッシュボードの構築 |
| 権限管理の複雑化 | RPAボットとAIサービスの権限が分散 | 統一的な認証・認可基盤 |
まとめ
| 項目 | ポイント |
|---|---|
| RPAとAIの違い | RPAはルールベース操作、AIはデータ駆動の判断・生成 |
| 3つの統合パターン | AIフロント+RPAバック、RPA+AI+RPA、AIオーケストレーション |
| アーキテクチャ | フロント/ミドル/AI層/RPA層/データ層の5層構成 |
| 注意点 | 速度不整合、エラーハンドリング統一、監視統合が重要 |
チェックリスト
- RPAとAIの使い分け基準を説明できる
- 3つの統合パターンの特徴と適用場面を理解した
- 統合アーキテクチャの設計ができる
- 統合時の落とし穴と対策を把握した
次のステップへ
次は「承認フロー設計」として、自動承認と手動承認の切り替え、権限設計について学ぼう。
推定読了時間: 30分