投稿者 投稿日: カテゴリー Claude
Claude Codeのプラグインとは、スキルやフック、MCPを1つにまとめた配布単位のことです。
Claude Codeのプラグインというと、便利なコマンドを1つ足す拡張機能のように受け取られがちです。しかし公式ドキュメントを読み込むと、プラグインの本質は「業務の手順書（スキル）、自動チェック（フック）、社内データへの接続（MCP）を1つの箱に詰め、チーム全員に同じ形で配る仕組み」だと分かります。EC事業者にとっては、ベテラン担当者の頭の中にある商品登録や問い合わせ対応のやり方を、新人にもそのまま渡せる道具になります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、プラグインの仕組み、EC業務で効く場面、社内標準パッケージを作る手順とプロンプト5本、配布時の安全面の注意までをまとめます。自社のAI活用が「人によってやり方がバラバラ」という段階にあるなら、来週から何を箱に詰めるべきかが見えてくるはずです。
プラグインとスキル単体は何が違うのか
プラグインとスキル単体の違いは、「1つずつ置くか、まとめて配るか」にあります。Claude Codeの公式ドキュメントは、プラグインを「スキル、エージェント、フック、MCPサーバーなどのコンポーネントを、Claude Codeが1つの単位としてインストールし読み込むディレクトリ」と定義しています。スキルやフックはプラグインなしでも単独で使えますが、複数をまとめてチームに配りたいとき、複数のプロジェクトに入れたいとき、版を管理して更新を届けたいときにプラグインを使う、という位置づけです。
中身として入れられるのは、主に5種類です。関連する場面でClaudeが読み込む業務手順書の「スキル」（SKILL.md）、仕事を任せられる「エージェント」（サブエージェント）、編集のたびなど決まったタイミングで自動実行される「フック」、JavaScriptで書いたフックで画面の部品やコマンドも追加できる「フックモジュール」、そして外部のツールやデータにつなぐ「MCPサーバー」です。プラグインの名前や版は、.claude-plugin/plugin.jsonというマニフェスト（設定ファイル）に書きます。
配布の仕組みは「マーケットプレイス」です。ドキュメントによると、マーケットプレイスは.claude-plugin/marketplace.jsonというファイルを置いたリポジトリやフォルダで、どのプラグインをどこから取得するかを並べた目録にすぎません。ホスティングされたストアではないため、社内のGitリポジトリに目録を置けば、それがそのまま社内専用のマーケットプレイスになります。利用者はClaude Codeで/pluginと入力し、目録からプラグインを選んでインストールします。
インストールには3つの範囲（スコープ）があります。自分のすべてのプロジェクトで有効にする「ユーザー」、リポジトリにコミットした.claude/settings.jsonを通じてそのリポジトリで作業する全員に有効にする「プロジェクト」、自分だけそのリポジトリで有効にする「ローカル」です。社内標準として配るなら、プロジェクトの範囲で有効にしておくのが基本になります。ただしプロジェクトの範囲でも、各メンバーが自分のパソコンにインストールする手順は必要です。
組織向けの統制も用意されています。管理用の設定（マネージド設定）を使えば、組織として許可するマーケットプレイスの指定や禁止、特定のプラグインの強制インストールができます。同じ形式のプラグインは、claude.aiのチャットやCoworkにもインストールでき、そこでは読み込まれるコンポーネントの範囲が異なると説明されています。
EC業務で「パッケージ化」すると効く場面
パッケージ化が最も効くのは、「手順は決まっているのに、担当者によって品質がばらつく業務」です。プラグインは手順書とチェックと接続先をセットで配れるため、誰が作業しても同じ品質に近づけられます。
1つ目の場面は、モールの商品登録です。たとえば楽天市場の商品登録を想定すると、商品名は半角255文字（全角換算127文字）以内、キャッチコピーは半角174文字以内、スマートフォン用商品説明文は半角2,560文字以内という上限があります。商品名の付け方や禁止表現のルールを「スキル」に書き、CSVを保存するたびに文字数と禁止表現を検査する「フック」を付け、在庫や商品マスタを参照する「MCPサーバー」をつなげば、楽天の商品登録パッケージが1つ完成します。新しく入った担当者は、プラグインを入れるだけで、ベテランと同じ手順とチェックで作業を始められます。
2つ目は、問い合わせ対応です。返品や交換、配送遅延といった問い合わせごとの返信方針をスキルにまとめ、返信文に個人情報や不適切な表現が残っていないかをフックで確認します。現場で繰り返し見るのは、返信テンプレートが担当者ごとに微妙に違い、言い回しの差がクレームのきっかけになるケースです。手順書を1つのパッケージで配れば、こうしたばらつきは目に見えて減ります。
3つ目は、モール横断の運用です。楽天市場とAmazonの両方を回している店舗で観測されたのは、同じ商品でもモールごとに担当者が分かれ、商品情報の更新漏れが起きやすいという構造でした。うるチカラでも取り上げたAmazon Selling Partnerのプラグインのように、外部の公式プラグインと自社のスキルを組み合わせれば、モールごとの作業を同じ画面と同じ手順書で回す土台が作れます。
4つ目は、新人の受け入れです。業務マニュアルを読ませてから実務に入る従来のやり方では、マニュアルと実際の作業のずれが必ず生まれます。プラグインに入れたスキルは、作業の場面でClaudeが参照する生きた手順書になるため、マニュアルが更新されれば翌日から全員の作業に反映されます。
反対に、パッケージ化に向かない業務もあります。判断が毎回異なる企画業務や、担当者が1人しかいない業務です。配る相手がいない、あるいは手順を書けない業務をプラグインにしても、管理の手間が増えるだけになります。
社内標準パッケージを作る手順とプロンプト5本
作り方は、「業務の棚卸し」「スキル化」「フックで機械的なチェック」「接続先の整理」「目録の作成と配布」の5段階です。以下のプロンプトはClaude Codeで使う想定ですが、下書きづくりにはChatGPTやGeminiでも使えます。
最初に、パッケージ化する業務を選び、その手順をスキルの形に書き起こします。ベテラン担当者に作業手順を話してもらい、そのメモを材料にするのが早道です。
プロンプト1：業務手順をスキル（SKILL.md）の下書きにする
以下は当店のベテラン担当者が説明した「{業務名}」の作業手順メモです。
これを、Claude Codeのスキル（SKILL.md）の下書きにしてください。
条件：
1. 冒頭に、どんな依頼のときにこのスキルを使うかを1〜2文で書く
2. 手順は番号付きで、1手順1操作にする
3. 判断が必要な箇所は「条件→対応」の形で書く
4. 守るべきルール（文字数上限、禁止表現、モールの規約）を別の見出しにまとめる
5. 担当者のメモに書かれていないことは推測で足さず、「要確認」と記す
作業手順メモ：{メモを貼る}
2つ目に、人の目に頼っていたチェックのうち、機械的に判定できるものをフックに切り出します。文字数や禁止表現のように、正解がはっきりしているものが対象です。
プロンプト2：フックで自動化するチェック項目の設計
以下は「{業務名}」で担当者が目視で確認している項目の一覧です。
各項目について、次の3つのどれに当たるかを判定してください。
A. フックで機械的に判定できる（文字数、禁止語、必須項目の有無など）
B. AIに判定させ、人が最終確認する
C. 人が判断すべき
Aに当たる項目は、判定の条件（例：商品名が半角255文字を超えたら警告）と、警告文の文面も示してください。
確認項目：{一覧}
3つ目に、パッケージの構成を決めます。どのスキル、フック、接続先を1つのプラグインに入れ、どれを分けるかを整理します。
プロンプト3：プラグインの構成案
以下の部品を、社内向けのClaude Codeプラグインとしてまとめる構成案を作ってください。
部品：{スキル名、フックの内容、接続したいデータやツール}
出力：
1. プラグインを何個に分けるか（業務単位かモール単位か）と、その理由
2. 各プラグインの名前、説明文（1文）、含める部品
3. プロジェクトの範囲で全員に有効にするもの、希望者だけが入れるもの
4. 版を上げるタイミングのルール（手順書の変更、チェック条件の変更など）
4つ目に、外部のプラグインを導入する前の点検です。ドキュメントは、プラグインが利用者の権限で動くと明記しています。社外のものを入れる前に、中身を確かめる手順を決めておきます。
プロンプト4：外部プラグインの導入前点検
以下のプラグインのファイル一覧と主要ファイルの内容を読み、導入前に確認すべき点を整理してください。
確認観点：
1. フックで実行されるコマンドの内容と、ファイルの削除や外部送信の有無
2. MCPサーバーが接続する先と、扱うデータの範囲
3. 提供元（公式、コミュニティ、第三者のどれか）と更新履歴
4. 常に読み込まれるスキルや説明文の量（毎回の利用量への影響）
最後に「導入してよい」「条件付きで導入」「導入しない」のいずれかと理由を示してください。
プラグインの内容：{ファイル一覧と内容}
5つ目は、配布した後の見直しです。使われていないプラグインは、毎回の利用量を圧迫するだけなので、定期的に棚卸しします。
プロンプト5：社内プラグインの四半期レビュー
以下は社内で配布しているプラグインの一覧と、各メンバーからの利用状況・不満のメモです。
次の3点を整理してください。
1. 使われていない、または重複しているプラグインと、統合・廃止の案
2. 手順書（スキル）の内容が実務とずれている箇所
3. 次の四半期に新しくパッケージ化すべき業務の候補（最大3つ）
プラグイン一覧と利用状況：{一覧とメモ}
最後に、完成したプラグインを社内のGitリポジトリに置き、.claude-plugin/marketplace.jsonで目録を作ります。業務用のリポジトリの.claude/settings.jsonに有効化の設定をコミットすれば、そのリポジトリで作業するメンバー全員に同じパッケージが行き渡ります。
失敗例と回避策
プラグインの社内展開で起きやすい失敗は3つあります。いずれも、配ること自体より、配った後の管理で起きるものです。
1つ目は、プラグインを入れすぎて利用量と文脈を圧迫する失敗です。公式ドキュメントによると、有効なプラグインは使っていない場面でもすべてのセッションに含まれ、Claudeが自分で呼び出せるスキルやエージェントの名前と説明は、毎回の文脈に入ります。その分の利用量が発生し、作業に使える文脈の余裕も減ります。回避策は、全員に必須のものだけをプロジェクトの範囲で有効にし、それ以外は希望者が入れる形にすることです。/pluginの「Installed」タブには最近使われていないプラグインがまとめて表示されるため、四半期ごとにプロンプト5で棚卸ししてください。
2つ目は、外部のプラグインを中身を確かめずに入れる失敗です。プラグインは利用者の権限で動くため、悪意のあるフックが入っていれば、ファイルの削除や情報の外部送信も起こりえます。2026年10月には、Claude Codeの拡張機能を装った偽物が約11時間公開されていた事例もありました（詳しくは偽Claude Code拡張の記事を参照）。マネージド設定で許可するマーケットプレイスを限定し、プロンプト4の点検を通したものだけを入れる運用にしてください。
3つ目は、フックの条件を厳しくしすぎて現場の作業を止める失敗です。たとえば商品説明文の禁止表現チェックで、文脈を考えずに単語だけで警告を出すと、問題のない表現まで止まり、担当者がフックを無効にしてしまいます。ある化粧品ジャンルの店舗で試したケースでは、最初は警告だけを出して記録を取り、誤検知が少ないことを確かめてから作業を止める設定に切り替えたことで、現場の納得を得られました。
KPI設計と費用・工数の目安
KPIは、「プラグインを入れた人数」ではなく「作業の品質のばらつき」と「新人が独り立ちするまでの期間」で見るのが効果的です。パッケージ化の目的は、作業の標準化だからです。
品質のばらつきは、フックが出した警告の件数で測れます。導入直後は警告が多く、手順書が浸透するにつれて減っていくのが健全な推移です。商品登録なら、モールの審査で差し戻された件数や、公開後に修正した商品ページの件数も合わせて記録すると、効果が見えやすくなります。新人の独り立ちは、プラグイン導入前後で、1人で商品登録を任せられるまでの日数を比べます。5,000社支援の中で何度も再現したパターンとして、手順書が作業の場面で参照できる状態になると、独り立ちまでの期間はおおむね半分前後に縮む傾向があります（業務の難しさで変わる目安です）。
費用面では、プラグインの仕組み自体に追加料金はかかりませんが、Claude Codeを使うためのClaudeの有料プランが必要です。個人向けのProプランは月額20米ドル前後、より多く使うMaxプランやチーム向けのプランもあります（2026年11月時点の価格と条件は公式で要確認）。前述のとおり、有効なプラグインが増えるほど毎回の利用量も増えるため、プラグインの数そのものがコストに影響する点は意識しておくべきです。
工数の目安は、最初の1パッケージを作るまでに2〜4週間です。内訳は、ベテラン担当者への聞き取りとスキルの下書きに1週間、フックの条件づくりと試験運用に1〜2週間、配布と説明に数日といったところです。2つ目以降のパッケージは、最初の型を流用できるため、半分程度の期間で作れることが多いと見ています。
今後の展望と独自考察
今後の大きな流れは、AIの各社が「業務パッケージ」の形式をそろえ始めていることです。ChatGPTではカスタムGPTがプラグインへ移行する方針が示され、GeminiではGemsがスキルへ自動移行すると発表されました。うるチカラでもChatGPTのカスタムGPT廃止とプラグイン移行やGemini Gemsのスキル移行を取り上げてきました。AIへの指示を、会話のたびに書くものから、パッケージとして配って管理するものへと変える動きが、ベンダーを問わず進んでいます。
EC事業者にとっての意味は、「手順書を資産として持つ」ことの価値が上がる点です。スキルに書いた業務手順は、Claude Codeだけでなく、claude.aiやCoworkでも同じ形式で使えます。さらに、スキルという考え方自体が各社に広がっていることを踏まえると、手順書をきちんと書いておけば、使うAIを乗り換えても中身は持ち運べる可能性が高いと判断します。逆に、手順が担当者の頭の中にしかない店舗は、どのAIを選んでも効果を出しにくいままです。
品質管理の仕組みも整いつつあります。公式ドキュメントには、プラグインを評価用の試験（evals）で検証する方法や、プラグインごとの利用量と使用状況を測る方法が用意されています。社内で配るパッケージも、手順書を書き換えるたびに「同じ依頼に対して期待どおりの作業をするか」を試験で確かめる運用にしておけば、更新のたびに品質が落ちる事故を防げます。たとえば商品名の作成スキルなら、過去に人が作った良い例と悪い例を10件ずつ用意し、改訂後のスキルで同じ商品情報から商品名を作らせて、ルール違反が出ないかを確認するだけでも十分な歯止めになります。手順書を「書いて終わり」にせず、試験と計測で育てていく発想が、プラグインを業務資産として長く使うための条件です。
もう1つの論点は、安全面の統制です。プラグインはフックやMCPサーバーを通じて、パソコン上でコマンドを実行したり、外部のシステムにつないだりできます。便利さと危険は表裏一体であり、組織として許可するマーケットプレイスを決め、社内で点検したものだけを配る体制は、プラグインを本格的に使う前に整えておくべきです。
よくある質問
Claude Codeのプラグインとは何ですか？
Claude Codeのプラグインとは、スキル、エージェント、フック、MCPサーバーなどを1つにまとめ、Claude Codeが1単位でインストールして読み込むディレクトリのことです。名前や版は.claude-plugin/plugin.jsonに書きます。複数の部品をまとめてチームに配りたいときに使います。
スキルだけ使う場合と何が違いますか？
違いは、まとめて配り、版を管理できるかどうかです。スキルは単独でも使えますが、プラグインにすると、フックやMCPサーバーとセットでチーム全員に同じ形で配れます。マーケットプレイスを通じて更新も届けられます。
社内だけでプラグインを配ることはできますか？
はい、できます。マーケットプレイスは.claude-plugin/marketplace.jsonを置いたリポジトリにすぎないため、社内のGitリポジトリに目録を置けば社内専用の配布元になります。業務用リポジトリの設定ファイルで有効化すれば、そこで作業するメンバー全員に行き渡ります。
外部のプラグインを入れても安全ですか？
いいえ、中身を確かめずに入れるのは危険です。プラグインは利用者の権限で動くため、フックやMCPサーバーの中身によっては、ファイルの削除や情報の外部送信も起こりえます。提供元を確認し、導入前に中身を点検し、組織として許可するマーケットプレイスを限定してください。
プラグインを入れすぎると何か問題がありますか？
はい、利用量と文脈を圧迫します。有効なプラグインは使っていない場面でもすべてのセッションに含まれ、スキルやエージェントの名前と説明が毎回の文脈に入ります。必須のものだけを全員に有効にし、使われていないものは定期的に無効にしてください。
プログラミングの知識がなくても作れますか？
スキルの作成だけなら、プログラミングの知識はほとんど不要です。SKILL.mdは文章で書く業務手順書だからです。一方、フックやMCPサーバーにはコマンドや設定の知識が必要になるため、社内の技術担当か外部の支援と組んで作るのが現実的です。
まとめ
Claude Codeのプラグインは、スキル、フック、MCPサーバーなどを1つにまとめて配る「業務パッケージ」の仕組みです。社内のGitリポジトリに目録を置けば社内専用の配布元になり、プロジェクトの設定で有効にすれば、作業するメンバー全員に同じ手順とチェックが行き渡ります。商品登録や問い合わせ対応のように、手順が決まっているのに担当者で品質がばらつく業務ほど効果が出ます。
最初の一歩は、ベテラン担当者の作業手順を1つ選び、プロンプト1でスキルの下書きにすることです。スキルそのものの書き方はClaude Agent Skillsの作り方の記事、外部の配布元の選び方はAgent Skillsマーケットプレイスの比較記事もあわせて参考にしてください。
参考文献
- Claude Code Docs「Plugins overview」
- Claude Code Docs「Create a plugin」
- Claude Code Docs「Manage plugins for your organization」
- Claude Code Docs「Plugin security and trust」
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
