データ管理を極める ServiceNow：増加状況の追跡から効率的なクリーンアップまで このナレッジベース記事では、データベースの増加状況の監視から大規模テーブルの最適化まで、ServiceNow におけるデータ管理の包括的なガイドを提供します。セルフマネージドによるデータクリーンアップのベストプラクティスを確認し、利用可能なツールや機能について学び、最大規模のテーブルへ効果的に対処する方法についての知見を得てください。より円滑な運用を実現するために、データ管理に関する十分な情報に基づいた意思決定を行うための知識を、ご自身とチームに身に付けてください。 注：大規模なデータセットの削除には、処理に数週間から数か月かかる場合があります。この期間を設けることで、運用への影響を最小限に抑えながら、徹底的かつ体系的な削除を実現します。 注：この KB 記事内でリンクされている詳細ドキュメントを表示するには、NowSupport Portal にログインしてください。 Table of Contents セルフマネージドによるデータクリーンアップおよび削除のベストプラクティス Best Practices for Data Removal テーブルの増加と全体的なデータベースフットプリントの追跡利用可能なデータ管理製品および機能 Database Compaction – テーブルの空き領域の再利用 Database Compaction とは何ですか？Database Compaction が重要である理由 レコードを削除してもデータベースがすぐに縮小しない理由Data Management ConsoleDelete JobsTable CleanerData ArchivingCMDB Data ManagerClonesScripted Methods 最大規模テーブルを管理するための戦略 sys_attachment/sys_attachment_docsys_auditsys_audit_deletesys_emailar_* テーブルおよび sys_archive_logsyslog*cmdb*sh* および sys_rollback* テーブルpa_scores* および pa_snapshots テーブル セルフマネージドによるデータクリーンアップおよび削除のベストプラクティス クリーンで整理された ServiceNow 環境を維持することは、システムパフォーマンスを最適化し、データの正確性を確保するうえで不可欠です。データを効果的に管理できるようにするため、セルフマネージドによるデータクリーンアップおよび削除に関するベストプラクティスをまとめました。 ほとんどの場合、ServiceNow Customer Support はお客様のインスタンスからのデータ削除を支援しません。その理由と、お客様が実施できる内容は以下のとおりです。 整合性と説明責任：データ削除へ直接介入することは、お客様固有の構成やデータの整合性にリスクをもたらす可能性があります。当社はお客様のデータの安全性と一貫性を最優先します。OOTB 機能：ServiceNow はデータクリーンアップを支援する OOTB 機能を提供しています。ただし、大規模なデータセットは処理に数週間から数か月かかる場合があります。この期間を設けることで、運用への影響を最小限に抑えながら、徹底的かつ体系的な削除を実現します。セルフサービスツール：ユーザーが効率的かつ安全にデータを管理およびクリーンアップできるよう、ツールとドキュメントを提供しています。推奨事項：大規模なデータクリーンアップを実施する前に ・テスト：本番環境で実行する前に、同等規模のデータセットを使用したサブ本番環境でクリーンアッププロセスをテストしてください。・相談：データ管理の経験を持つ ServiceNow コンサルタントまたはパートナーへ相談することを検討してください。・完了時間：データ削除プロセスには相当な時間がかかる場合があることを考慮し、適切に計画してください。大規模なデータセットは処理に数週間から数か月かかる場合があります。 データ管理が重要である理由と、プラットフォーム内で利用可能な選択肢の概要については、以下の YouTube 動画をご利用いただけます。 Platform Fundamentals Academy - March 20th, 2025 - Effective Data Management Best Practices for Data Removal 以下のナレッジ記事では、お客様の環境を効率的かつ安全に維持し、組織のデータポリシーへの準拠を確保するためのガイドラインについて説明しています。 Best Practices for Data Removal テーブルの増加と全体的なデータベースフットプリントの追跡 最適なパフォーマンスを維持し、ServiceNow 環境を効率的に運用するためには、テーブルの増加状況およびデータベース全体のフットプリントを監視することが不可欠です。これらの指標を理解し追跡することで、システムのパフォーマンスやスケーラビリティへ影響を与える前に潜在的な問題を特定できます。 ServiceNow インスタンス内におけるテーブル増加状況およびデータベースフットプリントを追跡する際の重要な考慮事項については、以下のナレッジ記事を参照してください。 Tracking Table Growth and Overall Database Footprint 利用可能なデータ管理製品および機能 データ管理の複雑さに対応する上で、利用可能な選択肢を把握することは非常に重要です。以下は、セルフサービスでデータを効果的に管理およびクリーンアップするために利用できる機能と製品です。 Database Compaction – テーブルの空き領域の再利用 ServiceNow 環境を最高の状態で運用し続けるためには、データベースの健全性を維持することが重要です。時間の経過とともに、データの追加、更新、削除が行われることで、データベースには未使用領域が蓄積される可能性があります。これは非効率性を引き起こし、システムパフォーマンスへ影響を与える可能性があります。Database Compaction は、未使用領域を回収し、システム全体のパフォーマンスを向上させ、効率的なストレージ管理を実現することで、インスタンスを最適化する重要なプロセスです。 Database Compaction とは何ですか？ Database Compaction とは、未使用領域や断片化した領域を除去するためにデータベースを再編成するプロセスです。これにより、データベース全体のサイズを削減し、システム速度を向上させ、環境を効率的かつ応答性の高い状態に維持できます。 Database Compaction が重要である理由 パフォーマンスの向上：データが蓄積されると断片化が発生し、クエリや処理が遅くなる可能性があります。Compaction はデータベース処理の速度と効率を向上させます。 ストレージの最適化：未使用領域を回収することで、データベース全体のサイズを削減し、貴重なストレージリソースを解放するとともに、システムのストレージ容量をより効率的に活用できます。 システムの健全性：定期的な Database Compaction は、過度な断片化に起因するパフォーマンス問題を防ぎ、インスタンスの円滑な運用を支援します。 Database Compaction の詳細については、以下のナレッジ記事を参照してください。 Database Compaction – Reclaiming Table Free Space レコードを削除してもデータベースがすぐに縮小しない理由 レコードを削除した後（Table Cleaner、アーカイブ／削除ルール、または手動削除のいずれの場合も）、インスタンスで報告されるサイズがすぐには減少しない、または想定よりも減少量が少ないことに気付く場合があります。これは想定どおりの動作であり、クリーンアップが機能していないことを示すものではありません。 レコードが削除されると、データベースはその領域を再利用可能としてマークしますが、直ちにその領域を回収したり、ディスク上のテーブルサイズを縮小したりするわけではありません。時間の経過とともに、レコードの削除と挿入が繰り返されると断片化が発生する可能性があります。これは、回収可能な領域が存在するにもかかわらず、テーブルサイズの縮小としてまだ反映されていない状態です。Database Compaction（前述のセクションを参照）は、この領域を回収するための仕組みです。この処理は、削除のたびに即時実行されるのではなく、スケジュールに従って実行されます。 特定のテーブルに対して手動のアドホック クリーンアップを推奨しない理由 いくつかの大量データを保持するシステムテーブルは、すでに Database Rotation（Table Rotation および Table Extension）によって自動管理されており、管理者による操作なしで継続的に増加へ対応しています。これらのテーブルに対して、この仕組み以外で手動削除を実行すると、不要な作業となるリスクがあるだけでなく、自動ローテーションと競合し、場合によっては改善するどころか断片化を悪化させる可能性があります。これらのテーブルのいずれかが想定以上の速度で増加している場合は、レコードを直接削除するのではなく、ローテーション設定を確認する必要があります。 Data Management Console プラットフォームの Yokohama リリースでは、Data Management Console を導入しました。これは、インスタンス内のデータ使用状況の要約を提供し、データ増加を管理することを目的として設計されています。Zurich リリースでは、Console の機能が強化され、より詳細な情報に加えて、増加傾向、データ内訳、およびデータクリーンアップの進捗状況に関するインサイトが提供されるようになりました。 Zurich リリース以降、Data Management Console はインスタンス内のデータサイズおよびテーブル内訳に関する「唯一の信頼できる情報源（Source of Truth）」となります。 Console の Overview タブでは、以下を確認できます。 ・インスタンス全体のサイズ ・インスタンス内で最大規模のテーブル ・それらの大規模テーブルに関連するレコードサイズ（sys_attachment、sys_attachment_doc、sys_audit、sys_journal_field などの関連テーブルデータを含む） ・最大規模テーブルの増加状況を時系列で示すグラフ表示 ・過去 30 日間で最も増加したテーブル Data Management Console の Overview タブ、Tables タブ、およびドリルダウンビューの詳細な説明については、以下のナレッジ記事を参照してください。 Data Management Console - Instance Data Breakdown 動画による概要については、以下を参照してください。 Data Management - Console Features & Best Practices Delete Jobs 不要になったデータを削除する必要が生じる場合があります。ServiceNow は、インスタンスをクリーンな状態に維持し、不要なデータを排除できるよう、安全にレコードを管理および削除するための効率的なプロセスを提供しています。不要なデータを削除することで、システムリソースを解放し、ServiceNow インスタンスのパフォーマンス向上につながります。 Delete Jobs の詳細については、以下のナレッジ記事を参照してください。 Delete Jobs Table Cleaner Table Cleaner は、特定のテーブル内のレコード クリーンアップを自動化できる ServiceNow の強力なツールです。この機能は、ServiceNow インスタンスから古いデータや不要なデータを削除することで、システムパフォーマンスを向上させ、不要なデータの蓄積を防ぎ、データ整合性を維持するのに役立ちます。 Table Cleaner は、古くなったレコード、有効期限切れのレコード、または不要なレコードをテーブルから削除するための定期実行ジョブです。デフォルトでは毎時間実行されます。これにより、テーブルが過度に肥大化することを防ぎ、より優れたクエリパフォーマンスを実現します。 Table Cleaner の機能の詳細については、以下のナレッジ記事を参照してください。 Table Cleaner Data Archiving ServiceNow インスタンスの規模が拡大するにつれて、システムパフォーマンスと組織ポリシーへの準拠の両方を維持するために、増加するデータ量を適切に管理することが重要になります。そのための効果的な方法の一つが Data Archiving です。このプロセスにより、古く使用頻度の低いレコードを別の保存領域へ移動できるため、重要な履歴データへのアクセスを維持しながら、アクティブテーブルへの負荷を軽減できます。 Data Archiving とは何ですか？ ServiceNow における Data Archiving とは、古いレコードまたは使用頻度の低いレコードをアクティブテーブルからアーカイブテーブル群へ移動するプロセスです。アーカイブされたレコードは必要に応じて引き続き利用できますが、プライマリシステム内のリソースを消費しなくなるため、システムを効率的に運用できます。 なぜデータをアーカイブするのですか？ システムパフォーマンスの最適化 : アーカイブによりアクティブテーブルのサイズを削減できるため、処理対象データ量が減少し、システム応答性やクエリパフォーマンスを向上できます。ストレージ管理の改善 : 古いレコードをアーカイブすることで、アクティブデータベース内の貴重なストレージ領域を解放でき、現在利用中のレコードへ効率的に活用できます。コンプライアンスの確保 : アーカイブにより履歴データを保持しながら、アクティブ環境には関連性の高いデータのみを残すことができます。 Data Archiving の詳細については、以下のナレッジ記事を参照してください。 Data Archiving CMDB Data Manager CMDB Data Manager は、Configuration Management Database（CMDB）の整合性を効果的に管理および維持するための重要なツールです。CMDB は ServiceNow 環境における重要なコンポーネントであり、IT サービスおよび運用の中核となる Configuration Item（CI）に関する情報を保持しています。このデータを正確かつ最新で整理された状態に維持することは、効率的なサービス管理と意思決定に不可欠です。 CMDB Data Manager の詳細については、以下のナレッジ記事を参照してください。 CMDB Data Manager Clones ServiceNow における Clone とは、構成、スクリプト、データ、およびカスタムアプリケーションを含むインスタンスの完全または部分的な複製です。Clone を利用することで、本番環境を非本番環境へ複製したり、非本番環境間でデータをコピーしたりでき、運用環境へ影響を与えることなくテスト、トレーニング、トラブルシューティングを実施できます。 Clone の詳細については、以下のナレッジ記事を参照してください。 Clones Clone または Restore の実行中もしくは実行後にディスクまたは容量アラートが発生している場合は、Understanding Disk/Capacity Alerts During Clone and Restore Operations を参照してください。 Scripted Methods ServiceNow プラットフォームでのスクリプト作成に慣れているお客様は、スケジュールジョブ、Fix Script、または Scripts - Background モジュール内で GlideRecord の delete() および deleteMultiple() メソッドを利用できます。Scripted Methods は柔軟性を高めることができ、例えば削除速度を向上させるために、対象データセットの異なるサブセットに対して並列ジョブ（最大 4 件）を実行できます。 Scripted Methods 最大規模テーブルを管理するための戦略 このセクションでは、お客様から特に多くの関心が寄せられる大規模テーブルについての知見を提供します。データ蓄積の問題に対処している場合でも、ストレージを最適化したい場合でも、ここで紹介するヒントは最大規模のテーブルを効果的に管理し、最適化するのに役立ちます。 特定のテーブルにおけるレコード作成の傾向を把握したい場合があります。添付されている record_creation_trend_analysis スクリプトを実行することで、インスタンス内のその情報を取得できます。この種のスクリプトは、本番環境で実行する前に、まずサブ本番環境で実行することを常に推奨します。 sys_attachment/sys_attachment_doc ServiceNow では、ファイル、画像、ドキュメントなどの添付ファイルの管理は、インシデント管理や変更要求などのさまざまなワークフローにおいて一般的な業務です。ServiceNow には、これらの添付ファイルを効率的に保存、整理、および管理するための専用テーブルが用意されています。このプロセスで重要なテーブルが sys_attachment と sys_attachment_doc です。 sys_attachment テーブルとは何ですか？ sys_attachment テーブルは、ServiceNow におけるすべての添付ファイルのメタデータを管理する主要テーブルです。このテーブルには、各添付ファイルに関連する以下の情報が保存されます。 ・添付ファイルが関連付けられているテーブル（例：Incident、Change Request、Knowledge Article）・添付ファイル名・ファイルサイズ・添付ファイルの種類（画像、PDF、ドキュメントなど） sys_attachment_doc テーブルとは何ですか？ 一方、sys_attachment_doc テーブルには添付ファイルそのものの内容、つまりファイルデータ本体が保存されます。ファイルがシステムへアップロードされた後、そのバイナリデータはこのテーブルに保存されます。 簡単に言うと、 ・sys_attachment テーブルはメタデータ（添付ファイルに関する情報）を保存します。・sys_attachment_doc テーブルはバイナリコンテンツを保存します。 これら 2 つのテーブルおよびデータ管理方法についての詳細は、以下のナレッジ記事を参照してください。 sys_attachment/sys_attachment_doc これらのテーブルサイズは Instance Database Footprint ツールを使用して確認および監視できます。ただし、データの内訳までは確認できません。添付の sys_attachment_aggregated_script は、サブ本番環境で実行することで、サイズ順上位 10 テーブルについて、添付ファイル総容量および添付ファイル数の内訳を取得できます。 sys_audit sys_audit テーブルは、変更履歴を追跡し、レコードへのすべての更新が監査目的で適切に記録されるようにする重要な役割を果たします。 sys_audit テーブルとは何ですか？ ServiceNow の sys_audit テーブルは、システム内のレコードが変更されるたびに監査情報を記録するシステムテーブルです。更新されたフィールドに関する以下の情報を保持します。 ・何が変更されたか（例：フィールド値やデータ）・誰が変更したか（変更を実行したユーザーまたはシステム）・いつ変更されたか（日付と時刻）・変更前および変更後の値・どのレコードが変更されたか sys_audit テーブルは変更履歴を生成するため、コンプライアンス、トラブルシューティング、および透明性の確保を目的として、レコード変更を追跡できます。 sys_audit テーブルでのデータ管理方法についての詳細は、以下のナレッジ記事を参照してください。 sys_audit sys_audit_delete ServiceNow の sys_audit_delete テーブルは、監査対象レコードの削除情報を記録するために使用されます。このデータは削除履歴の追跡に利用でき、Delete Recovery 機能（Rollback ではありません）の一部としても使用されます。 sys_audit_delete テーブルでのデータ管理方法についての詳細は、以下のナレッジ記事を参照してください。 sys_audit_delete sys_email メールは、インシデント、リクエスト、通知、およびその他のワークフローの管理において重要な役割を果たします。sys_email テーブルは、すべてのメール関連アクティビティを記録および保存するシステムの重要なコンポーネントであり、ServiceNow インスタンス内で送受信されたメールの可視性を提供します。 通常のメールクライアントにおける「送信済みフォルダー」と「受信トレイ」を統合したものを、ServiceNow システム向けに提供していると考えるとわかりやすいでしょう。 このテーブルには、各メールの内容、送信者、受信者、ステータス、および処理情報などの重要な情報が記録されます。これにより、組織はメール通信の包括的な履歴を保持でき、追跡、監査、およびトラブルシューティングに役立ちます。 sys_email テーブルの仕組みおよびデータ管理方法についての詳細は、以下のナレッジ記事を参照してください。 sys_email ar_* テーブルおよび sys_archive_log これらのテーブルは Data Archiving 製品の一部です。ar_* テーブルにはアクティブテーブルからアーカイブテーブルへ移動されたレコードが保存され、sys_archive_log テーブルには必要に応じてレコードを復元するためのメタデータおよびペイロードが保存されます。 これらのテーブルのサイズ管理方法についての詳細は、以下のナレッジ記事を参照してください。 ar_* tables and sys_archive_log syslog* ServiceNow の syslog テーブルは、システムアクティビティ、パフォーマンスメトリック、エラー、および警告に関連するログエントリを保存する専用システムテーブルです。これらのログは、スクリプト実行、ワークフロー処理、インテグレーション要求の処理など、さまざまな操作中にシステムによって自動生成されます。syslog テーブルにより、管理者およびサポートチームは ServiceNow インスタンス内で発生するイベント、エラー、およびその他の重要なアクティビティを追跡できます。 これらのテーブルのサイズ管理方法についての詳細は、以下のナレッジ記事を参照してください。 syslog* cmdb* これらのテーブルのサイズ管理方法についての詳細は、以下のナレッジ記事を参照してください。 cmdb* sh* および sys_rollback* テーブル ServiceNow の Rollback Context は、特定の操作を元に戻し、不要な変更から復旧するための強力な方法を提供します。Rollback を使用すると、パッチアップグレード、プラグインの有効化、およびバックグラウンドスクリプト実行などの特定の操作を取り消すことができます。さらに、削除されたレコードおよび関連するすべての変更を復元できるため、必要に応じて重要なデータを回復できます。 これらのテーブルの内容および維持管理方法についての詳細は、以下のナレッジ記事を参照してください。 sh* and sys_rollback* tables pa_scores* および pa_snapshots テーブル Performance Analytics のスコアおよびスナップショットは、時間の経過とともに蓄積されるため、これらのテーブルサイズが増大し、システムパフォーマンスへ影響を与える可能性があります。 Clean PA Collections ジョブは毎日実行され、これらのテーブル内のデータをクリーンアップします。このジョブにより、一度に削除されるデータ量は少量に抑えられ、システムパフォーマンスへの大きな影響を回避できます。 詳細については、以下のナレッジ記事を参照してください。 pa_scores* and pa_snapshots tables