AIスキルを入れるのは、他人のコードを自分のPCで動かすこと｜スコア100「CRITICAL」の15件が全部誤検知だった
Claude Codeのスキルを何本か入れて運用しているうちに、遅れて気づいたことがあります。
スキルを入れるというのは、他人が書いた手順とコードを、自分のPCの、自分のファイルが全部見える場所で動かすということだった。
拡張機能をブラウザに入れるのと同じ話です。ただスキルの場合、ファイルの読み書きとコマンド実行の権限を持ったAIが、その手順に従って動きます。 気づいてから、入れる前の確認を作業として固定しました。
この記事は運営者が実際にやった手順と実測値です。ツールの仕様や検出の傾向は変わるため、判断は必ず自分の環境で確かめてください。
結論：スコアは「見る場所」であって「判定」ではない
📌 先に結論 ① 新規スキルは配置する前に検査する（入れてからでは遅い） ② スコアを鵜呑みにしない。 実際にCRITICAL判定の全15件が誤検知だった ③ 検出時にAIがやってよいのは報告と提案まで。削除も修正も自動でやらせない
何で検査したか
使ったのは、AIスキル専用の静的解析ツール（NVIDIA製の SkillSpector・14.7kスター・Apache-2.0 ライセンス）です。選んだ理由は3つあります。
| 条件 | 実際 |
|---|---|
| ライセンスが商用利用を妨げないこと | Apache-2.0 |
| 中身を外部に送らないモードがあること | --no-llm でローカルの静的解析のみ |
| 環境を汚さずに入れられること | pip install --user でユーザー領域に限定 |
2番目が決め手でした。検査対象のスキルには、こちらのプロジェクト固有の情報が含まれることがあります。 それを外部に送る検査ツールでは本末転倒です。既定で外部に送るなら、送らない設定があるかを先に確認してください。
何を記録するか：SHA256ベースライン336ファイル
検査は「1回やって終わり」では意味がありません。入れた後に中身が変わったかどうかを見たいからです。
そこで、スキル関連の全ファイルのハッシュ値（SHA256）を一覧にして保存しています。初回のベースラインは336ファイルでした。次回は同じ一覧を作って突き合わせ、変化したファイルだけを見ます。
⚠ 更新は「勝手に起きる」ことがある 配布元がバージョン番号を上げずに中身を差し替える例を実際に踏みました（詳細はスキルの選び方と運用）。だからバージョン表記ではなくファイルのハッシュで見ます。
実行の頻度は毎月8日と22日の隔週で固定しました。日付を決めない運用は、実際にはやりません。異変に気づく手がかりがそもそも無いからです。
ここが本題：スコア100「CRITICAL」の中身が全部誤検知だった
初回の検査結果はこうでした。
| スキル | スコア | 判定 |
|---|---|---|
| 調査支援スキル | 100 | CRITICAL |
| デザイン審査スキル | 186 | HIGH |
| DB設計スキル | 40 | 中程度 |
CRITICALと出た時点で、削除するのが安全に思えます。実際にはそうしませんでした。検出された15件を1件ずつ、該当する行を開いて実物と照合しました。
結果、15件すべてが誤検知でした。内訳です。
| 検出内容 | 実際は何だったか |
|---|---|
| 外部への通信 | 引用元のURLが実在するかを検証する処理。調査結果に出典を付けるスキルなので、必須の機能 |
| ファイルの書き込み | 調査の途中経過を保存する状態ファイル。中断しても再開できるようにするための仕様 |
| 外部プロセスの起動（subprocess） | 自身のテストを走らせる処理。テストコード側にある |
デザイン審査スキルの186（HIGH）は、もっと分かりやすい話でした。
スキルの本文に 「secretsにアクセスするな」という禁止事項が書かれていた。検査ツールはその文字列に反応していた。
防御のために書かれた文言が、危険の証拠として数えられていたわけです。DB設計スキルの40も、引数が固定された subprocess の呼び出しで、外部からの入力が混ざる余地はありませんでした。
⚠ 静的解析は「何をしているか」しか見ない 「なぜそれをしているか」は見ません。正当な機能と攻撃は、コードの見た目が同じになります。 判断するのは人間の側です。
だからといって検査が無駄だったわけではない
ここを取り違えると、次から検査をやめてしまいます。実際に得たものは2つありました。
- どのスキルが、どこで、外部と通信し、何を書き込むかの一覧ができた。これは検査しなければ持てない情報です
- 誤検知の理由を書いた台帳ができた。次回同じ検出が出ても、5秒で「既知」と判断できます
2番目が本体です。検査の価値は「危険が無かった」という結論ではなく、「この検出は既知だ」と言い切れる状態になることでした。台帳が無いと、隔週の検査のたびに同じ15件を最初から調べ直すことになります。
固定した4つのルール
| ルール | なぜ |
|---|---|
| ① 配置する前に検査する。あわせてスキル本文を全文読む | コードの検査だけでは、指示文に書かれた「やらせたいこと」を見られない |
| ② スコアを鵜呑みにせず、行レベルで実物と照合する | CRITICALの15件が全部誤検知だった。逆にスコアが低くても安全の証明にはならない |
| ③ 検出時にAIがやってよいのは報告と提案まで（自動削除・自動修正・自動インストールを禁止） | 誤検知で必要なファイルを消される。修正されると原本と比較できなくなる |
| ④ ベースラインの更新は、全変更の出所が説明できたときだけ | 説明できない変更を含んだままハッシュを更新すると、その変更が「正常」として固定される |
①の後半は見落としがちです。スキルはコードだけでなく指示文でできています。コードが安全でも、指示文に「確認せずに実行してよい」と書いてあれば、危険なのは指示文のほうです。入れる前に全文を読むのは、行数が少ないうちなら現実的なコストでした。
④は、CLAUDE.mdの劣化で書いた「間違った前提は正しく守られてしまう」と同じ構造です。ベースラインは「これが正しい状態だ」という宣言なので、雑に更新すると以後の検査が全部無意味になります。
ライセンスは、検査より前に見る
もう1つ、実際に候補を落とした基準です。
プロジェクト管理系のスキルを何本か検討したとき、非商用（NC）ライセンスのものが多いことに気づきました。収益を出すサイトの作業に使うなら、この時点で候補から外れます。
📌 見る順番 スター数ではなく、①ライセンス → ②スキル本文の全文 → ③静的解析 の順。①で落ちるものに②③の時間をかけない。
スター数そのものが当てにならなかった件（紹介記事が157kと書いていたが実測169.6kだった）はスキルの選び方と運用に書きました。
そのまま使える確認の頼み方
検査の実行と解釈を、毎回同じ形で頼めるようにしています。
これから導入するスキルを、配置する前に確認したい。
1. スキル本文（指示文）を全文読み、「確認なしで実行させる」記述、
認証情報・環境変数・外部送信に触れる記述を抜き出してください
2. 静的解析を外部送信なしのモードで実行し、検出を一覧にしてください
3. 検出1件ごとに、該当ファイルの該当行を開いて実物を貼り、
「設計上必要な機能か / 不要か」を判定してください
スコアだけで判定しないでください
4. 削除も修正もしないでください。報告だけしてください
4行目を入れないと、「危険なので削除しました」で終わることがあります。 誤検知だったときに戻せません。
3行目の「該当行を開いて実物を貼る」も省けません。これを書かないと、検出内容の要約だけで「問題ありません」と結論されます。要約は、元の情報が正しいかどうかを判定しません。
まとめ
- スキルの導入は、他人のコードを自分の環境で動かすこと。ブラウザ拡張と同じ扱いをする
- 検査は配置前に。コードだけでなく指示文の全文を読む
- スコアは判定ではない。 CRITICAL（スコア100）の15件が全件誤検知、HIGHの原因は「secretsに触るな」という防御文言だった
- 価値は「安全だった」ではなく、誤検知台帳ができて次回5秒で判断できること
- AIには報告と提案まで。自動削除・自動修正・自動インストールはさせない
- 候補を絞る順番はライセンス → 本文 → 解析。スター数は最後
同じ「確認したつもり」の失敗は、見た目の検証でも起きます → AIの成果物は目視でなく実測で検証する
- 入れた後の運用とバージョンの罠 → AIスキルは入れた瞬間から腐る
- 検査の結果や判断を次のセッションに残す設計 → AIにAIを引き継ぐブリーフとメモリ設計
Claude Code自体で実際に起きた事故はClaude Codeとは何かにまとめています。