ServiceNowの匿名化はどこまで細かく設定できる？ dp_technique_parameterの既定値を実機で読む

個人情報を隠す設定を入れることになった。ただ「隠す」といっても、全部を伏せ字にするのか、先頭だけ残すのか、別の値に置き換えるのか。選択肢が分からないと設計できません。ServiceNowの匿名化機能を調べたところ、9つの技法のうち5つがパラメータを持っていて、マスクに使う記号や置換先の値まで既定値が決まっていました。

隠す前に「見つかるかどうか」をその場で試せる

Data Pattern のフォームには Test ボタンがあります。押すとモーダルが開き、任意の文章を入れてその場で判定できます。レコードを保存しなくても、既定のパターンが自社の書き方に反応するかを確かめられる作りです。

この1画面に匿名化の3要素がそろっています。どう見つけるかが Expression の正規表現です。どう隠すかが Privacy Technique Configuration、何に置き換えるかが右側の Synthetic Values にあたります。

Email のパターンで、日本語のメール文面を判定してみました。

日本語の地の文に英字のアドレスが1つ混じっただけの文章です。パターンが見ているのは英字の並びなので、周囲が日本語でも反応しました。

個人情報を含まない文章に差し替えると、判定は裏返ります。

検出されなければ、何も隠れません。 匿名化が効かない事故は、加工の側ではなく検出の側で起きます。技法の設定に入る前に、自社の文面がパターンに引っかかるかをこの画面で確かめておくと手戻りが減ります。

個人情報を隠すとき、何を決める必要があるか

「AI に渡す前に個人情報を伏せたい」という要件が来たとき、決めることは3つあります。

何を検出するか。 どう隠すか。そして隠したあとの値が後続の処理を通るか。3つ目が抜けると、桁数チェックや形式チェックで止まります。

このうち「どう隠すか」を担当するのが匿名化の技法です。全部を伏せ字にするのか、先頭だけ残すのか、別の値に置き換えるのか。選択肢を知らないと設計できません。

検出と匿名化は別の仕組み

Data Privacy の機能は2段に分かれています。どこに個人情報があるかを見つける層と、見つけたものを加工する層です。

検出はパターンで行います。メールアドレスらしい文字列、電話番号らしい並び。パターンの中身はServiceNowでAIに個人情報を渡さない設定はどこにある？で扱いました。

この記事が見るのは加工の側です。技法と、その技法が受け取るパラメータ。検出できても、隠し方を決めなければ動きません。

公式が書いているパラメータの意味

dp_technique_parameter の主要な項目には、ServiceNow 自身の説明が付いていました。

name は「Parameter expected by technique」。技法が期待するパラメータ、という言い方をしています。技法の側が要求する引数だという関係が読み取れます。

technique は「Technique using this parameter」で、このパラメータを使う技法を指します。description は「Description of parameter」でした。

このテーブルは Application File を継承しています。更新セットで運ばれる、アプリケーションの一部という扱いです。自分でパラメータを増やす想定はされていないと読むのが自然でしょう。既定値を変える運用が中心になります。

設定できるのは9技法のうち5つだけ

図の色は意味を持たせています。紺が起点で、青が対応する情報。緑は設定できる技法、赤は非推奨です。灰色は設定不要のものを示します。

匿名化の技法は9つあります。そのうちパラメータを持つのは5つ。残り4つは設定項目がありません。

設定が要らない4つは、動作が固定だからです。Removeは値を消すだけ、No Actionは何もしないだけ。Data Pattern AnonymizationとSynthetic Data Anonymizationも、内部のロジックで完結します。

パラメータの中身を見る

パラメータは全部で18個。技法ごとに分かれています。

具体的な値が入っているのが分かります。順に見ていきます。

端から何文字かを隠す

Selective Replace From Start or Endは3つのパラメータを持ちます。

マスクする文字数の既定値は5。どちらの端から始めるかは Left to Right、つまり左からです。マスクに使う記号はアスタリスクでした。

電話番号やカード番号のように、末尾4桁だけ残したい場面を想定した設定でしょう。既定のままなら、先頭5文字が*****に置き換わります。

位置を指定して隠す

Selective Replaceはもう少し細かい制御ができます。パラメータは4つ。

開始位置の既定値は1、置換に使う文字はアスタリスク。ここまでは似ています。

違うのは、終了位置と除外文字を指定できる点です。どちらも既定値は空で、必須でもありません。「3文字目から7文字目まで」「ハイフンは残す」といった細かい指定ができます。

