Claude Code の Skills を10個作って、納品前チェックを自動化した実録
Claude Code のカスタムSkillsを10個作って、Web制作の納品前チェックや先方FB対応を自動化した実録。作って初めて分かった「skillにすべきもの」と「しなくていいもの」の境界線を書く。
副業でWeb制作を受けるようになってから、毎回同じ作業で時間を溶かしてることに気づいた。
納品前の誤字脱字チェック、画像内テキストの確認、alt属性の有無、リンク切れ確認——どれも「重要だけどやること自体は単純」な作業で、でも見落とすと普通に事故る。実際、納品直前にOGP画像を設定し忘れて出しかけたことが1回ある。
そこで、こういう定型チェックをClaude CodeのSkillsに切り出すことにした。今は.claude/skills/配下に10個のSkillsが並んでいて、納品前の機械チェックはほぼそこに任せている。この記事は、実際に作ってみて分かった「skillにする価値があるもの」の見分け方をまとめたもの。
Skillsって結局、何が嬉しいのか
Claude Codeの通常の会話は、毎回ゼロから指示を組み立てる必要がある。「誤字脱字を見て」「alt属性もチェックして」「PC版とSP版両方見て」と、頭の中の手順を毎回言葉にする作業自体がコストだった。
Skillsは、この「毎回言葉にする作業」をファイルに固定できる。.claude/skills/<スキル名>/SKILL.mdに判断フローと手順を書いておくと、該当するタスクが来たときに自動で発動する。
通常の会話
手順を毎回言葉にするのがコスト
Skills 化
説明コストがほぼゼロに
僕が作ったSkillsの一部はこんな感じ。
| スキル | やること |
|---|---|
lp-preflight | LP納品前のmeta/OGP/alt/リンク切れ/ダミーテキストの機械チェック |
director-check | 誤字脱字・改行・画像内文字をPC/SPの両方でチェックして一覧化 |
fb-hanei | 先方フィードバックを正規化→指示書化→PC/SP反映→報告まで定型化 |
hosts-staging-check | ステージング環境のhosts設定を疎通確認 |
wp-manual | WordPress投稿マニュアルをpptx/PDFで自動生成 |
共通してるのは、どれも「やることは決まってるけど、毎回説明するのが面倒」な作業だということ。逆に言うと、これがskillにする価値があるものの条件だと分かってきた。
最初に失敗した作り方：手順を全部プロンプトで書いた
最初にlp-preflightを作ったとき、SKILL.mdに「meta descriptionが120〜160字か確認して、OGP画像の有無を見て、altタグが空じゃないか全部見て……」と、チェック手順を全部プロンプトの日本語で書いた。
これが全然安定しなかった。Claudeが見落とすページが出てきたり、同じサイトでも実行のたびに検出漏れの数が違ったりした。人間の注意力に頼るチェックを、AIの注意力に頼るチェックに置き換えただけで、根本的には同じ問題を抱えてた。
なので方針を変えて、機械的に判定できる部分はPythonスクリプトに切り出して、Skillはそのスクリプトを呼び出す「入口」にした。実体はtools/lp_preflight/に置いて、SKILL.mdからは「これを実行して、結果を読んで報告する」という指示だけを書く形に変えた。
lp-preflight/
├── SKILL.md # 判断フロー・発動条件だけ書く
tools/lp_preflight/
├── check.py # meta/OGP/alt/リンク切れの実チェック
最初の作り方（ブレた）
切り出したあと（安定）
これに変えてから検出のブレがなくなった。「プロンプトで約束できることと、コードで担保すべきことを分ける」のが、Skills設計でいちばん効いた学びだった。
トリガー条件が甘いと誤発動する
もう1つハマったのが、SKILL.mdのdescription（発動条件を書く部分）を曖昧にしすぎたケース。
director-checkの初期バージョンは、descriptionに「サイトをチェックする時に使う」とだけ書いていた。そうしたら、全然関係ない「デザインのレビューをして」という依頼のときにも発動してしまって、意図と違う出力が返ってきた。
descriptionを「サイトの誤字脱字・改行位置・画像内文字を、公開前または納品前にPC/SP両方でチェックする時」まで具体化してから、誤発動がほぼ消えた。広すぎるdescriptionは無関係な場面で暴走し、狭すぎると本来使うべき場面で発動しない——このバランスを取るのに、実際は3回くらい書き直しが要った。
Skillsにしなかったもの
逆に、途中でskill化をやめたものもある。例えば「オーナーへの報告文言」を毎回同じフォーマットで書くルールは、Skillではなく普通のルールファイル（.claude/rules/配下）に置いた。
理由は単純で、報告フォーマットは発動条件で分岐する必要がないから。「オーナーに報告する時は常にこの形式」でよくて、if-thenの判断フローが要らないものをSkillにすると、ただの静的ルールに余計な機構を被せることになる。
判断基準として僕の中で固まったのは、
- 判断フロー（if-thenの分岐）が要るか → 要るならSkill、要らないならルールファイル
- 機械的に検証できる部分があるか → あるならスクリプトに切り出して、Skillは入口にする
- 発動条件を1文で具体的に言えるか → 言えないなら、まだ設計が固まっていない
この3つを通してから作るようになって、無駄なskillを作る回数が減った。
まとめ
Skillsを10個作ってみて分かったのは、「便利そうだから作る」だと途中でメンテできなくなるということ。判断フローが本当にあるか、機械チェックに切り出せる部分がどこかを先に整理してから作ったskillだけが、実際に長く使えている。
今Claude Codeで同じ作業を繰り返し説明している人は、まずその作業に「if-thenの分岐」があるかどうかだけ確認してみるといい。分岐がないなら、Skillより先にAGENTS.mdかルールファイルに1行書くところから始めたほうが早い。