Anthropic社「knowledge-work-plugins」から読み解く、特化型エージェントの導入・運用・開発

1. 何が起きた

Anthropic社がオープンソースで「anthropics/knowledge-work-plugins」を公開した。ざっくり言えば、Claudeを法務・財務・営業といった特定職種の実務エージェントに仕立てるためのプラグイン集だ。Claude Coworkでの利用が主な想定だが、Claude Code（CLI）でも使える。

カバーしている領域は11個：

1. Productivity（タスク・カレンダー管理）
2. Sales（見込み客調査・パイプライン分析）
3. Customer Support（チケット対応・ナレッジベース構築）
4. Product Management（仕様書作成・ユーザーリサーチ）
5. Marketing（コンテンツ制作・ブランドボイス適用）
6. Legal（契約レビュー・コンプライアンス）
7. Finance（財務諸表分析・勘定照合）
8. Data（SQL生成・統計解析・可視化）
9. Enterprise Search（社内ドキュメント横断検索）
10. Bio-research（前臨床研究・文献調査）
11. Cowork-plugin-management（カスタムプラグイン構築）

何がインパクトだったかというと、SaaS企業の株価が動くレベルの反響があったこと。法務や経理のように「定型的だが専門知識が要る業務」を丸ごとAIエージェントに委ねられる道筋が、具体的なコードとして示された。単に仕事が奪われるという話ではなく、「ベテランの頭の中にある業務ノウハウをMarkdownに書き出してAIに読ませる」という運用モデルが具体的に見えてきたことが本質だと思う。

（参考：「SaaSの死」に3つの疑問　再び株価急落、震源はAnthropicのAI新機能、死ぬSaaS・死なないSaaSの境界線は　アンソロピックショックに震える市場）

2. 実際にLegalプラグインを導入してみた

ここからは、実際にLegal（法務）プラグインをインストールして動かしてみた記録。Cowork（GUI）とClaude Code（CLI）の両方で試した。

Claude Code（CLI）の場合

CLIは2ステップ。まず「マーケットプレイス」を登録してから、プラグインをインストールする。

# マーケットプレイスを追加（デフォルトには入っていない）
claude plugin marketplace add anthropics/knowledge-work-plugins

# プラグインをインストール
claude plugin install legal

ポイントは、legal プラグインはデフォルトの claude-plugins-official とは別のリポジトリにあること。先に marketplace add しないと install で見つからない。ここは最初ちょっと戸惑った。インストール後、Claude Codeを再起動すれば反映される。

Cowork（Desktop/Web）の場合

Coworkのほうが導入自体はシンプルで、claude.com/plugins/legal にアクセスしてインストールボタンを押すだけ。CLIのようなマーケットプレイス登録は不要。

……と思ったら、一発では通らなかった。

プラグインに対する許可設定がOFFになっていたのが原因。設定画面で許可をONにしてリトライしたら通った。

NDAを食わせてみる

インストールしただけでは面白くないので、サンプルのNDA（秘密保持契約書）を用意して /legal:triage-nda コマンドで分析させてみた。

結果は「RED（署名すべきでない）」。除外規定の欠如、従業員への開示規定なし、返還・破棄条項なし、準拠法の未記載——といったリスクを一覧で指摘してきた。具体的な修正文案まで出してくれるので、法務の一次スクリーニングとしては十分実用的に見える。

ただ気になった点もある。同じNDAを何度か食わせてみたが、出力のフォーマットが毎回微妙に変わる。指摘する項目は概ね同じだが、表の形式やセクションの並びが安定しない。実務で使うならこのあたりの出力安定性はカスタマイズで詰める必要がありそうだ（この話は後述するSkillのカスタマイズの章で触れる）。

3. プラグインの中身は「ただのMarkdown」だった

リポジトリを開いて最初に驚いたのは、コードがほぼないこと。プラグインの実体は Command、Skill、Connector の3要素で構成されているのだが、どれもMarkdownかJSONで書かれているだけだ。Legalプラグインのディレクトリ構造を見ると一目瞭然：

