CWE(Client Working Engineering)部の戸田です。
今回はPowerAutomateのバグ検証結果を紹介します。
エクセルの作業をPowerAutomateで自動化中にとあるバグに遭遇し、そのバグの挙動が気になったため動作検証を行いました。
最後にはこのバグのワークアラウンドも紹介しているので、ぜひ最後まで御覧ください。
バグ内容
まずは実際にどのようなバグが起こったのか、簡易的な再現フローにて紹介します。
動作させるフローはこちら。
テンプレートとなるエクセルファイルを複製し、そのファイル内のテーブルに行を追加していくというフローになります。
上記のフローを実行することで得られる想定の動作結果はこちら。
No、タイトルが入力され、HYPERLINK関数でJSONに格納されていたパスの値がリンク化されています。
しかし、実際にフローを実行した際の動作結果はこちらになりました。
Noとタイトルの列は正常に処理されていますが、リンクの列が赤吹き出しで書かれている異常が起こっています。
上書きされているのはフローの誤りかなと思ったのですが、空白になるはずの1行目にもリンクが挿入されているのは不可解です。
ということで、今回はこの摩訶不思議なバグの動作について検証していきます。
前提
検証をしていく前に動作されているフローについて前提条件を紹介しておきます。
フローは正常
動作フローに問題があるのではなく、あくまでPowerAutomateのバグとなります。
以下は動作させている変数の設定と行の追加のフローになります。
ログも正常
フローだけではなんとも言えない部分があるので、動作結果のログも紹介しておきます。
以下はループ処理のログになります。
ログも見ると明確ですが、想定通りループが処理されているのがわかります。
ただログを見てもどのタイミングでリンク内容が上書きされているのかはわかりませんでした。
そのため、おそらく上記のログの処理がされている時に同時に上書きされている可能性が高いと思われます。
検証① ~他のエクセル関数での発生有無~
では検証を行っていきます。
まずはこのバグがHYPERLINK関数のみで発生するバグであるのか、それとも他の関数でも発生するのかを確かめていきます。
以下のフローで検証します。
今回はHYPERLINK関数の代用として、同じく文字列同士を結合するCONCAT関数で検証してみましょう。
想定しているフロー実行結果は以下の通りです。
それぞれの行ごとにNoとタイトルと同じ文字列を結合したものがリンク列に表示されます。
では実際に動作させた結果を見てみましょう。
まさかのHYPERLINK関数と全く同じ事象が発生しました。
ここでの紹介は省きますが、他にも文字列をベタ書きしたエクセル関数での検証を行ってみましたが、同じ事象が発生してしまいました。
ということでこのバグはHYPERLINK関数だけでなく、文字列を扱うエクセル関数を挿入した場合に発生するバグということが判明しました。
意外とPowerAutomateでエクセル編集をする場合、致命的なバグのようです。
検証② ~関数の要素をセル名と文字列で混合させた場合の事象有無~
次は関数の要素の指定の仕方を変更して検証していきます。
ここでは文字列をベタ書きしたものと、値をセル名で指定したものを結合してみます。
想定される動作結果は以下のとおりです。
検証①と同じ結果ではありますが、セルに入力されている関数の内容が少し違います。
では実際の動作結果も見てみましょう。
少しおもしろい結果になりました。
セル名で表記した部分に関しては上書きされずに処理されていますが、ベタ書きした部分に関しては上書きされています。
この結果から考えるに、関数内で文字列をベタ書きで挿入するとバグが発生する可能性が高そうですね。
検証③ 関数の要素をセル名のみの場合の発生有無
検証②での仮説が合っているかを検証していきましょう。
先程はセル名と文字列ベタ張りの混合でしたが、ここではセル名のみで検証していきます。
実行フローは以下の通りです。
生成した行番号を用いて各セル名を明示させています。
想定の動作結果は以下の通りです。
検証②と同じ表記ですが、セル名の関数になっていることと、一番上の空白の行に処理が入らないことが想定となります。
では実際の実行結果を見てみましょう。
挿入された値は上書きが発生せず想定通りの値になりました。
しかし、空白の行に対して上書きがされてしまったので、バグ自体は発生してしまっていると見なされます。
ちなみにループの初動の行番号の値は「A3:B3」となっており、実際の結果の画像のような「A2:B2」の値は存在していません。
どのようなタイミングで、どのようなプロセスでバグが発生しているのか、検証していくほど謎が深まるハグでした。
ワークアラウンド
ここまでバグ回避に向けて検証してきましたが、フローや関数の表記による回避がなかなか難しいという結論に達しました。
ではこのバグは回避できないのでしょうか。
その答えは、Noです。
実はこのバグは編集するテーブルの形式をとある形にしておけば、事象を避けることができます。
その方法とは、以下のようにエクセル関数を記入するセルの上部のセルに文字列を入力することです。
このバグ自体が、エクセル関数を挿入するセルの上部に文字列がないと発生する事象のようで、そのため上記に対応をするだけで回避できるのです。
実際にこのテーブルの形式でフローを動作させた結果がこちらです。
あれだけ苦労していたバグがまるで無かったかのような挙動で回避できています。
もちろんベタ書きの文字列の上書きも、空白部分への関数挿入も同時に回避することが可能です。
ただこの文字列が入った状態のテーブルを完成とするのはあまりにも不格好ですよね。
そこでフローのループ後に、回避文字列が入っている行を削除する工程を入れておくと良いでしょう。
またループする要素の1つ目は行の更新、2つ目以降は行の追加に条件分岐させることでもテーブルの整形が可能ですね。
まとめ
ここまでお読みいただきありがとうございました。
今回はPowerAutomateでのエクセルの行の追加時に発生するバグの検証結果を紹介していきました。
最後にバグの事象や、検証結果などをおさらいしておきます。
- HYPERLINK関数だけでなく、ほぼすべてのエクセル関数を挿入する時に発生するバグである。
- ベタ書きした文字列要素は、必ず一番最後に処理した値に上書きされてしまう。
- A1やB2などのセル名を要素とした場合は、上書き事象は発生しない。
- 要素をすべてセル名にした場合でも、テーブルの最上部が空白の場合、同じエクセル関数が挿入されてしまう。
- エクセル関数を挿入する上部の行に文字列が入っていれば回避が可能。
またPowerAutomateの不可解なバグや面白いナレッジがあれば紹介していきます。
