北米のスタートアップVegaは、企業のセキュリティ運用を担う「エージェント型サイバー防御」の基盤を提供しています。Anthropicが公開した導入事例では、同社がClaudeを推論エンジンとして組み込み、検知・トリアージ・調査・最適化の一連をデータのある場所で回す設計を採ったことと、そこで得られた数値が公表されています。この事例が示しているのは、AIを「高性能なモデルを一つ選んで全部任せる」形ではなく、処理の重さに応じて階層を使い分ける形で組み込んだ設計判断です。AIを実務に載せようとしている日本の事業者にとって、参考になる論点が多く含まれています。
何をしたか：データを動かさずに推論を持ち込む
従来のセキュリティ運用では、各所に散らばったログを一か所に集約してから分析します。Vegaはこの前提を反転させ、データを移さずに分析側を持ち込む構成を採りました。クラウドのオブジェクトストレージ、既存のSIEM、データレイクといった保管先の上で直接処理を走らせるため、移行や取り込みのコストが発生しません。同社はこの基盤をSecurity Analytics Mesh（SAM）と呼んでいます。
共同創業者兼CTOのEli Rozenさんは、事例の中で課題をこう述べています。「AIエージェントは、アクセスできるデータの範囲でしか力を発揮しない。そして多くのセキュリティ基盤は、断片化しているか遅すぎるかのどちらかで、規模を持ったエージェント型防御を支えられない」。つまり、モデルの賢さではなく、モデルに届くデータの構造の側が制約になっていたという整理です。
設計上もっとも参考になるのは、モデルの使い分けです。VegaはClaudeのモデル群（Haiku・Sonnet・Opus）を、処理の階層ごとに割り当てています。ログの解析のように件数が膨大で一件あたりの判断が軽い工程には軽量なモデルを充て、確度の高いアラートに絞られた段階の深い推論にOpusを充てる。Rozenさんはこれを「必要なところに必要なだけの知性を当てられる」と表現しています。単一のモデル系列の中で強度を選べることが、この設計を成り立たせている条件です。
運用面の条件も公表されています。提供はAmazon Bedrock経由で、データを保持しない設定を用いています。通信はVPCエンドポイントを使い、公開インターネットを経由させません。GDPRへの対応として、フランクフルトを拠点とする制御面によるEUデータレジデンシーも用意されました。この対応は3週間かからずに実装されたとされています。加えて、社内のツールとClaude Codeの利用にはAPIを直接使う形をとっています。
Rozenさんは、モデルの選定を後から差し替える前提の意思決定として扱っていない点も語っています。「AIネイティブの企業として、私たちは初日からClaudeのような最先端のモデルと組む前提でVegaを作り、その水準の推論をプラットフォームの基準線に据えた」。既存の仕組みにAIを後付けするのではなく、AIが動くことを前提に基盤の側を設計したという順序です。この順序の違いは、後から効いてきます。データを集約する前提で作られた基盤に高性能なモデルを載せても、モデルが読める範囲は集約済みのデータに限られるためです。
公表されている結果
事例ページで公表されている数値を整理します。調査の速度は最大で44倍。コストは従来型のSIEMと比べて82パーセント低いとされています。あるFortune 500の企業では、トリアージにかかる時間が25分から3分未満へ短縮されました。アナリストの時間はおよそ67パーセントが手元に戻ったと記載されています。
処理規模の例として、17のAWSリージョンにまたがるCloudTrailのログを41秒で走査した事例が挙げられています。手作業を前提とした場合の目安は30分とされており、同じ作業の位置づけが変わる水準です。
導入先の例も公表されています。世界上位の銀行では、それまで費用面で扱えなかった$6 million相当のテレメトリ（VPCフローログ、CloudTrail、Microsoft 365）を扱えるようになりました。あるセキュリティ企業では、シグネチャに基づく既存のツールが見逃していた稼働中のマルウェア感染が見つかっています。Fortune 500の製造業では、大規模に展開したClaude Codeの利用を監視し、AIエージェント特有のリスクを見る用途に使われています。
2026年8月6日には、同社の公式ブログでDetection Skillsという枠組みが公表されました。従来の静的な検知ルールを、継続的に改善されるエージェントのループへ置き換える発想の標準で、detectionskills.io で公開されています。公開時点でVega Researchとパートナーによる50以上のスキルを備えたライブラリ、仕様に沿った検知を作成・検証・書き出しできるサンドボックス、貢献を受け付けるGitHubが用意されました。
この枠組みが示しているのは、検知の知見を「ルールの記述」ではなく「手順を持ったスキル」として扱う考え方です。従来の検知ルールは、条件に合致したら警告を出す静的な記述で、環境が変われば人が書き直す必要がありました。スキルとして持たせると、判断の手順そのものを部品として共有・改良できます。公式ブログでは、この基盤がデータの移行や取り込みの負担なしに、組織が持つデータの上でそのまま動く点が強調されています。マーケティングの領域に置き換えれば、分析の知見を個人のノウハウやスプレッドシートの式ではなく、再利用できる手順として組織に残す発想に近いものです。
なお、Vegaの企業規模や調達額、顧客数の総計は、今回参照した一次情報には記載がありません。導入先も「Fortune 200の企業」「世界上位の銀行」といった記述にとどまり、社名は公表されていません。
日本の実務者が参考にできる点
この事例から持ち帰れるのは、AIの導入を「どのモデルを選ぶか」ではなく「どの工程にどの強度を当てるか」の設計問題として扱う姿勢です。VegaはClaudeの階層を工程ごとに割り当てることで、件数の多い前段は安く速く、判断の重い後段は深く、という配分を実現しています。日本の事業者がAIをマーケティングや運用に組み込む場合も、同じ整理は使えます。問い合わせの一次仕分けと、こじれた案件の分析に、同じ強度のモデルを充てる必要はありません。
もうひとつは、データを動かさない構成です。分析のためにデータを集約する工程は、コストだけでなく、扱いの責任と遅延も生みます。集めた先で誰が管理するのか、どこの国に置かれるのか、消したいときに消せるのかといった論点が、集約した瞬間に発生します。手元の環境で完結できる部分がどこまであるかを先に確認しておくと、後から選べる範囲が広がります。Vegaが提供の経路やデータの所在を事例の中で明示しているのも、この論点が導入の可否を左右するからだと読めます。
最後に、公表された数値の読み方について補足します。ここに挙げた倍率や削減率は、Vegaの顧客環境で測られた値であり、前提となる規模や既存の構成に依存します。同じ施策が同じ効果をもたらすことを示すものではありません。自社で検討する際は、比較の起点になっている「従来の状態」が自社と近いかどうかから確認してください。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。