こんにちは。CData Software Japan リードエンジニアの杉本です。

CData Connect AI に Data Security という機能が追加され、AI とデータソースの間でやり取りされるデータから機密データを検知して、警告・マスキング・ブロックといった制御をかけられるようになりました！

検知の対象は、PII（Personally Identifiable Information：個人を特定できる情報）だけではありません。クレジットカード番号のようなカード情報や、医療・金融に関わる情報も対象に含まれます。

https://docs.cloud.cdata.com/ja/Data-Security

生成AI に社内データをつなぐとき、「このデータ、AI に見せて大丈夫だったかな」という不安はどうしてもついて回ります。というわけで今回は、この Data Security 機能の使い方と、日本の電話番号を検知するカスタムルールの作り方を紹介したいと思います。

なお、本機能は執筆時点（2026年8月）では早期アクセス（Early Access）での提供となっています。利用をご希望の場合はCData の問い合わせフォームまでお問い合わせください。

これまでの課題

Connect AI にはこれまでも、RBAC によるアクセス制御、コネクション単位での操作スコープの設定、クエリログによる監査といったガバナンス機能が備わっていました。ただ、これらはいずれも「どのテーブルに、誰が、どの操作でアクセスできるか」という粒度の制御です。

一方で実際に悩ましいのは、「テーブルへのアクセス自体は許可したいけれど、特定のカラムに入っている個人情報は AI に渡したくない」というケースではないでしょうか。MCP 経由で AI にデータソースをつなぐと、AI がどんなクエリを組み立てるかを事前に読み切ることはできません。テーブル単位の許可だけでは、メールアドレスや生年月日がそのまま LLM のコンテキストに流れ込んでしまいます。

Data Security は、この「データの中身」に対する制御を担当する機能です。

Data Security でできるようになったこと

Data Security は、Connect AI を通過するデータをパターンマッチで検査して、機密データを検知したときのアクションを定義する機能です。

Date of Birth（生年月日）や Email Address（メールアドレス）、クレジットカード番号といったルールが標準で用意されており、それぞれに規制タグとリージョンタグが付いています。

規制タグは CCPA/CPRA、HIPAA、GLBA、PCI DSS などに対応しており、リージョンタグは Global や US といった適用地域を示します。画面上部の Regulation Type や Region で絞り込めるので、自社が対応すべき規制から必要なルールを探せる作りになっています。

各ルールには Inbound Rule と Outbound Rule という2つのアクション設定と、有効・無効を切り替える Status トグルがあります。

Inbound / Outbound とアクションの考え方

ここが Data Security を使ううえで一番のポイントです。

Inbound と Outbound はどちらの方向か

Inbound と Outbound は、Connect AI を基準としたリクエストとレスポンスの方向を指します。ドキュメントでは以下のように定義されています。

つまり Outbound は「AI に機密データを見せない」ための設定、Inbound は「AI から機密データを送らせない」ための設定ということになります。

ここで注意したいのが、Inbound の対象は書き込みだけではないという点です。定義が「クエリやリクエストの内容」となっているとおり、読み取り専用の SELECT であっても、WHERE 句に機密データが含まれていれば検査の対象になります。この挙動は後ほど実際に確認します。

4つのアクション

Inbound / Outbound それぞれに、以下の4つから動作を選べます。

Redact で置き換わる値は、対象のデータ型によって変わります。

方向とアクションを組み合わせると、実際の挙動は以下のようになります。次の章で実際に動かして確認していきます。

Outbound の Redact は AI に返る値だけがマスクされ、元データには影響しません。一方 Inbound の Redact は挙動が大きく異なりますので、後半の注意点で改めて触れます。

ちなみにLog では、以下のように記録されていきます。Warn の場合は、挙動は変わらず、このLog のみが残る形となります。

まずは標準ルールを動かしてみる

いきなりカスタムルールを作る前に、標準で用意されている Email Address ルールを使って、実際の挙動を確認してみましょう。ここでは Salesforce の Contact を例にします。

まず「Data Security」に移動し「＋ Add Rule」をクリックします。

Rule はプリセットとカスタムが選べるようになっているので、今回は「Preset Categories」を選択します。

プリセットは各種法律「CCPA/CPRA」「GLBA」「HIPAA」「PCI DSS」に関連するものから選ぶか、それともプリセットそれぞれから選ぶかを決めることができます。

よくわからない場合は「I don't know my type - show me all」をクリックすれば、すべてのプリセットが見れるので、そこから選んでもOKです。

Email Address ルールを有効にする

Entities の一覧から Email Address の行を探します。

対象を選択して「Confirm」をクリックします。

右端の Status トグルを Enabled にして、Inbound Rule と Outbound Rule のドロップダウンからそれぞれのアクションを選びます。

まずは読み取り側の動きだけを見たいので、以下の設定にします。

