AIエージェントのスキルは、反復業務に必要な指示、参考資料、時には実行スクリプトをまとめた作業パッケージです。会社で安全に使用するためには、導入前に内容と出所を検討し、実行時にアクセス可能なデータとツールを制限し、更新と廃棄まで管理する必要があります。悪性スキル検査はこのプロセスの重要な一歩です。
例えば、「議事録整理スキル」をインストールしたとしましょう。指定された議事録を読み込み、要約ファイルを作成するために必要な権限は比較的少ないです。しかし、このスキルがすべての業務フォルダを検索し、外部サーバーに診断資料を送信するよう要求する場合、説明された目的と実際の行動の間に差異が生じます。この差異を導入審査で見つけ、見落とされた要求は実行環境で阻止する仕組みが必要です。
この記事は、2026年10月1日に確認された公式文書に基づき、スキルの攻撃経路、検査ツールの役割と限界、企業が適用すべき運用基準を整理します。以下の運用モデルと例は、組織に合わせて調整できる提案であり、特定の製品のデフォルトセキュリティ設定や検出性能を測定した結果ではありません。
1. スキルがもたらすもの：指示、コード、依存関係
Agent Skillsの仕様において、中心となるファイルはSKILL.mdです。これには名前や説明などのメタデータ、作業手順を記した本文が含まれます。さらにscripts、references、assetsのような補助ディレクトリが付随することがあります。したがって、検査範囲はマークダウン文書一枚よりも広いです。Agent Skills仕様
スキルは業務手順を伝え、エージェントは自身に接続されたツールでその手順を実行します。MCPは外部ツールやリソースと接続する方法であり、プラグインは複数の機能を配布するまとまりとなり得ます。一つのスキルがMCPツールを使用したり、プラグイン内に含まれたりする可能性があるため、実際の導入審査では接続された構成要素まで確認する必要があります。
スキルが直ちにオペレーティングシステムの管理者権限を持つわけではありません。リスクの大きさは、エージェントが読み取れるファイル、使用できる資格情報、呼び出し可能なツールによって異なります。同じスキルでも、公開資料のみを読み取る環境と、運用DBを変更できる環境では結果が大きく異なります。
また、スキル全体が最初からモデルに表示されると仮定すると、レビューを見落としがちです。メタデータ、アクティブ化された指示、必要に応じて読み込まれる補助資料に分けてロードする方式が使用されます。最初のファイルが平凡であっても、後から読み込まれる文書やスクリプトが行動を変える可能性があります。プロジェクトリポジトリに含まれるスキルの信頼性を別途確認するよう勧告も公式実装ガイドにあります。Agent Skills実装ガイド
会社で管理すべき対象は結局、「どの出所のどのような内容が、どのようなエージェント権限で実行されるのか」です。
2. 悪性スキルを疑う兆候
悪性指示は必ずしも実行ファイルだけに隠されているわけではありません。自然言語で作業目的を変更したり、参考資料中の文章を上位指示のように従わせたりすることも可能です。外部コンテンツがモデルの行動を変える問題は、プロンプトインジェクションと関連しています。OWASP Prompt Injection
次の表は、議事録整理スキルを審査すると仮定した例です。項目一つだけで悪性だと断定するのではなく、業務目的と必要な権限が一致するかどうかを判断するために使用します。
| 確認点 | 検討が必要な兆候 | 確認内容 |
| — | — | — |
| 作業指示 | 既存ポリシーを無視する、またはレビュー担当者に内容を隠すよう要求 | 業務遂行に必要な手順か、承認体系を迂回しようとしているか |
| データアクセス | 指定された議事録以外に認証資料や全業務フォルダを探索 | 入力範囲が文書化され、実際に制限されているか |
| 外部通信 | 説明にないアドレスに原文・ログ・診断資料を送信 | 受信主体、送信項目、保管目的が承認されているか |
| 実行コード | 判読しにくい文字列からコマンドを作成したり、リモートコードを受け取って実行 | ソースと依存関係をレビューできるか、実行対象が固定されているか |
| 環境変更 | 承認規則・開始設定・他のスキルを修正したり、常時実行登録 | 継続的な変更が業務目的に含まれるか |
| 更新 | 慣れた名前を維持しながら権限・送信対象・インストール手順を追加 | 以前の承認範囲を超える変更か |
外部通信やシェル実行自体が悪性の証拠ではありません。ウェブ調査スキルはネットワークが必要であり、ビルドスキルはコマンドを実行する必要があります。逆にコードがないスキルでも、既に接続された送信ツールを誤用するよう指示する可能性があります。目的、データ、行動、権限を合わせて検討する必要があります。
図1. 検討すべき二つの経路：モデルに入る指示と実際に実行されるコード。Agent Skills仕様、OWASP Prompt Injection公式文書を基に再構成した概念図。
3. インストール前に隔離し、全体を検査する
企業の最初の統制点は、従業員がスキルを選択する瞬間とエージェントがスキルを発見する瞬間の間に設けるのが良いでしょう。レビュー前のパッケージは、エージェントが自動的に検索するスキルディレクトリの外に保管します。検査のためにダウンロードしたファイルが、直ちに業務エージェントの指示としてロードされるのを避けるためです。
導入要求には、少なくとも出所URL、作成主体、使用する業務、入力データ等級、必要なファイル・ツール・ネットワーク権限、責任者を記載します。公開リポジトリの人気度や「公式」表示は出所を判断する手がかりですが、現在ダウンロードされた内容の適合性まで証明するものではありません。
検査対象を確定する際には、リポジトリ名だけを記録しません。正確なコミットとダウンロードされた全パッケージのハッシュを保存します。ハッシュはファイル内容で計算された指紋です。これは、後で配布されたファイルがレビューしたファイルと同じであるかを確認するために使用します。署名と出所証明も整合性と供給経路の判断に役立ちますが、正常な製作者が組み込んだ危険な機能まで自動的に除去してくれるわけではありません。サプライチェーンの複数の点を区別する観点は、SLSA脅威モデルを参照できます。
レビューリストには、SKILL.mdだけでなく、関連する文書、スクリプト、設定ファイル、ロックファイル、インストール時に実行されるフックを含めます。シンボリックリンクが指す外部ファイルやサブモジュールも実際の内容を確認します。実行中に他のアドレスから指示やコードを取得する場合、その外部コンテンツが承認範囲を超えないように別途管理する必要があります。
リモートインストールコマンドを先に実行してから結果を検査すると、インストール過程で既にコードが実行されている可能性があります。隔離された収集環境で資料を確保し、インストール段階の行動も分析対象とする順序が適切です。
図2. 企業向け導入・運用手順の提案。Agent Skills実装ガイド、Cisco検査推奨設定、SLSA脅威モデル公式文書を基に再構成。保留・拒否・例外基準は組織が定めます。
4. 悪性スキル検査は複数の方法を組み合わせて使用する
形式検査とセキュリティ検査は異なる質問に答えます。例えば、仕様検証ツールは必須メタデータや名前の規則を確認できますが、「要約後、原文を外部に送信せよ」という指示の業務上の正当性まで保証するものではありません。Agent Skillsの参照検証ツールも仕様検証用途として理解すべきです。Agent Skills検証ガイド
実務では、次のように検査を分けると見落とされた領域が見えてきます。
| 検査層 | 主に確認すること | 残る限界 |
| — | — | — |
| 形式・ファイルリスト検査 | メタデータ、参照ファイル、予期せぬファイルとリンク | 有効な形式の悪性指示は通過する可能性あり |
| 秘密情報・コード・依存関係検査 | 含まれるキー、危険なコードフロー、既知の脆弱性、固定されていない依存関係 | 自然言語の目的歪曲や新しい攻撃を見落とす可能性あり |
| 自然言語・意味分析 | 目的と行動の不一致、指示の迂回、不要な情報送信 | 誤検知・未検知があり、分析モデルも入力に影響を受ける可能性あり |
| 隔離実行試験 | 実際のファイルアクセス、プロセス、通信、生成・変更結果 | 試験していない条件や遅延された行動まで保証できない |
| 人による承認レビュー | 業務必要性、データ等級、権限、例外事由 | レビュー担当者が確認する根拠と組織基準が必要 |
Cisco Skill Scanner: スキル専用分析の出発点
CiscoのSkill Scannerは、ルールベース検査、コード・データフロー分析、選択的LLM分析などを組み合わせます。プロンプトインジェクション、情報漏洩、難読化、依存関係関連のリスクなどを検出するために使用できます。ただし、–use-behavioralのデータフロー分析を、実際にスキルを実行するサンドボックス試験と混同してはなりません。公式文書も、検出結果がないという事実がセキュリティ認証ではないと明記しています。Cisco Skill Scanner、公式リポジトリ
運用では、検出の深刻度と同じくらい検査完了の有無が重要です。公式推奨設定文書には、LLM分析失敗がLLM_ANALYSIS_FAILEDというINFO項目として報告され、ゲートを通過できるという説明があります。したがって、会社の承認手順は「高いリスクの発見なし」と「必須分析がすべて成功した」を別途確認する必要があります。ルールのみを使用する検査と、外部モデル・サービスを接続する検査も区別します。Cisco検査推奨設定
Snyk Agent Scan: 接続されたエージェント構成要素まで確認
Snyk Agent Scanは、スキルとMCPサーバーなどのエージェント構成要素を調査するツールです。スキル単独の内容検査と、接続環境の調査範囲を区別して使用できます。特に公式READMEでは、MCP設定検査過程でサーバーコマンドを実行したり、リモートアドレスに接続したりする可能性があると説明しています。信頼できないMCP設定は、検査自体も隔離環境で実行する必要があります。CLI出力構造が実験的であるという案内もあるため、特定のフィールドに依存する社内遮断ロジックはバージョンを固定し、変更を検証する必要があります。Snyk Agent Scan公式リポジトリ
検査ツールを選ぶ際には、検出機能とともにデータ処理方式を確認します。会社のスキルには内部アドレス、業務規則、非公開コードが含まれる可能性があります。オンラインアップロードや外部LLM分析を使用する場合、何がどのサービスに送信されるのか、保管・学習利用条件は何なのかを確認した上で許可する必要があります。「ローカルで実行するCLI」という理由だけで、すべての処理がローカルで完結すると仮定してはなりません。
ツールの検出率をこの記事で順位付けして比較することはありません。同一の試験資料とバージョンで測定していないためです。企業は、正常な業務スキル、禁止行動を要求する試験スキル、分析失敗事例を合わせて、独自の回帰試験を作成する方が有用です。
5. レビュー担当者が確認すべきは「なぜこの権限が必要なのか」
議事録整理スキルをレビューする場合、読み取るフォルダと作成するファイルをまず決めます。外部アップロードが不要であれば送信機能を除外し、資料取得に別途アカウントが必要であれば、必要な文書のみを読み取る接続を提供します。このように業務を具体化することで、過度な権限を発見しやすくなります。
自然言語分析をLLMに任せる場合でも、検査対象の指示は信頼できない入力として扱います。レビューモデルには実際の業務用資格情報と実行ツールを与えず、「問題なし」という結論よりも、疑わしい文章・ファイル位置・予想される行動・必要な権限を根拠として提出させます。モデルの判定はレビュー資料として使用し、高リスクの例外承認まで同じモデルに任せる構造は避けます。
誤検知を処理する際には、検査規則を丸ごとオフにするのではなく、当該バージョンの特定の動作が必要な理由を記録します。例外には適用範囲、責任者、有効期限を設けます。業務用に承認した送信アドレスが変わったり、データ等級が変更されたりした場合は、既存の例外を再利用しません。
レビュー記録は次の質問に答えられると実用的です。
- どのような業務に使用するスキルで、承認された正確なパッケージは何か？
- どのようなデータを読み取り、何を書き込んだり外部に送信したりできるか？
- 発見された警告をなぜ受け入れたり遮断したりしたのか？
- 実際の実行環境が承認された権限範囲を強制しているか？
- 問題が発生した場合、誰が使用を中断し、影響を調査するのか？
6. 実行中はモデル外で権限を制限する
事前レビューを通過したスキルにも、実行時の統制が必要です。正常なスキルが読み取ったウェブページや文書に悪性指示が含まれている可能性があり、承認後に依存関係や外部資料が変更されることもあります。OWASPは、機能と権限を最小化し、高リスク行動は別途承認し、下位システムで権限を検証するよう勧告しています。OWASP Excessive Agency
企業向け設計では、次の四つの境界を分けて点検できます。
ファイル境界：作業に必要な入力のみを読み取り専用で提供し、結果物を書き込むディレクトリを分離します。個人ホーム全体や他のプロジェクトまでアクセスさせないようにします。実行環境にホスト制御用ソケットや運用資格情報を一緒に露出させると、隔離の意味が弱まります。
ネットワーク境界：基本的に外部接続を制限し、業務に必要な宛先のみを許可します。ドメインが許可されていても、そのサービスの任意のストレージや他の組織アカウントにアップロードできる場合、情報漏洩経路が残ります。可能であれば、専用API中継層で対象アカウント・リソース・リクエストの種類まで検証します。LLM提供者に伝達されるプロンプトもデータ送信境界に含めます。
ツールと資格情報境界：汎用シェルや任意のURL呼び出しよりも用途が狭いツールを提供します。秘密値をプロンプトに入れるよりも、中継サービスが保管する短寿命の制限された資格情報で承認された作業のみを実行するよう設計します。ツールサーバーは、呼び出したユーザーに実際の権限があるかどうかも確認する必要があります。
外部行動境界：メール送信、運用デプロイ、大量削除などの作業は、実行直前の対象と内容を確認します。人が承認した場合、その承認と実際の実行引数を紐付け、内容が変更された場合は再度検査します。最終回答だけを遮断しても、既に実行された送信や変更は元に戻りません。
図3. 議事録処理業務のための実行境界提案。OWASP Excessive Agency、Claude Codeサンドボックス文書公式文書を基に再構成。特定の製品のデフォルト構成を示すものではありません。
サンドボックスを有効にしたという事実だけで、すべてのツールが制限されると結論付けてはなりません。どのようなプロセス・ファイルツール・ブラウザ・MCPサーバーがその境界内にあるのかをそれぞれ確認する必要があります。例えば、Claude Codeのサンドボックス文書は、コマンド実行のファイル・ネットワーク隔離、隔離外での再試行、使用できない場合の処理方式を区別しています。組織が隔離を必須と要求する場合、失敗時に通常実行に移行する経路まで点検する必要があります。Claude Codeサンドボックス
名前だけ見て信頼しやすい設定二つ
allowed-toolsをすべてのエージェントで同じ「ツール遮断リストの反対」と解釈するのは問題です。Agent Skills仕様では実験的フィールドとして説明されており、実装によってサポートが異なる可能性があると案内されています。Agent Skills仕様
Claude Codeの現在の文書では、allowed-toolsを当該スキル呼び出しターンで追加承認なしに使用するツールの指定として説明しています。リスト外のツールをすべて除去する機能ではなく、他のツールには別途の権限設定が適用されます。disable-model-invocation: trueは、モデルの自動スキル呼び出しを制限する設定です。自動呼び出し制御とファイル・ネットワーク隔離は異なる機能です。Claude Codeスキル設定
したがって、重要な制限は、レビュー対象のスキルが自ら宣言するに任せるのではなく、組織が管理する実行ポリシーとツールサーバーで強制する必要があります。製品とバージョンごとに実際の動作を確認し、許可されていない作業が拒否される試験も残します。
7. 承認されたスキルも更新と廃棄の手順が必要
社内リポジトリは、承認されたパッケージを配布する出発点となり得ます。ただし、リポジトリを作成するだけで終わると、ユーザーの個人スキル、プロジェクトに含まれるスキル、他のプラグインのスキルが一緒にロードされる可能性があります。組織が許可した供給経路と実際にロードされた出所を比較する必要があります。同じ名前のスキルが複数箇所にある場合に選択される対象もクライアントごとに確認します。
以下は社内承認記録の例です。製品の共通設定形式ではなく、会社が管理すべき項目を示しています。
| 管理項目 | 記録例 |
| — | — |
| 用途・責任者 | 議事録要約、業務自動化担当チーム |
| 承認対象 | オリジナルリポジトリ、コミット、全パッケージハッシュ、依存関係リスト |
| 実行条件 | 指定入力のみ読み取り、別途結果フォルダのみ書き込み、外部アップロード禁止 |
| 検査証拠 | スキャナー・規則・ポリシーバージョン、完了した分析、人によるレビュー、隔離試験結果 |
| 配布条件 | サポートエージェントバージョン、適用ポリシー、承認有効期限 |
| 変更・廃棄 | 更新再審査条件、回収担当者、中断・復旧手順 |
更新審査はSKILL.mdの変更分だけに限定されません。スクリプト、依存関係、接続サーバー、動的参照資料が変更されると、行動が変わる可能性があります。承認したファイルを配布直前とロード時に確認し、可能な構成は変更できないバージョンに固定します。エージェントやポリシーエンジンの更新が権限解釈に影響を与えるかどうかも合わせて試験します。
運用記録には、スキル識別子とハッシュ、呼び出したユーザー・業務、使用したツール、アクセス対象、許可・拒否結果を紐付けます。原文と秘密値を無制限に収集する必要はありません。保存範囲とアクセス者を制限し、機密値はマスキングする必要があります。
問題のあるスキルが発見された場合、新規インストール遮断とともに、実行中の作業、既にロードされた指示、キャッシュと配布コピーを確認します。必要に応じて作業を中断し、関連する資格情報の露出有無を調査して回収・交換します。スキルファイルが削除されたという事実と、実行中の作業が終了したという事実は別途確認する必要があります。
8. 会社で開始できる最小運用基準
最初からすべてのスキルを同じ手順で審査すると、運用負担が大きくなる可能性があります。公開資料の形式を整理する作業、非公開文書を読み取る作業、運用システムを変更する作業を区別し、データと行動の影響に合わせてレビューレベルを高める方式が現実的です。
最初の導入では、次の六つの基準を参考にできます。
- 承認された出所とバージョンのみを配布する。レビュー前の資料を業務エージェントが自動的に読み取らないようにする。
- 指示とコードを一緒に検査する。補助文書・依存関係・インストール手順まで含め、分析失敗は未レビュー状態のままにする。
- 業務目的に必要な権限のみを与える。ファイル、ネットワーク、ツール、データ等級を明示する。
- 隔離試験で制限を確認する。機能成功だけでなく、禁止された読み取り・送信・変更が実際に拒否されるかを確認する。
- 外部影響が大きい行動は別途検証する。人による承認とツールサーバーの権限検査を連携させる。
- 変更と回収を運用手順に組み込む。新バージョンの再審査、実行履歴、迅速な使用中断が可能であること。
肝心なのは、「悪性スキルを完璧に選別する検査器」を探すことに留まらないことです。検査結果は導入判断の根拠として活用し、実行環境は誤った行動の範囲を縮小し、運用手順は変化と事故に対応するように任せます。
企業でスキルを安全に活用するということは、レビューしたパッケージを必要な業務にのみ接続し、許可したデータと行動範囲が実際の実行でも維持されるかを確認することです。この基準が整えば、スキルの再利用性と自動化効果を組織のセキュリティ要件内で活用できます。
コメントを残す