相次ぐ個人情報漏えいから考える ― 巨人の肩に乗り、システムの「主権」を取り戻す

2026 年の 9 月末から、個人情報の大規模な漏えいが連日のように報じられています。外食、旅行、小売、コンビニ、ゲーム、EC、クラウド。普段の生活で使うサービスばかりです。

この記事では、特定の企業を批判するのではなく、事例から「自分たちのシステムで何を確かめればよいか」を整理します。

先に結論を書きます。

• 巨人の肩に乗る：ID 管理（ログイン・パスワード・多要素認証）は自前で作らず、Microsoft Entra ID などの認証サービスに任せる
• 使う人で基盤を選ぶ：Microsoft 365 を使う社内の業務システムなら Code Apps、社外の顧客が使うシステムなら Azure（と Entra External ID）
• 主権を取り戻す：開発標準とセキュリティのテストケースを自社で持ち、委託先が作ったものも同じテストで受け入れる
• 続ける：攻撃は巧妙になり続けるので、テストと見直しを一度で終わらせず、運用として回す。その持ち主を AI CoE にする

この 1 か月で起きたこと#

JNN の集計では、企業の情報流出はこの 2 週間ほどで、判明しているだけでも最大 6200 万件あまりのおそれがあるとされました（10 月上旬時点）。セキュリティ会社のまとめでは、2026 年に漏えいした可能性のある個人情報は、のべ 1 億 6500 万人分余りにのぼります（NHK、10 月 16 日）。9 月 15 日から 10 月 22 日までに国内で公表された事案を83 件まとめた一覧もあります。

※件数は公表時点のものです。「漏えいした」ものと「漏えいのおそれ」が混ざっています。原因を調べている途中のものもあります。

ここで挙げた事案が、すべて同じ手口とは限りません

JPCERT/CC も、把握している情報は限られていて、すべての事案が同じ手口とは限らないと説明しています。この記事では「どの事案が何の原因か」を決めつけず、公表された経路から、自分たちが確かめるべきことを引き出すことに絞ります。

国と専門機関の注意喚起#

政府は 10 月 8 日に関係省庁会議を開き、9 日に大量の個人情報を扱う事業者へ脆弱性への速やかな対策などを要請しました。専門機関の注意喚起の要点は次のとおりです。

世界の調査でも同じ傾向#

Verizon の「データ侵害調査報告書（DBIR）」2026 年版でも、同じ傾向が数字で出ています。

48%

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

31%

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

39%

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

委託先、脆弱性、ID。日本の事案から見えるものと同じです。

事例から見える 5 つのパターン#

1. 会員・アカウントの仕組みが入口になる：外食、旅行、中古品小売、コンビニ、ゲームはいずれも、会員管理やアカウント、アプリの仕組みが起点でした。ログイン、パスワードの変更、本人の情報の表示、管理機能。ID の周りは、攻撃する側にとって最も効率のよい入口です
2. アプリと API の作りの弱さ：アプリを解析して API を見つけ、他人の情報を取る・権限を変える。EC プラットフォームでは、アプリケーションの脆弱性から不正なプログラムが動き続けていました
3. 委託先の「一時的な置き場所」：カラオケの事案では、委託先の PC 1 台に委託業務の個人データが置かれていました。自社のシステムを守るだけでは、データを守り切れません
4. 共有の基盤が止まる：クラウド事業者へのランサムウェアでは、495 の企業・自治体が影響を受けました。復元できるのは顧客が持っているバックアップだけ、という説明も出ています
5. 重い情報・古い情報が残っている：カーシェアリングでは、退会者の情報や免許証の画像も対象になりました。個人情報保護法第 22 条は、必要がなくなった個人データを遅滞なく消すよう努めることを求めています。持っていなければ、漏れようがありません

巨人の肩に乗る ― ID 管理は自前で作らない#

パターン 1 と 2 の多くは、ID とアクセス制御の周りで起きています。ここで考えたいのは、そもそも自分たちで作るべき部分なのかということです。

ログインの仕組みを自前で作ると、次のものを全部、自分たちで正しく作り、守り続けることになります。

