スキルを「とりあえず入れる」時代は、もう終わった
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。
2025年末にAnthropicが公開した「Agent Skills」を起点に、AIエージェントへ業務知識を授ける単位は持ち運べるパッケージになりました。SKILL.mdという1枚のテキストと付随ファイルをフォルダにまとめるだけで、Claudeでも他社のコーディングツールでも同じスキルが読み込める——この手軽さが普及を一気に押し上げました。
しかし手軽さの裏側で、見過ごせない構図が生まれています。スキルが「誰でも作れて・誰でも配れて・誰でも入れられる」状態になった瞬間、それは新しいソフトウェアの供給網（サプライチェーン）になったのです。npmやPyPIのパッケージと同じく、出所の怪しいもの・改ざんされたもの・悪意ある指示が仕込まれたものが流通しうる。実際、Snykが2026年2月に公開した「ToxicSkills」調査では、3,984件のスキルを精査した結果、約36%が何らかのセキュリティ上の欠陥を含み、人手レビューで76件に悪意あるペイロードが確認されました（Snyk, 2026）。公開の障壁は「SKILL.mdと作成1週間のGitHubアカウント」だけ。署名もレビューもサンドボックスも、既定では存在しませんでした。
そして2026年春、この供給網に「秩序」を持ち込む動きが具体化します。本記事では、NVIDIAが2026年5月19日に公開した**検証済みスキル（NVIDIA-Verified Agent Skills）**を手がかりに、スキルを安全に配るための4つの柱——出所確認・署名・スキャン・カタログ化——を整理し、エンタープライズが社内でスキルを配布・共有する際の供給網セキュリティをどう設計するかを、実務目線で解説します。
本記事は2026年春の「検証済み・署名付きスキル＝供給網」という観点に焦点を当てます。スキルの基本やSKILL.mdの作り方、過去のインシデントを起点としたガバナンス全般は、homulaの既存記事（Agent Skillsとは何か、セキュリティリスクと企業ガバナンス）で扱っています。
なぜ「スキル」が供給網問題になったのか
ポイントは、スキルが可搬（ポータブル）で共有可能なパッケージになったことです。Anthropicは2025年12月18日にAgent Skillsをクロスプラットフォームのオープン標準として公開し、スキルを「エージェントが動的に発見・読み込みできる、手順・スクリプト・リソースのまとまったフォルダ」と位置づけました。誰もが手順という暗黙知をパッケージ化し、共有できる——これが設計思想です（Anthropic Engineering）。
可搬になるということは、コードと同じ流通経路に乗るということです。従来のソフトウェア供給網が抱えてきた論点が、ほぼそのままスキルにも当てはまります。
- 出所（プロベナンス）が見えない: そのスキルを誰が作り、どこから来たのかが分からない
- 改ざんを検知できない: ダウンロードしたものが配布元のオリジナルと同一かを確認できない
- 悪意ある指示を含みうる: スキルは「指示文」そのものなので、隠れたプロンプトインジェクションや過剰な権限要求を埋め込める
- バージョンと依存が追えない: どの版を使っているか、何に依存しているかを管理できない
しかも、スキル特有の難しさがあります。従来のパッケージは「コード」を実行しますが、スキルは自然言語の指示でエージェントの振る舞いそのものを書き換える。コードスキャナでは引っかからない「言葉による攻撃」——たとえば本文に紛れた隠し命令や、宣言された目的と実際の挙動の食い違い——が成立してしまうのです。
スキルのリスクは「不正なコードが動く」だけではありません。指示文がエージェントを誘導する点が本質です。だからこそ、従来のコード署名・脆弱性スキャンに加えて、エージェント固有のリスク検査が要ります。
「検証済みスキル」とは何か——NVIDIAの4ステップ
ここで参照したいのが、NVIDIAが2026年5月19日に公開した技術ブログ「NVIDIA-Verified Agent Skills」です。同社はスキルに対して、ソフトウェア供給網セキュリティの実践をそのまま持ち込むアプローチを示しました。NVIDIAの定義によれば、「検証済み（Verified）」とは次の状態を指します——カタログ化され、スキャンされ、署名され、スキルカードで文書化されていること（NVIDIA Technical Blog, 2026-05-19）。
同ブログは、信頼の置きどころについて次のように述べています。
Trust should come from verifiable integrity and authenticity, not from implied provenance alone.（信頼は、暗黙の出所の前提からではなく、検証可能な完全性と真正性から生まれるべきだ）
つまり「NVIDIAが出しているから安心」ではなく、「署名で真正性を、スキャンで安全性を、カードで透明性を、機械的に検証できるから安心」という発想です。公開フローは大きく4ステップで整理できます。
各ステップの中身を、NVIDIAブログの記述に沿って見ていきます。
- ① カタログ化: スキルは各製品のリポジトリで管理され、自動同期パイプラインで毎日カタログへ反映される。台帳に載っていること自体が「管理対象である」ことの起点になります。
- ② スキャン: 公開前に、専用スキャナ SkillSpector が検査します。従来型の脆弱な依存・危険なコード・認証情報アクセス・データ持ち出し経路に加え、隠し命令・プロンプトインジェクション・トリガー悪用・過剰な権限・ツール汚染・宣言された目的と実挙動の不一致といったエージェント固有のリスクを対象とします。NVIDIAは、この検査をOWASPのLLM/エージェントAI向けガイダンスやMITRE ATLASといった既存の枠組みに根ざしていると説明しています。
- ③ 署名: OpenSSF Model Signing（OMS）を用い、スキルディレクトリ内のすべてのファイルとサブディレクトリを対象に署名します。利用側は配布された署名（
skill.oms.sig）と信頼の起点となる証明書を使い、ダウンロードしたスキルが本物で・改ざんされていないことを確かめられます。 - ④ 文書化（スキルカード）: スキルが何をするか・誰が作ったか・ライセンス・依存関係・既知の技術的限界やリスクと緩和策を機械可読な形式で明示します。人にとっての説明書であると同時に、自動チェックの入力にもなります。
ここで重要なのは、個々の要素はどれも新発明ではないことです。署名はOpenSSFの既存標準、スキャンの観点はOWASPやMITRE ATLAS。新しいのは「これらをスキルというパッケージに、当たり前の出荷基準として束ねた」点にあります。
NVIDIAのカタログ規模（収録スキル数・対象製品数）は毎日同期される性質上、時点で変動します。本記事では具体的な件数の断定は避け、仕組みに焦点を当てます。最新の数値や仕様は一次情報（NVIDIA Technical Blog／GitHubのNVIDIA/skills）でご確認ください。
供給網セキュリティを支える4つの柱
NVIDIAの事例を一般化すると、スキルを安全に流通させるための柱は次の4つに整理できます。自社で内製化するにせよ、外部のスキルを取り込むにせよ、この4点が「最低限のチェックリスト」になります。
| 柱 | 解決する問い | 具体的な手段 | これが無いと |
|---|---|---|---|
| 出所確認（プロベナンス） | 誰が作り、どこから来たか | 配布元の特定・作者の明示・台帳登録 | 出所不明のスキルが本番に紛れ込む |
| 署名（真正性・完全性） | 本物か、改ざんされていないか | 全ファイルへの暗号署名（例: OMS）と証明書検証 | すり替え・改ざんを検知できない |
| スキャン（安全性） | 危険な指示やコードを含まないか | 従来型＋エージェント固有リスクの自動・人手検査 | 隠し命令や持ち出し経路を見逃す |
| カタログ化（透明性・管理） | どの版を、何の根拠で使っているか | バージョン管理・スキルカード・更新の追跡 | 棚卸し不能、撤回（取り下げ）が効かない |
この4つは独立しているようで、実際は連鎖しています。署名だけあってもスキャンしていなければ「改ざんされていない危険物」を信頼してしまう。スキャンだけしても署名がなければ、検査済みのものとすり替えられる。出所が分かってもバージョンを追えなければ、ある版で見つかった問題を撤回できない。4つが揃って初めて「信頼の連鎖」が閉じるのです。
ただし注意も必要です。スキャンは万能ではありません。Snykの調査でも、確認された悪意あるスキルの一部が公開後しばらく取り下げられずに残っていたことが報告されています。自動検査をすり抜ける巧妙な攻撃は常にありえるため、「検証済み」は安全の保証ではなく、リスクを大幅に下げる仕組みと捉えるのが正確です。だからこそ、署名・スキャンに加えて「いつでも撤回でき、誰が使っているか追える」カタログ運用が効いてきます。
エンタープライズが社内でスキルを配るなら
ここまでは「世の中に流通するスキル」の話でしたが、企業にとって本当に効くのは社内での配布・共有です。経費精算、与信審査、問い合わせ一次対応——こうした業務知識をスキル化し、部署をまたいで共有すれば再利用が一気に進みます。しかし同時に、社内スキルこそ供給網管理が要ります。出所不明のスキルが「便利だから」と部署間でコピーされ、誰も中身を検証しないまま本番に入る——これは外部由来の攻撃と同じくらい危険です。
社内スキルの供給網は、おおむね次の段階で設計します。
- 持ち込み口を一本化する: 外部スキルも内製スキルも、必ず社内カタログ（登録窓口）を通す。直接コピーでの横展開を止める。
- 入口でスキャンと署名を必須にする: 登録時に自動スキャンをかけ、通ったものに社内署名を付す。署名のないスキルはエージェントが読み込めないようにする。
- 承認とアクセス制御を挟む: どの部署のどのエージェントが、どのスキルを使ってよいかを役割（RBAC）で制御する。機微業務のスキルは承認フローを必須にする。
- 使用を記録し、撤回できるようにする: 誰がどのスキルをいつ使ったかを監査ログに残す。問題が見つかった版は即座に取り下げ、影響範囲を追えるようにする。
この4段階は、要するに**「とりあえず入れる」を構造的に不可能にする**設計です。便利さを殺さずに、しかし検証されていないスキルが本番のエージェントに届かないようにする。供給網セキュリティの本質は、個々の検査の精度よりも、この「関門を必ず通す」運用フローを敷けるかにあります。
homulaの観点 — スキルの供給網を「内製化」と「統制」でつなぐ
ここまで述べた4つの柱（出所・署名・スキャン・カタログ）と、社内配布の4段階（一本化・入口検査・承認/RBAC・監査/撤回）は、homulaが支援する領域とそのまま重なります。
スキルを「作る」側では、homulaのAIエージェント・ブートキャンプが効きます。業務棚卸しからプロトタイプ構築、ROI試算までを3〜5日で行い、現場の暗黙知を再利用可能なスキルへ落とし込みます。ここで大切なのは、最初から出所が明確で、承認境界が定義されたスキルとして内製することです。後付けで供給網管理を被せるより、設計段階で「誰が作り、どこで承認し、どの業務に使うか」を織り込むほうが、はるかに低コストで安全になります。
スキルを「配る・使う」側では、AgensとAgens Controlが土台になります。AgensはMCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。スキルが参照するツール基盤を共通化できるため、スキルごとに個別連携を積み増す保守負債を避けられます。そしてAgens Controlは、図3で示した関門——承認フロー・DLP・5年分の監査ログ・RBAC——をセットで提供します。
- 承認フロー: 機微業務のスキル利用に人間の承認を挟む（図3の③）
- RBAC: どの部署のどのエージェントがどのスキルを使えるかを役割で制御する（同③）
- 監査ログ（5年分）: 誰がどのスキルをいつ使ったかを長期に追跡し、問題発生時に影響範囲を特定する（同④）
- DLP: スキル経由でのデータ持ち出し経路を抑える（図1のスキャン観点を運用面で補完）
「便利なスキルを早く配りたい」と「検証していないものは本番に入れたくない」は、しばしば対立します。homulaの勝ち筋は、この2つを順序で両立させることです。すなわち、ブートキャンプで出所の明確なスキルを内製し、Agensで共通のツール基盤に乗せ、Agens Controlで承認・RBAC・監査の関門を通す——この順序を守れる企業ほど、スキルを「とりあえず入れた便利機能」ではなく「撤回でき・追跡でき・統制された業務資産」にできます。
まとめ
2026年春、AIエージェントのスキルは「持ち運べるパッケージ」から「管理すべき供給網」へと位置づけが変わりました。NVIDIAの検証済みスキルが示したのは、カタログ化・スキャン・署名・文書化という、ソフトウェア供給網で培われた実践をスキルにも当てはめる方向性です。そしてその根底には「信頼は暗黙の出所ではなく、検証可能な完全性と真正性から生まれる」という考え方があります。
エンタープライズにとっての論点は明快です。外部から取り込むスキルも、社内で内製するスキルも、出所・署名・スキャン・カタログの4つを通したものだけを本番に届ける。そのために、持ち込み口を一本化し、入口でスキャンと署名を必須にし、承認とRBACで使用を制御し、監査ログで追跡して問題のある版は即座に撤回する。
「とりあえず入れる」時代から、「署名・出所確認・スキャン・カタログ化して安全に配る」時代へ。スキルの便利さを活かしきるのは、検査の精度そのものより、この関門を必ず通す供給網の設計ができるかどうかにかかっています。
スキルの供給網セキュリティは、「危ないから止める」のではなく「安全に配れる仕組みを先に作る」ことで前に進みます。どの業務をスキル化し、どこで承認し、どのツール基盤に乗せて配るか——自社に合った供給網の型を早めに設計することが、エージェント活用の成否を分けます。