AIが脆弱性を見つけるほど修繕が詰まる——PHP危機とOpenSSHから作る「防御変更枠」

AIがソフトウェアの脆弱性を見つける速度は、開発者が一件ずつ手作業で調べていた時代の前提を変え始めました。2026年10月に公開されたPHPの重大な脆弱性では、OpenAIのモデルやGoogle傘下WizのAIが発見と影響確認に使われました。PHP Foundationは修正版を公開し、国内では多数のWebサービスが緊急メンテナンスへ入りました。

同じ週、AnthropicはClaudeで25件、計500万行超のオープンソースを分析し、攻撃対象領域に関わる493件の問題を見つけたと報告しました。OpenSSHでは、初期設定で認証前の利用者が到達できた実験的コードを減らす修正にもつながっています。

発見能力が上がること自体は、防御側にとって朗報です。しかし、報告が一日で百件届いても、再現、優先順位付け、修正、影響試験、本番配備、利用者案内を担う人と時間が増えなければ、未処理の脆弱性が積み上がります。AIが発見側と攻撃側の両方を速めるなら、企業が先に設計すべきなのは「何件見つけるか」ではなく「安全に何件直し、必要なら止められるか」です。

本記事では、PHPの緊急対応、OpenSSHの攻撃対象領域縮小、日本のサービス停止をつなぎ、AI時代の保守を「防御変更枠」として整理します。

防御変更を支えるサーバーラックとネットワーク基盤

結論——発見速度ではなく、検証から復旧までの容量を決めます

脆弱性管理では、深刻度の高い順に直すだけでは足りません。同じ重大度でも、インターネットから認証なしで到達できるサーバーと、隔離された検証環境では、今夜必要な行動が異なります。また、修正版があっても、古い拡張機能や業務アプリが新しい実行環境で動かなければ、更新作業は単純なボタン操作ではありません。

防御変更枠では、次の五つを別々に数えます。

枠	数える対象	上限に達したときの動作
検証枠	報告の再現、影響範囲、偽陽性の確認	新規スキャンを絞り、重要資産を優先します
露出削減枠	停止、遮断、認証追加、機能無効化	復旧条件を付け、期限のない仮対策を残しません
修正枠	パッチ、設定変更、依存更新、コード修正	同時変更を増やさず、差分の所有者を決めます
配備枠	検証、本番反映、利用者案内、監視	確認待ちを超えたら次の配備を始めません
復旧枠	巻き戻し、データ照合、再開、事後確認	戻せない変更は承認前に止めます

この五枠を分ける理由は、AIが見つけた時点では利用者の危険が減っていないからです。報告が正しいと確かめ、攻撃者が届く道を狭め、修正版を試し、本番へ反映し、問題時に戻れる状態まで閉じて初めて、防御が一件進みます。

以前の記事では、生成物が人の確認能力を超えて積み上がる状態を「検証待ち在庫」として整理しました。脆弱性発見でも同じです。ただし、セキュリティの在庫には、公開後に攻撃へ転用される時間制約があります。そのため、入口のスキャン件数だけでなく、一件を閉じるまでの滞留時間を管理します。

PHPの二件は、AI発見と人間の保守組織を同時に映しました

PHP Foundationは10月21日、PHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、二つの重大な遠隔コード実行の脆弱性を修正しました。Foundationの説明では、一つはメモリー上限へ達する特定の時点で不完全な内部データが残る問題、もう一つは致命的エラー後の古い状態が次の要求へ残る問題です。どちらもメモリー管理やエラー処理という、多くの要求が通る中心部分に関係します。

重要なのは、AIが突然ゼロから全てを解決したわけではないことです。PHP側は2024年の外部監査をきっかけに、一つ目の問題の兆候を把握していました。しかし、互換性の破壊、別のサービス拒否リスク、第三者拡張への変更要求という交換条件があり、修正方針の合意が進みにくかったと説明しています。深い知識を持つコア開発者が少なく、作業が止まり、再開を繰り返したことも「構造的な失敗」と明記しました。

