Unit 42 Continuous Frontier AI Defenseが始動、ただし単一モデルのカバレッジは40%未満

Unit 42 Continuous Frontier AI Defenseは9月22日にローンチされ、注目すべき警告を発した。テストしたAIモデルのうち、脆弱性の40%超を発見した単一モデルはなかったという。

Palo Alto Networksは、複数のAIモデル、独自のオーケストレーションソフトウェア、人間のセキュリティ専門家を組み合わせた常時稼働型の攻撃的セキュリティサービスでこれに対応する。このサービスは、露出を継続的に探索し、攻撃者が悪用可能かを検証し、攻撃経路をマッピングし、優先度を付けた修正を推奨する。

この見出しの数字は、同サービスが抱える中心的な緊張関係も示している。フロンティアモデルは、近年まで現実的ではなかった規模でセキュリティ調査を自動化できる一方、複雑な環境では各モデルが依然として大半の検出対象を見逃す。Palo Alto Networksは、Claude Mythos 5、GPT-5.6-Cyber、オープンウェイトモデル、専門ツール、Unit 42の研究者を組み合わせることで、その隔たりをより埋められると主張する。

このアプローチは、年次または四半期ごとの評価を中心に構築された従来のペネトレーションテストプログラムに圧力をかける。また、先進的なサイバーモデルを1つ選び、それを中心に防御自動化を構築しようとしていた購入者にも再考を迫る。

ただし、40%という上限は独立して再現されたベンチマークではなく、Palo Alto Networksによる評価に基づく。同社は、モデル間のカバレッジ、誤検知、コスト、修復結果を比較するために十分な方法論の詳細を公表していない。

したがって、このローンチの重要性は製品発表にとどまらない。モデルの多様性をセキュリティアーキテクチャ上の意思決定へと変える一方で、統合システムがどれだけ追加的な保護を提供するのかを検証する責任は購入者に残される。

Unit 42 Continuous Frontier AI Defense、テストを継続的なサービスへ転換

このサービスは、予定された評価を、発見・検証・修復が継続するサイクルへと置き換える。

Palo Alto Networksは、9月22日のローンチ発表を通じて、この世界向けサービスを発表した。利用モデルに応じたオプションを備える年間サブスクリプションとして販売される。

同社はこれを、専門家主導のエージェント型攻撃的セキュリティサービスと説明している。この文脈でのエージェント型とは、限られた人間の指示のもとで、ソフトウェアが複数のセキュリティテスト手順を計画・実行できることを意味する。

サービスは、組織全体の資産を対象とするベースライン評価から始まる。その後、アプリケーション、ID、クラウドリソース、ソースリポジトリ、API、ネットワーク資産が変化するたびにテストを継続する。

継続的テストエンジンは、既知および未知の弱点を探す。マルチモデルのハーネスが、各タスクをUnit 42が最適と判断したモデルに振り分ける。

ハーネスとは、モデルを取り巻くソフトウェア層である。ツール、指示、対象データ、検証手順、権限、制御を提供し、汎用モデルを運用可能なシステムに変える。

Unit 42は、このサービスがエンドツーエンドの攻撃経路も検証するとしている。この区別は重要だ。ソフトウェア上の欠陥があっても、ただちに機密システムへの実用的な侵入経路が生まれるわけではないためだ。

攻撃経路は、公開されたアプリケーション、弱いID管理、過剰なクラウド権限、到達可能なデータといった複数の条件を結び付ける。検証は、これらの条件が実質的な侵害につながり得るかを判断する助けとなる。

システムは続いて、優先順位付きの修正、コードレベルの推奨事項、可能な仮想パッチを含む修復ガイダンスを生成する。仮想パッチは、影響を受けるアプリケーションを即座に変更することが現実的でない場合に、セキュリティ制御を通じて悪意ある動作を遮断する。

同社のプレスリリースによると、サブスクリプションではAnthropic、OpenAI、オープンソースのモデルを利用できる。すべての構成でマルチモデルのハーネスを使用する。

この設計は、2026年4月に登場したUnit 42 Frontier AI Defenseを基盤とする。以前の提供内容は、特定時点での露出分析、セキュリティ設計図、より広範な変革プログラムを中心としていた。

9月のサービスは運用モデルを変える。単一の評価とロードマップを提供する代わりに、初回エンゲージメント後も環境のテストを続ける。

