はじめに

執筆者紹介

こんにちは。株式会社ビズリーチ 経営基盤開発部のワークフローグループ（以下、WFG）に所属する岩山です。
2025年10月にキャリア入社しました。ServiceNow歴は3年半ほどになり、ServiceNow資格としては、CSA/CAD/CIS-DF/CIS-ITSM/CIS-VRを取得しています。
現在は、ワークフローやデータの基盤となるServiceNowの企画・開発を担当しています。

WFGでは、ServiceNowのAI開発・運用に関するルールや体制の整備、UI刷新、最新機能の導入を進めています。
こうした取り組みの一端について、2026年10月27日・28日にグランドプリンスホテル新高輪で開催されるServiceNow World Forum Tokyo 2026でも登壇予定です。

本記事では、ServiceNowダッシュボード基盤の刷新を契機に、Performance Analyticsを活用して、WFGが日常的に利用するダッシュボードを高度化した事例を紹介します。あわせて、AIを前提とした開発プロセスにより、通常約40時間を想定する開発・テストを4時間で完了した取り組みも取り上げます。

想定読者

ServiceNowのダッシュボード基盤を刷新した背景

レガシーダッシュボード基盤からの移行

ServiceNowは、一言で言うとワークフローを中心に幅広い業務を支えるSaaSです。半年ごとに1回のメジャーリリースでは、機能追加やUI改善が継続的に行われます。
先日、ServiceNowから既存ダッシュボード基盤（Core UI）に関する公式方針が発表され、Core UIが非推奨となることがアナウンスされました。
そこで、我々は2027年末の期限に先立ち、新ダッシュボード基盤であるPlatform Analytics UIへの移行を進めることにしました。

補足：Australiaリリース以降も、Core UIで作成済みのレポート・ダッシュボードは無期限に参照・編集でき、新規作成も2027年末までは可能です。一方で、Core UIに起因する製品不具合は原則として修正対象外となり、新ダッシュボード基盤（Platform Analytics UI）への移行または再作成が案内されています。

これは単なるUI変更ではなく、データモデルそのものや分析データの扱い方が変わるため、開発者による移行に加え、利用者が新しい画面で分析を行えるようにするためのガイダンスも必要になります。

以下は、従来のレガシーダッシュボード基盤と、新しいダッシュボード基盤の画面例です。

レガシーダッシュボード基盤（Core UI）の例
レガシーダッシュボード基盤（Core UI）の例
新ダッシュボード基盤（Platform Analytics UI）の例
新ダッシュボード基盤（Platform Analytics UI）の例

見た目が少しモダンなスタイルになった気がします。
加えて、従来はレポートの作成・編集画面とダッシュボードを行き来していたのに対し、新ダッシュボード基盤では、レポートの配置から詳細設定までの一連の操作をダッシュボード上で完結できるようになりました。

Performance Analyticsの活用

今回、Platform Analyticsに加えて、Performance Analyticsという機能も活用することにしました。
Platform Analyticsは、新ダッシュボード基盤そのものの名称ですが、Performance Analyticsはその基盤の上で高度なレポートを作成するための専門的な機能の名称です。

ここで、高度なレポートとは、過去時点でのスナップショット値を正確に可視化したり、カテゴリ別・アサイン者別などのブレークダウンによって数値の内訳を分析したりできるレポートを指します。
通常のレポートは、現時点のテーブルを集計し、その値を画面に表示します。一方で、「過去時点の集計値がいくつだったか」を、現在のテーブルだけから正確に再現できるとは限りません。

例えば、以下のように「未解決の問い合わせ件数」の折れ線グラフを表示したいとします。
問い合わせレコードからは、作成日時や解決日時、現在のステータスを確認できます。
ただし、ステータスや担当者などの値は業務の進行に伴って更新されるため、現在のレコードだけを見ても、過去時点での正確な情報がわからないことが多いです。

Performance Analyticsであれば、過去時点での正確な集計値が表示可能
Performance Analyticsであれば、過去時点での正確な集計値が表示可能

Performance Analyticsでは、こうした過去の状態を都度再計算するのではなく、あらかじめ定義したKPIを定期的に集計し、その時点のスコアとして保存します。
これにより、「その時点で何件だったのか」という過去の状態を時系列で追跡できるようになります。

補足：正確には、Performance Analyticsを導入していない場合でも、履歴データは直近180日まで収集できます。しかし、180日を超える長期の履歴データを収集・分析するには、Performance Analyticsの導入が必要です。

このように、我々は新ダッシュボード基盤であるPlatform Analyticsへの移行と、Performance Analyticsの活用を通じて、ServiceNowのダッシュボード基盤を刷新することにしました。
次の章では、その第一歩としてServiceNowに寄せられる問い合わせや申請に関する運用ダッシュボードを刷新した事例を取り上げ、実際にどのような分析が可能になったのか、また利用してみて感じた効果や所感を紹介します。

