AnthropicのMythosは何を変えるのか：AI時代のサイバーセキュリティを経営課題として捉える

2026年4月7日、AnthropicはProject Glasswingを発表しました。

Project Glasswingは、Claude Mythos Previewという新しいフロンティアモデルを、重要なソフトウェア基盤の防御目的で限定提供する取り組みです。Anthropicはこのモデルについて、一般公開は予定しておらず、研究プレビューとして限られた組織に提供すると説明しています。

この発表が注目された理由は、単に新しいAIモデルが出たからではありません。

Anthropicは、Mythos Previewが主要なOSやWebブラウザを含む重要ソフトウェアから多数のゼロデイ脆弱性を見つけたと説明しています。さらに、AnthropicのFrontier Red Teamは、Mythos Previewが脆弱性の発見だけでなく、場合によっては悪用可能性の検証まで自律的に進めたとする技術評価を公開しています。

これは、AI開発の話であると同時に、企業のセキュリティ、開発体制、リスク管理の話です。

Mythosは「サイバー専用AI」ではない

まず整理したいのは、Mythos Previewは単なるセキュリティ専用ツールではないという点です。

Anthropicは、Mythos Previewを一般目的の未公開フロンティアモデルと位置づけています。強いコーディング能力、推論能力、エージェント的な作業能力があり、その結果としてサイバーセキュリティ領域でも強い能力を示している、という説明です。

ここが重要です。

もしサイバー攻撃だけに特化した特殊モデルであれば、議論はある程度限定できます。しかし、実際には「複雑なコードを読み、理解し、修正し、検証できる能力」が高まるほど、脆弱性の発見や悪用にも転用できるという構造です。

つまり、AIの開発能力が上がることと、AIのサイバー能力が上がることは、かなり深いところでつながっています。

これは避けられないトレードオフです。AIが安全なコードを書く力を持つほど、危険なコードの弱点も見つけやすくなります。AIが大規模コードベースを理解できるほど、人間が見落としてきた境界条件や古い設計上の弱点にも届きやすくなります。

本当に見るべきは「危険なモデルか」ではない

Mythosをめぐる報道では、「危険すぎて公開できないAI」という見出しが目立ちます。これはわかりやすい表現ですが、企業が向き合うべき論点としては少し粗いと思います。

重要なのは、Mythosだけが危険かどうかではありません。

重要なのは、AIによって脆弱性発見と悪用検証のコストが下がり始めていることです。

これまでも、優秀なセキュリティ研究者は高度な脆弱性を見つけてきました。ファジング、静的解析、動的解析、リバースエンジニアリング、ペネトレーションテストなど、既存の手法も進化してきました。

しかし、これらには高い専門性と時間が必要でした。脆弱性を見つけるだけでなく、再現条件を整理し、影響範囲を見極め、修正案を考え、場合によっては悪用可能性を検証するには、熟練した人間の判断が必要でした。

AIがここを補助できるようになると、攻撃側と防御側の両方に変化が起きます。

防御側にとっては、自社コードや依存ライブラリの弱点を早く見つけられる可能性があります。オープンソースのメンテナや企業のセキュリティチームにとっては、限られた人員でより広い範囲を確認できるかもしれません。

一方で、攻撃側にとっても、探索、再現、悪用検証の一部が速くなる可能性があります。

ここに、Mythosの本質があります。

すでにOpus 4.7でも、片鱗は見えている

Mythos Previewは一般提供されていないため、私たちが日常的に試せるモデルではありません。

しかし、一般利用できるClaude Opus 4.7の挙動を見ていると、Mythosで語られている変化が、まったく別世界の話ではないことも感じます。

AnthropicはOpus 4.7の発表で、このモデルをOpus 4.6より高性能なモデルとして位置づけつつ、Mythos Previewよりサイバー能力は低いと説明しています。さらに、Mythosで見えたリスクを踏まえ、より低能力なモデルでサイバー安全策を先に試す方針にも触れています。

ここで重要なのは、Opus 4.7がMythosと同じことをすべてできる、という話ではありません。

重要なのは、すでに一般提供モデルでも、複雑なコード、認証フロー、設定ファイル、ログ、API仕様を横断して読み解き、問題のありそうな箇所をかなり具体的に指摘できる段階に来ていることです。

たとえばOAuthを考えると、仕組み自体は標準化され、長く使われてきたものです。しかし、OAuthだから安全というわけではありません。実際には、redirect URIの扱い、scope設計、トークンの保存場所、ログへの混入、フロントエンドへの露出、リフレッシュトークンの運用、resource server側のaudience検証など、実装と運用に依存する攻撃面が多くあります。

特にBearer Tokenは、その名の通り「持っている人が使える」性質を持ちます。RFC 6750でも、Bearer Tokenは暗号鍵の所有証明を要求しないトークンとして説明されています。つまり、トークンが漏れれば、その影響をどう狭めるかが問題になります。

もちろん、これはOAuthが危険な仕組みだという意味ではありません。むしろOAuthは、適切に実装すれば現代の認可基盤として非常に重要です。ただし、仕組みを理解していないまま「標準だから安全」と扱うと、穴は残ります。

RFC 9700のOAuth 2.0 Security Best Current Practiceでも、漏洩したアクセストークンの悪用を防ぐため、sender-constrained access token、audience restriction、最小権限、トークン漏洩時の影響縮小などが整理されています。

AIが強くなると、この種の「仕様上は正しいが、実装・運用上は危うい部分」を見つける力が上がります。

人間のセキュリティ専門家が長い時間をかけて読み解いていた認証フローや権限境界を、AIが短時間でたどれるようになる。ここが、Mythosに見る驚異的なところです。

