CoreWeaveとCrowdStrikeの提携、AIワークロードのセキュリティを拡大
CoreWeaveとCrowdStrikeは11月2日、既存のAIクラウドに関する関係へ、より明確な運用セキュリティの提供内容を加え、提携を拡大した。CoreWeave CrowdStrike partnershipは、本番環境へAIを導入する顧客向けに、ワークロード保護とマネージドセキュリティサービスを組み合わせる。その重要性は、インフラストラクチャと、脅威の調査・封じ込めを担う担当者を結び付ける点にある。
今回の発表は、セキュリティをAIコンピューティングと並ぶ要素として位置付けていた両社の2025年11月の合意に続くものだ。この拡大により、その関係にはより具体的なサービス構成が与えられた。エンタープライズの購入者にとって中心的な問いは、統合された提供内容が実際にどこまで運用上の責任を軽減するかとなる。
AWSは、対応するクラウドワークロード向けの監視をすでに提供しているため、有用な比較対象となる。CoreWeaveのアプローチは、特化したAIインフラストラクチャを外部のセキュリティプラットフォームおよびマネージドの専門知識と組み合わせるものだ。これにより別の購買選択肢が生まれる一方、購入者には、対象範囲、対応権限、アプリケーションセキュリティを理解する責任が残る。
CoreWeave CrowdStrike partnershipが追加するもの
両社はバルセロナで開催されたFal.Con Europeで、この拡大を発表した。AI workload protectionに関する発表では、Falcon Cloud Security、Falcon Adversary OverWatch、Falcon Complete Cloud Security、CrowdStrike Elite Supportという4つの構成要素が示されている。
両社によれば、これらの構成要素は、クラウドワークロード、コンテナ、グラフィックス処理ユニットのクラスター全体を保護する。コンテナはアプリケーションとその依存関係をまとめてパッケージ化するものであり、GPUクラスターは、高負荷なAIタスクに使用されるコンピューティングリソースを接続する。提供内容には、継続的な脅威ハンティング、マネージドの調査と修復、専門的なサポートも含まれる。
具体的な変化は、CoreWeaveのワークロードを中心に据えた、セキュリティ製品と運用サービスの明確な組み合わせである。
これらの機能は、インシデントの異なる段階に対応する。保護機能は、不審な活動を特定または阻止しようとする。脅威ハンティングとは、自動アラートだけでは足りず調査に値する活動を含め、攻撃者の兆候を能動的に探すことを指す。
マネージド検知・対応では、脅威を調査し、対応を調整する人員が加わる。サポートは、顧客による基盤セキュリティ製品の運用を支援する。ソフトウェアへのアクセスが、誰が封じ込めの判断を下すかを定めるわけではないため、これらの責任を区別しておくことは重要だ。
両社の2025 cloud partnershipは、CoreWeaveのインフラストラクチャとFalconの保護を組み合わせることをすでに説明していた。この経緯から、今回の発表は関係の始まりではなく拡大といえる。また、現在言及されるすべてのセキュリティ機能を新たに生み出されたものとして扱わないよう注意を促すものでもある。
この違いは、エンタープライズ向けの発表を評価する際に重要となる。パートナーシップは、新たな検知手法を導入せずとも、サービスのパッケージ化、提供体制、顧客アクセスを通じて深化し得る。購入者は、自分たちがどの種類の変化を評価しているのかを理解する必要がある。
CoreWeave AI securityにとって、関連する進展はより明示的な運用モデルだ。インフラストラクチャの顧客は、調査できる関連セキュリティ機能の明確な組み合わせを得る。それが導入を簡素化するかどうかは、それらの機能が自社環境や既存のセキュリティ体制にどう適合するかに左右される。
エンタープライズAIアプリケーションの承認プロセスを考えてみよう。インフラストラクチャチームはコンピューティング容量を確認する一方、セキュリティチームは監視、エスカレーション、インシデント対応を別途検討するかもしれない。連携された提供内容により、こうした議論をより早い段階で集約できる可能性がある。
これは構成から導かれる分析上の含意であり、測定された顧客成果ではない。発表自体は、顧客がどれほど承認時間を短縮できるかを示していない。また、すべてのワークロードが自動的に同一の保護を受けることも立証していない。
この区別により、ニュースを適切な規模感に保てる。両社はより広範な共同提供を説明しており、これは検証可能な進展だ。その運用上の価値を示すには、導入事例、サービス文書、顧客体験からの証拠が必要になる。
本番AIでは、インフラストラクチャチームとセキュリティチームが同じ時間軸で動く
最も直接的な圧力を受けるのは、不審な活動が介入を正当化するかを判断しながら、AIアプリケーションの可用性を維持しなければならないチームだ。
実験的なアプリケーションなら、顧客サービスのワークフローでは受け入れられない中断も許容できる。従業員や顧客がそれに依存するようになると、セキュリティ上の判断は可用性に関する判断になる。封じ込め措置は情報を保護できる一方、事業が継続を期待する業務を中断させる可能性がある。
この緊張関係が、マネージド対応がこの話題に含まれる理由を説明している。アラートだけでは、アプリケーションの実行を停止すべきかどうかは決まらない。誰かが証拠を評価し、事業上の文脈を理解し、行動する権限を持つ必要がある。
プラットフォームエンジニアにとっては、コンピューティングホスト上の予期しないプロセスが懸念事項かもしれない。アプリケーション所有者にとっては、重要な業務処理中のサービス中断が問題となる可能性がある。セキュリティ対応担当者にとっての懸念は、それらのチームが責任について議論している間に侵入を継続させてしまうことだ。
これらは説明のための運用状況であり、いずれかの企業に関する報告済みのインシデントではない。新たなセキュリティベンチマークがなくても、インフラストラクチャと対応サービスを組み合わせることが重要になり得る理由を示している。
したがって、エンタープライズの購入者は、技術的な決定だけでなく調整上の課題にも直面する。サービスが有用な検知結果を生み出しても、それをアプリケーションの所有者と結び付ける作業が顧客側に残る場合がある。その残された作業が、調査が効率的に進むか停滞するかを決める。
関連する責任分担には、アクセス権限、ソフトウェア変更、復旧に関する判断が含まれる。プロバイダーは、不審な活動を特定しても、それが承認済みの実験を反映したものかどうかを把握していない可能性がある。社内チームは実験を理解していても、影響を受けたインフラストラクチャからの証拠を見ていない可能性がある。
連携されたサービスは、こうした視点が迅速に交わる場合に価値を持つ。情報が切り離されたサポートチャネルを経由しなければならない場合、その有用性は低下する。実務上の帰結は、パートナーシップの見出しの広がりではなく、提供体制に左右される。
本番AIは、コンピューティング環境を超えた依存関係も生む。アプリケーションは文書を取得し、外部サービスを呼び出し、または従業員アカウントを通じて行動する可能性がある。インフラストラクチャを保護することはこれらのワークフローを支えるが、アプリケーション所有者は依然として、許可された挙動がどのようなものかを説明する必要がある。
ナレッジワーカーにとって、この違いは身近な業務に現れる。社内文書を取得するアシスタントには、ホスティング環境にセキュリティ監視があったとしても、適切なアクセス制御が必要だ。インフラストラクチャと文書へのアクセス権限は、同じ事業リスクの異なる部分に対処する。
searchable knowledge baseを維持するエンジニアリングチームも、関連する情報課題に直面する。インシデント対応の判断は、システム、所有者、承認済み変更に関するアクセス可能な文書に依存する。文書化は対応プロセスを支援するが、セキュリティ制御の代替にはならない。
拡大された提供内容は、購入者に対し、導入前にこうした境界を明確にするよう促す。セキュリティチームには明確なエスカレーション経路が必要だ。インフラストラクチャチームは、対応担当者が実行できる介入を把握する必要がある。
事業所有者も、そうした介入の結果を理解する必要がある。この共通理解があって初めて、継続的な監視は組織が信頼できる運用体制となる。
SafeMindが関係を双方向にする
この関係には第二の接点がある。CoreWeaveはCrowdStrikeのセキュリティAIに関する取り組みにコンピューティングインフラストラクチャを提供している。CrowdStrikeは2026年9月1日、セキュリティモデル群とそれを支えるソフトウェアとしてSafeMindを発表した。
そのsecurity model architectureには、NVIDIA Nemotronを用いて構築され、CoreWeaveがトレーニングと推論を支援するモデルが含まれる。トレーニングはモデルが学習する挙動を形成し、推論はそのモデルを新たな入力に対して実行する。
CrowdStrikeは、ツールと実行を組織化するソフトウェアであるハーネスを通じて、攻撃側と防御側のモデルが稼働すると説明している。これらは同社によるシステムの説明である。顧客環境全体での有効性を独立して立証するものではない。
CoreWeaveは、自社クラウドに関連する保護を提供するセキュリティベンダーにインフラストラクチャを供給している。
この相互的な取り決めは、単純な紹介関係以上の実体をパートナーシップに与える。各社は相手の製品提供に参加している。同時に、読者が個別に評価すべき異なる主張も生み出す。
CoreWeave上でセキュリティモデルを実行していることは、インフラストラクチャ上の関係を示す証拠である。CoreWeaveのワークロードを中心とするセキュリティサービスを提供していることは、顧客保護の取り決めを示す証拠である。どちらの事実も、それだけで他方の性能を確立するものではない。
たとえば、モデルがコンピューティングプラットフォーム上で正常に動作したとしても、無関係な顧客環境で包括的な監視が行われていることを証明するわけではない。同様に、効果的なワークロード保護が、AIセキュリティモデルに関するすべての主張を独立して裏付けるわけでもない。
この切り分けは、AIに関する発表がインフラストラクチャ、モデル、サービスを一つの物語に組み込むことが多いため重要だ。その組み合わせは商業的に有用であり得る一方、各層には異なる技術的証拠が必要となる。
CoreWeave CrowdStrike partnershipにおいて、この相互的な構造は継続的なエンジニアリング協業への動機を生む。両社には、高負荷なAIワークロードがセキュリティ運用とどのように相互作用するかを理解する理由がある。これはビジネス上の解釈であり、特定の統合成果の証明ではない。
顧客価値は、その協業から何が生まれるかに左右される。関連する証拠には、導入ガイダンス、明確なサポート境界、現実的なセキュリティ演習における挙動の文書化が含まれる。こうした資料があれば、パートナーシップの構造と、購入者が実際に行う判断を結び付けられる。
同じ区別はCrowdStrike cloud securityにも当てはまる。広範なプラットフォーム関係は、調達とサポートの整理に役立つ可能性がある。それでも顧客には、自社環境で有効になる具体的な機能についての証拠が必要だ。
したがって、この提供内容を評価するエンタープライズは、サプライヤー間の関係と自社のサービス要件を分けて考えるべきだ。CrowdStrikeによるCoreWeaveの利用は、顧客のアプリケーションがCrowdStrikeのワークロードに似ていることを自動的に意味しない。異なるソフトウェア、権限、運用慣行は、異なるセキュリティ要件を生む。
有用な説明責任に関する問いもある。問題がインフラストラクチャとセキュリティの境界をまたぐ場合、サプライヤーは明確なプロセスを通じて共同で調査できるのか。この運用上の連携は、見出しを飾るモデル性能の主張がなくても、意味のある利点となるだろう。
SafeMindは、両社がAIの本番運用を軸に事業を構築しているため、この関係を戦略的に興味深いものにしている。より強力な顧客向けの訴求は、この関係が導入と対応をどのように改善するかを示しつつ、営業協議の後にも理解可能な責任範囲を維持することから生まれる。
AWSはセキュリティ提供を比較する実用的な基準となる
競合比較の対象はAIコンピューティングへのアクセスだけではない。エンタープライズの購入者は、アプリケーションの運用に必要な周辺サービスも比較する。セキュリティ監視はその評価の一部である。
AWSは、サポート対象のワークロードの実行中にアクティビティを分析するGuardDutyによるクラウドランタイム監視を文書化している。そのドキュメントでは、オペレーティングシステムのアクティビティ、ネットワーク動作、ファイルに対する可視性を説明している。
サポート対象の環境にはAmazon EC2仮想マシンと指定されたコンテナサービスが含まれる。AWSは、AWS Fargate上で実行されるAmazon EKSクラスターをサポートしないことなどの制約も文書化している。EKSはAWSのマネージドKubernetesサービスであり、Kubernetesはコンテナ化されたアプリケーションを連携・管理する。
この例は、包括的なクラウドセキュリティというラベルよりも、対象範囲の詳細が重要である理由を示している。製品があるサービス群をサポートしていても、特定のデプロイ構成を除外することはあり得る。購入者は実際のアーキテクチャと文書化された対象範囲を比較する必要がある。
CoreWeaveはここで、顧客がセキュリティの専門知識を得る方法を含む、AIインフラを取り巻く完全な運用体制で競争している。
AWSはプロバイダー固有の監視に関する基準を提供する。CoreWeaveの発表は、外部のセキュリティプラットフォームおよびマネージドサービスと連携する専門インフラプロバイダーを説明している。これらのアプローチは、異なる統合および組織上の選択を生む。
この発表は、いずれのアプローチも脅威をより適切に検知できることを立証していない。デプロイの労力や対応品質に関する比較可能な評価も示していない。優位性を主張するには、パートナーシップ自体を超える証拠が必要となる。
すでにCrowdStrikeのクラウドセキュリティを利用している顧客にとって、関連するCoreWeaveの提供は既存のセキュリティプロセスに適合する可能性がある。これは実際の構成とサービス条件を前提とする、組織面での潜在的な利点である。使い慣れたツールは、導入作業を不要にすることなく、学習負担を軽減できる。
別のクラウドプロバイダーの監視を中心に組織化されている顧客には、異なる構成の方が自然に適合する場合がある。既存の調査手法やスタッフの経験は、新しいサービスの価値に影響する。関連する比較には、セキュリティ上の発見事項を事業上の意思決定と結び付けるために必要な作業も含まれる。
エンタープライズ評価では、検知とマネージドレスポンスも区別すべきである。監視サービスは疑わしい動作を特定する。マネージドサービスは、合意された対象範囲と権限に従って運用責任を追加する。
これらの機能を互換可能なものとして比較すれば、購買判断を歪めることになる。適切な比較では、誰が発見事項を調査し、誰が承認済みの是正措置を実施するのかを含め、同等の責任を検討する。
ここに、CoreWeaveのAIセキュリティ発表の明確な商業的目的がある。これは、購入者にインフラに関する議論と並行したセキュリティの対話を提供する。それによりCoreWeaveは、コンピューティング性能を超えるエンタープライズ要件に対応しやすくなる。
同時に、より広く専門インフラプロバイダーにも圧力をかける。本番デプロイを評価する購入者は、監視、エスカレーション、対応がどのように機能するかを問うことができる。プロバイダーは、社内、パートナー、または顧客自身のチームを通じて提供するかを問わず、信頼できる回答を示す必要がある。
したがって競争上の含意は、評価基準の拡大である。インフラは依然として中心的だが、エンタープライズ対応力には、説明可能な運用モデルも含まれる。このパートナーシップは、名称が明示されたサービスと専門知識を通じてその要件に対応しているが、公正な比較には依然として導入に関する証拠が必要である。
インフラ保護ではアプリケーションのリスクが残る
AIが稼働する環境を保護しても、アプリケーションがその権限を適切に利用することは保証されない。
攻撃者はコンピューティングインフラを標的にできるが、AIアプリケーションも情報を処理し、意思決定を行う。これらの活動は、アプリケーションの文脈を必要とするリスクをもたらす。正当なプロセスであっても、従来型の悪意あるソフトウェアに似ることなく、望ましくない行為を実行し得る。
プロンプトインジェクションはこの違いを示す。これは、攻撃者が制御するコンテンツがAIシステムの動作を誘導し直そうとする場合に発生する。文書やウェブページには、アプリケーションが信頼できない情報として扱うべき指示が含まれる可能性がある。
英国国家サイバーセキュリティセンターのプロンプトインジェクションに関するガイダンスは、この問題に完全な技術的解決策があると想定しないよう注意を促している。安全な設計と運用を通じて、リスクと影響を軽減することを重視している。
このガイダンスは一般的な助言であり、このパートナーシップへの批判ではない。ここでの関連性は、インフラ保護と安全なアプリケーション動作には、関連しつつも異なる統制が必要であるという境界を示す点にある。
例として、文書アシスタントを考えると問題が具体化する。あるアプリケーションに、会社のファイルを読み取り、メッセージを送信する正当な権限があるとする。取得したコンテンツ内の悪意ある指示は、それらの権限の利用方法に影響を与えようとする可能性がある。
監視システムは、疑わしいプロセス活動や予期しない接続を特定できるかもしれない。それ以外は承認済みのワークフローを通じた不正利用を認識できるかどうかは、追加の機能と文脈に依存する。購入者は、AIワークロードを保護するという一般的な約束から、こうした機能を推測すべきではない。
CrowdStrikeは、ポートフォリオの別の領域でアプリケーションおよびエージェントのリスクに取り組んでいる。同社の11月3日のAIエージェント制御に関する発表は、プロンプト、エージェントの動作、ネットワーク活動に関わるFalcon Guardianの機能を説明している。
同社はまた、利用可能な機能と今後の開発も区別している。この別個の発表が重要なのは、製品の提供可否、デプロイ対象範囲、共同提供への含有は別の問いだからである。これは、すべてのGuardian機能がCoreWeaveのパッケージに含まれることを立証するものではない。
したがって顧客には、何を受け取るのかについて正確な説明が必要である。プラットフォーム名は複数の製品を包含する場合がある一方、特定の契約では定義された一部のみが有効になることがある。全面的な包含を想定すれば、発表が裏付けない期待が生まれる。
対応権限についても同様の精査が必要である。封じ込めとは、アクセスの制限や実行停止によって、インシデントの拡大を抑えることを意味する。本番環境では、その決定が正当な業務を中断させる可能性がある。
これは運用上のトレードオフである。広範な権限は対応者による迅速な行動を支援できる一方、顧客は重要なサービスに影響する措置について承認を求める場合がある。いずれの構成も、すべてのアプリケーションに自動的に適切とは限らない。
パフォーマンスにもワークロード固有の証拠が必要である。セキュリティ統制はコンピューティングリソースを消費し、アプリケーションの動作と相互作用する。購入者は、トレーニングと推論のタスクで同一の影響があると想定するのではなく、代表的な条件下での測定を求めるべきである。
これらの問いは、この拡張を否定するものではない。提示された機能をデプロイ判断へと移すために必要な証拠を特定するものである。このパートナーシップには信頼できる運用上の目的がある一方、その有効性は導入、構成、合意された責任に依然として固有である。
エンタープライズの購入者にとって、懐疑的な姿勢は焦点を絞るべきである。提案された構成が、実際のアプリケーションとその依存関係を対象にしているかを問う。そのうえで、利用可能な証拠が、それに割り当てられる責任を裏付けているかを検討する。
デプロイの明確さ、運用上の証拠、導入状況を注視する
CoreWeaveとCrowdStrikeのパートナーシップの次の段階は、発表と顧客運用を結び付ける証拠を通じて評価すべきである。今後数か月で優先すべきシグナルは、デプロイの明確さ、運用上の証拠、顧客導入の3つである。
最も強い検証は、顧客がこの提供をデプロイでき、その境界を理解し、インシデント発生時に効果的に利用できることを示すものになる。
第一に、詳細なデプロイおよびサービスのドキュメントを注視すべきである。有用な資料では、サポート対象の環境、前提条件、顧客の責任、保護を有効化する手順が特定される。また、意図したワークロードが対象となっていることを顧客が確認する方法も説明されるべきである。
そのドキュメントは、このパートナーシップが本番デプロイを簡素化するという主張を強める。購入者は、保護について推測する前に互換性を評価できる。境界が欠けている、または曖昧であれば、統合された提供が調整作業を減らすという主張は弱まる。
利用可能なサービスと自動的な包含の区別は、特に重要である。顧客は、どの機能に個別の有効化や契約が必要かを知る必要がある。明確な回答は、エンタープライズ対応力に関するもう一つの包括的な説明よりも有用である。
第二に、運用上の証拠を注視すべきである。関連する例には、文書化された顧客体験、代表的なパフォーマンス測定、調査と封じ込めを実証するセキュリティ演習が含まれる。これらは製品説明を観察可能な動作と結び付けることになる。
有用な説明では、サービスが何を検知し、誰が調査し、顧客がどのように参加したかが示される。また、制約と復旧に関する判断も説明される。こうした詳細は、他の購入者がその構成が自らの運用に適合するかを判断する助けとなる。
効果的な引き継ぎの証拠は、このパートナーシップの中心的な主張を強める。未解決の責任分担や不明確な対応権限に関する報告は、それを弱める。関連する成果は、共同構成が人々による説明可能な意思決定と実行を支援するかどうかである。
第三に、意味のあるデプロイの文脈を含む顧客導入を注視すべきである。有効化された機能と運用責任を説明する実名顧客は、単独のロゴよりも多くの洞察を提供する。読者が顧客が実際に何を利用しているかを理解できるとき、導入は有益な情報となる。
このシグナルは、財務上の推測とは区別すべきである。この発表だけでは、いずれの企業にとっても重要な収益貢献があることは立証されない。顧客に関する証拠は、事業業績についてより広範な主張を支えることなく、実用的な有用性を検証できる。
これらのシグナルを総合すると、評価を現実に根差したものに保てる。デプロイのドキュメントは、顧客が利用できるものを明らかにする。運用上の証拠は、その構成が意図どおりに機能するかを検証する。導入は、企業がサービス化するだけの価値を見いだしているかを示す。
より広い含意は、AIインフラの購入が対応すべき事項の変化にある。コンピューティング能力はワークロードを支え、監視と対応はその継続的な運用を支える。こうした議論をまとめることは、本番顧客を求めるプロバイダーにとって合理的な一歩である。
CoreWeaveとCrowdStrikeの提携を評価する際は、まず組織が実行する予定のアプリケーションから検討を始めてください。そのアプリケーションがアクセスする情報、実行可能な操作、可用性維持の責任を負う人物を特定します。サプライヤーには、提案するサービスがそれらの責任にどう対応するのかを示すよう求めてください。適用範囲の明確な境界、文書化された対応プロセス、代表的な運用条件に基づく証拠を要求しましょう。この取り決めがニーズを満たすかを評価する際は、インフラ保護とアプリケーション権限を分けて考えてください。有用な問いは、この拡張された提供内容が、チームに本番AIを運用するためのより明確で実行可能な方法をもたらすかどうかです。その責任を任せる前に、組織にはどのような証拠が必要でしょうか。
