SkillSpectorとは？AIエージェント用スキルをインストール前に監査する方法

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

SkillSpectorで何が分かる？

SkillSpectorは、AIエージェント用skillをインストールする前に見ておきたい危険信号を洗い出すscannerです。執筆時点では、Git repository、URL、zip、directory、single fileを対象にでき、静的解析を標準で走らせたうえで、必要ならLLMによるsemantic analysisを追加できます。

特に見てくれるのは、prompt injection、data exfiltration、privilege escalation、dangerous code patterns、MCP least privilege、tool poisoningのような「説明文だけでは見抜きにくい」部分です。READMEやSKILL.mdが丁寧でも、裏でexec()や広すぎる権限宣言が混ざっていれば、そこで初めて止まれるのが価値です。

要点は、SkillSpectorを“安全の証明書”として使うのではなく、入れてよいかを判断するための一次ふるいとして使うことです。次の章から、実際にどうscanし、どう結果を読むかを順番に整理します。

SkillSpectorを動かす手順

ここでやることは3つだけです。環境を用意する→対象skillをscanする→レポートを残す、この順に進めれば最初の監査は回せます。

ポイントは、手元のskillフォルダだけでなく、GitHub URLやzipでも同じCLIから扱えることです。つまり「気になるskillを見つけたら、とりあえずscanしてから入れる」という流れを、配布形式ごとに変えずに持てます。

まずは公式どおりに環境を整え、その後でscanコマンドを対象別に使い分けます。最後にレポートを保存しておくと、あとから再確認やチーム共有がしやすくなります。

① 仮想環境を作る

最初は公式READMEどおりに、repoをcloneして仮想環境を作ります。uvが使えるならそのまま進めればよく、無ければ標準のvenvでも問題ありません。

git clone https://github.com/NVIDIA/skillspector.git
cd skillspector
uv venv .venv && source .venv/bin/activate
make install

uvが無い環境では、次のように置き換えれば動きます。

python3 -m venv .venv
source .venv/bin/activate
make install

ここで大事なのは、いきなり他人のskillを実行しないことです。まずscanner側の環境を切り出しておくと、あとでscan対象を変えても同じ手順を繰り返しやすくなります。

② skillをscanする

scanコマンドはシンプルで、対象の渡し方だけ変えれば使い回せます。まずはいま入れようとしている実物に向けて走らせるのが基本です。

# ローカルのskill directory
skillspector scan ./my-skill/

# 単一のSKILL.md
skillspector scan ./SKILL.md

# GitHub repository
skillspector scan https://github.com/user/my-skill

# zip配布
skillspector scan ./my-skill.zip

配布ページしか見ていない段階でも、GitHub URLをそのまま投げれば監査を始められます。ローカルに落としてから入れる運用でも、zip配布でも同じCLIで回せるので、導入前チェックを習慣化しやすいのが強みです。

③ レポートを保存する

最初の確認だけならterminal出力でも足りますが、あとで見返す前提ならファイル出力までやっておくと便利です。特にチーム導入やCIに載せるなら、formatを使い分けたほうが判断がぶれません。

skillspector scan ./my-skill/ --format json --output report.json
skillspector scan ./my-skill/ --format markdown --output report.md
skillspector scan ./my-skill/ --format sarif --output report.sarif

「scanしたけど何を見たか忘れた」を防ぐためにも、最初の1本はMarkdownかJSONで残しておくのがおすすめです。

結果をどう判断するか

scan結果は、スコアだけ見て終わらせるより危険度→検知内容→文脈の順で読むほうが失敗しません。まずcritical/highがあるかを見て、その後にどのファイルで、どの挙動が引っかかったかを追います。

中でも見落としやすいのは、説明文と権限宣言のズレ、外部送信、秘密情報へのアクセス、難読化コードです。ここが曖昧なskillは、便利そうでも一度止めて確認したほうが安全です。

一方で、scan結果は常に絶対ではありません。medium以下や仕様解釈に近い項目は、次のH3で見るように『どういう理由で出たか』まで読んで判断するのが実務的です。

① 危険度とカテゴリを見る