WFGでの新ダッシュボード基盤の活用と評価

WFGにおける業務分析の現状と課題

WFGでは、ServiceNow上で扱われる問い合わせや申請の件数や傾向を継続的に計測・分析しています。
問い合わせや申請は毎日100件前後発生しており、月間でそれぞれ1000件以上のデータがServiceNow上に蓄積されます。内容は、社内システムに関する問い合わせから各種業務の申請・依頼まで幅広く、さまざまな業務領域に関わります。

WFGでは、こうした問い合わせ・申請の状況を把握するため、以下の4つのKPIを日常的に確認しています。

ただし、KPIの過去時点の値をServiceNow上に蓄積し、時系列で可視化するにはPerformance Analyticsが必要でした。 従来はPerformance Analyticsが活用できていなかったため、別の集計ツールを使って手作業でレポートを作成しており、必要以上に手間がかかっていたのです。

今回の刷新では、新ダッシュボード基盤への移行にあわせてPerformance Analyticsを活用し、これまで別ツールで補っていた集計作業をServiceNow上に集約しました。そして、利用者体験としても、メトリクスから個別レコードの詳細まで一貫してたどれる分析基盤へと高度化しました。
これにより、手動で数値を集計して確認する運用から、ServiceNowの中で自動的に集計を行い、その背景や要因まで掘り下げて判断できる運用へと変化を遂げています。

新ダッシュボード基盤の導入で見えた主な有用機能

開発プロセスの詳細については後述します。ここでは、新ダッシュボード基盤への移行とPerformance Analyticsの活用の中で、特に有用だった3つの機能を紹介します。

①半年以上前のKPIの可視化 - Performance Analytics

前述の通り、Performance Analyticsを利用すると、半年以上前まで遡って過去時点のKPIスコアを可視化できます。
これにより、集計・分析をServiceNow上に集約できるだけでなく、正確な過去データをもとに傾向を把握し、将来の予測やリソース計画の策定にも活用できるようになりました。

②ブレークダウンによるKPIの多角的な分析 - Performance Analytics

Performance Analyticsのブレークダウンを利用すると、収集したKPIをカテゴリや担当者などの切り口で分解できます。
これにより、全体の数値に変化があった際に、その要因をカテゴリや担当者単位で掘り下げて確認でき、より的確な判断や意思決定につなげられるようになりました。

ブレークダウンが利用できる高度なレポートの例
ブレークダウンが利用できる高度なレポートの例

③ダッシュボードの環境間移送の簡素化 - Platform Analytics

これは、ServiceNow管理者にとって特に嬉しい改善です。

レポートやダッシュボードに限らず、本番環境へ直接変更を加えることはできるだけ避け、開発環境で作成・検証したうえで本番環境へ移送したいところです。
しかし従来は、ダッシュボードのレイアウトとレポート・ダッシュボードの定義が別々に管理されていたため、レイアウトはXMLで個別に移送し、関連するシステム定義は別途リリースする必要があり、結果として1つのダッシュボードを移送するにも複数の手順を踏む必要がありました。

一方、Platform Analyticsへの移行後は、これらをほかのServiceNow設定と同じリリース工程に載せ、まとめて本番環境へ移送できるようになりました。

AIエージェントによるダッシュボード開発効率化

Performance Analyticsの構成要素

テーブルを直接集計する通常レポートであれば、条件と集計方法を設定してすぐにグラフやリストを作成できます。
一方、Performance Analyticsを活用した高度なレポートの場合、グラフを配置する前に、「何を、どの条件で、いつ収集し、どの切り口で見るか」を設定する必要があります。
以下、データがレポートとして表示されるまでの流れに沿って、レポートの構成要素を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

凡例：【 】Platform Analytics / Performance Analyticsの構成要素

業務データ
  ↓
集計対象となるテーブルと共通条件を定義【インジケーターソース】
  ↓
KPIごとの集計条件と集計方法を定義【自動インジケーター】
  ↓
分析軸を定義【ブレークダウン】
  ↓
KPIと分析軸を対応付け【ブレークダウンマッピング】
  ↓
日次・週次・月次でKPIを収集【データ収集ジョブ】
  ↓
収集時点の値と内訳を保存【スコア】
  ↓
グラフ、リスト、ピボットテーブルとして表示【ダッシュボード】
Platform Analytics / Performance Analyticsの全体像
Platform Analytics / Performance Analyticsの全体像(AI生成による参考画像)

ServiceNowには、Platform Analyticsの構成・実装・保守に関する知識を対象とした専用認定資格、Certified Implementation Specialist - Platform Analytics（CIS-PA）も用意されています。

なお、ブレークダウンとブレークダウンマッピングは分析軸ごと、データ収集ジョブは収集頻度や定期収集・履歴収集の用途に応じて構成するため、複数のレポートをまとめたダッシュボードの場合、開発工数が雪だるま式に増えることもあります。
本記事で最も伝えたいのは、こうした複雑な構成を人力だけで開発するのではなく、AIエージェントを正しく活用することで、開発工数を大幅に削減した仕組みと成果です。

