System Clone：クローンで何が残り、何が消えるか
「本番と同じデータで検証したい」。これは正しい望みです。ただし本番をそっくりコピーすると、困ったことが起きます。検証環境から本物の顧客へメールが飛ぶ。監視サーバへの接続情報がコピーされ、検証機が本番の機器を叩きにいく。個人情報が検証環境に増える。
ServiceNow の System Clone は、この問題に3つの仕掛けで答えています。持っていかない（除外）、上書きさせない（保持）、あとで直す（後始末）。今回は、その3つが実機にどれだけ入っているかを数え、中身を読んでみます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
クローンは3つの仕掛けで調整する
まず全体像です。
左のコピー元から右のコピー先へデータが流れます。その途中に除外と保持が立ち、流れを止めたり守ったりする。到着後には後始末が走り、使える状態に整える。この4つを束ねるのがクローンプロファイルです。
除外と保持は名前が似ていますが、結果が違います。除外したテーブルは、コピー先で空になる。保持したテーブルは、コピー先の既存データがそのまま残ります。「消える」のか「今のまま」なのか。この違いが分かれ目です。
なぜコピーするのか
そもそも、なぜ本番のコピーが要るのでしょうか。空の検証環境で足りるなら、そのほうが安全です。
答えは「量と形」にあります。本番には数十万件のレコードがあり、長年の運用でできた設定の癖があります。空の環境で動いた改修が、本番のデータ量では遅すぎる。空の環境では通った承認フローが、本番の複雑な組織構造では止まる。こうしたずれは、本番相当のデータでしか見つかりません。
だからコピーする。ただし、そのままでは危ない部分だけを外す。除外・保持・後始末の3つは、この「ほぼ本番、でも安全」を作るための道具です。
保持定義が持つ3つの真偽フィールド
保持定義（clone_data_preserver）の辞書を見ると、真偽値のフィールドが3本ありました。
include_in_system_clone … システムクローンの対象に含めるか。実測207件すべて true
theme … 見た目（テーマ）に関する定義かどうか
default … 既定の定義かどうか
include_in_system_clone が全件 true なのは、標準で用意された定義がすべてクローン対象だからです。自分で定義を足すときに、一時的に外しておく用途を想定した項目と読めます。
theme はプロファイルの Preserve Theme と対になります。この印が付いた定義は、テーマを残す設定を選んだときだけ効く。オプション1つで関連する複数の定義をまとめて切り替える作りです。
除外：持っていかないテーブル
clone_data_exclude は 242件 ありました。
name にテーブル名がそのまま入る作りです。名前順の先頭には、こんなテーブルが並びます。
account_subscription_entitlement（サブスクリプションの権利）
auth_key_verification（認証キーの検証）
auth_token_mapping（認証トークンの対応付け）
cdc_queue_ih（連携のキュー）
どれも認証や連携に関わるもので、コピー先に持ち込むと外部システムへの接続が本番と競合しかねない種類です。
面白いのは、そのあとに続く4件です。clone_cleanup_script / clone_data_exclude / clone_data_preserver / clone_preserved_data。クローンの仕組み自身のテーブルが、除外に入っています。
理由を考えると納得できます。コピー先には、そのコピー先なりのクローン設定があるはずです。コピー元の設定で上書きしてしまうと、次にコピー先からクローンを作るときに困ります。だから、クローンの設定はクローンで運ばない。
除外にも condition フィールドがあります。テーブル全体ではなく、条件に合う行だけを外すこともできる作りです。
保持：コピー先の値を守る
clone_data_preserver は 207件。
対象テーブルは 200種類 に広がっていました。1テーブルに複数の保持定義がぶら下がることもあります。最多は sys_properties の 8件 でした。
システムプロパティを丸ごと保持すると、コピー元の設定が一切入ってきません。かといって丸ごと上書きすると、コピー先のURLやメール設定まで書き換わってしまう。だから条件で細かく分けて、守るべきプロパティだけを名指しで残します。
なお sys_properties の保持定義は、集計APIでは8件と出ましたが、一覧APIで取得できたのは7件でした。差が出る理由までは追っていません。名前が分かった7件はこれです。
CustomURL properties（独自URLの設定）
Upgrade Plan Configuration（アップグレード計画）
Core Instance Properties（コア設定）
Custom Theme Application Property（独自テーマ）
Application Theme Properties（アプリのテーマ）
On-call Properties（オンコール通知）
Enable Clone Rest（クローンのREST有効化）
並べてみると性格が見えます。どれも「このインスタンス固有の事情」を持つ設定でした。コピー元の値を持ち込むと辻褄が合わなくなるものばかりです。
条件で「この行だけ残す」
保持定義を1件開いてみます。
「Core Instance Properties」という定義の条件は、こう始まっていました。
name=glide.sys.schedulers
^ORnameSTARTSWITHglide.db
^ORname=glide.ui.max.transactions
^ORnameINglide.email.read.active,glide.email.server,glide.email.smtp.active,…スケジューラの設定、データベース関連（glide.db で始まるもの）、同時実行数の上限、そしてメール関連の一群。どれもインスタンスごとに違う値で、コピー元の値を持ち込むと事故になるものばかりです。
メール関連が保持に入っているのは、後述する「Disable emails」の後始末と合わせて二重の守りになります。設定を残しつつ、送信自体も止める。
実画面で見えた保持定義の例
プロファイルの関連リストには、条件つきの定義がいくつも並んでいました。
JWT Keys（jwt_keystore_aliases）… 条件なし。鍵はコピー先のものを守る
On-call Properties（sys_properties）… オンコール通知の番号だけを名指し
UX Theme M2M Assets（sys_ux_theme_m2m_asset）… 条件 themeISNOTEMPTY^EQ、Theme 列は true
My Company（core_company）… 条件 primary=true^EQ。自社レコード1件だけを守る
App Collaboration Descriptor Permission … 条件 sys_scope=global^EQ
My Company の条件が目を引きます。core_company は取引先も含む会社テーブルですが、primary=true の1行だけが「自社」です。会社一覧はコピー元から持ってきつつ、自社レコードだけはコピー先のものを残します。粒度の細かさがよく分かる例です。
Theme 列が true の定義は、プロファイルの Preserve Theme オプションと連動します。見た目を残す設定を選ぶと、この印の付いた定義が効きます。
後始末：クローン後・稼働前に走る処理
clone_cleanup_script は 21件。うち有効なものが20件、無効が1件でした。
名前を眺めると、クローン直後のインスタンスが抱える問題がそのまま見えてきます。
Disable emails。これが最も分かりやすい後始末です。クローン直後にメール送信を止めておかないと、コピーされた通知設定が動いて本物の相手にメールが飛びます。
Bad MID Server credentials after clone と Clean Non-Existent MIDs From Application。MID Server はインスタンスと社内ネットワークをつなぐ中継役で、コピー先からは同じ MID を使えません。その参照を後始末スクリプトが片付けます。
Clear Vault Token。秘密情報の保管トークンを消します。コピー先に本番の鍵が残らないようにするための処理です。
Regenerate all text indexes。全文検索の索引を作り直します。データをまるごと入れ替えたあとは、索引も作り直さないと検索がずれます。
Clear scheduled job node association。スケジュールジョブとノードの紐づけを外します。コピー元のノード名はコピー先に存在しないので、そのままだとジョブが動きません。
Install deactivated plugin。無効になったプラグインを入れ直します。クローンでプラグインの状態が変わることがあり、その辻褄を合わせる処理です。
order には3段ある
order は 100、200、1000 の3種類でした。17件が100、2件が200、1件が1000です。
対になっているものがあります。PI Training Schedules は、order 100 で Deactivation（停止）、order 200 で Reactivation（再開）。先に止めて、あとで戻す。順番に意味があるので、order で並べ替えて実行されます。
order 1000 の ReSync App Collaborator Permissions が最後に走るのも理にかなっています。他の後始末で参照が整理されたあとに、権限を同期し直す流れです。
クローンプロファイル：3つを束ねる
ここまでの定義を選んで1セットにするのが clone_profile です。この PDI には System Profile が1件だけありました。
Options は6項目ありました。オンだったのは次の4つです。
Exclude Tables Specified In Exclusion List（除外リストを適用する）
Exclude Audit And Log Data（監査とログを外す）
Exclude Attachment Data（添付を外す）
Preserve Theme（見た目を残す）
残りの2つは値を持つ項目でした。Data Copied From Specific Tables が Full、Preserve In Progress Global Update Sets が None です。
Preserve In Progress Global Update Sets が None なのは考えどころです。作業中の更新セットはコピー先で消えます。検証環境で開発している最中にクローンが走ると、その作業は失われる。クローンの予定を開発者に伝えておくのが大事になる理由が、この設定に表れています。
監査・ログと添付を外す設定が既定でオンなのは、量の問題です。この2つはデータ量の大半を占めることが多く、検証には不要なことがほとんど。外せばクローンの時間が縮みます。
Target Instance は空でした。PDI は本番とサブ本番の関係を持たないので、コピー先を指定できません。実運用ではここに対象インスタンスが入ります。
Related Links に Create Clone Request があり、ここからクローンの依頼を起票する導線になっています。
定義があっても、使われるとは限らない
プロファイルの関連リストに、面白い数字が出ていました。
保持は207件のうち184件、除外は242件のうち218件、後始末は21件のうち17件。それぞれ20件前後の差があります。
つまり、テーブルに定義があることと、そのプロファイルで有効になっていることは別です。クローンの挙動を確認したいときに定義テーブルだけを見ると、実際とずれた読み方になります。
見るべきはプロファイルの関連リストのほうです。「このプロファイルでクローンしたら何が起きるか」は、プロファイルに紐づいた184件・218件・17件が決めます。
実行の記録はこのPDIには無かった
clone_instance（クローン実行の記録）を数えたところ、0件 でした。この PDI ではクローンが実行されたことがありません。
そのため、この記事で確認できたのは「クローンの設計図」までです。実際に走らせたときに何がどう動くかは、記録が無いので読み取れませんでした。
裏を返せば、定義は使われていなくても最初から全部入っている、ということでもあります。クローンを初めて実行する環境でも、メール停止や MID の整理といった基本的な後始末は用意されている。何も設定しなくても最低限の安全が確保される作りです。
実務で気をつけるところ
除外と保持を取り違えない
「このテーブルのデータは触らないでほしい」と言われたとき、除外を選ぶか保持を選ぶかで結果が正反対になります。除外を選ぶとコピー先で空になり、保持を選ぶとコピー先の中身が残ります。守りたいなら保持です。
監査・ログ・添付を外す判断
プロファイルの既定では、監査データ・ログデータ・添付データがまとめて外れます。この3つはデータ量の大半を占めるので、外すとクローンが速く終わります。
ただし、外れて困る場面もあります。「いつ誰がこの値を変えたか」を検証環境で追いたいなら監査データが要る。添付の表示を確認したいなら添付データが要る。既定はあくまで既定で、目的しだいでオンとオフを切り替える項目です。
外した場合、コピー先では該当テーブルが空になります。「監査履歴が見られない」と検証中に気づいたら、この設定を疑うと早く見つかります。
除外と保持がぶつかったら
同じテーブルに除外と保持の両方を設定したらどうなるか。気になるところですが、この記事では確かめていません。クローンを実行していないので、実際の優先順位は観測できませんでした。
設定を作る側としては、そもそも両方を設定しない運用にするのが安全です。「持っていかない」と「上書きさせない」は目的が違うので、どちらか一方で足ります。
独自テーブルには何も設定されていない
242件の除外も207件の保持も、標準テーブルに対する定義です。独自に作ったテーブルには何も入っていません。個人情報や接続情報を独自テーブルに持っているなら、自分で定義を足す必要があります。
クローン前に開発を止める
Preserve In Progress Global Update Sets が None である以上、作業中の更新セットはコピー先で失われます。検証環境で開発している人がいるなら、クローンの前に完了させるか、更新セットを書き出しておく必要があります。
クローンは「環境を新しくする」作業に見えますが、コピー先にとっては「今の状態を捨てる」作業でもあります。捨ててよいかを確認してから走らせる。この一手間を飛ばすと、数日ぶんの作業が消えます。
後始末は名前で目的が分かるように書く
後始末スクリプトは、クローン後にコピー先で走ります。問題が起きたとき、最初に見るのは名前です。標準の20件が「Disable emails」「Clear Vault Token」のように動詞で始まっているのは、そのための工夫です。自分で足すときも同じ書き方に揃えると、後から読む人が助かります。
どこから触るか
/clone_data_exclude_list.do … 除外テーブル242件
/clone_data_preserver_list.do?sysparm_query=ORDERBYtable … 保持定義207件
/clone_cleanup_script_list.do?sysparm_query=ORDERBYorder … 後始末21件
/clone_profile_list.do … クローンプロファイル
/clone_instance_list.do … クローン実行の記録
保持定義の一覧では、Table 列と Conditions 列を出しておくと読みやすくなります。条件が入っているかどうかで、丸ごと守るのか一部だけ守るのかが分かります。
まとめ
クローンは「全部コピー」ではありません。何を持っていかないか、何を守るか、あとで何を直すか。この3つの設計が先にあって、その組み合わせがプロファイルになります。
実測では除外242件、保持207件、後始末21件。ただしプロファイルに載っているのは218件・184件・17件で、定義の総数とは一致しませんでした。挙動を確かめるときはプロファイル側を見るのが確実です。
保持の条件に primary=true で自社レコード1件だけを指定していたり、予測学習のスケジュールを停止と再開で対にしていたり。標準の定義を読むだけでも、クローン運用で気をつけるべき箇所が見えてきます。
用語
クローン（System Clone） … インスタンスのコピーを別のインスタンスに作ること
除外（clone_data_exclude） … そのテーブルのデータを運ばない。コピー先では空になる
保持（clone_data_preserver） … コピー先の既存データを上書きさせない。条件で行を絞れる
後始末（clone_cleanup_script） … クローン後・稼働前にコピー先で走る処理。order 順
クローンプロファイル（clone_profile） … 除外・保持・後始末を選んで束ねた1セット
Preserve Theme … コピー先の見た目を残すオプション。Theme 印の付いた保持定義が効く
自分の環境で確認するときのURL
/clone_data_exclude_list.do?sysparm_query=ORDERBYname（除外242件）
/clone_data_preserver_list.do?sysparm_query=ORDERBYtable（保持207件）
/clone_data_preserver.do?sys_id=...（Core Instance Properties の条件）
/clone_cleanup_script_list.do?sysparm_query=ORDERBYorder（後始末21件）
/clone_profile.do?sys_id=...（System Profile のオプションと関連リスト）
実測の要点（再掲）
clone_data_exclude 242件 / clone_data_preserver 207件 / clone_cleanup_script 21件（active 20）
保持の対象テーブルは200種類。最多は sys_properties の8件
include_in_system_clone は保持207件すべて true
プロファイルの関連リストは Preservers 184 / Exclusions 218 / Cleanup Scripts 17
後始末の order は 100（17件）/ 200（2件）/ 1000（1件）
clone_instance は0件。この PDI でクローンは実行されていない
関連記事
ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — クローンで何を持っていき何を残すかも、データのライフサイクルの一部。添付・履歴・ログがどこにどれだけ溜まるかを合わせて確認すると、インスタンス間のデータの動きが見える。
検証範囲とおことわり
件数・項目・条件は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
クローンそのものは実行していません。設定の読み取りまでにとどめました。
後始末スクリプトの中身（script フィールド）は読んでいません。名前・order・active の確認までです。
除外・保持の condition が実際にどう評価されるかは未検証です。
PDI は本番とサブ本番の関係を持たないため、Target Instance は空のままでした。
