UiPathのXAMLから仕様を取得する——AIプロンプトで解析・Mermaid化する手順

はじめに

UiPathからPythonへ移行する際、既存の .xaml ワークフローから「何をしているか」を正確に把握する必要があります。XAMLはXMLベースで人間が読めますが、フローが複雑だと全体像の把握や仕様書化に時間がかかります。

この記事では、AI（チャット＋ファイル添付）にXAMLを渡し、構造化された表 → 深掘りポイントの洗い出し → Mermaidフロー図まで一気通貫で行うためのプロンプト例を3種類まとめます。社内AIやChatGPT／Claude等でそのまま使える形にしています。

本記事は「UiPathのxamlをドキュメント化する」「UiPathのxamlをPythonで実装する」をテーマにしたシリーズの全3回のうち、第1回です。 第2回ではプロンプト運用をPythonで実装した実例、第3回では手法と実装を踏まえた振り返りと今後の方針を扱う予定です。

背景：なぜUiPathからPythonへ移行するのか

本記事で扱う「XAML解析・Mermaid化」は、UiPath（やWinActor）からPythonへ移行するという判断をしたうえで、その第一歩として「既存ワークフローから仕様を取り出す」ために行うものです。まず、なぜ移行するのかという背景を簡潔にまとめます。

UiPath・WinActorで続けるリスク

• 保守性: フローが複雑化するとスパゲッティ化し、読むのもメンテするのも負荷が大きくなる。XAMLは巨大になりやすく、Gitでの差分・マージも困難になりがち。
• コスト: 実行ライセンス・開発ライセンスが高額で、ボット数や実行量に応じて線形にコストが増える。ROIの低い業務の自動化が見送られる要因にもなる。
• ベンダーロックイン: シナリオはツール固有の形式（XAMLや専用バイナリ）に縛られ、必ずRPAベンダーのアプリがなければ動かない。企業にとって「自分たちの資産」として持ち続けにくい。
• 技術的負債: 処理ロジックがGUIや独自形式の奥に隠れ、何をしているかの可視化や引き継ぎがしづらくなる。

今後の未来・AI発展の中でコード（Python）でやる理由

• AIとの相性: Pythonは世界中で使われており、AIにとっての学習データがUiPathよりはるかに多い。GitHub Copilot・Cursor・Claude CodeなどのAI開発環境と組み合わせると、自動化シナリオを「コード」で組みやすく、開発ハードルはRPA並みまで下がっている。
• 実行コスト: Pythonの実行にはライセンス料がかからない。開発はVS Code＋CopilotやCursorなど比較的安価なツールで完結し、スケールしても追加の実行ライセンスが不要。
• 企業資産として: コードはGitで管理でき、差分・レビュー・履歴追跡がしやすい。LLMやAIエージェントとの連携も、Pythonなら数行で組み込める。今後AIがさらに発達していく中で、コードベースの自動化のほうが進化に適しているという判断ができる。

以上を踏まえ、「既存のUiPath資産は仕様として取り出し、Pythonで再設計・再実装していく」という方針を取る場合、その入り口としてXAMLから仕様を取得する必要があります。そこで役立つのが、以下で述べる「解析 → 深掘り → Mermaid化」の一連の手法です。

なぜこの手法を実施するのか

UiPathからPythonへ移行するには、既存ワークフローが「何を・どの順で・どんな条件で」やっているかを仕様として取り出し、設計・レビューできる形にしておく必要があります。そのために、単にXAMLを読むだけでは不十分になる理由と、本手法で得られるものを整理します。

生のXAMLだけでは足りない点

• 全体像の把握がしづらい: 複数xamlにまたがり、Invoke Workflowで呼び出し関係があると、どこからどこまでが一連の処理か追いにくい。
• 仕様漏れのリスク: 複雑なVB式・代入、画面要素（セレクター）への依存、ファイルパスの動的生成などは、移行時に見落とすとバグや動作差の原因になりやすい。
• 引き継ぎ・レビューのコスト: 担当者以外が読むとき、XMLを直読みするより「処理の流れの表」や「フロー図」があると、議論や確認がしやすい。

この手法で実現すること

1. 構造化された表（ユニーク番号付き）
   「シーケンス／スコープ単位」の処理内容・種類・遷移先・備考を一覧にし、後でMermaid化するひな形にする。複数ワークフローは表を分けて、呼び出し関係が分かるようにする。

2. 深掘りすべき箇所の特定
   表をAIに渡し、「複雑なVB式」「セレクター依存」「分岐条件」「動的パス生成」などの観点で重点確認すべきユニーク番号を挙げてもらう。移行時の仕様漏れを減らす。

3. Mermaidフロー図
   表から graph TD 形式のコードを生成し、設計書やドキュメントにそのまま貼れる形にする。何をしているかの共通認識を図で持てる。

まとめると、「なぜ実施するか」＝移行前に仕様を可視化・共有し、重点確認箇所を押さえたうえでPython側の設計に活かすためです。以下では、そのためのプロンプト例を3段階で紹介します。

この記事で伝えること

