はじめに

前に Metadata API Context Skill を調べたとき、forcedotcom/sf-skills というリポジトリを1スキルだけ覗いて終わりにしていました。

あとで「そもそもこのリポジトリ、他にどんなスキルが入っているんだろう」と気になったので、今回はリポジトリ全体をざっくり眺めて整理します。

個別スキルの使い方を深掘りするのではなく、「どんな粒度で」「どんな領域に」スキルが用意されているのか という地図を作るのが目的です。

※本記事は個人の整理メモです。数値・構成はすべて 2026-08-04時点 の forcedotcom/sf-skills リポジトリ（コミット fe3e2ed、リリース 1.33.0、2026-07-31）を実際に取得して数えたものです。README自身が「頻繁に変わる」と明言しているリポジトリなので、読むときは必ず現物を確認してください。

この記事で扱うもの / 扱わないもの

扱うもの

forcedotcom/sf-skills リポジトリの全体構成
112個のスキルがどのドメインに分かれているか
スキル名の命名規則（ドメイン × 対象 × 動詞）
SKILL.md のfrontmatterに何が書かれているか
導入方法と、インストール先ディレクトリ
使う前に知っておきたい注意点

扱わないもの

個別スキルを実際に本番組織へ適用した検証結果
Agentforce Vibesの契約条件・ライセンス費用の詳細
「このスキルを入れれば開発が速くなる」という効果測定
スキルの中身（プロンプト設計）の良し悪しの評価

数え方はシンプルで、リポジトリを浅くクローンして skills/ 配下のディレクトリと SKILL.md を集計しただけです。特別なツールは使っていません。

まず結論

先に結論を書くと、sf-skillsは次のように捉えると整理しやすいと感じました。

観点	整理
正体	SalesforceがGitHubで公開・管理している、Agent Skills形式のAIコーディングエージェント向けスキル集
規模	112スキル / `skills/` 配下に4,100ファイル（2026-08-04時点）
分類	スキル名の先頭が実質的なドメイン名。14ドメインに分かれる
最大勢力	`platform-*` が38スキルで全体の約3分の1
中身	`SKILL.md` は必須。`references/` `assets/` `scripts/` `examples/` は任意
導入	Agentforce Vibesは自動。他ツールは `npx skills add forcedotcom/sf-skills`
一番の注意点	「頻繁に変わる」とREADMEが明言している。GA APIのような安定性はない

個人的に一番の発見は、カテゴリ用のディレクトリが存在しない ことでした。skills/ の直下にフラットに112個並んでいて、分類はすべて「名前の先頭」で表現されています。

sf-skillsリポジトリの全体像

READMEに書かれている構成はこうです。

sf-skills/
├── skills/               # ディレクトリ単位の実行可能ワークフロー
│   ├── platform-apex-generate/
│   ├── platform-custom-object-generate/
│   ├── automation-flow-generate/
│   └── ...
├── samples/              # npmから同期されるサンプルアプリ
│   └── ui-bundle-template-app-react-sample-b2e/
│   └── ...
├── scripts/
│   └── ...
└── README.md

実際に取得して数えると、skills/ 配下は次の内訳でした。

項目	数
スキル（ディレクトリ）数	112
`skills/` 配下の総ファイル数	4,100
`SKILL.md` を持つスキル	112（必須）
`references/` を持つスキル	79
`assets/` を持つスキル	41
`scripts/` を持つスキル	37
`examples/` を持つスキル	27
`README.md` を持つスキル	25

READMEでは各スキルのディレクトリ構成が次のように説明されています。

SKILL.md（必須）: 指示内容とYAML frontmatter
scripts/（任意）: 実行可能なスクリプト（Python、Bash、JavaScriptなど）
references/（任意）: 追加のリファレンス文書
assets/（任意）: テンプレート、スキーマ、ルックアップデータ

なお examples/ はREADMEの一覧には出てきませんが、27スキルが実際に持っています。「任意ディレクトリはこの3つに限る」という縛りではなさそうです。

