PJ-T&C合同会社

3分でわかるこの記事の要約

技術は制作会社に任せてよい。ただし「聞く」「契約に書く」「アカウントを守る」は発注側にしかできない。

本記事は約13,000字あります。先に結論だけ知りたい方のために、全体像をまとめました。

1

政府が「基本的な対策の不足」を名指しした

内閣官房国家サイバー統括室は2026年11月5日、相次ぐ個人情報漏えいについて「自組織又は委託先における基本的な対策が十分でなかった」事例を複数確認したと公表し、8項目の対策を示しました。

2

8項目は3領域。発注側が直接関わるのは2つ

「運用・管理」「設計・開発」「サプライチェーン」。設計・開発は制作会社の仕事ですが、運用・管理と委託先の管理は発注側の責任として残ります。設計・開発の品質も、契約と検収で担保するのは発注側です。

3

今週中に確認できる3つのこと

• 管理画面（wp-admin、phpMyAdmin、開発・検証環境）が外から誰でも開けないか
• 管理者・制作会社・保守会社の全員が多要素認証か。辞めた人・終わった会社のアカウントが残っていないか
• サポート終了のソフト（古いPHP、更新が止まったプラグイン）が残っていないか。残っていれば誰が更新の責任者か

PDFチェックリスト（PDF）をダウンロードサイト種類別・50項目。制作会社にそのまま渡せる質問票
KEYフィッシング耐性のある認証を始める複数メーカーの物理セキュリティキーを比較・ご相談 — security.pj-tc.com

※ 上記は対策の全体像です。各項目の根拠と前提条件は本文で説明しています。

序章：2026年11月5日、政府は何を言ったか

内閣官房国家サイバー統括室（NCO）は2026年11月5日、事業者向け文書「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」を公表しました。対象は「特にウェブサイトやモバイルアプリを使用した事業を運用し、個人情報を取り扱っている事業者等」です。

同室は10月9日にも「不正アクセスによる漏えい等の事案を踏まえた対応について」を公表しています。10月9日の文書は経営層向けに、ウェブシステムの管理、サプライチェーン、データ管理の3分野で考え方を示したものでした。11月5日の文書はその続編で、ITシステム・サイバーセキュリティ担当者向けに具体的な対策例を列挙しています。

11月5日の文書には、発注側の経営者・担当者が知っておくべき指摘が3つあります。

1. 原因は「基本的な対策の不足」。モバイルアプリ開発時のセキュリティ対策不足、ウェブサイト等の設定不備、サポートが終了しているソフトウェアや既知の脆弱性が未対策のソフトウェアの継続使用など、自組織または委託先における基本的な対策が十分でなかったとみられる事例を複数確認した、と書かれています。攻撃手法の高度さより先に、基本的な対策の抜けを問題にしている指摘です。
2. 攻撃者はAIで大規模に調査している可能性が高い。攻撃者は国内の公開ウェブサイトを広く調査し、侵入方法が見つかったサイトに侵入したとみられる、標的の調査や侵害にAIを使用している可能性も高い、と書かれています。これまでの脆弱性診断で「比較的低い」と評価されたリスクでも、組み合わされることで侵入の原因になった可能性のある事例がある、という点は重要です。なお、個々の事案でAIが使われたと確定したものではありません。
3. 事業規模の大小を問わない。攻撃の大規模化が容易になったことで、幅広い事業者が攻撃対象になっていると考えられる、と書かれています。「うちは小さいから狙われない」は前提として成り立ちません。

文書は13ページあり、SBOM、ASM、SAST/DAST、BOLA といった用語が並びます。制作会社に向けた内容としては適切ですが、発注側がそのまま読んで自社の確認事項に落とすのは難しい文書です。

本記事は、この8項目を「発注側が制作会社に何を聞けばよいか」「契約に何を書けばよいか」に組み替えたものです。技術的な前提知識がなくても読めるように書いています。なお、本記事は文書の要約ではなく解釈を含みます。原文は参考情報に掲載した公式PDFで確認してください。

