オープンウェイトLLMは「Kali Linux」をまだ使いこなせない——正確なコマンド生成は42%未満、実行なしで検証できるベンチマーク「KaliBench」

はじめに：AIエージェントにセキュリティツールを任せられるのか

セキュリティ運用の現場では、分析者が頭に描いた「意図」を、実際に動くコマンドへ翻訳する作業が日常的に発生します。たとえば「このサブネットのSMB設定不備を洗い出す」「取得したメモリイメージから侵入の痕跡を抽出する」といった要求は、そのままでは実行できません。Nmap、Metasploit、Volatility、John the Ripper といった個々のツールを選び、フラグと引数を組み立てて初めて、作業は実行可能な一連のコマンドになります。

この翻訳作業をLLM（大規模言語モデル）に任せる動きが進んでいます。エージェントに偵察や調査を委ねれば、人手の負担を減らせるという期待があります。しかし「LLMは本当に、そのまま実行できる正確なコマンドを書けるのか」という問いは、これまでほとんど測定されてきませんでした。知識を問うテストでは概念理解しか分からず、CTFのような実環境タスクでは計画・操作・エラー回復が混ざり合って、失敗の原因を切り分けられないからです。

本記事で扱う論文「KaliBench」は、この問いに正面から答えるベンチマークです。Kali Linux上に実在する1,642種のツールを対象に、8,504組の「自然言語クエリ → 正解コマンド」対を用意し、モデルが実行可能なコマンドを生成できるかを細かく採点します。採点はツール選択と引数構築を分離して行われるため、「どこで間違えたのか」を特定できる点が特徴です。

結論を先に示します。ツール名を一切与えず、モデルが自力でツールを選ぶ「Unrestricted（制約なし）」設定では、評価対象となったオープンウェイトモデル24構成のうち、正解コマンドを完全一致で出力できた割合（Exact Correct）が42%を超えたものは一つもありませんでした。最高でも41.3%にとどまり、平均は22.3%です。つまり現状のモデルは、セキュリティツールを「知っている」ことと「正しく呼び出せる」ことの間に、大きな隔たりを抱えています。

本記事を通じて持ち帰ってほしいポイントは三つあります。第一に、コマンド生成の難所はツール選択ではなく「引数の組み立て」にあること。第二に、ツールのドキュメント（マニュアル）を一緒に与えると精度が劇的に向上すること。第三に、正解が決定的に採点できるため、コマンドを実行せずに報酬を計算でき、強化学習の学習信号としても使えることです。以降では、ベンチマークの構造、評価結果、そして実務への示唆を順に掘り下げていきます。

Kali Linuxとは何か、なぜコマンドラインが重要なのか

Kali Linuxは、ペネトレーションテスト（侵入テスト）、フォレンジック（証跡分析）、脆弱性診断に使うツールを2,000パッケージ以上プリインストールしたセキュリティ特化型のLinuxディストリビューションです。個別のツールを探して導入する手間を省き、検証用の環境をすぐ立ち上げられる点が支持されています。代表的なものとして、ネットワークスキャンのNmap、エクスプロイト実行基盤のMetasploit、メモリイメージから痕跡を抽出するVolatility、パスワード解析のJohn the Ripperなどが挙げられます。

こうしたツールの多くは、グラフィカルな画面ではなくCLI（コマンドラインインターフェース）から操作します。CLIでは、コマンド名に続けてフラグ（-p や --open のようなオプション）と値を並べ、処理内容と対象を指定します。たとえば「192.168.1.100に対してTCP Connect方式でスキャンし、ポート21〜25と80のうち開いているものだけを表示する」という意図は、次のコマンドになります。

nmap --open -sT -p 21-25,80 192.168.1.100

ここでは、どのフラグを使うか、どの値と結び付けるか、対象アドレスをどこに置くかまでが一致していないと、コマンドは意図どおりに動きません。フラグの綴りが1文字違う、長い形式（--）と短い形式（-）を取り違える、引数の順序を入れ替える——いずれも実行エラーや、意図しない対象への操作につながります。通常の文章生成と決定的に異なるのはこの点です。自然な日本語として読める出力でも、実行可能なコマンドでなければ意味がありません。

セキュリティ作業の流れを俯瞰すると、ツール群は役割ごとに段階を成しています。偵察から始まり、脆弱性分析、エクスプロイトとペイロード配送、ポストエクスプロイトと横展開、そして防御分析とレポートへと続きます。

flowchart LR
    A["偵察と初期アクセス<br/>information-gathering / 802.11 / RFID<br/>Bluetooth / SDR / ソーシャルエンジニアリング"] --> B["脆弱性分析<br/>vulnerability / fuzzing / web<br/>database / VoIP"]
    B --> C["エクスプロイトと配送<br/>exploitation / sniffing-spoofing<br/>hardware / wireless"]
    C --> D["ポストエクスプロイトと横展開<br/>post-exploitation / passwords<br/>windows-resources / crypto-stego"]
    D --> E["防御分析とレポート<br/>reverse-engineering / forensics<br/>reporting / GPU"]

各段階で使うツールは異なり、フラグの体系も統一されていません。同じ「出力先を指定する」操作でも、あるツールは -o、別のツールは --output を用います。だからこそ、人間が長年かけて身につけてきた「どのツールの、どのオプションを、どの順序で書くか」という知識を、そのまま言語モデルに期待できるかは自明ではありません。この問いを測る土台として、以降ではKali Linuxの実コマンドを対象にした評価の仕組みを見ていきます。

なぜ既存のベンチマークでは不十分だったのか

