サイバーセキュリティ対策は、見つかった弱点を直せば追いつけるのか。
AIがソフトウェアを調べる能力を高めるにつれ、運営者には、修正を続けることと、修正が間に合わない場合に備えることの両方が求められる。
OpenAIのサム・アルトマンCEOは、スタンフォード経営大学院のインタビューで、個別のバグ修正だけに頼る防御の限界を指摘した。
ただし、その見通しを、そのまま「現在の対策がすべて無効になった」という事実として受け取ることはできない。
発言の意味を確かめたうえで、防御側の実例と照らし合わせる必要がある。
企業の担当者やWebサイト運営者が知りたいのは、脅威の大きさだけではない。
何を任せ、何を制限し、どこから手を付けるべきか。
本記事では、2026年10月24日時点で確認した公開資料をもとに、その判断材料を整理する。
インタビューの19分16秒以降で、アルトマン氏は、企業経営者や国家、個人が、迫るサイバーリスクを十分に深刻に捉えていないとの懸念を述べている。
一度、AIが見つけた問題を修正しても、その後にモデルが高度化すれば、発見できる弱点の範囲も変わるという見方だ。
同氏は、通常の攻撃者像から外れる脆弱性や、ハードウェアの層に関わる問題にも言及し、同じ技術を防御にも使う仕組みへの転換を主張した。
タイトルの「バグ修正だけでは守り切れない」は、この発言の要旨を日本語にしたものとなる。
ここで語られているのは、AIの進歩を踏まえた同氏の懸念と提案だ。
ハードウェアへの攻撃が既に一般化したことや、既存の防御が全面的に破られたことを示す調査結果ではない。
また、「バグ」はプログラムの不具合全般を指し、そのすべてが攻撃に使えるわけではない。
安全性に関わる弱点が「脆弱性」であり、さらに、実際の環境で悪用できるかどうかにも条件がある。
記事の読み手も、発見数、悪用可能性、現実の被害を分けて捉えたい。
この区別に立つと、発言から引き出せる運用上の問いは具体的になる。
新しい問題が判明するたび、対象の特定から修正の反映まで、組織はどれだけ速く動けるのか。
対応が遅れた場合、被害をどこまで抑えられるのか、という問いである。
Anthropicは2026年4月7日、Claude Mythos Previewの評価で、実際のソフトウェアにある未知の脆弱性の発見や、悪用可能性の検証を確認したと公表した。
これは開発企業による評価であり、あらゆるシステムへの侵入成功を意味するものではない。
こうした能力が広がれば、運営者が使う製品について、以前は見つからなかった問題が短期間に報告される可能性がある。
ところが、発見の速さだけで防御が完成するわけではない。自社で該当製品を使っているか調べ、影響を見積もり、修正を試し、本番へ反映する工程が残る。
たとえば、決済に関わる機能を止めずに更新するには、動作確認や切り戻しの準備も必要になる。
AIが調査を助けても、更新による不具合と未修正のリスクをどう扱うかという運営上の判断は消えない。
以下は、発言と公開事例を踏まえて整理した運用上の比較である。
「従来型の対策は手作業だけだった」という意味ではなく、既存の自動化を含む体制を、どこまで一連の対応につなげられるかを示している。
対応力を測るなら、「今月何件見つけたか」だけでなく、重大な問題の通知から担当者の確認まで何時間かかったか、修正や代替措置まで何日必要だったかを見るとよい。
発見数の増加が、そのまま安全性の向上になるとは限らないためだ。
Mozillaは4月21日、Claude Mythos Previewの初期評価で見つかった271件の脆弱性について、Firefox 150に修正を含めたと発表した。
これは当時の発見・修正実績であり、現在のFirefoxに同じ問題が残っているという意味ではない。
この事例が示すのは、AIの能力向上が攻撃者だけに利益をもたらすわけではないということだ。
ただし、ブラウザーの開発組織が行った取り組みを、そのまま小規模サイトの成果として見込むこともできない。
対象のコード、技術者の体制、検証に使える環境が異なる。
運営者にとって参考になるのは、AIの出力を受け取る先の仕組みである。
報告が正しいかを確かめ、修正を加え、利用者に配布するまでがつながって初めて、実際の防御になる。
Mozillaが5月7日に公開した技術解説では、モデルの性能だけでなく、出力の誘導や結果の選別など、AIを使う方法の改善が成果につながったと説明されている。
また、過去に加えた設計上の対策が、AIによる一部の侵入経路の探索を阻んだ事例も報告した。
ここから得られる示唆は、AI導入と従来の設計改善を二者択一にしないことだ。
問題を一件ずつ直す一方で、同じ種類の問題が大きな被害につながりにくい構造を作れば、修正が届く前にも防御の層を残せる。
Webサイトで考えるなら、公開画面と管理機能を分け、外部連携に渡す権限を絞るといった設計が、その検討対象になる。
これは特定のサイトで被害を確認した話ではなく、被害範囲を制限するための運用例である。
Anthropicの防御向け施策にも更新がある。
同社は10月6日、Cyber Verification Program（CVP）を拡張し、既存のProject Glasswing参加組織をSpecialized Accessへ移行させると発表した。
能力へのアクセスは、業務範囲や審査条件に応じて分かれる。
したがって、4月の発表だけを読み、「そのモデルを誰でもすぐ使える」「当初の参加組織しか使えない」と決めつけるのは適切ではない。
導入を考える担当者は、利用資格とデータの扱いを、その時点の公式条件で確認する必要がある。
セキュリティ用のAIがログを読むだけなのか、アカウント停止や設定変更まで行えるのかによって、導入時のリスクは変わる。
調査の補助と、本番環境への操作を同じ権限で扱うべきではない。
カナダのサイバーセキュリティ当局などが共同作成したAIエージェントの指針も、必要最小限の権限、継続的な監視、既存のセキュリティ管理への統合を求めている。
防御に使うAI自体も、管理されるITシステムである。
たとえば、不審な通信を見つけたAIに、直ちに全利用者の接続を止める権限を与えると、誤った判断が業務停止へ直結しかねない。
初期導入では通知や調査案の提示を中心にし、実際の結果を見ながら操作範囲を広げる方が、影響を確かめやすい。
見た目がもっともらしい報告でも、本当に問題が起きるかどうかは検証が必要になる。
Mozillaの技術解説も、正しそうに見えて誤っているAIの報告が、保守担当者の負担になることを指摘している。
運用では、指摘の件数と、確認できた問題の件数を分けるとよい。
対応不要な通知が増えれば、担当者が重要な警告を見落とす原因にもなる。
導入評価では、発見数に加え、調査に要した時間や、担当者が確認する情報の分かりやすさも確かめたい。
また、コードやログを外部サービスへ渡す前には、認証情報や個人情報が混ざっていないかを確認する。
AIに見せる情報を増やす判断と、外部へ提供してよい情報の判断は、別に行う必要がある。
AIが参照する外部文書やWebページには、作業を別方向へ誘導する指示が紛れ込むことがある。
いわゆるプロンプトインジェクションだ。指針でも、こうしたAI特有のリスクと、従来からある権限・認証の問題を併せて扱っている。
そのため、製品の説明だけでなく、実際の接続先、実行できる操作、操作記録の残し方まで見る必要がある。
導入先の仕組みが違えば、同じAIでも事故の影響は異なる。
危機を発信する企業が、防御技術の提供者でもある点は、製品評価の際に意識したい。
警告の妥当性と、特定製品を導入した場合の効果は、別々に確かめる必要がある。
この利害関係については、関連記事「サイバー攻撃で、本当は誰が儲かるのか？」で詳しく整理している。
IPAは、中小企業向けに段階的な対策を進めるガイドラインを公開している。
AIの新しいリスクに対応する場合も、まず自社の管理状況を把握するための土台として利用できる。
Webサイトなら、サイト本体に加え、ドメイン、管理用メール、フォーム、会員機能、決済、アクセス解析、外部連携を洗い出す。
そのうえで、各サービスの管理者と、問題が起きたときに止められる人を確認したい。
ホスティング型サービスを使っている場合は、基盤の更新をサービス側が担当していても、自社側にアカウントや連携設定の管理が残ることがある。
契約と管理画面を確かめ、誰が何を直すのかを明確にすると、緊急時の問い合わせ先も定まる。
次の表は、編集部が提案する点検の順序であり、公的機関が全組織に一律の実施順を指定したものではない。
自社の公開範囲や、停止したときの影響に応じて調整する。
更新や認証を強化しても、事故時の連絡先が分からなければ対応は止まる。
反対に、手順書があっても、必要なログが取れていなければ調査は難しい。
表を埋めるだけで終えず、通知を受け取れるか、連携を解除できるか、復旧できるかを実際に試すと、抜けが見つかりやすい。
導入候補を評価するときは、機能の数より、自社の負担をどこで減らせるかを定めたい。
たとえば、警告の整理に時間がかかっているなら要約や分類を試し、コードの調査に詰まっているなら検証環境でレビュー支援を試す。
試用前後で、担当者が確認する件数、誤報の割合、調査時間を比較すれば、継続利用の判断がしやすくなる。
速くなった工程があっても、別の工程へ確認待ちが移っただけなら、体制全体の改善には至っていない。
管理者アカウントの多要素認証、使っていない連携の解除、バックアップからの復元確認も点検に含めたい。
認証情報が漏れたときや、誤った変更を加えたときに備えるためだ。これらはAIの導入有無にかかわらず、運営側で実施状況を確認できる。
本番の設定変更まで任せるのは、結果を説明でき、操作を取り消せ、必要なときに止められることを確かめてからがよい。
予算を追加する場合も、製品の費用だけでなく、検証と運用に必要な人の時間を含めて考えたい。
今回の発言を受けて見直したいのは、自社が修正を適用するまでの速さと、それまでの間に残る防御だ。
「問題が見つかった」という通知を、誰が受け取り、何を止め、どの状態へ戻すのか。その流れを説明できるかどうかが、一つの判断軸になる。
まずは、最も停止の影響が大きいサービスを一つ選び、管理者・連携権限・復旧方法を確認するとよい。
AIの活用も、その過程で明らかになった負担から試せば、必要な機能と与えてよい権限を絞り込める。
.png){kind=logo}
