New RelicのWorkflow Automationで最初に迷う「起動条件（Trigger）」。本記事では、アラート連動・手動・定期実行の違いを整理し、現場でどう使い分けるべきかを分かりやすく解説します！
New Relic の Workflow Automation は、アラート対応や定型運用を自動化するための強力な仕組みです。
ただ、最初に触ったときに少し迷いやすいのが、「この Workflow は何をきっかけに動くのか」 という点です。
Workflowの設定画面を見ると、つい Action（実行内容）や条件分岐に目が行きがちですが、実際には入口となる Trigger（起動条件）をどう設計するかで、運用の性質が変わります。Workflow Automation の起動方法は Alerts / On-demand / Scheduled の3系統が存在します。
この記事では、まず Trigger に焦点を当て、New Relic Workflow Automation がどのように起動するのか、そして実務でどう使い分けるべきかを整理します。
- Workflow Automation の Trigger の全体像
- Alerts / On-demand / Scheduled の違いと特徴
- On-demand を「GUI実行」と「API実行」に分けて考える理由
- 実務におけるTriggerの使い分けガイド
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
なぜ最初に Trigger から整理するのか
Workflow Automation を理解する際、「何をするか（Action）」から入りたくなりますが、実務では 「何をきっかけに始まるか（Trigger）」 の方が先に決まることがほとんどです。
たとえば、同じ「Slack通知」や「外部APIの呼び出し」でも、以下のように目的が異なります。
- アラートが出た瞬間に自動で動かしたいのか
- 運用担当者が必要なときだけ手動で実行したいのか
- 毎朝9時に定期実行したいのか
これによって、設計の意図はまったく変わります。New Relic の Workflow Automation も、まずは「どの Trigger で起動するか」を決め、その後に Action をつなげていく思想になっています。
Triggerの全体像：3つの系統と実務的な分類
公式には、Workflow Automation の起動方法は次の3種類です。
- Alerts trigger: アラートをきっかけに自動起動する
- On-demand trigger: 必要なときに手動で起動する
- Scheduled trigger: cron 式で定期起動する
ただ、実際に運用を考えると、On-demand はさらに2つに分けて考えた方がわかりやすいです。
- GUI から人が実行する
- API から外部システムが実行する
実際、Workflow の管理画面やエンティティ画面では 手動実行 ができ、どのバージョンを実行するかを選べるようになっています。
1. Alerts trigger
もっともオーソドックスでわかりやすいのが Alerts trigger です。
これは、アラート条件が違反したことをきっかけに Workflow Automation を自動起動する方式です。
↓ 詳しい設定方法はこちらの記事で紹介されています。
向いているユースケース
- 障害発生時の初動対応（情報収集など）を自動化したい
- アラート通知だけで終わらず、即座に担当チームへのエスカレーション処理を回したい
- 「異常が起きたら決まったフローを回す」というイベントドリブンな運用を作りたい
特徴と注意点
最大の強みは監視運用との親和性の高さです。一方で、アラート自体の品質（Alert Quality）が低いと、自動化されたAction自体がノイズになってしまいます。
New Relic のガイドラインでも「各アラートは調査または是正措置につながるべき」とされています。Workflow Automation を組む前に、「そもそもそのアラートで自動化を動かす価値があるか？」を見直すことが重要です。
2. On-demand trigger（GUI / API）
次に On-demand trigger です。「必要なときに起動する」というものですが、人が押すのか、システムが呼ぶのかで意味合いが大きく異なります。
2-1. GUI からの On-demand trigger（人が実行）
GUI からの On-demand は、運用担当者が画面から必要なタイミングで実行する方式です。Workflow の管理画面では手動実行が可能で、実行時にはどのバージョンを動かすかも選択できます。
向いているケース
- 障害時に、担当者の判断で定型オペレーション（再起動など）を実行したい
- 検証環境でまず挙動を確認したい
- いきなり完全自動化せず、半自動の運用から始めたい
メリットと運用上のポイント:
最大のメリットは 「人の判断」を介在させられることです。手順書を見ながら叩いていたコマンドを、ボタン1つに集約できます。実行時にバージョンを選択できるため、安全にテスト運用を行うのにも適しています。
ただし、「誰が・どのタイミングで押すのか」という運用ルールを明確にしておかないと、属人化を招く点には注意が必要です。
2-2. API からの On-demand trigger（システムが実行）
もう1つが API からの On-demand trigger です。こちらは、外部システムやスクリプトから Workflow を起動する考え方です。
向いているケース
たとえば次のようなケースです。
- CI/CD パイプラインの中からデプロイ後の処理として起動したい
- 社内ポータルやITSMツール（Jira, ServiceNowなど）のイベントを起点にしたい
メリットと運用上のポイント
Workflow Automation を単なる画面上の機能ではなく、他システムと連携する「自動化の部品」 として扱えるようになります。
ただし、認証の設計、呼び出し元のイベント制御、二重実行の防止など、システム的な考慮事項が増えます。「まずはGUIで運用を固め、再現性が確認できたらAPI実行へ移行する」というステップアップがおすすめです。
3. Scheduled trigger
3つ目が Scheduled trigger です。
これは、cron 式を使って特定の時刻に定期実行する方式です。
向いているユースケース
- 毎朝のシステム点検処理
- 日次バッチ終了後のステータス確認
- 定期メンテナンス作業の補助
特徴と注意点
Alerts が「何かが起きたら動く」のに対し、Scheduled は 「何も起きていなくても、時間になれば動く」 のが特徴です。
例えば「バッチ処理の監視」を考えたとき、「エラーが起きたら通知（Alerts）」と「朝8時に正常終了しているか確認（Scheduled）」は似て非なる運用です。後者のような「期限までの完了確認（プロアクティブな監視）」には、Scheduled trigger が非常にマッチします。
また、定期実行の安定性を保つため、Scheduled trigger では 実行するバージョンを固定して運用することが推奨されています。
まとめ：Triggerはどう使い分けるべきか？
ここまで整理した内容をざっくりまとめると、以下のようになります。
| やりたいこと | 推奨されるTrigger |
|---|---|
| 何かが起きたら自動で動かしたい | Alerts |
| 人が判断して必要なときに実行したい | On-demand (GUI) |
| 外部システムからイベント連携で呼び出したい | On-demand (API) |
| 決まった時間に定期実行したい | Scheduled |
これから触る方へのおすすめステップ
- GUI の On-demand で動かし、Workflowの基本動作を理解する。
- Alerts trigger を設定し、監視と自動化をつなげる。
- Scheduled / API で運用基盤の一部として組み込んでいく。
オブザーバビリティとしての Workflow
Workflow Automation は「作って終わり」ではありません。New Relic 上には WorkflowAutomationEvent が定義されており、ステータス、実行時間、エラーメッセージなどをNRQLでクエリ可能です。
つまり、「自動化の仕組み自体が正常に動いているかを観測できる」 ということです。実行履歴を定期的に確認し、自動化そのものの品質を保つ運用を目指しましょう。
まずは Trigger を整理することで、Workflow Automation の全体像が見えてきます。次回は、Triggerの次につながる 「Action や条件分岐の考え方」 について解説したいと思います。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