セキュリティ領域におけるLLMの評価は、これまで大きく二つの系統に分かれてきました。一つは知識型の評価で、SecEval、CyberMetric、CyberBench、CS-Eval、SecBench、CTI-Benchなどが該当します。多肢選択や記述式の問題を通じて「セキュリティの概念を理解しているか」を測る形式です。もう一つはエンドツーエンドのエージェント型評価で、CyBench、NYU-CTF Bench、DefenderBenchなどが代表例です。CTF（Capture The Flag）のような実環境でタスクを完遂できるかを測ります。

どちらも有用ですが、知りたいことに直接答えてはくれません。知識型は概念理解を測るものであり、実際にツールを正しい構文で呼び出せるかは問いません。「Nmapの役割を説明できる」ことと「Nmapを正しく実行できる」ことは別の能力です。一方のエージェント型は、計画立案・環境操作・観察結果の解釈・ツール呼び出し・エラーからの回復が一つのタスクに混ざり合います。タスクに失敗しても、原因がツール選択の誤りなのか、引数の誤りなのか、環境の扱いの誤りなのかを切り分けられないという難点があります。

第三の系統として、汎用のファンクションコーリング（LLMに外部ツールを呼び出させる仕組み）向けのベンチマークもあります。BFCL、ToolSandbox、StableToolBench、HammerBenchなどがそれです。ただしこれらは、ツール名と引数がJSONスキーマとして明示されていることを前提としています。セキュリティの現場ではCLIが主流であり、数百種類のツールについてスキーマをプロンプトに列挙するのは現実的ではありません。

結果として、「スキーマなし（schema-free）」の条件で、モデルが自力でツールを選び、フラグと値を正しく組み合わせ、そのまま実行できるコマンドを出力できるかを測るベンチマークが空白になっていました。KaliBenchは、この空白を埋めるために設計されています。次節では、その具体的な構造を見ていきます。

KaliBenchとは：8,504組の「自然言語→コマンド」対で測るベンチマーク

KaliBenchは、Kali Linux上のセキュリティツールを対象に、「自然言語による要求」を「そのまま実行できるCLIコマンド」へ翻訳する能力を測るベンチマーク兼データセットです。正式名称は「KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards」で、NeurIPS 2026のEvaluations and Datasets Trackに採択されています。著者はPengfei Li氏、Naufal Suryanto氏、Sicheng Zhang氏、Muzzammal Naseer氏（Khalifa University／University of Western Australia、同等貢献）です。

ここでいうCLI（コマンドラインインターフェース）とは、GUIのボタン操作ではなく、テキストでコマンドを入力してツールを動かす方式を指します。セキュリティ作業はこのCLI中心であり、フラグ（-p や --open のような動作指定子）の綴りや値の結び付きが少しでも違えば実行が成立しません。KaliBenchは、この「翻訳レイヤー」だけを抽出して評価する点に特徴があります。

データの規模は次のとおりです。

KaliBenchの最大の設計上の利点は、正解コマンドを「ツール名」「オプション引数（フラグと値の対応）」「位置引数（順序を持つ値）」に分解して記録していることです。そのため、モデルがどのツールを選んだかと、引数をどう組み立てたかを別々に採点でき、「どこで失敗しているのか」を細かく特定できます。たとえば、クエリ「192.168.1.100をTCP Connectスキャンし、ポート21〜25と80のうち開いているものだけ表示せよ」に対する正解は nmap --open -sT -p 21-25,80 192.168.1.100 であり、ツール名・オプション・位置引数の各要素に切り分けられます。

flowchart LR
    Q["自然言語クエリ<br/>（例：SMB設定不備を洗い出す）"] --> C["コマンド"]
    C --> T["ツール名<br/>nmap"]
    C --> O["オプション引数<br/>--open / -sT / -p 21-25,80"]
    C --> P["位置引数<br/>192.168.1.100"]

論文（arXiv:2610.02206）、GitHubリポジトリ（RISys-Lab/KaliBench）、Hugging Face上のデータセットとRedSage-Kモデル群、プロジェクトページが公開されており、生成・検証・評価・学習のコードを再現できます。データは研究用途でCC BY-NC 4.0ライセンスです。次の節では、このデータがどのような能力次元とフェーズで整理されているかを見ていきます。

KaliBenchの構造：23の能力次元と5つのセキュリティフェーズ

KaliBenchは、8,504組のクエリ・コマンド対を「どの種類の能力を問う問題か」という観点で整理しています。この整理軸が、23の能力次元と5つのセキュリティフェーズです。単にスコアを平均するのではなく、能力ごとに性能を分解して集計できるため、「どの領域が弱いのか」を定量的に把握できます。

23の能力次元は、Kali Linux公式のメタパッケージ分類（kali-tools taxonomy）にそのまま対応させています。Kaliはツールを用途別のメタパッケージにまとめて配布しているため、この分類を使うと、実際の現場で使われるカテゴリと評価軸が一致します。たとえば「information-gathering（情報収集）」「vulnerability（脆弱性分析）」「forensics（フォレンジック）」などが1つの次元になります。

5つのセキュリティフェーズは、Lockheed Martinの「Cyber Kill Chain（サイバー攻撃を段階に分解するモデル）」に着想を得て、23次元を攻撃・防御の流れに沿って束ねたものです。各フェーズとそこに属する次元は次のように整理されています。

この2階層の分類は、評価結果の集計にも使われます。各ツールには23次元のうち該当するものを1とした多次元ベクトル（multi-hotベクトル）を注釈として付与しておき、モデルが各問題で得たスコアを該当次元へ射影して合算します。こうすると、同じ1問でも複数の次元にまたがるツール（例：無線系とスニッフィングの両方に関わるツール）の成績を、関連する能力ごとに正しく配分できます。

