AI攻撃の脅威は「これから数カ月」で変わる OpenAIらが共同声明:残された時間はわずか?
OpenAIは「今後数カ月でAIを使ったサイバー攻撃がより広範かつ高度になる」とし、企業が「やるべきこと」を示した公開書簡を発表した。同書簡では「従来のセキュリティ対策は不十分になる」という厳しい見方を示している。
MicrosoftやGoogle、Amazon Web Services(AWS)、Anthropic、Cisco、Cloudflare、CrowdStrike、Fortinet、IBM、Palo Alto Networks、Red Hat、Zscaler――。AI、クラウド、セキュリティなどを代表する企業が名を連ねる公開書簡を、OpenAIが2026年8月27日(現地時間)に発表した。書簡には、この他、GitHub、Hugging Face、Okta、Snyk、Tenable、ServiceNow、Shopify、Snowflake、Visa、NTT DATAなど多数の組織が署名している。
今回発表されたのは「サイバー防御に向けた共同行動の呼びかけ」と題した公開書簡だ。OpenAIはAIモデルの能力が高まるにつれ、「従来の防御策では不十分になる」と指摘し、「今後数カ月でAIを利用したサイバー攻撃がより広範かつ高度になる」との見通しを示した。病院や浄水場、インターネットを支えるインフラなど、社会が依存する重要サービスが危険にさらされる可能性にも言及している。
書簡では「AIを使った攻撃に注意しよう」という単なる警告ではなく、企業組織が「やるべきこと」にも踏み込んでいる。
企業が“やらなければならないこと”とは?
OpenAIは公開書簡において、長年放置されたバグや過剰な権限、設定ミス、未修正のソフトウェア、脆弱(ぜいじゃく)な認証、レガシーシステムの技術的負債などの基本的な弱点が、依然としてサイバー攻撃の足掛かりとなっていると指摘する。
企業組織はまずはこれらの穴をふさぎ、その上で、高リスク脆弱性を修正するだけでなく、修正後の検証についても怠らないようにしたい。AI時代の開発では、「修正する速度」だけでなく「修正が本当に効いたかどうかを検証する速度」まで引き上げることが重要になる。また、開発サイクルに関わるセキュリティ水準の引き上げも提言しており、特にAIが生成したコードの安全性についても注意すべきだ。
この他、公開書簡では、最小権限や強固なアクセス制御、多層防御を組み込むことも求めた。パッチを適用することが難しいシステムについては、代替的な防御策を適用し、その効果を検証するよう促している。
こうした対策と並行して、セキュリティ強化にAIを利用することももちろん重要だ。OpenAIは、防御側もAIを活用し、ツールだけでなく、実践的な知識や検証済みの修正策を共有し、組織で得られた成果を他の組織の防御にも生かすよう呼び掛けた。
「こうすべき」だけではない OpenAI自身も対策を強化
こうした提言を掲げる一方、OpenAIもAIエージェントによる「Hugging Face」への侵入事案を受け、具体的な対策を進めている。
2026年7月の事案では、内部のサイバーセキュリティ評価中だったAIモデルが、インターネットから隔離するための制御を回避。OpenAIの研究インフラやHugging Faceのシステムに侵入し、脆弱性の悪用や認証情報の利用などを組み合わせて攻撃を進めた。OpenAIは同年8月26日、この事案の調査結果と今後の対策を公表した。
OpenAIはこの事案を受け、AIモデルのライフサイクル全体でアライメントに関する要件を厳格化するとともに、より分離されたサンドボックスの構築、インターネットアクセスの制限、モデルウェイトへのアクセス制御強化を進めている。さらに、モデルの推論過程を監視するモニタリングにも計算資源を大幅に追加する方針だ。
評価環境についても、インフラ設定を厳格に管理し、脆弱性が修正されるまで研究速度を犠牲にしてでも制御を強化。今後のトレーニングや評価では、より強力な保護策を導入し、モデル開発時の封じ込め、監視、アクセス制御、評価手法を強化するとしている。
つまり、今回の公開書簡は「AIを使って防御を強化しよう」という呼び掛けであると同時に、AIを扱う側自身が、そのAIを制御できなくなるリスクに備える必要があるという問題提起でもある。
AIが脆弱性を見つけ、コードを修正し、さらにシステムを操作するようになれば、従来のセキュリティ対策だけでは追い付かない。
開発者に求められるのは、AIを開発やセキュリティに導入することだけではない。AIが生成したコードを検証し、AIエージェントの権限と行動を追跡し、問題が起きたときに止められる仕組みまで含めて設計することだ。
Microsoft、Google、AWS、Anthropicをはじめとする多数の企業が署名した今回の呼び掛けは、AI時代のサイバー防御が一社だけの問題ではなくなったことを示している。攻撃側のAIがどこまで進化するかを待つのではなく、防御側も今ある脆弱性とAIの管理方法を見直す時間が残されているうちに動くべきだというのが、今回のメッセージだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
「CTFはAIによって終わりました」 現役ハッカーが見た「人間の敗北」
「もうAIに勝てる人間はほとんどいない」。CTFは競技として崩壊し、脆弱性探索は“パチンコ”と化し、CVEの所持は何の実績にもならなくなった。日本有数の実績を持つ現役ハッカーが語る、AIの華々しい性能向上の裏にある負の側面とは。
API設計の常識が変わる? HTTP新メソッド「QUERY」とセキュリティ対策を学ぶ
APIはWebサービスや生成AIアプリケーションを支える重要な基盤だ。「IETF」がHTTP新メソッド「QUERY」を標準化プロセスへ進めるなど、API設計は変化しつつある。一方で、攻撃への備えも欠かせない。API設計とセキュリティを理解するための記事を紹介する。
ゼロトラストの壁は「製品」ではなかった トヨタが4年以上かけて見直したもの
サイバー攻撃への備えを「侵入を防ぐこと」だけで考えていないだろうか。ニチレイの事例が浮き彫りにしたのは、1社のシステム障害が取引先や顧客まで巻き込み、復旧の判断さえIT部門だけでは完結しない現実だ。では、企業は何を基準に「復旧」を考えるべきなのか。
セキュリティ対策は「足す」より「減らす」 開発者と共有したい5つの設計原則
セキュリティ製品やルールを増やすほど、安全になるとは限らない。むしろ現場の負担が増え、基本的な対策まで形骸化することもある。では、何を減らし、何を残すべきなのか。開発者とセキュリティ担当者が共有すべき「5つの設計原則」を軸に、「引き算」のセキュリティを開発現場へ落とし込む方法を考える。