メールアドレスの@より前だけ隠す、ハイフン入りの番号でハイフンだけ残す。そういう使い方が想定されていそうです。

決まった値に置き換える

Static Replaceは4つのパラメータを持ちます。ここが面白いところでした。

型ごとに置き換え先が分かれています。

文字列ならTEXT123、数値なら1234567、日付なら1988-11-11、日時なら1988-11-11 11:11:11。

これは考えてみれば当然です。日付フィールドにTEXT123は入りません。型が合わない値を入れると、置き換えた時点でエラーになります。だから型ごとに用意されています。

日付の既定値が1988-11-11なのは、1が並んでいて覚えやすいからでしょう。ログを見たときに「これはマスクされた値だ」と一目で分かります。

長さを保つかどうか

Random Replaceのパラメータは1つだけ。preserve_data_lengthで、既定値はtrueです。

ランダムな値に置き換えるとき、元の長さを保つかどうかの指定です。既定では保ちます。

長さを保つ理由は想像がつきます。桁数が変わると、後続の処理で弾かれる可能性があるためです。カード番号を16桁のまま別の値にする、電話番号を11桁のまま変える。形式チェックを通したいなら、長さは保ったほうが安全です。

非推奨の技法がいちばん設定項目を持っている

意外だったのがReplace - DEPRECATEDです。名前のとおり非推奨なのに、パラメータが6個で最多でした。

中身を見ると、Static Replaceの4つ（型ごとの置換値）と、Random Replaceの1つ（長さを保つか）、それにuse_random_generated_valueという項目を持っています。

つまりこの1つの技法が、固定値への置換とランダム置換の両方をやっていたわけです。use_random_generated_valueという真偽値で、どちらの動作をするかを切り替えていたのでしょう。

現在はStatic ReplaceとRandom Replaceの2つに分割されています。1つの技法にフラグで分岐を持たせるより、技法自体を分けたほうが分かりやすい。そういう判断だと読めます。ここは推測です。

非推奨のものを見ると、以前の設計が分かるという例でした。

パラメータの命名がばらついている

細かい点ですが、気になったことがあります。

マスクに使う文字を指定するパラメータが、技法によって名前が違います。Selective Replace From Start or Endではmasking_symbol、Selective Replaceではreplacement_char。

どちらも既定値はアスタリスクで、用途も同じに見えます。それでも名前が違う。

技法ごとに別々の担当者が実装したのか、時期が違うのか。理由は分かりません。ただ、スクリプトから参照するときは技法ごとに名前を確認する必要があるということです。同じだろうと思って書くと動きません。

どのフィールドに適用するかは別の問題

技法とパラメータが決まっても、それだけでは動きません。どのフィールドを対象にするかを決める必要があります。

ここで難しいのは、個人情報が入る場所が1か所ではないことです。

インシデントの説明文に顧客名が書かれる。作業メモに電話番号が残る。添付ファイルの中身にカード番号がある。同じ「個人情報」でも、置かれる場所はばらばらです。

添付の中身がどこに保存されるかは添付ファイルはDBのどこに保存される？で扱いました。本体とは別テーブルに分割されているので、対象に含めるかどうかは別途の判断になります。

履歴に残った値はどうなるか

もうひとつ見落としやすいのが、変更履歴です。

いま画面に表示されている値を隠しても、過去の値が履歴に残っていれば、そこから読めてしまいます。誰が何を変更したかの記録は変更履歴はどこに残る？で扱ったとおり、専用のテーブルに蓄積されます。

匿名化の対象に履歴を含めるのか、含めないのか。今回の調査では、そこまで追えていません。ただ設計するときに必ず出てくる論点なので、先に考えておいたほうがよさそうです。

データがどこに溜まっていつ消えるかという観点はデータはどこに溜まっていつ消える？にまとめてあります。保持期間の設計と合わせて考える必要があります。

「見せない」と「隠す」は違う

匿名化を検討していると、既存の仕組みと混同しがちです。整理しておきます。

フィールドレベルのACLは、特定のユーザーに見せない仕組みです。値そのものはデータベースに残ります。権限を持つ人には見えます。項目が画面に出ない理由の切り分けは項目が画面に出ないのはなぜ？で扱いました。

匿名化は、外に出る値を加工する仕組みです。誰が見るかではなく、どこへ渡すかで決まります。加工された値が相手に届きます。