flowchart TD
    KB["KaliBench<br/>8,504組"] --> P1["偵察・初期アクセス<br/>6次元"]
    KB --> P2["脆弱性分析<br/>5次元"]
    KB --> P3["エクスプロイト・配送<br/>4次元"]
    KB --> P4["ポストエクスプロイト・横展開<br/>4次元"]
    KB --> P5["防御分析・レポート<br/>4次元"]
    P1 --> D["23の能力次元<br/>（kali-tools taxonomy）"]
    P2 --> D
    P3 --> D
    P4 --> D
    P5 --> D

さらに、この分類はデータの構造とも結び付いています。各レコードは「クエリ」「正解コマンド」「ツール名」「オプション引数（フラグ＝値のマップ）」「位置引数（順序付き）」という構造化フィールドを持ちます。たとえば先ほどの nmap --open -sT -p 21-25,80 192.168.1.100 は、ツール名 nmap、オプション引数 --open・-sT・-p 21-25,80、位置引数 192.168.1.100 に分解して記録されます。能力次元はこのレコードに付随するメタデータとして機能し、次元ごとの難易度やモデルの得意・不得意を切り分ける土台になります。実際、次元別には gpu や crypto-stego が高スコア、802.11 や wireless が低スコアという偏りが報告されており、分類が失敗の所在を可視化する役割を果たしています。

どうやって作られたか：文書に基づく生成と3段階の検証

KaliBenchの土台は、Kali Linux公式のツールドキュメント（GitLabのkali-tools、Markdown形式、2,372ツール分）です。ツール名・フラグ（コマンドの挙動を切り替える - や -- で始まるオプション）・値・エイリアス（同じ意味を持つ別名、例：--domain と -d）を構造化シグナルとして抽出し、それらに接地させる形で「自然言語クエリ→正解コマンド」対を生成しました。この時点で27.7K組に達します。

生成の質を保つには、表記の統一が欠かせません。そこで決定論的な正規化ルール（canonicalization）をあらかじめ定義し、「ツール名→長いフラグ→短いフラグ（辞書順）→値付きフラグ→位置引数」の順に揃え、引用符は必要なときだけ付与、エイリアスはできる限り長いフラグの正規形へ統一しました。

ただし、文書に接地していても幻覚（hallucination、実在しない要素の生成）は残ります。初期の目視確認では、生成コマンドの50%超に存在しない／綴り違いのフラグ（例：--silence を --silent と誤る）が混ざっていました。これを除去するため、次の3段階の検証を重ねます。

1. LLM-as-Verifier（第1段階）：クエリ・生成コマンド・ツール文書を渡し、「全フラグと引数が文書に存在するか」「クエリの意図を文書の機能だけで実装しているか」を検証します。1回目で53.8%を除外し、有効データを持たないツール413種（17.4%）は再生成して補完。最終的に14.5K組（初期の47.65%を除去）になりました。
2. ターミナル検証（第2段階）：Kali-linux-everythingのDockerコンテナ内で各コマンドを実際に実行し、標準出力・標準エラー・終了コード・タイムアウトを記録します。存在しないツールや不正な引数によるエラーをルールベースで除外し、LLM検証済みデータの11.95%を除去しました。なお、パラメータが存在しないパスやIPといった合成値でも、構文として正しければ残す設計です。
3. ヒューマン・イン・ザ・ループ（第3段階）：最強モデルがヒント付きでも失敗したケースを重点的に人間が確認し、クエリの曖昧さやラベル誤りを検出します。追加で4.9%が無効と判明しました。

最後に重複を排除します。SemHashで「クエリ＋ツール名＋正解コマンド」を意味埋め込みし、コサイン類似度0.90超をクラスタ化して代表例だけを残しました。こうして27.7K組から最終的に8,504組（元の30.7%）へ絞り込まれ、評価用5,000件と学習用3,504件に分割されています。

flowchart LR
    A["Kali公式ドキュメント<br/>2,372ツール<br/>（ツール名・フラグ・値・エイリアス）"] --> B["生成<br/>27.7K組"]
    B --> C["第1段階<br/>LLM-as-Verifier<br/>→ 14.5K組"]
    C --> D["第2段階<br/>ターミナル検証<br/>（Docker実行・ルール除外）"]
    D --> E["第3段階<br/>ヒューマン検証<br/>（曖昧さ・ラベル誤り）"]
    E --> F["重複排除<br/>SemHash（類似度0.90超）<br/>→ 8,504組"]
    F --> G["分割<br/>評価5,000 / 学習3,504"]

各段階の通過率（27.7K→14.5K→8,504）が示すように、生成データの大半は検証で棄却されます。この厳しい洗浄があるからこそ、正解コマンドが唯一解に定まり、後述する実行不要の決定的な採点と報酬計算が成立します。

評価の仕組み：3つのモードとコマンド単位のスコア

KaliBenchの評価は「モデルにどれだけツール情報を与えるか」を変えた3つのモードで行われます。与える情報が増えるほど難易度が下がり、性能のどの部分が情報不足に由来するのかを切り分けられます。

• Unrestricted（制約なし）：クエリ（自然言語の要求）だけを与え、ツールも引数も自力で推測させます。最も現実に近く、最も難しい設定です。
• Restricted（制限付き）：正解ツールを含む候補20ツールの名前リストを与えます。ツール選択の探索空間を狭めますが、引数の組み立ては依然としてモデルの責務です。
• Hinted（ヒント付き）：候補ツールの公式ドキュメントまで与えます。JSONスキーマでツールと引数が明示される一般的なファンクションコーリングに近い条件です。

採点は、コマンドを <tool_name> <args> という構造として捉えます。引数は「オプション引数」（- または -- で始まり、値を持つこともある／順序は自由／エイリアス許容）と「位置引数」（値のみ／順序が固定）に分かれます。解析にはPythonのshlexを使い、コマンドを実行せずにUNIX流の字句解釈を再現します。これにより、危険なコマンドを動かさずに決定的で再現性のある採点が可能になります。

