この記事のポイント
MAI-Cyber-1.1-Flashは1 Flashの改良版で、MDASHのスキャン単価を約18%下げた更新。モデル単体で呼び出せる製品ではない
cyber refusalを減らす「permissive設計」への切替が最大の変更点で、vulnerability discovery・red teaming・pen testingまで対応範囲が拡張
1 Flashと同じ137B/5B・256kコンテキストはORA Model Cardで維持公開、外部ベンチマークは10指標以上に拡充
提供はAzure AI Foundry Private Preview経由のMDASH限定で、1 Flashと同じverified customer向け審査プロセスを継承
既存1 Flash利用者はカバレッジ固定の実測で切替効果を測るべきで、スキャン単価だけの比較は意味を持たない

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
MAI-Cyber-1.1-Flash(MAIサイバー1.1フラッシュ)は、Microsoftが2026年10月27日に発表したMAI-Cyber-1-Flashの改良版です。
Microsoftの脆弱性スキャンハーネスMDASH内で、1 Flashと同等の検出性能を保ちつつスキャン単価を約18%下げ、cyber refusalを減らす「permissive設計」へ思想を更新したと公表されました。
本記事では、1 Flashから1.1 Flashへの変更点、ORA Model Cardで公開された外部ベンチマーク10指標、MDASH内での利用条件、Gemini 3.8 Flash Cyber・GPT-5.6-Cyber・Claude Mythosとの位置づけ、既存MDASH利用者が切替を判断するための測定ステップまでを、2026年10月時点の最新情報で整理します。
目次
MAI-Cyber-1.1-Flashとは?2026年10月に発表されたMicrosoft製サイバーAIの改良版
cyber permissive設計への切替——「refusalを減らす」が最大の変化
MAI-Cyber-1.1 FlashのORA Model Cardで公開された外部ベンチマーク10指標
提供は「verified customer」向けのMDASH限定
既存MDASH利用者が1.1に切り替えるときの6つの検証ステップ
MAI-Cyber-1.1-Flashとは?2026年10月に発表されたMicrosoft製サイバーAIの改良版

MAI-Cyber-1.1-Flashは、Microsoft AIが2026年10月27日に公表した、サイバーセキュリティ特化モデルMAI-Cyber-1-Flashの後継バージョンです。
Microsoftはこの更新を「sharper findings and fewer tokens inside MDASH(MDASHでより鋭い発見を、より少ないトークンで)」と位置づけ、1 Flashと同等の脆弱性検出性能を維持したまま、スキャン単価を約18%下げたと公式ブログで説明しています。
ポイントは、1.1 Flashは単体で呼び出せる汎用モデルではなく、Microsoftの脆弱性スキャンハーネス「MDASH」の中でだけ動く、という点です。1 Flashと同じアーキテクチャ・パラメータ・コンテキスト長はORA Model Cardで引き続き公開されており、外部ベンチマーク結果はむしろ10指標以上に拡充されました(詳細は後述の「外部ベンチマーク結果」セクションで扱います)。
MAI-Cyberシリーズの中での位置づけ

MAI-Cyberシリーズは、Microsoftが2026年7月に発表した同社初のサイバーセキュリティ特化AIモデルとして始まりました。
1.1 Flashはそこから3か月後の改良版で、位置づけは「同じ検出能力を、より少ない計算リソースで出す」ことに絞られています。
-
MAI-Cyber-1-Flash(2026年7月27日)
Microsoft初のサイバー特化モデル。137B総パラメータ/5B活性のSparse MoE、256kコンテキスト。Model Cardで外部ベンチマーク5指標(CyberGym・CVEBench・CyberSecEval4・CRSBench・ExploitGym)を開示し、「security-first calibration」で慎重な稼働姿勢を取る。
codex -
MAI-Cyber-1.1-Flash(2026年10月27日)
1 Flashのfine-tune型後継。アーキテクチャ・パラメータは踏襲し、ORA Model Cardで外部ベンチマーク10指標以上に拡充公開。「cyber permissive model」として設計され、refusalを減らしてvulnerability discovery・red teaming・pen testingまでカバー範囲を広げた。
MAI-Cyberモデルは、どちらもMicrosoftの脆弱性スキャンハーネスMDASH(Multi-model agentic scanning harness)に組み込まれており、個別のAPIエンドポイントとしては提供されません。
1 Flashから1.1 Flashへの変更点