• パスワードの安全な保存（ハッシュの方式・ソルト・強度の更新）
• 多要素認証とパスキー（フィッシングに強い方式）
• パスワードの再設定と、そのときの本人確認
• 総当たり・リスト型攻撃への回数制限とロック
• 怪しいサインインの検知（いつもと違う国・端末・時間）
• トークンの発行・期限・失効、セッションの管理
• 監査のログと、事故のときの調査

これは、世界中の攻撃を毎日受けながら改善を続けている ID の専門のサービスが、すでに提供しているものです。巨人の肩に乗るとは、ここを自分たちで作らず、専門のサービスに任せることです。

任せても、権限の設計は自分たちの仕事

ID のサービスが守ってくれるのは「誰か」を確かめるところまでです。その人に何を見せるか（認可）は、業務を知っている自分たちにしか決められません。パターン 2 の「他人の情報が取れる」「権限が変えられる」は、ここの設計とテストの問題です。

使う人で、乗る基盤を選ぶ#

どの「巨人」に乗るかは、そのシステムを誰が使うかで決めます。

社内の業務システムなら Code Apps#

Microsoft 365 を使っている会社の業務システムなら、Power Apps の Code Apps が第一の選択肢です。公式のドキュメントは、主な特長として次を挙げています。

• Microsoft Entra による認証と認可
• 組織の管理された基盤のポリシー（共有の制限・条件付きアクセス・DLP など）に従う
• Power Platform の上で公開・ホストできる

マネージド環境では、アプリごとに条件付きアクセスを設定できます。個人データを扱うアプリだけ、フィッシングに強い多要素認証を求める、といった使い分けができます。

Code Apps でも気を付けること

公開したアプリのファイル（画面のプログラム）は、公開されたエンドポイントから配信されます。機密のデータやキーをアプリの中に入れず、サインインと権限の確認を通ったあとにデータソース（Dataverse など）から取る作りにします。場所や IP で絞るときは、条件付きアクセスを使います。

インフラの保守を Microsoft に任せられる点は、以前の記事で責任の範囲の図とともにまとめました。

Code Apps で「SaaS 製造」― 買っているシステムを作り直してコストを下げる試算の考え方毎年払う SaaS の利用料や委託の保守費を、GitHub Copilot と Power Apps の Code Apps で作ったアプリに置き換える「SaaS 製造」。対象にするシステムの見分け方、インフラと守りを任せられる理由、最近の Web の侵害、Premium を土台にしたコストの試算と KPI の優先順位を、グラフと例で紹介します。2026.10.27

社外向けなら Azure と Entra External ID#

顧客や一般の人が会員登録するサービスは、Azure で作り、サインインは Microsoft Entra External ID に任せます。セルフサービスのサインアップ、メールとパスワード・ワンタイムパスコード・Google などのアカウントでのサインイン、ブランドに合わせたサインインの画面を、Entra のセキュリティの上で使えます。顧客のアカウントは、社員のテナントとは分けた「外部テナント」で管理します。

Azure AD B2C を使っている場合

前の世代の Azure AD B2C は、2025 年 5 月 1 日から新しい顧客への販売を終えています。新しく作るなら Entra External ID です。

主権を取り戻す ― 「分からないまま」の委託と受け入れをやめる#

ここからが、この記事で一番伝えたいことです。

漏えいが起きたとき、委託元も委託先も「何がどう作られていたのか」を説明できない。そんな状態になっていないでしょうか。

• 設計書と納品物はあるが、どんなセキュリティのテストをして、何が合格だったのかを誰も説明できない
• パスワードをどう保存しているか、ログがどこに何日残るかを、委託元が知らない
• 委託先の担当者が変わるたびに、作り方が変わる
• 受け入れの検査は、画面が仕様どおりに動くかだけを見ている

これは委託そのものが悪いのではありません。何を守るべきか、何をもって合格とするかを、委託元が持っていないことが問題です。

主権を取り戻すとは、次の 3 つを自社で持つことです。

