本文へスキップ

Wiz Atlasの「Mythos超え」から考える、AIに仕事を任せる設計。サイバーエージェントの実践と共通するもの

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

シンジです。

セキュリティの分野では、AnthropicのClaude Mythosや、OpenAIのGPT-5.6-Cyberが史上最強と名高いわけですが、いやこれ俺ら使えませんやんというオチ付きです。これらは高度な脆弱性調査や、攻撃が成立するかの検証に使えるモデルですが、一般企業が通常の契約だけで自由に使えるものではありません。

一般提供されている強力なモデルでも、サイバーセキュリティの仕事を任せるとセーフガードに当たり、途中で作業を拒否されることがあります。シンジも、脆弱性調査だけでなく、セキュリティのブログを書く程度ですらセーフガードで弾かれます。

そんな中、Wizが発表した脆弱性研究システム「Atlas」は、CyberGymというベンチマークで、Claude Mythos Previewを上回るスコアを出しました。びっくらポンですわ。

何でそんなことが出来るのかと見てみたら、そこに至る設計がミソでした。Atlasは「新しい最強モデルを一つ作った」という話ではありません。一般的なAIモデルを使いながら、目的を達成するまでの仕事を細かく分け、役割ごとにAIを働かせ、出てきた答えを検証するシステムだったのです。

国内でも、サイバーエージェントが「BUGMAP」というセキュリティエージェントで、よく似た考え方を実践しています。

なお、当社はWizの販売代理店で、Wizの内部情報を書きそうにはなりますが、この記事は全て公開情報だけで仕上げてあります。

MythosもGPT-5.6-Cyberも、通常の契約だけでは使えない

Anthropicは、2026年4月に発表したProject Glasswingで、Claude Mythos Previewによって主要なOSやWebブラウザーなどから多数の脆弱性を発見したと報告しています。もともとは汎用の基盤モデルですが、コードを理解し、推論する能力がセキュリティの仕事でも強く発揮されている、という説明です。

ただし、Mythos Previewは、防御目的のパートナーや重要なソフトウェアを開発・保守する組織などへの限定提供です。一般提供は予定しないと説明されています。「強力だから、明日から自社の開発チーム全員で使おう」と通常の契約で導入できるものではありません。

