Claude Skills マーケットプレイス 2026 — 本当にインストールする価値のあるスキルのキュレーション(役割別バンドルとコンテキスト予算会計)

プロローグ — スキルはタダではない
1章 · 2026年 Claude Skills マーケットプレイス地図
2章 · コードレビュー & PR ワークフロー
3章 · リリース & チェンジログ
4章 · コンテンツドラフティング
5章 · ランブック実行
6章 · リサーチヘルパー
7章 · コードベース探索
8章 · 個人生産性
9章 · パートナー統合スキル
10章 · キュレーション哲学 — コンテキスト予算会計
11章 · 役割別スキルバンドル推奨
12章 · マーケットプレイスの未来 — 2026 下半期予測
エピローグ — チェックリスト、アンチパターン、次回予告
参考 / References

プロローグ — スキルはタダではない

前回の記事ではゼロからスキルを作った。SKILL.md、メタデータ、入出力例、allowed-tools、フォルダ構造まで。あの記事のメッセージは「必要なら自分で作れ」だった。

今回は反対側だ。すでに優れたスキルが大量に存在する。 Anthropic 公式マーケットプレイス、パートナー統合、コミュニティレジストリ — 何百ものスキルが並んでいる。全部インストールすればいい? 絶対に違う。

スキルはタダではない。 インストール済みのスキル1個あたり:

コンテキストウィンドウの一部を占有する(少なくとも SKILL.md のメタデータ)
エージェントが毎回「これを使うべきか?」と判断する必要がある(decision tax)
誤発動すれば見当違いのことをする(false trigger)
メンテナンスが要る(作者が手を離せば stale 化)

だから本当に難しい問いは「何をインストールするか」ではなく「何をインストールしないか」だ。200K コンテキストは無限ではない。30個のスキルをすべて有効化すれば、自分のコードすら見えなくなる。

この記事はキュレーションだ。2026年5月時点で、どのスキルが自身のコンテキストコストを正当化するかをカテゴリ別に整理する。最後に役割別バンドル — Backend・Frontend・SRE・PM・テクニカルライター — を推奨する。

1章 · 2026年 Claude Skills マーケットプレイス地図

まず、どこに何があるかを整理する。スキルの出所は大きく4つ。

1-1. Anthropic 公式マーケットプレイス

anthropic-skills プラグインに束ねられた公式スキル群。Anthropic が直接作りメンテナンスする。2026年現在のコアは:

docx / pptx / xlsx / pdf — オフィス文書の生成・編集・読み取り。Word/PowerPoint/Excel/PDF を直接扱う最も検証された道。
skill-creator — スキルを作るか改修するメタスキル。最初のスキル作成時にはほぼ必須。
consolidate-memory — メモリファイル群を整理するスキル。CLAUDE.md が肥大化したら呼ぶ。
setup-cowork — Cowork(チーム共有コンテキスト)設定ヘルパー。

このバンドルの原則は 「迷ったらオン」。信頼度が高く、他スキルの基盤になることが多い。

1-2. パートナー統合スキル

エンタープライズ SaaS ベンダーが Anthropic と協力して作る公式スキル。OAuth フローが組み込み済み、MCP サーバーが同梱される。

Atlassian(Jira・Confluence): チケット作成・検索、Wiki ページ作成
Figma: デザインファイル読み取り、コンポーネント抽出、デザイン-開発ハンドオフ仕様生成
Canva: デザインアセット生成・編集
Stripe: (制限付き)決済・サブスクリプションデータ照会 — トランザクション実行はブロック
Notion: ページ・データベースの読み書き
Zapier: Zap トリガーを呼び出し(Zapier 1経由で何千もの統合)
Slack: チャンネルメッセージ、DM、スレッド作業
Linear / Asana / ClickUp / Monday: プロジェクト管理統合
HubSpot / Salesforce 系 CRM: リード・ディール・コンタクト照会
GitHub / GitLab: PR・Issue・コードワークフロー

パートナースキルは社内 SaaS スタックと1対1で合わせてインストールする。使っていない SaaS のスキルを残しておくと false trigger の温床。

