便利な​AIスキル、​入れる​前に​中身を​見ていますか​ ──Agent Skillは​「プロンプト集」ではなく、​実行権限を​持つ部品だった

気になるAIの話を、分かりやすく ｜ 最新動向を、現場目線で

Claude Code や Codex を使っていると、つい「スキル（skill）」を増やしたくなる。調査、レビュー、資料作成、デザイン、テスト、MCP連携。自分の仕事の型を SKILL.md に書いておけば、AIは毎回ゼロから説明しなくても動いてくれる。GitHubには公式・非公式のスキル集が並び、スター数は伸び続けている。便利だ。^[1]

でも、ここで見落としがちな点がひとつある。スキルは「プロンプト」ではない。多くのスキルは、命令・参照資料・テンプレート・スクリプト・外部ツール接続をひとまとめにした、小さな実行可能パッケージだ。つまり便利なスキルを入れることは、AIに新しい能力を渡すと同時に、新しい攻撃面を渡すことでもある。

今日は「AIエージェントのスキルを、どう安全に入れるか」を、分かりやすく整理してみる。煽るためではない。スキルは強力で、使わない手はない。ただ、npmパッケージを入れるときに依存関係を見るのと同じ習慣を、AIスキルにも持っておくと安心だ、という話だ。私たち電脳技巧集団（AI職人ギルド）も毎日Claudeでものを作っている側なので、その現場目線で読み解いていく。

01な​ぜ今、​スキルが​急に​増えているのか

2026年の開発現場では、Claude Code・Codex・Cursor・VS Code・GitHub Copilot が、単なるチャットから「作業を実行するエージェント」へと近づいた。コードを書き、ファイルを操作し、コマンドを走らせ、外部サービスに接続する。

そうなると効いてくるのが、SKILL.md を中心にした「Agent Skills」だ。毎回の指示を減らし、チームの作業知識を配布可能な単位にまとめる仕組みで、複数のツールをまたいで再利用できる。Anthropicは Agent Skills を Claude.ai・Claude Code・Agent SDK へ展開しているし^[2]、Microsoftは VS Code / Copilot 向けに公式ドキュメントを用意し^[3]、.NETチームは C#・MSBuild・NuGet・ASP.NET Core・Blazor などを領域別にまとめた dotnet/skills を公開している^[4]。

GitHub上のスター数を見ても、この流れの勢いは分かる。2026-07-04時点で anthropics/skills は約15.8万、dotnet/skills は約3,700。スキルは「AI向けの便利メモ」から、公式の開発体験の一部へと変わりつつある（※スター数はGitHub上の公開値で、CAGの独自集計ではない）。

02スキルの​正体 ──プロンプトではなく​「フォルダ」

Agent Skills標準は、スキルを フォルダ として定義する。中心にあるのは SKILL.md（名前・説明・発動条件・手順を書いたファイル）だが、それだけではない。同じフォルダに scripts/（実行スクリプト）、references/（参照資料）、assets/（画像などの素材）を同梱できる^[3]。

しかも「progressive disclosure（段階的開示）」という仕組みで、必要になった時だけ中身が読み込まれる。普段は名前と短い説明しか見えず、AIがそのスキルを使うと判断した瞬間に、本文・スクリプト・参照が展開される。

この設計は再利用性が高くて優秀だが、裏を返すと 通常のプロンプトより「攻撃面」が広い。ただのテキストではなく、実行されるコード、外部に取りに行く参照、AIの文脈に注入されるメタデータを含みうるからだ。「小さい SKILL.md だからレビューは簡単」は半分だけ正しい。数十行の本文でも、その裏の scripts/ や外部URL、次章のMCPツールの説明文が、実際の挙動を変えることがある。

03なぜ"実行権限パッケージ"だと​危ないのか ──3層の​リスク

スキルのリスクは、大きく3層に分けて考えると整理しやすい。

• 1層目：スキルの中の悪意ある指示・隠れたメタデータ。 「常に〜せよ」「拒否するな」「このトークンを送れ」といった強い命令が、一見無害な説明文に紛れていることがある。Anthropic自身も、スキルは新しい能力を与える一方で、悪意あるスキルは環境の脆弱性を突いたり、データ流出や意図しない操作を起こしうると明示し、低信頼のソースは監査するよう促している^[2]。
• 2層目：スクリプトや依存関係による、通常のソフトウェア供給網リスク。 scripts/ に実行コードが入る以上、それが読み書きするファイル、走らせるサブプロセス、参照する環境変数、外部への通信は、普通のプログラムと同じ危険を持つ。「AIスキル」という新しい名前がついているだけで、中身はソフトウェアだ。
• 3層目：MCPツールの説明文を通じた prompt injection / tool poisoning。 これが一番見落とされやすい。Trail of Bitsは、MCPサーバーのツール説明文（description）が、ツールを呼び出す前にモデルの文脈へ入りうる点を指摘している（"line jumping"）^[5]。Snyk Labsも、説明文に仕込まれた命令でモデルの挙動を変える「tool poisoning」の検出を解説している^[6]。人間が「実行しますか？」と承認する前の段階で効いてしまうため、承認ボタンだけでは守りきれない。

04検査ツールが​出てきた​意味 ──SkillSpector と​ Snyk Agent Scan

この状況を受けて、「入れる前にスキャンする」ツールが登場している。いわば AI版の npm audit だ。