第1章：8項目の全体像

8項目を、発注側の視点で「自社でやる」「制作会社に聞く」「契約に書く」に振り分けると次のようになります。番号は本記事の便宜上のもので、原文では「1.（1）」のように領域と項番で示されています。

原文では、各項目に「サイバーセキュリティ担当者等向け」の対策例が2〜3件ずつ付いています。本記事では、そのうち発注側の判断に関わるものだけを取り上げます。

一つ補足します。「AIの活用」は項目3の見出しに入っていますが、原文は「AIを活用したセキュリティ診断ツール等の導入・活用を積極的に検討」「AIによる評価結果については、根拠や妥当性を確認し、最終的な対応判断については人による確認を行う」と書いています。発注側が特定のAIツールを指定する話ではなく、制作会社や診断会社が診断をどう効率化しているかを聞く材料と捉えてください。

第2章：自社ウェブサイト（コーポレートサイト・ECサイト）で確認すること

対象は、WordPress等のCMSで作ったコーポレートサイトや、問い合わせフォーム・ECを持つサイトです。対応する項目は1（資産把握）、2（アタックサーフェス）、3（継続診断）、8（OSS管理）です。

確認1：管理画面が外から見えていないか

原文は、インターネットに公開されたシステム管理画面に対する推測されやすい認証情報の悪用、総当たり攻撃、認証回避による不正アクセスが確認されていると書いています。また、外部公開を想定していないデバッグ用機能や管理用エンドポイントがアクセス可能だった例も挙げています。

制作会社に聞くこと：

• WordPressの管理画面（/wp-admin/）、phpMyAdmin、サーバーのコントロールパネルは、IPアドレス制限か追加認証で守られているか
• 開発・検証環境（staging、test といった名前のサブドメイン）がインターネットから見えていないか。見えている場合、本番と同じ個人情報が入っていないか
• クラウドストレージ（Amazon S3、Google Cloud Storage など）やバックアップファイルが誰でもダウンロードできる設定になっていないか

原文の対策例は「外部からのアクセス可否及び公開の必要性を点検する」「不要な機能は停止・無効化し、管理上必要な機能についても、アクセス元制限、多要素認証等を組み合わせて保護する」です。経済産業省のASM（Attack Surface Management）導入ガイダンス（2023年5月）が参考資料として挙げられており、外部から見える資産を自社の台帳と突き合わせる考え方が示されています。

確認2：管理者と委託先の全員が多要素認証か

管理画面への不正アクセスでは、推測されたパスワードや、フィッシングで盗まれたパスワードによる正規のログインが確認されています。原文は管理機能の保護に「多要素認証等」を挙げています。

自社で確認すること：

• 管理者権限を持つアカウントを全員分、一覧にする（自社の担当者、制作会社、保守会社、広告代理店）
• 全員が多要素認証を設定しているか
• 退職した人、契約が終わった制作会社のアカウントが残っていないか。残っていれば削除する
• 管理者権限は本当に必要な人だけか。記事を投稿するだけの人に管理者権限を与えていないか

多要素認証の方式には差があります。SMSや認証アプリのワンタイムコードは、偽サイトに入力してしまうと攻撃者に中継される可能性があります。パスキーや物理セキュリティキー（FIDO2/WebAuthn）は、認証が正規ドメインに暗号学的に紐づくため、偽サイト上では認証が成立しません。米国NISTの認証ガイドライン（SP 800-63B）は、この方式をフィッシング耐性のある認証と位置づけています。ただし、利用するCMSやサービスがFIDO2に対応していることが前提です。WordPressには標準機能としては備わっておらず、プラグインで追加することになりますが、プラグインの更新状況や復旧手順の検証が必要です。この点は別の記事で扱います。

確認3：サポートが終了したソフトが残っていないか

原文は「サポートが終了しているソフトウェアや既知の脆弱性が未対策のソフトウェアの継続使用」を漏えいの原因として名指ししています。

制作会社に聞くこと：

