Agent Skill Creator解説｜スキルを自動生成し17プラットフォームへ配るOSSの品質ゲートを実測

Agent Skill Creatorは、やりたい作業を普通の言葉で説明するだけでAgent Skillを一式生成し、17のプラットフォームへ配るMITライセンスのOSSだ（FrancyJGLisboa/agent-skill-creator）。2026年7月30日時点で2,035スター・238フォーク、主要言語はPython。

Agent Skills（SKILL.mdを中心としたフォルダ）でエージェントに自社の手順を覚えさせる方法はすっかり定着したが、実際に書こうとすると、仕様への適合・段階的な情報読み込みの設計・起動キーワードの調整と、地味な作業が積み上がる。このツールはその工程を入口ごと自動化しようとする。

エージェント基盤全体の中でどこに位置するツールなのかは、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で整理している。本記事はそのうち「エージェントに手順を持たせる側」を扱う。そして本記事の主眼は使い方の紹介ではなく、このツールが生成物に課すと宣言している4つの品質ゲートを、同梱サンプルに対して実際に走らせ、終了コードを測ることにある。

Agent Skill Creatorとは｜自然言語の説明からエージェントスキルを生成するOSS

Agent Skill Creatorは、それ自体がひとつのAgent Skillとして配布される。インストールすると各ツールのスキル置き場に入り、/agent-skill-creator に続けてやりたいことを書くと、対話の中でスキルを組み立てる。

READMEが挙げる入力は幅広い。平文の説明、社内Wikiのリンク、既存のPythonスクリプト、APIドキュメント、PDF、データベーススキーマ、会議の書き起こし。これらを混ぜて1つのメッセージに渡せるとされている。

処理は5フェーズに分かれる。特徴的なのは、READMEが「人は自分がやっていることを説明するが、必要なものは説明しない」と述べ、表面的な記述をそのまま実装せず、内部仕様をいったん生成してからコードを書く、と設計意図を明示している点だ。

図の右下、生成されたスキル自身が evolve.py を持ち、失敗の証拠を EVOLUTION.md に書き戻す部分がこのツールの設計上の主張だ。作って終わりではなく、作られたものが自分で自分の劣化を検出する形を取っている。

インストールとSKILL.md 作り方の実際｜ワンライナーから生成物の中身まで

導入はブートストラップスクリプト1本で完了する。clone先は ~/.agents/skills/agent-skill-creator で、そこから検出できたプラットフォームへリンクが張られる。

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/FrancyJGLisboa/agent-skill-creator/main/scripts/bootstrap.sh | sh

# 更新は clone 先で git pull するだけ
cd ~/.agents/skills/agent-skill-creator && git pull

Windowsは irm ... | iex のPowerShellワンライナーが用意されている。実行前に中身を確認したい場合は、curl の出力をいったんファイルに落として読んでから実行すればよい。

生成されるスキルの構成は、単なるSKILL.md 1枚ではない。READMEが示すディレクトリは、定義本体（SKILL.md）、他ツールが読む併走ファイル（AGENTS.md）、プラグインマニフェスト（.claude-plugin/）、実際に動くPythonコード（scripts/）、詳細ドキュメント（references/）、そしてeval仕様と正解データ（evals/）、クロスプラットフォームのインストーラ（install.sh）という構成だ。

つまりこのツールにおけるSKILL.md 作り方の答えは「1ファイルを上手に書く」ではなく「検査可能なパッケージを組み立てる」になっている。既に完成したスキルを取り込む方向のアプローチとしてはmattpocock/skills完全ガイド｜Claude Code用スキル集で開発プロセスを自動化のような公開スキル集があるが、本ツールが立っているのはその逆側、自社の手順を材料にして自分で作る側だ。

リポジトリには3本の実行可能なサンプルが同梱されており、クローンすればすぐ動かせる。以降の実測はすべてこのサンプルに対して行った。

git clone https://github.com/FrancyJGLisboa/agent-skill-creator
cd agent-skill-creator/references/examples/weekly-crm-report
python3 scripts/run_pipeline.py --input evals/golden/case-1/input.csv --output /tmp/summary.json

チームへ配るところまでが射程に入っている

生成後、ツールはスキルをチームへ共有するか尋ねる。GitHubかGitLabかを判別してリポジトリを作成・push し、同僚が貼り付けるだけの1行を返す仕組みで、配布の実体は「~/.agents/skills/ への git clone 1回」に集約される。前述のとおりこのディレクトリは複数ツールが共有するため、1回のcloneで複数の環境から呼べる状態になる。