評価指標は5つです。Tool Accuracyは正しいツールを選べたかを測る二値指標、Optional-Argument F1はエイリアス（--domain と -dのような別名）を同一視したうえでのフラグ名の一致率、Positional-Argument F1は位置引数の値の多重集合一致率です。Total Scoreはこの3指標の平均、Exact Correctはツールと全引数が完全一致したときだけ1となる最も厳しい指標です。正解データがツール名・オプション（別名対応）・順序付き位置引数を明示的に保持しているため、部分点と完全一致を同時に扱えます。出力は <output>...</output> タグで囲むよう指示し、コマンド部分だけを安定して抽出します。

flowchart TB
    Q["自然言語クエリ"] --> M{"評価モード"}
    M -->|Unrestricted| U["クエリのみ"]
    M -->|Restricted| R["＋候補20ツール名"]
    M -->|Hinted| H["＋ツール公式ドキュメント"]
    U --> G["コマンド生成<br/>（outputタグで囲む）"]
    R --> G
    H --> G
    G --> P["shlexで字句解析<br/>（実行なし）"]
    P --> S1["Tool Accuracy"]
    P --> S2["Optional-Argument F1"]
    P --> S3["Positional-Argument F1"]
    S1 --> T["Total Score<br/>（3指標の平均）"]
    S2 --> T
    S3 --> T
    P --> E["Exact Correct<br/>（完全一致のみ1）"]

この設計の要点は、ツール選択と引数構築を別々の指標として分離していることです。単一の正解／不正解ではなく、失敗が「どのツールを選んだか」に起因するのか「引数をどう組んだか」に起因するのかを数値で特定できます。次節以降で見るように、この分解能が「ボトルネックは引数構築である」という発見を可能にしました。

結果：オープンウェイトモデルは42%の壁を越えられない

評価には、汎用モデル14種、セキュリティ特化モデル7種、そしてKaliBenchのデータで追加学習したRedSage-K 3種を合わせた計24構成（パラメータ数8B〜753B）が用いられました。ここでBはパラメータ数の単位（10億）で、753Bは7530億パラメータ規模を意味します。まず押さえるべきは、モデルに与える情報が増えるほどスコアが伸びるという一貫した傾向です。

最も厳しいExact Correct（ツール名と全引数が完全一致したときだけ正解とする指標）は、制約なし（Unrestricted）で平均22.3%にとどまります。候補20ツールを与えるRestrictedでも28.3%で、大きくは伸びません。ところがツールの公式ドキュメントまで与えるHintedでは一気に73.1%へ跳ね上がります。この差は、後述するように「ツールを選ぶ力」ではなく「引数を組み立てる力」が情報不足に強く依存していることを示しています。

タイトルの「42%」は、制約なし設定でのExact Correctに由来します。この条件でのオープンウェイトモデル最良はGLM-5.2（753B）の41.3%で、評価した24構成のどれも42%を超えられませんでした。パラメータを10倍近く増やしても完全一致率は4割前後で頭打ちになる、というのがこの結果の核心です。

さらに、モデルの規模と性能は単純に比例しません。Qwen3（8B、推論有効）はGemma-3-it（27B）やLlama-Primus-Ins（70B）を平均スコアで上回りました。セキュリティ特化モデルも常に汎用モデルを圧倒するわけではなく、情報が少ないUnrestricted／Restrictedでは優位に立つ一方、ドキュメントが与えられるHintedでは汎用モデルの指示追従性が勝つ場面が目立ちます。推論（reasoning）を有効にしたモデルは、とくに引数系の指標を改善しやすい傾向がありました。

参考として、プロプライエタリなモデルや足場（scaffold）付きシステムも制約なし設定で追加評価されています。GPT-5.6-Solが全5,000件で61.68%、Codex CLI（GPT-5.5）が51.68%、Claude Opus 5は回答済み分で59.89%ですが回答率が73.50%のため全件換算では44.02%でした。最高でも61.68%であり、このベンチマークはまだ飽和していない（＝性能を測り切れる余地が残っている）ことを示しています。

ボトルネックは「引数の構築」——ツール選択ではない

KaliBenchの評価で最も重要な発見は、「どのツールを使うか」を選ぶ能力と、「そのツールに正しい引数を渡す」能力は別問題だという点です。ここでいう引数とは、コマンドの振る舞いを決めるフラグ（-sT のようなオプション）と、対象のIPアドレスやファイルパスのような位置引数のことです。この2つを分離して採点できる設計だからこそ、失敗の所在が明確になりました。

決定的なのは、正解ツールを候補20個の中に提示するRestrictedモードの結果です。ツール選択率（Tool Accuracy）は制約なし（Unrestricted）の平均72.0%から95.2%へ、実に23.2ポイントも改善します。ところが完全一致率（Exact Correct）は平均でわずか5.9ポイントしか伸びません。つまり「どの道具を使うか」を教えてもらっても、引数の組み立て方が分からなければ、実行できるコマンドにはならないということです。

逆に、ツールの公式ドキュメントまで与えるHintedモードでは、引数系の指標が劇的に改善します。オプション引数のF1は平均で39.1ポイント、位置引数のF1は21.9ポイント、完全一致率は44.8ポイントも上昇しました。ドキュメントは「ツールの特定」よりも「引数の曖昧さの解消」に効いているわけです。

xychart-beta
    title "3モードでの指標変化（24構成の平均）"
    x-axis ["Unrestricted", "Restricted", "Hinted"]
    y-axis "スコア (%)" 0 --> 100
    line "Tool Accuracy" [72.0, 95.2, 94.6]
    line "Optional-Argument F1" [45.1, 48.7, 87.8]
    line "Positional-Argument F1" [61.1, 68.2, 90.1]
    line "Exact Correct" [22.3, 28.3, 73.1]

