今日のトリビア：Micorosoft PowerAutomateでPowerFxを起動してはならない

Power Automateのコードを確認する方法

アクション単位

フローを編集にして、アクションをコピー後、メモ帳に張り付ける。
逆にメモ帳に張り付けたコードを張り付けるとアクションになる。

個別のステップ（アクション）の定義を確認する場合（JSONで取得する場合）

1. フロー編集画面で、対象のアクションの右上にある「...（三点リーダー）」をクリック。
2. 「クリップボードにコピー」を選択。
3. メモ帳などのテキストエディタに貼り付け（Ctrl + V）。
4. これで、そのアクションの定義が JSON形式 で表示される。
5. 戻す場合: 新しいステップを追加する際、「マイ クリップボード」タブを選択し、コピーした内容を選択するか、エディタからコピーした状態で Ctrl + V を押すとフローとして復元される。

   ステートメント（命令）

   命令の体系はrobin言語とされているが、大枠としてドットネットの命令が使用されている。ただしPower Automateオリジナルの命令についてはMicrosoftのどこにも公式な解説は存在しない。
   そしてrobin言語の解説はWebArchive
   https://www.youtube.com/watch?v=nofCem7a6BU
   にあるが、これまた変数の定義からして違うので役立たない。

   包含されるバイナリ

   PowerAutomateはUIの画像を保持する（BASE64）。これがJsonに入っているので、コードが超肥大化している。
   しかも目がちかちかする。

   PowerFxはOnにしてはならない

   基本的にExcelから導入しました！使いやすいです！
   と書いてあるが
   お前らあほか？馬鹿なのか？
   No Codeと言いながらなぜExcelの関数の話をしだすのか？
   あれは素人にはコードやぞ。
   この辺で、なぜMicrosoftが救いがたい馬鹿しかおらず、ノーコードだ口先だけで何一つ意味が分かってないってなるんですね。
   そもそもローコードで計算する馬鹿はいないし、プレミアム機能なんて使うキチガイがいるかボケ。
   それはそれとして、PowerFXをOnにすると何がまずいのか。
   なんと内部コードが変わってしまう。

   PowerFx不使用

   UIAutomation.PopulateTextField.SimulatePopulateTextField TextField: appmask['Window \'Microsoft  ...  - Microsoft​ Edge\'']['Edit \'ユーザー名\''] Text: NewVarID Mode: UIAutomation.PopulateTextMode.Replace
   

   NewVarID Mode: UIAutomation.PopulateTextMode.Replace

   PowerFx使用

   UIAutomation.PopulateTextField.SimulatePopulateTextField TextField: appmask['Window \'Microsoft  ...  - Microsoft​ Edge\'']['Edit \'ユーザー名\''] Text: $fx'=NewVarID' Mode: UIAutomation.PopulateTextMode.Replace
   

   $fx'=NewVarID' Mode: UIAutomation.PopulateTextMode.Replace

   お分かりいただけるだろうか

   実はすべて変数を扱うとき$fxとつく
   そして
   テキストは
   $fx'text'
   $fx'"Text with space"'
   $fx'=0'
   となる
   ‘$fx'=NewVarID'‘ この部分もプロセスID（Long型）が入った変数 NewVarIDを代入するためfxがついている。また数字のため＝がいる。

   変数に厳密な型ごとの操作を要求しながらExcelライクですとかNoCodeとかMSは言っている

   まあ普通にラリってるんじゃないか。これ作った人。

   交換不能

   はっきりってFxをOnにする、あるいはオフにするというのは「破壊的変更」になるレベルで、本来はスィッチで気軽に切り替える性質のレベルではない。
   fxOnとOffのフローが混在すると、fxOnのフローからFxOffのフローへアクションをコピーすると、
   エラーが発生する。なぜなら、fxoffの場合、$fxが不要だからである。これは自動的に修正されない。
   この逆もエラーが発生する。なぜなら今度はFxがついていないためである。

   公式サイトにこのエラーについての記述がなく、原因の究明が難しい。

   Power Fx が無効化されたフローから有効化されたフローへ移行する場合、いくつかの違いに気付くかもしれません。 新しいデスクトップ フローを作成する際のエクスペリエンスを効率化するには、次の重要な概念に留意してください。

   Excel の数式と同じように、式言語として Power Fx を使用するデスクトップ フローは、0 (ゼロ) ベースのインデックスではなく、1 (一) ベースの配列インデックスを採用します。 たとえば、式 =Index(numbersArray, 1) は numbersArray アレイの最初の要素を返します。
   Power Fx を使用したデスクトップ フローでは、変数名の大文字と小文字が区別されます。 たとえば、NewVar は newVar とは異なります。
   デスクトップ フローで Power Fx が有効になっている場合、使用前に変数の初期化が必要です。 初期化されていない変数を Power Fx 式で使用しようとすると、エラーが発生します。
   If アクションは、単一の条件式を受け入れます。 以前は、複数のオペランドを受け入れていました。
   Power Fx が有効になっていないフローでは、不明なオブジェクト タイプを示す "一般値" という用語が使用されますが、Power Fx は厳密な型システムを中心に展開されます。 Power Fx が有効なフローでは、動的変数 (実行時に型または値を変更できる変数) と 動的値 (実行時に型またはスキーマが決定される値) が区別されます。 この違いをより深く理解するために、次の例を参考にしてください。 dynamicVariable は実行時にフォームが Numeric から Boolean 値に変更されますが、dynamicValue は実行時に型指定されていないオブジェクトであると判断され、実際のフォームは Custom object になります

   意味が分からない。「Power Fx が有効になっている場合、使用前に変数の初期化が必要です」ここでぼんやりとわかるレベルである。

   コードが見えない

   ローコードなどというが、ならば内部コードを書き換えるのは暴挙であろう。そしてfxを見落とすとアウトのため、見えていても修正が難しい。

   コードの差異が「局所的」ではなく「全体に散在する」ため修正が困難

   問題は、
   IF
   SET
   RunApplication
   Timeout
   Index / List / DataTable
   条件式
   変数参照
   といった フロー全域に差異がにじむ点にある。

   対策はコメントの義務化

   コメント必須

   しかし、どうしてもPowerFx使うときはコメントで注記し、なぜ必要なのか明らかにすることを義務化した方がよい。
   ついでに会社に辞表を提出した方がいい。それでも必要ならスィッチをオンにするくらいの覚悟がいる。

   推奨されるコメント例（思想）

   // このフローは Power Fx を使用している
   // 理由：複雑な条件式（従来 IF では不可）を1式で評価するため
   // 注意：Power Fx 無効フローへはコピー不可

   Qiitaの記事の修正：

   Power Fx を有効にすると、リスト系・データテーブル系のアクションが使えなくなる旨の記載がある
   https://qiita.com/EasyCording/items/51ad0966c5ea694ecf14
   https://qiita.com/Natsu_Summer/items/984dffdb4ca91ca624fa
   記事が存在している。
   2023年12月～2024年前半の初期仕様（プレビュー段階）では事実だったが、現在は使用できる。
   Microsoft Learn の公式ドキュメント（2024-11-07 更新）では、Power Fx 有効時でも Collect / Clear / ClearCollect / Patch などを使って、実質的にリスト操作を行うことが可能であることが明確に記載されている。
   また、Zenn や公式イベント資料（2024年末～2025年）では、**「UI から一部の旧来アクションが見えなくなるだけで、Power Fx 式を用いれば同等以上の操作は可能」**という整理に変わっている。

   機能が同等になっても、実務上は従来フローと互換的に扱えるものではない。
   そもそも NoCode 前提の環境において数式を記述すること自体が構造的に矛盾している。
   また、データベース操作についても、理解している人間であれば Power Fx よりもコードベースの手段の方が効率的である。
   さらに、Power Fx は「Excelライク」と説明されているが、実際にはセルベースの計算モデルではなく、変数と型を持つ式言語であり、Excelとは構造的に全く異なる。
   そして、Power Automate Desktop はノーコードを謳っているが、UI画像をバイナリ化されており、実際には巨大なJSONとバイナリを内部に抱えたコード生成ツールである。しかもその構造は公開されておらず、Power Fx の有効化によって式言語まで変化するため、実質的にデバッグ不能なブラックボックスとなる。
   つまりこのことは同じ作業をさせた場合、動作が遅く、しかもフロー単体の容量が巨大になることを意味するうえ、デバッグが実質的に不能となる。
   ただより高いものはないというが、NoCodeほどCodeのハードルが高いものはない。