1-3. コミュニティマーケットプレイス(GitHub 起点)

awesome-claude-skills のようなキュレーションリポジトリ、個別メンテナーのスキルリポジトリ、そして増え続ける「スキルコレクション」型 plugin。2026年現在よく知られている出所:

anthropic-cookbook の Skills セクション — 公式サンプル集
awesome-claude-skills — コミュニティキュレーションインデックス
個別メンテナーの dotfiles 風スキル — GitHub スターが信頼シグナル

重要な注意: コミュニティスキルは出所検証が必須。SKILL.md だけ見ると立派だが、実際は bash 権限を広範に要求するケースがある。インストール前に allowed-tools セクションとシェルスクリプトを自分で読むこと。

1-4. 社内自作スキル

最も価値が高いカテゴリ。会社の中のワークフロー、コンベンション、ドメイン知識をスキルにしたもの。外部スキルでは代替不可(例:「自社の PR テンプレート」「自社のインシデント対応手順」)。通常は社内 Git リポジトリで管理し、.claude/skills/ にシンボリックリンクする。

この記事は外部スキルのキュレーションに集中する。社内スキルの作り方は前回の記事で。

2章 · コードレビュー & PR ワークフロー

エンジニアが最も多くスキルを有効化する領域。効果が可視化しやすく ROI が明確。

2-1. PR サマライザー

何をするか: PR の diff を読み「これは何をする PR か」を人間が読める要約として生成。通常 PR 本文の最初の段落に挿入する。

なぜコストを正当化するか:

レビュアーが最初の30秒で PR を理解できる
diff だけでは見えない「なぜ」を捉える
多言語チームでは要約が自動英訳されてグローバルレビューが活性化

よく合う組み合わせ: Conventional commit drafter(下)、security review スキル。1つの PR で3つが同時に動けば「要約 + コミット整理 + セキュリティチェック」セット完成。

インストールすべきとき: PR 本文が1行(fix bug)になりがちなチーム、PR が1日5件以上動くチーム。

インストールしない方がいいとき: 1人プロジェクト、PR 本文を必ず人が手で書く文化のチーム(重複)。

2-2. セキュリティレビュースキル

何をするか: 一般的なセキュリティ問題(SQL injection、XSS、secret leak、IDOR パターン、弱い暗号化)をパターンマッチで検出し、深刻度付きでコメント草案を作る。

なぜ: 人間のレビュアーは毎回セキュリティを意識し続けられない。「速いね」が1回、「テスト追加して」が1回、そしてセキュリティは流れる。スキルは流さない。

よく合う組み合わせ: PR サマライザー、Aikido / Snyk のような SCA ツール(MCP 経由)。スキルが1次の網、SCA が2次の網。

インストールすべきとき: 金融・医療・B2B SaaS など、セキュリティがビジネスリスクのドメイン。

インストールしない方がいいとき: 社内向けデモ・プロトタイプ。False positive 疲労が価値を上回る。

2-3. Conventional Commit ドラフター

何をするか: ステージ済み変更(git diff --staged)を見て Conventional Commits 規約に沿うコミットメッセージ候補を2-3個提示。feat:、fix:、refactor: などのタイプ、スコープ、変更の「なぜ」を含む本文。

なぜ: よいコミットメッセージは将来のデバッグ・リリースノート・チェンジログ・git bisect の資源だ。「なぜ」を書くのは人間が最も怠惰になる作業であり、スキルが最もよく助けてくれる作業。

よく合う組み合わせ: リリースノート生成スキル(下) — コミットメッセージが整えば、リリースノートの品質も自動的に上がる。

インストールすべきとき: Conventional Commits を採用しているチーム、採用したいチーム。

インストールしない方がいいとき: 1人プロジェクトで本人が既に習慣化済みのとき。

2-4. PR チェックリストエンフォーサー

何をするか: 社内 PR テンプレート(テスト追加? マイグレーション? ロールバック手順? モニタリングアラート?)を自動で埋めるか、空欄を表示する。

