ServiceNowを触っていると「何が起きたか」はだいたいログと履歴に残ります。逆に言うと、ここを追えないと、設定ミスなのか権限なのかデータなのか…判断がつかずにハマりがちです。
特にCSA学習では、仕組みとして“どこに何が残るのか”を理解しているかが効いてきます。暗記ではなく、「原因にたどり着く筋道」を作るために、Zurich基準で“ログ・履歴の見方”を整理します。
この記事で扱うこと
- ログと履歴を「目的別」に分ける考え方
- システムログとトランザクションのつなげ方
- 監査と履歴の違いと、どこを見ればよいか
- メール、Flow、Importなど“よく使う周辺ログ”の追い方
- 現場でも試験学習でも使える「見る順番テンプレ」
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
ログと履歴を追うための全体像
まず大枠から。ServiceNowの「記録」は、ざっくり次の4系統に分けると迷いにくいです。
- システムの出来事：エラーや警告など（例：System Log）
- 処理の流れ：1回の画面表示やAPI呼び出しの単位（例：Transaction Logs / syslog_transaction）
- レコードの変化：いつ誰が何を変えたか（例：Sys Audit / History sets）
- 機能別の実行記録：メール、Flow、Importなど（例：Email [sys_email]、Flow context、Import Log）
この切り分けを頭に置くと、「いま自分が知りたいのは何か」が明確になり、見る場所がスッと決まります。
まずは結論 “見る順番テンプレ”
初学者が混乱しやすいのは、いきなり深いログを掘り始めて迷子になることです。おすすめの順番はこれです。
- 何が起きたかをSystem Logで掴む（エラー文言、対象の機能名、発生時刻）
- 同じ時刻帯のTransactionで1回の処理にまとめる（誰が、どのURL/どの操作で、どれくらい時間がかかったか）
- 対象レコードの履歴で“変化の事実”を確定する（誰が、どのフィールドを変更したか）
- 必要に応じて機能別ログへ分岐（メールならEmailログ、Flowなら実行詳細、ImportならImport Log）
この「上から下へ」さえ守れば、深掘りが必要になっても筋が通ります。
System Logを使いこなす
System Logは、トラブルの入口として最強です。基本は All > System Log > All で syslog を見る、これが出発点になります。ログの閲覧手順として「All > System Log > All」「Log [syslog] テーブル」と明記されています。
System Logで見るべきポイント
- 発生時刻：あとでTransactionや履歴と突き合わせるため
- Severity：error / warning / info のどれか
- Source：どのアプリや機能が出したログか
- Message：検索キーワードになる本体
ありがちなコツ
- まずは“contains”検索：完全一致より、機能名や短い特徴語で絞る
- 1件に絞ろうとしすぎない：最初は同時刻帯をまとめて眺めるのが早い
- ログを出した処理を特定したらTransactionへ：System Logは出来事、Transactionは処理の単位
トランザクションと紐づける前提知識
ServiceNowでは、1回の処理中に複数のsyslogが出ます。処理とsyslogの対応を追いやすくするため、Transaction画面側から「Show Syslog Records」的な導線が用意されている、という説明があります。
つまり、ログ単体を追うより「処理単位に束ねる」方が、原因に近づきやすいです。
Transaction Logsで処理を1回分にまとめる
Transaction Logs（syslog_transaction）は、「誰が何をした処理が遅いのか」「どの処理でエラーが出たのか」を整理するのに向いています。
Zurichの公式ドキュメントでも、syslog_transaction（System transaction log）を参照する導線が示されています。
Transactionで何が分かるか
- 開始時刻と処理時間：遅い原因の切り分けに直結
- ユーザーと要求：誰の操作か、どの画面/APIか
- 同一処理中に出たsyslog：System Logの点を線にできる
初学者がつまずきやすいところ
- 「ログはあるのに原因が見えない」
→ System Logは断片なので、Transactionへ寄せて“その処理中に起きたこと”をまとめると見えることが多いです。 - 「同時刻にログが多すぎる」
→ 先にTransactionで1回の処理に絞ってから、その処理に紐づくsyslogを見る方が速いです。
レコードの履歴は 監査と履歴で考える
次に「誰が、何を変えたか」。ここはCSAでも前提として扱われやすい領域です。大事なのは、監査と履歴は似ているけど目的が違うこと。
Sys Auditは“変更の監査証跡”
Sys Auditや関連テーブルについて、公式に「Viewing Sys Audit…」としてまとめられています。
監査は、フィールド変更の記録として扱いやすく、「いつ・誰が・どの値をどう変えたか」を追う用途に向きます。
History setsは“フォーム上の履歴体験”
History setsについても公式に整理されています。
History setsは、ユーザーがフォーム上で履歴を見やすくするための仕組みとして理解するとスッキリします。
監査と履歴の違いを一言で
公式の「Differences Between Audit and History Sets」がまさにここを説明しています。
実務目線でざっくり言うと、こんな使い分けが便利です。
- “改ざんされていない変更の証跡”が欲しい → 監査寄り
- “フォームで見やすい履歴”が欲しい → 履歴寄り
そして試験学習では、**「どのテーブルに何が残るか」よりも、「目的に対してどちらを使う設計か」**を説明できると強いです。
よく使う周辺ログの見方
ここからは、現場でも学習でも登場頻度が高い3つに絞って、迷わない見方を作ります。
メールのログは sys_email を起点にする
メールは「送信されない」「受信で動かない」「通知が飛ばない」など、初学者が必ず一度は詰まります。
公式でも、インスタンスが作成・受信したメールはEmail [sys_email]に記録され、System Logs > Emails から見られると説明されています。
見る順番の例：
- 通知が飛ばない
→ 通知条件・イベントの前に、まず System Logs > Emails で対象メールが作られているかを見る - 作られていない
→ 条件、イベント、受信処理など“発火側”を疑う - 作られているが送れない
→ メールの状態やエラー、設定（送信元、SMTPなど）へ進む
Flowの実行履歴は Flow execution details と Flow context
Flow Designerは「テストしたときだけ詳細が出る」など、仕組みを知らないと混乱しがちです。
公式には、Flow contextはフロー実行ごとに生成され、必要に応じて実行詳細を生成できることが説明されています。
さらに、実行詳細には「Reporting level」という考え方があり、通常運用時にどこまで記録するかでパフォーマンス影響も変わる、という注意点があります。
見る順番の例：
- 「Flowが動いたか」→ Flow context（実行の事実と状態）
- 「どのステップで落ちたか」→ Flow execution details（詳細ログ）
- 「普段は詳細が見えない」→ reporting設定や保持期間の設計を疑う（運用方針の話）
Importのログは Import Log と Transform History
Import周りは「どこまで進んだか」を追えると一気に楽になります。
公式に、Import Logの場所と、インポート処理の各段階で生成される情報が説明されています。
また、プラットフォームのログ分類として「Import logs」が整理され、Transform Historyへ誘導されています。
見る順番の例：
- 「取込が失敗した」→ Import Logでエラーを掴む
- 「取込は成功したが反映されない」→ Transform Historyでマップ・変換・条件を確認
- 「一部だけ反映がズレる」→ coalesceやキー設計、データ型を疑う
学習者向け 仕組み理解に効くまとめ方
最後に、CSA学習としての“整理の仕方”を置いておきます。ログや履歴は暗記すると破綻しやすいので、次の3点でまとめるのがおすすめです。
何を確認したいかで道具を変える
- エラー文言を探す → System Log
- 1回の処理を追う → Transaction Logs
- 変更の事実を確定する → Sys Audit / History
- 機能の実行結果を追う → Email / Flow / Import など
データと設定と実行を分けて考える
- データ：レコードそのもの
- 設定：通知、Flow、Transform mapなど
- 実行：Transaction、Flow context、メール送受信、Importログ
この分け方ができると、問題文が長くても「何の話か」を切り出しやすくなります。
体系的に学ぶ教材の一例としてUdemyを使う
ログ・履歴は、断片知識よりも「原因→確認→切り分け→修正」の型を何度も回した方が身につきます。
UdemyのServiceNow講座やCSA対策講座の中には、実機操作でログや履歴を追う演習が含まれるものもあるので、手を動かしながら型を固めたい人には相性が良いです（教材は一例として、内容やレビューを見て選ぶのがおすすめです）。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
Zurichでのログ・履歴の見方は、最初に「目的別の地図」を作るだけで、一気に迷いにくくなります。
- System Logで出来事を掴み、Transaction Logsで1回の処理にまとめる
- 変更の証跡は、監査と履歴の違いを意識して追う
- メール、Flow、Importは“機能別ログ”へ枝分かれして確認する
- 暗記ではなく「見る順番テンプレ」を回して、仕組みとして理解する
この型が身につくと、実務のトラブル対応だけでなく、試験の長文問題でも「何を問われているか」を整理しやすくなります。ログと履歴は、遠回りに見えて、いちばん確実な近道です。