• サイトで使っているソフトの一覧（WordPress本体、PHP、プラグイン、テーマ、ライブラリ）とそれぞれのバージョンを出してもらう
• その中にサポート終了（EOL）のものがないか。PHPは各バージョンにサポート期限があり、更新が止まったプラグインも珍しくありません
• 更新を誰がいつ行うか。保守契約に「本体・プラグインの定期更新」が含まれているか。含まれていなければ、誰がいつ更新しているのかを確認する

原文は「ソフトウェア構成情報の把握・管理」として、製品名、バージョン、利用箇所を把握し、脆弱性情報と照合する運用を求めています。制作会社が一覧をすぐに出せない場合は、構成を管理する台帳が無い可能性があります。それも確認結果の一つです。

確認4：脆弱性診断が契約に入っているか

原文は、公開前だけでなく、認証・認可・API・個人情報の取扱いに関わる重要な変更時と運用開始後も、リスクに応じて継続的に診断・点検を行うことを求めています。参考資料としてIPA「安全なウェブサイトの運用管理に向けての20ヶ条」とIPA「ECサイト構築・運用セキュリティガイドライン」が挙げられています。

契約で確認すること：

• 保守契約に脆弱性診断が含まれているか。含まれている場合、頻度（年1回など）と、結果の報告書が出るか
• 大きな改修（決済の追加、会員機能の追加）のあとに診断を行うか
• 診断で見つかった問題を誰が、いつまでに直すか

診断の頻度は、サイトで扱う情報の量と種類で決めます。問い合わせフォームだけのコーポレートサイトと、会員情報を持つECサイトでは必要な水準が違います。制作会社に「どの水準が妥当か」を聞き、その答えを契約に反映してください。

この章のまとめ

確認1と2は自社で今週中にできます。確認3と4は制作会社に聞く必要がありますが、答えを待つあいだに「保守契約に何が含まれているか」を自社で読み直してください。

出典：NCO文書 第1章（1）〜（3）、参考資料1-1・1-4・1-5・1-6、NIST SP 800-63B

第3章：会員制サイト（ログインして個人情報を扱う）で確認すること

対象は、会員がログインして自分の情報を見たり、予約・購入・申込をしたりするサイトです。会員の氏名・住所・電話番号・利用履歴を自社システムが保持します。第2章の確認に加えて、対応する項目は4（セキュリティ・バイ・デザイン）、5（API）、6（公開前診断）です。

会員制サイトは、コーポレートサイトと違って「ログインした人が、見てよい情報だけを見られるか」という問題を抱えます。原文が設計・開発段階の対策として挙げている内容は、ほぼこの問題に関わるものです。

確認1：会員Aが会員Bの情報を見られないか

原文は、認証された利用者が本来アクセス権限を持たない情報や機能へアクセスできる状態を「認可不備」と呼び、情報漏えいや不正操作につながると書いています。具体的には「オブジェクトレベルの認可不備（BOLA）」と「機能レベルの認可不備（BFLA）」の2種類を挙げ、OWASP API Security Top 10（API1:2023、API5:2023）を参考資料としています。

言い換えると次のような状態です。

• 会員ページのURLが /mypage?id=1001 のようになっていて、数字を1002に変えると他人のページが見える
• 一般会員が、管理者向けの機能のURLを直接入力すると使えてしまう

原文は「APIリクエストが要求した機能及びデータに対する正当な権限を利用者が有することをサーバー側で検証する」ことを求めています。画面上でボタンを隠すだけでは対策になりません。

制作会社に聞くこと：

• 「ログインした会員が、他の会員のデータを参照・変更できないことを、サーバー側で検証していますか」
• 「その検証を、公開前の診断で確認しましたか」

この質問に「フレームワークが自動でやっている」とだけ返ってきた場合は、具体的にどの処理でどう確認しているかまで聞いてください。

確認2：ログインとパスワードリセットに回数制限があるか

