定型作業はどこへ消えたのか — RPAからオーケストレーションへ
要点
- RPAは画面操作を模倣する自動化であり、業務の「表面」をなぞる性質上、対象システムのUI変更に弱い。
- 近年の関心はRPA単体から、複数の処理を順序立てて束ねるワークフロー・オーケストレーションへ移りつつある。
- オーケストレーション（中央指揮）とコレオグラフィ（各自連携）は対立ではなく、可視性と結合度のトレードオフである。
- 自動化が増えるほど「失敗したときに誰がどう気づくか」という観測の設計が中心課題になる。
ある中堅企業の経理部門では、月末になると請求書の数字を会計システムへ転記する作業が積み上がる。数年前まで、それは数人が半日がかりで処理する仕事だった。いまその大半は、夜のうちに自動で走る。だが「人手が消えた」という単純な話ではない。消えたのは入力の手間であって、処理そのものは形を変えて残っている。背景に移っただけだ。
RPAは何を自動化したのか
RPA（ロボティック・プロセス・オートメーション）は、人間が画面上で行うクリックやキー入力を記録し、再生する仕組みである。APIを介さず、人が見る画面をそのまま操作するため、改修が難しい古いシステムにも後付けで導入できる。この「表面をなぞる」手軽さが普及の理由だった。情報処理推進機構（IPA）が継続的に公開している業務システムの実態調査でも、レガシー資産の多さは日本企業の共通課題として繰り返し指摘されている。RPAはその隙間を埋める道具として広がった。
もっとも、表面をなぞる設計には代償がある。対象アプリの画面レイアウトが少し変わるだけで、ロボットは座標を見失って止まる。自動化したはずの作業が、保守という別の作業を生む。ここで多くの現場が気づくのは、自動化の本質が「操作の再現」ではなく「処理の流れの管理」だという点だった。
流れを束ねるという発想
一つの作業を自動化できても、業務は単独の作業では完結しない。データを取得し、加工し、別のシステムへ渡し、結果を確認する。この連なりを定義し、順序・再試行・分岐を制御するのがワークフロー・オーケストレーションである。Apache Airflowの公式ドキュメントは、処理の依存関係を有向非巡回グラフ（DAG）として記述する考え方を中心に据えている。どの処理がどの処理の完了を待つのかを図として明示する、という発想だ。
この観点に立つと、RPAは「流れの中の一つのノード」に位置づけ直される。画面操作という手段は残るが、それを束ねる上位の層が主役になる。ワークフローエンジンの設計思想を比較すると、各製品が「流れをどう記述させ、失敗をどう扱わせるか」で性格を分けていることがわかる。
中央指揮か、各自連携か
処理の束ね方には大きく二つの立場がある。一つは中央の指揮者がすべての手順を把握して指示するオーケストレーション。もう一つは、各サービスがイベントに反応して自律的に動くコレオグラフィである。Sam Newmanは『マイクロサービスアーキテクチャ』のなかで、前者は流れが一望できる反面、指揮者にロジックが集中しやすく、後者は疎結合だが全体像が見えにくいと整理している。
一方で、現場の選択はしばしば二者択一にならない。中核の決済処理は指揮型で固め、通知やログ収集は反応型に任せる、といった混在が現実的だ。裏を返せば、純粋にどちらか一方で組まれたシステムのほうが珍しい。重要なのは様式の名前ではなく、障害が起きたときに流れのどこで止まったかを追えるかどうかである。
自動化が残す宿題
処理が背景へ移ると、成功しているあいだは誰も見ない。問題は失敗したときに表面化する。請求書転記の例で言えば、夜間に一件だけ通貨単位の解釈に失敗しても、翌朝の数字が静かにずれているだけで、警告は鳴らないかもしれない。自動化の成熟度は、どれだけ自動化したかではなく、失敗をどれだけ早く可視化できるかで測られる。これは分散トレーシングの議論とも地続きの問題だ。
RPAからオーケストレーションへという流れは、技術の世代交代として語られがちだが、実際に起きているのは関心の移動である。個々の操作を速くすることから、流れ全体の信頼性を保つことへ。自動化は人の作業を消すのではなく、人の役割を「実行者」から「流れの設計者と監視者」へ静かに押し上げている。
出典
- Sam Newman『マイクロサービスアーキテクチャ』（オーケストレーションとコレオグラフィの整理）
- Apache Airflow 公式ドキュメント（DAGによる処理依存の記述）
- 情報処理推進機構（IPA）公開の業務システム関連調査資料