公式マーケットプレイスでClaude Codeプラグインをインストールする前に監査する

Anthropicの公式Claude Codeプラグインマーケットプレイスは、もはや設定フォルダの奥に埋もれた噂話ではない。公開GitHubリポジトリのanthropics/claude-plugins-officialは、2026年6月17日時点で30,000以上のスターを獲得しており、そのREADMEでは、Anthropic内部のプラグインとサードパーティ製の項目を含む、キュレーションされたディレクトリだと説明されている。同じREADMEには、あなたの姿勢を決めるべき一文もある。「プラグインをインストール、更新、使用する前に、そのプラグインを信頼できることを確認してください」。なぜならAnthropicは、それらのプラグインに含まれるすべてのMCPサーバー、ファイル、その他の同梱依存関係を管理しているわけではないからだ（GitHub）。

この警告は、法務向けの定型文ではない。Claude Codeプラグインは、スラッシュコマンド、スキル、エージェント、フック、MCPサーバー、LSPサーバー、実行ファイル、設定を同梱できる。開発者向けに平たく言えば、プロンプトコンテキストを追加し、ローカルプロセスを起動し、リモートサービスを呼び出し、ライフサイクルイベントでシェルフックを実行し、モデルに新しいツールを公開できるということだ。

持つべき認識は、「エディタテーマをインストールする」ではない。「自分のソースツリーの近くでコードを実行できる依存関係を追加する」だ。

マーケットプレイスのカタログからローカルキャッシュ、そして有効化されたコンポーネントへ向かうClaude Codeプラグインのインストール経路を示すフロー図。不明点を含む

マーケットプレイスは本物だが、「公式」は「盲目的に安全」を意味しない

Anthropicは2025年10月9日にClaude Codeプラグインを発表し、/pluginでインストールできるスラッシュコマンド、エージェント、MCPサーバー、フックの集合だと説明した（Claude blog）。現在のClaude Codeドキュメントでは、公式Anthropicマーケットプレイスであるclaude-plugins-officialはClaude Code起動時に自動で利用可能になり、次のコマンドでプラグインをインストールできるとされている。

/plugin install github@claude-plugins-official

プラグインが見つからない場合、ドキュメントは次のコマンドでマーケットプレイスを更新するよう案内している。

/plugin marketplace update claude-plugins-official

または、次のコマンドで追加する。

/plugin marketplace add anthropics/claude-plugins-official

これが公式の順風満帆ルートだ（Claude Code docs）。便利ではある。だが、運用ポリシーとしては不完全だ。

公式リポジトリのマーケットプレイスファイルは、ローカルのプラグインディレクトリと、コミットSHAで固定された外部ソースが混在している。たとえば、.claude-plugin/marketplace.json内の項目は、GitHubリポジトリ、サブディレクトリ、ref、SHAを参照できる（raw marketplace file）。固定は助けになるが、固定されたコードが何をするのかを調べる必要が消えるわけではない。プラグインはそれでも、サーバーを起動したり、認証情報を求めたり、フックを実行したり、マーケットプレイスのマニフェスト外で挙動が変わるバイナリに依存したりする可能性がある。

コミュニティも同じ点に気づいている。重要なClaude Codeプラグインを尋ねる最近のr/ClaudeAIスレッドでは、ある返信がまずCLAUDE.mdとフックを推奨し、その後でプロジェクト固有のMCPサーバーだけを入れるべきだと述べていた。別の返信は、Claude Codeに「ランダムなコネクタを投げ込む」べきではないと警告していた。トークンを消費し、コンテキスト汚染を引き起こす可能性があるからだ（Reddit）。今の実務上の論点はそこにある。プラグインは強力だが、追加される能力の一つひとつにはコスト面がある。

まずマニフェストを見る。それからリポジトリを読む

最初に監査すべき対象は、プラグインのソースだ。検索結果の断片、ブログからコピーしたコマンド、出所不明のマーケットプレイス集約サイトからインストールしてはいけない。少なくとも、ソースをリポジトリとマニフェストまでたどれるまでは。

公式マーケットプレイスリポジトリでは、次を確認する。

.claude-plugin/marketplace.json内のマーケットプレイス項目
sourceのタイプ、URL、パス、ref、SHA
存在する場合は、プラグインの.claude-plugin/plugin.json
すべての.mcp.json、.lsp.json、hooks/hooks.json、commands/、skills/、agents/、bin/、スクリプト

Anthropicのプラグインリファレンスには、主要コンポーネントのパスが列挙されている。フックはhooks/hooks.jsonに置かれ、MCPサーバーは.mcp.jsonに置ける。実行ファイルはbin/に置けるし、プラグインマニフェストはカスタムのコンポーネント配置場所を指せる（Claude Code plugin reference）。つまり、「plugin.jsonは確認した」だけでは足りない。プラグインはデフォルトの探索パスに依存できるからだ。

手早い手動レビューはこんな感じだ。

git clone https://github.com/OWNER/PLUGIN-REPO /tmp/plugin-audit
cd /tmp/plugin-audit

