ServiceNow ワークフローエンジン概要と作成手順 – インシデント自動割り当てガイド

2026年7月2日

Contents

1 ServiceNow ワークフローエンジンの基本構造
- 1.1 トリガー・ステップ・コンテキストの三層構造
  - 1.1.1 各層の具体例
2 主な活用シーンと実装例
3 必要なロール・権限と事前準備
- 3.1 workflow_admin と flow_designer の役割比較
- 3.2 作業前に確認すべき環境設定
4 Workflow Editor と Flow Designer の起動方法・新規フロー作成手順
- 4.1 旧 UI（Workflow Editor）からフローを作成する流れ
- 4.2 Flow Designer への移行と新規フロー作成のベストプラクティス
5 基本アクティビティと高度な実装テクニック
6 デバッグ・テストから本番リリースまでのベストプラクティス
7 まとめ

スポンサードリンク

ServiceNow ワークフローエンジンの基本構造

このセクションでは、ワークフローがどのような層で構成されているかを俯瞰し、各層が果たす役割と相互関係を解説します。三層モデルを理解するだけで、複雑なロジックでも段階的に設計・保守できるようになります。

トリガー・ステップ・コンテキストの三層構造

トリガー はレコードの作成・更新やスケジュール実行など、フローを開始させる入口です。
ステップ（アクティビティ） は実際に処理を行う単位で、Create Record・Update Record・Send Notification などが含まれます。
コンテキスト はフロー実行時の状態情報やエラーログを保持し、デバッグや履歴管理に利用されます。

各層の具体例

層	主な役割	実務での典型的な使用例
トリガー	フロー開始条件の検知	インシデントが「新規」になると自動発火
ステップ	ビジネスロジック実行	`Create Record` → `Update Record` → `Send Notification`
コンテキスト	実行履歴・エラー保持	Workflow Context で失敗箇所を特定

ポイント：三層構造を意識して設計すると、ロジックの分離が明確になり保守性が向上します。

主な活用シーンと実装例

ここでは ServiceNow のワークフローが最も効果を発揮する業務領域を紹介し、具体的な実装イメージを提示します。自社の課題に合わせてカスタマイズすれば、即座に効率化が期待できます。

インシデント自動割り当て

インシデントが登録された瞬間に優先度・カテゴリに応じた担当グループへ自動で振り分けます。手作業のミスを削減し、一次対応までの時間を大幅に短縮できます。

トリガー：Incident テーブルの state = New
ステップ：Lookup Assignment Group → Update Record (assignment_group) → Send Notification

変更承認フロー（二段階承認）

重大な構成変更はマネージャーとリスクオーナーの両方から承認を得る必要があります。ワークフローで承認ステータスを自動管理し、承認漏れを防ぎます。

トリガー：Change Request の state = Requested
ステップ：Approval – User (Manager) → If approved → Approval – User (Risk Owner) → Publish Change

資産ライフサイクル管理

資産の保守期限が近づくと自動で更新依頼や廃棄手続きを通知します。定期的なフォローアップを忘れずに実施でき、コンプライアンス遵守に貢献します。

トリガー：Scheduled Job（毎日 00:00 実行）
ステップ：Get Records (Asset where expiry_date <= today+7) → For Each → Create Record (Task) → Send Notification

ポイント：上記シナリオはすべて「ServiceNow ワークフロー作成手順」に沿って構築でき、必要に応じてテンプレート化して再利用可能です。

必要なロール・権限と事前準備

ワークフロー設計・実装には適切なユーザーロールとインスタンス設定が不可欠です。このセクションで、最低限必要な権限と環境チェック項目を網羅します。

`workflow_admin` と `flow_designer` の役割比較

ロール	対象エンジン	主な権限
workflow_admin	旧 Workflow エディタ全般	テーブルスクリプト、カスタムアクティビティ作成・削除
flow_designer	Flow Designer（新エディタ）	フロー作成・テスト・公開、データピル操作

ポイント：新規プロジェクトは保守性と拡張性の観点から flow_designer のみで開始することを推奨します。

作業前に確認すべき環境設定

サンドボックス／開発インスタンス が有効かどうか
Update Set 機能が利用可能で、変更対象が正しくパッケージ化できるか
必要プラグイン Workflow と Flow Designer が Active 状態であること
自分のユーザーに flow_designer（または workflow_admin）ロールが付与されているか

ポイント：上記項目をすべてクリアしたら、次章の「Workflow Editor の起動と新規ワークフロー作成手順」に進めます。

Workflow Editor と Flow Designer の起動方法・新規フロー作成手順

このセクションでは、旧 UI（Workflow Editor）と最新 UI（Flow Designer）のそれぞれの起動手順と基本設定をステップバイステップで示します。実際に画面操作しながら確認できるよう、スクリーンショットは省略していますが、記載の手順だけで問題なく開始できます。