legal/
├── .claude-plugin/
│   └── plugin.json           # プラグインの名前・説明（数行のJSON）
├── .mcp.json                 # 外部ツールの接続先URL
├── CONNECTORS.md             # 接続先ツールの一覧
├── commands/                 # スラッシュコマンド（.mdが5つ）
│   ├── review-contract.md
│   ├── triage-nda.md
│   ├── vendor-check.md
│   ├── brief.md
│   └── respond.md
└── skills/                   # ドメイン知識（フォルダごとにSKILL.md）
    ├── contract-review/
    │   └── SKILL.md
    ├── nda-triage/
    │   └── SKILL.md
    └── ...（他4つ）

Command：「何をどの順番でやるか」の手順書

/legal:review-contract のようにスラッシュで呼び出すもの。中身は commands/review-contract.md というMarkdownファイルで、YAMLフロントマターに説明文、本文にワークフローの手順が書いてある。

---
description: 組織の交渉プレイブックに基づいて契約書をレビューする
argument-hint: "<契約書ファイルまたはテキスト>"
---

## ワークフロー

### Step 1: 契約書を受け取る
### Step 2: 背景情報を聞く
### Step 3: プレイブックを読み込む
### Step 4: 条項ごとに分析する
### Step 5: 逸脱箇所をフラグ付けする（GREEN / YELLOW / RED）
### Step 6: 修正案（レッドライン）を生成する
### Step 7: ビジネスインパクトのサマリーを出す
...

要するに「契約書を受け取れ→背景を聞け→プレイブックを読め→条項ごとに分析しろ→……」という段取りがMarkdownで書かれているだけ。Claudeはこれを読んで、手順通りに動く。

注目したいのは Step 3 の「プレイブックを読み込む」。ここにはこう書かれている：

ローカル設定（legal.local.md 等）から組織の契約レビュー用プレイブックを探す。
プレイブックには以下を定義すること：

• 標準ポジション：各主要条項に対する組織の希望条件
• 許容範囲：エスカレーションなしで合意できる範囲
• エスカレーション条件：シニアカウンセルや外部弁護士のレビューが必要な条件

プレイブックが未設定の場合： ユーザーに未設定であることを伝え、(1) プレイブック作成を支援する、(2) 一般的な商慣行の基準でレビューを進める、のいずれかを提示する。

つまりCommandの中に「プレイブックを読め、なければ作るのを手伝え」という指示まで入っている。プレイブック自体のテンプレートは README に掲載されており、.claude/legal.local.md に配置する想定だ。こんな感じ：

# 法務プレイブック設定

## 契約レビューのポジション

### 責任制限（Limitation of Liability）
- 標準ポジション：支払済み/支払予定額の12ヶ月分を上限とする相互キャップ
- 許容範囲：6〜24ヶ月分
- エスカレーション条件：無制限の責任、結果損害の包含

### 補償（Indemnification）
- 標準ポジション：IP侵害とデータ漏洩に対する相互補償
- 許容範囲：第三者請求に限定した補償
- エスカレーション条件：一方的な補償義務、上限なしの補償

### 知的財産
- 標準ポジション：各当事者が既存IPを保持、顧客データは顧客が所有
- エスカレーション条件：広範なIP譲渡条項、既存IPへの職務著作規定

### データ保護
- 標準ポジション：個人データ処理にはDPA（データ処理契約）を要求
- 要件：再委託先の通知、契約終了時のデータ削除、72時間以内の漏洩通知
- エスカレーション条件：DPAの提供なし、保護措置のない国外データ移転
...

（出典：legal/README.md）

このテンプレートを自社の基準に書き換えれば、Claudeがレビュー時にそれを参照して判断するようになる。前章で試したNDAトリアージでも同じ仕組みで、commands/triage-nda.md の Step 2 に「legal.local.md からNDAスクリーニング基準を読め」という指示がある。

Skill：「どう判断するか」の専門知識

Commandが「手順」なら、Skillは「知識」。各スキルのフォルダに入っている SKILL.md には、その分野の判断基準やドメイン知識が書かれている。

たとえば skills/contract-review/SKILL.md の冒頭はこうだ：

あなたは企業法務チームの契約レビューアシスタントです。
組織の交渉プレイブックに基づいて契約書を分析し、
逸脱箇所を特定・重大度分類し、実行可能な修正案を生成します。

このSKILL.md には、たとえば次のような「判断に必要な材料」がまとまっている：