その後、PHP Foundationは2026年5月にEcosystem Security Teamを設け、報告の仕分け、調整、堅牢化を担う体制を増やしました。外部監査、AIスキャン、再現環境、複数の研究組織がつながり、Calif、OpenAI、Wizから届いた報告によって遠隔コード実行までの具体的な影響が明らかになりました。修正を進められた背景には、モデル性能だけでなく、資金、担当者、合意方法、再現環境、公開前の調整があります。

ITmedia NEWSが紹介したOpenAIの説明では、上流での検証と修正、影響組織へ準備時間を与えること、重要システムを守る政府連携、製品全体の更新準備、公開後の配備支援という五段階が示されました。発見したモデル名より、この順番の方が企業の実務には重要です。公開だけを早めると、防御側の準備時間も攻撃側の手掛かりも同時に増えるからです。

「緊急」でも、危険を一つの数字へ潰さないことが必要です

TechCrunchはPHPが広く使われ、古い版も多く残ることを踏まえ、更新できないサイトは一時的に公開を止めるべきだという強い勧告を伝えました。国内でも政府が迅速な適用準備と、状況によるサイト停止の有効性を呼び掛けました。多数のサービスが緊急メンテナンスへ入ったことは、停止が障害ではなく防御変更になり得る例です。

一方、公開直後に出回った実証コードの全てが、一般的なPHP環境へそのまま通用したわけではありません。独立した技術者による分析では、既存のローカルファイル読み込み問題など、別の弱点を前提にした「実証」が多数含まれたと指摘されています。公式の修正勧告を軽視してよいという意味ではありません。深刻度、理論上の影響、特定構成での再現、一般環境での容易な悪用、実際の攻撃観測を分けて扱うという意味です。

企業の緊急票には、少なくとも次の状態を分けて記録します。

自社に対象バージョンまたは対象構成が存在します
外部から到達できる入口があります
公式情報で影響と修正版が示されています
自社構成で再現または防御条件を確認しました
攻撃の痕跡をログ、ファイル、認証履歴で調べました
暫定遮断または停止を実施しました
修正後の機能、性能、データ整合性を確認しました
再開後の監視と利用者案内を完了しました

「CVSSが高いから全て止める」と「悪用例が少ないから何もしない」の間には、多くの実務があります。公式の修正版は速やかに適用しつつ、どの入口が外部へ開き、停止時に誰が困り、再開時に何を照合するかを同じ記録へ置きます。

古いサービスでは、更新できないこと自体が重大な保守情報です

国内の旅行ゲーム「ワールドクエスト」は、PHPの脆弱性公表後、古い仕組みのため十分な対策を取れないとして即日終了しました。同作は2011年に公開され、いったん終了した後、2020年に復活して運営が続いていました。終了は利用者にとって損失ですが、「動いているから維持できる」という判断を続けず、情報保護を優先した点は重要です。

古いシステムには、修正版を入れられない理由が複数あります。言語の版を上げるとアプリが動かない、使っている拡張が保守されていない、試験環境がない、構築手順が残っていない、担当者がいない、データ移行の方法が分からない、といった理由です。これらは緊急時に初めて探す情報ではありません。

前回扱ったAIによるCOBOL移行の「移行完了票」では、変換率ではなく、計算、記録、連携、例外、復旧を同じ仕事として受け入れる必要性を整理しました。Webサービスの保守も同様です。最新版へ上げられるかだけでなく、停止、縮退、データ返却、代替窓口、終了告知までを保守の出口へ含めます。

更新不能なサービスを無期限に公開し続けることは、無料の選択ではありません。利用者データ、運営者の信用、緊急対応者の深夜作業を将来へ先送りしています。四半期ごとに「現在の版」「サポート終了日」「更新に必要な試験」「停止できる時間」「終了時のデータ処理」を確かめれば、緊急日に初めて廃止を決める状況を減らせます。