samples/ はスキルではなく、npmパッケージ（@salesforce/ui-bundle-template-app-react-sample-b2e など）から毎晩GitHub Actionsで同期されるReactサンプルアプリ置き場です。バージョンが変わったときだけPRが作られる仕組みになっています。

スキル名の付き方 - ドメイン × 対象 × 動詞

112スキルの名前を並べると、ほぼ例外なく次の形になっています。

<ドメイン> - <対象> - <動詞>

platform  -  apex           -  generate
platform  -  metadata-api-context  -  get
dx        -  code-analyzer  -  run
data360   -  query                        ← 対象が省略される場合もある
agentforce-  bot            -  upgrade

末尾の動詞を数えると、上位はこうなります。

末尾の動詞	数	意味合い
`generate`	39	生成する（Apex、Flow、LWC、メタデータなど）
`configure`	19	設定する（暗号化、共有設定、チャネルなど）
`analyze`	4	分析する
`get`	4	情報を取得する（コンテキスト提供系）
`manage`	4	管理する
`coordinate`	4	複数スキルを取りまとめる
その他	38	`run` `deploy` `query` `create` `validate` `apply` `debug` など

「作る」と「設定する」で58スキル、全体の半分強を占めます。逆に言うと、sf-skillsは「生成と設定を自動化するための道具箱」 という性格が強いです。

命名ルールはリポジトリ内の検証スクリプト scripts/validate-skills.ts で機械的にチェックされています。読むと分かる制約は次のとおりです。

名前はkebab-case（小文字・数字・ハイフンのみ）
名前は64文字以内
skills/ 直下の1階層のみ（カテゴリ用のサブディレクトリを作ってはいけない）
ディレクトリ名とfrontmatterの name が一致すること

このスクリプトは npm run validate:skills で実行でき、GitHub Actionsのpull_requestトリガーで自動実行されます。変更されたスキルだけを検証する --changed --base=origin/main モードもあります。

余談として、このバリデータには「名前の最初の単語は -ing で終わる動名詞形にすべき（例: generating-apex-tests）」というチェックも入っています。ただし重要度が warning 扱いで、コード内にも「警告は表示されるが終了コードは0のまま」と書かれています。sf-skillsの112スキルはすべてドメイン名始まりなので、この警告は全件出る前提の運用になっているようです。Agent Skills一般の推奨と、Salesforce側の都合（ドメインで並べたい）が食い違った跡だと読めます。

どんなスキル群があるのか - 14ドメイン112スキル

名前の先頭で分類すると、14ドメインになります。

ドメイン	数	ざっくり何のスキルか
`platform-*`	38	Apex、SOQL、メタデータ、権限セット、共有設定、レポートなどコア機能全般
`experience-*`	17	LWC、LWRサイト、UI bundle、CMSなどExperience Cloud／フロントエンド
`dx-*`	14	Salesforce DX運用（スクラッチ組織、Code Analyzer、DevOpsテスト、パッケージ）
`data360-*`	9	Data Cloud（Data 360）の接続・整形・クエリ・セグメント
`omnistudio-*`	8	OmniScript、FlexCard、DataMapper、Integration Procedureなど
`agentforce-*`	6	エージェントの生成・テスト・観測・アーキテクチャ分析
`integration-*`	4	Named Credential、外部サービス、Platform Event、CDC
`service-*`	4	Service Cloud（Help Agent、デジタルエンゲージメント）
`commerce-*`	3	B2Bコマースストア、Open Codeコンポーネント
`design-systems-*`	3	SLDSの適用・検証・SLDS2移行
`mobile-*`	3	Mobile SDK、ネイティブ機能、オフライン検証
`automation-*`	1	Flow生成
`external-*`	1	Mermaid図の生成
`sales-*`	1	Agentforce Pipeline Management設定

眺めていて面白かった点をいくつか。

`platform-*` が38スキルで最大勢力

Apex（生成・テスト生成・テスト実行・ログデバッグの4分割）、カスタムオブジェクト／項目／タブ／アプリケーション、権限セット、共有設定（OWDと共有ルールで別スキル）、入力規則、レポート、SOQL……と、Salesforce開発で日常的に触る対象がほぼ1つずつスキルになっています。