スキルが増えてきた段階では、共有リポジトリをカタログとして使う registry コマンド群が用意されている。サーバもデータベースも使わず、git リポジトリ1つで公開・検索・インストールを回す設計だ。

python3 scripts/skill_registry.py init --name "Acme Corp Skills"   # 最初の1回だけ
python3 scripts/skill_registry.py publish ./sales-report-skill/ --tags sales,reports
python3 scripts/skill_registry.py search "sales"                    # 探す
python3 scripts/skill_registry.py install sales-report-skill        # 環境を判別して入れる
python3 scripts/skill_registry.py stale                             # 棚卸し（後述）

生成したスキルが起動しないときに見る場所

生成物のトラブルで最も多いのは「スキルが呼ばれない」ことだ。この点はスキルの仕組みそのものに由来する。エージェントがどのスキルを使うか決める材料は frontmatter の description であり、そこに利用者の問いかけと重なる語が入っていなければ起動しない。READMEのトラブルシューティングも最初にこれを挙げている。

validate.py が機械的に確認している境界も知っておくと切り分けが速い。ソースの定数を読むと、名前は64文字以内で小文字・数字・ハイフンのみ（先頭と末尾のハイフン、連続ハイフンはエラー）、description は1,024文字以内、本文が500行を超えると警告になる。本文が長すぎる場合の対処は references/ へ切り出して参照させることで、これはスキルの段階的読み込みの設計そのものだ。

自動検出が効かない環境では --platform cursor のように明示指定でき、生成されたスキル側では ./install.sh --all（Windowsは .\install.ps1 -All）で検出できた全ツールへ一括導入できる。

対応17プラットフォームの実体｜platforms.pyが定義する配置先

「17プラットフォーム対応」は本ツールの看板だが、この数字が何を数えたものかはソースを読むと分かる。単一の真実源として scripts/platforms.py に PLATFORMS タプルが定義されており、要素数を数えると確かに17だった。

ただし内訳には注意点が2つある。ひとつは universal というエントリで、これは特定の製品ではなく汎用の ~/.agents/skills を指す枠だ。もうひとつは、その universal と codex が同じディレクトリを共有している点で、実際に作られるディレクトリの数は17より少ない。READMEも「~/.agents/skills への1回のclone で Codex CLI・Gemini CLI・Kiro・Antigravity が同時に使えるようになる」と説明しており、これは矛盾ではなく共有ディレクトリを前提とした設計である。

もうひとつ、クロスプラットフォーム スキルとして配る際の変換も押さえておきたい。すべてのツールがSKILL.mdをそのまま読むわけではなく、Cursorには .mdc、Windsurfには .md ルール、Junieには guidelines.md という形式アダプタが自動生成される。「同じスキルが17か所で同じ結果を出す」というより、「1つの定義を各ツールの置き場所と形式へ機械的に配る」と理解するのが実態に近い。

Agent Skill Creatorの4つの品質ゲートを実際に走らせて測る

ここからが本題だ。READMEは生成物に対して4種類のゲートを掛けると書いている。実際に同梱サンプルへ走らせ、終了コードを確認した（2026-07-30・Python 3.14.4）。

# 各ゲートは独立して実行できる。判定は終了コードで取る
python3 scripts/validate.py ./references/examples/weekly-crm-report/;       echo "exit=$?"
python3 scripts/security_scan.py ./references/examples/weekly-crm-report/;  echo "exit=$?"
python3 scripts/check_pipeline.py ./references/examples/weekly-crm-report/; echo "exit=$?"

# eval はスキル自身のディレクトリから実行する
cd references/examples/weekly-crm-report && python3 scripts/run_evals.py --rollout; echo "exit=$?"

結果は、weekly-crm-report / pr-blocker-summarizer / stock-analyzer の3本すべてで4ゲートとも終了コード0だった。宣言どおりゲートは動作し、サンプルはそれを通過する。

測って初めて分かることが3点あった。

1. VALIDでも警告は残る。 weekly-crm-report の検証結果は Status: VALID かつ終了コード0だが、警告は4件出ている。内容は「名前を -skill で終わらせると発見されやすい」「AGENTS.md が無い」「activation フィールドが無い」「provenance メタデータが無い」。つまりリポジトリ自身のショーケースが、自身の検証ツールの推奨をすべては満たしていない。警告は非ブロックなので配信は止まらないが、「ゲートを通った＝推奨をすべて満たした」ではない点は押さえておきたい。

