こんにちは。もるふぉです。
~/.claude/ フォルダ、いま何個ファイルが入っていますか?
hooks、skills、MCP、subagents、slash commands、claude-code-setup——便利な仕組みが次々に増えるのは嬉しいんですが、気づくと「何を入れたか覚えてない」「どこから持ってきたか分からない」「チームメンバーと環境がバラバラ」みたいな状態になっていませんか?
私もそうでした。地味にストレスたまるんですよ、これが。
そんな中、Anthropic公式の claude-code-setup というプラグインを触ってみて、「あ、これは今までのツールと役割が違うやつだ」と気づいたんです。
この記事では、claude-code-setupと、よく一緒に語られるMicrosoftの APM、GitHubの gh skill——この3者の役割分担を整理します。「どれが優れているか」ではなく「どれをいつ使うか」が見えるように書きました。
3行まとめ
先に結論からいきます。
- claude-code-setup: コードベースをスキャンして「何を入れるべきか」を推奨してくれる。Claude Code専用、対話形式、読み取り専用
- APM:
apm.ymlで依存を宣言してチームに配布する。マルチエージェント対応、ガバナンス機能あり - gh skill: GitHub CLIからスキルを安全にインストールできる。tag/release pinとTree SHAで配布経路の完全性を担保
つまり、claude-code-setupは「推奨エンジン」、APMとgh skillは「配布基盤」です。
役割レイヤーが違うので、競合ではなく組み合わせて使うのが正解。ここが分かると、3者への見方が一気に変わります。では、それぞれの正体を実際の操作感とともに見ていきましょう。
claude-code-setupとは何か——Anthropicが解くべき問題を変えた
claude-code-setupは、Anthropicが公式マーケットプレイス claude-plugins-official で配布している公式プラグインです。
起動コマンドはこれだけ。
/plugin install claude-code-setup@claude-plugins-officialインストール後、Claude Codeのセッション内で「このプロジェクトに合うautomationを推薦して」みたいに話しかけると、プロジェクトの中身を読んで推奨してくれます。
最初に触ったとき「ふーん、推薦してくれるんだ」くらいの印象だったんですが、何回か使っているうちに「これ、ほかのツールと根本的に解いている問題が違うな」と気づきました。
「何を入れるか」を決める前に「何を入れるべきか」を知る問題
私が地味に困っていたのが、「そもそも何を入れればいいか分からない」フェーズです。
新しい案件に入る、新しいリポジトリをcloneする、知らない技術スタックの仕事を頼まれる。そのたびに「このプロジェクト、何を仕込めば快適になるんだろう?」と考えるんですが、これがけっこう時間を食う。
たとえばReactのフロントエンド案件なら、Playwright MCPを入れたほうが捗る。Rails案件なら、テスト関係のhooksを仕込みたい。Python + 機械学習なら、また別の組み合わせが要る。
頭では分かっていても、毎回ゼロから「このスタックなら何だっけ」と思い出すのは、地味にコストです。
claude-code-setupは、この「何を入れるべきか」のフェーズを担当します。コードベースを読んで、そのプロジェクトに合いそうなhooks/skills/MCP/subagents/slash commandsを5カテゴリで提案してくれる。
APMもgh skillも、ここは解いていないんです。両方とも「入れるものが決まっている前提」で、配布と管理を担うツールなので。
スキャンが返す5カテゴリ(MCP / Skills / Hooks / Subagents / Slash Commands)
実際に走らせると、こんな感じで5カテゴリが返ってきます。
- MCP servers: プロジェクトに合うMCPサーバー(例: React案件ならPlaywright)
- Skills: 業務に役立つカスタムスキル
- Hooks: 自動トリガー(コミット前のlintとか)
- Subagents: 専門性のあるサブエージェント(例: security-reviewer)
- Slash commands: よく使う操作のショートカット
最初は各カテゴリで1〜2個の推奨が出てきて、「もっと候補を見たい」と言うと3〜5個まで広げてくれます。
ここが地味によくできていて、最初から大量に候補を出されると「で、どれを使えばいいの?」になりがちなんですが、まず厳選版を出してくれるから判断しやすい。
私の感覚だと、「この技術スタック詳しい同僚に、5分だけ相談する」みたいな体験に近いです。「あのhooksは入れといたほうがいいよ」「このMCPは無くてもいけるかな」みたいな会話を、ツールがやってくれる。
読み取り専用設計と対話形式の意味——実際の操作の流れ
ここが個人的に一番アツいポイントなんですが、claude-code-setupは 読み取り専用 で動きます。
つまり、推奨してくれるだけで、勝手にファイルを書き換えたりインストールしたりはしない。「これを入れるといいですよ」と言うだけで、実際に入れるかは自分で決められる。
これ、エンジニアの感覚だとめちゃくちゃ大事です。よく分からないツールが勝手に package.json をいじってきたら困りますよね。「とりあえずスキャンだけしてもらって、提案を見てから自分で選ぶ」ができる安心感がある。
実際の操作の流れはこんなイメージです。
/plugin install claude-code-setup@claude-plugins-officialでインストール- Claude Codeのセッションで「このプロジェクトに合うautomationを教えて」と話しかける
- 5カテゴリの推奨が返ってくる
- 気になったものをピックアップして、自分でインストールする(ここからは別ツールの出番)
「気になったものを自分でインストールする」の4ステップ目——ここでAPMとgh skillが登場します。この2つの役割を整理すると、3者の全体像がはっきり見えてきます。
APMとgh skillが担う「配布・再現・ガバナンス」の役割
claude-code-setupが「何を入れるか」を担当するなら、APMとgh skillは「決まったものをどう入れて、どう管理するか」を担当します。
両方とも基本的には「配布管理ツール」なんですが、設計思想がちょっと違うので、それぞれ見ていきます。
apm.ymlで「依存関係を宣言」する思想——npmに近いモデル
APMはMicrosoftのDaniel Meppielさんが作成し、Sergio SisternesさんらとともにメンテナンスしているOSSで、ライセンスはMIT。コンセプトを一言で言うなら「コーディングエージェント用のnpm」です。
何が便利かというと、apm.yml というマニフェストファイルにエージェント関連の依存を宣言できるんです。skill、prompt、instruction、MCPサーバー、plugin。これらを全部 apm.yml に書いておけば、別の人が apm install するだけで同じ環境が再現できる。
最小サンプルだとこんな感じになります。
name: my-project-agent-config
version: 1.0.0
dependencies:
- microsoft/apm-sample-package#v1.0.0
mcp:
- io.github.github/github-mcp-serverインストール側はこれだけ。
apm install microsoft/apm-sample-package#v1.0.0インストールコマンドはmacOS/Linuxなら次の通り。
curl -sSL https://aka.ms/apm-unix | shWindowsならPowerShellで。
irm https://aka.ms/apm-windows | iexHomebrew、Scoop、pipにも対応していて、各エコシステムの作法で入れられます。
APMが地味にすごいのは、マルチエージェント対応 なところです。Claude Code、GitHub Copilot、Cursor、OpenCode、Codex、Gemini、Windsurfに対応していて、apm compile -t copilot のように出力先のエージェントを指定するとそれぞれに合わせた形でコンパイルしてくれる。
「skillの実体は1つだけ書いて、複数のエージェント向けに展開する」という発想です。チームでエージェントが分かれているとき(Aさんは Claude Code、Bさんは Copilot、みたいな状況)に効いてきます。「ツールごとに設定を管理し直す」という地味なダルさから解放される、ここが刺さる人は刺さるはずです。
さらにエンタープライズ用には apm-policy.yml で組織ポリシーを宣言できる。「このマーケットプレイスからしかインストールを許可しない」「このスキルはバージョンXX以上必須」みたいなガバナンスが書ける。セキュリティ要件が厳しい会社でも導入できる設計です。
gh skillが保証する「配布経路の完全性」——release pinとTree SHA
gh skillは2026年4月16日にリリースされた、GitHub CLI公式のスキル管理コマンドです。要件は gh v2.90.0以上。
コマンドは直感的で、こんな感じになります。
gh skill search <keyword> # スキルを検索
gh skill preview OWNER/REPO SKILL # 中身を確認
gh skill install OWNER/REPO SKILL # インストール
gh skill update # 更新
gh skill publish # 自作スキルを公開バージョン指定もできます。
gh skill install OWNER/REPO SKILL@v1.2.0ここからがgh skillの本領で、私が一番評価しているのが 「配布経路の完全性」を保証してくれる ところです。
具体的には、tag/releaseでバージョンを管理しつつ、インストール時にgit tree SHAを記録して、SKILL.mdのfront-matterに追跡メタデータ(リポジトリ・参照・tree SHA)を埋め込む。
何が嬉しいかというと、「自分が入れたスキルが、配布元のどの状態なのか」が後から分かります。誰かがリポジトリを書き換えても、自分の手元のスキルがどのSHAから来たのかは残るので、整合性が確認できる。スキルの中身が知らないうちに変わっていた、なんて事故を防げるわけです。
--pin v1.2.0 のようにgit tagやSHAを渡してバージョンを固定すれば、不意に新しいバージョンに更新されることもない。
対応エージェントはClaude Code、GitHub Copilot、Cursor、Codex、Gemini CLI、Antigravity。APMとほぼ同じレンジで、マルチエージェント環境でも使えます。
両者の共通点:claude-code-setupと担う問いが違う
APMもgh skillも、共通しているのは 「入れるものは決まっている前提」 で動くツールだということです。
apm.ymlに書く対象が分かっている、gh skill installに渡すOWNER/REPO/SKILLが分かっている。この前提が成立して初めて、両ツールは力を発揮します。
逆に「何を入れるべきか分からない」状態だと、APMもgh skillも答えをくれない。検索はできますが、自分のプロジェクトに何が合うかまでは判断してくれないんです。
ここが、claude-code-setupとAPM/gh skillが「競合しない」理由です。担当する問いが違うので、組み合わせて使うのが自然な落とし所になります。
この「担う問いが違う」という構造を、レイヤー図に落とすと一気に見えやすくなります。ここが今回の記事の核です。
claude-code-setup・APM・gh skillの役割レイヤー——推奨エンジンと配布基盤は別物だった
最初、私もこの3つを「同じカテゴリのツール」として比較しようとして、ハマりました。
横並びで比べようとすると、どこが違うのかよく分からなくなる。レイヤーで考えると一気にスッキリします。
レイヤー図解——「何を入れるか分からない」から「チームに届ける」まで
3者をレイヤーで整理すると、こんな構造になります。
claude-code-setupは「決める」フェーズ。APMとgh skillは「実行する」フェーズ。
そう考えると、3者は競合ではなくバトンを渡し合う関係だと分かります。
個人開発者の使い方:claude-code-setup → gh skill のフロー
個人で開発している場合、私のおすすめは「claude-code-setup → gh skill」の流れです。
- claude-code-setupでプロジェクトをスキャン、推奨候補を見る
- 気になったスキルをgh skill installで入れる
--pinでバージョンを固定して、不意の更新を防ぐ
このフローのいいところは、APMほどの設定オーバーヘッドがない点です。apm.yml を書くまでもなく、必要なものをサクッと入れて始められる。
新しい案件に入ったとき、まずこのフローでサッと環境を立ち上げる。1日くらい使ってみて「これは要らない」と思ったら gh skill で外す。試行錯誤しやすいんです。
チーム開発の使い方:claude-code-setup + APM の組み合わせ
チームで開発している場合は、APMが効いてきます。
- claude-code-setupでプロジェクトの推奨を確認
- チームで「これは入れよう」と合意したものを
apm.ymlに書く - メンバーは
apm installで同じ環境を再現
apm.ymlがリポジトリにcommitされていれば、新しいメンバーがcloneしてきたときに apm install 一発でチーム標準の環境が手に入る。
しかも、エンタープライズなら apm-policy.yml で「この組織はこのマーケットプレイスからしかインストールできない」と縛れる。セキュリティ要件が厳しい会社でも導入できる設計になっています。
「個人ではgh skill、チームではAPM、何を入れるか考えるときはclaude-code-setup」と覚えておくと、迷いません。
ここまでで役割分担のイメージは掴めたと思います。次の比較表で、観点ごとの特徴を一覧で確認してみてください。
claude-code-setup vs APM vs gh skill 機能比較表
実際に並べて見ると、「え、こんなにきれいに分かれてるの?」と感じるはずです。
3者を並べて見ると、明らかにカバーする領域が違うのが分かります。
claude-code-setupは「対話・推奨」に振り切っていて、バージョン管理やガバナンス機能がない。代わりに「何を入れるべきか」という人間の判断を支援する。
APMは宣言型でロックファイルもあり、組織ガバナンスまでカバー。一番「IT部門が好きそう」な作りです。
gh skillは個人運用とチーム運用の中間に立っていて、tag/releaseとSHA追跡で配布経路の信頼性を確保しつつ、コマンドはシンプル。普段からgh CLIを使っているなら、追加学習コストもほぼゼロ。
並べてみると、本当にきれいに役割が分かれているんですよね。理解した上で次のセクションを読むと、「あ、この手順は当然そうなるな」と腹落ちするはずです。
claude-code-setup・APM・gh skillを組み合わせた実践ワークフロー
「整理は分かったけど、実際にどう使うの?」という人向けに、具体的な手順を3ステップでまとめました。
私が新しい案件に入るときに、よくやっている流れです。
ステップ1: claude-code-setupでプロジェクトのセットアップ候補を洗い出す
まず、claude-code-setupをClaude Codeに入れます。
/plugin install claude-code-setup@claude-plugins-official入ったら、対象のリポジトリで Claude Code を立ち上げて、こう話しかけます。
recommend automations for this project英語じゃなくても通じます。日本語で「このプロジェクトに合う自動化を教えて」でもOK。
返ってくる5カテゴリの推奨を見て、「これは入れたい」というものをピックアップします。私は最初は2〜3個に絞って、徐々に増やしていくスタイルです。
ここでは 何もインストールしない のがポイント。あくまで「何を入れるか」を決めるフェーズです。
ステップ2: gh skillで見つけたスキルを安全にインストールする
入れると決めたスキルを、gh skillで入れます。
gh skill search <keyword> # まず検索
gh skill preview OWNER/REPO SKILL # 中身を確認(重要)
gh skill install OWNER/REPO SKILL --pin v1.2.0--pin v1.2.0 のようにgit tagやSHAを渡してバージョンを固定するのが個人的なお作法です。スキルがいつの間にか更新されて挙動が変わる、みたいな事故を防げます。
gh skill preview は地味に大事で、入れる前に中身を読む癖をつけておくと、変なスクリプトを引き込むリスクが下がります。SKILL.mdに何が書いてあるか、どんなコマンドを実行するのか、一度目を通す。
ここまでで個人の環境はだいたい整います。実際に1〜2週間使ってみて、「これは案件全体で使うべきだな」と感じたものをチーム展開に進めます。
ステップ3: 安定したら apm.yml で宣言してチームに展開する
チームで標準化する段階に来たら、APMの出番です。
リポジトリのルートに apm.yml を作って、こう書きます。
name: project-agent-config
version: 0.1.0
dependencies:
- OWNER/REPO/SKILL#v1.2.0
- microsoft/apm-sample-package#v1.0.0
mcp:
- io.github.github/github-mcp-serverこれをリポジトリにcommitしておけば、メンバーは次のコマンドで全員同じ環境になります。
apm installCIに組み込めば、PRごとにスキル整合性チェックも回せます。
組織ガバナンスが要るなら、ルートディレクトリに apm-policy.yml も置いて、許可するマーケットプレイスやバージョン制約を書く。
apm marketplace add github/awesome-copilot「個人で試す → チーム標準化 → 組織ガバナンス」と段階的に上がっていけるので、最初から完璧を目指さなくていい。これが3者を組み合わせる最大のメリットだと思っています。
まとめ——「推奨 → 配布 → 再現」のフローで覚える
今回の3者を一言で整理するなら、こうなります。
- claude-code-setup: 推奨エンジン。「何を入れるか」を考えるフェーズを担当
- gh skill: 配布基盤(個人〜小チーム)。release pinとSHA追跡で配布の完全性を担保
- APM: 配布基盤(チーム〜組織)。apm.ymlで依存を宣言、policyでガバナンス
3者の役割を「推奨 → 配布 → 再現」のフローで覚えておくと、迷いません。
新しい案件に入った → claude-code-setupで何を入れるべきか考える。決まったらgh skillで入れる。チームで標準化するならAPMに移す。
このフローを回せるようになると、Claude Codeの拡張管理がぐっと楽になります。「とりあえず入れまくってカオス」「人によって環境がバラバラ」みたいな状態から抜け出せる。
まずはclaude-code-setupをインストールして、いま手元にあるリポジトリでスキャンを1回走らせてみてください。コマンド1行、1分で終わります。「あ、こういう提案が返ってくるのか」と体感できれば、残り2つの使い所も自然に分かってきます。





💬 コメント
ログイン か 会員登録 するとコメントできます