Microsoftが2026年10月27日の発表で示した差分は、数値としては「スキャン単価18%削減」と「後続スキャン継続率9/10」の2点が目立ちますが、より重要な設計変更としてORA Model Cardで「cyber permissive model」への切替が明記されています。
本セクションでは、公表された差分の中身と、1 Flashの「security-first calibration」からの思想変更を整理します。
公式が示した3つの数値

Microsoftが公式ブログで示した定量情報は、以下の3点に集約されます。
| 指標 | 数値 | 測定スコープ |
|---|---|---|
| スキャン単価 | 1 Flash比 約18%削減 | 内部MDASH脆弱性スキャン評価スイート |
| 全MDASHスキャンにおけるMAI Cyberプロファイルのシェア | 約50% | 数百顧客・数千スキャン実績 |
| 初回MAI Cyberプロファイル採用後の後続スキャン継続率 | 約9/10(nearly 9 in 10 subsequent scans) | 顧客単位の追跡データ |
注目すべきは、スキャン単価の比較が「内部評価スイート」上の数値である点です。
1 Flashのときに公表されていた「MDASH全体でCyberGym 95.95%」のようなハーネス統合込みのスコアは、1.1 Flashでは発表ブログ段階では紐付けられていません。
モデル単体の数値はORA Model Cardで公開されています(詳細は後述の「外部ベンチマーク結果」セクション)。
cyber permissive設計への切替——「refusalを減らす」が最大の変化

1.1 Flashの最大の設計変更は、1 Flash時代の「security-first calibration(慎重な稼働姿勢)」から「cyber permissive model」への切替です。
ORA Model Card §2.8 は、この更新を「trained to reduce cyber refusals to support a broader set of Microsoft Security product needs(Microsoft Securityの製品ニーズを広く支えるため、cyber refusalを減らすよう学習された)」と明記しています。
1 Flashは、サイバー能力が持つdual-use(防御にも攻撃にも使える)性質を踏まえ、曖昧なリクエストに対しては過剰に拒否する姿勢で始まりました。1.1 Flashは、この拒否頻度を下げる方向で再調整され、vulnerability discovery・red teaming・pen testingまで実務用途が広がっています。
この設計変更とスキャン単価18%削減の関係は、公式発表の説明の範囲内では明示されていません。Microsoftは1.1 Flashを「a more focused model that takes on more of the work itself(モデル自身がより多くの仕事をこなす、より焦点を絞ったモデル)」と表現しているため、以前のMDASH設計(90/10ルーティング:全タスクの最大90%をMAI-Cyber-1-Flashが担当し、閾値を超える10%をOpenAI GPT-5.4にエスカレーション)で発生していたエスカレーション分が減った可能性は推測できますが、公表ベースでは因果の確定はできません。
顧客採用率が示す運用面での定着

一方で、顧客採用率に関する数値は実運用の手応えを示唆しています。
Microsoftによれば、顧客が1 Flashを初めてMAI Cyberプロファイルで利用した後、同じ顧客の後続スキャンのうち約9/10がOpenAI-onlyではなくMAIプロファイルで実行されています。
MDASH全体のスキャン実行の約50%がMAI Cyberプロファイル側に移っているという数字もあわせて公表されました(どちらも1 Flashが運用に乗っていた期間の実績値で、1.1 Flashの継続率はまだ公表されていません)。
この継続率はあくまで1 Flashを初回利用した顧客群の後続スキャン傾向で、1.1 Flashの継続実績や、OpenAI-onlyプロファイル継続率のベースライン・測定ウィンドウは公表されていません。1.1 Flash自体の実運用データが積み上がるのを待つ必要があります。
MAI-Cyber-1.1 FlashのORA Model Cardで公開された外部ベンチマーク10指標

1 Flash時点でも5指標の外部ベンチマークが開示されていましたが、1.1 FlashはORA Model Cardで10指標以上に拡充し、cyber permissive設計で広がった対応範囲を定量的に示しています。
本セクションでは、1.1 Flashの単体性能データと、1 Flashからの開示拡充点を整理します。
1 Flashと1.1 Flashの公開情報比較

