WPユーザーのPHP脆弱性回避術｜AIが暴いた14年越しの欠陥と、サイトを守るために「今やるべきこと」

ログイン不要でサイトが乗っ取られる？
PHP重大脆弱性「php2shell」とWordPress管理者の処方箋

ちょっと一息のつもりが、一息つけない話です

小職も早々当ブログサーバー管理画面からPHPのバージョンを確認したところ7.〇て止まっていました？
管理サーバー側からWEBメールで頻繁にWPとサーバーのバージョンアップ情報（PHP対応更新情報）が来ており、自動（裏側）で更新が行われているものと安心していましたので驚きです。

結論はPHPのバージョンが古すぎて、更新対象にさえ入っていなかった。笑えないはなしです！
早々、PHP8.3以降に緊急に書き換えたところです。
（プラグイン等々によってはPHPの書き換えによってサイトが真っ白になる危険性もありうる）
全くの素人には少々危険性が伴う、冷や汗ものの緊急対応です。バックアップは忘れずに！

前置きが長くなりました、本題です。

いつもはクルマの話ばかり書いている当ブログですが、今回は「ちょっと一息」の枠をお借りして、少し毛色の違う話をいたします。とはいえ、内容は決して軽くありません。むしろ、このブログを読んでくださっている業界の皆さまにこそ、読んでいただきたい話です。

2026年10月21日の夜、世界中のWebサイトを支えるプログラミング言語「PHP」に、極めて深刻な脆弱性が見つかったと公表されました。国内では官公庁、EC、ゲーム会社が相次いでサイトを止めました。私たちの自動車業界でも、メーカー系の認定中古車検索サイト、大手中古車ポータル、ディーラーのホームページ、自動車保有関係手続きのワンストップサービス（OSS）、リース会社や損害保険会社の試乗予約・契約者向けページまで、予防的な停止やメンテナンスが広がりました。

この業界に身を置いて46年になります。キャブレターの調整が整備の腕の見せどころだった時代から、ECU、CAN通信、そしてOTA（無線によるソフトウェア更新）の時代まで見てきました。その経験から申し上げると、今回の件は**クルマで言えば「全メーカー共通部品に、キーがなくてもエンジンを掛けられてしまう欠陥が見つかった」**ような話です。

私自身はプログラマーではありません。ただ、このブログはWordPressで運営しておりますし、HTML、CSS、JavaScript、jQuery、そして最低限のPHPは読めます。読めるからこそ、今回の件の怖さがよく分かります。

この記事では、業界関係者の目線で、WordPressを使っている一般のサイト管理者の方が**最低限「やっておくべきこと」**を、できるだけ具体的にまとめました。後半では、この脆弱性を見つけたのが「AI」だったという点について、実際にAIへ率直な意見を求めた内容も紹介します。今回も少し長くなりますが、是非とも最後までお付き合いください。必見です

2026年10月21日、何が起きたのか
なぜ「ログインしなくても」サイトを書き換えられてしまうのか
今すぐやるべきこと【緊急整備編】
侵入されていないかを点検する【下回り点検編】
平時からやっておくべきこと【定期点検編】
AIは敵か味方か ― 二極性とどう向き合うか
まとめ ― 今日やること、これから続けること

2026年10月21日、何が起きたのか

事実関係の整理

まずは公式発表と主要な報道で確認できる事実を整理します。

項　目	内　容
脆弱性の識別番号	CVE-2026-109618／CVE-2026-109619（攻撃手法の通称「php2shell」）
深刻度	CVSS v4.0で9.2（4段階の最上位「緊急」）
何が起きるか	認証なしで、外部からサーバー上の命令を実行される恐れ（リモートコード実行）
対象	Webリクエストを処理するPHP全般（Apacheのmod_php、PHP-FPM、php-cgi、LiteSpeedなど）
修正版	PHP 8.5.12／8.4.27／8.3.36／8.2.35
サポート終了版	7.4／8.0／8.1には修正部分のソースのみ提供。7.3以前には公式の手当てなし
公開日時	日本時間10月21日21時59分（予告の23時より前倒し）

修正版の公開が予定より早まったのは、本来の公表日より前に情報が外部に漏れたためと報じられています。つまり今回は、パッチが出る前から、攻撃する側が走り出していた可能性があるということです。

国が「大至急」と呼びかけた異例の事態