問題は、AIが突然魔法のように未知の穴を作り出すことではありません。もともと複雑なシステムの中に存在していた弱い前提、曖昧な実装、古い設定、漏れたトークン、広すぎる権限を、AIが高速に見つけやすくなることです。

発表内容は大きいが、冷静な読み方も必要

Anthropicの発表はかなり強い内容です。Project Glasswingでは、AWS、Apple、Google、Microsoft、NVIDIA、Linux Foundation、JPMorganChase、Palo Alto Networksなどが立ち上げパートナーとして挙げられています。Anthropicは、Mythos Previewの利用クレジットとして最大1億ドル、オープンソースセキュリティ組織への寄付として400万ドルを投じるとも説明しています。

一方で、この発表をそのまま「AIがすぐに世界中のシステムを壊せるようになった」と読むのは早計です。

Anthropic自身のRed Team記事でも、見つかった脆弱性の多くはまだ未修正であり、詳細公開には制約があると説明されています。また、重大度評価については、手動レビュー済みの198件で専門家の評価と高い一致が見られたとされていますが、未レビューの大量の報告については今後の検証が必要です。

Scientific Americanの記事でも、専門家の見方は分かれています。Mythosは重要な進歩である一方、最悪シナリオだけで語るべきではない、という慎重な意見も紹介されています。

ここで必要なのは、過小評価でも過大評価でもありません。

「すぐに終末が来る」と見る必要はありません。しかし、「まだ一部の研究プレビューだから関係ない」と無視するのも危険です。

企業にとっての本当の変化

企業にとってMythosの意味は、AIモデル名そのものよりも、セキュリティ運用の前提が変わることにあります。

これまで多くの企業では、セキュリティは開発の最後に確認するものとして扱われがちでした。リリース前に診断を受ける。年に一度ペネトレーションテストを行う。重大な脆弱性情報が出たら対応する。もちろん、それらは重要です。

しかし、AIが脆弱性の探索と検証を加速するなら、セキュリティは最後のチェックでは足りません。

設計段階で脅威を整理する。実装中に依存関係と権限境界を確認する。CIで静的解析や依存ライブラリチェックを回す。ステージングで攻撃面を確認する。リリース後もログ、監視、パッチ適用、インシデント対応を継続する。

つまり、DevSecOpsの考え方がより現実的な必須要件になります。

AIで開発が速くなるほど、変更量は増えます。変更量が増えるほど、脆弱性が混入する機会も増えます。さらに、AIが攻撃側にも使われるなら、脆弱性が見つかってから悪用されるまでの時間も短くなる可能性があります。

「速く作れる」ことと「安全に運用できる」ことの差は、これからさらに広がります。

AIエージェント開発では、権限設計がより重要になる

Mythosの話は、AIエージェント開発にも直結します。

AIエージェントは、コードを書くだけでなく、ファイルを読み、コマンドを実行し、外部APIにアクセスし、場合によっては本番環境に近い情報を扱います。これは開発効率を大きく上げる一方で、権限の持たせ方を間違えるとリスクも大きくなります。

たとえば、AIに広すぎる権限を渡していないか。秘密情報を読み取れる場所に置いていないか。実行ログは残っているか。危険な操作にはレビューや承認が挟まるか。外部サービスへの送信内容は管理できているか。

これらは、AI時代の開発基盤における基本設計になります。

AIが賢くなるほど、雑な権限設計は危険になります。人間なら空気を読んで止まる場面でも、AIは与えられたゴールに向かって実行してしまうことがあります。だからこそ、AIに何を許可し、何を禁止し、どこで止めるのかをシステム側で設計する必要があります。

今すぐ企業が見直すべきこと

Mythos級のモデルを自社で使えるかどうかに関係なく、企業は次の論点を見直すべきです。

まず、ソフトウェア資産の把握です。自社がどのアプリケーション、依存ライブラリ、SaaS、クラウド設定に依存しているのかが見えていなければ、脆弱性情報が出ても影響範囲を判断できません。

次に、パッチ適用の意思決定です。重大な脆弱性が見つかったとき、誰が判断し、どの環境から適用し、どの順番で本番へ反映するのか。ここが曖昧だと、AIによって発見速度が上がっても、防御側の対応速度は上がりません。

三つ目は、開発プロセスへのセキュリティ組み込みです。脅威モデリング、コードレビュー、依存関係スキャン、シークレット検出、ログ設計、ロールバック手順を、開発フローの外側ではなく内側に入れる必要があります。

四つ目は、AI利用ルールです。AIにどのコードを見せてよいのか。どのデータを入力してよいのか。生成された修正を誰がレビューするのか。AIが提案したセキュリティ修正をどのように検証するのか。これを現場任せにしないことです。

最後に、インシデント対応の訓練です。AI時代のセキュリティでは、未然防止だけでなく、検知、封じ込め、復旧、説明責任まで含めた運用能力が問われます。

フィールフロウとしての見方

Mythosの発表は、AIが「便利な文章生成ツール」から「実際のシステムに深く関与する実行主体」へ近づいていることを示しています。

企業にとって重要なのは、AIを恐れて止まることではありません。かといって、AIで何でも速くなると考えて統制を後回しにすることでもありません。

必要なのは、AI活用とセキュリティを同じ設計図の中で扱うことです。

AIで開発を速くするなら、セキュリティ確認も速くする。AIエージェントに作業させるなら、権限とログを設計する。AIで業務を自動化するなら、例外時の責任と復旧手順を決める。

この接続がないままAI導入だけを進めると、短期的には生産性が上がっても、長期的には運用負債とセキュリティリスクが増えます。

Mythosは、特定のモデルのニュースで終わる話ではありません。

AI時代のシステム開発では、「作れる力」と「守れる力」を同時に設計しなければならない。そのことを、かなり強い形で示した出来事だと捉えるべきです。