2026年11月5日、内閣官房国家サイバー統括室が事業者向けの文書「個人情報の漏えい等につながる不正アクセスへの対策について」を公表しました。副題は「ウェブサイトやモバイルアプリに関する基本的な対策の徹底」です。ウェブサイトやモバイルアプリで事業を運用し、個人情報を扱う事業者に向けて、運用・設計開発・委託先管理の3つの段階で具体的な対策例を示しています。
文書は、攻撃者がAIを使って日本のウェブサイトを大規模に調べている可能性が高いと指摘しています。その結果、事業規模の大小を問わず狙われているとみています。この記事では、文書の要点を段階ごとに整理し、10月9日の文書との違いと、小さな事業者がまず確かめたい項目をまとめます。
11月5日の文書は「基本対策の不足」が原因とみられる事案を受けた再要請
政府は、相次ぐ不正アクセスによる情報漏えいのうち、自組織や委託先の基本的な対策が十分でなかったことが原因とみられる事例を複数確認したと説明しています。原因として挙げているのは次の3つです。
- モバイルアプリを開発するときのセキュリティ対策の不足
- ウェブサイトなどの設定の不備
- サポートが終わったソフトウェアや、既知の脆弱性を直していないソフトウェアの使用継続
文書は読み手を分けた2層構成です。冒頭の柱書は経営層を含む組織の幅広い人に向けて、考え方と背景を説明しています。各項目に付いた「対策例」はITシステムやセキュリティの担当者向けで、使うべき手段まで踏み込んでいます。
攻撃者はAIで日本のサイトを大規模に調べ、見つけた侵入口から入っている
文書によると、攻撃者はインターネットに公開されている日本のウェブサイトなどを標的に大規模な調査を行い、侵入方法が見つかったサイトに入り込んで個人情報を盗んだとみられます。標的の調査や侵害にAIを使っている可能性も高いとしています。
見逃せないのは次の指摘です。AIが悪用されたことで、従来の脆弱性診断では比較的低いリスクと評価された問題でも、いくつかが組み合わさって侵入の原因になったとみられる事例があるといいます。弱点が小さくても安心はできません。攻撃の大規模化が容易になった結果、幅広い事業者が攻撃対象になっていると文書は見ています。
対策は「運用・管理」「設計・開発」「サプライチェーン」の3段階
文書が示す対策の全体像は次のとおりです。
| 段階 | 主な項目 | 担当者向けの対策例（抜粋） |
|---|---|---|
| 運用・管理 | デジタル資産の把握と脆弱性の解消／アタックサーフェスの棚卸しと最小化／AIの活用などによる継続的な診断と監視 | SBOM・SCAによる構成情報の管理、CISAのKEVカタログを使った優先確認、ASMによる公開資産の洗い出し、SIEM・EDRによる監視 |
| 設計・開発 | セキュリティ・バイ・デザインの適用／利用するAPIの対策強化／公開前の脆弱性診断 | 脅威モデリング、SAST・SCA・DAST・IASTの活用、認可不備の排除、認証情報の埋め込み禁止、レート制限、リリース可否の基準づくり |
| サプライチェーン | 委託先の統制と接続経路の厳格化／OSSや外部ライブラリの管理 | 委託先のVPNなどへの多要素認証、契約へのセキュリティ要件の明記、ゼロトラスト型のアクセス制御、委託開発でのSBOM提出 |
運用・管理：何を公開しているかを把握し、要らない入口を閉じる
最初の柱は、自社が何を使い、何をインターネットに出しているかを把握することです。ソフトウェアは導入時に問題がなくても、運用中に新しい脆弱性が見つかります。直接使う製品だけでなく、その中に組み込まれたOSSやライブラリにも脆弱性がありえます。
そのため文書は、OS・ミドルウェア・フレームワーク・ライブラリについて、製品名、バージョン、利用箇所を管理するよう求めています。手段として挙がっているのは、使っている部品の一覧であるソフトウェア部品表（SBOM）と、部品を自動で洗い出すソフトウェア構成解析（SCA）です。脆弱性情報は製品ベンダー、米国のNVD、日本のJVNなどから集めます。とくに、実際に悪用が確認された脆弱性をまとめた米CISAの「KEVカタログ」を優先して照合するよう書かれています。すぐに修正できない場合は、該当機能の停止やアクセス制限で暫定的に守ります。すでに悪用が確認された脆弱性なら、ログを見て侵害の兆候がないかも調べます。
次に、インターネットに露出している攻撃対象領域（アタックサーフェス）を減らす項目があります。文書が実際の事案として挙げているのは、公開された管理画面が推測しやすい認証情報や総当たり攻撃で破られた例と、外部公開を想定していないデバッグ用機能や管理用エンドポイントに外から届いてしまっていた例です。対策例では、点検すべき場所をかなり具体的に挙げています。
- 公開されている管理画面、デバッグ用エンドポイント、開発・検証環境、データベース管理機能
- リバースプロキシ、ロードバランサー、APIゲートウェイの振り分けルール（想定外のURLパスに来たリクエストをどう扱うかを含む）
- クラウドストレージのアクセス設定や外部共有、ファイアウォールの不要な許可、ウェブサーバーの意図しないファイル公開
是正したあとに外からアクセスして、本当に塞がったかを確かめるところまでが対策に含まれています。
3つ目は継続的な診断と監視です。ここで文書は、防御側でもAIの活用を積極的に検討するよう求めています。AIを使った診断ツールで攻撃経路の探索やテストケースの生成を効率化し、AIを使った監視で大量のログやアラートを横断して分析する、といった使い方です。そのうえで、AIの評価結果は根拠と妥当性を確かめ、最終的な判断は人が行うよう念を押しています。
設計・開発：アプリを解析してAPIを突く攻撃に備える
設計・開発段階では、セキュリティを後付けせず、要件定義から運用までの全体に組み込む「セキュリティ・バイ・デザイン」を求めています。リリース後に見つかった問題を直すコストは、設計時に防ぐ場合より大幅に高くなるからです。
とくに重く扱われているのがAPIです。文書は、情報通信研究機構（NICT）が注意喚起した「A2B（App-to-Backend）攻撃」を例に挙げています。公開されているアプリを解析してAPIの弱点や認可の不備を見つけ、バックエンドから機密情報を抜き取る手口です。対策例は次の3つです。
- 認可不備の排除：利用者がそのデータや機能を扱う権限を持っているかを、サーバー側で確かめる。最小権限の原則でアクセスを制御する
- 認証情報の安全な管理：APIキー、アクセストークン、秘密鍵をソースコードやアプリに埋め込まない。サーバー側ではシークレットマネージャーで管理し、有効期間の設定と定期的な入れ替えを行う。コミット時やCI/CDの工程で、認証情報の混入を検知する仕組みを整える
- レート制限：ログインやパスワードリセットに短時間で大量のリクエストが来たら制限する。複数のIPアドレスに分散した試行も含めて、異常なアクセスを検知できるようにする
公開前の脆弱性診断については、受け入れられるリスクの水準を事前に決めておき、一定以上のリスクがある脆弱性が残っていれば本番に出さない「セキュリティゲート」を設けるよう求めています。診断を外部に頼む場合は、自動診断だけでなく、手動の検証や業務ロジックを踏まえた診断をしてくれる事業者を選ぶよう書かれています。
サプライチェーン：委託先の接続経路も自社の責任範囲
文書によると、業務委託先や保守事業者の環境を足がかりに発注元へ侵入される事案も確認されています。委託先が使うリモート接続は、攻撃者にとって正規の認証情報で入れる入口になりえます。それでも、サービス停止や漏えいの影響を負うのは発注元です。文書はこの点を明記しています。個人情報の取扱いを委託する場合は、個人情報保護法第25条で委託先の監督が求められている点にも触れています。
対策例の中心は接続経路の保護です。委託先が使うVPN、リモートデスクトップ、保守用回線を洗い出して多要素認証をかけます。すぐには難しい経路は、接続元IPアドレスの制限や作業時だけの接続開放で補います。作業が終わった委託先のアカウントや、付けたままの管理者権限も棚卸しの対象です。契約面では、再委託の手続き、インシデント発生時の通知義務、契約終了時のデータ消去を盛り込むよう求めています。委託先を選ぶ際の客観的な評価として、経済産業省の「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」も挙がっています。申請受付は2027年3月に始まる予定です。
委託先に対策を求める際の注意書きも添えられています。費用負担や実施方法を十分に協議し、取引上の立場を利用して一方的に負担を押し付けないように、という内容です。
OSSや外部ライブラリについては、中身の分からない部品を使い続けないことが基本です。深刻な脆弱性が公表されたとき、保守事業者任せにせず自社で影響を判断できる手順を決めておくこと。委託開発ではSBOMの提出を契約や仕様で定め、検収時に既知の脆弱性やライセンスを確認すること。この2点が対策例として挙がっています。
10月9日の文書からの変化：対象をウェブとアプリに絞り、手段まで具体化
国家サイバー統括室は10月9日にも、大量の個人情報を扱う事業者向けに対策を求める文書を出しています。このときは「ウェブシステム等の適切な管理」「サプライチェーンを通じた侵害への対策」「データの適切な管理」の3分野で、基本的な対策を幅広く並べる内容でした（詳しくは10月9日の文書の解説記事）。
11月5日の文書は、対象をウェブサイトとモバイルアプリに絞ったうえで、次の点を前面に出しています。2つの文書を読み比べた teriablog の整理です。
- 攻撃者のAI利用を明記し、防御側にもAI活用の検討を求めた
- モバイルアプリとバックエンドのAPIを独立した項目として扱った
- 運用中の対策に加え、設計・開発段階とリリース前の診断まで範囲を広げた
- SBOM、ASM、KEVカタログ、SAST・DASTなど、担当者がすぐ調べて着手できる水準まで手段を具体化した
10月の文書が「対策を徹底してください」という要請だったのに対し、今回は「この手段で、この場所を点検してください」と一段踏み込んだ内容です。
小さな事業者がまず確かめたい5項目
文書は対策を網羅的に並べていますが、専任のセキュリティ担当がいない事業者がすべてを一度に進めるのは現実的ではありません。文書の対策例のうち、手間が比較的小さく被害に直結しやすいものを teriablog の判断で選ぶと、次の5つになります。
- 管理画面（ブログやECサイトのCMSを含む）がインターネットから誰でも開ける状態になっていないか。開ける場合は、アクセス元の制限と多要素認証をかける
- サポートが終わったソフトウェアや、更新が止まったプラグイン・ライブラリが残っていないか
- 開発・検証用の環境やデバッグ機能が、外部から到達できる状態で残っていないか
- 委託先や保守業者が使うVPN・リモート接続に多要素認証がかかっているか。作業が終わったアカウントが残っていないか
- アプリを外注している場合、アプリ内にAPIキーなどが埋め込まれていないか、APIの権限確認をサーバー側で行っているかを委託先に確かめる
文書の参考資料には、IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」や「ECサイト構築・運用セキュリティガイドライン」なども挙がっています。点検の進め方に迷ったときの手がかりになります。
サービスの利用者が知っておきたいこと
この文書は事業者向けで、サービスの利用者に向けた呼びかけは含まれていません。挙がっている原因の多くは、利用者の側からは防ぎようのない事業者側の不備です。利用者にできるのは、漏えいが起きたときの被害を小さくしておくことです。サービスごとにパスワードを変える、使えるサービスでは多要素認証を有効にする、漏えいの通知が届いたら事業者の公式の案内に沿って対処する、という基本は変わりません（この段落は teriablog の考えで、文書の記載ではありません）。
まとめ：新しい対策より、基本を確実に回すことが求められている
11月5日の文書は、AIによって攻撃が大規模化し、小さな弱点の組み合わせでも侵入されうるという認識のもと、ウェブサイトとモバイルアプリの基本対策を具体的な手段まで示しました。求められているのは目新しい対策ではありません。公開している資産の把握、不要な入口の閉鎖、APIの権限確認と鍵の管理、委託先の接続経路の保護といった基本を、運用・開発・委託のそれぞれで確実に回すことです。事業規模を理由に後回しにできる状況ではない、というのが文書全体を通したメッセージです。
関連記事
- 【考察】国家サイバー統括室・IPAが漏えい対策を要請｜10/9文書と相次ぐ事案から読む
- 【2026年10月】情報漏えい相次ぎ国が注意喚起｜NCO・IPA・個情委など8機関の声明を一次情報で整理
- 【2026年9月〜10月】情報漏洩まとめ｜ソースネクスト・タイムズカー・バーガーキングなど主要事例と侵入経路
出典：内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」（2026年11月5日）
元記事URL：https://www.cyber.go.jp/pdf/press/261105_taiou.pdf
コメント