原文は、認証機能やパスワードリセット機能に対して、短時間に大量のリクエストが送信された場合にアクセスを制限するレート制限を求めています。あわせて、同一IPアドレスからだけでなく、複数のIPアドレスからのアクセスも含めて異常を検知する仕組みを挙げています。参考資料はOWASP API Security Top 10 API4:2023です。

制作会社に聞くこと：

• 同じアカウントに対するログイン失敗が続いたとき、一時的にロックされるか
• パスワードリセットの申請が短時間に大量に来たとき、止まるか
• そうした異常がログに残り、通知されるか

確認3：会員データの一括出力は誰ができるか

国家サイバー統括室が10月9日に出した文書は、データへのアクセスを業務上必要な利用者に限定し、閲覧権限と更新権限を分け、管理者権限を必要最小限にすることを求めています。

会員制サイトでは、管理画面から会員一覧をCSVで出力できる機能がよくあります。この機能を持つアカウントが乗っ取られると、会員全員の情報が一度に持ち出されます。前回の記事で取り上げたスタッフアカウント乗っ取りの事例は、まさにこの形でした。

自社で確認すること：

• 会員データの一括出力（CSVエクスポート、API経由の一覧取得）ができる人は誰か
• その人たちは全員、多要素認証を設定しているか
• 出力の操作がログに残るか

確認4：会員にもフィッシング耐性のあるログインを用意できるか

これは必須ではなく、サイトの性質で決める項目です。会員が預けている情報の重要度が高い場合（決済情報、医療・金融に関わる情報）、会員自身のアカウントが乗っ取られる被害も想定する必要があります。

制作会社に聞くこと：

• 使っている基盤（WordPressの会員プラグイン、Laravel等のフレームワーク、SaaS）はパスキー（FIDO2/WebAuthn）ログインに対応しているか
• 対応している場合、会員に任意で設定してもらう形にできるか

対応していない基盤に無理に追加する必要はありません。対応状況を把握しておくことが目的です。

確認5：公開前に診断し、報告書を受け取ったか

原文は、個人情報を取り扱うウェブアプリについて、リリース前に脆弱性診断やペネトレーションテストを実施し、検出された脆弱性に対して是正措置を実施し、その結果を確認した上で本番環境へ公開することを求めています。

また「あらかじめ受容可能なリスク水準を定め、その基準に基づいてリリース可否を判断する運用」、いわゆるセキュリティゲートの設定を求めています。一定以上のリスクを持つ脆弱性が残った状態で本番公開しない方針を定めること、修正責任者と対応期限を明確にすることが対策例に書かれています。

発注側が確認すること：

• 公開前に診断を行ったか。行った場合、報告書を受け取ったか
• 報告書に残っている指摘があるか。あるなら、なぜ残ったまま公開したのか
• 診断を第三者に委託した場合、その会社はウェブアプリ診断・API診断の実績があるか。原文は「情報セキュリティサービス基準」に適合したサービスを提供する事業者の選定を挙げています

「診断したかどうか」は制作会社の判断に任せるものではなく、発注側が契約で求め、報告書を受け取って初めて確認できたことになります。

この章のまとめ

会員制サイトの対策は、第2章の「外から守る」に「中で分ける」が加わります。確認1と2は技術的な実装の話なので、答えは制作会社から聞くしかありません。確認3は自社で今週中にできます。

出典：NCO文書 第2章（1）〜（3）、参考資料2-5・2-6・2-8・2-10、NCO 10月9日文書、OWASP API Security Top 10 2023

第4章：ウェブアプリ・モバイルアプリ（自社開発・受託開発）で確認すること

対象は、業務用のウェブアプリ、顧客向けのモバイルアプリ、それらが通信するバックエンドのサーバーです。対応する項目は4（セキュリティ・バイ・デザイン）、5（API）、6（公開前診断）、8（OSS管理）です。第3章の確認も当てはまります。

11月5日の文書のタイトルに「モバイルアプリ」が入っているのは、アプリを起点にした漏えいが相次いだためです。原文は、国立研究開発法人情報通信研究機構（NICT）が注意喚起した「A2B（App-to-Backend）攻撃」に触れています。公開されているアプリを解析してAPIの弱点や認可不備を特定し、バックエンドから機密情報を窃取する手口です。