執筆時点では、SkillSpectorは64パターンを16カテゴリで扱っています。全部を覚える必要はありませんが、何が即停止に近い信号かは先に押さえておくと判断が速くなります。

category名より大事なのは、そのskillの目的に本当に必要な挙動かです。ファイルを読む理由が説明できない、外部送信の用途が曖昧、説明より広い権限を要求している。このどれかに当たるなら、スコア以上に慎重に扱う価値があります。

② 解析モードを分ける

まずは静的解析だけでも十分価値があります。速く回せて、権限宣言、危険なコードパターン、既知の依存関係リスクのような構造的な異常をすぐ見つけられるからです。

一方で、説明文と実際の挙動が噛み合っているか、parameter descriptionに不自然な誘導が混ざっていないかのような意図比較は、semantic analysisを足したほうが拾いやすくなります。逆に、まず一覧をさばきたいときやオフライン寄りで回したいときは、--no-llmで静的パスだけ先に通す運用が現実的です。

迷ったら、初回は静的→怪しいものだけ深掘りの順で十分です。最初から全部を重いモードで回すより、導入前の判断コストを下げやすくなります。

③ criticalとhighを優先する

導入判断の基準で迷ったら、NVIDIAのrelease checklistに寄せるのが分かりやすいです。つまり、critical/highは先に止める、mediumは用途と影響を見て読むという順番です。

おすすめは次の3段階です。

この流れなら、スコアだけで機械的に拒否せずに済みます。逆に、critical/highを『便利そうだから』で流してしまうと、導入前scanの意味がかなり薄れます。

SkillSpectorだけで終わらせない

ここが大事です。SkillSpectorは危険な挙動が見えないかを見る道具ですが、reviewしたskillと今から入れるskillが同じ中身かどうか、誰が作り、何を想定しているかまでは単独で担いません。

NVIDIAのdocsでは、scan、skill card、署名を別レイヤーとして扱っています。scanは危険挙動の検出、skill cardは用途・所有者・制約の確認、署名はreview済み成果物と配布物が同じかの検証です。つまり、導入前の安心感を高めたいなら、scannerだけで完了扱いにしないのが基本になります。

この章では、残りの2レイヤーと公開初期ならではの注意点を見ていきます。ここまでやると『便利そうだから入れる』から一段進んだ判断がしやすくなります。

skill cardと署名も確認する

skill cardでは、そのskillが何をするか、誰がownerか、どんな依存関係や既知リスクがあるかを確認します。ここが曖昧なら、scanがきれいでも『何を入れるのか分からない』状態が残ります。

署名検証はさらに別で、reviewしたdirectoryと今の配布物が同じかを確かめる工程です。公式docsでも、署名は安全性そのものを保証しないと明記されています。

model_signing verify certificate SKILL_DIR \
  --signature SKILL_DIR/skill.oms.sig \
  --certificate-chain nv-agent-root-cert.pem

導入前は、scan reportを読む、skill cardで用途と権限を確認する、最後に署名を検証する。この順で見ると、判断がかなり安定します。

誤検知とissueを前提に読む

公開初期のツールなので、scan結果をそのまま絶対視しない姿勢も必要です。執筆時点では、GitHub issuesにfalse positive、allowed-toolsの解釈漏れ、stage 2のretry不足、staticへのfallbackに関する報告が出ています。

一方で、実務者の反応を見ると、手動レビューで見落としたenv読み取りやexec()、難読化文字列を静的パスが拾えたという利点もあります。つまり、価値は十分あるけれど、最後の導入判断は人が持つという使い方がちょうどいい段階です。

おすすめは、flagを『拒否の宣告』ではなく確認キューとして扱うことです。理由が説明できるならaccept、説明できないなら止める。このルールにしておくと、誤検知にも過検知にも振り回されにくくなります。

SkillSpectorのよくある質問

まとめ

SkillSpectorは、他人のskillを入れる前に危険信号を洗い出すための実務ツールです。READMEやSKILL.mdの見た目だけでは見抜きにくい権限やコードパターンを、導入前に止められるのが一番の強みです。

次に試すなら、気になっているGitHub URLを1本そのままscanしてみてください。scan結果を読む癖が付くと、skill導入の安心感がかなり変わります。