この転換は、定期的なセキュリティレビューが抱える現実的な弱点を反映している。企業システムは、デプロイ、ID更新、新たな統合、クラウド設定の変更、サードパーティー依存関係を通じて絶えず変化する。

次のリリース後には、問題がないとされた評価も古くなり得る。継続的テストは、リスクのある変更からその発見までの時間を短縮することを目指す。

もっとも、継続的テストは運用上の責務も生む。常時稼働するシステムには、安定した資産インベントリ、管理された認証情報、テストの境界、証跡の保持、明確なエスカレーションルールが必要となる。

こうした統制がなければ、継続的な発見は継続的なアラート生成に変わりかねない。このサービスの価値は、検証済みの検出結果が修正できるチームに届くかどうかに左右される。

40%のカバレッジ上限がローンチ以上に重要な理由

Palo Alto Networksは、単一のフロンティアモデルが脆弱性発見を解決すると主張しているわけではない。モデル間の見解の違いは避けられないと訴えている。

Unit 42によると、評価した企業のコードベースと稼働中環境全体で、脆弱性の40%超を発見した単一モデルはなかった。また、Claude Mythos 5とGPT-5.6-Cyberが特定した露出の重複は10%未満だったとしている。

これらの主張を合わせると、モデルはかなり異なる弱点を発見していたことが示唆される。総検出数で首位のモデルであっても、別のモデルが認識する問題を見逃す可能性がある。

これが発表に含まれる逆転である。より高性能なサイバーモデルが、必ずしもセキュリティ業務を単一の勝者に集約するとは限らない。むしろ異なるモデル間をオーケストレーションする価値を高める可能性がある。

モデルが異なるのは、訓練データ、強化手法、安全策、コンテキスト処理、ツール利用、推論の挙動が異なるためだ。同じ対象に対しても、異なる前提でアプローチする場合がある。

あるモデルはソースコードのレビューで優れた性能を示すかもしれない。別のモデルは、稼働中アプリケーションとの対話や、クラウドシステム全体にまたがるIDの弱点を結び付けることにより強い可能性がある。

周辺のハーネスは、基盤モデルと同じほど重要になり得る。ツール選択、再試行ロジック、メモリ、対象の分解、検証ルールは、システムが発見できる範囲に影響する。

Unit 42の以前のNOVA研究は、この補完性のより大規模な例を示している。NOVAは同社のNetwork and Open-Source Vulnerability Analyzerである。

Palo Alto Networksによると、NOVAは2カ月間で3,915件のオープンソースプロジェクトを分析し、14,090件の確認済み脆弱性を生成した。同社はこのうち40%を高重大度またはクリティカルと分類した。

同社はまた、これらの検出結果の99.4%は従来報告されていなかったと報告した。この数字は、ソフトウェア脆弱性の独立した全数調査ではなく、ベンダーによる研究結果として読むべきだ。

このプロジェクトは、Go、JavaScript and TypeScript、PHP、C and C++、Javaを含むエコシステムを対象とした。Unit 42によると、評価したすべてのモデルが、他のモデルでは得られなかった検出結果を提供した。

ある詳細なサブセットでは、最も検出量の多いモデルが235件の確認済み検出結果を生成し、そのうち185件が固有の検出結果だった。最も検出量の少ないモデルでも139件を生成し、そのうち93件は固有のものだった。

これらの数字は、アンサンブルによってカバレッジが向上し得るという考えを支持する。ただし、すべての企業顧客が得られる追加的なカバレッジの程度を確立するものではない。

コードベースの規模、プログラミング言語、アプリケーションアーキテクチャ、利用可能なツール、テスト権限はいずれも結果を変え得る。稼働中環境には、リポジトリだけを対象としたテストには存在しない制御も導入されている。

したがって、40%という主張をAIモデルの普遍的な上限と解釈すべきではない。これは、Palo Alto Networksが公に完全には開示していない条件下におけるUnit 42の評価を説明するものだ。

不足している詳細には、完全な脆弱性セット、モデル構成、試行回数、ツールアクセス、時間予算、重複した検出結果の扱いが含まれる。

Palo Alto Networksは、真陽性、偽陽性、偽陰性、異議のある結果を示す完全な混同行列も公表していない。このため、独立した比較は難しい。

