Webサイトのお助け隊

自社のサーバーには何も起きていないのに、自社名でお知らせを出すことになる。そういう状況が実際に起きています。使っている外部のシステムが侵害され、そこに預けていた顧客情報が対象になったとき、公表するのは預けた側です。相手の調査が終わるまで原因は書けず、件数も確定しない。2026年6月1日から10月8日までに公表・報道された漏えい事案を集計した調査資料から、この連鎖がどう広がったのかを見ていきます。そのうえで、発注と運用の段階で決めておける項目に落とします。

「自社のシステムは侵害されていない」という公表文が3社から出た

集計の母数は176件です。公式発表が確認できたもの114件と、報道のみで公式が未確認のもの62件の合計で、対象期間は2026年6月1日から10月8日まで。原因別に見ると、最も多いのが原因不明の60件（34%）、続いて人的ミス28件（16%）、認証情報の窃取やアカウント乗っ取り27件（15%）、脆弱性の悪用25件（14%）。そして委託先やサプライチェーン経由が16件、全体の9%です。公開情報のみを積み上げた資料で網羅性には限界があるため、実際にはこれより多いと考えるほうが自然です。

この9%が厄介なのは、1つの侵害から複数の公表が発生するところです。期間内でいちばん分かりやすい形になったのが、FAQシステムを提供している会社の事案でした。管理サイトへの不正ログインと不正プログラムの設置が公表され、同じサーバー上にあった利用企業のデータベースから情報を取得された可能性があるとされています（約71.3万件）。

ここから、証券会社（約22万件）、時計メーカー（約10万件）、損害保険会社（約6万件）がそれぞれ個別に公表を出しました。いずれも公式発表があり、どの会社も自社のシステムについては侵害が確認されていないと記載しています。つまり、自社の設備には手を入れられていないのに、顧客に知らせる主体は自社になる、という構図です。

同じ期間には、ISP向けのメールシステムの脆弱性が悪用され、そのシステムを使っていたISP各社に影響が及んだ事案も公表されています（最大約1,422万件）。基盤を1つ押さえられると、その上に乗っている事業者の数だけ公表が並びます。

基盤側の事案か、使っている側の事案か

公表の主体がどこになるかは、侵害された場所で決まります。この区別が付いていないと、連絡が来てから混乱します。

メール配信サービスの事案が分かりやすい形でした。配信システムを提供している会社のサーバーに不正アクセスがあり、その会社自身が公表を出す。一方で、そのシステムを委託先が使っていた団体も、自分の会員情報が対象になったことを別に公表しています（約4,111件）。基盤側は「自社のサーバーが侵害された」、利用側は「委託先経由で自社の情報が漏れた」として、別々に出すわけです。旅行会社の公表では、外部のメルマガ配信サービスへの不正アクセスについて、手口は配信事業者側で調査中と書かれていました。利用側が書ける内容には限りがあります。

さらに段数が増えることもあります。ある小売の会社の公表では、問い合わせ管理に使っていた外部サービスの運営会社の、さらにその委託先のサーバーに不正アクセスがあったとされています（約3,560件）。発注の相手の先に、もう1社いる構造です。この段数を把握していないと、どこで止まっているのかが分からないまま日が過ぎます。

委託は運用中だけの話でもありません。破砕処理に出したHDDが未破砕のまま流通してネットオークションに出品された事案（約17万件）と、廃品処理の破損処理が不十分でデータが残ったPCが流通した事案（約4,298件）が、どちらも公式発表として記録されています。報道のみで公式が未確認のものには、保守・運用の委託先がバックアップ作業後のファイルを残し、外部から取得できる状態になっていたとされる事案もありました。契約の入口から出口まで、どこでも起こります。

保守用のアカウントも同じ経路です。行政機関のシステムでは、ネットワーク接続機器の脆弱性を使って侵入されたあと、保守事業者のアカウントが使用されたことが公表されています（約24.6万件）。委託先に渡したアカウントは、委託先の管理下にありながら自社のシステムに入れる鍵です。

発注の時点で決めておける6項目

個人情報保護法には委託先の監督という考え方があります。条文の解釈は専門家の領域なので踏み込みませんが、実務としては、契約と確認の手順に落としておくと事故の後が速いというのが実感です。決めておく項目を、決めていないと起きることと対にしておきます。

6項目のうち、後から埋めるのが最も難しいのが5行目です。ログは相手のサーバーにあるため、取り決めがないと見せてもらえません。見せてもらえないと、こちらの公表文には相手の調査結果をそのまま書くしかなくなります。原因が出てこないときに何が起きるかは脆弱性悪用25件の内訳と、更新が止まった公開資産を数える手順でも触れています。

引き継いだサイトのCSSが、WordPressの外から読み込まれていた

ここから、当社が他社の作ったサイトを引き継いだときに見つかったものを書きます。累計615件・184クライアントの対応のうち、引き継ぎ案件で引き継ぎ資料が揃っていたことはほとんどありません。資料が無い状態が平常です。

美容室のサイトを引き継いだ案件では、子テーマを作るという3,000円の作業から入りました。作業中に分かったのは、CSS・JavaScript・画像が、WordPressのディレクトリの外に置かれていたことです。/home/{アカウント}/css のような場所から読み込まれている。管理画面からは一切触れないため、サイトの持ち主が自分で直せる範囲が最初から存在していませんでした。

もうひとつ見つかったのが、親テーマが wp_head() を使っていないことです。この関数が無いテーマは、子テーマ化しても親テーマのCSSやJavaScriptの読み込みを継承できません。対処として header.php と front-page.php を子テーマ側にコピーして上書きする必要があり、これが「部分的な改修ができない」「修正に費用がかかる」の直接の理由になっていました。混在コンテンツ、つまり http のままになっているURLの読み込みも残っていました。