国内では国家サイバー統括室とIPAが注意喚起を出し、修正プログラムの適用と、適用が難しい場合のサイトの一時停止を推奨しました。首相もSNSで「大至急」と呼びかけています。一つのソフトウェアの不具合について、首相が直接注意を呼びかけるのは極めて異例です。

10月21日の夜までに、国内だけで50を超える組織がサイトの停止や緊急メンテナンスを告知しました。海外でも欧州の政府機関やWikipediaの運営元などが予防的にサービスを止めています。

一方で、震源地の米国では、サイトを止めずに更新で乗り切った企業が大半だったと報じられています。クラウド事業者が顧客に即時更新を呼びかけ、政府とテック企業が密に連携した結果です。この「止めた日本、止めなかった米国」という対比は、後ほど触れる「平時の備え」の話につながります。

自動車業界も決して無関係ではありませんでした

私たちの業界では、次のようなサービスに影響が出ました。

メーカー系の認定中古車検索サイト：
複数メーカーのサイトが緊急メンテナンスに入り、閲覧できない状態に
大手中古車ポータルサイト：
メンテナンス終了予定を何度も延長し、慎重な対応を続けた例も
新車ディーラーのホームページ：
多くのディーラーが共通で利用している販売管理システム（DMS）関連の影響とみられる停止
自動車保有関係手続きのワンストップサービス（OSS）：
一部サービスが停止
リース、輸入車販売、損害保険：
試乗予約や契約者向けページの休止

各社とも、この件による不正アクセスや情報流出は起きていないとしています。止めた判断は、まさに「予防整備」です。

ここで業界の皆さまに気づいていただきたいのは、自社で直接PHPを触っていなくても、委託先・共通システム・ポータルを経由して影響を受けるという点です。クルマで言えば、自社の整備は完璧でも、メーカー共通部品にリコールが出れば、全車に影響が出るのと同じ構図です。

14年間、誰にも気づかれなかった欠陥

今回の欠陥の元になったコードは、セキュリティ企業の分析によれば2012年のPHP 5.4の頃から存在していたとされます。実に14年近く、世界中の技術者の目をすり抜けてきたことになります。

さらに、PHPの開発側は2024年の外部セキュリティ監査をきっかけに、今回の脆弱性の一つにつながる問題の兆候を把握していたものの、修正までは進められていなかったと報じられています。

そして2026年の夏、複数のセキュリティ企業とOpenAIが、AIを使ってこの欠陥にたどり着きました。8月に開発元へ報告され、約2か月の準備期間を経て修正版が公開されています。

人間が14年見逃したものを、AIが見つけた。 この事実の意味については、記事の後半で改めて考えます。

なぜ「ログインしなくても」サイトを書き換えられてしまうのか

クルマに例えると、構造がよく分かります

WordPressサイトの仕組みを、クルマに置き換えてみます。

Webサイト	クルマに例えると
PHP	エンジン
WordPress本体	車体・シャシー
テーマ	内外装
プラグイン	社外パーツ・後付け用品
レンタルサーバー	整備工場兼ガレージ
管理画面のログイン	キー・イモビライザー

普段、私たちが気にしているセキュリティ対策の多くは「キー」の話です。パスワードを強くする、二段階認証を入れる、ログイン画面のURLを変える。どれも大切です。

ところが今回の欠陥はエンジンそのものにありました。しかも、キーを差す前、つまりWordPressが動き出す前の段階で問題が起きます。どれだけ立派なイモビライザーを付けていても、エンジン側に穴があれば意味がありません。

リレーアタックに近い怖さ

業界の方なら、スマートキーの電波を中継して車両を盗む「リレーアタック」をご存じだと思います。オーナーが鍵を持ったまま自宅で寝ている間に、クルマが持ち去られてしまう手口です。

今回の脆弱性も、構造的にはこれに近い怖さがあります。管理者が一度もログインしていなくても、外部から細工した通信を送り込むだけで、サーバーに命令を実行させられる可能性があるのです。

仕組みをごく簡単にご説明します。

PHPは、アクセスが来るたびに「受付→処理→後片付け」を繰り返しています
一つ目の欠陥は、メモリが足りなくなって処理が途中で止まったとき、中途半端な状態のデータを、後片付けの処理が正常なものとして扱ってしまう問題です
二つ目の欠陥は、あるアクセスで使ったメモリを片付けた後も、その場所を指す情報が残り、次のアクセスで再利用されてしまう問題です

