[第11回] 隠された電話番号が必要なとき — QueryPieのマスキング解除申請と承認
2026年11月8日
以前の実習では注文を確認しながら連絡先を隠せた。ただ、配送問い合わせ担当は顧客へ連絡する場面もある。その都度マスキング全体の変更を管理者に依頼する必要があるのだろうか。
今回はQueryPieの マスキング解除申請(Unmasking Request)を使った。開発者が列・期間・理由を記載して申請し、承認後にDBeaverで再参照した。電話は原文で見え、メールは引き続き隠れていた。
前回までの架空注文と連絡先を使った。画面の名前・電話・メールはすべてテストデータだ。
1. 配送問い合わせに必要な電話番号だけを申請する
開発者がDBeaverで4002番の連絡先を参照すると、状態と名前は見えたが電話は 010-****-1002と表示され、メールもマスキングされていた。

今回は配送問い合わせのための電話確認なので、customer_contactsの phone列一つだけを解除対象にした。メールを見る必要はなかった。
2. 承認担当を先に決める
Approval RulesでOrders Lab - Contact Unmasking Approvalを作り、Unmasking Requestを指定した。
Demo Approverを指定した。開発者と承認者を分けることで、本人の必要判断だけで解除せず、担当者の確認を経る構成にできた。

3. 必要列と利用時間を記載して申請する
開発者のWorkflow → Unmasking Requestで「注文4002の配送問い合わせのための電話確認」と入力し、Orders Control Lab、orders_control、customer_contacts、phoneを選んだ。
11月8日16時から24時間とし、配送問い合わせに電話の原文が必要で、メールの保護は維持すると記載した。

列単位で選ぶため、何をなぜいつまで使うかが具体的に残る。今回の承認範囲はphone列であり、4002番は業務理由と検索条件として使った。

4. 承認者が内容を確認して処理する
Demo ApproverのReceived Requests → To Doに届いた。タイトル、申請者、列、期間、理由を一つの申請で確認できた。

電話確認の承認と利用期間をコメントして承認した。Doneに移り、状態は Approvedに変わった。

後から原文を見られた理由を確認する際、口頭のやり取りをたどらず申請を調べられるのは便利だ。
5. 再参照すると電話番号だけが見えた
承認後、開発者のDBeaverで同じSQLを再実行すると、電話は 010-0000-1002と原文になったが、メールは隠れたままだった。

必要な電話を確認しつつメール保護を維持できた点がよかった。開発者はDBeaverを使い続け、管理者が共通ポリシー全体を解除する必要もなかった。
6. 個人情報が必要な業務にも承認手順を付けられる
マスキングで露出を減らし、業務上原文が必要な場合は解除申請で同じ製品内で対応できた。
実際に試すと、 必要列を選び、理由と期間を記載し、担当者が承認するという流れが明確だった。利用者は何を申請すべきか、承認者はどの情報を許可するかが分かる。
電話番号一つの必要性から始めたが、QueryPieは隠すだけでなく、必要な人へ必要な情報を承認する業務手順も提供すると分かった。
![[第10回] 「必要な列だけを参照してください」— QueryPie Query RulesでSQL利用ルールを適用する](/assets/content/acp-lab-notes/query-rules/01.webp)
![[第12回] DB資料も承認を受けてエクスポートする — QueryPie SQL Export実習](/assets/content/acp-lab-notes/sql-export/01.webp)