それでも、このカバレッジに関する発見は重要な警告をもたらす。企業は、有力なモデルのベンチマークを、単一モデルが攻撃対象領域全体を把握できる証拠として扱うべきではない。

モデルは、制御された課題では高い性能を示しながら、特定のID連鎖、統合、デプロイパターンによって生じる弱点を見逃す可能性がある。カバレッジは購入者自身の環境に対して測定する必要がある。

真の競争は、マルチモデルのカバレッジと単一モデルの簡潔さの間にある

主な選択肢はもはや人間によるテストかAIによるテストかではない。管理されたアンサンブルか、単一モデルと単一ワークフローへの依存かである。

単一モデルのシステムには明白な利点がある。複数の制限付きモデルとオープンモデルに作業を振り分けるサービスよりも、統合、監視、ガバナンス、評価が容易だ。

購入者は、1つのプロバイダー、1つのアクセス方針、1つのモデルファミリー、1組の出力特性を文書化できる。不整合な結果を診断する際、エンジニアリングチームが扱う変動要因も少なくなる。

マルチモデルのサービスは複雑さを増す。各モデルには、異なるプロンプト、ツール、安全策、データ処理ルール、エスカレーション経路が必要となる可能性がある。

さらに、アナリストが比較する前に結果を正規化しなければならない。2つのモデルが同じ脆弱性を異なる方法で記述したり、矛盾する重大度を割り当てたりする場合がある。

Unit 42の答えはオーケストレーションだ。同社独自のハーネスは、作業の振り分け、結果の統合、悪用可能性の検証、1つの管理サービスを通じた検出結果の提示を目的としている。

これは、価値をモデル層より上位に置く。高性能モデルが代替可能になれば、持続的な優位性は対象へのアクセス、タスクのルーティング、検証、修復統合、専門家の監督へと移る。

Palo Alto NetworksのCEO、Nikesh AroraはAxiosのインタビューで、この論点を示した。人間の専門知識と組み合わせた複数のモデルが、業界の進む可能性が高い方向を表すと主張した。

基盤となるモデルは、一般的な公開チャットボットではない。Anthropicは、最も制限の少ないサイバー機能を、Mythos access programを通じて審査済みの利用者に限定している。

OpenAIも同様に、GPT-5.6-Cyberを認可された脆弱性研究とセキュリティテスト向けに位置付けている。拡張されたDaybreak programは、先進的なサイバーワークフローに適したアクセスを適格な防御担当者に提供する。

こうした制限は、管理サービスを購入するもう1つの理由となる。多くの企業は、Unit 42のシステムに含まれるすべてのアクセス制限付きモデルを、直接入手、運用、統制することができない。

ただし、管理されたアクセスは集中リスクをもたらす。顧客はモデルの可用性、ルーティング判断、評価、証跡、修復の優先順位についてPalo Alto Networksに依存する。

モデルプロバイダーは、アクセス条件、安全策、保持ルール、モデルバージョンを変更し得る。Unit 42は、カバレッジを低下させたり、進行中の評価を妨げたりすることなく、こうした変更を吸収しなければならない。

オープンウェイトモデルは別の経路を提供するが、独自のガバナンス負担を伴う。運用者は、ホスティング、更新、隔離、監視、不正利用対策に責任を負う。

このアンサンブルは、難しい測定上の問題も生み出す。モデルを増やせば発見件数は増え得るが、重大リスクがそれに比例して減少するとは限らない。

重要度の低い重複した発見が10件あっても、本番データに到達する検証済みのIDチェーンが1件あることより重要とは限らない。発見数だけでは、成功を測る指標として不十分だ。

購入者は、検証済みの攻撃経路、受理された発見、修復時間、再発、独立して確認されたリスク低減に注目すべきである。これらの指標は、モデルの出力をセキュリティ成果に結び付ける。

同じ原則は社内のセキュリティナレッジにも当てはまる。発見、コードの文脈、責任分担の記録、修復判断には、分散したレポートではなく追跡可能な保管先が必要だ。

すでにエンジニアリングナレッジベースを構築しているエンジニアリングチームは、セキュリティの証拠にも同じ規律を適用できる。目的は、ある発見がなぜ重要だったのか、どのように解決されたのかを残すことだ。

競争優位を得るのは、証拠を行動へと移すシステムになる。より多くのベンダーが同等の能力を得るにつれ、モデルへのアクセスだけでは説得力を失っていくだろう。

