7月11日、Skyvernが「The Five Layers of Agentic Process Automation」と題した記事を公開した。AIエージェントによるプロセス自動化（APA）を5つの層に分解し、各層の役割・障害モード・アーキテクチャ要件を体系的に整理した内容だ。
「自動化がいつも同じ場所で壊れる」問題の正体
ログインフローが変わった、フォームが再構成された、セッション中にモーダルが割り込んだ、出力のスキーマがずれた——これらはランダムな障害ではない。Agentic Process Automation（APA）システムの特定の層に対応した、予測可能な故障パターンだ。
従来のRPA（ロボティック・プロセス・オートメーション）はクリック操作を記録・再生する仕組みのため、ポータルのボタン名が変わるだけで動作が止まる。RPA運用チームはその維持管理に**全工数の30〜70%**を費やしているとされる。
APAはその前提を根本から変える。エージェントが実行時にページの状態を視覚的に読み取り、次の行動を自律的に決定するため、UIの変化は「致命的な障害」ではなく「新しい入力」として扱われる。
APAが適用される4条件
すべてのワークフローがAPAの対象になるわけではない。以下の4条件がそろったとき、スクリプト自動化やシンプルなAIラッパーでは対応しきれなくなる。
- APIが存在しないウェブポータルが対象であること
- 複数ステップにまたがるコンテキスト保持が必要なワークフローであること
- セレクタやレイアウト、認証フローが予告なく変わる環境であること
- 出力が重要な下流の意思決定に使われ、監査可能な構造化データが必須であること
5層フレームワークの全体像
APAを「単一の能力」として捉えるのではなく、スタック（積み重ね）として理解することが、障害診断の出発点になる。Skyvernはこの構造を以下の5層に整理している。
Layer 1: Perception（知覚）
知覚層は、APAがスクリプトと根本的に異なる起点だ。
従来のブラウザ自動化はページ記録時に静的なセレクタマップを作成する。ポータルが変わるとそのマップが壊れ、エラーも出さずに何も返さない。オペレーターが気づいたときには、ポータルがすでに再び変わっているケースもある。
APAエージェントはキャッシュされたマップを持たない。実行時に実際のページをビジュアルに読み取る。知覚層の具体的な能力は3つだ。
- ビジュアルページ読み取り: 外観・位置・文脈から要素を識別。「Submit」ボタンが列移動や色変更をしても認識できる
- ライブ状態評価: 各ステップで実際のページ状態を確認。セッション警告やCAPTCHAの割り込みにも対応
- 文脈的要素解決: 「NPI Number」と「Provider ID」のように表記が異なる同一概念を同じ意図として解釈。同一のワークフロー仕様が複数のポータルで動作する
Layer 2: Reasoning（推論）
推論層は、「何をすべきか」を決定する層だ。ここがなければ、APAは高機能な再生ツールにすぎない。
エージェントはゴールを受け取り、現在のページ状態を読み取り、ゴールに最も近づく次のアクションを選択・実行し、再評価する——このプランニングループを各ステップで繰り返す。
プロダクションレベルの推論に必要な3能力：
- 状態認識: 多段階ワークフローのどこにいるかを追跡。セッションタイムアウトで最初からやり直しにならない
- 例外認識: 未知のモーダルやCAPTCHAを「例外」として識別し、解決または人間にエスカレーション
- ゴール分解: 複雑なタスクをサブゴールに分割し、独立して計画・検証
Layer 3: Planning（計画）
計画層は、実行に入る前にアクションシーケンス全体を構造化する責務を持つ。推論層が「次の一手」を決めるのに対し、計画層はワークフロー全体の依存関係と分岐条件を事前に定義する点で役割が異なる。
具体的には次の3つの機能が含まれる。
- シーケンス構造化: 複数ステップの順序と依存関係を明示的に表現し、途中ステップの失敗が後続ステップに波及しないよう分離する
- 分岐条件の定義: 「このポータルでは2FAが要求される場合がある」「フォームのバリエーションがX/Yの2種類存在する」といった条件分岐を計画段階で織り込む
- 承認ゲートの設置: 高リスクなステップ（最終送信・支払い確定など）の直前に人間レビューを要求するゲートを組み込み、自動化と人間の監視を共存させる
計画層が欠けると、エージェントは個々のステップを正しく実行できても、ワークフロー全体として整合性のない結果を出力するリスクが高まる。
Layer 4: Execution（実行）
実行層は、計画されたアクションシーケンスを実際のブラウザ操作として具現化する層だ。ここでの障害モードは計画の誤りではなく、リアルタイムの環境変化への対処能力に起因する。
主な機能は次のとおりだ。
- ブラウザ操作の実施: クリック・入力・スクロール・ファイルアップロードといった操作を実行時のページ状態に基づいて行う
- 認証フローへの対応: ローテーションする2FAコードや、セッション切れ後の再認証フローを動的に処理する。記録済みパスの再生ではなく、その都度の状態を読み取って対応する
- 予期しない割り込みへの処理: 実行中に出現する同意バナー・タイムアウト警告・未知のモーダルをリアルタイムで識別し、ワークフローを継続するか人間にエスカレーションするかを判断する
- 構造化出力の生成: 実行結果をスキーマ定義済みの構造化データとして出力する。下流システムへの受け渡しや監査ログの作成に直結する機能だ
Layer 5: Learning（学習）
学習層は、ランをまたいだ知識の蓄積がこの層の最大の特徴だ。個々の実行から得たパターンを記憶し、後続の実行に自動で適用することで、時間とともにシステム全体の耐障害性が向上する。
元記事が示す具体例が分かりやすい。ある保険会社ポータルで新しい割り込みモーダルへの対処パターンを学習した場合、同グループの後続ポータルへの実行時にそのパターンが自動で適用される。個別ポータルの修正が、関連ポータル群全体の改善に波及する構造だ。
学習層がない場合、同じ種類の割り込みが別のポータルで発生するたびに手動対応が必要になり、大量ポータル環境ではその累積コストが無視できなくなる。
この5層は閉じたループを形成しており、1つでも欠けると特定の形でワークフローが壊れる。知覚が弱ければ誤った状態認識から連鎖的に失敗し、学習がなければ同じ障害を何度も繰り返す。
RPA・IPA・APAの比較
比較表に登場するIPAとはIntegrated/Intelligent Process Automationの略で、従来RPAにAIによる入力解析を組み合わせた中間的なアプローチを指す。セレクタ再生を基本としつつ、OCRや自然言語処理で入力データを補完する構成が一般的だ。
| 項目 | 従来RPA | IPA | APA |
|---|---|---|---|
| 実行モデル | 固定クリック列を記録・再生 | セレクタ再生＋AI入力解析 | 実行時にライブページ状態を読み取り |
| UI変化への耐性 | ボタン名変更で即破綻 | レイアウト変更で破綻 | レイアウト変更は新しい入力として処理 |
| 認証処理 | 記録済みパスを再生 | RPAと同等 | ローテーション2FA・セッション切れに対応 |
| 保守負荷 | 工数の30〜70%が保守 | セレクタマップの保守が残る | セレクタマップ不要 |
実務的な含意
Skyvernはこの5層すべてにわたって動作するAPA基盤として自社を位置づけており、ワークフロー仕様に承認ゲートと完全な実行トレースを最初から組み込む設計をとっている。ただし高リスクなワークフローの最終提出前には人間によるレビューが依然として重要だと明記している点は注目しておくべきだろう。
数十の保険会社ポータルにまたがる適格性確認や、20以上の物流システムにまたがる運賃照会ワークフローのように、「APIなし・レイアウト可変・大量ポータル」の環境で、この5層フレームワークが最も直接的な効果を発揮するとされている。
詳細はThe Five Layers of Agentic Process Automationを参照していただきたい。