この結果から、難易度の階層が見えてきます。最も難しいのはオプション引数の予測で、次に位置引数、そしてツール選択は（候補さえ与えられれば）比較的容易です。別の言い方をすれば、現在のモデルはセキュリティツール固有のドメイン知識——フラグの綴りや値の仕様——が不足しており、ドキュメントという外部知識なしには正確な引数を組み立てられません。実際、nikto はツール選択率0.986（ほぼ完璧）でありながら完全一致率は0.000でした。ツールを正しく当てることと、正しいコマンドを書くことは、まったく別の能力なのです。

この非対称性は実務に直結する示唆を持ちます。エージェントにコマンドを生成させるとき、候補ツールの提示だけでは不十分で、ドキュメントの提供や引数の機械的な検証・補完を組み合わせる必要があります。

現場でよく起きる失敗パターン

KaliBenchの誤答を分類すると、失敗はツール名の取り違えではなく、引数の細部に集中していることが分かります。ここでいう引数は、-sT や --open のようにコマンドの挙動を切り替えるオプション引数と、IPアドレスやファイルパスのように順序が意味を持つ位置引数の2種類です。1つの誤りが単独で現れるのではなく、複数の引数ミスが積み重なってコマンド全体を実行不能にします。

観察された失敗は大きく4類型に整理できます。

人手レビューで確認された無効な例も、同じ傾向を示します。-g を --g と誤記する不正なCLIオプション、クエリが要求する引数を省略するケース（kustomize completion bash を kustomize completion と短縮）、そして意味が食い違う引数の代用（git -C <dir> status を --work-tree で代用、dos2unix で入力と出力の順序を入れ替え、URLが必要な箇所にただのパスを渡す）などです。いずれも「コマンドとしてはそれらしく見えるが、実行すると意図どおりに動かない」という点で共通しています。

ツール別に見ると、難しさはモデル固有ではなくCLIインターフェースの複雑さに由来します。d2j-std-apk、rfdump、truecrypt2john は完全一致で満点でした。一方 nikto はツール選択率0.986（ほぼ完璧）でありながら完全一致率は0.000で、引数構築の弱さが露呈しています。steghide、above、exiflooter も低スコアでした。呼び出しが単純で既定値が明確なツールは安定し、不規則で珍しいオプションを持つツールは難しくなる、という傾向が読み取れます。

flowchart LR
    A[クエリ] --> B[ツール選択]
    B --> C[オプション引数の構築]
    C --> D[位置引数の構築]
    D --> E[実行可能なコマンド]
    B -.->|誤りは少ない| X[失敗]
    C -.->|混用・幻覚・捏造・名前誤り| X
    D -.->|順序・型・欠落| X

この失敗類型は、エージェントにコマンドを生成させる際の検証ポイントを示しています。ツール名だけでなく、オプションの別名・存在性・単複、位置引数の順序と型を機械的にチェックする層を挟むことが、誤ったコマンドの実行を防ぐ第一歩になります。

言い回しの揺れにどれだけ弱いか（ロバスト性）

KaliBenchのクエリは、いずれもKali公式ドキュメントから合成された整った自然言語です。しかし実際の運用現場で入力されるのは、常に整理された文章とは限りません。同じ意図でも言い回しは変わり、口語的になり、誤字や語の欠落が混じります。そこで論文では、クエリを3種類の変種に書き換え、8モデル構成に対して制約なし（Unrestricted）・制限付き（Restricted）・ヒント付き（Hinted）の3モードで評価し、スコアの変動を測っています。

まず注目すべきは、Paraphrase（言い換え）の影響がほぼ無視できる点です。制約なしでは+0.61ポイントとわずかに改善し、最も厳しい条件であるヒント付きでも-0.09ポイントにとどまりました。モデルは語彙の置き換え程度では揺らがない、言い換えには比較的頑健であることが分かります。

これに対し、Informal（口語表現）は小さく、しかし一貫した低下をもたらします（-0.55／-0.48／-0.28）。そして最も深刻なのがMessy（ノイズ混入）で、制約なしでは-3.20ポイント、最も影響の小さいヒント付きでも-1.07ポイント下落しました。評価した全モデル構成でMessy入力はスコアが下がり、その最小の落ち込みでも-1.98ポイントに達しています。誤字や語の欠落は、モデルが文意を補おうとするほど引数の推測を狂わせる、より根深い問題だと考えられます。

flowchart LR
    A[整ったクエリ] --> B[Paraphrase]
    A --> C[Informal]
    A --> D[Messy]
    B -->|ほぼ影響なし| E[コマンド生成]
    C -->|小さく一貫した低下| E
    D -->|最大の低下| E
    F[ツール文書の提示] -.->|ノイズの影響を緩和| E

モード別に見ると、低下幅はどの変種でもヒント付きが最小でした。ツールの公式ドキュメントを一緒に与えると、入力の揺れやノイズが引数解釈に与える影響は緩和されます。ただしMessyで-1.07ポイントが残るように、その効果は影響を消し去るものではなく、あくまで軽減にとどまります。雑な自然言語を正確なコマンドへ翻訳することは、特定のモデルやモードに依存しない、自然言語→CLI翻訳の体系的な課題だと言えます。

実務に引き寄せると、この結果は入力側の前処理の重要性を示します。誤字や口語表現をそのまま渡すと、たとえツール文書を添えても性能は落ちます。入力を正規化する、曖昧な箇所を確認する、といったステップを挟むことが、生成コマンドの安定性を保つうえで有効です。

実行なしで報われる学習：Runtime-Free Verifiable Rewards

