サイバーモデルとは何か？そのカテゴリーと、実際に何を変えるのか

毎週3つの製品が「サイバーモデル」と呼ばれているが、共通点はほとんどない。1つは学習データにセキュリティ関連コーパスを組み込んだ汎用モデル。1つは、サンドボックス、ファザー、リトライを付与するループで包んだ普通のモデル。1つは、他社と同じモデルを検証フォームの後ろに置いたもの。このうち別のモデルなのは最初の1つだけだ。残り2つは製品上の判断——場合によっては良い判断——であり、同じフレーズでマーケティングされている。だからこのカテゴリは比較を難しくしている。3つのうちどれを測定したかを明記していないベンチマーク表は、明記している表と比較できない。そしてほとんどの表は明記していない。本稿は、その区別について、また本当に最初のカテゴリに属する少数のモデルについて、そしてセキュリティチームがその答えをどう扱うべきかについてのガイドである。また、400件のエージェントインシデントがカタログ化されているAIインシデントアーカイブの背後にあるカテゴリ観でもあり、そこでは「問題だったのはモデルか、それともデプロイか」という問いが絶えず出てくる。

そのフレーズが対象とする3つの事柄

運用上重要な違いから始めましょう。ベンダーがその仕組みを構築したとき、何が変わったのか。

セキュリティ向けに訓練済みとは、重みが変化したという意味です。セキュリティ関連のコーパスが訓練データの混合に加えられ、ベースはすでに高い能力を持つ汎用モデルであることが多く、その結果得られるモデルは、セキュリティ知識がボトルネックとなるタスク——クラッシュを読む、メモリレイアウトについて推論する、大きな差分の中から脆弱なパターンを認識する——において測定可能なほど異なります。このグループのモデルは通常、CyberGymやCyberSecEvalのようなセキュリティ特化ベンチマークに対して報告され、オープンウェイトの場合もAPIのみの場合もあります。

ハーネスで包まれているというのは、ループが変わり、モデルは変わっていないことを意味する。ベンダーはサンドボックス、ツール、リトライロジック、プランナー、場合によってはファザーを追加し、システムがよく設計されているためにセキュリティタスクで高性能を発揮するシステムを構築した。これは正当で、しばしば過小評価される製品である。また、スコアが曖昧になるカテゴリーでもある。なぜなら、その数値はモデルと同じくらいハーネスに属しており、ハーネスは独立して交換できるものではないからだ。

アクセス制限付きとは、扉が変わったという意味だ。モデル自体は公開されているものと同一かもしれない。異なるのは、利用を制限する条件の下で、認可された業務を行う検証済みの事業者でなければならないという点だ。これはポリシー製品であり、擁護可能なものではあるが、そこから能力の主張は導かれない。悪用すれば危険で、正しく使えば安全なモデルは、より高能力になったのではない。より制御されたものになったのだ。

実務上の帰結として、あるモデルが「サイバーモデル」だと読んだとき、次に問うべきはその三つのどれなのかということです。というのも、その答えによって、あなたが買っているのが能力なのか、エンジニアリングなのか、それとも許可なのかが決まり、それぞれ価格も故障の仕方も異なるからです。

なぜそのカテゴリーがそもそも存在するのか

セキュリティ業務は、汎用モデルが一貫性なく示す2つの特性に異常なほど敏感だ。それは、読まれることを想定せずに書かれたコードに対する長文脈推論と、役に立つ程度に詳細な攻撃の説明をいとわない姿勢である。前者は能力の問題であり、このグループのモデルが数十万から数百万トークンのコンテキストウィンドウをうたう傾向がある理由でもある。後者は安全性の問題であり、このカテゴリがアクセス制御と絡み合っている理由でもある。

コードベースについて優れた推論ができても、動作する概念実証（PoC）を書くことを拒むモデルは、トリアージには役立たない。なぜなら、概念実証こそが証拠だからだ。概念実証を自由に書くモデルは、防御側にとって有用であり、防御側でない者にとっても同じくらい有用である。サイバー向けに調整されたモデルは、事実上、この緊張を解消しようとする試みであり、狭めるのは誰が問い合わせできるかであって、何を答えられるかではない — これは一貫した設計だが、モデル層で強制するのは難しい。強制は重みの変更ではなく検証プロセスだからだ。

機能が実際に論じられている箇所

サイバー向けにチューニングされたモデルが主張する利点は具体的で検証可能であり、通常は形容詞で議論する分野にあって清々しい。繰り返し挙がるのは、リポジトリ全体や監査証跡を一度に取り込む長いコンテキスト、パイプライン利用向けの構造化出力、自動化ワークフロー内に収まるほど安定したツール呼び出しや関数呼び出しだ。これらはモデルに関する主張であると同時にエンジニアリングに関する主張でもあり、自分のコーパスに対して半日で検証できる。

評価側は独自の機関を育ててきた。Wiz ResearchはCyber Model Arenaを運営しており、基盤モデルと標準的なハーネスから構成されるAIエージェントを実世界のサイバーセキュリティタスク全体で評価し、モデル品質を効率との対比で報告している。成功率を、k回の独立した試行にわたる解くあたりのコスト、時間、またはステップ数に対してプロットする。この枠組みは丸ごと採用する価値がある。というのも、生の合格率が隠すもの、すなわち2つのエージェントが同じ成功率に達しても解くあたりのコストは大きく異なり得るという事実を捉えているからだ。そして高コストな方は、しばしば予算をリトライにつぎ込んだ方である。