整備に例えるなら、前の作業で外した部品が作業台に残ったまま、次のクルマの作業に紛れ込むような状態です。攻撃者はこの状態を意図的に作り出し、本来実行できないはずの命令を通そうとします。

「うちはアップロード機能がないから大丈夫」は誤解です

今回の欠陥は、ファイルを送信する仕組み（multipart/form-data）の解析処理や、アップロードの進捗を記録する機能に関わっています。そのため「問い合わせフォームも画像投稿もないから関係ない」と考えた方もいらっしゃると思います。

しかし、これは誤解です。

攻撃者は画面上のフォームを使いません。通信を直接組み立てて送り込みます
PHPは、WordPressなどのアプリが動き出す前に、届いた通信の中身を自動的に解析します
したがって、サイトにアップロード画面があるかどうかは関係ありません

WordPressは、トップページもログイン画面も、すべてPHPで動いています。PHPのファイルに通信が届く時点で、対象になりうると考えてください。

危険度の差は「PHPの動かし方」で決まります

すべてのサーバーが同じだけ危険というわけではありません。分かれ目は、PHPがどういう方式で動いているかです。

Apacheのmod_php（危険度：最も高い）

PHPの公式発表で、最もリスクが高いと名指しされている方式です。認証なしの通信で、アプリが動く前に攻撃が成立することが実証されています。

PHP-FPM（危険度：高いが、条件付き）

nginxなどと組み合わせて使われる方式です。処理の開始で異常が起きると、その処理を担当するプロセスごと捨てる作りのため、mod_phpと同じ攻撃がそのまま通るわけではありません。ただし二つ目の欠陥については、条件がそろえばFPMでも攻撃が通る経路が確認されています。

「FPMだから安全」ではありません。 危険度の順番が違うだけで、更新が必要なことに変わりはありません。

ご自身のサイトの方式は、WordPressの管理画面「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の欄で確認できます。「PHP SAPI」の項目が「apache2handler」ならmod_php、「fpm-fcgi」ならPHP-FPMです。

WordPressを最新にしても、今回の穴はふさがりません

ここは特に強調しておきたい点です。

今回の欠陥は、WordPress本体やプラグインではなく、その下で動いているPHP本体にあります。管理画面で「お使いのWordPressは最新バージョンです」と表示されていても、今回の件とは関係ありません。

クルマで言えば、ボディをいくら磨いても、エンジンのリコール改修を受けていなければ意味がない、ということです。直すべきはPHPのほうです。

今すぐやるべきこと【緊急整備編】

ここからが本題です。エンジニアではない一般のWordPress管理者の方が、今日やるべきことを順番に整理しました。

ステップ1：自分のサイトのPHPバージョンを確認する

先ほどの「サイトヘルス」の画面で、PHPのバージョンを確認します。

8.5.12以上、8.4.27以上、8.3.36以上、8.2.35以上のいずれかであれば、今回の修正は適用済みです
それより低い数字であれば、更新が必要です
8.1以前、または7系であれば、PHPの開発元からは正式な修正版が出ていません。後述の「古いPHPをお使いの方へ」をお読みください

ステップ2：レンタルサーバー会社の告知を確認する

多くの個人ブログや中小企業のサイトは、レンタルサーバーで動いています。この場合、PHP本体の入れ替えは基本的にサーバー会社が行います。

契約しているサーバー会社の「障害・メンテナンス情報」や「お知らせ」のページを確認してください
「対応済み」と告知されていても、念のためステップ1の方法でバージョンを自分の目で確かめてください
サーバーの管理パネルでPHPのバージョンを選べる場合は、修正版を含むバージョンを選択します

整備で言えば、工場任せにせず、作業完了後に自分でも確認するということです。

ステップ3：VPSや自社サーバーの場合は、自分で更新する

VPSやクラウドで自分でサーバーを管理している方は、OSのパッケージ管理を通じてPHPを更新し、PHP-FPMやApacheを再起動してください。更新しただけでは、動いているプロセスは古いままです。

Dockerで動かしている場合の注意

公式イメージを元に自前のイメージを作っている場合は、**作り直し（再ビルド）**が必要です
動いているコンテナは、新しいイメージで作り直してください。再起動だけでは古いままです
バージョン番号を細かく固定している場合は、その番号を上げてください