旧 UI（Workflow Editor）からフローを作成する流れ

まずはレガシーエディタの起動方法と新規ワークフロー作成手順です。既存カスタムアクティビティが残っている環境では必須の操作になります。

アプリケーションナビゲータで 「Workflow」 と入力し、候補から 「Workflow Editor」 を選択
エディタ左上の New → Workflow をクリックして新規ワークフロー作成ダイアログを開く
ダイアログに名前（例：Incident Auto Assignment (Legacy)）と 対象テーブル（incident）を入力し、保存

ポイント：レガシーエディタではテンプレート選択ができないため、最初からステップを手動で配置します。

Flow Designer への移行と新規フロー作成のベストプラクティス

次にモダンな Flow Designer の起動手順と、推奨される作成プロセスを解説します。ドラッグ＆ドロップ操作が中心で、非エンジニアでも直感的に構築できます。

アプリケーションナビゲータで 「Flow Designer」 と入力し、対象アプリを開く
右上の Create new flow をクリックし、フロー名（例：Incident Auto Assignment (Modern)）を入力
「Record‑based」テンプレートから Incident テーブルを選択。テンプレートが無い場合は空白テンプレートで開始
画面左側の Trigger パネルで「When a record is inserted」または「When a record is updated」を設定し、対象フィールドに state = New を追加

ポイント：Flow Designer では Data Pill 機能を活用してトリガーから取得したレコード情報を簡単に次ステップへ渡せます。

基本アクティビティと高度な実装テクニック

ここでは代表的なアクティビティの設定例と、条件分岐・スクリプトステップを組み合わせた高度な実装方法を紹介します。実務で頻出するパターンに焦点を当て、エラー防止策も併せて提示します。

Create Record と Update Record の正しい設定手順

Create Record は新規レコード生成、Update Record は既存レコードの変更を行います。フィールドマッピングミスが最も多いので、以下のポイントに注意してください。

必須項目だけを明示的に指定：自動マッピングはオフにし、必要なフィールドのみ手入力
データ型の一致確認：文字列 → 文字列、整数 → 整数など、型が合わないと実行時エラーになる

インシデント自動割り当てでの設定例

アクティビティ	設定項目	値／式
Create Record (Task)	テーブル	`task`
	short_description	`"Auto‑assigned incident"`
	assignment_group	`{{trigger.incident.assignment_group}}`
Update Record (Incident)	対象レコード	`{{trigger.incident.sys_id}}`
	state	`2`（In Progress）
	comments	`"自動割り当て完了"`

ポイント：更新対象は必ず sys_id で指定し、不要なフィールドは除外するとエラーが減ります。

Notification アクティビティの活用法

通知はステークホルダーへの情報共有に不可欠です。メールテンプレートと Data Pill を組み合わせることで、動的コンテンツを簡単に埋め込めます。

アクティビティ名：Send Notification
使用テンプレート：Incident Assignment Alert（事前作成）
パラメータ例：
recipient = {{trigger.incident.assigned_to.email}}
variables.short_description = {{trigger.incident.short_description}}

ポイント：テンプレート内のマクロは Data Pill と同名で紐付けると、内容が自動的に置換されます。

条件分岐（If/Else）とスクリプトステップのベストプラクティス

複雑なロジックは If/Else だけでは表現しきれないことがあります。その際は Script step を組み合わせ、可読性と保守性を両立させます。

条件分岐のシンプル化例

If {{trigger.incident.priority}} == 1 (Critical)
    → Create Record (Escalation Task)
Else If {{trigger.incident.category}} == 'Network'
    → Update Record (assignment_group = Network Support)
Else
    → No Action

If {{trigger.incident.priority}} == 1 (Critical)

→ Create Record (Escalation Task)

Else If {{trigger.incident.category}} == 'Network'

→ Update Record (assignment_group = Network Support)

Else

→ No Action

スクリプトステップの実装例（JavaScript）

// 担当グループを動的に決定するロジック
try {
  var grp = (current.category == 'Network') ?
            'Network Support' : 'General Support';
  // 返却はオブジェクト形式で後続ステップの Data Pill として利用可能
  return { assignment_group: grp };
} catch (e) {
  gs.log('Group determination error: ' + e.message, 'FlowScript');
  throw e;   // エラーを上位に伝播させ、フローを失敗状態にする
}

// 担当グループを動的に決定するロジック

try {

var grp = (current.category == 'Network') ?

'Network Support' : 'General Support';

// 返却はオブジェクト形式で後続ステップの Data Pill として利用可能

return { assignment_group: grp };

} catch (e) {

gs.log('Group determination error: ' + e.message, 'FlowScript');

throw e; // エラーを上位に伝播させ、フローを失敗状態にする

}