確認1：アプリの中に秘密情報が埋め込まれていないか

原文は、ソースコードやアプリケーションパッケージ内にAPIキー、アクセストークン、秘密鍵、データベース接続情報が埋め込まれていると、アプリの解析によって窃取される可能性があると書いています。参考資料はOWASP Mobile Top 10 2024 M1（Improper Credential Usage）です。

モバイルアプリは、ストアから誰でもダウンロードして中身を解析できます。アプリの中に書かれた秘密鍵や認証情報は、解析されれば取り出せます。公開されているものとして扱う必要があります。

制作会社に聞くこと：

• 「アプリの中に、サーバーやクラウドサービスの鍵を書いていますか」
• 「鍵はサーバー側のシークレットマネージャーで管理し、有効期間と定期的なローテーションを設定していますか」
• 「ソースコードをコミットするときやCI/CDで、鍵の混入を検知するシークレットスキャンを行っていますか」

原文は3つとも対策例として挙げています。

確認2：認可はサーバー側で検証しているか

第3章の確認1と同じ内容です。モバイルアプリの場合、アプリの画面で機能を隠しても、攻撃者はアプリを経由せずにAPIを直接呼べます。「アプリ側で制御している」は対策になりません。

制作会社に聞くこと：

• 「すべてのAPIについて、呼び出した利用者がそのデータと機能に権限を持つことをサーバー側で検証していますか」

確認3：SBOM（ソフトウェア部品表）が納品物に含まれているか

原文は、開発・改修を委託する際に、使用するソフトウェア部品の明示とSBOMの提出を契約・仕様に定め、検収時に既知の脆弱性やライセンスの確認結果とあわせて内容を確認することを求めています。参考資料は経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0」（2024年8月）です。

SBOMは、アプリに含まれるOSSやライブラリの一覧です。これがあると、新しい脆弱性が公表されたときに「うちのアプリに影響があるか」をすぐに判断できます。ないと、制作会社に聞いて調べてもらうところから始まります。

発注側が確認すること：

• 既存のアプリについて、SBOMまたはそれに相当する部品一覧を受け取っているか
• 受け取っていなければ、次の改修から納品物に含める
• 納品後も新しい脆弱性の公表を監視する体制（SCAツールの活用）を、自社か制作会社のどちらが持つか

確認4：開発工程に自動のセキュリティ検査が入っているか

原文は、実装段階でSAST（静的解析）とSCA（構成解析）、テスト段階でDAST（動的検査）とIAST（対話型検査）を活用し、必要に応じてCI/CDパイプラインへ統合することを求めています。

発注側がツール名を指定する必要はありません。「結果の報告」を求めてください。

制作会社に聞くこと：

• 「開発中に自動のセキュリティ検査を行っていますか。行っている場合、検出された問題と対応の記録を見せてください」

確認5：公開の判断基準を誰が決めるか

第3章の確認5と同じです。アプリの場合、ストアへの申請と公開は制作会社が代行することが多く、「いつの間にか公開されていた」ことが起きます。

発注側が決めること：

• どの深刻度の脆弱性が残っていたら公開しないか（セキュリティゲート）
• その判断を誰が行うか。制作会社ではなく、発注側の責任者が最終判断する

この章のまとめ

アプリの対策は、ほぼすべて設計・開発の工程に埋め込まれています。発注後に追加するのは難しく、費用もかかります。原文も「後から修正するコストは設計時に防止する場合と比較して大幅に増加する」と書いています。確認3と5は次の発注から契約に入れてください。

出典：NCO文書 第2章（1）〜（3）、第3章（2）、参考資料2-4・2-7・3-7、NICT注意喚起（2026年10月13日）、OWASP Mobile Top 10 2024、経済産業省SBOM導入手引 ver2.0（2024年8月）

第5章：制作会社・保守会社との契約で担保すること

対応する項目は7（委託先の統制と接続経路）と8（OSS管理）です。ここは制作会社に聞くことではなく、発注側が自社の契約と運用を見直す章です。