1スキル1タスクの粒度がかなり細かいのが特徴で、たとえばApexは「書く」「テストを書く」「テストを流す」「ログを見る」で4スキルに分かれています。

`experience-*` の12個がUI bundle関連

17スキル中12個が experience-ui-bundle-* です。プロジェクト生成、フロントエンド生成、メタデータ生成、デプロイ、MFA設定、ファイルアップロード、Salesforceデータアクセス……と、UI bundleの工程ごとに分かれています。

Multi-Framework GA（SalesforceでReactアプリを動かす）の文脈と地続きの領域で、工程ごとにスキルを分けるくらい力が入っていると分かります。

ドメインが1スキルしかない領域もある

automation-flow-generate（Flow生成）は1スキルだけですが、descriptionには「This is the only skill for Salesforce Flow generation.」と明記されています。数が少ない＝手薄、とは限らないようです。

SKILL.mdの中身を1枚で見る

スキルの実体は SKILL.md 1枚です。先頭にYAML frontmatterがあり、その下がAIへの指示本文になります。

実際の例（platform-apex-generate）を短くすると、こんな形です。

---
name: platform-apex-generate
description: "Primary Apex authoring skill for class generation, refactoring, and review.
  ALWAYS ACTIVATE when the user mentions Apex, .cls, triggers, or asks to create/refactor
  a class (service, selector, domain, batch, queueable, ...)."
metadata:
  version: "1.0"
  minApiVersion: "66.0"
---

# Apex 生成スキルの本文（AIへの手順書）

112スキル分のfrontmatterを集計すると、使われているキーはこうでした。

キー	使用スキル数	必須か
`name`	112	必須（ディレクトリ名と一致）
`description`	112	必須
`metadata.version`	112	必須（`x.y` 形式）
`metadata.minApiVersion`	41	任意
`metadata.cliTools`	41	任意（必要なCLIとsemver範囲）
`metadata.relatedSkills`	35	任意（関連スキル名の配列）
`compatibility`	14	任意（前提条件を1文で）
`allowed-tools`	10	任意（スペース区切りの文字列）
`metadata.mcpTools`	4	任意

description の書き方には、バリデータでかなり細かい制約がかかっています。

ダブルクォートで囲むこと
20語以上（情報量を確保するため）
1,024文字以内
小文字化したときに use を含むこと（＝発動条件を書かせるため）

実際の分布を測ると、112スキルのdescriptionは 中央値710文字、最大1,023文字（上限ぎりぎり）でした。日本語の感覚だと「説明文」というより、AIにいつ発動すべきかを教え込むための小さなプロンプトです。

本文の長さは中央値207行、最大623行。バリデータは500行を超えると警告を出しますが（これも警告止まり）、超えているのは3スキルだけでした。

metadata.minApiVersion の値は 67.0 が13スキルで最多、古いものでは 47.0 もありました。これは、そのスキルが前提とする最低APIバージョンを示しています。プロジェクトの sourceApiVersion や、利用するAPI／メタデータのバージョンとの整合性を確認したほうがよさそうです。

スキル同士が「譲り合う」設計になっている

眺めていて一番「うまいな」と思ったのが、発動条件だけでなく、発動しない条件がdescriptionに書かれている点です。

112スキル中、

TRIGGER when: を含むもの: 70スキル
DO NOT TRIGGER を含むもの: 72スキル
他スキルの名前をdescriptionの中で名指ししているもの: 81スキル

たとえば experience-lwc-generate はこう書いています。

TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html,
.css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests.
DO NOT TRIGGER when: Apex classes (use platform-apex-generate), Aura components,
or Visualforce.

data360-query も同様に「標準のCRM SOQLなら platform-soql-query を使え」「セグメント設計なら data360-segment を使え」と、隣のスキルへ明示的に投げています。