その構成が何を意味するかに注目してください。これはモデルではなくエージェントのベンチマークであり、基盤モデルとハーネスを組み合わせたもので、まさにこのカテゴリーが抱える曖昧さそのものです。アリーナは定義の中でハーネスを明記することで、その点について誠実です。ほとんどのローンチ投稿はそうではありません。

アクセスゲート、そしてなぜそれがこのカテゴリーの真の境界なのか

サイバー向けに調整されたモデルが実際にどのように提供されているかを見ると、検証ゲートはどのベンチマーク数値よりも決定的です。なぜなら、それは誰が評価を実行できるかをそもそも左右するからです。パターンは一貫しています。事業者確認のステップ、利用を認可されたセキュリティ業務に制限する条件、そしてアクセスが記録される対象となる許容利用ポリシーです。

そのパターンには、たとえサイバーモデルを決して購入しなくても、盗む価値のある設計上の詳細が2つある。1つ目は自己申告ではなく事業者による検証である。チェックボックスは説明責任の仕組みではないからだ。2つ目はゲートをランタイム制御と同じ場所に配置することだ — モデルを保持する同じゲートウェイが、ファイアウォール、ガードレール、ログ記録も保持するため、権限と執行が一箇所に置かれる。トラフィックとは別のシステムにある検証ゲートは、監査できないゲートである。

私たち自身のサイバー層もその形に従っています。攻撃的な作業にはモデル、防御的な作業にはゲートウェイ制御、そしてその両方の手前に検証を置くという形です。これは「このモデルをただ呼び出せばいいのか」という問いへの誠実な答えでもあります。攻撃的な層については、アクセスとは誰かがあなたについて下す判断であり、APIリクエストのフィールドではない、というのが答えです。

サイバーモデルにはどのようなものがあり、どう見分ければよいですか

その数は頭に収まるほど少なく、ベンダー別ではなく上記の3つのカテゴリーで分かれます。

• 真にサイバー向けにチューニングされたモデル。 セキュリティに重点を置いたデータでトレーニングされ、通常はCyberGymやCyberSecEvalで報告され、クラッシュ読解およびパッチ作成タスクで測定可能な違いがある。一部はオープンウェイトで、ローカル評価が可能；一部は検証中のAPI専用。

• セキュリティ行動が強力な汎用モデル。その作業に合わせてチューニングされていなくても、たまたまその作業が得意なフロンティアモデル。同じモデルが残りの仕事もこなしてくれるため、防御側にとってはしばしば正しい選択となります。

• エージェント製品。モデルに加え、サンドボックス、ファザー、プランナーといったセキュリティ専用のループを組み合わせ、システムとして提供されるもの。これらはモデルのベンチマークではなく、1件の解決あたりのコストと、失敗時にループがどう振る舞うかで評価すべきだ。

• 上記のゲート付きバージョン。 同じモデルで、アクセスは制限されています。ゲートが変えるのは誰が使用できるかであり、何ができるかではありません。

セキュリティチームにとって実際に重要な比較は、モデル対モデルであることはほとんどない。重要なのは、必要な作業が知識依存なのか、それともループ依存なのかということだ。監査レポートを読んでエクスプロイトチェーンについて推論するのは知識依存であり、チューニングされたモデルに有利だ。ファザーを6時間動かしてクラッシュをトリアージするのはループ依存であり、優れたエンジニアリングに有利だ。実際のプログラムのほとんどは両方を必要とする。だからこそ有用な調達上の問いは、「どのモデルが高いスコアを出すか」ではなく、「この2つの仕事のどちらのために買うのか」なのだ。

導入する前に確認すべきこと

カテゴリー決定とマーケティング決定を分ける5つの問い。

• 何が変わったのか — 重み、ループ、アクセス？ ベンダーは一文で答えられるはずです。「ループ」が答えなら、その製品を製品として評価してください。

• どのベンチマークを、誰が、どのハーネスで実行したのか？ ハーネスなしのCyberGymの数値は、再現できない構成についての数値にすぎない。

• 合格率ではなく、1件の解決あたりのコストはいくらか？ Wizの捉え方が正しい。同じ成功率の2つのエージェントは、同じ買い物ではない。

• ゲートを通過できなかった場合、ゲートはどう動作しますか？検証済みのアクセスに依存するあらゆる導入では、偽陰性が発生したときに何が起こるかを説明すべきです。なぜなら、偽陰性となるのはあなた自身のエンジニアだからです。

• 何ができないのか？ 防御専用のバリアントは自らの限界を明記しており、そうした明記自体が特長です——攻撃に転用できないモデルは、転用できるモデルとは異なるリスク対象となります。

カテゴリーは実在しており、能力の違いも実在している。そして混乱の大半は、3つの異なる製品が同じ名前を共有していることに由来する。重みとループとドアを切り分ければ、比較表は矛盾したものではなくなり、それぞれ異なる対象について語るものになる——セキュリティチームがそれらを使って判断を下せるのは、まさにそうした条件下だけだ。