Microsoft MDASHとは？仕組み・実績・三強比較を徹底解説

Microsoft MDASH（multi-model agentic scanning harness）は、Microsoftが2026年5月に発表した、複数のAIモデルと100を超える専門エージェントを束ねてWindowsクラスの巨大コードベースから脆弱性を自動で見つけ出す新しいセキュリティ基盤です。
同月のPatch Tuesdayで修正された16件のCVE（うち4件はリモートコード実行のCritical）を発見した実績を持ち、公開ベンチマークCyberGymでもAnthropic MythosやOpenAI GPT-5.5を上回る88.45%で首位に立っています。

本記事では、2026年5月時点の公式情報をもとに、MDASHの5段階パイプラインの仕組み、ベンチマークと実際に潰したWindows脆弱性、Mythos / Daybreakとの三強比較、既存セキュリティ運用への接続、向き不向き、料金と提供条件、そして企業が今から取るべき準備までを一気に整理します。

Microsoft MDASHとは？

Microsoft MDASHは、Microsoftが2026年5月12日に発表した、AIエージェントを使ってソースコードから脆弱性（悪用可能なバグ）を自動的に発見・実証するエージェント型セキュリティシステムです。

コードネームの「MDASH」は multi-model agentic scanning harness の略で、「複数モデル × エージェント群 × 走査基盤」という設計思想がそのまま名前に出ています。

これまで脆弱性発見は、静的解析ツール、ファジング、人間のセキュリティリサーチャーの組み合わせで成り立ってきました。
MDASHはこの工程を「100以上の専門AIエージェントが協調して回す自律パイプライン」に置き換える試みであり、Microsoft Security Blogの公式発表記事でも「Defense at AI speed（AIのスピードで防御する）」というキャッチで紹介されています。

Microsoftが発表したMDASHの公式記事ビジュアル（出典：Microsoft Security Blog）

名称（MDASH）の意味

MDASHは略語で、それぞれの単語に役割が割り振られています。意味を分解しておくと、後段のアーキテクチャ理解がしやすくなります。

• Multi-model
  単一のフラッグシップモデル1本に依存せず、推論用のSOTA（最先端）モデル、検証用の蒸留型モデル、独立反証用の別系統SOTAモデルを使い分ける構成
  
  

• Agentic
  固定ロジックではなく、目的を与えられたエージェントが自律的に判断・行動する設計
  
  

• Scanning
  ソースコードを対象とした走査が主用途。バイナリ解析やネットワーク検知ではなく、コード起点
  
  

• Harness
  個別のエージェントを束ねて1つのパイプラインに統合する「枠組み」自体を指す
  
  

特に注目すべきは「Harness」という単語の選び方で、MDASHは特定のモデルや技術に固執した製品ではなく、モデル交代可能な基盤として設計されている点が公式の差別化ポイントとして強調されています。

開発チームと公開背景

MDASHを開発したのは、Microsoft内部の Autonomous Code Security（ACS）チーム と、Windowsの攻撃研究・防御を専門とする Windows Attack Research and Protection（WARP）チーム の合同部隊です。

さらにメンバーの一部は、DARPA AI Cyber Challenge（賞金約2,950万ドル）で優勝した「Team Atlanta」からMicrosoftへ合流した研究者で構成されています。

公開のタイミングも戦略的で、Microsoft Security Blogでの発表と同じ日に行われた2026年5月のPatch Tuesdayで、MDASH自身が発見した16件のWindows脆弱性が修正リリースされています。

「研究中のAI」ではなく「すでに製品リリースに組み込まれて動いているAI」として発表されたことが、この発表の重みになっています。

Microsoft Security Blogの冒頭部分（出典：Microsoft Security Blog）

MDASHの立ち位置（一言で）

社内ミーティングで一文で説明するなら、MDASHは「Microsoft自身がWindowsを守るために作った、AIエージェント型の脆弱性発見ハーネス」です。

Defender XDR・Microsoft Sentinel・Copilot for Securityといった既存のセキュリティ運用製品とは別レイヤーにあり、「人間のリサーチャーがやっていたコード監査をAIに自律的にやらせる」基盤層に位置しています。

