個人情報保護委員会が示した不正アクセス９類型―API，クラウド，グループ会社，個人領域及びログ管理（AI作成）

第１　本記事の対象と資料の位置付け

１　令和８年１０月７日の個人情報保護委員会資料

個人情報保護委員会は，令和８年１０月７日の第３７１回会合で，「大規模な漏えい等事案を踏まえた対応について（注意喚起）」と改訂版「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」を公表した。
後者は，委員会に報告された不正アクセス事案の問題を９類型に整理し，原因と対策例を示している。

本記事は，この９類型を，一般企業だけでなく，弁護士，司法書士及び税理士の事務所で使える点検項目に置き換えるものである。
令和８年１０月１６日時点の公表資料に基づき，個別のシステムを安全と判定するものではない。

２　法的な拘束力と例示の区別

個人情報保護委員会の注意喚起は，法２３条の安全管理措置を具体化する際の重要な行政資料であるが，資料に並ぶ全ての技術を全事業者に一律に義務付けるものではない。
「講じなければならない措置」と「手法の例示」を分け，事業の規模・性質，データの性質・量，リスク及び当時の技術水準に即して必要かつ適切な方法を選ぶ必要がある。

第２　現行法と技術的安全管理措置の見直し予定

１　法２２条から２５条までを一体で見る

個人情報保護法２２条は，個人データを正確かつ最新の内容に保つとともに，利用する必要がなくなったときの遅滞ない消去について努力義務を定める。
同法２３条の安全管理措置，２４条の従業者の監督及び２５条の委託先の監督は，保有するデータと関係者を抽象的に管理するのではなく，資産台帳，保存場所，アクセス権限，委託関係及び消去時期に落とす必要がある。

２　現行の４項目と将来の第５項目

令和８年１０月時点のガイドライン通則編は，技術的安全管理措置の「講じなければならない措置」を，①アクセス制御，②アクセス者の識別と認証，③外部からの不正アクセス等の防止，④情報システムの使用に伴う漏えい等の防止としている。

同委員会の令和８年１０月７日の注意喚起は，見直し内容の確定を令和９年４月に予定していると説明し，その予定内容を先取りする形で，⑤不正アクセス等の検知等を示している。
この時点で示された予定を，令和９年４月からの適用開始が確定したとの説明に置き換えない。
認証ログ，アクセスログ，操作ログ及び通信ログの保存・保護・定期分析，IDS/IPSやEDR等による早期検知，侵害システムの停止・隔離及びアカウント無効化が例示されているが，確定前の見直し予定と現行ガイドラインを混同してはならない。

第３　不正アクセス９類型と対策

１　脆弱性が放置された事例

システム導入の契約だけで保守契約がない，保守契約に脆弱性対応が含まれない，又は対応の役割分担が未定であると，公開された脆弱性と修正情報があっても対応が止まる。
貸与品を含むIT資産の棚卸し，脆弱性情報の収集・分析，対処者と期限，終了確認までを一つのプロセスとして決める必要がある。

ウェブサイトでは，WordPress等のCMS本体，テーマ及びプラグインだけでなく，PHP，OS及び関連ライブラリも管理対象として確認する。
CMS側に更新がないことだけで，実行基盤の脆弱性への対応まで不要と判断することはできない。
令和８年１０月２１日のPHP公式告知は，認証不要の遠隔コード実行につながり得る２件の脆弱性について修正版を示しており，CMSと実行基盤の更新担当を分けて把握する具体例となる。
これはPHPの開発側による技術的な告知であり，特定のサイトの侵害や管理者の過失を認定した資料ではない。
出典：PHP「News Archive – 2026」。
https://www.php.net/archive/2026.php

個人情報保護委員会の令和７年度年次報告も，不正アクセスによる漏えい等の原因として，「ＶＰＮ（Virtual Private Network）機器の脆弱性やＥＣサイトを構築するためのアプリケーション等の脆弱性が公開され対応方法がリリースされていたにもかかわらず、事業者が放置していたこと」を最初に挙げている（印字頁１０頁）。
ECサイトの脆弱性からクレジットカード情報が漏えいした場合の加盟店の義務と開発委託先の責任は，ECサイトのカード情報漏えいと加盟店の義務―割賦販売法３５条の１６，クレジットカード・セキュリティガイドライン６．１版及び開発委託先の責任で扱っている。

