AIは、見てはいけない顧客情報まで参照していないか？
会員照会AIの受入テストが終わりました。予約日時も、顧客への案内も正しく、別の会員の名前は画面に一度も出ていません。
ところが、実行記録を確認した担当者が、回答前に取得した情報の範囲で手を止めます。本人以外の記録まで、検索結果に含まれていました。
これは、評価の盲点を考えるための架空の場面です。実在企業の漏えい事案やAILの検証実績を再現したものではありません。しかし、回答の見た目だけを採点しているなら、この違いを確かめることはできません。
AIが何を答えたかに加え、何を取得し、何を実行し、その操作が許されていたかを別に評価します。API（システム同士がデータや機能をやり取りする接続口）の認可、つまり「誰にどの操作を許すか」を、AIエージェントの受入判定にも含めると、見るべき証拠が変わります。
合格したのは、どの部分だったのか
冒頭のテスト結果は、間違っているとは限りません。顧客への最終回答は適切だった可能性があります。ただ、その結果から、取得した情報も適切だったと結論付けることはできません。
AIが使う情報には、検索結果、ツールから返されたデータ、以前の会話、保存された状態などがあります。最終回答は、それらの一部だけを利用して作られる場合があります。表示されなかった情報も、処理の途中には存在し得るということです。
ここで、表示されていないから漏えいではない、とも、取得しただけで必ず法的な漏えいだ、とも一律には判断しません。取得主体、保存先、許可範囲、外部への送信などを確認する必要があります。まず確かめたいのは、業務上の許可を超えて情報が参照されていないかという点です。
OWASPのエージェント向けリスク整理も、会話の出力だけでなく、ツールの利用やID・権限を含むリスクを扱います。私たちはこれを、回答テストを残しながら、実行の妥当性を追加で確かめる理由として捉えます。
一回の照会を、三つの記録で追う
想定場面の担当者は、合格を取り消す前に、一回の照会で起きたことを整理します。利用者からの依頼、AIのツール呼出し、接続先の処理結果が、同じ一件として対応するかを見ます。
AILが提案するのは、次の三つを対応付ける評価です。
回答：顧客に表示された内容
実行：実際に照会・変更・送信した対象と結果
認可：誰にどの操作を許したかという、接続先の判断
それぞれの記録に、同じ処理をたどれる識別情報が必要になります。利用者のID、対象の記録、実行した操作、判定、時点がわかれば、回答の前に何が起きたかを追いやすくなります。システムの時計や中継を含め、どこまで対応できるかも確認します。
AIに自分の行動を説明させた文章は、この証拠の代わりにはなりません。説明と実行結果が一致するかは別の確認だからです。理由の文章がもっともらしいことより、接続先に残っている、実際の操作の記録を優先します。
余分に取得した原因を、モデルの問題に決め付けない
本人以外の記録が検索結果に入っていたとしても、最初からモデルを変更すればよいとは限りません。検索条件、ツールの仕様、接続に使うID、データ側の制約など、複数の原因が考えられます。
例えば、ツールが広い一覧を返し、その中からAIに本人の分を選ばせる設計だった場合、AIが指示どおりに答えても、取得の範囲は広いままです。必要な対象だけを返す役割をどこへ置くかを、設計として見直す必要があります。
一方、担当者が複数の会員を照会する正当な業務もあります。複数件の取得だから直ちに不適切と決めず、誰のどの仕事に必要かを確認します。顧客本人向けの照会と、担当者向けの業務検索で、同じ期待結果を使わないことが重要です。
この区別をせずに、取得件数を減らす指示だけをAIへ追加すると、画面上の結果は変わっても、接続先の許可範囲は変わらないかもしれません。原因に対応する統制を選び、その統制が実際に働いたことを再び確かめます。
拒否された回答にも、複数の意味がある
逆の場面も考えてみましょう。AIが依頼を断ったため、担当者が安全性のテストに合格を付けました。ところが、断る前にツールを実行していたなら、回答の拒否と操作の拒否は一致していません。
処理の順番を追うと、入力の段階で止まったのか、ツールへ渡す前に止まったのか、接続先で拒否されたのか、情報を取得した後に表示を止めたのかを分けられます。業務上防ぎたい被害に対し、どの段階の拒否が必要かを決めておきましょう。
住所変更を禁止する要件なら、変更が実行されずに終わることを確認します。回答に住所を出さない要件なら、それに加えて表示の確認も必要になります。安全という一つの言葉へまとめず、対象と操作ごとに判定する方が説明しやすくなります。
なお、実行記録が見つからないことも、実行がなかった証拠とは限りません。記録を取得できている範囲、保存の期間、途中で失敗した場合の残り方を確かめます。証拠が不足するテストは、合格ではなく未確認として扱う判断が必要です。
見えないアクセスを探すために、ログを増やし過ぎない
すべての情報を保存すれば追える、という設計にも問題があります。検証用の記録に顧客情報や資格情報（接続時に使うIDやトークンなど）をそのまま複製すれば、新たな管理対象を増やしてしまいます。
まず、実行の有無と許可範囲を判定するのに必要な情報を決めます。対象の識別子、操作の種類、許可・拒否、結果の件数などで確認できる部分と、限定した内容確認が必要な部分を分けます。実データの閲覧は、必要な担当者と手順に絞りましょう。
資格情報や秘密の値を記録しないこと、記録のアクセスと保存期間を管理することも重要になります。詳しい証拠を別の保護された場所へ置き、通常の報告には参照先と判定だけを出す設計も考えられます。
確認のために作った記録が、次の漏えいの対象になることは避けたい点です。ログの網羅性と情報の最小化は、どちらかを捨てる二択ではありません。必要な判定から逆算して記録を設計する課題です。
同じ回答でも、利用者を変えると合否が変わる
冒頭の試験をもう一度行うなら、正常な一件だけで終えません。利用者と対象の関係が違うケースを用意し、期待される取得範囲を変えます。
確認するのは、次のような条件です。
本人には許される照会が、別の会員からは拒否されるか
代理の担当者には、承認された範囲だけが返るか
権限の取消し後に同じ依頼をしても、以前の結果へ届かないか
いずれも、合意した検証環境とデータで確認します。
ここで必要なのは、危険な質問を大量に増やすことではありません。同じ言い方の依頼でも、権限の条件で許可と拒否が分かれることを確かめる試験です。通常の回答精度の問題とは違う軸を持てます。
テストの表には、利用者、対象、許可された操作、期待するアクセス結果、期待する回答、確認する証拠を並べます。回答だけが正しい場合と、操作まで正しい場合を区別できれば、改善の担当も選びやすくなります。
通信が失敗したとき、何が終わっているのか
実行の評価には、途中で応答を受け取れない場合も含めておきましょう。AIの画面がエラーになっていても、接続先では照会や変更を受け付けていた可能性があります。画面の失敗と、業務処理の未実行を同じものにしません。
特に、変更や外部送信では、返答がなかったためにもう一度実行する動作が、重複した処理を生むおそれがあります。再試行してよい条件と、先に処理の状態を照会すべき条件を決める必要があります。
これは、AIのエラー率を下げるだけでは解決しない場合があります。接続先に状態確認の方法があるか、同じ依頼の重複を抑えられるか、人へ引き継ぐときに何を伝えるかまで確認しておきましょう。一般的な分散処理の問題も、AIの会話画面の裏側に残っています。
想定場面の担当者が、一回の成功だけで合格を付けていたなら、ここは追加の確認になります。成功、拒否、途中失敗という異なる結果を、画面と実行の両方から読みます。判定の範囲を広げる理由が明確になります。
証拠をつなげても、対象の版が違えば判断できない
別の担当者が翌週、同じ質問を試して問題なしと報告したとします。質問の文章が同じでも、接続先の権限、検索の設定、利用者の所属が変わっていたなら、最初の試験と同じ条件ではありません。結果の違いを、モデルの偶然だけで説明しないことが必要になります。
そこで、試験時点の構成と期待結果を一緒に残します。モデルやツールの版だけでなく、どの権限を持つ利用者を使い、どのデータを対象にし、何を許さない条件だったかを記録します。後から同じ条件を再現できる程度に具体化し、秘密の値そのものは残しません。
例えば、担当者向けには複数会員の照会を認め、本人向けには一人分だけを認める設計なら、取得件数の多さだけを異常の基準にできません。役割ごとの期待範囲と照合して初めて、広過ぎる取得を判定できます。テスト結果の集計にも、この役割の違いを残しておきましょう。
また、以前の照会結果を再利用する経路では、今回の検索を呼び出さずに回答が作られることも想定します。新しい検索の記録だけを探しても、情報の出所を説明できません。会話や再利用された結果を含め、今回の回答につながった経路を追えるかが問われます。
すべての経路を一度に詳しく記録できない場合は、どこまで確認でき、どこから確認できないかを示します。追跡できない経路を、問題が起きなかった経路として数えません。この扱いを受入基準に入れておくと、ログ不足が合格の理由になる逆転を防ぎやすくなります。
最初の受入判定を、どこから変えるか
自社で始めるなら、顧客情報を取得する一つの機能を選びます。既存の回答テストを捨てる必要はありません。その横へ、実際に取得してよい対象と、操作を許す条件を追加します。
開発担当者には、その条件をどこで強制しているか、結果を何で確かめるかを説明してもらいます。業務責任者には、本人、代理、窓口担当者の許可範囲が実務に合うかを確認してもらいます。評価者だけで正解を作らない方がよいでしょう。
証拠が足りない場合は、未確認の理由と追加の確認方法を残します。取得した内容が不適切なら、指示文の修正だけで済ませず、原因と統制を対応付けて直します。修正した後は、同じ条件で回答と実行を再確認します。
AIの答えが正しいことは、顧客体験にとって大切です。しかし、会員情報につながるAIの評価は、それだけで完了しません。何を答え、何を行い、何が許されていたかを一つの処理として説明できることが、運用の判断を支えます。
RAGの回答で個人情報を隠しても、取得の段階で守るべき境界が残っていないかを考えます。
参考情報
公表情報の確認基準日：2026年10月22日。会員照会や途中失敗の場面は設計・評価の想定例です。特定企業の侵害や法的な漏えいの認定を示すものではありません。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
