アプリに問題がなくても、なぜ会員情報は漏れるのか？
会員アプリのテストで、利用者Aとしてログインしました。表示されるのはAの氏名と予約履歴だけで、別の会員の画面へ移るボタンもありません。
テスト担当者は、「本人以外の情報は見えない」と記録しました。
ところが、確認したのがその画面操作だけなら、裏側のサーバーが他人の情報を返さないことまで確かめたとは限りません。これは認可の確認範囲を考えるための想定場面であり、特定企業で起きた事故の再現ではありません。
本人の情報だけを表示する画面と、本人に許された情報だけを返すAPIは、別々に確認する必要があります。 公開アプリを解析してサーバーを狙う手口から学びたいのは、この境界です。
注意喚起が示したのは、画面の外にある経路
NICT（情報通信研究機構）は2026年10月13日、公開されたAndroidアプリを解析し、その結果からアプリの裏側で動くサーバーを狙うA2B攻撃への注意喚起を公表しました。アプリ自体に脆弱性がなくても、裏側の認証・認可や入力値の検証に不備があれば、不正アクセスや漏えいにつながるおそれがあるとしています。
APIとは、システム同士が情報や機能をやり取りする窓口です。アプリで予約履歴を開くと、その裏でAPIへ照会し、返ってきた情報を画面に整える、といった構成があります。画面の見やすさと、その窓口で何を許すかは、担当する仕組みが異なります。
アプリの内部をわかりにくくすれば、解析の手間を増やすことはできるかもしれません。しかし、接続先が知られないことだけを前提に、情報へのアクセスを許してよいわけではありません。窓口に届いた要求を、サーバー自身が判断する必要があります。
この話を、特定のアプリ形式だけの問題として閉じない方がよいでしょう。同じく裏側のAPIを使うWebサービスや業務システムでも、正規の利用画面でしか要求が作られないという前提がないかを確認できます。
ログインできることと、対象を見てよいことは違う
冒頭のテストでは、Aとしてログインできたことを確かめていました。これは、要求を行う人が誰かを確認する認証に関係します。一方、Aがその予約履歴を見てよいかを判断するのが認可です。
会員情報へのアクセスでは、ログイン済みであることだけでは足りません。対象の記録がその人に属するか、その担当者が業務上参照できる範囲か、その操作が許されているかを判断する必要があります。本人確認の強化と、対象データの制約を同じものと考えないことが重要です。
個人情報保護委員会の注意喚起資料「WARNING」は、ログイン後の要求の値によって他の利用者の情報へアクセスできた事例を挙げ、認証に加え、対象データへの権限を都度確認する対策を示しています。
この公的な事例から導ける問いは明快です。利用者が誰かはわかっているとして、その人が見てよい記録の範囲は、どこで判定されているのでしょうか。画面、AI、API、データベースのうち、どこがその判断を確実に適用するのかを図にしてみます。
テスト表の一行を、誰が書き換えるべきか
想定場面のテスト担当者は、本人以外の情報は見えないという一行を、二つに分けられます。画面が本人の情報だけを表示することと、接続先が権限外の情報の取得を拒否することです。
この変更は、担当者にもっと高度な攻撃を試すよう求めるものではありません。許可されたテスト環境で、誰が何を取得できるべきかを明確にし、画面の結果に加えて接続先の判定も確かめるということです。実際の検証方法や範囲は、安全性と対象システムの条件を踏まえて合意します。
開発責任者が確認すべきなのは、正常な照会が通る証拠と、許可されない照会が通らない証拠の両方です。単に例外のメッセージが出たとしても、裏で情報を取得した後に表示を止めただけなら、参照を防いだ証拠にはなりません。
逆に、期待どおりに要求が拒否されたなら、画面上の不便だけで不具合と決め付けません。必要な権限がない操作を正しく止めた結果かもしれません。業務の要件と許可範囲を先に決めておく意味が、ここにあります。
見る、変える、まとめて取るを同じ許可にしない
APIの権限を確認するとき、利用できる・できないの二択では粗すぎることがあります。会員の氏名を参照すること、住所を変更すること、複数の履歴を出力することは、業務上の意味が違います。
例えば、窓口担当者が一人の予約を確認する権限を持つ想定でも、全会員の履歴を一括で取得できる必要はないでしょう。通常の業務で使う一件の処理を通すために、広い検索や出力まで許していないかを確認しておきましょう。
返す情報にも同じ問いが使えます。画面で必要なのが予約日時だけなら、住所や支払いに関する情報を同じ応答に含める必要があるでしょうか。表示しない項目だから問題ないという考え方では、情報が通る範囲を広げてしまいます。
利用回数の制限や監視は、この点検を補います。ただし、一度でも取得してはいけない情報があるなら、回数を少なくするだけでは権限の問題は解決しません。認可、返す情報の絞り込み、異常な量の検知を、それぞれの目的で組み合わせます。
古い窓口を残すと、新しい画面だけ直しても足りない
最初の問題が見つかり、担当チームが最新アプリ用のAPIを修正したとします。これで終えてよいかを考えるために、もう一段だけ想定場面を進めてみます。
旧版のアプリが使っていたAPIや、運用担当者だけが使う窓口はどうでしょうか。同じ会員データへ別の経路から届くなら、最新の画面で確認した結果だけでは、その経路を説明できません。
ここで必要なのは、画面の一覧を作ることより、対象の会員データへ届く窓口をたどる作業です。現在の利用者、必要な期間、付与している権限、管理する担当を一つずつ確かめます。使われていないと判断できれば、停止の影響を確認した上で閉じる選択もあります。
すぐに停止できない場合は、誰のために残し、どの条件で使わせるかを明確にします。利用状況を確認し、終了の条件と責任者を置きます。存在がわからないまま放置することと、必要性を判断して期限付きで管理することは違います。
AIをつないだとき、同じ境界を越えていないか
この教訓は、顧客対応AIにも当てはまります。利用者AがAIへ問い合わせたとき、裏側のツールが全会員を参照できるサービスID（システムの自動処理に使うID）で動く構成なら、画面でAとしてログインしているだけで十分とは言えません。
共有のサービスIDを使う構成を、一律に否定する必要はありません。ただし、その場合は利用者と対象をどこで結び付け、許されない参照を何が拒否するかを説明できるようにしておくことが大切です。AIへ本人の情報だけを見るよう指示したことと、接続先でその範囲に確実に制限したことは区別します。
以下は設計上の想定例です。AIが丁寧に正しい回答を返していても、内部で余分な会員情報を取得し、最終回答から除いていたらどうでしょうか。利用者から苦情がないことだけでは、不適切な参照がなかった証明にはなりません。
AI Librarium（AIL）が提案するのは、AIの回答、ツールの実行結果、接続先の認可判断を対応付けて見ることです。全部を一つの画面で自動判定できると約束するのではなく、実際の構成でどの証拠が取得できるかから、評価の仕方を決めます。
本人以外をすべて拒否すれば、業務は成立するか
ここまで読んで、本人以外の情報はすべて拒否すればよいと考えたなら、もう一つ確認しておきたい条件があります。実際の業務には、代理の手続き、家族の予約、窓口担当者による照会など、本人と操作する人が異なる場面もあります。
必要なのは、他人の情報を一切扱わないという固定ルールより、業務上許された関係を、どの条件で確認するかです。代理の範囲、有効な期間、許される操作、取消しの扱いを決め、それが接続先の判断に反映されるかを確かめます。
例えば、家族の予約日時を確認できることと、登録住所を変更できることは同じ許可でなくてもよいでしょう。家族という属性があるだけで全履歴を見せる必要もありません。誰をどの対象へ結び付けるかに加えて、許可する操作まで定義すると、過大な権限を避けやすくなります。
逆方向の試験も重要です。許可された代理の照会が止まった場合、エラーを消すためにサービスIDの権限を広げると、ほかの利用者へも影響するかもしれません。どの関係を確認できなかったのかを調べ、必要な範囲だけ直す方がよいでしょう。
冒頭のAのテスト表には、本人として許される照会、対象外として拒否すべき照会、条件付きで許される代理の照会という違いを残せます。それぞれに業務上の理由と期待する結果を付ければ、画面を作る人とAPIを管理する人が同じ許可範囲を共有できます。
AIに自然な言葉で依頼できるようになっても、この業務上の関係は省略できません。頼まれた内容がもっともらしいという判断と、代理の権限が成立しているという判断を分けます。便利な窓口を作るためにも、裏側の許可条件を先に明確にしておくことが大切です。
一つの会員照会を、四つの確認へ分ける
自社の点検を始めるなら、一件の会員照会について次の四つを確かめてみてください。
利用者を何で識別し、本人であることをどこで確認しているか。
接続先に届く要求は、誰のIDと権限で実行されるか。
参照する会員と許可された操作の範囲を、どこで制限するか。
許可と拒否の結果を、どの記録で確認できるか。
ここで答えが揃わなければ、設計書だけで決め付けず、開発と運用の担当者に同じ要求を追ってもらいます。設定が変わっていたり、設計書にない中継があったりすれば、それも点検の対象になります。実態が見えた上で、必要な修正と追加検証を選びます。
この確認は、アプリを何回操作したかでは完了しません。何を許し、何を拒否し、その結果を何で確かめたかが残って初めて、他の人にも説明できます。
公開アプリから個人情報へ届く経路は、画面の内側だけでは捉え切れません。アプリの正常な動作を確認する価値はそのままに、裏側の認可を独立した評価対象に置きます。次の開発レビューでは、テスト表の一行をその二つに分けるところから始めてはどうでしょうか。
参考情報
公表情報の確認基準日：2026年10月22日。登場するアプリと会議は設計・評価の想定例です。公表された攻撃類型を、根拠なく特定の被害企業の原因へ結び付けていません。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