---

エージェント型AIセキュリティの潮流

MDASHを単体で評価するより、2026年に同時並行で進んでいるAIセキュリティの三強競争の一角として読む方が、立ち位置と意味が見えてきます。

MDASHは「単発の発表」ではなく、防御側AIの主導権争いの一手として登場しています。

防御側AIが攻撃側を上回る局面

2025年から2026年にかけて、攻撃側のAI活用（フィッシング自動化・コード生成型マルウェア・自律侵入エージェント）に対抗する形で、「AIに脆弱性を先に見つけさせる」防御側ツールチェーンが急速に立ち上がってきました。

背景にあるのは、CVE登録件数が右肩上がりで、人間のセキュリティチームでは追いつかなくなっている現状です。

この潮流の中で2026年に登場したのが、Anthropic Mythos、OpenAI Daybreak、Microsoft MDASHの三つです。三社とも「単発のスキャナ」ではなく、「自律的に動き続けるエージェント基盤」として打ち出している点が共通しています。

三強の登場

ここで「三強」と呼んでいるのは、2026年時点でフロンティアレベル（Claude Opus / GPT-5.5 / Gemini 3.1 Proなど最先端帯のモデル）を背景に、エージェント型の脆弱性発見・修復に本格参入した三つのプレイヤーを指します。

• Anthropic Mythos
  Anthropicが先行発表したエージェント型の脆弱性発見モデル。発表当初は「発見だけでなく悪用までできてしまう」点が議論を呼びました。Microsoftも参加する Project Glasswing という招待制コンソーシアム経由で限定的に提供されています
  
  

• OpenAI Daybreak
  OpenAIがGPT-5.5＋Codexを軸に発表した、セキュアコードレビュー・脅威モデリング・パッチ検証・依存リスク分析を一括で扱うサイバーセキュリティ基盤。Mythosの招待制に対して 一般提供 を打ち出した点が差別化ポイント
  
  

• Microsoft MDASH
  ここまで見てきたMicrosoftの新基盤。マルチモデル＋100超エージェント構成と、Windowsという巨大実コードベースでの実証を武器に、CyberGymベンチマークで首位を取って参戦しました
  
  

つまり、Anthropicが「先発・限定」、OpenAIが「広く配る」、Microsoftが「自社製品で実証して攻める」 という三者三様の入り方になっています。

「AIで先に見つける」が前提の世界へ

GeekWireが報じた比較記事では、Microsoftの担当者が「単一モデルの賢さよりも、その周りのエージェントシステムこそが持続的な優位を生む」と説明しています。これはモデルが今後も入れ替わり続けることを前提にした発言で、競争の主戦場が「どのモデルを使うか」から「どんなエージェント基盤を組むか」に移ったことを示しています。

実務的に見ると、企業側にとっての論点は「どのAIを使うか」よりも、**「AIが発見してきた脆弱性を、どれだけ早く修正運用に乗せられるか」**の方が重い課題になります。発見側だけ高速化しても、パッチ運用が追いつかないと、検出件数が積み上がるだけです。

---

MDASHの仕組み：5段階パイプラインと100+エージェントの設計

MDASHのアーキテクチャは、ソースコードを入力にして「悪用可能なバグ＋実証PoC」を出力するまでを 5段階のパイプライン に分解した構造になっています。各段階で異なる役割のエージェントが動き、複数モデルがアンサンブルで結論を出します。

MDASHのPrepare、Scan、Validate/dedup、Prove、Patch generationの流れ（出典：Microsoft Security Blog）

以下の表で、5段階の役割と担当エージェントの種類をまとめました。この表だけで全体像は掴めますが、後段で各段階の中身を順番に詳しく見ていきます。

段階	役割	担当エージェントの性格	出力
1. Prepare	コード取り込み・脅威モデリング	解析エージェント	攻撃対象領域（Attack Surface）と脅威モデル
2. Scan	脆弱性候補の抽出	100超の専門監査エージェント	仮説と根拠付きの候補リスト
3. Validate	候補の到達性・悪用性の検証	議論（debater）エージェント	検証済みファインディング
4. Dedup	意味的同等な検出の統合	集約エージェント	重複排除済みの一意な検出
5. Prove	実行可能な入力で動的に再現	実証エージェント	PoC入力と再現ログ