設定を変えたら、画面右上の Save Changes をクリックするのを忘れないようにしてください。ここを押さないと反映されません。

読み取り結果がマスクされることを確認する

それでは Explorer から、メールアドレスを含むテーブルにクエリを投げてみましょう。カタログ名は適宜自社の環境に合わせて調整してみてください。

SELECT [Id], [Name], [Email] FROM [Demo_Salesforce].[Salesforce].[Contact] LIMIT 5

ルールを有効にする前は当然そのままの値が返ってきますが、Outbound Rule に Redact を設定した状態では、Email カラムの値が XXXX に置き換わって返ってきます。

このとき Salesforce 側の実データは何も変わっていません。あくまで Connect AI から返る値だけがマスクされています。

もちろん、MCP 経由で Claude などから同じテーブルを参照した場合も同様に XXXX が返るので、LLM のコンテキストにメールアドレスが入り込むことを防げます。AI にはメールアドレスの存在は伝わりますが、中身は渡らないという状態ですね。

Claude で実行した時の様子は以下のものになります。

ちなみに、今回はEmail というカラムの結果だけを見ていますが、例えばDescription や打ち合わせメモなどに入っているメールアドレスなども対象になります。

書き込みをブロックしてみる

次は書き込み側です。Inbound Rule を Block に変更して、もう一度 Save Changes をクリックします。

この状態でメールアドレスを含む INSERT を実行してみます。

INSERT INTO [Demo_Salesforce].[Salesforce].[Contact] (LastName, Email) VALUES ('テスト', '[email protected]')

すると書き込みはエラーになり、レコードは作成されません。

念のため Salesforce 側を確認してみると、レコードが増えていないことがわかります。AI エージェントに書き込み権限を渡しつつ、個人情報だけは書き込ませない、という制御ができるわけですね。

検索条件に含まれる値もブロックされる

ここが Inbound を扱ううえで一番の注意点です。Inbound Rule を Block にしたまま、今度は読み取りのクエリを実行してみます。

SELECT [Id] FROM [Demo_Salesforce].[Salesforce].[Contact] WHERE [Email] = '[email protected]'

これは SELECT なので Outbound だけが効きそうに見えますが、実際には以下のエラーが返ってきて実行できません。

Request blocked: PII detected in inbound query

エラーメッセージにも inbound query と出ているとおり、WHERE 句に書いたメールアドレスが Inbound の検査に引っかかっています。

AI エージェントの利用シーンを考えると、これは影響の大きい挙動です。「[email protected] さんの担当案件を調べて」といった依頼はごく普通に発生しますが、Inbound を Block にしているとこの手のクエリがすべて失敗します。Inbound の設定は、書き込みだけでなく検索操作への影響もあわせて検討する必要があります。

Inbound を Redact にすると何が起きるか

ここで、Inbound Rule を Block ではなく Redact にして同じ INSERT を実行すると、挙動が大きく変わります。

書き込み自体は PII のエラーにはなりませんが、メールアドレスが XXXX という値で入力されようとするため、Salesforce 側のフォーマットバリデーションに引っかかってエラーになります。

逆に言えば、バリデーションのない項目──たとえば Description のような自由記述欄であれば、マスクされた値がそのまま登録されてしまいます。

Outbound の Redact が「見せる値だけを隠す」のに対し、Inbound の Redact は「書き込む値そのものを置き換える」動作になります。同じ Redact という名前でも結果がまったく異なるので、設定時にはご注意ください。

標準ルールの守備範囲

このように標準ルールだけでも、メールアドレスや生年月日といった代表的な個人情報については、設定を数回クリックするだけで制御をかけられます。

ただし標準ルールは海外の規制を前提としたものが中心なので、日本のデータ形式に合わせた検知をしたい場合は、次に紹介するカスタムルールを使うことになります。

カスタムルールで日本の電話番号を検知する

標準ルールの Email Address は国際的に形式が共通なので問題ありませんが、電話番号は国ごとに形式が違います。日本の電話番号を確実に捉えたい場合は、カスタムルールを作ることになります。

Add Rule の設定項目

一覧画面の右上にある Add ボタンから「Custom Rule」を追加します。

以下の項目を利用しながら、カスタムルールを設定することができます。

Score と Context Keywords は組み合わせて機能します。ドキュメントによると、両者の関係は 0.8 を境に切り替わります。

つまり Score は「この正規表現だけでどこまで断定してよいか」を表す値ということですね。パターン単体で確信が持てるなら 0.8 以上、周辺の文脈で裏を取りたいなら 0.8 未満、という使い分けになります。

なお、スコアを設定した場合は Context Keywords が必須になります。

電話番号検知ルールの設計

日本の電話番号には、固定電話・携帯電話・IP電話・フリーダイヤルなど複数の形式があります。共通しているのは「0 で始まる10〜11桁の数字」という点です。

