Claude Code の Skill 機能を使い始めてから、業務のあちこちを少しずつスキルにしてきました。

気づけば自作スキルは累計 24 個。
うち 7 個は使わなくなって削除したので、いま現役なのは 17 個です。

朝のタスク整理、依存パッケージの調査、月次の定型業務、コードレビューまで、「毎回やること」をどんどんスキルに落とし込んでいます。

この記事では、現役 17 個の中から 「これは本当に効いた」と感じたスキルを 8 つ、何をするものか・なぜ効くのかとセットで紹介します。

あわせて、捨てた 7 個がなぜ使われなくなったのかと、そこから見えた 「効くスキルの共通点」 もまとめました。
自分でスキルを作ってみたい方の参考にしていただけたら幸いです。

Skill 機能そのものの説明は省略します。「SKILL.md という Markdown に手順書を書いておくと、Claude が依頼内容との関連を判断して呼び出してくれる仕組み（/スキル名 での明示呼び出しも可）」くらいの理解で読み進められます。

そもそも、スキルにすると何が嬉しいか？

本題の前に、スキル化の効果を一言で。

スキルとは、「毎回やる作業の手順と判断基準を、Markdown で書き出したもの」です。

一度書いておけば、話しかけるだけで Claude がその手順どおりに動いてくれます。

効果は大きく 3 つです。

手順を覚えなくてよくなる
- 久しぶりの作業でも、スキルが手順を持っている
判断がブレなくなる
- 「何を優先するか」を明文化するので、品質がブレにくくなる
属人化が解ける
- 自分の頭の中にあった暗黙知が、誰でも使える形になる

では、実際に効いた 8 つを見ていきます。

【ルーティン自動化】毎日・毎月の定型をスキルに

① 朝の秘書ブリーフィング

カレンダー・タスク・目標・Slack を横断して、今日やるべきことを優先度付きで提案してくれるスキルです。

毎朝の「何からやろう」で消えていた 10〜15 分が、「ブリーフィングして」と話しかけるだけで済むようになりました。

仕組みの詳細は別記事にまとめています：Claude Code でカレンダー、Obsidian、Slack を横断して毎朝のタスク整理してくれる秘書をつくった

② 月次の定型業務を「仕組み」に固める

毎月 1 回ある定型業務（あるサイトのリソース状況更新）を、工程ごとにスキル化しました。

作業用 issue を作る
CMS の値を更新する
お知らせ記事を追加する
完了報告を投稿する

月 1 回しかやらない作業ほど、手順を忘れます。
スキルにしておくと「やり方を思い出す」コストがゼロになり、環境さえ整っていれば誰でも同じ手順で実行できるようになります。

月次業務をスキル化して気づいたのは、**「決まりきった手順はスキル、判断が要る部分は対話」**という線引きの大切さです。
全部自動化するより、変化しうる部分（確認・調整）は対話で残すほうが、結果的に安定しました。

【調査・レビューの相棒】 AI に「観点」を仕込む

ここが個人的に一番効いている領域です。
レビューや調査の観点をスキルに仕込んでおくと、チェックの抜け漏れがぐっと減ります。

③ Dependabot PR の調査スキル

Dependabot が作る依存アップデートの PR を、依存チェーンを遡ってルートパッケージを特定し、アップデート戦略を提案してくれるスキルです。

package-lock.json を辿る・ルートパッケージの将来バージョンを調べる、といった地味だが時間のかかる一次調査を肩代わりしてくれます。
1 件 5〜10 分かかっていた調査が、ほぼ一瞬になりました。

④ 脆弱性の影響調査スキル

CVE 番号や GitHub Security Advisory の URL を渡すと、指定リポジトリの lock file を解析して「自分たちに影響があるか」を判定してくれるスキルです。

「この脆弱性、うちは関係ある？」を毎回手で調べるのは大変ですが、スキルにしておくと入力を渡すだけで影響有無と対応要否が返ってきます。

⑤ コードレビューを Codex に頼む「セカンドオピニオン」スキル

自分（Claude）の調査結果や記事を、別の AI（Codex）に独立レビューさせるスキルです。

記事を書いたり技術調査をまとめたあと、このスキルで Codex にファクトチェックを依頼します。

バージョン差・最新仕様・伝聞の混入など、一人で確認すると見落としがちな誤りを、独立した検証者がもう一度洗ってくれます。

実際にこのスキルに、記事の「未確認の予測を断定で書いていた」箇所や事実誤認を何度も見つけてもらいました。
AI の結論を、別の AI でダブルチェックするこの体制を仕組みにできるのが面白いところです。

⑥ ブログ記事の「編集パートナー」スキル

技術ブログの執筆を支援するスキルで、企画の壁打ち（企画モード）と下書きチェック（チェックモード）の 2 モードを持たせています。

ポイントは、「読者にとっての価値があるか」「構成に飛躍がないか」といった編集者の観点をスキル側に明文化してあることです。

