knowledge-work-pluginsのリポジトリを実装者として読み解く

anthropics/knowledge-work-plugins というリポジトリが公開されています。
法務・セールス・データ分析など職種別のプラグインが揃っていて、「とりあえず入れてみた」という方も多いと思います。
ただ、インストールはできたけど中身の構造がよく分からない、自社向けに改変したいけどどこから手をつければいいか分からない、という状態で止まっているケースも少なくないはずです。

そこで、 実装者の目線 でリポジトリを読み解きます。
legal プラグインを1本まるごと部品レベルまで分解して、plugin.json から skills・commands の連携まで把握します。
「プロンプト集と何が違うのか」という問いにも答えながら、自社業務向けにカスタマイズするときの最初の一手が具体的にイメージできるところまで届けます。

knowledge-work-plugins のリポジトリを俯瞰する

トップレベルを見ると、legal・sales・data・cowork-plugin-management といったディレクトリが並んでいます。
それぞれが独立したプラグインで、職種や業務領域ごとに1ディレクトリが割り当てられている構成です。

knowledge-work-plugins/
├── legal/
├── sales/
├── data/
├── marketing/
├── product/
├── engineering/
├── finance/
├── cowork-plugin-management/
└── partner-built/

ここで重要なのは、収録されているプラグインの種類よりも 全プラグインに共通する型 を先に把握することです。
この型さえ読めれば、どのプラグインのコードも同じ地図で読み解けます。

plugin-name/
├── .claude-plugin/
│   └── plugin.json    # マニフェスト
├── .mcp.json          # 外部ツールとの接続設定
├── commands/          # 明示的に呼び出すスラッシュコマンド
└── skills/            # Claudeが自動参照するドメイン知識

この4点セットがすべてのプラグインに共通しています。
plugin.json がマニフェスト、.mcp.json が外部ツールとの接続定義、commands ディレクトリが「呼び出し型」の指示、skills ディレクトリが「常駐型」の知識、という役割分担になっています。

ここで最初に言っておきたいのですが、「全部入れれば強くなる」という発想は捨てたほうがいいです。
skills ディレクトリ配下のファイルはすべてコンテキストウィンドウを消費します。
プラグインを詰め込みすぎると、モデルが使える作業用の余白が圧迫されます。
実務的には 3〜5本に厳選して運用する のが現実解で、自社の業務フローを棚卸しして毎日使うタスクに絞り込む、という判断が先に来ます。

legal プラグインを1本まるごと読み解く

法務向けの legal プラグインを題材に、内部構造を順番に追っていきます。

まず plugin.json です。

{
  "name": "legal",
  "description": "Legal review, contract triage, and compliance support",
  "author": {
    "name": "Anthropic"
  }
}

これが最小限の必須フィールドです。
リポジトリの Issue の情報によると、version・license・displayName・homepage・repository といったフィールドは省略可能で、legal プラグインの実際のマニフェストもこれらを省いた形になっています。
自分でプラグインを書くときも、最初は必須フィールドだけで問題ありません。

次に skills ディレクトリを見ます。
legal プラグインには contract-review・nda-triage・compliance・legal-risk-assessment など6本のスキルが置かれています。
それぞれのスキルフォルダに SKILL.md という名前のファイルが1つ入っている構造です。

skills/
├── contract-review/SKILL.md
├── nda-triage/SKILL.md
├── compliance/SKILL.md
├── canned-responses/SKILL.md
├── legal-risk-assessment/SKILL.md
└── meeting-briefing/SKILL.md

この SKILL.md が 自動発火するコンテキスト注入 として機能する核心部分です。
Claude がそのドメインに関係すると判断したとき、SKILL.md の内容を自動的に参照します。
ユーザーが明示的に呼び出す必要はなく、関連する会話が始まったタイミングで静かに動き出します。

続いて commands ディレクトリを見ます。
legal プラグインには triage-nda・review-contract・vendor-check・brief・respond という5つのコマンドが入っています。
triage-nda を例に取ると、コマンドファイルの中には NDA の判断ロジックが書かれています。
入ってきた NDA を GREEN（標準的な承認）・YELLOW（法務担当者レビュー）・RED（重大な問題あり）の3つに分類する処理が、Markdown でコマンド定義の中に記述されています。
「このコマンドを呼んだときに何をするか」が全部そのファイルの中で完結しているわけです。

skills と commands の違いをひとことで言うと、スキルは「常にそこにいる専門家」で、コマンドは「明示的に依頼する作業」です。
スキルが背景知識を補完し、コマンドが具体的なアウトプットを生成するという 二層構造 になっています。

「プロンプト集」と何が違うのか：構造化の本質

正直なところ、最初にこのリポジトリを見たとき「プロンプトを Markdown に書いただけじゃないか」と思いました。
ただ使い込んでいくうちに、その印象は変わりました。

プロンプト集との本質的な違いは コンテキストの扱い方 にあります。

プロンプト集は個人が引き出しから取り出して貼る運用です。
毎回同じ40行のコンテキストをコピーしてセッションの頭に貼る、というのは多くのエンジニアが経験していると思います。
その作業は地味に面倒で、しかも貼り忘れが起きます。
チームで使うと「誰がどのバージョンのプロンプトを使っているか」が管理しきれなくなります。