２　脆弱性への対応が遅れた事例

親会社がパッチ適用を指示しても，子会社の要員不足や資産管理の不備により適用できなければ，グループ全体が攻撃を受け得る。
指示の送付で終えず，適用状況，未適用の理由，代替措置及びサポート終了機器の有無を経営層へ集約する。

デジタル庁のGSS不正アクセスに関するQ＆A（令和８年９月１２日更新）は，悪用された脆弱性について，当初の公表評価はCVSSのMediumであり，修正プログラムの適用前に悪用されたと説明する。
同庁が一般的対応より早く対処を進めたという説明と，適用完了前に攻撃を受けたことを分ける。
CVSSの評価だけで対応順序を固定せず，外部公開の有無，扱う情報，認証・認可への影響，攻撃の状況及び業務の重要性を併せて判断することが実務上の提案である。
政府システムの事案から，民間事業者の報告義務の適用や担当者の過失まで同じと推定しない。

ベネフィット・ワンの令和８年９月３０日の公表は，アンケート結果のダウンロード機能の条件設定不備を前年１０月の社内調査で認知していたものの，その後の解消作業が適切に実施されていなかったと説明する。
これは同社の公表内容であり，特定の担当者の責任を認定した資料ではない。
不具合を把握した記録，修正依頼及び本番環境で解消したことの確認を分けて管理する必要性を示す例となる。

不具合・脆弱性の管理には，対象機能・権限境界，担当・代替者，対応期限，修正までの利用停止等の暫定措置，本番適用日，再試験の方法・結果及び未解消・期限超過時の上申先を対応させる運用が考えられる。
他社のデータを閲覧できないかを確かめる試験も，許されたテスト環境・資料で行う。
修正済みという連絡だけで完了とせず，現在のシステムで予定した制御が働くことを確認する。

次の表は，脆弱性対応の完了を確認するための運用例であり，法定の報告様式ではない。
修正の適用を示す資料と，適用後の機能確認の資料は，それぞれの目的に応じて対応付ける。

旧版へ修正だけを取り込む提供形態では，表示された版番号だけで修正の有無を決めず，対象CVEとパッケージ等の版及び提供者の根拠資料を確認する。
逆に，主要な画面が表示されたことだけでは，修正自体が適用されたことの証明にはならない。

３　不正ログインの事例

推測しやすいパスワード，ロック機能の不足，漏えいした認証情報の未変更，及びログの保存・監視ルールの不在が原因として示されている。
強固な認証，多要素認証，試行回数制限，認証情報の初期化及びログ分析を組み合わせる必要があり，どれか一つだけで十分とはいえない。

個人情報保護委員会の令和８年８月１９日のKDDI及びインターネットサービスプロバイダに関する資料は，認証情報の漏えいと，内部での横展開を防ぐアクセス制御等の不足を指摘している（１頁～３頁）。
認証情報を変更する対応と，侵入後に別のサーバーへ移動できない構造を点検する対応は，分けて確認する必要がある。
同資料はメールボックス内の情報が閲覧可能な状態だったとするが，メール本文の全件が窃取されたとの認定に置き換えない。

４　グループ会社や海外拠点が狙われた事例

海外子会社の未把握のVPN装置等が足がかりとなり，拠点間の水平移動により親会社のデータセンターに被害が広がる。
海外拠点と外部事業者からの貸与品を含めた資産台帳を作り，拠点間通信を業務上必要な範囲に限定する。

５　グループ会社間のアクセス制御不備

データセンターを一元管理していても，各社のデータへ相互にアクセスできる設定は，一社の侵害を全社へ広げる。
業務上必要な最小限への制限，各社のシステムの分離，管理者アカウントの強固な認証及び定期的な権限棚卸しが必要となる。