Microsoft AI公式Model Card(1 Flash用)と、1.1 Flash向けのORA Model Cardを並べると、継承された項目と拡充された項目が明確になります。
| 項目 | MAI-Cyber-1-Flash(2026年7月) | MAI-Cyber-1.1-Flash(2026年10月) |
|---|---|---|
| 総パラメータ数 | 137B | 137B(継承) |
| 活性パラメータ数 | 5B | 5B(継承) |
| コンテキスト長 | 256k | 256k(継承) |
| アーキテクチャ | sparse MoE | sparse MoE(継承) |
| 派生元 | MAI-Code-1-Flashのfine-tune | MAI-Cyber-1-Flashのfine-tune(MAI-Code-1-Flashの孫) |
| アライメント方針 | security-first calibration(慎重姿勢) | cyber permissive model(refusal削減) |
| 外部ベンチマーク指標数 | 5指標 | 10指標以上に拡充 |
| 対応言語 | 英語+EU主要言語+MAI-Code-1-Flash継承 | 同(継承) |
この比較から見えてくるのは、Microsoftがアーキテクチャ・パラメータ・コンテキスト長はそのまま踏襲し、cyber permissive設計への切替と、それを第三者検証可能にするベンチマーク拡充を同時に実施したという点です。

MAI-Cyber-1.1-Flash ORA Model CardのModel summary(出典:Microsoft AI Model Card)
Model summaryには、Developerとして「Microsoft Ireland Operations Limited(MIOL)」、Model architectureとして「transformer with self-attention and sparse Mixture-of-Experts(MoE)layers」、Model dependenciesとして「fine-tuned version of the MAI-Cyber-1-Flash model」が明示されています。
Descriptionには「cyber permissive model that has been designed to deepen cybersecurity capability to support vulnerability discovery, red teaming, and pen testing」と、1 Flashの「security-first calibration」から踏み込んだ設計意図が記載されています。
SmartScopeの検証ブログが1 Flashのスコア(95.95%)の文脈をCyberGym公式リーダーボードと突き合わせて検証していたのと同じように、1.1 Flashについても外部研究者がORA Model Cardの数値を独立検証できる足場が引き続き整っています。
1.1 Flashで新たに公表された外部ベンチマーク結果

ORA Model Card §3「Quality and performance evaluation」に掲載された、1.1 Flash単体の外部ベンチマーク結果は以下のとおりです。1 Flashと同じ軽量ターミナルハーネスで測定された、ハーネス非統合時の性能値になります。
| カテゴリ | ベンチマーク | MAI-Cyber-1.1-Flash |
|---|---|---|
| Headline capability | CyberGym-E2E | S3 = 41.68% |
| Headline capability | WebExploitBench | 23.0% |
| Exploitation | CyberGym target-crash | 71.70% |
| Exploitation | ExploitGym | 0/862 |
| Vulnerability exploitation | CVEBench | Medium = 0.371 / High = 0.400 |
| Threat intelligence/malware | CyberSecEval4 | Threat Intelligence (Low) = 0.575 / Malware Analysis (Low) = 0.314 |
| Cyber reasoning | CRSBench | Minimum = 0.500 / Low = 0.570 / Medium = 0.610 / High = 0.590 |
| Threat intelligence | CTI-Realm | Minimum = 0.530 / Low = 0.556 / Medium = 0.580 / High = 0.610 |
| Cybersecurity analysis | SecBench Pro – IntuneExplorer | High = 0.854 |
| Cyber threat intelligence | ExCyTIn | Minimum = 0.800 / Low = 0.870 / Medium = 0.880 / High = 0.890 |

MAI-Cyber-1.1-FlashのORA Model Card外部ベンチマーク結果(出典:Microsoft AI Model Card)
この結果から分かるのは、1.1 Flashが単なるコスト最適化ではなく、CyberGym-E2EやWebExploitBench等のheadline capability領域でも実測数値を公開しているという点です。
脅威インテリジェンス・マルウェア分析(CyberSecEval4)やサイバーリーズニング(CRSBench)は1 FlashのModel Cardでも評価されていたため1.1固有の新機能ではありませんが、SecBench Pro – IntuneExplorer・CyberGym target-crash・WebExploitBench・CTI-Realm・ExCyTInのように1 FlashのModel Cardに含まれていなかった評価項目がORA Model Cardで追加公表された点が、指標拡充の中身になります。
CTI-RealmとExCyTInでそれぞれHighレベル0.610・0.890という高スコアが出ていることも、permissive設計で扱える評価範囲が広がっているサインとして読めます。
ExploitGymのスコアは0/862でした。拒否方針との因果関係は公式で明示されていないため、能力の制約・評価方法・ランタイム要件のいずれが要因かはこの結果だけからは判断できず、以降の運用判断では別のベンチマークや自社tail setを合わせて見る必要があります。
MAI-Cyber-1.1 Flashの利用条件と課金

