ServiceNowでAIに個人情報を渡さない設定はどこにある？ Data Privacyの32パターンを実機で読む

Now Assistを有効にしたい。ただ、インシデントの説明文に顧客の氏名やカード番号が入っていることがある。そのまま生成AIに渡してよいのか、という懸念は当然出てきます。ServiceNowにはData Privacyという仕組みがあり、AIや外部にデータが出る経路ごとに、値を隠す設定を持てるようになっていました。標準で32種類の検出パターンと9種類の隠し方が入っています。

結論：経路・検出・隠し方の3つを組み合わせる

先に全体像です。設定は3つの要素に分かれていました。

• どの経路に適用するか … dp_channel に4件。Now Assist、Virtual Agent、Data Kit、Data Extraction

• 何を個人情報とみなすか … dp_data_pattern に32件。クレジットカードから医療コードまで

• どう隠すか … dp_technique に9件。置換、削除、合成データへの差し替えなど

図の色は意味を持たせています。橙は分岐点、緑は設定できるもの、青は最終的に外へ出る値、灰色はこの環境で使われていない部分です。

この3つを組み合わせると、「Now Assistに渡すときだけ、クレジットカード番号を伏せ字にする」といった設定ができる構造になっています。

いちばん重要なのは、経路が4つに分かれていること

dp_channelを開くと4件ありました。

注目したいのは、経路ごとに別々の管理者ロールが割り当てられている点です。Now Assistの設定はnow_assist_data_privacy_admin、Virtual Agentはvirtual_agent_data_privacy_admin、Data Kitはdata_kit_data_privacy_admin。ひとつのロールで全部を触れるわけではありません。

生成AIの設定を任せる相手と、チャットボットの設定を任せる相手を分けられる。組織によっては、この分割が効いてきます。ロールが誰に付いているかを調べる方法はユーザー・グループ・ロールを中間表で読むにまとめています。

表示名と内部名が食い違う1件

一覧を見ていて気づいたことがあります。「Now Assist」と表示されているチャネルの内部名はGenerative AIでした。他の3件は表示名と内部名が一致しています。

スクリプトから参照するときは内部名を使うので、画面の表示だけを見てNow Assistと書くと動きません。ここは実機で見ないと気づけない部分です。

1件だけ規制対象から外れている

regulated_instanceという項目があり、4件のうち3件がtrue、Data Extractionだけfalseでした。

規制対象のインスタンスかどうかで挙動が変わる仕組みがある、という読み方になります。ただし、この値が具体的に何を切り替えるのかまでは確認できていません。推測は控えます。

32のパターンは、何を想定しているのか

dp_data_patternには32件が登録されていました。

分類して眺めると、想定している範囲がはっきりします。

いちばん手厚いのがクレジットカードでした。ブランド別に5件あります。Visa・Mastercard・American Express・Discover・Diners Club。さらにCVVと有効期限が独立して1件ずつ用意されていました。番号の桁数や形式がブランドごとに違うので、まとめて1パターンにはできないという事情でしょう。

国民IDは米国以外もカバーされています。インドのAadhaar、フランスのINSEE、カナダのSIN。英国はNHS番号とNational Insurance Numberの2種類。米国はSocial security numberに加えて、納税者番号・EIN・パスポート番号・グリーンカード番号まで揃っていました。

医療系にICD-10の診断コードが入っているのも目を引きます。病名そのものを機微情報として扱う想定です。

技術情報ではIPv4・IPv6アドレスとMACアドレス、車両識別番号。個人を特定しうる識別子として扱われています。

日本向けのパターンは見当たらなかった

32件を確認した限り、日本向けのパターンはありませんでした。マイナンバーにも、運転免許証の番号にも当てはまるものが見当たりません。

日本で使うなら、自分でパターンを追加する必要がありそうです。とはいえ、クレジットカードやメールアドレス、生年月日のような国に依存しないものは標準で使えます。足りない分だけ足す、という順序で考えるとよさそうです。

隠し方は9種類。「何もしない」も選べる

技法は9件でした。

固定文字への置換（Static Replace）、部分的な置換（Selective Replace）、先頭または末尾からの部分置換、ランダムな値への置換。値を消してしまうRemove。パターンに基づく匿名化と、合成データへの差し替え。

そしてNo Action、つまり「何もしない」という選択肢が1件あります。

