Japan Blog 記事

World Forum Tokyo 2026で体験するServiceNow Universityの世界

KoheiKatayama — Tue, 20 Oct 2026 03:30:08 GMT

こんにちは、ServiceNowトレーニングチームの片山です。

10月27日・28日にグランドプリンスホテル新高輪で開催される「World Forum Tokyo 2026」にて、ServiceNow UniversityはExpoエリアにブースを出展します。今年も「学びのための遊び場」をテーマに、昨年大好評だったブース体験をさらにパワーアップしてお届けします。新たにAI Learning Guide / SimStudioのアクティビティを加え、ポイントを集めて楽しめるLevel Up Challengeもスタート。バッジをスキャンして5つのアクティビティを巡りながら、AIによる学びの世界を体験いただける内容をご用意しました。

=====

5つのアクティビティで、あなたの「今」と「次の一歩」を見つけましょう！

Start your journey
まずはバッジをスキャンして、現在のランクを確認し、写真を撮影します。ここから「学びのための遊び場」への旅が始まります。
What’s your level?

ServiceNow Universityでの自分のランクに応じて、メーターが上昇します。Start your journeyで撮影したアバター写真は、その場でプリントして持ち帰ることができます。さらに、メッセンジャーバッグをデコレーションできるパッチもお受け取りいただけます。
Unlock your skills

「何から始めればいい？」という問いに答えるステーションです。すでに持っているスキルや身につけたいスキルを選ぶことで、そのスキルに最適なキャリアジャーニーや学習コンテンツをご提案します。
AI Learning Guide / SimStudio（NEW）

今年新たに加わったアクティビティです。AI Learning Guideとの対話をシミュレーションで体験できるほか、SimStudioでは、ServiceNow AI Platformでの実際のタスクを安全な環境で疑似体験できます。AIがどのように学びを支え、学びから実践へと進めてくれるのかを、ぜひ体感してください。
Skill my team
組織の規模等に応じて、必要なロールとスキルを探ることができます。ユーザー導入のベストプラクティスや、お客様事例もご確認いただけますので、チーム全体のスキルアップや人材育成を考える際のヒントにしてください。

Level Up Challenge：200ポイントを目指しましょう！

Start your journey以外の4つのアクティビティを体験するたびに、50ポイントを獲得できます。4つすべてを体験して合計200ポイントを達成した方の中から、各日先着100名様に、ServiceNow Universityオリジナルのメッセンジャーバッグをプレゼントします。

AIによる学びの世界を、ぜひ体験しにお越しください

AIは今、私たちの働き方を大きく変えつつあります。ServiceNowプラットフォームの価値を最大限に引き出し、ビジネスやキャリアで一歩先へ進むために、個人のスキルアップと人材育成はこれまで以上に重要になっています。ServiceNow Universityブースでは、ゲーム感覚で楽しみながら、AIを活用した学びを体験し、ご自身のキャリアや組織の人材育成につなげるヒントを見つけていただけます。World Forum Tokyo 2026にお越しの際は、ぜひServiceNow Universityブースにお立ち寄りください。皆様のご来場をお待ちしております！

World Forumでの、ServiceNow Universityの取り組み

ServiceNow Universityは、ブースのほかにもコンテンツをご用意しています。現地でのServiceNow認定資格試験の受験や、ServiceNow Universityのセッションについては、以下の紹介資料でご確認いただけます。あわせて、ぜひご覧ください。

🔗 ServiceNow University at World Forum Tokyo 2026 紹介資料はこちら

World Forumへのご登録がまだの方は以下からご登録をお願いいたします！

🔗World Forumのご登録はこちらから

日比谷オフィスでの追加開催決定！APOMトレーニングの魅力を講師インタビューでご紹介🎤

Ayane Omura — Mon, 19 Oct 2026 03:19:21 GMT

こんにちは。ServiceNowトレーニングチームです。

2026年8月に開催した、プラットフォームオーナーとしての役割や価値をグループワークで学ぶトレーニング「Adopting a Platform Owner Mindset（APOM）」は、過去最大の参加者数となり、ご好評のうちに終了しました（開催の様子はこちらの開催報告で紹介しています）。
受講者の皆様から多くの好評の声をいただいたことを受け、このたび2026年12月7日～8日に追加開催が決定しました✨

今回は追加開催に先立ち、本コースの担当講師の1人である齋藤講師(@Hideki Saito)に、受講前に気になるポイントやコースの特徴についてインタビューをしました。Platform Ownerとしての役割に悩んでいる方や、APOMコースが気になっている方、ぜひ参考にしていただけますと幸いです！

＝＝＝
※以下、Platform OwnerはPOと表記します。

Q. このコースの対象者はどのような人でしょうか？
A. ユーザー企業で現在 POの役割を担っている方や、これからPOを目指している方、パートナー企業でPOや近しい立場の方と業務で関わる方です。
また、ServiceNowを通じて、プラットフォームについて包括的に考えたい方、変更に関するメッセージの伝え方などのパワースキル（ソフトスキル）を身につけたい方にも役立つ内容です。

Q. プラットフォームオーナーとしての経験が浅くても学びを得られる内容でしょうか？
A. はい。問題ありません。
POの経験がなくても、グループワークを通じて多くのことを学び、気づくことができます。
POの立場になって、意思決定の場面を疑似体験しながら、他の参加者の視点に触れられることも大きな財産になります。

Q. SNAFなどの技術系コースとAPOMコースはどのような点が違うのでしょうか？
A. 技術系のコースは、講師がServiceNowの機能や仕組みをレクチャーして、その後ラボで手を動かすことが基本的な流れです。
一方APOMは、コースタイトルにもあるように、POとして、どのように考えて行動していけばいいのかというマインドセットを知ってもらい、POに必要なパワースキルを高めるコースで、参加者同士のコミュニケーションとグループワークを中心に進みます。

Q. クラスの雰囲気はどのような感じでしょうか？
A. 事前にチーム分けを行い、ワークだけでなく、休憩時間やお昼休みもチームでの会話が弾み、和気あいあいとした雰囲気です。

Q. チームはどのように編成されるのでしょうか？
A. 講師がコース実施前に決めています。
同じ会社の方に偏らないように、また経験豊富な方と新しくPOに関わり始めた方が偏らないように配慮しています。

Q. このコースを受けてよかったと言われる一番多い理由は何ですか？
A. 最も多いのは、POという役割について、求められる視点や心構えを体系的に理解できたという声です。
組織の中でどのような立場で価値を生み出していくかに焦点を当てた内容は、他のコースにはない学びとしてご好評をいただいています。
また、参加者同士で意見交換ができることも、オンサイト開催ならではの魅力として好評いただいております。

Q. このコースの受講前に受けておくべきコースなどはありますか？
A. 最低限、「Welcome to ServiceNow」と「ServiceNowって何？」はご受講いただければと思います。

Q. 最後に、参加を迷っている方に向けてメッセージをお願いします。
A. POやPOに関わる方が集まるのはとても貴重な機会かと思います。
日々の業務や組織の壁に直面する中で、「他の現場ではどうしているんだろう？」「自分のアプローチは合っているのだろうか？」と悩むことはありませんか？
このコースでは、同じ立場だからこそ分かり合える課題の共有や、実践的なディスカッションを通じて、明日からすぐに使えるヒントを持ち帰ることができます。
ぜひ一緒に、プラットフォームの価値を最大化するアプローチを深めてみませんか？

＝＝＝

いかがでしたでしょうか？
他の技術系のコースとは違ったAPOMコースならではの特徴や、シラバスなどからはわからないクラスの雰囲気が齋藤講師へのインタビューから感じられたかと思います。
皆様のお申し込みをお待ちしております🚀

次回開催日程：2026年12月7日(月)～8日(火)
開催場所：日比谷オフィス 30階トレーニングルーム
参加費用：1,900 Learning Credit（1,900 USD）/人

📮お申し込みはこちらから
📚シラバスはこちらから

💭過去の開催報告
2024年4月
2024年11月
2025年8月

ご質問がございましたら、トレーニングチームまでお気軽にご連絡ください。
お問合せ先：JapanTrainingOps@servicenow.com

パートナーさんと一緒にImpactを活用する編 vol.1 - まずはアクセラレーターから始めてみませんか？-

kensuketsun — Wed, 07 Oct 2026 04:39:11 GMT

みなさん、こんにちは！
ServiceNow Japan カスタマーサクセスチームのKensukeです。

突然ですが、お客様がImpactでアクセラレーターを活用される際に、パートナーさんも一緒に参加いただけることをご存じですか？

導入や運用をご支援いただいているパートナーさんにもご参加いただくことで、お客様と同じ目線で内容を理解でき、その後のご支援もよりスムーズになります。

今回は、お客様と一緒にぜひご参加いただきたいアクセラレーターをご紹介します！

⚠️ ご参加の前に：アクセラレーターはお客様のImpactのご契約にもとづくものです。パートナーさんがご参加される場合は、必ず事前にお客様の許諾を得てから進めてください。

💡 本格的な検証の前に、「ServiceNow社のベストプラクティス」に対する理解を深めていただくことが可能です

ServiceNowはメジャーリリースのたびに新機能が追加されます。最近は特にAI領域のアップデートが活発ですよね！

お客様が新機能の導入を検討される際、いきなり本格的な検証に入ると「どこを見ればいいのか」が定まらないまま進んでしまうこともあります。

そんな時は、導入検討の第一歩としてアクセラレーターを活用してみてください。「各テーマや機能に関するベストプラクティスへの理解」を深めていただくことができます。

アクセラレーターでは、お客様のインスタンスのコピーを使うので、お客様が普段使っている環境で実際の画面や設定を見ながら機能を把握できます。わからないことは担当コンサルタントに直接質問することもできます。

お客様とパートナーさんが一緒に機能への理解を深めておくことで、検証で確認したいポイントが明確になり、その後の検討もより深く進められます。

💡パートナーさんにも参加いただきたいおすすめのアクセラレーター

アクセラレーターにはさまざまな種類がありますが、今回は目的別に、お客様と一緒にパートナーさんにもご参加いただくと特に効果的なものをピックアップしました！

🚀 AI活用を検討されているお客様と一緒に（導入検討の第一歩に）

📝 Jumpstart Your GenAI

「ServiceNowで生成AIってどう使えるの？」「まずは全体像をつかみたい」

AI活用の初級編となり、生成AIとLLMの基本から、利用者目線のデモ、技術面のデモまでまとめて確認できます！

📝 JumpStart Your Now Assist Skill Kit

「Now Assistで自社向けのスキルを作れるって聞いたけど、どんなものかイメージがわかない」

「カスタムスキルがどうやって作られるのか、実際の画面で見てみたい」

「自社ならどんなスキルが作れそうか」を考えるきっかけにもなりますね！

⚠️ このアクセラレーターを活用するには、お客様側でNow Assist（AI）のライセンスが必要です。

🔧 運用改善をご支援されているお客様と一緒に

📝Jumpstart Your Upgrade

お客様にもよくおすすめしている、いわば入門編のアクセラレーターです。

「アップグレードの工数を減らしたい」「今の構成がServiceNowのベストプラクティスに沿っているか不安」

お客様がそんな課題をお持ちなら、ぜひ一緒にご参加ください！

📝TuneUp Your Security

「ServiceNow Security Centerを活用したいけどどんなものかわからない！」

「ServiceNowのセキュリティのベストプラクティスを知りたい」

「推奨されるセキュリティ構成の実装方法を知りたい」

お客様のセキュリティ強化をご支援する際にぴったりです！

📝Jumpstart Your Impact Platform Health

「Impactアプリを入れてみたけれども、まだ使いこなせていない」

「新しくなった診断スキャンの内容を知りたい」

「開発時の問題を未然に防ぐ機能や、AIを活用した開発プロセスについて知りたい」

お客様の開発・運用をご支援しているパートナーさんにおすすめです！

🔍 アクセラレーターの詳細はこちら

「そもそもアクセラレーターって何？」という方は、こちらの記事もぜひご覧ください。お申し込み方法も掲載しています。ご不明点があれば、お客様担当のCSMまでお気軽にご連絡ください。

アクセラレーターの概要について - ServiceNow Community

✅ 今回のまとめ

お客様が活用されるアクセラレーターには、パートナーさんも一緒に参加できる
新機能の導入検討の第一歩としてアクセラレーターを活用し、べストプラクティスを理解できる
運用改善なら「Upgrade」「Security」「Platform Health」がおすすめ
ご参加の際は、事前にお客様の許諾を忘れずに

お客様とパートナーさんが一緒にImpactを活用し、より良い関係を築いていただけるよう、このブログでも引き続き情報をお届けしていきます。お楽しみに！

※本記事はImpactのご契約社向けに作成しています。

※本記事の内容は執筆時点の情報です。機能の詳細や利用条件は予告なく変更される場合がありますので、あらかじめご了承ください。

ServiceNowをもっと有効活用いただく編 vol.3ーその機能リクエスト、Idea Portalに送ってみませんか？

naonakamura — Tue, 29 Sep 2026 01:30:04 GMT

みなさん、こんにちは！

ServiceNow Japan カスタマーサクセスチームのNaoです。

前回は「ServiceNowをもっと有効活用いただく編」の第2回として、リリース間の翻訳変更を事前に確認できる「OOTB差分リスト」をご紹介しました。KB1642639で確認方法を確認し、コミュニティの「ローカリゼーション」ラベルを購読しておくことで、アップグレード前に翻訳変更をキャッチできる、という内容でしたね📋

今回は第3回として、機能リクエストの送り方をご紹介します🎯

「もっとこんな機能があれば良いのに…」

「これ、どこにリクエストをあげれば良いんだろう？」

そんな風にお悩みになったことはありませんか？実は、ServiceNowにはお客様からのアイデアを募集し、製品に反映させるための場が用意されています。それがIdea Portalです。

📋 Idea Portalとは？

私たちServiceNowは、お客様から寄せられたアイデアを募集し、製品開発に反映させるための仕組みとしてIdea Portalをご用意しています。

⚠️ 注意

本機能はServiceNow IDにご登録済みのお客様限定の機能となります。リクエストがある場合は、社内のNowSupport管理者にご依頼ください。

⚠️ 注意

エンハンスメント・リクエストは製品不具合とは区別され、実現をお約束するものではありません。そのため、その実現はテクニカル・サポートの対象範囲外となります。