1.1 Flashのアクセス経路と課金の枠組みは1 Flash時点から継承されており、提供はMDASH経由のverified customer向けに限定されます。
1 Flash時点でも顧客審査・追加承認プロセスが設けられていたため、1.1 Flash特有の審査強化は公表範囲では確認できません。ここでは、公式に公表されている範囲での提供形態と、課金の読み解きを整理します。
提供は「verified customer」向けのMDASH限定

Microsoftは1.1 Flashの提供範囲について、「available through MDASH to verified customers, with safeguards in place to support responsible use(verified customer向けにMDASH経由で提供、責任ある利用のためのセーフガード付き)」と公式に明示しています。
ORA Model Card §2.8では「the model is only being made available within codename MDASH to select verified customers(モデルは選定済みのverified customer向けにMDASH内でのみ提供)」と、アクセス範囲が明示されています。
- 提供チャネル
Azure AI Foundry Private Preview経由。1.1 Flash単体のAPIエンドポイントは存在せず、MDASH内でのみ呼び出される
- アクセス方法
新規利用希望者は、Microsoftの申請フォーム経由でMDASHへのアクセス権を申請。審査通過後に有効化
- モデル配備
MDASHセットアップ手順に従い、既存3モデルに加えてMAI-Cyber-1.1-FlashをAzure AI Foundry側で配備する作業が必要
- 用途制限
Model Card記載の「defensive security operations within Microsoft MDASH」の範囲外は利用不可。MDASH外での利用試行はアラートが上がり、未修正ならアクセス剥奪対象になる旨がORA Model Cardに追記されている
この構造が意味するのは、モデル単体を他のハーネス(独自の脆弱性スキャナやCI/CDパイプライン)に組み込むことはできない、という点です。
MAI-Cyber-1.1-Flashを使うには、脆弱性管理フローごとMDASH側に合わせる必要があります。既存のSAST(静的解析)/DAST(動的解析)/SCA(ソフトウェア構成分析)製品を使い続けながら、モデルだけ差し替える構成は現時点では成立しません。
MDASH内での課金方式

MDASH自体の課金は、Azureの従量課金として組み込まれており、スキャン時のモデル呼び出しによるトークン消費で発生します。
1.1 Flash単体の価格は公表されていませんが、Microsoft内部のMDASH脆弱性スキャン評価スイートで測定したスキャン単価が1 Flash比18%削減された、と公表されています。顧客請求額が一律で18%下がる保証ではなく、実際の削減幅はスキャン対象のコードベースや呼び出しプロファイルに依存します。
サイバー特化AIモデルは、Gemini 3.8 Flash Cyber(Fairwind Program)のようにプログラム審査通過組織へ提供されるケースと、GPT-5.6-Cyberのように公開単価付きで承認後のAPI利用を認めるケースがあり、提供スタイルはベンダーごとに分かれています。
1.1 FlashはMDASH内に閉じた課金のため、既存のMDASH契約の中でモデルプロファイルを切り替える判断が中心になります。
Microsoft Securityスタックへの統合計画

MAI-Cyberモデルは、長期的にはMDASH単独ではなくMicrosoftのセキュリティ製品群全体に展開される方針が示されています。
1 Flash時点では、Project Perceptionという上位プラットフォームに組み込まれる形で、Red/Blue/Greenの3色AIエージェントの中核モデルとして位置づけられていました。
1.1 Flashへの切替は、まずMDASHで検証されたうえで、Microsoft Defender XDR等の既存セキュリティ製品に順次反映される流れが想定されます。
ただし1.1 Flashの発表ブログでは、他Microsoft Security製品への統合時期の具体は明示されておらず、現時点では「MDASH内で先行検証中」の位置づけです。
他のサイバー特化AIとの位置づけ

2026年7月以降、Google・OpenAI・Anthropicからもサイバーセキュリティ特化モデルが相次いで登場しており、MAI-Cyber-1.1-Flashはこの競合群の中で位置づけを理解する必要があります。
ここでは、2026年10月時点で確認できる主要4モデルを、提供形態・公開透明性・単体性能評価の3軸で整理します。
4モデルの提供形態と透明性比較