これは無意味な設定に見えますが、実務では使い道があります。パターンとしては検出させたいが、値は残したい場合です。検出結果だけ記録して、実際の値は変えない。監査の観点で「どこに個人情報があるか」を把握する用途が想定できます。ここは推測です。

非推奨の技法が残っている

9件のうち1件はReplace - DEPRECATEDという名前でした。非推奨とはっきり書いてあります。

新しく設定するときは選ばないほうがよいものが、一覧に混ざっている状態です。名前を見れば分かるようになっているのは親切ですが、知らずに選ぶと後で困ります。

技法にはパラメータが付く

dp_technique_parameterに18件、dp_technique_parameter_valueに16件がありました。技法ごとに設定項目があり、既定値が用意されているという構造です。

たとえば部分置換なら「先頭から何文字を残すか」といった指定が要ります。そうしたパラメータがテーブルとして分離されているので、同じ技法を違う設定で使い分けられる作りに見えます。

テーブル15件のうち、7件にしかデータが入っていない

dp_で始まるテーブルは15件ありますが、実際にレコードが入っているのは7件でした。

入っているのは定義側でした。経路・技法・パターン・パラメータ・処理系の設定です。設定の材料は全部そろっていることになります。

0件だったのは、検出結果を記録するdp_user_sensitive_dataと、利用状況を記録するdp_telemetry、それに設定の紐付けを保持するテーブル群でした。実際に運用を始めると埋まっていく側です。

この構造は、他の機能でも見かける形です。定義は標準で投入され、実績は空。テーブルが存在することと、機能が動いていることは別だと考えたほうが安全です。同じ型は標準の連携定義が今も動くかや通知の棚卸しでも見ています。

処理系は2件、その設定は3件

dp_system_processorに2件、dp_system_processor_configurationに3件がありました。

処理系というのは、実際に値を検出して加工する部分にあたります。パターンと技法が「何を、どう」を決める設定だとすると、こちらは「それを実行する側」です。

2件しかないのは、検出の実装が限られているということでしょう。パターンを32件も用意しておきながら処理系が2件で足りるのは、パターン側が正規表現のような共通の形式で書かれていて、同じエンジンで処理できるからだと考えられます。ここは推測です。中身のスクリプトまでは追っていません。

設定の紐付けはまだ空のまま

15テーブルのうち0件だったものを見ると、この機能の使い方が推し量れます。

dp_m2m_configuration_patternは、設定とパターンを結ぶ中間テーブルです。0件ということは、どのパターンをどの経路で使うかの紐付けが、まだ一件も作られていないという状態を意味します。

dp_configuration_domain_separatedも0件。ドメイン分離を使う環境向けの設定です。

dp_discovery_api_policyも0件。APIからの検出に関するポリシーのようです。

つまり標準では、材料だけが置かれていて、組み合わせは利用者が作るという設計になっています。インストールしただけでは何も起きません。パターンと技法を選んで、経路に紐付けて、はじめて動き始めます。

この「材料は用意するが組み合わせは決めない」という方針は、個人情報の扱いが国や業種で大きく変わることを考えれば妥当です。日本の企業がマイナンバーを追加し、医療機関がICD-10を有効にする。同じ標準から出発して違う設定に育てられます。

導入前に確認しておきたいこと

実際に使う前に、いくつか押さえておく点があります。

ロールの割り当て先を決めておく。 経路ごとに管理者ロールが分かれているので、Now Assistを使うだけでも専用のロールが要ります。誰に渡すかは組織の判断になります。セキュリティ担当なのか、AI導入の担当者なのか。

標準パターンで足りるかを棚卸しする。 32件は網羅的に見えますが、日本向けは入っていません。自社が扱う情報を一覧にして、対応するパターンがあるか照合する作業が要ります。

技法の選択が品質に影響することを理解しておく。 完全に削除すると、AIは文脈を失います。合成データに置き換えれば文脈は残りますが、実在しない値が回答に混ざる可能性があります。パターンごとに使い分ける判断が必要です。

検出漏れを前提に設計する。 パターンマッチは万能ではありません。自由記述の中に書かれた氏名や、独自形式の社内番号は拾えない可能性があります。この仕組みだけに頼らず、そもそも機微情報を書かせない運用と組み合わせるのが現実的でしょう。

32パターンを分類して分かること

パターンの構成を見ると、想定されている業種が読み取れます。

金融系が厚いのは明らかです。クレジットカード7件に加えて、IBAN、SWIFT・BIC、米国の銀行支店番号。ビットコインのウォレットアドレスまで入っています。決済や送金を扱う業務での利用を想定しているのでしょう。