1. 開発標準：どの基盤に乗るか（Code Apps か Azure か）、認証は何に任せるか、秘密をどこに置くか、ログを何日残すか。セキュリティのチェックを含めて、自社の言葉で書く
2. テストケース：何をもって「安全」とするかを、確かめられる形で持つ（次の章）
3. 受け入れの基準：自社で作っても委託先が作っても、同じテストに合格したものだけを本番に出す

開発標準を一から書く必要はありません。私が公開している「AI ファースト開発標準」を土台に、自社の規程を足していく方法を別の記事で紹介しています。GitHub Copilot に標準を読ませれば、標準に沿った実装とテストを一緒に進められます。

AI ファースト開発標準で始める Code Apps 開発 ― 外注費の削減を内製で実現する手法（2026 年 10 月版）GitHub で公開している AI ファースト開発標準を、2026 年 10 月の内容で解説します。「クイックスタートして」から始める開発の流れ、27 のスキルと 20 の業務サンプル、管理者と開発者の準備、AI CoE が自社の標準として持つ方法を、外注費の削減・Code Apps とのつながりとあわせて図で紹介します。2026.08.12

事例から作るテストケース#

公表された経路をもとに、自分たちのシステムで確かめるテストケースにしました。「自社のシステムは、これに合格するか」を、自社で作ったものにも委託先が作ったものにも当ててみてください。

「巨人の肩」に乗ると、表の半分は最初から満たせる

ログインの回数制限、パスワードの再設定、多要素認証、怪しいサインインの検知は、Entra ID・Entra External ID に任せれば、自分たちで作らずに合格できます。自分たちが力を入れるのは、他人の情報を返さない・権限を変えさせない・秘密を入れない、という「認可」と「作り」の部分です。

国際的な基準では、OWASP Top 10 の 2025 年版でも、1 位は「アクセス制御の不備」、7 位は「認証の失敗」です。上の表は、ちょうどこの 2 つを日本の事例で具体にしたものです。

自社のシステムは準拠しているか#

テストケースは、作って終わりではありません。システムごとに、次の問いに「はい」と答えられるかを確かめます。

• すべての業務システムの一覧があり、それぞれが個人データを持つかが分かる
• ログインは Entra ID / Entra External ID に任せていて、自前のパスワードの表がない
• 上のテストケースを、システムごとに実行した結果（いつ・誰が・合否）が残っている
• 委託先が作ったシステムも、同じテストケースで受け入れている
• 新しく変更を出すたびに、テストが自動で回る
• 事故のときの連絡先と手順が、紙 1 枚にまとまっている

Web の侵害は巧妙になる ― 続けられるか#

注意喚起にあったとおり、AI を使ってアプリの解析や脆弱性の探索を効率よく進めるリスクが指摘されています。攻撃する側の手間が下がると、一度テストに合格したシステムも、来月は合格しないかもしれません。

だから、テストは「納品のときに 1 回」では足りません。運用として回し続けます。

flowchart LR
  A[脆弱性・注意喚起の情報を集める] --> B[テストケースを足す・直す]
  B --> C[変更のたびに自動で実行]
  C --> D[ログと検知で見張る]
  D --> E[事故・訓練から学ぶ]
  E --> A

• 毎日：ログと検知のアラートを見る。重大な脆弱性の情報（JPCERT/CC・IPA など）を追う
• 変更のたび：テストケースを CI（GitHub Actions など）で自動で回し、落ちたら本番に出さない
• 月に 1 回：委託先・外部のアカウント・使っていないデータを棚卸しして消す
• 四半期に 1 回：テストケースを新しい事例で見直す。復元の訓練をする。必要なら外部の診断を受ける

ここで AI が味方になります。GitHub Copilot に開発標準とテストケースを読ませれば、テストのコードを書く、依存関係の脆弱性を直す、ログを調べる、といった作業を、少ない人数でも続けられます。攻撃する側が AI で効率を上げるなら、守る側も AI で効率を上げる必要があります。

AI CoE が「主権」の持ち主になる#

ここまでの「開発標準」「テストケース」「受け入れの基準」「続ける運用」は、誰が持つべきでしょうか。