📋 Idea Portalアクセス方法

ServiceNow IDでNow Supoortにログイン
ユーザー設定(画面右上のユーザアイコン)をクリック
Idea Portalへ遷移

📝 リクエスト記載のコツ

良いアイデアも、伝え方次第でレビューの通りやすさが変わります。以下のポイントを意識して記載してみましょう（英語での記載が基本となります）。

分かりやすいタイトル

誰が読んでもパッと分かる、一行で機能と目的を表現します。

冒頭の「要約」

何を、誰のために、どう改善するかを1〜2文で明記します。

背景とユースケース

現状の課題（As-Is）、対象ロール、対象製品/モジュールを記載します。

目指す姿（To-Be）の提示

理想の状態と実現したい体験を記載します。参考として、画面名、フィールド、条件、既存の類似機能なども併せて記載すると効果的です。

ビジネスインパクトと期待効果

時間削減、リスク低減、品質向上などを数値・指標で明示します。

💡 Tips

「何が課題で、どうなれば嬉しいか」が具体的であればあるほど、レビューする側にも伝わりやすくなります✍️

🔍 リクエストはどのように処理されるのか？

投稿したアイデアは、以下のステータスで進行状況を確認できます。

ステータス	内容
Submitted	アイデアがコミュニティに投稿済み・投票オープン。Idea Portalに投稿されたアイデアの初期ステータスです。
Under Review	アイデアが製品レビューを進行中・投票オープン。このステータスのアイデアは6週間以内にレビュー・処理されます。
In Consideration	アイデアが将来リリースに向けて検討中。実現される可能性はあるものの、ターゲット・リリースはまだ未定の状態です。
Planned	アイデアが将来リリース向けに計画済みとして確認された状態。特定リリースを対象としたレビュー済みのアイデアとなります。
Available	アイデアが直近のリリースで実装済み。実装されたアイデアはこのステータスになります。

💡 Tips

ご自身でアイデアを投稿しない場合でも、既存のアイデアに「私も！」と思うものがあれば、ぜひ投票してみてください🔑

✅ 今回のまとめ

Idea Portalの役割と対象ユーザーを理解した
リクエスト記載の5つのコツを確認した
アイデアのステータスの流れを理解した
気になる既存アイデアに投票してみた

次回もお楽しみに！

ご不明な点はサクセスマネージャーまでお気軽にご相談ください。

※本記事の内容は執筆時点の情報です。機能の詳細や利用条件は予告なく変更される場合がありますので、あらかじめご了承ください。

「AI人材育成のリアル」に「組織的なAI人材準備の指南書」を

Kentaro Suzuki — Sun, 27 Sep 2026 14:20:52 GMT

AI人材を組織的に育成する際の指南書がServiceNow Universityで公開されています

Kentaro Suzuki — Sun, 27 Sep 2026 12:52:03 GMT

ServiceNowをもっと有効活用いただく編 vol.2-OOTB差分リストで、翻訳変更をアップグレード前にチェックしよう

naonakamura — Thu, 24 Sep 2026 00:59:11 GMT

みなさん、こんにちは！

ServiceNow Japan カスタマーサクセスチームのNaoです。

前回は「ServiceNowをもっと有効活用いただく編」の第1回として、製品ドキュメントの日本語表記に気になる点があった場合に、フィードバックを送信できる仕組みをご紹介しました。誤訳や不自然な表現、わかりにくい説明などを見つけたら、リクエストを送っていただける、という内容でしたね📋

今回は「ServiceNowをもっと有効活用いただく編」第2回として、リリース間で発生する翻訳変更を事前に確認し、スムーズなアップグレードを実現するための「OOTB差分リスト」についてご紹介します🎯

「アップグレードしたら、見慣れた用語がいつの間にか変わっていた…」

そんな経験、ありませんか？今回ご紹介する仕組みを使えば、そうした変更を事前にキャッチできます。

📋 OOTB差分リストとは？

ServiceNowでは、新しいファミリーリリースやパッチリリースのたびに、より適切な訳語への変更や表現の統一を行うことで、製品の改善に取り組んでいます。

OOTB差分リストとは、ServiceNowの標準機能における日本語翻訳の変更内容をExcel表形式でまとめたファイルです。Internationalizationチームでは、Vancouverリリース以降、このリストを各リリースごとに作成・提供しています。

💡 OOTB差分リストでできること

✔️ アップグレード前に翻訳変更を確認 — 社内への影響を事前評価
✔️ カスタマイズとの整合性をチェック — スクリプトやマニュアルの修正要否を判断
✔️ ユーザートレーニングの準備 — 変更された用語を事前に把握

アップグレード作業を計画する際に、この差分リストを併せて確認することで、思わぬ「用語が変わっていた」というトラブルを防ぐことができます。

📝 確認方法は簡単3ステップ

①使用方法を確認

KB1642639で差分リストの参照方法を確認します。

②自動通知を設定

コミュニティで「ローカリゼーション」ラベルを購読し、メール通知を受け取れるようにします。

③アップグレード前に確認

次回リリース前に該当する差分リストをダウンロードし、影響を評価します。

🔔 新しいリストの公開通知を受け取るには

ServiceNow コミュニティ > Japan Blog >「ローカリゼーション」ラベルを購読してください。

💡 Tips

現在公開されているのはAustraliaリリースが最新です。ラベルを購読しておくと、新しいリストが公開されたタイミングでメール通知が届くので、確認漏れを防げます🔑

⚠️ 注意

パッチリリースで翻訳の修正が生じない、またはごく少量の場合は、差分リストは作成されません。

✅ 今回のまとめ

OOTB差分リストの役割を理解した
KB1642639で参照方法を確認した
コミュニティで「ローカリゼーション」ラベルを購読した
次回アップグレード前に差分リストを確認する予定を立てた

次回は、機能リクエストの送り方編をご紹介します🚀 お楽しみに！

※本記事の内容は執筆時点の情報です。機能の詳細や利用条件は予告なく変更される場合がありますので、あらかじめご了承ください。

World Forum Tokyo 2026で、ServiceNow認定資格無償受験を開催します！

KoheiKatayama — Wed, 16 Sep 2026 06:34:20 GMT

こんにちは、ServiceNowトレーニングチームです。

World Forum Tokyo 2026の開催が近づいてきました。

このたび、ServiceNow Universityは、World Forum TokyoでServiceNow認定資格の現地受験を日本初開催します。しかも今回は受験料が無償——通常300〜450 USDの受験料がかからず、資格取得にチャレンジできる貴重な機会です。

開催概要

開催日時	2026年10月27日（火）〜28日（水）9:00〜17:30（最終受付 16:00）
申し込み期間	9月11日（金）〜10月26日（月）正午
会場	グランドプリンスホテル新高輪 3F 平安
受験料	無償（通常 300〜450 USD ）
対象試験	すべてのハイステークス（メインライン）資格・再試験各種
受験言語	日本語 / 英語

※一部資格の受験には、CIS – Data Foundations(CMDB and CSDM)の保有が必須です。詳細はお申し込みサイトでご確認ください。
※受験枠に限りがございますので、お早めのご予約をおすすめします。
※本プログラムは、World Forum Tokyo 2026にご登録いただいている方のみが対象です。まだご登録がお済みでない方は、下記リンクからWorld Forum Tokyo 2026へのご登録をお願いいたします。

こんな方におすすめです

ServiceNowの認定資格は、どなたでも取得できます。ServiceNowのお客様・パートナーの方はもちろん、ServiceNow AI Platformに関心のある方にも、資格取得を通じて数多くのメリットを得られます。

即戦力の証明：Fortune 500企業の85%以上を含む約8,400の組織に信頼されるプラットフォームで、即戦力となるスキルを備えていることを示せます

成長市場でのキャリアアップ：2025年にサブスクリプション収益が約129億ドル(前年比21%増)に達する、成長を続けるAIプラットフォームを活用するスキルと自信を身につけられます

共有可能なデジタルバッジ：取得した成果を、雇用主やネットワークにアピールできる、共有可能なCredlyデジタルバッジを獲得できます

受験者へのギフト🎁

受験者全員にServiceNow Universityノベルティをプレゼントします！合格者には先着100名様に、ServiceNow University オリジナル Cap をお渡しします。

お申し込みについて

受験枠には限りがございます。当日も可能な範囲で受け付ける予定ですが、確実に受験されたい方は事前のご予約を強くおすすめします。また、会場受験のお申し込みは、World Forum Tokyo 2026へのご登録が前提となります。

👉 まだWorld Forum Tokyo 2026にご登録でない方はこちら

👉現地受験のお申し込み・試験カタログ・FAQはこちら

World Forum Tokyo 2026へのご来場予定の方は、ぜひこの機会に資格取得へ挑戦してみてください。

会場では現地受験のほか、ServiceNow University の Expo ブースやセッションもご用意していますのでこちらからぜひ詳細をご確認ください。

皆さまのご来場をお待ちしております！

ServiceNowをもっと有効活用いただく編 vol.1-製品ドキュメントの日本語、気になったことはありませんか？

naonakamura — Wed, 16 Sep 2026 01:03:07 GMT

みなさん、こんにちは！

ServiceNow Japan カスタマーサクセスチームのNaoです。

今回から新しいシリーズ「ServiceNowをもっと有効活用いただく編」をスタートします。ServiceNowにはたくさんの便利な仕組みがありますが、意外と知られていない機能や制度がまだたくさんあります。このシリーズでは、そうした「もっと有効活用できるポイント」を少しずつご紹介していきます📋

第1回のテーマは、製品ドキュメントの日本語表記に関するフィードバック制度です。

「この説明、日本語だとちょっとわかりにくいな…」

「これって直訳っぽくて意味が伝わりにくいかも…」

ServiceNowの製品ドキュメントを読んでいて、そんな風に感じたことはありませんか？実は、そうした気になる点を改善リクエストとして送ることができるんです。ご存知でしたでしょうか？🎯

💡 こんなときにフィードバックをお送りください

以下のようなケースに気づいた際は、ぜひフィードバックをお送りください。

✔️ 誤訳や不自然な日本語表現
✔️ わかりにくい説明や用語
✔️ 情報の不足
✔️ その他、改善が必要と思われる点

「小さな違和感でも送っていいのかな？」と思われるかもしれませんが、そうした細かい気づきの積み重ねが、ドキュメント全体の質の向上につながります。気になった点があれば、遠慮なくお送りください。

📝 フィードバックの送り方

フィードバックの送信手順は、とてもシンプルです。

1.フィードバックボタンをクリック

製品ドキュメント各ページ右上の[フィードバック] ボタンをクリックするか、または記事の下にある [このトピックは役に立ちましたか?] で [いいえ] をクリックします。 [このコンテンツの改善点があればお知らせください】というダイアログボックスが表示されます。

2.改善点を選択【このトピックは役に立ちましたか?] で [いいえ] を選択すると、改善点を入力できるようになります。【このコンテンツの改善点があればお知らせください ]で当てはまる改善点を選択します(複数選択可)。

3.具体的な内容を記入【コメント】欄に、問題点の具体的内容を記入します (日本語でOKです)。

