RPA停止事件から考える生成AI時代の業務自動化

1. はじめに

masatoです。
今回は、実務でよくありそうな仮定のシチュエーションを通じて、
生成AI時代の業務自動化について、私の考えを紹介します。

あくまで仮定の話ですが、
「これは普通に起こり得るな」と感じてもらえたら嬉しいです。

---

2. RPA停止事件の発生

ある朝、いつも通り出社しました。
すると、日々動いていたRPA（Power Automate Desktop）が
止まっていることに気づきました。

このRPAは、顧客EDIにログインして受注情報を取得する
フローです。

状況を整理すると、次のような状態でした。

• RPA担当の田中さんは先月退職
• 引き継ぎ書は、簡単なペーパーが数枚だけ
• フローの詳細を把握している人はいない

顧客EDIを手動でログインして確認すると、 画面が少し変更されており、
RPAがセル番地を読み取れなくなっていました。

フローを開いてみましたが、

• アクションが多い
• コメントはほぼなし
• 変数名も分かりにくい

どこを直せば復旧するのか、判断できません。

結局、当面の間手作業に逆戻りしてしました。

---

3. 生成AIへの相談と提案

応急対応はできましたが、
同じことが繰り返されるのは避けたいところです。

そこで、今後に向けた解決策を生成AIに相談しました。

実際に使ったプロンプト

Power Automate Desktopで作成されたRPAが、顧客EDIの画面変更により動かなくなりました。
RPA担当者は退職しており、フローは属人化しています。

非エンジニアが運用している現場を前提に、
今後同様のトラブルを減らすための選択肢を整理してください。
それぞれのメリット・デメリットも教えてください。

生成AIからは、いくつかの選択肢が提示されました。
その中で印象に残ったのが、RPAではなくPythonで実装する案です。

「テキストベースで管理でき、生成AIが内容を理解し、修正しやすい」

理屈としては、確かに納得できる提案でした。

一方で、実務的には懸念もあります。

• 非エンジニアが多い職場でPythonのインストールや環境構築ができるのか

• 生成AIが生成したコードをどこまで信頼するのか

RPAですら難しいと感じる職場で、Pythonへの移行は慎重に検討すべき、
という判断になりました。

4. まとめ

今回のRPA停止事件はあくまで仮定の話ですが、
あらためて感じたのは、生成AI時代の業務自動化の考え方です。

• RPAは便利だが、属人化リスクがある

• 担当者の退職は、いつでも起こり得る

生成AI時代では、コードを生成AIが読みやすい形で残すことが
重要になってくると感じています。

今回はすぐに置き換えはしませんでしたが、
生成AIが読める・支援できる形で業務を設計するという視点は、
今後の業務自動化において欠かせないものだと思います。