• UiPathの .xaml をテキストで渡して「解析用プロンプト」で箇条書き表を得る方法
• その表をもとに「深掘りすべき箇所」をAIに挙げてもらう「深掘り用プロンプト」
• 表からMermaidの graph TD を生成する「Mermaid生成用プロンプト」
• 各プロンプトの想定入力・出力イメージ

前提：XAMLの渡し方

.xaml の実体はXMLのテキストです。以下のいずれかで渡すと解析しやすくなります。

• テキストとして貼り付け: コードブロック内にXAMLを貼る
• ファイル添付: 社内AIやツールがファイル添付をサポートしている場合はそのまま添付

複数ワークフロー（Main / 取得フロー / 登録フローなど）がある場合は、呼び出し関係が分かるようにまとめて渡すと、後でMermaid化する際に便利です。

1. 解析用プロンプト

用途: 添付した .xaml から、後でMermaid化するための「箇条書き表」を出力させる。

プロンプト文面（コピー用）

【タイトル】UiPath .xamlファイルの構造解析とフロー概要の作成

【目的】
提供するUiPathの .xaml ファイルを解析し、処理内容を構造化された箇条書きでまとめてください。この内容は、後ほどMermaid形式でフロー図を作成するための「ひな形」として使用します。

【解析ルール】
1. 粒度: まずは「シーケンス」や「スコープ」単位で大きな処理の流れを記述してください。
2. 重要情報の抽出: その処理の中で「Invoke Workflow（別フローの呼び出し）」や「複雑な代入式（Multiple Assign）」「分岐条件（If/Decision）」がある場合は、必ずその詳細を備考に含めてください。
3. 複数xamlがある場合: ワークフローごとに表を分け、呼び出し関係がわかるようにしてください（例: Main / 取得フロー / 登録フロー）。
4. 出力は以下の【出力フォーマット】に厳密に従ってください。

【出力フォーマット】
| ユニーク番号 | 処理の内容 (DisplayName) | 処理の種類 (Activity Type) | つながるユニーク番号 | 備考/使用変数 |
| :--- | :--- | :--- | :--- | :--- |
| (例: M01) | (アクティビティ名) | (Read Range, Invoke Workflow等) | (次へ進む番号) | (引数や計算式、条件式) |

【対象ファイル】
（ここに .xaml のテキストを貼り付けるか、ファイルを添付してください）

出力例（1ワークフロー分）

複数xamlの場合は、ワークフローごとに表を分けて記載すると、呼び出し関係が追いやすくなります。

2. 深掘り用プロンプト

用途: 解析結果の表を渡したあと、「どの番号を詳しく見るべきか」をAIに挙げてもらう。移行時に仕様漏れやバグを防ぐため、重点確認箇所を特定するのに使います。

プロンプト文面（コピー用）

上記の解析結果（表）を見て、次の観点で「詳細なステップ確認が必要と思われる」ユニーク番号を挙げてください。各番号について、なぜ深掘りすべきか理由を1行で書いてください。

- 複雑なVB式・代入（Assign）が含まれる箇所
- 画面要素（セレクター）に依存している箇所
- 分岐条件が複雑な箇所
- ファイルパスや重要変数を動的に生成している箇所

目安として、優先度の高いものから3〜5個程度で構いません。

出力例

1. G04 … 備考から「オプション」の有無を判定・抽出するロジックがあり、VB式やSplit等が含まれる可能性が高い。仕様変更時のバグが起きやすい。
2. R04 … フォームへの値入力でセレクターに依存している。画面改修で止まるリスクがある。
3. G05 … ファイル名を動的生成している。他フローとのパス・命名規則の一致確認が必要。

3. Mermaid生成用プロンプト

用途: 解析結果の表を、Mermaidのフローチャートコードに変換させる。ドキュメントや設計書にそのまま貼れます。

プロンプト文面（コピー用）

上記の表（解析結果の箇条書き）を元に、Mermaidの graph TD 形式でフロー図のコードを出力してください。

【ルール】
- ノードIDは表の「ユニーク番号」をそのまま使うこと（例: M01, G02, R03）。
- ノードのラベルは「処理の内容 (DisplayName)」を使うこと。
- つながるユニーク番号に従ってエッジ（矢印）を張ること。
- 条件分岐で True/False などがある場合は、エッジに (T)(F) 等のラベルを付けてよい。
- 複数ワークフローがある場合は、1つのgraphにまとめても、サブグラフで分けてもよい。読みやすさを優先すること。

出力例

graph TD
    M01["設定ファイル(config.xlsx)の読み込み"]
    M02["顧客データ取得処理の実行"]
    M03["顧客データ登録処理の実行"]
    M01 --> M02
    M02 --> M03
    M03 --> 完了

実際には、複数フローをまとめた大きめのグラフになる想定です。

おわりに

• 解析用でXAML → 表、深掘り用で重点確認箇所の洗い出し、Mermaid生成用で表 → フロー図、という3段階に分けると、移行設計やレビューがしやすくなります。
• プロンプトは社内AI・ChatGPT・Claude等でそのまま使えます。解析対象のXAMLを「【対象ファイル】」の下に貼るか、ファイル添付で渡してください。
• 履歴や運用メモは個人管理用に元ノート（Obsidian等）に残し、必要に応じてプロンプトを微調整するとよいです。

UiPathからPythonへの移行を進める際の一助になれば幸いです。