ServiceNowのPlaybookはFlowと何が違う？ 人が進める手順をどう組むか
Incidentの調査手順は、Flowで自動化するべきか、担当者が確認しながら進める手順として組むべきか、判断に迷うことがあります。ServiceNowにはFlow Designerとは別に、担当者向けにPlaybookと呼ばれる仕組みが用意されています。プロセス定義・レーン・アクティビティという3階層でレコードごとの手順を管理し、実行のたびに専用テーブルへ進捗を残す作りです。Zurich PDIで実際に組まれているPlaybookを1本たどり、Flowとの構造の違いを確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：Playbookはレコードの横で担当者が進める手順
定義はProcess Definition→Lane→Activityの3階層です。 今回のPDIには48件のProcess Definitionがあり、そのうち画面表示形式が「Kanban」だったのは数件でした。担当者がレーンを列として見る、伝統的なPlaybook体験です。
実行のたびに専用のテーブルへ記録が残ります。 Playbook Executions（sys_pd_context）が1回の実行につき1件、Laneごとの進み具合はActivity Execution（sys_pd_activity_context）に記録されます。Flowのsys_flow_contextと同じ、定義と実行を分ける作りです。
Flowが裏側で自動的に最後まで流すのに対し、Playbookは担当者がレコードのそばで1ステップずつ進める前提です。 承認やレーンの遷移そのものが、進捗として画面に見える形で残ります。
Playbookの定義は3階層に分かれている
Playbookの定義そのものを格納する中心テーブルはsys_pd_process_definitionです。ラベルは「Process Definition」となっています。ただしフィールドprocess_type（プロセス種別）の列ラベルは「Playbook type」でした。UI上ではPlaybookという名前で扱われていることが、このフィールド名から分かります。
今回確認したPDI（Zurich / OOTB）では、sys_pd_process_definitionは48件、うちactiveが48件でした。ラベルを見ると大半が「Task steps」という汎用名です。Critical Updates（重要な更新プログラム）やBest practice configurations（推奨設定）向けの手順で使われています。一方で、業務名が付いたものも一部ありました。例えば「Remediate device」「Remediate server」「On-Call Scheduling」「Multi-factor Authentication」です。
一覧の下には「Number of rows removed from this list by Security constraints: 1」という表示もありました。ACLによって1件が一覧から除かれていたことになります。件数を数える記事ではないのでここでは深追いしませんが、Process Definitionにも通常のテーブルと同じくACLが効いているという実例です。
このうち「Remediate device」（内部名remedial_action_process）を1本たどってみます。所属アプリケーションは「Incident Management for Service Operations Workspace」でした。Descriptionには「remedial action executions during incident investigation」向けとあります。フォームを開くと、Lanes・Activities・Process Variants・Translated Messagesのタブが並ぶ関連リスト構成でした。Lanesタブには2件、Activitiesタブにも2件が入っています。
Lane（sys_pd_lane）は「レーン」で、担当者から見ると進捗の列にあたります。今回のPDIには114件ありました。Remediate deviceのレーンは2つだけのシンプルな構成です。1つ目は「User approval」（順序1、開始ルールはImmediately＝すぐ開始）、2つ目は「Remediate」（順序2、開始ルールはAfter Lanes＝前のレーン完了後）でした。
なおsys_pd_process_type（Playbook type、プロセスの分類タグ）は、今回のPDIにわずか1件（"Creator Studio Automation"）しかありませんでした。Remediate deviceを含む48件のProcess Definitionは、いずれもこのタグを使っていません。用意されているのに、実際にはほとんど使われていない分類フィールドという印象です。
レーンの中身はActivityとActivity Definitionでできている
レーンの中に並ぶ1つ1つの手順がActivity（sys_pd_activity）です。今回のPDIには146件ありました。Remediate deviceには「Get user approval」（Userapprovalレーン）と「Remediate」（Remediateレーン）の2件があります。
Activityは自分では処理内容を持たず、activity_definitionという参照フィールドで種類を指します。参照先のsys_pd_activity_definition（Activity Definition）は、いわば手順の部品カタログです。今回のPDIには55件ありました。代表例はUpdate Record・Show List of Records・Request approval（承認依頼）です。ほかにCreate task（タスク作成）・Remedial Action Execution（復旧アクション実行）もあり、Flowのアクションタイプによく似た種類でした。「Remediate - device」のActivity Definitionは、Remedial Action Executionという専用タイプでした。
55件のうち、activity_typeが空欄のものも複数ありました。Submit Catalog Item・Decision・Dummy Activityなどです。UIレイアウトを持たない、内部制御向けの種類だと考えられます。
Activity・Lane・Process Definitionのどれも「Starts After Activities」「Starts After Lanes」という参照フィールドを持っています。前のアクティビティやレーンが終わってから始める、という順序関係を表すフィールドです。Flowにおけるアクション同士のorder順とは仕組みが違います。レーン単位・アクティビティ単位で、個別に前後関係を組めるようになっていました。
実行のたびにsys_pd_contextが1件作られる
ここまでは定義（設計図）側の話でした。Playbookが実際に動くと、記録がどこに残るのかを見ます。
Playbookが起動すると、sys_pd_context（ラベルは「Playbook Executions」）へ1件のレコードが作られます。フィールドを見ると、process_definitionはsys_pd_process_definitionではなくsys_pd_snapshot（Process Definition Snapshot）を参照していました。公開時点のスナップショットを実行が参照する作りです。Flowが実行のたびに公開版を参照する構造とよく似ています。
今回のPDIにはsys_pd_contextが41件あり、stateはすべてIn Progress（実行中）でした。一覧を開くと、Input RecordにCritical Updates（重要な更新プログラム）とBest practice configurations（推奨設定）の項目名がそのまま並んでいます。
Laneごとの進み具合はActivity Execution（sys_pd_activity_context）に残ります。今回のPDIには270件ありました。new_stage_1$startのような内部制御用の行が多数を占めています。AI Agent Action SummaryやAI Agent Statusという列も並んでいました。Playbookのアクティビティに生成AIエージェントを割り当てられる作りになっていることも、実機で確認できました。
動いているPlaybookの先は、REST APIでは見えないことがある
sys_pd_contextのInput Recordが指す先は、sn_critical_update（Critical Updates）とsn_vsc_best_practice_configurations（Best practice configurations）というテーブルでした。この2つにGET /api/now/table/で直接アクセスすると、403 User Not Authorizedが返ってきます。ところが同じテーブルの一覧を管理者としてブラウザで開くと、普通に7件のレコードが表示されました。
同じ管理者権限でも、テーブルAPIとブラウザのUI一覧とでACLの扱いが違う場面があります。原因の詳細（ACLの種別）までは今回の検証範囲外です。「REST APIで403が返る＝画面でも見えない」とは限らないという実例として記録しておきます。
実機で気づいたこと
Trigger Instance（sys_pd_trigger_instance）は48件あるのに、Trigger Template（sys_pd_trigger_definition）は0件でした。テンプレートを介さず、個々のPlaybookに直接トリガ条件を持たせる作りが、この環境では標準だったことになります。同じ理屈で、Swim Lane専用の画像テーブル（sys_pd_swim_lane）も0件でした。名前だけを見ると主役に見えるテーブルが、実際にはほとんど使われていないという意外な発見です。
Remediate deviceのフォームを開いたとき、グラフィカルなKanbanキャンバスがすぐには出てきませんでした。代わりにLanes・Activitiesが並ぶ通常の関連リスト画面が表示されたのも予想と違いました。Flow Designerのキャンバスはsys_hub_flowのフォームを開くとほぼ自動的に専用エディタへ切り替わります。今回のPlaybookでは、同じような導線が見つかりませんでした。レコードのアプリケーションスコープは「Incident Management for Service Operations Workspace」です。今回開いた先は「Global」でした。この不一致が影響している可能性はありますが、断定はできません。
sys_pd_contextを41件すべて見たとき、Remediate device自身の実行例は1件もありませんでした。実際に動いているのはCritical UpdatesとBest practice configurationsという、ServiceNow自身が管理者向けに用意したチェックリストだけです。Playbookという機能は担当者向けの業務手順のイメージが先行します。ですがこの環境では「管理者にプラットフォームの保守タスクを1つずつ確認させる」という使い方の比重が大きいことが、件数の内訳から見えました。
sys_pd_process_type（Playbook type）というプロセスの分類タグが、48件中1件も使われていなかったことも意外でした。分類用のフィールドが用意されていても、運用上は使わなくてもPlaybookとして問題なく機能する、という実例です。
実務ではFlowとPlaybookをどう使い分けるか
自分がこれから手順を組むなら、まず「最後まで人の目を通さず流してよいか」を自問します。レコード更新・通知・他システム連携のように、条件さえ揃えば自動で完結してよい処理はFlow向きです。逆に、承認・現地確認・段階的な復旧作業のように、担当者が状況を見ながら次のレーンへ進めるかどうかを判断する場面では、Playbookのレーン構造がそのまま業務の流れに合います。
公式ドキュメントにも、両者の使い分けを示すページが用意されています。迷ったときはこの判断基準に沿って選ぶのが安全です。
Playbookのレーンや個々のアクティビティは、承認待ちの状態そのものが進捗として画面に残ります。Flowで同じことをすると、承認待ちはWait For ConditionやAsk for Approvalという1アクションの中に埋もれます。外からは「実行中」としか見えません。担当者に「今どこまで進んでいるか」を見せたい業務ほど、Playbookを選ぶ理由になります。
今回のPDIで実際にPlaybookが使われていたCritical UpdatesやBest practice configurationsも、この判断基準に当てはまります。管理者が1件ずつ内容を読み、対応してから次に進む前提の業務だからこそ、通知だけで完結するFlowよりも、進捗が残るPlaybookが選ばれていると考えられます。
つまずきやすい点
Process Definitionのフォームを開いても、Flow Designerのようにグラフィカルなキャンバスへ自動的に切り替わるとは限りません。今回のPDIでは通常の関連リスト画面のままでした。
sys_pd_contextのprocess_definitionが指す先はスナップショットです。Process Definitionそのものを直接たどろうとすると、参照先のテーブルが違うことに気づきにくいので注意します。
実行対象の業務テーブルにACLがかかっていると、テーブルAPIでは403になっても、UI一覧では普通に見える場合があります。API経由の調査だけで「アクセス不可」と判断しないほうが安全です。
Trigger Template（sys_pd_trigger_definition）が空でも、Trigger Instanceは正常に機能します。テンプレートが無いからといって、そのPlaybookのトリガが未設定とは限りません。
Activity Definitionの一覧には、activity_typeが空のものが混ざっています（Decision・Dummy Activityなど）。種類が空だからといって使われていないアクティビティとは限らないため、process_definition側から実際の使用有無を確認したほうが確実です。
よくある質問
Q1. PlaybookとFlowは同じデータで動いていますか
いいえ。定義側はProcess Definition・Lane・Activityという別テーブル群です。実行側もPlaybook Executions（sys_pd_context）とFlow Executions（sys_flow_context）は別テーブルでした。ただしどちらも「定義を公開してから実行のたびに記録が作られる」という設計思想は共通しています。
Q2. PlaybookはFlowを呼び出せますか
今回の検証では確認していません。Activity Definitionの種類にはRecord・List・External Linksなどがあります。Flowを直接呼ぶ専用タイプが存在するかどうかは、今回のPDIでは特定できませんでした。気になる場合は自分のPDIでActivity Definitionの一覧を眺めてみることをおすすめします。
Q3. Process Definitionの件数が48件というのは多いですか
比較対象になるのはFlow（sys_hub_flow）です。以前の検証では338件でした。単純な件数の大小よりも、使われ方の違いが目立ちます。Process DefinitionはCritical UpdatesやBest practice configurationsのような場面でも使われています。プラットフォーム自身の保守用チェックリストという性格です。
Q4. Kanban表示とDiagram表示、どちらが本来のPlaybookですか
どちらもProcess Definitionのview_typeで選べる表示形式です。今回のPDIでは、担当者が手を動かす業務（Remediate device/serverなど）はKanbanでした。管理者向けのガイド設定（Multi-factor Authenticationなど）はDiagramが使われています。用途に応じて選ぶもので、優劣はありません。
Q5. 本番環境でも同じ手順で調査できますか
基本の考え方は同じです。ただし本番環境ではカスタムのProcess Definitionが追加されている可能性が高く、sys_pd_contextの件数も桁違いに増えます。特定のPlaybookを追いたいときは、process_definition（実体はsnapshot参照）やInput Recordで絞り込んでから見ると迷いにくくなります。
まとめ
Playbookの定義はProcess Definition→Lane→Activityの3階層です。実際の処理内容はActivity Definitionという部品カタログを参照します。実行のたびにPlaybook Executions（sys_pd_context）とActivity Execution（sys_pd_activity_context）へ記録が残る点は、Flowのsys_flow_contextと同じ「定義と実行の分離」でした。違いは進める主体にあります。Flowはシステムが自動で最後まで流すのに対し、Playbookは担当者がレコードのそばでレーンを1つずつ進める前提で作られていました。今回のPDIで実際に動いていたPlaybookも、Critical UpdatesとBest practice configurationsという、管理者に保守タスクを1つずつ確認させる用途が中心です。
用語
Process Definition（sys_pd_process_definition） … Playbookの定義そのもの。UI上はPlaybookと呼ばれる
Lane（sys_pd_lane） … 担当者から見た進捗の列。Process Definitionの下にぶら下がる
Activity（sys_pd_activity） … レーンの中の1つ1つの手順。Activity Definitionを参照して処理内容が決まる
Activity Definition（sys_pd_activity_definition） … アクティビティの種類カタログ（Record・List・承認・External Linksなど）
Playbook Executions（sys_pd_context） … Playbookが実行されるたびに作られる記録。stateで進捗が分かる
Activity Execution（sys_pd_activity_context） … レーン・アクティビティ単位の実行記録
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
Process Definition一覧（active） : sys_pd_process_definition_list.do?sysparm_query=active=true^ORDERBYlabel
特定Process DefinitionのLane一覧 : sys_pd_lane_list.do?sysparm_query=process_definition=<sys_id>^ORDERBYorder
特定Process DefinitionのActivity一覧 : sys_pd_activity_list.do?sysparm_query=process_definition=<sys_id>^ORDERBYorder
Activity Definitionのカタログ : sys_pd_activity_definition_list.do?sysparm_query=ORDERBYlabel
Playbook実行の一覧（新しい順） : sys_pd_context_list.do?sysparm_query=ORDERBYDESCsys_created_on
Activity Executionの一覧（新しい順） : sys_pd_activity_context_list.do?sysparm_query=ORDERBYDESCsys_created_on参考リンク
関連記事
Flow Designerの中身は3テーブル（sys_hub_flow） — 前提知識：Flow側の定義構造を先に押さえたい人向け
レガシーWorkflow（wf_workflow）とFlowの違い — 前提知識：もう1つの旧世代の自動化機能との対応関係を知りたい人向け
ServiceNowのFlowは動いたのか？ 実行ログで止まった場所をたどる — 実務編：Flow側の実行記録の追い方を先に知りたい人向け
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で確認したものです。本番環境やカスタマイズ済みの環境では、Process Definitionの構成や件数が異なります。PDIへの書き込み（レコード作成・更新）は行っておらず、Remediate deviceを実際に発火させてPlaybookが動く様子そのものは確認していません。
Playbookのトリガが対象テーブルをどのフィールドに保持しているか（sys_pd_trigger_inputの中身）は確認できませんでした。グラフィカルなKanbanキャンバスへの遷移経路も同様です。担当者から見てレコードの横にPlaybookパネルが表示される画面も、今回のPDIの権限・アプリ構成では確認できませんでした。sn_critical_update・sn_vsc_best_practice_configurationsへのREST 403の正確な原因も、今回の検証範囲の外です。Playbookのアクティビティが承認レコードを実際に作るかどうかも確認していません。