この流れの面白いところは、Scan→Validate→Prove で「主張する側」「反論する側」「実証する側」が役割分離されている点です。同じモデルが自分の発見を自分で検証すると過信しがちですが、別エージェントが議論することで信頼性が上がります。実際、エージェント同士の不一致そのものを「ここは怪しい」というシグナルとして使う設計です。

1. Prepare（準備段階）

最初の段階では、対象のソースコードを取り込み、言語ごとのインデックスを構築したうえで、攻撃対象領域と脅威モデル を組み立てます。「どこから入力が入ってきて、どこを通り、どこに脅威が集中するか」をコード全体に対して整理する段階です。

ここで重要なのは、脅威モデルが事前に固定されていないことです。コードを読み込んだうえでエージェントが構成を判断するため、新しいプロジェクトやレガシーコードでも形を作れます。これは静的解析ツールが事前ルール依存だったのと対照的な設計です。

2. Scan（スキャン段階）

準備で作った地図に対して、100以上の専門監査エージェント が並行でコードを読み、脆弱性候補を出します。各エージェントは脆弱性クラスごとに専門化されており、たとえばUse-After-Free担当、整数オーバーフロー担当、認証バイパス担当、メモリ破壊担当などが別々に走るイメージです。

監査エージェントの出力は単なる検出結果ではなく、「仮説＋根拠コード片＋想定される入力経路」のセットになります。Validateで議論する素材を揃えるために、根拠のないアラートを出さない設計になっているのが特徴です。

3. Validate（検証段階）

ここで登場するのが debater（議論）エージェント です。Scanが出した候補に対して、debaterは「本当に到達可能か」「悪用可能か」を別の視点から検証します。Scanとは異なるモデルが担当することがあり、モデル間の主張のズレ自体が脆弱性のシグナルとして活用されます。

評論調になりがちなところを実務調で言い直すと、「自分が見つけたバグを別の優秀な同僚にレビューさせる」工程をAIで自動化している段階です。検証が通らなかった候補はここで落とされるので、後段に流れる件数が大幅に絞られます。

4. Dedup（重複排除段階）

100超のエージェントが並行で走るため、同じ脆弱性を別の角度から検出する重複が大量に発生します。Dedup段階では 意味的に同等な検出を統合 します。

単純な文字列マッチではなく、根本原因（root cause）が同一かをエージェントが判定するため、表面的には異なるコードパスでも「実は同じバグ」と認識して1件にまとめられます。これにより、後段のProveに流す件数を絞り、人間のトリアージ負荷を下げる効果があります。

5. Prove（実証段階）

最終段階では、実際にバグを発火させる入力を構築 します。仕様レベルでは脆弱と見えても、現実のコードパスでは到達できないケースが多くあるため、「PoC入力までセットで提示できるか」をハードルにしています。

Proveでは、入力生成エージェントがファジング的な探索を行い、再現ログを取得したうえで結果を返します。ここまで通った検出だけが「人間のエンジニアにレビューを依頼する」段階に進み、レビュー工数を抑える設計です。

マルチモデル＋エージェント分業の意図

MDASHにおける specialized agents と複数モデルによる検証の考え方（出典：Microsoft Security Blog）

MDASHは、ステージごとに モデルの種類を変えて使う設計 をしています。

具体的には、推論用のSOTAモデル、大量に走らせる検証用の蒸留型モデル、独立した反証用の別系統SOTAモデルを、目的に応じて配置します。この発想は、マルチAIエージェントの議論で出てくる「役割分担」と同じ流れに乗っています。

この設計が効くのは、コスト構造と信頼性のバランスです。Scan段階のように大量に走らせる箇所には高速・低コストのモデルを使い、Validate段階のように深く考えさせたい箇所にはフラッグシップを使う。結果として、フラッグシップ単体を全段階で走らせるよりも、安く・速く・信頼性高く回せます。