書き手の自分とは別の役割を Claude に持たせることで、セルフレビューでは気づけない「独りよがりな構成」を指摘してくれます。

この記事の下書きも、このスキルでチェックしてから公開しています。

【制作・コミュニケーション支援】

⑦ 日報作成スキル

GitHub / Slack からその日の自分のアクティビティを自動収集し、対話で所感を引き出してから日報を生成するスキルです。

日報で一番時間がかかるのは、書くことより「今日何やったっけ」の思い出しすことです。

そこを自動収集に任せて、人間は所感や気づきを話すだけにしました。
案件ごとの分類ルールや表記の細かい好みもスキルに書いてあるので、毎日同じフォーマットで仕上がります。

⑧ 依頼文・メッセージの最適化スキル

クライアントへの依頼文や Slack メッセージを、前提を知らない相手にも伝わる形に整えるスキルです。

「この文面、最適化して」と渡すと、曖昧な表現や抜けている前提を補って、ポジティブで明確なテキストにしてくれます。
伝え方で消耗しがちなコミュニケーションを、一段ラクにしてくれました。

捨てた 7 個のスキルの話

「効いた 8 つ」だけ見るとうまくいった話に見えますが、実際は 24 個作って 7 個捨てています。
先日スキルの棚卸しをして、使っていないものを整理しました。捨てた顔ぶれはこんな感じです。

汎用知識系（3 個）: パフォーマンス最適化・プログレッシブエンハンスメント・セキュリティレビューの「観点集」スキル。Claude が最初から知っている一般論をスキルにしても、出番がありませんでした
頻度が足りなかったもの（1 個）: ADR（意思決定記録）作成スキル。作業自体の発生頻度が低く、スキル化のコストを回収できませんでした
ネタ系（1 個）: 辛口レビューをしてくれる「マサカリ少年」スキル。面白かったのですが、業務では結局呼びませんでした
役目を終えたもの（2 個）: 日報スキルの旧版（⑦ の前身）と、Figma と実装の差分チェックスキル。前者は新版に引き継ぎ、後者は使う場面が続きませんでした

並べてみると、捨てた理由は 「一般論」「低頻度」「ネタ」「役目を終えた」 の 4 つに分かれます。
逆に生き残ったのは、自分の業務に固有の手順・判断を書いたスキルだけでした。

効くスキルの共通点

24 個作って 7 個捨てた経験から、「効くスキル」と「作ったけど使わないスキル」の差が見えてきました。

共通点1：「毎回やること」を対象にしている

効くスキルは、例外なく繰り返し発生する作業が対象です。
一度しかやらないことをスキルにしても、作るコストのほうが高くつきます。
「これ、前にもやったな」と感じた瞬間が、スキル化のサインです。

共通点2：判断基準まで書いてある

「手順」だけでなく、「何を優先するか」「どう判断するか」の基準まで書いたスキルほど、出力が安定します。
逆に手順だけのスキルは、状況が少し変わると使えなくなりがちです。

共通点3：普段の言い回しを `description` に仕込んでいる

スキルは、frontmatter の description を手がかりに Claude が「今の依頼に関係あるか」を判断して起動します（キーワードの完全一致ではありません）。
だからこそ、自分が普段使う言い回しを description に幅広く入れておくと、自然な言葉で呼び出せて、結局よく使うようになります。

共通点4: 「全部自動化」を狙っていない

意外かもしれませんが、判断や調整が必要な部分は対話で残すスキルのほうが、長く使えます。

決まりきった処理はスキルに、変化しうる部分は対話に。この線引きが、実用性を分けます。

まとめ

カテゴリ	スキル	効果
ルーティン自動化	① ブリーフィング / ② 月次業務	毎日・毎月の定型を話しかけるだけに
調査・レビュー	③ Dependabot 調査 / ④ 脆弱性調査	時間のかかる一次調査を肩代わり
レビューの質	⑤ Codex セカンドオピニオン / ⑥ ブログ編集パートナー	AI に観点を仕込んでチェックの抜け漏れを減らす
制作・伝達	⑦ 日報作成 / ⑧ 依頼文最適化	収集と整形を任せて、人間は判断と所感だけに

本記事の要点は下記のとおりです。

スキルとは「毎回やる作業の手順と判断基準を Markdown に書き出したもの」
繰り返す作業こそスキル化の対象。一度きりの作業は割に合わない
一般論のスキルは使われない。自分の業務に固有の手順・判断を書いたスキルだけが生き残る
手順だけでなく 判断基準 まで書くと、出力が安定する
全部自動化せず、判断が要る部分は対話で残すほうが長く使える
レビューや調査の「観点」を仕込むスキルは、特に費用対効果が高い

「これ、前にもやったな」と感じる作業があったら、それはスキル化のチャンスです。

まずは一番繰り返している作業を、ひとつ SKILL.md に書き出すところから始めてみてください（frontmatter の description に、普段の言い回しを入れるのを忘れずに）。