AIエージェントのスキルに潜む危険を導入前に検査するOSS「SkillSpector」を解説

「社員が便利そうなスキルを見つけてきて、エージェントに次々と足しているが、中身を誰も読んでいない」「スキルは文章のファイルにすぎないのに、何を確かめれば安全と言えるのか分からない」——AIエージェントの業務利用が広がった企業の、情報システム部門やセキュリティ部門から聞こえてくる声です。スキルとは、AIエージェントに作業のやり方を教える手順書と、それに付属する小さなプログラムの組み合わせです。手軽に足せる分、取り込む前に中身を確かめる工程が、ほとんどの組織で抜け落ちていることが本当の問題です。検査の道具があるかどうかではありません。この記事では、NVIDIAが公開した、スキルを導入前に検査するOSS「SkillSpector」を取り上げ、確かめられる事実、検査の仕組み、社外へ出る情報、検査の限界、企業が導入前に決めておくべきことを整理します。導入や操作の手順は扱いません。

SkillSpectorとは何か。2026年10月時点で確かめられる事実

SkillSpectorは、NVIDIAの組織アカウントがGitHubで公開しているOSSです。リポジトリの説明は「AIエージェントのスキルのためのセキュリティ検査の道具」で、Claude Code、Codex、MCPのスキルについて、脆弱性、悪意のある処理の型、プロンプトインジェクション、情報の持ち出し、供給網の危険を、導入する前に見つけるものだと紹介されています。READMEは、この道具が答えようとする問いを「このスキルを入れても安全か」という一文にまとめています。

配布の形を確かめます。リポジトリは2026年3月21日に作られ、ライセンスはApache-2.0です。2026年10月27日時点でスターは2万2109、派生は1931に上ります。最後の更新は10月23日で、同じ日に2.13.1の版が公開されました。9月以降だけでも複数の版が出ており、大手の組織が、速い頻度で手を入れ続けているOSSと読めます。作り手は個人ではなく、NVIDIAの組織アカウント（2012年作成）です。

位置づけも確認しておきます。READMEによると、SkillSpectorはNVIDIAの検証済みスキルの仕組み（Verified Skills）の一部で、この仕組みはスキルを公開する前に検査し、評価し、署名します。検査を通ったスキルはNVIDIAのスキル集に公開されると説明されています。NVIDIAの公式ドキュメントでは、スキルの公開前の評価を行う道具の中で、セキュリティを受け持つ第一段階とされています。自社のスキルを公開する前の関門として使われてきた道具を、利用者側にも開いたものと理解すると分かりやすいでしょう。

なぜ今、スキルを導入前に検査する必要があるのか

READMEは冒頭で、AIエージェントのスキルは「暗黙の信頼のもとで、ほとんど審査されずに実行される」と指摘しています。根拠として挙げられているのが、2026年の研究論文です。主要な配布の場から集めた4万2447件のスキルのうち、分析した3万1132件について、26.1%に少なくとも一つの脆弱性があり、5.2%に悪意の可能性が高い兆候があったとされています。また、実行できるプログラムを含むスキルは、脆弱性を持つ割合が2.12倍高いという結果も紹介されています。

これらの数字は論文の分析によるもので、この記事で独自に確かめたものではありません。それでも、スキルという部品の性格を考えると、危険の構造は理解しやすいはずです。スキルは手順書の形をしているため、従来のプログラムの検査では見逃されやすい一方、エージェントはその手順書に書かれた指示に従って、ファイルを読み、命令を実行し、外部と通信します。文章の形をした部品が、プログラムと同じ権限で動くという点が、スキルの危うさの核心です。

さらに、スキルは社員一人ひとりが気軽に足せます。公開の場から取ってきたスキルを、情報システム部門が把握しないまま業務の端末で使っている、という状況は珍しくないと考えられます。ソフトウェアの導入には申請と審査があるのに、スキルの追加だけが審査の網から漏れている組織も多いはずです。SkillSpectorのような道具が注目されている背景には、この空白を埋めたいという需要があります。

何を検査するのか。17の分類に分けた危険の型

READMEは、検出の型を17の分類に整理しています。プロンプトインジェクション（AIへの不正な指示の紛れ込み）、安全装置を外させる指示、情報の持ち出し、権限の引き上げ、供給網の危険、過剰な自律性、出力の扱い、システムプロンプトの漏えい、記憶の汚染、道具の悪用、暴走するエージェント、起動条件の悪用、危ないプログラムの呼び出し、汚染された値の流れの追跡、既知の不正なプログラムの特徴、MCPの最小権限、MCPの道具の説明への毒の仕込みです。

