Power Automate と Logic Apps の使い分けは、機能比較表を眺めるほど判断が遅くなる。
結論は単純で、**「3年後にこれを誰が触っているか」**が決まれば、ツールも決まる。
業務部門が3年後も自分で触る → Power Automate
3年後の保守オーナーが見えない → Logic Apps
これだけで、9割の判断は片付く。
なぜ機能比較表では決められないか
両者の機能比較は、調べれば10行でも20行でも書ける。だが、機能はどちらでも8割重なっている。残りの2割の違いは、現場のほとんどで誤差だ。
決定的に違うのは、運用の主語だ。
| 観点 | Power Automate | Logic Apps |
|---|---|---|
| 運用の主語 | 業務部門 | IT/インフラ部門 |
| ライセンス起点 | M365 ユーザー / Premium | Azure サブスクリプション |
| 統制と監査 | Power Platform 管理センター + Purview | Azure Monitor + Defender for Cloud |
Power Platform の本質は「業務部門が自分で直せる」ことであり、その前提が崩れた瞬間、Power Automate を選ぶ理由は半分消える。
逆に、IT 部門が SLA を持って運用する世界に Power Automate を置くと、Premium ライセンス費用と運用統制の不整合で、3年後に必ず揉める。
ツール選定とは、3年後の組織図を予想する作業だ。
中規模・部門横断のときだけ迷う
判断が割れるのは、たとえばこういうケース。
- 経理部が起点だが、人事と情シスにもまたがる承認ワークフロー
- 月数万件のトランザクション
- データソースが Dataverse + SharePoint + 外部 SaaS API
このとき、Power Automate Premium で攻めるか、Logic Apps Standard で攻めるか。
判断軸はやはり主語だ。
- 3年後にこのワークフローを触る人物を、名前と顔で想像できる → Power Automate でよい
- 3年後の保守オーナーが「異動でいなくなる」「制度が変わる」「組織再編で消える」のいずれかが視野に入る → Logic Apps に逃がす
ローコードはオーナーの顔が見える範囲でしか機能しない。これは原則だ。
設計時に必ず詰める5つのチェック
どちらを選んでも、以下5つは設計時点で必ず詰める。これを飛ばすと、3年後に必ずコストか障害か監査でしっぺ返しが来る。
1. 環境戦略（Dev / Test / Prod）
Power Automate なら Solution（ソリューション）を必ず使う。マイフローのまま開発してはいけない。
Logic Apps なら ARM テンプレート / Bicep で IaC 化する。ポータルでの直接編集は禁忌。
これは ALM（Application Lifecycle Management：アプリのライフサイクル管理）の最低ライン。本番環境で直接編集するのは「サーバー本番機にコードを直書きする」のと同じだ。にもかかわらず、現場の8割が Solution を使わずに本番デプロイしている。
2. 認証情報の取り扱い
接続情報は環境変数（Environment Variables）または Key Vault に逃がす。コネクション参照を埋め込んだまま deploy しない。
3. エラーハンドリングの3パターン
Power Automate なら「Configure run after」、Logic Apps なら「runAfter」設定で、最低3分岐を設計する。
- リトライで回復可能（一時的なネットワーク障害）
- リトライしても無駄（認証失敗、データ不整合）
- 人間判断が必要（ビジネスルール例外）
「失敗したらメール飛ばして終わり」は運用が破綻する。
4. 監査ログの粒度
GDPR / 個人情報保護法 / SOX対応が絡むなら、Purview に統合するか、Logic Apps なら Diagnostic Settings で Log Analytics に流す。
何を / どれくらいの期間 / 誰がアクセスできるかまで設計する。「ログは標準で取れています」では監査人を納得させられない。
5. コストの可視化
Power Automate Premium は per user / per flow で課金が変わる。Logic Apps は実行回数 + コネクタ呼び出しで課金される。
3年分の月次コスト試算をスプレッドシートで明示しておく。これがないと、3年後に必ず「なぜこんなにコストが膨らんだ」と揉める。
ところで、この5つを貸与PCの上で検証できるか
ここまで5つのチェックを書いた。
ただ、実際にこれらを触りながら学ぶには、貸与PC環境では無理がある。
たとえば Solution と Pipeline を組み合わせた ALM の挙動を、新しい案件のたびにゼロから試行錯誤するのは、時間の浪費だ。一度作ったテンプレートを、案件横断で使い回せる場所が必要になる。
Microsoft 365 Developer Program は、月額無料で Power Platform / Dataverse / Power Automate がフルに使える検証環境を提供している。Microsoft 公式の制度であり、グレーゾーンではない。
個人PC側にこの検証環境を構築し、過去の設計テンプレートを蓄積していくのが、最短のラーニングカーブになる。
蓄積する資産は、たとえばこうだ：
- ALM の Solution 雛形（Dev/Test/Prod の環境変数定義込み）
- エラーハンドリングの3パターンテンプレート
- 監査ログ統合の Bicep スニペット
- コスト試算用のスプレッドシート
新しい案件が来たら、個人テナントで30分プロトタイプを作る。動くものを確認してから、設計書とソリューションファイルを成果物として顧客環境に持ち込む。
顧客側エンジニアは、それを読み、検証し、本番デプロイする。
顧客貸与PCにログインする時間は、最小化できる。
これは契約上きちんと整理する必要がある。NDA、業務委託契約の条項、機密データの取り扱い——詰めるべき論点は多いが、整理さえつけば、運用は成立する。
3年後、この働き方が「普通」になっている可能性は、低くない。
まとめ
Power Automate vs Logic Apps の議論は、機能比較に終始しがちだが、本質は「3年後に誰が触るか」というオーナーシップの問題に尽きる。
そして、その判断を速く・正確に・横展開可能な形で出すためには、貸与PC環境だけでは足りない。
個人PC側に検証環境とテンプレ群を持つことが、これからのアーキテクト級フリーランスの基礎装備になる。
次の一歩：Microsoft 365 Developer Program の無料登録から始める。検証用テナントが手に入る。
詳細スライド：[Power Platform ALM 環境戦略 標準資料]（リンク予定箇所）
契約交渉のポイント：[個人PC利用を契約に明記する条項例]（リンク予定箇所）
関連記事：Power Automate の疎結合化、変更コストを線形から定数に落とす判断軸