Comments/Work notes（sys_journal_field）は1追記1行

2026年6月28日 15:30

Incident の Work notes に書いた文章は、どこに保存されているのでしょうか。incident テーブルの列が毎回上書きされているなら、過去の追記は残らないはずです。実際には Comments / Work notes は普通のテキスト項目ではありません。journal（ジャーナル）型という別種のフィールドで、入力1回ごとに sys_journal_field（画面ラベルは Journal Entry） へ1レコードずつ積まれます。PDI で総数1,310件の内訳まで追いました。

検証環境：Zurich PDI / OOTB / 2026-08-09 確認

追記が積み上がるのはこの欄

先に、追記が読み手から見えている場所を出しておきます。Incident のフォーム下部です。

Activities: 23 と出ています。1件ずつカードになっていて、投稿者・日時・種別が付く形です。上書きではなく積み上げだと、この画面を見るだけで分かります。

注目したいのは、同じ並びに2種類が混ざっていることです。「Incident state Closed was Resolved」は値が変わった記録。「Hi David,」で始まるものは人が書いた文章。見た目は同じカードでも、保存先のテーブルが違います。

前者は監査ログ、後者がこの記事で追う sys_journal_field です。この2つを分けて理解しておくと、「コメントだけ検索したい」「変更履歴だけ抽出したい」と言われたときに、見るテーブルを迷わずに済みます。

もう1つ、この画面から読み取れることがあります。1件のインシデントに23件も並んでいるという事実です。追記は消えないので、運用が長引いた案件ほどカードが増え続ける構造になっています。件数が積み上がる前提でテーブルを設計しているかどうかは、あとで効いてきます。

そして表示されているのは Incident 1件ぶんだけです。同じ仕組みが Change や Problem でも動いているので、テーブル全体では追記がどれくらい溜まっているのか、どの欄に偏っているのかまで見ておく価値があります。この記事では最後にその分布まで数えます。

この記事で分かること

Comments / Work notes が通常フィールドではなく journal_input 型であること
フォーム下部の Activity は journal_list 型の表示専用欄であること
追記の実体が sys_journal_field の1行＝1回の追記として溜まること
sys_journal_field が独立したルート基底テーブルで、append-only（追記専用）であること
ジャーナル（人が書いた文章）と監査ログ sys_audit（値の変更）の 役割の違い

対応記録を書くとき、どこに書けばいいのか

インシデントを対応していると、書く場所が2つあります。Additional comments と Work notes。

見た目はどちらも追記欄です。ところが片方は申請者に見え、片方は見えません。取り違えると、社内向けのメモが利用者に届きます。

さらに困るのは、書いた内容を後から消せないことです。追記型のフィールドは上書きではなく積み重ねなので、間違えた内容もそのまま残ります。

だからどちらがどちらなのかを、思い込みではなく確認しておく必要があります。

公式が1行で定義している

comments の説明はこうです。

Journaled field, shared with the end user

利用者と共有される追記型の項目。これが Additional comments です。shared with the end user と明記されているので、申請者に見えることが確定します。

同じ説明が task にも incident にも problem にも sc_task にも付いていました。プロセスをまたいで同じ定義です。どのテーブルでも comments は利用者に見えます。

裏返せば、Work notes 側にはこの記述がありません。社内向けという位置づけです。

迷ったら「comments は共有される」と覚えるのが確実です。公式が全テーブルで同じ言い方をしているため、例外を心配せずに済みます。

追記の宛先や通知の経路はメール通知が飛ぶまでの4段階（Notification）、変更そのものの記録はServiceNowの変更履歴はどこに残る？で扱いました。

追記型フィールドの位置づけ

通常のフィールドは上書きです。値を入れ直せば前の値は消えます。

追記型（ジャーナル）は違います。書くたびに1件のレコードが増える仕組みで、sys_journal_field に溜まります。

だから追記型のフィールドは、テーブルの列としては存在しません。画面には出ますが、実体は別テーブルの集まりです。レポートで集計しようとすると勝手が違うのはこのためです。

履歴を持つ仕組みは他にもあります。監査履歴（sys_audit）はどのフィールドが何から何に変わったかを記録します。アクティビティ表示（sys_history_set / sys_history_line）はそれを読みやすくまとめたものです。

追記型は「書いた内容そのもの」を持つ点が違います。変更の記録ではなく、記録そのものです。

Comments / Work notes は普通のフィールドではない

まず押さえたいのは、Comments と Work notes は通常のテキスト列ではないという点です。これらは ServiceNow の journal（ジャーナル）型フィールドです。incident の基底であるtask テーブルに定義されています。task の構造は別記事で扱っています。

実機で sys_dictionary（フィールド定義）を task テーブルで確認すると、型がはっきり分かります。

