Claude Code をはじめとするコーディングエージェントでは、他の人が作った Skills やプラグインを数コマンドで導入できるようになりました。公式マーケットプレイスにはベンダー製のプラグインが並び、GitHub にも個人の Skills 集がたくさん公開されています。
特に企業でAI活用をしたい、という人の中で、大きく分けて「良いものはどんどん入れたほうがいい」という人と、「外部のものは入れず、必要なら自作する」というタイプに分かれます。
今回は、外部Skills・プラグイン積極派/消極派の論点を整理してみました。
Skills やプラグインそのものの説明は割愛します。詳しくは公式ドキュメントを参照してください。
参考：https://platform.claude.com/docs/ja/agents-and-tools/agent-skills/overview
参考：https://code.claude.com/docs/ja/plugins
積極派の意見
モデルの進化に合わせたメンテナンスを任せられる
Skills は、モデルが変わるたびに見直しが必要なものです。一度書いたら終わり、とはいきません。
Anthropic のプロンプトガイドによると、Claude Opus 4.5 / 4.6 は以前のモデルよりシステムプロンプトに敏感です。そのため、呼び出し漏れへの対策として書いた強い言い回しが、逆に呼ばれすぎの原因になります。「CRITICAL: You MUST use this tool when…」のような書き方です。Claude Fable 5 のガイドはさらに直接的です。「以前のモデル向けに作られた Skills は指示が細かすぎることが多く、出力品質を下げることがある」と書かれています。
自作した Skills なら、この見直しは自分たちの仕事です。外部のものなら、作者が新しいモデルに合わせて更新してくれるのを待てばいい。Claude Code では公式マーケットプレイスの自動更新がデフォルトで有効なので、利用者側はほぼ何もしなくて済みます。
参考：https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/claude-prompting-best-practices
参考：https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-fable-5
優れたワークフローを業務に採用できる
プラグインは複数の Skills やサブエージェント、フックをまとめて配れるので、単発のコツではなく「仕事の進め方」を丸ごと持ち込めます。公式マーケットプレイスにも、機能開発の流れをまとめた feature-dev などがあります。
自分たちの業務に合わせて作り込むより、よくできたワークフローに業務のほうを合わせたほうがうまくいく、という場面は多いと思います。業務システムの導入で、パッケージの標準プロセスに業務を寄せる（いわゆる Fit to Standard）のと同じ考え方です。カスタマイズを重ねるほど保守が辛くなる、というのはよく聞く話です。
特に、チームにまだ決まったやり方がない領域では、ゼロから設計するより外部のものを試すほうが早いです。合わなかったら外すだけなので、試すコストも小さいです。
参考：https://code.claude.com/docs/ja/plugins/anthropic-marketplaces
モデルが知らない知識を補強できる
モデルがどれだけ賢くなっても、学習データにない情報は知りません。出たばかりのフレームワークの API や、ベンダー製品の最新仕様などです。
Vercel は、学習データにない Next.js 16 の API を使う課題で実験結果を公開しています（今年の年初ぐらいなので若干古い情報）。ドキュメントなしだと53%だった合格率が、ドキュメントの索引を渡すと100%になりました。1つのフレームワークに絞った実験ですが、知らないことは教えれば解ける、という当たり前のことが数字で見える例だと思います。
こういう知識はモデルが進化しても価値が落ちませんし、製品の作り手が自分で出しているものなら、自作するより正確で更新も早いはずです。
参考：https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals
消極派の意見
入れすぎると競合して効果が下がる
これは Anthropic 自身が注意を促しています。企業向けのガイドには「同時にロードする Skills の数を制限すること。各 Skill の名前と説明文はシステムプロンプトの中で注意を奪い合う」とあります。失敗例として、新しい Skill の説明文が広すぎて、既存の Skill の出番を奪うケースも挙がっています。
加えて、プラグインを有効にしている間は、その中の Skills の名前と説明文が毎ターンコンテキストに入ります。一度も使わないセッションでも同じです。外部のものは自分たちが使わない機能まで入っていることが多いので、積み重なると「使わない道具の説明書を毎回読ませている」状態になります。
参考：https://platform.claude.com/docs/ja/agents-and-tools/agent-skills/enterprise
参考：https://code.claude.com/docs/ja/plugins
モデルが賢くなり、Skills 自体が過剰な場面が増えた
Anthropic の Skills 作成ガイドは、出発点を「Claude はすでに十分賢い」に置いています。そのうえで、Claude がまだ持っていない情報だけを足すこと、まず Skill なしで試して、失敗したところだけを埋めることを勧めています。
積極派の1つ目の裏返しでもあります。新しいモデルほど以前は必要だった指示が要らなくなり、場合によっては邪魔になります。外部の Skills には、作者が当時のモデルの弱点を補うために書いた指示が混ざっていることがあり、それが今も必要かどうかは外から見ても分かりません。
Claude Code には、プラグインあり・なしでテストして差を出す評価機能もあります。公式ドキュメントには「あり・なしの両方で満点なら、合格したのはプラグインのおかげではない」と書かれています。入れたら良くなった気がする、ではなく、外したときと比べてどうかで判断するのが筋だと思います。
参考：https://platform.claude.com/docs/ja/agents-and-tools/agent-skills/best-practices
参考：https://code.claude.com/docs/ja/plugin-evals
サプライチェーン攻撃のリスクをゼロにできない
公式の見解はかなり慎重です。Agent Skills のドキュメントには「Skills は自分で作ったものか Anthropic から入手したもの、つまり信頼できる出どころのものだけを使うこと」とあります。ソフトウェアのインストールと同じように扱うべき、という立場です。プラグインについても、インストールしたプラグインは自分のユーザー権限で任意のコードを実行できる、と明記されています。
OpenClaw というエージェント向けの公開マーケットプレイスでは、実際に被害が出ています。2026年2月に Koi Security が掲載中の2,857件を調べたところ、341件が悪性でした。Snyk の調査でも、約4,000件のうち76件で悪性のペイロードが確認されました。Claude Code の公式マーケットプレイスでの話ではありませんが、野良の Skills を気軽に入れるのが危ないのは間違いなさそうです。
では人気のものなら安全かというと、相対的には安全でも、ゼロリスクにはできません。
・自動更新が有効だと、レビューした時点のファイルが後から書き換わる
・作者のアカウントが乗っ取られれば、正規の更新として悪性コードが配られる（2025年の npm の Shai-Hulud は、まさにこの手口で数百のパッケージに広がりました）
・Skill 自体が無害でも、外部の Web ページなどを取り込む Skill だと、そこに仕込まれた指示を拾ってしまう
さらに Skills の場合、悪意のある内容がコードではなく自然言語の指示として書かれることが多いです。Snyk の調査では、確認された悪性 Skill の91%がプロンプトインジェクションを使っていました。従来のウイルススキャンの感覚では見つけにくい、というのも厄介なところです。
参考：https://code.claude.com/docs/ja/plugins/security
参考：https://www.koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting
参考：https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/
参考：https://unit42.paloaltonetworks.com/ja/npm-supply-chain-attack/
ブラックボックス化してしまう
外部のワークフローをそのまま使っていると、「なぜこの手順なのか」が分からないまま回ることになりがちです。うまくいかなかったときに、原因がモデルなのか、プラグインの指示なのか、自分たちの使い方なのかを切り分けられません。前提が自社に合っていない箇所があっても気づけないまま、ということもあります。
採用してみてから業務プロセスを見直すという方法も取れますが、浸透する頃には理解度もある程度は必要になりそうです。
放置されたときに業務へのリスクが発生する
「メンテナンスを任せられる」は、作者が更新を続けてくれる前提の話です。個人が公開しているものだと、作者の関心が移れば更新は止まりますし、止まったことは利用者側からは見えにくいです。
便利なツールの1つとして使っている分には、更新が止まっても外せば済みます。ただ、業務の流れそのものをそのプラグインに預けていると、放置されたときに困ります。新しいモデルで挙動がおかしくなっても直してもらえず、かといって中身を理解していないので自分たちでも直せない。ブラックボックス化と組み合わさると、ここが一番の痛手になりそうです。
どう付き合うか
両方の意見を並べてみると、外部と自作のどちらにするかを一括で決めるのは無理があり、何らかの落としどころを設定するのが良いと思いました。（特に企業の場合、全て自由にも、全面禁止にもしにくいため）以下は例です。
・製品やパッケージの公式が出している知識系のものは、積極的に使う
・社内固有の規約や業務知識は自作する
・フックや MCP サーバーを含むプラグインは、自分の権限でコードが動くので、入れる前に中身を見る（公式ドキュメントにレビュー手順がある）
・個人作のワークフローは、意図を読んだうえで自分たちのリポジトリに取り込み、手元で管理する。更新は差分を見てから取り込む
・入れっぱなしにしない。モデルが新しくなったら、外して比べてみる。使っていないものは外す（Claude Code には /skill-doctor など、使われていない Skills を洗い出す機能を利用）
組織としてルールを敷くなら、Claude Code の管理設定でマーケットプレイスの許可リストを作り、公式と自社のものだけに絞る、といった制御もできるようです。
参考：https://code.claude.com/docs/ja/plugins/security
参考：https://code.claude.com/docs/ja/plugins/measure
参考：https://code.claude.com/docs/ja/plugins/org
おわりに
他にも論点がありそうですが、大まかにまとめてみました。コンテキストの重要性や、プラグインのようなツール群の認知度が上がっている中、企業としてはそれらの管理も課題になりそうです。