委託先の接続は「正規の認証情報を使った入口」

原文は、業務委託先や保守事業者の環境を足掛かりとして発注元のシステムへ侵入される事案が確認されていると書いています。委託先が使うリモート接続環境は、攻撃者にとって正規の認証情報を用いた侵入口になり得る、という指摘です。そして、サービス停止や情報漏えいの影響は発注元が負うことになる、と続きます。

自社で確認すること：

• 制作会社・保守会社がサーバーに入る経路（VPN、リモートデスクトップ、FTP/SFTP、保守用回線）をすべて洗い出す
• その経路に多要素認証が掛かっているか。原文は「重要度の高い経路から計画的に多要素認証へ切り替える」としています
• 多要素認証が難しい経路には、接続元IPアドレスの制限、作業時のみの接続開放、作業記録の取得といった代替策を講じる
• 作業が完了した委託先のアカウント、常時付与されたままの管理者権限を棚卸しし、無効化・最小化する

接続経路の多要素認証は、委託先の担当者が何人いても、全員に行き渡っていなければ意味がありません。物理セキュリティキーは、委託先に1人1本配布して「この鍵がないと入れない」状態にする運用に向いています。第2章の確認2で触れたとおり、フィッシングで中継されない点が、ワンタイムコードとの違いです。

契約書に入れる5項目

原文は、発注仕様書や業務委託契約書に次の要件を盛り込むことを求めています。

1. 秘密保持義務（多くの契約に既にある）
2. 再委託の手続き（制作会社がさらに外注するときの承認）
3. インシデント発生時の通知義務と連絡先
4. 契約終了時のデータ消去
5. SBOMの提出（第4章の確認3）

これに加えて、原文は「深刻な脆弱性の公表時における初動対応手順の明確化」を挙げています。ゼロデイ脆弱性の注意喚起が出たとき、保守事業者任せにせず、発注側で迅速に判断できる手順を定めるというものです。具体的には、影響調査の責任者、委託先との役割分担、経営層への報告基準、修正プログラム適用・WAFによる防御・機能停止といった暫定対策の判断手順です。

参考資料としてIPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」の付録5（情報セキュリティ関連規定のサンプル）が挙げられています。契約書の条文を一から書く必要はありません。

「制作会社に任せている」は免責にならない

原文は、個人情報の取扱いを委託する場合、個人情報保護法第25条により委託先に対する必要かつ適切な監督が求められている、と明記しています。委託先で漏えいが起きた場合も、委託元の責任が問われます。

同時に、原文は「委託先に対策を求める際は、費用負担や実施方法について十分に協議し、取引上の地位を利用した一方的な負担の押し付けとならないよう留意」とも書いています。参考資料は経済産業省・公正取引委員会「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」です。

本記事で挙げた確認事項を制作会社に求めるときは、追加費用が発生するものがあります。診断、SBOMの作成、接続経路の多要素認証化は、保守費用に含まれていないことが普通です。「今の契約の範囲でできること」と「追加費用が必要なこと」を分けて協議してください。

委託先の選定に使える制度

原文は、委託先の選定時に第三者認証や「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」（2027年3月申請受付開始予定）等の客観的な評価を活用する、としています。今はまだ運用前ですが、2027年以降は「SCS評価を取得しているか」が制作会社を選ぶ基準の一つになります。

この章のまとめ

契約の見直しは今週中には終わりません。ただ、「委託先の接続経路の洗い出し」と「終わった案件のアカウント削除」は今週中にできます。契約への反映は、次の更新時期に向けて準備を始めてください。

出典：NCO文書 第3章（1）〜（2）、参考資料3-1〜3-7、個人情報保護法第25条、経済産業省SCS評価制度

第6章：事例 — 移行プラグインのバックアップが公開状態だったケース

第2章の確認項目を実際に行うと何が見つかるか、ある事業者の例を紹介します。複数のWordPressサイトを同一のレンタルサーバーで運用している小規模事業者で、確認は2026年11月に行われました。個別の名称は伏せますが、経緯と対処は事実のままです。