---

MDASHのベンチマーク実績と発見したWindows脆弱性

MDASHのベンチマーク実績をまとめた公式ビジュアル（出典：Microsoft Security Blog）

「設計が良い」だけでは評価できないのがセキュリティツールです。MDASHが発表時点で出している実績は、公開ベンチマーク・内部ベンチマーク・実コードベースでの発見、の3レイヤーに分かれます。

CyberGym 88.45%でリーダーボード首位

CyberGymリーダーボードでMDASHが1位に位置付けられている画面（出典：Microsoft Security Blog）

公開ベンチマーク CyberGym は、1,507件の実世界脆弱性再現タスクで構成された評価基盤で、AIシステムが「既知のバグをコードから再発見できるか」を測ります。Microsoftの公式発表によれば、MDASHはこのベンチマークで 88.45% を記録し、リーダーボードで首位（次点より約5ポイント差）に立ったとされています。

次点に位置するとされるのが、Anthropic Mythos相当のシステムと、OpenAIのGPT-5.5系の構成です。つまりMDASHは、現時点で公開数値が出ている脆弱性発見AIの中ではトップに置かれていると見られます。

内部ベンチマーク：21/21検出・96-100%リコール

公開ベンチマークに加えて、Microsoftは内部の検証結果も公開しています。社内で用意した検証用ドライバ（StorageDrive）では、21件の人工的に埋め込まれた脆弱性を21件すべて検出し、偽陽性ゼロ という結果が出ています。

さらに、Windows実コードベースに対しても過去5年のMSRC（Microsoft Security Response Center）案件で再発見テストが行われており、ファイルシステムログ系のclfs.sysで 96%リコール、TCP/IP系のtcpip.sysで 100%リコール という数値が示されています。「過去5年で人間が見つけた脆弱性のほとんどを、AIだけで再発見できる」ところまで来ているということです。

2026年5月Patch Tuesdayで修正された16件のCVE

Microsoft公式ブログに掲載された2026年5月Patch TuesdayのMDASH発見CVE一覧（出典：Microsoft Security Blog）

そして実コードベースでの最大の成果が、2026年5月のPatch Tuesdayで修正された 16件のWindows脆弱性 です。すべてMDASHが発見し、人間のリサーチャーが確認したうえでパッチに含められたとされています。

The Hacker Newsのまとめ記事などによれば、16件はWindowsのネットワーク・認証系コンポーネントに集中しており、内訳としては Critical 4件、Important 12件 という構成です。

Critical 4件のRCE詳細

Critical扱いされた4件は、いずれも認証不要のリモートコード実行に発展しうる重大なものです。以下の表で4件の特徴を整理しました。

CVE	対象	種別	想定リスク
CVE-2026-33824	ikeext.dll	IKEv2 SA_INIT の二重解放	リモートでの認証不要RCE
CVE-2026-33827	tcpip.sys	SSRR経由のUse-After-Free	リモートでの認証不要RCE
CVE-2026-41089	netlogon.dll	CLDAP応答処理のバッファオーバーフロー	リモートでの認証不要RCE
CVE-2026-41096	dnsapi.dll	DNS応答処理のヒープOOB	リモートでの認証不要RCE

この表が示しているのは、いずれもネットワークプロトコルスタックの深部に潜む種類の不具合で、人間のレビューでは見落としやすい類のものだという点です。MDASHは「分かりやすいコードの綻び」ではなく「複数ファイルにまたがる呼び出しの整合性ズレ」のような検出に強いことを、実装で示している格好になります。

---

【詳細比較】MDASH vs Anthropic Mythos vs OpenAI Daybreak

ここまでがMDASH単体の話で、ここから三強の比較に入ります。三つはどれもエージェント型の脆弱性発見・修復を扱いますが、設計思想と提供形態が大きく違います。

三強の比較表

まず全体像を1枚にまとめます。比較軸はアーキテクチャ・提供形態・ベンチマーク・想定ユーザー・差別化ポイントの5つです。

