ServiceNowの通知メールで「改行が消える」「ボタンだけ崩れる」「レイアウト全体がずれる」「プレビューではよく見えるのに受信メールで崩れる」といった症状は、単純なHTMLミスだけでなく、通知設定、テンプレート適用、メールスクリプト、リッチHTML変換、そして受信側メールクライアントの制約が重なって起きることが多いです。ServiceNowでは通知のContent type、テンプレート、レイアウト、mail script、生成されたsys_emailを順番に見ていくと、かなりの確率で原因を絞れます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まず確認すべきチェックリスト
HTML崩れの調査は、最初から細かいHTMLを読むより、設定の大きなズレを先に潰したほうが早いです。特に「Notificationの設定」「TemplateやLayoutの適用」「mail scriptの出力」「生成後のsys_email」「受信側メーラー差分」の5点を最初に確認してください。
通知レコードのContent typeを確認する
最初に確認する場所は、System Notification > Email > Notifications の通知レコードです。ここで見るべき代表フィールドは Content type です。ServiceNowの通知は HTML and plain text、HTML only、Plain text only を選べます。HTML崩れを疑っているのに Plain text only になっている、あるいはテキスト側とHTML側の期待が混ざっていると、受信結果の見え方が大きく変わります。通知作成時の公式手順でもこのフィールドは明示されています。
よくある誤解は、「通知本文にHTMLタグを書いてあるから自動でHTMLメールになるはず」という考え方です。実際は通知の Content type 側の設計が前提です。HTMLタグを書いていても、周辺設定や出力経路が噛み合っていなければ、期待どおりの表示にはなりません。
生成されたsys_emailを確認する
次に必ず確認したいのが、System Logs > Emails にある Email [sys_email] レコードです。ServiceNowは生成・受信した通知メールをsys_emailに記録します。つまり「通知定義がどう書かれているか」ではなく、「実際に生成されたメールがどうなっているか」をここで見ます。
ここで確認したい状態例は、「期待した通知が生成されているか」「件名は合っているか」「本文プレビューで既に崩れているか」です。sys_emailの時点で崩れていれば、原因はServiceNow側の通知構成にあります。逆にsys_emailでは正常なのに受信メールだけ崩れるなら、メールクライアント側のHTML/CSS制約を疑うべきです。
テンプレートやレイアウトが適用されていないか確認する
通知HTMLは、通知本文だけで完結していないことがあります。ServiceNowにはEmail TemplateとEmail Layoutがあり、レイアウトは Email Layout [sys_email_layout] テーブルで管理されます。レイアウト側にヘッダーやフッター、共通スタイル、ロゴ、背景などを持たせていると、通知本文では正常でも最終メールで崩れることがあります。
特に見落としやすいのが、「通知本文を直したのに崩れが直らない」ケースです。実際にはレイアウト側のHTMLが閉じていない、古いテンプレートが適用されている、レイアウトに想定外の装飾がある、ということが起きます。通知本文だけを見て終わらないことが重要です。
mail scriptの出力を確認する
通知本文内で ${mail_script:...} を使っている場合は、System Notifications > Email > Notification Email Script のスクリプトも確認対象です。ServiceNow公式でもmail scriptは通知本文に差し込んで使う前提で説明されています。mail scriptがHTMLを途中で壊したり、改行処理を誤ったりすると、通知全体が崩れます。
見るべきポイントは、template.print() で何を出しているか、HTMLタグの開閉が揃っているか、複数行テキストをそのまま出していないか、Newlines to HTML の扱いがどうなっているかです。Rich HTMLでは改行制御に関する仕様があり、既存スクリプトの移行時にはこの差が崩れの原因になりやすいです。
受信側メールクライアント差分を疑う
ServiceNow側に問題がなくても、メールクライアントはWeb画面のように自由なCSSを解釈してくれません。ServiceNow公式でも、メール本文には関連づいたスタイルシートがなく、エディタはインラインスタイルを付与する前提と説明されています。つまり、外部CSSや通常のWebページ前提の書き方は崩れやすいです。
よくある誤解は、「ブラウザで見たHTMLがそのままメールでも再現される」という前提です。メールは別物です。div ベースの複雑なレイアウト、外部CSS、クラス依存の装飾、凝ったレスポンシブ制御は、受信側で大きく変形されることがあります。
原因の全体構造整理
通知HTMLが崩れる原因は、実務ではだいたい次の6層に分けると整理しやすくなります。ひとつずつ下流へ追うと、切り分けの漏れが減ります。
設定層
通知レコードの Content type、本文エディタ形式、テンプレート適用有無など、通知定義そのもののズレです。ここが崩れていると、以降をいくら見ても治りません。
共通部品層
Email TemplateやEmail Layoutの影響です。共通ヘッダー、共通フッター、ロゴ、共通スタイルがレイアウト側にあると、通知本文だけ見ても全体像は分かりません。
スクリプト層
mail scriptのHTML出力や改行制御です。文字列結合の途中でタグが欠ける、想定外の値が入る、旧来の改行前提が残る、といった不具合がここで起きます。
データ層
通知に差し込んでいるレコード値そのものがHTMLと相性悪いケースです。たとえば複数行テキスト、説明欄、コメント、ワークノート由来の文字列に < > & などが含まれていると、表示が崩れたように見えることがあります。ServiceNowはメールオブジェクトで email.body_html と email.body_text を区別しています。HTML扱いとテキスト扱いを混同しないことが重要です。
生成結果層
sys_emailに生成された時点で崩れているかどうかです。ここは「ServiceNowが最終的に何を作ったか」を見る場所なので、切り分けの中心になります。
受信表示層
OutlookやGmailなど受信側の描画差分です。sys_emailで正常でも受信後だけ崩れるなら、この層の問題です。ServiceNow公式がインラインスタイル前提としているのも、この層で崩れにくくするためです。
原因層ごとの詳細解説
ここからは、実際に崩れを起こしやすい原因を層ごとに細かく見ていきます。HTMLだけを読むのではなく、どのテーブル・どのフィールド・どの状態を見るかを意識すると、現場での復旧が速くなります。
通知レコードの形式が崩れの起点になっている
確認箇所は sysevent_email_action の通知レコードです。見るべき代表項目は Content type と、通知本文がどの形式で管理されているかです。最近の系統では新規通知はRich HTMLが既定で、旧来通知をRich HTMLへ変換する導線も公式に用意されています。古い通知と新しい通知で本文の扱いが違うと、同じように見えても改行やタグ処理がずれることがあります。
状態例としては、「古い通知を流用したら改行だけおかしい」「message_html側を編集したつもりが旧形式の想定でmail scriptを書いていた」などです。よくある誤解は、通知の見た目が同じなら内部形式も同じだと思うことです。実際は、legacy由来かRich HTML由来かで挙動差が残ることがあります。
Email LayoutやTemplateがHTML構造を壊している
確認箇所は Email Layout [sys_email_layout] と、適用中のEmail Templateです。レイアウトは共通ヘッダー・本文枠・フッターを持てるため、通知本文側で <table> を閉じたつもりでも、レイアウト側のタグ構造と干渉すると全体が崩れます。ServiceNow公式でも、レイアウトはインラインHTMLエディタまたは手入力HTMLで作成し、通知全体の一貫した見た目を持たせるための仕組みとされています。
状態例は、「一部通知だけ同じヘッダーで崩れる」「本文単体は正しいのに最終メールの上下余白や背景色が乱れる」「ロゴを入れた瞬間に横幅が崩れる」です。よくある誤解は、通知本文さえ正しければメール全体も正しいはずという考えです。共通レイアウトがある環境では、その前提は通用しません。
CSSの置き方がメール向きでない
確認箇所は通知本文やテンプレートに書いた装飾方法です。ServiceNow公式では、メール本文には関連づいたスタイルシートがなく、エディタの装飾はインラインスタイルを付ける前提です。つまり、Webアプリの感覚でクラス指定や外部CSS依存で作ると、受信側で崩れやすくなります。
状態例としては、「プレビューでは色が付くのに受信メールで消える」「ボタンの余白だけなくなる」「見出しだけフォントが変わる」が典型です。見るべき具体項目は、style="" が要素に直接入っているか、クラス名頼みになっていないか、<style> や外部参照を前提にしていないかです。よくある誤解は、Service PortalやCMSのCSSを流用できるという認識です。メール通知はそこにぶら下がっていません。
mail scriptの改行処理とHTML出力が噛み合っていない
確認箇所は Notification Email Script の Newlines to HTML と template.print() の中身です。ServiceNow公式では、Rich HTMLでは改行制御のために Newlines to HTML が用意されており、新規mail scriptでは template.print() に正しいHTML改行を明示的に入れることが案内されています。
状態例は、「テキストは出るが全部一行になる」「二重改行になる」「箇条書きのはずが詰まる」「途中からHTMLが無効化されたように見える」です。よくある誤解は、複数行文字列をそのまま template.print() すれば見た目も維持されるというものです。メールではテキスト改行とHTML改行は別扱いなので、旧来のまま持ち込むと崩れます。
差し込むデータがHTMLとして安全でない
確認箇所は通知対象レコードの説明欄、コメント、カタログ変数、複数行テキストです。通知そのものが正しくても、差し込んだ値に記号や改行が多いと表示が乱れます。特に自由入力欄をそのままHTMLの中に埋め込むと、意図しない位置でレイアウトが壊れたように見えます。ServiceNowが email.body_html と email.body_text を分けているのは、HTML文字列とテキスト文字列を同一視しないためです。
状態例は、「特定ユーザーの申請だけ崩れる」「説明欄が長い案件だけ横幅が広がる」「コメント欄に記号がある案件だけ表示が不自然になる」です。よくある誤解は、HTML崩れは常にテンプレート側の責任だと思うことです。実際には、崩れを引き起こす入力値がレコード側に潜んでいることも珍しくありません。
sys_emailでは正常かどうかを見ずに受信結果だけで判断している
確認箇所は sys_email の生成結果です。ServiceNow公式でも、通知メールの調査にはログと診断機能を使うことが案内されています。sys_emailを見ずに受信トレイだけを追うと、ServiceNow側の生成不良なのか、メーラー側の描画差なのかが混ざってしまいます。
状態例としては、「Outlookでだけ崩れる」「転送するとさらに崩れる」「モバイルでのみボタンが縦に潰れる」です。この場合、sys_emailプレビューが正常ならServiceNow側のHTML生成は通っている可能性が高いです。よくある誤解は、受信側で崩れたら通知設定が悪いに違いない、という短絡です。そこは分けて考えるべきです。
実務での最短切り分けフロー
ここでは、現場で最も早く原因に当たりやすい順番を示します。上から順に進めれば、無駄にHTMLを全文読み込まなくて済みます。
まずsys_emailで崩れが再現しているかを見る
最初にSystem Logs > Emailsで対象の sys_email を開き、本文プレビューを確認します。ここで既に崩れていれば、ServiceNow側の通知設計が原因です。ここで正常なら、受信側メーラー差分の可能性が高いです。
次に通知レコードのContent typeと本文形式を見る
通知レコードで Content type を確認し、HTML通知として作っている前提が崩れていないかを見ます。さらに、Rich HTML移行済みか、古い通知の流用かもチェックします。ここで想定と違えば、以降の修正は空振りになりやすいです。
その後にTemplateとLayoutを外して比較する
可能であれば、一時的に共通レイアウトや複雑なテンプレート依存を減らした最小構成で再送します。これで直るなら、本文ではなく共通部品が原因です。HTML崩れ調査では、この比較が非常に効きます。
mail scriptを単純化して再現確認する
${mail_script:...} を使っているなら、固定文字列だけにした版を作って比較します。そこで崩れが消えるなら、script出力が原因です。特に template.print() の改行、タグ開閉、複数行データの扱いを重点的に見ます。
最後に受信側メーラー差分を確認する
sys_emailが正常で、通知・テンプレート・mail scriptも問題なければ、OutlookやGmailなど複数クライアントで見比べます。この段階で初めて「メール向けHTMLとして単純化する」方向の修正を行います。最初からここに飛ばないことが大切です。
設計観点からの再発防止
HTML崩れは、その場しのぎの修正をすると再発しやすいです。通知は運用が長く続くため、最初から壊れにくい設計に寄せたほうが結果的に工数を減らせます。
メールはWebページではなくメールとして設計する
再発防止の基本は、通知メールをWebページの縮小版として作らないことです。インラインスタイル中心、複雑なCSS依存を避ける、横幅固定気味にする、構造を単純にする、という方向が安全です。ServiceNow公式がメール本文にスタイルシートが関連付かないと説明している以上、メール向け設計に割り切るべきです。
共通レイアウトと通知本文の責務を分ける
ヘッダー、フッター、共通ブランド要素はLayoutへ、案件固有メッセージは通知本文へ、と責務を分けると崩れ箇所が追いやすくなります。何でも本文に詰め込む、または何でもレイアウトに寄せると、修正範囲が不透明になります。
mail scriptはHTML生成装置として厳格に扱う
mail scriptで文字列を雑に連結すると、運用中に小さな仕様変更で簡単に崩れます。改行はHTMLとして出す、タグの開始と終了を明確にする、自由入力値の扱いを慎重にする、という基本を徹底したほうが安全です。Rich HTML環境では旧来の改行感覚を持ち込まないことが重要です。
調査起点を必ずsys_emailに寄せる
運用設計として、「通知の不具合はまずsys_emailを見る」をチーム内で共通化すると、切り分け速度が一気に上がります。ServiceNow公式もメールログや診断ダッシュボードを調査資源として案内しています。受信トレイの見た目だけで判断しない運用が再発防止につながります。
CSA学習者が押さえたい理解ポイント
CSA学習の観点では、「通知は本文だけで完結しない」という理解が重要です。通知レコード、テンプレート、レイアウト、mail script、生成ログ、診断、そして受信側表示までが一連の仕組みです。この構造を押さえると、単なる設定暗記ではなく、なぜ崩れるのかを説明できるようになります。
まとめ
ServiceNowの通知HTML崩れは、HTML文法だけの問題ではありません。まず Content type を見て、次にテンプレートとレイアウト、mail script、差し込むデータ、そして sys_email の生成結果を追うのが最短です。特に、sys_emailで既に崩れているかどうかを起点にすると、ServiceNow側か受信側かを切り分けやすくなります。メールはWebページの延長ではなく、制約の強い配信媒体として設計するのが再発防止の近道です。
次に読むと理解がつながりやすい記事
通知HTML崩れを直したあとに理解を深めるなら、次は「通知が送られない」「sys_emailが作られない」「Eventが発火しない」「送信先が意図どおりにならない」といったテーマを続けて押さえると、通知全体の仕組みがかなり整理できます。あわせて、Notification、Email Template、Email Layout、mail scriptの役割差を整理した基礎記事も読んでおくと、実務でもCSA学習でも強くなります。
また、ServiceNowを体系的に学ぶ方法の一例として、Udemyの講座で通知・イベント・メール関連の流れをまとめて確認するやり方もあります。実機操作を見ながら全体像をつかみたいときには、独学の補助として使いやすい選択肢です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
