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 行を超えるか
エラーハンドリング（リトライ、ロールバック、通知）が肥大化したら、それは独立した責務だ。子フロー化して、呼び出し元はトリガーと正常系だけに絞る。
これは関数を切り出すのと同じ感覚で、フロー設計でも有効に効く。
基準 3：呼び出し元の業務文脈が 2 つ以上あるか
「経理部の月次処理」と「人事部の異動処理」の両方から、同じ承認ロジックを呼ぶ——この瞬間、承認ロジックは子フロー化する。
業務文脈が複数ある処理は、必ず仕様変更の方向がぶつかる。1 本に直書きしておくと、片方の都合でもう片方が壊れる。
3 つすべて満たす必要はない。1 つでも該当すれば子フロー化を検討、2 つ以上なら即座に切り出す——この粒度で運用すると、過剰設計と密結合の両方を回避できる。
データ受け渡しで踏みやすい 3 つの罠
子フロー化したあと、親→子のデータ受け渡しで詰まるケースは多い。設計時点で次の 3 つを潰しておく。
罠 1：JSON オブジェクトを生のまま渡す
「フローの実行」アクションの入力で、複雑な JSON をそのまま受け渡すと、スキーマ変更のたびに親子両方で型エラーが出る。
プリミティブ型（string、int、bool）に分解して渡すか、どうしても構造を保ちたい場合は受け側でスキーマ検証を 1 アクション挟む。
罠 2：子フロー側で接続情報をハードコードする
子フローの中で SharePoint サイト URL や Dataverse 環境を直書きすると、テナント横展開のときに全部書き換える羽目になる。
環境変数（Environment Variables：Solution に紐づく設定値の外出し機構）経由で参照する。これだけで、Dev / Test / Prod の差し替えが Solution インポート時に完結する。
罠 3：戻り値の型を「Respond to a PowerApp or flow」で曖昧にしない
子フローの応答アクションで、出力スキーマを明示しないと、呼び出し元は any 型相当で受け取り、後続のアクションで実行時エラーが出る。
出力変数の型を明示し、null 許容かどうかも宣言する。この一手で、デバッグ時間が体感で半分になる。
個人 PC で素振りできるか、企業テナントでしか試せないか
ここで一度立ち止まる。今書いた基準・罠は、貸与 PC の中だけで素振りできるか？
実務上、難しい。本番テナントは検証用フローを増やしにくく、Dev 環境があっても権限と監査の都合で「ちょっと試す」ができない場面が多い。
M365 Developer Tenant（Microsoft 365 Developer Program で発行される、Power Platform / Dataverse / Power Automate がフルに使える個人検証環境）を個人 PC 側に持っておくと、ここが解決する。Microsoft 公式の無料制度であり、グレーゾーンではない。
個人 PC 側で蓄積すべき疎結合化の資産は、おおよそこうだ。
- 子フロー化の判定チェックリスト（上記 3 基準のテンプレート）
- 環境変数を使った Solution の雛形（Dev/Test/Prod 切り替え定義込み）
- データ受け渡しスキーマのサンプル（JSON 分解パターン / Respond スキーマ定義）
- エラーハンドリング子フローのテンプレート（リトライ / 通知 / ロールバック）
新しい案件が来たら、個人テナントで 30 分プロトタイプを組み、判断軸が機能することを確認してから顧客環境に持ち込む。これを習慣化すると、貸与 PC にログインしている時間そのものが、判断時間ではなく実装時間に絞り込まれる。
→ 顧客環境と個人 PC の境界設計そのものを掘り下げたい場合：顧客環境に拘束された時間は、あなたの資産にならない
設計時に詰めておく 4 つのチェック
子フロー化の境界線が決まったら、運用に入る前に次の 4 つを必ず詰める。これを飛ばすと、3 ヶ月後に密結合フローと同じコスト構造に戻る。
| # | チェック項目 | 飛ばした場合の症状 |
|---|---|---|
| 1 | Solution（ソリューション：ALM 単位の論理パッケージ）に必ず格納 | マイフロー直下で開発し、横展開時に手作業移植が発生 |
| 2 | 環境変数で接続情報を外出し | テナント切り替えのたびに子フロー全数を再編集 |
| 3 | 子フローごとに単体テスト手順を定義 | 親フロー経由でしかテストできず、エラー切り分け不能 |
| 4 | 命名規則を Solution 単位で固定（例：cf_承認_共通） | 子フローが 20 本を超えたあたりで誰も探せなくなる |
特に 1 と 2 は ALM（Application Lifecycle Management：アプリのライフサイクル管理）の最低ライン。Solution を使わずに本番環境で子フローを運用するのは、設計図なしに建てた建物を増築し続けるのと同じで、3 件目の案件で必ず崩れる。
まとめ
Power Automate の疎結合化は、機能ではなく変更コストの単位で判断する設計だ。
「3 ヶ月後に呼び出し元が増えるか」「例外処理が 5 行を超えるか」「業務文脈が 2 つ以上あるか」——この 3 つで子フロー化の境界線を決め、データ受け渡しの 3 つの罠を潰し、Solution と環境変数で ALM の最低ラインを守る。
これだけで、変更コストは線形から定数オーダーに落ちる。
次の一歩：手元の本番フローを 1 本選び、上記 3 基準に照らして「子フロー化候補のアクション群」を洗い出す。30 分で終わる。
検証環境の用意：M365 Developer Program の無料登録から始める。個人 PC 側に検証テナントが手に入る。
関連スライド：[Power Platform 子フロー化チェックリスト 標準資料]（リンク予定箇所）
関連主題：Power Automate と Logic Apps の選定（3 年後の保守者を判断軸にしたツール選定主題）
メンテナンス情報
最終更新日：2026-05-09
次回見直しトリガー：(a) Power Automate 子フロー機能の API / 制限変更、(b) 環境変数の挙動変更（特に Dataverse 接続周り）、(c) Solution / Pipeline の GA 移行・課金体系変更、(d) M365 Developer Program の提供条件変更。いずれか発生時、または半年〜1 年で再点検。