1. はじめに
-
本記事のゴール
- 「Functions と Automation、どっちを選べばいいか？」を判断できるようになること
-
結論の先出し（ざっくり）
- イベントドリブンなアプリロジック → Azure Functions
- スクリプトベースの運用自動化・ハイブリッド構成 → Azure Automation
2. なぜこの記事を書こうと思ったか（背景）
ある案件で、Logic Apps から Azure Automation の Runbook を呼び出すフローを作っていました。
運用タスクを自動化する目的で、Azure Automation のアクションを使っていたのですが、レビューのタイミングでこんな指摘を受けました。
「これ、Azure Functions じゃダメなんですか？」
たしかに言われてみれば、
- Logic Apps → Azure Automation で実装するパターン
- Logic Apps → Azure Functions で実装するパターン
どちらでも実現できそうなケースが多く、「どこからどこまでを Automation に任せて、どこからを Functions にするのが良いのか？」という線引きが、自分の中で言語化しきれていませんでした。
そこで一度、
- Azure Functions と Azure Automation の違いを整理し直す
- 「どんなシナリオならどっちを選ぶのか？」を自分なりにパターン化する
という目的でまとめてみることにしました。
3. Azure Functions / Azure Automation のざっくりおさらい
Azure Functions
-
特徴
- サーバーレスな「関数」をデプロイして実行
- HTTP, Timer, Queue, EventHub など、豊富なトリガー
-
主な用途
- Web API
- イベントドリブン処理（Queue, EventHub, Blob トリガー等）
Azure Automation
-
特徴
- PowerShell / Python の Runbook をジョブとして実行
- スケジュール実行・手動実行・Webhook 起動など
-
主な用途
- Azure VM の起動/停止、タグ付け、リソース整理
- ログの定期集計・レポート出力
- ハイブリッド Worker 経由でオンプレサーバー操作
4. Azure Functions vs Azure Automation 比較表
それぞれの機能を比較してみました。
表中の ⭐ マークは、私が現場で使っていて「ここが強みだな」と感じたポイントです。
| 観点 | Azure Functions | Azure Automation |
|---|---|---|
| 開発言語 | C#, JavaScript, Python など | PowerShell, Python |
| 主なトリガー | ⭐HTTP、Timer、Queue、EventHub、Service Bus など | スケジュール、Webhook、他サービスからのジョブ起動 |
| スケーリング | ⭐イベント量に応じて自動スケール | 不可 |
| 実行環境 | Azure（App Service基盤） | Azure Automation アカウント＋（必要なら）ハイブリッド Worker |
| ハイブリッド実行（オンプレ等） | 基本的に不可（工夫は必要） | ⭐ハイブリッド Runbook Worker でオンプレ/他クラウドで実行可能 |
| Azure Portal での編集／即時実行 | .NET Isolated では不可能 | ポータル上で Runbook を直接編集してその場でテスト／実行しやすい |
| CI/CD | ⭐非常にやりやすい（GitHub Actions / Azure Pipelines 等） | ソース管理機能にて可能 |
| ジョブ管理／履歴確認 | Azure Monitor / Application Insights で確認 | ポータルからジョブ履歴・出力を GUI で確認 |
5. ⭐ を付けたポイントをもう少し詳しく
ここからは、比較表の中で ⭐ を付けたポイントを絞って深掘りしていきます。
-
Functions 側の ⭐
- 豊富なトリガー（HTTP / Timer / Queue / EventHub など）
- イベント量に応じたスケール
- CI/CD
-
Automation 側の ⭐
- ハイブリッド Runbook Worker によるオンプレ／他クラウド実行
Functions 側の強み
1. 豊富なトリガー
Azure Functions の最大の強みは、豊富なトリガーが準備されているため、あらゆる要件に対応できる点です。
例えば「Blob ストレージに画像がアップロードされたらリサイズする」という要件があった場合、Functions なら BlobTrigger を使うだけで、ファイルが置かれた瞬間に処理が走ります。
一方、Automation で同じことをやろうとすると、
- 定期的に Blob をポーリングする Runbook を書く
または - Logic Apps → Automation という連携構成を組む
といった形になり、どうしてもリアルタイムでの対応がしづらいのと、構成が複雑になりがちです。
2. イベント量に応じた自動スケール
「1 分間に 1 万件のリクエストが来る」といったスパイクアクセスがある場合、Functions は自動でインスタンスを増やして並列処理してくれます。
Automation は基本的にジョブキューに積んで順次実行していく仕組みなので、
- 「大量のイベントを一気にさばきたい」
- 「時間内に処理を終わらせたい」
といった要件に対しては、Functions のほうが圧倒的に向いていると言えます。
3. CI/CD と開発者体験
Functions は VS Code や Visual Studio などのエディタで開発し、GitHub にプッシュしたら GitHub Actions でビルド・デプロイ、という モダンなアプリ開発フローにしっかり乗せられます。
Automation にもソース管理機能で Git 連携はありますが、
- ローカルでのデバッグ実行
- 単体テスト
- ライブラリ管理
といった開発体験の面では、やはり Functions に軍配が上がります。
Automation 側の強み
ネットワークの壁を超える Hybrid Runbook Worker
私が Automation を選ぶ最大の理由が、Hybrid Runbook Worker の存在です。
通常、PaaS からオンプレミスのサーバーや閉域網（VNET 内）のリソースを操作しようとすると、
- VNET 統合
- VPN Gateway / ExpressRoute
- NSG / Firewall の調整
など、ネットワーク設計が必要です。
しかし Hybrid Runbook Worker を使えば、対象のサーバー（またはそのネットワーク内の踏み台）にエージェントを入れるだけで、「そのサーバー上でスクリプトを実行」 できます。
- オンプレにある AD サーバーで PowerShell を叩きたい
- 社内ファイルサーバーのログを整理したい
- 特定サーバー上のサービスを再起動したい
といった要件の場合、Functions からネットワーク越しに頑張るよりも、Automation の Hybrid Worker を使ったほうが、構成もシンプルでセキュアに収まりやすいです。
6. 【結論】Functions と Automation の使い分けパターン
以上より、シンプルに以下の 4 つの観点で「どっちが有利か？」を天秤にかけると決断しやすくなります。
① 柔軟なトリガーが必要か？
-
Yes → Azure Functions
- 「HTTPリクエスト」「Blobにファイルが置かれた」「Queueにメッセージが入った」など、多様なイベントをリアルタイムに検知したい場合。
-
No (スケジュール実行が主) → Azure Automation
- 「毎日朝9時に実行」「Webhookで単純起動」程度であれば Automation で十分です。
② 大量処理・スケールは必要か？
-
Yes → Azure Functions
- 短時間に数千件のアクセスが来るなど、自動でサーバー台数が増えてほしい（オートスケール）場合。
-
No (じっくり順次処理) → Azure Automation
- ジョブがキューに溜まっても良く、長い時間をかけて一つずつ処理すればいい場合。
③ どのコード（言語）で実行するか？
-
C# / Java / TypeScript / Python (アプリ開発) → Azure Functions
- アプリケーションロジックとして、クラス設計やライブラリ活用を含んだ開発をする場合。
④ オンプレミスへの接続が必要か？
-
Yes → Azure Automation (Hybrid Runbook Worker)
- オンプレミスのサーバー内や、閉域網のVM上で直接コマンドを叩きたい場合。これが最も簡単に実現できるのが Automation の強みです。
-
No (クラウド完結) → どちらでもOK
- 処理内容に応じて ①〜③ で判断します。
7. おわりに
ここまで整理してみると、Functions と Automation の機能差は、サービス自体の設計思想による差であると改めて思いました。
作ろうとしているシステムの要件を改めて整理することで、どちらが最適な選択肢であるかが見えてくると思います。
Azure にはこれら以外にも互いに似た機能を持つサービスがありますが、設計思想を意識した採用判断をすることが大切ですね。