業務自動化の相談では、よく次のような話から始まります。
- この入力作業をRPAで自動化したい
- 毎日このボタンを押しているので自動化したい
- Excelからシステムへの転記をなくしたい
- 定期処理を無人化したい
もちろん、RPAは有効な選択肢です。
ただ、実装する側としては、RPAを作る前に一度、
「そもそも、その人間の操作自体をなくせないか」
を考えた方がよいと思っています。
人の操作をそのままロボットに置き換えるだけでは、画面変更や通信遅延に弱く、運用負荷が高い仕組みになることがあります。
一方で、業務そのものを分解してみると、
- ファイル監視
- バッチ処理
- API連携
- ステータス管理
- 承認フロー
- リトライ
- ログ監視
といった、よりシンプルな仕組みで置き換えられるケースも多くあります。
この記事では、業務自動化を設計するときに個人的に重要だと思っている5つのポイントを整理します。
1. 人が入力している情報を、システム側で判断できないか考える
例えば、次のような業務があるとします。
- 対象日を入力
- CSVファイルを指定
- 実行ボタンを押す
- データを取り込む
このままRPA化すると、
画面を開く
↓
日付欄に今日の日付を入力
↓
ファイル選択ダイアログを開く
↓
CSVを選択
↓
実行ボタンをクリック
という実装になりがちです。
しかし、そもそも対象日は本当に人が入力する必要があるでしょうか。
例えば、
- ファイル名
- ファイル作成日時
- 更新日時
- ファイル内の対象年月
- フォルダに配置された時刻
などから判定できる可能性があります。
例えば、
/data/incoming/
sales_20260815.csv
というファイルが配置されたら、
ファイル検知
↓
ファイル名から 2026-08-15 と判定
↓
バリデーション
↓
取込処理
↓
処理済フォルダへ移動
とすれば、人が画面を操作する必要はありません。
実装としても、
if new_file_detected:
target_date = parse_date(filename)
validate(file)
import_data(file, target_date)
のような処理で済む場合があります。
自動化で最初に疑いたい操作
個人的には、次の操作は最初に疑っています。
- 日付入力
- ファイル指定
- 実行ボタン
- コピー＆ペースト
- ファイル移動
- メール送信
これらは「人間がやる業務」というより、
処理を開始するためのインターフェース
になっていることが多いためです。
自動化では、
ボタンを自動で押す方法より、ボタンをなくす方法
を先に考えた方がシンプルになることがあります。
2. 「自動化できるところ」ではなく「人が必要なところ」を探す
複数工程を持つ業務では、最初から全自動を目指すと難しくなります。
例えば、
ファイル取得
↓
システム取込
↓
マスタ照合
↓
欠損マスタ抽出
↓
欠損データ補完
↓
最終データ生成
↓
確認
↓
顧客へ送信
という業務があるとします。
「これを全部自動化しよう」と考えると、欠損データの扱いなどで止まります。
そこで逆に、
どこだけ人間が必要なのか
を考えます。
例えば、
| 工程 | 実行主体 |
|---|---|
| ファイル取得 | 自動 |
| システム取込 | 自動 |
| マスタ照合 | 自動 |
| 欠損抽出 | 自動 |
| 欠損内容の判断 | 人 |
| 最終データ生成 | 自動 |
| 最終確認 | 人 |
| 配信 | 自動 |
という設計にできます。
この場合、システム側では、
AUTO
↓
AUTO
↓
AUTO
↓
HUMAN
↓
AUTO
↓
HUMAN
↓
AUTO
という状態になります。
全自動ではありませんが、人の作業量はかなり減ります。
ここで重要なのは、
自動化率100%を目指す必要はない
ということです。
80%を安定して自動化できるなら、その方が業務システムとして価値があるケースもあります。
3. Human in the Loopでは、人に「作業」ではなく「判断」をしてもらう
人の確認が必要な業務は多くあります。
例えば、毎週送られてくるデータを加工し、第三者が確認してから顧客へ配信する業務を考えます。
従来型だと、
メールからファイルを保存
↓
Excelで加工
↓
加工済ファイルを保存
↓
担当者へメール
↓
担当者が確認
↓
別システムへアップロード
↓
配信
となるかもしれません。
これを、
データ自動取得
↓
自動加工
↓
確認用データ生成
↓
確認依頼通知
↓
人が確認
↓
承認
↓
APIで配信
にします。
人がやるのは、
確認
↓
承認
だけです。
例えば承認APIを用意して、
POST /jobs/123/approve
が実行されたら、
status = APPROVED
↓
配信APIを実行
↓
status = DELIVERED
と処理します。
これは生成AIを組み込む場合にも有効です。
例えばAIに、
- データ分類
- コメント生成
- 異常候補抽出
- 欠損候補補完
をさせても、最終判断だけ人に残すことができます。
つまり、
Human in the Loop = 人間を処理フローに残すこと
ではなく、
人間を意思決定ポイントにだけ残すこと
と考えた方が設計しやすいと思います。
4. cronだけではなく「状態」を管理する
定期処理では、cronやWindowsタスクスケジューラだけで設計すると問題になることがあります。
例えば、
- 毎週金曜日に週次処理
- 毎月末日に月次処理
があるとします。
処理内容はほぼ同じですが、月末金曜日に両方動くと困る。
単純に、
0 20 * * 5 weekly_job
0 21 28-31 * * monthly_job
のように時間をずらすことで対応する方法もあります。
ただし、処理時間が長引くと衝突する可能性があります。
そこで、実行時刻だけではなく、
処理状態をデータとして管理する
という考え方が必要になります。
例えば、
RECEIVED
PROCESSING
PROCESSED
WAITING_APPROVAL
APPROVED
DELIVERED
FAILED
という状態を持たせます。
DB上では例えば、
job_id
target_date
job_type
status
started_at
finished_at
を管理します。
例：
123
2026-08-31
MONTHLY
PROCESSING
2026-08-31 20:00
NULL
処理開始時には、
SELECT *
FROM jobs
WHERE target_date = '2026-08-31'
AND status IN ('PROCESSING', 'PROCESSED', 'DELIVERED');
などを確認します。
既に月次処理が存在するなら、
週次処理をスキップ
とできます。
二重実行防止
もう一つ重要なのが冪等性です。
例えば同じAPIが二度呼ばれても、
二重登録しない
二重配信しない
二重請求しない
という設計にします。
例えば、
target_date + job_type
をユニークキーにする方法もあります。
UNIQUE(target_date, job_type)
あるいは、
idempotency_key
を持たせる方法もあります。
定期処理では、
「何時に動かすか」より「同じ処理が二度動いても問題ないか」
の方が重要になるケースがあります。
5. RPAは「1回失敗したらエラー」にしない
RPAはGUIを操作するため、外部要因の影響を受けやすいです。
例えば、
- ネットワーク遅延
- Web画面の描画遅延
- JavaScriptの実行待ち
- 一時的なタイムアウト
- セッション切れ
- ポップアップ
- 画面レイアウト変更
などがあります。
そのため、
クリック失敗
↓
即エラー通知
という設計にすると、人が頻繁に対応することになります。
実運用では例えば、
処理
↓
失敗
↓
スクリーンショット保存
↓
ログ保存
↓
30秒待機
↓
再試行
↓
最大5回
↓
5回失敗したら通知
のようにします。
疑似コードなら、
for attempt in range(5):
try:
execute_rpa()
break
except Exception as e:
save_screenshot()
write_log(e)
if attempt == 4:
notify_operator()
else:
sleep(30)
といったイメージです。
さらに、リトライ間隔も、
10秒
30秒
60秒
120秒
のように伸ばすExponential Backoffを使う方法もあります。
エラー時に残しておきたい情報
最低限、
- 発生日時
- 処理ID
- 対象データ
- エラー内容
- スタックトレース
- スクリーンショット
- リトライ回数
- 最終URL
- 実行ユーザー
などがあると原因調査しやすくなります。
重要なのは、
エラー処理も業務自動化の一部
として設計することです。
正常系だけ自動化して、
失敗したら人間が何とかする
では、運用開始後に人の負担が増えてしまうことがあります。
RPA、API、バッチ、ファイル監視を使い分ける
業務自動化というとRPAを想像しやすいですが、RPAは手段の一つです。
例えば、
| 要件 | 候補 |
|---|---|
| ファイルが来たら処理 | ファイル監視 |
| 定期集計 | バッチ |
| システム間連携 | API |
| DBの更新 | SQL / API |
| 人の判断 | 承認画面 |
| GUIしか存在しない | RPA |
| 文章や非定型判断の補助 | 生成AI |
という選択肢があります。
個人的には優先順位として、
API
↓
DB / バッチ
↓
ファイル連携
↓
RPA
くらいで考えています。
RPAが悪いという意味ではありません。
APIが提供されていない既存システムや、短期間で自動化したい業務では非常に有効です。
ただし、
GUI操作以外の方法があるなら、そちらの方が壊れにくい
ケースが多いです。
自動化するときは業務を6つに分けて考える
業務自動化を検討するとき、私は次のように分解すると整理しやすいと思っています。
入力
↓
判断
↓
処理
↓
確認
↓
出力
↓
異常時
それぞれについて、
これは本当に人間が必要なのか？
と考えます。
例えば、
入力
日付入力
ファイル選択
→ メタデータやイベントで自動化できないか。
判断
欠損データをどう扱うか
→ 人間またはAI補助。
処理
データ加工
集計
→ バッチ処理。
確認
外部配信してよいか
→ Human in the Loop。
出力
ファイル送信
システム登録
→ APIや自動配信。
異常時
通信失敗
画面操作失敗
→ リトライ、ログ、通知。
この分解をするだけでも、
「RPAで全部作る」
という設計から離れやすくなります。
まとめ
業務自動化では、人が行っている操作をそのまま自動化することが必ずしも最適とは限りません。
個人的に重要だと思っているのは、次の5点です。
- 人が入力している情報をシステム側で判断できないか考える
- 自動化できる部分ではなく、人が必要な部分を特定する
- 人には作業ではなく判断をしてもらう
- スケジュールだけでなく状態を管理する
- 異常系とリトライまで含めて自動化する
自動化とは、
人間の操作を再現することではなく、業務の状態遷移をシステムに管理させること
だと考えると、設計の仕方がかなり変わります。
RPAが必要ならRPAを使う。
APIで済むならAPIを使う。
ファイル監視で済むならファイル監視にする。
人が必要なら判断だけ残す。
最近ではそこに生成AIも加わります。
技術を先に決めるのではなく、
業務を分解してから、最も壊れにくい方法を選ぶ。
それが、長く運用できる業務自動化につながるのではないかと思います。