4.スクリーンショットを添付(推奨) [アップロードするファイルを選択してください】をクリックするとファイルを添付できます。できる限りスクリーンショットを添付いただくと、問題箇所の確認に役立ちます。

5.メールアドレスを入力 (任意) 【メールアドレス (オプション)】に連絡先メールアドレスを入力します。 ※匿名でも送信可能です

🔍 フィードバックの確認・対応について

お送りいただいたフィードバックは、ServiceNow Internationalization チームの担当者が随時確認のうえ、対応しております。

⚠️ 注意

内容によっては反映までにお時間をいただく場合があります。あらかじめご了承ください。

✅ 今回のまとめ

製品ドキュメントの日本語に「フィードバック」を送れることを知った
誤訳・不自然な表現・わかりにくい説明などを見つけたら送ってみる

次回は、リリース間の翻訳変更をリストで確認する方法をご紹介します🚀 お楽しみに！

※本記事の内容は執筆時点の情報です。機能の詳細や利用条件は予告なく変更される場合がありますので、あらかじめご了承ください。

「CVSS 7.0以上は30日以内」はもう古い？ ― CISA BOD 26-04にServiceNow VRでどう対応するか

ESL — Tue, 15 Sep 2026 00:57:04 GMT

はじめに：「CVSS 7.0以上は30日以内」― その運用、まだ続けていますか？

多くの企業の脆弱性管理規程には、こうした期限が定められています。

Critical（CVSS 9.0以上）：15日以内
High（CVSS 7.0以上）：30日以内

日本企業で最もよく見かける運用のひとつです。監査でも説明しやすく、社内規程にも書きやすい。

では、この運用は現在の脅威環境において、まだ適切でしょうか。

この数字はどこから来たのか

「Critical 15日／High 30日」という組み合わせの直接の出自は、米国CISAが2019年4月に発出した拘束的運用指令 BOD 19-02「Vulnerability Remediation Requirements for Internet-Accessible Systems」 です。インターネット公開システム上のCritical脆弱性は初回検知から15暦日以内、Highは30暦日以内に修復せよ、という要件でした。さらに遡ると、2015年のBOD 15-01が「Criticalを30日以内」と定めています。PCI DSSの要件6.3.3も、深刻度の高いパッチを1か月以内に適用することを求めています（対象範囲はバージョンにより異なります^※1）。

日本の多くの規程が参照している数字は、この系譜の上にあります。つまり、2019年時点の脅威環境を前提に設計された期限です。

図1：「30日ルール」の系譜と、BOD 26-04による転換

2019年と現在で、何が変わったか

7年前の前提が、いま成り立っているかを確認します。

攻撃側の速度が上がりました。2026年版のVerizon Data Breach Investigations Report（22,000件超の侵害を分析）では、脆弱性の悪用が初期侵入ベクターの第1位となり、31%を占めました。前年の20%から上昇し、同レポート19年の歴史で初めて認証情報の窃取が首位から陥落しています^※2。

防御側の速度は下がりました。同レポートによれば、CISA KEV（悪用が確認された脆弱性カタログ）に掲載された脆弱性が完全に修復された割合は26%で、前年の38%から低下。完全解決までの日数の中央値は32日から43日へと延びています。

つまり「30日」という期限は、すでに中央値で守られていません。規程に書かれている数字と、現場が実際に到達できる速度が乖離しています。

そして2026年、AIが変数として加わりました。脆弱性の発見から悪用までの時間が、AIによってさらに圧縮されつつあります。日本でもこれは政策課題として扱われており、2026年5月18日に政府全体のパッケージ「Project YATA-Shield」が公表され、5月22日には金融庁と日本銀行が連名で金融機関等に対し「フロンティアAIによる脅威変化を踏まえた短期的な対応」を要請しています。後者では、CVSSスコアだけに依存しないリスクベースの優先順位付けが明示的に求められました（詳細は第3章）。

そして、30日ルールの源流は撤回されました

2026年6月10日、CISAはBOD 19-02を廃止しました。

後継として発出されたのが BOD 26-04「Prioritizing Security Updates Based on Risk」 です。BOD 19-02と、KEV対応を定めたBOD 22-01の両方を廃止・統合し、CVSSの深刻度に応じて一律の期限を割り当てるという、10年以上続いた考え方を明確に転換しました。

BOD 26-04は米国連邦民間行政機関（FCEB）向けの指令であり、日本企業に法的拘束力はありません。しかし、自社の規程が参照している数字の源流が撤回されたのであれば、なぜ撤回されたのか、そして代わりに何が採用されたのかは知っておく価値があります。

本記事では、BOD 26-04が採用した優先順位付けの仕組みを整理したうえで、それをServiceNow Vulnerability Responseでどう実装するかを検討します。

1. BOD 26-04の要点 ― 実装に必要な範囲だけ

BOD 26-04の全体解説は他に良い記事があるので、ここではServiceNowで実装する際に必要になる部分だけを押さえます。

1-1. 4つの二値変数

BOD 26-04は、CERT/CCが策定した SSVC（Stakeholder-Specific Vulnerability Categorization）の決定木に基づき、以下4つの変数の組み合わせで是正期限を決定します。

変数	判定内容
Asset Exposure （公開曝露）	当該資産がインターネット等から到達可能か
KEV Status	CISA Known Exploited Vulnerabilities カタログに掲載されているか
Automatable （悪用の自動化可能性）	攻撃者がキルチェーンのステップ1〜4（偵察・武器化・配送・エクスプロイト）を信頼性高く自動化できるか
Technical Impact （技術的影響）	Total（ソフトウェア挙動の完全な制御、または当該システム上の全情報の完全な開示）か、Partial（限定的な制御・情報露出）か

1-2. 是正期限の決定表（16通り・5階層）

4変数はいずれも二値なので、組み合わせは16通りです。実装ガイダンスの判定表（Appendix A / Table 1）は、この16通りを5つの是正期限に対応づけています。

是正期限	KEV	公開曝露	自動化	技術的影響
3日＋フォレンジック調査	yes	yes	yes	Total
	yes	yes	no	Total
	yes	no	yes	Total
3日	yes	yes	yes	Partial
3日	no	yes	yes	Total
14日	yes	yes	no	Partial
	yes	no	yes	Partial
	yes	no	no	Partial
	yes	no	no	Total
	no	yes	yes	Partial
	no	yes	no	Total
60日	no	yes	no	Partial
	no	no	yes	Partial
	no	no	yes	Total
次回システム更新時（＝延期）	no	no	no	Total
次回システム更新時（＝延期）	no	no	no	Partial

条件式を誤りやすい箇所です。「KEV収載かつ Technical Impact = Total なら3日＋フォレンジック」と要約したくなりますが、KEV=yes・曝露=no・自動化=no・Total の組み合わせは14日です。最上位階層に入るには、Total かつ KEV収載に加えて公開曝露または自動化のいずれかが必要です。ベンダー各社の解説でもこの点が省略されている例があるため、条件式は必ず判定表と照らして組んでください。

図2：4変数から是正期限が決まる構造

この数字がBOD 26-04の本質です。厳しくなったのではなく、「本当に急ぐべき1%」を特定してリソースを集中させ、残りを正式に延期してよいと認める仕組みです。全件を同じ期限で追いかけるのをやめる、という意思決定がここにあります^※3。

1-3. 期限が「動く」という設計

もうひとつ実装上重要な特徴があります。是正期限は静的ではありません。

KEVに新規収載された → 期限が短縮される
当該システムをインターネットから切り離した → 「公開曝露」がNoになり、期限が緩和される

つまり緩和策（mitigation）が期限計算に反映されます。「すぐに直せないなら曝露を減らす」という現実的な選択肢が、制度に組み込まれています。最上位階層では、完全なパッチ適用だけでなく緩和アクションも期限充足として扱われるとされています。

また、期限のカウント起点は「KEV収載時」または「当該資産上での検知時」のいずれか早い方です。曝露状況が判定できない資産は「公開曝露あり」とみなされ、最短のクロックが適用されます。分からないものは危険側に倒す設計です。

この章のポイント：BOD 26-04は「4つの二値変数 → 16通り → 5階層の是正期限」という決定木であり、スコアリングモデルではありません。そして期限は状況変化に応じて動的に変わります。この2点が、次章の実装設計をそのまま決めます。

2. ServiceNow VRでどう対応するか

前提のお断り：本セクションはServiceNow公式のコンプライアンスマッピングではありません。製品機能から実装方法を検討したものであり、BOD 26-04への準拠を保証するものではありません。実装は各組織の要件に基づいて設計・検証してください。

2-1. Risk Calculator は2層でできている

BOD 26-04をServiceNowで実装しようとすると、多くの方がまずRisk Calculatorの重み付けを調整しようとします。その方向は行き止まりです。ただし理由は「Risk Calculatorが使えないから」ではありません。Risk Calculatorは2つの層でできていて、どちらの層を使うかで答えが正反対になります。

図3：Risk Calculator の2層構造 ― ルール層は決定リスト、値の層は加重加算

そもそも考え方が違う ― 加重加算は使いようがない

加重加算（Scoring Criteria）は、変数ごとに固定の点数を割り当てて合計するモデルです（Calculator._runRiskCalculation()）。「Total は25点」と決めたら、他に何が付いていようが常に25点を足します。

BOD 26-04はそういうモデルではありません。同じ変数でも、他に何が揃っているかで効き方が変わります。判定表から「Total を足す場合」と「曝露を足す場合」を、同じ土台の上で比べてみます。

土台	Total を足すと	曝露を足すと
なし（KEV・曝露・自動化なし）	次回更新時（最下位）	60日（1つ上）
KEV ＋自動化	3日＋フォレンジック（最上位）	3日（1つ下）

同じ2変数の比較なのに、土台によって強弱が逆転しています。攻撃経路が何も無いときに効くのは「機会」（曝露）で、KEVと自動化がすでに揃っているときに効くのは「影響」（Total）だからです。変数が互いに影響し合う ― SSVCが決定木を採用しているのは、この性質があるためです。

ルール層は「order 昇順・最初の一致で確定」する決定リスト

一方、ルール層の挙動は加重加算ではありません。Calculator._applyCalculators() は1つのCalculator group内でルールを order 昇順に評価し、最初に条件が一致したルールを適用した時点で break します。加算も上書きもしません。

Risk Calculator Rule は順序付き決定リストです。上から順に評価し、当たったところで止まる。これは決定木を平坦化したものと同じ構造であり、BOD 26-04の判定表をそのまま書き下せます。

条件の指定方法も3通りあります。condition_type は Filter ／ Filter group ／ Script。Script条件（advanced_condition）は GlideScopedEvaluator で評価され、current にFindingのGlideRecordが渡されます。

2-2. 設計方針 ― ServiceNow本来の流れに載せる

ServiceNowの思想は「Risk Score を計算 → Severity（Risk Rating）を決定 → 修復ターゲットを決定」です。そしてBOD 26-04の5階層は、Risk Ratingの5段階にちょうど対応します。

図4：4変数 → Risk Score → Risk Rating → 修復ターゲットの流れ

Risk Ratingの境界値は固定ではなく、テーブル sn_sec_calculator_risk_score_weight にFindingテーブルごとのレコードとして定義されています。CalculatorUtils.getRiskRatingFromRiskScore() が「risk_score以上の上限を持つ最初のRating」を返す仕組みです。

Risk Rating	risk_score 範囲（既定）	BOD 26-04 の是正期限
1 − Critical	90 – 100	3日＋フォレンジック調査
2 − High	70 – 89	3日
3 − Medium	40 – 69	14日
4 − Low	1 – 39	60日
5 − None	0	次回システム更新時（ルールを当てない）

この設計を採るときのトレードオフ。risk_score が「深刻度」ではなく「BOD Tier」を意味する値に変わります。①OOTBのRisk Calculatorルール（後述の「Technical Impact」、order 1000）には到達しなくなる ②risk_score が「深刻度」ではなくTierを表す値になる ③risk_rating を参照している既存のダッシュボード・SLA・アサインメントルールの棚卸しが要る ― の3点は事前に判断してください。②の副作用（Tier内の着手順にスコアを使えなくなる）への対処は 2-4 で扱います。

2-3. 4変数と標準項目の対応 ― 実機で確認した構成

4変数 × フィールド確定表

先に結論を置きます。実装で参照するフィールドは以下の4つです。

#	BOD 26-04の変数	フィールド	テーブル	選択値
1	KEV Status	cisa_exists	sn_vul_entry	true / false
2	Automatable	automatable	sn_vul_entry	yes / no（小文字）
3	Technical Impact	technical_impact	sn_vul_entry	total / partial（小文字）
4	Asset Exposure	internet_facing	cmdb_ci_hardware	true / false

1〜3はVulnerability Entry側の値、4だけは資産側の値です。この非対称性が実装設計を決めます。

実装前に確認すべき3点。

列が存在しない環境がある。これらの列を追加しているのはNVD連携アプリではなく Central Vulnerability Database（sn_sec_cvd） です。CVDはUSEM前提のアプリなので、USEMへ移行していない環境では列そのものが無い可能性があります
紛らわしい同名フィールドがある。CVSS v4のSupplemental Metricsが v4_ 接頭辞で6項目実装されています（v4_automatable ほか）。選択値も大文字の YES / NO / NOT_DEFINED で体系が違います。接頭辞なしの automatable がSSVC判断点です
連携を回すまで値は入らない。Automatable と Technical Impact はCISAがVulnrichmentで付与し、NVD 2.0 API経由で取り込まれます。アプリのバージョンを上げただけでは0件のままで、NVD連携を有効化して同期を回して初めて値が入ります（実測では全CVEの約47%、KEV収載済みは100%）

Asset Exposure

4変数のうち、CISA側がデータを提供していないのはこれだけです。CMDB CI の internet_facing 属性が該当します。

internet_facing 属性は cmdb_ci_hardware 配下のクラスにしか定義されていません。cmdb_ci など、それ以外のクラスのCIでは internet_facing 自体が存在せず、値は常にNullになります。この場合はBOD 26-04の「判定できない資産は公開曝露ありとみなす」という原則に従い、値が空のときも true として扱う処理を明示的に実装してください。2-4のScriptではこの処理を行っています。

2-4. 実装 ― Risk Calculator 5本＋ Remediation Target Rule 4本

ここが実装の中核です。決定木はRisk Calculator側に置き、Remediation Target RuleはRisk Ratingだけを見る4本に単純化します。

Risk Calculator ― 5本のルールで16通りを表現する

16通りの組み合わせを見て「ルールを16本作るのか」と考えてしまいますが、その必要はありません。上から順に評価して最初に当たったところで止まるという性質のおかげで、上位ほど狭い条件を置くだけで済みます。

k = KEV収載   e = 公開曝露   a = Automatable   t = Technical Impact が Total

order 100   k && t && (e || a)        → risk_score 100  → Critical → 3日＋フォレンジック
order 200   (e && a) && (k || t)       → risk_score  80  → High     → 3日
order 300   k || (e && (a || t))        → risk_score  50  → Medium   → 14日
order 400   e || a                      → risk_score  20  → Low      → 60日
order 500   true                        → risk_score   0  → None     → ルールを当てない

各ルールは Condition type = Script／Value type = Script で作ります。条件スクリプトの中身は4変数の読み取りだけです。

var v = current.vulnerability;
var k = (v.cisa_exists == true || v.cisa_exists == '1');
var a = (v.automatable + '' == 'yes');
var t = (v.technical_impact + '' == 'total');

var ci = current.cmdb_ci;
var iface = (ci && !ci.nil()) ? (ci.internet_facing + '') : '';
var e = !(iface == 'false' || iface == '0');   // 空も true ＝ BODのfail-safe

return k && t && (e || a);                     // ← ルールごとにここだけ差し替える

SSVCが空のときの扱いを、このスクリプトで明示的に決めてください。上の書き方は automatable が空なら no、technical_impact が空なら partial として扱います。黙って安全側でない方に倒れるので、意図した挙動かを確認する必要があります。実機ではSSVCが入っているCVEは半数弱でした（ただしKEV収載済みは100%入っているため、最上位Tierの判定は穴に落ちません）。

値が空のときにCVSSから近似するなら、technical_impact は v3のCとIがともに HIGH なら total（ServiceNow標準のRisk Calculatorルールと同じ判定式）、automatable は AV:N + AC:L + PR:N + UI:N（＝ネットワーク到達可能なRCE）で導出できます。EPSSは連続値で二値化の閾値に根拠が置けないため、この用途には使いません。

推定値を使った場合は、その旨をVulnerable Item側に記録してください。BOD 26-04が決定木を採用した理由は説明可能性です。監査で「なぜ14日なのか」と問われたときに「Technical Impactが推定値だから」と答えられなければ、決定木の利点が失われます。導出元を示すフィールドを1つ持つか、work notesに残す形で足ります。

自作ルールは order 1000 より前に置いてください。OOTBの「Technical Impact」ルールが order 1000 にあり、条件が active=true なので必ず一致します。後ろに置くと自作ルールには到達しません。

逆に、上記の order 500（条件 true）を置いた時点でOOTBの「Technical Impact」ルールは二度と実行されません。この環境の risk_score はBOD Tierを意味する値に変わります。意図した上書きであることを設計文書に明記してください。

Remediation Target Rule ― 4本。条件は Risk Rating だけ

ルール名	Target (days)	Condition	Target from
BOD 26-04 T1 Critical	3	risk_rating = 1	first_found
BOD 26-04 T2 High	3	risk_rating = 2	first_found
BOD 26-04 T3 Medium	14	risk_rating = 3	first_found
BOD 26-04 T4 Low	60	risk_rating = 4	first_found
Rating 5（None）にはルールを作らない ― ターゲット日なし＝「次回システム更新時」

4本の条件は互いに排他なので、複数一致は起きません。Tierの判定ロジックはRisk Calculator側に集約され、こちらは対応表を書くだけになります。

同じ「3日」の中では Critical を先に着手する

T1（Critical）とT2（High）は、期限としてはどちらも3日です。しかし同じ3日の中では Critical を先に処理します。フォレンジック調査が必要な最上位階層だからです。

より細かい順序 ― 同じCriticalの中でどの案件から着手するかは、BOD 26-04が規定する領域ではありません。従来のCVSS順など、各社の脆弱性対応準則に沿って判断してください。

「3日＋フォレンジック調査」をどう表現するか

T1とT2は期限が同じ3日なので、Remediation Target Rule上は同じ日数になります。差分であるフォレンジック調査は、Risk Rating = Critical を条件にFlow側で表現します。

Flow Designer で Vulnerable Item の作成・更新をトリガーに risk_rating = 1 を評価し、一致したら ①フォレンジック・トリアージ用の Remediation Task を生成 ②Security Incident Response で Security Incident を起票 する構成が素直です。既存の Remediation Task Rule や Assignment Rule にも相乗りできます。

「次回システム更新時」をどう表現するか

Remediation Target Rule は日付を算出する仕組みで、「次回更新時」という無期限の概念を直接は持ちません。Rating = None（risk_score 0）にルールを当てず、ターゲット日なしのまま運用してダッシュボードで別管理するのを推奨します。無理に長い固定日数を割り当てるとBODの意図が歪み、将来のOOTB対応やBOD準拠レポートとの整合も取りにくくなります。

2-5. 期限を動的に再計算する

BOD 26-04の設計思想の核心は「期限は静的ではない」ことです。初回検出のあとにKEVへ収載されたら期限は縮み、資産をインターネットから切り離したら緩む。この往復をどう成立させるかが、実装の最後の論点です。

OOTBで再計算が走るのは KEV の変化だけ

変更を検知して再計算を起動する経路は、4変数で揃っていません。

変数	変更を拾う仕組み	再計算
KEV Status	BR「Set recalculate flag (CISA)」（filter cisa_existsVALCHANGES）→ recalculate_flag → ジョブ「Run severity calculator」	自動で走る
Automatable	監視しているBRが無い	走らない
Technical Impact	同上	走らない
Asset Exposure	CMDBの属性変更はVRに伝播しない	走らない

埋めるべき3つの穴

SSVC変更のトリガーを作る ― sn_vul_entry にBRを1本追加し、filter を automatableVALCHANGES ^NQ technical_impactVALCHANGES にして current.recalculate_flag = true を立てるだけです。CISA用のBRと同じ形で、以降はOOTBのジョブが拾います。スコープは sn_vul で作る必要があります（globalスコープからはテーブルを更新できません）
曝露変更のトリガーを作る ― cmdb_ci_hardware.internet_facing の変更を拾うBusiness Rule／Flowで、その CI に紐づく active な Vulnerable Item を touch して Risk Calculator を再実行させます。CVE側の recalculate_flag は資産単位の変更には使えないため、VIを直接叩く経路が要ります
保険としての一括再計算を持つ ― Risk Calculator グループには OOTB で「Reapply」（背景ジョブ "Reapply Risk Calculators"）があります。日次で回すか、規模が許すなら active な VI 全件の再計算ジョブを持つ。①②を作っても取りこぼしは出るため、突き合わせの意味があります

再計算時の起点日 ― Recalculation method の選択

同じ「KEV収載でTierが上がる」でも、ルールの Recalculation method の選択で期限がまったく変わります（first_found = 2026-06-01、KEV収載の検知が2026-08-20のケース）。

Recalculation method	算出される期限	意味
Default calculation（既定）	2026-06-15	first_found + 14。検知日起点。BODの「KEV収載時または資産上での検知時のいずれか早い方」に忠実。ただし即座に期限超過になる
Recalculate from risk change date	2026-09-03	KEV収載を検知した日 + 14。運用しやすいが、BODの起点定義からは外れる

BOD準拠を優先するならDefault calculation（既定）です。ただし「古い検出がKEV入りすると即座に期限超過になる」という運用上の帰結も込みで判断してください。

2-6. 実装ステップの推奨順序

NVD連携・CISA連携アプリを導入し、CMDBの internet_facing を整備します。Risk Calculator に5本、Remediation Target Rule に4本のルールを作成し（Rating = None にはルールを作らない）、再計算トリガーの穴を埋めます。Tier内の着手順（Criticalを優先）、フォレンジック起票、延期ワークフローもあわせて設計してください。

2-7. アンチパターン ― 作り込みすぎないために

よくある失敗は、加重加算でTierを再現しようとする、ルールの評価順序を誤る、曝露のfalse落としを怠る、再計算トリガーをKEVだけで済ませる、Remediation Target Ruleを16本作るの5つです。SSVCの器と取込コードは既に標準で存在し、将来OOTB対応が進む可能性もあるため、過度なカスタマイズは避け、移行しやすい最小構成に留めてください。

3. 日本企業への示唆 ― 金融庁・日銀要請との対比

BOD 26-04は米国連邦民間行政機関向けの指令であり、日本企業に法的拘束力はありません。それでも参照する価値があると考える理由は、日本でも同じ方向の要請が、ほぼ同時期に出ているからです。

3-1. 2026年5月、日本でも同じ問題に答えが出た

2026年5月18日、国家サイバー統括室を中心に14の省庁・機関が参加する政府全体のパッケージ 「Project YATA-Shield」 が公表されました。フロンティアAIモデルによる脆弱性の発見・修正等の性能向上に備え、重要インフラ事業者等への対応と脆弱性の発見・修正等への対応の双方に取り組む必要があるとしています。

その金融分野における実装として、5月22日に金融庁と日本銀行が連名で、金融機関等に対し 「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」 を要請しました。経営トップを含めた経営層の直接関与のもと、概ね1ヶ月程度を目途に9項目の対応を進めることが期待されています。

9項目のうち、本記事のテーマに直接関わるのが次の2つです。

項目②「優先的に対応すべきサービス／ITシステムを特定する」：リソースが有限であることを前提にリスクベースで重点配分し、インターネットバンキング等の外部公開ITシステムを最優先とする
項目⑥「パッチ適用プロセスをリスクベースにする」：CVSSスコアや攻撃コードの有無だけでなく、自組織への影響と攻撃成立の蓋然性を踏まえて優先順位を付ける

BOD 26-04を読んだ後にこれを読むと、同じことを言っているのが分かります。

3-2. 日米の対比

論点	金融庁・日銀要請（2026年5月22日）	CISA BOD 26-04 （2026年6月10日）	関係
法的性格	要請（拘束力なし）	Binding Operational Directive（FCEB機関に拘束力）	相違
優先順位の考え方	CVSSスコアだけに依存せず、自組織への影響と攻撃成立の蓋然性で判断	CVSSを必須入力から外し、4変数で是正期限を決定	一致
期限の具体性	9項目全体で「概ね1ヶ月」。手法・数値は規定しない	16通りの組み合わせで3日／14日／60日／延期を厳密規定	相違
外部公開資産	インターネットバンキング等を最優先	Asset Exposure を4変数の1つとして重視	一致
実際の悪用の重視	CVSSが高くない脆弱性でも実際に悪用されている実態を考慮	KEV収載を最重要トリガーとして扱う	一致
パッチ以外の対策	仮想パッチ・WAF・分離等と、リスク受容手続の整備	曝露除去等の緩和アクションを期限充足として受容	一致
動機	フロンティアAIによる脆弱性の大量発見・悪用高速化	AIによる開示から武器化までの時間圧縮	一致

動機も方向も同じです。違いは、CISAが4変数16通りの決定表と数値期限で厳密に規定する拘束的指令である一方、金融庁要請は手法を規定しない原則ベースの要請だという点です。

3-3. だからBOD 26-04が実装の参考になる

日本のガイドライン・要請は「リスクベースでやりなさい」とは言うものの、その具体的な判定ロジックは各組織に委ねられています。デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」（DS-221）も、CVSSの基本評価基準は脆弱性の技術的特性を示すものであり、それ単体で対応の優先度を決めるべきものではない、という趣旨を示していますが、代わりに何を使うかは示していません。

ここがBOD 26-04の使いどころです。「リスクベースの優先順位付け」を、具体的な変数と期限の対応表まで落とし込んだ、最も詳細な公開仕様のひとつとして参照できます。社内の脆弱性管理規程を改定する際、「米国連邦政府はこの4変数でこの期限を設定している」という事実は有力な論拠になります。

前身のBOD 22-01（KEVカタログ）が米連邦向け指令から民間の事実上の標準へ広がった経緯を思い出せば、同じ経路をたどる可能性は十分にあります。

まとめ

BOD 26-04が示した新しい運用

「CVSS 7.0以上は30日以内」という運用の源流であるBOD 19-02は2026年6月に廃止され、後継のBOD 26-04が示したのは「もっと厳しくやれ」ではなく「絞れ」というメッセージでした。CVSS一律の期限設定をやめ、曝露・KEV・自動化可能性・技術的影響の4変数、16通りの組み合わせで優先順位を決めます。急ぐべきは全体の約1%、60%以上は正式に延期してよく、期限は状況に応じて動的に変わります。同じ方向の要請は、日本でも2026年5月に金融庁・日銀から出ています。

現行バージョンのServiceNowでの対応 ― 過剰なカスタマイズは不要

BOD 26-04の5階層は、Risk Ratingの5段階（Critical / High / Medium / Low / None）にちょうど対応します。そのためRisk Score を計算 → Severity を決定 → 修復ターゲットを決定というServiceNow本来の流れに、思ったより作り込まずに載せられます。決定木はRisk Calculatorのルール層（5本）に、対応表はRemediation Target Rule（4本）に置くだけで16通りを再現でき、着手順（Criticalを先に処理する等）もRisk Ratingで自然に決まります。実データで16通りすべての判定と期限の一致も確認済みです。

ただしこの領域は製品側でOOTB化が進行中でもあります。将来的に4変数から期限を決める機能そのものが標準提供される可能性もあるため、過剰なカスタマイズはせず、移行しやすい最小限の構成に留めるのが賢明です。

自社の脆弱性管理規程に「CVSS 7.0以上は30日以内」と書かれているなら、その数字の出自と、それが撤回された理由を一度確認してみてはいかがでしょうか。

※1 PCI DSS 要件6.3.3の対象範囲はバージョンにより異なります。v4.0では Critical および High のパッチを1か月以内としていましたが、v4.0.1では対象が Critical 深刻度に限定されたとする解説があります。実際に参照する際はPCI SSCの原文で対象バージョンを確認してください。

※2 この数値には留保があります。2026年版DBIRから「pretexting」が新規の初期侵入ベクターとして追加され、従来「認証情報の悪用」に計上されていた一部が再分類されました。レポート自身が、この変更がなければ認証情報の悪用は13%ではなく16%だったと明示しています。同一基準で見ると、アイデンティティ関連の初期侵入（フィッシング16%＋認証情報の悪用16%）は32%となり、脆弱性悪用の31%とほぼ並びます。「脆弱性悪用が1位」は事実ですが、アイデンティティ関連の脅威が後退したという意味ではありません。

※3 「約1%」「60%超」という数値はCISAに帰属する試算として報じられているものですが、筆者が確認した範囲ではCISAの一次文書内での記載を確認できていません。第三者ベンダーの分析記事経由の情報である点にご留意ください。

参考情報

CISA：BOD 26-04: Prioritizing Security Updates Based on Risk
https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
CISA：BOD 26-04 Implementation Guidance
https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
CERT/CC：CISA BOD 26-04 Response Model（SSVC決定表）
https://certcc.github.io/SSVC/howto/cisa_response/
金融庁・日本銀行：「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請（2026年5月22日）
https://www.fsa.go.jp/news/r7/sonota/20260522-5/20260522.html
国家サイバー統括室：AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について～Project YATA-Shield～（2026年5月18日）
https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Package.pdf
デジタル庁：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221）
Verizon：2026 Data Breach Investigations Report
CISA：Unlocking Vulnrichment: Enriching CVE Data
https://www.cisa.gov/news-events/news/unlocking-vulnrichment-enriching-cve-data
GitHub：cisagov/vulnrichment（README にSSVCデータの格納仕様の記載あり）
https://github.com/cisagov/vulnrichment
ServiceNow Docs：Remediation target rules（Vulnerability Response > Administration）
ServiceNow Store：Vulnerability Response Integration with NVD（v30.4.2 のリリースノートにSSVC取込の記載あり）
https://store.servicenow.com/store/app/f55b276a1b246a50a85b16db234bcb32
ServiceNow Store：Vulnerability Response Integration with CISA
https://store.servicenow.com/store/app/02ea27e61b246a50a85b16db234bcb2e

本記事は個人の見解に基づくものであり、ServiceNowの公式見解ではありません。記載内容は執筆時点の情報です。

ユーザーにネクストエクスペリエンス UI と UI16 の切り替えを許可

JunshuO — Mon, 14 Sep 2026 03:50:10 GMT

個人設定のダイアログにある [UI15 に切り替える] ボタンは誰もが知っており、懐かしいと感じるユーザーは ServiceNow の UI 進化を数年前にさかのぼることができます。

そして、同じ場所に別のボタンがあり、「ネクストエクスペリエンス」と呼ばれる UI 進化の次の段階にジャンプするのは素晴らしいと思いませんか？そして確かに、「統一ナビゲーションを有効にする」というボタンが存在します。いいえ、これは画像モンタージュではありません。

もちろん、このための前提条件は、インスタンスに San Diego リリースがあることです。ただし、設定する必要があるのは、システムプロパティ glide.ui.polaris.on_off_user_pref_enabled を「true」にすることだけです。

「ネクストエクスペリエンス」を有効にすると、対応するスイッチがディスプレイ設定に表示されます。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/servicenow-ai-platform-articles/allow-users-to-switch-between-next-experience-ui-and-ui16/ta-p/2316994

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

Assist とトークン:Assist とトークンによる Now Assist ライセンスの定義方法

JunshuO — Mon, 14 Sep 2026 05:49:50 GMT

みなさん、こんにちは。

ここまでで「Now Assist」に精通し、「Now Assist」で作業を開始し、ワークフローを強化し、貴重なインサイトを提供する可能性を実感している方も多いでしょう。しかし、ライセンスの重要な構成要素である「Assist」の計算メカニズムは、私にとってブラックボックスのように感じることがよくあります。

この「Assist」がどのように計算されるかを正確に理解することは、私たちのコミュニティ内で多くの議論と探求のトピックとなっています。
正確な公式は依然として不明瞭な点があるかもしれませんが、この記事では、これを主要なコンポーネントである「トークン」と関連付けることで、私の見解を提供することを目指します。Now Assist がどのように情報を「トークン」に分解し、これらの「トークン」が「Assist」スコアにどのように寄与するかを調べることで、謎を解き明かすことができます。

ここでの主な目標は、現在の理解を共有し、Now Assist のインテリジェントな提案という魅力的なプロセスの根底にあるこの概念をある程度説明するのに役立つフレームワークを提供することです。

まず「Assist」から始め、次に「トークン」、そしてそれぞれの例を見ていきましょう。

「Assist」とは何ですか？

「Assist」は、AIインタラクションを追跡する測定単位です。「Assist」は、AIエンジンによって実行されたインタラクションの数を測定します。

例 1:

質問1. ユーザーがAIボットに「フランスの首都は何ですか？」と尋ねます。

R1. AIボットはこの質問を処理し、「フランスの首都はパリです」と答えます

この場合、上記の1往復（ユーザーからの質問とAIからの直接回答）は、1「Assist」と見なされます。これは、AIがユーザーからのリクエストを正常に処理するたびに、「Assist」のカウントが1ずつ増加することを意味します。

例 2:

質問1. ユーザーがAIボットとやり取りします - 「チョコレートケーキを作るためのレシピを教えてもらえますか？」

R1. AIボットは「チョコレート、小麦粉、砂糖、卵、塩...」と指示を処理して応答します。これにより1アシストが消費されます。

質問2. ユーザー: 「ありがとうございます！柔らかくふわふわのケーキを作るにはどのくらい焼けば良いですか？」

R2. 現在、AIボットは「ふわふわにするには20分間焼きます」と処理して応答します。これにより1アシストが消費され、合計で2アシストが消費されたことになります。

この基本的な理解と、「Assist」がどのように消費されるかを理解していただければ幸いです。ご注意ください、 これは、内部処理 ( 「トークン」 ) ではなく、ユーザー向けアクションまたは完了したタスクに関するものです。ServiceNow関連の例を見てみましょう。

シナリオで「Assist」の計算方法を解き明かしましょう。

シナリオ 1:ServiceNow でのインシデントの要約

ユーザーが ServiceNow で、次のような長くて詳細なインシデントチケットを持っているとします。
* 説明:問題の長い説明。
* 再現手順: 問題を再現するための詳細な手順。
* ログ: 技術データとエラーメッセージ。
* コメント: ユーザーとサポートスタッフ間のやり取りのスレッド。
ユーザーは、Now Assist でこのインシデントの簡潔なサマリーを生成することを望んでいます。

実例:

Now Assist を使用する以下の例を挙げます。

参照: https://www.servicenow.com/docs/r/platform-administration/monitoring-now-assist-usage.html?content-l...

スキル	複雑さ	「トークン」	「Assist」ユニット
チャット返信の推奨事項	高 (マルチターンコンテキスト、予測生成)	多くの「トークン」、動的要因。	5
変更リスクの説明	低 (単一レコード、静的要因)	「トークン」が少なく、ロジックは少ない	1
メール要約機能*	中 (単一レコード、ステータス要因)	「トークン」数が多く、ロジックは少ない	1 (使用される「トークン」の数は、要約の長さによって異なります。)

「Assist」の仕組み:
* ユーザー要求: ユーザーは Now Assist でボタンをクリックするかコマンドをトリガーして、インシデントを要約します。
* AI 処理: Now Assist のAIモデルは、短い説明、説明、作業メモなど（Yokohamaではカスタマイズ可能）を含め、インシデントチケット全体を入力として受け取ります。
* サマリー生成: AI が情報を処理し、短くて首尾一貫したサマリーを生成します。
* サマリーを表示: Now Assist はユーザーにサマリーを表示します。
ユーザーの最初の要求からサマリーの表示までのこのプロセス全体は、1 つの「Assist」としてカウントされます。

では、「トークン」について見ていきましょう。

「トークン」は、AI がそのタスクを実行するために使用するデータの単位であり、「トークン」の数は計算コストに影響します

例: 上記の同じ例「フランスの首都は何ですか？」を見てみましょう。この入力文字列は、AIトークナイザーによって「What」、「Is」、「the」、「capital」、「of」、「France」、「?」のように個々の「トークン」に分解され、おおよそ7トークンになります。

「フランスの首都はパリ」という応答になります。「The」「capital」「of」「France」「is」「Paris」のように分割され、おおよそ6トークンとなります。合計13トークンが処理されたことになります。では、長いメールの場合にどれほどの「トークン」が使用され、どれほどの計算コストが発生するか想像してみてください。それがServiceNow Skill kitが「トークン」数を制限している理由です。

AIは、入力「トークン」の処理（質問を理解するため）と出力「トークン」の生成（回答を作成するため）の両方で、計算コストを発生させます。「トークン」数が多ければ多いほど、処理時間が長くなり、消費エネルギーも増大します。

この記事が、「Assist」、その計算方法、そして「トークン」に関する基本的な理解を深める一助となれば幸いです。次の記事では、「Assist」が「トークン」と計算コストにどのように関連するか、また「Now Assist」に事前定義された「Assist」が付属している理由について説明します。

私の理解に誤りがあれば、お気軽に編集または訂正をお願いいたします！これがお役に立てば幸いです。

よろしくお願いいたします。

ポール

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/now-assist-blog/assist-amp-token-how-assist-and-tokens-define-your-now-assist/ba-p/3235887

アップグレードセンター：スキップされたレコードルールを探る

JunshuO — Mon, 14 Sep 2026 03:47:16 GMT

記事、ブログ、ビデオ、ポッドキャスト、プロジェクトの共有 - 現場の経験

皆様、こんにちは。

Vancouver リリースで、ServiceNow はアップグレードセンターに 「スキップされたレコードルール」 を導入しました。ホットフィックス/パッチ/アップグレード後にスキップされた更新に取り組む際に非常に便利な追加機能のようです。スキップされたレコードルールは ServiceNow のエコシステムではまだあまり注目されていなかったため、深掘りしていきましょう。

スキップされた更新

ホットフィックス/パッチ/アップグレード後の「スキップされた更新」の処理は、誰もが好んで行う作業ではないかもしれません。大規模/古いインスタンスや適切なガバナンスが欠けているインスタンスでは、スキップされた更新の数がリリースごとに数百、あるいは数千に上ることがあります。理論的には、これらすべてを処理することが望ましいですが、これは時間のかかるタスクになる可能性があり、すべての ServiceNow アドミニストレーターまたは開発者がこのタスクを実行できるわけではありません。ここで、スキップされたレコードルールがお役に立つかもしれません。

まず、「スキップされた更新」とは何かについて、少しおさらいしてみましょう。以下に、 ServiceNow から見つけることができる説明の1つを示します。

「スキップされた変更とは、Now Platform® インスタンスに変更 (構成やカスタマイズなど) を行い、ServiceNow® が新しいリリース (Orlando から Paris など) の一部として同じレコードを更新した場合に作成されるレコードです。ServiceNow のアップグレードでは、お客様が行った変更が上書きされることはありません。そのため、スキップされた変更を確認し、ベースに戻すか、マージするか、変更を保持するかを決定する必要があります。インスタンスでスキップされた変更を生成する可能性のある機能強化を特定するために、アップグレード前にリリースノートを確認してください。」

お客様が変更したことを認識していなくても、何らかの理由で顧客による更新と見なされるレコードについても、スキップされた変更が発生する点にご留意ください。

アップグレードセンターでアップグレードモニターを表示すると (アップグレードセンター > アップグレードモニター、または `upgrade_monitor.do`) 、「 * へのアップグレードでスキップされたレコード」というセクションに、前回のホットフィックス/パッチ/アップグレードで発生したスキップされたレコードの概要が表示されます。以下のようになります。

Vancouver リリース以降、左下にスキップされたレコードルールを参照する新しいリンクが表示されます。

スキップされたレコードルール

Vancouver リリースで、ServiceNow はアップグレードセンターにスキップされたレコードルールを導入しました。スキップされたレコードルールは、 ServiceNow から次のように説明されています: 「設定された条件に基づいてスキップされたレコードルールを作成し、アップグレード後のカスタマイズを定義します。」

ホットフィックス/パッチ/リリース後、スキップされたレコードルールが自動的に実行されます。いずれかのスキップされたレコードルールの条件に一致するレコードがある場合、それらのスキップされたレコードは、そのルールで定義された条件に従って処理されます。スキップされたレコードルールは、アクションを自動的に更新したり、コメントを追加したりできます。

ServiceNow は、標準で4つの非アクティブなスキップされたレコードルールを追加しています。スキップされたレコードルールは、 「`sys_upgrade_skipped_record_rule`」 テーブルに保存されます。標準で提供されるスキップされたレコードルールの一例を以下に示します。

スキップされたレコードルールの作成

スキップされたレコードルールの作成はそれほど複雑ではありませんし、以下の最初の例に示すように、必ずしも複雑である必要はありません。この例では、リリース中に頻繁に更新されるシステムプロパティのいくつかがリストされています。私のお客様の何社かでは、これらのシステムプロパティがほぼすべてのリリースで同じアクションで繰り返し処理される経験をしてきました。スキップされたレコードルールを作成するのに最適な例と言えるでしょう。

使用可能なアクションは、次のとおりです。

- 自分の変更を保持

- 元に戻して非アクティブのままにする

- スキップされたレコードをユーザーにアサインする

- スキップされたレコードにタグをアサインする

より複雑なスキップされたレコードルールを作成することが可能です。アップグレード時には、顧客インスタンスで意図的に非アクティブ化された通知がスキップされたレコードとして発生することがよくあります。このようなスキップされたレコードの確認と対処に時間を費やすのは非効率的であるため、スキップされたレコードルールを作成しましょう。条件のノーコードオプションは限られていますが、コードを使用できます。以下は、クライアント呼び出し可能スクリプトインクルードで定義されたロジックを適用する例です。これは、すべての非アクティブな通知を取得するロジックであり、これによりスキップされたレコードルールが顧客インスタンス上の非アクティブな通知に関連するスキップされたレコードを自動的に処理するようになります。

クライアント呼び出し可能スクリプトインクルード:

これはあくまで一例です。安易にコピー＆ペーストするのではなく、それが適用可能であり、お使いのインスタンスに適用することが適切かどうかを判断してください。

スキップされたレコードルールの実行

スキップされたレコードルールを初めて適用しテストできるのは、次のホットフィックス/パッチ/アップグレードの時だと思っていました。しかし幸いなことに、そうではありませんでした。実は私も最初はこの点を見落としていました。スキップされたレコードルールを手動で実行することは可能です。スキップされたレコードルールのリストを表示する際 （特定のルールを表示するのではなく） 、使用可能なアクションの1つは 「今すぐ実行」 です。

スキップされたレコードルール履歴

スキップされたレコードルールの履歴についても、分かりやすい概要が提供されています。これは、 「`sys_skipped_record_rule_history`」 テーブルで確認できます。

結果

スキップされたレコードルールを導入すると、ホットフィックス/パッチ/アップグレード後には、アップグレードセンターのアップグレードモニターに、スキップされたレコードの一部が自動的に処理されたことが直ちに表示されることが期待されます。私のお客様の1社では、Washington DC Patch 0 へのアップグレードにおいて、91件のスキップされた更新のうち55件を自動的に処理することに成功しました。

---

以上となります。お役に立てれば幸いです。ご質問やご意見がございましたら、お気軽にお知らせください。

C	この内容がお役に立ちましたら、ブックマークしていただくか、「役に立つ」とマークしていただけると幸いです。私が共有/参加した記事、ブログ、ビデオ、ポッドキャスト、共有プロジェクトにもっと興味がありますか? - 記事、ブログ、ビデオ、ポッドキャスト、プロジェクトの共有 - 現場の経験

よろしくお願いいたします。

マーク・ロートフ

独立系 ServiceNow コンサルタント
9x ServiceNow MVP

---

リンクトイン

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/upgrades-and-patching-articles/exploring-upgrade-center-skipped-record-rules/ta-p/2864060

OAuth2 統合用の JWT トークンの生成

JunshuO — Mon, 14 Sep 2026 03:44:31 GMT

はじめに

一部の統合では、認証フローで実際のアクセストークンを要求する前に JSON Web トークン (JWT) を生成する必要があります。認証エンドポイントとclient_idとclient_secretを直接交換する代わりに、発行者、件名、タイムスタンプ、その他のIDなどの特定のクレームを含む署名付き JWT がシステムで予期されます。このようなシナリオでは、clientId、clientSecret、追加のクレームなどの値を使用して、プロバイダーの要件に従って JWT を構築するカスタムスクリプトを ServiceNow に実装する必要がある場合があります。以下に、これをどのように実装できるかの概要を示します。

1. JWT の生成

ServiceNowでは、次のような入力を受け入れるスクリプトインクルードを作成します client_id 、 client_secret 、 subject 、およびその他のクレーム。次に、正しいクレーム(iss、sub、iatなど)でJWTを構築し、それに署名し(この場合はHS256)、トークンを返します。

重要な注意事項:

CertificateEncryption() API は、ソリューションがカスタムスコープ内で機能するようにするために使用されます。
クレームは、認証 API が期待するものと正確に一致する必要があります。

これで、上記のスクリプトインクルードを、アクション入力として userId を想定して、Workflow Studio/フローデザイナーのアクションスクリプトから呼び出すことができます。

(function execute(inputs, outputs) { var now = new GlideDateTime(); var params = { clientId: gs.getProperty({sysPropertyNameClientId}), // sys_property of "Password2" type subject: {custom_value} + inputs.user + '@' + inputs.user, issuedAt: now, secret: gs.getProperty({sysPropertyNameClientSecret}), // sys_property of "Password2" type user: inputs.user }; var jwt = new x_{custom_app_name}.JWTGenerator.generate(params); // Return the JWT to the Action outputs outputs.jwt_token = jwt; })(inputs, outputs);

2. JWT の送信とアクセストークンの取得

JWT を取得したら、次のステップでは、認証エンドポイントを呼び出し、必要なヘッダーまたは本文パラメーターでトークンを送信します。その後、API はアクセストークンを返します。これを後続の呼び出しに使用します。

プレースホルダー – REST 呼び出し + ヘッダー:

POST https://example.com/oauth2/token
Headers:
  Content-Type: application/x-www-form-urlencoded
  Authorization: Bearer <your_jwt_token>

トークン API から応答を受信したら、応答本文の JSON を解析して、必要なアクセストークンを取得する必要があります。

最後に、フローデザイナーアクションには次の手順が含まれます。

JWT スクリプトインクルードを呼び出し、JWT を生成します。
REST メッセージを呼び出してアクセストークンを取得します。
REST メッセージの応答を解析し、アクセストークンを取得します。

JWT を外部で検証する

開発中は、jwt.io のようなツールを使用して、生成された JWT を検証することが必要になる場合があります。これにより、適切なアルゴリズム (HS256/RS256) などが使用され、クレームが正しく、有効な署名が存在することが保証されます。

まとめ
JWT を生成し、それをアクセストークンと交換してから、そのトークンを統合で使用するこのパターンは確実に機能し、ServiceNow 内で再利用可能なフローデザイナーアクションとしてパッケージ化できます。これは、JWT ベアラー認証を想定している API を扱う場合に役立つアプローチです。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/workflow-data-fabric-articles/generating-jwt-token-for-oauth2-integrations/ta-p/3430831

UI16 とネクストエクスペリエンスのインターフェイス比較

JunshuO — Mon, 14 Sep 2026 03:37:50 GMT

San Diego リリースに伴い、ServiceNow は、Now Platform 全体の生産性の向上、エンゲージメントの向上、インサイトの可視化を実現する、次世代の直感的でパーソナライズされたエクスペリエンスを提供する「ネクストエクスペリエンス」を導入しました。

この記事では、現在の UI16 インターフェイスと Next Experience を比較します。

ネクストエクスペリエンスのアクティブ化
ログインページ
統一ナビゲーション
リストビュー
レコードビュー
代理操作

ネクストエクスペリエンスのアクティブ化

すべてのユーザーに一律適用

San Diego リリース以降の新規顧客には、ネクストエクスペリエンスが自動的に有効になります。

以前のリリースからアップグレードする既存のインスタンスは、システムプロパティ glide.ui.polaris.experience を「true」に設定することで、ネクストエクスペリエンスを手動で有効にする必要があります。

ユーザーが選択できるようにする

この設定方法については、私の記事ユーザーにネクストエクスペリエンス UI と UI16 の切り替えを許可をご参照ください。

ログインページ

UI16

ネクストエクスペリエンス

ログインページが宇宙的な美しいデザインになり、ログインボックスが中央に配置されました。

デフォルトでは、テーブルのコンテンツ sys_home_list (UI16の下部にあるテキストブロック)は考慮されなくなりましたが、これは私の目には大きな損失ではありません。元に戻したい場合は、ページ「ネクストエクスペリエンスでログインのテーマを編集する」の手順をご参照ください。

ユニークな効果：背景の星がマウスに追従します。

そして、目のアイコンをクリックすると、入力したパスワードが表示されます。

統一ナビゲーション

ネクストエクスペリエンス統一ナビゲーションはすべてのページの上部で実行され、インスタンスのナビゲーションに役立つコントロールが含まれています。ワークスペースとクラシック UI に簡単にアクセスし、インスタンスを検索し、通知を受信できます。

UI16	ネクストエクスペリエンス

(1)異なるロゴ
(2) 固定および折りたたみ可能なフレームのアプリケーションナビゲーター/お気に入り/履歴。 (3) (4) アプリケーションピッカーと更新セットピッカーは、設定で有効にすることができ、常に表示されます。 (7) コネクトチャットは新しいエクスペリエンスでは使用できなくなりました！ (8) 多くのプラグイン (Notify など) やアプリケーション (Xplore など) では、その領域にアイコンが配置されており、すばやくアクセスできるようになっていますが、ネクストエクスペリエンスではこの機能は提供されなくなったようです。	(2) すべて/お気に入り/履歴は透明なレイヤーで開き、固定して常に表示することができます。ピン留めできるメニューは 1 つだけです。 (3) ここに「設定」と「印刷対応版」を追加しました (4) 選択されているアプリケーションまたは更新セットを確認するには、地球アイコンをクリックする必要があります。また、右矢印をもう一度クリックして、要素を選択するためのフィルターパネルを取得する必要があります。 (5) 検索フィールドが表示され、より目立つようになりました。 (6) 完全に再編成され、タイルベースの新鮮なデザインで提示されます。 (7) インスタンス内の現在の場所のコンテキストを提供します。星型アイコンを選択して、表示されたページをお気に入りに追加します。 (8) この選択ダイアログから特定のワークスペースを一元的に選択できるようになりました。

リストビュー

UI16

ネクストエクスペリエンス

(1) リストメニュー

(2) 選択したビュー

(3) UI アクションボタン

(4) リスト検索

(5) アクティビティ

(6) リストナビゲーター

(7) 適用済みフィルター

(8) リスト設定

(9) 列検索

(10) 行選択とプレビューアイコン

(11) 適用スタイル

(12) リストアクション

(3)UIアクションボタンの位置はかなり不便だと思います。

(5) / (8) これらのアイコンは、より認識しやすくするために大きくする必要があります。

(6) 最後に、ページナビゲーターが配置されるべき場所に配置されます。

(10) 行の選択とプレビューアイコンは、行にカーソルを合わせたときにのみ表示されます。

(11) フィールドスタイルがワークスペースと同じように表示されるようになりました。

(12) 最後に、リストアクションを選択するためにリストの最後までスクロールする必要がなくなります。

レコードビュー

レコードビューは以前とほぼ同じです。フィールドを強調するために、いくつかのスタイル調整が行われました。

UI16	ネクストエクスペリエンス

代理操作

UI16

ネクストエクスペリエンス

代理操作が進行中であることを確認する唯一の方法は、[代理操作を終了] メニュー項目を使用することです。

4 つの新しい兆候は、代理操作セッションを明確に示しています。

上部の赤いバー
アバター画像を囲む赤い円
アバター画像の右上隅にある目のアイコン
ヒント「ユーザーの代理操作」

🛈	この記事がお役に立てば、適宜マークしていただければ幸いです。私からもっと読みたい場合は、すべての記事リストをご覧ください。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/servicenow-ai-platform-articles/interface-comparison-between-ui16-the-next-experience/ta-p/2307243

ネクストエクスペリエンス UI の概要

JunshuO — Mon, 14 Sep 2026 03:36:24 GMT

センターオブエクセレンス / ネクストエクスペリエンス / ネクストエクスペリエンス UI の概要

San Diego リリースでは、Next Experience UI をリリースし、ユーザーに新しい最新のビジュアルデザインと、コア UI とインスタンス内のアプリケーション間の統一されたエクスペリエンスを提供しました。統一ナビゲーションを使用すると、ユーザーはワークスペースと同様に、UI16 フォーム、リスト、ダッシュボードなどのさまざまなソースのコンテンツに 1 つのペインでアクセスできます。

この記事では、Next Experience 製品ドキュメントで使用される用語、Next Experience UI をアクティブ化するための考慮事項、および Next Experience UI で使用されるテクノロジーをユーザーとアドミニストレーターに紹介します。詳細については、ネクストエクスペリエンス UI 製品ドキュメントをご参照ください。

San Diego での Next Experience UI の初回ローンチでは、サービスデリバリチーム (エージェント、履行者) — Now Platform で勤務日の大半を過ごすユーザー — のエクスペリエンス改善に重点を置いています。従業員センター (サービスポータルのテクノロジースタック上に構築) は、従業員のエンゲージメントと生産性を維持し、情報を提供し、必要なサービスやリソースを簡単に要求できるようにするためのポータルに推奨されるソリューションです。従業員センターはローマで立ち上げられ、継続的な投資と強固なロードマップが計画されており、当面は四半期ごとにリリースされる予定です。

Next Experience で従業員ポータルを提供するためのアプローチと期間はまだ定義中です。当社は、サービスポータルベースの従業員ポータルからネクストエクスペリエンスへの段階的な移行を可能にするために、ネクストエクスペリエンスとサービスポータル機能を組み合わせたハイブリッド展開をサポートすることを期待しています。ネクストエクスペリエンス従業員ポータルのアプローチと期間が定義され次第、詳細を共有します。

前提条件

このガイドのテクノロジーと概念は、Now Platform の San Diego リリースに基づいています。

このガイドで扱うテクノロジーの主な対象者は、次の 2 種類です。

プラットフォームアドミニストレーター (admin) - この対象者は、ネクストエクスペリエンスを有効にし、ランディングページとテーマを設定し、システムプロパティを設定できます。

ユーザー (admin 以外のロール: itil、snc_internal、sn_customerservice_agent、カスタムアプリロールなど) — ネクストエクスペリエンスが有効になっている場合、この対象者にはネクストエクスペリエンス UI レイアウトが表示されます。

用語

用語	定義
対象者	対象者は、ページを表示できるユーザーを定義します。対象者やロール (エージェントやマネージャーなど) に合わせたターゲットエクスペリエンス向けにページを作成できます。
コア UI	UI16 (プラットフォーム/クラシック UI) とも呼ばれます。コア UI は、リスト、フォーム、ダッシュボードなどのコンテンツを含む Jelly ベースのページで構成されています。
ランディングページ	ネクストエクスペリエンス UI を使用する場合、ランディングページでユーザーの作業をすばやく表示してアクセスできます。
ネクストエクスペリエンス UI フレームワーク	正式名称は Now Experience UI フレームワークで、Web コンポーネント標準に基づいて構築された ServiceNow JavaScript フレームワークです。開発者がカスタム Web コンポーネントをビルドして、ユーザー向けの最新のユーザーインターフェイスを作成できるようにします。
ネクストエクスペリエンス UI	San Diego リリースでローンチされ、ランディングページと統一ナビゲーションを利用する特定のユーザーインターフェイスです。インスタンスとこの記事 (Next Experience UI の以前の名前) には、Polaris への技術的な言及が含まれている場合があります。
UI ビルダー	Next Experience UI フレームワーク用の Web ユーザーインターフェイスビルダーです。UI ビルダーは、ネクストエクスペリエンス UI ランディングページ、構成可能なワークスペース、App Engine Studio で生成されたワークスペースとポータル、またはネクストエクスペリエンスコンポーネントとカスタム Web コンポーネントを使用したカスタム Web エクスペリエンスのページをビルドするために使用されます。
統一ナビゲーション	Next Experience 統一ナビゲーションは、従来の UI16 アプリケーションと WEP (Web Experience Platform、UI ビルダーとも呼ばれる) ワークスペースを 1 つのナビゲーションヘッダー内に統合します。
バリアント	特定の対象者をターゲットとするコンテンツを備えたページのバージョンです。たとえば、マネージャー用とエージェント用で異なるターゲットコンテンツを組み立てるために、バリアントを作成できます。
Web エクスペリエンスプラットフォーム	UI ビルダーやネクストエクスペリエンスコンポーネントなど、共有可能、拡張可能、構成可能、かつ一貫性のあるエクスペリエンスを提供するために使用される複数のテクノロジーで構成されています。

アクティブ化と移行

ネクストエクスペリエンス UI のアクティブ化は、San Diego へのアップグレードの必須要件ではありません。既存のお客様は、Next Experience UI のアクティブ化を決定する際に、以下の情報と製品ドキュメントを参照してください。San Diego のアップグレードでは、既存の顧客のネクストエクスペリエンス UI は自動的に有効になりません。

ネクストエクスペリエンス UI をアクティブ化するまでのパスは、インスタンスのカスタマイズレベルによって異なる場合があります。ネクストエクスペリエンス UI への移行がスムーズに進むように、インスタンスのカスタマイズを支援したユーザーまたはその他の認定パートナーからガイダンスとサポートを受けることをお勧めします。ネクストエクスペリエンス UI のアクティブ化の詳細については、「ネクストエクスペリエンスのアクティブ化に関する考慮事項」製品ドキュメントをご参照ください。

新規顧客

San Diego でローンチする新規顧客、またはインスタンスで zBoot を実行した顧客には、インスタンスでネクストエクスペリエンス UI が自動的に有効になります。これらの顧客には、ネクストエクスペリエンス UI が自動的に有効になったデフォルトのランディングページもあります。

既存のお客様

低カスタマイズ性 - 以前のリリースからアップグレードするお客様で、UI スクリプトや DOM 操作などの形式で UI カスタマイズを実装しておらず、ワークスペースに多額の投資を行っていない場合は、glide.ui.polaris.experience システムプロパティを設定し、一般的なファミリーリリース検証を実行することでアップグレードできます。

高度なカスタマイズ性 - 以前のリリースからアップグレードし、インスタンスに次の変更を加えたお客様は、シームレスなアクティベーションを確実に行うために、変更作成者または確立されたパートナーの支援を必要とする場合があります。
- ハードコードされたスタイルや UI スクリプトによるユーザーインターフェイスのカスタマイズ
- クラシック (エージェント) ワークスペースを採用していて、新しい構成可能ワークスペースを採用したい場合
- クラシック (エージェント) ワークスペースでカスタムコンポーネントを作成していて、新しい構成可能ワークスペースを採用したい場合

高度にカスタマイズされたエクスペリエンスを持つ顧客は、統一ナビゲーションを使用するように本番インスタンスをアップグレードする前に、徹底的なテストを実行する必要があります。

システムプロパティ

ネクストエクスペリエンス UI はシステムプロパティで有効になり、他のプロパティは、ユーザーがテーマのバリアントを変更するオプションを持つかどうか、およびネクストエクスペリエンスが有効になっているインスタンスにログインしたときに表示されるランディングページを制御します。システムプロパティのより広範なリストについては、「ネクストエクスペリエンスのシステムプロパティ」製品ドキュメントをご参照ください。

プロパティ	説明	デフォルト
glide.ui.polaris.experience		新規顧客:true 既存の顧客:false
glide.login.home	ユーザーがログインしたときに表示されるパスです。	新規顧客:now/nav/ui/home 既存のお客様:前のホーム設定
glide.ui.polaris.dark_themes_enabled	ダークテーマとバリアントを有効にします。	false
glide.banner.image.url	バナー/ロゴ画像のクリック時に使用する URL です。	これを任意の値に設定できます。glide.login.home と同じ値にしたい場合は、同じ値を入力します。

...その他のシステムプロパティ

ユーザー環境設定

環境設定	説明	デフォルト	システム
glide.ui.polaris.landing_page_header_collapsed	デフォルトのランディングページにオンボーディングセクションを表示するかどうかを決定します。false に設定すると、オンボーディングセクションが表示されます。	デフォルトのランディングページのオンボーディングでユーザーが [閉じる] をクリックすると作成され、true に設定されます。	いいえ
overview_help.visited.navui	ユーザーがネクストエクスペリエンス UI を使用して初めてインスタンスにログインしたときに、オンボーディングのポップアップを表示するかどうかを決定します。	ネクストエクスペリエンス UI が有効になっているインスタンスにユーザーが初めてログインすると作成され、true に設定されます。	いいえ
glide.ui.menu.main.pinned.id	このユーザー設定は、固定されているメニューを保持します。アドミニストレーターがすべてのユーザーにデフォルトの固定メニューを設定する場合は、システムユーザー設定を作成し、ユーザーがログインしてメニューを固定する前に、固定したいメニューの sys_id を入力できます。	ユーザーがメニューを固定したときに、このユーザー設定が作成されます。	デフォルトではありません

デフォルトのランディングページ

デフォルトのランディングページでは、ユーザーは自分の作業を一目で確認し、その日に開始できる作業を特定できます。ランディングページには、ロールとタスクに基づいて次のアイテムが含まれている場合があります。

ネクストエクスペリエンス統一ナビゲーションについて学習するためのリンクを含むバナー

作業のステータスと優先度を最新の状態に保つための新しい重要なタスク

優先度別に現在オープンになっているタスク

作業対象として自分に割り当てられたタスクレコードを含むリスト

タスクの完了に関連するパフォーマンスアナリティクスとレポート (PAR) データ

ランディングページで実行可能な承認

お気に入りのアイテム

未解決の要求

有用な機能を特定するためのその他のリソース

新規顧客

既存のお客様

以前のリリースからアップグレードした既存の顧客には、ネクストエクスペリエンス UI をアクティブ化してもデフォルトのランディングページは表示されません。既存の顧客には、既存のスタートページ (ホームページまたはダッシュボード) が引き続き表示されます。既存のスタートページを利用することで、管理者は Next Experience UI を有効にしてユーザーが新しいユーザーインターフェイスの使用を開始できるようにするとともに、組織固有のランディングページを作成する時間を確保できます。glide.login.home システムプロパティを変更することで、既存の顧客もデフォルトのランディングページを使用できますが、サブ製品インスタンスのデフォルトのランディングページでテストを実行して、現在のユーザーニーズを満たしていることを確認することをお勧めします。

デフォルトのランディングページは、次の 3 つの領域に分かれています。

オンボーディング - オンボーディングヘッダーは、ユーザーがネクストエクスペリエンス UI を採用するのに役立つ主要な統一ナビゲーション機能を強調表示するデフォルトのランディングページの機能です。

可視化 - デフォルトの可視化はロールとタスクに基づいています。可視化には、新規タスクやオープンタスク、自分にアサインされたタスクレコードのリスト、タスクに関連するパフォーマンスアナリティクスとレポートデータ、お気に入りのアイテム、未解決の要求などが含まれます。

便利な機能 - 便利な機能には、ユーザーに関連するダッシュボードやナレッジベース記事などのリソースへのリンクが含まれており、ユーザーはデフォルトのランディングページから直接役立つ情報にアクセスできます。

ランディングページのカスタマイズ

デフォルトのランディングページは変更できませんが、独自のランディングページを作成する顧客向けのテンプレートとして使用できます。ランディングページは、UI ビルダーのさまざまなユーザーエクスペリエンスに合わせてカスタマイズできます。UI ビルダーでのページの作成とランディングページの作成の詳細については、次のリソースを参照してください。

製品ドキュメント: デフォルトのランディングページの探索

製品ドキュメント: ランディングページとダッシュボードの違い

ネクストエクスペリエンスセンターオブエクセレンス: ランディングページの作成

ネクストエクスペリエンスセンターオブエクセレンス: UI ビルダークイックスタートガイド

統一ナビゲーション

ネクストエクスペリエンス統一ナビゲーションは、コア UI (UI16) アプリケーションと WEP (Web エクスペリエンスプラットフォーム、UI ビルダーとも呼ばれます) ワークスペースを 1 つのナビゲーションヘッダー内に統合します。ユーザーは、UI16 メニューへのアクセス、現在の場所の表示、通知へのアクセス、プラットフォームリストとワークスペース全体でのグローバル検索の使用、ヘルプの表示、統一ナビゲーションヘッダーからのユーザーメニューへのアクセスを行うことができます。統一ナビゲーションは個別の領域に分割されます。

ロゴ

表示されるデフォルトのロゴは ServiceNow ロゴで、統一ナビゲーションアプリ構成レコードに関連付けられたテーマレコードをカスタマイズして、会社のロゴに置き換えることができます。ロゴをクリックすると、ユーザーはネクストエクスペリエンスのランディングページ、または glide.banner.image.url システムプロパティで指定された URL に戻ります。ロゴにカーソルを合わせると、[インスタンス名] と [説明] が表示されます。

ナビゲーションメニュー

統一ナビゲーションが有効になっている場合、ユーザーにはデフォルトで [すべて]、[お気に入り]、および [履歴] オーバーレイメニューが表示されます。ユーザーが WEP (構成可能) ワークスペースにアクセスできる場合は、[ワークスペース] メニューアイテムが表示されます。オーバーレイメニューを使用すると、ユーザーはアプリケーションへのアクセス中に画面の領域を解放できます。メニューは固定可能で、ユーザーはナビゲーションの環境設定を選択できます。小さいウィンドウサイズで作業する場合、メニューはオーバーフローメニューに折りたたまれます。

すべて - お客様は、UI16 アプリケーションナビゲーターのカスタマイズと同じように [すべて] メニューをカスタマイズできます。詳細については、「アプリケーションナビゲーター」製品ドキュメントをご参照ください。

お気に入り - [お気に入り] メニューには、Next Experience アイテムと CoreUI アイテムの両方が含まれています。「お気に入りを編集」画面が更新され、新しいスタイルとアイコンが追加されました。コンテキストアプリピルのコンテキスト名の横にあるお気に入りの星により、お気に入りへの追加が容易になりました。

履歴 - [履歴] メニューが改善され、フィルターが追加され、エントリが時間/日付別にグループ化されるようになりました。

ワークスペース - [ワークスペース] メニューには、統一ナビゲーションシェルを親アプリシェルとして使用するエクスペリエンスが表示されます。ユーザーはワークスペースを表示するために移動したり、新しいタブを開いたりする必要がなく、WEP ワークスペースヘッダーの代わりに統一ナビゲーションヘッダーが表示されます。クラシック (エージェント) ワークスペースは、統一ナビゲーションアプリシェル内に表示されません。構成可能なワークスペースは、エクスペリエンスカテゴリにレコードを追加することで [ワークスペース] タブに追加できます。詳細については、「統一ナビゲーションワークスペースメニューへのワークスペースの追加」製品ドキュメントをご参照ください。

コンテキストアプリピル

コンテキストアプリピルは、ユーザーがインスタンス内のどこにいるかを示すコンテキストを提供します。お気に入りスターを使用すると、ユーザーはインスタンス内の現在の場所をお気に入りに追加できます。注: UI16 システム構成でブラウザタブのタイトルが設定されている場合、コンテキストアプリシェルに表示されます。

ユーティリティ

ユーザーが仕事をするために必要なコントロールは、ヘッダーの右側に配置されています。すべてのユーザーが一貫した検索、ヘルプ、および通知を利用できます。

検索は、glide.ui.polaris.global_search システムプロパティを true に設定することで有効にできます。統一ナビゲーションでの検索では、ユーザーが検索するワークスペースを選択してワークスペースを検索することもできます。統一ナビゲーション検索の詳細については、「ネクストエクスペリエンスでの検索の使用」製品ドキュメントをご参照ください。
Web 通知は、ユーザーが Web 通知機能を含むワークスペースにアクセスできる場合に使用できます。
ユーザーがドメイン選択、アプリケーションスコープ、または更新セットにアクセスできる場合は、スコープ選択メニューなどの管理機能を使用できます。[スコープ選択] メニューの詳細とキーボードショートカットの使用方法については、ネクストエクスペリエンスセンターオブエクセレンスの記事を参照してください。
CTI (電話) は、CTI ソフトフォンプラグインがインストールされているインスタンスで使用できます。

ユーザーメニュー

ユーザーは、プラットフォーム UI と WEP (UI ビルダー) エクスペリエンスにおけるユーザー環境設定に 1 か所でアクセスできます。一部の環境設定カテゴリは、[代理操作ユーザー] や [ロールを昇格] など、権限またはコンテキストに応じて動的にのみ表示されます。アドミニストレーター機能とキーボードショートカットについては、「ネクストエクスペリエンスピッカーの詳細」製品ドキュメントをご参照ください。

環境設定

表示 - San Diego の新しい環境設定: 常に上部ナビゲーションを表示。San Diego で更新された環境設定: コンパクトな間隔モードを使用、リストに改行を入れる、日付と時刻の形式。

アクセシビリティ - San Diego の新しい環境設定: モーションを減らす。San Diego で更新された環境設定: チャートとグラフのデータテーブルを有効にする。

通知 - ユーザーがワークスペースにアクセスできる場合、ユーザーがワークスペースとコア UI の通知を 1 つのペインで行ったり来たりできるようにします。

テーマ - 複数のテーマバリアントがユーザーに利用でき、かつ glide.ui.polaris.dark_theme_enabled プロパティが true に設定されている場合に表示されます。

ワークスペース - この環境設定は、ユーザーがワークスペース内にいる場合に表示されます。

デバッグ - スクリプトデバッガーと自動テストフレームワーク (ATF) インスペクターが含まれ、admin ロールを持つユーザーのみが使用できます。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/next-experience-articles/next-experience-ui-overview/ta-p/2332080

ServiceNow での OAuth 2.0 セットアップ

JunshuO — Mon, 14 Sep 2026 05:48:20 GMT

ServiceNow の統合はパズルと格闘しているように感じることもありますが、OAuth 2.0 の設定は面倒なことではありません。私は最近これを実装しましたが、そのプロセスは簡単で、迅速かつクリーンで信頼できるものでした。ServiceNow を外部システムに簡単に接続できるように、ここで文書化した内容をご紹介します。

クライアントから必要なもの

まず、クライアントから 3 つの情報を入手する必要があります。シンプルにしましょう。

トークン URL ：ServiceNow がアクセストークンをフェッチするエンドポイントです。
クライアント ID ：アプリケーションの一意の識別子です。
クライアントシークレット ：認証用のセキュアキーです。

それで全部です！ユーザー認証情報は不要です。クリーンなバックエンド間接続だけです。

ServiceNow でのステップバイステップセットアップ

ここでは、ServiceNow で OAuth 2.0 を手間抜きに構成する方法をご紹介します。

REST メッセージを設定
まず、ServiceNow で REST メッセージを作成します (システム Web サービス > 送信 > REST メッセージ)。これが統合の基盤になります。
OAuth プロファイルの作成
システム OAuth > アプリケーションレジストリー に移動し、新規をクリックします。
- サードパーティ OAuth プロバイダーに接続します を選択します。
- 明確でわかりやすい名前を付けます (「Externalsystem_OAuth」など)。
- クライアントから提供された クライアント ID 、 クライアントシークレット 、および トークン URL を入力します。
- デフォルトの権限許可タイプ を クライアント認証情報 に設定します。
- レコードを保存します。
OAuth エンティティプロファイルの構成
保存後、下にスクロールして OAuth エンティティプロファイル 関連リストを開き、プロファイルを開きます。
- ここでも 権限許可タイプ が クライアント認証情報 に設定されていることを再度確認します。
- もう一度保存します。
プロのヒント :このステップを見落とすのはよくある落とし穴です！トークンの問題を回避するために、メインプロファイルとエンティティプロファイルの両方で権限許可タイプを常に確認してください。
OAuth プロファイルを REST メッセージにリンクする
REST メッセージ (または使用している場合は統合ハブアクション) に戻ります。
- 認証セクションで、新しく作成した OAuth プロファイルを選択します。
- ServiceNow は認証をシームレスに処理します。

このセットアップが素晴らしい理由

最も良い点の 1 つは、ServiceNow がトークンの更新を自動的に処理することです。カスタムスクリプトを書いたり、トークンの期限切れを心配したりする必要はなく、すべてバックグラウンドで処理されます。これにより、統合のメンテナンスが少なくなり、信頼性が高くなります。

最終的な考え

ServiceNow で OAuth 2.0 を設定することは、困難である必要はありません。クライアントからのいくつかの情報と、プラットフォームでのわずかな作業だけで、安全で自動化された統合を稼働させることができます。私はこのアプローチを複数のプロジェクトで使用してきましたが、何時間ものトラブルシューティングから解放されました。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-articles/oauth-2-0-setup-in-servicenow/ta-p/3307347

スキップされたレコードの処理と更新セットでのアップグレードの詳細のキャプチャ

JunshuO — Mon, 14 Sep 2026 03:32:30 GMT

記事、ブログ、ビデオ、ポッドキャスト、プロジェクトの共有 - 現場の経験

こんにちは。

ほとんどすべての開発者またはシステム管理者は、ある時点でスキップされたレコードに対応することになります。以前は、スキップされたレコードに関連するアップグレードの詳細レコードは、すべてのインスタンスで手動で処理する必要がありました。

Paris リリース以降、ServiceNow によってこのプロセスがはるかに簡単になったことをご存知ですか?

まったく新しいものではありませんが、多くのお客様やServiceNowパートナーがまだ気づいていないことに気付いたため、今回は改めて注目してみたいと思います。

詳しく見てみましょう。

スキップされたレコード

ServiceNow インスタンスのファミリーリリースをアップグレードすると、数十、場合によっては数百のスキップされたレコードが表示されることがよくあります。スキップされたレコードは、パッチ、ホットフィックス、またはストアアプリケーションの更新によって作成することもできます。

これらを表示および管理するための便利な場所の 1 つがアップグレードセンターです。

アップグレードの詳細 [sys_upgrade_history_log]

すべてのスキップされたレコードを確認することをお勧めします。通常は、準本番インスタンスで最初にすべてのスキップされたレコードをレビューします。実行するアクション (ビジネスルールの元に戻す、スクリプトインクルードの結合など) は顧客アップデートとして更新セットにキャプチャされます。

その後、その更新セットを取得して、次のインスタンスでコミットできます。このようにして、実行した作業は一度実行するだけで済み、他の通常の開発作業と同様に、簡単に取得してコミットできます。

スキップされたレコードの解決のトラッキング

以前は、実際のアップグレード詳細レコード自体は顧客アップデートとして取得されませんでした。つまり、この「管理」作業はすべてのインスタンスで処理する必要がありました。

ServiceNow の Paris リリース以降、このプロセスははるかに簡単になりました。アップグレード詳細レコードの [解決] フィールドを変更すると、関連するアクション (ビジネスルールを元に戻したり、スクリプトインクルードを結合したりするなど) が更新セットにキャプチャされるだけでなく、アップグレードの詳細レコード自体も含まれるようになりました。

この動作は、ビジネスルール「解決変更時に更新セットに追加」によってトリガーされます。

sys_id -> incoming_version_payload_hash

更新セット内のキャプチャされたアップグレードの詳細レコードを確認すると、興味深いことに気付くでしょう。ペイロードフィールドにはsys_idが含まれていません。代わりに、「incoming_version_payload_hash」という値が含まれています。これにより、次のインスタンスで更新セットを取得してコミットするときに、アップグレード詳細レコードの Sys ID がインスタンス間で異なっていても、正しいアップグレード詳細レコードが更新されます。

アップグレード詳細レコードを手動でエクスポート/インポートしたり、更新セットに強制的に含めたりしても機能しないのは、Sys ID が異なるためです。

これらのスクリーンショットを作成するときに更新セットを変更しませんでした...悪い例です。まあ、意図はご理解いただけたかと思います。アップグレードの詳細は顧客アップデートとしてキャプチャされるため、スキップされたレコードを処理する前に更新セットを選択してください。

<edit>アップグレードの詳細に関する顧客アップデートを含む更新セットの例を以下に示します。</edit>

---

以上です!
これで皆さんのアップグレード体験が少しでもスムーズになることを願っています。

C	この内容がお役に立てば、ブックマークしていただくか、または役に立つとマークしていただければ幸いです。私が共有した、または参加した記事、ブログ、ビデオ、ポッドキャスト、プロジェクトにご興味がありますか？ - 記事、ブログ、ビデオ、ポッドキャスト、プロジェクトの共有 - 現場の経験

よろしくお願いいたします。

マーク・ロートフ

独立系 ServiceNow コンサルタント
ServiceNow MVPを10回受賞

---

リンクトイン

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/upgrades-and-patching-articles/processing-skipped-records-and-capturing-upgrade-details-in/ta-p/3403302

ServiceNow アップグレードでスキップされるレコードの削減

JunshuO — Mon, 14 Sep 2026 05:47:57 GMT

スキップされるレコードは ServiceNow のアップグレードでよく発生する問題で、多くの場合、標準 (OOB) レコードに加えられた変更が原因です。レコードがスキップされると、アップグレードプロセスが複雑になり、手作業が増加する可能性があります。この記事では、ServiceNow のアップグレードでスキップされるレコードを減らし、将来のアップグレードをより円滑にするための戦略について説明します。

概要: スキップされるレコードは ServiceNow のアップグレードでよく発生する問題で、多くの場合、標準 (OOB) レコードに加えられた変更が原因です。レコードがスキップされると、アップグレードプロセスが複雑になり、手作業が増加する可能性があります。この記事では、ServiceNow のアップグレードでスキップされるレコードを減らし、将来のアップグレードをより円滑にするための戦略について説明します。

スキップされるレコードが発生する理由

スキップされるレコードは通常、フォーム、クライアントスクリプト、ビジネスルール、ワークフローなどのカスタマイズされた標準 (OOB) アイテムが、アップグレード中に導入された更新と競合する場合に発生します。ServiceNow はカスタマイズを保持するためにこれらのレコードを「スキップ」しますが、これらのスキップを管理し、減らすことで、アップグレードプロセスを簡素化し、安定したプラットフォームを維持するのに役立ちます。

スキップされるレコードを減らす手順

1. カスタマイズのベストプラクティスに従う

標準 (OOB) レコードからカスタムレコードを分離する :

標準 (OOB) フォームまたはスクリプトを直接変更する代わりに、可能な限りカスタムバージョンを作成するようにしてください。
これにより、標準 (OOB) レコードがそのまま維持され、アップグレード中の競合が最小限に抑えられます。

例文 :デフォルトのIncidentフォームレイアウトを直接変更する代わりに、Custom Incidentビューを作成し、そこで変更を適用するようにしてください。これによりカスタマイズが分離され、今後デフォルトビューでスキップされるのを防ぎます。

スコープアプリケーションの使用 :新しいアプリケーションや大幅な機能変更の場合は、スコープアプリケーションを使用します。スコープアプリケーションは、カスタマイズをグローバルスコープから分離することでカスタマイズを保護し、スキップされるレコードを減らします。

2. 更新セットとソースコントロールを使用する

更新セットのすべての変更を追跡 :

すべてのカスタマイズを更新セットにキャプチャし、変更の詳細とともに各セットに明確な名前を付けます。
これにより、変更を追跡できるため、アップグレード時に競合を特定しやすくなります。

例文 :インシデント管理などの特定のモジュールに対する変更の更新セットを作成し、日付と目的のラベルを付けます (例:「インシデント UI の変更 - 2023 年 4 月」)。これにより、アップグレード中にこれらの変更を簡単に再確認できます。

ソースコントロールを使用 :

カスタマイズのために ServiceNow を Git と連携させます。ソースコントロールにより、将来のアップグレードのための簡単な追跡、バージョニング、および比較が可能になります。

例文 :ビジネスルールを変更する場合は、変更を適用する前にベースラインバージョンを Git に保存します。これにより、ServiceNow がルールを更新した場合に、ベースラインを最新バージョンと比較できます。

3. カスタマイズを定期的に確認して廃止する

古いカスタマイズを特定して削除する :

カスタマイズを定期的に監査して、関連する構成のみが残るようにします。
古いカスタマイズを廃止すると、スキップされるレコードを減らし、インスタンスをアップグレードしやすい状態に保つことができます。

例文 :何年も前に追加されたカスタムビジネスルールが不要になった場合は、削除するか無効にすることを検討してください。これにより、アクティブで必要なカスタマイズのみが残り、将来のアップグレードでの競合が減少します。

4. アップグレードセンターを活用する

アップグレードセンターツールの使用 :

ServiceNow のアップグレードセンターには、スキップされるレコードを管理するためのツールが用意されています。これを使用して、潜在的なスキップをプレビューし、本番アップグレードの前にそれらに対処します。

アップグレードのプレビュー :アップグレードのプレビューを実行して、競合を早期に特定します。

競合の解決 :比較機能を使用して、スキップされる各レコードを評価し、変更の保持、置換、または結合を決定します。

例文 :アップグレードセンターが変更されたクライアントスクリプトにフラグを立てた場合、カスタムバージョンを標準 (OOB) の更新と比較し、現在のビジネスニーズに基づいて変更を保持、採用、または結合するかどうかを決定します。

5. 標準 (OOB) スクリプトの直接的な変更を避ける

標準 (OOB) スクリプトの拡張または上書き :

ServiceNow のコアスクリプトまたは構成を直接変更する代わりに、カスタムスクリプトまたは代替構成を使用してそれらを拡張または上書きします。
この方法では、元の標準 (OOB) スクリプトを保持することで、アップグレード中にスキップされるレコードを最小限に抑えます。

例文 :もしIncidentUtilsスクリプトインクルードに追加機能が必要な場合は、新しいスクリプトインクルード（例：CustomIncidentUtils）を作成してIncidentUtilsを拡張するようにしてください。直接変更することは避けます。

新しい UI ポリシーまたはルールを追加 :

既存の標準 (OOB) ポリシーを変更するのではなく、新しいポリシーを追加します。これにより、ServiceNow が元のポリシーに加えた変更がカスタマイズと競合することがなくなります。

6. すべてのカスタマイズを文書化する

詳細なドキュメントを管理 :

ビジネス上の根拠、影響を受けるフィールド、依存関係など、各カスタマイズの目的と詳細を文書化します。

カスタマイズインベントリの作成 :

中央のドキュメントまたはデータベースでカスタマイズを追跡します。今後のアップグレードをより円滑にするために、各変更を行ったユーザー、目的、および依存関係を含めます。

例文 :カスタムデータフィールドを検証するビジネスルールが作成された場合は、理由、関連フィールド、およびそれが適用されるシナリオを文書化します。これにより、将来のアップグレードで競合を理解し、解決しやすくなります。

まとめ

ServiceNow のアップグレードでスキップされるレコードを減らすには、カスタマイズ管理に対する積極的なアプローチが必要です。標準 (OOB) レコードを変更する代わりにカスタムバージョンを使用する、アップグレードセンターを活用する、カスタマイズを定期的に監査する、変更を文書化するなど、これらのベストプラクティスに従うことで、よりアップグレードしやすいインスタンスをビルドできます。これらのプラクティスを実装すると、スキップされるレコードが最小限に抑えられ、将来のアップグレードがより迅速かつ効率的になります。

これらの手順に従うことで、チームは手作業による競合解決ではなく付加価値の高いアクティビティに集中できるようになり、ServiceNow プラットフォームの信頼性と効率性が向上します。

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/reducing-skipped-records-in-servicenow-upgrades/ba-p/3102307

Japan Blog 記事

World Forum Tokyo 2026で体験するServiceNow Universityの世界

5つのアクティビティで、あなたの「今」と「次の一歩」を見つけましょう！

Level Up Challenge：200ポイントを目指しましょう！

AIによる学びの世界を、ぜひ体験しにお越しください

World Forumでの、ServiceNow Universityの取り組み

日比谷オフィスでの追加開催決定！APOMトレーニングの魅力を講師インタビューでご紹介🎤

パートナーさんと一緒にImpactを活用する編 vol.1 - まずはアクセラレーターから始めてみませんか？-

💡 本格的な検証の前に、「ServiceNow社のベストプラクティス」に対する理解を深めていただくことが可能です

💡パートナーさんにも参加いただきたいおすすめのアクセラレーター

🔍 アクセラレーターの詳細はこちら

✅ 今回のまとめ

ServiceNowをもっと有効活用いただく編 vol.3ーその機能リクエスト、Idea Portalに送ってみませんか？

📋 Idea Portalとは？

📋 Idea Portalアクセス方法

📝 リクエスト記載のコツ

🔍 リクエストはどのように処理されるのか？

✅ 今回のまとめ

「AI人材育成のリアル」に「組織的なAI人材準備の指南書」を

AI人材を組織的に育成する際の指南書がServiceNow Universityで公開されています

最新技術を最速で学ぶためにブラウザ翻訳を最大限活用しよう

SNUのUIをブラウザ翻訳

フレーム化されたコンテンツをブラウザ翻訳

Level 2の方法が使えない場合

Level 2・3でも翻訳できない場合

まとめ

ServiceNowをもっと有効活用いただく編 vol.2-OOTB差分リストで、翻訳変更をアップグレード前にチェックしよう

📋 OOTB差分リストとは？

💡 OOTB差分リストでできること

📝 確認方法は簡単3ステップ

🔔 新しいリストの公開通知を受け取るには

✅ 今回のまとめ

World Forum Tokyo 2026で、ServiceNow認定資格無償受験を開催します！

開催概要

こんな方におすすめです

受験者への ギフト🎁

お申し込みについて

ServiceNowをもっと有効活用いただく編 vol.1-製品ドキュメントの日本語、気になったことはありませんか？

💡 こんなときにフィードバックをお送りください

📝 フィードバックの送り方

🔍 フィードバックの確認・対応について

✅ 今回のまとめ

「CVSS 7.0以上は30日以内」はもう古い？ ― CISA BOD 26-04にServiceNow VRでどう対応するか

はじめに：「CVSS 7.0以上は30日以内」― その運用、まだ続けていますか？

この数字はどこから来たのか

2019年と現在で、何が変わったか

そして、30日ルールの源流は撤回されました

目次

1. BOD 26-04の要点 ― 実装に必要な範囲だけ

1-1. 4つの二値変数

1-2. 是正期限の決定表（16通り・5階層）

1-3. 期限が「動く」という設計

2. ServiceNow VRでどう対応するか

2-1. Risk Calculator は2層でできている

そもそも考え方が違う ― 加重加算は使いようがない

ルール層は「order 昇順・最初の一致で確定」する決定リスト

2-2. 設計方針 ― ServiceNow本来の流れに載せる

2-3. 4変数と標準項目の対応 ― 実機で確認した構成

4変数 × フィールド 確定表

Asset Exposure

2-4. 実装 ― Risk Calculator 5本 ＋ Remediation Target Rule 4本

Risk Calculator ― 5本のルールで16通りを表現する

Remediation Target Rule ― 4本。条件は Risk Rating だけ

同じ「3日」の中では Critical を先に着手する

「3日＋フォレンジック調査」をどう表現するか

「次回システム更新時」をどう表現するか

2-5. 期限を動的に再計算する

OOTBで再計算が走るのは KEV の変化だけ

埋めるべき3つの穴

再計算時の起点日 ― Recalculation method の選択

2-6. 実装ステップの推奨順序

2-7. アンチパターン ― 作り込みすぎないために

3. 日本企業への示唆 ― 金融庁・日銀要請との対比

3-1. 2026年5月、日本でも同じ問題に答えが出た

3-2. 日米の対比

3-3. だからBOD 26-04が実装の参考になる

まとめ

BOD 26-04が示した新しい運用

現行バージョンのServiceNowでの対応 ― 過剰なカスタマイズは不要

参考情報

受験者へのギフト🎁

4変数 × フィールド確定表

2-4. 実装 ― Risk Calculator 5本＋ Remediation Target Rule 4本