Mythos 5.1の公式発表でも、利用は審査された組織などへの提供に限定され、発表時点の提供先は一部の米国組織とされています。一方、同じモデルに異なるセーフガードを適用したFable 5.1は一般提供されています。このセーフガードのお陰で、セキュリティの実務上ではかなり苦労します(シンジ経験談

他にもAnthropicは2026年8月21日の発表で、Claude Enterprise向けのClaude Security(公開ベータ)のスキャンをClaude Mythos 5で動かすと説明し、Mythos 5.1の発表後はMythos 5.1で動くとしています。ただし利用者が受け取るのは脆弱性の指摘や修正案といった成果物で、モデル自体に自由にプロンプトを送れるわけではありません。本記事で「通常の契約だけでは使えない」と言っているのは、この直接アクセスの話です。

OpenAIにも、サイバーセキュリティ向けのGPT-5.6-Cyberがあります。公式APIドキュメントでは、承認された防御側の利用者が、許可された脆弱性調査、エクスプロイトの検証、セキュリティテストに使うモデルと説明されています。利用には別途の承認と利用環境の有効化が必要で、Daybreakプログラムへの申請が案内されています。OpenAIのモデル一覧では、Daybreakの下にGPT-5.6-Cyberのほか、汎用モデルに防御業務向けのセーフガードを適用した「Daybreak Blue」と、専用モデルを指す「Daybreak Red」というエイリアスも掲載されています。通常のGPT-5.6を使えることと、GPT-5.6-Cyberを使えることは別です。

AnthropicにもCyber Verification Programという申請窓口はありますが、Mythos級モデルの対象化は「近い将来」とされ、発表時点のMythos 5.1の提供先は一部の米国組織です。申請すれば審査を受けられるGPT-5.6-Cyberとは、アクセスの条件や経路が異なります。ただ、後者も「APIの契約があれば誰でもすぐ使える」というものではありません。少なくとも、一般企業が自社での利用を前提に計画を立てるには、承認の確認が必要です。

使えるモデルでも、任せた仕事が途中で止まる

Fable 5.1、GPT-5.6、GPT-6といった最新の強力なモデルが使えても、サイバーセキュリティの仕事を最後まで任せられるとは限りません。悪用を防ぐためのセーフガードが、業務の途中で作動するためです。

これは、シンジ自身が実際に困っていることです。脆弱性調査を任せているときだけではありません。セキュリティのブログを書くだけでも、セーフガードに引っかかって、依頼した作業を拒否されることが多々あります。こちらは防御や解説のために使っているのに、仕事が止まってしまう。このもどかしさは、モデルの賢さとは別の問題です。

AnthropicはFable 5.1の発表で、ソースコードの脆弱性発見を許可し、誤検知を減らした一方、ペネトレーションテスト、エクスプロイト生成、バイナリの脆弱性スキャンなどは引き続きOpusモデルへ振り分けると説明しています。公式システムカードも、安全側に余裕を持たせるため、無害な利用や境界的な利用の一部が引き続きブロックされることを認めています。作業そのものの拒否と、別モデルへの切り替えは違いますが、どちらも「選んだモデルの能力を、そのまま仕事に使える」とは限らない例です。なお、Anthropicのヘルプによると、Claudeのアプリではこの自動切り替えが既定で有効ですが、Claude APIでは利用者側でフォールバックを設定しない限り、拒否応答が返ります。判定の対象も最新のメッセージだけでなく、ファイルや検索結果などモデルが読む内容全体に及ぶと説明されています。

OpenAIもGPT-5.6の公式システムカードで、サイバー領域の悪用防止と正当な防御業務の両立を目指すセーフガードを説明しています。ただし、僕のブログ執筆中の拒否が、具体的にどの判定や制御によるものだったかまでは確認できていません。

安全策が必要ない、と言いたいわけではありません。問題は、正当な業務まで止まることがあるなかで、どう仕事を成立させるかです。モデルの能力、利用承認、実際に許可される作業。この三つは別々に確認しなければなりません。

Wiz Atlasは、どこでMythos Previewを上回ったのか

Wizは、コードやクラウド環境、稼働中のシステムの情報をつなぎ、リスクの把握や修正、脅威への対応を支援するセキュリティプラットフォームを提供しています。クラウドインフラを運用してるとき、Wizがあるだけでセキュリティ対応が驚くほど楽になります。そんなWizの研究チームが開発したのがAtlasです。

2026年7月27日のWizの発表では、AtlasのCyberGym成功率は90.9%。Anthropicが公表したClaude Mythos Previewの値は83.1%です。この公表値の比較では、Atlasが上回っています。

Wizが公開したCyberGym成功率の比較図。横軸はリリース日、縦軸は成功率。出典:Wiz「Introducing Atlas」
Wizが公開したCyberGym成功率の比較図。横軸はリリース日、縦軸は成功率。出典:Wiz「Introducing Atlas」

ただし、この「Mythos超え」の意味は限定して理解する必要があります。

CyberGymの今回の指標は、脆弱性の説明と修正前のコードを与えられたシステムが、その問題を再現するPoCを作れるか、という課題です。PoCは、問題が実際に起きることを示すテストや入力だと考えてください。

何が悪いか分かっているコードで問題を再現することと、未知の問題をゼロから発見することは別です。90.9%は、世の中の未知の脆弱性を90.9%発見できるという意味ではありません。また、リーダーボード上ではどちらも課題ごとの試行回数1回として掲載されていますが、エージェント内部の並列探索、計算資源、実行ステップ数などの条件までそろえた比較は確認できていません。Mythos Preview側も実行の仕組みを通じて評価されるため、「裸のモデル一つ」と「エージェント集団」の純粋な比較ではありません。

ここで取り扱っているのは、あくまでMythos Previewとの公表スコアの比較です。Mythos Previewの後継であるClaude Mythos 5は2026年6月9日に発表済みで、Atlasの比較対象はそれ以前のPreviewの公表値です。

また、2026年9月4日更新時点のCyberGymリーダーボードには、Atlasの90.9%を上回るスコアのシステムが複数掲載されています。Atlasの結果は、Mythos 5や最新のMythos 5.1を含む全モデルへの優越や、現在の世界一という意味ではありません。

90%超えがこんなに沢山存在する
90%超えがこんなに沢山存在する

そのうえで、この結果を出したAtlasの構造には、点数以上に参考になるところがあります。

大事なポイントですが、Atlasは、まだ顧客向けに一般販売されているものではありません。今後Wizの利用顧客へ提供するための準備段階です。Wizの公式ブログではWiz Codeへの組み込みに取り組んでいると説明され、8月4日の公式記事でも未商用提供と明記されています。顧客の既存のアプリケーションセキュリティ業務へ組み込む計画であり、具体的な提供開始日や対象プランは、確認した公開情報では明らかになっていません。Wizを利用していれば、今すぐAtlasも使えるという意味ではありません。

「脆弱性を探して」を、ひとつのAIに丸投げしない

人間のセキュリティ担当者も、いきなりコードを眺めて脆弱性を言い当てているわけではありません。いや、そんな神がかった脆弱性診断士を俺は知っていますが(脆弱なコードが光って見えるらしいが)、これはもう超レアケースにしてください。

普通は、外から入力が入る場所を探したり、データの流れを追ったり、怪しい処理について仮説を立てて考えたり、本当にその経路へ到達できるか調べたり、問題が起きる条件を再現したり、そうした仕事を複数組み合わせています。

Atlasは、この過程を専門のエージェントに分担させますが、大きく次の4つに整理されています。

  1. 調査の地図を作るAI
    入力の入口、関数の呼び出し、データの流れ、危険な操作までの経路を整理します。コードの構造を表すCode Property Graph(CPG)を使い、推論を実際の関係情報に基づかせます。
  2. 複数のエージェントが独立して探すAI
    それぞれが仮説を立てて調査します。一つのAIが最初に思いついた筋書きだけに、調査全体を依存させません。
  3. 別のエージェントに反論させるAI
    「悪用できる」と主張する役、「成立しない」と反論する役、証拠を見て判定する役を分けます。もっともらしい説明を、そのまま報告書にしないためです。
  4. 実際に動かして確かめるAI
    専用の実行環境を用意し、必要な依存関係を入れて、問題を起こす入力を実行します。推理だけではなく、再現できる証拠を残します。

目的は一つでも、そこに至る仕事は一つではないということを再現しています。だから、各工程の「担当者」をAIに任せるという実装です。

ここでいう役割とは、単にプロンプトに「あなたは優秀なセキュリティ専門家です」と書くことではありません。何を入力として受け取り、何を調べ、どんな証拠を出し、次の担当へ何を渡すかまで決めることです。

例えば「この処理は危険です」という候補が出ても、その前に必ず有効な入力検査を通るなら、主張が崩れるかもしれません。最初の発見役とは別の担当に、その可能性を調べさせます。AIに答えを出させるだけでなく、その答えを疑う仕事も設計するわけです。

モデルの能力を引き出す「ハーネス」

この役割分担を動かす土台が、ハーネスです。モデルに渡す情報や道具、作業手順、実行環境、結果の受け渡しなどを支えます。

Wizは、工程全体の進行をモデルに自由に任せるより、仕事を分解してプログラムで制御し、モデルには範囲を絞った推論を担当させる方がよい結果になったと説明しています。また、各工程に適したモデルを評価して選び、新しいモデルが出れば見直す設計です。

汎用の基盤モデルが持つ能力を、専門業務の手順と道具で引き出しています。

ただし、採用モデルの詳細は限られた範囲でしか公開されていません。CyberGymのリーダーボードには、Wizの提出情報としてAtlasの採用モデルがGPT-5.5とClaude Opus 4.6の複数モデル構成と記載されている一方、Wiz自身のブログではモデル名を明かしておらず、工程ごとの割り当てやバージョン、時期による入れ替えは確認できません。参考までに、Project Glasswingの公表値ではClaude Opus 4.6単体のCyberGym成功率は66.6%です(評価条件が同一とは限りません)。いずれも一般提供されている上位モデルであり、「誰でも使える安価なモデルだけで達成した」とまでは言えませんし、役割分担だけがスコア差の原因だと証明されたわけでもありません。モデルの選択、コードの構造情報、検証環境、評価を通じた改善が組み合わさっています。

それでも、我々一般企業が学べる点は明確です。モデルの性能を上げることだけが、AIを仕事で役立てる方法ではありません。仕事の渡し方と、結果の確かめ方にも改善の余地があります。

ただし、ハーネスを作れば、先ほどのセーフガードの問題まで解消するわけではありません。Atlasが一般提供モデルの拒否や制限をどう扱っているか、その詳細は確認できていません。ここで学びたいのは、安全策の回避方法ではなく、利用条件の範囲内で仕事を分け、検証し、止まったときには人へ引き継げる設計です。

国内でも、サイバーエージェントが実践している

この考え方は、Wizだけのものではありません。

サイバーエージェントは、「脆弱性診断・脅威モデリングを行うセキュリティエージェントを実装しました」という記事で、社内向けのセキュリティエージェント「BUGMAP」を紹介しています。記事公開が5月なので、今はもっと進化しているかもしれません。

BUGMAPは、Webシステムの脆弱性診断と、設計レビュー・脅威モデリングを行う仕組みです。2026年2月頃から実際の診断・レビュー業務に導入され、4月には現場のエンジニアがセルフサービスで使えるツールとして社内公開されたと説明されています。

アーキテクチャを見ると、Atlasとの共通点がよく分かります。

  • セキュリティレビューを専用タスクに分割する。
  • 各タスクの出力を、次のタスクの判断材料として渡す。
  • レビュー観点ごとに専用エージェントを用意し、並列に動かす。
  • タスクに応じてモデルや推論の強さを使い分ける。
  • 最後に結果をレビュー・検証し、まとめる。

記事では、専用レビューエージェントが144個あると紹介されています。ただし、記事の説明は各タスクで複数の専用エージェントを起動する構成であり、144個は同時実行数を示す数値ではありません。記事自身も、数が多ければよいわけではなく、担当範囲を絞ることに意味があると説明しています。

また、AIに怪しい場所を挙げさせるだけではなく、PoCを生成したり、実際にAPIリクエストを送ったりして、攻撃が成立するかを確認します。記事では、ソースコードを材料にしたホワイトボックス診断と、外側から動作を試すブラックボックス診断の双方を行うと説明されている点も、参考になります。

実務上の結果として、記事では診断が約1〜2時間で完了すること、人手のレビューと並行して品質を確認したこと、誤検知が少なかったことが報告されています。GitHubのIssueやPR作成にもつながり、現場が問題を理解して修正するまでの使い勝手を整えています。

ここでの「実績」は、同社の社内運用で報告されたものです。誤検知率の具体的な数値や、Atlasと同じ条件でのCyberGymスコアは示されていません。それでも、専門家の知見を分解し、AIで繰り返し実行できる形にして、現場の業務へ組み込んだという事例として読み応えがあります。

共通するのは思想

Atlasは、反論役と判定役を設ける敵対的な検証を明示しています。BUGMAPは、大枠のワークフローをAWS Step Functionsで制御し、タスク内では親プロンプトが複数のSubagentを動かす構成です。レビュー・検証フローはありますが、Atlasと同じ三者構成とは説明されていません。

共通しているのは、一つの大きな依頼を、そのまま一つのAIに渡さないことです。仕事を分け、必要な情報を渡し、結果を検証し、その先の対応へつなげることです。

さらに、BUGMAPは、社内で広く導入されているRISKENやWizの検出結果を、脅威分析の証拠として利用すると説明されています。

既存製品が持つ環境情報に、自社のレビュー観点や業務フローを組み合わせる。そうした使い方もあるわけです。

企業が持っているのは、AIモデルだけではない

というわけで、「エージェントを144個作ろう」とはならないので。

まず整理したいのは、自社の専門家が普段どのように判断しているかです。何を最初に確認するのか。どの証拠があれば問題と判断するのか。逆に、どういう条件なら指摘を取り下げるのか。修正を誰に渡し、何をもって完了とするのか。

こうした知識は、モデルを契約しただけでは手に入りません。自社の人間が持っています。

AIに任せる工程を作るなら、少なくとも次の四つを決めたいところです。

  1. 担当範囲を決める。何を調べ、何は調べないのか。必要な情報と道具は何か。
  2. 完了条件をはっきりさせる。文章を出せばよいのか、再現できる証拠まで必要なのか。
  3. 検証方法を用意する。別の担当、テスト、人のレビューなどで、どう誤りを見つけるのか。
  4. 権限と引き継ぎを決めておく。モデルの利用条件と対象システムの許可を踏まえ、どこまで実行できるのか。拒否や中断が起きたら誰が確認し、どこから人が承認し、誰が修正を引き受けるのか。

セキュリティ分野では、能力と一緒に実行範囲も設計する必要があります。BUGMAPはサンドボックスに加え、許可する通信先や除外する操作を設定し、外向きの通信を専用プロキシ経由に制限しています。「安全に行動して」とAIにお願いするだけではなく、実行環境側でも制御している点が重要です。

もちろん、分業にはコストの問題もあります。呼び出す回数が増えれば時間や費用がかかりますし、工程間で情報が欠けたり、複数のAIが同じ誤りをしたりすることもあります。既存のやり方と同じ対象で比較し、確認できた問題、誤検知対応の手間、修正までの時間を見ながら改善する必要があります。

最強モデルを待つだけではなく、仕事の設計を始める

MythosやGPT-5.6-Cyberのようなモデルは、主要OSやブラウザーで多数の脆弱性を見つけるなど、脆弱性発見の規模を変えつつあります。しかし、一般企業がその利用権を持っているとは限りません。一般提供モデルを使えても、セーフガードで任せた仕事が止まることがあります。

Wiz Atlasの「Mythos Preview超え」と、サイバーエージェントのBUGMAPには、仕事の分け方と検証の仕組みを考えるための具体的なヒントがあります。

目的を作業へ分解する。各担当をAIに任せる。必要な情報と道具を渡す。答えを疑い、実行して確かめ、修正につなげる。

これは、モデルの強さが不要になるという話ではありません。強いモデルを、仕事の成果に変えるための設計です。

Atlasの顧客向け提供はこれからです。Wiz Codeへの組み込みが進められていますが、本記事は「MythosやGPT-5.6-Cyberが使えないなら、今すぐAtlasを買えば同じことができる」という提案ではありません。

企業が今から取り組めるのは、利用可能なモデルと許可される作業の範囲を確認し、自社の専門家の仕事を言語化して、小さく検証することです。拒否や中断も起こり得るものとして扱い、人の作業へ戻せるようにする。すべてを自作する必要も、いきなり完全自律にする必要もありません。

「どのモデルを使うか」の次に、「そのモデルに、どんな仕事を、どんな手順と責任範囲で任せるか」。1つの業務を細分化し、特定業務に特化したAIをそれぞれ作って、最終的な成果の完成度を高めるというアプローチが、AI業務組み込みの正攻法な気がしています。


参考情報・数値の扱い

本記事ではAtlasのスコアを7月27日の元記事に合わせて90.9%としています。7月30日の別のWiz公式記事には90.8%という表記もありますが、差の理由は確認できていません。異なる公表値を根拠なく統合せず、元記事への帰属を明示しています。

この記事をシェア