以下の表で、2026年10月時点で公開されている主要サイバー特化AIを並べました。
| モデル | ベンダー | 提供形態 | 公開ベンチマーク | モデル単体API | 発表時期 |
|---|---|---|---|---|---|
| MAI-Cyber-1.1-Flash | Microsoft | MDASH内のみ・verified customer申請 | モデル単体CyberGym-E2E 41.68% / WebExploitBench 23.0% / CyberGym target-crash 71.70%等10指標(ORA Model Card) | なし | 2026年10月27日 |
| Gemini 3.8 Flash Cyber | Fairwind Program(650+パートナー) | モデル単体CyberGym 86.2% pass@1を公表 | なし | 2026年9月2日 | |
| GPT-5.6-Cyber | OpenAI | Daybreak経由の承認制。承認後はResponses APIで利用可能 | Advanced Cybersecurity Completion Rate **95%**を公表 | あり(承認後、入力$12.50/出力$75.00・1Mトークン) | 2026年8月 |
| Claude Mythos 5.1 | Anthropic | 2026年10月6日にCVP 3階層(Defense/Red Team/Specialized)へ再編、既存Glasswing参加組織はSpecialized Accessへ移行 | 初代Mythos PreviewはCyberGym 83.1%(Opus 4.6比+16.5pt)を公表 | あり(承認後にClaude API経由) | 初代Mythos 2026年4月7日/5.1は2026年9月1日 |

1 Flash発表時に公表されたMDASH全体のCyberGym Evaluation(出典:Microsoft AI)
この比較から読み取れるのは、Microsoft・Google・OpenAI・Anthropicの4社ともにモデル単体の数値ベンチマークを公表しているが、ベンチマーク名が同じでも測定条件は各社で異なるという点です。
MicrosoftはORA Model CardでCyberGym-E2E 41.68%等のモデル単体値を公開しており、これは1 Flash発表時に公表されたMDASH全体の95.95%(ハーネス統合込み・Replace 80%条件)とは測定対象が異なります。
OpenAIはGPT-5.6-Cyberの内部ベンチマーク(Advanced Cybersecurity Completion Rate 95%)とAPI単価(入力$12.50/出力$75.00・1Mトークン)を公開しており、承認後にResponses API経由で利用できる形になっています。
orcarouter.aiのGemini比較は、「Googleは86.2%(モデル単体)、Microsoftは95.95%(ハーネス全体・1 Flash)を同じ指標として比較してはいけない」と警告しています。1.1 Flashで公表された41.68%(CyberGym-E2E S3)も、Geminiの86.2%とは「E2E vs pass@1」で測定単位が違うため、横並び比較には引き続き注意が必要です。
提供思想の違い——ハーネス統合型 vs モデル単体型

4モデルは、同じ「サイバーセキュリティ特化AI」でも提供思想が明確に分かれます。
-
ハーネス統合型(Microsoft)
MAI-CyberシリーズはMDASHという多段ハーネスの中核モデルとして動く。顧客はモデルを直接触らず、MDASHスキャンの実行結果だけを受け取る。モデル差し替えの効果が「ハーネス全体の性能」として吸収される設計
-
プログラム型限定提供(Google・Anthropic)
Gemini 3.8 Flash CyberはFairwind Programを通じて重要インフラ防御者650+パートナーに提供。Claude Mythosは2026年10月6日にCVP 3階層(Defense/Red Team/Specialized)に再編され、既存Glasswing参加組織はSpecialized Accessへ移行。Claude Opus 5.5・Sonnet 5.5・Mythos 5.1(2026年9月1日リリース)を審査通過組織に提供する枠組みで、承認後はClaude API経由で呼び出せる
-
信頼アクセス型(OpenAI)
Daybreakは、GPT-5.6-CyberとDaybreak Red/Blueの構成で、Trusted Access for Cyberプログラム経由で提供。GPT-5.6-Cyberは承認後にResponses API経由で呼び出せる
どのモデルも「APIキー発行=即利用」ではない点は共通ですが、顧客の意思決定で違ってくるのは「モデルを選びに行くのか、プラットフォームを選びに行くのか」の軸です。
MAI-Cyber-1.1-Flashを選ぶとは、実質的には「MDASHを選ぶ」ことに等しく、Gemini 3.8 Flash Cyberを選ぶとは「Fairwind経由でGoogle Cloudのセキュリティ運用パイプラインに乗る」ことに近い意思決定になります。
選定時の判断軸

