Power Automate

Power Automate のフローは、組み始めると一瞬で密結合に倒れる。 気づくと、1 アクション直すたびに別フローが連鎖で壊れ、変更コストが案件数に比例して線形に膨らむ。 結論を先に置く。「この処理ブロックは、別フローから呼ばれる可能性が 3 ヶ月以内に出るか」——この一問で、子フロー化の境界線はおおむね片付く。 そして、判断を素振りする場所は貸与 PC ではなく、個人 PC 側の M365 Developer Tenant（Microsoft 公式の無料開発テナント）に置くのが速い。 なぜ「とりあえず 1 本のフロー」が線形コストになるのか 新規依頼が来るたびに、トリガー直下に分岐とアクションを直書きしていく。これが密結合フローの典型的な作り方だ。動く。最初は動く。 だが、3 ヶ月後に同じパターンを別テナント・別部門で再利用しようとした瞬間、コピペ + 微修正の往復が始まる。 観点 密結合（1 本フロー直書き） 疎結合（子フロー + 環境変数） 同一パターンを別案件に転用するコスト 案件数に比例（線形 O(N)） 初回設計後はほぼ定数（O(1)） 1 アクション仕様変更の影響範囲 全フローを 1 本ずつ手修正 子フローを 1 箇所修正で完結 単体テストの実施可否 トリガーごと走らせる必要あり 子フロー単独で「フローの実行」から検証可能 認証情報の差し替え コネクション参照を全フロー触る 環境変数 1 箇所の差し替えで完了 機能比較表ではなく、3 ヶ月後の自分の手数で測るのが、この判断の正しい単位だ。 「動くかどうか」ではなく、「変更が来たときに、いくつのフローを開く必要があるか」を見る。 子フロー化の境界線：3 つの判定基準 子フロー（Child Flow：別フローから呼び出される再利用可能なフロー単位）を切る基準は、機能ではなく呼び出し元の数と寿命で決まる。次の 3 つで判定する。 基準 1：再利用予定が 3 ヶ月以内に 2 件以上見えているか 「いつか使うかも」では切らない。具体的に「次の案件で同じパターンを使う」「同テナント内の別部門に展開する」見通しがあるときだけ、子フロー化する。 予定なき抽象化は、保守すべき子フローの数だけ増やして終わる。 基準 2：例外処理ロジックが 5 行を超えるか エラーハンドリング（リトライ、ロールバック、通知）が肥大化したら、それは独立した責務だ。子フロー化して、呼び出し元はトリガーと正常系だけに絞る。 これは関数を切り出すのと同じ感覚で、フロー設計でも有効に効く。 ...