強化学習（RL：Reinforcement Learning、モデルの出力に対して与えた報酬を手がかりに振る舞いを改善する訓練手法）をセキュリティ領域で回そうとすると、通常は大きな障害に突き当たります。モデルが生成したコマンドをそのまま実行して成否を判定しなければならないため、危険な操作や環境破壊のリスクを常に伴うからです。KaliBenchは、この制約を設計段階で外しています。収録されている正解コマンドはデータ構築時にサンドボックス上で実行検証済みであり、評価対象のモデルが出力したコマンドは一切実行しなくても、正解データとの突き合わせだけで報酬を計算できます。これを「Runtime-Free Verifiable Rewards（実行不要の検証可能報酬）」と呼びます。

報酬は、評価指標と同じ構成要素から組み立てられます。具体的には、ツール名が正しいか、位置引数（値のみで順序が固定される引数）が一致するか、エイリアス（別名）を考慮したうえでオプション引数（-や--で始まるフラグ）が一致するか、そしてコマンド全体が完全一致したか、という段階的な信号です。加えて、<output>...</output>タグで囲むといった出力形式の遵守にも報酬が与えられます。単純な二値の正誤ではなく、部分点が連続的に得られる設計になっているため、学習の手がかりが細かくなっています。

flowchart LR
    A[モデル出力コマンド] --> B[出力形式の報酬]
    A --> C[ツール名の一致]
    A --> D[位置引数の一致]
    A --> E[オプション引数の一致<br/>エイリアス考慮]
    C --> F[完全一致ボーナス]
    D --> F
    E --> F
    B --> G[合計報酬]
    C --> G
    D --> G
    E --> G
    F --> G
    G --> H[GRPOによるパラメータ更新]

学習プロトコルは評価条件と揃えられています。評価と同じプロンプトを使い、Unrestricted・Restricted・Hintedの3モード分のデータを連結して、学習用の3,504件を3倍に増やした10,512サンプルを用意します。教師あり微調整（SFT：正解コマンドをそのまま模倣させる学習）と、検証可能報酬による強化学習（RLVR）の2段構えです。RLVRでは、モデルに中間推論をさせてからコマンドを生成させ、GRPO（Group Relative Policy Optimization：同じ問いに対する複数の出力をグループとして比較し、相対的に良い出力を強化する最適化手法）で更新します。

実行環境を必要としないこの仕組みは、スケーラブルで再現性が高いです。実際、8B（80億パラメータ）のセキュリティ特化モデルがこの報酬で学習し、685B級のMoE（Mixture of Experts、複数の専門サブネットワークを状況に応じて使い分ける大規模モデル）に迫る性能を達成しています。安全性の制約が厳しいセキュリティ運用の現場にとって、実行を伴わずにモデルを鍛えられることは、実用化への大きな一歩となります。

8Bモデルが685Bに迫る：SFT＋GRPOの威力

モデルの規模を大きくするだけでは性能が伸びない、というKaliBenchの観察は、裏を返せば「学習の設計次第で小さなモデルでも大きく伸びる」ことを意味します。論文では、セキュリティ特化の8B（80億パラメータ）モデルを土台に、SFT（教師あり微調整：正解コマンドをそのまま模倣させる学習）とGRPO（Group Relative Policy Optimization：同じ問いに対する複数の出力を比較し、相対的に良い出力を強化する強化学習）を組み合わせた3種のモデル「RedSage-K」を構築し、その効果を測っています。

結果は明確です。平均Total Scoreは、ベースモデルのRedSage-Insが71.7、SFTのみで77.4、SFT＋GRPOで79.2へと段階的に改善しました。SFT＋GRPOの構成は、評価したオープンウェイトモデル全体で3位に入り、685B級のMoE（Mixture of Experts、複数の専門サブネットワークを使い分ける大規模モデル）であるDeepSeek-V3.2の80.2に、わずか1.0ポイント差まで肉薄しました。パラメータ数の差が数十倍ある相手に対し、8Bが実用圏のスコアに到達したことになります。

手法ごとに得意分野が分かれる点も興味深いです。SFTはツールとクエリの対応付け（マッピング）の学習に強く、ドキュメントを与えるHintedモードでの伸びが最大になります。一方GRPOは、制約の少ないUnrestricted／Restrictedで位置引数F1とTotal Scoreを押し上げますが、Hintedでは伸び悩みます。両者を組み合わせたSFT＋GRPOは、制約が少ないU／Rで最良のスコアを示し、SFTによる初期化が強化学習時の性能劣化を抑える役割を果たしています。

flowchart LR
    A[RedSage-Ins 8B<br/>Total 71.7] --> B[SFT<br/>71.7→77.4]
    B --> C[SFT＋GRPO<br/>79.2]
    C -. 1.0pt差 .-> D[DeepSeek-V3.2 685B MoE<br/>80.2]

ただし万能ではありません。GRPO系の学習はHintedモードでわずかにスコアを下げます（GRPO -0.76ポイント、SFT＋GRPO -0.19ポイント）。ベースモデルでは解けていた問題を壊してしまう「回帰」が起きるためです。Hintedでは537件を修正する一方で562件を新たに誤らせており、修正数と回帰数がほぼ拮抗しています。SFTで初期化しておくと、この回帰は562件から488件へと減少しました。検証可能報酬による強化学習は、正解を増やす力と既存の正解を失うリスクを同時に抱えており、初期化やデータ設計でバランスを取る必要があります。

この結果が示す示唆は大きいです。ドメイン特化の検証可能報酬さえ用意できれば、小規模なオープンウェイトモデルでも大規模モデルに迫る性能を引き出せます。機微なデータを外部に送れないセキュリティ現場にとって、ローカルで動く8Bモデルが実用水準に届くことは、現実的な選択肢を広げます。

セキュリティ実務への示唆：ローカルLLMを安全に使うために

