PowerAutomate（クラウドフロー）の備忘

案件でPowerAutomateを利用することになりましたので、その備忘のための記録です。
読者は想定していません。そのうちきれいにしたいと思っております。

SharePointのUnicodeデコーダー（日本語プロパティをデコードするツール）

https://www.pulsar-works.jp/features/tools/sp-unicode-decoder.html
作りましたので、おいておきます。ほんとは物理名と論理名を分けたほうがいいと思いますが、そうはいかない事情もあるでしょう。

作った理由は後述。

もっとも重要なアクション

PowerAutomateで最も重要なアクションは作成です。

これはデバッグ用に、処理内部の内容をconsole.logのように出力しています。

{
  "type": "Compose",
  "inputs": {
    "trigger": "@triggerBody()",
    "a": "@variables('a')"
  }
}

最重要アクション作成は特定のスコープ内で定数を定義するアクションです。

プログラマーは、特定のスコープ、例えばSwitchの先にスコープ定数を指定したいと思うでしょう。そんなとき、変数を初期化するは使えません。使えるのは作成です。

変数を初期化するは変数を作成するアクションではなく、グローバル変数を作成するアクションです。なぜこんな名前がついているのか不明です。

純粋にスコープ内の変数を定義する方法はなさそうです。

「作成」はComposeをそのまま日本語にしているのでしょうが、重要性を感じず、まったく取るに足らないアクションに見えます。しかしながら、スコープ内の定数を定義する重要なアクションだと思います。

例として、「条件」の内部のアクションで、変数を初期化することはできません。（やってみてください。エラーになり保存できません。）

作成で出来たオブジェクトを取得・利用するには、「出力」というプロパティを利用します。

作成アクションのアウトプットです。

数式でのオブジェクト操作が重要

数式はWorkflow Definition Language（WDL）式というらしいです。

例えば、Teamsの承認アクションの戻り値は

"body": {
        "responses": [
            {
                "responder": {
                    "id": "id-1239das",
                    "displayName": "your-name",
                    "email": "[e-mail]",
                    "tenantId": "tenantId",
                    "userPrincipalName": "user-principal-1234-aaa"
                },
                "requestDate": "2026-02-26T11:08:31Z",
                "responseDate": "2026-02-26T11:11:07Z",
                "approverResponse": "Approve",
                "comments": "あい\nう"
            }
        ],
        "responseSummary": "要約",
        "completionDate": "2026-02-26T11:11:07Z",
        "outcome": "Approve",
        "name": "aweawfn",
        "title": "オンライン経費申請",
        "itemLink": "https://example.com",
        "requestDate": "2026-02-26T11:08:31Z",
        "expirationDate": "9999-12-31T23:59:59Z",
        "priority": "Medium"
    }
}

こんな感じです。

この構造を頭に入れないといけないので、知らないアクションや接続先の場合は、まずフローを流してデータを見るところから始めることになります。

型を強制する

特定のアクションの出力がどのような構造になるか、決まらない場合、その先にサジェストが現れません。例えば、SharePointリストを指定して、項目を取得すると、そのプロパティを類推（サジェスト）させることができますが、リストのIDを変数で受けるなど、抽象度が上がると推論がきかなくなります。

JSONの解析を利用すると、サンプルデータから型を強制することができます。

型が決まらない抽象度の高い出力にJSONの解析を行うと、その先（JSONの解析の出力）は型の類推がきいた状態になります。

アクションを途中まで一度流すと、だいたい出力でそのサンプルが取得できるので、有用です。万能ではないが。

勝手にFor-Eachになる

アクションの戻りが配列になっているとき、その戻りのプロパティを別のアクションで使おうとすると、勝手にForEachで作成されますよね。最初は戸惑いました。

例えば、ぼくは承認のコメントをSharePointリストの項目に入れようとしたのですが、戻りが配列になっていた（承認者を複数設定することができるため、コメントも複数戻ってくる）ために、Forで括られてしまいました。

これは親切な機能だなって思います。

for文内で、CurrentItem（for-eachの論点になっているアイテム)をとる

item()

または

items('Forアクションの名前')

で、対象のアイテムを取得できます。

?と[]

JSのOptionalChainみたいな感じです。nullだったら評価しない。
と思っていました。違いました。