• レビュー手順
  1. 契約種別の特定
  2. 自社の立場の確認
  3. 全文通読
  4. 条項ごとの分析
  5. 全体的なリスク評価
• 逸脱の分類
  • GREEN：許容範囲
  • YELLOW：要交渉
  • RED：要エスカレーション
• 交渉の優先度
  • Tier 1：必須
  • Tier 2：強い希望
  • Tier 3：譲歩候補
• レッドライン作成：修正案（レッドライン）生成のベストプラクティス

CommandがSkillを参照して動くので、手順と知識が分離されている構造だ。

CommandとSkillの使い分けをまとめるとこう：

具体例（プログラミング）

たとえば「バグ修正」をエージェントにやらせたい場合：

• Command（手順）：/fix-bug のようなコマンドを用意して、「再現手順の確認→原因の切り分け→テスト追加→修正→リグレッション確認→変更点の要約」までの順番を固定する
• Skill（知識）：そのリポジトリ固有の「アーキテクチャ」「コーディング規約」「テスト方針」「よくある落とし穴（例：この層からDBを触らない）」などをまとめておき、Commandの各ステップで参照させる

同じCommandでも、Skillを差し替えれば「TypeScript + Next.jsの作法」「Python + FastAPIの作法」みたいに“判断の癖”を入れ替えられる。

具体例（Legal：契約書レビュー）

/legal:review-contract を例にすると：

• Command（手順）：契約書を受け取り、背景情報を聞き、プレイブック有無を確認し、条項ごとに分析し、GREEN/YELLOW/REDで分類し、レッドライン案とサマリーを出す……という「レビューの段取り」を固定する
• Skill（知識）：GREEN/YELLOW/REDの基準、条項別の典型論点、交渉の優先度（Tier 1/2/3）、レッドライン作成のベストプラクティスなど「どう判断するか」を持たせる

プレイブック（legal.local.md）はSkillの一部というより「組織の個別ルール」なので、Skillより優先して適用される“上書きレイヤー”として扱うのがわかりやすい。

Connector：外部ツールとの接続設定

SlackやBox、Jiraなどの外部ツールとの接続を担う。実体はルート直下の .mcp.json で、MCPサーバーのURLが並んでいるだけ。

{
  "mcpServers": {
    "slack": { "type": "http", "url": "https://mcp.slack.com/mcp" },
    "box":   { "type": "http", "url": "https://mcp.box.com" },
    ...
  }
}

面白いのは、CommandやSkillの中では ~~cloud storage や ~~chat のようなプレースホルダーで外部ツールを参照していること（CONNECTORS.md に対応表がある）。「Boxに保存しろ」ではなく「~~cloud storageに保存しろ」と書いてあるので、接続先をEgnyteやSharePointに差し替えてもCommand側の書き換えは不要になっている。

つまり全部「設定ファイル」

ここまで見てわかるように、プラグインにプログラミング言語で書かれたロジックは一切ない。Markdown（手順と知識）+ JSON（メタデータと接続先）だけで、専門エージェントが成立している。「AIエージェント開発」と聞くと身構えるが、やっていることは業務マニュアルとノウハウ集をMarkdownで書いてフォルダに置いているだけ。

4. Legalプラグインのコマンド一覧と、できること

前章でプラグインの構造がわかったところで、Legalプラグインに実際に入っているコマンドを一覧にしておく。

（出典：legal/commands/）

2章で試した /legal:triage-nda はこの中の1つ。どのコマンドも、前章で見た通り「Markdownに書かれた手順」+「SKILL.mdの専門知識」+「プレイブック（legal.local.md）の自社基準」の組み合わせで動く。

5. プレイブックを書き換えてみた

3章で紹介したプレイブック（legal.local.md）を実際にカスタマイズして、結果が変わるか試してみた。

やったこと

.claude/legal.local.md に以下の設定を追加した：

# Legal Playbook Configuration

## Limitation of Liability（責任制限）
- Standard position: capped at $1M
- Yellow (要確認): $1M〜$2M
- Red (エスカレーション): $2M超 または uncapped

Claudeもプレイブックを認識している様子：

プレイブックあり vs なしの違い

2章で最初に試したとき（プレイブック未設定）は、レポートに Review Basis: Default Standards（ローカル設定なし） と表示されていた。プレイブック設定後に同じNDAを再度食わせると、Review Basis: Playbook + Default Standards に変わり、損害賠償のチェック結果にプレイブックの基準が反映された：

