Mave Series A、既存のセキュリティツール横断のAI調査に2,800万ドルを調達
Maveは、企業がまずセキュリティデータを一元化しなくてもセキュリティ調査を自動化できるようにするため、Series Aで2,800万ドルを調達した。10月22日に発表されたMave Series Aは、ソフトウェアが既存ツール間の証拠を結び付ける一方で、重大な対応の主導権は人間が維持するという、特定のアーキテクチャ上の賭けを支えるものだ。これにより累計調達額は3,400万ドルとなる。
ここには、情報を集めることと、根拠を示せる判断に到達することの間に緊張関係がある。組織は高機能なセキュリティ製品を保有していても、相反する所見を整理する作業をアナリストに頼る場合がある。Maveはこの接続作業の自動化を提案しており、その製品は、不審な活動を報告するシステムと、行動の責任を負う人々の間に位置することになる。
Dropzone AIのような競合企業もすでに自動調査を追求しており、Maveはセキュリティチームの信頼をめぐる既存の競争に参入する。その機会は、断片化したツールを連携させることにかかっている。重要な論点は、調査の質、運用上の権限、そして人によるレビューを加味した後に自動化が実際に作業を減らすかどうかだ。
Mave Series Aが実際に資金を投じる対象
この投資は、既存システム横断の調査レイヤーを支援し、技術開発と並行してエンタープライズ事業を拡大する。
Red Dot Capital Partnersがラウンドを主導し、Lumir Growth Partnersが参加した。先行する600万ドルのシードラウンドは、Dell Technologies CapitalとEmerge Venturesが主導した。CTechによるセキュリティ調査への資金調達の報道では、AI研究、エンタープライズ製品、国際展開が資金の用途として挙げられている。
今回のラウンドと累計調達額の違いは重要である。Maveが発表したのは、同額のSeries Aではなく、累計3,400万ドルの資金調達だ。この発表は投資家の支援と支出の優先事項を示す。一方で、比較可能な条件下において製品が競合アプローチに対してどのような性能を示すかを立証するものではない。
Maveは2025年、CEOのRaziel OrenとCTOのGuy Eshelによって設立された。同社は厳格なエンタープライズ環境を対象としているものの、事業運営の歴史はまだ浅い。資金調達は開発と販売のためのリソースをもたらすが、顧客にはシステムが自社固有のセキュリティ運用に適合するという証拠が依然として必要となる。
Mave Series Aは、モデル開発以外の取り組みも支える。エンタープライズ導入には、信頼性の高い接続、権限管理、ドキュメント、サポート、基盤ツールの変更時にも予測可能な動作が必要だ。調査製品は接続先のすべてのシステムから依存関係を引き継ぐため、これらの責務は重要である。
説得力のあるデモは、ソフトウェアが不審な活動について一貫した説明を組み立てる様子を示せる。しかし持続可能な導入では、アクセス方針が変わり、ツールがアップグレードされ、組織が再編された後も、有用な結果を出し続けなければならない。投資家はこうした問題に対処する能力に資金を提供するが、資金調達の発表だけでは、それらが解決済みであることは示せない。
商業面での意味合いもある。既存システム横断で機能する製品は、より広範なインフラ刷新に踏み切らずとも、購入者が自動化を試せる可能性がある。そのため初期提案は評価しやすくなるが、実際の導入負荷は各組織が必要とする統合と統制に左右される。
したがって、このラウンドの最も妥当な解釈は具体的だ。投資家は、セキュリティ製品の間にある調査作業を自動化する試みを支援している。そのことはベンダーに対し、自動化がどこから始まるのか、どのような依存関係を導入するのか、顧客がその結果としての判断をどう検証できるのかを説明する圧力を生む。
また、Maveには技術開発と事業開発を同時に進める余地も生まれる。導入が再現可能になる前に販売を拡大すれば、サポートリソースが逼迫する可能性がある。研究だけに集中すれば、有効な製品でも導入しにくくなる。発表された支出の優先事項は、エンタープライズ向けセキュリティ事業を構築する両面を反映している。
セキュリティ責任者が直面するのは連携の問題
Maveの提案は、単一のアラートソースではなく、セキュリティツールをつなぐ手作業に焦点を当てている。
セキュリティオペレーションセンター、すなわちSOCは、脅威の監視と調査の調整を担うチームおよび運用機能である。その業務は警告を読むだけではない。アナリストは、どの証拠が関連するのか、事象が不審かどうか、そして事業が許容できる対応は何かを判断しなければならない。
不審な従業員ログインに関する仮想的な調査を考えてみよう。IDシステムは認証活動を示し、エンドポイント製品は従業員のデバイス上の挙動を記録できる。資産台帳はそのデバイスの所有者を特定する可能性がある。アナリストは、それらの観測結果が同じ事象についての判断を形成できるようにする必要がある。
この例は、Maveの顧客事例として開示されたものではなく、仮定である。これは、アラートを収集しても調査が自動的に解決されるわけではない理由を示している。各観測結果は異なる問いに答えるものであり、その答え同士の関係が、その事象をエスカレーションすべきかを決定する。
セキュリティ情報・イベント管理システム、すなわちSIEMは、セキュリティイベントを中央プラットフォームで収集・分析する。中央収集は履歴の把握や記録横断の検索に役立つ。しかし購入者は、調査にそのプラットフォーム外の関連コンテキストが含まれているかを依然として評価する必要がある。
この負担はまず、見逃した脅威と業務の混乱の両方を説明しなければならないセキュリティ責任者にかかる。処理の高速化は魅力的だが、アクセスを無効化する判断は正当な業務を中断させるおそれがある。自動調査には、単に推奨をより早く提示するのではなく、その行動の根拠となる判断を支えることが求められる。
アナリストも関連した責任の変化に直面する。ソフトウェアが証拠を集めるなら、彼らの注意は未解決の前提を確認し、例外を扱うことへと移る。この変化が価値を生むのは、出力のレビューに要する労力が、調査を手作業で再構築するより少ない場合に限られる。
マネージドセキュリティサービスプロバイダー、すなわちMSSPは、他組織向けにセキュリティサービスを運営する。こうした事業者にとって、調査自動化は顧客環境間の一貫性を問う問題となる。標準化された環境でうまく機能するアプローチも、顧客ごとに異なる製品やアクセス方針を使う場合には、さらなる評価が必要だ。
ここから直ちに購入に関する問いが生じる。製品は実際に、作業のどの部分を取り除くのか。記録の取得、関係性の特定、行動の推奨、対応の実行は、それぞれ別個の能力である。販売プレゼンテーションでこれらを組み合わせても、本番環境での異なる結果を覆い隠してはならない。
長期的な圧力はセキュリティプラットフォームベンダーにも及ぶ。独立した調査レイヤーが有用になれば、顧客には既存製品を連携させる別の方法が生まれる。既存ベンダーは、自社の接続済みワークフローが、より良い証拠、より簡単な管理、またはより明確な説明責任を提供する理由を示す必要がある。
この結果は、導入を条件とする。Maveの資金調達は、顧客が予算を移行したり既存プロセスを置き換えたりすることを示してはいない。それは同社に対し、追加のインターフェースを超える測定可能な利益を伴う独自の製品レイヤーに、連携は値するのだと主張するためのリソースを与える。
その場での調査は依存関係を変える
新たな中央リポジトリを避けることで、統合の課題はライブアクセス、一貫した解釈、再現可能な証拠へと移る。
Maveは、接続されたツールに問い合わせ、現在のコンテキストを収集し、証拠が現れるにつれて調査を適応させるシステムを説明している。同社が示すアプローチでは、新たな中央テレメトリデータベースを必要としない。テレメトリとは、システムがその動作について生成する活動記録を指す。
同社がエージェント型セキュリティ運用について発表した内容では、既存システムを横断して調査を行い、許可されたタスクを実行するエージェントが説明されている。ここでいうエージェントとは、接続されたツールを通じてタスクを遂行するソフトウェアコンポーネントである。これらの能力は、独立して確立された比較結果ではなく、依然として同社の主張である。
情報がすでに存在する場所で作業することは、魅力的な提案となる。購入者は、収集プロセス全体を再構築せずに、調査レイヤーが有用なコンテキストへアクセスするかを評価できる。アーキテクチャ上の問いは、すべての記録をどこに置くべきかから、必要なときにシステムがどの証拠を取得できるかへと移る。
この変化は、検討に値する依存関係を生む。接続先ツールが利用できなくなった場合、調査では、不完全な検索と不審な活動が存在しないことを区別する必要がある。そうしなければ、欠けた回答が根拠のない結論になるおそれがある。
同じ問題は権限にも当てはまる。限定的なアクセスはセキュリティ上適切な場合もあるが、システムが確立できる範囲を狭める。レビュー担当者が未回答の問いを理解できるよう、調査はその境界を可視化すべきである。
時間は別の複雑さを加える。現在の情報は進行中のインシデントの説明に役立ち、履歴記録は以前に何が起きたのかを再構築する助けになる。特に調査中にアカウント状態やデバイス設定が変化する場合、購入者は製品が異なる時点で収集された観測結果をどのように関連付けるかを評価すべきだ。
監査証跡、すなわち調査手順と証拠を保持した記録は、レビュー担当者がその関係を調べる助けになる。Maveは、クエリ、証拠、推論、行動を記録すると述べている。実務上の問いは、その記録によって、レビュー担当者がワークフロー全体を繰り返さずに結論を検証できるかどうかだ。
たとえば、ある推奨は、それを裏付ける観測結果と区別できるべきである。アクセスが取り消されたという記録は、アカウントが侵害されたという証拠とは異なる。これらの要素を分離しておくことで、意見の相違が事実、その解釈、あるいは対応方針のどこにあるのかをレビュー担当者が特定しやすくなる。
これは、実証されたMaveの制約についての主張ではなく、評価基準である。調査が複数の接続システムに依存するため、このアーキテクチャではこうした問いが特に重要となる。信頼性は、言語モデルだけでなく、接続とその解釈も対象にしなければならない。
一元化を避けても、データガバナンスの問いがなくなるわけではない。購入者には、どの情報が取得されるのか、どこで処理されるのか、どの調査記録が保持されるのかについて、依然として明確さが必要である。こうした詳細が、その設計が組織の義務に適合するかを決める。
そのため、アーキテクチャ上のトレードオフは、古いデータベースと新しいAIの選択よりも具体的である。中央収集とライブ調査は、重複するニーズに対応する。Maveの機会は、残るギャップを検査可能にしながら、既存環境全体で自社アプローチが判断を改善することを示す点にある。
競合は調査品質を比較対象にする
自動調査はすでに競争カテゴリーであり、Maveには購入者が自社環境で観察できる差別化が必要となる。
Dropzone AIは有用な比較対象となる。GeekWireによる同社のAI SOCアナリストの報道では、アラートを調査し、人の注意を要するインシデントをエスカレーションすることを目的としたソフトウェアが紹介されている。これは製品の目指す方向性が重なることを示すものであり、いずれかの企業の方が優れている証拠ではない。
この比較が重要なのは、エンタープライズの買い手が類似の業務に対する複数のアプローチを評価できるからだ。反復的な調査を減らすという大まかな約束だけでは、どのような条件で特定のシステムを優先すべきかは分からない。統合の対応範囲、証拠の品質、運用上の適合性が、この判断の中心となる。
既存システムをまたいで調査するというMaveの強調点は、具体的な立ち位置を与えている。しかし、立ち位置が差別化となるのは、実装が優位性を生み出す場合に限られる。買い手は、その製品が自社固有のツール構成、不完全な記録、例外的なワークフローの組み合わせに対応できるかを確認する必要がある。
競合他社の主張についても、Maveに適用するのと同じ帰属に関する厳密さが必要だ。Dropzone CEOのEdward Wu氏はCRNに対し、同社の製品は基盤となるサービスを人手で実行せずに調査を提供すると語った。同氏は別途、完了した作業をレビューする社内の人間による品質管理機能についても説明している。
CRNのソフトウェアのみで行う調査に関する記事は、サービスを提供することと、その品質を確認することの有用な違いを示している。これはWu氏による自社アプローチの説明である。Maveが自社の運用をどのように人員配置しているかを示すものではない。
買い手にとって、この違いは、運用面で自動化が何を意味するのかというより大きな問いを開く。製品によっては証拠の取得を自動化する一方で、難しい推論は人が完了させる場合がある。別の製品では調査を自動化しつつも、顧客による広範なレビューを必要とする場合がある。顧客が結果を比較する前に、いずれの形態についても明確な開示が必要だ。
同じ慎重さは速度に関する主張にも当てはまる。調査の範囲を理解しなければ、迅速な判定が持つ意味は限られる。システムが関連する情報源をより少なく確認しているなら、完了時間が短いことは必ずしもより良い仕事を示さない。
比較では、未解決のケースも考慮すべきだ。不確実性を明確に示す製品は、十分な証拠なしに確信に満ちた回答を出す製品より有用な場合がある。完了済みの調査だけを評価すれば、この違いを見落とすことになる。
こうした考慮により、競争上の枠組みは現実に根ざしたものとなる。MaveとDropzoneは、同じ運用上の責任をめぐって競争するために、同一のアーキテクチャを採用する必要はない。重要なのは、どのアプローチがセキュリティチームの総作業量を抑えながら、根拠のある判断に到達する助けとなるかだ。
これは、既存のワークフローが依然として重要な比較基準である理由も説明している。新しい製品は、導入する人によるレビューも含め、顧客がすでに行っていることを改善しなければならない。資金調達やデモは企業がその議論に参加する助けとなるが、そこにとどまれるかどうかを決めるのは導入後の成果である。
MaveのシリーズAは、同社がこうした条件で競争するための資源を与える。だが、それは同社をカテゴリーのリーダーと呼んだり、そのアーキテクチャが優れた成果を生むと想定したりする根拠にはならない。こうした判断には、資金調達そのものでは得られない比較可能な証拠が必要だ。
トレーサビリティは役立つが、正しさを立証するものではない
読みやすい調査記録は説明責任を支える一方、結論そのものには依然として独立した検証が必要となる。
Maveは、200を超えるSOCで稼働しており、チームが自動実行と人による承認を管理できるとしている。これらの記述は、報告された導入状況と意図された統制を示すものだ。調査精度の共通指標を示すものでも、各導入で製品がどの程度広範に使われているかを示すものでもない。
導入数は、大きく異なる運用体制の組織を指し得る。限定的な試験導入と広範に採用されたワークフローは、依存度が異なる。こうした文脈がなければ、この数値は運用の深さよりも、報告された到達範囲をより明確に示す。
技術的な不確実性は、導入ラベルにとどまらない。米国国立標準技術研究所は、自信をもって生成される誤った内容を意味するコンファビュレーションを、生成AIのリスクとして挙げている。同研究所の生成AIリスクプロファイルも、生成された説明が誤った出力を人々に信頼させてしまう可能性を警告している。
このガイダンスはMaveに対する評価ではなく、一般的なリスクの枠組みである。その関連性は、買い手がAI生成の調査をどのように解釈すべきかにある。説明が首尾一貫して聞こえても、特に提案された対応がアクセスやシステムの可用性に影響する場合には、裏付けとなる観察結果が必要だ。
トレーサビリティは、この問題の一部に対処する。レビュアーはソフトウェアが確認した内容を検査し、判断を証拠と照合できる。しかし、手順の記録だけでは、必要な問いがすべて投げかけられたことや、各観察結果が適切に解釈されたことを立証できない。
承認コントロールは別の問題に対処する。これは誰がアクションを承認できるかを定めるものだが、その価値はレビュアーが何を受け取るかに左右される。裏付けとなる証拠が不明確であれば、人による承認ステップは意味のある確認ではなく、事務的な形式になり得る。
したがって、有用な評価では、製品が不確実性をどのように伝えるかを検討する。不足している情報、矛盾する観察結果、曖昧なアイデンティティは、見える状態に保たれるべきだ。買い手は、システムが停止するのか、より多くの文脈を求めるのか、範囲を限定した判断を提示するのかを知る必要がある。
権限にも同様の精査が必要となる。記録を閲覧する権限と、デバイスを隔離したりアカウントを無効化したりする権限は異なる。顧客は、これらの責任がどのように分離され、例外が進行中の調査にどのような影響を与えるかを理解すべきだ。
これらの問いはいずれも、Maveの製品に欠陥があることを示すものではない。意図された役割を評価するために必要な証拠を特定するものである。許可されるアクションの影響が大きいほど、観察から承認に至る経路全体を検討する根拠は強くなる。
調査終了後には、実務上のナレッジの問題もある。チームは、将来のレビューに役立つ判断、例外、説明を保存する必要がある。検索可能なナレッジベースはこうした文書化作業を支援する一方、セキュリティコントロールは運用上のアクセスと対応を管理する。
中心的な不確実性は、こうした責任を含めた後でも自動化が労力を節約するかどうかだ。より多くの所見を生み出すシステムでも、アナリストに相当な検証作業を残すことがある。有用な自動化を示すには、信頼できる調査作業がどれだけ完了に至るかを示す必要がある。
顧客の証拠、運用上の境界、継続的な採用を注視する
次に有用なシグナルは、実証された成果、開示されたコントロール、そして顧客が製品への依存を拡大するかどうかに関するものだ。
今後数カ月で最初に注目すべきシグナルは、詳細な顧客の証拠である。有用な事例では、運用環境、調査の範囲、従来のワークフロー、残る人の関与を説明する。記名された事例は、集計された導入数だけよりも主張を評価しやすくする。
最も強い証拠には、日常的な成功例とともに困難なケースも含まれる。レビュアーは、ソフトウェアが何を処理し、どこで支援を必要とし、チームがその境界をどのように認識したのかを理解する必要がある。慎重に範囲を定めた結果は、すべてのアラートを調査するという広範な主張よりも多くの情報をもたらすことがある。
こうした開示は、Maveのアーキテクチャが既存システム全体で実用的な価値を生むという論拠を強める。大規模な再構築や反復的な手作業での修正を示す証拠は、その論拠を狭める。この違いは、調査の物語を生成できるかではなく、システムがどれだけの信頼できる作業を完了するかに関わる。
2つ目のシグナルは、運用上の境界に関する詳細の拡充だ。買い手は、権限、利用できない接続、保持される証拠、承認時の挙動を説明する文書に注目すべきである。こうした詳細があれば、成功したデモの外でプラットフォームがどのように動作するかを評価しやすくなる。
明確な境界は、エンタープライズチームが不完全な条件下でも予測可能な挙動を必要とするため、Maveの立ち位置を支えることになる。曖昧な説明では、統合に伴う負担を評価しにくいままとなる。このシグナルは、企業が約束した特定の機能リリースではなく、開示された挙動に関するものだ。
3つ目のシグナルは、継続的な採用である。顧客が更新し、調査対象を拡大し、追加の承認済みワークフローを委ねるという証拠は、運用上の依存が強まっていることを示す。重要なのは、導入数の増加とあわせて、実際の利用で何が変わったのかという点だ。
拡大についても、慎重な解釈が必要である。追加のアクセスは信頼を反映する場合があるが、買い手はどの責任が引き続き人に残るのかを知る必要がある。より完全な全体像は、利用拡大をレビューの労力、エスカレーションの品質、例外の処理と結び付けるだろう。
これらのシグナルには論理的な順序がある。顧客の証拠が有用性を確立し、運用の詳細がその有用性がどのように維持されるかを示し、継続的な採用がその取り決めに価値が残るかを示す。いずれも、Maveが既存プラットフォームを置き換える、あるいはすべての競合を上回ると予測する必要はない。
MaveのシリーズAを追うセキュリティリーダーは、まずチームが最も確実に完了させにくいワークフローから検討すべきだ。証拠がどこに存在するか、どの判断に人による説明責任が必要か、自動化された所見にどれほどのレビューが求められるかを特定する。そのうえで、ベンダーの主張をその運用上の実態と照らし合わせる。不確実性が表れる完了済みの調査を求め、システムが停止またはエスカレーションしたケースも含める。記録が提案された対応を裏付けるか、別のアナリストもその流れを追えるかを検討する。有用な次のステップは、こうした問いに答える証拠を求めることだ。調査プロセスのどの部分ならソフトウェアに完了を委ねられるだろうか。そして、その信頼を拡大する前に何を確認する必要があるだろうか。
