システムログ（syslog）の読み方と溜まり方

2026年6月27日 08:56

ServiceNow を触っていて「Flow が動かない」「通知が飛ばない」「スクリプトが期待どおりに動かない」というとき、最後に頼るのがサーバ側の システムログ です。アプリナビゲーターで「System Logs」を開くと、プラットフォームが裏側で出力した大量のログが時系列で並びます。この中心になっているテーブルが syslog（画面ラベルは Log Entry） です。

この記事は、ServiceNow の画面操作には慣れたが、ログがどのテーブルに、どんな形で溜まっているのかはこれから確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で syslog を実際に開き、1行＝1回のログ出力であることを確認します。深刻度を表す level、出力元を表す source、本文の message、そして gs.log() などのスクリプトが syslog をどう書くのかも見ていきます。最後に監査ログ sys_audit との役割分担も確認します。

この記事で分かること

システムログが syslog（Log Entry）の1行＝1回のログ出力として溜まること
syslog が独立したルート基底テーブルで、append-only（追記専用）であること
深刻度 level（Information / Warning / Error など6種）と、PDI 実機の約79万件の内訳
出力元 source（Evaluator・DataCollector・*** Script など）の見方
gs.log() / gs.warn() / gs.error() が level に対応して syslog を書くこと
システムログ（処理の動作）と監査ログ（データ変更履歴）の役割の違い

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ログの件数・source・level の分布が異なります。

システムログ（syslog）とは

システムログとは、ServiceNow のサーバ側で起きた処理の動作を、1件＝1レコードで記録したものです。スケジュールジョブの実行、スクリプトのエラー、プラットフォームの内部処理などが、その都度 syslog に1行ずつ書き込まれます。アプリナビで「System Logs > All」を開くと見えるのが、この syslog です。

下の画面は、PDI（Zurich / OOTB）の syslog を level でグループ化したものです。Information・Warning・Error といった深刻度ごとに件数がまとまり、それぞれの中に出力元（source）と本文（message）が並びます。

PDI（Zurich / OOTB）の syslog には、すでに 約79万件（取得時点で794,574件）のログが溜まっていました。ログは止まらず書き込まれ続けるため、この数は刻一刻と増えていきます（このあとの集計値や画面の合計が数十件ずれるのは、計測の合間にもログが増え続けているためです）。

syslog はどんなテーブルか

名前から特別なテーブルに見えますが、継承元を確認するとシンプルでした。今回の PDI（Zurich / OOTB）では、syslog の super_class（継承元）は空で、task も cmdb も継承しない 独立したルート基底テーブルです。サーバ側のログ出力を専門に受け止める器として、業務テーブルとは独立して用意されています。

もう一つ重要なのが、syslog が append-only（追記専用）であることです。固有フィールドに sys_updated_on / sys_updated_by を持たず、一度書かれたログは更新されず、ただ積み上がっていきます。これは後述の監査ログ sys_audit と同じ性質で、「いつ何が起きたか」の証跡になる理由です。

1行のログが持つ主なフィールドは次のとおりです。

中心になるのは level（深刻度）・source（出力元）・message（本文）の3つです。フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=syslog^elementISNOTEMPTY

level：ログの深刻度

level は、そのログがどれくらい重要かを表す深刻度です。PDI では選択肢が6種類ありました。

実機で level の選択肢を開くと、内部値（value）と表示名（label）の対応が確認できます。

PDI 実機で level 別に件数を数えると、分布がはっきりしました。

Information が456,065件、Warning が334,141件、Error が4,380件で、この3つでほぼ全体を占めます。Debug / Trace / Fatal は選択肢としては用意されていますが、今回の PDI の現データには0件でした。エラーは全体の約0.5%しかなく、ログの大半は「正常に動いた」「ちょっと気になる」レベルの記録だと分かります。だから障害調査では、まず level=Error で絞り込むのが定石になります。

https://<YourInstance>/syslog_list.do?sysparm_query=level=2

source：誰がそのログを書いたか

source は、そのログを出力したのが誰（どの処理）かを表す名前です。PDI で syslog を source 別に集計すると、出力元は 394種類ありました。上位3件は次のとおりです。

