Zurichのレポート作成で事故る落とし穴まとめ：遅い・ズレる・見えないを防ぐ設計チェック

Zurichで「レポートは作れるのに怖い」が起きる理由

ServiceNowの学習を進めていると、レポートは早い段階で触ります。リストのフィルタを作って「これをグラフにしたい」と思うのは自然ですし、CSAの学習でも“データを見える化して説明できるか”は、理解の深さに直結します。

一方で、Zurich以降の環境では、レポートやダッシュボード周辺が「作れる」だけだと事故りやすい領域になっています。理由は単純で、レポートは“データの見せ方”ではなく、“権限・パフォーマンス・運用”の交差点だからです。リストなら見えていたのに、レポートだと見えない。あるいは、見せたくない集計が見えてしまう。作った直後は速いのに、数週間で重くなる。こういう話が現場で起きがちです。

この記事では、Zurich環境でレポートを作るときに混乱しやすい落とし穴を、暗記ではなく仕組みの理解として整理します。読み終わったときに、

• 「そのレポート、何を根拠に正しいと言える？」
• 「誰に見える？見えちゃう？見えない？」
• 「半年後も運用できる？」

を自分でチェックできる状態を目指します。なお、Zurichは現在もパッチが継続している現行リリースとして扱われています。

---

“正しいデータ”の前提がズレる落とし穴

同じ条件のはずなのに、数字が違う

最初に起きやすいのがこれです。

• リストで「Active = true」の件数
• レポートで同じ条件にしたつもりの件数

がズレる。ここで焦って「レポートのバグ？」となりがちですが、まず疑う順番があります。

期間条件が暗黙で入っていないか

レポートは、種類や設定によって**期間（いつのデータか）**が暗黙に影響します。代表例は「作成日」「更新日」「クローズ日」などの“日付フィールド基準”が、グラフ側の設定で変わっているケースです。

• リスト：条件がすべて自分のフィルタに見えている
• レポート：条件に加えて「Trend by（どの日時で時系列化するか）」などの設計要素が入る

この差を意識すると、「条件は同じでも、集計の軸が違う」ことに気づけます。

集計（Aggregation）の意味が違う

Countは分かりやすいですが、AverageやSumなどを使い始めると、途端に“正しさ”が揺らぎます。例えば「平均解決時間」を出したいとき、解決時間の定義はどのフィールドで担保しているのか（ビジネスルールやSLAの影響はあるのか）まで含めないと、数字だけが独り歩きします。

試験対策としては、「レポートは“見た目”ではなく、“何を集計しているか”を説明できるか」を意識すると、理解が崩れにくいです。

データが“近い未来”で変わることを忘れる

もう一つの落とし穴は、レポートがリアルタイムのスナップショットである点です。今見た瞬間の件数は、次の更新で変わります。運用レポートならそれで良いのですが、経営層向けや月次報告で「数字が変わった」が起きると信用を落とします。

ここで覚えておきたい考え方はシンプルで、

• リアルタイムで良い可視化：運用監視、当日対応状況
• 固定した数字が必要な可視化：締め処理、月次、監査

後者に近い用途なら、Performance Analyticsやスナップショットの考え方も視野に入ります（「レポートだけで全部やる」から外れる判断ができると強い）。

---

参照フィールドのドットウォークでハマる落とし穴

ドットウォークは便利だが、無限ではない

「IncidentのAssigned toのCompanyでグルーピングしたい」みたいな要望はよくあります。そこで参照フィールドを辿るのがドットウォークです。

ただし、公式ドキュメントでも推奨のチェーン長は3階層とされています。
例：incident.assigned_to.company は3階層で、ここまでは分かりやすい。

これを超えて深掘りすると、以下が起きやすくなります。

• フィールド選択が複雑になり、設計意図が伝わらない
• 実行が重くなり、表示に時間がかかる
• 参照先の権限やデータ品質に引きずられ、結果が不安定になる

「できる」より「運用できる」を優先するなら、ドットウォークを深くする前に、中間の情報を別フィールドに持つ／設計を変えるという発想が役に立ちます。

拡張テーブルの理解がないと“対象外”が混ざる

ServiceNowはTask系など、拡張テーブル（親子関係）が多いです。ここを理解しないままレポートを作ると、

• 期待していない子テーブルのレコードが混ざる
• 逆に、欲しいレコードが集計されない

が起こります。ドットウォークの説明でも、拡張テーブルを前提にした例が出ています。

学習としてのコツは、レポート作成のたびに「どのテーブルを母集団にしているか」を言語化することです。
「Incidentの集計」なのか、「Taskの集計の中でIncidentだけを条件で絞っている」のか。ここがズレると、数字が合わない原因をいつまでも追い続けることになります。

---

共有・権限・セキュリティで詰む落とし穴

ここがZurich環境のレポート作成で一番“事故”につながりやすいところです。結論から言うと、レポートはACLと別の入口で制御されることがある、という点です。

report_viewで「見える／見えない」が決まるケース

ServiceNowには report_view という操作（operation）のACLがあり、これがレポートや可視化の閲覧を制御します。公式ドキュメントでは、report_viewは「レポートへのアクセスを制限するACL」で、必要ロールを持つユーザーだけが閲覧できる、と整理されています。