find . -maxdepth 3 \( \
  -name plugin.json -o \
  -name hooks.json -o \
  -name .mcp.json -o \
  -name .lsp.json -o \
  -path "*/bin/*" -o \
  -path "*/scripts/*" \
\) -print

rg -n "curl|wget|bash|sh -c|chmod|open |xdg-open|osascript|token|api_key|secret|eval|exec|spawn|subprocess"

このrgコマンドは乱暴だが、ここでは乱暴でいい。探しているのは、インストール時の意外な挙動、シェル実行、ブラウザ起動、リモートダウンロード、認証情報の扱い、そして自分のリポジトリやホームディレクトリを書き換えるスクリプトだ。

私のルールはこうだ。プラグインが中核機能のためにシェルスクリプトを必要とするなら、インストール前にそのスクリプト内のすべてのコマンドを理解したい。実行時に別の成果物をダウンロードするなら、その実行時成果物もプラグインの一部として扱う。

MCPサーバーは最も高くつく「便利機能」

MCPは、プラグインの便利さが見えにくいコストへ変わりやすい場所だ。AnthropicのMCPドキュメントによれば、プラグインで定義されたMCPサーバーは、プラグインが有効になると自動的に起動し、プラグインのMCPツールは手動設定されたMCPツールと並んで表示される（Claude Code MCP docs）。同ドキュメントはまた、プラグインMCPサーバーが手動設定サーバーと同じ環境変数を使うとも述べている。これは、あなたのシェルがクラウドトークン、データベースURL、社内サービスの認証情報をexportしている場合に重要だ。

コミュニティの不満は具体的だ。MCPツールのスキーマは、ツールを呼び出す前からコンテキストを食うことがある。r/ClaudeCodeのトークンオーバーヘッドに関するスレッドでは、ユーザーたちが、トークン消費が少ない理由として無効化されたプラグインや重いMCPサーバーがないことを挙げ、あるコメントはMCPツールスキーマを「巨大な隠れコスト」と呼んだ（Reddit）。別のスレッドでは、接続されたMCPサーバーがツールスキーマをコンテキストに登録すると主張するコメントがあり、セッションごとにサーバーを絞ることが推奨されていた（Reddit）。

Reddit上の正確なトークン見積もりは、自分の環境で再現するまでは逸話として扱うべきだ。それでも、根本的な方向性は正しい。冗長なツールを大量に持つ常時稼働サーバーは無料ではない。

コネクタ型プラグインをインストールする前に、この判断表を使う。

必要なこと	より安全なデフォルト	MCPを使うべき場合
GitHub操作を実行する	Bash経由の`gh` CLI	Claudeがissue、PR、メタデータを対話的に見る必要がある
データベースに問い合わせる	読み取り専用CLIまたはローカルスクリプト	Claudeがスコープ付き認証情報で構造化されたツール呼び出しを必要とする
クラウドリソースを調べる	明示的なコマンドを使うベンダーCLI	MCPサーバーの権限が狭く、監査ログが明確である
ドキュメントを取得する	静的ドキュメント、リポジトリ内ファイル、またはWebリンク	リソースが大きく、動的で、頻繁に参照される
ポリシーを強制する	`PreToolUse`フック	判断にClaudeから見えるコンテキストやツールメタデータが必要である

CLIツールのほうが安全なことは多い。必要なときだけ呼び出され、そのターンだけに出力を生成するからだ。MCPは、スコープ付きOAuth、型付きツール、監査ログを提供する場合には、より安全になり得る。間違いは、反射的にMCPをインストールすることだ。

CLIツールとMCPサーバーを、コンテキストコスト、権限面、セットアップなど4行で比較するコンパクトな図表

フックには独自のセキュリティレビューが必要だ

フックは、プラグインを魔法のように感じさせる機能だ。同時に、私が最も厳しく監査する機能でもある。

Claude Codeのフックは、SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、PreCompact、SessionEndなどのイベントで実行できる。プラグインリファレンスによれば、フックの種類にはコマンドフック、HTTPフック、MCPツールフック、プロンプトフック、エージェントフックが含まれる（Claude Code plugin reference）。フックガイドは、PreToolUseフックが終了コード2でアクションをブロックできること、またUserPromptSubmit、UserPromptExpansion、SessionStartのstdoutはClaudeのコンテキストに追加され得ることを説明している（Claude Code hooks guide）。

かなりの権限だ。

良いフックは、危険な挙動をブロックするか、コンパクトで決定的なコンテキストを追加する。悪いフックは、すべてのプロンプトを高コストなRAGパイプラインに変え、プロンプト本文をHTTPエンドポイントへ漏らし、または環境をこっそり変更する。

フックは4つの質問で監査する。

どのイベントで発火するか？
どのmatcherが対象を絞っているか？
どんなデータを受け取るか？
stdout、stderr、ディスク、ネットワーク、コンテキストに何を書き込むか？

ここでのコミュニティの意見の割れ方は、むしろ有益だ。r/ClaudeCodeのフックスレッドでは、一部の開発者が、ルールを強制したり、危険なgit操作をブロックしたり、Claudeにメモリを書くよう促したりする唯一の信頼できる方法としてフックを説明している。一方で、UserPromptSubmit上に手の込んだメモリやRAGフローを構築している人たちもいる（Reddit）。どちらも有効になり得る。違いは、予算と爆発半径だ。