Liability Cap | FLAG | $2M（プレイブック: $1M〜$2MはYellow）

プレイブックの基準がちゃんとレビューに反映されていることが確認できた。つまり legal.local.md に自社の判断基準を書くだけで、Claudeのレビュー基準を組織に合わせられる。

出力のブレをどう抑えるか

2章で触れた「出力フォーマットが毎回変わる」問題。これはSKILL.mdに出力テンプレートを追記することで改善できるはず。たとえば「レポートは必ずこの表形式で出力しろ」「セクションの順序はこうしろ」といった制約を書き足せば、出力は安定する方向に向かう。プラグインのカスタマイズは、判断基準だけでなく出力形式の統制にも使えるということだ。

6. Connectorと外部連携の可能性

Legalプラグインの .mcp.json には、以下のツールがデフォルトで接続先として定義されている：

（出典：CONNECTORS.md）

3章で触れた ~~category プレースホルダーのおかげで、CommandやSkill側は特定のツール名に依存していない。たとえばSlackの代わりにTeamsを使いたければ、.mcp.json の接続先URLを差し替えるだけでいい。

カスタムConnectorの追加

デフォルトにないツール（例：Azure DevOps）と連携したい場合は、自前でMCPサーバーを用意して .mcp.json に追加すればいい（Azure DevOps MCPは現在動作確認中）。たとえばこんなワークフローが組める：

1. Azure DevOpsのBoardに「新規契約案件」のチケットが作成される
2. Legalエージェントがチケット内容を読み取り、Boxから関連ファイルを取得してレビュー開始
3. レビュー結果をAzure DevOpsのコメントに自動投稿、ステータスを「法務チェック中」に更新

Connector自体はURLの設定にすぎないので、MCPサーバーさえ用意できれば何でもつなげる。

7. 組織でプラグインを運用するなら

ここまでの話をまとめると、プラグインのカスタマイズは大きく3つ：

1. プレイブック（legal.local.md）：自社の判断基準を定義する
2. SKILL.md：出力フォーマットやドメイン知識を調整する
3. .mcp.json：接続する外部ツールを差し替え・追加する

どれもMarkdownかJSONの編集だけで完結する。ということは、これをGitで管理すればそのまま組織の資産になる。

Gitで管理するメリット

• プレイブックの変更履歴が残る（「いつ、誰が、何の基準を変えたか」が追える）
• SKILL.mdの更新をプルリクエストでレビューできる（業務ルール変更のガバナンス）
• 社内の法務チーム全員が同じプレイブックを使える

プライベートマーケットプレイスという選択肢

CLI版では claude plugin marketplace add でGitHubリポジトリをマーケットプレイスとして登録できる。これを社内のプライベートリポジトリで運用すれば、自社カスタマイズ済みのプラグインを全社員に配布できる。

# 社内リポジトリをマーケットプレイスとして追加
claude plugin marketplace add mycompany/legal-plugins

# 社内カスタマイズ版をインストール
claude plugin install legal

Markdownで書かれた業務ナレッジをGitで版管理して、CLIやCowork経由で社員に配る。プロンプトが個人の手元でバラバラに管理される状態を防げるので、かなり実用的だと思う。

8. このノウハウをSaaSとして提供するなら

ここまで見てきたように、プラグインの実体は「Skill（ドメイン知識）」「Command（ワークフロー手順）」「Playbook（組織固有の基準）」のMarkdownだった。ということは、これらをAPIの裏側に組み込めば、Claude CoworkやClaude Codeを使わなくても同じことをWebサービスとして提供できる。

あえてGemini APIで実装してみることで、このプロンプト設計がClaude以外のLLMでも再現できるのか検証する狙いもある。

プラグインの3要素がAPIのどこにマッピングされるかを整理するとこうなる：

そのまま使えるのか？

ただし、リポジトリの .md ファイルをそのままGemini APIに流し込むと問題がある。Claude Code / Cowork 固有の記述が含まれているからだ。調査したところ、主に以下の5箇所：

一方、サブエージェント呼び出しや ~~category プレースホルダーはcommand/skill本文には含まれていなかった。問題箇所は限定的なので、Python側でパッチを当てれば実ファイルがそのまま使える。

