GitHub公式gh skillの使い方とMicrosoft製apmとの違い——どっちで管理すべき？

こんにちは。もるふぉです。

先日、Microsoft製のapm（Agent Package Manager）の記事を書いたばかりなのですが、その数日後の2026年4月16日にGitHub公式からgh skillコマンドが発表されました。

「スキル管理ツール、また増えたのか」と思った方、正直自分もそう思いました。

ただ実際に触ってみると、apmとは役割がはっきり違うことが分かって、「どっちを使うべきか」という迷いはわりとすぐ解消されました。

この記事では、GitHub公式のgh skill installコマンドの使い方を、先日書いたapmと比較しながら整理します。

結論から言うと、両者は競合というより「役割が違う」ので、使い分けを理解しておくのが一番楽です。

apmについてはこちら↓

Microsoft製AIエージェントのパッケージマネージャーapmの使い方。Claude Codeの設定をチームで再現する

こんにちは。もるふぉです。今日はMicrosoft製のapm（Agent Package Manager）について書きます。CLAUDE.mdをGitにコミットしているのに、チームメンバーごとに設定がバラバラになっていた経験はありませんか。プロンプトを共有したいのに、Slackでmdファイルを送り合っている。MC...

aimanavo.com

3行まとめ

• gh skillはGitHub公式のスキル管理CLI。Claude Codeなどのagent skillsを、サプライチェーン攻撃に強い形で配布・インストールできる
• apm（Microsoft製）はチーム開発向けの依存関係マネージャー。apm.lock.yamlで再現性を確保し、複数AIツールの設定を一括管理できる
• 個人がスキルを試すならgh skill、チーム標準化するならapm。両方併用も十分アリ

gh skillとは何か——GitHub公式のスキル管理CLIツール

gh skillは、GitHub CLIにビルトインされた新しいサブコマンド群です。

Claude CodeやGitHub Copilot、Cursor、Codex、Gemini CLIといった主要なAIエージェントに対して、「スキル」と呼ばれる命令セット（手順書＋スクリプト＋リソース）を配布・インストール・公開できるようにする仕組みです。

2026年4月16日にGitHub Blogで発表されたばかりで、現時点ではパブリックプレビューという位置付けです。

Manage agent skills with GitHub CLI - GitHub Changelog

Agent skills are reshaping how developers work with AI coding agents. Today we’re launching gh skill, a new command in the GitHub CLI that makes it easy to discover, install,…

github.blog

なぜGitHubが「公式」スキル管理を出したのか

ここまでのスキル管理の歴史を振り返ると、流れが見えてきます。

最初はVercel Labsが出したnpx skillsがありました。

手軽でよかったのですが、npx skillsは~/.agents/skills/に実体を置いて、各エージェントのディレクトリからシンボリックリンクを張る設計でした。

複数エージェントでスキルを共有できる利点はありますが、どのバージョンが入っているかを追跡する仕組みは薄く、運用しづらかったんですよね。

次にMicrosoftからapmが出てきて、「apm.yml」という宣言的マニフェストで依存関係を管理できるようになりました。

こちらはチーム開発にフィットする設計です。

そして今回、GitHub本体からgh skillが出てきたわけです。

何が嬉しいかというと、GitHubのリリース機構そのものをスキル配布の信頼基盤として使える点に尽きます。

具体的には、Immutable Releases（後述）やTree SHA検知、Portable Provenanceといった仕組みで、「配布経路で改ざんされていないか」を検証できる設計になっています。

これはnpx skillsやapmにはない強みです。

次のセクションで、実際の操作感を確認していきます。

使うための前提（GitHub CLI v2.90.0以上）

gh skillを使うには、GitHub CLIのv2.90.0以上が必須です。

手元のバージョンを確認するなら以下のコマンドです。

gh --version

古ければアップデートしておきましょう。

# macOSの場合
brew upgrade gh

# その他のOS
# 公式ドキュメントのインストール手順に従う

なお、gh skillはGitHub CLIに同梱されているので、追加インストールは不要です。

v2.90.0以上にした時点で即使えます。

gh skill installの基本コマンドと実際の流れ

gh skill --helpを叩くと、以下のサブコマンドが確認できます。

• gh skill search —— 公開されているスキルを検索
• gh skill preview —— インストール前にSKILL.mdの中身を確認
• gh skill install —— スキルをローカルにインストール
• gh skill update —— 導入済みスキルを最新に更新
• gh skill publish —— 自作スキルを公開

個人が試すときに一番よく使う流れを、順に見ていきます。

gh skill previewでインストール前に中身を覗く

GitHub公式も「インストール前にpreviewしろ」と強く言っています。

理由はシンプルで、スキルの中身はLLMに対する命令文の塊なので、プロンプトインジェクションを仕込まれている可能性があるからです。

実行例はこんな感じです。

gh skill preview owner/repo

これを叩くと、SKILL.mdの中身（frontmatterと本文）がターミナル上に展開されます。

ここで「なんか怪しい命令が入ってないか」を人間の目で見ておく、というステップが挟まります。

地味ですが、これをやらずにインストールすると危ないです。

