実際の個人情報を使わずに、漏えいリスクをどこまで検証できるか？
会員照会AIの試験環境ができました。
架空の会員が一人、予約も一件あり、回答は正しい内容です。
ところが、試験設計を見たセキュリティ担当者は尋ねました。
「別の会員との境界は、これでどう確かめますか」
この想定場面で足りないのは、本物の氏名ではありません。権限の異なる人とデータの関係を、試験環境へ再現することです。合成データでも確認できる問題は多くあります。ただし、再現していない接続設定や運用条件まで、安全だとは判断できません。
開発用のコピーにも管理が必要です。この記事では、漏えいを確かめる試験が新たな漏えい経路を作らないよう、データと環境を設計します。
名前を架空にする前に、確かめる条件を書く
試験の目的が、別会員の予約を取得できないことなら、少なくとも区別できる複数の会員と、それぞれの予約が必要になります。正当な代理照会もあるなら、代理権限のある担当者と、持たない担当者を分けます。
退会や権限取消しを扱う業務なら、有効な権限だけでなく、失効した権限も再現しておきましょう。検索の権限情報が遅れて更新される場合を確認するなら、その状態を試験条件へ含めます。きれいな正常データだけでは、境界が動く場面を調べられません。
架空のデータであっても、対象者、操作、許可条件、期待結果の関係が本番と対応していれば、有効な確認ができます。逆に、氏名や住所の見た目が本番に近くても、すべて管理者権限で照会しているなら、利用者ごとの認可は試していません。
試験データの品質は、現実らしい文章の量だけでは決まりません。防ぎたい被害を起こし得る条件を、どれだけ意図的に作れたかで評価しましょう。
四人の架空会員から、試験の違いを見せる
例えば、本人会員A、別会員B、代理権限のある担当者C、権限が失効した担当者Dを用意します。予約を照会する質問の内容は似ていても、取得してよい範囲は同じではありません。
これは試験設計の例であり、この四人を用意すれば十分という基準ではありません。家族会員、法人契約、複数店舗など、業務によって関係は増えます。重要なのは、業務責任者が「何が許されるか」を先に決め、テスト担当者が期待結果を独断で作らないことです。
正常な照会が通ることも、同時に確かめます。すべて拒否すれば権限外の取得は減るかもしれないが、サービスとして使えません。許可と拒否の境界が、業務に合って働くことが目標になります。
隔離したつもりの環境が、どこへつながっているか
データが架空でも、接続先が本番なら影響は生じ得ます。実在の宛先へ通知を送る、本番の会員レコードを変更する、外部サービスの利用料が増えるといった可能性を、環境の接続図から確認しておきましょう。
試験用のID、認証情報、API（システム同士がデータや機能をやり取りする接続口）接続先、送信先を揃え、何を外へ出せるかを制限します。架空のメールアドレスに見えても、実在する送信先を使っていないかを確認します。通知や決済などの副作用がある機能は、試験用の受け口や模擬処理を検討します。
ただし、模擬処理へ置き換えた部分では、本番の認可や制限を直接確認できない場合があります。その場合は「模擬接続での動作確認」と記載し、本番構成との差を別途確認します。隔離によって守った範囲と、隔離によって試せなかった範囲を、同じ資料へ残す必要があります。
McKinseyは、エージェントのリスク管理で、接続するデータ・権限の把握と、障害時の隔離や代替策を挙げています。本稿では、その考え方を、検証環境にも適用する提案として具体化しています。
試験の許可は、環境の所有者だけで完結しない
自社の環境であっても、クラウド、外部のAPI、委託先のシステムが含まれることがあります。顧客が試験を依頼した事実だけで、すべての接続先にあらゆる試験を行えると考えません。対象を許可できる主体と、利用条件を確認します。
合意したいのは、対象業務、環境、許可する手法、実施する時間、使用するID、許容する負荷、外部送信の扱い、停止条件、連絡先です。検証中に想定外のデータや本番の接続が見つかった場合、そこで範囲を拡大せず、止めて確認する手順も決めておきます。
現場では、調べたい経路が途中で増えることがあります。追加の確認が有益でも、当初の許可を自動的に拡張しません。追加対象の責任者へ戻し、必要な条件を揃えてから再開する方が、結果の説明も明確になります。
この準備は、攻撃者視点の検証を弱めるものではありません。合意した境界の中で、何を確かめたかを明瞭にする作業です。実施者の判断だけで範囲が広がらないことも、検証の品質に含めておきましょう。
それでも実データが必要だと言われたら
ある不具合が、特定の文書形式や長い履歴でしか再現しないとします。この場合も、最初の選択肢を本番データのコピーにしません。必要なのは具体的にどの条件かを切り出し、合成データや加工した資料で再現できないかを検討します。
例えば、予約が多いこと、古い所属情報が残ること、複数の契約関係が重なることが原因なら、その関係を架空に作る方法があります。実在する顧客の住所や連絡先そのものが必要なのかは、別の問いになります。
個人情報保護委員会のQ&Aも、テストデータについて、個人情報を含まないデータを用いることなどを説明しています。具体的な取扱いは、利用目的や安全管理措置を含め、自社の条件に即して確認する必要があります。
例外的な実データ利用を検討するなら、必要な理由、対象項目と件数、アクセスできる人、保管場所、終了後の処理を明確にします。氏名の置換だけで、再識別や他の項目の問題が消えたと判断しません。法務・個人情報管理の担当者を含め、例外を承認できる根拠を確認しておきましょう。
終了時の片付けも、試験の一工程にする
検証結果の報告が終わっても、試験用のアカウントや広い権限が残ることがあります。資料を作るために取得したログが、別の共有場所へ置かれることもあります。データだけでなく、検証のために増やしたアクセス手段も閉じる必要があります。
終了の確認には、不要になった権限の取消し、認証情報の扱い、残す証拠と消す作業データの区別を含めます。報告書へ生の個人情報や秘密の値を貼らず、必要な担当者が保護された証拠へ到達できる形を考えます。
合成データであっても、内部の接続構成や弱点の詳細が含まれる資料は管理対象になります。個人情報を含まないことから、検証資料の公開まで許されるとは限りません。結果の共有先も、合意した範囲へ絞りましょう。
想定場面の担当者は、一人分のデータを四人の権限関係へ作り直します。その際、試験の後に何を無効化するかも表へ追加します。試験を始める条件と、終える条件が一緒に見えるようになります。
本番との差分を、三種類に分けて残す
隔離環境の試験を読む際は、構成、データ、運用の差を分けると判断しやすくなります。
構成の差：模擬APIや試験用の認証など、接続の仕組みの違い
データの差：件数や文書の種類、権限関係の違い
運用の差：担当者の確認や夜間の対応など、業務の動かし方の違い
この三つは、同じ方法で埋めるとは限りません。構成の差なら、設定の照合や対象を限定した追加確認を検討します。データの差なら、不足する権限関係や形式を合成データへ追加します。運用の差なら、担当者が参加する机上演習を行うといった方法が考えられます。
例えば、試験用の検索では権限変更がすぐ反映されるのに、本番では別の更新処理を挟むなら、試験の成功だけで失効後の動作を判断できません。その更新経路を別途確認するか、未確認として公開条件へ渡す必要があります。
また、本番の利用量でだけ問題が起きる可能性を調べたい場合も、実データの持込みと負荷試験を同じ判断にしません。架空のデータを増やして再現できる部分がある一方、許容する負荷や外部サービスへの影響には別の合意が要ります。データの代表性と、試験の実施許可を分けて整理しておきましょう。
差分の一覧には、未再現の条件、影響する判断、代わりに行う確認、担当者を載せます。単に「本番と異なる」と注意書きを付けるより、何を次へ渡すかが明確になります。差分が残ることを隠さず、差分を管理できる資料に変えることが目標です。
冒頭の一人分の試験データも、この見方で改善できます。人数を増やすだけでなく、本人と他人、代理と失効、現在と過去という関係を作ります。その上で、本番と同じ認可の条件を通せているかを確認します。条件が再現できない部分には、別の確認が必要だと書きます。
合成データは、現実を丸ごと複製するものではありません。確かめたい条件を意図的に作れることに価値があります。その利点を生かしながら、試験の外へ残る条件も説明できれば、本番情報を増やさずに検証の意味を深められます。
再現できなかった条件を、次の確認へ渡す
合成データと隔離環境では、本番の規模、すべての外部連携、担当者の実際の運用まで再現できないことがあります。その差を隠して試験を大きく見せるより、未確認の条件を本番前の確認や段階的な導入へ渡す方がよいでしょう。
AIL Red Team Xでは、原則として合成データと隔離された検証環境を用い、対象・許容手法・停止条件を顧客と合意して進めます。本番環境への直接試験には、別途の合意と追加統制が必要となります。提供開始は2026年11月の予定です。
依頼の準備としては、業務の流れ、権限の種類、接続先、検証環境との差を整理するとよいでしょう。本物の顧客情報を最初から渡すより、確かめたい境界を説明する資料が、試験の設計に役立ちます。
架空の会員データでも、現実に起こり得る問題を再現できます。その条件は、データの見た目ではなく、業務と権限の関係にあります。
参考情報
AIL Red Team Xの実施条件はAILのサービス発表案に基づきます。表と会議の場面は試験設計の想定例です。特定構成での安全性や法適合性を保証するものではありません。確認基準日：2026年10月22日。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
