Anthropic が公開した「職種別 Claude」テンプレ集 ─ knowledge-work-plugins を読み解く

2026 年、Anthropic が anthropics/knowledge-work-plugins という OSS リポジトリを公開した。営業・法務・データ・エンジニアリング・人事…と、職務ごとに Claude を専門家化するための「プラグイン」が 19 種類、それに加えてパートナー企業の手によるプラグインが 5 種類、リファレンス実装としてそろっている。Apache 2.0 ライセンス。これは新製品の発表というより、「ナレッジワーク向け AI エージェントは、どう構造化されるべきか」という Anthropic 自身の解答書として読むと面白い。本稿ではその中身と設計判断を紹介する。

1. どんなプラグインが入っているのか

リポジトリの README に名前が並ぶのは 11 個だが、実体ディレクトリには次のものがある。

• 横断系: productivity(タスク・カレンダー・メモ管理), enterprise-search(社内全ツールを横断検索), cowork-plugin-management(プラグインを作るためのプラグイン)
• 対顧客系: sales(見込み客調査・コール準備・パイプライン管理), customer-support(チケット triage・KB 化), marketing(ブランドレビュー・キャンペーン計画)
• 専門系: product-management, engineering, design, data, legal, finance, human-resources, operations
• 特殊系: bio-research(preclinical R&D、PubMed・bioRxiv・ChEMBL 接続), small-business(個人事業主・小規模事業者向けに 31 スキルを 1 つのルータが捌く), pdf-viewer(PDF をライブ操作)
• パートナー製: apollo, common-room, slack, zoom, brand-voice(Tribe AI 製)

それぞれのプラグインは、その役割に必要な「スキル(知識・手順書)」と「外部ツール接続(MCP)」がセットで入っている。たとえば legal プラグインは契約レビュー、NDA triage、コンプライアンス相談、文書ベンダー照会など 9 個のスキルを持ち、Box・Egnyte・DocuSign・Atlassian・Slack の MCP がつながる。

2. 構造はとてもシンプル

各プラグインは、たった 4 種類のファイルでできている。

plugin-name/
├── .claude-plugin/plugin.json   # 4 フィールドだけのマニフェスト
├── .mcp.json                    # 外部ツール接続
├── CONNECTORS.md                # ツール抽象化レイヤ
└── skills/<name>/SKILL.md       # 知識・手順書

plugin.json には name / version / description / author の 4 行しか書いていない。スキル群は skills/<name>/SKILL.md の存在で自動検出される。コードもビルドも要らない、Markdown と JSON だけで完結する。

スキル本体の SKILL.md には、冒頭の YAML frontmatter で「いつ発火するか」のトリガー語句を並べ、本文に手順・出力テンプレート・チェックリストをすべて書き下す。1 ファイル 4〜13KB が標準で、サブファイルに分割しない「フラット」流派が多い。

3. 設計上、特に面白い 5 つのポイント

3.1 ツール名を伏字にする「~~placeholder」抽象

スキル本文には具体的なツール名を書かない。代わりに ~~project tracker や ~~knowledge base といった二重チルダのプレースホルダで書く。各プラグイン直下の CONNECTORS.md が「~~project tracker = Jira」のようなマッピング表を持ち、組織ごとにここを書き換える。

これで同じスキル本文が、Asana を使う会社でも Jira を使う会社でも Linear を使う会社でも動く。プラグインを fork して書き換えるのではなく、設定だけで現地調整できる。プラグイン市場が増えても、内部のスキルを「ツール非依存の知識」として書く規律が生まれる。

3.2 プラグインを作るためのプラグイン

cowork-plugin-management は、新しいプラグインをゼロから作ったり、既存プラグインを社内向けにカスタムしたりするメタプラグイン。5 フェーズの会話で進む。

• Phase 1 (Discovery) で「何を作るか/誰が使うか/参考プラグインは何か」を 4 問だけ尋ね
• Phase 2 で | Component | Count | Purpose | の表を提示して合意
• Phase 3 で詳細を詰め
• Phase 4 で全ファイルを生成
• Phase 5 で .plugin ファイル(ディレクトリを zip して拡張子を変えたもの)にパッケージ

カスタマイズ版(cowork-plugin-customizer)が秀逸で、Phase 1 で社内の Slack や Notion を勝手に読みに行って、ツール名・workspace ID・チーム用語を吸い上げ、後の質問を最小化する。「組織別に AI を現地調整する」工程そのものをスキル化している。これは「fork して書き換える」から「対話して埋める」への発想の転換。

3.3 出力テンプレートをスキル内に同梱

スキル本文に、Markdown の出力雛形を丸ごと書き込むのが定石になっている。例:

• legal/review-contract は Redline の 6 フィールド固定(Clause / Current / Proposed / Rationale / Priority / Fallback)
• product-management/write-spec は PRD の 9 セクション固定(Problem / Goals / Non-Goals / User Stories / Reqs(P0/P1/P2) / Success Metrics(leading vs lagging) / Open Questions / Timeline)
• legal/triage-nda は GREEN / YELLOW / RED 判定を AND / OR 条件で機械的に決める 10 章チェックリスト

「成果物の型を先に見せる」ことで、出力のブレを抑える設計判断。ナレッジワークの自動化で一番難しいのは「上司が読んで違和感がない形式」を毎回守ることだが、それをスキル本文で強制している。

3.4 ハブ & スポーク

スキル数が増えると start スキルがルーティング表になる。small-business プラグインは 31 スキルを持つが、それを smb-router(窓口)と smb-onboard(初回セットアップ)の 2 つが捌く。zoom-plugin も 30 スキルを start が振り分ける。「最初のひと言で正しいスキルに振る」ためのデファクトパターン。

合わせて、内部スキルを user-invocable: false でユーザーから直接呼べないようにする規約もある。たとえば data プラグインは sql-queries / statistical-analysis / data-visualization の 3 つを「内部ライブラリ」として隠し、analyze や write-query から参照される。スキルを「窓口」と「ライブラリ」に階層化する設計思想。

3.5 CI で marketplace のセキュリティを守る

リポジトリの .github/workflows/ には、外部プラグインをマージする前に Claude 自身がポリシーレビューをかける scan-plugins.yml がある。.github/policy/prompt.md が判定基準で、ここがとても具体的:

• ungated な PreToolUse/PostToolUse フックは broad-scope 違反として fail
• 未開示の telemetry は fail
• ANTHROPIC_AUTH_TOKEN を非 Anthropic サーバへ送るようなクロスサービスでのクレデンシャル持ち出しは fail
• 観点は「悪意の有無」ではなく「ユーザーのデータを責任もって扱っているか」

判定結果は (plugin, sha) でキャッシュされ、ポリシーが変わると全件 invalidate。外部パートナーの SHA は別ワークフロー(bump-plugin-shas.yml)が毎日 07:23 UTC に追従し、エントリごとに個別 PR を作る。1 つの失敗が他をブロックしない設計になっている。これは「プラグイン市場のセキュリティ規範の最良の公開例」と言ってよい。

4. MCP 接続のパターン

.mcp.json を眺めると、外部ツールへの繋ぎ方にいくつかの定型がある。

Amplitude の US / EU 2 エンドポイント併記(GDPR リージョン分離)など現実解も入っている。HTTP リモート MCP オンリーが基本で、stdio による local プロセス起動は例外という規律も読み取れる。

5. 使い方

Claude Code から使う場合は次の 2 行で済む。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install sales@knowledge-work-plugins

インストールすると、スキルが状況に応じて自動発火する。明示的に呼びたい場合は /sales:call-prep や /data:write-query のようにスラッシュコマンドで起動できる。

Cowork(Anthropic の GUI 製品)からは claude.com/plugins で直接インストール可能。Cowork と Claude Code の両方で同じプラグインが動くのがこのリポジトリの設計目標になっている。

6. 「マニフェスト」として読む

技術的には、このリポジトリは「ナレッジワーク向け AI を構築する公式アーキテクチャの提案」だと読める。Anthropic が考える「将来の AI 利用組織の標準形」は、おおむね次の四つ組になっている。

1. 職能別に専門化された Claude (Plugin = 部署単位)
2. ツール非依存の知識記述 (~~placeholder + CONNECTORS.md)
3. 組織別の対話的カスタマイズ (メタプラグインが社内 MCP を先読みして現地調整)
4. CI で守られる marketplace (LLM ベースのポリシースキャンと SHA pin)

19 個のプラグインそのものより、この四つ組をリファレンス実装として一気に公開したことが、このリポジトリのいちばんの面白さだ。AI エージェントを業務に入れる側の人は、自社で同じ構造を組むときに、ここを設計の起点にして損はない。

7. まとめ

• リポジトリ: github.com/anthropics/knowledge-work-plugins
• ライセンス: Apache 2.0
• 中身: Markdown と JSON だけで書かれた 19 + 5 個の職務別 Claude
• 核: SKILL.md(知識) + .mcp.json(接続) + CONNECTORS.md(抽象化) + plugin.json(マニフェスト)
• 学び: ツール抽象化レイヤ、メタプラグイン、出力テンプレート同梱、ハブ&スポーク、LLM ベースのポリシースキャン

「職種別の手順書を Markdown でフラットに書いて、ツール名は伏字にして、組織別の置換は別ファイルに切り出す」── このシンプルな分離が、結局のところいちばん長く保つ。そんな当たり前の答えを、Anthropic が公式に出してくれた。