ステップ4：更新がすぐにできない場合の暫定策

制作会社と連絡が取れない、独自の改修が多くて検証が必要など、すぐに更新できない事情もあると思います。その場合に限り、次の暫定策があります。

公式の緩和策を設定する

PHPの公式から、アップロード進捗機能の無効化（session.upload_progress.enabled=0）などの暫定策が案内されています。ただし、公式自身が「特定の攻撃経路を減らすだけで、安全にはならない」と明言しています。あくまで応急処置です。

サイトを一時停止するなら「止め方」が重要です

会員情報や決済を扱っているサイトで、更新の見通しが立たない場合は、一時停止も合理的な判断です。ただし、止め方を誤ると、セキュリティは守れても、その後の検索流入を大きく損ないます。

正しい止め方：
HTTPステータス「503」（一時的に利用不可）を返す。Googleに「一時停止中」と正しく伝わります
避けるべき止め方：
通常の「200」でメンテナンス画面を表示する、または全ページを「404」にする

そして、ここが多くの解説記事が触れていない重要な点です。

WordPressのメンテナンスモード用プラグインでは、今回の対策になりません。 プラグインもPHPで動いているからです。今回の欠陥は、WordPressやプラグインが動き出す前に起きるため、プラグインで「メンテナンス中」と表示しても、PHPには通信が届いてしまいます。

止めるなら、PHPが動く手前、つまりWebサーバーの段階で止める必要があります。Apache系のレンタルサーバーであれば、.htaccessで次のような設定が一般的です。

ErrorDocument 503 /maintenance.html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]
</IfModule>
<IfModule mod_headers.c>
Header always set Retry-After "3600"
</IfModule>

maintenance.htmlは、PHPを含まない普通のHTMLファイルとして用意します。なお、サーバーによって書式や使える機能が異なりますので、必ずサーバー会社の手順を優先し、作業前に元の.htaccessを保存しておいてください。サーバー管理パネルにサイト停止の機能があれば、そちらを使うのが確実です。

ステップ5：古いPHP（8.1以前・7系）をお使いの方へ

正直に申し上げます。この機会にPHPを8.3以上へ上げることを強くお勧めします。

8.1以前は、PHPの開発元からの正式な更新がすでに終了しています
8.2も2026年12月31日でセキュリティ修正が終わります。今8.2に上げても、2か月後に同じことを繰り返すことになります
7系から8系への移行では、古い書き方がエラーになり、古いプラグインやテーマが動かなくなることがよくあります

移行の手順は、クルマのエンジン載せ替えと同じで、いきなり本番車両でやらないことが鉄則です。

現在のサイトを丸ごとバックアップする
WordPress本体、テーマ、プラグインをすべて最新にする（PHPより先に）
サーバー会社の「ステージング環境」機能などで、本番のコピーを作る
コピー側でPHPを上げ、表示崩れやエラーがないか確認する
問題がなければ本番に反映する

7系や8.1以前でしか動かない古いプラグインに依存している場合は、そのプラグインそのものが今後の弱点になります。代わりのプラグインを探す良い機会と捉えてください。

ステップ6：更新後に、必ず「外から」確認する

更新や停止の作業が終わったら、必ずご自身のサイトを、普段使いのブラウザのシークレットモードで開いてください。

証明書エラー（「この接続ではプライバシーが保護されません」）が出ていないか
表示崩れや真っ白な画面になっていないか
問い合わせフォームが正常に動くか

緊急対応の副作用で、SSL証明書の設定が外れたり、表示が崩れたりする例は珍しくありません。整備後の試運転を省略しないことです。

PHP7系からバージョンアップを行うとページの表示速度が驚くほど快適になります。googleの評価も上がりますので一石二鳥です

侵入されていないかを点検する【下回り点検編】

更新が済んだからといって、すでに侵入されていた場合は意味がありません。修正版の公開前から攻撃の試みが観測されていたという報告もあります。次の項目を点検してください。

技術者でなくても確認できるサイン

Google Search Consoleの「セキュリティと手動による対策」に通知が出ていないか
Googleで「site:自分のドメイン」と検索し、見覚えのないページ（外国語のページ、通販ページなど）が出てこないか
ブラウザでアクセスしたときに、警告画面が出ないか
WordPressの「ユーザー」一覧に、見覚えのない管理者アカウントが増えていないか
「プラグイン」一覧に、入れた覚えのないプラグインがないか
固定ページや投稿に、見覚えのないリンクや広告が紛れ込んでいないか