プラグインのスキルファイルはそこが違います。
インストールさえしておけば、Claude が関連するタスクを検知したタイミングで自動的にコンテキストを読み込みます。
貼り忘れがなく、チーム全員が同じ知識ベースを持った状態で作業できます。

もう一点、全体が Markdown と JSON で完結しているということも大事です。
特別なビルドステップも、依存パッケージのインストールも不要です。
Git でバージョン管理して、PR でレビューして、チームにマージする、という普通のソフトウェア開発のワークフローがそのまま使えます。
「プロンプトの改善案があったので PR 出しました」が普通に言える状態になります。

複数プラグインの併用も自然にできます。
legal と data を同時にインストールして、契約書のデータを集計するようなユースケースでも、各プラグインのスキルが独立して機能します。

プロンプト集は個人の引き出しです。
プラグインはチームのインフラです。
この違いは、チームの規模や業務の複雑さが増すほど効いてきます。

自社業務向けにカスタマイズする：改変か新規か

自社業務に適用するとき、まず判断するのは「既存プラグインを改変するか、新規に作るか」です。

判断の軸はシンプルで、 既存プラグインのドメインと自社業務の距離感 で決めます。
legal プラグインをベースに社内の契約審査フローに合わせるなら改変一択です。
一方、業務システム開発の要件定義サポートや AI 活用支援のヒアリング整理など、既存プラグインのどれとも重ならない業務には新規追加が向いています。

改変のとっかかりは2箇所です。
.mcp.json を編集して接続先を自社ツールに差し替えること、そして skills ディレクトリ配下のファイルに自社固有の用語・組織構造・業務フローを追記することです。
コードを書かずに Markdown を編集するだけで済むので、改変のハードルは思っているより低いです。

新規プラグインは最小構成から始めるのが安全です。
以下は議事録要約プラグインの構成例です。

meeting-notes/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── meeting-notes/
│       └── SKILL.md
└── README.md

{
  "name": "meeting-notes",
  "description": "Generate structured meeting notes from transcripts",
  "author": {
    "name": "Your Team"
  }
}

スキル1本・コマンドなし・.mcp.json なし、というミニマムな構成です。
仕様書ドラフト生成なら SKILL.md に「このチームが仕様書で使う項目構成と記述スタイル」を書くだけで動き始めます。
顧客対応メモの整理なら、よく出てくる用語や対応フローの判断基準を SKILL.md に落とし込む、というアプローチです。

雛形の生成自体を Claude に任せる手もあります。
cowork-plugin-management プラグインに含まれる /create-cowork-plugin コマンドを使うと、Claude が対話的にプラグインの構造を生成してくれます。
「議事録を構造化して要約するプラグインを作りたい」と伝えるだけで、plugin.json と SKILL.md のドラフトが出てきます。
完成品ではありませんが、ゼロから書くより明らかに早いです。

つまずきやすいポイントと動作確認の進め方

インストールしたのにスキルが動かない、コマンドが見えない、というのは最初によくある詰まり方です。
典型的な原因をまとめておきます。

• 環境の違いを確認する：Cowork（Claude Desktop の Cowork タブ）と Claude Code では導入フローが異なります。Cowork の場合は claude.com/plugins からマーケットプレイスを追加してインストール、Claude Code の場合は CLI でマーケットプレイスを追加してからインストールという手順です。どちらの環境で使うかを先に確定させておくと混乱が減ります。

• インストール後は再起動する：プラグインをインストールした直後は、アプリを再起動しないとスキルやコマンドが反映されないことがあります。「インストールしたはずなのにコマンドが出ない」の大半はこれです。

• plugin.json のパスを確認する：自作プラグインや改変版をローカルから読み込む場合、plugin.json が .claude-plugin/plugin.json という正しいパスに置かれているかを確認してください。ディレクトリ名のタイポやネストの深さのずれで、マニフェストが読まれないことがあります。

• local.md の配置場所に注意する：legal プラグインの場合、legal.local.md というプレイブックファイルを 作業プロジェクトの .claude ディレクトリ下 に置きます。プラグイン本体のディレクトリではなく、自分が作業するプロジェクト側に置くというのが混乱しやすいポイントです。ここには自社の契約方針やリスク許容度など、プラグイン本体に書かないチーム固有の情報を記述します。

動作確認の流れとしては、Cowork のマーケットプレイスから anthropics/knowledge-work-plugins を追加して対象プラグインをインストールし、アプリを再起動します。
スラッシュコマンド一覧に /legal:triage-nda などが表示されていれば成功です。
スキルの自動発火は、対象ドメインの会話を始めることで確認できます。

プラグインの構造はシンプルです。
plugin.json・.mcp.json・skills・commands の4点セットを軸に読んでいけば、どのプラグインも同じ地図で読み解けます。
最初の一歩は、legal や sales など自分の業務に近いプラグインを1本フォークして、skills ファイルに自社の言葉を足してみることです。

株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
knowledge-work-plugins のような仕組みを実務の業務フローに組み込む支援も行っていますので、気になることがあれば お問い合わせ からどうぞ。