Claude Codeは、コードを書かせるだけでも強い。しかし、実務で本当に時間を奪うのは、実装そのものだけではない。過去の意思決定を探す、仕様を整理する、SQLを書く、デザインをレビューする、リリース前の確認をする、契約書やPDFを読む、関係者向けの報告を作る。開発者やプロダクトチームの仕事は、コードの外側に大きく広がっている。
そこで使えるのがClaudeの公式プラグインだ。
今回扱うのは、Claude Code CLI専用マーケットプレイスの開発系プラグインではない。画像にあるClaude Desktopの「ディレクトリ → プラグイン → Anthropic」タブから選べる、Anthropic公式の業務別プラグインである。具体的にはEngineering、Product Management、Data、Design、Enterprise Search、PDF Viewerなどだ。
これらは主にClaude DesktopのChatやCowork向けに提供されているが、Anthropicの公式リポジトリではClaude Codeでも動作すると案内されている。同じパッケージをClaude Code側へ導入すれば、スキルやスラッシュコマンド、MCPコネクタを開発ワークフローへ持ち込める。つまり「デスクトップで見つけられる公式プラグインを、Claude Codeでも使う」というのが本記事の前提だ。
2026年7月18日現在、プラグインはPro、Max、Team、Enterpriseの有料プランで利用できる。プラグインにはスキル、コネクタ、サブエージェントなどがまとめられており、インストールしたスキルはWeb版のチャット、Claude DesktopのChat、Coworkで利用できる。一方、フックやサブエージェントはCowork限定のものもあるため、「どこで何が動くか」はプラグインごとに確認したい。
本記事では、単に機能が多いものではなく、開発者、プロダクトマネージャー、デザイナー、技術責任者、個人開発者が実務で繰り返し使えるかを基準に10本を選んだ。
まず知っておきたい導入方法
Claude Desktopでは、左サイドバーの「カスタマイズ」を開き、「プラグイン」タブから「＋」を押してディレクトリを表示する。その後「Anthropic」タブを選び、対象カードの「＋」またはInstallを押せばよい。インストール後は、入力欄で「/」を打つか「＋」メニューを開くと、追加されたスキルやコマンドを確認できる。
Claude Codeで同じプラグインを使う場合は、公式のKnowledge Workマーケットプレイスを追加し、個別にインストールする。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-plugins
engineering の部分を data、design、product-management などへ変えればよい。導入後はスキルが必要な場面で自動的に参照され、明示的なコマンドは /engineering:review や /data:write-query のように名前空間付きで呼び出せる。
なお、プラグインによってはローカルMCPサーバーを起動したり、Google Drive、Slack、GitHub、Figmaなどの外部サービスへ接続したりする。ローカルMCPは通常のプログラムと同等の権限で端末上を動く場合があるため、提供元、要求権限、接続先、書き込みの有無は必ず確認しておきたい。
1. Engineering｜まず入れるべき開発チームの基本セット
最優先で入れたいのがEngineeringだ。対象範囲は、スタンドアップ、コードレビュー、デバッグ、アーキテクチャ判断、インシデント対応、デプロイ前確認、技術ドキュメントまで広い。Claude Codeを単なる実装担当ではなく、開発プロセス全体を支える相棒として使うための土台になる。
用意されている代表的なコマンドは、変更内容をレビューする /engineering:review、再現・切り分け・原因特定・修正を順番に進める /engineering:debug、ADR形式で技術判断を整理する /engineering:architecture、障害対応を支援する /engineering:incident、リリース前の抜け漏れを確認する /engineering:deploy-checklist だ。コードレビューのスキルだけでなく、テスト戦略、技術的負債、システム設計、ドキュメント作成の知識も含まれる。
特に使えるのは、コードを書く前後の工程である。たとえば実装前に「この機能を同期処理にするかキューへ逃がすか」を /engineering:architecture で整理し、実装後に /engineering:review、本番反映前に /engineering:deploy-checklist を回す。障害時には、ログを漫然と眺めさせるのではなく、再現条件、影響範囲、仮説、検証結果、緩和策、恒久対応を時系列で残せる。
最初に試すなら、次の依頼が分かりやすい。
/engineering:review
今回の差分を、正しさ・セキュリティ・性能・保守性の順に確認してください。
重大度が高い問題だけを先に出し、各指摘には根拠と修正案を付けてください。
ただし、レビュー結果をテストやCIの代わりにしてはいけない。Engineeringは判断材料を構造化するプラグインとして強いのであって、ビルド成功、型チェック、実環境の挙動まで保証するものではない。実装、テスト、レビューを一つの流れへ組み込んだときに最大の価値が出る。
2. Product Management｜曖昧なアイデアを実装可能な仕様へ変える
Claude Codeへいきなり「この機能を作って」と投げると、もっともらしい実装は出てくる。しかし、誰のどんな問題を解くのか、何をスコープ外にするのか、成功を何で測るのかが曖昧なままだと、完成後に大きな手戻りが起きる。Product Managementは、この上流工程を補強するプラグインだ。
機能仕様やPRDを書く /product-management:write-spec、ロードマップを更新する /product-management:roadmap-update、経営層や開発チーム向けの進捗報告を作る /product-management:stakeholder-update、インタビューやアンケートをまとめる /product-management:synthesize-research、競合比較を作る /product-management:competitive-brief、指標を点検する /product-management:metrics-review、仮説を深掘りする /product-management:brainstorm が含まれる。RICE、MoSCoW、Jobs-to-be-Done、Opportunity Solution Treeなど、PMでよく使われる考え方もスキルとして組み込まれている。
Claude Codeとの相性がよいのは、「仕様と実装を同じ会話でつなげられる」点だ。まず /product-management:write-spec で問題、対象ユーザー、受け入れ条件、非機能要件、成功指標、未決事項を整理する。その内容をIssueへ落とし、実装タスクへ分解し、最後にEngineeringでレビューする。仕様書が別の場所で眠らず、コード変更の理由まで一貫させやすい。
実務では、完成形を一発で書かせるより、最初に「不明点を質問し、推測した項目は推測と明記すること」と指定するのが重要だ。PMプラグインは文章をきれいにするだけではなく、曖昧さを露出させるために使う。きれいなPRDより、実装前に潰すべき疑問が見えるPRDのほうが価値は高い。
3. Enterprise Search｜Slack、メール、資料に散った過去の判断を探す
チーム開発で最も無駄が大きい作業の一つが、「あの話、どこで決まったっけ」を探す時間だ。仕様はNotion、議論はSlack、承認はメール、作業状況はJira、最終資料はGoogle Driveという状態では、検索だけで集中力が削られる。
Enterprise Searchは、接続したチャット、メール、クラウドストレージ、Wiki、プロジェクト管理、CRM、チケット管理を横断検索し、結果を重複除去しながら一つの回答へまとめる。/enterprise-search:search で質問を投げると、Claudeが質問を検索元ごとのクエリへ分解し、出典を付けて統合する。/enterprise-search:digest --daily や --weekly では、意思決定、アクション項目、自分へのメンションを話題別にまとめられる。
開発者にとっては、過去のADR、障害時の対応、API変更の経緯、特定機能の担当者、顧客からの要望を探す用途が強い。たとえば「認証基盤を自作せず外部IdPへ寄せると決めた理由は何か」「このテーブルのownerは誰か」「決済障害の前回の暫定対応は何だったか」と聞ける。新しく参加したメンバーの立ち上がりにも効く。
弱点は、接続していない場所の情報は見つからないことと、アクセス権の広さがそのまま検索範囲になることだ。まずはSlack、ドキュメント、プロジェクト管理など必要最小限から接続し、個人DMや機密フォルダまで無差別に広げない。回答には必ず元資料を付けさせ、「見つからない」と「存在しない」を区別させると安全に使える。
4. Data｜SQL、可視化、分析の検証まで一気通貫
Dataは、SQL生成だけをするプラグインではない。データ探索、品質確認、統計分析、可視化、HTMLダッシュボード作成、共有前の検証までを一つの分析工程として扱う。
主なコマンドは、質問から分析を進める /data:analyze、データセットの形や欠損、異常値を調べる /data:explore-data、SQLを書く /data:write-query、Pythonでグラフを作る /data:create-viz、対話型HTMLダッシュボードを作る /data:build-dashboard、分析方法や集計ロジックを点検する /data:validate だ。Snowflake、Databricks、BigQueryなどへMCPで接続できるほか、接続なしでもCSVやExcel、貼り付けた集計結果を扱える。
Claude Codeで便利なのは、分析用SQLとプロダクトコードを往復できることだ。たとえば新しいオンボーディングを実装する前に離脱箇所を調べ、リリース後に同じ定義で指標を再計算し、差分を可視化する。バグ調査でも、「特定バージョンのユーザーだけ失敗率が高いか」「データ移行後にNULLが増えていないか」といった仮説をすぐ検証できる。
最も価値が高いコマンドは意外にも /data:validate である。AIはSQLを速く書けても、分母の取り方、重複行、タイムゾーン、サバイバーシップバイアス、テストユーザー混入などで簡単に誤る。分析後に別工程として検証させ、使用テーブル、フィルタ、期間、指標定義、除外条件を明記させるべきだ。本番DBへ接続する場合は、最初は読み取り専用権限に限定したい。
5. Design｜デザインレビューから実装引き継ぎまでをつなぐ
Designは、画像をそれっぽく生成するためのプラグインではない。デザイン批評、デザインシステム管理、UXライティング、アクセシビリティ監査、ユーザー調査の統合、開発者向けハンドオフを扱う、プロダクトデザインの実務セットだ。
/design:critique ではユーザビリティ、視覚的階層、整合性、アクセシビリティの観点からレビューし、/design:design-system ではコンポーネント、トークン、命名、パターンを監査する。/design:handoff は寸法、状態、インタラクション、例外条件まで含む実装仕様を作り、/design:ux-copy はエラー文、空状態、オンボーディングなどのマイクロコピーを支援する。/design:accessibility と /design:research-synthesis も用意されている。
Claude Codeで使うなら、Figmaの見た目をそのままコード化させる前に、Designで仕様の穴を見つける使い方がよい。「hoverはあるがkeyboard focusはどうするか」「読み込み中、空状態、権限不足、通信失敗はどう見せるか」「長い日本語や200％ズームで崩れないか」といった、スクリーンショットだけでは分からない状態を列挙させる。その後、ハンドオフを実装条件としてClaude Codeへ渡す。
アクセシビリティ監査については、WCAG観点の確認を効率化できる一方、実ブラウザ、スクリーンリーダー、キーボード操作、実利用者による検証を置き換えるものではない。Designでレビュー項目を作り、ブラウザテストと人間の確認へつなげるのが正しい使い方だ。
6. PDF Viewer｜PDFを読むだけでなく、見ながら直す
PDF Viewerは、ClaudeがPDFを要約する機能とは役割が違う。ローカルファイルや直接PDF URLをインタラクティブなビューアーで開き、ハイライト、注釈、スタンプ、フォーム入力、署名画像の配置を行い、編集後のPDFを保存するためのプラグインだ。
/pdf-viewer:open で表示し、/pdf-viewer:annotate でページごとに注釈案を確認しながら反映する。/pdf-viewer:fill-form は入力欄を順番に埋め、/pdf-viewer:sign は署名またはイニシャル画像を配置する。ローカルMCPサーバーとして @modelcontextprotocol/server-pdf を npx で動かす構成で、Node.js 18以上が要件とされている。
開発者なら、API仕様書、要件定義書、セキュリティ監査報告、外部ベンダーの提案書、契約書などのレビューに使える。単に「問題点を要約して」ではなく、「変更が必要な箇所へ注釈を置き、質問事項を黄色、ブロッカーを赤相当のラベルで整理する」と頼めば、相手へ返せる成果物になる。
一方、内容を読むだけならClaudeのネイティブPDF読解のほうが速い。PDF Viewerを使うべきなのは、視覚的に確認しながら書き込み、最終ファイルを持ち帰りたいときだ。また、sign が置くのは見た目上の署名画像であり、証明書を使った暗号学的な電子署名ではない。法的効力が必要な契約には専用の電子署名サービスを使う必要がある。
7. Operations｜属人化した作業をSOPとランブックへ変える
Operationsは、事業運営向けに見えるが、開発組織でもかなり使える。ベンダー評価、業務プロセスの文書化、変更管理、キャパシティ計画、経営向けステータス報告、ランブック作成を支援するからだ。
/operations:vendor-review は費用、リスク、契約、更新判断を整理し、/operations:process-doc はフロー、RACI、SOPを作る。/operations:change-request は影響分析、承認経路、ロールバック計画まで含む変更申請を作成し、/operations:capacity-plan は負荷と人員を分析する。/operations:runbook は定常作業を手順、チェックリスト、トラブル対応、エスカレーション先まで含む反復可能な文書へ変える。
Claude Codeとの組み合わせで強いのは、リリースや運用を「コード外の記憶」から解放できることだ。たとえば、データベース移行の手順を変更申請へまとめ、実行前チェック、監視項目、中止条件、ロールバックSQL、担当者、連絡文まで作る。障害対応後にはEngineeringでポストモーテムを作り、Operationsでランブックへ反映する。
注意したいのは、Claudeが書いた手順を一度も試さず正式運用にしないことだ。ランブックはステージング環境で実行し、コマンド、権限、所要時間、戻し方を人間が検証する。Operationsは文書作成を速めるが、現場で動く手順へ仕上げるにはリハーサルが必要である。
8. Marketing｜リリース後の「届ける仕事」までClaude Codeで回す
良い機能を作っても、リリースノート、ブログ、メール、LP、SNS、営業向け説明が弱ければ使われない。Marketingは、開発後に発生するコンテンツ制作とキャンペーン設計をまとめて支援する。
/marketing:draft-content はブログ、SNS、ニュースレター、LP、プレスリリース、事例記事を作り、/marketing:campaign-plan は目標、対象、チャネル、日程、KPIを含む計画を作る。/marketing:brand-review はブランドボイスとの整合性を確認し、/marketing:competitive-brief、/marketing:performance-report、/marketing:seo-audit、/marketing:email-sequence も利用できる。Slack、Canva、Figma、HubSpot、Amplitude、Notion、Ahrefs、Similarweb、Klaviyoなどとの連携が想定されている。
Claude Codeユーザーには、コード差分から発信物を作らせる流れが便利だ。変更された機能、対象ユーザー、既知の制約、移行手順をリポジトリから読み、技術者向けリリースノート、一般ユーザー向け告知、営業向けFAQをそれぞれ作り分ける。内容の源泉が同じなので、チャネルごとの説明が食い違いにくい。
ただし、ブランド設定なしで使うと、無難でAIらしい文章になりやすい。禁止表現、用語表、代表的な過去記事、顧客の呼び方、断定してよい範囲を与え、brand-review を最後に通すと実用度が上がる。性能レポートも、接続したデータの定義が曖昧なら結論を誤るため、KPIの定義と比較期間を固定したい。
9. Legal｜契約レビューを高速化するが、最終判断は人間が持つ
Legalは、社内法務向けの契約レビュー、NDA一次判定、コンプライアンス、法務ブリーフ、定型回答を扱う。特に重要なのは、一般論で契約を読むのではなく、自社の交渉方針やリスク許容度を legal.local.md に設定し、それと照合できる点だ。
/legal:review-contract は条項ごとに自社プレイブックとの差分を見つけ、リスクと修正文案を整理する。/legal:triage-nda はGREEN、YELLOW、REDのように一次分類し、/legal:vendor-check は既存のNDA、MSA、DPA、期限、主要条件を接続先から確認する。/legal:brief と /legal:respond では、案件の要約や定型問い合わせへの回答案を作れる。
開発現場では、SaaS契約、クラウド利用規約、DPA、秘密保持契約、外部委託契約、セキュリティ条項などの事前整理に使える。法務へ丸投げする前に、データ所在地、サブプロセッサー、責任上限、知的財産、解約、監査権などの論点を抜き出し、質問リストを作る用途が現実的だ。
ただし、公式READMEも、これは法律相談ではなく、資格を持つ専門家による確認が必要だと明記している。また、初期のプレイブック例は米国法と米国の商慣行を前提にしているため、日本法や自社方針で使うなら必ず設定を作り直す必要がある。AIの判定を承認フローの最終ゲートにせず、論点抽出と一次整理へ限定するのが安全だ。
10. Small Business｜個人開発者と小規模事業者には最も化ける一本
Small Businessは、特定職種の補助というより、小規模事業の運営をまとめて扱うプラグインだ。15個の基礎スキル、15個の実行ワークフロー、自然言語から適切な処理へ案内するルーターを備えている。「給与を払えるか不安」「売上が落ちた」「顧客から怒りのメールが来た」「価格を上げるべきか」と普通に相談すると、必要なフローへ誘導する設計になっている。
資金繰りと未回収請求を確認する /small-business:plan-payroll、30日先を見る /small-business:month-heads-up、月次締めを進める /small-business:close-month、利益率と価格を比べる /small-business:price-check、営業キャンペーンを組む /small-business:run-campaign、苦情対応を進める /small-business:handle-complaint、週次状況をまとめる /small-business:monday-brief などがある。QuickBooks、PayPal、HubSpot、Canva、Gmail、Microsoft 365、DocuSignなどとの接続が想定され、金銭や顧客へ触れる処理では承認チェックポイントを挟む設計だ。
個人開発者や小規模SaaS運営者にとっては、「開発以外を全部後回しにする問題」を減らせる。Claude Codeで機能を作り、Small Businessで売上、問い合わせ、請求、販促、契約、週次レビューを回す。経営者本人しか状況を把握していない事業ほど、定型ワークフローを持つ効果が大きい。
一方、接続先が多いぶん権限設計は慎重にしたい。最初から会計、決済、CRM、メールをすべて接続するのではなく、読み取り中心の一つか二つから始める。返金、送信、顧客データ更新などは必ずプレビューと承認を要求する。また、財務、税務、法務、人事の専門助言を提供するものではないという公式の注意書きも前提にする必要がある。
目的別に選ぶなら、この組み合わせが強い
一人でプロダクトを作っているなら、Engineering、Product Management、Design、PDF Viewer、Small Businessの組み合わせが扱いやすい。要件を決め、実装し、UIを点検し、外部資料を処理し、事業運営までつなげられる。全部を常時使う必要はなく、開発中はEngineeringとDesign、販売や運営ではSmall Businessというように切り替える。
複数人の開発チームなら、Engineering、Enterprise Search、Data、Operations、Legalが強い。過去の判断を探し、データで仮説を検証し、変更手順を残し、契約やコンプライアンス上の論点を早期に洗い出せる。Product Managementを加えるなら、要件から実装、検証、社内共有まで一つの流れになる。
プロダクトの立ち上げや大きなリリースでは、Product Management、Design、Engineering、Marketingの4本が効く。PRD、デザイン仕様、実装、告知物の順に同じ前提を引き継がせれば、「作ったもの」と「伝えたもの」のずれを減らせる。
公式プラグインを入れるときの4つの注意点
第一に、デスクトップ版でインストールした状態と、Claude Codeの導入手順を混同しないことだ。Desktopではディレクトリから追加し、Claude Codeでは公式マーケットプレイスを登録して対象プラグインをインストールするのが確実である。公式リポジトリは同じプラグインがCoworkとClaude Codeの双方で使えると案内しているが、使えるコネクタや実行環境は同一とは限らない。
第二に、コネクタは「便利な検索先」ではなく権限を持つ外部連携だと考える。読み取りだけで足りる作業に書き込み権限を与えず、会計、決済、メール、契約、個人情報などは特に範囲を絞る。結果を作るだけの処理と、送信・更新・承認を伴う処理を分け、後者には人間の確認を置く。
第三に、プラグインを一度に入れすぎないことだ。スキルやコマンドが増えるほど、どの手順を選ぶかの判断も増え、似た機能が重複しやすい。最初は自分のボトルネックに直接効く2〜3本から始める。たとえば、レビューに時間がかかるならEngineering、仕様が曖昧ならProduct Management、情報探しが多いならEnterprise Searchという選び方でよい。
第四に、プラグインの出力を「完成品」ではなく「検証可能な下書き」として扱うことだ。SQLは実行結果と定義を確認し、デザインはブラウザで試し、ランブックはリハーサルし、契約は専門家が確認する。AIに任せる範囲を広げても、承認責任まで移すことはできない。
結論：最初の3本はEngineering、Product Management、Enterprise Search
Claude DesktopのAnthropicディレクトリから選べる公式プラグインは、単なる追加プロンプト集ではない。職種ごとの知識、再利用可能な手順、外部ツールとの接続を一つのパッケージへまとめ、Claudeを自分たちの仕事の進め方へ寄せる仕組みだ。公式リポジトリ上では、これらをClaude Codeへ導入する方法も提供されている。
最初に3本だけ選ぶなら、Engineering、Product Management、Enterprise Searchをすすめる。Engineeringで実装と運用の質を上げ、Product Managementで作る前の曖昧さを減らし、Enterprise Searchで組織の過去の知識を回収する。この3本だけでも、Claude Codeは「コードを書くAI」から「仕様、実装、判断、共有をつなぐ開発基盤」へかなり近づく。
データを扱う人はData、UI中心ならDesign、文書の受け渡しが多いならPDF Viewer、個人事業や小規模SaaSならSmall Businessを次に足す。重要なのは全部入れることではなく、日常で最も時間を失っている工程へ、役割の合う一本を置くことだ。