もう一歩踏み込んだ確認（FTPやファイルマネージャーが使える方）

wp-content/uploadsフォルダの中に、.phpファイルが置かれていないか（本来、画像などしか置かれない場所です）
サーバーのルートやwp-includesに、最近の日付で更新された見覚えのないファイルがないか
.htaccessに、見覚えのない転送設定が書き込まれていないか
サーバーのエラーログに、メモリ不足のエラーやPHPの異常終了が頻発していないか

異常が見つかったら

慌ててファイルを削除する前に、まずサーバー会社と制作会社に連絡してください。削除してしまうと、侵入経路の調査ができなくなります。事故車の現場保存と同じ考え方です。

あわせて、WordPressの管理者パスワード、データベースのパスワード、FTPのパスワードをすべて変更し、wp-config.phpの認証用キーも作り直します。改ざんを除去した後は、Search Consoleから再審査を依頼します。

平時からやっておくべきこと【定期点検編】

今回の件は、「たまたま運が悪かった事故」ではありません。後ほど詳しく触れますが、AIの登場によって、こうした重大な欠陥の発見は今後確実に増えていきます。一度きりの緊急対応で終わらせず、定期点検の仕組みを作っておくことが大切です。

バックアップは「取ってある」ではなく「戻せる」状態に

サイトのファイルとデータベースの両方を、定期的に自動でバックアップする
バックアップは、同じサーバーの中だけでなく、別の場所（クラウドストレージなど）にも保存する
年に一度は、実際にバックアップから復元できるか試してみる

スペアタイヤを積んでいても、空気が抜けていたら役に立ちません。

プラグインの棚卸しをする

プラグインは便利ですが、一つ増えるごとに「穴」の可能性も一つ増えます。

使っていないプラグインは、「停止」ではなく削除する（停止中でもファイルはサーバーに残ります）
2年以上更新されていないプラグインは、代わりを探す
配布元が不明なプラグインやテーマ、いわゆる「無料配布の有料版」は絶対に入れない

社外パーツを付けるほど、車検で引っかかるリスクが増えるのと同じです。

自動更新を味方につける

WordPress本体のマイナーアップデート（セキュリティ修正）は自動更新を有効にしておく
サーバー会社が提供する「PHPの自動更新」や「推奨バージョンへの自動追従」の設定があれば確認する
信頼できる主要プラグインは、自動更新を有効にすることも検討する

WAF（Webアプリケーションファイアウォール）を有効にする

多くのレンタルサーバーには、不正な通信を手前で遮断する「WAF」機能が用意されています。初期状態で無効になっていることもありますので、管理パネルで確認してください。

また、CloudflareなどのCDN（配信ネットワーク）を前段に置くと、今回のような攻撃の試みを、自分のサーバーに届く前に遮断できることがあります。今回の件でも、こうした事業者がいち早く防御ルールを配信していました。

ログイン周りの基本も、あらためて

今回の欠陥はログインと無関係でしたが、日常的な攻撃の大半は依然としてログイン画面への総当たりです。

管理者パスワードは長く、使い回さない
二段階認証を導入する
管理者ユーザー名を「admin」にしない
使っていなければ、XML-RPC機能を無効にする

「休眠サイト」を放置しない

業界の皆さまに特にお伝えしたいのがここです。

過去のキャンペーン用に作ったまま放置しているサイト
前任者が立ち上げて、今は誰も管理していないブログ
閉店・統合した拠点の、残ったままのホームページ

こうしたサイトこそ、最も狙われやすい場所です。報道でも、休眠サイトのリスクが指摘されています。使っていないサイトは、きちんと閉じる。これも立派なセキュリティ対策です。

緊急時の連絡先リストを作っておく

今回、日本で多くのサイトが「止める」判断を取った背景には、すぐに更新できる体制がなかったという事情もあります。いざというときに慌てないよう、次の連絡先を一枚の紙にまとめておいてください。

サーバー会社のサポート窓口と契約番号
制作会社・保守会社の担当者と緊急連絡先
ドメイン管理会社
サイトの管理者アカウントを持っている社内の人

事故対応のマニュアルが整っている工場ほど、トラブル時の対応が早いのと同じことです。