112スキルを全部入れると、AIから見れば「似た名前の道具が112個並んでいる」状態になります。そこで誤爆しないよう、各スキルが自分の境界線を自己申告しているわけです。

さらに metadata.relatedSkills を宣言しているスキルが35個あり、平均4.7個、最大では37個の関連スキルを列挙していました。スキル同士がゆるやかにグラフを作っている、と捉えると理解しやすいです。

自分でスキルを書くときにも、この「DO NOT TRIGGERを書く」「隣のスキル名を名指しする」は真似したい書き方でした。

スキルの「重さ」は均一ではない

スキル数だけ見ると112個で横並びに見えますが、中身のサイズは全く均一ではありません。ファイル数の多い順に並べると次のようになります。

スキル	ファイル数
`platform-data-and-tooling-api-context-get`	2,137
`platform-metadata-api-context-get`	612
`design-systems-slds-apply`	151
`agentforce-architecture-analyze`	91
`agentforce-generate`	78
（全112スキルの中央値）	6

上位2つで全4,100ファイルの約3分の2を占めています。この2つは「AIに渡す参照データそのもの」を抱えているスキルで、platform-metadata-api-context-get は604個のMetadata APIタイプのJSONを持っています（このスキルについては前回の記事で整理しました）。

一方、中央値は6ファイル。多くのスキルは SKILL.md に数個の references/ が付く程度です。

つまりsf-skillsには、性格の違う2種類が混ざっています。

種類	中身	例
手順書型	AIへの作業手順が中心。ファイル数は少ない	`platform-apex-generate`、`dx-org-manage`
資料庫型	大量の参照データを抱え、AIに根拠を渡す	`platform-metadata-api-context-get`、`platform-data-and-tooling-api-context-get`

資料庫型は「全部読ませない」ことが前提の設計になっているので、扱うときは意識が必要です。

導入方法と、どこに入るのか

READMEに書かれている導入方法は2通りです。

ツール	導入方法
Agentforce Vibes	自動インストール・自動更新
OpenCode、Claude Code、Codex、Cursor など	`npx skills add forcedotcom/sf-skills`

この skills コマンドはSalesforce製ではなく、Agent Skillsエコシステムの共通CLI（npmパッケージ skills / vercel-labs/skills）です。インストール先はエージェントごとに決まっていて、READMEの対応表から抜粋すると次のようになります。

エージェント	プロジェクト内	グローバル（`-g`）
Claude Code	`.claude/skills/`	`~/.claude/skills/`
Codex	`.agents/skills/`	`~/.codex/skills/`
Cursor	`.agents/skills/`	`~/.cursor/skills/`

いきなり112個全部を入れる必要はなく、次のように絞り込めます。

# 何が入っているかだけ見る（インストールしない）
npx skills add forcedotcom/sf-skills --list

# 必要なスキルだけ入れる
npx skills add forcedotcom/sf-skills --skill platform-apex-generate --skill platform-soql-query

# エージェントを指定して入れる
npx skills add forcedotcom/sf-skills -a claude-code

絞り込みを勧めるのには理由があって、スキルのdescriptionは常時コンテキストに載るからです。112スキル分のdescriptionを合計すると約78,000文字ありました。英語なので単純計算でも2万トークン前後の常設コストになります（実際の消費量はツールの読み込み方式やトークナイザによって変わるので、目安として捉えてください）。

Apexしか触らないプロジェクトにOmniStudioとCommerceとMobileのスキルを常駐させる意味は薄いので、まずは --list で眺めて、必要な領域だけ入れるのが扱いやすいと感じました。

使う前に知っておきたい注意点

1. 「頻繁に変わる」と公式が明言している

READMEの冒頭に警告があります。

Expect frequent changes. The Salesforce skills library is evolving rapidly as we refine patterns and incorporate feedback. Skills may be renamed, restructured, or removed between releases — they do not follow the same stability guarantees as GA platform APIs.

スキル名を手順書や社内ドキュメントに直書きすると、リネームで壊れます。本記事の112という数字も、読んでいる時点では変わっている可能性が高いです。