コード例：実ファイル読み込み + 追加プロンプト

「PDFの契約書」と「プレイブック（組織の判断基準）」を受け取り、契約レビュー結果を返すAPI。リポジトリをcloneして legal/ ディレクトリを参照する構成。

from fastapi import FastAPI, UploadFile, Form
from google import genai
from google.genai import types
from pathlib import Path

app = FastAPI()
client = genai.Client()  # GOOGLE_API_KEY 環境変数を参照

PLUGIN_DIR = Path("legal")  # git clone したリポジトリの legal/ を指定

# ── Skill + Command を実ファイルから読み込み ──
SKILL = (PLUGIN_DIR / "skills" / "contract-review" / "SKILL.md").read_text()
COMMAND = (PLUGIN_DIR / "commands" / "review-contract.md").read_text()

# ローカル前提の記述をAPI利用に読み替えるための短い補足
API_ADJUST = (
    "この指示はAPI経由で実行される。ローカルファイル参照・UI手順・MCP/CLM連携の指示は、"
    "システム指示や本メッセージ内の情報で代替すること。"
)


@app.post("/review")
async def review_contract(
    file: UploadFile,
    playbook: str = Form(default=""),
):
    pdf_bytes = await file.read()

    # Skill → system instruction / Playbook → system instructionに追加
    system = SKILL + "\n\n" + API_ADJUST
    if playbook:
        system += (
            "\n\n## 組織のプレイブック（この基準を優先して判定すること）\n"
            + playbook
        )

    # Command + PDF → contents としてまとめてAPIに投げる
    response = client.models.generate_content(
        model="gemini-2.0-flash",
        config=types.GenerateContentConfig(
            system_instruction=system,
        ),
        contents=[
            types.Part.from_bytes(
                data=pdf_bytes,
                mime_type="application/pdf",
            ),
            COMMAND,
        ],
    )

    return {"review": response.text}

動かしてみたところ、以下のようなプラグインを使用したかのような出力結果が得られた。

## NDAトリアージレポート

**分類**: RED (重大な問題)
**当事者**: Acme Corporation および Beta Technologies Inc.
**種類**: 相互秘密保持契約 (Mutual NDA)
**期間**: 契約期間2年、秘密保持義務存続期間3年
**準拠法**: カリフォルニア州法
**審査基準**: デフォルト基準

## スクリーニング結果

| 基準 | ステータス | 詳細 |
|:------------------------------------|:-----------|:---------------------------------------------------------------------------------------------------------------------------------|
| 相互義務 (Mutual Obligations) | PASS | 本NDAは相互秘密保持契約です。 |
| 秘密情報の定義範囲 (Definition Scope) | PASS | 合理的な範囲であり、過度に広範ではありません。 |
| 期間 (Term) | PASS | 契約期間2年、秘密保持義務存続期間3年は標準的な範囲です。 |
| 標準的除外規定 (Standard Carveouts) | PASS | 公知情報、開示前の既知情報、第三者からの適法な入手情報、独立開発情報、法的強制による開示の全てが含まれています。 |
| 許可される開示 (Permitted Disclosures) | PASS | 従業員、契約者、アドバイザーへの開示が認められています。 |
| 返還・破棄 (Return/Destruction) | PASS | 契約終了時または要求時の返還・破棄義務があり、法令遵守またはバックアップ目的でのコピー保持の例外が明示されています。 |
| 残留条項 (Residuals Clause) | PASS | 残留条項はありません。 |
| 従業員勧誘禁止 (Non-Solicitation) | FAIL | 従業員勧誘禁止条項 (第11条) が含まれています。 |
| 競業禁止 (Non-Compete) | PASS | 競業禁止条項はありません。 |
| 差止請求による救済 (Injunctive Relief) | PASS | 損害賠償額の予定条項はなく、差止請求による救済の可能性が記述されています。 |
| 準拠法 (Governing Law) | PASS | カリフォルニア州は商業取引において確立された法域であり、管轄裁判所も一致しています。 |
| 譲渡 (Assignment) | PASS | 相手方の事前の書面による同意なしには譲渡できない、一般的な規定です。 |
| その他の規定 (Unusual Provisions) | FLAG | 従業員勧誘禁止条項はNDAに含めるべきではない条項です。 |