医療系は2件だけですが、ICD-10の診断コードという踏み込んだものが入っています。病名は最も機微な情報のひとつです。カルテを直接扱わなくても、問い合わせの本文に病名が書かれることはあり得ます。

行政・公共系は国民IDが中心でした。10か国以上をカバーしています。グローバルで使う製品として当然の設計ですが、日本が入っていないのは残念なところです。

技術情報が含まれているのは見落としやすい点です。IPアドレスやMACアドレスは、単体では個人情報に見えません。ただ他の情報と組み合わせると個人を特定できるため、地域によっては個人データとして扱われます。標準で入っているのは、そうした規制を意識した結果だと考えられます。

逆に入っていないもの

氏名そのもののパターンは見当たりませんでした。住所もありません。

これは技術的な理由がありそうです。氏名や住所は形式が定まっていないため、正規表現のようなパターンマッチでは検出が難しい。クレジットカード番号のように桁数と形式が決まっているものと違い、機械的に見つけられません。

つまりこの仕組みで守れるのは、形式が決まっている情報だけということになります。自由記述に書かれた氏名は、別の手段で対処する必要があります。ここは導入時に期待値を合わせておくべき部分でしょう。「AIに個人情報を渡さない仕組みを入れた」と説明すると、氏名まで守られると受け取られかねません。何が守れて何が守れないかを、最初にはっきりさせておいたほうが安全です。

運用に乗せたあとに見る場所

設定して終わりではありません。動き始めたら見る場所があります。

dp_user_sensitive_dataが検出結果の記録先です。この環境では0件でしたが、運用を始めるとここに溜まっていくはずです。何が検出されたかを追えるようになります。

dp_telemetryは利用状況の記録です。こちらも0件でした。どの経路で何回加工が走ったか、といった情報が入ると推測されます。

dp_product_action_historyも0件で、名前から見て操作履歴でしょう。誰がいつ設定を変えたかを追う用途だと思われます。ログがどこに残るかという観点はデータがどこに溜まっていつ消えるかでも扱いました。個人情報の検出記録そのものが機微情報になるので、保持期間の設計は別途必要になります。

実機を見て気づいたこと

いちばん意外だったのは、経路ごとにロールが分かれていたことでした。Data Privacyという名前から、instance全体に一律で効く設定を想像していました。実際は「Now Assistに渡すとき」「Virtual Agentに渡すとき」と経路単位で、しかも管理者まで分かれています。生成AIの導入を段階的に進める組織を想定した作りに見えます。

もうひとつは、表示名と内部名のズレです。画面には「Now Assist」と出ているのに、内部名はGenerative AIでした。4件中1件だけこうなっています。おそらく機能名が後から変わったのだろうと考えていますが、確証はありません。画面の表示を信じてスクリプトを書くと動かないという、地味に厄介な部分です。

そして「No Action」の存在です。隠す仕組みなのに、何もしない選択肢が最初から入っている。検出と匿名化が別々に設計されていることの表れだと読みました。何を個人情報とみなすかの定義と、それをどう扱うかの判断が、分離されているわけです。

この機能はZurichには入っていませんでした。テーブルもプラグインも存在しません。新しいリリースで追加された仕組みということになります。

この仕組みが必要になる場面

そもそも、なぜ経路ごとの設定が要るのでしょうか。

社内で完結しているうちは、権限で守れました。誰がどのレコードを見られるかはACLとロールの層で決まります。見せたくない相手には見せない。それで足りていました。

ところが生成AIに渡すとなると、話が変わります。渡した先で何が起きるかを、権限では制御できません。AIは渡された文字列を処理するだけで、そこに誰の権限が働くわけでもない。だから渡す前の値そのものを加工する必要が出てきます。

Data Privacyが経路単位になっているのは、この理由だと考えられます。社内の画面表示はACLで守り、外へ出る経路は値の加工で守る。守り方が二段構えになっているわけです。

似た仕組みとの違い

ServiceNowには値を隠す仕組みがいくつかあります。区別しておくと混乱しません。

フィールドレベルのACLは、特定のユーザーに見せない仕組みです。値そのものは残ります。項目が画面に出ないときの切り分けで扱ったとおり、見え方の制御です。

Data Privacyは、外に出る値を加工する仕組みです。誰が見るかではなく、どこへ渡すかで決まります。