2. evalは全件を走らせない。 --rollout の出力は rollout: 6 passed, 0 failed, 0 errored, 0 regressed で、末尾に held out (split=test, use --include-holdout): case-2 と出る。3つある正解ケースのうち case-2 は意図的に実行されない。最適化ループに一度も見せないホールドアウトを確保する設計で、スキルを自動で直す仕組みを持つツールとしては筋が通っている。

3. 表示された行数と件数は一致しない。 出力には8行のチェックが並ぶのに、集計は「6 passed」と出る。run_evals_template.py を読むと、集計対象は各ケースの判定基準（valid-json / has-grand-total / dedup-happened）のみで、2ケース×3基準＝6。残る2行の <baseline> は基準ではなく回帰ゲートで、こちらは 0 regressed として別に報告される。数字を読み違えないためにはこの内訳を知っておく必要がある。

なお、冒頭のデモGIFは同じコマンドを流しているが、そこでは3ケース全部が走り 9 passed と出ている。ホールドアウトが導入される前の記録で、現在のコードとは挙動が異なる。手元で走らせた結果と配布物の記録が食い違ったときは、コードのほうが新しいと考えるのが妥当だ。

陳腐化の検出は、生成されたスキル自身に同梱される

スキルは静かに腐る。APIの応答が変わり、参照先が移動し、半年前は正しかった手順が今日は誤った結果を出す。このツールが持つ3層の検出は、生成されたスキル側にも scripts/evolve.py として同梱されるため、作成元のリポジトリを持っていなくてもスキル単体で回せる。

# スキル自身のルートから。陳腐化＋依存＋スキーマ差分＋eval を一度に
python3 scripts/evolve.py
# 失敗した項目はそのスキルの EVOLUTION.md に証拠として追記される

# 個別に確認する場合（終了コードで判定）
python3 scripts/staleness_check.py ./my-skill/                # 0=新鮮 / 1=レビュー期限切れ
python3 scripts/staleness_check.py ./my-skill/ --check-deps   # 2=依存先に到達できない
python3 scripts/staleness_check.py ./my-skill/ --check-drift  # 宣言した応答キーが消えていないか

3層はそれぞれ、レビュー日の期限切れ（frontmatter の last_reviewed と review_interval_days を突き合わせ、宣言が無ければ SKILL.md の最終コミット日で代用）、依存先URLへのHTTP到達性、そしてAPI応答のトップレベルキーが宣言と一致するかを見る。いずれもfrontmatterの任意フィールドで制御されるオプトインで、既存スキルは何もしなければ従来どおり動く。

「スキルを大量に作れる」ことと「作ったスキルが半年後も正しい」ことは別問題で、後者に手を打とうとしている点は、生成系ツールとしては珍しい設計判断だ。

主観的な基準の採点と、モデル比較の扱い

evalの判定基準には「JSONとして妥当か」のように機械で判定できるものと、「要約が読み手に伝わるか」のように判定しづらいものがある。後者は --judge でLLMに採点させるが、この仕組みには2つ確認しておきたい性質がある。

ひとつは採点者の解決順序だ。ソースを読むと、EVAL_JUDGE_CMD に指定した任意のランタイム → 手元のヘッドレスランタイム（APIキー不要） → ANTHROPIC_API_KEY による素のAPI呼び出し、の順に試される。既に契約しているCLIを採点者として使えるため、eval を回すためだけに新しくAPIキーを用意する必要は基本的にない。

もうひとつがキャナリア（canary）の扱いで、ここは設計として気が利いている。あらかじめ「明らかに不合格であるべき出力」を用意し、採点者にそれを採点させる。すべての判定基準がその出力を不合格と判断しなければ、採点結果そのものを無効とする。ソースのコメントにも「キャナリアを合格させた採点者は実行全体を無効にする」と明記されている。甘い採点者や壊れた採点者が全部を合格にしてしまう事故を、構造で防いでいる。

モデル比較（--rollout --model A --model B）も同様に慎重だ。同じテスト一式をモデルごとに1回ずつ走らせ、合格率とコストを並べる機能だが、コストはパイプラインが書き出した実測の使用量ファイルからのみ取得され、推定はしない。数字が無い場合は空欄になる。「このタスクはどのモデルで、いくらで回すべきか」を、根拠のある数字だけで比べる方針が取られている。

加えて v6 系では --mcp-audit が入っており、MCPサーバーの仕様から「作れるスキル」の候補と「作れないスキル」を仕分ける。後者には欠けている機能を必ず明記させる決まりで、その出力自体も scripts/mcp_audit_validate.py で機械的に検査される。