何が見つかったか

第2章の確認1（バックアップ・ストレージの公開設定）で、サイト移行に使ったプラグイン（All-in-One WP Migration）のエクスポートファイル（拡張子 .wpress）が、wp-content/ai1wm-backups/ に残っていました。同一サーバーの複数サイト分。最も新しいものは約2週間前のサイトリニューアル時のもの、最も古いものは数年前のものでした。

このファイルは、URLを知っていれば誰でもダウンロードできる状態でした。中身はサイト全体です。データベース（問い合わせフォームの受信内容、会員情報、管理者のパスワードハッシュ）と、wp-content配下のファイル（プラグインの設定、外部サービスとの連携に使う鍵）が含まれていました。

なぜ起きたか

原因は3つの重なりです。

1. プラグインが、ウェブから見える場所にバックアップを置く。 wp-content/ の中は公開領域です。プラグインはファイル名にランダムな12文字を付けて推測されにくくしていますが、置き場所そのものは変わりません。
2. プラグインの保護が、このサーバーでは効かなかった。 ディレクトリには .htaccess が置かれていましたが、内容は一覧表示を止めるだけ（Options -Indexes）でした。さらに、このレンタルサーバーは静的ファイルをnginxがApacheを通さずに直接配信する構成だったため、仮に .htaccess に拒否ルールがあってもファイル本体には効きません。
3. 作業後にファイルを消していなかった。 プラグインは自動では削除しません。移行や複製の作業が終わったあと、サーバー側のファイルを消す手順が運用に無かったため、年単位で残っていました。

この3つのうち、発注側が関われるのは3だけです。1と2はサーバーとプラグインの仕様で、制作会社に確認してもらう内容です。

第三者に取られたか

判定できませんでした。レンタルサーバーのアクセスログは直近2週間弱しか残っておらず、ファイルが置かれてから最初の数日間の記録がありません。残っていた期間には、バックアップファイルへの第三者アクセスはありませんでした。ただし、この期間中に自動スキャナーが /wp-content/ai1wm-backups/ ディレクトリの存在を確認していた記録（応答200）が残っていました。ファイル名までは到達していませんが、この場所を狙うスキャンが日常的に来ていることは分かります。

この種のチェックは脆弱性スキャナーの定番項目です。Acunetixは「WordPress migration backup publicly accessible」として登録し、対象として ai1wm-backups（All-in-One WP Migration）、updraft（UpdraftPlus）、backups-dup-lite（Duplicator）などを並べています。

どう対処したか

取得されていないことを証明できないため、「取得された前提」で対処しました。発見から同日中に完了しています。

個人情報保護委員会への報告要否は、要配慮個人情報、財産的被害のおそれ、不正の目的、対象者が1,000人超、の4つの事態に当たるかで決まります。この事業者は、上記の記録を残した上で、現時点では報告対象外と判断しています。注意点が2つあります。ログで第三者の閲覧が無かったと確認できない期間がある場合は「漏えいのおそれ」に当たりうること（個人情報保護委員会 Q&A 6-2）、そして報告期限の起算点は「報告対象事態を知った時点」であること（同 Q&A 6-24）です。判断に迷う場合は専門家に確認してください。

発注側が制作会社に聞くこと

この事例から、第2章の確認1に次の質問を加えてください。

• 「サイトの移行・複製・バックアップに使ったプラグインのファイルが、サーバーに残っていませんか」
• 「残っている場合、外部からダウンロードできない場所にありますか。それをどう確認しましたか」
• 「このサーバーでは .htaccess によるアクセス制限が静的ファイルに効きますか」

3つ目の質問に即答できる制作会社は多くありません。答えられなければ、サーバー会社の仕様を確認してもらってください。

出典：NCO文書 第1章（2）（3）・第2章（2）、Acunetix「WordPress migration backup publicly accessible」、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」漏えい等の報告、同「個人情報の保護に関する法律についてのガイドラインに関するQ&A」6-2・6-24

