テレビ朝日メディアプレックスの不正アクセス公表をきっかけに、外部から見えたWordPress/PHPの古い構成、ISMS認証との距離、そしてカスタムテーマが更新を止める「塩漬け」の構造を、ERPのアドオン問題とSAP Clean Coreの考え方から読み解く。
2026年7月3日、株式会社テレビ朝日メディアプレックスが「当社サーバへの不正アクセスに関するお知らせとお詫び」を公表した。時系列はこうだ。
認証取得の公表から、わずか11日後の侵害。そして発見から公表まで66日。この時間差に、今回いちばん学べるものがある。
同社サイトは WordPress で構築されている。外部から観測できる範囲、つまり一般公開されているHTTPヘッダとHTMLの中に、構成がそのまま出ていた。
curl -s https://www.mediaplex.co.jp/ | grep -iE "wp-content|ver="
# → wp-includes/js/wp-emoji-release.min.js?ver=4.9.7
# → contact-form-7/...?ver=5.0.3
curl -sI https://www.mediaplex.co.jp/wp-login.php
# → Server: Apache/2.4.61 (Amazon) OpenSSL/1.0.2k-fips PHP/7.1.33
読み取れる構成:
構成のほぼ全体が2018年で時間が止まっている。Apache だけ比較的新しいが、これはクラウド側のイメージ更新でついでに上がっただけと見るのが自然だ。
興味深いのは、同社が運用受託しているサービス群を確認すると、そちらはモダンだったことだ。動画配信サービスは CloudFront + エッジ処理の構成で、WordPress の痕跡はまったくない。同社が公開している事例でも「疎結合CMS・コンテナ・Blue/Greenデプロイ」と説明されている。
客に納めるものはしっかり作られ、モダンに保たれている。止まっていたのは、自社のコーポレートサイトだけだった。
技術力がないのではない。優先順位の問題だ。これはいわゆる「紺屋の白袴」——他人の袴は仕立てるが、自分は白袴のまま、という古い言葉そのものだった。
もう一段、根を掘る。なぜ8年もアップグレードできなかったのか。
答えはおそらく、凝ったカスタムテーマそのものにある。デザインを作り込むほど、WordPressのコアやプラグインの標準的な挙動から離れていく。独自のPHPコードがコアの関数に深く依存すると、コアを新しくした瞬間にサイトが壊れる。だからアップグレードできない。放置するしかなくなる。「動いているものに触るな」——こうして2018年で凍結する。
これは、SAPをはじめとするERPの世界で、何十年も繰り返されてきた失敗と、まったく同じ構造だ。
ERPを導入するとき、標準機能（バニラ）では業務に合わない部分が必ず出る。そこを埋めるために「アドオン」を大量に作り込む。最初は動く。だが数年後、ベンダーがバージョンアップを出したとき、そのアドオンが足枷になる。標準に手を入れすぎたシステムは、上げようとすると壊れる。上げるための改修費が新規導入並みに膨らむ。結果、塩漬けになる。アドオンのお化けを抱えたまま、古いバージョンで動かし続ける。日本中のERPが陥ってきた道だ。
SAPはこの反省から「Clean Core（クリーンコア）」を掲げるようになった。Clean Coreとは、アップグレードできる状態を維持するための設計思想だ。コアには手を入れるな。標準はバニラのまま保て。拡張は外側（BTPなどの拡張基盤）に出せ。そうすればコアはいつでも安全にアップグレードできる。考え方としては、私たちが昔から言い続けてきたことでもある。パッケージはバニラで使う。カスタマイズは外出しする。中身をいじるな、と。
今回のWordPressで起きたことは、これの小さな相似形だ。カスタムテーマという「アドオン」がコアに絡みつき、アップグレードを止めた。ERPほど規模は大きくないから、誰も深刻に受け止めなかっただけだ。
そして、ここが怖いところなのだが——ERPは業務システムだから、塩漬けの代償はまず「不便」や「非効率」として社内に現れる。ところがフロントのWebは、インターネットに直接晒されている。同じ「アドオンで塩漬け」という病を抱えていても、その代償がセキュリティ侵害という形で、外から、公然と暴かれる。
ERPで長年くすぶってきた構造的問題が、フロントエンドでは、より直接的に、より逃げ場のない形で露呈する。Webは規模が小さいから軽く見られる。だが小さいからこそ、コアとの結合を安易に考え、放置され、そして真っ先に狙われる。
もうひとつ触れておきたい。同社は4月17日にISMS（ISO/IEC 27001）認証取得を公表している。侵害確認の11日前だ。
ただ、「ISMSを取ったのに、なぜ会社サイトが8年も古いままなのか」と単純に笑うのは、正確ではない。認証の適用範囲は会社全体ではなく、テクノロジーソリューション事業本部だ。認証範囲の文言も「顧客要求事項に基づくソフトウェアの設計・開発」などで、対象は顧客に納める業務そのものである。
むしろ、ここに今回の本質がある。認証された範囲と、実際にインターネットに晒されている資産のあいだに、運用上の隙間が生まれうる、ということだ。守られていたのは顧客向けの業務であり、凍結していた自社コーポレートサイトは、おそらく最初からスコープの外にいた。
認証は枠組みであって、枠の外まで自動的に守ってくれるわけではない。そして攻撃者から見れば、認証の外側に取り残された資産こそ、一番柔らかい入口になる。
もう一段掘ると、コスト構造に行き着く。
売上を生むもの——客に納めるサービス——には金をかける。動画配信基盤はモダンに保たれ、CDNで守られている。一方、直接売上を生まない自社サイトの保守は、コストとして真っ先に削られる。利益率を追えば、自然とそうなる。
問題は、その「コスト」の中にセキュリティリスクが計上されていないことだ。保守を止めれば、短期的には支出が減る。だがそこには「侵害される確率 × 侵害されたときの損害」という見えないコストが、静かに積み上がっていく。今回の66日間の対応、外部専門機関の費用、公表による信用の毀損——これらは、保守を削って浮かせた金額を、おそらく大きく上回る。
リスクを利益率の計算に入れていない。これは一社の問題ではなく、多くの組織に共通する盲点だと思う。目に見える支出は削れる。だが目に見えないリスクは削れない。ただ後ろに溜まっていくだけだ。
公告は「当社が持つ個人情報を含む情報の一部」としか書いていない。コーポレートサイト自体は会員機能もECもない、問い合わせ・採用・資料請求が中心のB2Bサイトだ。大量の個人情報が集まる構造ではない。
運用受託先（動画配信サービス等）は別ドメイン・別インフラで、コーポレートサイトの侵害から物理的に離れている。そちらへの波及を示す発表も、現時点でない。
素直に見れば、抜けたのは自社サイトのデータベースにあった問い合わせ・応募・登録情報だろう。件数は多くなくても、個人情報保護法上は報告対象になる。派手な事件ではない。だが「見えているサイトには大した情報がないのに漏れた」という違和感こそ、入口の性質を物語っている。
Contact Form 7 の 5.0.3 は、2026年時点から見れば、既知の脆弱性を抱えた古い系統に属する。断定はできないが、「フォーム周辺を起点にファイルを置かれ、そこから内部へ」という筋書きは、観測された構成と矛盾しない。
発見から漏えい範囲の特定まで52日。ここも見逃せない。
2018年の構成には、いまの環境が持つ監査ログや検知の仕組みが乏しい。「侵入されたのは分かるが、何が持ち出されたかを追いきれない」状態になりやすい。だから外部専門機関に頼り、それでも結論は「漏えいの恐れ」に留まった。
古さが侵入を許し、古さが調査も遅らせた。二重の代償だ。新しい構成なら、数日で範囲を切れたかもしれない。
今回を自分ごとに引き寄せると、防御の初手はどれも「ひと手間」で済むものばかりだ。実際、この記事を書きながら私も自分のサイトを見直した。
オリジンをCDNの裏に隠す。サイトのIPが直接見えていると、WAFを迂回してサーバを直接叩かれる。どのクラウドにも一手間で入れられる仕組みがある。
| クラウド | CDN | 追加の防御 |
|---|---|---|
| AWS | CloudFront | AWS WAF |
| Azure | Front Door | 統合WAF |
| GCP | Cloud CDN | Cloud Armor |
apexドメイン（www なしのドメイン）をCDNに向けるにはDNS側の対応が要るが、そこも含めて半日あれば終わる。
メールのなりすまし対策。DMARC を p=none（検知のみ）から p=reject（拒否）へ。SPF を ~all から -all へ。これは数分だ。放置すると、自社ドメインを騙るフィッシングメールが素通りしてしまう。
そして、依存関係を「見る」こと。ここが本題だ。
今回いちばん効くのは、たぶんこれだ。
凝ったカスタムテーマは、WordPress.org の自動更新から外れる。プラグインも「動いているから」と放置されやすい。こうして依存関係は少しずつ見えなくなっていく。8年という時間は、そうやって過ぎる。Clean Coreを守れなかったERPが、自分が何を抱え込んでいるのか分からなくなっていくのと、同じことだ。
SCA（Software Composition Analysis／ソフトウェア構成分析）は、この「見えなくなった依存」を機械的に洗い出す仕組みだ。CVEが公表された瞬間に、「あなたの環境のこの部品には、この脆弱性がある」と教えてくれる。言い換えれば、見えなくなっていたリスクを、もう一度コストの計算に載せられるようにする道具だ。
世界は動いている。脆弱性は毎日公表され、公表から数時間で攻撃コードが出回り、自動スキャナが世界中のサイトを舐めていく。可視化すれば、自分のサイトが今どう狙われうるのかが、手に取るように分かる。逆に言えば、可視化していなければ、8年間まったく気づかないまま、ということが現実に起きる。
完璧な運用は難しい。人手も時間も足りない。それでも、CVEを持ち、追いかける姿勢は持てる。依存を可視化し、警告が来たら動く。それだけで「気づかないまま8年」は避けられる。
凝ったものを作れる力と、それを守り続ける力は別物だ。むしろ凝るほどコードは増え、コアに絡みつき、標準の更新から外れ、「作った人にしか触れない」ブラックボックスになっていく。ERPで何十年も繰り返してきた失敗を、私たちはフロントエンドでも、もっと小さく、もっと無防備な形で繰り返している。
コアはバニラに保つ。拡張は外に出す。そして自分が何に依存しているのかを、常に「見える」状態にしておく。認証という枠組みに実を伴わせるのは、結局そうした地道な運用だ。
凝ることと、守ること。同じ熱量で。今回の件を、そう受け止めたい。
Aikido Community Japan
公開日: 2026/7/4
最終更新: 2026/7/3
セキュリティの最新情報をお届けします。