AIバグハンターの報告殺到で広がるAppleとGoogleのセキュリティ格差
AIバグハンターがAppleの脆弱性受け付けプロセスの弱点を浮き彫りにしたことで、AppleとGoogleのセキュリティ戦略は新たな局面に入った。機械生成された報告がレビュー能力を圧迫したため、Appleは有効な報告件数を制限したと報じられている。
当面の問題は、単なる誤報ではなかった。イタリアのセキュリティ企業Bynarioの研究者は、自動化ワークフローによって大量の報告の中から実在するmacOSの認可上の欠陥を特定したと述べている。同社は最終的に、root権限でファイルを作成できる攻撃経路を検証した。
Appleは2026年7月にこの脆弱性へパッチを適用した。しかし、この事例は、欠陥を見つけることと信頼できる人間の担当者に評価してもらうことの間に、より広い運用上の隔たりがあることを示した。Googleは、Project ZeroとAIシステムBig Sleepを中心に、その検証層を長年かけて構築してきた。
ここに重要な逆転がある。AIはベンダーによるコード検査の規模を拡大すると期待されていたが、外部研究者がベンダーの処理能力を上回る速度で報告を生成することも可能にした。ボトルネックは発見から、検証、優先順位付け、パッチ提供へと移っている。
Appleにとって、この変化は単一のmacOS欠陥を超える圧力を生む。正当な報告を妨げずに、価値あるAI支援研究と、もっともらしいが誤った提出を見分けなければならない。Googleのアプローチは一つのモデルを示すが、依然として専門家によるレビューに大きく依存している。
パッチ適用済みのMacの欠陥が、より大きな受け付け問題を露呈
重要な変化は、自動化された発見が、人間による報告量を前提に設計された脆弱性プロセスと衝突したことにある。
Bynarioは、Appleが関連するアップデートを公開した2日後の7月29日に技術的な分析を公開した。研究者らはmacOS Screen Sharingにおける関連する2つの認可問題を特定し、CVE-2026-43760としてまとめた。
この欠陥は、Virtual Network Computing、すなわちVNCで使われるレガシー認証経路に影響した。VNCは、リモートユーザーが別のコンピューターの画面を表示・操作できるようにするプロトコルだ。
悪用には複数の条件が必要だった。Screen SharingまたはRemote Managementが有効であること、レガシーVNCパスワードのオプションも設定されていること、そして攻撃者がそのパスワードを知っていることが求められた。
これらの要件により、この欠陥の対象範囲は、認証不要のゼロクリック攻撃より狭くなる。しかし、その重要性がなくなるわけではない。VNCパスワードは画面操作を認可するものであり、特権的なファイルシステムアクセスを認めるものではないはずだった。
研究者らは、macOSがネイティブのApple認証とレガシーVNC認証を異なる方法で処理していることを突き止めた。ネイティブセッションでは、操作が認識済みのmacOSユーザーに紐付けられる。レガシー経路では同じユーザーIDが提供されなかった。
そのIDが欠けている場合でも、ファイルコピー用ヘルパーはroot権限を保持していた。その結果、リモートビューアは保護されたファイルを要求したり、特権的な場所に攻撃者が制御するファイルを作成したりできた。
macOS exploit analysisで、Bynarioは保護された設定ディレクトリ内にポリシーファイルを配置したと説明している。そのファイルはパスワード不要の管理コマンドを有効にし、リモートでのroot権限によるコマンド実行の実証を支えた。
研究者らは、System Integrity Protectionを有効にした最近のApple siliconシステムでこの挙動をテストした。この欠陥はメモリ破壊エクスプロイトではなく認可エラーであるため、Appleのメモリ保護を突破するものではなかった。
この区別は重要だ。現代的な防御は、バッファオーバーフローや偽造ポインターの悪用を難しくできる。一方で、正当なシステムコンポーネントが誤ったIDの下で認可済みの操作を実行することは防げない。
Appleのアドバイザリーは、機微なユーザーデータにアクセスされる可能性があると、より抑制的な表現を用いた。Bynarioは、この説明では特権的なファイル作成の影響全体を捉えていないと主張した。
公開された説明では深刻度も異なっていた。Appleのアドバイザリーと研究者らの評価では、異なるスコアと前提が用いられた。この不一致は、検証が自動化されたラベルを受け入れるだけでは不十分である理由を改めて示している。
Appleは7月27日、macOS Tahoe 26.6とSonoma 14.8.8でこの問題を修正した。同社のsecurity updateは、このリリースで対処した複数の脆弱性について外部研究者に謝辞を示している。
ユーザーにとって、実践的な対応は明確だ。最新のmacOSアップデートをインストールすること。更新できない組織は、不要な場合にはレガシーVNCパスワードのオプションを無効化するか、Screen Sharingをオフにすべきだ。
より大きな物語は、パッチ適用前から始まっている。報道によれば、Bynarioの研究者らは数週間にわたり、すでに数十件の発見を提出していた。その後、有効な報告件数の上限により、別の潜在的に深刻な問題を直ちに提出できなくなった。
Appleは後に研究者らへ連絡し、この欠陥を調査した。この対応はパッチの提供に寄与したが、通常の受け付け経路に対する例外に依存していた。拡張可能なセキュリティプログラムは、待ち行列が研究者の作業を受け付けなくなった後に個別対応を受けられることへ依存できない。
AIバグハンターが人間のレビューを圧倒する理由
AIバグハンターは、検証の経済性を改善するよりも速く、発見の経済性を変えている。
従来の脆弱性研究は、人間の時間という点で高コストだ。研究者はコードベースを調べ、仮説を立て、テストし、誤った手掛かりを排除し、再現可能な報告を書き上げる。
AIは、このプロセスの一部を圧縮できる。モデルは疑わしいパターンを検索し、類似するコードパスを比較し、テストケースを生成し、認可に関する前提が破綻しそうな箇所を示唆できる。
この規模は、システムが証拠を生み出す場合には有用だ。しかし、エージェントが不確かなパターンをすべて自信に満ちた報告へ変換すると、コストが増大する。
セキュリティチームは依然として、挙動を再現し、影響を受けるバージョンを特定し、悪用条件を評価し、担当を割り当て、修正を調整しなければならない。モデルが生成した洗練された説明は、これらの義務を減らすものではない。
Apple自身のreporting guidelinesは、この緊張関係を反映している。長文のAI生成説明を控えるよう促し、適切な検証を欠く理論上のAI発見を対象外としている。
これらのルールは妥当だ。ベンダーに必要なのは再現可能な証拠であり、推測に満ちた何ページもの論証ではない。それでも、一人の研究者が弱い手掛かりと重大な発見の両方を提出する場合、報告件数の制限は粗い統制手段となる。
Bynarioの事例は、AI生成の量とAI支援によるセキュリティ研究の違いを示している。同社によれば、システムが認証情報の不一致を見つけ出したが、人間が結果を最初から最後まで検証した。
その検証にはネガティブコントロールも含まれた。ネイティブ認証の下では、保護された操作は通常のユーザー権限で失敗した。レガシー経路では、類似の操作がroot権限で成功した。
この差分テストは、モデルの信頼度スコアよりはるかに価値が高い。認証経路の一つが変わるとセキュリティ上の結果も変化することを確立するからだ。
この発見は、悪用テストにも耐えた。研究者らは異例の権限差から、特権的なファイル作成、さらにコマンド実行へと進んだ。各段階が次の段階の具体的な証拠となった。
低品質な報告には、こうした連鎖が欠けていることが多い。到達可能性を示さずに疑わしいコードを特定するだけかもしれない。セキュリティへの影響を証明せずにクラッシュを説明したり、内部に留まるデータを攻撃者が制御できると仮定したりする場合もある。
生成モデルは、このような報告を完成されたものに見せる。根本的な主張が証明される前に、脆弱性の分類、攻撃シナリオ、修正に関する文言を提供できる。
それにより、非対称な作業負荷が生じる。もっともらしい報告を10件生成する時間は、1件を慎重に反証する時間より短い場合がある。報告者が発見を検証しないとき、受け手側がコストの大半を負担する。
したがって、AppleのAIセキュリティ運用は二つの関連する課題に直面する。同社にはより優れた受け付け統制が必要だが、繰り返し信頼できる仕事を示す研究者のための経路も必要である。
評判システムは役立つ可能性がある。検証済みの報告履歴、完全な概念実証、決定論的な再現手順、明確な影響対象バージョンのデータは、報告の優先度を高めるべきだ。
機械支援のトリアージでは、提出内容の比較、重複の特定、基本的な主張のテストも可能になる。ただし、別のモデルを使って裏付けのないモデル出力を判断すると、共通する誤りを増幅する恐れがある。
最も強力なアプローチは、自動フィルタリングと反証を組み合わせるものだ。報告が信頼できそうかを問うのではなく、トリアージシステムはその報告が誤りとなる条件を積極的にテストすべきである。
そのためには、ビルド、ログ、設定状態、制御されたテスト環境へのアクセスが必要になる。また、報告が越えたと主張する境界を理解する人間のレビュアーも必要だ。
発見を生成するコストは下がり続けているため、受け付けの課題はさらに大きくなる。すべての提出を同じように扱うベンダーはノイズに埋もれる。自動化を無差別に遮断するベンダーは、本物の欠陥を見逃す。
AppleとGoogleのアプローチは検証層で分岐する
AppleとGoogleの違いは、AIモデルへのアクセスよりも、各社が専門家による検証をどのように組織化しているかにある。
Googleは2014年、重大な脆弱性に焦点を当てる専門研究グループとしてProject Zeroを立ち上げた。この組織的な経験により、Googleは対象の選定、発見の再現、欠陥の開示に関する既存のプロセスを得た。
Big Sleepは、そのセキュリティ経験とGoogle DeepMindのモデル研究を組み合わせている。このシステムは、ソフトウェアを調査し、仮説をテストし、専門家レビューを通過する報告を作成するよう設計されている。
2025年8月、GoogleはBig Sleepがオープンソースプロジェクトで20件の脆弱性を発見し、再現したと発表した。影響を受けたソフトウェアには、広く使われているメディアおよび画像処理コンポーネントが含まれると報じられた。
修正がまだ保留中だったため、Googleは技術的な詳細を直ちには開示しなかった。広報担当者は、システムが脆弱性を自律的に発見・再現した一方で、報告前にはすべての問題を人間の専門家がレビューしたとも述べた。
この人間によるチェックポイントこそ、Big Sleep resultsの重要な部分だ。このプロセスを完全に自律的なものにはしないが、保守担当者が未加工のモデル出力を受け取ることを防ぐ。
Google Big Sleepは、開示期限と下流の依存関係を理解するチーム内でも運用されている。その発見は、文脈なしに無関係なベンダーの待ち行列へ投げ込まれるだけではない。
Project Zeroの開示システムは、もう一つの利点を生む。Googleは、問題が報告された時点、期限が切れる時点、影響を受けるユーザーが実際にパッチを受け取る時点を追跡する。
同社のdisclosure policyは、アップストリームの修正からエンドユーザー端末へのインストールまでに生じるパッチギャップを認識しつつ、標準的な期限を用いている。Big Sleepも同じ枠組みに参加している。
Appleも独自に重要なセキュリティエンジニアリングのリソースを有している。プラットフォーム強化機能、セキュリティ研究用デバイスプログラム、公開された報奨金プロセスを維持している。
Appleのbounty programも、研究者に技術的な説明と概念実証を求めている。新しいターゲットフラグは、特定のエクスプロイト条件に到達したことを示す客観的な方法を提供している。
これらの投資は、Appleが脆弱性研究を軽視しているわけではないことを意味する。ここで明らかになった隔たりは、組織外から自動化された報告が届く際の処理能力と信頼性に関するものだ。
GoogleはAIシステムと、その出力を精査する専門家チームの両方を管理している。一方Appleは、異なるモデル、プロンプト、ツール、検証基準を用いる多数の独立研究者から報告を受け取る。
これは、より難しい受け付けの問題だ。Appleは、外部のモデルエージェントがProject Zeroの手法に従っている、あるいは報告者が提出前に主張を検証した、と仮定することはできない。
それでも、報告チャネルの設計責任はAppleにある。検証済みの研究者が、先行する報告が未処理のままであるために重大な問題を提出できないなら、そのシステムはセキュリティへの影響ではなく、キューの規模を最適化していることになる。
成熟したプログラムには複数のレーンが必要だ。最小限の文書化しかない自動化リードは低優先度キューに入れられ、一方で再現可能な証拠を伴う実証済みのエクスプロイトには、直ちに人間が対応すべきだ。
Appleには、大量投稿を助長せずに、信頼できる報告者の処理枠を増やす手段も必要だ。より高い上限は、単なる追加枠の要請ではなく、検証済みの品質に基づいて付与されるべきである。
Googleのアプローチも誤りと無縁ではない。同社のシステムには高コストな専門家の監督が必要であり、最初に公表された成果だけでは、Big Sleepがプロプライエタリなプラットフォーム全体でどの程度機能するかは示されなかった。
また、報告された発見に至る前に、システムがどれだけの候補を棄却したのかも依然として不明だ。その分母がなければ、外部の人間は偽陽性率やレビューコストを算出できない。
得られる教訓は、より限定的なものだ。AIによる発見は、モデルが説明責任を負う専門家を備えた証拠パイプラインの中で機能する場合に最も有効となる。Appleの課題は、この基準をオープンな外部報告プログラム全体で再現することにある。
セキュリティにおけるトレードオフは速度とシグナルの対立だ
発見件数がセキュリティ向上につながるのは、攻撃者が同じツールを使う前に、ベンダーがそれらを検証済みの修正へと変換できる場合に限られる。
AI支援による脆弱性発見は、開示プロセスの双方に圧力をかける。研究者はより多くのコードを調査できる一方、悪意ある主体も同じソフトウェアから悪用可能な欠陥を探せるようになる。
Googleは2026年5月、AI支援によるゼロデイ発見を伴う犯罪的な試みを阻止したと述べた。同社は影響を受けた製品と、攻撃者が使用したとされるモデルを明らかにしていない。
AI攻撃に関する報道によると、この脆弱性はシステム管理製品の二要素認証を回避できる可能性があった。Googleは被害が発生する前に、ベンダーと法執行機関へ通知したとしている。
詳細は依然として限られており、この事例からモデルがどこまで作業を完了したかは判断できない。ただし、報告処理の遅延が現在はより大きなリスクを伴う理由は示している。
キューで待機している欠陥は静的なものではない。別の研究チーム、犯罪集団、あるいは国家支援を受けた工作員が、独自にそれを発見する可能性がある。探索が高速化すれば、その衝突が起きる可能性も高まる。
Appleは、すべての自動化された報告を受け入れることでこの問題を解決できない。それではレビュー担当者の時間を消費し、最も重大な報告への対応が遅れる。
また、機械支援による研究を抑圧することでも解決できない。Bynarioの欠陥は、有効な認可上の不備が自動化ワークフローから生まれ、厳格な人間によるテストを通過し得ることを示している。
正しいトレードオフは選別された速度だ。強い証拠を伴う報告は迅速にエスカレーションされる必要がある一方、不完全な主張は上級エンジニアに届く前に、低コストな自動検証を受けるべきである。
報告では、影響を受けるビルド、必要な構成、攻撃者の前提条件、観測結果、期待結果、再現可能なテストを明示すべきだ。セキュリティへの影響は、モデル生成の推測ではなく証拠から導かれる必要がある。
権限に関する問題なら、制御下の操作中にプロセスIDを記録することが考えられる。メモリ欠陥なら、サニタイザのトレースと最小限の再現コードを含めることができる。
ベンダーは、こうした要件に沿った構造化された提出テンプレートを公開できる。機械可読な証拠があれば、流麗な文章を証明として扱わずに、自動トリアージが報告をテストする助けになる。
研究者側にも責任がある。不確実な発見を何十件も送ることは、検証コストをベンダーへ転嫁し、その後のすべての提出に対する信頼を弱める。
AIセキュリティツールは、報告を生成する前に反証の段階を組み込むべきだ。エージェントは見落としたアクセス制御を探し、修正済みと未修正のビルドをテストし、主張する攻撃者が必要なすべての入力を制御できることを確認すべきである。
高い影響を主張する内容については、人間によるレビューを必須としなければならない。そのレビュー担当者は問題を独立して再現し、テスト環境が人為的な条件を導入していないかを検証すべきだ。
この要件はAIの価値を下げるものではない。規模が役立つ反復的な調査作業へモデルを向ける一方で、責任を名前の明らかな研究者に残すものだ。
また一般の人々は、脆弱性件数をランキングのように扱うことを避けるべきである。受理された20件の欠陥が、検証済みの1つの攻撃チェーンより自動的に重要になるわけではない。
件数は浅いスキャンや重複報告を助長しかねない。より良い指標には、検証までの時間、確認済みの深刻度、パッチ提供、偽陽性の負担、修正のユーザー導入率が含まれる。
Appleの報告上限は、こうした指標のうち1つにしか対応していない。未処理の提出件数を減らすことはできるが、最も危険な報告が迅速に適切なエンジニアへ届くことを証明するものではない。
報奨金の増額より、優れたトリアージが重要になる
AIセキュリティにおける次の競争優位は、機械による発見から人間が検証した修正までを結ぶ、信頼できるパイプラインになる。
Appleはすでに高度な研究に対する報奨を提供しているが、資金だけでは混雑した受け付けプロセスを修復できない。研究者には、十分な裏付けを持つ発見が読まれ、再現され、適切に振り分けられるという確信が必要だ。
最初の改善は、証拠に基づく優先順位付けであるべきだ。動作する概念実証、明確な前提条件、検証済みの影響は、提出順序より重視されるべきである。
第2に、段階的なアクセスが必要だ。これまでの研究で確認済みの修正につながった研究者には、より大きな同時報告枠と直接の技術的エスカレーションを提供できる。
第3に、透明なステータスが必要だ。有意義なフィードバックがない期間が長引くと、重複メッセージ、早すぎる開示、報告が正しいチームに届いているかどうかの不確実性を招く。
Appleのターゲットフラグという概念は、この方向を示している。客観的なシグナルは悪用可能性を巡る争いを減らし、有意な制御を実証する研究者に報いることができる。
ただし、フラグが対象とするのは定義済みの行動クラスに限られる。新しいロジック欠陥は、特に脆弱性が複数の信頼されたコンポーネントをまたぐ場合、あらかじめ選定されたターゲットに当てはまらない可能性がある。
CVE-2026-43760は、その難しさを示している。各ファイルコピー操作は、単独では正常に動作していた。問題は、認証ID、ヘルパーの権限、ファイルシステムへのアクセスが相互に作用する仕組みから生じた。
この種のバグには意味論的な推論が必要だ。意味論的分析では、単にコードがクラッシュするかではなく、システムの振る舞いがセキュリティ上の意図に合致しているかを検証する。
AIモデルは、関数やコンポーネントをまたぐ関係を追跡できるため支援できる。しかし、存在しない関係を作り出すこともあるため、実行可能な検証が不可欠となる。
強力なトリアージプラットフォームなら、モデルの推論を保存しつつ、それを証拠から切り離せる。レビュー担当者は、どの主張が観測済みで、どれが推論で、どれが未検証なのかを確認できる。
チームは同じ原則を社内のエンジニアリング記録にも適用できる。検索可能な技術ナレッジベースは、生成された要約を権威あるものとして扱わずに、過去の欠陥、設計上の前提、テスト結果、担当範囲を結び付ける助けになる。
新しい報告が以前の問題に似ている場合、この文脈は重要になる。システムは関連するコンポーネントと修正を特定しつつ、元の成果物へのアクセスを維持すべきだ。
Appleは脆弱性を公開せずに、集計された処理データを公表することもできる。有用な指標には、検証時間の中央値、重複率、追加情報の要求数、根拠不十分としてクローズされた報告の割合が含まれる。
こうした報告により、AIによる提出が主にノイズなのか、それとも単に処理能力が有効な研究の増加に追いついていないのかが明らかになる。
Googleにも同じ透明性の基準が求められる。レビューコストを公表せずに成功した発見だけを公開しても、自動化されたセキュリティ研究の全体像としては不完全だ。
この比較を、GoogleがAIセキュリティを解決したという主張にしてはならない。Big Sleepの人間によるレビューは強みである一方、自律的な脆弱性研究には依然として専門家の統制が必要であることの証拠でもある。
AppleはGoogleの組織構造をコピーせずとも追いつける。想定される発見が豊富になっても、実証された証拠を希少で価値あるものとして扱う報告システムが必要だ。
Appleが追いついているかを示す3つのシグナル
今後数カ月で、Appleがこの出来事を一時的なキューの問題として扱うのか、それともセキュリティ研究における恒久的な変化として捉えるのかが明らかになる。
第1のシグナルは、Appleの提出管理に対する変更だ。有意義な更新であれば、検証済みの研究者や再現可能なエクスプロイトを、未検証の自動化された発見と区別することになる。
単純な上限引き上げだけでは不十分だ。報告が注目を受ける順序を改善せずに、件数だけを増やすことになる。
証拠に基づくエスカレーションは、Appleが適応しているという見方を強める。個別の働きかけへの依存が続くなら、プロセスが依然として脆弱であることを示唆する。
第2のシグナルは、今後のセキュリティアドバイザリにおけるAI支援の発見の扱いだ。明確なクレジット、正確な影響説明、一貫した修正詳細は、自動化によって報告の位置付けが下がらないことを示す。
CVE-2026-43760を巡るもののような意見の相違に注目すべきだ。深刻度の判断が異なることは普通だが、アドバイザリと実証済みエクスプロイトの間に説明のない隔たりがあると、防御側にとって優先順位付けが難しくなる。
より充実した説明は、武器化可能な詳細の公開を必要としない。ベンダーは、攻撃者に役立つ手順を伏せながら、前提条件と影響を説明できる。
第3のシグナルは、Google Big Sleepや同様のシステムが最初の公開バッチ以外でどのように機能するかだ。確認済みのロジック欠陥、低い偽陽性率、効率的なパッチ連携は、Googleのモデルを強化する。
弱い報告が大量に出れば、そのモデルは弱まる。また、自律的な発見として提示されながら、文書化されていない水準の人間の労働に依存する結果も、同様に信頼を損なう。
これらのシグナルが企業の購入担当者にとって重要なのは、脆弱性の取り扱いがあらゆるデバイス群に影響するためだ。有効な報告がレビューに届かない、あるいはリリースされた修正が導入されないなら、セキュリティ機能の価値は限られる。
開発者も、変化する証拠の基準を意識すべきだ。AIはコードの検査を支援できるが、メンテナーは報告に時間を費やす前に、再現可能なテストをますます求めるようになる。
セキュリティ研究者も同じ選択に直面している。モデルを使って提出件数を増やすこともできるし、各提出を簡単に退けられない、より強力な実験を構築するために使うこともできる。
したがってAppleとGoogleの競争は、最も多くの脆弱性の主張を生み出す競争ではない。不確実な機械出力を、信頼できる防御行動へと変換する競争である。
この競争はすでに一般的なソフトウェアチームにも及んでいる。脆弱性受け付けのルールを見直し、エスカレーションに必要な証拠を定義し、高い影響を持つ報告が通常のキュー制限を回避できるかをテストしてほしい。もしできないなら、次の有効なAI支援の発見は、コードを明らかにする前にプロセスの問題を露呈させるかもしれない。