項目	Microsoft MDASH	Anthropic Mythos	OpenAI Daybreak
アーキテクチャ	マルチモデル＋100超エージェント	単一モデル＋エージェントフレーム	GPT-5.5＋Codex統合プラットフォーム
主用途	コードスキャンによる脆弱性発見・実証	脆弱性発見・悪用検証	コードレビュー・脅威モデリング・パッチ検証・依存リスク・修復支援
提供形態	限定private preview→2026年6月企業向け拡大	招待制（Project Glasswingコンソーシアム経由）	一般提供（広く配る方針）
ベンチマーク（CyberGym）	88.45%（首位）	MDASHに次ぐ位置	GPT-5.5構成でMDASHに次ぐ
想定ユーザー	自社コードベースを持つ大規模組織・OSベンダ	限定パートナーのみ（先行検証層）	広く一般企業・SaaS事業者
強み	大規模コード×マルチエージェント	単一モデルで完結する手軽さ	既存ChatGPT/Codex資産との統合

この表から読み解けるのは、Microsoftは「アーキテクチャの厚み」、Anthropicは「先手の確保」、OpenAIは「広さ」 で勝負しているという構図です。同じ「AIで脆弱性を見つける」というカテゴリでも、戦略の起点が異なっています。

アーキテクチャの違い

最大の差は、MDASHが マルチモデル＋エージェント分業 なのに対し、Mythosが単一モデルベース、Daybreakがプラットフォーム統合型である点です。MDASHは「異なる役割のエージェントが議論する」構造で信頼性を担保しているのに対し、Mythosは1モデルの賢さに依存します。Daybreakはコードレビューから依存リスクまでカバー範囲が広い分、深掘りより横展開の発想です。

実務的には、深い脆弱性ハンティングはMDASH、CI連動の継続的レビューはDaybreak、限られた先行検証はMythos と読み分けられます。

提供形態の違い

提供モデルも対照的です。AnthropicのMythosは Project Glasswing という招待制コンソーシアム（参加企業にはMicrosoftも含まれる）経由で限定的に提供されており、一般企業が今日から使うことはできません。これに対しOpenAIのDaybreakは CSO Onlineの解説 などによれば、より広いユーザーが利用できるオープンな提供方針です。

Microsoft MDASHはこの中間で、2026年5月時点では限定パートナー向けprivate preview、同年6月から企業向けに拡大 という段階提供を取っています。

ベンチマークでの位置づけ

CyberGymで首位を取ったのはMDASHですが、ベンチマークの解釈には注意が必要です。CyberGymは既知のCVEを再発見できるかを測るタスク群で、未知の脆弱性の発見力そのものを直接測るわけではありません。それでも、5年分の実MSRC案件で90%超のリコールを叩き出している事実と合わせると、MDASHの実戦投入レベルは高いと言えます。

想定ユーザーと使い分け

3つの使い分けの軸は「自社にどのくらいの規模のコードベースがあるか」と「いつ・どの形で組み込みたいか」です。

• 巨大な自社コードベース×OSベンダ規模
  MDASHが第一候補。Windows相当の規模で実証されているのは現状MDASHのみ
  
  

• 既存のCI/CDに脆弱性レビューを組み込みたいSaaS事業者
  Daybreakが現実的。Codex統合で広い範囲をカバーできる
  
  

• コンソーシアム経由で最先端を試したい先行検証層
  Mythosが選択肢。ただしアクセス制限が強い
  
  

つまりMDASHは「巨大コードベースでの深い掘り下げ」に最適化された一方、Daybreakは「広く浅く全社カバー」を狙う構造です。同じカテゴリの製品でも、SIerとして提案する場面は明確に分かれます。

---

MDASHが既存セキュリティ運用とどう接続するか

ここがニュース記事ではほぼ触れられていない実務論点です。MDASHは脆弱性発見だけを担う基盤層で、それ単体で完結する製品ではありません。

実際に企業で価値を出すには、既存のセキュリティ運用と接続する設計が必要です。

Defender for Cloud（CNAPP）との関係

Microsoftには既に Microsoft Defender for Cloud というクラウドネイティブアプリケーション保護プラットフォーム（CNAPP）があり、マルチクラウド環境の構成・ランタイム・コードまでを横断で守る基盤として展開されています。

