Power Automate、しんどすぎるので何がつらいのか整理した

まえがき

これまで、あまりPowerAutomateを触る機会がなかった。そういうツールは存在していると知ってはいたが、使ったことがなかったのだ。

きっかけは些細なことだった。毎週金曜日に社内向けのニュースレターを配信していて、その中に「その週、各部門から全社に展開された重要事項をまとめる」というコーナーがある。部下が担当してくれているのだが、各部門のメールを拾って整理する作業はそれなりに工数がかかる。AIも使えることだし、Power Automateで自動化すれば30分もあれば組めるだろう——そう思っていた。結果として、2時間近く溶かした。

AIが提示してくれた情報そのまま入力していけばうまくいくだろう……そう考えていたのが間違いだった。
AIはアクション名を英語で提示してくる。ところがPower Automateの日本語UIは英語での検索にほぼ対応していない。英語で示された項目から日本語名を予測して検索をかけ、それでも見つからず、ようやくたどり着いたと思ったら今度は結合と統合をミスっていた。「シンプルなことをやっているはずなのに、なぜここまで面倒なのか」という疑問が積み上がり、最後までやり切った後にこの記事を書くことにした。

できることは多い。OutlookもTeamsもSharePointもExcelも触れる。Microsoft 365で業務を回している組織なら、導入を検討したくなる理由はよく分かる。でも実際に触ってみると、しんどさの正体は機能不足ではなかった。小さな不親切が、いたるところに埋まっているのだ。しかもその不親切が、学習コストとして前向きに積み上がる種類ではない。「なるほど、こういう設計思想か」と腑に落ちるタイプの難しさではなく、なんでそんなところで転ばせるんだよという類のつまずきが、延々と続く。

1. アクション名がまず不親切

部品を探す段階で、すでにしんどい。英語の情報を参照しながら作ろうとすると、日本語UIでは名前が違う。しかもただの直訳でもなく、微妙にズレている。以下のあたりが、検索しても素直に引っかからない。

• Apply to each（それぞれに適用する）

• Compose（作成）

• Filter array（配列のフィルター処理）

• Initialize variable（変数を初期化する）

何をしたいかは分かっているのに、その部品にたどり着けないという状況が生まれる。ロジックを考える以前に、工具箱の中身を探すだけで時間を溶かす。

2. 表示名と参照名がズレる

これがPower Automateの最悪ポイントのひとつだと思う。画面上に見えているアクション名と、式の中で参照するときの名前が一致しないことがある。正確には、動的コンテンツ経由で挿入した参照はアクション名の変更に追従してくれるのだが、式を自分で書いた箇所は追従しない。古い名前のまま置き去りにされる。その結果何が起きるかというと、画面上にはちゃんと存在しているのに、保存すると「定義されていません」と怒られる。そこにあるのに、ないことにされる。見えている現実とシステムの認識がズレている状態で作業するのは、じわじわと体力を削られる。

3. 式なのか文字列なのか分かりにくい

Power Automateは「ただの文字列」「動的コンテンツ」「式」を厳密に区別している。そこまでは理解できる。問題は、UIがその差を体感的に分かるように作っていないことだ。`item()?['subject']`と入力したつもりが、式ではなくただの文字列として保存されることがある。後続の処理が全部崩れる。でも原因はロジックの間違いではなく、その欄が"式を入れる欄"に見えなかっただけだったりする。知らんがな、という気持ちになる。

4. エラーメッセージが親切そうで親切じゃない

「型が一致しません」「配列を入力してください」「無効な参照です」——エラー自体は出る。でも利用者が本当に知りたいのは、どのアクションの、どの欄が、どう間違っていて、何に直せばいいかだ。そこが最後まで言われない。診断の方向は合っているのに、治し方を教えてくれない。半端に頭のいい人の説明に似ていて、地味に腹が立つ。

5. 途中修正に弱い

Power Automateは、最初から全部きれいに設計された前提で動いている感じがある。でも現実の業務自動化はそんなにきれいじゃない。まず仮で作って、動かして、エラーが出て、名前を変えて、順番を入れ替えて、少しずつ直す——それが普通の進め方だ。なのにPower Automateは、途中で名前を変えたりアクションを差し替えたりすると急に機嫌を損ねる。古い参照が残り、見た目は直っているのに保存で転ぶ。試行錯誤しながら作る人間に、このツールは冷たい。

6. デバッグが気持ちよくない

何が起きているかを確認するには、実行結果を一個ずつ開いて、出力を見て、どこでデータの形が崩れているかを追う必要がある。今回実際に遭遇したのは、受信日時が文字列扱いになっていた、`from`が文字列のこともオブジェクトのこともあった、キー名に余計な改行が入っていた、参照名がズレていた——といった問題群で、これは実データを見るまで分からない類のものだ。なのに、その確認の体験がまったくなめらかじゃない。デバッグは本来、問題を潰していく前向きな作業のはずなのに、やっていて消耗するほうに振れていく。

7. 「ノーコード」の顔をしているのが逆につらい

Power Automateは、見た目だけなら「ノーコードでできますよ」という顔をしている。でも実際にはかなり早い段階で、配列、オブジェクト、文字列と式の違い、参照名、型、条件式——といった概念の理解が必要になる。要するに、普通にローコードツールだ。ローコードなのが悪いのではない。問題は、そこまでコード的な理解を要求するのに、UIが最後まで「やさしい道具ですよ」という顔をし続けることだ。ノーコードの仮面をかぶった、かなり気難しいローコードツール——触ってみれば分かる。

それでも使われる理由は分かる

公平に言っておくと、Power Automateが選ばれる理由はある。Microsoft 365を基盤にしている組織では、OutlookやTeamsやSharePointとシームレスにつながるのは純粋に強い。すでにそこに社内インフラがあるなら、候補に上がるのは当然だ。ただ、それと使いやすさは別の話である。選ばれやすいことと、優れていることは同義ではない。

ついでもう一つしんどかった点を言えば、PowerAutomateでMicrosoft Copilotに色々と尋ねられるが、驚くほど全く役に立たなかった点だ。動かない理由をCopilotに尋ねて修正をかけても、ますますおかしな方向に修正されていく。Copilotは使わず、ChatGPTやClaudeに確認しながら進める方が賢明だ。

結論

Power Automateがしんどいのは、難しいからではない。細かい不親切の積み重ねが、あまりにも多いからだ。名前が見つからない、参照がズレる、式と文字列の境界が分かりにくい、エラーが遠回し、途中修正に弱い、デバッグが気持ちよくない——この積み重ねで、利用者は「自動化している感覚」より先に、気難しい道具の機嫌をうかがっている感覚になる。業務を楽にしたいだけなのに、まず自分の精神衛生を管理しなければいけない。そこがしんどい。

Power Automateに本当に必要なのは、機能追加より先にこの3つだと思う。英語名でも日本語名でも引ける検索、表示名と参照名のズレをなくすこと、エラー時に「どこをどう直せばよいか」まで示すこと。これだけでも、だいぶ違うはずだ。