Claude Mythosが示したのは、AIモデルの能力が上がったという話だけではない。本当に重要なのは、「自社のソフトウェアが、こういうAIにかかれば一瞬で脆弱性として暴かれる時代になった」という事実のほうだ。長年人間のセキュリティレビューを生き残ってきたコードが、Mythosの手にかかれば数千件単位で穴が見つかる。Project Glasswingでの実績がそれを証明してしまった。
これは、企業のセキュリティ担当者・CTO・エンジニアリングマネージャーにとって、無視できない変化だ。「うちはまだ大丈夫」と言える状況ではなくなってきている。攻撃側が同等のツールを手に入れるのが時間の問題である以上、防御側もアプローチを変える必要がある。本記事では、Mythos以降の世界で社内の脆弱性管理とAI監査をどう見直すかを、実務寄りに整理する。
何が変わったのか ── 3つの新しい現実
Mythosが現実に存在することで、企業が直面する状況は具体的に3つ変わった。
① 既存コードの「眠っていた脆弱性」が一気に表面化する
Project Glasswingが最初の1ヶ月で見つけた1万件超の重大脆弱性は、ほとんどが「広く使われているOSS」に存在していたものだ。OpenBSDから27年前のバグが出てきた事例が象徴的だが、これはOpenBSDが特別怠っていたわけではない。人間のレビューでは見つけられないレベルの欠陥が、どのコードベースにも一定数眠っていると考えるのが現実的になった。
自社のコードベースも例外ではない。むしろ、OSS以下の精査しか受けていない社内プロダクトのほうが、相対的にリスクが高い可能性すらある。
② サードパーティ・依存ライブラリの透明性が一段重要になる
自社で書いたコードだけを守っても意味がない時代になっている。npmパッケージ、PyPIライブラリ、Dockerイメージ、それらの依存関係──現代のプロダクトは外部コードの上に積み上がっている。Mythos級のツールが攻撃側に渡れば、依存ツリーのどこか1箇所の脆弱性から侵入される可能性が現実的なシナリオになる。
③ AIによる監査自体が、新しい運用課題になる
「AIに自社コードを監査させる」こと自体が新しい意思決定領域になる。どのツールを使うか、結果をどう扱うか、誤検出にどう対処するか、外部に開示するかどうか。これまでなかった運用フローを、ゼロから組み立てる必要がある。
これまでの常識 vs これからの常識
具体的に、何がどう変わるのか。これまでセキュリティ業界で「ベストプラクティス」とされていた慣行と、Mythos以降に求められる慣行を並べてみる。
| 領域 | これまでの常識 | これからの常識 |
|---|---|---|
| 監査頻度 | 年1回の定期監査＋大型リリース時 | CI/CDに組み込んだ継続的AIスキャン |
| 脆弱性の発見元 | CVE公開・外部報告を待つ | 自社で先回りして発見・対処 |
| レビュー対象 | 新規コード中心 | レガシーコードも含めた全体棚卸し |
| サードパーティ依存 | 主要ライブラリのみ確認 | 依存ツリー全体の継続監視 |
| 脆弱性管理ツール | シグネチャベースのスキャナ | AI型の動的解析ツールを併用 |
| 開示判断 | 個別判断 | 明文化された開示プロセス |
| 権限・アクセス制御 | 役割ベース（RBAC）中心 | AI操作も含めた監査ログの整備 |
すべてを一気に変える必要はない。ただ、自社の現状が左列に寄っているなら、右列に向けて動き出す時期が来ていると考えたほうがいい。
社内で「いま、何をすべきか」
では、明日から動けることは何か。優先度別に整理する。
短期（1〜3ヶ月）
| 項目 | 具体的な内容 | 担当目安 |
|---|---|---|
| 資産棚卸し | 守るべきコードベース・サービス・データを一覧化 | セキュリティ＋プロダクト |
| SBOM整備 | 依存ライブラリ一覧（Software Bill of Materials）を作成 | 開発リード |
| 既存スキャナの結果確認 | DependabotやSnykの未対応Alertを洗い出す | 開発チーム |
| AI監査ツールの試験導入 | 1プロジェクトに対象を絞ってPoC実施 | セキュリティリード |
| 開示プロセスの草案作成 | 脆弱性を見つけた際の社内フローを文書化 | 法務＋セキュリティ |
中期（3〜12ヶ月）
| 項目 | 具体的な内容 | 担当目安 |
|---|---|---|
| CI/CDへの組み込み | プルリクエスト時の自動スキャンを標準化 | プラットフォーム |
| レガシーコード監査 | 年単位で放置されてきたコードの優先順位付け監査 | セキュリティ＋各事業部 |
| AIガバナンス策定 | 社内でAIを使う際のルール・許可範囲を明文化 | 経営＋法務 |
| インシデント対応訓練 | AI起因の脆弱性発見シナリオでの机上演習 | セキュリティ |
| 外部ベンダ評価基準の更新 | 調達時のセキュリティチェック項目にAI監査の有無を追加 | 調達＋セキュリティ |
AI監査ツールを選ぶときの観点
「AIで脆弱性を見つける」と一口に言っても、ツールによって得意分野がかなり違う。導入を検討する際にチェックすべき観点を整理しておく。
| 観点 | 確認すべきこと |
|---|---|
| 解析方式 | 静的解析のみか、動的解析（実際に走らせる）もできるか |
| 対応言語・フレームワーク | 自社の技術スタックをカバーしているか |
| 誤検出率 | False Positiveが多すぎるとレビュー工数が爆発する |
| 修正提案の品質 | 「ここがバグ」だけでなく「こう直す」まで提示できるか |
| データの取り扱い | コードを外部に送信するか、オンプレ・VPC内で動くか |
| 監査ログ | 誰が・いつ・何をスキャンしたかが追跡できるか |
| 既存ツールとの連携 | GitHub、GitLab、Jira、Slackなどに統合できるか |
| 料金モデル | コード量課金か、ユーザー数課金か。スケール時のコスト試算 |
特に重要なのは「データの取り扱い」だ。自社の機密コードを外部APIに投げるツールの場合、契約上どこまで使われるのか、学習に利用されないか、保存期間はどれくらいかを契約書レベルで確認する必要がある。法務・調達と必ず連携したい部分だ。
見落とされがちな論点 ── 倫理と法務
AIで自社コードや依存ライブラリの脆弱性を発見できるようになった、として。次に出てくるのが「見つけたものをどう扱うか」という問題だ。これは技術論ではなく、運用・倫理・法務の領域になる。
自社プロダクトの脆弱性
自社のコードに見つかった重大な脆弱性を、どのタイミングで顧客に開示するか。修正前に開示すれば攻撃の好機を与えるし、隠したまま事後発覚すれば信頼を失う。多くの企業は「Coordinated Disclosure（協調的開示）」というフレームワークに従うが、社内ルールとして事前に明文化されていないと、いざという時に判断がぶれる。
サードパーティの脆弱性
使っているOSSライブラリにAIが脆弱性を発見した場合、それをメンテナーに通報するべきか、しないか。これは「セキュリティ研究者としてのマナー」と「自社の競争上の利益」が衝突しうる領域だ。Anthropic自身がProject Glasswingで採用しているのは、CERT/CCを通じた責任ある開示プロセスで、参考にしやすい。
AIの誤検出と過剰反応
AIが「これは脆弱性です」と言ったものの、実際には誤検出だった、というケースは必ず一定割合で発生する。これに毎回過剰反応していると、開発チームが疲弊する。「AIの指摘は人間のセキュリティエンジニアがトリアージする」という運用ルールを明確に置いておかないと、ノイズに溺れる。
経営層に説明するときのポイント
セキュリティ強化のための投資を経営層に提案する場面で、Mythosの話は強力な材料になる。ただし、煽る形では説得力が落ちる。整理して伝えるなら、以下の3点が要点だ。
- 事実：Anthropicが限定公開した実例で、1ヶ月で1万件超の重大脆弱性がOSSから発見された。これは攻撃側にも同等のツールが行き渡る可能性を示している
- 含意：自社のコードベースにも、まだ発見されていない重大脆弱性が存在する可能性が高い。これまでの監査体制では検出が難しいレベルのものを含む
- 提案：先回りで監査体制を強化する。「攻撃を受けてから対処」のコストと、「事前にAI監査を導入」のコストを比較すれば、後者のほうが桁違いに安い
これは脅し材料というより、「守りの投資が、過去最も費用対効果の高い領域になっている」というポジティブな提案として伝えるのがいい。
おわりに ── 変化は、もう始まっている
Claude Mythosそのものを使えるかどうかは、当面、ほとんどの企業にとっては関係ない話だ。だが、Mythosが示した「AIで脆弱性を発見する」という時代の流れは、すでに動き始めている。Claude Securityのような派生プロダクトはEnterprise顧客向けにベータ提供中で、TeamやMaxプランへの拡大も予告されている。他社からも類似のツールが続々登場するはずだ。
1年後を想像すると、「AI監査を導入している企業」と「まだ手をつけていない企業」のセキュリティ水準には、はっきりした差が生まれている可能性が高い。差を生むのは技術ではなく、運用フローと意思決定の早さのほうだ。資産棚卸し、SBOM整備、開示プロセスの文書化──どれも明日から動ける項目ばかりなので、まず一歩目を踏み出してみるところから始めたい。
※本記事の情報は2026年5月時点のものです。Anthropicの製品ラインナップ・提供条件は変更される可能性があります。実際の導入検討時は、最新の公式情報をご確認ください。