2026年5月時点で、MDASHとDefender for Cloudの正式な統合は公式に発表されていません。ただし役割分担で見ると、MDASHが「コードレベルでの脆弱性発見」、Defender for Cloudが「クラウドリソース構成・ランタイムの保護」 という形で機能が補完関係にあります。

中長期的には、MDASHが見つけた脆弱性をDefenderのワークフローに連動させる流れは自然な進化方向と見られます。

Sentinel（SIEM/SOAR）との連携可能性

セキュリティ運用全体を見ると、Microsoft Sentinelが SIEM/SOAR として中心に置かれます。

Microsoft Learnの公式ガイドによれば、Sentinelは2027年3月31日以降、Defender ポータルに統合される予定 で、SOCの単一ペイン化が進められています。

この流れの中で、MDASHが発見した脆弱性をSentinelのインシデントに自動連動させる経路は、十分にあり得るシナリオです。

現時点では公式に統合は発表されていませんが、運用設計を考える企業はこの接続点を見越して、「MDASHが発見→Sentinelでインシデント化→SOCがトリアージ→修正パッチに乗せる」というループを想定しておく方が現実的でしょう。

SOC運用フローへの組み込み

実務での組み込み方は、以下のような段階的展開が現実的です。

• 第1段階
  MDASHを限定的なリポジトリ（基幹コードのうち外部公開部分など）に適用し、検出件数と人間のトリアージ負荷を計測する
  
  

• 第2段階
  検出結果のフォーマットを既存のチケット管理（Azure DevOps、Jira等）に流し込み、修正フローに乗せる
  
  

• 第3段階
  Sentinelのインシデントとして取り込み、SOC側で対応SLAを管理する
  
  

• 第4段階
  パッチリリースまでの所要時間（time-to-patch）を継続計測し、SLAを段階的に短縮する
  
  

各段階で詰まりやすいのは「検出件数が想定より多くてトリアージが回らない」というポイントです。AIが先に大量検出してくる前提に、人間側のレビュー枠が追いついていないと、検出結果が積み上がるだけで対応が回りません。導入の最初の数週間で件数の見通しを立てることが、後段の運用安定化に直結します。

---

MDASHが向いている場面 vs 向かない場面

ここまで読むと「強力に見える」MDASHですが、すべての組織で価値が出る製品ではありません。向き不向きを最初に整理しておく方が、無理な導入で疲弊するリスクを避けられます。

向いている場面

以下のような条件を持つ組織では、MDASHの効果が出やすい状況です。

• 自社で大規模なコードベースを抱えている
  ライブラリ・OS・基幹システムなど、コード行数が数百万〜数千万行規模で、人間のレビューだけでは到底回らない組織
  
  

• 既にセキュリティチームと修正運用が動いている
  発見だけ増えても、SOCとパッチ運用が機能していなければ詰まる。MDASHは「発見側を高速化する」基盤
  
  

• 金融・医療・公共などコンプライアンス要件が重い領域
  脆弱性を1件残すコストが高く、発見と修正のループが事業継続に直結する業界
  
  

• マルチクラウド・複雑な依存関係を持つ製品スタック
  複数ファイル・複数モジュールを跨いだ脆弱性の発見はMDASHの得意領域
  
  

向かない場面

逆に、以下のような状況では別の選択肢の方が合います。

• コードベースが小さく、人間レビューで十分回せる
  スタートアップや小規模SaaSなど、コード行数が限定的で既存ツールで足りている
  
  

• セキュリティチームや修正パイプラインがまだ未整備
  発見側だけ強化しても、修正運用がボトルネックになる。先に運用を整える方が効果が大きい
  
  

• CI/CDに継続的なコードレビューを組み込みたい用途
  深い掘り下げよりも広い継続レビューが目的なら、OpenAI Daybreak系の方が現実的
  
  

• MDASHのprivate previewに対象として参加できない組織規模
  2026年6月時点でアクセス自体が限定される可能性があり、現段階で組み込みを前提にできない
  
  