区別が要るのは、生成AIに渡すときには権限が働かないからです。AIは渡された文字列を処理するだけで、そこにACLは介在しません。だから値そのものを加工する必要が出てきます。

誰にどのロールが付いているかを調べる方法はユーザー・グループ・ロールを中間表で読むにまとめました。匿名化の設定を任せる相手を決めるときに使えます。

既定値をそのまま使うか、変えるか

導入時によく迷うのがここでしょう。判断材料を整理します。

そのまま使ってよい場合

検証環境で試す段階なら、既定値のままで構いません。むしろ変えないほうが、標準の挙動を確認できます。

マスク記号のアスタリスクは、一般的な表記です。**--**-1234のような表示は多くの人が見慣れています。変える理由は特にありません。

変えたほうがよい場合

固定値の置換を使う場合は、既定値を見直したほうがよいかもしれません。

TEXT123という文字列が業務データに紛れると、後から見たときに何か分かりにくい。[MASKED]や*匿名化*のように、意図が伝わる値にしておくほうが親切です。

日付の1988-11-11も同様です。この日付が業務上あり得る値なら、実データと区別がつきません。ただ多くの場合、1が並ぶ日付は明らかに人工的なので、そのままでも問題は少ないでしょう。

変えるときの注意

パラメータを変更すると、その技法を使っているすべての設定に影響します。技法ごとに1組のパラメータしかないためです。

「この経路では*、別の経路では###」という使い分けは、同じ技法では成立しません。異なる記号を使いたければ、別の技法を選ぶことになります。技法とパラメータが1対1で結びついている**という制約は、設計時に意識しておく必要があります。

16件と18件のずれ

細かい話ですが、数が合わない箇所がありました。

パラメータの定義はdp_technique_parameterに18件。その既定値を持つdp_technique_parameter_valueは16件です。2件少ない。

考えられるのは、既定値を持たないパラメータが2つあるということです。実際、Selective Replaceのend_indexとexclude_charは既定値が空でした。必須でもありません。値を持たないパラメータには、値のレコードを作らない。そういう設計なら辻褄が合います。

断定はできません。別の理由による可能性も残ります。ただ、数が合わないときは必須かどうかを見ると説明がつく場面は多く、今回もそれに当てはまります。

技法とパラメータの結び付き方

dp_technique_with_paramsというテーブルが9件ありました。技法の数と同じです。

パラメータを持たない技法も含めて9件あるので、これは「技法とパラメータの組み合わせ」を表現するテーブルというより、技法ごとに1つ作られる入れ物に見えます。

パラメータ0個の技法にもレコードがあるということは、後からパラメータを追加できる余地を残しているのでしょう。いまは設定不要でも、将来オプションが増える可能性があります。そのときテーブル構造を変えずに済みます。

これも推測です。ただ、空のレコードが並んでいるときは拡張のための余地であることが多いという見方はできます。

数を数えると設計が見える

今回やったのは、テーブルを4つ開いて件数と中身を並べただけです。それでも分かったことがあります。

技法は9つあるが、設定できるのは5つ。非推奨のものが最も多くのパラメータを持ち、それが2つに分割された経緯が読める。既定値には人工的な日付が選ばれていて、マスクされた値だと分かる配慮がある。

公式ドキュメントには「パラメータがあります」としか書かれていない部分が、実機を見ると具体的な値まで分かります。設計を検討する段階では、この具体性が効きます。

「マスク記号は何が使えますか」と聞かれたとき、「アスタリスクが既定です。変更できます」と答えられる。この差は小さくありません。

実機を見て気づいたこと

いちばん印象に残ったのは、既定値がここまで具体的に決まっていることでした。

匿名化の設定というと、自分で全部決めるものだと思っていました。実際には、マスク記号も置換先の値も最初から入っています。設定画面を開いて、必要なところだけ変えれば動く状態です。

これは導入のハードルを下げる作りです。「何を入れればいいか分からない」で止まらずに済みます。

もうひとつは、設定不要の技法が4つもあることです。9つのうち4つはパラメータを持ちません。

一見すると機能が少ないように見えますが、逆でしょう。Data Pattern AnonymizationやSynthetic Data Anonymizationは、内部で複雑な処理をしているはずです。それを利用者に設定させず、内部で完結させている。設定項目が無いことは、機能が単純なことを意味しないという例です。