comments（Additional comments） … 型は journal_input。顧客向けの追加コメント。
work_notes（Work notes） … 型は journal_input。社内向けの作業メモ。
comments_and_work_notes（Comments and Work notes） … 型は journal_list。フォーム下部の Activity ストリームを表示する表示専用フィールドで、実データの列は持ちません。

つまり、入力欄（journal_input）に1回書くたびに sys_journal_field に1レコードが追記されます。その追記の集まりを journal_list がまとめて画面に表示する、という二段構えです。流れを図にすると次のとおりです。

sys_journal_field とはどんなテーブルか

追記の実体が積まれるのが sys_journal_field（画面ラベルは Journal Entry）です。名前から特別なテーブルに見えますが、継承元を確認するとシンプルでした。今回の PDI（Zurich / OOTB）では、sys_journal_field の super_class（継承元）は空でした。task も cmdb も継承しない、独立したルート基底テーブルです。すべてのテーブルの journal 追記を、業務テーブルとは独立して受け止める共通の器になっています。

下の画面は、PDI の sys_journal_field を element でグループ化したものです。approval_history・comments・work_notes といった「どの journal 欄への追記か」ごとに件数がまとまって並びます。

もう一つ重要なのが、sys_journal_field が append-only（追記専用） であることです。固有フィールドに sys_updated_on / sys_updated_by を持たず、一度書かれた追記は更新されず、ただ積み上がっていきます。これは監査ログ sys_audit と同じ性質で、「過去のやり取りが消えずに全部残る」理由です。

1件の追記が持つフィールドは、わずか7つです。

1追記＝1レコード：誰がいつ何を書いたか

sys_journal_field の1レコードは、「どのレコードのどの欄に、誰がいつ何を書いたか」を1行で表します。中心になるのは次の組み合わせです。

name … 追記先のテーブル（例: incident）
element … どの journal 欄か（comments か work_notes か）
element_id … 追記先レコードの sys_id（どの Incident かを指す）
value … 追記された本文（最大8000文字）
sys_created_by / sys_created_on … 誰が・いつ追記したか

下の画面は、name=incident で絞った sys_journal_field の一覧です。同じ Incident に対して work_notes や comments が1追記＝1レコードで並んでいるのが分かります。フォーム上は1つの入力欄に見えても、裏では追記のたびにレコードが増えていきます。

追記レコードを1件フォームで開くと、name・element・element_id・value がそのまま項目として確認できます。下は work_notes に「Changed the priority of the Incident」と追記された1件です。

この追記が、実際の Incident フォームではどう見えるかも確認しておきます。下は OOTB のデモ Incident（INC0000060「Unable to connect to email」）のフォームです。Activity に Comments / Work notes のやり取りが時系列で並びます。この1件1件が sys_journal_field の1レコードです。Incident テーブルの構造は別記事で扱っています。状態（State）の設計も別記事で扱っています。

実機の件数：どのテーブルに、どんな追記が溜まっているか

PDI（Zurich / OOTB）の sys_journal_field には、1,310件の追記がありました。これを element 別・テーブル（name）別に集計すると、OOTB の使われ方がはっきりします。

element 別では、approval_history が1,223件と最多で、人が手で書く comments が57件、work_notes が30件でした。approval_history は承認まわりの journal。OOTB のデモデータでは大半を占めます。承認履歴もコメントも作業メモも、同じ sys_journal_field に同じ形で集約されます。欄が違っても行き先は1つのテーブルです。

テーブル（name）別に見ると、追記先は change_request が1,136件で圧倒的です。次いで task（基底）が150件、incident が18件でした。下の画面は name でグループ化した実機の一覧です。

incident の18件は内訳が comments 9件・work_notes 9件で、OOTB のデモ Incident に残されたやり取りです。追記の量は業務の進め方によって変わるため、本番環境ではこの分布は大きく異なります。

ジャーナルと監査ログ（sys_audit）の違い

Activity に並ぶものには、もう1系統あります。フィールドの値が変わった記録です。「Incident state Resolved → Closed」のような変更は、sys_journal_field には記録されません。かわりに監査ログ sys_auditに記録されます。両者は同じ Activity に並ぶため混同されがちですが、記録するものがまったく違います。

sys_journal_field（ジャーナル） … ユーザーが Comments / Work notes に書いた文章を、value にそのまま記録します。
sys_audit（監査ログ） … 業務レコードの「どの項目が、何から何に変わったか」を、fieldname・oldvalue・newvalue で記録します。監査が有効なテーブルの更新時に自動で書かれます。

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

ざっくり言えば、ジャーナルは「人が書いた文章」、sys_audit は「値がどう変わったか」です。Activity 表示そのものは、この2系統に履歴セットを加えて組み立てられます。履歴セットの実体は sys_history_set / sys_history_line です。その全体像と監査側の詳細は「監査と履歴を実機で読み解く」で扱っています。合わせて読むと「追記（ジャーナル）／変更（監査）／表示（履歴セット）」の3層がつながって見えてきます。

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

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

