ServiceNowの最新バージョンを調べると、Yokohama、Zurich、Australiaなどの名前が出てきます。では、現在の環境と何が違い、管理者や開発者の作業はどう変わるのでしょうか。
この記事では、Australia Patch 2のPDIを実際に起動し、フローの変更履歴の比較、変更後のテスト実行、インシデントの可視化を確認しました。公式リリースノートで変更点を整理したうえで、操作手順と実画面、試して分かったことを紹介します。
検証日:2026年9月16日(日本時間)。画面は英語UIです。PDI内の日時表示は日本時間と異なるため、画像に前日の日付が含まれます。
ServiceNowの最新バージョンは?YokohamaからAustraliaへの流れ
2026年9月16日の調査時点で、一般提供済みの最新ファミリーとして確認できるのはAustraliaです。公式ドキュメントに記載されたAustraliaの一般提供日(GA)は2026年5月5日です。Yokohamaを「最新」とする記事は、その記事の確認日も併せて読む必要があります。Australiaのリリース日(公式)
直近のファミリーを、今回の検証に関係する変更と一緒に整理しました。全バージョンの一覧ではなく、Yokohama以降の位置づけをつかむための表です。
| ファミリー | 一般提供日 | フロー開発で注目するポイント |
|---|---|---|
| Yokohama(横浜) | 2025年3月12日 | Flow debuggerなど、フローの動作を追うための機能 |
| Zurich(チューリッヒ) | 2025年9月10日 | フロー・サブフローの履歴表示と管理 |
| Australia(オーストラリア) | 2026年5月5日 | 2つのフロー履歴を左右に並べて比較する機能 |
日付の出典:Yokohamaの公式リリース情報、Zurichの公式発表。変更点の出典:Yokohamaのフローリリースノート、Zurichのフローリリースノート、Australiaのフローリリースノート。
次のBrazilについては、調査時点のServiceNow社員による案内に、Early Availability(EA)が9月24日予定と記載されています。先行提供の予定と一般提供済みのバージョンは区別してください。本記事ではBrazilの実機検証は行っていません。Brazil EAと9月のStore更新に関する案内
「新しいファミリー」と「最新パッチ」は別の確認項目
Australiaという名前が同じでも、PatchやHotfix、インストール済みアプリの版が違えば、使える機能や修正内容が一致するとは限りません。今回の環境はAustralia Patch 2であり、最新パッチまで適用済みの環境として紹介しているわけではありません。
さらに、Workflow Studioのホーム画面には、新しいバージョンへの更新案内が表示されました。ファミリー名を確認しただけでは、Storeアプリも最新であると判断できないことが、実画面からも分かります。製品ごとの変更点を読むときは、ファミリーのリリースノートとアプリの更新履歴をセットで確認すると整理しやすくなります。Workflow StudioのStore版リリース履歴
PDIでServiceNowのバージョンを確認する方法
今回最初に行ったのは、Developer Portalから休止中のPDIを復帰させ、管理者として環境に入ることです。その後、インスタンスのホスト名に続けて /stats.do を開き、ビルド情報を確認しました。
確認できた値は次のとおりです。
| 項目 | 今回のPDIの表示 |
|---|---|
| Build name | Australia |
| Build date | 04-29-2026_2044 |
| Build tag | glide-australia-02-11-2026__patch2-04-17-2026 |
| 操作ユーザー | System Administrator |

記事や社内の検証記録では、「Australiaで確認」だけでなく、この程度まで環境を残しておくと再現しやすくなります。手順が同じなのに画面が違った場合にも、最初に版の違いを確認できます。なお、この画面の閲覧可否は環境の権限や設定に依存するため、企業の環境では管理者が許可された方法で確認してください。
今回行ったのは、既存のPDIを起動してその版を確認する作業です。YokohamaからAustraliaへのアップグレード作業や、旧環境と新環境の同条件比較は実施していません。以下の「新機能」は公式資料で追加時期を確認し、「動いた」という記述は今回のPDI操作に基づいています。
実機検証1:フローの変更履歴を左右に並べて比較
Australiaで特に試してみたかったのが、Flow historyのCompare entryです。以前の設定を開くだけでなく、2つの履歴を並べて、追加・削除・変更された内容を確認できます。履歴そのものはZurichのリリースノートにも記載されているため、「履歴機能がAustraliaで初めて登場した」と理解しないようにしましょう。履歴比較の公式手順
まず、比較するための小さなフローを作成
Workflow StudioのFlowsから新しいフローを作り、名前を Release Lab 20260916 - History Compare としました。トリガーはDaily、アクションはServiceNow CoreのLogを1つだけ配置しています。
今回の目的は履歴と実行結果の確認なので、インシデントの更新、メールの送信、承認依頼などは組み込んでいません。フローはInactiveのままにし、後ほどTestから手動実行しました。Dailyトリガーを設定したことと、毎日の自動実行を開始したことは別です。
最初のLogには、LevelをInfo、Messageを Australia PDI verification - baseline と入力して確定しました。その後、Messageの末尾を updated に変更し、保存が完了してから履歴を開きます。