６　個人領域に保存したデータの漏えい

従業者のデスクトップや個人フォルダでの加工・保存が慣例化すると，管理台帳や監査の網から外れ，本来消去すべき古いデータまで漏えい範囲に入る。
保存場所を指定し，取扱者・媒体・保存期間を台帳化し，定期監査と不要データの消去を行う。

７　グループ会社への監督が不十分な事例

親会社が子会社の人事データの取扱いの委託を受ける場面では，グループ内という信頼関係があっても委託先監督が不要とはならない。
自己点検や第三者検査の結果，パッチ適用状況，重大インシデント及び是正状況をグループ内で共有し，規模と性質に応じて監督する。

８　利用するクラウドサービスからの漏えい

クラウド事業者が個人データを取り扱う契約であれば委託先監督を検討する必要があり，取り扱わない契約であっても利用者側の安全管理措置として適切なサービス選定が必要である。
利用規約，安全性評価資料，セキュリティレポート，再委託，事故通知，ログ提供及び終了時の消去の条件を確認する。
クラウド事業者が個人データを取り扱わないこととなっている場合でも，漏えい等が生じたときに報告義務を負うのは利用者である（個人情報保護委員会Q&A６－２２）。
また，施行規則７条３号の「当該個人情報取扱事業者」には，利用している第三者のサービスの提供者も含まれる（通則編ガイドライン３－５－３－１）ので，クラウド事業者へのランサムウェア攻撃は，利用者にとって人数にかかわらず報告対象事態となり得る。
ランサムウェアで暗号化され復元できなくなった個人データは毀損に当たるが，同じデータが他に保管されていれば毀損に当たらない（同３－５－１－４）から，利用者自身のバックアップの有無が結論を左右する。
令和８年１０月のIDCフロンティアの事案を題材にした検討は，クラウド事業者がランサムウェア被害を受けたとき，利用者に漏えい等報告義務はあるか―施行規則７条３号，滅失・毀損とバックアップで扱っている。

楽天ドライブの令和８年１０月６日の公表は，管理用アカウントの認証情報が不正取得され，保存された写真や文書が取得・閲覧された事案を説明している。
利用者の認証設定に加え，提供者側の特権アカウントの利用範囲，承認，操作ログ及び侵害時の失効手順を点検する必要がある。
事故発生だけから，その提供者の認証取得状況や利用者ごとの安全管理措置違反を推定するものではない。

クラウドの点検では，利用者のアカウントに加え，外部サービスとの連携のため，自社環境へのアクセスを許可したアプリも対象にする。
Microsoftは，令和８年１０月２１日の調査報告で，ConnectWiseに関係するアプリケーション資格情報を悪用し，対話型のユーザーログインを介さず顧客環境へアクセスする活動を報告した。
影響するアプリの存在や認証成功だけで，データの取得・外部送信まで確認されたことにはならないと留保している。

この技術事例は，個人情報保護委員会の９類型に新しい類型を追加する趣旨ではない。
既存のクラウド・API・権限管理の点検を具体化する補足であり，利用者のMFAとアプリ自身のアクセスの違い，ログの確認及び証拠保全は，Microsoft 365の外部アプリ権限と情報漏えい―ConnectWise事案から学ぶ点検事項で扱う。
事例の原資料：https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/

９　APIが悪用される事例

サービスにログインできることと，個別のデータへアクセスする権限があることは別である。
URLや会員ID等のパラメータを書き換えて他人のデータを取得できるなら，認証だけが動いていても認可が不十分である。

APIの棚卸し，要求ごとの認可，不要なレスポンス項目の削除，UUID等の推測しにくい識別子，及び短時間の大量アクセスを検知・遮断するレート制限を組み合わせる。
連番のIDをUUIDに変えるだけでは認可の代わりにならない。