よく合う組み合わせ: 社内 deploy-checklist スキル、社内 ADR スキル。

インストールすべきとき: PR テンプレートが長く、頻繁に空欄が残るチーム。最もコスパのよいスキルのひとつ。

3章 · リリース & チェンジログ

3-1. release-notes-from-git-log

何をするか: 前回タグから HEAD までのコミットを読み、ユーザー向けリリースノート(### Added / ### Fixed / ### Breaking)を生成。Conventional Commits を使っていれば精度が急上昇。

よく合う組み合わせ: Conventional commit drafter(上流)、社内 changelog フォーマットスキル、social copy スキル(下) — リリースノートがツイートや LinkedIn 投稿に自動変換。

インストールすべきとき: 隔週以上でリリースを回すチーム。毎回リリースノートを人が絞り出す時間は統計的に最大級の無駄。

インストールしない方がいいとき: 「continuous deploy、ノートなし」の文化。

3-2. SemVer 判定器

何をするか: 変更リストと公開 API スナップショットを比較し、次のリリースが patch、minor、major のどれかを推奨。Breaking change 候補を別途表示。

なぜ: SemVer はライブラリメンテナーの永遠の頭痛。外部依存者がいるライブラリでの誤った minor リリースは下流のビルドを全部壊す。

よく合う組み合わせ: 公開 API 抽出スキル、breaking-change detector。

インストールすべきとき: ライブラリ・SDK・公開 API メンテナー。

3-3. Changelog マイグレーションヘルパー

何をするか: Keep a Changelog フォーマット、GitHub Releases markdown、社内 wiki — 同じ変更情報をチャンネル別に異なるフォーマットで整形。一度書いたリリースノートを3箇所に自動複製。

よく合う組み合わせ: Notion 統合スキル、Slack チャンネル自動投稿スキル。

4章 · コンテンツドラフティング

エンジニアが書かない理由は「書けないから」ではなく「空白ページが怖いから」。スキルがその空白を埋める。

4-1. ブログ記事ドラフター

何をするか: 変更コード、リリースノート、議事録 — 入力ソースを受けてブログ記事の草案を生成。社内トーン・構造ガイドに従う。

よく合う組み合わせ: Brand voice スキル(下)、Notion 統合(草案を自動保存)。

インストールすべきとき: デベロッパーマーケティング・DevRel チーム、または会社のブログを運営するすべてのエンジニアリング組織。

インストールしない方がいいとき: 真正性がコアアセットの1人ブロガー(過依存リスク)。

4-2. Changelog → ソーシャルコピー変換器

何をするか: リリースノートを1つのツイートスレッド、LinkedIn 投稿、社内 Slack 告知に変換。チャンネル別のトーン・長さ・ハッシュタグ。

よく合う組み合わせ: release-notes-from-git-log(上流)。1パイプライン: git log → リリースノート → ソーシャルコピー。

4-3. Brand Voice エンフォーサー

何をするか: 会社のトーン・文体ガイド(例:「能動態を使え」「感嘆符控えめ」「不必要なマーケティング形容詞禁止」)を把握し、草案をそのトーンで整える。

なぜ: 複数人がコンテンツを作るとトーンが分散する。人が常にトーンガイドを暗記できない。スキルは暗記する。

よく合う組み合わせ: ブログ記事ドラフター、マーケティングメールドラフター。

4-4. 会議 → ブログ変換器

何をするか: Granola・Fireflies のような会議ツールの raw transcript を受け、外部公開可能なブログ記事の草案に変換。機微情報マスキング + トーン整形。

よく合う組み合わせ: Granola スキル、Brand Voice エンフォーサー。

5章 · ランブック実行

SRE・プラットフォーム・オンコール領域。1度のミスが高くつくので、スキルのコスパが最も高い。

5-1. インシデントトリアージスキル

何をするか: 受信したアラートのペイロード(PagerDuty/Datadog/Sentry)を解析し、(a) 深刻度分類、(b) 影響範囲推定、(c) 過去の類似インシデント検索、(d) 初動ステップ提示。

なぜ: インシデント初期5分が最も重要で、最も事故が起きる。眠気の残るオンコール担当者に「1) ユーザー N 名影響、2) 類似は PD-1234、3) 初動: A/B 確認」と自動で出すのが本当の価値。