暗号化はまた別で、保存されている値そのものを読めなくします。用途が違うので、置き換えの関係にはありません。

実際に試すときの順序

この記事では設定を変更していません。読み取りだけです。実際に動かすなら、次の順序が安全だと思います。

まず検証環境で、No Actionから始める。 検出だけ動かして、何が引っかかるかを見ます。いきなり値を消すと、AIの回答品質がどう変わるか分からないまま本番に持っていくことになります。

次に、影響の小さいパターンから有効にする。 クレジットカード番号のように、業務上まず使わない値から始めるとリスクが低い。メールアドレスや氏名を最初に消すと、問い合わせ対応の文脈が壊れる可能性があります。

そして、隠した後の回答を実際に読む。 ここが肝心です。値を隠せば安全になりますが、AIの回答が使い物にならなくなっては意味がありません。保護と実用のバランスは、実際の回答を見ないと決められません。

最後に、検出漏れを探す。 自由記述の中に、パターンに引っかからない形で機微情報が書かれていないか。ここは人が読んで確かめるしかない部分です。

この順序なら、途中で止めても被害が出ません。逆に全パターンを一気に有効にすると、何が原因で回答が変わったのか切り分けられなくなります。

実務では何に使えるか

生成AIの導入を検討している段階なら、次の順で確認すると話が進めやすいと思います。

まず経路を決めます。 Now Assistだけなのか、Virtual Agentも使うのか。経路が決まればロールも決まるので、誰に設定を任せるかの整理につながります。

次にパターンを棚卸しします。 標準の32件で足りるか、自社で扱う情報に合わせて追加が要るか。日本の個人情報を扱うなら追加は避けられません。ここで「何を機微情報とみなすか」を組織として決めることになります。

最後に技法を選びます。 完全に消すのか、部分的に伏せるのか、合成データに置き換えるのか。AIの回答品質と保護の強さはトレードオフなので、パターンごとに変えることになるはずです。

この3段階を先に決めておくと、AI導入の稟議で「個人情報はどうするのか」と聞かれたときに、具体的な設計として答えられます。

誰が判断するかを先に決める

技術的な設定より難しいのが、この部分かもしれません。何を機微情報とみなすかは、情報システム部門だけでは決められない話です。法務や、業務部門の判断が要ります。

一方で、パターンや技法の設定を触れるのは専用のロールを持つ人だけです。判断する人と設定する人が違う場合、その間をつなぐ手順が必要になります。承認を挟むなら、承認が誰の画面で止まっているかを追う仕組みと組み合わせることになるでしょう。

設定変更の履歴を残す必要もあります。監査で「いつから、この情報を隠しているのか」を問われる可能性があるためです。変更履歴の追い方は誰が何を変えたかはどこに残るかにまとめています。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• 匿名化：個人を特定できないように値を加工すること

• 合成データ：実在しないが形式は本物らしいダミー値

自分の環境で確認するときのURL

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

• /dp_channel_list.do … 適用する経路

• /dp_data_pattern_list.do … 検出パターン

• /dp_technique_list.do … 隠し方の技法

• /dp_technique_parameter_list.do … 技法ごとの設定項目

• /sys_db_object_list.do?sysparm_query=nameSTARTSWITHdp_ … 関連テーブルの一覧

関連記事

• ServiceNowで権限はどこで決まる？ ユーザーからACL・ドメインまで7つの層を実機でたどる完全ガイド — チャネルごとのロール分割を理解する前提になります。

• ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表で読む — 管理者ロールを誰に割り当てるかを調べるときに使えます。

• ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — 個人情報がどこに残るかという観点で続けて読めます。

検証環境と未検証範囲

• 確認した範囲：Australia PDI（OOTB）におけるdp_系15テーブルの件数、dp_channel4件・dp_technique9件・dp_data_pattern32件の中身、および各テーブルの一覧画面。すべてREST APIと画面の読み取りのみで、設定の変更は行っていません。

• 確認していない範囲（断定しません）：実際にNow AssistやVirtual Agentを動かして値が隠されるところ、dp_user_sensitive_dataに検出結果がどう記録されるか、各技法のパラメータの具体的な意味と設定手順、regulated_instanceフラグが何を切り替えるのか、パターンを自分で追加する手順。これらは別途の検証が必要です。

• この機能はZurichには存在しませんでした。Australiaで新しく入ったものです。ただし本記事は2つの別々のPDIを比較した結果であり、アップグレードを通した場合の挙動は確認していません。