Appleが脆弱性報告に上限を設けた──AIが生む「量」に、受け手が追いつかなくなっている

AIが仕事を速くする、という話は、たいてい作る側の速度で語られる。受け取る側がどうなるかは、あまり語られない。

Appleがバグ報奨金プログラムに手を入れていたことが明らかになった。同社はFinancial Timesに対し、社内のセキュリティポータル経由の提出について上限と30日のクールオフ期間を導入し、枠を増やすには申請を必要とする形にしたと認めている。実施は6月からだという。狙いは、業界全体で起きている報告の急増への対処だ。脆弱性を見つけ、つなぎ、悪用するところまでこなせるLLMが強力になった結果、審査チームが提出の量に追いつけなくなっている。

質が上がっているのに、詰まる

厄介なのは、これが「AIの出力は使えない」という話ではないことだ。Appleは数週間前、こうしたAIツールへの対応として、セキュリティ更新の前倒しを認めている。当初は26.6で配る予定だった修正を、iOS 26.5.2とその同系列で先に出した。しかもその更新のセキュリティノートでは、OpenAI・Anthropic・Z.aiなどのAIツールを使って複数の脆弱性の発見に貢献した研究者に、謝辞が記されている。本物が混ざっているから、機械的には弾けない。だから一件ずつ人間が見ることになり、そこで詰まる。上限とクールオフは、見つける能力への評価ではなく、見る側の処理能力に合わせた調整である。

生産量と処理量は、別々に増えない

この構図は、セキュリティに限った話ではない。会議の記録でも同じことが起きる。文字起こしと要約が自動になれば、一人が回せる会議の数は増える。だが出てきた議事録を読んで決定事項を確認し、認識のずれを見つける仕事は、人間の側に残ったままだ。生産量だけが先に増えると、確認されない記録が積み上がっていく。

Appleの対処からは、二つのことが読み取れる。ひとつは、量そのものを制限する仕組みの粗さだ。件数の上限とクールオフは「多すぎる」への即効性はあるが、本物の脆弱性を送る側にも同じ待ち時間を課してしまう。件数で絞るより、既知の脆弱性パターンとの一致や再現手順の有無で一次スクリーニングし、優先度の高いものから人間に回す仕組みにするほうが、量を減らさずに詰まりを解消できる。重複排除やスコアリングによるトリアージは脆弱性報奨金業界ではすでに一般的な手法であり、そこまで踏み込まず件数上限という粗い手段を選んだのは、応急処置としての性格が強い。

もうひとつは、メモリスのような記録・要約ツール側に課される、同じ構図の宿題だ。メモリスは録音した音声をAIに渡して議事録を作る道具で、この非対称からは逃れられない。作れる本数が増えることと、読まれる本数が増えることは別の問題であり、対処すべきは生成側ではなく受け取る側の設計だ。だからこそ要約は短く、決定事項とToDoを先頭に固定し、認識のずれのように見落としやすい部分ほど目立つ位置に出すべきで、全文を読まなくても判断できる形になっていなければ、量が増えた分だけ読まれなくなる。

あわせて読みたい：

• 議事録の要点とは？押さえるべきポイントと書き方
• 決定事項とアクションアイテムの違いと書き分け方
• AI議事録を無料で作る方法｜自動作成の手順と精度のコツ
• 構造化された議事録の作り方