こんにちは、digiです。
最近、仕事ではUiPathの高度な機能であるDocument Understanding（DU）やAction Centerを使った業務自動化の設計・実装に深く携わっています。
AIが帳票を読み取り、判断に迷う箇所だけを人間がチェックする。この「AIと人の協調」というコンセプトは非常にスマートですが、いざ実装フェーズに入ると、ドキュメントを読んだだけでは見えてこない「現場ならではの泥臭い壁」に何度も突き当たりました。
特に頭を悩ませたのが、以下の2点です。
- 「待機して再開（Wait and Resume）」によるプロセス構造の根本的な変化
- 「シリアライズ可能」な変数でなければならないという、データ型の制約
C#やVBAなど、これまでさまざまな言語で開発を経験してきましたが、UiPathのオーケストレーションプロセス特有の挙動には、ベテランエンジニアならではの「設計の勘」が通用しない部分もあり、正直かなり手こずりました。
今回は、私が実務でこの壁をどう乗り越えたのか、また上流工程の視点から「あらかじめ何を考慮しておくべきだったか」という教訓を、備忘録を兼ねて共有します。
第1章：メインに居座る「待機して再開」アクティビティの衝撃
Action Centerを組み込む際、まず最初に突き当たるのが、プロセスの作りそのものを「非同期」に変えなければならないというルールです。
通常のRPAは、上から下へ一本道で実行して終わります。しかし、DUで読み取った結果を人間が確認するAction Centerを挟む場合、ロボットは人間の入力を待つ間、一度処理を「中断」し、リソース（ライセンス）を解放してOrchestratorに制御を戻さなければなりません。
ここで使うのが「待機して再開（Wait and Resume）」系のアクティビティですが、これが実に曲者でした。
ここがハマりどころ：Mainに置かないと駄目という絶対ルール
待機アクティビティは、基本的にMain（最上位のエントリポイント）のスコープ内に配置する必要があります。この制約があるため、使い慣れたReFrameworkテンプレートがそのままでは使用できません。ドキュメント等にもなかなか明記されておらず、気づかないと延々とハマってしまうポイントです。
この解決には、UiPath公式が提供している「長期実行ワークフロー（Long-running Workflows）」のテンプレートが非常に参考になりました。Mainに「待機して再開」のアクティビティが鎮座している構造は、一見特殊ですが、この挙動を理解することでようやく視界が開けました。
第2章：エンジニアを絶望させる「シリアライズ可能」の呪縛
オーケストレーションプロセスにおいて、最大の技術的障壁となるのが「変数のシリアライズ」です。
「待機して再開」アクティビティを実行すると、ロボットは一度停止し、その瞬間のメモリ上の情報をOrchestratorへ保存します。再開時にそのデータを再びメモリに読み戻す（デシリアライズする）ため、すべての変数が特定の条件を満たしている必要があります。
1. 「型」の厳格なセレクション
プロセス内で使っているすべての変数が「シリアライズ可能」でなければなりません。Int32やStringといった基本型は問題ありませんが、実務で多用する以下の型には注意が必要です。
- ExtractionResults：DUの抽出結果そのものは、そのままでは待機を跨げない場合があります。
- .NETの一部のクラス：特定のライブラリが生成する複雑なオブジェクトは軒並みエラーの対象になります。
- QueueItem：これも待機を跨ぐ際には注意が必要です。
2. C#やVBAの常識が通用しない「データの断捨離」
ふだんC#などで開発していると、オブジェクトをメモリに保持したまま処理を流すのは当たり前です。しかし、Action Center連携では、待機の直前で「必要なデータだけをシリアライズ可能な型に詰め替え、不要なオブジェクトを破棄する」という作業が発生します。
例えば、使用頻度の高い DataTable型変数は List型に変換しておく といった工夫が必須でした。Document Understandingの複雑なデータ構造から「どの項目が人間による検証に必要なのか」を選別し、型を変換して受け渡す処理の実装には、かなりの時間を溶かしました。
3. 「スコープ」の設計が成否を分ける
この問題を回避する戦略は、「変数のスコープを最小限にすること」に尽きます。待機アクティビティがある階層の変数パネルを極限までシンプルに保ち、シリアライズ不可能な変数は、待機が入る前のサブワークフロー（Invoke Workflow）内で使い切って消滅させることが重要です。
この「変数の寿命管理」こそが、UiPathの高度な開発において最も設計力が試されるポイントだと痛感しました。
いかがでしたでしょうか。技術的な制約は多いですが、これらを乗り越えた先にある「AIと人間のシームレスな連携」は、業務自動化の価値を一段引き上げてくれます。この記事が、同じ悩みを持つエンジニアの方の助けになれば幸いです。
コメントを残す