SIerとしての導入判断軸

支援経験から実務的な使い分けを言うと、判断軸はおおむね3つに集約されます。

1つめは コードベース規模。100万行超を抱えるなら検討に値しますが、それ未満なら投資対効果が薄くなりがちです。
2つめは 修正パイプラインの成熟度。発見側だけ強化しても運用が伴わない状態で導入すると、「検出は出るが修正は溜まる」というアンチパターンに陥ります。3つめは コンプライアンス要件の強度。要件が重ければ、検出取りこぼしの機会損失コストが高くなり、MDASHの投資は回収しやすくなります。

中堅以下のSaaS事業者で、コードベース規模が限定的なら、まずはDaybreakのようなCI連動型のツールで継続レビュー体制を作り、コードベースが膨らんできた段階でMDASHを検討するのが現実的な順序です。

開発側にAIを入れる流れは、GitHub Copilotのセキュリティで整理した観点と地続きで考えるとブレません。

---

企業がMDASHから今得るべき示唆

MDASHが完成形ではなく「これから配られていく基盤」である現状で、企業側が今すぐ取れるアクションは「使う準備」よりも「受け入れる前提を整える」方が中心になります。

AIが先に見つけてくる前提への移行

セキュリティ運用に毎日30分以上の手動チェックをかけているなら、それはAIスキャンで上書きされる可能性が高い領域です。MDASHや競合の本格普及にあと半年〜1年の時間軸を見るなら、その期間で 「AI発見前提の運用」 に切り替える準備期間が確保できます。

具体的には、次のような問いに自社で答えを持っているかが、準備度合いを測る指標になります。

• 自社のコードベースで、外部スキャンに乗せていい範囲とNGの範囲を切り分けてあるか
• 検出件数が現状の3倍に増えたとき、トリアージできる人員枠は確保できるか
• パッチリリースまでの平均所要時間を、自社で正確に計測できているか
• セキュリティ脆弱性のチケット管理が、開発側のチケットと統合されているか

この4つに即答できない場合、「AI発見」より先に「運用整備」のフェーズに投資した方が、最終的な効果は大きくなります。

エンタープライズ環境でのAI運用設計の考え方は、Claude for Enterprise でまとめた枠組みも参考になります。

自社で今からできる準備

private previewの対象に入れるかは別として、今日からできる準備は限定的ですが確実なものがあります。

• コードベースの棚卸し
  どのリポジトリ・どのコンポーネントが外部公開向けで、どこに脆弱性があると致命的かをマッピングする
  
  

• time-to-patchの現状計測
  脆弱性発見から修正リリースまでの実所要時間を、現在の運用で計測する。MDASH導入後の改善幅を測る基準値になる
  
  

• SOC・開発・QAの連携プロセスの確認
  発見→トリアージ→修正→検証→リリースの各段階で、担当と引き継ぎ手順が明確になっているかを点検する
  
  

• セキュリティチケットの優先度ルール明文化
  AI発見が大量に流れ込んだとき、自動的にトリアージ優先度をつけられるルールが必要になる
  
  

段階的な取り込みステップ

MDASHが正式に企業向けに提供開始されたあとを想定すると、現実的な取り込み順は次の3段階です。

1. パイロット
   限定リポジトリで導入し、検出件数と質を計測する。3〜6ヶ月程度で運用負荷の見通しを立てる
   
   

2. 段階展開
   パイロットで運用に組み込めた範囲を、より広いリポジトリ・チームに拡大する。SOC・チケット運用との接続を整える
   
   

3. 本格運用
   全社のコードベースに対して継続的にスキャンを回し、time-to-patchのSLAを管理する
   
   

「いきなり全社展開」ではなく、まず1リポジトリ・1チームから始めるのがセオリーです。検出件数の見立てができないまま全社で動かすと、トリアージが破綻します。

---

MDASHの料金と提供条件（2026年5月時点）

MDASHの料金と提供条件は、2026年5月14日時点ではまだ正式公開されていません。把握できる事実だけを整理します。

提供形態の現状

MDASHのlimited private previewへの案内（出典：Microsoft Security Blog）