チーム導入なら、コンテキスト注入フックよりも先にポリシーフックを許可する。rm -rfパターンをブロックするPreToolUseフックは理解しやすい。毎ターンメモリを取得して注入するUserPromptSubmitフックには、測定、上限、明確な所有者が必要だ。

狭くインストールし、測定してから昇格する

Claude Codeは、user、project、local、managedのプラグインスコープをサポートしている。ドキュメントでは、userスコープはプロジェクト横断の個人用、projectスコープは.claude/settings.jsonを通じて共有されるもの、localスコープはプロジェクト固有だが共有されないものとして説明されている（Claude Code docs）。

これらのスコープをロールアウト機構として使う。

まずlocalにインストールする。
実際のタスクを1つ実行する。
/pluginの詳細と/mcpを確認する。
有効化の前後で/contextと/usageを使う。
コストに見合わないものは無効化する。
レビュー後にだけprojectスコープへ昇格する。

ドキュメントによれば、Claude Code v2.1.143以降ではプラグイン詳細ペインにコンテキストコスト見積もりを表示でき、v2.1.144以降では最終更新日を表示でき、v2.1.145以降では「Will install」のインベントリを表示できる（Claude Code docs）。インストールを押す前に、そのインベントリを使うこと。フォーマッタを名乗るプラグインが、MCPサーバー、フック、バックグラウンドモニターをインストールしようとしているなら、止まって調べる。

自動更新にも注意する。Anthropicによれば、公式マーケットプレイスではデフォルトで自動更新が有効になっており、サードパーティおよびローカルのマーケットプレイスではデフォルトで無効になっている。ドキュメントには、更新挙動を制御するためのDISABLE_AUTOUPDATERとFORCE_AUTOUPDATE_PLUGINSも説明されている（Claude Code docs）。自動更新はセキュリティ修正には便利だが、実行時のサプライチェーンを変える。規制のあるチームでは、各ノートPCが独立してずれていく状態にするのではなく、レビュー済みの社内マーケットプレイスでマーケットプレイスのバージョンを固定するべきだ。

導入済みプラグインのインベントリが、多数のMCPサーバーとフックから減っていく様子を示す監査ダッシュボードのビフォーアフターモックアップ

インストール前に私が使うチェックリスト

Claude Codeを使うチームの開発者に渡すなら、この短縮版にする。

ソース:

マーケットプレイスはanthropics/claude-plugins-officialか、社内リポジトリか、サードパーティリポジトリか？
プラグインソースはSHAに固定されているか？
ホームページはソースの所有者と一致しているか？
リポジトリに最近の予想外の変更、生成されたblob、インストールスクリプトはないか？

コンポーネント:

MCPサーバーを追加するか？
フックを追加するか？
bin/内に実行ファイルを追加するか？
ツールを呼び出せるエージェントを追加するか？
ローカルバイナリを必要とするLSPサーバーを追加するか？

権限:

どの認証情報を要求するか？
機密値はプラグインのuserConfigでsensitiveフィールドとして保存されるか？
MCPサーバーには読み取り専用アクセスが与えられるか、書き込みアクセスも与えられるか？
フックはHTTPで外部に通信するか？
広範な環境変数を継承するスクリプトはあるか？

コスト:

/pluginはコンテキストコストをどう報告しているか？
有効化後に/contextはどう変わるか？
そのプラグインは毎セッション価値を出すか、それともまれなワークフローだけか？
CLIコマンドで、より少ない永続コンテキストで同じ結果を出せないか？

運用:

/plugin disable name@marketplaceで問題なく無効化できるか？
問題なくアンインストールできるか？
設定、認証情報、デーモン、キャッシュ、ブラウザ認証を残さないか？
更新の責任者は誰か？
プラグインソースが消えたら何が壊れるか？

かなり意見を込めて言えば、欲しい数より少ないプラグインを入れるべきだ。1つのワークフローだけを追加する、小さくて退屈なプラグインを優先する。一度きりの操作にはCLIを優先する。MCPは、サーバーがスコープ化され、監査され、本当に対話的である場合に使う。フックはガードレールに使うべきで、モデルに覚えていてほしい好みを何でも放り込む場所ではない。

プラグインは、Claude Codeにおけるワークフローのパッケージ形式になりつつある。それは良いことだ。チームは部族的なプロンプト知識ではなく、再現可能なセットアップを共有できるようになる。だが、そのパッケージ形式は、依存関係レビュー、権限レビュー、コストレビューに値するほど強力だ。中身を読まずにツールを自分のリポジトリへcurl | bashしないのなら、親しみやすいマーケットプレイスUIに表示されているからという理由だけで、そのプラグイン版をインストールしてはいけない。

静かなフッター: Claude Fable 5を自分で試したいなら、Claude Fable 5 on OneHopから使える。定価より約30%安いドロップインエンドポイントだ。新規アカウントは、カード不要で$10 freeから始められる。

さらに読む: Claude Fable 5入門.