よく合う組み合わせ: PagerDuty スキル、Sentry スキル、社内 runbook インデックススキル。

インストールすべきとき: 24/7 運用責任を持つチーム。

5-2. オンコール応答テンプレート

何をするか: 「ユーザー報告への初動応答 — 情報収集 + 平静な応答」「ステータスページ最初の更新」「社内インシデントチャンネル最初のメッセージ」— チャンネル別に整えられたテンプレートを状況に合わせて埋める。

よく合う組み合わせ: Slack スキル、Statuspage MCP。

5-3. Runbook 実行ガイド

何をするか: 社内 runbook(通常 Markdown)をインデックス化し、人が「X をやる必要がある」と言ったら該当 runbook を見つけてステップ別実行ガイドを提供。危険なステップ前に確認要請。

よく合う組み合わせ: AWS / GCP / Azure CLI MCP(下)、Kubernetes スキル。

インストールすべきとき: Runbook が wiki に整備されているチーム。Runbook が形骸化していると、スキルが堂々と嘘をつく。

5-4. ポストモーテムドラフター

何をするか: インシデントタイムラインの raw(Slack スレッド、PagerDuty イベント、デプロイログ)を受けて、blameless ポストモーテム草案を作成。「5 Whys」「Action Items」セクション付き。

よく合う組み合わせ: Slack スキル、PagerDuty スキル、Notion スキル。

6章 · リサーチヘルパー

技術的決定の根拠を集める領域。誤用すれば時間泥棒、活用すれば時間節約器。

6-1. 論文サマライザー

何をするか: arXiv PDF か学会論文 PDF を受け取り、「1) 問題、2) 中核アイデア、3) 評価結果、4) 限界、5) 1行要約」の5セクション要約を生成。数式は自然言語で説明。

なぜ: AI 分野では週に何百本の論文が出る。人間は全部読めない。「深く読む価値があるか」を90秒で判断してくれる道具が必要。

よく合う組み合わせ: PDF スキル(公式)、Notion ノート統合。

インストールすべきとき: リサーチエンジニア、応用 ML チーム、技術意思決定者。

6-2. URL 3つの比較表生成器

何をするか: 競合製品3つのページ(例: Drizzle / Prisma / Kysely)を受けて、フィーチャー比較表を生成。マーケティング誇張を削ぎ、客観的比較項目に整える。

よく合う組み合わせ: Web フェッチツール、社内 ADR スキル。

インストールすべきとき: 技術選定を頻繁にするチーム、ベンダー評価が多いチーム。

6-3. RFC 比較スキル

何をするか: 2-3個の RFC または ADR 文書を受けて、「共通点・差異点・決定に必要な追加情報」の表を作る。

よく合う組み合わせ: Notion / Confluence スキル。

7章 · コードベース探索

新しいコードベースに合流するとき、または大きなリファクタリングを始めるとき、最も高くつくコストは「どこに何があるか分からない」。

7-1. アーキテクチャマッパー

何をするか: コードベースをスキャンしてモジュール間依存グラフ、データフロー、外部システム統合点、そして「このシステムの hot spot 5つ」を Markdown でまとめる。

なぜ: 新人オンボーディング初週に最も必要な資料。だが手書きで描くと常に stale。

よく合う組み合わせ: Mermaid 図生成器、社内 ADR スキル。

インストールすべきとき: 大きなモノリス、数十のマイクロサービス、レガシーコードを引き継ぐとき。

7-2. Dead Code ファインダー

何をするか: import グラフと呼び出しグラフを解析して「他のどこからも呼ばれていない関数・ファイル・エンドポイント」候補を表示。動的 import / リフレクションのケースは false positive 可能性も同時に表示。