具体的な例をいくつか挙げます。情報の持ち出しでは、環境に設定された秘密の値を集める書き方や、会話の内容を外部へ送る書き方が対象です。供給網では、版を固定していない依存部品、外から取ってきた処理をそのまま実行する書き方、有名な部品に似せた名前、部品の入手先のすり替えなどが並んでいます。起動条件の悪用では、ありふれた言葉で起動するように書かれたスキルや、既存の命令や別のスキルを横取りするスキルも検出の対象です。スキルならではの危険まで型として整理している点が、この道具の特徴です。

MCPの道具に関しては、説明文に隠された指示（見えない文字や埋め込まれた符号化文字列）、見た目の似た別の文字による偽装、宣言した権限と実際の処理の食い違いを見ます。権限の宣言にない機能をプログラムが使っていれば、宣言より多くのことをしている部品として指摘される仕組みです。なお、検出の型の数はREADMEでは71、NVIDIAの公式ドキュメントでは68と記載が分かれていました。版の更新で型が増えている途中と考えられ、数は目安として読むのが妥当です。

二段階の解析。静的な解析と、AIによる意味の確認

READMEによると、検査は二段階です。第一段階は静的な解析で、文字の並びの型による照合、パイソンのプログラムの構文を読んで危ない呼び出しを探す解析、外から入った値がどこへ流れるかを追う解析、既知の不正なプログラムの特徴を記したYARAの規則による照合、そして依存部品の既知の脆弱性の照会を組み合わせます。READMEはこの段階を「取りこぼしは少ないが、誤検知もある程度ある」と説明しています。

第二段階は任意で、AIに文脈と意図を評価させます。公式ドキュメントの表現では、スキルが説明で主張していることと、プログラムが実際にしていそうなことを比べる工程です。説明と動きの食い違い、あいまいな起動条件など、規則の型では拾いにくい問題を狙っています。

注目したいのは、AIの扱い方です。READMEによると、AIが確認した指摘は説明が加わり確からしさが上がることはあっても、下がることはありません。静的な解析で見つかった指摘は、AIが同意しても反対しても報告に残り、AIが確認しなかったものには「未確認」の印が付きます。AIの判断で、規則による指摘が消されない設計です。AIに渡す指示には、悪意のあるスキルが解析を操ろうとすることへの対策も入っているとされます。ただしREADMEは、第二段階の結果は使うAIと文脈に左右され、一定の精度を保証するものではないとも書いています。

0から100の危険度の点数と、三つの推奨

検査の結果は、0から100の危険度の点数と、重大度、推奨としてまとめられます。READMEによると、点数は指摘の重大度ごとに加算されます。重大な指摘が1件で50点、高い指摘で25点、中程度で10点、低い指摘で5点です。実行できるプログラムを含むスキルには1.3倍の係数がかかります。

点数の帯は四つです。0から20は「安全」、21から50は「注意」、51から80と81から100は、どちらも「導入しない」が推奨になります。報告の形式は、画面への表示、機械で扱うためのJSON、人が読む文書の形式、開発の検査結果を集める仕組みで使われるSARIFの四つから選べます。公式ドキュメントは、画面表示は手元での確認、JSONは自動化、文書の形式は審査の資料、SARIFは開発工程への組み込みと、用途に分けて説明しています。

点数の読み方には注意が要ります。加算の方式のため、重大な指摘が1件だけでも50点に届きますが、それだけでは「注意」の帯にとどまります。逆に、軽い指摘が多数あれば点数は上がります。点数は優先順位を付ける材料で、合否の証明ではないと考え、どの規則に当たったのか、根拠となった箇所はどこかを、必ず報告の本文で確かめるべきです。

検査の結果を導入の関門につなぐ考え方

READMEは、SkillSpectorを導入の関門として使う場合の対応づけを示しています。推奨が「安全」なら許可、「注意」なら利用者に確認を促すか警告、「導入しない」なら遮断、という対応です。そのうえで、関門をどこまで厳しくするかは、組み込む側の方針の判断だと明記しています。たとえば「注意」を自動の検査で止めるかどうかは、道具ではなく導入する組織が決めることです。

初期の設定では、「安全」と「注意」はどちらも通過として扱われます。READMEによると、指摘が1件でもあれば止める指定、解析が途中で終わった場合に止める指定、解析できた割合が基準を下回ったら止める指定が別に用意されています。既定のままでは、「注意」の帯にあるスキルが、そのまま関門を通ってしまうことになります。どの指定を使うかを、社内の基準として先に決めておく必要があります。