サーバーと通信経路を世界規模で確認する運用画面

OpenSSHの事例は、未知の穴を探す前に入口を狭める方法を示します

PHPの事例が「見つかった重大な穴をどう直すか」だとすれば、Anthropicの研究は「まだ見つかっていない穴へ、どう届きにくくするか」を扱います。Claudeは25件、計500万行超のオープンソースから1万7000超の設定項目を整理し、そのうち3842項目をセキュリティ関連として分析しました。報告された問題は493件です。

分析は、初期設定で不要なコードへ届かないか、二つの設定を組み合わせると防御が外れないか、認証などの確認より前に複雑な処理が動かないか、という三方向です。認証を前提とする11プロジェクト全てで、意図せず到達できるコードが見つかりました。また、警告なく受け入れられる162件の設定組み合わせのうち、94件はセキュリティ制御を意図せず無効化したと報告されています。

OpenSSH 10.4では、耐量子署名方式ML-DSA-44の実験的なコード約4500行に、認証前の利用者が到達できました。この方式を管理者が有効にしていなくても、受信した鍵を解析してから許可方式かを確認する順番だったためです。約4500行は、初期設定のOpenSSHで認証前に動く独自コードの約16％に相当します。

開発者は10.5で確認順を変えましたが、Claudeはその修正にも二つの抜け道を見つけました。追加修正を経た10.6では、認証前に到達できたコードの約5分の1を減らしたとAnthropicは説明しています。これは個別の脆弱性を一件直したというより、攻撃者が触れられる複雑さそのものを減らした事例です。

ただし、到達できるコードを減らせば必ず安全になると単純化はできません。機能を認証後へ移すと互換性が変わり、初期設定を無効にすると利用者の接続が止まる場合があります。Anthropicの手法でも、既定動作に関わる修正ではプロジェクトの試験を実行し、既定外の動作へ影響する変更は人間の判断に残す設計です。AIは変更候補と経路を広く探せますが、使われている構成と許容できる停止を決めるのは運営者です。

日本企業は資産台帳を「動いている一覧」から「変えられる一覧」へ直します

多くの資産台帳には、サーバー名、OS、IPアドレス、担当部署が並びます。しかし、緊急時に必要なのは、そのシステムを今夜変えられるかという情報です。次の十欄を一件のサービスへ持たせます。

欄	記録する内容
利用者と完了条件	誰のどの用事を終えるサービスか
公開入口	ドメイン、API、管理画面、認証前の処理
実行基盤	言語、版、Webサーバー、拡張、コンテナ
依存関係	CMS、ライブラリ、外部認証、決済、メール
変更所有者	判断者、実装者、確認者、連絡先
修正可能時間	通常、夜間、休日に何件変えられるか
試験資産	正常、例外、性能、データ整合性、戻し方
暫定防御	停止、遮断、認証追加、機能無効化の手順
復旧条件	巻き戻し、再開、ログ確認、利用者案内
保守出口	更新不能時の移行、データ返却、終了条件

この表は、脆弱性の名前が出てから作るものではありません。毎月一件ずつ停止と復旧を試し、担当者がいなくても別の人が実行できるか確かめます。使っていない入口や管理機能は閉じ、外部公開が不要な処理は認証やネットワーク境界の内側へ移します。

AIスキャナーへ資産を渡す際も、発見件数を成功指標にしません。確認済みの真の問題、既に閉じた入口、修正を本番へ届けた時間、変更で起きた障害、再発防止へつながった設定を測ります。似た報告を束ね、一つの共通原因として直せた件数も重要です。

30日で「防御変更枠」を試します

最初の一週間は、外部公開するサービスを十件だけ選びます。言語と版、認証前の入口、管理画面、依存関係、担当者、停止可能時間を記録します。既存の診断結果を集め、未確認、確認済み、修正中、配備済み、保留へ分けます。