提示した見積りは、背景画像だけなら1.5万円、トップページ全体なら7万円、親テーマの整理まで踏み込むと25万〜30万円という段階構成です。親テーマの整理については、やらないほうがよいと助言しました。万一のときに親テーマへ戻すだけで現状に復帰できる状態を残しておくほうが安全で、子テーマだけを触る改修なら検証環境を用意しなくても切り戻せます。

この会社は、以前の制作会社と連絡を絶っていました。担当が何度も代わり、自分たちで触れるように作ってほしいという要望が通らなかったためだそうです。結果として、サイトの構成を把握している人が社内にも社外にも誰も残っていませんでした。同じ状態からの調査の進め方は制作会社と連絡が取れないWordPressを引き継ぐときのチェックリストと引き継ぎ資料が無いサイトの調査記録、何から把握していったかに分けて書いています。

改変して使っているプラグインは、更新のたびに同じ所が壊れる

引き継ぎで見つかるもののうち、更新のリスクに直結するのが改変済みのプラグインです。

自作テーマで動いているサイトの改修案件では、トップのスライドショーが表示されなくなっていました。原因はテーマのコードではなく、カスタムフィールド系のプラグインとその拡張を改変して流用していたことでした。本体がメジャーバージョンアップされ、改変部分が前提にしていた挙動が変わって動かなくなった形です。あわせて、ページ送りのプラグインがWordPress側で自動的に無効化されていました。互換性のないプラグインが黙って停止され、テーマは関数の呼び出しを続けるためエラーになる、という流れです。

このサイトはPC版とモバイル版でテーマが分かれており、4つのテーマディレクトリが同居していました。片方だけ直すと必ず追従漏れが出るため、修正後は両方を目視で確認しています。さらに、旧ドメインからのリダイレクト経由のリンクが残っていました。旧ドメインの契約が切れた時点でリンク切れになる構造で、これも引き継ぎ資料には書かれていません。

別の案件では、特定のプラグインの不具合を本体のコードを直す形で対応しました。インストールできるZIPにして納品したのですが、提供元から更新が出ればその修正は上書きされ、同じ症状が戻ります。自動更新が有効なままだと、気づかないうちに繰り返します。納品時に更新前の相談をお願いし、該当プラグインの自動更新を切る運用にしました。前任者から引き継いだ改修案件では、作業の最中に別のプラグインが更新されてデザインが崩れたこともあります。作業期間中は更新を止めるか、更新の有無を確認する必要があります。

外部のシステムを使う場合も同じです。改変して使っているもの、提供元の更新で挙動が変わるもの、誰のアカウントで入っているのか分からないもの。この3つは平常時に一覧にしておく対象になります。

今あるものを確認する順番

契約の見直しから入ると、だいたい止まります。契約書を書き換えるには相手の合意が必要で、時間がかかるからです。先に手を付けるのは棚卸しのほうです。

最初に、外部に預けているデータを書き出します。どのサービスに、どの範囲の個人情報を、いつから置いているか。次に、それぞれの管理画面に誰のアカウントで入れるのかを並べます。退職者のものが残っていないか、保守のために渡したアカウントがどれかも含めてです。ここまでで、把握できていない部分が必ず出てきます。

次が連絡先の整備です。事故のときに誰へ連絡するのか、相手は誰へ連絡してくるのか。担当者個人のメールアドレスしか分からない状態になっていることが多く、その人が異動すると連絡経路が消えます。窓口は人ではなく役割で持っておくほうが切れません。

契約への追記は最後です。棚卸しで出てきた実態をもとに、通知の期限、ログの提供、再委託の扱い、終了時の削除を追記していく。順番を逆にすると、実態と合わない条文だけが増えます。発注時に見るべき点はWeb制作の見積書は、どこを見れば他社と比較できるようになるかにもまとめました。引き継いだサイトの構成を一度調べておきたい場合は、対応実績から近い事例を確認いただけます。

よくある質問

委託先で事故が起きたとき、こちらが公表しないという選択はありますか

公表の判断は、漏えいした情報の内容と範囲、法令上の報告義務の有無によって変わるため、一律には言えません。法的な判断は専門家に確認してください。実務の観点から言えるのは、調査資料に記録されている事案では、基盤側の会社と利用側の会社がそれぞれ別に公表を出している例が多いということです。同じ侵害について、提供元が公表した内容と自社の顧客に伝える内容は別の文章になります。あらかじめ誰がどこまで書くのかを相手と確認しておくと、出す時期がずれにくくなります。

外部サービスを選ぶとき、どこを見れば事故の確率を下げられますか

事故の確率そのものを外から測る方法はありません。見るべきは、起きたときに自社が動けるかどうかです。管理画面に多要素認証が設定できるか、他社のデータと分けて保管されているか、ログを見せてもらえるか、解約時にデータを削除した記録が出るか。この4点は導入前に質問できます。答えられるかどうかではなく、答えを文書で受け取れるかどうかを見てください。事故の後に効くのは口約束ではなく記録です。

引き継ぎ資料が無いサイトは、まず何から調べればよいですか

公開されているファイルの構成からです。WordPressのディレクトリ外から読み込まれているアセット、改変されたプラグイン、同居している複数のテーマ、旧ドメイン経由のリンクが、この順でよく出てきます。管理画面を見るだけでは分からず、FTPでファイルを落として読む必要があります。調査時間は構成によって大きく変わるため、調査と修正を分けて見積もるのが現実的です。