データベースを扱うチームなら、いずれ同じ問題に直面することになります。テストには実際のデータが一番役立ちますが、本番環境のデータをそのまま開発やテストに利用するのは、コンプライアンス上大きなリスクがあります。GDPR、HIPAA、PCI-DSSなどの規制では、「テストのためだった」という理由は通用しません。開発者のノートPCや本番公開前のテスト用サーバーから、実際の顧客の名前、メールアドレス、決済情報などが漏れれば、データ侵害につながります。Navicat 18では、この問題に正面から対応するため、新機能としてData Masking（データマスキング）が追加されました。機密性の高い本番データを、安全で現実的なテスト用データに変換できるため、開発チーム、テストチーム、品質保証（QA）チームもリスクを抑えて作業できます。
データの削除や架空データへの置き換えより、マスキングが優れている理由
機密性の高いカラムを完全に削除したり、test1、test2、 xxxxxのような明らかに架空のデータに置き換えたりすると、テストしようとしている処理がうまく機能しなくなることがあります。現実的なデータ形式、一意性制約、参照整合性などに依存するクエリは、不自然なデータを使用すると異なる動作をする可能性があるためです。マスキングなら、実際の人物を特定できる情報を取り除きながら、データの構造や使いやすさを維持できます。
Navicat 18では、業界で標準的に使われている5種類のマスキング手法に対応しています。
- Substitution（置換）：実際の値を、現実にありそうな架空の値に置き換えます。（例えば、実際の名前を、別のもっともらしい名前に置き換えることができます。）
- Variance（変動）：数値や日付の値をランダムにずらし、正確な数値を隠しながら、データ全体の傾向を維持します。
- Shuffling（シャッフル）：同じカラム内の値をランダムに並べ替えます。実際の値を維持しながら、それぞれの値が本来の行と結び付かないようにします。
- Hashing（ハッシュ化）：値を、元の値とは似ていない、復元できない固定長の文字列に変換します。元のデータを隠しながら、値の一貫性を維持したい場合に便利です（同じ入力値には常に同じハッシュ値が生成されます）。
- Nulling（NULL化）：フィールド全体を空欄にします。本番環境以外では使用する必要がないデータに適しています。
どのマスキング手法を使うかは、テストで何を確認したいかによって変わります。例えば、あとで別のデータと結び付けたり、同じ値かどうか照合したりする必要がある値にはHashingが適している一方、置換は、品質保証（QA）担当者がデータを目で確認する場合にも分かりやすいというメリットがあります。
Navicat 18でのデータマスキング：簡単な操作手順
データマスキング機能はEnterprise版とStandard版で利用でき、MySQL、Oracle、PostgreSQL、SQLite、SQL Server、MariaDB、MongoDB、Snowflakeの各データベースに対応しています。ここでは、実際の顧客データの複数のカラムを、安全で現実的なテスト用データに変換する方法を紹介します。
- メイン画面のツールバーから、［ツール -> データマスキング］を選択します。
- データマスキングウィザードが起動します。ウィザードの案内に従って、マスキングの処理を進めます。
最初の画面では、マスキングの適用方法として、マスキングしたデータを別のデータベースに転送する方法（デフォルト）と、既存のテーブルを直接マスキングする方法を選択できます。ここでは、デフォルトの設定を使用します。
- 次に、データの転送元と転送先のデータベースを選択します。前の画面でマスキングしたデータを別のデータベースに転送する方法を選択したため、転送先のデータベースを選択するか、SQLをファイルに出力するかを選択できます。ここでは、SQLをファイルに出力する方法を選び、ファイル名を「customer_test」とします。複数のデータベースで同じテスト用データを使用したい場合に便利です。
- 次の画面では、マスキングするテーブルと行を選択できます。ここではcustomerテーブルを選択します。なお、MongoDBを除くすべてのデータベースでは、データマスキングを実行するために、テーブルに主キーが設定されている必要があります。転送モードには、「自動」と「詳細」の2つのモードがあります。「自動」ではすべての行がマスキングされ、フィールド名はそのまま維持されます。一方、「詳細」では、転送先のテーブル名やフィールド名、処理する行を自由に指定できます。ここでは、ほかの設定はそのままにして、処理対象となるレコードだけを変更します。今回は、最初の10件のcustomer_idを処理対象にします。設定方法は次のとおりです。
- 「カスタムレコードセット」を選択します。これにより、レコードセットリストの新しい空の行にカーソルが移動します。
- テキストボックス右側の［…］ボタンをクリックすると、［フィルター］ダイアログが表示されます。
- ［＋］をクリックして、新しい条件を追加します。ビジュアルクエリビルダ
- ［SQLプレビュー］ボタンをクリックすると、生成されたSQLを確認できます。
これが設定完了後の［データベースオブジェクト］画面です。
続いて、マスキング対象のフィールドを選択します。ここでは、store_id、last_name、email、create_dateを選択します。
- 次の画面では、各フィールドに適用するマスキング方法をNavicatに指定します。それぞれ順番に見ていきましょう。
store_idカラム
store_idは数値フィールドなので、さまざまなマスキング方法を選択できます。ここでは、データマスキング手法に「Shuffling（シャッフル）」を選択します。これにより、各行に有効なIDを割り当てたまま、IDの順番を入れ替えることができます。
画面下部で、処理結果を確認できます。
last_nameカラム
ast_nameフィールドには、データマスキング手法として「Substitution（置換）」を使用します。分類には、汎用的なものからより専門的なものまで、さまざまな種類があります。今回の用途には「名前」が最適です。
また、元の値の一部を残して、それ以外をマスキングすることも、ダミーの値に置き換えることもできます。ここでは前者を選択し、姓の最初の1文字だけを残して、それ以外の文字をアスタリスク（*）でマスキングします。
emailカラム
メールアドレスには専用の分類が用意されており、ユーザー名部分とドメイン部分にそれぞれ異なるマスキングを適用できます。ドメイン名については、候補となるドメインのリストが用意されており、その内容をカスタマイズすることもできます。
create_dateカラム
日付や時刻のデータには、さまざまなマスキング方法があります。例えば、DateTime（日付と時刻）をDate（日付のみ）に変換したり、値を変更したり、現実的なダミーの値に置き換えたりできます。
- ［概要］では、処理を開始する前に、マスキングの設定内容を最後に確認できます。
- Navicatでは、実行している処理の内容を詳しく確認できます。
- ダイアログを閉じた後、［ファイル］→［ファイルを開く］→［クエリ...］を選択すると、Navicatで出力ファイルを開いて確認できます。
一連の処理はすべてNavicat内で完結するため、別のツールやスクリプトにデータをエクスポートする必要はありません。普段作業しているNavicat上で、データベース全体を数分でマスキングできます。
まとめ
データマスキングは、コンプライアンス要件への対応と、現実的なテスト用データの必要性という相反する課題を抱えるチームのニーズに応える機能です。Navicat 18の幅広いAI機能と組み合わせることで、これまで手作業で行っていたミスの起こりやすい作業を、わずか数クリックで実行できるようになります。開発環境やテスト環境で規制対象のデータを扱っているチームなら、アップグレードしたらぜひ試してみる価値のある機能です。