第二週は、一件の緊急変更を想定します。修正版を検証環境へ入れ、基本機能だけでなく、ログイン、決済、通知、定期処理、バックアップ、復旧を試します。同時に、修正できない場合の遮断、読み取り専用化、サイト停止、代替窓口を実行します。停止画面が表示されても、問い合わせ先や再開見込みが空欄なら合格にしません。

第三週は、攻撃対象領域を減らします。利用していないAPI、古い管理画面、不要なプラグイン、公開不要な診断機能を棚卸しします。コードを消せなくても、認証後へ移す、ネットワークで制限する、初期設定を無効にすることで到達経路を狭められます。変更前後で必要な利用者まで遮断していないかも確かめます。

第四週は、担当交代と復旧を試します。主担当者がいない前提で、別担当者が台帳から対象を特定し、停止、修正、試験、再開まで進めます。失敗したら元の版へ戻し、変更中に受けた取引や入力が欠落、重複していないか照合します。

月末には、次の指標を並べます。

新規報告数と、再現・影響確認を終えた数
外部公開資産のうち版と所有者が分かる割合
報告から暫定遮断まで、修正版配備までの時間
認証前に到達できる不要な機能とコード経路の減少
確認待ち、修正待ち、配備待ちの最大件数と滞留日数
変更で発生した障害、巻き戻し、データ不整合の件数
担当交代後も停止と復旧を完了できた割合
更新不能と判定し、移行または終了計画を持つサービス数

AIで新規報告が増えたのに、配備済みの件数が変わらないなら、検証か修正か本番変更が詰まっています。AIエージェントの「同時稼働予算」と同じく、確認待ちが上限へ達したら新しい探索を絞り、重要資産の修繕へ人と計算資源を戻します。

防御変更の順番と担当を確認するチーム

調達では「見つけるAI」だけでなく、直す出口を買います

脆弱性診断製品やAIコード分析を選ぶとき、検出件数、対応言語、ベンチマークだけを比較すると、報告書だけが増える場合があります。調達条件には、根拠のコード経路、再現手順、影響する構成、偽陽性を却下する方法、修正候補、変更試験、既存の課題管理への連携を含めます。

提供者が自動修正を掲げる場合は、どこまでを無人で変えるかを確認します。読み取り専用の分析、修正案の作成、検証環境への反映、本番配備、公開停止は同じ権限ではありません。外部へ影響する段階ほど、対象、差分、試験結果、巻き戻しを人へ戻します。

さらに、AIが生成した実証コードも成果物として検査します。脆弱な設定を後から加えて成功したように見せていないか、対象外の別の弱点を前提にしていないか、一般的な構成と研究用環境を混同していないかを確認します。もっともらしい端末出力や成功メッセージではなく、修正前後の同じ環境、パケット、クラッシュ、ログ、コード経路で判断します。

「重大な問題を百件発見」は、入口の数字です。「重要サービス三件で外部到達を閉じ、二件を更新し、一件を安全に終了した」の方が、利用者の危険をどれだけ減らしたかを説明できます。

まとめ——AI時代の防御力は、見つけた穴の数ではなく閉じられる変更です

PHPの二つの重大な問題は、AIが長く残った弱点の影響を具体化し、防御側が攻撃より先に修正を準備できる可能性を示しました。同時にPHP Foundationの説明は、難しい修正には専門家、資金、合意方法、互換性試験、公開調整が必要だと示しています。モデルが報告を速めても、保守組織の容量は自動では増えません。

OpenSSHの事例は、未知の脆弱性を全て発見する前でも、認証前に触れられる複雑なコードを減らせることを示しました。国内のサービス停止は、更新できない仕組みに対して、公開を続けない判断も利用者保護の一部であることを示しています。

次にAI診断の報告が届いたとき、発見件数だけで成功を語らず、その一件が検証、露出削減、修正、配備、復旧のどこにいるかを尋ねてみてはどうでしょうか。夜間に担当者が一人でも、止める手順、直す試験、戻す経路まで読めるなら、AIの速さは警報の洪水ではなく、利用者を守る修繕能力へ変わっていきます。