再現するときの操作順は次のとおりです。
- Workflow StudioでFlowsを開き、検証用フローを作成する。
- DailyトリガーとLogアクションを設定し、比較元のメッセージを保存する。
- Logのメッセージを変更し、再び保存完了を確認する。
- 右側のサイドバーからHistoryを開く。
- 比較したい過去の履歴カードのメニューでCompare entryを選ぶ。
- 左右のLogアクションを展開し、Messageの値を見比べる。
同じ時刻付近に複数の自動保存履歴が残ることがあるため、日時だけで判断せず、開いた内容が比較したい版かどうかも確認しました。
結果:変更したLogが青く表示され、入力値を比較できた
実際の比較画面では、左側に baseline、右側に updated が表示されました。変更対象のLogアクションは青い背景で示されています。

試して分かったのは、差分を見たいときには、アクションの行を展開するところまで進む必要があるという点です。フロー全体を眺めているだけでは、どの入力値を変えたのかが分かりにくくても、左右を展開すれば値の違いを直接確認できます。
今回の変更は1行の文言ですが、実務であれば「アクションの構成は同じなのに挙動が変わった」という場面で、入力値の変更を追う手掛かりになりそうです。ただし、この機能だけで権限、参照先データ、連携先の状態まで説明できるわけではありません。フロー定義の差分を確認した後に、実行時の値も確認する、という使い方が適しています。
実機検証2:変更後のフローをTestから実行
比較できたことに加えて、変更した版が実際に動くかも確認しました。比較画面から編集画面に戻り、Testを選択します。今回のトリガーでは入力が不要で、テスト確認画面から実行するとすぐに処理が開始されました。
完了後に実行詳細を開くと、フロー全体とLogアクションの両方がCompletedになっています。Logの詳細では、MessageのRuntime Valueが Australia PDI verification - updated で、設定値と一致していました。Action Statusにはcodeが0、messageがSuccessと表示されました。

| 確認項目 | 実際の結果 |
|---|---|
| フローのテスト | Completed |
| Logアクション | Completed |
| Messageの実行時の値 | Australia PDI verification – updated |
| Action Status | code: 0 / message: Success |
| 自動実行の有効化 | 実施せず、Inactiveを維持 |
ここで確認したのは、Logアクションに渡された実行時の値と処理結果です。システムログ一覧に出力された行の追跡までは行っていません。また、画面に短い実行時間が出ても、この1回の小さなテストからAustraliaの性能向上率を判断することはできません。
履歴比較は「何を変えたか」、実行詳細は「その設定で何が実行されたか」を読むための材料になります。この2つを続けて確認できたことが、今回の検証で最も分かりやすかった点です。フローとスクリプトの使い分けから確認したい場合は、Business RuleとFlow Designerの違いも参考にしてください。
実機検証3:Platform Analyticsで使用状況と割合を確認
Australiaの分析機能では、Platform Analyticsのナビゲーションやライブラリの使用状況表示、割合の表示などにも変更が案内されています。今回は分析画面を開き、ライブラリのカード操作と、Incidentテーブルを使ったドーナツグラフの作成を行いました。Platform Analytics experienceのリリースノート
可視化ライブラリで「使われていないもの」を探す
AllメニューでPlatform Analyticsを検索し、LibraryのData Visualizationsを開きました。画面には、ダッシュボードで使われていない可視化、長期間閲覧されていない可視化などを確認するカードがあります。
新しい可視化を作る前の一覧は131件でした。「Not used in any dashboard」のカードを選択するとCountは0となり、一覧にはNo data to displayと表示されました。

0件という結果だけで「不要な可視化が一切ない」「企業の環境でもすぐ正確な棚卸しができる」とは判断していません。今回はカードの表示と、クリックによる絞り込み動作を確認したものです。実運用の棚卸しでは、使用状況データがどの範囲まで収集されているかと、可視化を利用する業務の両方を確認する必要があります。
IncidentをPriority別に集計し、割合の数値まで確認
次に、Create data visualizationから Release Lab 20260916 - Incident Priority を作成しました。Data sourceには Incident [incident] を選び、追加の条件は設定していません。MetricはCount、Visualization typeはDonut、Group byはPriorityです。
PresentationのDisplay settingsには、Show data tableとShow % of total in tooltipが表示されました。今回の環境では後者が選択済みだったため、その状態を確認し、Show data tableを選択して保存しています。円・ドーナツグラフの公式設定手順