なぜ: Dead code は毎度レビュアーの認知資源を蝕む。定期的に掃除するチームとしないチームのコードベース健全度差は1年後に歴然。

よく合う組み合わせ: Test coverage 解析スキル、社内 refactor ガイドスキル。

インストールすべきとき: コードベースが2年以上生存した時点から。

7-3. 依存性監査器

何をするか: package.json、pyproject.toml、go.mod を読み、(a) 未使用依存、(b) セキュリティ勧告、(c) major バージョンアップグレード候補を整理。

よく合う組み合わせ: Aikido / Snyk MCP。

7-4. テストギャップ解析器

何をするか: どのコードパスがテストでカバーされていないか、そして「このパスがビジネス的にどれだけ重要か」も合わせて評価し、テスト追加優先順位を付ける。

よく合う組み合わせ: Coverage ツール(vitest --coverage、pytest-cov)、社内 critical path 定義スキル。

8章 · 個人生産性

最も直接的に時間を返してくれるカテゴリ。

8-1. 日次スタンドアップライター

何をするか: 昨日の PR・コミット・完了チケット・明日のカレンダーをまとめて「昨日・今日・ブロッカー」の3段スタンドアップノートを生成。Slack に自動投稿。

よく合う組み合わせ: GitHub スキル、Linear / Jira スキル、Slack スキル、Calendar スキル。

インストールすべきとき: 毎日非同期スタンドアップノートを書くチーム。

8-2. 議事録 → アクションアイテム抽出器

何をするか: Granola・Fireflies などの議事録 raw を受けて、アクションアイテムのみ抽出。担当者・期限別に整理。ユーザー確認後 Linear/Jira に自動チケット作成。

よく合う組み合わせ: Granola スキル、Linear スキル。

8-3. メールトリアージヘルパー

何をするか: 受信箱をスキャンして「今日返信 / 今週 / FYI / 無視可」の4分類。返信すべきもののうち単純なものは応答草案まで。

よく合う組み合わせ: Gmail / Outlook 統合。

インストールしない方がいいとき: メールをほぼ見ない職種。コンテキストウィンドウの無駄。

8-4. 週次レトロライター

何をするか: 一週間の PR/コミット/議事録/カレンダーをまとめて「今週やったこと / やれなかったこと / 来週の優先事項」の3セクションレトロを生成。

よく合う組み合わせ: GitHub スキル、Calendar スキル、Notion スキル。

9章 · パートナー統合スキル

SaaS 統合は通常 MCP サーバー + スキルのペアで来る。MCP がツール、スキルがワークフロー知識を提供。

9-1. Atlassian (Jira・Confluence)

何をするか: チケット検索・作成・移動、Wiki ページ読み書き。スキルは「良いバグチケットの書き方」「リリースノートページの作り方」のワークフローパターンを知っている。

インストールすべきとき: Jira / Confluence を会社の SoR(Source of Record)として使うすべてのチーム。

9-2. Figma

何をするか: デザインファイルからコンポーネント・スタイル・assets 抽出、デザイン-開発ハンドオフ仕様自動生成、デザイントークンをコードトークンに変換。

よく合う組み合わせ: Storybook 統合、design system スキル。

インストールすべきとき: フロントエンド・フルスタックチーム、デザインシステム運用チーム。

9-3. Canva

何をするか: デザインアセット生成 — ソーシャルカード、発表スライド、1ページ仕様書。テキスト入力でデザイン。

インストールすべきとき: マーケティングチーム、DevRel。

9-4. Stripe

何をするか: 決済・サブスクリプション・インボイスデータ照会。トランザクション実行はブロック(意図的な安全装置)。「顧客 X の最後の決済失敗理由」のような照会ワークフロー。

インストールすべきとき: Stripe データを頻繁に読む必要のある CS・Finance・Eng on-call。

9-5. Notion

何をするか: ページ・データベース読み書き。スキルは「議事録自動整理」「プロジェクト文書自動インデックス」のようなワークフロー。

よく合う組み合わせ: Granola、Calendar。

インストールすべきとき: 社内 wiki が Notion のチーム。

