RPA × AI：なぜ「自動化」は知能なしでは破綻し、知能は制御なしでは信頼されないのか

はじめに

RPA（Robotic Process Automation）は、
人の操作を模倣することで業務を高速化する技術として普及しました。

一方、AI（人工知能）は、
文書理解や判断支援を通じて業務を高度化する存在として期待されています。

しかし、多くの企業が実感し始めているのは、次の現実です。

RPA だけでは壊れやすい
AI だけでは責任を持てない
そして両者は、統制なしでは成立しない

本記事では、日本企業の業務特性（稟議・監査・既存システム）を前提に、
RPA × AI を現実的に成立させる考え方とアーキテクチャを解説します。

RPA が得意なこと、苦手なこと

RPA が得意なのは以下のような業務です。

画面入力
データ転記
ファイルアップロード
定型処理の繰り返し

しかし、RPA には構造的な限界があります。

RPA は「理解」しない
決められた操作を実行するだけ

以下が増えるほど、RPA は不安定になります。

文書フォーマットのばらつき
例外処理
人的判断
UI の変更

これはツールの問題ではなく、設計の問題です。

AI だけに任せると何が起きるか

AI は以下が得意です。

非構造文書の読解
情報抽出
分類・リスク検知
判断の「補助」

しかし、AI の本質は 確率的 です。

AI は「提案」するが「決裁」はしない
AI は「理由」を出すが「責任」は持たない

監査・説明責任が求められる日本企業では、
AI 単独での自動実行は現実的ではありません。

本質的な整理：RPA と AI は役割が違う

失敗しやすい考え方は以下です。

RPA に判断させる
AI に実行させる

持続可能な整理はこうなります。

要素	役割
AI	読む・分析する・提案する
ルール	ポリシーを強制する
人	承認・決裁・責任を持つ
RPA	操作を実行する
Workflow	全体を制御・記録

要約すると、

AI が考え
人が決め
RPA が動き
Workflow が全てを管理する

実務で使える RPA × AI アーキテクチャ（APIなし前提）

日本企業では、API を持たない Web システムが多く残っています。
以下は、その前提で成立する構成例です。

flowchart TD
    U["業務担当者（経理 / 調達 / 物流 / 法務）"] --> P["受付ポータル"]
    P --> S["文書保管（MinIO）"]
    P --> W["Workflowエンジン（Camunda BPMN/DMN）"]

    W --> O["OCR（Tesseract：日/英/泰）"]
    O --> A["AI分析（Private LLM）"]
    A --> R["ルール / ポリシー（DMN）"]

    R -->|低リスク| X["自動実行リクエスト"]
    R -->|例外| H["人による承認（稟議）"]

    H -->|承認| X
    H -->|否認| E["停止・理由記録"]

    X --> B["RPA Bot（Robot Framework）"]
    B --> G["既存Webシステム（APIなし）"]

    W --> D["業務DB（PostgreSQL）"]
    W --> L["監査ログ（ELK）"]
    B --> L