公式ドキュメントには、指摘の種類ごとの対応の目安も載っています。重大度が重大または高いものは、修正するか正式に受け入れるまで公開を止める。隠された指示や道具の説明への毒の仕込みは取り除く。宣言にない機能は、権限を宣言し直すか処理を取り除く。既知の脆弱性がある部品は、更新するか受け入れる理由を記録する。説明と動きが食い違うなら、説明か処理を直す、というものです。目指すのは報告がきれいになることではなく、目的、権限、プログラム、記録された危険が一致している状態だと説明されています。

誤検知の扱いと、受け入れた指摘の記録

検査の道具を業務に組み込むと、誤検知とどう付き合うかが必ず問題になります。SkillSpectorには、既に確かめて受け入れた指摘を「基準線」として登録し、再検査では新しい指摘だけを示す仕組みがあります。説明文書によると、受け入れた指摘には一件ごとに理由を書き残す形になっており、受け入れた指摘は点数には数えられません。

受け入れた指摘が消えてなくなるわけではない点も大事です。説明文書によると、開発工程向けの形式では「外部で受け入れ済み」の印付きで残り、JSONの報告にも一覧として必ず含まれます。また、解析が途中で終わった状態は、指摘を受け入れても「不完全」のまま残ります。何を、なぜ受け入れたかを後から監査できる作りです。

この仕組みは便利な一方で、使い方を誤ると検査を形だけのものにします。今ある指摘をまとめて受け入れる操作もできるため、担当者が指摘を読まずに一括で受け入れれば、検査は何も見ていないのと同じになります。受け入れの理由を誰が書き、誰が承認するかを決めておくことが、この機能を生かす前提です。

手元に残る情報と、社外へ出る情報

防御担当者にとって最も大事なのは、どの情報が社外へ出るかです。READMEの「信頼のモデルと情報の外部送信」の節は、この点をはっきり書いています。まず、検査するスキルを実行することはないと明記されています。解析はすべて静的なもので、それにAIによるファイルの中身の評価が任意で加わる形です。

一方で、AIによる確認を使う場合は、解析の対象となるファイルの中身が、設定したAIの提供元へ送られます。READMEによると、AIによる確認は初期の状態で有効になっており、提供元の初期の設定はNVIDIAの推論サービスです。OpenAI、Anthropic、Bedrock、Azure、Gemini、手元で動かすOllamaなども選べます。何も決めずに使うと、スキルの中身が外部のAIに渡りうるということです。静的な解析だけで動かす指定にすれば、ファイルの中身は手元に残るとされています。

もう一つ、依存部品の既知の脆弱性の照会は、静的な解析だけで動かしても行われます。READMEによると、スキルが宣言する部品の名前と版を、公開の脆弱性データベースであるOSVに問い合わせます。送るのは部品の名前と版で、ファイルの中身ではありません。外部と通信できない環境では、同梱の小さな一覧で代わりに照合しますが、その場合は検出できる範囲が狭くなります。社内の部品の名前そのものが機密に当たる組織では、この照会も情報管理の担当と確認しておくべき点です。

従来の手段と何が違うのか

スキルを取り込む前に確かめる方法は、ほかにもあります。一次情報で確認できた範囲をもとに、代表的なやり方と比べます。どれが優れているかではなく、何を見たいかで組み合わせる話です。

見る点	人が目で読む	従来のコード検査・部品の監査	SkillSpector
手順書に紛れた不正な指示	読めば気づける場合がある	多くは対象外	規則の型で照合し、任意でAIが意図を評価する
見えない文字や似た文字での偽装	目では気づきにくい	対象外のことが多い	道具の説明や手順書の中を規則で調べる
宣言した権限と実際の処理の差	読む人の力量による	対象外	宣言にない機能や広すぎる権限を指摘する
依存部品の既知の脆弱性	調べれば分かる	得意な分野	公開の脆弱性データベースに照会する
結果の形	確かめた人の記録	検出の一覧	点数・重大度・推奨と、規則ごとの根拠
実行して動きを見ること	しない	製品による	しない。動かしたときの振る舞いは見ない

表のとおり、SkillSpectorの強みは、スキルとMCPの道具に特有の危険を型として整理し、一つの道具で調べられる点です。従来のコード検査や部品の監査を置き換えるものではなく、スキルという新しい部品の分だけ網を広げるものと位置づけるのが妥当でしょう。実際に動かしたときの振る舞いを見る仕組みは別に要ります。

安全性の評価：紹介可とした根拠