JPCERT/CCの令和８年１０月８日の注意喚起（同月２３日更新）は，非公開APIを含むエンドポイントごとのアクセス制御，API利用者・トークンの最小権限，有効期限の設定及び不要・漏えいが疑われるトークンの速やかな無効化を推奨している。
ログイン，パスワードリセット，SMS送信及び検索等には，機能ごとのレート制限・利用回数制限も設ける。
「画面に表示していないAPIだから外部から使えない」という前提を置かず，許可する利用者，HTTPメソッド及び対象データを確認する。
記載された不審なIPアドレスが調査時点では正規利用されている可能性もあるため，送信元だけで侵害又は攻撃者を断定しない。

同注意喚起の令和８年１０月２３日の更新は，ケースEとして，ARTEXなどのAIを用いたペネトレーションテスト基盤を悪用した攻撃試行も取り上げている。
AIの使用は，個人情報保護委員会の９類型と並ぶ第１０の原因類型というよりも，脆弱性探索や管理不備の悪用などを横断する手段として整理すると，点検の対象が分かりやすい。
後者は本稿の整理であり，個人情報保護委員会自身の分類ではない。

ツールの名称だけで被害範囲や攻撃者を決めず，認証・認可，付与権限及び操作の記録を確認する。
仕組みと各調査報告の違いは，ARTEXとは―AIサイバー攻撃の仕組みと企業が確認すべき対策を参照されたい。

認可を確認する対象は，APIだけに限られない。
アドベンチャーの令和８年１０月９日の公表は，skyticketのバス予約完了ページがログインせず表示でき，第三者に機械的に閲覧されたと説明している。
予約番号等を含む画面や共有URLについても，誰がどの記録を閲覧できるかを要求ごとに確認する。
同公表の約１万２０００件は予約件数であり，同行者を含む人数はこれより多いとされているため，件数・アカウント数・本人の数を混同しない。

ソースネクスト株式会社の令和８年１０月１５日の公表によれば，同月９日頃から第三者が会員情報取得APIを不正に利用し，対象件数２２５１万９９６０件の会員情報を取得したとされている。
同社は，公表した項目は流出した可能性のある全項目であり，全ての会員について全項目が対象となったわけではないこと，クレジットカード情報は対象システムに保存していなかったことを説明している。

これは同社の公表内容であり，令和８年１０月１６日時点で外部の独立した専門機関による第三者調査は準備中とされている。
現在の公表資料だけから，要求ごとの認可不備，連番ID，レート制限の欠如又はパスワードの保存方式を確定することはできず，平文保存であったとも判断できない。
API事故の検討では，対象エンドポイント，認証情報・トークン，要求ごとの認可，取得回数，件数の数え方，返却項目及びパスワードの保存方式を分けて確認する必要がある。

NICTは令和８年１０月１３日，公開Androidアプリの解析結果を悪用して接続先サーバを攻撃するA2B攻撃を，国内で相次ぐ情報漏えい事案の原因の一つとして特定したと公表した。
一般に公開していないつもりのAPI仕様も，公開アプリの解析から知られる場合がある。
同公表は，AIによる解析・脆弱性発見の効率化で攻撃が広がる可能性を指摘しているが，全ての漏えい事案でAIの利用や同じ侵入経路が確認されたという意味ではない。

アプリ自体の不備の有無だけでなく，接続先の認証・認可，入力値の検証及びアクセスの記録を確認する必要がある。
NICTの公表（https://www1.nict.go.jp/press/2026/10/13-1.html）は，「侵害の確認」「脆弱性の点検」「暫定的な緩和策」を示している。
個別の点検は，自社の構成に即して技術担当者・開発運用の委託先と行う。

第４　弁護士・司法書士・税理士実務への落とし込み

１　共通の台帳を五つに分ける

専門職事務所では，①端末・ネットワーク機器，②アカウント・権限，③クラウド・外部委託，④データの保存場所・保存期間，⑤ログ・保全期間を分けて台帳化するとよい。
一つの「情報資産台帳」に全てを押し込むより，機器，認証，委託，保存及び証拠の責任者と更新契機を分けた方が漏れを発見しやすい。