Microsoft Security Blogの発表記事によれば、2026年5月時点では以下の状況です。

• 限定パートナー向けの private preview が稼働中
• Microsoft内部の Windows エンジニアリングチームでは既に常用
• 2026年6月から企業向けに private preview の対象を拡大

つまり、いま外部から触れるのは「ごく一部の事前選定パートナーのみ」で、6月以降に申し込みベースで対象範囲が広がる予定という段階です。

MDASHのpreview sign-upフォームのヘッダー（出典：Microsoft Forms）

料金体系

2026年5月14日時点で、MDASHの料金体系はMicrosoftから公式に提示されていません。SaaS型の従量課金（スキャン対象のコード行数や検出件数に応じた価格）か、Azure系のクレジットに統合される形か、いずれの構成も発表段階では明示されていません。

価格情報が公開されるタイミングは、6月のprivate preview拡大に合わせて行われる可能性が高いと見られます。導入予算を組む段階の企業は、6月の発表を待つ前提でスケジュールを引いておく方が安全です。

想定される利用要件

公式の利用要件はまだ提示されていませんが、private previewの性格と既存のMicrosoftセキュリティ製品の慣例から、以下のような前提条件が想定されます。

• 一定規模以上のエンタープライズ契約（Microsoft Enterprise Agreement等）保有
• スキャン対象コードベースをMicrosoft側に開示することへの同意
• 検出結果のフィードバック提供への同意（ベータ的性格）
• セキュリティチームとの直接連絡経路の確立

これらはあくまで一般的なprivate previewの慣例から想定される条件で、6月の正式アナウンスで具体的な利用要件が示される見込みです。

導入を検討する企業は、サインアップページの公開を待ち、自社の契約状態と要件のすり合わせを準備しておくことをおすすめします。

---

エージェント型セキュリティを業務AIの一部として捉える

MDASHのようなエージェント型セキュリティ基盤は、単独の製品として導入するというより、業務全体のAI化の一部として位置づける方が成果につながります。

脆弱性発見だけ自動化しても、その先のトリアージ・修正・運用が手動のままだと、ボトルネックが移動するだけだからです。

AI総合研究所では、AI Agent Hubを通じて、業務全体をエージェントで統合する設計と運用ノウハウを提供しています。
セキュリティ運用に限らず、開発・営業・カスタマーサポート・社内ナレッジまでをエージェントで横断する構成を、自社の状況に合わせて構築できます。

「自社にMDASHのようなAI基盤を取り込みたいが、何から始めればいいかわからない」段階であれば、まずは業務全体のAIエージェント化の青写真から逆算するのが現実的です。

詳細は資料でまとめていますので、ぜひご覧ください。

---

まとめ

Microsoft MDASHは、100超のAIエージェントを5段階パイプラインで動かす マルチモデル型の脆弱性発見ハーネス です。CyberGym 88.45%首位、内部ベンチマーク96-100%リコール、2026年5月Patch Tuesdayで16件のCVE発見という実績を持ち、Anthropic Mythos / OpenAI Daybreakと並ぶエージェント型AIセキュリティの三強の一角に位置づけられます。

選定上の判断軸は3つに集約できます。

• 巨大コードベースを抱える組織
  ならMDASHが第一候補。Windows規模での実証は競合にない強み
  
  

• 既にセキュリティ運用が回っている組織
  が前提条件。発見だけ高速化しても、修正運用が伴わないと詰まる
  
  

• 2026年6月のprivate preview拡大が事実上の入り口
  それまでに自社のコードベース棚卸し・time-to-patch計測・SOC連携プロセス確認を済ませておくのが現実的な準備
  
  

「AIが先に脆弱性を見つけてくる」が当たり前になる時代に、企業側に必要なのはモデル選びより運用側の整備です。MDASHや競合の本格普及にあと半年〜1年の時間軸を見て、その期間に運用フローを再設計する企業ほど、AI発見前提のセキュリティ運用に滑らかに移行できます。

次のステップとしては、自社のセキュリティ運用が「AI発見前提」に耐えうるかを点検することから始めてみてください。