AIは敵か味方か ― 二極性とどう向き合うか

発見する側のAI

今回の欠陥は、複数のセキュリティ企業とOpenAIが、それぞれAIを使ってたどり着いたものです。あるセキュリティ企業は、8月にAIで最初の欠陥を見つけ、すぐに開発元へ報告したと公表しています。OpenAIは「同様の発見は今後数か月で急増する」と予測しています。

これは、良い知らせでもあります。14年間誰にも見つからなかった欠陥が、悪用される前に、正規の手順で開発元へ報告され、修正されたのですから。

攻撃する側のAI

一方で、攻撃する側もAIを使います。修正プログラムは、裏を返せば「ここに穴がありました」という地図です。その差分をAIで素早く解析すれば、攻撃の準備にかかる時間は大幅に縮まります。

実際、公表後には大手のネットワーク事業者が、攻撃の試みが数千件から数百万件へと桁違いに跳ね上がったと報告しています。公表の数日前から試みを観測していたという報告もあります。

つまり、AIの時代には**「脆弱性が公表されてから、攻撃が始まるまでの時間」が限りなくゼロに近づいていく**ということです。

実際にAIに率直な意見を聞いてみました

ここで、せっかくですので、対話型AIに「AIが脆弱性を見つける時代に、一般のサイト管理者はどう向き合えばよいか。率直な意見を聞かせてほしい」と尋ねてみました。以下は、その回答の要旨です。

率直に申し上げると、AIが脆弱性を見つけること自体は、守る側にとって有利な変化です。今回も、欠陥は悪用される前に見つかり、報告され、修正されました。問題は「見つかる速度」が上がったのに、「直す速度」が人間の側で追いついていないことです。

今回の件で、技術的に最も弱かったのはPHPのコードではなく、更新が遅れたまま放置されているサイトの「長い尾」です。何年も前に作られ、誰も管理していないサイトが世界中に無数にあります。AIによる攻撃は、そうした場所を数分で見つけ出します。

ですから、一般の管理者の方にお伝えしたいのは、「AIに勝とうとしなくてよい」ということです。必要なのは高度な知識ではなく、更新が自動で、あるいは速やかに当たる仕組みと、使わないものを持たない習慣です。地味ですが、それが最も効果があります。

もう一つ。AIは点検の相棒としては優秀です。エラーメッセージの意味を尋ねたり、設定ファイルの確認を手伝わせたりするのは有効です。ただし、パスワードやwp-config.phpの中身など、秘密の情報をそのままAIに貼り付けることは避けてください。そして、AIが書いたコードやプラグインを、中身を理解しないまま本番サイトに入れることも勧めません。AIは間違えることがありますし、私も例外ではありません。

最後に、今回は「23時15分から一斉に乗っ取りが始まる」といった根拠のない情報も大量に出回りました。AIで作られた煽り記事も少なくなかったはずです。危機のときほど、PHPの公式発表、国の注意喚起、契約しているサーバー会社の告知といった一次情報に当たる習慣が、身を守ります。

AIの回答を読んで、私はなるほどと思いました。特に「AIに勝とうとしなくてよい」という部分は、私たちの業界にも通じる話です。

業界関係者として思うこと

クルマの世界も、同じ変化の只中にあります。

かつてクルマの不具合は、壊れてから直すものでした。それが定期点検で予防するものになり、今ではOTAで、オーナーが寝ている間にソフトウェアが更新される時代です。同時に、クルマがネットにつながったことで、サイバー攻撃の対象にもなりました。国連の基準でサイバーセキュリティ対策とソフトウェア更新の管理が義務化されたのも、その流れです。

Webサイトも同じです。作って終わり、公開して終わりの時代は、とうに過ぎています。 「点検」と「更新」を前提に運用するもの、という認識に切り替える必要があります。

AIとの付き合い方も、クルマの運転支援システムに似ていると感じます。自動ブレーキは事故を大きく減らしましたが、それでも運転の責任はドライバーにあります。AIが脆弱性を見つけ、AIが更新を手伝ってくれる時代になっても、サイトを守る最終的な責任は、管理者である私たち自身にある。そこは変わりません。

AIを過度に恐れる必要はありません。かといって、AIに丸投げしてよいわけでもありません。道具として正しく使い、地味な基本を続ける。46年この業界にいて、結局それが一番強いと実感しています。