数字が依然として証明していないこと

この発表は説得力のあるカバレッジ主張を示しているが、再現可能な有効性ベンチマークはまだ提示していない。

公開資料では、カバレッジ比較に含まれたモデルの完全な一覧は明らかにされていない。主要な例としてClaude Mythos 5とGPT-5.6-Cyberを挙げ、オープンウェイトモデルも併記している。

また、各モデルのカバレッジを算出する際の基準となる脆弱性の完全な集合を、Unit 42がどのように決定したのかも説明していない。

その分母は不可欠である。十分に完全な参照セット、または慎重に定義された統合セットがなければ、モデルが40%を発見したとは研究者には分からない。

分母に全モデルが生成したすべての固有の発見が含まれる場合、モデルを追加すると総数が増え、各モデル単体の割合は低下し得る。それでも相補性は示されるが、測定されるのはアンサンブル相対のカバレッジとなる。

埋め込まれた脆弱性に基づくベンチマークは、異なる問いに答える。それは、各モデルが既知の管理された欠陥セットを発見できたかを測るものだ。

実際の顧客環境をテストすると、さらに複雑になる。悪用すれば本番環境を妨げたり、機密データにアクセスしたりするため、真の脆弱性の一部は未確認のまま残る。

Unit 42は、そのシステムが現実世界での悪用可能性を検証するとしているが、公開資料では各テストモードの認可境界を説明していない。こうした境界は、見かけ上のカバレッジに大きく影響し得る。

偽陽性率も同様に重要だ。AIシステムは、悪用可能なリスクを生まないまま、アナリストの時間を消費するもっともらしい脆弱性仮説を数多く生成できる。

人間による検証は、この問題を軽減できる。しかし、このサービスは、専門家が生の発見のうち何件を却下、統合、格下げ、または追加テストに差し戻すのかを公表していない。

コストとレイテンシーも不明確なままだ。マルチモデルのハーネスはカバレッジを改善できる一方、単一モデルのワークフローより大幅に多くの推論、サンドボックス、アナリストのリソースを消費する可能性がある。

同社は、ルーティングが大規模なフロンティアAIのコスト管理に役立つとしている。だが、タスク単位のコスト比較やルーターで採用するトレードオフは公表していない。

購入者には、データの取り扱いについても明確さが必要だ。セキュリティテストでは、独自のソースコード、アーキテクチャの詳細、認証情報、悪用可能な弱点の証拠が露出する可能性がある。

各モデルプロバイダーには異なる保持・監視要件がある場合がある。顧客は、どのデータが自らの環境を離れるのか、どの期間利用可能な状態で残るのか、誰が確認できるのかを明確にすべきだ。

このサービスの修復に関する主張も、同様の精査を必要とする。コード変更を推奨することと、それを安全に展開することは同じではない。

提案された修正には、レビュー、テスト、担当者、ロールバック計画、検証が必要だ。仮想パッチは迅速に露出を減らせるが、根本的な欠陥が残っている場合には誤った安心感も生み得る。

Palo Alto Networksは、このサービスが環境全体のベースラインを可視化し、環境の変化に応じてテストを継続できるとしている。購入者は、それらの変更をどのように検出し、何を再テストするかをどのように判断するのかを問うべきだ。

リポジトリへのコミット、クラウドポリシーの更新、新しいAPIルート、またはID変更は、攻撃経路の異なる部分に影響し得る。効率的な再テストは、これらの依存関係を理解することにかかっている。

したがって重要な懐疑的問いは測定可能である。このアンサンブルは、既存のペネトレーションテストおよび脆弱性管理プログラムよりも速く、検証済みの露出を減らせるのか。

その答えには顧客レベルの証拠が必要だ。有用な比較には、テスト時間当たりの受理された発見、排除された重大な攻撃経路、修復時間の中央値、再発率が含まれる。

独立した再テストによって、報告された修正が元の経路を閉じたことも確認すべきだ。そうでなければ、このシステムはリスク低減ではなく、生成された作業量を測ることになりかねない。

これらの欠落のいずれも、このサービスが無効であることを意味しない。これらは、もっともらしい技術戦略と、独立して実証された運用上の価値との違きを示すものだ。

継続的なAIテストがセキュリティチームに新たな圧力をかける

このサービスは、ボトルネックを脆弱性の発見から、どの発見に即時対応すべきかという判断へ移す。