AI総合研究所の支援現場で見ている典型的な選定軸は、次の3点に収まります。
- 既存のクラウド・セキュリティ製品スタックとの整合
Azure中心ならMDASH、Google Cloud中心ならFairwind経由のGemini、マルチクラウドで独立性を保ちたいならAnthropic CVP経由のClaude
- 自社ワークフローとの合致
ハーネス統合済みの脆弱性スキャンを求めるならMDASH、承認後に自社パイプラインへAPI連携したいなら公開単価付きのGPT-5.6-CyberやCVP経由のClaude、重要インフラ防御向けのプログラム提供を使いたいならGemini 3.8 Flash CyberやCVP Specialized Access
- 測定観点の違い
1.1 FlashはCyberGym-E2E・ExCyTIn等10指標、GeminiはCyberGym pass@1、GPTはAdvanced Cybersecurity Completion Rate、Mythos 5.1はSystem CardでExploitGym等の指標を公開(CyberGymは飽和を理由に評価から外されている)。自社の評価軸に合うベンチマークを基準に選ぶ
Microsoft Azureのセキュリティスタックで統一している企業にとっては、MDASHがそのまま意思決定の中心になります。他クラウドが入り混じる環境では、他のモデルの比較評価を外さずに検討するのが現実的です。
既存MDASH利用者が1.1に切り替えるときの6つの検証ステップ

既にMAI-Cyber-1-Flashを含むMDASHを運用している組織にとって、1.1への切替は「18%削減」とORA Model Cardのベンチマーク結果を鵜呑みにするのではなく、自社環境で実効を測定して判断するのが本筋になります。
1.1 Flashはcyber permissive設計で挙動の性質が変わっているため、単純なモデル差し替えとしては扱えません。
ここでは、orcarouter.aiの推奨フレームをベースに、AI総合研究所が支援先で推奨している測定ステップを6つに整理します。
切替判断の6ステップ
-
ハーネス構成の固定
MDASH側の設定(並行度・タイムアウト・対象リポジトリ)を同一にしたうえで、1 Flashと1.1 Flashのプロファイルだけ切り替えて実行する。他の変数が混ざるとモデル差分を切り分けられない
-
カバレッジ固定でのfindings per dollar比較
1スキャンあたりのコストではなく、「同一コードベースで検出された真の脆弱性数 ÷ コスト」で評価する。スキャン単価は発見を減らすだけで下がるため、カバレッジを揃えないと18%削減が改善なのか省略なのか判定できない
-
エスカレーション率の指標入手
MDASHの運用ダッシュボードやMicrosoft側から提供されるレポートで、MAI Cyberプロファイルが大型モデル(GPT-5.4等)へフォールバックした比率を1 Flashと1.1 Flashで比較できないかを確認する。顧客側で直接ログ取得できる場合はそれを使い、取得できない場合はMicrosoftに個別に提示を依頼する
-
tail setの再スキャン
過去に自社エンジニアが時間をかけて特定した「人間でも難しかった脆弱性」のサンプルセットをMDASHのスキャン対象として投入し、1.1 Flashプロファイルで再現できるかを測る。MDASHは利用者がプロンプトを直接編集できない運用のため、通常のスキャンフローの中でtail setをコードベースとして扱って差分を見る
-
アナリスト工数の実測
検出件数ではなく、「検出された内容を人手でトリアージするのに要した時間」を記録する。偽陽性が増えるとコスト削減が実質的な工数増に化けるため、SOC運用コストの観点では必須
-
継続スキャンでの維持検証
3〜4週間にわたって継続的にスキャンを回し、1.1プロファイルの運用が安定して回るかを検証する。初回でよく見える数字と、継続運用で安定する数字は別物のため、少なくとも週次でカバレッジと所要時間を観測する
この6ステップのうち、1〜3は切替可否判断の必須項目、4〜6は切替後の運用品質を担保するための監視項目として機能します。
既存のFlash利用者が陥りやすい3つのパターン