# 追記を欄（element）でグループ化
https://<YourInstance>/sys_journal_field_list.do?sysparm_query=GROUPBYelement

# 追記先テーブル（name）でグループ化
https://<YourInstance>/sys_journal_field_list.do?sysparm_query=GROUPBYname

# 特定テーブルの追記だけ絞る（例: incident）
https://<YourInstance>/sys_journal_field_list.do?sysparm_query=name=incident^ORDERBYDESCsys_created_on

# Comments / Work notes のフィールド定義（journal型）を確認
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=task^elementINcomments,work_notes,comments_and_work_notes

追記が集まる場所を横で見る

sys_journal_field は1つのテーブルなので、全プロセスの追記がここに集まります。

インシデントのコメントも、変更申請の作業メモも、承認履歴も同じ場所です。だから「この期間に誰が何を書いたか」を横断して調べられます。

逆に言えば、このテーブルだけ肥大しやすいということでもあります。ログ系テーブルの溜まり方はシステムログ（syslog）の読み方と溜まり方で扱いました。追記型も同じ性格を持ちます。

表示の速さに効く

アクティビティ表示は追記を読み直して組み立てます。件数が増えるほど重くなる構造です。

そこで別テーブルにまとめ直す仕組みがあります。履歴セット（sys_history_set）はActivity表示のキャッシュで扱ったとおり、読みやすさのために別に持っているわけです。

追記そのものと、その表示用のまとめ。2つあることを知っていると、片方だけ見て判断せずに済みます。

追記欄を運用に載せるとき決めること

何を comments に書くか

利用者に見える欄なので、書いた内容がそのまま連絡になります。「調査中」とだけ書くのか、見込みまで書くのか。粒度を決めておかないと担当者ごとにばらつきます。

社内向けの検討は work notes 側に書く。この線引きを手順書に入れておくと、事故が減ります。

消せない前提で運用する

追記型は上書きではないので、間違えた内容も残ります。訂正は「訂正の追記」で行うことになります。

個人情報や機微な内容を書いてしまうと厄介です。書く前に確認するしかありません。

件数が増える前提で設計する

1件のタスクに何度も追記すると、そのぶんレコードが増えます。承認履歴まで含めると、実測では approval_history が最多でした。

タスク本体の件数より、追記の件数のほうが早く増えるということです。データ量の見積もりでは、こちらを見ておく必要があります。データが溜まる場所の全体像はServiceNowのデータはどこに溜まっていつ消える？にまとめました。

用語

ジャーナル型フィールド：上書きではなく追記されるフィールド。入力1回ごとに1レコードが増える。

sys_journal_field：追記の実体が入るテーブル。どのテーブルのどのレコードに対する追記かを持つ。

Additional comments（comments）：利用者と共有される追記欄。公式説明に「shared with the end user」とある。

Work notes：社内向けの追記欄。利用者には見えない。

activity_due：Inactivity Monitor が更新を期待する期日。一定期間の無更新を検知する仕組みで使う。

検証範囲とおことわり

件数はこの環境の実測値です。フィールドの公式説明は、製品が持つフィールドドキュメント（sys_documentation）から 2026-08-11 に引用しました。

確認していないこともあります。ポータル側で実際に Additional comments がどう見えるかは見ていません。Inactivity Monitor を動かして検知されるところまでも確認していません。テーブル構造と公式説明までが今回の範囲です。

まとめ

Comments / Work notes は通常フィールドではなく journal_input 型。フォーム下部の Activity は journal_list 型の表示専用欄。
追記の実体は sys_journal_field（Journal Entry）の1行＝1回の追記として溜まる。PDI では総数1,310件。
sys_journal_field は独立したルート基底テーブルで、append-only（追記専用）。過去の追記は消えずに残る。
1レコードは name / element / element_id / value / sys_created_by / sys_created_on の組み合わせで構成される。
これらの列で「どのレコードのどの欄に、誰がいつ何を書いたか」を表す。
PDI 実機では element 別に approval_history 1,223 / comments 57 / work_notes 30。
テーブル別には change_request 1,136 / task 150 / incident 18。
ジャーナルは「人が書いた文章」、sys_audit は「値がどう変わったか」。役割が違う。

ジャーナルフィールドの仕組みが分かると、次のつながりも見えてきます。

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — sys_journal_fieldも追記が消えずに積み上がるテーブルの1つ。添付・履歴・ログを含めたデータ全体がどこに溜まりいつ消えるのかを横断的に確認できます
監査と履歴（sys_audit）
task テーブルの継承

「人が書く → 追記が残る → 履歴に並ぶ」という流れです。