GitHub自体は「スキルの中身が安全かどうかは検証していない」と公式に言っているので、最終的な安全性はユーザー側の責任になります。

まずはここから始めてみてください。中身を見てから入れる、という習慣を先に作っておくのが一番です。

--agentと--scopeオプションの使い分け

スキルをインストールする基本形は以下です。

gh skill install owner/repo

これだけだと対話プロンプトが出てきて、「どのエージェントに入れる？」「ユーザー全体？プロジェクト単位？」を聞かれます。

CIやスクリプトに組み込みたいときは、--agentと--scopeで明示指定できます。

# Claude Code用に、ユーザー全体にインストール
gh skill install owner/repo --agent claude-code --scope user

# Claude Code用に、プロジェクト単位でインストール
gh skill install owner/repo --agent claude-code --scope project

--scope userだと保存先は~/.claude/skills/、--scope projectだとプロジェクトルート直下の.claude/skills/に保存されます。

ここがnpx skillsと大きく違うポイントで、シンボリックリンクではなく実体ファイルとしてコピーされます。

つまり、「今どのバージョンのスキルが手元にあるか」がlsとcatだけで分かります。

シンボリックリンク経由だと、参照先のファイルが気づかないうちに変わることがあります。実体コピーならそれがない。運用上、これは想像以上に楽です。

version pinningで特定バージョンに固定する

本番で使うスキルは、バージョンを固定しておきたいですよね。

gh skill installは@記法でタグやコミットSHAを指定できます。

# タグで固定
gh skill install owner/repo@v1.2.3

# コミットSHAで固定
gh skill install owner/repo@abc1234

# --pinフラグで現在のバージョンにロック（以降updateしても変わらない）
gh skill install owner/repo --pin

--pinフラグが特に便利で、これを付けておくとgh skill updateを叩いても対象スキルは更新されなくなります。

チーム全員で同じバージョンを使いたいときに使えます。

ただし、本格的なチーム運用で再現性を保証したいなら、この後紹介するapmのapm.lock.yamlのほうが筋が良いです。

gh skillの--pinはあくまで個人ユース寄りの機能と考えておくのが無難です。

gh skill updateはTree SHAで「こっそり改ざん」を防ぐ

更新コマンドはこう使います。

# 全スキルを最新に更新
gh skill update

# 実行前に何が起きるか確認（dry-run）
gh skill update --dry-run

--dry-runを先に叩いてから本番実行、が安全な流れです。

なお、--dry-runはgh skill updateだけでなくgh skill publishでも使えます。

ここで地味に効いてくるのがTree SHAです。

スキルインストール時、フォルダ単位のハッシュ値がSKILL.mdに記録されます。

更新時、リモート側のハッシュと比較することで、「同じタグなのに中身が書き換わっている」という改ざんを検知できます。

これが後述するImmutable Releasesと組み合わさって、「公開されたスキルは誰にも書き換えられない」という保証になります。

このセキュリティ設計の話、次のセクションでもう少し詳しく掘り下げます。

なぜgh skillはサプライチェーン攻撃に強いのか

ここがgh skillの一番面白いところです。

セキュリティ設計が3層に分かれていて、それぞれ防いでいるものが違います。

Immutable Releases（不変リリース）という考え方

GitHubには以前からImmutable Releasesという機能がありました。

これは、リポジトリ設定で有効化することで、公開済みリリースのアセットをタグごとロックする仕組みです。

有効化後は管理者を含め誰もアセットの追加・変更・削除ができなくなります（リリース自体の削除は可能）。

gh skill publishでスキルを公開するとき、このImmutable Releases機能が有効化されているかをチェックし、有効化を推奨します。

つまり、「v1.0.0タグで公開したスキルを、後からこっそり悪意あるコードに差し替える」という攻撃ができなくなるわけです。

攻撃者がリポジトリを乗っ取っても、既存リリースの中身は改変できない。

これは地味にすごいです。

Portable Provenanceで「誰が作ったか」を追跡する

Provenance（来歴）情報は、スキルを配布した後も追跡できるようにするためのメタデータです。

gh skill installでスキルを入れると、SKILL.mdのfrontmatterに以下のようなメタデータが自動で埋め込まれます。

---
name: my-skill
description: ...
github-repo: owner/repo
github-ref: v1.2.3
github-path: skills/my-skill
github-tree-sha: abc1234...
---

この情報があることで、「このスキルはどのリポジトリのどのバージョンから来たのか」を後から辿れます。

Portableという名前の通り、スキルファイルをコピーして別環境に持っていっても、来歴が失われません。

たとえばインシデント対応のとき、「このスキル、どこから入れたんだっけ？」という状況は意外と起きます。

SKILL.mdを開けば、リポジトリ・バージョン・ファイルパスまで一発で確認できる。それだけのことですが、運用上これは地味に助かります。

なお、SKILL.mdのfrontmatter自体の仕様はagentskills.ioで策定中の共通仕様に準拠しており、nameとdescriptionが必須フィールドです。

GitHubはこの共通仕様に乗った上で、自分たち独自のgithub-*メタデータを追加している形です。