このラインでは、紹介する題材を公開されている事実だけを基に精査しています。題材を入手したり動かしたりはしていません。SkillSpectorの判定は「紹介可」です。

根拠は次のとおりです。公開元は2012年に作られたNVIDIAの組織アカウントで、作り手の実態は確かめやすい部類です。ライセンスはOSI承認のApache-2.0です。GitHub上に、このリポジトリのセキュリティ勧告は2026年10月27日時点で登録されていませんでした。リポジトリ直下の配布用の設定ファイルは、別の道具に組み込むための非公開の設定で、入れたときに自動で動く処理は登録されていませんでした。弱点の報告の方針の文書では、公開の場ではなく、NVIDIAの製品セキュリティの窓口（PSIRT）へ届け出るよう求めています。

スター数は1日あたり約100件の勢いで増えていますが、古くからある大手の組織の公開物であることから、不自然な水増しとはみていません。変更の記録を見ても、検出の見落としや誤った判定の修正が細かく積み重ねられています。なお、この判定は安全の保証ではありません。精査は公開情報の範囲に限られ、プログラムの全体を検証したものではないからです。導入する組織は、自らの基準で改めて確かめる必要があります。

検査の限界と、公式が明記する前提

READMEは、SkillSpectorを「多層防御の一つであり、隔離の仕組みではない」と位置づけています。危ない型を導入前に示すのが役割で、それでも導入すると決めたスキルを封じ込めたり、端末から切り離したりはしないと明記されています。検査を通ったスキルを動かす環境の守りは、別に考える必要があります。

限界として挙がっているのは五つです。英語以外の言語で書かれた指示は見逃す可能性があること、画像の中の文字は解析できないこと、暗号化されたものや機械語に変換済みのプログラムは解析できないこと、実行時にだけ現れる振る舞いは見えないこと、外部と通信できない環境では脆弱性の照会が小さな一覧に限られることです。日本語で書かれたスキルを主に使う組織にとって、言語による見逃しの可能性は見過ごせない点です。

解析の量にも上限があります。説明文書によると、一つのスキルの束で扱うファイルの数、容量、階層の深さ、処理の時間などに上限が設けられ、上限に達した場合は「一部だけ解析した」と報告されます。文書は、上限は安全のための境界であって、調べた部分に問題がなかったことの証拠ではないと明記しています。署名の情報を含む束についても、中身は解析するものの、署名そのものの正しさや署名者の確認は行わないと書かれています。

悪用されうるリスク

SkillSpectorは守りのための道具で、攻撃に使うための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査で問題なし」という結果が、安全の証明として独り歩きすることです。先に見たとおり、言語や実行時の振る舞いによる見逃し、解析の上限による一部の解析は、仕組みとして起こりえます。

次に挙げるのは推測ですが、検討の材料として無視できません。検出の型が公開されている以上、攻撃者がその型を避ける書き方を工夫する可能性があります。英語以外で指示を書く、実行時にだけ外から指示を取ってくる、といった手口は、公式が挙げる限界とも重なります。検査の道具が広まるほど、それをすり抜けようとする工夫も生まれると考えておくのが自然です。

もう一つは、道具そのものの扱いです。READMEによると、エージェントから検査を呼び出せるMCPサーバーとして動かす使い方があり、通信で受け付ける形では認証がなく、届く者は誰でも検査を呼び出せると注意書きがあります。受け付けるのは自分の端末の中からの接続だけに限られているとされますが、共用の端末や基盤で動かす場合は、誰が呼び出せるかを確かめる必要があります。なお、この道具が実際に悪用された事例は、2026年10月27日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、道具を動かす前の段階で終えられるものに絞っています。

この手順の要は、動かす前に「何を外へ出すか」と「どの結果で止めるか」を決めておくことです。検査の道具は、入れた瞬間から「調べている」という安心を生みます。その中身を先に決めておかないと、報告が誰にも読まれない状態や、点数だけで通過が決まる状態が続きます。

企業が取るべき対策

一つ目は、スキルとMCPの道具を、ソフトウェアと同じ審査の対象にすることです。社内規程に「エージェントに足す手順書や道具も、導入前の審査の対象とする」と明記します。把握していない部品は、検査の対象にもならないからです。二つ目は、許可したスキルの一覧を作ることです。許可したもの、確認中のもの、使わないものに分け、検査の道具は一覧に載せる前の確認の手段として使います。

