本記事は ServicenNow アドベントカレンダー 2025の参加記事 第3日目 です
概要
ServiceNowのワークフロー自動化を担ってきたWorkflow Editorは、Zurichリリースをもって大きな転換期を迎えました。本記事では、新規インスタンスにおけるOOTBフローのFlow Designerへの移行という現実を受け止め、「準備なしの強制移行」の悪夢を迎えないようしたいと考えています。
長年にわたりサポートが続けられてきたWorkflow Editorですが、既に7年もの間、機能更新のない 「メンテナンスモード」で運用されています。
本記事では、Workflow Editor廃止の背景・歴史、そしてFlow Designerへの移行に伴った変化を解説します。
そして、ナレッジ管理やサービスカタログといった中核機能で実際に発生した移行事例を分析した上で、 「移行を自力で行う」 ことを前提とした、リスクを最小限に抑えつつ効果を最大化するための具体的な移行戦略を提示します。
導入
こんにちは、にわと🐔(𝕏：@niwaniwa2wato)です。
Workflow Editorの既存利用者は、まだサポートが続きます、すぐには廃止はされません。が、安心ばかりもしていられません。 公式からの移行ツールが展開される気配はなく、継続的な移行アナウンスから既に7年が経過しています。
免責事項
この記事は将来的なWorkflow Editorの廃止を前提に記述していますが、筆者の予測を含みます。今後のServiceNowのロードマップや計画次第で状況が変わる可能性があることをご承知おきください。
しかしながら、最悪に備えることは悪いことでないと思いますし、ServiceNowのメッセージに沿って対応すべきだと考えた上での記事になります。
さて、皆さんの意識を高めるために、ここからはWorkflow EditorをLegacy Workflowと記載します。
それでは、現在の状況を整理しましょう。
🕰️Legacy Workflow Editorのこれまで
💬きっかけは一本のLinkedIn投稿
事の発端は、2024年8月のLinkedInでの投稿でした。
| 翻訳 |
|---|
| 確認済み：ServiceNow Zurichでレガシーワークフローが廃止！ ついに、100以上のワークフローをプレイブックとフローに移行し、再利用可能なサブフロー、カスタムアクション、決定表を実装してきた私たちの努力が実を結びました。 ワシントンDCリリース以降、ワークフロースタジオで最高の環境を実現しています。 Zurichリリースに伴い、ServiceNowは新規インスタンス向けにOOBレガシーワークフローを提供しません。 全社内アプリケーションチームはフローデザイナーへ移行済みです。 既存顧客向けにはレガシーワークフローは引き続き機能しますが、その終焉は明らかです。 まだレガシーワークフローに依存していますか？ 今すぐ移行戦略の策定を開始しましょう！ |
要点を整理すると以下の通りです。
- 新規インスタンス：Legacy Workflowは提供されない
- 既存インスタンス：影響なし。作成・編集のサポートは継続
- メッセージ：「サポートは続けるけど、そろそろ本気で移行考えてね？（圧）」（意訳）
ここが最初の情報発信源なのかまで調査は行っていませんが、この発信により、
Legacy WorkflowのOOTBフローが全て廃止され、Flow Designer製のフローに移行が決まりました。
❔移行ツールでないの❔
Legacy Workflowは多くの顧客環境で今でも使用されています。そして、それらを１つ１つ解析してFlow Designerに移行している余裕がない組織も多いはずです。そんな状況で皆さんが求めるもの...
そう、移行ツールですよね。
Xanaduではレポート・ダッシュボード機能が廃止され、プラットフォームアナリティクスにすぐに移行できるよう移行ツールが提供されました。Legacy Workflowも同じように提供されるのでは？と期待したくなりますよね。
今のところ公式の見解はこちらです。
| 翻訳 |
|---|
| 常に議論を巻き起こす質問は、ワークフローを古いワークフローエディターからフローデザイナーに移行する必要があるということです。 壊れていなければ直さないでください。ワークフローエディターはすぐになくなることはなく、 直接変換ツールもありません。 フローデザイナーで新しいフローを作成する。新しいプロセスや既存のプロセスへの大幅な変更については、Flow Designer が最適です。継続的な改善、より簡単な統合、強力な機能 (外部トリガーやフロー デバッガーなど) により、最新の開発にとって優れた選択肢となっています。 |
はい、ありません。
現実は厳しいものでした。残念ながらプラットフォームアナリティクスに移行したときのような直接の変換ツールは展開されないようです。継続的に移行のアナウンスがされているのは、このためですね。つまり、我々は自力で移行計画を考える必要があります。
🏛️Legacy Workflow Editorの歴史
クライアントや上司に「なぜ今Flow Designerなのか」を説明するための材料として、歴史を振り返ってみましょう。
Legacy Workflowの登場は2008年。iPhone 3Gが日本で発売された年です。
個人ならすぐにでも、iPhone 17に乗り換える人が多い中、組織になると未だにiPhone 3Gを使用し、いまだ新規フローもiPhone 3Gで開発していることに疑問も思わない組織がまだいる現状です。
そして2018年以降、7年間「メンテナンスモード（機能改善なし）」 で運用されています。技術的負債となる前に、モダンな環境へ移行すべき理由はここにあります。
✅Flow Designerを選ぶ技術的理由
「サポートが続くなら、まだそのままでいいのでは？」と思うかもしれません。しかし、Legacy WorkflowからFlow Designerへ移行すべき理由は、単に「新しいから」だけではありません。開発体験、拡張性、そしてパフォーマンス・アーキテクチャの根本的な違いがそこにはあります。
🟩開発者体験の圧倒的向上
Legacy Workflowは2018年以降、機能更新が完全に停止しています。一方で、最新のWorkflow Studioは、フロー、サブフロー、Playbook、意思決定テーブル（Decision Tables）など、あらゆる自動化ツールを1つのビルダーに統合しています。
🟢デバッグの効率化
Flow Designerではテスト機能とデバッグ機能も用意されており、Legacy Workflowより格段にテストがしやすくなっています。また、ブラウザのタブを行き来してコンポーネントを作成する必要はありません。ビルダー内で直接テストを実行し、詳細な実行分析やエラー処理を確認できます。
🟢可読性と再利用
再利用が容易な「カスタムアクション」や「サブフロー」、近年では意思決定テーブル（Decision Tables）により複雑なIF文の管理がしやすくなりましたし、Zurichバージョンから独自のフロートリガー機能も開発できるようになりました。
🟢Integration Hub
ServiceNowの特徴でもある、豊富な連携機能。その増え続けるSpoke（接続コネクタ）を利用することで、外部システム連携の工数を劇的に削減できます。
🟩生成AI・RPAなど最新技術へのアクセス
Flow Designerは、ServiceNowの最新イノベーションへの入り口です。（とServiceNowは言います）
ServiceNowの製品戦略のメインとなるNow AssistやAI AgentはFlow Designerにのみ機能しています。特にAI Agentを作成する際に、使用するツールの１つFlow Designerは組み込まれており、Agentの動きをフローで作成することができます。
RPA連携では、APIがないレガシーシステムとも、フローからRPAロボットを呼び出すことでシームレスに連携可能。 これらはLegacy Workflowでは享受できないメリットです。
🟩アーキテクチャとパフォーマンスの刷新
そして最も重要なのが、エンジンの設計思想の違いです。
🟢DB負荷の軽減
Legacy Workflowは実行ログ[wf_context]は無効化できません。これはDB書き込みコストが常にかかります。対してFlow Designerは、レポート機能用に最適化された書き込み[sys_flow_context]を行いますが、大量処理時にはオフにすることも可能です。
🟢「1秒待機」ハックからの卒業
Legacy Workflowはデフォルトで同期実行（ユーザースレッド）されるため、ユーザーの画面操作をブロックしがちでした。これを回避するために、冒頭に「1秒タイマー」を入れて無理やりバックグラウンドに回すハックを使った経験がある方も多いでしょう。
それでもなお、イベントキューのポーリング間隔（2〜8秒）の影響を受けます。 Flow Designerはデフォルトでバックグラウンド実行であり、
NowMQ(メモリ内のキュー)を使用します。これにより、ユーザースレッドをブロックせず、かつ0.5秒未満という高速な処理開始を実現しています。
つまり、Flow Designerへの移行は、単なるツールの置き換えではなく、「システムの健全性とパフォーマンスの最適化」 そのものなのです。
☑️Zurichで移行されたWorkflowのまとめ
改めてですが、ServiceNowは新規顧客向けにLegacy Workflowを提供しなくなりました。
すべてのOOTB Legacy WorkflowはFlow Designerに移行されました。
では、具体的にどのフローがFlow Designerに移行されたのでしょうか？
そのリストは下記の公式サポートKBで公開されています。
なんと165フローもあるため、この記事内には記載しませんが、是非ご確認ください。
🟪サービスカタログとナレッジ公開・廃止のフローが移行
特筆すべきは、以下の領域がついにFlow Designerへ完全移行されたことです。
- ナレッジ管理（公開・廃止フロー）
- サービスカタログ（OOTBフロー）
これまでナレッジ管理の承認フローなどは、「なぜかLegacy Workflowでしか動かない」という謎の制約に縛られていました。「Flow Designerで作りたいのに...」と歯痒い思いをした開発者も多いはずです。
Zurichでの移行により、これらもモダンなFlow Designerで構築・管理できるようになります。これは非常に大きなメリットです。
🟪ナレッジ承認フローの差分を確認する
ここからは、Legacy WorkflowからFlow Designerへの移行前後のナレッジ承認フローの差分を確認して、何が変更されているのか確認します。
Legacy Workflow環境：Yokohama Patch9
Flow Designer環境：Zurich Patch3
🟣フィールドの変更
ナレッジベース[kb_knowledge_base]テーブルのレコードを開くと、そのナレッジベース内のナレッジ記事が公開・廃止される際に利用されるフローを設定するフィールドが存在します。そのフィールドの情報を確認すると以下の画像のように、フィールド自体が追加されています。
🟣スクリプトの変更
参照するフローのフィールド定義が異なれば、そのフィールド内のフローを実行するためのスクリプトも異なります。ここでは、ナレッジ記事[kb_knowledge]テーブルのUIアクションである「公開」UIアクション内のスクリプトインクルードである、KnowledgeUIAction()を確認し、公開フローの実行処理がどう行われているのか違いをまとめます。
対象のSys IDを載せておきます。
コードが長いので詳細はご自身でご確認ください。
UI アクション：
「公開」[d0c86952eb8321007128a5fc5206fe64]
スクリプトインクルード：
「KnowledgeUIActionSNC」[53f2247bb712230026778d78ee11a971]
| 特徴 | 以前のバージョン (workflowのみを前提) | 新しいバージョン (workflowとflowに対応) |
|---|---|---|
| Flow Designerの対応 | 対応なし。 ナレッジベースの設定がワークフローのみに対応していると想定しています。 | 対応あり。 checkIfFlowFieldExistsとnew KBFlow().startFlow()を使用して、ナレッジベースにkb_publish_flowが設定されている場合に実行できます。 |
| ワークフロー/フローの選択 | ワークフローがハードコードされています: new KBWorkflow().startWorkflow(articleGr, "workflow")。 | 動的に選択されます: workflowFieldExistsがfalseならフローを実行します。 |
| 設定フィールドのチェック | ワークフローフィールドの存在チェックが欠落しています（if文の条件で直接startWorkflowを試みている）。 | checkIfWorkflowFieldExistsとcheckIfFlowFieldExistsを使用して、フィールドが有効で値があるかを事前に確認しています。 |
| フロー実行後のデータ更新 | フロー実行後の特別なデータ更新ロジックは存在しません。ワークフローエンジンがcurrent.update()を実行すると想定しています。 | フロー実行後の対応ロジックが追加されています。フローが非同期で動作し、レコードオブジェクトをすぐに更新しない可能性があるため、articleGrCopyを使ってデータベースから最新のバージョン情報を再取得しています。 |
新しいバージョンでは、ServiceNowのプラットフォームの進化に合わせて、公開ロジックが大幅に強化されています。
🚀Flow Designerへの対応
最も大きな違いは、従来のワークフローエンジン（KBWorkflow）に加え、Flow Designerのフロー（KBFlow）に対応したことです。
以前のバージョンでは、常にnew KBWorkflow().startWorkflow(articleGr, "workflow")を呼び出していました。
新しいバージョンでは、checkIfWorkflowFieldExistsとcheckIfFlowFieldExistsの結果に基づいて、ワークフローとフローのどちらを使用するかを動的に決定します。
📈ロバスト性の向上
新しいバージョンでは、ワークフローまたはフローを実行する前に、checkIfWorkflowFieldExistsやcheckIfFlowFieldExistsというヘルパーメソッドを使用して、ナレッジベースレコードにフィールドが存在し、かつアクティブな値が設定されているかを明示的に確認しています。これにより、設定ミスによるエラーを防ぎ、より堅牢になっています。
🔄フロー実行時の競合回避
新しいバージョンには、Flow Designer特有の問題に対処するための重要なコメントとロジックが追加されています。
「Flowは必ずしも同じレコードオブジェクトを更新しないため...データベースからクエリを実行して、ナレッジレコードに関する正確で最新の情報を取得することを保証します。」
これは、フローの非同期性や更新方法により、articleGrオブジェクトが最新の状態ではない可能性があるため、 データベースからレコードを再取得（articleGrCopy） してバージョンを確認し、必要な場合は手動でarticleGr.update()を実行するロジックです。以前のワークフローのみを前提としたコードには、このロジックは必要ありませんでした。
🟣フローの処理
フローエンジンが異なるので、それぞれのフローデザインも異なります。しかし、本質的な処理は変わりません。
Legacy Workflow
Flow Designer
ZurichバージョンからFlow Designerのトリガーやアクションにナレッジ管理・リクエスト管理専用のものが追加されています。新規でフローを作成する場合にはこれらを使用する必要がありそうですね。
*️⃣移行の戦略を考えてみる
Legacy Workflowを使用している組織では、そのWorkflowの多さと大変さから移行が億劫になることでしょう。
しかし、実行しなければ進めることはできません。
ここではLegacy Workflowからどのように移行すべきか、考えてみましょう。
🟦前準備
いきなり、このブログの話をして危機感を煽るのは悪手だと思います。
（自分で書いておいてなんですが🐔）
もしあなたが、ServiceNowのパートナー企業として、クライアントのLegacy Workflowを解消する場合、事前の情報収集と分析をしたうえで計画を打ち出すべきだと思います。
移行を進めるうえで、以下のステップを検討してみます。
- Legacy Workflowの全量を把握する
- 最初の移行対象を分析して決める
- Flow Designerへ移行するフローが実現できるか確認する
- 移行計画・実行をしていく
🟦Legacy Workflowの全量を把握する
ServiceNowインスタンス内のLegacy Workflowの全量を確認し、どれだけのWorkflowが存在するのか、それらのWorkflowはどのような業務・製品機能に影響するのか把握しましょう。
Legacy Workflowは[wf_workflow]テーブルから確認可能です。
できれば、過去のストーリーや設計書からこれらのフローを作成した経緯やフローを管理する担当者やオーナーといったステークホルダーを把握しておきましょう。
🟦移行対象を分析して決める
最初に移行すべきWorkflowはどのようなWorkflowでしょうか？
まずはこれを議論する必要があります。今後順次Legacy Workflowを移行できるようにしていくことが目標になるので、移行効果が高いWorkflow、もしくは全てを移行できるか確認するために、検証にふさわしい複雑なWorkflowを選ぶべきだと思います。
🔵移行効果の高いWorkflow（影響度×労力）
早期に成果を出すために、頻繫に実行されるWorkflowかつ、移行に労力が掛からないWorkflowを優先すべきだと思います。
評価軸：
影響度＝実行回数です。
[wf_context]テーブル等を確認して、実行回数の多いWorkflowを特定します。
労力＝複雑さです。これは個人の感覚に左右されますが、アクティビティ自体の数やアクティビティ内のコードの行数、複雑な分岐やループがあるか、Flow DesignerのOOTBアクションで再構築できるのか？という観点で労力が少ないものを評価していきます。
🟦Flow Designerへ移行するフローが実現できるか確認する
「全てのWorkflowが移行できるのか？」
「何かしらの制約や障害があるのではないか？」
という議論は起こります。そのためにも、Legacy Workflowの中でも一番複雑なWorkflowや、Flow Designerで再構築する際に、気になるポイントがあるWorkflowを抽出して、検証することで、そのフィージビリティを確認するこで、全体的な移行の足掛けになると思います。
🟦移行フローの計画と改善
プロジェクトとして一気に移行するのか、
はたまた、定期的なリリースタイミングや変更会議に合わせて任意のフローを選定して移行していくのか、移行計画とやり方は組織によると思いますのでこちらは深ぼりいたしません。
しかし、改善の機会と捉えて、Legacy Workflowの要件を再確認し、あるべき姿を定義していくサイクルは回していきたいところです。
以下の動画を参考に、フローのあり方やループの考え方を予習すると単なる移行ではなく、よりパフォーマンスが改善されると思います。ご参考にしてください。
終わりに
ドキドキしながら読んでしまった方、申し訳ございません。煽るつもりはございません🙇♂️
ServiceNowとしても、全体の利用状況は把握しながらアクションを実施していくと思いますので、継続的なウォッチ
をしながら、実施できる施策を考えておくことは、無駄ではないと思います。
Legacy Workflowからの移行は、単なる技術的な更新ではありません。業務プロセスの効率化、メンテナンス性の向上、そして将来のAI活用といったイノベーションへの基盤作りです。
影響度と労力に基づき適切な優先順位を付け、ステークホルダーを巻き込みながら移行施策を進めることで、組織がプラットフォームの価値を最大限に享受できるようにしていきましょう。
移行計画の第一歩として、まずはLegacy Workflowの「棚卸し」から始めませんか？
最後まで読んでいただき本当にありがとうございました!!
ここまで読んでいただけた方はいいねとストックよろしくお願いします。
𝕏：@niwaniwa2watoをフォローいただけると嬉しく思います。