このガイドは、組織全体でAgent Skillsを統制する必要があるエンタープライズの管理者およびアーキテクト向けです。Skillsの審査、評価、展開、および大規模な管理の方法を説明します。作成に関するガイダンスについては、ベストプラクティスを参照してください。アーキテクチャの詳細については、Skillsの概要を参照してください。
エンタープライズでSkillsを展開するには、2つの異なる質問に答える必要があります。
展開を承認する前に、各Skillを以下のリスク指標に照らして評価してください。
| リスク指標 | 確認すべき点 | 懸念レベル |
|---|---|---|
| コード実行 | Skillディレクトリ内のスクリプト(*.py、*.sh、*.js) | 高:スクリプトは環境への完全なアクセス権を持って実行される |
| 指示の操作 | 安全ルールを無視する、ユーザーからアクションを隠す、または条件付きでClaudeの動作を変更する指示 | 高:セキュリティ制御を回避できる |
| MCPサーバーへの参照 | MCPツールを参照する指示(ServerName:tool_name) | 高:Skill自体を超えてアクセスを拡張する |
| ネットワークアクセスパターン | URL、APIエンドポイント、fetch、curl、またはrequestsの呼び出し | 高:データ流出の潜在的な経路 |
| ハードコードされた認証情報 | SkillファイルまたはスクリプトにあるAPIキー、トークン、またはパスワード | 高:Git履歴とコンテキストウィンドウにシークレットが露出する |
| ファイルシステムアクセスの範囲 | Skillディレクトリ外のパス、広範なglobパターン、パストラバーサル(../) | 中:意図しないデータにアクセスする可能性がある |
| ツールの呼び出し | Claudeにbash、ファイル操作、またはその他のツールの使用を指示する指示 | 中:どのような操作が実行されるかを確認する |
サードパーティまたは社内の貢献者からのSkillを展開する前に、以下の手順を完了してください。
http、requests.get、urllib、curl、fetch)を検索します。信頼できないソースからのSkillsを完全な監査なしに展開しないでください。悪意のあるSkillは、Claudeに任意のコードの実行、機密ファイルへのアクセス、または外部へのデータ送信を指示する可能性があります。Skillのインストールは、本番システムへのソフトウェアのインストールと同じ厳格さで扱ってください。
Skillsが誤ってトリガーされたり、他のSkillsと競合したり、不適切な指示を提供したりすると、エージェントのパフォーマンスが低下する可能性があります。本番環境への展開前には必ず評価を要求してください。
Skillを展開する前に、以下の観点について承認ゲートを設けてください。
| 観点 | 測定内容 | 失敗例 |
|---|---|---|
| トリガーの精度 | Skillは適切なクエリで起動し、無関係なクエリでは起動しないか? | ユーザーが単にデータについて議論したいだけの場合でも、スプレッドシートに言及するたびにSkillがトリガーされる |
| 単独での動作 | Skillは単独で正しく動作するか? | Skillがディレクトリに存在しないファイルを参照している |
| 共存性 | このSkillを追加すると他のSkillsが劣化しないか? | 新しいSkillの説明が広すぎて、既存のSkillsからトリガーを奪ってしまう |
| 指示の遵守 | ClaudeはSkillの指示を正確に従うか? | Claudeが検証手順をスキップしたり、誤ったライブラリを使用したりする |
| 出力品質 | Skillは正確で有用な結果を生成するか? | 生成されたレポートにフォーマットエラーやデータの欠落がある |
Skillの作成者に、Skillごとに3〜5個の代表的なクエリを含む評価スイートの提出を要求してください。これには、Skillがトリガーされるべきケース、トリガーされるべきでないケース、および曖昧なエッジケースを含めます。Skillの有効性はモデルによって異なるため、組織で使用するモデル(Haiku、Sonnet、Opus)全体でのテストを要求してください。
評価の構築に関する詳細なガイダンスについては、ベストプラクティスの評価と反復を参照してください。一般的な評価手法については、テストケースの開発を参照してください。
評価結果は、いつ行動すべきかのシグナルとなります。
計画
反復的、エラーが発生しやすい、または専門知識を必要とするワークフローを特定します。これらを組織の役割にマッピングし、どれがSkillsの候補となるかを判断します。
作成とレビュー
Skillの作成者がベストプラクティスに従っていることを確認します。レビューチェックリストを使用したセキュリティレビューを要求します。承認前に評価スイートを要求します。職務の分離を確立します。Skillの作成者が自身のレビュー担当者になるべきではありません。
テスト
単独(Skill単体)および既存のSkillsとの併用(共存テスト)での評価を要求します。本番環境への承認前に、アクティブなSkillセット全体でトリガーの精度、出力品質、およびリグレッションがないことを確認します。
展開
ワークスペース全体でのアクセスのためにSkills APIを通じてアップロードします。アップロードとバージョン管理については、APIでのSkillsの使用を参照してください。目的、所有者、バージョンとともに、社内レジストリにSkillを文書化します。
監視
使用パターンを追跡し、ユーザーからのフィードバックを収集します。ワークフローやモデルの進化に伴うドリフトやリグレッションを検出するために、定期的に評価を再実行します。使用状況の分析は現在Skills APIでは利用できません。どのSkillsがリクエストに含まれているかを追跡するために、アプリケーションレベルのロギングを実装してください。
反復または廃止
新しいバージョンに昇格する前に、完全な評価スイートの合格を要求します。ワークフローが変更されたり、評価スコアが低下したりした場合はSkillsを更新します。評価が一貫して失敗する場合、またはワークフローが廃止された場合はSkillsを廃止します。
一般的なガイドラインとして、信頼性の高い想起精度を維持するために、同時にロードするSkillsの数を制限してください。各Skillのメタデータ(名前と説明)は、システムプロンプト内で注意を奪い合います。アクティブなSkillsが多すぎると、Claudeが適切なSkillを選択できなかったり、関連するSkillsを完全に見逃したりする可能性があります。Skillsを追加する際には評価スイートを使用して想起精度を測定し、パフォーマンスが低下したら追加を停止してください。
APIリクエストは、リクエストごとに最大8個のSkillsをサポートすることに注意してください(APIでのSkillsの使用を参照)。役割が単一のリクエストでサポートされる数以上のSkillsを必要とする場合は、狭い範囲のSkillsをより広範なものに統合するか、タスクの種類に基づいてリクエストを異なるSkillセットにルーティングすることを検討してください。
チームには、広範で多目的なSkillsではなく、狭い範囲のワークフロー固有のSkillsから始めることを推奨してください。組織全体でパターンが明らかになるにつれて、関連するSkillsを役割ベースのバンドルに統合します。
統合のタイミングを決定するために評価を使用してください。統合されたSkillの評価が、置き換える個々のSkillsと同等のパフォーマンスを確認できた場合にのみ、狭い範囲のSkillsをより広範なものに統合してください。
進化の例:
formatting-sales-reports、querying-pipeline-data、updating-crm-recordssales-operations(評価で同等のパフォーマンスが確認された場合)組織全体で一貫した命名規則を使用してください。ベストプラクティスの命名規則セクションにフォーマットのガイダンスがあります。
各Skillについて、以下を含む社内レジストリを維持してください。
各ユーザーのアクティブなSkillセットを焦点の絞られたものに保つために、組織の役割ごとにSkillsをグループ化します。
各役割ベースのバンドルには、その役割の日常的なワークフローに関連するSkillsのみを含めるべきです。
履歴の追跡、プルリクエストによるコードレビュー、およびロールバック機能のために、SkillディレクトリをGitに保存してください。各Skillディレクトリ(SKILL.mdとバンドルされたファイルを含む)は、Gitで追跡されるフォルダに自然にマッピングされます。
Skills APIはワークスペーススコープの配布を提供します。APIを通じてアップロードされたSkillsは、すべてのワークスペースメンバーが利用できます。アップロード、バージョニング、および管理エンドポイントについては、APIでのSkillsの使用を参照してください。
カスタムSkillsはサーフェス間で同期されません。APIにアップロードされたSkillsはclaude.aiやClaude Codeでは利用できず、その逆も同様です。各サーフェスには個別のアップロードと管理が必要です。
Skillのソースファイルを唯一の信頼できる情報源としてGitで維持してください。組織が複数のサーフェスにSkillsを展開する場合は、一貫性を保つために独自の同期プロセスを実装してください。詳細については、サーフェス間の可用性を参照してください。
Was this page helpful?