apm auditとの違い：検出フェーズのズレが面白い

ここでapmと比較すると、セキュリティ哲学の違いがくっきり見えてきます。

要するに、gh skillは「配布経路を守る」、apmは「中身の悪意を検出する」という役割分担になっています。

少し具体的にイメージしてみます。

スキルが公開される場面を「食品の流通」に例えると、gh skillは「製造元から店頭に届くまでの輸送経路が正しいか」を確認する仕組みです。

一方apmは、「店頭に届いた食品の中身に問題がないか」を検査する仕組みに近い。

どちらが欠けていても片手落ちなんですよね。

gh skillだけだと、作者本人が悪意ある命令を正規リリースに含めたケースを検知できません。

逆にapmだけだと、タグ改ざんやなりすましといった配布経路の攻撃に弱いです。

apm auditが検出できる隠しUnicode文字を使ったプロンプトインジェクションは、人間の目で見ても普通のテキストと区別がつきません。

たとえばU+200B（ゼロ幅スペース）のような不可視文字を命令文に混ぜ込み、AIだけに別の指示を読ませるという手口です。

これは自動スキャンに頼るしかなく、apm auditはそこをカバーしています。

gh skill vs apm——エンジニア視点で使い分けを整理する

さて、本題の比較です。

両者のスペックを実務目線で並べてみます。

gh skill vs apm 機能比較表

表にすると、両者の性格の違いがハッキリします。

個人で使うならgh skillで十分な理由

自分の作業用Macで、気になったスキルをちょっと試したいだけなら、gh skillで十分です。

理由は3つあります。

1. セットアップが不要：GitHub CLIさえ入っていれば即使える
2. 実体ファイルでコピーされる：どのバージョンが入ってるか一目で分かる
3. Previewで中身を見てから入れられる：怪しければ止められる

マニフェストファイルを書く必要もないですし、gh skill installだけでサクッと入るスピード感は、個人ユースだと正義です。

チーム標準化するならapmが強い理由

一方で、チーム開発で「全員同じAIエージェント設定にしたい」となると、話が変わってきます。

apmの強みはここで効いてきます。

# apm.yml の例
name: my-project
version: 1.0.0
dependencies:
  apm:
    - owner/skill-a#v1.0.0
    - owner/skill-b#v2.3.1
  mcp:
    - io.github.owner/mcp-server

このマニフェストをリポジトリに含めておけば、新メンバーは以下3行でセットアップ完了です。

git clone <repo>
cd <repo>
apm install

さらにapm.lock.yamlで厳密にバージョンロックされるので、「Aさんのマシンでは動くのにBさんのマシンでは動かない」という事故がほぼ起きません。

apm auditをCIに組み込んでおけば、プロンプトインジェクションの自動検出もできます。

チーム開発やプロダクション運用で欲しい要素が、一通り揃っている感じです。

両方併用したいときの組み合わせ方

実はこの2つ、併用が普通にアリです。

自分が実際に採用しつつあるパターンを紹介します。

• チームの標準スキル：apm.ymlで管理、apm.lock.yamlでバージョン固定、CIでapm auditを通す
• 個人が試したい新スキル：gh skill install --scope userでユーザー全体に入れる（チームのリポジトリには影響しない）
• スキルを自作して公開するとき：gh skill publishでImmutable Releasesを有効化してGitHubリリースを作る

この使い分けだと、チーム標準の再現性を守りつつ、個人の実験速度も殺さずに済みます。

gh skill publishでリリースしたスキルをapm.ymlで参照する、という形で連携もできます。

2026年4月時点のgh skill・apmを含むスキル管理ツール全体図

最後に、2026年4月時点で主要なスキル管理ツールを一枚で整理しておきます。

気付いたら2026年のスキル管理は、実質「gh skill or apm」の2択に収束しつつあります。

npx skillsはgh skillにそのまま置き換えられるユースケースが多いので、徐々にフェードアウトしていく可能性が高いです。

ただ、どのツールが勝つか負けるかという話というより、個人で気軽に試す→gh skill、チームで本格運用→apmという役割分担が自然に見えてきた、というのが現時点での自分の見方です。

まとめ

今回はgh skill installの使い方を、先日書いたapmと比較しながら整理しました。

ポイントをもう一度まとめると、こうなります。

• gh skill：GitHub公式、個人利用向け、サプライチェーン攻撃（配布経路の改ざん）に強い
• apm：Microsoft OSS、チーム開発向け、中身の悪意検出（プロンプトインジェクション）に強い
• 併用が現実解：チーム標準はapm、個人実験はgh skill、自作公開はgh skill publish

まず試してみるなら、GitHub CLIをv2.90.0以上にアップデートして、gh skill previewから始めるのが一番手っ取り早いです。

インストールなし、マニフェスト不要、コマンド1本で中身が見られます。

個人的には、「GitHubがスキル配布の公式インフラを取りに来た」という点で、今回の発表はかなり大きいと感じています。

npmやpipと同じポジションを、AIエージェント時代のスキル流通で取りに行こうとしている動きに見えますね。

しばらくは両方の動向を追っていきます。