9-6. Zapier

何をするか: Zapier の数千の統合を Zap トリガーで呼び出し。「Salesforce に新 lead 作成」「Mailchimp に購読者追加」のような動作をスキルとして公開。

なぜ価値があるか: 個別 SaaS スキルを毎回インストールしなくても Zapier 1経由でカバー。ただし応答時間は遅め。

インストールすべきとき: 多様な軽量 SaaS 統合が必要なマーケティング・セールスチーム。

9-7. Slack / Linear / GitHub

生産性のトライアード。ほぼすべてのエンジニアリングチームの基本セット。それぞれのスキルはよく検証されており安定している。

10章 · キュレーション哲学 — コンテキスト予算会計

ここからが本当に難しい話。スキルをインストールするたびに、私たちはコンテキストの一部を支払う。 これは抽象的な話ではない。

10-1. スキルの本当の3つのコスト

メタデータコスト — SKILL.md の description が常にシステムプロンプトに入る。200文字 description × 30個のスキル = 常時 6,000文字。
決定コスト(decision tax) — スキルが多いほどエージェントが「どのスキルを使うか?」判断するのにトークンを使う。応答遅延が増加。
False trigger コスト — 意図しないスキルが発動すれば誤った答えを生成。ユーザーはデバッグ時間で支払う。

10-2. ROI マトリクス — どのスキルが正当化されるか

カテゴリ	使用頻度	タスク価値	コスト正当化?
インシデントトリアージ	低(週1-2回)	非常に高い(分単位の損失)	常時オン
PR サマライザー	非常に高い(毎日)	中	オン
論文サマライザー	中(週5-10回)	高	オン
議事録変換器	中	中	条件付き
メールトリアージ	職種差大	低〜高	職種依存
Stripe スキル	低	高(お金)	CS/Finance のみ

ルールは単純: 「今週1回でも使う?」と聞いて「たぶん使わない」ならオフ。 オンにするスキルは週平均1回以上トリガーされるべき。

10-3. オン vs オフ決定ワークフロー

四半期レトロにスキル監査30分を入れる。 四半期にどのスキルが実際に発動したか確認。
使用0回のスキルはオフ。 「念のため」は良くない理由。
False trigger 頻度が高ければ description を整えるかオフ。
社内スキル > コミュニティスキル > パートナースキル > 公式一般スキル の順で優先(会社特殊性が高いほど優先)。

10-4. アンチパターン5つ

「マーケットプレイス全部インストール」 — スキル30個の環境は常に1個の環境より劣る。
「トレンドに従ってインストール」 — 新しいスキルベータが出たからと無闇に追加するな。1週間試して定量的に評価。
「検証なしでコミュニティスキルを信頼」 — allowed-tools とシェルスクリプトを直接読まないならインストールしないこと。
「description 衝突を無視」 — 2つのスキルの description が似ていれば false trigger が必然。1つだけ残すか、description を明確に区別。
「パートナースキルを社内スキルの代替に使う」 — 自社の PR テンプレートを外部パートナースキルは知らない。会社特殊ワークフローは社内スキルで。

11章 · 役割別スキルバンドル推奨

以上の整理に基づき、役割別の推奨セット。これが最終解ではなく出発点。自分のチームに合わせて調整せよ。

11-1. バックエンドエンジニア(15個以下)

中核: コードレビュー + リリース + 日次ワークフロー。

公式: skill-creator、consolidate-memory
コード: PR サマライザー、conventional commit drafter、security review
リリース: release-notes-from-git-log、semver decider
探索: アーキテクチャマッパー、dead code ファインダー
統合: GitHub、Linear/Jira、Slack
個人: 日次スタンドアップライター

11-2. フロントエンドエンジニア(15個以下)

中核: デザインハンドオフ + コンポーネント検収。

公式: skill-creator
コード: PR サマライザー、conventional commit drafter
デザイン: Figma スキル、design system スキル(社内)、brand voice
コンテンツ: changelog → ソーシャルコピー
統合: GitHub、Linear、Slack、Figma
個人: 日次スタンドアップライター

