業種ごとの漏えい（おそれを含む）の規模

--- title: "相次ぐ個人情報漏えいから考える ― 巨人の肩に乗り、システムの「主権」を取り戻す" url: "https://www.geekfujiwara.com/ai-coe/8659/" author: ギークフジワラ published: "2026-10-27T23:09:47+00:00" updated: "2026-10-27T23:28:41+00:00" categories: [AI CoE] tags: [AI CoE, Code apps, Microsoft Entra, セキュリティ, 個人情報保護, 開発標準] description: "2026 年秋に相次いだ個人情報の漏えいを、社名を伏せて業種ごとに整理しました。ID 管理を自前で作らず Entra ID に任せること、自社の開発標準とテストケースを持つこと、継続して運用することを、事例とテストケースとともに解説します。AI CoE が担う役割にもつなげます。" --- # 相次ぐ個人情報漏えいから考える ― 巨人の肩に乗り、システムの「主権」を取り戻す 2026 年の 9 月末から、個人情報の大規模な漏えいが連日のように報じられています。外食、旅行、小売、コンビニ、ゲーム、EC、クラウド。普段の生活で使うサービスばかりです。この記事では、特定の企業を批判するのではなく、==事例から「自分たちのシステムで何を確かめればよいか」==を整理します。先に結論を書きます。 {.check} - **巨人の肩に乗る**：ID 管理（ログイン・パスワード・多要素認証）は自前で作らず、Microsoft Entra ID などの認証サービスに任せる - **使う人で基盤を選ぶ**：Microsoft 365 を使う社内の業務システムなら Code Apps、社外の顧客が使うシステムなら Azure（と Entra External ID） - **主権を取り戻す**：開発標準とセキュリティのテストケースを自社で持ち、委託先が作ったものも同じテストで受け入れる - **続ける**：攻撃は巧妙になり続けるので、テストと見直しを一度で終わらせず、運用として回す。その持ち主を AI CoE にする ## この 1 か月で起きたこと JNN の集計では、企業の情報流出はこの 2 週間ほどで、判明しているだけでも[最大 6200 万件あまりのおそれ](https://news.infoseek.co.jp/article/tbs_3002456/)があるとされました（10 月上旬時点）。セキュリティ会社のまとめでは、2026 年に漏えいした可能性のある個人情報は、[のべ 1 億 6500 万人分余り](https://news.web.nhk/newsweb/na/nd-20261016de60239)にのぼります（NHK、10 月 16 日）。9 月 15 日から 10 月 22 日までに国内で公表された事案を[83 件](https://plastic-pallet.co.jp/joho-roei-ichiran-2026-10/)まとめた一覧もあります。 :::raw

報道をもとに作成。EC プラットフォームは人数、ほかは件数。調査の進展で変わることがあります。

