claude-code-setupを検証したところ、既存設定の点検として機能した話

Claude Codeのプラグイン一覧を確認していた際、claude-code-setup という名称が目に留まりました。

setupという語が何を指しているのかが、名称からは判断できません。Claude Code自体の導入を支援するものとも読めますが、それにしては対象が漠然としています。インストール数は5万件台で、公式マーケットプレイス内では上位に位置します。相応に利用されているにもかかわらず、機能が名称から読み取れない。そこで内容を確認し、自分のリポジトリで実行してみました。

結果は想定と異なりました。新しい自動化の提案を受けるつもりでしたが、既存設定の不備を先に指摘される形になりました。

自動化の推薦のみを行うプラグイン

機能は、コードベースを解析して自動化の候補を提示することに限られます。どのhooksを設定すべきか、どのsubagentを作成すべきか、といった提案を出力します。

Anthropic公式の claude-plugins-official に収録されており、構成は claude-automation-recommender というSkill 1件のみです。agent、hook、MCPサーバーはいずれも同梱されていません。

そしてread-onlyであることが明記されています。

This skill is read-only. It analyzes the codebase and outputs recommendations. It does NOT create or modify any files.

提案は行うが作成はしない。この点については当初、機能として不足があるのではないかと感じました。

実行前に内容を確認した

何を根拠に推薦するのかを把握しておきたかったため、実行前に全ファイルを確認しました。

.claude-plugin/plugin.json
README.md
skills/claude-automation-recommender/SKILL.md
skills/claude-automation-recommender/references/hooks-patterns.md
skills/claude-automation-recommender/references/mcp-servers.md
skills/claude-automation-recommender/references/plugins-reference.md
skills/claude-automation-recommender/references/skills-reference.md
skills/claude-automation-recommender/references/subagent-templates.md

SKILL.md が289行、referencesが5本で合計1200行程度です。内容は判定表が大半を占めています。

判定基準はほぼファイルの有無でした。.prettierrc が存在すればフォーマット用のPostToolUse hook、tsconfig.json が存在すれば型チェック、.env が存在すれば編集を禁止するPreToolUse hook。依存関係に @supabase/supabase-js があればSupabase MCP、という具合です。

想定していたより簡素な構造でした。コードを解析するのではなく、設定ファイルの存在から逆算しています。ただし判定に時間を要さないという点では、妥当な設計だと考えます。

トークンコストも確認しました。

$ claude plugin details claude-code-setup@claude-plugins-official
Projected token cost
  Always-on:   ~139 tok   added to every session

  component                      always-on  on-invoke
  claude-automation-recommender       ~140      ~4.1k

常時139トークン、呼び出し時のみ4.1k。導入したままでも影響はほぼありません。年に数回しか使用しないものが常時コストを消費するのは避けたいところなので、この配分は適切だと思います。

内容の確認で見つかった不備

細部ですが、確認した以上は記録しておきます。

READMEとSKILL.mdでカテゴリ数が一致していない

READMEには5番目のカテゴリとしてSlash Commandsが挙げられていますが、SKILL.md の推薦対象はhooks、subagents、skills、plugins、MCP serversの5種であり、スラッシュコマンドに関する節は存在しません。

出力テンプレート内のコマンドが、そのままでは実行できない

SKILL.md には以下の記述があります。

**Install**: `claude mcp add context7`

しかし claude mcp add は <name> <commandOrUrl> を必須引数とするため、この記述だけでは不足します。またcontext7は単体のプラグインとしても配布されており、そちらのほうが導入は容易です。テンプレート内の例示であるため影響は限定的ですが、そのまま実行する利用者は出ると思われます。

referencesにtypoが残存している

mcp-servers.md の見出しが ## Monitoring & Observtic となっています。また hooks-patterns.md には Quick Reference: Detection → Recommendation という同一の表が2回出現します。追記時の削除漏れと推測されます。

ただし SKILL.md に以下の記述があり、この点で評価が変わりました。

The reference files contain common patterns, but use web search to find recommendations specific to the codebase’s tools, frameworks, and libraries

referencesは辞書ではなく起点である、という位置づけのようです。したがってtypoの影響は小さく、表に記載のない技術についても推薦できる構造になっています。この設計は後の実行結果で効いてきました。

判定材料が存在しない対象で実行した

導入します。今回はこのリポジトリに限定して試したかったため --scope local を指定しました。

$ claude plugin install claude-code-setup@claude-plugins-official --scope local

実行対象はこのブログ用リポジトリです。内容は記事のmarkdownとCLAUDE.mdのみで、package.json、tsconfig.json、.prettierrc はいずれも存在しません。git管理下のファイルはmarkdown 4本とjson 1本です。

先に確認した判定表を踏まえると、判定はすべて空振りするはずでした。Prettierもテストも依存関係も存在しない。出力はほぼ得られないだろうと予想した上で実行しています。条件としては厳しい試し方でした。

