# IBMとProject Glasswingで読むAIサイバー防御 攻撃が速くなる時代に企業は何を変えるべきか
2026年5月19日、IBMはAI時代に向けた企業セキュリティポートフォリオの拡充を発表しました。発表の中心にあるのは、AIを使ってアプリケーション、インフラ、ネットワークのリスクを横断的に把握し、脆弱性の発見から修正までの時間を短縮する取り組みです。同時にIBMは、Anthropicが進める「Project Glasswing」に参加し、広く使われるソフトウェアの脆弱性を見つけ、修正し、協調的に共有する活動を強めると説明しています。
このニュースが重要なのは、単に「IBMが新しいセキュリティ製品を発表した」という話にとどまらないからです。生成AIとエージェント型AIは、開発、運用、調査、攻撃、防御のすべての速度を変えつつあります。攻撃者がAIを使って偵察、脆弱性探索、攻撃コード作成、横展開を高速化するなら、防御側も同じ速度感で、検知、優先順位付け、修正、検証、開示を進める必要があります。
本記事では、IBMの発表とProject Glasswingの一次情報をもとに、AIサイバー防御がなぜ注目されているのか、企業は何を変えるべきなのか、そしてAIに任せてはいけない領域はどこかを整理します。サイバーセキュリティは、金融、医療、公共サービス、教育、雇用、通信など、生活や財産に直結する領域に影響します。本記事は一般的な情報整理であり、個別システムの安全性診断、法的助言、投資判断、インシデント対応手順を代替するものではありません。実際の対策では、社内のセキュリティ責任者、法務、外部専門家、監督官庁、製品ベンダーの公式情報を必ず確認してください。
何が発表されたのか
IBMの発表は、AI時代の企業セキュリティを支える複数の要素をまとめたものです。ポイントは大きく四つあります。
第一に、IBM Concertを軸に、アプリケーション、インフラ、ネットワークのシグナルを統合し、組織が抱える脆弱性や構成リスクを一つの運用ビューで把握しやすくすることです。IBMはこれを、受け身の監視から、調整された知的な対応へ進むための仕組みとして説明しています。
第二に、IBM Concert Secure Coderによって、開発者のIDE内でコードリスクを検出し、事業影響を踏まえて優先順位を付け、修正案を提示する方向です。脆弱性が本番環境に入ってから慌てて直すのではなく、コードが書かれている時点で早めに見つけるという考え方です。
第三に、IBM ConsultingとIBM Autonomous Securityによって、AIで圧縮される攻撃時間に合わせ、企業ごとの脆弱性管理やオープンソース管理を作り直すことです。発表では、マルチエージェント型のサービスが検知、意思決定、対応を機械速度で連携させると説明されています。
第四に、Project Glasswingを通じて、広く使われるソフトウェアの脆弱性を特定し、修正し、協調的に開示し、オープンソースコミュニティへ還元することです。AnthropicのProject Glasswingは、Claude Mythos Previewという限定公開のフロンティアAIモデルを、防御目的で重要ソフトウェアの保護に使う取り組みです。Anthropicは、AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksなどを立ち上げ時のパートナーとして挙げています。IBMの参加は、この流れにエンタープライズセキュリティとハイブリッドクラウドの観点が加わることを意味します。
ここで注意したいのは、AIサイバー防御が「魔法の自動修復」ではないことです。AIはリスクの発見、優先順位付け、修正案作成、ログ分析、影響範囲調査を助けます。しかし、修正を本番環境へ反映する判断、顧客や利用者への説明、法令や契約に基づく開示、事業停止リスクの評価は、人間と組織の責任として残ります。
なぜAIサイバー防御が急に重要になったのか
生成AIが広がる前から、サイバー攻撃は自動化されていました。脆弱性スキャン、フィッシングメール、認証情報の詰め込み、マルウェア配布、ランサムウェアの横展開など、攻撃者はすでに多くの工程でツールを使っています。では、なぜ今あらためてAIサイバー防御が話題になるのでしょうか。
理由は、AIが攻撃の「質」と「速度」の両方を変える可能性があるからです。従来の自動化は、決められたパターンに沿って大量に処理するのが得意でした。一方、現在のフロンティアAIモデルは、コードを読み、仕様を推測し、設定ファイルを比較し、エラーログを解釈し、複数の手順を組み合わせる能力を高めています。これは、防御側にとって便利であると同時に、攻撃側にとっても強力な道具になり得ます。
たとえば、公開されたソフトウェアの更新差分をAIに読ませ、どの変更が脆弱性修正に関係するかを推測する。社内外に漏れた設定情報やエラーメッセージから攻撃経路を組み立てる。フィッシング文面を相手企業の業務用語に合わせる。攻撃コードの試行錯誤を短時間で繰り返す。こうした用途は、完全に新しいものではありませんが、AIによってスケールと速度が変わります。
防御側にも同じ変化が起きています。大量のアラートから本当に重要なものを選ぶ。古いライブラリの依存関係を調べる。ソースコードと実行環境の差分を見る。修正案を作る。テストを追加する。影響範囲を説明する。これらは人間だけで行うと時間がかかりますが、AIを適切に使えば、初動の遅れを減らせます。
IBMの発表が示しているのは、セキュリティ運用の中心が「アラートを見る」から「リスクをつなげて、早く直す」へ移っていることです。AI時代には、検知だけでは不十分です。見つけたリスクを、どの事業に影響するのか、どの資産に紐づくのか、どの順番で直すのか、誰が承認するのか、修正後にどう検証するのかまでつなげる必要があります。
Project Glasswingとは何か
Project Glasswingは、Anthropicが2026年4月に発表した、重要ソフトウェアをAI時代に守るための取り組みです。Anthropicは、Claude Mythos Previewを「コーディングとエージェント型タスクにおいて高い能力を持つフロンティアモデル」と説明し、一般公開ではなく、限定された防御目的の研究プレビューとして提供しています。
Project Glasswingの考え方は明快です。強力なAIモデルが脆弱性を見つけられるなら、その能力が攻撃者に広く渡る前に、防御側が重要インフラやオープンソースソフトウェアの弱点を見つけ、修正し、知見を共有する必要があるというものです。Anthropicは、Project Glasswingの参加者に対してモデル利用枠を提供し、さらにオープンソースセキュリティ組織への支援も掲げています。
この取り組みは、AI安全性の観点でも興味深い事例です。一般的なAI製品発表では、モデルの性能を示し、広いユーザーに使ってもらい、エコシステムを広げることが重視されます。一方、Project Glasswingでは、能力の高さがそのまま悪用リスクにつながるため、アクセスを制限し、防御目的に絞り、パートナーと協調する形が採られています。
もちろん、限定公開であればすべて安全というわけではありません。誰がアクセスできるのか、どのログが残るのか、モデルの出力をどう検証するのか、見つかった脆弱性を誰にいつ伝えるのか、修正までの間に情報が漏れないか、といった論点は残ります。強力なAIを防御に使うほど、運用ルールと監査が重要になります。
IBMの参加は、Project Glasswingのような取り組みが、研究や大手テック企業だけの話ではなく、企業向けセキュリティ運用にも接続し始めたことを示しています。銀行、通信、医療、製造、公共、物流などの組織は、多数の商用製品、クラウド、オンプレミス、オープンソース、古いシステムを組み合わせて動いています。AIで脆弱性を見つけても、実際に修正するには、業務影響、保守契約、テスト、停止時間、規制対応が絡みます。ここを現実の運用に落とし込めるかが、AIサイバー防御の成否を左右します。
IBM Concertが狙う「統合された運用ビュー」
IBM Concertの説明で重要なのは、単一の脆弱性スキャナーではなく、アプリケーション、インフラ、ネットワークの情報を一つの運用視点へ集めるという点です。現代の企業システムでは、一つの脆弱性が単独で存在しているわけではありません。あるライブラリの脆弱性、公開設定、認証の弱さ、ネットワーク到達性、重要データへの近さ、業務の重要度が組み合わさって、実際のリスクになります。
たとえば、同じ脆弱性が二つのサーバーに存在していたとします。一つは外部から到達できず、個人情報も扱わない検証環境。もう一つは顧客向けサービスの認証部分に関わる本番環境です。脆弱性番号だけを見れば同じでも、対応優先度は大きく違います。防御側に必要なのは、脆弱性の深刻度だけでなく、どこにあり、何につながり、誰に影響するのかを理解することです。
AIは、この相関付けを助ける可能性があります。ログ、構成情報、依存関係、コード、チケット、資産台帳、クラウド設定、ネットワーク経路を読み解き、どの修正が最も事業リスクを下げるかを示す。人間の担当者は、AIの提案を入口として、優先順位、修正計画、承認、通知を判断する。これが実現すれば、アラートが多すぎて動けない状態から、対応すべき順番が見える状態へ近づきます。
ただし、統合された運用ビューには前提があります。資産台帳が古い、所有者が不明、ネットワーク構成が実態と違う、ログが取れていない、クラウド権限が整理されていない、といった状態では、AIに渡す情報も不正確になります。AIを導入する前に、基本的な資産管理、権限管理、ログ管理、変更管理を整える必要があります。
ここは地味ですが、最も重要です。AIサイバー防御は、整った情報を与えられて初めて力を発揮します。混乱した台帳、属人的な運用、見えない例外、放置された古いシステムをそのままにして、AIだけで安全になるわけではありません。
Secure Coderが示す「開発中に直す」方向
IBM Concert Secure Coderは、開発者のIDE内でリスクを検出し、優先順位を付け、修正案を提示する方向を示しています。この考え方は、セキュリティを開発の最後にまとめて確認するのではなく、コードを書く段階で組み込む「シフトレフト」に近いものです。
開発現場では、脆弱性対応が後回しになりがちです。機能開発、納期、顧客要望、障害対応が優先され、セキュリティレビューはリリース前のチェックリストになってしまうことがあります。その結果、見つかった問題を直すには大きな手戻りが発生します。設計を変える必要がある場合、リリース予定そのものに影響することもあります。
AIがIDE内でリスクを示せるなら、開発者は問題が小さいうちに直せます。危険な入力処理、認可漏れ、秘密情報の埋め込み、古い暗号方式、脆弱な依存パッケージ、例外処理の不足などを早期に見つけられれば、本番投入後の対応よりもコストは低くなります。
一方で、AIによるコード修正には注意が必要です。AIが提案した修正が、見かけ上は正しくても、業務仕様を壊すことがあります。認可を厳しくしすぎて正当なユーザーが使えなくなる。エラーを握りつぶして監査ログが消える。依存ライブラリの更新で互換性が崩れる。テストが不足したまま修正を取り込む。こうした問題は実務で起こり得ます。
したがって、開発中のAIセキュリティ支援は、提案を自動で取り込む道具ではなく、レビューを加速する道具として扱うべきです。修正案には、差分、根拠、影響範囲、必要なテスト、残るリスクを添える。重要な変更はコードレビューとCIを通す。機密情報を含むコードや顧客データを外部AIに渡す場合は、契約と社内規程を確認する。これらの基本を外さないことが大切です。
AIエージェント型SOCの可能性と限界
IBM Autonomous Securityのようなマルチエージェント型セキュリティサービスは、SOCの運用を変える可能性があります。SOCでは、日々大量のアラート、ログ、チケット、脆弱性情報、脅威インテリジェンスを扱います。人間のアナリストがすべてを深く読むことは難しく、重要なアラートが埋もれることもあります。
AIエージェントは、複数の役割に分かれて作業できます。あるエージェントはログを要約し、別のエージェントは脅威情報と照合し、別のエージェントは影響範囲を調べ、さらに別のエージェントが修正候補や封じ込め手順を作る。人間の担当者は、これらの出力を確認し、判断し、実行を承認する。うまく設計されれば、初動の速さと説明の質を高められます。
しかし、SOCの自動化には限界があります。AIがアラートを誤って低リスクと判断すれば、重大な侵害を見逃すかもしれません。逆に誤って高リスクと判断すれば、不要な遮断や業務停止を招くかもしれません。攻撃者がAIの判断を誘導するために、ログや入力情報を操作する可能性もあります。AI自身が使うツールや権限が乗っ取られれば、被害が拡大する恐れもあります。
そのため、AIエージェント型SOCでは、実行権限を段階的に分けることが重要です。最初は読み取りと要約だけに限定する。次にチケット作成や修正提案まで広げる。さらに封じ込め手順の下書き、スクリプト生成、検証環境での実行へ進める。本番遮断、アカウント停止、データ削除、外部通知などの重要操作は、人間の承認を必須にする。こうした段階設計がなければ、速さがリスクに変わります。
企業が最初に決めるべき五つのガードレール
AIサイバー防御を導入する企業は、製品選定の前にガードレールを決める必要があります。どのAIを使うかよりも、何を許し、何を許さないかが先です。
一つ目は、目的の限定です。脆弱性管理、ログ要約、開発者支援、インシデント初動、サプライチェーン監視など、用途ごとに対象データと許容リスクは違います。最初から全領域に広げるのではなく、効果を測りやすく、リスクを管理しやすい用途から始めるべきです。
二つ目は、権限の最小化です。AIに管理者権限を渡す、全社の機密文書を読ませる、本番環境で自由にコマンドを実行させる、といった設計は危険です。AIは人間の権限を超えてアクセスできないようにし、読み取り、提案、検証、実行、外部送信の段階を分ける必要があります。
三つ目は、監査ログです。AIが何を参照し、何を生成し、どのツールを使い、誰が承認し、どの結果になったのかを残さなければ、問題発生時に原因を追えません。セキュリティのためにAIを入れたのに、AIの行動が追跡できない状態では本末転倒です。
四つ目は、人間の承認です。人間が確認する、という言葉だけでは不十分です。確認者が根拠、差分、影響範囲、代替案、残るリスクを見られる形にする必要があります。AIが長い説明を出すだけでは、実質的なレビューになりません。判断に必要な情報を短く整理し、必要なら詳細へ進める設計が求められます。
五つ目は、脆弱性の調整開示です。AIが未知の脆弱性を見つけた場合、すぐに公表すれば攻撃者に情報を与える可能性があります。逆に閉じたままにすれば、利用者がリスクを知らないままになります。製品ベンダー、オープンソースメンテナー、顧客、規制当局、業界団体とどう連携するかを事前に決めておく必要があります。
オープンソースとサプライチェーンの見方が変わる
IBMの発表では、Red Hatを含むオープンソース領域への言及も重要です。現代のソフトウェアは、多くのオープンソースコンポーネントに依存しています。アプリケーション本体のコードが安全でも、依存ライブラリ、コンテナイメージ、ビルドツール、CI/CD設定、パッケージレジストリ、署名、配布経路に弱点があれば、サプライチェーン全体が危険になります。
AIは、サプライチェーンの可視化に役立つ可能性があります。依存関係を読み解き、脆弱なバージョンを見つけ、どのアプリが影響を受けるかを整理し、修正の優先順位を出す。さらに、更新による互換性リスクやテスト範囲を提案することも考えられます。
ただし、オープンソースの安全性は、AIだけでは解決できません。メンテナーの負担、資金不足、古い依存関係、署名や配布の仕組み、企業利用者の責任が絡みます。企業がオープンソースを使うなら、SBOMの整備、依存関係の更新方針、長期サポートの有無、脆弱性通知の受け取り、メンテナーへの還元を考える必要があります。
Project Glasswingのような取り組みは、強力なAIを使って重要なソフトウェアの弱点を先に見つける可能性を開きます。しかし、見つけるだけでは不十分です。修正を作り、レビューし、リリースし、利用者へ届け、古いバージョンを更新してもらうところまでが防御です。ここには、人間のコミュニティ、企業の保守体制、利用者の更新文化が必要です。
日本企業にとっての実務的な意味
日本企業にとって、このニュースは遠い海外のAI企業の話ではありません。日本の企業システムも、クラウド、SaaS、オープンソース、外部委託、古い基幹システム、海外ベンダーの製品に依存しています。AIで攻撃速度が上がるなら、日本語圏や国内企業だけが例外になることはありません。
特に注意が必要なのは、レガシーシステムと外部委託の多い環境です。古いシステムは仕様書が不完全で、担当者が退職し、更新手順が属人化していることがあります。AIが脆弱性を見つけても、誰が直すのか、どのテストが必要か、停止時間をどう確保するかが決まっていなければ対応は進みません。外部委託先との契約に、脆弱性対応、ログ提供、緊急パッチ、AI利用時のデータ取り扱いが含まれているかも確認が必要です。
金融、医療、公共、通信、教育、交通などの分野では、サイバー対策が社会的な責任に直結します。AIが提示したリスク評価や修正案を、そのまま重要システムへ適用することは避けるべきです。業務影響、法令、監督指針、顧客説明、インシデント報告、委託先責任を含めて判断する必要があります。
また、日本語のログ、コメント、設計書、業務用語をAIがどこまで正確に理解できるかも検証が必要です。英語圏のベンチマークで高い性能を示していても、日本語の社内文書や古い仕様書、業界固有の略語では誤解が起きます。AIの出力が流暢な日本語であっても、根拠と原文を確認する姿勢が欠かせません。
導入前チェックリスト
AIサイバー防御を導入する前に、企業は次の項目を確認するとよいでしょう。
- 対象にする用途は明確か。脆弱性管理、ログ分析、開発支援、SOC支援などを分けているか。
- AIに渡すデータの範囲は決まっているか。顧客情報、個人情報、営業秘密、ソースコードの扱いは契約上問題ないか。
- AIの権限は最小化されているか。読み取り、提案、検証、本番実行を分けているか。
- AIの出力を誰が確認するか。確認者に必要な根拠、差分、影響範囲が提示されるか。
- 監査ログは残るか。参照データ、生成内容、実行コマンド、承認者、結果を追跡できるか。
- 誤検知と見逃しにどう対応するか。AIの判断を評価する指標とレビュー体制はあるか。
- 脆弱性発見時の開示手順はあるか。ベンダー、顧客、規制当局、社内広報との連携は決まっているか。
- オープンソース依存関係は把握できているか。SBOM、更新方針、長期サポート、緊急パッチ手順はあるか。
- 本番環境での自動実行をどこまで許すか。遮断、削除、アカウント停止、外部通知は人間承認になっているか。
- 導入効果をどう測るか。平均修正時間、重大アラートの処理時間、再発率、レビュー負荷などを追えるか。
このチェックリストは、AI製品を比較する前の土台です。製品の機能が豊富でも、社内の権限、ログ、承認、開示手順が未整備なら、AIの効果は限定的です。逆に、基本運用が整っていれば、AIは人間の判断を支える強力な補助線になります。
AI防御が広がることで起きる業界変化
AIサイバー防御が広がると、セキュリティ業界の競争軸も変わります。従来は、検知精度、シグネチャ、EDR、SIEM、脆弱性スキャン、ペネトレーションテスト、マネージドサービスといった領域ごとに製品が分かれていました。これからは、検知した情報をどうつなげ、どの修正を優先し、誰に承認させ、どの証跡を残すかが重要になります。
ベンダーに求められるのは、AIモデルの性能だけではありません。企業の既存システムに接続できるか、権限を細かく制御できるか、監査ログを残せるか、誤判断をレビューしやすいか、規制産業で使える説明性があるか、データの所在と契約条件が明確か。こうした運用面が評価されるようになります。
セキュリティ人材の役割も変わります。AIがログ要約や初期調査を助ける一方で、人間には、事業リスクの判断、攻撃者の意図の読み解き、組織内の調整、外部説明、例外対応、制度設計がより強く求められます。単純作業が減る可能性はありますが、責任が軽くなるわけではありません。
開発者にも影響があります。AIがコードの弱点を指摘するようになると、セキュリティレビューは専門部署だけの仕事ではなく、日常の開発体験に組み込まれます。開発者は、AIの指摘を理解し、必要な修正を選び、テストで確かめる力が必要になります。セキュリティ担当者は、開発者を責めるのではなく、修正しやすい仕組みを整える役割を担います。
過度な期待を避けるための見方
AIサイバー防御には大きな可能性がありますが、過度な期待は危険です。AIが未知の脆弱性を見つけられるとしても、すべての脆弱性を見つけられるわけではありません。AIが修正案を作れても、業務仕様や法的要件を完全に理解しているとは限りません。AIがログを要約しても、攻撃者が意図的にノイズを混ぜれば判断を誤る可能性があります。
また、AIを導入することで新しい攻撃面も増えます。AIエージェントに与えたAPIキー、チケットシステム、クラウド権限、コードリポジトリ、チャットツールが悪用されるかもしれません。プロンプトインジェクションによって、AIが意図しない命令を実行する可能性もあります。AIの出力を過信して、人間のレビューが形骸化するリスクもあります。
AIを使った防御の成熟度は、モデル性能だけでなく、運用設計で決まります。どの情報を入力し、どのツールを使わせ、どの出力を信じ、どの操作を止めるのか。誤りをどう検知し、改善し、再発を防ぐのか。ここを設計しないまま導入すると、AIはセキュリティを強化するどころか、複雑さを増やす要因になります。
現実的な導入は、小さく始めて検証することです。まずは読み取り専用のログ要約や脆弱性優先順位付けから始める。次に、修正案の下書きやテスト生成に広げる。検証環境で自動実行を試し、評価指標を作る。十分に監査できる状態で、本番操作の一部に人間承認付きで適用する。段階的に進めることで、効果とリスクの両方を見やすくなります。
読者が今日からできること
個人の開発者や小規模チームであれば、まず依存関係と秘密情報の管理を見直すことから始められます。使っていないパッケージ、古いライブラリ、公開リポジトリに残ったAPIキー、過剰なクラウド権限、テストされていない認可処理は、AI以前から危険です。AIツールを使う場合も、ソースコードや設定情報をどこへ送るのか、保存されるのか、学習に使われるのかを確認してください。
企業のセキュリティ担当者であれば、AI導入前に現在の脆弱性対応時間を測ることが有効です。重大な脆弱性が公表されてから、自社資産の影響範囲を特定するまで何時間かかるのか。所有者へ連絡するまで何時間かかるのか。修正、検証、本番反映、完了報告まで何日かかるのか。この時間を把握していなければ、AI導入で何が改善したのか評価できません。
経営層であれば、AIサイバー防御を単なるツール購入ではなく、事業継続とガバナンスの課題として扱うべきです。攻撃が速くなるなら、意思決定も速くする必要があります。予算、権限、緊急対応、広報、法務、顧客説明、委託先管理を横断して準備しなければ、現場だけでは対応できません。
メディアや一般読者は、AIサイバー防御のニュースを見るときに、能力の宣伝と実運用を分けて読むことが大切です。どのモデルがどんな脆弱性を見つけたのか、検証は独立しているのか、修正は完了したのか、公開範囲は適切か、誰が責任を持つのか。こうした問いを持つことで、誇張された期待や不安に振り回されにくくなります。
まとめ AI時代のセキュリティは「速さ」と「統制」の両立へ
IBMのAIセキュリティポートフォリオ拡充とProject Glasswingへの参加は、AIサイバー防御が実務の中心へ近づいていることを示しています。攻撃者がAIで偵察、脆弱性発見、悪用、横展開を速めるなら、防御側も、検知、優先順位付け、修正、検証、開示を速めなければなりません。
ただし、速さだけを追えば危険です。AIが本番環境で重要操作を行うなら、権限、監査ログ、人間の承認、説明責任が必要です。未知の脆弱性を見つけたなら、協調的な開示と修正の順序が必要です。開発者に修正案を出すなら、テストとレビューが必要です。AIをセキュリティに使うほど、組織の統制が問われます。
今回のニュースから読み取れる最大の変化は、サイバーセキュリティが「見つける」だけではなく「直し切る」方向へ進んでいることです。大量のアラートを眺める時代から、事業影響を踏まえて優先順位を付け、修正を作り、検証し、証跡を残す時代へ移っています。AIはその流れを加速しますが、責任を肩代わりするものではありません。
AIサイバー防御を成功させる企業は、モデルの性能だけを見ません。資産管理、権限管理、ログ、承認、開示、開発プロセス、オープンソース管理を整えたうえで、AIを人間の判断を支える道具として組み込みます。攻撃が速くなる時代に必要なのは、AIへの丸投げではなく、AIを使いこなすための現実的な運用設計です。
