プラグインを「作れる」から「配れる」へ。Claude のディレクトリ提出ポータルが開設

要約

Anthropic は 2026-09-25、Claude のディレクトリへプラグインを提出するためのポータルを公開しました。公式 Release Notes（support.claude.com の 09-25 の日付見出し）と公式ブログ “Build plugins for Claude” の両方で告知されています。提出先は claude.ai/directory/manage/new です。

これまでの1年、Claude の拡張の話はほぼ「作り方」に集中していました。MCP でサーバーを立てる、Skills を書く、hooks を仕込む。手元で動くものを作る手段は揃っていました。足りていなかったのは、作ったものを他人に届ける経路です。 社内なら設定ファイルを共有する、外に出すなら GitHub の README で手順を説明して各自にインストールしてもらう。配布は作者の手作業でした。

今回のポータルは、そこを埋めるものです。提出、審査、掲載、公開後の計測という一連の流れが1か所にまとまりました。

提出できる形態は2つです。 ひとつは単一の MCP コネクタで、リモート MCP サーバーを指定します。もうひとつはプラグインバンドルで、MCP サーバーと Skills を GitHub 上でホストしてまとめます。Claude Code 向けには、これに加えて LSP、コマンド、hooks、agents も含められます。対応仕様は MCP 2.0 で、MCP 拡張のうち Apps（対話的な UI を持つもの）と Enterprise Managed Auth（OAuth）に対応します。

審査は提出した時点で動き始めます。 公式は「Auto-validate your plugin. Each submission is checked and safety-scanned as soon as you submit, so you catch issues early.」と書いています。提出即時の検証と安全性スキャンが走り、審査ステータス、スキャン結果、承認前に直すべき点がポータルで確認できます。「出して待つ」のではなく、出した直後に何が引っかかるか分かる設計です。

公開後はアナリティクスが見られます。 内容は2系統に分かれます。インストール数は製品サーフェス別・バージョン別に出ます。発見側の指標として、ディレクトリ掲載ページの表示回数と、流入した検索キーワードが出ます。前者は「使われているか」、後者は「見つけられているか」を測るものです。この2つが分かれていることに意味があります。 表示は多いのにインストールが少なければ説明が悪い、表示が少なければ名前とキーワードが悪い、という切り分けができます。

提出できるのは有料 Claude プランの開発者です。あわせて「Over the coming weeks, one discovery experience will roll out across Claude and Claude Code.」として、現在 Claude と Claude Code で分かれている発見体験を、今後数週間で1つに統合する予定が示されました。

何が変わったか

• claude.ai/directory/manage/new からプラグイン / MCP コネクタをディレクトリへ提出できるようになった
• 提出形態は2つ: 単一 MCP コネクタ（リモートサーバー指定）、プラグインバンドル（MCP サーバー＋Skills を GitHub ホスト）
• Claude Code 向けには LSP、コマンド、hooks、agents も含められる
• 対応仕様は MCP 2.0。MCP 拡張は Apps（対話的 UI）と Enterprise Managed Auth（OAuth）に対応
• 提出時点で自動検証と安全性スキャンが走る
• 審査ステータス、スキャン結果、承認前の推奨修正をポータルで確認できる
• 公開後のアナリティクス: 製品サーフェス別・バージョン別のインストール数、掲載ページの表示回数、流入した検索キーワード
• 提出できるのは有料 Claude プランの開発者
• 今後数週間で Claude と Claude Code の発見体験を1つに統合する予定

業務インパクト（一般企業向け）

まず効くのは、内製プラグインの位置づけです。 社内でしか使わないものをディレクトリに出す必要はありません。ただ、提出時の自動検証と安全性スキャンが何を見ているかは、内製プラグインの品質基準としてそのまま参考にできます。公式が「提出即時にスキャンする」と明言した以上、そのスキャンを通らない作りは、社内向けであっても危ないという目安になります。自前の審査基準をゼロから設計するより、通る形に寄せる方が早い。

次に、調達側の判断が変わります。 ディレクトリに掲載されたプラグインは、Anthropic の自動検証と安全性スキャンを通過しているという前提が付きます。これは「安全である」という保証ではありませんが、何も通っていない GitHub のリポジトリとは区別できるようになります。情シスがサードパーティのプラグインを審査するとき、掲載の有無は最初のフィルタとして使えます。逆に言えば、掲載されていないものを入れる場合の説明責任が上がります。

MCP 2.0 と Enterprise Managed Auth への対応は、認可の設計に関わります。 Enterprise Managed Auth は OAuth 拡張で、組織が管理する認可をプラグインに効かせるためのものです。「プラグインが誰の権限で動くか」を組織側が握れるかどうかは、導入審査で必ず問われる点です。提出要件にこれが含まれていることは、組織向けに配ることを想定した設計だと読めます。

発見体験の統合予定は、社内周知の順番に影響します。 今後数週間で Claude と Claude Code の発見体験が1つになるなら、いま「Claude Code ではこう、Claude ではこう」という社内マニュアルを書くと、書いた直後に古くなります。 統合後の姿を待ってから手順書を作る方が無駄がありません。

副業・個人活用視点

これは配布チャネルが手に入ったという話です。 これまで個人が作った MCP サーバーや Skills は、見つけてもらう手段がほぼ X の投稿しかありませんでした。 ディレクトリに載れば、Claude の中で検索して見つかるようになります。流入経路が「作者のフォロワー数」から「ディレクトリ内の検索」に変わるのは、無名の個人にとって有利な変化です。

検索キーワードが見られるのが、実務上いちばん大きい。 どんな言葉で探されているかが分かれば、名前と説明文をそれに合わせられます。 表示回数とインストール数の比も出るので、「見られているが入れられていない」状態を検知できます。これは広告運用と同じ改善ループで、作ったあとに伸ばす余地があるということです。作って放置するのと差が付きます。

有料プランが提出の前提なので、無料で配布だけしたい形は取れません。ただ、提出の関門が自動スキャンで機械的に効くという点は、個人にとってむしろ追い風です。審査待ちの列に並ぶのではなく、出した瞬間に何が足りないか返ってきます。修正して出し直すサイクルが自分のペースで回せるため、時間を細切れに使う副業のやり方と相性がいい。

狙い目は、汎用ツールより狭い業務です。 汎用のものは競合が多く、大手が出してきます。「特定の業界の特定の帳票を扱う」「特定の SaaS の特定の画面を読む」といった狭さは、ディレクトリ内検索では強みになります。 検索キーワードが見られる以上、狭い言葉で確実に一位を取る戦い方が成立します。