みなさんはフローを作るときにどんなことを意識していますか？
SharePointリストの5000件問題を回避したり、Graph APIを勉強したり、慣れない関数をAIに書いてもらったりして、なんとか要件通りに動くフローを完成させることに必死ですよね。
ただ、もう一つ意識すべき重要なポイントがあります。
それは「フローは完成した後も動き続ける」ということです。
自動化するために作っているのですから当たり前なのですが、私たち開発者はそれを考慮した設計や運用方法を考えることをしばしば怠ってしまいます。
動き続けることを考慮されていない、つまり「持続可能でないフロー」は次のような問題を引き起こします。
- ちょっとしたエラーでしょっちゅう止まる
- エラー対応で結局開発者自身の業務効率が落ちる
- 周囲からも「使い物にならねえもの作りやがって。これなら無いほうがマシだよ」と思われる（かも）
- 改修するときに、アクションや関数が何のためどんな背景で今の形で実装されているのかわからなくなる
- 改修やアップデートで要らぬミスを発生させて余計に混乱を生む
- 開発者が休職・異動・退職した途端に動かなくなる
- フローの構造が他人に理解できないため、初期開発者がいなくなると誰も触れないパンドラの箱と化す
今回はこんなふうにならない、開発が完了した後のことを考えたサステナブル（持続可能）なフローを作るために、考えておきたいことをお伝えします。
普段は「なつぐれの業務効率化ログ」という個人ブログで、Power Platformに関する技術記事を投稿しています。
開発からIT管理者向けまで幅広く取り扱っていますので、こちらもぜひ読んでいただけると嬉しいです！
設計・開発編
1. 実行条件の構成とスコープでエラーを適切に処理する
これが一番大事です。 他の項目の実践が難しくても、これだけは最低限今日から取り入れてください。
実行条件の構成
新しいフローデザイナーでは、各アクションの「設定」タブにある「この後に実行する」のことを指します。
何も設定していないと、フロー内でいずれかのアクションで失敗すると、後続のアクションはすべてキャンセル（※）され、フロー全体が失敗したと判定されます。
※Apply to each（それぞれに適用する）とDo Until内でエラーが発生した場合は、指定された条件内のループ処理は継続し、ループ外の直後にあるアクション以降がキャンセルされます。
しかし、全部が全部問答無用で停止しては都合が悪いですし、フローの所有者以外に通知したい場合もあるはずです。
そんなときは、実行条件の構成に「失敗しました」にチェックを入れたアクションを直後に配置することで、成功と失敗で処理を分けたり、どんな結果になっても処理を継続させたりすることができます。
スコープ
アクションに実行条件の構成を設定するやり方だと、必ずアクション単位でその直後に実行条件を分岐させなくてはなりません。
そのため、エラー処理を実装するときによく使うのが「スコープ」です。
スコープは複数のアクションをまとめることができるアクションで、スコープ内のいずれかのアクションでエラーが発生した場合は、スコープ内の後続のアクションのみをスキップし、その直後に実行条件の構成が「失敗しました」になっている別のスコープでエラー処理を入れる、のような構成を作ることができます。
Power Automate公式でも「Try, Catch, and Finally Template」というテンプ
レートを公開しています。
- Tryスコープ: エラーが発生する可能性のある処理を配置
-
Catchスコープ: エラー発生時の処理を配置
- 実行条件は「失敗しました」にチェック
-
Finallyスコープ: エラーの有無に関わらず必ず実行したい処理を配置
- すべての実行条件にチェック
独自のエラー通知機能を実装する
Power Automateには標準機能として、フローが失敗したときに所有者へメール通知が届く仕組みがありますが、Outlookメールで届くので気づきづらいですし、即日うちではないので対応が遅れるというデメリットもあります。
そのため、CatchスコープでTeamsコネクタを使った独自の通知機能を実装しておくのがおすすめです。通知には以下の情報を含めると、トラブルシューティングがスムーズになります。
通知は以下くらい簡素にして、エラーの詳細はフローの実行結果で確認するのがいいと思います。
- フロー名
- 実行日時
- エラーが発生したアクション名
2. 並列処理を使う
並列分岐アクションは、実行時間を短縮するだけでなく、「止める必要がないところで止めない構成」を実現する上でも非常に有効です。
例：申請に基づくリソース作成処理
新規プロジェクトの申請を受けて、Teamsチームの作成とAsanaプロジェクトの作成を行うフローを考えてみましょう。
すべてのアクションを直列に繋いでしまうと、先に配置したアクション（例：Teamsチーム作成）が失敗した場合、後続のアクション（Asanaプロジェクト作成）は実行される前にキャンセルされてしまいます。しかし実際には、Teamsの作成が失敗してもAsanaプロジェクトは作成できるべきですし、逆も然りです。
この場合、並列分岐を使って2つの処理を独立させ、それぞれをスコープで囲んでエラーハンドリングを実装します。
※フローは説明用のイメージです。
3. アクションに適切な命名をする
フローの可読性と保守性を高める上で、アクション名は非常に重要です。私は個人的に**「自動挿入された名称 - 何をしているのか」という構成**で命名しています。
命名の具体例
複数の項目を取得 - 申請リストを全件取得SharePoint に HTTP 要求を送信します - ページ作成作成 - 配列をカンマで分割条件 - 承認者が部長以上かそれぞれに適用 - 承認者リスト
この命名規則のメリット
自動挿入されるアクション名（「複数の項目を取得」「作成」など）の後ろにさらに記述を足すと、冗長で野暮ったい印象を受けるかもしれません。
私が以下の2つの理由でこの命名規則を採用しています。
1. 開発者以外にもわかりやすい
フローを引き継ぐ人がPower Automateの経験が浅い場合でも、「何のアクションをどのような目的で使用しているか」が一目でわかります。
2. 同一コネクタの識別が容易
たまに同じコネクタに入力パラメータまで一緒のアクションが存在したりします。
そのため、アクション名を消してしまうといよいよ何のアクションかわからなくなってしまうんですよね。
特にPower Platformのコネクタに関するMicrosoft Learnは、アクション名やパラメータ名がフローデザイナー上の表記と異なっていることが多々あるので、アクション名は消さないほうが無難かなと思います。
3. フローデザイナー上での可読性が向上
これは当然ですが、フローを眺めていて「条件 2」「作成-copy」と表示されていたら何をしているのかさっぱりわかりません。
特にPower Automateはネストされたアクションの見通しが悪いので、アクションの名前を細かい粒度で記載しておくと、ある程度全体像が頭に入っている開発している最中でさえ、可読性の向上させてくれます。
命名時の注意点
- アクション名だけで説明しきれない複雑なロジックは、後述するメモ機能も併用しましょう。
- もしPower Automateを扱える社員がチーム内に複数人いる場合は、命名規則を統一しておいたほうがいいかもしれません。
4. メモ（コメント）を残す
各アクションの右上メニューから追加できる「メモ」機能も積極的に活用しましょう。
Power Automateの場合、よほど複雑なフローでない限り、別途ExcelやWordで大仰なドキュメントを作成する必要はありません。このメモ機能だけで十分なドキュメントとして機能します。
また、すべてのアクションにメモを残す必要はありません。
主に以下のような場合に書いておくと、他の開発者や未来の自分を助けられると思います。
メモに記載すべき内容
- アクション名で説明しきれないロジック：複雑な式や条件分岐の意図
- 実装した背景：「なぜこの方法を採用したのか」という設計判断の理由
- 期待される出力：特に複雑な関数を複数組み合わせた場合
- 既知の制約や注意点：「このAPIはクールダウン時間を設けないと高確率でエラーになる」など
- 将来の改善案：「将来的にはDataverseテーブルに移行予定」など
運用編
ここからはみんなが目を背けたくなる運用編です。
設計・開発がどれだけ優れていても、運用面での準備が不十分だといつかは崩壊します。
1. 共同所有者をあらかじめ追加しておく
フローの所有者が長期休職・異動・退職した場合に備えて、共同所有者を事前に追加しておくことは必須です。
「そのときになってから」では遅すぎます。
産休・育休や、円満退職なら、それが公表されてからでも十分間に合うかもしれません。
しかし、異動や病気療養などは突発的です。その段階では動いているフローの引き継ぎが後回しになる・忘れられるのは想像に難くないでしょう。
遅くとも、フローが実運用を開始する時点で共同所有者を追加しておくべきです。理想的には、開発段階から共同所有者を設定し、レビューやテストにも関与してもらうことで、複数人がフローの内容を理解している状態を作ることが望ましいです。
誰を共同所有者にするか問題
Power Automateの基礎知識を持っている人が他にチームや部署にいればいいですが、あなたが孤独なDX担当で他に任せられそうな人が思いつかないということもあると思います。
それでも一人で抱えておくのではなく、ひとまず異動や退職の可能性が低そうな信頼できる人を共同所有者にしてしまったほうがいいです。
フローの所有者が不在になった「孤立したフロー」の措置は、Power Platform管理者や環境のシステム管理者を通じて行う必要があります。
きちんとマニュアルが整備されていればいいですが、組織のIT部門がPower Platformのガバナンス管理のナレッジに乏しいと、孤立したフローを救い出すのに何週間もかかってしまう可能性もあります。
あとで後悔する前に、対策は事が起こりそうにないうちに取っておきましょう。
2. フローをソリューション化しておく
フローをソリューション内で管理することで、運用面で多くのメリットが得られます。
ソリューションフローの主なメリット
1. 主要な所有者の変更が可能
通常のフロー（非ソリューションフロー）では、作成者が自動的に所有者となり、所有者の変更ができません。一方、ソリューションフローでは主要な所有者を変更できます。
2. バージョン管理ができる
ソリューション化されたフローは、非ソリューションフローではできなかったバージョン管理ができるようになります。
編集中にどうしようもない変更をしてしまったときに、フローを気軽に過去のバージョンにロールバックできるので非常に便利です。
3. 関連リソースを一つのパッケージとして扱える
フローが他のフローやPower Appsアプリ、Dataverseテーブルと依存関係にあるとき、これらをソリューションとして一つのパッケージにまとめることで、関連性が明確になり、管理が容易になります。
4. 環境間の移行が容易
後述する環境分離戦略と組み合わせることで、開発環境で作成・テストしたフローを、ソリューションのエクスポート/インポート機能を使って本番環境に展開できます。手動でフローをコピーして設定し直す必要がなく、ミスも減少します。
3. 実稼働環境と開発環境を分ける（既定環境を使わない）
環境の分離は、開発者1人ではどうにもならない問題かもしれませんが、ぜひ知識として身につけ、IT部門に環境整備を働きかけてください。
なぜ環境分離が必要なのか
環境を分ける必要性は挙げるとキリがないですが、今回のテーマに関連する部分でいうと以下のリスクを回避するためです。
- 追加開発やバグ修正時: 本番環境で直接修正すると、テスト中に実際の業務データが影響を受けるリスクがある
- 大規模な仕様変更時: 同じ環境内でフローをコピーして対応すると、置き換え時に接続やパラメータの切り替えが発生して面倒かつミスの原因になる
他にも環境分離の必要性は以下の記事でも解説しています。
最低限の環境構成
開発環境と本番環境の2つは最低限用意しましょう。
-
開発環境（サンドボックス）
- 新機能の開発やテストを行う
- フロー・アプリ・テーブル等はアンマネージドソリューション化してから開発する
-
本番環境（実稼働）
- 本番運用中のフロー・アプリ・テーブルのみを置く
- 原則的に、開発環境からマネージドソリューションとしてインポートする
既定環境を使わない理由
Power Platformには「既定環境」が用意されていますが、本番環境として使用することは推奨されません。
本記事の主題ではないので詳細には解説しませんが、Microsoft曰く「既定環境を使うのはクレイジー」だそうです。
まとめ
持続可能なフローを意識して作るのは、最初は手間に感じるかもしれません。
しかし、フローが長期間にわたって安定稼働し、担当者が変わってもスムーズに引き継げる状態を作ることは、組織全体の生産性向上に直結します。
「とりあえず動けばいい」から「長く使い続けられる」フロー開発へ、今日からできることから始めていきましょう。