2. 前提条件が要るスキルがある

compatibility フィールドを持つ14スキルは、追加の前提が必要です。例を挙げると、

data360-query: 「外部のコミュニティ製 sf data360 CLIプラグインと、Data Cloud有効化済み組織が必要」
commerce-b2b-store-create: 「Commerceライセンス、Experience Cloud、Salesforce CLIが必要」

また metadata.cliTools を宣言している41スキルは、sf（>=2.139.6 など）、jq、python3、curl といったツールのバージョン要件を持っています。入れただけでは動かないスキルがある、という前提で見たほうがよさそうです。

3. MCPツール前提のスキルがある

automation-flow-generate のdescriptionは「Generate Salesforce Flows using the MCP tool execute_metadata_action」で始まります。metadata.mcpTools を宣言しているスキルも4つあります。

スキルだけ入れてもMCPサーバー側が未設定なら期待どおりに動かないので、スキルとMCPはセットで見る必要があります。

4. ライセンス表記が2箇所で食い違っている

これは実務で判断が要りそうな点なので書いておきます。

ファイル	記載
`LICENSE.txt`	Apache License Version 2.0（Copyright (c) 2026 Salesforce, Inc.）
ルートの `package.json`（npmパッケージ `@salesforce/afv-skills` v1.33.0）	`"license": "CC-BY-NC-4.0"`

CC-BY-NC-4.0は非商用ライセンスなので、Apache-2.0とは条件がかなり違います。同じリポジトリの中で両方が存在している状態です。

どちらの表記が、どの配布物や利用形態に適用されるのかは、この2ファイルだけでは断定できません。スキルをフォークして再配布する、内容を製品や社内資産へ組み込むといった場合は、リポジトリ管理者への確認や法務確認を挟んだほうが安全です（本記事は法的助言ではありません）。

5. 生成物のレビューは結局必要

platform-apex-generate のように、静的解析（Code Analyzer）とテスト実行まで手順に組み込んでいるスキルもありますが、それでも組織固有の設定・ライセンス・依存機能まではスキル側では分かりません。

デプロイ前の sf project deploy validate と差分レビューは、これまでどおり残る作業だと思っておくのが無難です。

まとめ

sf-skillsをざっくり眺めて分かったことを、3つに絞ると次のとおりです。

フラットな112スキル、分類は名前の先頭で表現されている。 カテゴリのディレクトリはなく、platform- experience- dx- などのプレフィックスが実質的なドメイン。platform-* だけで38スキルと最大勢力。
粒度が細かく、スキル同士が譲り合う設計。 Apexだけで4スキルに分かれ、72スキルが DO NOT TRIGGER を書き、81スキルが隣のスキルを名指ししている。112個並んでも誤爆しないための工夫と読める。
全部入れる前提の道具箱ではない。 descriptionの合計は約78,000文字あり、常時コンテキストに載る。--list と --skill で必要な領域だけ入れるほうが扱いやすい。

「Salesforce開発の何がAIに任せられる範囲として整理されているか」を知る資料としても、この一覧はなかなか面白い読み物でした。次は platform-apex-generate あたりを実際に動かして、手順書型スキルの中身を追ってみようと思います。

参考（公式情報）

Salesforce Skills Library | GitHub
https://github.com/forcedotcom/sf-skills
Salesforce Skills Library README
https://github.com/forcedotcom/sf-skills/blob/main/README.md
スキル検証スクリプト scripts/validate-skills.ts | GitHub
https://github.com/forcedotcom/sf-skills/blob/main/scripts/validate-skills.ts
Metadata API Context Get Skill | GitHub
https://github.com/forcedotcom/sf-skills/tree/main/skills/platform-metadata-api-context-get
skills CLI（Agent Skillsエコシステムの共通CLI）| GitHub
https://github.com/vercel-labs/skills
Agent Skills specification
https://agentskills.io/
Build Smarter with Metadata API Context Skills | Salesforce Developers Blog
https://developer.salesforce.com/blogs/2026/07/build-smarter-with-metadata-api-context-skills