【番外編1】UiPathのXAMLをAIに読ませてみた実録ログ——Claude Sonnet 4.5で解析〜Mermaid化まで

はじめに

この記事は、Zenn に公開している:

• 「UiPathのXAMLから仕様を取得する——AIプロンプトで解析・Mermaid化する手順」 (uipath-xaml-mermaid)

の**番外編1（実録ケーススタディ）**です。

本編では、

• 解析用プロンプト（XAML → 構造化された表）
• 深掘り用プロンプト（重点確認すべきステップの洗い出し）
• Mermaid 生成用プロンプト（表 → graph TD のコード）

という 「プロンプトの型」そのものを紹介しました。

本記事では、そのプロンプトを Claude Sonnet 4.5 に投げてみた実際のログを整理し、

• どのくらい素直に意図通りの表が出てくるのか
• どんなステップが「要深掘り」と判定されたのか
• Mermaid フロー図はどの程度そのまま使えるのか

といった観点で振り返ります。

対象ワークフローと前提

対象は、以下 3 つの .xaml です。

• Main.xaml
• 顧客データ取得フローチャート.xaml
• 顧客データ登録フローチャート.xaml

ざっくり役割は次の通りです。

• Main.xaml

  • config.xlsx を読み込み dt_config に格納
  • 顧客データ取得フローチャート.xaml を Invoke
  • 顧客データ登録フローチャート.xaml を Invoke

• 顧客データ取得フローチャート.xaml

  • argument_config (DataTable) を Dictionary<string, string> に変換（configDict）
  • WebアプリA から営業獲得データをスクレイピング（dt_kakutoku）
  • 加工用 dtOutput を組み立て、「オプション有無・品名」を VB 式で判定
  • 日付付きファイル名で Excel（input 用ファイル）を書き出し

• 顧客データ登録フローチャート.xaml

  • argument_config から configDict を生成し、取得フローと同じ命名規則で input ファイルパスを作成
  • Excel から dt_Exceldata を読み込み
  • WebアプリB に対して ForEachRow で1行ずつフォームに入力 → 確認 → 登録ボタン押下

以降、この 3 つをまとめて AI に渡し、本編で紹介した「3つのプロンプト」を順番に投げていきます。

1. 解析用プロンプト → 構造化された表

まずは本編で紹介した「解析用プロンプト」を、そのまま Sonnet 4.5 に投げました。

投げたプロンプト（抜粋）

（※全文は本編記事の「1. 解析用プロンプト」を参照）

• 粒度は「シーケンス／スコープ」単位
• Invoke Workflow や複雑な Multiple Assign、分岐条件があれば「備考」に詳しく書く
• 複数 xaml があればワークフローごとに表を分ける
• 出力フォーマット（ユニーク番号・DisplayName・Activity Type・つながるユニーク番号・備考）を厳守

Sonnet 4.5 の出力（ダイジェスト）

実際の出力では、以下のような ユニーク番号付きの表がワークフローごとに生成されました。ここではダイジェストとして一部だけ載せます。

Main.xaml

顧客データ取得フローチャート.xaml

顧客データ登録フローチャート.xaml

所感

• プロンプト通りに「ワークフローごとの表」と「ユニーク番号」が素直に出てくる。
• VB式や Path.Combine を含む箇所も、かなり細かく「備考」に書いてくれる。
• 後続の Mermaid 生成を見据えた「ノード候補」として、そのまま使える品質でした。

2. 深掘り用プロンプト → 要確認ステップの抽出

次に、本編で紹介した「深掘り用プロンプト」を、いま得た表に対して投げます。

投げたプロンプト（要旨）

• 複雑な VB 式・代入
• 画面要素（セレクター）依存
• 分岐条件の複雑さ
• 動的なファイルパス・重要変数の生成

といった観点で、「詳細なステップ確認が必要と思われるユニーク番号」を 3〜5 個挙げてほしい、という指示です。

Sonnet 4.5 が挙げたステップ

• G03（営業獲得Excelファイル作成）
  複数の複雑な VB 式（If(...Contains("なし")...) や Split("："c).Last、dtOutput.AsEnumerable().Skip(1).CopyToDataTable()）と動的ファイルパス生成が混在しており、データ変換仕様の誤解・不具合リスクが高い。

• R04（データ登録を実施）
  1レコード分の全入力処理で多数の NTypeInto / NSelectItem がセレクターと CurrentRow の列名に依存しており、画面変更や列名変更に影響を受けやすい重要ステップ。

• R01（設定ファイルをdicに、登録データ読み込み）
  argument_config から configDict への ToDictionary と、Path.Combine(configDict("inputFile保存先"), Now.ToString("yyyyMMdd") & "_営業獲得データ_rpa用inputFile.xlsx") による動的ファイルパス生成があり、設定ミス・日付フォーマット・パス構成の確認が必須。