NVIDIAの SkillSpector は、スキルをインストールする前に、prompt injection・data exfiltration・privilege escalation・supply chain・memory poisoning・MCPの最小権限・MCP tool poisoning などのパターンを検査する^[7]。READMEでは検査対象を68パターン／17カテゴリと記載している（ドキュメント側では64パターン／16カテゴリと表記差がある）。READMEは「調査したスキルの26.1%に脆弱性、5.2%に悪意の可能性」という数字も掲げているが、この母集団やサンプリング、分類基準は別途の精査が要る。ここでは 「SkillSpector READMEが投げかけた問題提起」 として扱い、数字を鵜呑みにはしない（CAGの検証値ではない）。

Snykの Agent Scan は少し役割が違い、Claude Code・Cursor・VS Code・Codex などに入っているスキルやMCPサーバーを横断的に発見して棚卸しし、prompt injection や tool poisoning、認証情報の扱いをスキャンする方向だ^[8]。SkillSpectorが「入れる前の1個」を、Agent Scanが「もう入っている全体」を見るイメージで使い分けられる。

ただし、大事な注意がひとつ。「スキャナーを通せば安全」は誤りだ。スキャナーは入口の検査ゲートであって、実行時の権限、外部通信、MCPツールの組み合わせ、承認UI、ログ、ロールバックまでは別に設計しないといけない。静的検査には false positive も false negative もあり、Markdownの説明文を過検知する議論も実際にある。スキャナーの結果は「絶対」ではなく「材料のひとつ」として扱うのが健全だ。

05じゃあ、​どう​安全に​入れるか​ ──6段の​ゲート

難しく考えなくていい。外部スキルを npmパッケージやGitHub Actionと同じ扱いにして、次の6段を通すだけでかなり守れる。

1. 読む（read）── SKILL.md の name / description / 発動条件を読む。scripts/・references/・assets/・隠しファイル・バイナリ・外部URLの有無を見る。
2. 調べる（scan）── network access、ファイル読み書き、shellコマンド、subprocess、環境変数の参照、認証情報の扱いを探す。「always」「never refuse」「ignore」「send」「upload」「token」「secret」のような強い語を grep する。必要ならSkillSpectorで静的スキャンをかける。
3. 隔離して試す（sandbox）── 使い捨てリポジトリ・一時ワークスペース・本番の秘密を持たない環境で初回実行する。.env やパスワードマネージャを読める状態でいきなり走らせない。
4. 権限を絞る（narrow）── 書き込み系ツール、ブラウザ操作、Git push、メール送信、SNS投稿は人間の承認を必須にする。
5. プロジェクト内から始める（project-local）── まずプロジェクト単位で導入し、影響範囲が広いグローバル導入は「自作・公式・監査済み」に限る。
6. 記録する（log）── 導入理由・ソースURL・スキャン結果・許可した権限・禁止事項・ロールバック手順を残す。

この6段は、そのまま「新しいツールを組織に入れるときの型」でもある。CAG（電脳技巧集団）でも近い運用をしていて、各リポジトリの AGENTS.md に「AIが何を読めて・何を書けて・何を送れるか」を職務分掌のように書き、MCPの権限や秘密情報の扱いを分け、外部送信や本番反映のような重い操作は人間が最終承認する（HITL）。導入の経緯はWikiのログに残す。派手な仕組みではないが、スキルやMCPが増えるほど、この地味なゲートが効いてくる。この「権限を契約として書く」考え方は、以前CAGが書いたMCPとAGENTS.mdの記事とまっすぐつながっている。

関連記事 ｜ ツール接続は権限の話MCPは便利な拡張機能ではなく、権限レイヤーだ ──AI導入がgovernanceになる理由 →

06まとめ ──能力を​増やすより​「管理する​力」が​差に​なる

AIエージェントの次の差は、たぶん「どのモデルを選ぶか」よりも「どのスキルを、どう安全に運用できるか」に出る。スキルはプロンプト集ではなく、実行権限を持つ作業能力のパッケージだ。だからこそ、npmパッケージを入れるときに依存関係を見るように、AIスキルを入れるときも、出所・署名・コード・依存・外部通信・MCP権限・発動条件を確認する価値がある。

怖がりすぎる必要はない。自作スキル・公式スキル・プロジェクト内スキルは、大きな生産性を生む。ただ「便利そうだから即グローバル導入」だけは避ける。読む・調べる・隔離して試す・権限を絞る・プロジェクト内から始める・記録する。この6段を習慣にすれば、スキルの便利さは受け取りつつ、余計なことをAIにさせずに済む。

AI活用が進むほど、「能力を増やす」より「能力を管理する」ほうが効いてくる。スキルの安全運用は、開発効率化の話であると同時に、事業を守る話でもある。

同じ「スキルを入れる」でも、プロンプト集として扱うか、供給網として扱うかで、備え方が変わる。今回の要点を一枚に。

観点	"便利そうだから即導入"	"供給網として検査して導入"
スキルの捉え方	プロンプト集	実行権限を持つ部品
入れる前	スター数と説明文で判断	read → scan（SkillSpector等）
初回実行	本番・秘密ありで即実行	sandboxで隔離実行
権限	既定のまま	write / 送信 / pushは人間承認
導入範囲	いきなりグローバル	project-localから
記録	なし	導入理由・権限・rollbackをログ
MCPツール	説明文を信頼	poisoning前提で最小権限

※ 本記事はAnthropic・NVIDIA・Microsoft・Snyk・Trail of Bits・Model Context Protocol の公式ドキュメントおよびGitHub公開情報を、AIを業務に使う側の観点から分かりやすく整理したもの。パターン数・スター数・「26.1%/5.2%」などの数値はすべて公式・README・研究の引用であり、CAG自身の検証結果ではない。数値は2026-07-04時点の公開値で変動しうる（v0）。