セキュリティ運用の現場では、調査対象のIPアドレスやホスト名、メモリイメージの中身、インシデントの運用ログなど、扱う情報の大半が機微です。外部のAPIにそのまま送るわけにはいかないケースが多く、自組織の環境内にモデルを置いて動かせる「オープンウェイトモデル」の実力評価が現実的な意味を持ちます。KaliBenchの結果は、そうしたローカルLLMを実際の作業に組み込む際の指針をいくつか与えてくれます。

第一に、コマンドを書かせる際はツールのドキュメント（マニュアル）を一緒に与えるのが最も効きます。ツール選択を助けても正解コマンドには届きにくいのに対し、引数の仕様を提示すると精度が跳ね上がります。KaliBenchの平均値では、Exact Correct（ツールと全引数の完全一致率）が制約なしの22.3%から、ドキュメント提示時の73.1%まで改善しました。失敗の最大要因が引数の組み立てにある以上、フラグや値の仕様をモデルに渡すことが最短の対策になります。

第二に、ツール選択の補助だけでは不十分です。正解ツールを含む候補20件を提示すると、正しいツールを選ぶ割合は72.0%から95.2%へ大きく上がりますが、完全一致率は平均でわずか5.9ポイントしか伸びません。ツール名が確定しても引数の誤りが残るため、引数専用のバリデーションや補完機構を別途用意する必要があります。

第三に、生成されたコマンドをそのまま実行しない設計が安全です。引数の検証を実行前の層として挟むことが推奨されます。KaliBench自体が「実行せずに字句解析だけで採点する」設計を採っていることは、この発想の実例になっています。

第四に、入力の正規化と確認ステップが有効です。口語的な表現や誤字・語の欠落が混じった「雑な」入力ではスコアが最も落ち（制約なしで-3.20ポイント、全モデルで最低-1.98ポイント）、ドキュメントを与えても完全には緩和されません。入力段階で意図を整える手順を組み込むことが、誤コマンドの発生を抑えます。

flowchart LR
    A[自然言語クエリ<br/>正規化・意図確認] --> B{ツール候補の提示}
    B --> C[ツール文書の提示]
    C --> D[コマンド生成]
    D --> E[構文・引数の<br/>機械的検証]
    E -->|合格| F[実行環境へ]
    E -->|不合格| D

これらの教訓は、いずれも「モデルに任せきる」のではなく「検証層を挟む」方向に収束します。ドキュメント提示で引数の曖昧さを減らし、機械的検証で誤りを実行前に止め、入力の揺れを正規化するという三段構えが、ローカルLLMを安全に運用するための現実的な出発点になります。

限界と今後の展望

KaliBenchは自然言語からコマンドへの翻訳を精密に測りますが、その評価範囲にははっきりとした境界があります。ここでは、このベンチマークが何を測っていないのか、そして今後どこへ拡張されるべきかを整理します。

最大の制約は、評価対象が「単一ターンのコマンド生成」に限定されている点です。実際のセキュリティ作業は、偵察で得た情報をもとに次のスキャンを選び、失敗すれば別のツールへ切り替えるといった複数ステップの連鎖で成り立ちます。環境の状態は各ステップで変化し、途中の出力を読んで判断する必要もあります。KaliBenchが測るのはその一歩手前、すなわち「1つの意図を1本の実行可能なコマンドに落とせるか」であり、ワークフロー全体の遂行能力や、エラーからの回復力は範囲外です。

次に、データの鮮度という問題があります。正解コマンドはデータ構築時点のKali公式ドキュメントに基づいており、上流のマニュアルが改訂されてフラグが追加・廃止・改名されれば、一部の正解が古くなります。ただし、多くのツールは後方互換の別名を維持しており、候補ツールのドキュメントを与えるHintedモードでは最新の仕様が提示されるため、影響はある程度緩和されます。

正規化と採点の完全性にも限界があります。実世界のドキュメントには矛盾や誤りが含まれます。たとえば特定ツールでは同じ短オプションが「値を出力しない」と「バージョン表示」の2つの意味で衝突しており、Impacket系のように非典型的な短オプション表記を持つものもあります。こうした揺れを決定論的なルールで吸収しきることはできず、正規化は本質的に近似にとどまります。検証に用いたLLMによるチェックや、エイリアスを考慮した採点も、歴史的・ディストリビューション固有・コミュニティ由来のあらゆる変種を捉えきれるものではありません。

今後の方向性として、論文はマルチステップのワークフロー評価、検索拡張（RAG）によるツール利用、環境の状態を意識した評価への拡張を課題として挙げています。位置づけとしては、KaliBenchは実行ベースやエージェント型の評価を置き換えるものではなく、失敗の原因を切り分けられる統制された抽象化として、それらを補完する役割を担います。

flowchart LR
    A[単一コマンド生成<br/>KaliBenchの範囲] --> B[マルチステップ<br/>ワークフロー]
    B --> C[RAGによる<br/>ツール利用]
    C --> D[環境状態を<br/>意識した評価]
    A -.->|現在の限界| B

これらの限界を踏まえても、引数構築という最大のボトルネックを単一コマンド単位で可視化した意義は大きいです。足りない部分を明示しているからこそ、次の評価設計の出発点として使いやすいベンチマークになっています。

よくある質問

KaliBenchの「Runtime-Free（実行不要）」とはどういう意味ですか？

正解コマンドはデータ構築の時点でサンドボックス上で実行され、構文と引数が妥当であることが確認済みです。そのため評価時にはモデルの出力を実行する必要がなく、shlexによる字句解析と構成要素の一致だけで採点できます。報酬も同じ仕組みで計算できるため、危険なコマンドを走らせずに強化学習を回せる点が「実行不要」の意味です。

「42%未満」という数字は何を指しますか？