• G01（設定ファイルをdicに）
  取得フロー側でも同様の ToDictionary によりキー/値を構成しており、設定表の列順やキー名称の変更が全体に波及するため、マッピング仕様の詳細確認が必要。

• R05（入力内容の確認と登録）
  「確認」「✅ 登録」「データを登録する」の3つのボタンを順に NClick する UI 依存ステップであり、セレクターや画面遷移タイミングのズレが登録失敗や二重登録に直結するため、フローと待機条件の詳細確認が必要。

所感

• 人間の目から見ても「たしかにここは怖い」と感じる箇所を、かなり素直に拾ってくれた印象です。
• 特に、
  • config.xlsx → Dictionary → 動的パス
  • 備考文字列からオプション情報を抜くロジック
  • Web画面のセレクター依存
    など、UiPath → Python 移行時に仕様漏れしやすいポイントを自然にリストアップしてくれたのは有用でした。

3. Mermaid 生成用プロンプト → フロー図コード

最後に、「Mermaid 生成用プロンプト」を使って、先ほどの表から graph TD を作ってもらいます。

生成された Mermaid コード

graph TD

  %% Main.xaml
  subgraph Main["Main.xaml（メイン）"]
    M01["Main Sequence / main 内の Excel プロセス スコープ"]
    M02["顧客データ取得 シーケンス"]
    M03["顧客データ登録 シーケンス"]

    M01 --> M02
    M02 --> M03
  end

  %% 顧客データ取得フローチャート.xaml
  subgraph 顧客データ取得["顧客データ取得フローチャート.xaml"]
    G01["設定ファイルをdicに"]
    G02["営業獲得データをデ取得"]
    G03["営業獲得Excelファイル作成"]
    G04["ブラウザーを使用 Edge: WebアプリA - 営業獲得管理システム"]

    G01 --> G02
    G02 --> G03
    G03 --> G04
  end

  %% 顧客データ登録フローチャート.xaml
  subgraph 顧客データ登録["顧客データ登録フローチャート.xaml"]
    R01["設定ファイルをdicに、登録データ読み込み"]
    R02["データ登録 内の最初のブラウザ起動"]
    R03["データ登録 内の 繰り返し (データ テーブルの各行)"]
    R04["データ登録を実施"]
    R05["入力内容の確認と登録"]

    R01 --> R02
    R02 --> R03
    R03 --> R04
    R04 --> R05
    R05 --> R03
  end

  %% ワークフロー呼び出し関係（Main から子XAML）
  M02 -.->|Invoke WorkflowFile| G01
  M03 -.->|Invoke WorkflowFile| R01

このコードを Mermaid Live Editor や VS Code の Mermaid プレビュー拡張などに貼ると、

• Main → 取得フロー / 登録フロー の呼び出し関係
• 登録フロー内の ForEachRow によるループ構造

が一目で分かる図が得られます。

所感

• 「ユニーク番号」をノード ID にする、という本編の設計がそのまま効いていて、ほぼ手修正ゼロで図にできるレベルでした。
• ループ（R05 → R03）などもきちんとエッジとして表現されており、「設計レビュー用のたたき台」としては十分です。

4. やってみて分かったこと

今回、同じプロンプトセットを Sonnet 4.5 に対して実行してみて、次のような学びがありました。

• プロンプトが「構造と粒度」をかなり強く縛ってくれる。
  モデルが違っても、ユニーク番号・ワークフロー単位の表・備考の書き方が大きく崩れにくいと期待できる。

• 「深掘り候補」の出し方に、そのモデルの得意分野が出る。
  Sonnet 4.5 は VB 式／LINQ／Path 組み立て／セレクター依存といった「バグりやすいポイント」を自然にピックアップしてくれた。

• Mermaid への変換は、ほぼ機械的に任せられる。
  一度「ユニーク番号＋つながる番号」という表形式を決めておけば、グラフへの変換はプロンプトでかなり自動化できる。

• 別エンジンでも同じプロンプトを試す価値がある。
  例えば Gemini 3 の高速版など、他モデルに同じ 3 ステップを投げて、「どの程度同じ構造・同じユニーク番号が出てくるか」を比較すると、**「プロンプトの汎用性」**を評価できそうです。

おわりに（今後の番外編について）

本記事では、本編で紹介したプロンプトを、実際の .xaml（顧客データ取得・登録フロー）に対して Sonnet 4.5 で実行したログをまとめました。

• XAML → 構造化された表
• 表 → 深掘り候補
• 表 → Mermaid フロー図

という 3 ステップが、現実のプロジェクトでも十分実用的な形になることを確認できました。

今後の番外編としては、

• 番外編2: Gemini 3 高速版など他モデルで同じプロンプトを実行して比較
• 番外編3: 深掘り候補（G03 / R01 / R04 / R05 など）を、Python 実装側の設計にどう落とすか

といった内容も試していく予定です。