Claude Enterprise が Skill・プラグインの自動セキュリティ検査をベータ提供

要約

Claude の公式リリースノートに 2026-08-06 付で「Skill and plugin security scanning (beta)」が追加されました。Enterprise 契約の組織が、サードパーティ製の Skill とプラグインに対する自動セキュリティ検査を有効化できる機能です。アップロード時および変更時に、有害となりうるコードを検出します。

リリースノートの記述自体は数行で、詳細は書かれていません。どういう手法で検出するのか、何を検出項目としているのか、検出したときにアップロードをブロックするのか警告に留めるのか、対象は claude.ai なのか API なのか Claude Code なのか — いずれも公式には示されていません。ベータ機能として組織側で有効化する形、という点だけが明確です。

情報が薄いこの発表の意味を掴むには、これまで Anthropic が Skill の安全性について何を言ってきたかを見る必要があります。Claude Platform の Enterprise 向け Skills ドキュメントは、Skill の導入を「本番システムにソフトウェアをインストールするのと同じ厳格さで扱え」と表現し、人手による審査手順を詳細に規定しています。

具体的には7つのリスク指標が挙げられています。コード実行（Skill ディレクトリ内の *.py / *.sh / *.js）、指示の改変（安全ルールを無視させる、動作をユーザーから隠す、条件によって振る舞いを変える）、MCP サーバー参照（Skill 自体の範囲を超えてアクセスが広がる）、ネットワークアクセス（URL や fetch / curl / requests の呼び出し）、ハードコードされた認証情報、ファイルシステムのアクセス範囲（../ を含むパストラバーサルや広すぎるグロブ）、ツール呼び出し。そのうえで、SKILL.md と参照ファイル・同梱スクリプトの全文読解、サンドボックスでのスクリプト実行検証、敵対的な指示の確認、外部URLの検査、認証情報の確認など8項目のチェックリストを完了させてから配布せよ、としています。

これを毎回人手でやるのは、率直に言って現実的ではありません。Skill が10個なら回りますが、部門ごとに作られて数十個になった時点で審査待ちの行列ができます。今回のベータは、この一次スクリーニングを自動化するものと読むのが自然です。

ただし注意すべき点があります。2026-08-07 時点で、上記の Enterprise 向けドキュメントは人手審査を前提としたまま更新されていません。つまり公式としては、自動検査が8項目のチェックリストのどこまでを代替するのかを、まだ言っていない状態です。

なお、名前が紛らわしいのですが、これは Claude Security（コードベースの脆弱性をスキャンする Enterprise 向け公開ベータ）や Claude Security プラグイン（Claude Code 内でリポジトリを多エージェントで診断するもの）とは別の機能です。今回のものは「Claude に持ち込む Skill / プラグインそれ自体を検査する」ものです。

何が変わったか

• Claude Enterprise の組織が、サードパーティ製 Skill / プラグインの自動セキュリティ検査を有効化できる（ベータ）
• Skill / プラグインのアップロード時と変更時に、有害となりうるコードが検出される
• 有効化は組織側の操作で行う（既定で有効ではない）
• 検出手法・検出項目の内訳・検出時の挙動・対象サーフェスは公式に未記載
• Enterprise 向け Skills ドキュメントは人手審査手順を規定したままで、自動検査との関係は未整理

業務インパクト（一般企業向け）

Skill を社内で本格的に配布しようとして止まっている組織にとって、これは待っていた種類の機能です。

Skill の導入が進まない典型的な理由は、能力の問題ではなく審査の問題です。「便利そうだから入れたい」という現場の要望に対し、情シスやセキュリティ部門は「中身を見ないと許可できない」と答えます。ところが公式が求める審査手順は、スクリプトの全文読解とサンドボックスでの実行検証まで含む重量級のもので、専任者を置かないと回りません。結果として、Skill は「一部の人が個人的に使っているが、組織としては配布していない」という宙ぶらりんの状態に置かれがちでした。自動検査が入ると、明らかに危険なものを機械的に弾いたうえで、人手のレビューを残りに集中させる二段構えが組めます。審査の総量を減らすのではなく、審査の優先順位をつけられるようになる、という理解が正確です。

一方で、現時点でこの機能を「人手審査を廃止する根拠」にするのは早計です。検出項目が公開されていない以上、何が検出されて何がすり抜けるのかを組織側で把握できません。公式ドキュメントが人手審査を求めたままである点も、そう読むべき理由になります。運用ルールを書くなら、「自動検査を通過したこと」を配布の必要条件に加えるのが妥当で、十分条件に格上げするのは検出範囲が公開されてからです。

もう一つ、Skill 特有の難しさとして「更新のたびに再審査が必要」という性質があります。今回の機能がアップロード時だけでなく変更時も対象にしている点は、この観点で重要です。人手審査だけで運用していると、初回は厳格に見ても更新時が形骸化しがちです。機械的に毎回走る仕組みがあることで、この抜けが塞がります。社内の Skill 運用ルールを作るなら、初回審査と更新時審査を分けて定義し、後者は自動検査を軸にする設計が現実的です。

ベータであることの扱いも決めておくべきです。組織側で有効化する形なので、まず検証用のワークスペースで有効にして、既存の Skill を通してみてどう判定されるかを見るのが安全です。いきなり本番ワークスペースで有効にして、業務で使っている Skill が弾かれると混乱します。

副業・個人活用視点

Skill を作って配る側にいる人にとって、これは「作り方の基準が実質的に決まった」という話として読むべきです。

個人が Skill を作り、それを企業に納品したり公開したりする場面が増えています。これまでは何をもって「安全な Skill」と言えるのか曖昧で、受け手側の判断もばらついていました。今回、自動検査が入ったことで、企業側の Skill 受け入れフローに機械的なゲートが立ちます。作る側は、そのゲートを通る前提で書く必要が出てきます。

検出項目は公開されていませんが、公式ドキュメントが挙げる7つのリスク指標は明示されています。実務上は、これを避けて書けば通る可能性が高いと考えるのが妥当です。つまり、スクリプトを同梱するなら用途を明確にする、ネットワークアクセスを不用意に入れない、認証情報は絶対にハードコードせず環境変数を使う、ファイルアクセスは Skill ディレクトリ内に収める、../ を含むパスを書かない。これらは「怒られないため」ではなく、そもそも良い Skill の書き方でもあります。

案件の作り方としても使えます。企業向けに「Skill 導入支援」を提案するなら、Skill そのものを作るだけでなく、受け入れ審査のフローを一緒に設計する方が価値が出ます。自動検査を必要条件に置き、人手レビューをどこに残すか、更新時の扱いをどうするかを整理した運用ルールは、多くの組織がまだ持っていません。技術的な実装より、この手のガバナンス設計の方が単価を取りやすい領域です。

注意点として、この機能は Enterprise 向けかつベータです。個人プランや Team プランで検証できるとは限らないため、提案時に「相手の契約プランで使えるか」を先に確認する必要があります。また検出範囲が非公開である以上、「この検査を通ったから安全です」と言い切る提案は避けるべきです。自分の作った Skill については、何をしていて何をしていないかを説明できる状態にしておく方が、結局のところ信頼につながります。