三つ目は、検査の結果の扱いを決めることです。点数の帯ごとに許可、確認、遮断のどれにするかを決め、重大または高い指摘は人が根拠を読んでから判断するようにします。四つ目は、社外へ出る情報の決まりです。AIによる確認や依存部品の照会を使う条件を、ほかの開発支援の道具と同じ基準で決めます。

五つ目は、検査を通ったスキルを動かす環境の守りです。SkillSpectorは隔離の仕組みではないため、エージェントに与える権限を絞る、秘密の値を手の届く場所に置かない、外部への通信を見張るといった対策を別に用意します。導入前の検査と、導入後の権限の絞り込みと監視を組み合わせて、初めて守りに厚みが出ます。

AIに任せる範囲と、人が決める範囲

SkillSpectorは、人が読み切れない量のスキルを規則で調べ、任意でAIに意図を評価させます。AIの判断で規則による指摘が消えない設計になっているのは、AIを万能とみなしていない表れです。導入する側も同じ姿勢が必要で、AIや道具の判断のまま受け入れず、根拠を人が読むことが欠かせません。道具に任せてよいのは、決めた範囲の中で、規則に照らして怪しい箇所を示させる部分です。

どのスキルを検査の対象にするか、どの結果で止めるか、どの指摘を誤検知として受け入れるか、どの情報を外へ出してよいか。この四つは道具にもAIにも委ねず、人が決めて記録に残します。やってはいけない向き合い方を挙げます。

• 「安全」の推奨や点数の低さだけを理由に、スキルをそのまま全社の端末に配る
• AIによる確認の「問題なし」を、規則による指摘を無視する理由にする
• 初期の設定のまま使い、スキルの中身が外部のAIに送られていることに気づかない
• 今ある指摘を理由も書かずに一括で受け入れ、以後の検査を形だけにする
• 日本語で書かれた手順書も、英語と同じ精度で見てくれるものと思い込む
• 検査を通ったことを理由に、エージェントの権限の絞り込みや監視をやめる

裏を返せば、人が決める範囲ははっきりしています。何を検査するか、どの結果で止めるか、何を受け入れるか、何を外へ出すか。この四つが決まっていないまま検査の道具を入れても、守りの厚みは増えません。AIに判断させず、根拠を示させ、人が確認する範囲を先に決めることが基本です。

よくある質問：検査で問題が出なければ導入してよいのか

答えは「それだけでは決められない」です。SkillSpectorは、スキルを実行せずに中身を読んで、既知の危険の型を探す道具です。READMEが挙げる限界のとおり、英語以外の指示、画像の中の文字、実行時にだけ現れる振る舞いは見えない可能性があります。検査は判断の材料の一つで、導入の可否を決めるのは人です。作者、入手した経路、求める権限、業務での必要性とあわせて判断します。

もう一つ、「NVIDIAが出しているOSSなら、そのまま使ってよいのか」という問いもありそうです。ライセンスはApache-2.0で、提供元の実態も確かめやすく、判定は紹介可としました。ただし、初期の設定ではAIによる確認が有効で、スキルの中身が外部の提供元に渡る点は、提供元の信頼性とは別に、自社の情報管理の基準で判断すべきことです。まず限られた範囲で、使う機能と止める基準を決めてから広げるのが現実的です。

• SkillSpectorの機能・版・配布の形・外部への送信の説明は、GitHubのリポジトリとその中の文書、NVIDIAの公式ドキュメントを2026年10月27日に確かめた範囲に基づきます。更新の頻度が高く、内容は変わる可能性があります
• 検出の型の数は、READMEでは71、公式ドキュメントでは68と記載が分かれていました。研究論文の数値は論文の分析によるもので、この記事で独自に確かめたものではありません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

SkillSpectorは、Claude CodeやCodexなどで使うスキルやMCPの道具を導入前に調べ、不正な指示、情報の持ち出し、供給網の危険などを見つけるNVIDIAのOSSです。Apache-2.0で公開され、スキルを実行しない静的な解析と、任意のAIによる意味の確認の二段階で、危険度の点数と推奨を返します。AIの判断で規則による指摘が消えない設計や、受け入れた指摘に理由を残す仕組みなど、業務に組み込むことを意識した作りです。

一方で、公式自身が「隔離の仕組みではない」と明記しており、言語や実行時の振る舞いによる見逃しもありえます。初期の設定ではスキルの中身が外部のAIに送られる点も、導入前に確かめるべきところです。何を検査するか、どの結果で止めるか、何を受け入れるか、何を外へ出すかは、道具ではなく人が決める範囲です。この四つを先に決めたうえで使うことが、スキルという新しい部品の入り口を守る関門として、この道具を生かす方法です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。