Capability CI/CDとは：Agent Skillを検証して配布する設計
この記事で学べること
- Agent Skillを、変更履歴や配布先まで管理する資産として扱う理由
- 静的検査、重複確認、実行評価の役割の違い
- 暗号署名と社内のSkill一覧で確認できることと、その限界
- 本番環境への配布判断に必要な記録と承認情報
Capability CI/CDの役割と配布前の検証
Agent Skill（AIが特定の作業を行うための指示や手順、必要なスクリプトなどをまとめたもの。以下、Skill）は、作成して終わりではありません。業務で使うには、内容に問題がないか、実際に役立つかを確かめ、どの版を誰が利用できるかまで管理する必要があります。
Capability CI/CDは、そのための仕組みです。CI（継続的インテグレーション）はSkillの変更を継続して検査し、CD（継続的デリバリー）は承認済みの版を利用環境へ配ります。この二つを組み合わせ、変更の確認から配布までSkillの品質と安全性を管理します。
2026年8月19日、NVIDIAはSkillEvaluator（Skillの品質や効果を評価するツール）を公開しました。Skillの構造、安全性、既存Skillとの重複、実際の効果を分けて確認できる点が特徴です。[1][2]
複数のAI実行環境（AIがSkillを読み込み、作業を行う場所）へSkillを配る組織では、検査結果に加え、必要な権限や承認条件もそろえる必要があります。この記事では、**「何を根拠にSkillを評価し、誰が本番環境への配布を承認するか」**を考えます。公開情報で確認できる内容と、その限界を整理し、自社で判断するための材料を示します。
構造・安全性、重複、実際の効果の違い
Skillの評価では、形式が正しいこと、安全に使えること、業務に役立つことを分けて考えます。SkillEvaluatorは、これらを三つのTier（評価の段階）で確認します。[1][2]
| 評価の段階 | 確認する内容 | 判断したいこと |
|---|---|---|
| Tier 1：構造と安全性 | 形式、秘密情報、個人情報、ライセンス（利用・配布の条件）、スクリプト（処理を実行するコード）、安全性 | Skillの内容や構成に問題がないか |
| Tier 2：既存Skillとの重複 | 名前や文章が違っていても、役割や意味が重なるSkillの有無 | 既存のSkillとは別に用意する必要があるか |
| Tier 3：実行による比較 | 隔離環境（本番のデータやシステムへの影響を抑えて試せる環境）で、同じ課題をSkillあり／なしで実行した結果 | Skillを使うことで、実際に結果がよくなるか |
形式が正しくても、業務に役立つとは限りません。安全性の検査に合格していても、回答の正確さが下がるSkillは配布できません。逆に、回答が正確になっても、秘密情報を読み出す処理や必要以上の権限が含まれていれば、本番利用には向きません。
NVIDIAは、30以上の製品群で300を超えるVerified Skills（NVIDIAが検証したSkill）を評価しました。その結果、Correctness（正確さ）やEffectiveness（目的を達成し、期待された手順に従えたか）の平均点が上がったと報告しています。[1]
ただし、公開結果の85%は各課題を1回、15%は2回試したもので、信頼区間（測定結果の統計的な不確かさを示す範囲）も示されていません。[1]
そのため、報告された平均値だけで、自社のSkillも必ず改善すると判断することはできません。自社で使う入力、期待する結果、付与する権限をそろえ、Skillあり／なしで比較する必要があります。
暗号署名と社内一覧による出所・版・承認状態の管理
評価を終えたSkillには、作成者、版、用途、評価条件、利用を承認した環境をひも付けます。これにより、利用者は「誰が作り、どの条件で確認されたSkillなのか」を把握できます。
暗号署名（署名者と、署名後に内容が変わっていないことを確認する仕組み）は、配布するファイルの確認に使えます。NVIDIAの公開Skillでは、署名検証に成功すると、NVIDIAによる署名後に内容が変更されていないことを確認できます。[3] ただし、署名があることと、Skillの業務判断が正しいことは別です。 すべての入力に対する安全性も、署名だけでは保証できません。
Catalog（利用可能なSkillをまとめた社内一覧）は、Skillを探す場所であると同時に、承認状態を確認する台帳です。最低限、次の情報を記録します。
- Owner（保守責任者）
- 版と対象業務
- 利用を許可するAI実行環境
- 必要な権限
- 最終評価日と有効期限
- 廃止の有無や状態
目指すのは、利用者がGitHubのURLだけを見て導入するのではなく、社内一覧から承認済みの版を選べる状態です。
既存のSkillOpsの記事では、Skillの作成、公開、評価、保守を継続する運用全体を扱いました。Capability CI/CDは、その中でも、変更ごとの品質ゲート（次の段階へ進めるかを判断する検査・承認の関門）と、本番配布を許可する根拠に焦点を当てます。
配布判断に必要な記録と承認情報
検査結果が複数の画面に分かれていると、どのSkillのどの版を承認してよいのか、判断しにくくなります。配布時には、Skillと、その評価・承認の根拠を一つにまとめます。
この記事では、この記録一式をCapability Release Packet（Skillの配布判断に必要な情報をまとめた記録）と呼びます。製品名ではなく、承認に必要な情報を整理するためのテンプレートです。
| 項目 | 記録する内容 | 配布を止める条件 |
|---|---|---|
| 目的と保守責任者 | 対象業務、利用者、保守責任者 | 保守責任者または利用目的が不明 |
| 変更内容 | 版、変更前後の差分、依存先（動作に必要なツールやサービスなど） | 未確認の実行ファイルや接続先がある |
| 静的検査（Skillを実行せずに内容を調べる検査） | 形式、秘密情報、個人情報、ライセンス、安全性 | Critical（重大）と判定された指摘が未解決 |
| 重複確認 | 既存Skillとの役割の違い | 既存Skillへ統合すべき重複がある |
| 実行評価 | Skillあり／なしの正確さ、手順の遵守、費用、処理時間 | 重要な指標が基準を下回る |
| 権限 | 読み書きするデータ、外部接続、承認が必要な操作 | 目的に必要な範囲を超える権限を要求する |
| 承認と期限 | 承認者、対象環境、再評価日、有効期限 | 承認または有効期限がない |
評価指標を増やしても、配布判断が正確になるとは限りません。対象業務に合った指標を選びます。たとえば週次報告を作るSkillなら、情報源を適切に使っているか、重要事項の抜けがないか、数値が一致しているか、指定の書式を守っているか、処理時間が適切かを中心に確認します。
利用者の行動や外部システムを変更するSkillでは、結果の品質だけでは不十分です。権限が適切であること、操作を取り消す方法があること、必要な場面で人が承認することも、合格条件に含めます。
配布後の更新・停止・切り戻し
Skillの挙動は、Skill本体を変更しなくても変わることがあります。接続先のAPI（外部のシステムやサービスの機能を呼び出すための接続点）、参照文書、AIモデル、社内ルールが変わるためです。
初回の配布時だけ評価しても、その後の品質低下は見つけられません。版を変更したときは配布判断用の記録も更新し、変更の影響を受ける評価をやり直します。
運用中の扱いを明確にするため、Skillの状態を次のように分けます。
| 状態 | 意味と利用上の扱い |
|---|---|
| Draft（作成中） | 利用環境へは配布しない |
| Evaluating（評価中） | 隔離環境で検査と比較を行う |
| Approved（承認済み） | 指定した環境と権限で利用できる |
| Suspended（一時停止） | 問題を調査している間、新しい実行を止める |
| Deprecated（廃止予定・移行対象） | 後継のSkillへ移行し、新規利用を認めない |
| Revoked（承認取り消し） | 重大な問題により利用を取り消す |
切り戻し（問題が起きたときに以前の版へ戻すこと）には、前のSkillファイルだけでなく、その版が前提としていたツール、権限、評価結果も必要です。署名済みのファイルを保存していても、依存するAPIが変わっていれば、以前と同じ動作に戻せるとは限りません。
リスクに応じた審査の深さと検査の限界
すべてのSkillに、同じ重さの審査を課す必要はありません。外部接続やデータ変更をせず、文章の整形だけを行うSkillと、顧客情報を読み取って外部APIへ送信するSkillでは、問題が起きたときの影響が異なります。確認の深さも、それに合わせて変えます。
導入時は、一つの代表的なSkillを対象に、静的検査、Skillあり／なしの比較、保守責任者による承認、利用する版の固定をそろえることから始められます。
高い権限、外部へのデータ送信、取り消しにくい操作、規制対象のデータのいずれかを扱う場合は、審査を手厚くします。隔離環境での確認、セキュリティ担当者による確認、試行回数の追加、短い有効期限の設定を組み合わせます。
ただし、Scanner（問題のある記述や構成を探す検査ツール）の結果だけで、絶対的な安全を証明することはできません。静的検査では、実行時の入力、外部サービスの応答、権限の組み合わせをすべて再現できないためです。検査結果と実行評価を合わせ、最終的な判断を誰が担うかも明確にします。
まとめ：Skillの配布を支える評価の根拠と運用責任
Capability CI/CDは、Skillの構造、安全性、重複、実際の効果を確認し、版と承認条件を付けて配布する設計です。SkillEvaluatorは、静的検査、重複確認、Skillあり／なしの実行比較を、一連の評価の流れとして具体化しました。
配布判断で大切なのは、評価点の高さだけではありません。誰が、どの版を、何を根拠に、どの環境での利用に承認したのかを追えることです。Capability Release Packetは、その情報を一つにまとめるために使えます。
最初の実装では、一つのSkillについてこの記録をそろえる方法があります。停止条件と再評価日まで含めれば、Skillを追加するときだけでなく、問題が起きて利用を取り消すときにも、同じ記録をもとに判断できます。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- NVIDIA Technical Blog, Evaluating AI Agent Skill Performance with NVIDIA SkillEvaluator, 2026年8月19日
- NVIDIA, SkillEvaluator
- NVIDIA, NVIDIA Agent Skills