AI総合研究所の支援現場で、サイバー特化AIの切替検討で詰まるパターンとして、以下の3つが典型的です。
- 「18%削減」をそのまま稟議に乗せる: 内部評価スイートでの削減率は、自社の脆弱性分布・コードベース規模とは独立した参考値。ORA Model CardのCyberGym-E2E 41.68%・CRSBench High 0.590などの単体性能とセットで提示し、自社環境での再測定結果も添える
- カバレッジ指標を取らないまま切り替える: 1.1プロファイルで実行コストが下がったことに満足し、「同じ脆弱性を同じ水準で発見できているか」の検証を省略する。結果、半年後のインシデント時に「切替で検出が落ちていた」と気付く
- MDASH側の指標を運用で見ない: Microsoftから提供される運用レポート(スキャン時間・検出件数・プロファイル別実行履歴等)を受け取っていても、SOC運用に組み込まれていないケース。1.1 Flashの改善効果を継続的に可視化できず、劣化を検知できない
いずれも切替の意思決定フェーズと切替後の運用フェーズを別物として設計することで回避できる話で、技術的な難易度は高くありません。
MDASHを運用している組織であれば、1.1プロファイルは今週中にでも検証を開始でき、2〜3週間の継続観測で切替可否は十分判断できます。
MDASHを使えなくても業務Agent基盤で防御運用は進められる

MAI-Cyber-1.1-Flashのような「verified customer向けMDASH限定モデル」には多くの企業がすぐにアクセスできません。ただし、サイバー特化モデルを待たずとも、現行のフロンティアモデル(Claude Opus 5・GPT-5.6・Gemini 3.8等)でコードレビュー・脆弱性報告のトリアージを業務に組み込むことは可能です。
モデル選定単独では動かず、業務Agent実行層・権限・監査を整える基盤が並行して必要になります。
このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、Mythos/MAI-Cyber世代のモデル切替を吸収しながら業務プロセスに載せる運用基盤として機能します。
-
現行モデルで脆弱性トリアージAgentを先行実装
Claude Opus 5・GPT-5.6などをバックエンドに据えたコードレビューAgentや、脆弱性報告の一次トリアージAgentを、Teams上から即起動できる状態で構築します。
-
モデル世代交代を吸収する管理層
MAI-Cyber-1 → 1.1のような短サイクル改版、GPT-5.5-Cyber → 5.6-Cyberのような競合モデル刷新をAgent設計の外側で吸収。特定モデル依存のワークフロー陥落を回避できます。
-
Agent単位でアクセスを統制
コード・脆弱性情報を扱うAgentごとにアクセス範囲を設計し、誰がどのAgentで何を照会したかを不変ログで保管。監査対応をそのまま提出できる形で残します。
-
データは100%自社Azureテナント内で完結
コード・脆弱性情報はAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完結する設計です。
AI総合研究所の専任チームが、フロンティアモデル選定から業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、Mythos/MAI-Cyber世代を見据えたセキュリティ×業務Agent実装例をご確認ください。
サイバー特化AIを使えなくても業務Agentで防御は進められる
Teamsから呼べる業務特化Agent群で脆弱性運用を回す
MAI-Cyber-1.1-FlashのようなMDASH限定モデルを使えなくても、現行のフロンティアモデル(Claude Opus 5・GPT-5.6等)でコードレビュー・脆弱性報告のトリアージを業務に組み込むことは可能です。AI Agent Hubは業務特化Agent群を1つのダッシュボードで統合管理し、モデル世代交代を吸収しながらセキュリティ運用と業務プロセスを1枚のオペレーションに載せる基盤として機能します。
まとめ
本記事では、MAI-Cyber-1.1-Flashについて、1 Flashからの変更点、ORA Model Cardで公開された外部ベンチマーク10指標、MDASH内での利用条件、競合サイバー特化AIとの位置づけ、既存利用者の切替判断ステップまでを、2026年10月時点の最新情報で整理しました。
2026年10月時点で押さえておくべきポイントは次の3つです。
- 1.1 Flashはcyber permissive設計への切替が最大の変更点で、refusalを減らしてvulnerability discovery・red teaming・pen testingまでカバー範囲を拡張した
- アーキテクチャ・パラメータ・コンテキストはORA Model Cardで維持公開され、外部ベンチマークはCyberGym-E2E 41.68%・ExCyTIn High 0.890など10指標以上に拡充された
- 既存MDASH利用者はカバレッジ固定のfindings per dollarとpermissive設計の挙動差分を自社環境で測るべきで、スキャン単価18%だけの比較は意味を持たない
MAI-Cyber-1.1-Flashは「使えるかどうか」よりも「cyber permissive設計のAIを自社ワークフローにどう組み込むか」という問いを突きつける更新です。MDASHを運用している組織であれば今週中にでも1.1プロファイルの検証を開始でき、非MDASH組織は現行のフロンティアモデルで脆弱性トリアージ運用を先行して整えておくのが、2026年末時点での現実的な第一歩になります。