表示されたデータ表の値を整理すると、次の結果になりました。
| Priority | 件数 | データ表に表示された割合 |
|---|---|---|
| 1 – Critical | 27 | 36.99% |
| 2 – High | 4 | 5.48% |
| 3 – Moderate | 12 | 16.44% |
| 4 – Low | 12 | 16.44% |
| 5 – Planning | 18 | 24.66% |
| 合計 | 73 | 丸めにより表示値の合計は100.01% |
たとえばCriticalの27件を全73件で割ると約36.99%になり、画面の表示と一致します。件数だけでなく構成比が分かるため、「どの優先度が多いか」を説明する資料に使いやすいと感じました。ただし、この分布は学習用PDIにあるデータの結果であり、一般企業の障害傾向を示すものではありません。
今回確認した範囲は、グラフの描画、データ表の件数・割合、設定の保存成功です。マウスを重ねたツールチップ自体の表示は検証していないため、画像と表はデータ表側の実測値として紹介しています。また、ドーナツグラフの作成そのものをAustraliaで初登場した機能と説明しているわけではありません。
Platform AnalyticsとPerformance Analyticsの役割から整理したい場合は、両者の違いと使い分けで、現在のデータの可視化と継続的な指標管理の考え方を確認できます。
公式資料で確認した新機能と、今回の未検証範囲
Australiaのフローリリースノートには、既存の業務カレンダーを使うBusiness calendarトリガーや、生成AIによる実行結果の分析も記載されています。今回の実験では通常のDailyトリガーを使用しており、業務カレンダーに従った自動実行やAIによる分析結果までは確認していません。Australiaのフロー機能
PDIの入口にはBuild AgentやServiceNow Studioへの導線もありました。ただし、入口があることと、目的のAI機能が使えることは同じではありません。今回、AIによるアプリ生成は実行していません。特定機能を試す際は、必要な製品、Storeアプリの版、権限、利用条件をその機能の資料で確認する必要があります。
新バージョンを調べるときは、まず「公式資料で追加とされるもの」「自分の環境に表示されたもの」「実際に保存・実行できたもの」の順に確認すると、導入判断に使える記録になります。本記事では、実機で動かせた履歴比較と分析画面を中心に紹介しました。
Australiaへのバージョンアップ前に確認したいこと
実機を触ったうえで、検証計画に入れておきたいと考えたのは、次の4点です。
- 現在のファミリー・パッチ・対象アプリを記録する。 「Yokohamaから移行」といった情報に加えて、実際に使用しているアプリも整理します。
- 移行元に対応したリリースノートを読む。 今回の記事で触れた機能だけでなく、自社が利用する製品の変更、修正、移行作業を確認します。
- 主要な業務フローと分析画面を検証する。 申請、承認、レコード更新、通知、レポート表示など、利用者の操作単位で期待結果を用意します。
- 変更箇所と実行結果を両方記録する。 履歴の差分だけで完了にせず、テスト時の値と実際の結果を確認します。
公式のアップグレード案内も、移行元からAustraliaまでの変更内容を確認するよう案内しています。最新機能の一覧を読むだけでは、自社環境に必要な確認項目は決まりません。Australiaへのアップグレードに向けた情報
回帰テストの進め方は、ServiceNow ATFの使い方とベストプラクティスも参考になります。今回のLogだけの成功結果を、そのまま本番アップグレードの適合判定に使わないことが大切です。
よくある質問
ServiceNowの最新バージョンはYokohamaですか?
2026年9月16日の確認時点では、一般提供済みの最新ファミリーとしてAustraliaを確認しています。Yokohama、Zurich、Australiaの順に提供されています。「最新」という表記は確認日と一緒に読み、予定されているEAと提供済みのGAを区別してください。
Australiaにすれば、記事と同じ機能が必ず使えますか?
ファミリー名だけでは判断できません。今回の検証環境はAustralia Patch 2で、管理者ユーザーを使用しました。Storeアプリの版、権限、インストール済み製品などによって違いが出るため、自分の環境の条件と照合してください。
今回のPDIで、実際にどこまで動かしましたか?
フローを新規作成し、Logのメッセージを変更して履歴を比較し、Testから手動実行してCompletedとSuccessを確認しました。Platform Analyticsでは未使用可視化のカードを操作し、IncidentのPriority別ドーナツグラフを作成・保存して73件の集計を確認しています。
リリースの新機能は、そのままCSAの出題範囲になりますか?
新機能を読んだら、自分のPDIでも小さな例を1つ作り、変更前後と実行結果を残してみてください。今回の検証では、履歴比較で定義の変更を確認し、その直後のテストで変更後の値を確認する流れが、Australiaを理解する具体的な入口になりました。