security_scanのインジェクション検出は何を捕まえ、何を捕まえないか

4つのゲートのうち、生成AIの文脈で最も踏み込んでいるのが security_scan.py だ。READMEはハードコードされた鍵や危険なコードパターンに加え、指示文そのものに埋め込まれたプロンプトインジェクション（命令上書き・秘匿/持ち出し指示・不可視Unicode・エンコードされた塊）と、スクリプトが未申告のネットワーク接続先を持つケースを検査対象に挙げている。

これが本当に発火するかを確かめるため、意図的に問題のある SKILL.md を作って走らせた。

# 命令上書き・秘匿指示・APIキーを含むSKILL.mdを検査
python3 scripts/security_scan.py /tmp/badskill/; echo "exit=$?"
# → Status: ISSUES FOUND (4) / High: 3  Medium: 1 / exit=1

結果は終了コード1でブロック。検出されたのは「Instruction override（Ignore all previous instructions）」「Concealment directive（Do not tell the user）」「Anthropic API Key のハードコード」、加えて汎用シークレットとしてMedium 1件。宣言どおり、指示文の中に書かれた命令上書きと秘匿指示は止まる。

一方で、同じファイルに入れていた「認証情報を外部URLへ送れ」という一文は検出されなかった。切り分けのため、その持ち出し指示だけを含むSKILL.mdを別に作って走らせると、結果は Status: CLEAN・終了コード0。ソースを読むと理由がはっきりする。持ち出し検出の正規表現は、動詞（send / post / upload / transmit / forward / exfiltrate）と秘密情報を表す名詞（credentials / api keys / tokens / secrets 等）が近接していることを条件にしており、その間隔が [^.\n]{0,60} と定義されている。この文字クラスはドットを跨げない。

実際にパターンへ文字列を通して確かめると、差は次のようになった。

意味はどれも同じで、認証情報のありかをドット入りのファイルパスで書いたかどうかだけが違う。皮肉なことに、認証情報を指す最も自然な書き方であるドットファイルのパス（~/.aws/credentials、~/.ssh/id_rsa）が、ちょうど一致を妨げる形になっている。

公平を期すため、READMEが挙げる他の検出項目も同じ方法で1つずつ確かめた。結果は次のとおりで、一致しなかったのは持ち出し指示の1項目だけだった。

不可視Unicodeの検出は特に効く。人間のレビューでは見えない文字で指示を隠す手口は、まさに機械のほうが得意な領域だ。未申告の接続先の指摘も具体的で、「telemetry.example.net に接続しているが SKILL.md に依存として宣言が無い。metadata.dependencies に書くか呼び出しを消せ」と対処まで示される。

つまり持ち出し指示の件は、検査全体が緩いという話ではなく、6項目中5項目は宣言どおり機能するなかでの1項目の取りこぼしだ。そしてこれは実装の欠陥というより、語句パターンによる検査が本質的に持つ性質でもある。同じ意味を表す表現は無数にあり、正規表現はそのうち列挙したものしか捕まえられない。重要なのは、このゲートを「機械が読める危険信号を機械的に落とす層」として扱い、意味を理解した安全性の保証と取り違えないことだ。スキルは実行されるコードと指示を同時に運ぶ以上、配布前に人が読む工程は依然として必要になる。この観点でのスキル資産の一元管理は、Agent Skill Harbor徹底解説｜AIエージェントのスキル資産をGitで一元管理するOSS基盤が扱っている領域と重なる。

なお、公開時のブロック条件は明確に定義されている。高深刻度の指摘は公開（publish）時のハードブロックで、--force で上書きできるのは重複バージョンのエントリだけであり、セキュリティ指摘は上書きできない。一方でエクスポート時は既定では報告のみで止まらず、止めたい場合は --strict を渡す。この非対称性はCI設定時に効いてくる。

類似ツールとの比較｜Anthropic公式skill-creator・Microsoft wazaとの違い

Agent Skills 作成まわりのツールは増えており、役割が重なって見える。実際には守備範囲が異なる。数値は2026年7月30日時点のGitHub API実測値。

比較で注意したいのは、anthropics/skills の165,041スターはリポジトリ全体に対するもので、その中の skill-creator 単体の人気を示す数字ではないという点だ。同リポジトリには docx / pdf / mcp-builder など17のスキルが含まれる。

wazaは「作る」ではなく「測る」に寄っており、Agent Skill Creatorが生成物へeval仕様を同梱するのと目的は近い。両者の詳細はMicrosoft Waza｜Agent Skillsの品質を測るGo製評価フレームワークを解説で扱っている。生成を自動化したいのか、既にあるスキルの良し悪しを数値化したいのかで選ぶ対象が変わる。

