← ブログに戻る
Ai読了目安 12 分

OpenAIはPHPの脆弱性を見つけた。だが本当に重要なのはその後の2か月だ

公開日 2026年10月23日
OpenAIはPHPの脆弱性を見つけた。だが本当に重要なのはその後の2か月だ

Webのおよそ7割はPHPで動いている。今月、OpenAIはGPT-5.6 Solを含む自社モデルが、PHPの重大なセキュリティ欠陥の発見に貢献したと発表した。ここまでがヘッドラインで、次の一文からが本題だ。同社はその後2か月をかけて、メンテナーとセキュリティ企業による連合の中で修正を作り、検証し、それが終わるまで一切公表しなかった。

2か月の沈黙は広報のサイクルではない。脆弱性対応のうち、誰もスクリーンショットを撮らない部分がそこにある。

協調的開示こそが成果物だ

モデルでバグを見つけること自体は、もう安い。シェルとソース一式と数時間を与えられたまともなエージェントは、同じコードを人が読むより速く候補のクラッシュを出す。そのほとんどはゴミで、ゴミと本物のメモリ安全性の問題をより分けるところにコストが移った。

OpenAIがここでやったこと、少なくとも同社がそう言っていることは、地味な中間工程だ。連合を作り、候補を1件ずつ検証し、パッチを書き、エコシステム全体に対してテストし、開示日を合意し、それからようやく公開する。この順番があったからこそ、PHPの欠陥はWordPressサイトを狙う週末の祭りにならずに済んだ。

つまり本当の論点は「モデルが見つけられたか」ではない。「この段取りを繰り返せるか」だ。連合が機能するのは、資源のある一者が招集するからで、PHPと同じ依存グラフにぶら下がりながら、誰も何も招集できない何千ものOSSプロジェクトに、そのまま当てはまる話ではない。

{{INLINE1}}

このチェッカーは、できないことを正直に言う

開示とあわせて、OpenAIはPHPのバージョンチェッカーを公開した。Codexのスキルと、Node製のCLIツールだ。サイトを指定するとHTTPヘッダーを読み、OK、VULNERABLE、UNKNOWNのいずれかを返す。

この方式はちゃんと読む価値がある。ヘッダーのバージョン文字列を、既知のパッチ境界と比べているだけだ。単独で何かを検証しているわけではない。これは意図的な設計判断で、その代わりに「正直な3つの出力」を持つツールになり、「不正直な2つの出力」にはなっていない。

ヘッダー依存の検出には有名な失敗パターンがある。本番のPHP配備の多くはバージョンについて嘘をつく。リバースプロキシがヘッダーを書き換えているか、ヘッダーが落とされているか、何年も前に誰かがexpose_phpを切って、もう誰も覚えていないかだ。UNKNOWNはそのためにある。「判別できない」と言うツールは、「問題ありません」と言うツールより役に立つ。

配布経路も見逃せない。WebアプリでもGitHub Actionでもなく、Codexのスキルとして出てきた。これは、セキュリティの一次対応が次にどこで起きるとOpenAIが考えているかの表明だ。すでにあなたのリポジトリを読んでいる、あのエージェントの中で。

モデルはどうやってメモリバグを見つけるのか

「AIが脆弱性を見つけた」という言葉は3つの別のことを指して使われるので、仕組みは正確に押さえておきたい。

1つ目は、より賢いスケジューラを載せたファジングだ。カバレッジ誘導型のファザーは10年前からPHPのバグを見つけてきた。モデルが足すのはパッチを読み、隣接するどのコードパスが新たに到達可能になったかを推測し、そこまで走るハーネスを書く能力だ。実用的ではあるが、魔法ではない。

2つ目はソース上の推論だ。長さプレフィックスを解析してから確保する関数を与えれば、強いモデルは整数オーバーフローを指摘し、候補入力を提案する。何も実行せずに。誤検知の多くはここから出る。3つ隣のファイルに、すでに値を制限している呼び出し元が見えていないからだ。

3つ目はトリアージだ。数百件の候補を「たぶん本物」「たぶんノイズ」「人間が必要」に振り分ける作業は、最も語られず、おそらく最も価値が高い。セキュリティチームに何かを見る時間が残るかどうかを決めるのが、まさにこの工程だからだ。

連合なしでスケールするのは3つ目だけだ。ここがこの発表全体の静かな問題である。モデル側の作業はAPIキーさえあれば誰でも再現できるが、調整側の作業はそうはいかない。

10億ドル分のアクセス

OpenAIは最前線の防御者向けに、Daybreakへの10億ドル相当のアクセスも約束した。これは慈善ではなくインフラとして読むべきだ。検出ツールは、攻撃が来るのと同じ頻度で回せる人にしか役に立たない。無料枠は病院のITチームに1回チェックさせる。10億ドル分の計算資源は、それを継続させる。

その下には戦略的な理屈がある。名前をつけておく価値がある。モデル提供者がセキュリティツールの上流になれば、どの脆弱性が先に見つかり、誰に先に伝えられるかを決める側にもなる。商業ラボに集中する判断はかなりの量で、上の開示プロセスは、その体制が信頼されるかどうかをまさに左右する。

採用の理屈でもある。セキュリティ研究者は足りていない。Webで最も普及している言語を2か月かけて協調修正したと示せるラボは、ベンチマークを公開するラボより語れる話が多い。

サイトを運営している人にとっての意味

今週中にPHPのバージョンを確認してほしい。しかも自分のネットワークの外から。攻撃者に見えているのはそれだからだ。ヘッダーが何も教えてくれないなら、どのスキャナにも代われない作業が残っている。信頼できる答えは、マシン上のパッケージマネージャにしかない。

そして、出来事ではなくパターンのほうを考えてほしい。モデルはセキュリティチームを置き換えたのではない。比率を変えたのだ。候補は増え、トリアージは増え、判断できる人の数は同じ。これらのツールを入れる組織は、どこかでトリアージ能力を作る必要があり、作らない組織には未読の検出結果が溜まる。それはスキャンを一度も回していない状態と見分けがつかない。

忘れられる部分

もうひとつ気づいておきたい。今回出たのはバージョンチェッカーであって、パッチャーではない。ワンクリック修正は誰にも渡されていない。Webの7割に一斉に配るワンクリック修正は、それ自体が大規模障害になるからだ。ここで保守側に倒したのは正しい。そして同時に、未修正のインストールが長く尾を引くことを保証してもいる。次の事故はそこから来る。

半年後、この件のまとめは「AIがPHPのバグを見つけた」になるだろう。手に入る真実の中で、いちばん退屈な一文だ。持ち帰れる教訓はもっと地味で、価値は2か月の協調作業にあり、モデルの貢献はその工程の最初の1週間を速くしただけだということ。

それでも大きな出来事だ。ただ、発表文が売っている出来事とは違う。セキュリティの仕事は昔からほとんどが調整で、最も役に立つツールは調整を安くするものであって、発見を大声にするものではない。

関連記事