【UiPath】「PowerShellを呼び出し」がここにきて便利なんじゃないか考察

はじめに

• 本記事は、「PowerShellを呼び出し」がここにきて便利なんじゃないかと考察した記事です。
• 記事の内容は、個人の見解または確認結果であり、UiPath の公式見解ではありません。
• 製品仕様や参考画像は 26.0.204 バージョンのもので構成しています。

「PowerShellを呼び出し」アクティビティ

「スクリプト入力」プロパティをONにすることで、PowerShellスクリプトをそのまま実行できます。

■使い方（例）

1. PowerShellスクリプトをテキスト変数（スクリプト）に読み込み
2. 「PowerShellを呼び出し」のプロパティを次の様に指定
   1. 入力：変数（スクリプト）
   2. スクリプト入力：ON
   3. 現在の型：String
   4. パラメーター：必要に応じて設定
   5. PowerShell変数：必要に応じて設定

Excelへの値入力サンプル

指定したExcelファイルの Sheet1 のリスト最終行の次の行に、社員情報を1行追加する場合、次の様なスクリプトで実現できます。

param(
    [Parameter(Mandatory = $true, Position = 0)][string]$Path,
    [Parameter(Mandatory = $true, Position = 1)][string]$社員番号,
    [Parameter(Mandatory = $true, Position = 2)][string]$社員名称,
    [Parameter(Mandatory = $true, Position = 3)][int]$年齢,
    [Parameter(Mandatory = $true, Position = 4)][string]$性別,
    [Parameter(Mandatory = $true, Position = 5)][string]$アカウント発行,
    [Parameter(Mandatory = $true, Position = 6)][string]$端末受領,
    [Parameter(Mandatory = $true, Position = 7)][string]$携帯番号,
    [string]$SheetName = "Sheet1"
)

$ErrorActionPreference = "Stop"

if (-not (Test-Path -LiteralPath $Path)) {
    throw "Excelファイルが見つかりません: $Path"
}
$Path = (Resolve-Path -LiteralPath $Path).Path

$excel = $null
$workbook = $null
$sheet = $null

try {
    $excel = New-Object -ComObject Excel.Application
    $excel.Visible = $false
    $excel.DisplayAlerts = $false

    $workbook = $excel.Workbooks.Open($Path)
    $sheet = $workbook.Worksheets.Item($SheetName)

    # A列（社員番号）の最終入力行を取得し、その次の行に書き込む
    # （罫線などの書式だけの行は対象外にするため UsedRange ではなく End(xlUp) を使う）
    $xlUp = -4162
    $lastRow = $sheet.Cells.Item($sheet.Rows.Count, 1).End($xlUp).Row
    $newRow = $lastRow + 1

    $values = @($社員番号, $社員名称, $年齢, $性別, $アカウント発行, $端末受領, $携帯番号)
    for ($i = 0; $i -lt $values.Count; $i++) {
        $cell = $sheet.Cells.Item($newRow, $i + 1)
        if ($values[$i] -is [string]) {
            # 先頭0の番号や「020-…」などが数値・日付に変換されないよう文字列として入力
            $cell.NumberFormat = "@"
            $cell.Value2 = [string]$values[$i]
        }
        else {
            # 年齢は数値として入力（COMへ渡すため double に変換）
            $cell.Value2 = [double]$values[$i]
        }
    }

    $workbook.Save()
    $rstMessage = "$SheetName の $newRow 行目に追加しました: $($values -join ', ')"
}
finally {
    if ($workbook) { $workbook.Close($false) }
    if ($excel) { $excel.Quit() }
    foreach ($o in @($sheet, $workbook, $excel)) {
        if ($o) { [void][System.Runtime.InteropServices.Marshal]::ReleaseComObject($o) }
    }
    [GC]::Collect()
    [GC]::WaitForPendingFinalizers()
}

（output.xlsx - 処理前）

複数代入アクティビティでパラメータ用の変数に値を設定します。

→「PowerShellを呼び出し」のプロパティのパラメータを設定します。

→「PowerShellを呼び出し」のプロパティのPowerShell変数を設定します。
（処理結果を rstMessage 変数に入れてワークフロー側に戻す例です）

    $workbook.Save()
    $rstMessage = "$SheetName の $newRow 行目に追加しました: $($values -join ', ')"
}

→
（output.xlsx - 処理後）

「PowerShellを呼び出し」がここにきて便利なんじゃないかとおもう理由

その① 生成AIがほぼ100点の精度のアウトプットを出せる

PowerShellのスクリプトについては、生成AIの学習用データが他言語に比べて豊富なのと、JavaScriptやPythonのライブラリのように、バージョンでAPIが変わることもなく、.NET基盤上で動作し、主要なコマンドレットの仕様がほとんど変わっていないことなどが高精度の理由と考えます。

その② 開発環境が不要（Windows-PC）

①番の精度メリットだけでいえば、VBやC＃でCoded WFをつくるとかでも得られますが、
PowerShellスクリプト以外だと、エディタや実行環境が必要になるので最低限それらをインストールする必要があります。
スクリプト開発者とStudio開発者というかたちで分業できた場合、
スクリプト開発者はUiPathのライセンスも不要な訳でコスパがよいのです。
テストコードもサクッとつくってくれますし、繰り返しのテスト実行も簡単です。

その③ Excelアクティビティを使わなくてもできる

UiPathで最も多く使われているパッケージはUiPath.Excel.Activitiesじゃないかとおもいますが、
秘密度の操作とかをのぞけば、ほとんどのExcelアクティビティの操作はPowerShellスクリプトでも実現可能です。
まだ生成AIの精度がいまいちだった頃（数年前）までは、
魔法のコードを書いてしまうと”保守できない”問題が生じるので
コード呼び出し系でゴリゴリ作りこんじゃうのは忌避されてきたとおもいますが、
今日日は簡単に仕様を書き起こせるし、スクリプトの修正であれば生成AIの方が正確だったりするので
Studioでワークフローを作りこむメリットがあまりないなというのが所感です。

その④ セキュリティブロックを回避できる

Windows Defender アプリケーション制御やグループポリシーの制約がある場合、せっかくつくった.ps1スクリプトも使えないといったケースがあるかとおもいます。
そんなときでも.ps1スクリプトの内容をテキストファイルとして保存し、
「PowerShellを呼び出し」アクティビティで読み込んで使えばスクリプト実行できたりします。
※UiPathはインストールされている前提

さいごに

いかがでしたでしょうか。
PowerShellスクリプトであれば、簡単な使い方説明書だけ添えれば
エンドユーザーも実行できるので、検証作業に早期から巻き込んでコアモジュールの品質を早めにかためることもできそうだなーと、今日はPowerShellの良いとこばっかに目がいきました✨
最後までお読みいただきありがとうございますm(_ _)m