例えば、variables('aaa')['bbb']と書いたとき、aaaがnullじゃなくても、bbbがないとエラー になります。また、aaaがnullでもエラーになります。

一方で、variables('aaa')?['bbb']と書いたとき、aaaがnullである場合のエラーは一緒 で、bbbがない場合はエラーにはなりません。

つまり、?は後ろの宣言に係る。 と分かりました。
JSのOptionalChainは前の宣言に係っているので、違っています。

item()?['comments']
は、ループ内にいるオブジェクトからcommentsを取り出す。なければ何もしない。 ことを表すようです。

条件式

条件式を条件を使って書くと不具合を起こしやすいし、ネストが深くなる。
作成を利用してWDLを書き、1,2,3やOK,キャンセル,エラーのように場合分けしてしまうほうが良さそう。それをスイッチした方が見た目に分かりやすく、分岐のログも残る。（条件内部にWDLを書いた場合ログをたどれないっぽい。やり方あったら教えてほしいです。）

ガード(Early Return)

ネストが深くなるのを避けるために、アーリーリターンをしたくなる。
終了アクションがそれです。

ただし、実行ログがちょっと汚くなる。

トリガーの条件にWDLを書けるので、そっちに書いたほうが見た目はきれい。（動かないときに原因究明ができないが。)

エラーメッセージ

保存時にエラーメッセージが出ます。赤字の。
めちゃくちゃ苦痛ですよね。問題解決の方法が載ってないし。

エラーメッセージはコピーして、VSCodeなどに貼り付け、JSONフォーマットします。

これで、問題解決の方法を探ることができます。実はちゃんとメッセージが返ってきているのですが、わけわからんメッセージで埋められて、ヒントが読めなくなっています。

Results/Value（ODataパス)

ResultsというプロパティがValueという子をもっているとき、Results/Valueのように表記できます。
例えば、SharePointリストの選択列などを作成した場合、Valueに実際の値が入っています。

また、SharePointリストの特性ですが、日本語のプロパティはUnicodeエンコードされますよね。

OData__x5408__x8a08__x91d1__x984d_

合計金額

こいつらが重なり合うと可読性がひどいことになります。

エンコードされたODataクエリをデコードするツールを作りました。
https://www.pulsar-works.jp/features/tools/sp-unicode-decoder.html

ダウンロードできます。Web上のフォームに入力すると怒られる環境の方はローカルにDLして使ってください。（Ctrl＋S)

式のエスケープ

@をプロパティの先頭に入れたい場合があります。その場合は、@@とすると、@を出力できます。

入力

{
  "@@hoge" : "@variable('bar')"
}

出力

{
  "@hoge" : "barの値"
}

@が式展開に利用されるから、こういうことが起こります。

こんな現象にも遭遇しました

AIに考えてもらうには

AIにやりたいことを伝えるとき、アクションの内容をそのまま見てもらっても、AIは前後の問題を全く見ないらしく、回答に自力でたどり着けない場合が多いです。
スコープを利用して、ひとまとまりの処理にくくってしまいます。 それをコードビューで表示すると、全体像を表すJSONが現れます。これをAIに渡すと、内容が理解しやすいようです。

人間が見ても有用です。勝手にPowerAutomateのエディタが数式を書き換えていたりすることがあります。そういう時に生の設定を見るにはコードビューが有効でした。

OfficeScript

OfficeScriptはTypeScriptで書くことができます（！！）
できないことはOfficeScriptに渡して、出力をもらったほうがわかりやすいです。
Excelのデータを入出力するなどは早めにオブジェクトごとOfficeScriptへ渡したほうが保守性は良さそうです。

出力から、OfficeScript内の「console.log」を見ることができます！（素晴らしい😊）　logsプロパティがそれです。

PowerAutomateの感想

WDLを知ることで苦痛を和らげることができました。
いろんなことが安全にできるのはすごいですが、仕様が一貫していない感じがします。
アクションの命名が日本人には直感的ではないですね。SharePointのアクションとかひどくて、アイテムとか項目とか、用語が一貫していないのですごくわかりにくいです。機械翻訳だからでしょうね。

Web記事も販促用の怪しいものが多く、解決策に到達するまでに時間がかかりました。すごい量のサービスに接続できるので、使いこなせれば意義があるんだろうなと思いますし、注目度も高いのかなと感じました。