カード番号が漏れていなければ、顧客の被害は小さいと言えるか？
「カード番号もパスワードも含まれていない」。情報漏えいのお知らせで、その説明に少し安心した経験はないでしょうか。
直ちに決済やログインへ使われる情報が含まれるかどうかは重要です。しかし、それだけで顧客への影響を評価し終えることはできません。
ヤマトホールディングスが2026年10月16日に公表した後払いサービスの調査結果では、利用者情報約526万件と届け先情報約5万件の不正持ち出しが示されました。カード情報とパスワードは含まれず、同発表時点で不正利用による二次被害は確認されていないとしています。
この事案に、確認されていない被害を付け足すべきではありません。一方、自社のリスク評価をカード情報の有無で終えることも避ける必要があります。情報の組み合わせが何を可能にし、顧客にどんな負担を生むかまで考えることが、業務上の被害を評価することにつながります。
項目の一覧を、顧客が受け取る場面へ置き換える
漏えいの調査では、氏名、住所、電話番号、メールアドレス、利用や取引に関わる情報などを、項目ごとに確認します。一覧は必要ですが、項目名だけでは、顧客の立場で何が起きるかまでは見えてきません。
ここからは、一般的なリスクを考えるための仮想例です。顧客の氏名と、最近利用したサービスに関する情報を知る相手から連絡が届きます。顧客は、知っている内容が含まれるため、正規の事業者からの連絡かどうか迷うかもしれません。
この迷いを減らすには、怪しい連絡に注意するよう伝えるだけでなく、事業者がどんな連絡をし、何を尋ねず、どこで真偽を確認できるかを示す必要があります。情報の悪用が確認されていなくても、予防的な案内を設計する意味があります。
もちろん、情報を知っている相手から連絡が来たことだけで、特定の事故に起因すると断定はできません。実際の被害との因果関係は別途調査します。この区別を保ちながら、起こり得る場面に備えるのがリスク管理です。
「漏れた情報だけではログインできない」の、その先
漏れた情報だけではログインできないという説明は、確認対象を限定すれば意味があります。その組み合わせで認証を通過しないかを確かめた結果なら、重要な情報です。
ただし、顧客の生活の中で使われる経路はログイン画面だけではありません。問い合わせ窓口、会員情報の変更、紛失時の手続き、別のサービスへの連絡などがあります。情報がそのまま鍵にならなくても、相手が正当な利用者を装う材料にならないかを点検できます。
これを、漏れた項目を知っていれば本人確認を必ず突破できる、という意味にしてはいけません。実際の手続きに何が必要か、他の確認や制限があるかで結果は変わります。そのため、推測だけで終わらせず、自社の具体的な手続きに照らして確かめる必要があります。
AI Librarium（AIL）が重視するのは、漏えいした情報の評価と、顧客に対して許す操作の評価を結び付けることです。どんな情報が知られた場合に、どの操作の確認条件を見直すかを決めておきます。無関係な手続きまで一律に止めれば、顧客の不便も大きくなります。
取引情報には、金銭以外の影響もある
顧客に関わる情報は、種類によって知られたときの影響が異なります。ある商品やサービスの利用が知られること自体に、顧客が大きな負担を感じる場合もあります。金銭の移動が起きたかだけでは、プライバシーへの影響を十分に捉えられません。
この点は、特定企業の公表情報から顧客の事情を推測するために使うべきではありません。自社のデータを分類するときに、購入内容、訪問先、相談の内容などが、本人にとってどのような意味を持つかを検討する問いとして使います。
同じメールアドレス一項目でも、何のサービスを利用する人のアドレスかで、情報の意味が変わることがあります。件数が少ないから軽微だとする前に、利用の文脈を確認しておきましょう。自社の評価基準が、金銭的な損失だけに偏っていないかを見る機会になります。
事業部門は、データの意味を技術部門より具体的に説明できる場合があります。セキュリティ部門が情報の形式を整理し、事業部門が顧客との関係を補います。責任を押し付けるためではなく、被害の見落としを減らすための分担です。
顧客が対応する時間も、事故の影響になる
損失を試算する会議では、調査費用、復旧費用、外部支援費用など、自社が支払う費用を並べがちです。そこに、顧客が必要とする確認や対応の負担も加えて考えておくことが大切です。
例えば、自分が対象かを調べたり、問い合わせ窓口へ連絡したり、怪しい通知の真偽を確かめたりする時間です。状況によっては他の手続きの見直しも必要になるでしょう。実際に何を求めるべきかは、漏えいした内容と確認された危険に応じて決めます。
ここで、すべての顧客へ一律に多くの作業を求めると、負担だけが増える可能性があります。何をしてほしいかと、その理由を対応させることが重要です。対象外の情報について過剰な変更を勧めない判断も含まれます。
前述の仮想例で、顧客が不審な連絡の真偽を調べたいと考えたとします。正規のお知らせに確認窓口がわかりやすく示され、問い合わせ担当者が同じ説明をできれば、顧客は行動を選びやすくなります。事故対応を情報の流出調査だけで終えない価値がここにあります。
公表文は、三つの内容に分けて読む
自社の説明を準備する際は、内容を三つに分けるとよいでしょう。確認済みの事実、まだわからないこと、予防のための案内です。
確認済みの事実：対象のサービス、情報の種類、判明した範囲、実施した制限などを示します。
まだわからないこと：調査中の範囲と、次に更新する情報を示します。
予防のための案内：顧客が注意すべき連絡、事業者が求めない情報、確認窓口を示します。
この三つが混ざると、二次被害は確認されていないという説明が、何もする必要がないという意味に読まれたり、注意喚起が、被害が発生したという意味に読まれたりします。広報、法務、顧客対応部門で言葉の意味を合わせておくことが大切です。
公表内容を更新する場合も、何が新たにわかったかを明確にします。過去のお知らせとの差が見えれば、顧客と窓口担当者は同じ基準で対応できます。更新履歴を残すことは、後から説明を検証するためにも役立ちます。
自社の一サービスで、被害のつながりを確認する
顧客への影響を検討する場では、情報の項目を並べた表の右側に、もう三列を足してみます。以下は検討用の例であり、特定の事故で発生した被害の記録ではありません。
大切なのは、表の例をそのままリスクの確定事項にしないことです。自社の窓口やシステムで何が起こり得るかを確かめ、成立しないシナリオはその理由を記録します。成立し得るものには、対策の担当と検証方法を置きます。
例えば、会員情報変更の手続きで、連絡先を知っているだけでは進めないことを確認できたなら、それも根拠になります。追加確認をどこで強制しているか、代理の手続きはどうか、例外の判断が記録されるかまで見ておくと、説明の範囲が明確になります。
AIの本人確認に、何を任せるべきか
顧客対応AIが自然な会話をするほど、相手の説明がもっともらしいことを、本人である根拠と取り違えない設計が必要になります。取引の内容をよく知っていることと、その情報へのアクセスや操作を許可してよいことは別です。
これはAIの回答を信用するかどうかという抽象論ではありません。本人確認の結果を、AIが使うツールにどう渡し、住所変更などの操作をどこで許可するかという設計の問題です。会話の雰囲気によって、接続先の権限が広がらないようにします。
私たちがAIエージェント（情報の取得やツールの操作を行うAI）の評価で業務被害を先に考えるのは、このためです。個人情報が返答に出たかだけでなく、知られた情報を手がかりに、許されない参照や変更へ進めないかを確かめます。判定に必要な証拠は、会話と実行結果の両方になります。
この検討を、自社の業務責任者と開発担当者で行います。顧客にとって重要な操作を選び、その操作の安全性に問題があると判断する条件を決めます。モデルの一般的な正答率だけでは、その条件を代替できません。
予防の案内が、顧客をさらに迷わせていないか
仮想例の顧客が、注意を促すお知らせを読み終えた後、どう行動するかも考えておくことが大切です。心当たりのない連絡を受けたら、届いたメッセージのリンクから確認するのか、以前から使っている公式の窓口へ自分で接続するのでしょうか。その違いを理解できる案内が必要です。
顧客向けの告知を作る側は、長い専門用語より、具体的な行動と公式の確認先を揃えます。問い合わせ担当者にも、確定した情報と調査中の情報を同じ版で渡します。電話では別の説明をされた、という状態を減らすことが、顧客の追加の確認負担を抑えます。
この案内の有効性も、読んだかどうかだけでは確かめにくいものです。架空の不審な連絡を題材に、正しい確認先を選べるかを社内の机上演習で試す方法が考えられます。実際の顧客へ疑わしい連絡を送る必要はありません。説明文の曖昧さを、関係者の確認で見つけるための試みです。
AIを窓口に使うなら、未確認の被害や補償について、その場で断定して答えないことも評価します。更新された正式な案内へ接続し、個別判断が必要な質問は人へ渡します。事故時に何を答えないかまで決めることが、顧客との信頼を守る運用になります。
被害が小さいかを決める前に、何を確かめたかを示す
カード情報を含まないという事実は、正しく伝えるべきです。二次被害が確認されていないという調査状況も、その時点と範囲を付けて伝える必要があります。どちらも、顧客への影響全体が小さいという結論と同じではありません。
次のリスク会議では、漏れたら何件かという問いに加えて、顧客にどんな連絡が届き、自社のどの手続きが関係し、何を根拠に影響を限定できるかを確認してみてください。推測を事実として扱わず、仮説を具体的な点検へ変えることが重要です。
情報の項目から、顧客の行動と業務の操作までつながりを描ければ、優先して守るべきものが見えてきます。その前段にある保有の判断も重要です。過去の顧客情報を残すことと、AIへ参照させることは、同じ判断でよいのでしょうか。
参考情報
本文の二次被害、本人確認、AI連携の例は、AILによる一般的なリスク分析・設計上の想定です。当該事案で二次被害が確認された、またはAIが関与したと主張するものではありません。
公表情報の確認基準日：2026年10月22日。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