これは制約なし（Unrestricted）設定、つまりクエリだけを与えたときのExact Correct（完全一致率）を指します。評価したオープンウェイトモデル24構成のうち最高はGLM-5.2（753B）の41.3%で、42%を超えたモデルはありませんでした。平均値は22.3%にとどまっています。

3つの評価モードは何が違いますか？

Unrestrictedはクエリのみ、Restrictedは正解ツールを含む候補20ツールの名前リストを提示、Hintedは候補ツールの公式ドキュメントまで提示します。与えるツール情報が増えるほどExact Correctは上がり、平均は22.3%→28.3%→73.1%と変化します。

なぜツール名を当てても正解コマンドにならないのですか？

最大の難所が引数の組み立てです。フラグの綴り、値との結び付き、位置引数の順序、エイリアス（別名）の使い分けで誤りが積み重なります。実際、Restrictedではツール特定率が平均95.2%まで上がる一方、Exact Correctは平均でわずか5.9ポイントしか改善しませんでした。

KaliBenchはどうやって学習にも使えますか？

構造化された正解データから「ツール名」「オプション引数」「位置引数」「完全一致」「出力形式」に対応する決定的な報酬を作り、SFT（教師あり微調整）とGRPOによるRLVR（検証可能報酬による強化学習）に利用できます。実際に8Bモデルが平均スコア71.7から79.2へ改善し、685BのMoEモデル（80.2）に1.0ポイント差まで迫りました。

データやコードは公開されていますか？

はい。GitHubのリポジトリ（RISys-Lab/KaliBench）に生成・検証・評価・学習のコードが、Hugging Faceに学習用3,504件・評価用5,000件のデータとRedSage-Kモデル3種が公開されています。KaliBenchは研究用途でCC BY-NC 4.0ライセンスです。

まとめ

KaliBenchは、Kali Linuxに搭載された実ツール1,642種を対象に、「自然言語の要求」から「実行可能なコマンド」への翻訳をきめ細かく測定するベンチマークです。8,504組のクエリ・コマンド対、23の能力次元、5つのセキュリティフェーズという構造を持ち、ツールと引数がスキーマとして与えられない「スキーマなし（schema-free）」の条件下で、モデルが自力でツールを選び、引数を正しく組み立てられるかを評価する点に独自性があります。

最大の発見は、LLMの弱点が「どのツールを使うか」ではなく「引数をどう組むか」にあるという点です。正解ツールを含む候補20件を提示する制限付き設定では、Tool Accuracyが平均72.0%から95.2%へと大きく改善する一方、Exact Correct（完全一致率）は平均で+5.9ポイントしか伸びません。逆にツールの公式ドキュメントまで与える設定では、オプション引数のF1が+39.1ポイント、Exact Correctが+44.8ポイントと急上昇します。つまり、フラグの綴りや値との結び付き、位置引数の順序といったドメイン固有の仕様知識こそが精度の律速要因であり、ドキュメントは「ツールの特定」よりも「引数の曖昧さ解消」に効きます。

この難しさは、制約なし設定でオープンウェイトモデル24構成の最高がGLM-5.2（753B）の41.3%にとどまるという結果に表れています。ツール選択が比較的容易である一方、引数構築が依然として壁になっています。ただし、正解コマンドが構築時にサンドボックスで検証済みであるため、モデルの出力を実行しなくても決定的な報酬が計算できます。この実行不要の検証可能報酬（Runtime-Free Verifiable Rewards）をSFTとGRPOによる強化学習に用いることで、8Bモデルの平均Total Scoreは71.7から79.2へと改善し、685B MoEのDeepSeek-V3.2（80.2）にわずか1.0ポイント差まで迫りました。小規模モデルでもドメイン特化の学習で実用水準に近づけることを示した点は、機微なデータを外部APIに送れないセキュリティ現場にとって重要な意味を持ちます。

実務への示唆は明確です。コマンド生成を任せる際はツールのドキュメントを一緒に与えること、ツール選択の補助だけでは不十分なため引数の検証・補完機構を別途用意すること、生成されたコマンドをそのまま実行せず構文と引数を機械的に検証してから実行すること、誤字や口語を含む雑な入力に備えて正規化や確認ステップを挟むこと。Messy入力では全モデル構成でスコアが低下し、ドキュメントを提示しても影響は緩和されますが、消えはしません。

今後の課題は、単一ターンのコマンド生成から複数ステップのワークフロー、検索拡張（RAG）によるツール利用、環境の状態変化を伴う評価への拡張です。KaliBenchは実行ベースのエージェント型評価を置き換えるものではなく、失敗の原因を切り分けられる統制された抽象化として、両者を補完する位置づけにあります。

• 論文：arXiv:2610.02206
• コード：github.com/RISys-Lab/KaliBench
• プロジェクトページ：risys-lab.github.io/KaliBench/

参考資料

• KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards（arXiv Abstract）: http://arxiv.org/abs/2610.02206v1
• 同（arXiv HTML全文）: https://arxiv.org/html/2610.02206v1
• KaliBench 公式プロジェクトページ: https://risys-lab.github.io/KaliBench/
• KaliBench GitHub リポジトリ: https://github.com/RISys-Lab/KaliBench
• KaliBench Datasets & Models（Hugging Face）: https://huggingface.co/collections/RISys-Lab/kalibench-datasets-and-models
• Kali Linux 公式ツール一覧: https://www.kali.org/tools/
• Kali-tools ドキュメント（GitLab）: https://gitlab.com/kalilinux/documentation/kali-tools

関連記事

• AIがあなたのPCを動かす時代――Claude Cowork、Perplexity、GPT Codex、Geminiの「コンピュータ使用」徹底比較と次に来るもの
• 日常タスクをAIエージェントはこなせるか？ClawBenchが評価するAIの実用性