さらに重要なのが、

• report_viewには テーブルACL と フィールドACL がある
• フィールドACLは、Group byや集計にそのフィールドを使った時点で「アクセス拒否」になり得る

という点です。

つまり、普段は読めるテーブルでも、**“そのフィールドで集計する”**という行為によって、閲覧制御が変わる可能性があります。
これが「リストでは見えるのに、レポートは見えない」の代表的な原因になります。

report_viewはスクリプト条件を使えない

report_viewの設計上の注意点として、ロールによる制限のみをサポートし、スクリプトや高度な条件は使えないと明記されています。
ここを知らずに「条件で例外を作ろう」とすると迷子になります。

なので設計の現実解はだいたい次のどれかです。

• report_viewはロールでシンプルに区切る
• “見せたくないデータ”はそもそもテーブル／フィールドのread ACLで守る
• 可視化用にデータの持ち方（テーブル設計・集計対象）を見直す

セキュリティ強化で「公開」が危険になりやすい

運用上ありがちなのが「とりあえず共有」「とりあえず公開リンク」です。
ただ、セキュリティ側のガイドには、未認証で公開されたレポートの無効化といった項目も含まれています。

これは「公開＝悪」ではなく、公開するなら“誰が見えるのか”を説明できる状態でというメッセージに近いです。CSA学習者目線でも、セキュリティと可視化が衝突するポイントを知っておくと、設問の読み取りが楽になります。

---

パフォーマンスと運用で詰む落とし穴

いちばん効くのは「同じ条件を量産しない」設計

実務でレポートが増えてくると、同じような条件を各レポートにコピペし始めます。これが後々の地獄の入口です。

そこで使いたいのが Report Source（Report DesignerではData Sourceと呼ばれる）です。
公式ドキュメントでは、Report Sourceは「事前定義されたデータセット」で、同じ条件を繰り返し定義しなくてよくなり、組織全体で同じ定義を実装できる、と説明されています。

さらに重要ポイントとして、

• Report Sourceの条件を更新すると、そのSourceに基づくレポートへ自動的に反映される

これ、地味ですが運用でめちゃくちゃ効きます。
「定義は一か所、表示は複数」という形に寄せると、レポートが増えても破綻しにくくなります。

ただし、OR条件や関連リスト条件には注意

Report Source周りには細かい注意点もあり、例えば

• SourceがOR条件を含む場合、レポート側の条件と“両方に一致するレコードだけ”が対象になる
• 関連リスト条件やドットウォーク条件の組み合わせでエラーになることがある

このあたりは「設定を覚える」というより、**“条件の合成は簡単じゃない”**という感覚を持っておくのが大事です。試験でも実務でも、条件の合成がテーマになると混乱しやすいからです。

スケジュール配信は「便利」より「事故らない」が先

レポートは、共有や閲覧だけでなく、配信（メール等）まで含めると運用価値が上がります。ドキュメント上も、レポートには共有やメールスケジュールといった配布機能が整理されています。

ただ、配信は次の“見えないコスト”が乗ります。

• 送信先の権限は適切か（受け取った人が見るべき情報か）
• 添付形式や詳細データの扱いは安全か
• 件数が増えたときに、重くならないか

ここを雑にすると、レポートの信用ではなく「仕組み」そのものが嫌われます。
おすすめは、最初から完璧にするより、

• まずは管理者や限定ロールだけに配信して動作確認
• 次に受け手のグループ単位で展開
• 定義が固まったらReport Source化で保守性を上げる

という段階的なやり方です。

勉強を最短にするなら「一冊／一講座で体系化」もあり

レポート周りは、点で覚えると破綻します。テーブル、条件、集計、権限、共有、ダッシュボード…と繋がっているからです。

CSA学習者向けには、公式ドキュメントで概念を押さえつつ、全体像を短時間で整理できる教材を一つ持つのは合理的です。例えば Udemy のServiceNow CSA対策講座（レポートやACL、ダッシュボードを横断して学べるもの）を「体系的に学べる教材の一例」として使い、理解の穴を埋める、という使い方は相性が良いです。

---

Zurichのレポート作成は「表示」ではなく「設計」を問われる

Zurich環境でレポートを作るときに怖いのは、ボタン操作ではなく“前提のズレ”です。最後に、この記事の要点を一枚にまとめます。

• レポートの正しさは、条件だけでなく**集計軸・期間軸・母集団（テーブル）**で決まる
• ドットウォークは便利だが、推奨は3階層。深掘りは運用リスクになりやすい
• 「見える／見えない」は、read ACLだけでなく report_view が関係することがある
• report_viewはロール制御が中心で、設計はシンプルに。守るべきデータはread ACL側で守る
• レポートの増殖は運用負債。Report Sourceで定義を集約すると、保守性が一気に上がる
• 共有や配信は便利だが、セキュリティ観点のガイド（未認証公開の扱い等）も踏まえて慎重に

この整理ができると、試験でも実務でも「それっぽい画面操作」ではなく、「なぜそうなるか」を軸に判断できるようになります。
次にレポートを作るときは、まず“どのテーブルの、どの期間の、どの集計を、誰に見せるか”を一言で説明してから手を動かしてみてください。そこで迷わなくなったら、レポート作成はかなり安定してきています。