そして日付の既定値1988-11-11。これを見たとき、設計した人の意図が透けて見えた気がしました。ランダムな日付ではなく、明らかに人工的な値を選んでいます。マスクされた値だと分かるようにする配慮です。実際の運用で、この日付を見たら「あ、これは隠された値だ」とすぐ気づけます。

実務では何に使えるか

設定を決めるときの手順として、次の順で考えると整理しやすいはずです。

手順1：残したい部分があるかを決める

全部隠していいならRemoveが最も簡単です。設定項目がありません。

一部を残したいなら、Selective Replace系を選びます。末尾4桁を残すのか、先頭を残すのか。ここが決まれば技法が決まります。

手順2：形式チェックが要るかを考える

隠した後の値が、後続の処理で検証される可能性はないでしょうか。

桁数チェックがあるなら、Random Replaceで長さを保つか、Selective Replaceで一部だけ置き換えるのが安全です。Removeで空にすると、必須チェックに引っかかる場面があります。

手順3：既定値のままでよいかを確認する

マスク記号がアスタリスクでよいか。置換先の文字列がTEXT123でよいか。

多くの場合、既定値のままで問題ありません。ただし自社の帳票やログにTEXT123が並ぶのが許容できるかは確認しておいたほうがよいでしょう。監査で説明を求められる可能性があります。

手順4：AIの回答品質を確かめる

ここが肝心です。隠しすぎると、生成AIが文脈を失います。

Removeで消してしまうと、AIは「何かがあった」ことすら分かりません。Selective Replaceで一部を残せば、形式は伝わります。Synthetic Data Anonymizationなら、それらしいダミー値が入るので文脈が保たれます。

保護の強さと回答品質は逆方向に働きます。パターンごとに技法を変えるという設計が現実的でしょう。

テーブル名から読み取れる設計

4つのテーブル名を並べると、役割分担が見えてきます。

dp_techniqueが技法そのもの。dp_technique_parameterが「その技法が受け取れる設定項目の定義」。dp_technique_parameter_valueが「実際に入っている値」。そしてdp_technique_with_paramsが両者を結ぶ関係です。

定義と値を分ける構造は、ServiceNowの他の設定機構にもよく出てきます。項目の定義がプラットフォーム側、値が利用者側という切り分けです。アップグレードで定義が増えても、入れた値は保持されます。

この形が分かっていると、どこを触ってよいかが判断できます。 dp_technique_parameterはプラットフォームの定義なので基本は触りません。触るのは値の側です。

名前にwith_paramsと付くテーブルがあること自体も情報です。9件の技法すべてに行があり、パラメータを持たない技法にも行が用意されています。関係テーブルとしては、有無にかかわらず全技法を並べておく作りです。件数が9で揃うのは偶然ではありません。

パラメータを持たない4技法の意味

パラメータが0個の技法が4つあります。Remove、No Action、Data Pattern Anonymization、Synthetic Data Anonymizationです。設定項目が無いということは、動作が固定されているという意味になります。

Removeは値を消すだけなので、調整する余地がありません。No Actionは何もしない技法です。この2つは分かりやすい。

問題は残る2つです。Data Pattern AnonymizationとSynthetic Data Anonymizationにパラメータが無いのは、設定が別の場所にあると読むのが自然です。パターン定義や生成ルールをdp_technique_parameterに持たせるのは無理があります。値の形が1つに決まらないからです。

つまりパラメータテーブルは「単純な置換系の設定置き場」であって、匿名化の設定全体を集約する場所ではありません。ここを勘違いすると、設定画面を探す場所を間違えます。

既定値を変えるべき場面

18件のパラメータには既定値が入っています。そのまま使えるものと、環境に合わせて見直したほうがよいものがあります。

そのまま使えるもの

masking_symbolのアスタリスクは、変える理由がほとんどありません。マスクの記号として一般的で、見た目で「隠されている」と分かります。

preserve_data_lengthのtrueも、既定のままが無難です。桁数が変わると後続処理が壊れる場合があるためです。

見直したほうがよいもの

number_of_characters_to_maskの5は、対象データの桁数次第で意味が変わります。8桁の値なら5文字隠せば十分ですが、20桁の値では大半が見えたままです。逆に4桁の値では全部隠れます。

string_valueのTEXT123も、置換後の値として業務的な意味を持ちません。テストデータとしては分かりやすいものの、実運用では自組織の規約に合わせた値にしたほうが、ログを見たときに判別しやすくなります。

日付の1988-11-11は、明らかに架空と分かる値という点で優秀です。ただし将来日付が必要な処理に流れると、過去日付では矛盾が出ます。用途を確認してから決めます。

