追加開発のリグレッションテストを来週から始めます、と言われて、基盤担当が週末に本番から検証環境へシステムコピーを流す。月曜には昨日までの本番の残高がQAS環境に載っていて、テストは進む。この作業に、稟議も、法務のレビューも、経理の承認も要らない。 社外に何も出ていないからである。個人情報保護法の条文を順に当てていっても、引っかかる場所がほとんど無い。だから止まらない。
「仮名加工情報にすれば楽になる」は逆である
マスキングの議論を始めると、まず出てくるのが仮名加工情報という語である。加工してしまえば個人データではなくなるので義務が軽くなる、という理解が広く流通している。これは二重に誤っている。
第一に、仮名加工情報は義務が軽くなるどころか、固有の義務が上乗せされる。 法第41条第2項は、仮名加工情報を作成した事業者に対し、削除した記述等および加工の方法に関する情報（削除情報等）の安全管理措置を義務づける。氏名と仮IDの対応表がこれに当たる。個人情報保護委員会は、削除情報等が漏えいした場合には原則として仮IDを振り直して仮名加工情報を作り直す等の措置が必要になるとしている。第41条第6項は、法令に基づく場合を除いて仮名加工情報である個人データの第三者提供を禁じ、第41条第7項は、元の個人情報に係る本人を識別する目的で他の情報と照合することを禁じる。テストの過程で「この社員番号は誰か」を確認する行為が、この禁止に触れる。 障害調査でそれをやらない保証は、どこにもない。
第二に、多くの会社が実際にやっている加工は、そもそも仮名加工情報の作成ではない。 仮名加工情報は、他の情報と照合しない限り特定の個人を識別することができないよう、委員会規則で定める基準に従って加工したものをいう。氏名の列だけを伏せて、生年月日・住所・部署・役職・給与額をそのまま残したデータは、この基準を満たさない。満たさなければ、それは加工されただけの個人データであり、法第23条の対象のままである。 中途半端な加工は、法的な区分を一つも動かさないまま、テストの精度だけを落とす。
結論は単純になる。検証環境のデータを法的な区分の付け替えで処理しようとしない。 個人データのままだと認めたうえで、その環境に見合う安全管理措置を設計するほうが、はるかに安く済む。
権限が緩いのは事故ではなく、検証環境の設計思想である
検証環境の権限が本番より緩いのは、担当者の怠慢ではない。テストとは、通常の業務では通れない経路を通す作業だからである。エラーを再現するにはデバッガが要り、データを作るにはテーブルの直接更新が要り、外部ベンダーには広い権限が要る。緩さは仕様である。 問題は、その仕様の上に本番と同じ給与と取引条件を置くことにある。
具体的にどこが緩むかを列挙すると、対策の順番が見える。
権限オブジェクトの面では、本番で厳格に絞られている P_ORGIN（人事マスタの権限）や S_TABU_DIS / S_TABU_NAM（テーブル参照・保守）が、検証環境では広いロールにまとめられていることが多い。とりわけ S_DEVELOP は決定的で、これを持つ利用者はデバッガから任意のテーブルの内容を参照でき、条件によっては値を書き換えられる。マスキングされた列があっても、マスキングの前後で何が起きたかを追える立場の人間が、環境の中に常時存在する。
記録の面では、本番で有効にしているテーブル変更ログ（プロファイルパラメータ rec/client）や、参照そのものを記録する Read Access Logging が、検証環境では性能を理由に無効にされていることがある。本番なら「誰が給与テーブルを見たか」が残るのに、検証環境では残らない。 漏えいが疑われたときに、影響範囲を特定できない。
そして外部要員の面では、テスト期間中だけ発行された利用者IDが、テスト終了後もロックされずに残る。プロジェクトの終盤ほど、この後始末は後回しになる（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
列を潰しても、添付ファイルとスプールは潰れない
マスキングの実装で最も落ちるのがここである。処理を書く人は、テーブルの列を対象にする。PA0008（基本給）、PA0009（銀行情報）、PA0006（住所）、LFBK（仕入先の銀行情報）、KONP（条件明細）といった、値が入っている列を洗い出して置換する。それで終わったつもりになる。
残るものが三種類ある。
一つ目が、添付ファイルの本体である。伝票やワークフローに添付されたPDF・Excelは、SAP Office の内容テーブル（SOFFCONT1 など）にバイナリのまま格納されている。給与明細のPDF、稟議に添付した見積書、契約書のスキャン。列の置換処理は、この中身に一切届かない。 取引先名も金額も、そのまま検証環境に載っている。
二つ目が、スプールリクエストである。本番で出力された帳票のスプールが、システムコピーでは環境ごと持ち込まれる。給与明細や支払通知書の出力結果を、スプールの一覧から誰でも開ける状態になっていることがある。
三つ目が、アーカイブとバックアップである。マスキングを掛けた後の検証環境をバックアップから戻せば、マスキング前の状態に戻る。マスキングは一度きりの作業ではなく、環境の状態が変わるたびに再実行される工程でなければ意味を持たない。
対策の順序としては、まずクライアントコピー（SCCL / SCC9）とシステムコピーを区別する。クライアントコピーは指定したクライアントのデータだけを運ぶため、クライアント非依存の領域やスプールは相対的に混入しにくい。一方、本番と同じ性能・同じデータ量でテストしたいという要求に応えるのはシステムコピーであり、性能テストの要求が、そのまま個人データの持ち込み量を決めているという関係になる。ここは技術の問題ではなく、テスト計画で先に決める話である（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。
本番データが要ると言うとき、要っているのは値ではなく組み合わせである
「加工したデータではテストにならない」という反論は、たいてい正しくない。何が要るのかを分解すると、要求は三つに割れる。
一つ目が件数と分布である。月次で十万件の伝票が流れる会社で、性能とバッチの処理時間を測るには、その件数が要る。ただし要るのは件数であって、その伝票の相手先が実在の取引先である必要はない。二つ目が組み合わせの偏りである。本番データの価値の大半はここにある。特定の得意先だけに適用されている例外的な条件、一件だけ存在する三桁の税コードの組み合わせ、十年前のマスタ設定を引きずっている品目。テスト設計者が思いつかない組み合わせが、本番には実在する。 三つ目が実際の値そのもので、これが要る場面は驚くほど少ない。給与の支給控除計算の検算をするときに、実在の社員の実額でなければ検証できない、という主張はほとんど成立しない。
順序をこう置き直すと、判断が変わる。一つ目と二つ目は、値を置換しても失われない。 件数を保ち、コード体系と参照整合性を保ったまま、氏名と金額と口座番号を差し替えれば、性能も組み合わせの偏りもそのまま残る。落ちるのは三つ目だけである。
だから、テスト計画で決めるべき問いは「マスキングするかどうか」ではない。**「このテストケースは、実在の値がないと合否を判定できないか」**である。この問いを一件ずつ立てると、実データを要求するケースは全体の数%まで落ちる。そして残った数%については、環境を分けるか、対象者を限定するか、参照の記録を取ったうえで期間を区切って許可するか、という個別の判断になる。全体を丸ごと持ち込むか、丸ごと諦めるかの二択にしているから、議論が終わらない。
クラウドに置いた検証環境は、置き場所の国まで含めて安全管理措置になる
本番はオンプレミス、検証環境はハイパースケーラー上、という構成は珍しくない。コストの観点では合理的だが、個人情報保護法の観点では一つ論点が増える。
個人情報保護委員会のガイドライン（通則編）が安全管理措置の一項目として掲げる外的環境の把握は、外国において個人データを取り扱う場合に、当該外国の個人情報の保護に関する制度等を把握したうえで安全管理措置を講じることを求めている。委員会は、外国にある第三者の提供するクラウドサービスを利用してそのサーバに個人データを保存する場合も、外国において個人データを取り扱うことになるため制度等の把握が必要になる、という考え方を示している。本番が国内でも、検証環境のリージョンが海外にあれば、そこで個人データを取り扱っていることになる。
さらに、この把握した内容は社内で完結しない。法第32条第1項第4号・施行令第10条第1号により、保有個人データの安全管理のために講じた措置は本人の知り得る状態に置くべき事項に含まれる。プライバシーポリシーに書いてある「安全管理措置」の記述と、実際の検証環境の置き場所が食い違っている会社は、少なくない。
漏えいの報告義務は、本番か検証かを区別しない
法第26条は、個人データの漏えい等であって個人の権利利益を害するおそれが大きいものとして委員会規則で定めるものが生じたときに、委員会への報告と本人への通知を義務づける。規則が定める類型には、要配慮個人情報が含まれる事態、財産的被害が生じるおそれがある事態、不正の目的をもって行われたおそれがある行為によるもの、そして本人の数が1,000人を超える事態がある。
条文のどこにも、本番環境という限定はない。検証環境に置いた従業員データが1,000人分あれば、そこからの漏えいは報告対象になる。 そして報告には速報と確報があり、速報は速やかに、確報は原則30日以内（不正の目的をもって行われたおそれがある行為によるものは60日以内）とされている。この期間内に「何件が、どの範囲で漏れたか」を答えられるかどうかが、そのまま Read Access Logging を切っていたかどうかで決まる。
規制の重さは今後さらに上がる。令和8年7月10日に成立し、同月17日に公布された「個人情報の保護に関する法律等の一部を改正する法律」は、個人情報の違法な取扱い等によって財産上の利益を得た場合に個人情報保護委員会が課徴金納付を命ずる制度を設けるものである。施行は一部を除き、公布日から起算して2年以内で政令で定める日とされている。課徴金の要件が財産上の利益に係る以上、テスト環境からの漏えいが直ちに対象になるとは限らない。 ただし、政令・規則・ガイドラインの検討がこれから進む局面で、非本番環境の個人データの持ち方を放置しておく理由にはならない。
S_DEVELOP を含むロールを持っていた。CFOは、権限の棚卸しより先に、そもそも何が置かれているのかを確認させた。出てきたのは、マスキングプログラムが触っていない領域だった。 稟議ワークフローの添付ファイルが SOFFCONT1 に残っており、そこには役員報酬の改定稟議に添付された個人別の一覧表と、主要仕入先との単価改定合意書のスキャンが入っていた。給与明細の出力スプールも、本番のものが二か月分そのまま持ち込まれていた。列は潰れていて、添付は潰れていない。マスキングの仕様書に「テーブルと列の一覧」しか書かれていなかったことが、そのまま穴になっていた。 対応は三本立てになった。一本目は、マスキングを「移行時の作業」から「クライアントコピー後に必ず走る後処理」へ位置づけ直し、コピーの手順書に組み込んで、実行ログを残さない限り環境を利用者へ開放しない運用にしたこと。二本目は、対象を列から領域へ広げ、添付ファイルとスプールは加工でなく削除の対象としたこと。テストで添付が必要な場合は、テスト用に作成したダミーの添付を投入する手順を別に用意した。三本目が、環境ごとの記録の再設定で、検証環境でも人事関連テーブルについては Read Access Logging を有効にした。性能への影響を懸念する声があったため、対象を人事と仕入先銀行情報に絞っている。さらに一つ、テスト計画の側で決めたことがある。 性能テストは本番同等のデータ量を要求するが、そこで要るのは件数と分布であって実在の氏名や口座番号ではない。件数と金額分布を保ったまま値を差し替える方針を先に決めたことで、「実データでないとテストにならない」という反論が出なくなった。情報システム部長はこう言っている。議論が長引いていたのは、マスキングの技術の話をしていたからだ。何を残せばテストが成立するかを先に決めたら、残りは自動化できる作業だった、と。決めるのは三つ
第一に、法的な区分の付け替えで解こうとしない。 仮名加工情報とすれば軽くなるという理解は逆で、法第41条第2項の削除情報等の安全管理、第41条第6項の第三者提供の禁止、第41条第7項の識別行為の禁止が上乗せされる。しかも氏名の列だけを伏せたデータは、委員会規則で定める基準を満たさないため個人データのままである。個人データであると認めたうえで、法第23条の安全管理措置を環境ごとに設計する。
第二に、マスキングを工程に固定する。 移行時の一度きりの作業として作られたプログラムは、環境リフレッシュのたびに穴が開き直す。クライアントコピーの手順書に後処理として組み込み、実行ログが残るまで利用者へ環境を開放しない。そして対象をテーブルの列に限定しない。添付ファイルの本体、スプールリクエスト、アーカイブとバックアップは、列の置換処理が届かない。
第三に、置き場所と記録を、本番と別に決める。 ガイドライン（通則編）の外的環境の把握は、外国にある第三者の提供するクラウドサービスを利用して個人データを保存する場合にも制度等の把握を求める。検証環境のリージョンは、そのまま法第32条第1項第4号の公表事項に跳ね返る。そして法第26条の漏えい等報告は環境を区別せず、1,000人を超える事態は報告対象になる。確報の期限内に範囲を答えられるかどうかは、参照の記録を切っていたかどうかで決まる。
P_ORGIN や S_TABU_DIS / S_TABU_NAM が広いロールにまとめられ、S_DEVELOP を持つ利用者はデバッガから任意のテーブルを参照できる。テーブル変更ログ（rec/client）や Read Access Logging が性能を理由に無効化され、テスト終了後も外部要員のIDが残る。マスキングの実装で最も落ちるのは、対象をテーブルの列に限定してしまう点である。稟議やワークフローの添付ファイルは SAP Office の内容テーブル（SOFFCONT1 など）にバイナリで格納されており列の置換処理が届かず、本番で出力された給与明細や支払通知書のスプールはシステムコピーで環境ごと持ち込まれ、バックアップから復元すればマスキング前の状態に戻る。したがってマスキングは移行時の一度きりの作業ではなく、クライアントコピー（SCCL / SCC9）の手順書に組み込まれ、実行ログが残るまで環境を開放しない後処理として設計する必要がある。クラウド上に検証環境を置く場合には外的環境の把握が加わり、個人情報保護委員会は外国にある第三者の提供するクラウドサービスのサーバに個人データを保存する場合も外国において個人データを取り扱うことになるため当該外国の制度等の把握が必要という考え方を示している。把握した内容は法第32条第1項第4号・施行令第10条第1号により本人の知り得る状態に置く事項へ跳ね返る。漏えい時の対応についても、法第26条の報告義務に本番・検証の区別はなく、要配慮個人情報、財産的被害のおそれ、不正の目的をもって行われたおそれがある行為、本人の数が1,000人を超える事態が規則の類型に含まれる。報告は速報と確報に分かれ、確報は原則30日以内、不正の目的をもって行われたおそれがある行為によるものは60日以内とされており、その期限内に影響範囲を答えられるかどうかは参照の記録を残していたかどうかで決まる。加えて、令和8年7月10日に成立し同月17日に公布された「個人情報の保護に関する法律等の一部を改正する法律」は、個人情報の違法な取扱い等によって財産上の利益を得た場合に課徴金納付を命ずる制度を設けるもので、施行は一部を除き公布日から起算して2年以内で政令で定める日とされている。課徴金の要件が財産上の利益に係る以上、非本番環境からの漏えいが直ちに対象になるとは限らないが、政令・規則・ガイドラインの検討が進む局面で非本番環境の個人データを放置する理由にはならない。何をどこまで加工するかは、テストで実データの分布や整合性が要る度合いと、再識別・流出時の被害の大きさという二軸で決める。給与額・口座番号・取引単価は桁と分布を保ったまま値を置換し、氏名・住所・電話番号は桁数と文字種だけ合わせた固定パターンへ寄せ、マイナンバーや健康診断結果のようにテストで使う場面が無いものはコピー後に削除し、勘定コードや原価センタのように個人にも取引条件にも結び付かないものは触らない。