アカウント・権限の台帳では，通常のログインだけでなく，復旧する者と，権限を止める者まで対応させるとよい。
次の表は，NIST SP 800-63B-4（https://pages.nist.gov/800-63-4/sp800-63b.html）４及び付録Ｂの認証手段の管理・復旧・失効を参考にした運用例であり，個人情報保護委員会が指定した法定の台帳様式ではない。

共有台帳には，パスワード，秘密鍵，ワンタイムコード又は復旧コードの値を記載しない。
秘密情報の保管・閲覧権限は別に管理し，職員個人の端末・電話又は個人アカウントだけに復旧を依存していないかを確認する。
認証方式の違いは，アカウント・パスワード・PIN・多要素認証の違いと安全な管理（https://yamanaka-bengoshi.jp/2026/09/15/account-password-pin-mfa/）で整理している。

ログ・保全期間の台帳は，保存しているという回答だけで終えず，次の項目を機器・サービスごとに記録するとよい。
ログの一覧と監視対象の一覧を照合し，取得されない操作や対象外の環境も分かるようにする。

個人情報保護委員会「フォレンジック調査の着眼点」１４頁は，調査に必要となるログを少なくとも１年程度保管することが望ましいとしている。
これは全てのログに共通する一律の法定保存義務ではなく，法令上保管が許容される範囲を超える保存を勧めるものでもない。
ログの必要性，機微性，業務上のリスク及び保存・消去の条件を定め，法令上必要な帳簿の保存と同じ期間になるとは限らないことに注意する。

事故件数ゼロという説明の評価は，「情報漏えいゼロ」は安全の証拠かを参照されたい。
事故後に受け取った報告書の調査範囲と結論の点検は，情報漏えいのフォレンジック報告書をどう読むかで扱っている。

２　弁護士実務

事件記録，刑事記録，医療資料，相手方や第三者の個人情報及び裁判上の期限管理は，漏えいだけでなく，改ざん，利用不能及び未受信の影響も大きい。
認証ログ・操作ログの保存と，事務所のメール・電子提出・クラウドが停止したときの代替連絡・期限監査を，基本的な取扱方法と事故対応計画に書き込む必要がある。

３　司法書士実務

登記申請資料，本人確認資料，戸籍・住民票，本人限定受取郵便等の記録及び電子署名関係データは，受件ごとの正式な保存場所と役割ごとのアクセス権限を定める。
個人のデスクトップや個人メールへ一時保存したものを正式保管先へ移し，作業用複製を消去したことを確認する運用にする。
これらは本資料から導く実務上の当てはめであり，司法書士の職務規律による保存期間等は別途確認する必要がある。

４　税理士実務

申告書，帳簿，給与データ，マイナンバー関係資料及びOCR・生成AIへの入力データについて，原資料，中間データ，外部処理先，会計ソフトへの取込み及び作業用複製の保存場所を分けて記録する。
税法上その他の法令上の保存期間と，利用目的との関係で不要となったデータの消去を分け，入力先と再委託先の削除条件も確認する。
会計ソフト等をクラウドで使い，税理士法４１条の帳簿（閉鎖後５年間保存）や顧客の申告データを置いている場合は，クラウド事業者の被害でデータが失われたときに備え，同じデータを別の場所に保管しておく。

クラウド会計，給与計算及び電子申告に関係する権限は，顧客が契約・管理するアカウントと，事務所の担当者に付与された権限を区別して台帳に対応させるとよい。
担当変更や顧問契約終了時は，担当者の権限の停止と，顧客が必要なデータ・正規の管理権限を保持することを分けて確認する。
顧客のパスワードを事務所全員で共有する運用を前提とせず，サービスが提供する権限分離と公式の手続を用いる。
これは事務所運営上の提案であり，個々の電子申告サービスがパスキーに対応していることや，同じ代理権設定を使えることまで意味しない。

税理士事務所がクラウド会計・給与サービスから漏えい通知を受けた場合の顧問先別の影響確認，マイナンバー，e-Tax及び業務継続は，税理士事務所がクラウド会計・給与サービスの漏えい通知を受けたときで整理している。