検証環境で試すときの進め方

実際に動かすなら、順序を決めておくと安全です。設定を変えると元に戻すのが手間になる場面があります。

最初は No Action で試す

いきなり値を隠さず、No Actionから始めます。検出だけ動かして、何が引っかかるかを確認する段階です。

この時点で、想定外のフィールドが検出されていないか、逆に検出してほしいものが漏れていないかが分かります。値は変わらないので、業務への影響もありません。

次に Selective Replace を試す

検出対象が固まったら、部分的に隠す技法を試します。既定値のままなら、先頭5文字がアスタリスクになります。

ここで確認したいのは、隠した後の値が後続の処理を通るかです。桁数チェックや形式チェックに引っかからないか。引っかかるなら、preserve_data_lengthを持つ技法に切り替える判断が要ります。

最後に本命の技法を選ぶ

用途に応じてStatic ReplaceやSynthetic Data Anonymizationに切り替えます。この段階では、AIの回答品質を見ながら調整することになります。

3段階を踏むと、どこで問題が起きたかが切り分けられます。 いきなり最終形を入れると、検出の問題なのか技法の問題なのか判断できません。

設定を記録しておく

パラメータを既定値から変えた場合、その記録を残しておくことをおすすめします。

理由は2つあります。ひとつは、次のリリースで既定値が変わる可能性があること。変更した箇所を把握していないと、差分が追えません。

もうひとつは監査です。「なぜこの値にしたのか」を後から説明できる必要があります。マスク記号を変えた、置換先の文字列を変えた。それぞれに理由があるはずです。

記録の置き場所は、Update Set でも設計書でも構いません。変更した事実と理由が対で残っていることが大事です。

値を持つレコードは16件でした。パラメータの定義18件に対して2件少ないのは、値が設定されていないものがあるためです。

この機能の全体像

今回はパラメータに絞って見ました。仕組み全体は別の記事にまとめています。

どの経路に適用するか、何を個人情報とみなすか、という2つの軸についてはAIに個人情報を渡さない設定はどこにある？をご覧ください。標準で32種類の検出パターンが用意されていることや、経路ごとに管理者ロールが分かれていることを扱っています。

この機能はZurichには存在しませんでした。新旧の差分はZurichとAustraliaを並べて数えたらにまとめてあります。

権限の設計という観点ではServiceNowで権限はどこで決まる？が前提になります。誰が匿名化の設定を触れるかは、ロールで決まるためです。

パラメータ名で分けると、同じ名前が複数の技法で使われているのが分かります。共通の設定項目は名前を揃えてある作りです。

用語

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

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

• マスク：値の一部または全部を別の文字で覆い隠すこと

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

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

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

• /dp_technique_parameter_list.do … パラメータの一覧

• /dp_technique_parameter_list.do?sysparm_query=GROUPBYtechnique … 技法ごとの件数

• /dp_technique_parameter_value_list.do … 既定値の保持先

• /dp_technique_list.do … 技法そのもの

• /dp_technique_with_params_list.do … 技法とパラメータの組み合わせ

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINdp_technique_parameter,dp_technique^hintISNOTEMPTY

関連記事

• ServiceNowでAIに個人情報を渡さない設定はどこにある？ Data Privacyの32パターンを実機で読む — 機能全体の構造はこちらで扱っています。

• ZurichとAustraliaを並べて数えたら何が変わっていたか — この機能が追加された経緯が分かります。

• ServiceNowで権限はどこで決まる？ 7つの層を実機でたどる完全ガイド — 設定を誰に任せるかを考えるときの前提です。

検証環境と未検証範囲

• 確認した範囲：Australia PDI（OOTB）におけるdp_technique9件、dp_technique_parameter18件の技法別内訳と既定値、dp_technique_parameter_value16件、dp_technique_with_params9件の件数。および Data Pattern の Test 機能による検出判定（Emailパターン／一致・不一致の各1回）。すべて読み取りとテスト実行のみで、設定の変更は行っていません。

• 確認していない範囲（断定しません）：技法を適用したあとの文字列そのもの（検出の判定までは確認しましたが、伏せ字に置き換わった結果は取得していません）、dp_technique_parameter_valueの16件がパラメータ18個と2個ずれている理由、start_masking_fromの選択肢、非推奨の技法を選んだときに警告が出るか、型が一致しない値を設定した場合の挙動。これらは別途の検証が必要です。

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