なぜ SkillPact か

エージェントのスキルはあなたの権限で動きます。SkillPact があれば、スキルを入れる前に「何をしてよいことになっているか」が分かり、ツールが自動で確かめられます。

問題#

• エージェントのスキルは SKILL.md と、多くの場合スクリプトを含むフォルダです。エージェントがそれを使うと、スクリプトはあなたとして動きます。あなたのファイル、通信、認証情報、ときにはお金やアカウントにも触れます。
• SKILL.md はモデル向けに書かれた文章です。インストール前に機械で確かめられるものは何もありません。「このスキルはここにファイルを書き、このホストと通信し、このコマンドを動かし、メッセージを送ることがある」と書く決まった場所がありません。
• OWASP Agentic Skills Top 10（OWASP のインキュベータープロジェクト、owasp.org/www-project-agentic-skills-top-10）は、スキルのリスクの種類として、悪意あるスキル、サプライチェーンの侵害、過剰な権限、安全でないメタデータ、弱い隔離、更新によるずれなどを挙げています。動機として挙げられている事例には、公開のスキルマーケットで 1,184 件の悪意あるスキルが見つかった「ClawHavoc」や、Claude Code の CVE-2025-59536（リポジトリの設定ファイルによってプロジェクトを開いただけでコードが実行される）があります（OWASP の評価チェックリストによる。私たちは独自には確認していません）。それぞれに SkillPact が何をし、何をしないかは OWASP との対応表にあります。

SkillPact が加えるもの#

変更しない SKILL.md の隣に置く skill.contract.json です。作者はすべての副作用を 6 種類（read、write、network、exec、spend、send）と範囲で宣言し、ネットなしで動くテストを付け、ファイルに署名します。ツールはそれをインストール前に確かめます。

利点#

• 入れる前に分かる。 SKILL.md とスクリプトを全部読まなくても、スキルが触れうるものの短い一覧が見られます。
• allow / ask / deny を自動で決める。 あなたや組織のポリシーが capability ごとに判定します。スキルごとに手で判断しなくて済みます。
• 確認の回数が減る。 宣言され、ポリシーが認めた効果はハーネスで事前に許可でき、確認は宣言外や危険なものだけに残せます。
• 改ざんが分かる。 ハッシュがスキルのファイル（.git/ と .DS_Store を除く）を覆うので、変わったファイルがあれば検証に失敗します。分かるのは変更だけで、検証を省くハーネスを止めるものではありません。
• ポリシーは一度書くだけ。 同じ判定を Claude Code・Cursor・Codex・Gemini CLI の設定に変換し（それぞれ表せないものの一覧つき）、HushSpec・Rego にも書き出せます。
• 作者には信頼のバッジ。 L1 / L2 / L3 で、宣言・テスト・署名がどこまで済んでいるかを示せます。
• 組織には監査の材料。 署名と版のある契約は、セキュリティレビューで承認でき、CI で確かめ直せます。

副次的な利点：「何に触れるか」を知るためのトークンが少ない#

契約を読むのは主にツールで、モデルではありません。それでも、効果の一覧だけが必要なときは、契約から作る要約のほうが SKILL.md よりずっと短くなります。サンプルの 4 スキルについて cl100k_base のトークナイザーで測った値です（2026-10-22。どの SKILL.md も他の .md ファイルにリンクしていません）。

要約は none 以外の効果ごとに範囲を 1 行で書いたものです（スクリプト：review/token_measure.py。最初に示した数値のスクリプトがリポジトリになく、要約の形式を再現できなかったため、2026-10-22 に測り直しました）。答えられるのは「このスキルが何に触れうるか」だけで、SKILL.md の代わりにはなりません。契約全体はハッシュやテストを含むので SKILL.md より大きく、プロンプトに入れるためのものではありません。

誰のためになるか#

• 利用者：入れる前にできることが分かり、確認が減る。
• スキルの作者：どのハーネスでも読める 1 つのファイルと、テストと署名が済んだことを示すバッジ。
• ハーネスの開発元：新しい形式を作らずに、インストール画面や権限設定に使える標準の入力。
• 企業と CI：どこでも同じように効くポリシーと、レビューできる署名つきの記録。

既存のツールではだめなのか#

• 実行時ポリシーの規格（APS、Microsoft ACS、HushSpec） は、エージェントが動いている間にツール呼び出しごとに判定します。インストール前にスキルが何を宣言しているかは扱いません。SkillPact は競合せず、それらに書き出します。
• MDA Open Spec には requires（ランタイム、ツール、ネットワーク、パッケージ）があります。spend と send の区別、スキルごとのテスト、ハーネス設定への変換はありません。SkillPact は相互に変換できます。
• AutoVault は frontmatter で capabilities を宣言し、ボルト側でマニフェストに署名します。宣言は静的に照合し、テストは実行しません。SkillPact は相互に変換できます。
• SkillSeal（同名の複数のプロジェクト）は署名と証明が中心で、効果は宣言しません。
• スキャナーは後から推測します。契約があれば、照らし合わせる宣言が手に入ります。

詳細と出典：比較。

テストが確かめること#

宣言が実際の動きと突き合わされるのはテストです。ランナーは skill をサンドボックスで動かし、契約にないことをしたケースを不合格にします。公開レビューの中で、編集者は 0.8 が説明より少ししか確かめていないことを見つけました。下の修正は #1 で議論したうえでマージしました。

最初の exec の確認で、見本のスキルに宣言漏れが 2 つ見つかりました（fc-match と、media.check の ffmpeg）。これらはすべてテストの中の話で、テストで動かした範囲について宣言に漏れがないかを示します。実行時の制御ではありません。レビューの記録：#1。

SkillPact が保証しないこと#

• 契約は作者の申告です。L1 は矛盾がないことを示すだけで、正しいことは示しません。
• テストで確かめられるのは、試した範囲だけです。テストの外では違う振る舞いをするかもしれません。
• L3 ＝ このファイル一式 ＋ 信頼する作者の署名 ＋ 隔離環境でテストが通ったこと。「安全」という意味ではありません。
• SkillPact は実行時には何も強制しません。それはハーネスや実行時ポリシーの役目です。
• スキルディレクトリの外にある依存先は対象外です。
• ブラウザのチェッカーはファイルを見られないので、L1 と署名の状態だけを表示します。

よくある質問#

なぜ 6 種類？ 人が実際に判断する単位（ファイルの読み書き、通信、他のプログラムの実行、お金を使うこと、人に連絡すること）に合わせました。spend と send はコンピューターの外に届き、取り消せないので分けています。これより多いと確認しにくく、少ないと別々に判断すべきものが混ざります。

なぜ署名？ ハッシュはファイルが変わっていないことを示し、署名は誰がそれを保証したかを示します。署名がなければ、ファイルを変えられる人はハッシュも変えられます。

なぜオフラインのテスト？ ネットが必要なテストは、スキルと関係ない理由で成功・失敗することがあり、データが漏れるおそれもあります。隔離したテストなら、ネットなしで宣言どおりに動くことが分かります。

導入の手間は？ 作者は skillpact init で下書きを作って確認し、テストをいくつか足して、ハッシュと署名をします。ハーネスは JSON ファイルを 1 つ読んでチェッカーかライブラリを呼ぶだけです。SKILL.md は何も変わりません。

もう安定版？ まだです。いまはドラフト 0.8 です（位置づけ）。