::: | 業種 | 規模（公表時点） | 経路・特徴 | | --- | --- | --- | | [EC プラットフォーム](https://scan.netsecurity.ne.jp/article/2026/08/28/56060.html) | 約 2,336 万人（約 7,900 店の購入者） | サーバーのアプリケーションの脆弱性を突かれ、不正なプログラムが 2 か月以上データベースの情報を外へ送っていた | | [旅行予約サイト](https://atmarkit.itmedia.co.jp/ait/articles/2610/13/news037.html) | 約 1,464 万件（うち約 413 万件にハッシュ化パスワード） | 3 つの経路。管理機能が不正に操作され、ほかのサーバーやクラウドのデータに届いた | | [ゲームの共通 ID](https://gamebusiness.jp/article/2026/10/23/28420.html) | 約 1,177 万件（主にメールアドレス） | 196 件でパスワードが不正に変更されていた | | [外食チェーン](https://weekly.ascii.jp/elem/000/004/440/4440100/) | 約 1,078 万件 | 公式アプリの会員管理システム | | [カラオケ](https://internet.watch.impress.co.jp/docs/news/2147032.html) | 約 872 万件のおそれ | 委託先の従業員の PC 1 台がマルウェアに感染。委託業務で一時的に置かれていた個人データ | | [カーシェアリング](https://www.ben54.jp/news/3980) | 約 660 万件（退会者を含む）。うち約 160 万件で免許証の画像など | Web システムへの不正アクセス | | [中古品小売](https://kumanichi.com/articles/2044802) | 最大約 643 万件 | 子会社が運営する会員管理システム | | [コンビニ](https://atmarkit.itmedia.co.jp/ait/articles/2610/16/news020.html) | 約 215 万件 | アプリに関係する、本人に情報を表示する仕組みが不正に使われた | | [クラウド事業者](https://www.watch.impress.co.jp/docs/news/2146693.html) | 495 の企業・自治体に影響 | ランサムウェア。一部は復元が難しく、顧客側のバックアップからだけ復元できると説明 | ※件数は公表時点のものです。「漏えいした」ものと「漏えいのおそれ」が混ざっています。原因を調べている途中のものもあります。 > [!NOTE] ここで挙げた事案が、すべて同じ手口とは限りません > JPCERT/CC も、把握している情報は限られていて、すべての事案が同じ手口とは限らないと説明しています。この記事では「どの事案が何の原因か」を決めつけず、==公表された経路から、自分たちが確かめるべきことを引き出す==ことに絞ります。 ## 国と専門機関の注意喚起政府は 10 月 8 日に[関係省庁会議](https://kumanichi.com/articles/2044438)を開き、9 日に大量の個人情報を扱う事業者へ[脆弱性への速やかな対策などを要請](https://news.web.nhk/newsweb/na/nd-20261009de57110)しました。専門機関の注意喚起の要点は次のとおりです。 | 発信元 | 要点 | | --- | --- | | [個人情報保護委員会](https://www.ppc.go.jp/news/press/2026/261007_houdou/)（10 月 7 日） | 2027 年 4 月に確定する予定のガイドライン（技術的安全管理措置）の見直しを先に示した。権限の最小化、フィッシングに強い多要素認証、脆弱性への対応、ログの保存と分析、EDR などによる検知と隔離、不要な個人データの消去。典型事例に「API が悪用される事例」を加え、[9 つ](https://rocket-boys.co.jp/?p=42842)にした | | [JPCERT/CC](https://scan.netsecurity.ne.jp/article/2026/10/13/56428.html)（10 月 8 日） | 3 つの類型。① 既知の脆弱性や機器の管理の不備を狙ったスキャン ② 公開されているスマートフォンのアプリを解析して API とキーを特定し、内部の API で権限を変えたり不正なアカウントを作ったりする ③ BI ツールの既知の脆弱性（認証なしで管理者の権限を取られるおそれ）。API の回数制限、非公開の API も含めたアクセス制御、権限の最小化を推奨 | | [NICT CYNEX](https://smartscope.blog/blog/jpcert-domestic-unauthorized-access-alert-api-2026/)（10 月 13 日） | AI を使うことで、アプリの解析や脆弱性の探索が効率よくなるリスクに触れた | ### 世界の調査でも同じ傾向 Verizon の「データ侵害調査報告書（DBIR）」2026 年版でも、同じ傾向が数字で出ています。 :::raw

48%

侵害のうち、第三者（委託先・取引先・SaaS）が関わったもの。前の年の 30% から増えた

31%

最初の入口が脆弱性の悪用だったもの。初めて 1 位になった

39%

攻撃の途中のどこかで認証情報の悪用があったもの（最初の入口としては 13%）

出典：Safe Security、SecurityInfoWatch による 2026 Verizon DBIR の解説

::: 委託先、脆弱性、ID。日本の事案から見えるものと同じです。 ## 事例から見える 5 つのパターン {.steps} 1. **会員・アカウントの仕組みが入口になる**：外食、旅行、中古品小売、コンビニ、ゲームはいずれも、会員管理やアカウント、アプリの仕組みが起点でした。ログイン、パスワードの変更、本人の情報の表示、管理機能。==ID の周りは、攻撃する側にとって最も効率のよい入口==です 2. **アプリと API の作りの弱さ**：アプリを解析して API を見つけ、他人の情報を取る・権限を変える。EC プラットフォームでは、アプリケーションの脆弱性から不正なプログラムが動き続けていました 3. **委託先の「一時的な置き場所」**：カラオケの事案では、委託先の PC 1 台に委託業務の個人データが置かれていました。自社のシステムを守るだけでは、データを守り切れません 4. **共有の基盤が止まる**：クラウド事業者へのランサムウェアでは、495 の企業・自治体が影響を受けました。復元できるのは顧客が持っているバックアップだけ、という説明も出ています 5. **重い情報・古い情報が残っている**：カーシェアリングでは、退会者の情報や免許証の画像も対象になりました。個人情報保護法第 22 条は、必要がなくなった個人データを遅滞なく消すよう努めることを求めています。==持っていなければ、漏れようがありません== ## 巨人の肩に乗る ― ID 管理は自前で作らないパターン 1 と 2 の多くは、ID とアクセス制御の周りで起きています。ここで考えたいのは、==そもそも自分たちで作るべき部分なのか==ということです。ログインの仕組みを自前で作ると、次のものを全部、自分たちで正しく作り、守り続けることになります。 {.circle} - パスワードの安全な保存（ハッシュの方式・ソルト・強度の更新） - 多要素認証とパスキー（フィッシングに強い方式） - パスワードの再設定と、そのときの本人確認 - 総当たり・リスト型攻撃への回数制限とロック - 怪しいサインインの検知（いつもと違う国・端末・時間） - トークンの発行・期限・失効、セッションの管理 - 監査のログと、事故のときの調査これは、世界中の攻撃を毎日受けながら改善を続けている ID の専門のサービスが、すでに提供しているものです。==巨人の肩に乗る==とは、ここを自分たちで作らず、専門のサービスに任せることです。 :::raw

::: > [!IMPORTANT] 任せても、権限の設計は自分たちの仕事 > ID のサービスが守ってくれるのは「誰か」を確かめるところまでです。==その人に何を見せるか（認可）は、業務を知っている自分たちにしか決められません。==パターン 2 の「他人の情報が取れる」「権限が変えられる」は、ここの設計とテストの問題です。 ## 使う人で、乗る基盤を選ぶどの「巨人」に乗るかは、そのシステムを誰が使うかで決めます。 :::raw

::: ### 社内の業務システムなら Code Apps Microsoft 365 を使っている会社の業務システムなら、Power Apps の Code Apps が第一の選択肢です。[公式のドキュメント](https://learn.microsoft.com/power-apps/developer/code-apps/overview)は、主な特長として次を挙げています。 {.check} - Microsoft Entra による認証と認可 - 組織の管理された基盤のポリシー（共有の制限・条件付きアクセス・DLP など）に従う - Power Platform の上で公開・ホストできる [マネージド環境では、アプリごとに条件付きアクセス](https://learn.microsoft.com/power-platform/admin/admin-manage-apps#managed-environments-conditional-access-on-individual-apps)を設定できます。個人データを扱うアプリだけ、フィッシングに強い多要素認証を求める、といった使い分けができます。 > [!WARNING] Code Apps でも気を付けること > 公開したアプリのファイル（画面のプログラム）は、[公開されたエンドポイントから配信](https://learn.microsoft.com/power-apps/developer/code-apps/system-limits-configuration)されます。==機密のデータやキーをアプリの中に入れず、サインインと権限の確認を通ったあとにデータソース（Dataverse など）から取る==作りにします。場所や IP で絞るときは、条件付きアクセスを使います。インフラの保守を Microsoft に任せられる点は、以前の記事で責任の範囲の図とともにまとめました。 https://www.geekfujiwara.com/tech/powerplatform/9527/ ### 社外向けなら Azure と Entra External ID 顧客や一般の人が会員登録するサービスは、Azure で作り、サインインは [Microsoft Entra External ID](https://learn.microsoft.com/entra/external-id/customers/overview-customers-ciam) に任せます。セルフサービスのサインアップ、メールとパスワード・ワンタイムパスコード・Google などのアカウントでのサインイン、ブランドに合わせたサインインの画面を、Entra のセキュリティの上で使えます。顧客のアカウントは、社員のテナントとは分けた「外部テナント」で管理します。 > [!NOTE] Azure AD B2C を使っている場合 > 前の世代の Azure AD B2C は、[2025 年 5 月 1 日から新しい顧客への販売を終えています](https://learn.microsoft.com/entra/external-id/tenant-configurations#external-tenants)。新しく作るなら Entra External ID です。 ## 主権を取り戻す ― 「分からないまま」の委託と受け入れをやめるここからが、この記事で一番伝えたいことです。漏えいが起きたとき、委託元も委託先も「何がどう作られていたのか」を説明できない。そんな状態になっていないでしょうか。 {.point} - 設計書と納品物はあるが、==どんなセキュリティのテストをして、何が合格だったのか==を誰も説明できない - パスワードをどう保存しているか、ログがどこに何日残るかを、委託元が知らない - 委託先の担当者が変わるたびに、作り方が変わる - 受け入れの検査は、画面が仕様どおりに動くかだけを見ているこれは委託そのものが悪いのではありません。==何を守るべきか、何をもって合格とするかを、委託元が持っていない==ことが問題です。 :::raw

::: 主権を取り戻すとは、次の 3 つを自社で持つことです。 {.steps} 1. **開発標準**：どの基盤に乗るか（Code Apps か Azure か）、認証は何に任せるか、秘密をどこに置くか、ログを何日残すか。セキュリティのチェックを含めて、自社の言葉で書く 2. **テストケース**：何をもって「安全」とするかを、確かめられる形で持つ（次の章） 3. **受け入れの基準**：自社で作っても委託先が作っても、同じテストに合格したものだけを本番に出す開発標準を一から書く必要はありません。私が公開している「AI ファースト開発標準」を土台に、自社の規程を足していく方法を別の記事で紹介しています。GitHub Copilot に標準を読ませれば、標準に沿った実装とテストを一緒に進められます。 https://www.geekfujiwara.com/tech/powerplatform/8554/ ## 事例から作るテストケース公表された経路をもとに、自分たちのシステムで確かめるテストケースにしました。==「自社のシステムは、これに合格するか」==を、自社で作ったものにも委託先が作ったものにも当ててみてください。 | 事例のパターン | テストケース | 合格の条件 | | --- | --- | --- | | 管理機能が不正に操作された（旅行予約） | 一般の利用者のトークンで、管理の画面・管理の API を呼ぶ | すべて拒否される（403）。管理の画面はインターネットから直接届かないか、条件付きアクセスで絞られている | | アプリを解析して API とキーを特定（注意喚起） | 公開しているアプリ・画面のプログラムの中に、API のキーや秘密が入っていないかを調べる | 秘密が 1 つも入っていない。秘密は Key Vault かサーバー側にだけある | | 内部の API で権限を変える・不正なアカウントを作る（注意喚起） | 自分のアカウントの更新の API に `role=admin` などの項目を足して送る。登録の API を直接呼ぶ | 権限は変わらない。決められた手順を通らない登録はできない | | 本人の情報を表示する仕組みが不正に使われた（コンビニ） | ログインした人が、URL や API の会員番号を他人のものに変えて呼ぶ | 他人の情報は返らない（ID ごとに持ち主を確かめている） | | 大量の取得・総当たり | 同じ API を短い時間に何千回も呼ぶ。ログインを何百回も失敗させる | 回数制限で止まる（429）。ログインは ID のサービスがロック・検知する | | パスワードが不正に変更された（ゲームの共通 ID） | パスワードの再設定を、メールアドレスだけで進められるかを試す | 多要素認証か、本人に届く確認が要る。変更したら本人に知らせる。ここは ID のサービスの標準の機能で満たす | | アプリケーションの脆弱性から不正なプログラムが動いた（EC プラットフォーム） | 使っているライブラリ・ミドルウェアの既知の脆弱性を調べる。アップロードしたファイルが実行されるかを試す | 重大な既知の脆弱性がない。アップロードしたものは実行されない | | 管理のツールの既知の脆弱性（注意喚起） | 外からポートと URL を調べ、管理用のツール（BI・DB 管理など）が公開されていないかを見る | 公開されていない。緊急のパッチを決めた日数の中で当てられる | | データが外へ送られ続けた（EC プラットフォーム） | ふだんより多い件数の取得や、外への大きな送信を起こしてみる | アラートが鳴る。誰が・いつ・何件を、ログで追える | | 委託先の PC に個人データが置かれた（カラオケ） | 委託先のアカウントで、個人データを手元にダウンロード・コピーできるかを試す | DLP などで止まる。委託先のアカウントは期限つきで、終わったら消える | | 共有の基盤が止まった（クラウド事業者） | 自分たちのバックアップだけで、別の場所に復元する | 決めた時間の中で復元できる。バックアップは書き換えられない場所にある | | 退会者・本人確認の画像が残っていた（カーシェアリング） | 保存の期限を過ぎたデータの件数を数える | 0 件。本人確認の画像は、確認が済んだら消える | > [!TIP] 「巨人の肩」に乗ると、表の半分は最初から満たせる > ログインの回数制限、パスワードの再設定、多要素認証、怪しいサインインの検知は、Entra ID・Entra External ID に任せれば、==自分たちで作らずに合格できます==。自分たちが力を入れるのは、他人の情報を返さない・権限を変えさせない・秘密を入れない、という「認可」と「作り」の部分です。国際的な基準では、OWASP Top 10 の 2025 年版でも、[1 位は「アクセス制御の不備」、7 位は「認証の失敗」](https://owasp.org/Top10/2025/ja/)です。上の表は、ちょうどこの 2 つを日本の事例で具体にしたものです。 ### 自社のシステムは準拠しているかテストケースは、作って終わりではありません。システムごとに、次の問いに「はい」と答えられるかを確かめます。 - [ ] すべての業務システムの一覧があり、それぞれが個人データを持つかが分かる - [ ] ログインは Entra ID / Entra External ID に任せていて、自前のパスワードの表がない - [ ] 上のテストケースを、システムごとに実行した結果（いつ・誰が・合否）が残っている - [ ] 委託先が作ったシステムも、同じテストケースで受け入れている - [ ] 新しく変更を出すたびに、テストが自動で回る - [ ] 事故のときの連絡先と手順が、紙 1 枚にまとまっている ## Web の侵害は巧妙になる ― 続けられるか注意喚起にあったとおり、AI を使ってアプリの解析や脆弱性の探索を効率よく進めるリスクが指摘されています。攻撃する側の手間が下がると、==一度テストに合格したシステムも、来月は合格しないかもしれません==。だから、テストは「納品のときに 1 回」では足りません。運用として回し続けます。 ```mermaid flowchart LR A[脆弱性・注意喚起の情報を集める] --> B[テストケースを足す・直す] B --> C[変更のたびに自動で実行] C --> D[ログと検知で見張る] D --> E[事故・訓練から学ぶ] E --> A ``` {.check} - **毎日**：ログと検知のアラートを見る。重大な脆弱性の情報（JPCERT/CC・IPA など）を追う - **変更のたび**：テストケースを CI（GitHub Actions など）で自動で回し、落ちたら本番に出さない - **月に 1 回**：委託先・外部のアカウント・使っていないデータを棚卸しして消す - **四半期に 1 回**：テストケースを新しい事例で見直す。復元の訓練をする。必要なら外部の診断を受けるここで AI が味方になります。GitHub Copilot に開発標準とテストケースを読ませれば、テストのコードを書く、依存関係の脆弱性を直す、ログを調べる、といった作業を、少ない人数でも続けられます。攻撃する側が AI で効率を上げるなら、守る側も AI で効率を上げる必要があります。 ## AI CoE が「主権」の持ち主になるここまでの「開発標準」「テストケース」「受け入れの基準」「続ける運用」は、誰が持つべきでしょうか。部署ごと、委託先ごとにばらばらに持つと、また「分からないまま」に戻ります。==全社で 1 つの標準を持ち、更新し続ける役==が必要です。それが AI CoE（AI の推進の中心の組織）の役割だと考えています。 | AI CoE が持つもの | この記事との関係 | | --- | --- | | 開発標準（Code Apps と Azure の使い分け、認証は Entra に任せる） | 巨人の肩に乗る | | セキュリティのテストケースと受け入れの基準 | 主権を取り戻す | | CI と運用の仕組み（自動のテスト・ログ・棚卸し） | 続けられるか | | 委託先・パートナーとの共通のルール | 委託先の盲点をなくす | AI CoE の立ち上げ方と、読む順番は次の記事にまとめています。 https://www.geekfujiwara.com/ai-coe/9549/ 外注費の削減を最初の成果にする考え方と、パートナー企業との関わり方はこちらです。 https://www.geekfujiwara.com/ai-coe/9485/ https://www.geekfujiwara.com/ai-coe/9553/ ## 自分が「利用者」の側だったら {.circle} - お詫びや案内のメールが届いても、メールのリンクからログインしない。公式アプリや、自分で登録したブックマークから確かめる - 同じパスワードを使い回しているサービスは、パスワードを変える。使えるところはパスキーにする - 氏名・電話番号・メールアドレスが漏れると、なりすましの SMS やメールが増えやすい。見覚えのない連絡には返信しない - 免許証の画像などの流出が確認されたら、名義の悪用に備えて、信用情報機関への本人申告も考える ## まとめ今回の事案から見えるのは、新しい攻撃への備えより先に、==「自分たちのシステムを、自分たちで説明できるか」==が問われているということです。 {.steps} 1. ID 管理は自前で作らず、Entra ID・Entra External ID という巨人の肩に乗る 2. 社内の業務システムは Code Apps、外向けのサービスは Azure で作る 3. 開発標準とテストケースを自社で持ち、委託先が作ったものも同じテストで受け入れる 4. 攻撃は巧妙になり続けるので、テストと見直しを運用として回す 5. その持ち主を AI CoE にする委託をやめる必要はありません。==何を守り、何をもって合格とするかを、自分たちの手に取り戻す。==そこから始めてみてください。 --- ### 参考 - [個人情報保護委員会：大規模な漏えい等事案を踏まえた対応について（注意喚起）](https://www.ppc.go.jp/news/press/2026/261007_houdou/) - [JPCERT/CC の注意喚起の報道（ScanNetSecurity）](https://scan.netsecurity.ne.jp/article/2026/10/13/56428.html) - [各機関の注意喚起のまとめ（国家サイバー統括室）](https://www.cyber.go.jp/news/20261014.html) - [国内で相次ぐ不正アクセスに対する注意喚起のまとめ（piyolog）](https://piyolog.hatenadiary.jp/entry/2026/10/11/004353) - [政府による事業者への要請（NHK、10 月 9 日）](https://news.web.nhk/newsweb/na/nd-20261009de57110) - [2026 Verizon DBIR: Third-Party Risk Is Now Breach Risk（Safe Security）](https://safe.security/resources/reports-research/2026-verizon-dbir-third-party-risk-is-now-breach-risk/) - [OWASP Top 10:2025](https://owasp.org/Top10/2025/ja/) - [Power Apps code apps overview（Microsoft Learn）](https://learn.microsoft.com/power-apps/developer/code-apps/overview) - [Microsoft Entra External ID の概要（Microsoft Learn）](https://learn.microsoft.com/entra/external-id/customers/overview-customers-ciam)