出力されたのは自分の設定の不備

出力の冒頭が以下でした。

One thing to fix before anything else: .claude/skills/tech-blog-writer.md is not in the format Claude Code loads.

Skillは .claude/skills/<name>/SKILL.md の形式で、YAML frontmatterを付与して配置する必要があります。当リポジトリでは .claude/skills/tech-blog-writer.md という平置きのファイルでした。確認したところfrontmatterもありません。文体ルールを記述した128行のmarkdownが、そのまま置かれている状態です。

さらにREADMEには、利用方法として以下が記載されています。

/write-blog <テーマ>
/blog <テーマ>

このスラッシュコマンドも存在しません。自分で記述したREADMEにもかかわらず、実体と乖離していました。

救いは、CLAUDE.md 側に文体ルールの要約と詳細ファイルへの参照パスが記載されていた点です。そのため記事の執筆自体は成立していました。参照ファイルとしては機能し、Skillとしては機能していない。この状態は外部から把握しづらいと思います。表面上は動作しているためです。

指摘された他の項目も検証した

この種の指摘は無検証で受け入れると危険なため、各項目を自分で確認しました。

CLAUDE.mdとAGENTS.mdに差分がある

$ diff CLAUDE.md AGENTS.md
23c23
< - 完璧に整いすぎた文章
---
> - 完璧に整りすぎた文章

同一内容を2ファイルに手作業でコピーしていたため、一方のみtypoが残っていました。しかも整いすぎた文章を禁止する行にtypoが入っているという状態です。

記事がgit管理下にない

articles/ が未追跡で、.gitignore も存在しません。19記事がこのディスク上にのみ存在します。自動化の追加より優先すべき事項です。

一文は短くと規定しているが、200字超の行が343行ある

自らルールに記載した上で、この数値です。

WebFetchのドメイン許可が66件

調査のたびに1件ずつ追加した結果です。指摘を受けて初めて総数を認識しました。

判定表の外から出た推薦

最も評価すべき点はここです。

判定表には存在し得ない推薦が出力されました。fact-checker というsubagentの作成提案で、理由は以下と記述されていました。

this is your recurring failure mode

過去に、実際には確認していない調査項目を推測で記述した記事があります。またBedrockを前提として一人称で執筆した記事が、実際にはTeamプラン利用という事実と食い違った例もありました。いずれもセッションのメモリに記録されています。

それを読み取った上で、下書きを執筆した文脈とは別のagentに事実確認をさせるべき、という提案でした。

これはファイルの有無による判定からは導出できません。referencesは起点にすぎない、という設計がここで機能していました。

read-onlyで停止する設計は妥当だった

当初は機能不足と感じたread-only設計ですが、実行後には納得しました。

.claude/settings.json を無断で書き換えられるのは、明確に避けたい事象です。hookは全セッションに作用するため、意図しない設定が1件混入するだけで影響が継続します。診断で処理を止め、判断は人に戻す。この境界設定は妥当だと判断しました。

そして出力の末尾に以下が付きます。

Want help implementing? I can set up any of these

診断は診断として完了させ、実装は別の依頼として継続する。この分離であれば、そのまま会話を続けても問題は起きにくい構造です。

所感と今後の対応

自動化の候補を提示するプラグインとして導入したところ、実質的には既存設定の点検になりました。

これは対象がコードを含まないリポジトリであったことが大きいと考えます。通常のコードベースであれば、判定表に沿った推薦が並ぶはずです。Prettierが存在するのでformat hook、という形です。今回は判定材料が不足していたため、既存設定の不整合を検出する側に寄ったものと理解しています。

ただし、価値があったのはそちらでした。自動化を1件追加するより、5か月間読み込まれていなかったSkillを検出できたことのほうが効果が大きい。自分の設定は、動作しているように見える限り点検の対象になりません。外部から確認する枠を用意することには、それ自体に意味があると思います。

対応の順序は以下で考えています。

1. .gitignore を作成し articles/ をコミットする（最優先。19記事がこのディスク上にのみ存在するため）
2. tech-blog-writer.md を .claude/skills/write-blog/SKILL.md に移動し、frontmatterを付与する
3. AGENTS.md を CLAUDE.md へのsymlinkに変更する（手作業でのコピーは再度乖離するため）
4. 200字超の行を書き込み時に警告するhookを設定する
5. fact-checker subagentを作成する

3のsymlinkは、推薦内では代替案として提示されていた方式です。hookでcpを実行するより、2ファイルに分けない構成のほうが確実だと判断しました。ただしCodex側がsymlinkを解決できるかは未検証のため、確認後に実施します。

なお本プラグインについては、コードを含むリポジトリでの実行結果を確認できていません。手元に対象がなかったためです。機会があれば別途記録します。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる