ServiceNowを従来UIからService Operations Workspaceへ移すには？ 4プロセスの回し方まで実機で確認

2026年8月9日 15:48

「Service Operations Workspaceへ移りたいが、従来のフォームを使う人はどうなるのか」。ワークスペースへの移行を検討すると、まずこの疑問が浮かびます。両方のUIは同時に使え、移行はユーザー単位で段階的に進められるというのが実機で確かめた答えです。Incident・Problem・Change・Knowledgeの4プロセスも、実際に操作してSOWでの回し方を確認しました。

検証環境：Zurich PDI / OOTB / 2026-08-09 確認

結論：3つのポイント

先に全体像を書きます。

移行に必須なのはロール（sn_sow.sow_userなど）とワークスペース本体（sys_ux_app_config）の2つ。sn_sow.sow_userには従来UIのitilロールも含まれており、1つ付与するだけで両方の画面にアクセスできる状態になります
従来UI（/incident.doなど）とSOW（/now/sow/record/...）は同時に使えます。片方の設定を変えてももう片方には影響しません。ただし独自のUI Actionやフォームレイアウトは自動では引き継がれません
Incident・Problem・Change・Knowledgeはどれも実際に状態を進められましたが、Change承認とKnowledge公開の最終ステップは、承認者・レビュアーとして指名された人でなければ実行できません。管理者権限があっても素通りはできない設計でした

第1部：従来UIからどう移行するか

移行というと大がかりに聞こえますが、やることは意外とシンプルでした。URL・ロール・着地点という3つの設定を確認するだけで、あとはユーザー単位で少しずつ進められます。以下、順番に確認します。

SOWはどのURLで開くか、従来UIとの行き来はどうするか

Service Operations Workspaceは /now/sow/home で開きます。ログイン後にこのURLへ直接アクセスすると、ウィジェット型のダッシュボードが表示されました。

従来UIへ戻る動線は、画面上部の「Workspaces」というメニューにあります。開くとフィルタ欄と、この環境で使えるワークスペースの一覧が並びました。

このメニューにはSOW以外のワークスペースも並んでいます。Knowledge Centerは独立したワークスペースアプリで、SOWとは別物でした。ナレッジ記事の一覧管理はKnowledge Center側が主な入口で、SOW側では個別のレコードだけを開けます（詳しくは第2部で扱います）。従来UI自体は「All」メニューやブラウザのブックマークからそのまま開けるので、SOWとの間に特別な切り替え操作は要りません。両方とも同じログインセッションで並行して開けます。

移行に必要なものは何か

まず必要なのはロールです。sys_user_roleをsowで検索すると6件が該当しました。

中心になるのはsn_sow.sow_userで、説明欄には「Service Operations Workspaceへのアクセスと基本操作を許可する」とあります。ロール同士の包含関係（role contains）を調べたところ、sn_sow.sow_userはitil・sn_sow.sow_home・sn_sow.sow_listの3つを内包していました。つまりこのロールを1つ付与するだけで、従来UIのインシデント権限とSOWへのアクセス権限が同時に手に入ります。

ワークスペース本体の存在はsys_ux_app_configで確認します。名前に「Workspace」を含む条件で検索すると6件ヒットし、その中に対象の「Service Operations Workspace」レコードがありました。このレコードが存在し、/now/sow/homeが実際に描画されることをもって機能が有効だと判断しています。なおsys_pluginsとsys_store_appのテーブルは、管理者権限でもREST API経由ではFailed API level ACL Validationというエラーが返り、直接の読み取りはできませんでした。プラグインの有効化状況を機械的に確認したい場合は、System Definitionのプラグイン管理画面を人が開いて確認する必要があります。

管理系のロールも2つ見つかりました。sn_sow_admin.sow_admin_center_userはSOW Admin centerへの基本アクセスを許可し、sn_sow_itsm_admin.sow_admin_userはSOW関連設定への詳細アクセスを許可します。一般ユーザーへの展開ではsn_sow.sow_userだけで十分で、管理系ロールは設定変更を担当する少数のメンバーだけに絞って付与するほうが安全です。6件のロールはいずれもElevated privilege（昇格特権）はfalseで、特別な権限昇格を必要とする作りにはなっていませんでした。

既定の着地点は変えられるか

ログイン直後にどの画面が開くかはglide.login.homeというシステムプロパティが決めています。このPDIでの値を確認しました。

このPDIではglide.login.homeはSOWを指していません。通常のホームページ（ui_page）のままでした。ここを書き換えれば全社的にSOWを既定の着地点にできると考えられますが、環境設定を壊すリスクがあるため今回は値の確認だけにとどめています。もう一つ、glide.next_experience.user_selected_landing_page_enabledがtrueになっている点も見つかりました。これはユーザーが自分で着地点を選べる設定です。全社一括で切り替える方法と、ユーザーごとに選んでもらう方法の両方が用意されていることになります。

従来UIとSOWは併用できるか

このPDIでは同じレコードに、従来UI（/incident.do?sys_id=...）とSOW（/now/sow/record/incident/...）の両方から問題なくアクセスできました。片方を無効化する操作は行っていませんが、URLの系統が完全に別（sys_ui_form系列とsys_ux_macroponent系列は独立したテーブル）なので、技術的に併用を妨げる要素は見当たりません。ロール設計もsn_sow.sow_userがitilを含む形になっており、同じユーザーが両方の画面を行き来する運用が前提になっていると考えられます。移行を全員一斉に切り替える必要はなく、ユーザー単位・チーム単位で段階的に進められます。

移行前に確認しておくこと

もう一つ実務上大事なのが、移行時に引き継がれないものです。従来UIのボタン（sys_ui_action）とSOWのボタン（sys_declarative_action_assignment）は別テーブルの別レコードで、format_for_configurable_workspaceというフラグがオンのものだけが両方に表示される仕組みになっています。フォームレイアウトについても同様に、従来UIの並び順を変えてもSOWの画面には反映されません。独自にカスタマイズしたボタンやレイアウトがある場合は、移行前に棚卸しをしておく必要があります。ここまでの内容を、移行担当者が確認すべき項目としてまとめました。

第2部：SOWで4プロセスを回す

ここからはIncident・Problem・Change・Knowledgeの4つを、実際にSOWの画面で操作して確認します。既存のデモレコードを使い、新規に作成したレコードはありません。Incidentを詳しく扱い、残り3つは同じ型で簡潔に紹介します。4つとも「一覧の開き方」「状態を進める場所」「プロセス特有の要素」という同じ3点で見ていきます。型さえ分かれば、他のテーブルでも迷わず操作できるはずです。

Incident：一覧を開いてResolveまで進める

一覧は左側の一覧アイコンから開くか、/now/sow/list/incidentに直接アクセスします。

対象にしたのはINC0000016「Rain is leaking on main DNS Server」、状態はIn Progressでした。画面の見た目はかなり違います。レコードを開くと、従来フォームのような縦一段組みではなく、中央にサマリーカード、右側にActivityと関連情報パネルという構成でした。

状態を進める操作は右上の「Resolve」ボタンです。クリックすると、画面中央にResolution codeとResolution notesの入力欄が現れました。どちらも必須項目で、未入力のままでは送信できません。Resolution codeは選択式でした。代表的な選択肢はDuplicate・Known error・Solution provided・User errorなど、全部で11種類です。

Solution providedを選び、対応内容を入力して送信すると、画面上部にトースト通知が表示され、Activityにも同じ内容のフィールド変更が記録されました。

読み取りだけで終わらせず、実際に解決させて記録が残るところまで確認できました。

Problem：マイルストーンのステップで進み方が見える

対象はPRB0000008「Hang when trying to print VISIO document」、状態はAssessでした。Problemのレコード画面には、Incidentには無かったマイルストーンのステップ表示が上部にあります。New・Assess・Root Cause Analysis・Fix in Progress・Resolvedの5段階が横に並び、現在地にチェックマークが付きます。

状態を進める操作は「Confirm」ボタンでした。追加の入力を求められることなく、クリックした瞬間にRoot Cause Analysisへ進みました。ステップ表示にもチェックが増え、ボタンのラベルも「Fix」に変わります。同時に「Add analysis」という項目が現れました。展開するとPrimary Known Error article（KB記事への参照）・Workaround・Cause notesの入力欄が並んでいます。ここがKnown Errorに関する情報を残す場所です。

本記事ではこの欄への保存は行っていません。参考として、すでにKnown Errorになっている別のデモレコード（PRB0000014、状態はResolved）も読み取りだけ確認しましたが、変更はしていません。

Change：承認を依頼するには必須項目を満たす

対象はCHG0000036「Perform maintenance on database server - bond_trading_uk」、状態はNewでした。Changeのステップ表示は8段階です。New・Assess・Authorize・Scheduled・Implement・Review・Closed・Canceledと並び、Incident・Problemより細かく分かれています。

承認は一筋縄ではいきませんでした。状態を進める操作は「Request approval」ボタンです。最初にクリックしたときは、Assignment groupが未入力だという検証エラーが表示され、先に進めませんでした。

Assignment欄からグループに「Change Management」を設定し、あらためて「Request approval」を押すと、今度は成功しました。

承認依頼を出すと、承認待ちのレコードが自動で2件作られました。承認者にはChuck TomasiとChange Managerという2名が入っていましたが、どちらも操作しているSystem Administratorではありません。そのため実際に「Approve」ボタンを押す操作は、この環境では確認できませんでした。承認者として指名された人でなければ承認できないという、当然といえば当然の制約を実機で確かめた形です。

Knowledge：Publishは1回では終わらない

対象はKB0005012「What to do when you are locked out of you computer?」です。状態はDraft、タイトルの表記はOOTBのデモデータのままでした。SOWの一般的なレコードURL（/now/sow/record/kb_knowledge/...）でそのまま開けます。

状態を進める操作は「Publish」ボタンですが、1回押しただけでは公開されません。最初のクリックで記事の詳細編集タブに切り替わり、フィールドが編集可能な状態になります。

もう一度「Publish」を押すと送信され、状態はDraftからいきなりPublishedにはならず、Reviewという中間状態に変わりました。ボタンも「Publish」から「Recall」（Draftへ引き戻す）に切り替わります。

Changeの承認と同じく、Reviewから先へ進める操作はこの環境の管理者権限だけでは見当たりませんでした。レビュー担当者として指名されている必要があると考えられます。

4プロセスの対応表

長くなったので一度まとめます。ここまでの内容を、プロセスごとに整理しました。

実機で気づいたこと

思っていたより発見が多くありました。いちばん意外だったのは、ChangeとKnowledgeで「承認・レビューの最終ステップは管理者でも素通りできない」という制約に、2回とも同じ形でぶつかったことです。承認依頼や公開申請そのものはSOWの画面から問題なく出せますが、実際にApproveやPublishを確定させる操作は、承認者・レビュアーとして名前が挙がっている人にしかできません。念のため、操作していたSystem Administratorに割り当てられた承認待ちレコードが他に無いかも調べましたが、該当は0件でした。管理者権限イコール何でもできる、ではないという設計を実機で確認できたのは収穫です。

Problemのステップ表示も印象的でした。Incidentは右上のResolveボタン1つで状態が進みます。一方でProblemは画面上部に5段階のステップ（New〜Resolved）が常に見えていて、今どこにいるかが一目で分かります。Changeはさらに8段階あり、プロセスが複雑になるほどステップ表示も細かくなる、という対応関係が見えました。

Knowledgeについては、「Publish」ボタンが1回のクリックで完結しない点に戸惑いました。最初は失敗したのかと思いましたが、実際には1回目が編集画面への遷移、2回目が送信という2段階の操作でした。似た名前のボタンでも、プロセスによって挙動が違うという点は覚えておく価値があります。

もう一つ、Workspacesメニューを開いて分かったのは、KnowledgeだけがSOWとは別の独立したワークスペースアプリだったことです。Incident・Problem・Changeは同じSOWの中で完結します。一方でKnowledgeの本格的な管理はKnowledge Center側が主戦場で、SOWからは個別記事を開けるだけという位置づけでした。4プロセスをひとまとめに「SOWで回す」と考えていると、この違いに気づきにくいと感じます。

ChangeとKnowledgeでは、先に進めなかったときの見え方も違いました。Changeは「Assignment groupが未入力」と具体的な項目名を赤いバナーで教えてくれます。一方Knowledgeは、Publishを2回押すだけで特にエラー表示はなく、静かにReview状態へ切り替わりました。同じ「すぐには完了しない」状況でも、エラーとして見せるプロセスと、次の状態として見せるプロセスがある、という違いに気づきました。

実務での使い方

移行を進める場合、最初の一歩はsn_sow.sow_userロールをパイロットユーザーの数名に付与することです。このロールにはitilが含まれているため、従来UIの操作権限を奪う心配はありません。パイロット期間中は両方のUIが並行して使える状態になるので、ユーザーの反応を見ながら対象範囲を広げられます。

Change・Knowledgeを運用に組み込む場合は、承認者・レビュアーの割り当てを先に済ませておく必要があります。SOWから申請だけは出せても、承認する人がいなければ止まったままになるためです。逆にIncident・Problemは、状態を進める操作自体は担当者本人で完結するので、比較的スムーズに移行できると考えられます。

独自にカスタマイズしたUI Actionやフォームレイアウトがある場合は、format_for_configurable_workspaceフラグの有無を確認し、対象外のものはSOW向けに作り直す計画を立てておくと手戻りが減ります。

現場への周知でも一言添えておきたい点があります。Problemのステップ表示やChangeの8段階など、SOWは「今どこにいるか」を画面上に常に出す作りです。従来UIのフォームに慣れたユーザーほど、この視覚的な違いに最初は戸惑います。操作そのものは難しくないので、画面上部のステップ表示を見る癖さえ付けば、移行後の問い合わせは自然に減っていくと考えられます。

実務でつまずきやすい点

SOWで一覧が開けない、画面が真っ白になる場合は、まずsn_sow.sow_userなどのロールが付与されているかを確認します。ロールが無いままURLだけ案内してしまうケースが少なくありません
従来UIで動いていたボタンがSOWに出てこないのは仕様通りの動きです。format_for_configurable_workspaceがオンかどうかをボタンごとに個別に確認します
Changeで「Request approval」がエラーになる場合、Assignment groupなど必須項目の未入力が原因であることが多いです。エラーバナーに具体的な項目名が表示されるので、まずそこを確認します
Knowledgeの「Publish」を押しても公開されないのは失敗ではありません。Review状態への遷移が正常な動きです。次に進めるのはレビュー担当者です
ログイン直後にSOWを開かせたい場合は、glide.login.homeの変更（全社一括）と、Next Experienceのユーザー個別設定（glide.next_experience.user_selected_landing_page_enabled）のどちらを使うか、運用方針を先に決めておきます
Problemの「Add analysis」欄は、入力しただけでは保存されません。「Save Analysis」を押し忘れて画面を離れると入力内容が失われるので、まとめて入力してから保存します

よくある質問

Q1. 従来UIとSOWのどちらかを無効化する必要がありますか

いいえ、必要ありません。このPDIで確認した範囲では、ロール設計・URL設計ともに両方が同時に使えるようになっており、片方の変更がもう片方に影響することもありませんでした。

Q2. 移行にはどのロールを付与すればよいですか

一般ユーザーにはsn_sow.sow_userで足ります。このロールはitilを含んでいるため、従来UIの権限を別途用意する必要はありません。管理系の設定を触る担当者にはsn_sow_admin.sow_admin_center_userやsn_sow_itsm_admin.sow_admin_userが必要になります。これらは一般ユーザーには不要なので、付与対象を分けて管理するとよいでしょう。

Q3. Changeの承認がSOWから完結しないのはなぜですか

SOW特有の制約ではありません。承認自体はServiceNowの標準的な仕組み（sysapproval_approver）に沿っており、SOWかどうかに関係なく、承認者として指名された人だけがApproveできます。この記事の検証では、操作していた管理者が承認者リストに入っていなかったため、承認を実行するところまでは確認できていません。

Q4. Knowledgeの記事もSOWだけで管理できますか

部分的には可能です。個別の記事を開いて編集し、公開申請までは可能でした。ただし記事の一覧管理やカテゴリ整理など本格的なナレッジ運用は、Workspacesメニューにある別アプリの「Knowledge Center」が主な入口になっていました。

Q5. パイロット導入はどの単位で進めるのが安全ですか

チームか個人単位が安全です。ロールはユーザー単位で付与できるため、少人数から段階的に進められます。Incident・Problemは担当者の操作だけで進むため始めやすいプロセスです。Change・Knowledgeは承認者・レビュアーの割り当てが先に必要になるため、その点を踏まえてスケジュールを組むと手戻りが少なくなります。最初の対象は、日常的に更新頻度が高いIncident担当チームにするのが無難だと考えられます。

まとめ

移行は一度で終わらせる作業ではありません。Service Operations Workspaceへの移行は、従来UIを止めてから始める必要もありません。sn_sow.sow_userロールの付与とsys_ux_app_configの存在確認さえできていれば、ユーザー単位で段階的に進められます。Incident・Problem・Change・Knowledgeはどれも実際に状態を動かせました。ただし承認やレビューが絡むChangeとKnowledgeは、担当者の割り当てを先に済ませておかないと申請止まりになります。独自のUI Actionやフォームレイアウトは自動では引き継がれないため、移行前の棚卸しが欠かせません。

用語

sn_sow.sow_user … SOWへのアクセスと基本操作を許可する中心的なロール。role containsでitil・sn_sow.sow_home・sn_sow.sow_listを含む
sys_ux_app_config … ワークスペースそのものの設定を持つテーブル。Service Operations Workspaceのレコードもここにあり、landing_pathなどワークスペース全体の設定を持つ
format_for_configurable_workspace … sys_ui_actionが持つ真偽値。オンのボタンだけが従来UIとSOWの橋渡し対象になり、既定値はfalse
glide.login.home … ログイン直後に開く既定の画面を決めるシステムプロパティ。ui_pageへのパスなどを値に持つ
sysapproval_approver … 承認待ちの記録を持つテーブル。承認者として登録された人だけがApprove・Rejectを操作できる
workflow_state … kb_knowledgeが持つ状態列。draft・review・published・retiredなどの値を取る

実機で確認したURL

/now/sow/home … Service Operations Workspaceのホーム画面
/now/sow/record/<table>/<sys_id> … 任意テーブルのレコードを1件開く画面（全テーブル共通のルート）
/now/sow/list/<table> … 任意テーブルの一覧画面
/now/sow/record/kb_knowledge/<sys_id> … Knowledge記事1件をSOW側から開く画面
/sys_user_role_list.do?sysparm_query=nameLIKEsow … SOW関連ロールの一覧
/sys_properties_list.do?sysparm_query=nameLIKElogin.home … 既定の着地点を決めるプロパティ
/sys_user_role_contains_list.do?sysparm_query=contains=<sn_sow.sow_userのsys_id> … ロールの包含関係一覧

参考リンク

検証環境と未検証範囲

この記事はZurich PDI（OOTB）で、実際にSOWの画面を操作して確認しました。更新したレコードは4件です。INC0000016をResolvedへ進めました。PRB0000008をRoot Cause Analysisへ、CHG0000036をAssess・承認依頼済みへ、KB0005012をReview状態へ、それぞれ進めています。新規に作成したレコードはなく、削除も行っていません。

未確認の範囲もあります。sys_plugins・sys_store_appのREST直接確認はACLで拒否され、プラグインのバージョンや有効化日時は未確認です。glide.login.homeを実際にSOWへ書き換える操作は、環境設定を壊すリスクを避けるため行っていません。Change承認とKnowledge公開の最終ステップ（Approve・Published確定）は、承認者・レビュアーへのなりすましを行っていないため未確認です。Problemの「Add analysis」欄への実際の保存も行っていません。SOWの画面デザインやボタンの配置は、ServiceNowのバージョンアップで変わることがあります。本番環境や独自にカスタマイズされた環境では、ロールの構成や承認フローの設定が異なる場合もあるでしょう。数字や画面構成は環境ごとに違っても、従来UIとSOWが別テーブル系列で独立して動くという構造そのものは共通です。