部署ごと、委託先ごとにばらばらに持つと、また「分からないまま」に戻ります。全社で 1 つの標準を持ち、更新し続ける役が必要です。それが AI CoE（AI の推進の中心の組織）の役割だと考えています。

AI CoE の立ち上げ方と、読む順番は次の記事にまとめています。

AI CoE のジャーニー ― 本部と事業部に分かれ、予算を持つ部門で外注費を内製で減らすAI CoE の概要と、これからの形をまとめます。本部 AI CoE が標準と基盤を持ち、事業部 AI CoE が自分の予算に載っている外注費を内製で減らす。JUAS・IPA・Gartner の調査結果と図で、AI CoE のジャーニーと、担当者が読む記事の順番を紹介します。2026.10.27

外注費の削減を最初の成果にする考え方と、パートナー企業との関わり方はこちらです。

AI CoE の最初の KPI は「外注費の削減」― 現場のユースケースから始めないAI を使った開発で、AI CoE は自社でアプリを作れるようになりました。最初にやるべきことは、現場からユースケースを集めることではありません。外注費を棚卸しし、内製できるものから削減額を経営に見せることです。2026.10.27 AI CoE の内製化で、パートナー企業はどうすればいいのか ― 人月から「顧問」へユーザー企業の AI CoE が内製を始めると、多重下請けと人月のビジネスは縮みます。一方で、AI CoE の立ち上げ支援、Cowork スキルハッカソン、レビューや保守の「顧問」のビジネスが生まれます。FDE との違い、フルスタックビルダー、サブスクリプションの指標を図と例で紹介します。2026.10.27

自分が「利用者」の側だったら#

• お詫びや案内のメールが届いても、メールのリンクからログインしない。公式アプリや、自分で登録したブックマークから確かめる
• 同じパスワードを使い回しているサービスは、パスワードを変える。使えるところはパスキーにする
• 氏名・電話番号・メールアドレスが漏れると、なりすましの SMS やメールが増えやすい。見覚えのない連絡には返信しない
• 免許証の画像などの流出が確認されたら、名義の悪用に備えて、信用情報機関への本人申告も考える

まとめ#

今回の事案から見えるのは、新しい攻撃への備えより先に、「自分たちのシステムを、自分たちで説明できるか」が問われているということです。

1. ID 管理は自前で作らず、Entra ID・Entra External ID という巨人の肩に乗る
2. 社内の業務システムは Code Apps、外向けのサービスは Azure で作る
3. 開発標準とテストケースを自社で持ち、委託先が作ったものも同じテストで受け入れる
4. 攻撃は巧妙になり続けるので、テストと見直しを運用として回す
5. その持ち主を AI CoE にする

委託をやめる必要はありません。何を守り、何をもって合格とするかを、自分たちの手に取り戻す。そこから始めてみてください。

---

参考#

• 個人情報保護委員会：大規模な漏えい等事案を踏まえた対応について（注意喚起）
• JPCERT/CC の注意喚起の報道（ScanNetSecurity）
• 各機関の注意喚起のまとめ（国家サイバー統括室）
• 国内で相次ぐ不正アクセスに対する注意喚起のまとめ（piyolog）
• 政府による事業者への要請（NHK、10 月 9 日）
• 2026 Verizon DBIR: Third-Party Risk Is Now Breach Risk（Safe Security）
• OWASP Top 10:2025
• Power Apps code apps overview（Microsoft Learn）
• Microsoft Entra External ID の概要（Microsoft Learn）

メルマガで新しい記事を受け取る

新しい記事や講座のお知らせを、メールでお届けします。いつでも配信を停止できます。

メールアドレスお名前（任意）登録する

Website

ご登録いただいたアドレスは、メルマガの配信にだけ使います。

あわせて学びたいオンライン講座

どの講座から始めればよいか、学ぶ順番をまとめています。

ギークフジワラ式：Power Platform ＆ Copilot 学習ロードマップギークフジワラでは、初心者からプロまでをサポートする包括的なコンテンツの作成を目指しています。 本記事では、少しコースが増えてきたので推奨するラーニングパス (学習の順番)をご紹介…2025.05.16