AI前提の開発プロセス設計

今回の開発は、次の流れで進めました。

1
2
3
4
5
6
7

人間：要求定義
  ↓
AI：要件整理・設計・実装・一次検証
  ↓
人間：二次検証
  ↓
AI：移行準備・ドキュメント作成（設計書・README.LLM）

方法論としては、AIに開発環境をバックグラウンドスクリプトで操作させて実装しました。新ダッシュボード基盤であれば、ダッシュボードのレイアウトといったUI領域の実装タスクもこの方法で容易に完遂することができます。実装後の動作確認や、問題があった場合の原因調査・修正もAI自身が行い、さらに本番環境へのリリースに向けた移行準備や、ドキュメント管理ツールのMCPサーバーを通じた設計書作成まで担います。
一方で、人間の役割は、現場がどのようなビジネス指標を可視化したいのかといったコンテキストを的確に捉え、AIの成果物がその要求を本当に満たしているかを見極めることと定義しました。

補足：なお、利用しているAIサービスは法人契約のもとで運用しており、入力したデータがモデルの学習に利用されることや第三者に開示されることはありません。

さらに今回は、ハーネスエンジニアリングとループエンジニアリングの考え方を取り入れました。実装方法や注意点をまとめた開発ドキュメント（README.LLM）をドキュメント管理ツール上で管理し、AIが毎回参照するというルールで設計しています。
これにより、以前AIがつまづいたミスを再発させないようにし、ServiceNowやデータエンジニアリングの知見が十分でないメンバーでも、要求仕様を整理してAIに指示するだけで高度なレポートを作成できる仕組みを整えました。

次節では、この開発プロセスの変更によって得られた定量的な工数削減の効果を示します。

数字で見るAI開発の効果

本節では、AI活用によって工数削減効果を得られた要件整理以降のステップを対象として定量評価します。

今回作成・修正したServiceNow設定の差分は、全部で695件でした。成果物は、次の5つのタブからなるダッシュボードです。

各タブには、それぞれ複数の高度なレポートを配置しています。

作成したダッシュボード画面（イメージ）
作成したダッシュボード画面（イメージ）

まずは、AIを使わずに完全に人手で実装した場合を試算してみます。1件あたりの実装時間を3分と置くと約35時間、ここに検証と設計書作成を5時間程度加え、合計で約40時間かかると仮定します。
一方、AIを前提とした今回の開発では、人間の正味の作業量はわずか4時間に収まりました。

その差は、なんと10倍です。

見積もりが甘いのではないか、と思われるかもしれません。ただ、ServiceNow開発に3年半携わってきた筆者の経験上、1日5時間稼働としてこの量を8日で仕上げるのはむしろ、厳しいくらいではないかと思います。
また、ループエンジニアリングを取り入れた効果によって、AIはダッシュボード開発の勘所を自律的に学習していくため、開発ミスが起こって人間が介入することも今後は減っていきます。
上記を踏まえると、長い目で見た時の実質的な工数削減効果は、10倍どころか100倍に届いてもおかしくないと考えています。
ただし、ここで重要なのは数字の大きさそのものではなく、AIは工数改善の域を超えてプロセスのほぼ全てを代替し、人間は他のより重要な仕事に時間をかけられるようになるということです。
ServiceNow開発にも、AIによる革命の波はすぐそこに来ています。

まとめ

今回は、Platform Analytics / Performance Analyticsというダッシュボード基盤について取り上げました。多くの組織で当たり前に使われている機能ですが、みなさまの組織ではどのように活用されていますでしょうか。
そして後半では、AIエージェントを前提とした開発プロセスと、その効果を事例として紹介しました。
本記事がみなさまの現場で少しでもお役に立てば幸いです。

最後に、冒頭でも触れましたが、ServiceNow World Forum Tokyo 2026の10月27日のセッションに登壇予定です。本記事では触れていない、Impactの活用状況や、経営・マネジメントにおける活用シーン等の事例も紹介します。イベントに参加される方は、ぜひ弊社のセッションにも足をお運びいただけますと幸いです。

Tips - Platform Analytics移行に関して

ServiceNow開発者がPlatform Analytics移行の際につまずきやすそうなポイントをTipsとして挙げておきます。

以上です。

ビズリーチでは、新しい仲間を募集しています。

お客様にとって価値あるモノをつくり、働く環境の変革に挑戦する仲間を募集しています。
募集中のポジションやプロダクト組織の詳細は、ぜひキャリア採用サイトをご覧ください。

ビズリーチ採用サイト
岩山 凌也
岩山 凌也

株式会社ビズリーチ 経営基盤開発部ワークフローグループのエンジニア。主にServiceNowの企画・開発とAIエージェント基盤開発に携わっています