導入前に確認したい制約

実測と一次資料から、採用判断に関わる点を挙げる。

開発体制は実質1人。 コミット総数121に対し、著者名は3通りの表記で記録されているがいずれも同一人物で、他の貢献者はGitHub APIのcontributorsに現れない。2,035スター・238フォークという注目度に対し、issue 6件・PR 21件（いずれも累計）と流入は少ない。バス係数1のプロジェクトである点は、業務ワークフローの中核に据える前に見ておきたい。

GitHub Releasesが無い。 配布はタグのみで、確認できるのは v2.1.0（2025-10-23）と v6.0.0（2026-06-01）の2つ。READMEのバッジはバージョン6.0.0を示す。ブートストラップは main を clone し、更新も git pull なので、実質的には常に最新のmainを追う運用になる。特定バージョンで固定したい場合は自分でタグをチェックアウトする必要がある。

インストールはワンライナー実行が前提。 curl | sh および irm | iex の形式で、リモートのスクリプトをそのまま実行する。組織のポリシー次第では、スクリプトを取得して内容を確認してから実行する手順に置き換えることになる。

eval rolloutは実コードを実行する。 READMEも明記しているとおり --rollout はオプトインで、スキルの実際のコードを走らせる。素性の分からないスキルに対して無条件に回すものではなく、他人が作ったスキルを検証する場合は、隔離した環境で走らせるか、先に security_scan.py と中身の目視を済ませてから回す順序が安全だ。

ディレクトリ名が name と一致していないと検証が落ちる。 検証を試す際に踏んだ挙動を記しておく。任意の名前のディレクトリにcloneして validate.py を掛けると、Status: INVALID・終了コード1で止まる。原因は「ディレクトリ名が frontmatter の name フィールドと一致しない」というエラーで、正しい名前のディレクトリに置き直すと同じリポジトリが Status: VALID・終了コード0になった。スキルは「名前＝フォルダ名」が同一であることを前提にした構造なので仕様どおりの挙動だが、検証だけ試したいときに引っかかりやすい。

なお、このツール自身に security_scan.py を掛けると高深刻度4件が出るが、内容を見ると scripts/security_scan.py の141〜149行目、すなわち走査ツールが自分の検出パターン定義（eval() / exec() の文字列）を検出しているものだった。自己言及による誤検出で、実際の危険を示すものではない。走査対象に検出器自身を含めるとこうなる、という例として理解しておけばよい。

参考実装の一部は未実装。 references/agentdb-integration.md は将来の学習レイヤー設計として、リポジトリ自身が未実装（not implemented）と記載している。ドキュメントに書かれている＝動く、ではない箇所がある。

まとめ

Agent Skill Creatorは、エージェントスキル 生成の入口を「普通の言葉で説明する」ところまで下げたうえで、出口に検査を置いたツールだ。同梱サンプルに4つのゲートを実際に走らせた結果、宣言どおりゲートは機能し、3サンプルとも終了コード0で通過した。

ただし測ってみると、境界も同時に見えてくる。VALID表示でも推奨を満たさない警告は残り、evalは1ケースを意図的に走らせず、表示行数と集計値は別の意味を持つ。セキュリティ走査は7項目のうち6項目を宣言どおり止める一方、持ち出し指示の検出だけは語句パターンに依存し、認証情報を指す最も自然な書き方であるドット入りパスでは一致しなかった。走査ツールを自分自身に向けると誤検出が出ることも含め、これらは「機械の検査に何を期待してよいか」の実像を示している。

このツールの価値は「安全なスキルを保証する」ことではなく、人が読む前に機械で落とせるものを落とし、生成物に測定可能な指標を最初から同梱させることにある。そう捉えるなら、手書きのSKILL.md運用に対して足りていなかった層を埋める選択肢になる。スキルを複数ツールへ配る予定があり、かつ生成物をレビューする体制がある組織であれば、試す価値のある設計だ。

参照ソース

・FrancyJGLisboa/agent-skill-creator — GitHubリポジトリ（README・scripts/platforms.py・scripts/security_scan.py・scripts/run_evals_template.py・references/examples/ を実読、および同リポジトリに対するGitHub API実測値）
・agent-skill-creator assets/DEMO.md — デモ収録の方針
・anthropics/agent-skills-spec — Agent Skills Open Standard
・anthropics/skills — 公式スキル集（skill-creator を含む）
・microsoft/waza — Agent Skills評価フレームワーク