この記事の出発点は、エージェント関連のツールがうまく機能し始めて初めて表面化する問題である。各チームが独自のスキルやエージェントを蓄積していくにつれ、それらの資産は作ったチームの中にとどまり、AI 支援開発に習熟しつつあるチームとそうでないチームとの差が広がり続ける。著者らが掲げる理想は、他チームの開発資産を自チームのものと同じくらい気軽に参照・再利用でき、新しい仕事の出発点として使える状態である。そのために構築したのが、チーム横断で共有する 1 つの Claude Code プラグインマーケットプレイス であり、2025 年後半から運用されている。
1 つのカタログを共有すること自体が固有の問題を生むことがわかり、記事はそのうちの 5 つを軸に構成されている。各課題は、プラグインが書かれてから他チームに使われるまでの道筋の段階 ── 開発、プルリクエストによる取り込み、検証、発見とインストール、改善 ── に対応づけられている。5 つとも、参加するチームとプラグインの数が増えるほど頻発するようになると説明されており、それぞれに対して 1 つの汎用的な解決策ではなく異なる種類の仕組みで対処している。1 つ目には構造、2 つ目にはコード生成、3 つ目には CI による強制、4 つ目には別の検索面、5 つ目にはオンデマンドのチェックである。
記事は、どこまでを扱うかを明示している。著者らは、プラグインの品質はテキストをレビューするだけでは確定できず、インストールして動かしてみて初めてわかると述べている。そのため自動チェックは、入り口としての最低ライン（最低限動くか、規約に従っているか、既存のものと重複していないか）だけを意図的に保証するにとどめ、実際に品質を担保するのは必須となっている人間によるプルリクエストレビューだとしている。
要点
- 記事が掲げる中心的な課題はツールの導入ではなく資産の孤立である。スキルやエージェントはチームごとに蓄積され、共有の場がなければチーム間の差が開いていく。記事が示す目標は、他チームの資産を自チームのものとまったく同じように参照・再利用できることである。
- メンテナンスの所有権は、メタデータではなくディレクトリ構成で表現されている。プラグインは所有チームごとのディレクトリの下に置かれ、チーム横断のものには
common-plugins/ディレクトリが用意されているため、プラグインの置き場所がメンテナンス担当を決める。共通ディレクトリに置くべきかどうかは、チーム横断での利用が見込まれるかを基準に、プルリクエストのレビューの中で判断される。著者らは、plugin.jsonの author フィールドはプラグインを書いた人を示すが、それが 1 チーム向けなのか全員向けなのかは示さないと指摘している。 - この構成が可能なのは、カタログの各エントリが相対パスでプラグインの場所を指定するため、プラグインを 1 か所に固定して置く必要がないからである。著者らは受け入れた制約も記録している。相対パスで参照できるのは同じリポジトリ内のプラグインに限られ、CI やリポジトリ設定がチームごとに分散するのを避けるため、リポジトリ横断の参照ではなく単一リポジトリを選んだ。
- 共有マニフェストは手で編集するのではなく生成される。各プラグイン自身の
plugin.jsonを信頼できる唯一の情報源として扱い、カタログのマニフェストは CI から実行されるスクリプトによってそれらすべてから再構築され、結果はボットのコミットとしてプルリクエストのブランチに書き戻される。開発者が書くのは自分のプラグインのメタデータだけである。記事は 2 つの帰結を挙げている。ファイルを部分的に修正するのではなく毎回全体を再生成するため、削除したプラグインがカタログに取り残されることがない。また、エントリをパス順にソートするため、2 つのチームが別々のプラグインを追加しても触れる行が異なり、末尾に追記していく共有ファイルで起きがちなマージコンフリクトがほぼ起きなくなる。 - 個々のプラグインではなくカタログ全体に属する情報は、生成元となる
plugin.jsonが存在しないため、別のメタデータファイルに保持され、生成スクリプトがそれをマージする。著者らによれば、このファイルはプラグインを追加する際に編集する必要がない。 - 構造上の誤りは、レビュアーではなく CI で検出する。その理由として記事は、構造上の誤りは差分では見つけにくいこと、そして共有マニフェストが壊れると全チームのマーケットプレイス更新が一斉に失敗し、1 つのチームのミスが全員の新しいプラグイン取得を止めてしまうことを挙げている。チェックのほぼすべては Claude Code 自身の
claude plugin validateに委ねられており、著者らが独自に書いたチェックは 2 つだけだという。README の有無と、plugin.jsonはあるのにカタログに登録されていないプラグインの検出である。 - スキルは説明文ではなく意図で検索される。著者らの診断では、
SKILL.mdの説明文は開発者が実装の観点で書くのに対し、利用者はやりたいことの観点で検索するため、両者がかみ合わない。スキルインデックスは各スキルに、それが使われる場面を表す短いタスクフレーズを複数付与し、検索ではそれらのフレーズに最も大きな重みを置く。フレーズは、通常のスクリプト処理と Claude を組み合わせた日次の GitHub Actions ジョブで生成され、処理対象はSKILL.mdが変更されたスキルだけである。カテゴリは閲覧用のタブとしてのみ使われ、マッチングには用いられない。記事に掲載されたスクリーンショットの時点で、73 個のスキルが対象になっていたと報告されている。 - 検索は意図的にシンプルに保たれている。マッチングはクライアント側のキーワード照合で、埋め込みもクエリ時の LLM 推論も使わないため、インデックスは GitHub Pages 上の静的サイトとして公開されている。
- 5 つ目の仕組みが対処するのは正しさではなくためらいである。開発者は自分のスキルが他チームでどう使われているかを見られないため、説明文のトリガー条件、引数の形式、出力の契約を変更すると見えない呼び出し元を壊すおそれがあり、改善が先送りされがちになる。プルリクエストのコメントに
@claudeと書くと、2 つの軸で機械的なチェックが実行される。破壊的変更（スキル名と説明文のトリガー、引数と出力の契約、エージェントの契約とステータスコード、フックと MCP の設定、参照されているファイルの削除）と、マーケットプレイスの規約（SKILL.mdの長さ、説明文の形式、段階的開示、過剰に付与されたallowed-tools、MCP サービスの分離、ハードコードされたシークレット）である。 - 約 10 か月後に報告されている効果は次のとおりである。共有インデックスを通じて他チームの取り組みが見えるようになり、その
SKILL.mdを読んで自分たち向けに手直しできるようになった。具体的な再利用も起きており、あるチームのシステム横断検索スキルが 4 つの独立した検索エージェントに分割され、別のチームがインシデント調査スキルを作る際にそれらを直接呼び出した。オンボーディングも、プラグインをゼロから作ることから、既存のものをインストールし動く実例を読むことへと変わった。これらは 1 つの組織の経験についての著者ら自身の報告であり、計測された結果ではない。 - 報告されている未解決の課題は次のとおりである。容易に成長するカタログには使われないプラグインも蓄積し、それらが検索結果に出続けるうえ、プラグイン間の依存関係が見えにくくなる。追加や変更の告知は、専用の Slack チャンネルへの投稿が個人の判断に任されているため、徐々に行われなくなっている。Claude Code 自体の変化の速さに追随し続けなければ、カタログの資産が古びるおそれがある。そして著者らは、5 つの仕組みのいずれもが問題が表面化した後に作られたものだと述べ、運用のサイクルそのものを次に設計すべき対象として挙げている。
背景
この記事は、個人単位ではなくチーム横断でエージェントの利用を標準化している組織による、本 wiki 内の他の一次報告と並ぶものである。また、ZOZO の 1 つの部門が自部門のワークフローを 2 つのコマンドに標準化した様子を述べた AI駆動開発を2コマンドで組織標準に ── Claude Code × Codexで設計からテストまで に対して、カタログ規模で対をなす記事でもある。あちらの記事が、内部が変わっても表面を安定させる方針をとっているのに対し、この記事は、所有者の異なる資産のために安定した置き場所を用意している。
著者らが繰り返し述べる注意点は、仕組みがあることと需要があることは同じではないということである。構築したチェックは品質保証ではなく入り口の最低ラインであると明言されており、締めくくりの節では、共同運用を安全にする作業が、プラグイン作成の容易さに一貫して後れを取っていると報告されている。記事の技術的な説明は Claude Code の公式ドキュメントに基づいて書かれており、著者らはその時点を 2026 年 8 月としている。