11-3. SRE / プラットフォームエンジニア(12個以下)

中核: インシデント + ランブック + 自動化。

公式: skill-creator、docx(ポストモーテム自動生成用)
ランブック: インシデントトリアージ、オンコール応答、runbook ガイド、ポストモーテムドラフター
統合: PagerDuty、Sentry、Slack、GitHub、AWS/GCP CLI MCP
コード: PR サマライザー

11-4. プロダクトマネージャー(10個以下)

中核: 会議 + リサーチ + ライティング。

公式: pptx、docx
リサーチ: 論文サマライザー、URL 3つ比較表
コンテンツ: ブログドラフター、ブランドボイス
会議: 議事録 → アクションアイテム抽出器
統合: Linear/Jira、Notion、Slack、Figma(共有読み取り)
個人: 週次レトロライター

11-5. テクニカルライター / DevRel(10個以下)

中核: コンテンツパイプライン。

公式: docx、pptx、pdf
コンテンツ: ブログドラフター、changelog → ソーシャルコピー、ブランドボイス、議事録 → ブログ変換器
リサーチ: 論文サマライザー、URL 3つ比較表
統合: Notion、Canva、Slack、GitHub(release notes)

11-6. 新人 / オンボーディング(5-8個)

中核: 学習 + 探索。最初は小さく始める。

公式: skill-creator(いずれ作る)、docx
探索: アーキテクチャマッパー、依存性監査器
コード: PR サマライザー
統合: GitHub、Slack
個人: 日次スタンドアップライター

12章 · マーケットプレイスの未来 — 2026 下半期予測

最後に簡潔に、2026年5月時点で見える流れ。

スキルの composability が中核価値として浮上。 単一巨大スキルより、小さなスキル同士が呼び合うグラフモデル。
パートナースキルの SLA 化。 無料スキルは自身のコンテキストコストを保証できなければユーザーがオフにする。有料パートナースキルは「false trigger 率1%以下」を保証する形に進化。
社内スキルホスティングサービス。 社内 plugin レジストリが dotfiles 風管理を置き換える。
スキルの audit log。 コンプライアンス領域で「どのスキルがいつどう発動したか」の監査ログ義務化が始まる。SOC 2 影響領域。
スキルキュレーションの職務化。 「AI Skill Curator」が大組織で登場 — 社内スキルカタログ管理、外部スキル検証、四半期スキル監査。

エピローグ — チェックリスト、アンチパターン、次回予告

キュレーションの本質は「足す」ではなく「引く」。スキルをオンにする決定よりオフにする決定の方が難しく、より価値がある。 四半期ごとに30分の監査をスケジュールせよ。

出発チェックリスト

自分の職種に合う11章のバンドル1つを1週間試運用
毎回どのスキルがトリガーされたかメモ(Claude Code には自動ログもある)
1週間後、トリガー0回のスキルはオフ
False trigger が頻発するスキルは description を整えるかオフ
四半期ごとにスキル監査30分をカレンダーに入れる
会社特殊ワークフローは社内スキルで作る(外部代替不可)

アンチパターンの即時想起

「マーケットプレイス全部インストール」— 30個環境は1個より劣る
「トレンドに従う」— 1週間定量評価なしに追加禁止
「検証なしでコミュニティスキル信頼」— allowed-tools とシェルを直接読め
「description 衝突無視」— 類似 description は false trigger の温床
「パートナースキルで社内スキル代替」— 会社特殊性は外部が知らない

次回予告

社内スキルカタログを作る — Git リポジトリ構造と権限モデル
スキルのための評価システム — false trigger 回帰アラート
MCP サーバーとスキルの役割分離 — 何がツールで何がワークフローか
「AI Skill Curator」という新職種 — カタログ管理者の1日

「スキルはタダではない。コンテキストウィンドウという有限資源の一部を支払わなければならない。何をインストールするかを決めるより、何をインストールしないかを決める方が難しく、より価値がある。」

— Claude Skills マーケットプレイス 2026、完。