５　委託契約と事故対応

保守契約とクラウド契約には，①管理対象，②脆弱性情報の収集者，③パッチ適用の責任者・期限・完了報告，④権限棚卸し，⑤ログ保存・提供，⑥事故通知，⑦フォレンジック協力，⑧契約終了時の返還・消去を定める。
封じ込めと証拠保全を両立させ，端末の電源断，再起動，ウイルススキャン，初期化及び更新は，フォレンジックの方針と証拠への影響を確認してから行う。

ウェブサイトの保守では，PHP等の実行基盤の更新が契約に含まれるか，CMS側との互換性確認を誰が担うか，追加費用と承認の条件，緊急時の公開停止・再開の判断者まで確認する。
ホスティング事業者，制作会社，保守会社及び運営者の担当が異なる場合には，通知の転送先だけでなく，実際に適用する者と完了を確認する者を対応させる。
サポート終了の情報収集，移行提案，検証及び移行完了の期限も，今回の緊急修正とは別に管理する。

第５　後日の事実認定と一次資料の使い方

１　確認済み・技術上可能・不明を分ける

事故報告書では，ログや保全イメージから確認できた事実，設定や機能上可能だったこと，及びログ欠落等により不明であることを分ける。
「漏えいを確認できない」と「漏えいはなかった」は同じではない。

２　行政資料と裁判例の射程を分ける

第３７１回個人情報保護委員会資料は，実際の報告事案に基づく公式の行政資料であり，規程，台帳，委託契約及び事故対応を点検する有力な手掛かりとなる。
他方，各対策が個別事案で直ちに契約上の義務，不法行為の注意義務又は懲戒基準になるかは，契約，業務の性質，被害の予見可能性，当時の技術水準及び関連裁判例を別に確認する必要がある。

第６　関連記事

PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順（AI作成）

不正アクセス対策を，企業の平時の体制，発覚後の証拠保全，個人情報保護委員会への報告，本人通知及び対外公表まで一続きで確認する場合は，情報漏洩が相次ぐ今，企業の信頼を守る法務の備えを参照されたい。

個人情報保護法の安全管理措置は機密性に偏っているか
法律事務所のサイバー事故初動チェックリスト
AIで作った社内ツールの情報漏えい
外部委託先で個人情報が漏えいした場合の委託元の対応
社員が私用LINE・私物USB・個人メールで会社の情報を扱ったとき
税理士事務所で生成AIを使うときの入力資料の分け方
クラウド事業者がランサムウェア被害を受けたとき，利用者に漏えい等報告義務はあるか
ECサイトのカード情報漏えいと加盟店の義務

広く弱点を探す攻撃と個別のシステムを狙う攻撃の関係，AIによる効率化及び企業の対策は，AIを悪用した無差別サイバー攻撃とは―仕組みと企業の対策（AI作成）で整理している。

第７　出典

【API対策の追加資料】JPCERT/CC，「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」Ⅱ・Ⅲ（令和８年１０月８日公表，同月２３日更新）。

①個人情報保護委員会「第３７１回個人情報保護委員会」（令和８年１０月７日）
②個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（令和８年１０月７日）
③個人情報保護委員会「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」（令和６年１２月１１日，令和８年１０月７日改訂）
④個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（令和８年６月一部改正）
⑤e-Gov法令検索「個人情報の保護に関する法律」２２条から２６条まで
⑥個人情報保護委員会「フォレンジック調査の着眼点」（令和８年１月１６日）
⑦個人情報保護委員会「令和７年度個人情報保護委員会年次報告」印字頁１０頁
⑧個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」（令和７年７月１日更新）Q６－２２
⑨デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A（令和８年９月１２日更新）
⑩株式会社ベネフィット・ワン「当社システムにおける個人情報漏えいに関するお知らせとお詫び」（令和８年９月３０日）

⑪ソースネクスト株式会社「当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ」（令和８年１０月１５日）

⑫ソースネクスト株式会社「情報漏洩に関するよくあるご質問」（令和８年１０月１６日確認）