## 発見された問題

### 問題1 -- RED: 従業員勧誘禁止条項 (Non-Solicitation Clause)
**内容**: 第11条に、契約期間中およびその後12ヶ月間、当事者が「本件目的」に関連して接触した相手方の従業員を直接勧誘して雇用することを禁止する条項が含まれています。一般的な求人広告は違反とみなされない旨の記述はあります。
**リスク**: 秘密保持契約は秘密情報の保護を目的とするものであり、従業員勧誘禁止のような競業避止義務に類する条項を含めるべきではありません。このような条項は、将来の採用活動を不必要に制限し、また意図しない法的責任を生じさせる可能性があります。従業員勧誘禁止条項は、通常、秘密保持契約の範囲外の事項と見なされます。
**提案される修正**: 第11条の「NON-SOLICITATION」条項を完全に削除することを推奨します。相手方が強く主張する場合は、対象者を重要な個人に限定し、期間を短縮するよう交渉するか、別途の契約で対処することを提案します。

## 勧告

本NDAは、従業員勧誘禁止条項を含むため、**RED (重大な問題)** に分類されます。標準的な秘密保持契約に含めるべきではない条項が含まれているため、署名すべきではありません。

## 次のステップ

1.  **法務部門への連携**: 本NDAを貴社の法務部門に転送し、詳細なレビューを依頼してください。
2.  **カウンタープロポーザルの準備**: 貴社の標準的な秘密保持契約書を相手方へのカウンタープロポーザルとして用意するか、または本NDAの第11条の削除を交渉する準備をしてください。
3.  **交渉**: 法務部門の指示に従い、問題のある条項の修正または削除について相手方と交渉してください。

Geminiであってもプラグインの内容を多少補正させてあげれば、かなり近しい結果が得られることがわかった。

何をやっているか

処理の流れは3段階：

起動時（ファイル読み込み）：

1. リポジトリの .md ファイルをそのまま読み込む
2. API実行前提の短い補足プロンプト（API_ADJUST）を用意する

リクエスト時（API呼び出し）：
3. SKILL と補足プロンプトをSystem Instructionに設定し、リクエストの Playbook があれば追加
4. COMMAND とPDFをcontentsとしてGemini APIに送信

ポイントは、リポジトリの .md ファイルをそのまま使っていること。ドメイン知識（SKILL.md）やワークフロー手順（command .md）の本体には手を入れず、「ローカル前提の記述はAPI向けに読み替える」という1〜2行の補足だけを追加している。プラグインが更新されたら git pull するだけで最新のノウハウが反映される。

SaaSとして拡張するなら

この最小構成をベースに拡張するとしたら：

• Skill/Commandの切り替え：エンドポイントを /review（契約レビュー）、/triage-nda（NDAトリアージ）のように分け、PLUGIN_DIR から異なる .md ファイルを読み込む
• Playbookの永続化：組織ごとのプレイブックをDBに保存し、APIキーで自動適用
• 出力の安定化：response_mime_type: "application/json" でJSON出力を強制する
• LLMの差し替え：model="gemini-2.0-flash" を変えるだけで別モデルに切り替えられる。.md ファイルはそのまま

ビジネスロジックの大部分がリポジトリの .md ファイルに収まっているので、SaaS化しても機能追加の主な作業は「Markdownを書く（またはAnthropicの更新を取り込む）」ことになる。

まとめ

knowledge-work-pluginsの正体は、Markdownで書かれた業務マニュアルとノウハウ集だった。コードは1行もない。

やっていることを整理すると：

• Command（手順書）で「何をどの順番でやるか」を定義
• Skill（ノウハウ集）で「どう判断するか」の知識を与える
• Connector（接続設定）で外部ツールとつなぐ
• Playbook（legal.local.md）で自社の基準にカスタマイズ

これらを全部Gitで管理すれば、「ベテランの頭の中にある業務ノウハウをMarkdownに書き出して、AIに読ませて、バージョン管理する」という運用モデルが完成する。

AIエージェント開発というと大げさに聞こえるが、実態は「業務を知っている人がMarkdownを書く」ことだった。エンジニアリングの問題というより、業務知識の棚卸しと構造化の問題。そう考えると、これは法務に限らず、どの職種でも同じアプローチで展開できるはずだ。