ここで悩ましいのが、ハイフンありとハイフンなしで検知の確実性がまったく違うことです。03-1234-5678 のようにハイフンで区切られていれば電話番号だと断定できますが、0312345678 という数字の並びだけでは、伝票番号や管理番号と区別がつきません。

そこで、先ほどの Score の仕組みを利用して、2本立てのルールにします。

まずは、ハイフン区切りの形式を拾う高精度ルールです。

\b0\d{1,4}[-‐−－]\d{1,4}[-‐−－]\d{3,4}\b

市外局番が2桁の 03-1234-5678 から5桁の 09802-1-2345 まで、また 090-1234-5678（携帯）や 0120-123-456（フリーダイヤル）も、この1本でカバーできます。ハイフンが2つ含まれている時点で電話番号である可能性がかなり高いので、Score は 0.8 以上にしてパターン一致だけで検知させています。

次に、ハイフンなしで数字が連続しているケースを拾う緩いルールです。

\b0\d{9,10}\b

こちらは 0 始まりの10〜11桁というだけの緩いパターンなので、Score を 0.8 未満にしています。これにより、TEL や 連絡先 といった語が近くにある場合だけ検知される動作になります。CSV の取り込みデータのように、ラベルが近くにない状態で数字だけが並んでいる場合は反応しません。

前後の \b は、より長い数字列の一部を誤って切り出さないための境界指定です。これがないと 0312345678901 のような13桁の連番から、先頭10桁だけを電話番号として切り出してしまいます。

動作確認

ルールを保存したら、Explorer などから電話番号を含むテーブルにクエリを流してみましょう。Outbound を Redact にしていれば、電話番号のカラムが XXXX に置き換わって返ってきます。

例えばkintone の担当者管理で、以下の1レコード目がCData Software Japan の電話番号になっていますが

下記のようにマスキングされていることがわかります。さらに、ダミーデータでxxxx という文字列が含まれているものは正規表現に一致していないため、マスキングされていない（XXXXになっていない）ことがわかります。

制約・注意点

なお、本文でも触れていますが、改めて以下の点についてはご注意ください。

Inbound の Block は、正当な検索クエリも止めます。 記事の中ほどで確認したとおり、Inbound の検査対象には SELECT の WHERE 句に指定した値も含まれます。「特定のメールアドレスの顧客を探す」といった日常的な操作ができなくなるため、書き込みを止めるつもりで設定すると想定外の影響が出ます。適用前に、その項目を検索条件に使う業務がないかを確認してください。

Inbound の Redact は、連携先の実データを書き換えます。 Outbound の Redact が「AI に見せる値だけをマスクする」のに対し、Inbound の Redact は置換後の値がそのまま連携先に書き込まれます。しかもデータソース側のバリデーションで許容される場合、書き込み自体は成功扱いになることもあるため、エラーにも気づけません。誤検知したまま運用すると、SaaS 側にマスク値が量産されてしまいます。テキストなら XXXX ですが、数値カラムなら 0、日付カラムなら 1900-01-01 に化けるので、元の値との区別がつきにくい点も厄介です。

さらに、WHERE 句の値が Redact された場合は検索条件そのものが置き換わります。エラーにはならず「該当0件」という結果が返るため、AI 側は「そんなデータは存在しない」と解釈してしまいます。誤った回答が返るという意味では、Block よりも危険な設定になり得ます。

そのため Inbound はまず Warn から始めることをおすすめします。 Logs でどんなクエリが引っかかるかを観察し、業務影響を把握したうえで Block に上げるのが安全です。上の電話番号ルールで両方とも Inbound を Warn にしているのもこの理由からです。電話番号は問い合わせ対応で検索条件に使う代表的な項目なので、Block にすると業務影響が大きくなります。

おわりに

このように Data Security を使うことで、テーブル単位のアクセス制御では届かなかった「データの中身」のレベルで、AI とのやり取りを制御できるようになります。

運用を始めるときは、まずは全ルールを Warn にして Logs でヒット状況を観察し、影響範囲を把握してから Redact や Block に昇格させる、という段階的な進め方がおすすめです。今回見てきたとおり、Inbound は書き込みだけでなく検索条件にも効くため、いきなり Block を設定すると正当な業務クエリまで止まってしまいます。

どの方向にどのアクションを割り当てるかは、守りたいものによって変わります。「AI に見せたくない」だけであれば Outbound を Redact にするのが最も副作用が少なく、「AI に触らせたくない」まで踏み込むなら Inbound の設定を検討する、という順序で考えるとよいと思います。

ぜひトライアルで色々と試してみてください。

なにかわからないことがあれば、お気軽にサポートやお問い合わせからどうぞ。

https://jp.cdata.com/contact/