Power Automate vs Graph API — 業務自動化、いつどちらを使うか
読了 5分
Microsoft 365 環境で「この業務を自動化したい」となると、道が 2 つ現れます。クリックでフローを組み立てる Power Automate、そして実務入門シリーズで扱ってきた Graph API の直接呼び出しです。同じ目的地に着く別の交通手段なので、「どちらが優れているか」という問いは成立せず、「この作業にはどちらが合うか」だけが成立します。この記事ではその判断基準を整理します。
2 つの道具の正体 #
- Power Automate: トリガー(メール到着、フォーム送信、指定時刻)とアクション(行の追加、承認依頼、メッセージ送信)をコネクタでつなぎ合わせるローコード自動化サービスです。コネクタは Microsoft 365 全般はもちろん、サードパーティの SaaS まで数百種類以上提供されています。内部的には、多くのコネクタが結局 Graph API を呼んでいます。
- Graph API: 同じデータと機能をコードから直接呼び出す REST API です。言語の制約がなく、アプリ登録と権限管理(実務入門 #2)を自分で行います。
つまり両者の関係は競争というより包装の違いです。Power Automate は Graph(と各サービスの API)を市民開発者が使えるように包んだ層であり、その包装がそのまま強みでもあり限界でもあります。
Power Automate が勝つ場所 #
- トリガーベースの軽いフロー: 「フォームが送信されたら Excel に行を追加して Teams に通知」のようなフローは 15 分で作れます。同じものをコードでやるなら、Webhook の受信部、認証、デプロイのインフラから立ち上げることになります。
- 承認フロー: 承認依頼カードの送信、応答待ち、結果の分岐が組み込み機能です。人の決裁が挟まる自動化では、この組み込み承認ひとつが開発数日分を肩代わりします。
- 現場主導(市民開発): 部門の担当者が自分の業務を自分で自動化できること自体が価値です。IT チームのバックログを経由しません。
- 接続の広さ: サードパーティ SaaS まで含むコネクタのエコシステムは、個々の API をいちいち学ぶコストをなくしてくれます。
Graph API が勝つ場所 #
- ボリュームと性能: 数万件の処理、並列呼び出し、バッチリクエスト、スロットリング対応(実務入門 #7)はコードの領域です。Power Automate はフロー実行回数や API 呼び出し量に上限と性能の制約があり、大量処理には向きません。
- 複雑なロジック: 条件が何段にもネストしデータ変換が多いフローは、ローコードのキャンバス上ではかえって読みにくくなります。画面いっぱいのネストした条件ブロックは、コード 20 行より保守が大変です。
- エンジニアリングのライフサイクル: バージョン管理、コードレビュー、テスト、CI/CD、環境分離。自動化が「部門の便利ツール」を超えて「運用システム」になった瞬間これらが必要になり、すべてコード側が圧倒的に成熟しています。
- きめ細かい権限統制: アプリ権限の範囲を最小に設計して監査する統制は、自前のアプリ登録のほうが明確です。Power Automate の接続は作った人のアカウント権限で動くことが多く、その人の退職・異動がフローの障害につながるという古典的な事故パターンがあります。
隠れた変数 — ライセンスと所有権 #
技術比較だけで決めると、2 つの伏兵に出会います。
- プレミアムコネクタとライセンス: 基本の Microsoft 365 ライセンスに含まれる標準コネクタと違い、HTTP コネクタを含むプレミアムコネクタ・機能には別途 Power Automate のライセンスが必要です。「無料だと思って作ったのに、広げようとしたら有料」になるのがここです。一方、Graph API の呼び出し自体に別途課金はありません(インフラのコストは別)。
- 所有権と寿命: 個人アカウントに紐付いたフローは、その人と一緒に消えます。部門業務に使われるフローは共有所有権・サービスアカウントで作って一覧を管理すべきで、これができない組織では「誰も知らないフローが突然止まる」事件が繰り返されます。
実務の分業基準 — 混ぜて使うのが正解です #
整理すると判断軸は 3 つです。ボリューム(件数・頻度)、複雑さ(ロジック・変換)、寿命(一時的な便利ツールか運用システムか)。 3 つとも低ければ Power Automate、ひとつでも高ければ Graph に傾けます。
| 状況 | 推奨 |
|---|---|
| フォーム送信 → 記録 → 通知、1 日数十件 | Power Automate |
| 人の承認が挟まる決裁系フロー | Power Automate(組み込み承認) |
| 数千〜数万件の一括処理、夜間バッチ | Graph API |
| システム間連携、複雑な変換・分岐 | Graph API |
| 組織標準の自動化(オンボーディングなどの運用システム) | Graph API + CI/CD |
そしてこの 2 つはつなげられます。よくあるハイブリッドが、重い処理は Graph を使うバックエンド(Azure Functions など)が担い、トリガーと人とのやり取り(承認、通知)は Power Automate が担う構造です。それぞれ得意な場所に立たせればよいのです。
まとめ #
- Power Automate は Graph を含む API 群をローコードで包んだ層です。競争関係ではなく包装の違いです。
- トリガーベースの軽いフロー、組み込み承認、現場主導の自動化は Power Automate が速くて安いです。
- ボリューム、複雑なロジック、バージョン管理・CI/CD、きめ細かい権限統制が必要になった瞬間、Graph API の出番です。
- プレミアムコネクタのライセンスと個人アカウント依存という 2 つの伏兵を、設計段階で確認すべきです。
- 判断軸はボリューム・複雑さ・寿命の 3 つで、トリガー・承認は Power Automate + 重い処理は Graph バックエンドというハイブリッドが実務の標準です。