セキュリティチームはすでに、スキャナーのアラート、コード分析の結果、バグ報告、ペネトレーションテストの発見、クラウド設定ミス、IDに関する警告を管理している。さらに高ボリュームの発見システムが加われば、この負担は悪化し得る。

Unit 42が悪用の検証を重視するのは、この問題に対処するためだ。実行可能な攻撃経路につながる発見は、孤立した理論上の弱点よりも多くの注意に値する。

エージェントが継続的に動作する場合、この優先順位付けは重要になる。月次レポートならチームは限定されたパッケージを処理できるが、常時稼働のシステムは重要な変更のたびに作業を生み出し得る。

この圧力はセキュリティオペレーションセンターにとどまらない。アプリケーションの所有者、クラウドチーム、ID管理者、エンジニアリングマネージャーも修復に参加しなければならない。

コードレベルの推奨には、影響を受けるサービスを理解する開発者が必要だ。IDに関する発見では、定着したワークフローや自動化システムを妨げる変更が必要になる場合がある。

クラウドの露出は複数のチームやアカウントにまたがり得る。ネットワークの修正は、可用性、監視、顧客トラフィックに影響する可能性がある。

このため、所有権データはセキュリティ統制の一部となる。このサービスは、検証済みの各露出を、それを解決できる個人またはチームに結び付けなければならない。

組織には、悪用可能性、到達範囲、事業への影響に基づく対応目標も必要だ。重要度ラベルだけでは、こうした関係を捉えられることはほとんどない。

重大なライブラリの欠陥であっても、ある環境では到達可能な経路がないかもしれない。中程度のIDの弱点が、機密性の高い本番システムへの直接アクセスを提供する場合もある。

継続的なテストは、調達時の問いも変える。購入者は、発表に記載されたモデル名だけでなく、モデルを取り巻く運用プロセスを評価すべきだ。

各攻撃ステップの証拠をUnit 42が提供するか、すべてのツール操作を記録するか、発見と悪用を分離するか、顧客定義の停止条件をサポートするかを問うべきである。

認証情報には、テストに必要な最小権限を使用すべきだ。本番環境へのアクセスは、隔離され、一時的で、監視され、取り消し可能でなければならない。

破壊的な操作には明示的な統制が必要だ。データベースの弱点を検証するエージェントに、本番情報を変更または削除する権限を与えるべきではない。

顧客は完全なログも要求すべきだ。有用な発見には、影響を受ける資産、テストされた経路、観測された証拠、モデルとハーネスのバージョン、人間のレビュアーが示されるべきである。

これらの記録は、修復、監査、インシデント対応、後の再テストを支える。また、更新後のモデル回帰の特定にも役立つ。

従来のペネトレーションテストプロバイダーは、この運用モデルから圧力を受ける。年次の契約は深い専門性を提供するが、対象が変わればその発見はすぐに古くなり始める。

自動化スキャナーは別の課題に直面する。継続的な可視性を提供する一方で、多くはコード、クラウド、ID、ネットワークの各層にまたがる複雑な悪用チェーンの検証に苦戦している。

Unit 42は、このサービスをそれらのカテゴリの中間に位置付けている。継続的な自動化を、専門家による監督と攻撃経路の検証と組み合わせるものだ。

未解決の問いは、その組み合わせが人間によるレビューの品質を下げずに経済的に拡張できるかどうかである。モデル推論が拡大しても、専門家の注意力には限りがある。

モデルが顧客の修復能力を上回る速度で発見を生成するなら、このサービスはキューの削減を支援しなければならない。そうでなければ、継続的な発見は同じ組織的制約をより頻繁に露呈するだけになり得る。

マルチモデル戦略が機能するかを示す3つのシグナル

次の試金石は、また別のモデル発表ではない。統合されたカバレッジが、より速い、独立して検証されたリスク低減を生むという証拠である。

最初のシグナルは、詳細な評価手法だ。Palo Alto Networksは、40%のカバレッジ上限と10%未満の重複という数値をどのように計算したかを開示すべきである。

有用な手法では、モデルのバージョン、対象の種類、ツールの権限、試行回数の上限、時間予算、検証基準、分母を特定する。

偽陽性と異議のある発見も報告すべきだ。こうした詳細がなければ、外部の人々はアンサンブルの優位性がモデルの多様性、ハーネス設計、追加コンピュート、人間の介入のどこから来るのかを判断できない。

