RPA 大規模導入で 3 年後に露呈する保守コストの構造:1000 プロセスの現実

初期 2 年で「うまくいっている」ように見える理由

RPA プロジェクトの初期フェーズは、多くの場合、業務工数の削減効果が数値として明確に出る。定型的なデータ転記、社内システム間のコピー&ペースト、Excel マクロで賄えなかった複雑な操作の自動化——これらの工数削減は、実運用開始から数か月で経営層に報告可能な形で現れる。IPA (情報処理推進機構) が公表している業務自動化の実態調査でも、導入直後の効果は比較的達成されやすいことが指摘されている。

この段階では、開発を委託した外部ベンダーや RPA CoE (Center of Excellence) チームが、開発から保守までを一貫して担当することが多い。プロセスは数十〜数百規模で、UI 変更などの例外事象も CoE 内で吸収可能である。順調に見えるこの期間が、次のフェーズの落とし穴を隠す。

3 年目に始まる「UI 変更対応」の連鎖破綻

3 年目に典型的に発生するのが、対象システム側の UI 変更に伴う RPA スクリプトの一斉修正である。SAP のアップグレード、Microsoft 365 の UI 変更、社内 Web アプリの改修——1 つの変更が数十〜数百のプロセスを同時に停止させる。CoE チームの緊急対応が続くと、新規開発が事実上止まる。

一方、対応工数は年々増加する。プロセスの数は減らず、対象システムの変更頻度は SaaS の普及とともにむしろ増えるためである。国内の大手金融機関や保険会社では、この段階で「RPA 保守のための保守人員」が、当初想定の数倍規模に達している事例が複数の業界レポートに現れている。

例外処理の肥大化と「ブラックボックス化」

もう 1 つの保守コスト増の要因は、例外処理の累積である。稼働開始時にはシンプルだったスクリプトが、実運用で遭遇する各種例外に対応する分岐処理を追加し続けた結果、5 年目には元のスクリプトの 3〜5 倍のロジック量になる、というのが観察される一般的なパターンである。

もっとも、この肥大化は必ずしも設計の失敗ではない。業務ロジックの現実的な複雑性を、RPA という「業務側から見える形」で表現した結果として自然に発生する側面もある。ただし、肥大化したスクリプトが元の開発者から離れると、他のエンジニアが読み解くのは著しく困難で、リエンジニアリングを避けるためだけに古いプロセスを維持する状況が生まれやすい。

監査要件の変化がもたらす追加コスト

3 年目以降、内部監査部門・情報システム監査から、RPA ロボットの実行ログ・アクセス権限管理・変更履歴の完全性を求められることが増える。金融庁のシステム管理基準・IPA の内部統制関連ガイドラインを踏まえた要件変更に、既存の RPA プラットフォームが十分に対応していない場合、監査対応のためだけの改修工数が発生する。

これは技術的には解決可能な課題だが、CoE チームの工数が UI 変更対応で既に飽和している状況では、監査対応が新規開発を圧迫する構造的な問題になる。ただし、この段階に至った組織の多くは、初期の RPA プラットフォーム選定時に監査要件を十分に検討していなかったという共通の反省点を持つ。

初期設計時に検討すべき対応策

これらの構造的コストを事前に軽減するには、初期のプロセス選定段階から次の 3 点を組み込む姿勢が有効である。第 1 に、UI 変更の影響を受けにくい API 連携で代替できるプロセスを優先する。第 2 に、CoE チームの持続可能な人員規模を、稼働プロセス数の上限として設計する。第 3 に、監査要件を初期の要件定義に組み込む——後から追加するのではなく。

イベント駆動ワークフローにおける冪等性の設計パターンで議論した冪等性の考え方は、RPA の再実行時の業務データ整合性にも直接関わる論点である。また、生成 AI エージェント時代の RPAで扱う次世代アーキテクチャは、UI 変更の影響を受けにくい構造を持つ一方、新しい保守コストを持ち込む。

結論:RPA 3 年目問題との向き合い方

RPA の保守コスト問題は、技術選定の失敗というより、初期の効果測定期間 (1〜2 年) が、長期的コスト構造を予測するには短すぎるという時間的なミスマッチの問題である。導入評価にあたっては、5 年後の運用像を含めた総保有コスト (TCO) で判断する姿勢が、後の意思決定を安定させる。DX 推進 5 年の総括で扱う長期的な視点は、RPA だけでなくあらゆる業務自動化投資に共通する論点である。