セキュリティアナリストが隣の席でこう言う。「このサブネットでSMBの設定ミスをスキャンして」。サブネットとは一つのネットワークを細かく区切ったIPアドレスの区画で、SMBはWindowsのコンピュータ同士がファイルをやり取りするときに使う通信規約だ。人間のアナリストにとって、この一言はたやすい。どのツールを使うかが頭に浮かび、手が勝手にコマンドを打つ。
AIにやらせると、ここで道が分かれる。「どのツールを使うか」はそれなりに答える。ところが、そのツールを実際に動くKali Linuxのコマンド一行へ落とし込む段になると、しばしばつまずく。Kaliはセキュリティ点検に使うツールを数多くそろえたLinuxだ。ただし最初から全部が入っているわけではなく、公式には標準構成(kali-linux-default)と全ツール構成(kali-linux-everything)が分かれていて、既定ではその一部がインストールされる(Kali公式ドキュメント)。これらのツールの多くはCLIで使う。CLIは文字でコマンドを打ってプログラムを動かす方式だが、手加減がない。オプション名の綴り一つ、ダッシュ(-)一つか二つの違いで、コマンド全体が実行されなくなる。
そのためこの問題は、二つの異なる能力に分かれる。一つはツール選択 — どのツールを使うかを選ぶ仕事。もう一つは引数構成 — 選んだツールを正確に呼び出す仕事だ。引数とはコマンドの後ろに付くオプションと値のことを指す。KaliBenchは、この二つを切り離して別々に採点したベンチマークだ。1,642個のツールにまたがる質問-コマンドのペア8,504件で、24種のモデル構成を評価した。結論から言うと、AIが崩れるのは選択ではなく構成の側だった。
今出回っている「AI関数呼び出し」の評価はかなり成熟している。関数呼び出しとは、モデルが決められたツールを選び、入力値を埋め込む方式だ。ところがここには隠れた前提が一つある。使えるツールと入力値の形式が、スキーマとしてあらかじめ書かれているということ。スキーマとは「このツールはこういう入力をこういう形式で受け取る」と定めた仕様だ。スキーマがあれば、モデルは空欄を埋めるだけでよい。
セキュリティの現場はそうではない。ツールが数百、数千個もあるのに、その膨大なスキーマをプロンプトに全部入れるのは分量的に不可能だ。モデルはスキーマなしに、自力でツールを選び、引数を推論して、文法に合うコマンド一行を丸ごと書き上げなければならない。空欄を埋めるのではなく、白紙に書くことに近い。KaliBenchはまさにこの「スキーマなしのツール使用」を精密に狙う。著者らは、この領域をこう測るベンチマークは初めてだと述べている。
既存の評価がこの地点を見落としてきた理由もはっきりしている。知識を問う評価は、モデルが何を「知っているか」までしか測らず、手を動かす能力は見ない。逆に、ハッキングチャレンジを最後まで解かせる評価は、計画・実行・結果解釈・エラー復旧を一括りにして見る。失敗しても、ツールを選び間違えたのか、引数を間違えたのか、結果を読めなかったのかを切り離せない。KaliBenchは、その一塊から「コマンド一行を正確に書く」能力だけを孤立させて取り出す。
コマンドは<ツール名> <引数群>の形だ。引数には二種類ある。オプション引数は-で始まり、順序が自由で、別名が許される。位置引数は値だけがあり、順序が固定だ。
採点は、完成した料理の味を見る代わりに、調理の過程を段階ごとに分解して見る。先の「SMBの設定ミスをスキャンして」を例にとると、モデルが出した一行を三つに分解する。スキャンツールを正しく選んだか(ツール正確度)。SMB点検を有効にするオプションフラグを正しく付けたか(オプション引数F1) — このとき採点はフラグ名を見るが、-oと--outputのように同じ意味の別名は一つのフラグとして扱う。対象サブネットの値が正しく入ったか(位置引数F1) — 並び順は問わず、値の多重集合が一致するかだけを見る。ここでF1とは、取りこぼしたものと余計に入れたものを同時に反映する厳しい正確度の指標だ。抜かしても減点され、無駄に多く入れても減点される。そして「完全一致」はこの三つとは別の指標だ。正規化したコマンドの引数の値と、その組み合わせまでそのまま合ってはじめて1点を与える。だから三つの構成スコアがすべて満点でも、完全一致が保証されるわけではない。
こう分けておけば、コマンドが間違ったとき、三つのうちどこで間違えたのかがすぐに突き止められる。そして決定的なことに、採点はコマンドを実際には動かさない。シェル文法をパースして — 文を文法単位に分けて解釈して — 正解にあらかじめ記録されたツール名・オプション・位置引数と、要素ごとに比較する。この設計が、後に来る学習の鍵になる。
このベンチマークの核心となる仕掛けは「実行なしの検証可能な報酬」だ。コマンドを動かしてみなくても、正解と構造を照らし合わせて点数を付けられるという意味だ。この仕掛けを使えるようにするために、最初に作ったデータの約70%を捨てる骨の折れる工程を経た。
出発点はKali公式ドキュメント(ツール2,372個)だった。大きな生成モデルに、このドキュメントを根拠として質問-コマンドのペアを2万7千件あまり作らせた。ところがドキュメントを渡したにもかかわらず、でっち上げがひどかった。初期点検で、生成されたコマンドの半分以上が、存在しない事実を作り出していたり、間違ったオプションを付けていたりした。
そこで濾過網を三重に積み上げた。まずAI検証者が、すべてのフラグがドキュメントに実在するか、質問を忠実に移したかを確認した(ここだけで半分以上が脱落)。次に、実システムから隔離された仮想の実験空間(Dockerサンドボックス)でコマンドを一つずつ動かし、存在しないツールや間違った引数でエラーが出たら捨てた。最後に、最も強いモデルがドキュメントを受け取っても失敗したケースは、人が直接目を通した。そうした失敗はモデルのせいというより、データの欠陥である確率が高いからだ。最後に、意味が重なるペアをまとめ、代表だけを残した。
この関門をすべて通過したのは8,504件、最初の量の30.7%だけだ。これを評価用5,000件(ツール1,642個をすべてカバーする)と訓練用3,504件に分けた。正解コマンドがすでにサンドボックス実行でふるいにかけられており、採点が機械的なので、学習時にモデルの出力を毎回実行しなくても点数を付けて報酬を与えられる。CLIを動かさずに強化学習を回すわけだ。
ベンチマークのもう一つの軸は、「ツール情報をどれだけ与えるか」を三段階に分けた点にある。
UからRへ進むとツール選択が楽になる。RからHへ進むと引数構成が楽になる。だから点数がどの区間で跳ねるかを見れば、モデルがツールを選べずに間違えたのか、引数を組めずに間違えたのかが数値で表れる。評価対象は、汎用14種とセキュリティ特化7種を含む24構成だ。
| 指標(平均) | U | R | H |
|---|---|---|---|
| 完全一致 | 22.3% | 28.3% | 73.1% |
| ツール正確度 | 72.0% | 95.2% | 94.6% |
| オプション引数F1 | 45.1% | 48.7% | 87.8% |
| 位置引数F1 | 61.1% | 68.2% | 90.1% |
| 総合スコア | 59.4% | 70.7% | 90.8% |
表を二つの区間に区切って読むと、話がくっきりする。
UからRへ。候補を20個に狭めてやると、ツール正確度が72.0%から95.2%へと跳ね上がる。ツール選びは少し手を貸すだけでほぼ解けるという意味だ。ところが同じ区間で、オプション引数は45.1%から48.7%へとわずかに上がるにとどまる。ツールを正しく選んだからといって、引数まで正しく組めるわけではまったくない。
変化はRからHへ移るときに爆発する。ドキュメントを握らせると、オプションF1が87.8%へ、完全一致が73.1%へ跳ねる。ノーヒントの22.3%から三倍を超える。ボトルネックがどこだったかがここで露わになる。引数構成、その中でもオプション引数だ。
なぜオプション引数がとりわけ難しいのか。モデルはドキュメントからオプション名を探し出せばいいだけではない。-oと--outputが同じ意味であることを文脈から読み取らねばならず、あるツールは--timeout 30は受け取るが--timeout=30は拒むといった微妙な文法の違いを、ドキュメントにはっきり書かれてもいないその規則を、例示コードのニュアンスだけから推論しなければならない。これは非定型のドキュメントから暗黙の文法規則を抜き出す問題だ。自然言語理解を超えて、コード生成に近い推論だ。ドキュメントを丸ごと見せたときにようやく解けたということは、モデルがこの規則を頭の中に持っていないという証拠だ。
モデル別に見るともっと実感がわく。最も強い部類のGLM-5.2がノーヒントの完全一致41.3%、DeepSeek-V3.2が33.0%だ。どの公開モデルもノーヒントで42%を超えられなかった。同じモデルたちが候補20個の中からツールを選ぶ仕事は、Rモードでは GLM-5.2が94.2%、DeepSeek-V3.2が98.3%でこなす。選ぶのはできるのに、正確に呼び出すところで引っかかる。
実行なしの報酬がなぜ役に立つのかは、訓練で明らかになる。著者らは80億(8B)パラメータのセキュリティ特化モデルRedSageを選んだ。そしてモデル全体ではなく一部だけを軽く手直しするLoRA方式で、二つの学習を加えた。一つは正解をそのままなぞって書けるように教える教師あり学習(SFT)、もう一つは点数の高い方へ行動を少しずつ補正する強化学習(GRPO)だ。この補正に使った点数が、まさに先の実行なしの報酬である。
手直しの結果、この80億のモデルが6,850億(685B)パラメータの巨大モデルDeepSeek-V3.2のすぐ目の前まで追いついた。三モード平均の総合スコア79.2%。手直し前の71.7%から7.5ポイント上がった値で、DeepSeek-V3.2の80.2%とはわずか1ポイント差だ。図体が85倍小さいのにである。適切なデータと機械的な報酬さえあれば、小さなモデルもずっと大きなモデルの近くまで行ける。
ただし、この上昇を誇張してはいけない。7.5ポイントは三モードの平均であり、利得は手がかりの少ないU・Rに集中している。ドキュメントを全部握らせるHでは、同格やより大きなモデルを必ずしも上回らない。効果の正体は「ヒントなしでもコマンドをより上手く組めるようになった」側だ。
限界は一か所にまとめて押さえるのがよい。採点が正解コマンドとの構造的一致に頼っているせいで、同じ目標を達する別の有効なコマンドが不当に減点される余地がある。評価がコマンド一行に集中しているため、パイプでコマンドをつなぐ多段作業は範囲外だ。サンドボックス検証は「文法的に動く」ことを確認したのであって、「実戦で通用する」ことを保証しはしない。攻撃・探知ツールが混ざったデータなので、悪用のリスクも伴う。
そこで残る問い。単一コマンドの正確度を引き上げることを目標に据えるのか、それとも複数のコマンドをつないで問題を解く作戦術を教えるのか。目標を知ることと、その目標を正確なコマンドへ落とし込むことは別の能力であり、一行を当てることと盤面全体を運用することもまた別の問題だ。「勝手に全部やってくれるAIアシスタント」という絵が思ったより遠いことを、この研究は数字で見せてくれる。
この問いは我々の仕事でもある。ONTLEは顧客プロジェクトごとにAI PMを付け、要求の受付から実行までを任せる。このPMも結局、人の言葉を機械が実行する動作へ落とし込む仕事をする。KaliBenchが狙ったまさにその隙間だ。
一つの場面を最後まで追ってみよう。顧客がPMにこう言う。「今週のレビューデータから重複を除いて、仕入先ごとに集計して」。PMはこれを集計クエリや呼び出しコードへ落とし込む。検証は二つの層に分かれる。
第一に、規格は機械が見る。PMが出したクエリを実行前にパースし、使える関数・引数の形式に合うかを機械的に照合する。集計関数・日付形式・グループ基準が規格の中にあるかを見る関門だ。KaliBenchの構造採点をそのまま移した形だ。これに加えて、PMに自由記述でクエリを組ませるのではなく、使える「狭いアクション」の使い方ドキュメントを一緒に握らせる。ドキュメントを与えたとき正確度が三倍に跳ねた、あの効果を狙う。
第二に、業務上の意味は人が見る。規格が合っていても、「重複の定義」や「仕入先をまとめる基準」といった判断は、構造採点では捉えられない。この層は機械の関門と分離して、別に確認する。
ここで測るべき数字は、ちょうど二つに絞られる。一つ、狭いアクションのドキュメントを与える前と後に分けて、運用DBに手を付ける前にふるい落とした規格エラーの割合。二つ、同じ前後で、PMの「言葉と行動の不一致」がどれだけ減ったか。注意点も一つはっきりさせておく。セキュリティコマンドでドキュメントが見せた効果が、我々の業務クエリでもそのまま出るとは限らない。だから上の二つの指標を実際に測って確かめるまでは、期待にすぎない。金・クレジットがかかり、取り返しのつかない作業であるほど、実行前の関門の値打ちは大きくなる。
いいえ。F1は、正解コマンドと構造がどれだけ重なるかを要素ごとに測った値です。採点がコマンドを実際には動かさないため、スコアが高くても「文法上、正解に似ている」までしか保証しません。逆に、同じ目標を達する別の有効なコマンドは、正解と構造が異なるため不当に減点されることがあります。これが構造採点方式の原理的な限界です。
理論上はそうです。しかしセキュリティツールは数百、数千個もあるので、そのスキーマをプロンプトに全部入れるのは分量的に非現実的です。KaliBenchが「スキーマなし」の状況をわざわざ扱う理由がここにあります。代わりに現実的な妥協があります — 全スキーマの代わりに、関連するツールのドキュメントだけを選んで一緒に与えることであり、実験ではそれだけで正確度が大きく上がりました。
そう見るのは早計です。小さなモデルの利得はヒントの少ない状況(U・R)に集中しており、ドキュメントを全部与える状況(H)では、同格やより大きなモデルを必ずしも上回りませんでした。また、これはコマンド一行の生成という狭い課題に特化した訓練をした結果です。複数の段階をつなぐ広い作業までそのまま追いつくという意味ではありません。