Evaluator（スクリプト評価器）… 333,902件
DataCollector（Performance Analytics の収集）… 246,238件
TableCleaner … 102,175件

つまり syslog の大半は、プラットフォームやスケジュールジョブが自動で書いているログです。裏側のジョブは定期実行（Scheduled Jobs）も参考になります。

4番目に多いのは * Script（29,915件）です。これは背景スクリプトや Business Rule・Script Include の中で gs.log(message) を呼ぶとき、source を省略するとこの出力元になります**。詳しくは次を参考にしてください。

下の画面は、その *** Script のログだけを絞ったもので、自分で書いたデバッグログはたいていここに集まります。

gs.log() がシステムログを書く

開発中に「ここまで処理が来ているか」を確認したいとき、サーバサイドスクリプトに gs.log("ここまで来た") と書くと、その文字列が syslog に1行追加されます。呼び出す API によって、書き込まれる level が変わります。

gs.info() / gs.log() → Information（0）
gs.warn() → Warning（1）
gs.error() → Error（2）
gs.debug() → Debug（-1）（詳細ログを有効にしたときに残る）

下の画面は、実際に書き込まれた1件のログをフォームで開いたものです。Level=Information、Source=* Script、Message にスクリプトが出力した本文**が入っているのが分かります。

このように、スクリプトが出力した1回のログ＝syslog の1行です。開発時のデバッグ出力も、プラットフォームの自動ログも、同じ syslog テーブルに同じ形で積まれていきます。

システムログと監査ログ（sys_audit）の違い

ServiceNow には、似て非なる「ログ」がもう一つあります。監査ログ sys_audit です。両者は混同されがちですが、記録する対象がまったく違います。

syslog（システムログ） … サーバの処理やスクリプトが「何をした・何が起きた」を、自由文の message で記録します。gs.log() などが書きます。
sys_audit（監査ログ） … 業務レコードの「どの項目が、何から何に変わったか」を、fieldname・oldvalue・newvalue で記録します。監査が有効なテーブルの更新時に自動で書かれます。

整理すると次のようになります。

ざっくり言えば、syslog は「処理がどう動いたか」、sys_audit は「データがどう変わったか」 です。障害でスクリプトの挙動を追うなら syslog、誰がいつデータを変えたかを追うなら sys_audit、と使い分けます。なお、どちらも append-only（追記専用）です。

なお syslog には、用途別の子テーブルもあります。

syslog_email（Email Log Entry）… メール専用
syslog_app_scope（App Log Entry）… スコープアプリ用
syslog_transaction（Transaction Log Entry）… 約4.8万件（別系統）

これらの詳細は今回の検証範囲外ですが、ログが用途ごとに分かれていることだけ押さえておくと迷いません。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# ログを深刻度でグループ化
https://<YourInstance>/syslog_list.do?sysparm_query=GROUPBYlevel

# エラーログだけ絞る
https://<YourInstance>/syslog_list.do?sysparm_query=level=2

# 出力元でグループ化
https://<YourInstance>/syslog_list.do?sysparm_query=GROUPBYsource

# syslog のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=syslog^elementISNOTEMPTY

まとめ

システムログは syslog（Log Entry）の1行＝1回のログ出力として溜まる。PDI では約79万件。
syslog は 独立したルート基底テーブルで、append-only（追記専用）。中心は level / source / message。
level は深刻度で、PDI では Information 456,065 / Warning 334,141 / Error 4,380。障害調査はまず level=Error で絞る。
source は出力元で、大半はプラットフォームやジョブが自動で書く。自前の gs.log() は既定で * Script** に出る。
gs.info / gs.warn / gs.error が level に対応して syslog を書く。
syslog は「処理がどう動いたか」、sys_audit は「データがどう変わったか」。役割が違う。

システムログが分かると、関連する記事が「処理が動く → ログが残る → 履歴が残る」という流れでつながって見えてきます。

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — syslogもデータの一種。添付・履歴・アーカイブまで含めた、データがどこに溜まりいつ消えるかを確認できる。
監査と履歴（sys_audit）
Business Rule