第１ 本記事の対象と要点
１ 対象と基準日
内閣官房国家サイバー統括室は，令和８年１１月５日，「個人情報の漏えい等につながる不正アクセスへの対策について～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」と題する事業者向けの注意喚起を公表した。
翌６日には，サイバーセキュリティに関する関係閣僚会議（第２回）が開かれ，「サイバーセキュリティ緊急対策パッケージ」が決定された。
本記事は，この二つの資料と，同統括室の令和８年１０月９日の注意喚起を基に，ウェブサイトやモバイルアプリを運営して個人情報を取り扱う事業者が確認すべき事項を，法律上の義務との関係を区別して整理する。
基準日は令和８年１１月７日である。
２ 要点
① 政府は，相次ぐ漏えい事案の主な原因を，自組織又は委託先における基本的な対策の不十分さとみている。
② 注意喚起は，運用・管理段階，設計・開発段階及びサプライチェーンの三つの柱で対策例を示す。
③ 注意喚起自体は協力の依頼であり，新たな法的義務を課すものではないが，個人情報保護法の安全管理措置（２３条）と委託先の監督（２５条）の義務は別に存在する。
④ 委託先に対策を求める場合は，費用負担や実施方法を十分に協議することも求められている。
⑤ 緊急対策パッケージは，個人情報保護委員会の安全管理措置に関するガイドラインの改正（令和９年１月中の施行を目指す），SCS評価制度の開始，被害を受けた事業者への支援窓口などを示した。
第２ 令和８年１１月５日の注意喚起の位置付け
１ 発出の経緯
国家サイバー統括室は，令和８年１０月９日にも「不正アクセスによる漏えい等の事案を踏まえた対応について」を公表し，ウェブシステム等の適切な管理，サプライチェーンを通じた侵害への対策及びデータの適切な管理を求めていた。
緊急対策パッケージの概要（関係閣僚会議の資料１）は，１１月５日の注意喚起を，自社及び委託先におけるウェブサイトやモバイルアプリに関する基本的な対策の徹底を呼び掛けるため，あらためて具体的に発出したものと説明している（資料１・８頁）。
同統括室は，相談窓口や注意喚起をまとめた「サイバー対応特設サイト」を令和８年１０月３０日に開設し，両注意喚起もそこに掲載している。
２ 原因についての政府の認識
注意喚起は，不正アクセスによる情報漏えい事案で，モバイルアプリ開発時のセキュリティ対策不足，ウェブサイト等の設定不備，サポートが終了しているソフトウェアや既知の脆弱性が未対策のソフトウェアの継続使用など，自組織又は委託先における基本的な対策が十分でなかったことが原因とみられる事例を複数確認したとする（１頁）。
また，攻撃者が我が国のウェブサイト等を標的に大規模な調査を行って侵入したとみられること，標的の調査や侵害にAIを使用している可能性も高いこと，低いと評価されたリスクが組み合わされて侵入の原因となった可能性のある事例もあることを挙げる（１頁）。
これらは「とみられ」「可能性」と留保を付けた政府の評価であり，個別の事案でAIが使われたことや侵入経路を確定したものではない。
３ 法的拘束力と法的義務の区別
注意喚起は，事業者に対策事項の確認と基本的な対策の徹底を「お願い」し，具体的な対策例を「参考」として示す文書である。
それ自体が新たな法的義務を課すものではない。
他方で，個人情報取扱事業者には，個人情報保護法２３条の安全管理措置義務がある。
同条は，「個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。」と定める。
個人データの取扱いを委託する場合は，同法２５条により，委託先に対する必要かつ適切な監督も必要となる。
注意喚起に法的拘束力がないことと，そこに書かれた対策が後の紛争で意味を持たないことは別である。
開発委託先がSQLインジェクション対策を怠った事案で，東京地裁平成２６年１月２３日判決（平成２３年（ワ）第３２０６０号，判例秘書の判例番号 Ｌ０６９３０１８７）は，契約当時の技術水準を判断する際に，経済産業省の注意喚起や情報処理推進機構（IPA）の文書を考慮している。
本記事の整理としては，公的機関が具体的な対策を周知した後は，その対策を講じていたかどうかが，安全管理措置や契約上の注意義務の水準を検討する際の資料になり得ると考えられる。
同判決の詳細は，ECサイトのカード情報漏えいと加盟店の義務で扱っている。
第３ 注意喚起の三つの柱
１ 運用・管理段階
運用・管理段階では，次の三つが挙げられている（２頁～５頁）。
① デジタル資産の適切な把握及び脆弱性の解消：OS，ミドルウェア，フレームワーク，ライブラリ等の製品名・バージョン・利用箇所を把握し，米国CISAのKEV（既知の悪用された脆弱性）カタログに載るなど実際に悪用が確認されている脆弱性を優先して確認する。
② アタックサーフェスの継続的な棚卸し及び最小化：インターネットに公開されたシステム管理画面や，本来は外部公開を想定していないデバッグ用機能等を経由した不正アクセスが確認されているとして，不要な公開機能の停止とアクセス制限を求める。
③ AIの活用等による継続的な脆弱性診断及び不審な挙動の監視：公開前だけでなく，認証・認可，API，個人情報の取扱い等に係る重要な変更時や運用開始後も診断・点検を行う。
AIを活用した診断ツールや監視の導入を積極的に検討するよう求める一方，AIによる評価結果は根拠や妥当性を確認し，最終的な対応判断は人が確認するとしている（５頁）。
２ 設計・開発段階
設計・開発段階では，次の三つが挙げられている（６頁～９頁）。
① セキュリティ・バイ・デザインの適用：要件定義・設計段階で脅威モデリングを行い，認証・認可，暗号化，ログ取得，アクセス制御等の要件を明確にし，要件定義，設計，調達，開発，検収及び運用の各段階で確認すべき項目を明確にする。
② 利用するAPIのセキュリティ対策の強化：情報通信研究機構（NICT）が注意喚起した「A2B（App-to-Backend）攻撃」のように，公開アプリの解析を通じてAPIの脆弱性や認可不備を特定し，バックエンドから情報を窃取するインシデントが報告されているとして，サーバー側での認可の検証，APIキー等の認証情報をソースコードに埋め込まない管理，レート制限を求める。
③ 公開前の脆弱性診断の実施：受容可能なリスク水準を定めてリリースの可否を判断し，修正責任者と対応期限を明確にする。第三者に診断を委託する場合は，情報セキュリティサービス基準に適合したサービスを提供する事業者を選ぶ。
③では，製品やプラットフォームの既知の脆弱性だけでなく，自社又は委託先が開発したウェブアプリやモバイルアプリのバックエンド機能に固有の設計・実装上の脆弱性も，診断と是正の対象とする必要があるとされている（９頁）。
A2B攻撃の仕組みは，AIを悪用した無差別サイバー攻撃とはの第３で説明している。
３ サプライチェーンを通じた侵害への対策
サプライチェーンについては，次の二つが挙げられている（９頁～１１頁）。
① 委託先のセキュリティ統制及び接続経路の厳格化：委託先が使うVPN，リモートデスクトップ，保守用回線等に多要素認証を適用し，困難な経路には接続元の制限や作業時だけの接続等の代替策を講じる。作業が完了した委託先のアカウントや常時付与された管理者権限を棚卸しする。
② OSSや外部ライブラリ等の適切な管理：深刻な脆弱性の公表時に保守事業者任せにせず判断できるよう，影響調査の責任者，委託先との役割分担，経営層への報告基準及び暫定対策の判断手順をあらかじめ定める。委託開発では，使用するソフトウェア部品の明示とソフトウェア部品表（SBOM）の提出を契約・仕様に定め，検収時に確認する。
注意喚起は，これらの対策が昨今の一連の攻撃手口に焦点を当てたものであり，VPN等の機器の脆弱性を狙う攻撃，標的型メール攻撃，DDoS攻撃などへの対策も別に必要であるとし，経営トップの判断の下でリスク評価を行うよう求めている（１１頁）。
国家サイバー統括室は，緊急対策パッケージの決定を踏まえた古川サイバー安全保障担当大臣のメッセージ動画を，令和８年１１月６日にYouTubeで公開している。
第４ 法務・契約の観点で確認する事項
１ 委託契約に定める事項
注意喚起は，発注仕様書や業務委託契約書に，秘密保持義務に加え，再委託の手続，インシデント発生時の通知義務・連絡先，契約終了時のデータ消去等の要件を盛り込むよう求めている（１０頁）。
令和８年１０月９日の注意喚起も，不正アクセスや漏えいが発生した場合の報告義務の規定，委託先へ提供する情報の最小化，業務終了後の委託先でのデータ削除の徹底を挙げていた。
委託先の監督と事故時の対応は，外部委託先で個人情報が漏えいした場合の委託元の対応で扱っている。
２ 開発・保守契約で脆弱性対応の担当を決める
緊急対策パッケージは，システム開発契約や運用保守契約において，脆弱性対応の実施主体が明確に定められていない場合が多く，緊急の対策が必要となった際に支障が生じる事例が発生しているとし，契約で留意すべき事項の普及促進の方策を検討するとした（資料２・別紙１８頁）。
これは今後の検討事項であり，現時点で契約の書式が示されたわけではない。
もっとも，保守の対象，脆弱性情報を収集する者，重大な脆弱性の公表時の対応期限，サポート終了版の扱いと費用は，現在の契約でも当事者間で決めることができる。
具体的な項目は，Web制作・保守会社にPHPを更新する責任はあるかの第８で整理している。
３ 取引先への要請と費用負担
注意喚起は，委託先に対策を求める際は，費用負担や実施方法について十分に協議し，取引上の地位を利用した一方的な負担の押し付けとならないよう留意するよう求めている（９頁）。
独占禁止法と取適法の考え方は，取引先にサイバーセキュリティ対策を求めるときで扱っている。
４ 保有する個人データを絞る
緊急対策パッケージは，個人情報取扱事業者が，個人データを利用する必要がなくなったときは遅滞なく消去するよう努めなければならないとされていることを踏まえ，個人情報保護委員会が令和８年１０月７日に不要なデータの消去を含めて注意喚起を行ったと記載する（資料２・別紙１頁）。
これは個人情報保護法２２条の努力義務である。
同パッケージは，本人確認等のために取得した画像等の保存期間・保存方法などに関する基本ルールについて，令和８年度中に業種ごとの注意喚起等を行うとしている。
退会者等のデータの扱いは，退会後の個人情報は削除できるかで扱っている。
第５ 緊急対策パッケージで示された今後の予定
１ 安全管理措置に関するガイドラインの改正
個人情報保護委員会は，安全管理措置に関するガイドラインの全項目の「手法の例示」の改正作業を加速させ，令和９年１月中の施行を目指すとされた（資料２・別紙１頁）。
これは施行の目標であり，改正の内容と施行日が確定したものではない。
同委員会が令和８年１０月７日に示した見直しの方向は，個人情報保護委員会が示した不正アクセス９類型で整理している。
同パッケージは，同委員会が報告された漏えい等について適時適切に事実関係を調査し，必要に応じて指導・助言等の権限を行使するとも記載している。
２ SCS評価制度の開始と情報提供の仕組み
サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は，令和９年３月から開始し，大企業の委託先管理手法として推奨するとされた（資料２・別紙８頁）。
また，運用開始後，★を取得した企業等がサイバー攻撃を受けた場合に，国家サイバー統括室が関係情報を求めることが可能な仕組みを導入するとされている（同頁）。
制度の契約上の扱いは，SCS評価制度の契約実務で扱っている。
３ 被害を受けたときの相談窓口と支援
同パッケージ及び特設サイトによれば，事業者向けには次の窓口や体制が示されている。
① 警察庁のサイバー事案に関する相談窓口に加え，全ての都道府県警察本部のサイバー部門に，法人専用の相談・通報窓口であるサイバー被害１１０番（仮称）を令和８年中に開設し，専用ダイヤルを令和８年度中に整備する。
② IPAの不正アクセス特別相談窓口（令和８年１０月１６日設置）と，よろず支援拠点及び中小企業基盤整備機構の「サイバーセキュリティ特別相談窓口」（同月２７日設置）がある。
③ 政府による支援の必要性が特に認められる場合に，官民の専門人材で構成する「官民サイバー救援隊（仮称）」を被害組織に派遣する仕組みを整備し，令和８年度中の早期に国家サイバー統括室内に事務局を設ける。
④ 警察庁及び管区警察局等に，ログの保全や原因究明等の初期対応を担う「ファスト・フォレンジック・フォース（FFF）（仮称）」を立ち上げる。
⑤ 中小企業向けの「サイバーセキュリティお助け隊サービス」に，被害発生時の診断，定期バックアップと復旧支援，定期脆弱性診断等のメニューを加える。
同パッケージは，捜査・実態解明のため，所管企業等から通報やログ等の証拠の提供が得られるよう必要な要請を行うともしている（資料２・別紙７頁～８頁）。
被害を受けた事業者にとっては，ログの保全と，警察や所管省庁への相談・報告の判断を初動の段階で行う必要がある。
初動の手順は，法律事務所のサイバー事故初動チェックリストも参考になる。
４ 本人確認の方法
同パッケージは，運転免許証の画像による本人確認に国民が不安を感じているとして，マイナンバーカード等のICチップの読取りによる本人確認の利活用場面を拡大するとした（資料２・２頁）。
また，漏えいした個人情報を悪用したなりすましによる口座開設等を防ぐため，口座開設や貸付け等を行う事業者に，犯罪収益移転防止法等に定める本人確認の徹底を要請するとしている（資料２・別紙１７頁）。
第６ よくある質問
１ 注意喚起に従わないと違法になるか
注意喚起そのものに従う法的義務はない。
もっとも，個人情報保護法２３条・２５条の義務は別にあり，周知された対策を講じていなかったことは，後に安全管理措置や契約上の注意義務が問題となった際の資料になり得る。
２ 中小企業も対象になるか
注意喚起は，攻撃の大規模化が容易になったことで，事業規模の大小を問わず幅広い事業者が攻撃対象になっていると考えられるとしている（１頁）。
個人情報保護法の安全管理措置義務も，事業者の規模にかかわらず個人情報取扱事業者に適用される。
３ 委託先が原因で漏えいした場合はどうなるか
注意喚起は，委託先の環境を足掛かりとした侵入でも，サービス停止や情報漏えいに伴う影響は発注元である事業者自身が負うとしている（９頁）。
漏えい等の報告や本人通知の要否と，委託元・委託先間の責任の分担は，別に検討する必要がある。
第７ 関連記事
① 取引先にサイバーセキュリティ対策を求めるとき―優越的地位の濫用・取適法と費用負担の協議
② 情報漏洩が相次ぐ今，企業の信頼を守る法務の備え―平時の体制，発覚後の初動，報告・通知・公表
③ 個人情報保護委員会が示した不正アクセス９類型―API，クラウド，グループ会社，個人領域及びログ管理
④ SCS評価制度の契約実務―★３・★４の取得，脆弱性対応期限及び委託先管理
⑤ Web制作・保守会社にPHPを更新する責任はあるか―保守契約の範囲，サポート終了版，責任制限条項と重過失
⑥ AIを悪用した無差別サイバー攻撃とは―仕組みと企業の対策
第８ 出典
① 内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」（２０２６年１１月５日）
② 内閣官房国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」（２０２６年１０月９日）
③ 内閣官房国家サイバー統括室「サイバー対応特設サイト」（令和８年１１月７日閲覧）
④ 内閣官房「サイバーセキュリティに関する関係閣僚会議（第２回）議事次第」（令和８年１１月６日）
⑤ 同会議資料１「サイバーセキュリティ緊急対策パッケージ（概要）」
⑥ 同会議資料２「サイバーセキュリティ緊急対策パッケージ（案）について」
⑦ e-Gov法令検索「個人情報の保護に関する法律」２２条，２３条，２５条
⑧ 東京地裁平成２６年１月２３日判決（平成２３年（ワ）第３２０６０号，判例秘書の判例番号 Ｌ０６９３０１８７）
⑨ 内閣官房国家サイバー統括室「【古川サイバー安全保障担当大臣メッセージ】サイバーセキュリティ緊急対策パッケージの決定を踏まえて」（YouTube，令和８年１１月６日公開）