その情報を公開すれば、中核となる主張は強化される。再現可能な条件下でも差が持続するなら、単一モデルの防御システムは明確なアーキテクチャ上の不利に直面することになる。

独立テストで差がより小さいと示されれば、顧客は1つのモデルと専門ツールによるより単純なワークフローを好むかもしれない。その結果は、大規模なマネージドアンサンブルの根拠を弱める。

2つ目のシグナルは、修復に結び付いた顧客の証拠だ。ケーススタディでは、閉鎖された検証済みの攻撃経路、解決までの時間、再発、以前のテスト手法との比較を報告すべきである。

数週間で1年分の露出を発見したという話は印象的に聞こえるが、量だけでは価値を示さない。重要な成果は、チームが重大なリスクをより早く取り除けたかどうかだ。

証拠では、新たに発見された脆弱性と既存スキャナーの発見を区別すべきだ。また、モデルが生成した修正と、顧客がレビューして展開した変更も分けるべきである。

独立した再テストは、こうした結果の信頼性を高める。別チームが、元の攻撃経路がもはや機能しないこと、また修正が別の露出を生んでいないことを確認すべきだ。

3つ目のシグナルは、競合他社とモデルプロバイダーがどう反応するかである。他のセキュリティベンダーは独自のルーターを構築し、限定的なモデルプログラムと提携し、またはモデル非依存の検証レイヤーを提供できる。

AnthropicとOpenAIも、審査済みの防御側ユーザーへの直接アクセスを拡大できる。より広範なアクセスは、マネージドプロバイダーを通じて能力を購入する利点の一つを減らすことになる。

同時に、新しいモデルのリリースは多様性を高め得る。真に異なる学習またはツール利用の振る舞いを持つモデルは、現在のシステムが見逃す発見に寄与する可能性がある。

Unit 42がモデルを追加する理由が、測定されたカバレッジの改善なのか、それともマーケティング上のリストを強化するためなのかを注視すべきだ。このサービスは、固有の価値をほとんど追加しないモデルを外せるべきである。

購入者は、アンサンブル内の各モデルについて寄与データを要求すべきだ。有用なレポートでは、固有の検証済み発見、重複、コスト、レイテンシー、タスクカテゴリ別の性能を示す。

また、ルーティングが時間とともにどのように変化するかも問うべきだ。特定の言語や対象タイプをどのモデルが最も適切に扱うかを学習するハーネスは、効率を改善できる。

ただし、動的ルーティングは再現性を複雑にする。異なるモデル構成で同じ環境を再テストすると、異なる発見や証拠が生成される可能性がある。

バージョン管理された記録は、この問題の抑制に役立つ。すべての結果で、テスト時に使用したモデル、ハーネス、ツール、ポリシー、関連する対象環境の状態を保持すべきだ。

Unit 42 Continuous Frontier AI Defenseは、サイバーセキュリティ向けモデルの能力が高まる一方で、利用制限も強化されつつある時期に登場した。この組み合わせにより、信頼できる仲介者への需要が生まれている。

Palo Alto Networksは一貫した答えを提示している。複数のモデルを使い、制御されたツールで囲み、発見事項を検証し、専門家をプロセスに関与させ続けるというものだ。

40%のカバレッジという主張は、この戦略の妥当性を示すものではあるが、決定的な証明ではない。企業はこれを、自社のアプリケーション、ID、クラウド環境に照らして検証すべき仮説として扱うべきだ。

このサービスを評価するセキュリティ責任者は、範囲を限定したパイロットから始めるべきである。テスト開始前に、対象資産、権限、安全制御、既存の検出事項、是正指標を定義する。

そのうえで、受け入れられた検出事項、検証済みの攻撃経路、アナリストの作業負荷、解決までの時間を、現行プログラムと比較する。重要な結果ごとに、どのモデルが固有の貢献をしたのかを問うべきだ。

このプロセスにより、Unit 42の中心的な主張は組織が検証可能なものになる。既存ツールが見逃す重大な経路をアンサンブルが発見するなら、このアーキテクチャの複雑さは正当化される。

主にアラートキューを増やすだけなら、モデル数は重要ではない。問われるのは、継続的なマルチモデルテストが、攻撃者に悪用される前に防御側が露出を解消する助けとなるかどうかだ。