注意点：current は読み取り専用です。書き込みは別の Update Record ステップで行う
エラーハンドリング：必ず try…catch で例外捕捉し、ログに残すことでトラブルシュートが容易になる

ポイント：ロジックはなるべくスクリプトステップに集中させ、フロー図上はシンプルな分岐だけを配置すると全体の見通しが良くなります。

デバッグ・テストから本番リリースまでのベストプラクティス

作成したワークフローは本番環境へデプロイする前に入念な検証が必要です。ここでは実践的なデバッグ手順、バージョン管理方法、パフォーマンス最適化策をまとめます。

Workflow Context の活用方法

Workflow Context はフロー実行の履歴レコードで、ステップごとの状態やエラーメッセージが格納されています。以下の手順で確認できます。

アプリケーションナビゲータで 「Workflow Context」 を検索
フィルタに対象インシデント番号（例：INC0012345）を入力し、実行中・完了・失敗のレコードを一覧表示
該当レコードを開き、Error Message 欄や Log タブで詳細情報を取得

ポイント：コンテキストは自動的に 30 日間保持されますが、長期保存したい場合はカスタムスクリプトで別テーブルへエクスポートすると便利です。

Log Viewer を使ったサーバ側デバッグ

gs.log() や gs.error() で出力したメッセージは Log Viewer の「Application Logs」から確認できます。デバッグ時のコツは次の通りです。

ログレベルを Info に設定し、不要な大量ログを抑制
source パラメータにフロー名やカスタムタグ（例：FlowDebug）を付与してフィルタリングしやすくする

gs.log('Assignment group resolved: ' + grp, 'FlowDebug');

1 2	gs.log('Assignment group resolved: ' + grp, 'FlowDebug');

ポイント：本番環境ではログ出力がパフォーマンスに影響するため、デバッグ完了後は gs.debug() 系の呼び出しを削除またはコメントアウトしてください。

バージョン管理と承認フロー連携

ServiceNow では Update Set と Application Repository によるバージョン管理が標準装備されています。チーム開発時の流れは次の通りです。

作業開始前に「Create Update Set」し、作業対象を限定
フロー完成後、Update Set に自動的に差分が保存されることを確認
承認が必要な場合は Approval – User アクティビティで state = "Pending Approval" を設定し、承認者のレビューを取得
テスト環境で Preview → Publish し、本番インスタンスへ適用

ポイント：Update Set の内容は必ず Commit 前に差分プレビューで確認し、不要なレコードが含まれていないかチェックしましょう。

パフォーマンス最適化と失敗パターンの対策

大規模インスタンスではワークフロー実行時間が SLA に直結します。以下はよくあるボトルネックとその回避策です。

失敗例	原因	改善策
`Get Records` が全テーブル走査	フィルタ条件が緩すぎる	インデックス付きフィールドで絞り込み、`Query Fields` を限定
スクリプト内の `while (true)` ループ	無限ループによるサーバ過負荷	ループ回数上限を設定し、`gs.sleep()` は使用しない
同一レコードへの複数回更新	不要な DB アクセス	更新が必要か判定する If 条件を追加

ベンチマーク：テスト環境で Performance Analytics > Transaction を利用し、フロー実行時間の分布を測定
モニタリング：System Logs > Scheduled Jobs でバッチジョブの実行状況を定期的に確認

ポイント：パフォーマンスチューニングは「最小ステップ」「インデックス活用」の原則に沿って設計し、テストフェーズで負荷シミュレーションを必ず実施します。

まとめ

ServiceNow のワークフローエンジンは トリガー・ステップ・コンテキスト の三層構造で動作し、インシデント自動割り当てや二段階承認など多様な業務プロセスをコードレスで実装できる
必要ロールは flow_designer（新） または workflow_admin（旧）。サンドボックス環境・プラグイン有効化・ロール付与の事前チェックが成功の鍵
旧 UI の Workflow Editor と最新 Flow Designer の起動手順とフロー作成方法を把握すれば、どちらの環境でも即座に開発可能
基本アクティビティ（Create/Update Record、Notification）はフィールドマッピングとデータ型確認でエラー防止。条件分岐はシンプルに保ち、複雑ロジックは Script step に委譲するのがベストプラクティス
デバッグは Workflow Context と Log Viewer を駆使し、変更履歴は Update Set で管理。パフォーマンスは不要な検索・ループを排除し、インデックス活用と負荷テストで最適化

これらのポイントを押さえておけば、ServiceNow のワークフロー設計から本番リリースまでを安全かつ効率的に進めることができます。ぜひ実務で試してみてください。