Power Platform｜本番データを開発環境へ——「氏名マスク済み」で安全と言い切れるか

氏名をアスタリスクに置き換えた。日付も丸めた。それで「マスク完了」として開発環境にデータを流している——この判断に、識別子レベルの穴が開いていることがある。
個人情報保護法が「匿名加工情報」に求める要件は、「特定の個人を識別できず、かつ復元不可能」（第2条第6項・2017年5月30日施行）だ。支社コードや担当者コードが残った状態では、その要件を満たさない。
結論から言う。境界線は「氏名を消したか」ではなく、「識別子レベルで設計されているか」に引かれる。

判断軸の核心：「誰であるか」より「どのコードか」

氏名・住所・生年月日は、誰もがマスク対象だとわかる。見えている。
問題は見えていない識別子だ。支社コード、担当者コード、部門コード、顧客番号——これらは「個人名ではない」という認識から、マスク対象として見逃されやすい。

経済産業省の「匿名加工情報作成マニュアル」（Ver1.0・2016年8月）は、k-匿名性（k≧2）という技術基準を示している。k-匿名性とは、あるレコードが少なくとも k 個の他のレコードと区別できない状態を指す技術要件だ。支社コードが「BR-07（東京第7支社）」のように実コードのまま残れば、社員名簿と突き合わせるだけで個人が絞り込める。これが間接識別子の再識別リスク（経産省技術基準（2016年）では k-匿名性として定式化されており、業界では「モザイク効果」とも通称される）だ。

識別子の設計こそが、安全な境界線の実体だ。

判断が割れるケース：「社内データだから大丈夫」

開発環境への本番データ持ち込みが曖昧になりやすいのは、次のようなシナリオだ。

ケース1：社内申請システムの開発
Power Apps で社内の経費申請システムを開発する。テストデータに実際の社員情報を使えば動作確認が楽だ。「社内限定だし」という判断が走る。しかし開発環境は、本番環境と比べてアクセス制御が甘い。Microsoft の ALM（Application Lifecycle Management：アプリのライフサイクル管理）原則は、「環境はセキュリティ境界として機能する」（Environments act as security boundaries）と明示している。開発環境は本番環境と同等のセキュリティを持たない前提で設計されている。

ケース2：外部委託プロジェクトでの引き継ぎ
委託先に動作確認してもらう必要があり、「実データに近いものを渡す」判断をする。この時点で、担当者コードや顧客コードが混入していると、法人の営業秘密に該当し得る情報が外部に渡る構造が生じる。不正競争防止法上の論点が発生しうるが、コード類が「営業秘密」に当たるかは個別判断であり、法的断定はできない。ただし、リスクが生じうる構造であることは確かだ。

ケース3：Power Automate フローのテスト
接続先エンドポイントが開発と本番で切り替わっていない状態で実コードを流すと、本番環境への誤通信・誤通知が発生しうる。Microsoft の ALM basics ドキュメントは「Solutions don’t contain any business data.」と明示している。この設計思想は、開発ソリューションにビジネスデータを持ち込まない前提を前提としており、識別子が実コードのまま残った状態でのフロー実行はその前提を崩す。

設計時に詰める識別子チェックリスト

開発環境へデータを持ち込む前に、以下を確認する。

このチェックを通過したデータが、法令上の「仮名加工情報」（第2条第5項・2022年4月施行）の要件に近づく。仮名加工情報は、他の情報と照合しない限り特定の個人を識別できない状態に変換したデータであり、開発・テスト用途への活用可能性が認められている（PPC「ガイドライン（仮名加工情報・匿名加工情報編）」）。マスクの目的地として、この要件を基準に設計するのが合理的だ。

対策 A：コード類のハッシュ化・連番化

支社コード「BR-07」を「BR-001」のような連番に置き換える。担当者コード「EMP-12345」は、ハッシュ関数を通した文字列か、連番の仮コードに変換する。

重要なのは、変換ルールの台帳を開発環境とは別管理にすることだ。変換台帳が開発環境に置かれると、復元が可能になり、匿名加工情報・仮名加工情報の要件を満たさなくなる。

Power Platform / Dataverse 固有のハッシュ化・連番化の実装手順は、2026年時点では Microsoft 公式ドキュメントで直接提供されていない。実務での観察では、Power Query の変換ステップか、Python スクリプト等の前処理ツールで変換してから Dataverse にインポートするパターンが確認されている。詳細は続編（「Dataverse 投入前の落とし穴」）で扱う予定だ。

対策 B：マスターデータのダミー化

支社コードや顧客コードは、マスターテーブル（親テーブル）を持つ。そのマスターテーブルごとダミーデータに差し替えると、子テーブル側のコードが実コードとして残っていても、照合先がなくなる。

Microsoft の ALM 原則（「Solutions don’t contain any business data.」）は、開発ソリューションがビジネスデータを持ち込まない設計を前提としている。B の対策は、この設計思想と整合する。

個人 PC 環境での検証設計

M365 Developer Tenant を個人 PC に構築してある場合、上記の対策 A / B を本番環境に影響なく試せる。
→ 関連記事：社内の申請業務を「失敗しないように」デジタル化する

まとめ

「氏名マスク済み」は、境界線の入口に過ぎない。法令上の最低ラインを充足する判断軸は、識別子レベルで設計が完了しているかに置かれる。

匿名加工情報（2017年施行）の要件「特定の個人を識別できず、かつ復元不可能」、仮名加工情報（2022年施行）の活用可能性——これらを判断基準として、開発環境への持ち込み前にコード類の扱いを確認する。

PPC 公式の「匿名加工情報に関する規制」（https://www.ppc.go.jp/personalinfo/tokumeikakouInfo/）で第2条第6項の定義を確認したうえで、自社データの識別子一覧を書き出し、上記チェックリストと照合する。この2ステップで「どこが穴か」が見える。

関連記事

• 社内の申請業務を「失敗しないように」デジタル化する
• そのスキルは、5年後も価値が残るのか