結論：発注側がやることは「聞く」「契約に書く」「アカウントを守る」の3つ

国家サイバー統括室の8項目は、技術的には制作会社が実装するものです。発注側がコードを書くことはありません。ただし、次の3つは発注側にしかできません。

1. 聞く。使っているソフトの一覧、管理画面の公開状態、認可の検証、診断の実施。制作会社に聞いて、答えを受け取る。答えがすぐ出てこないこと自体が確認結果です。
2. 契約に書く。診断の頻度と報告、SBOMの提出、インシデント通知、契約終了時のデータ消去、公開の判断基準。口約束ではなく契約と検収で担保する。追加費用が必要なものは協議する。
3. アカウントを守る。管理者と委託先の全員に多要素認証。辞めた人と終わった案件のアカウントを消す。これは今週中にできます。

原文は、基本的な対策の不足が原因とみられる漏えい事案を複数確認したとしています。本記事は、その「基本的な対策」のうち発注側が確認できるものを、この3つに整理しました。

チェックリスト（PDF）のご案内

第2章から第6章の確認事項を、サイトの種類別（コーポレート・EC／会員制／アプリ／契約）に50項目の質問票にまとめました。各項目に「聞く相手」「優先度」「原文の根拠」を付けています。制作会社にそのまま渡していただける形です。

セキュリティ確認チェックリスト（PDF）をダウンロード

質問票を渡した制作会社から返ってきた答えの読み方に迷う場合は、お気軽にご相談ください。また、管理者や委託先の多要素認証にフィッシング耐性のある物理セキュリティキーをご検討の場合は、security.pj-tc.com で各社製品を比較いただけます。

参考情報（一次情報）

本記事の事実関係は、2026年11月8日時点で確認できる公的機関の公開資料にもとづいています。

政府文書

• 内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」2026年11月5日 — cyber.go.jp（PDF）
• 内閣官房国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」2026年10月9日 — cyber.go.jp（PDF）
• 国立研究開発法人情報通信研究機構（NICT）「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」2026年10月13日 — cynex.nict.go.jp（PDF）

11月5日文書が参考資料として挙げているもの（本記事で言及したもの）

• 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」2024年8月 — meti.go.jp
• 経済産業省「ASM（Attack Surface Management）導入ガイダンス」2023年5月 — meti.go.jp
• IPA「安全なウェブサイトの運用管理に向けての20ヶ条」 — ipa.go.jp
• IPA「ECサイト構築・運用セキュリティガイドライン」 — ipa.go.jp
• IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録5 — ipa.go.jp
• OWASP「API Security Top 10 2023」API1（BOLA）・API4（Unrestricted Resource Consumption）・API5（BFLA） — api-security.owasp.org
• OWASP「Mobile Top 10 2024」M1（Improper Credential Usage） — owasp.org
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」委託先の監督・漏えい等の報告 — ppc.go.jp
• 個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」6-2・6-24（漏えい等の該当性、報告期限の起算点） — ppc.go.jp
• 経済産業省・公正取引委員会「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」 — meti.go.jp
• 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 — meti.go.jp
• 情報セキュリティサービス基準審査登録制度「情報セキュリティサービス台帳」 — sss-erc.org

その他

• NIST SP 800-63B「Digital Identity Guidelines: Authentication and Lifecycle Management」— フィッシング耐性のある認証方式の位置づけ
• Acunetix「WordPress migration backup publicly accessible」 — acunetix.com

報道（二次資料）

• ITmedia NEWS「政府、相次ぐ情報漏えいで事業者に注意喚起」2026年11月6日 — itmedia.co.jp
• INTERNET Watch「国家サイバー統括室、事業者向けに不正アクセス対策のポイントをまとめた資料を公開」2026年11月6日
• Impress Watch「国家サイバー統括室、個人情報漏えい対策の徹底を要請」2026年11月6日 — watch.impress.co.jp
• piyolog「国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた」2026年10月11日 — piyolog.hatenadiary.jp