SECTION 01
Claude Code Skills とは——毎回同じ指示を打つ非効率を消す仕組み
Claude Code を使い始めた頃は、やりたいことを毎回日本語で書いてコピペする流れが普通でした。「レビューして」「テストして」「スクショ撮って確認して」と毎回打つのは、指示出しというより単なる作業です。この繰り返しを丸ごと消してくれるのが Skills という機能です。
Skills の本質は、再利用可能な指示セットを登録し、呼び出すだけで実行できる仕組みです。プロンプトのテンプレートと言えばわかりやすいかもしれませんが、テンプレートと違うのは、Claude Code のエージェントがコンテキストに応じて自動で呼び出してくれる点です。一度登録すれば、必要な場面で勝手に動き出すという感覚に近いです。
使い始めて最初に気づくのは、スキルの価値は精度より再現性にあるということです。毎回ゼロから指示するより、一度作ったスキルを呼び出すほうが、失敗も減りますしメンタルコストも下がります。考えなくていい作業に頭を使わなくてすむ、というのが一番大きな変化です。
スキルには3つの配置場所があります。それぞれ用途が異なるので、最初に整理しておくと迷いません。
- プロジェクトスキル: リポジトリの .claude/skills に置く。そのプロジェクト固有の手順やルールを標準化するのに使います
- ユーザースキル: ~/.claude/skills に置く。どのプロジェクトでも共通で使いたい汎用的な指示に向いています
- スラッシュコマンド: / で明示的に呼び出す形式。自動発動させたくない操作や、意図的に実行タイミングを選びたい作業に適しています
どこに置くかの判断は単純です。そのプロジェクトだけで使うならプロジェクトスキル、どこでも使うならユーザースキルと考えれば間違いありません。スラッシュコマンドは「勝手に動いてほしくない操作」に限定するのがコツです。
SECTION 02
作業標準化 3つの型——どのスキルから作ればいいか
Skills を使い始めると、「何をスキルにすればいいのか」という問いにぶつかります。手当たり次第にスキル化しても管理が煩雑になるだけです。作業を3つの型に分類することで、優先順位が明確になります。
3つの型とは、①品質ゲート型 ②定期実行型 ③外部連携型です。それぞれの型は、作業の性質によって自然に分かれます。判断の流れはシンプルで、以下のように考えます。
- 毎回やる確認作業があるか？ → 品質ゲート型
- 時間をトリガーにして動かしたい作業があるか？ → 定期実行型
- 外部のAPIやツールを呼び出す必要があるか？ → 外部連携型
この3つの型は排他的ではなく、組み合わせて使うのが実際の運用です。たとえばテスト完了後にデプロイAPIを叩く場合、品質ゲート型と外部連携型が連続します。まずは自分の業務で一番繰り返しが多い作業を見つけ、それがどの型に当てはまるかを考えるところから始めるのがおすすめです。
これまでの経験から言えるのは、最初に作るべきは品質ゲート型だということです。レビューやテストは毎回必ず発生しますし、手順のブレが品質に直結します。ここをスキルで固めると、開発サイクル全体が安定します。
定期実行型と外部連携型は、品質ゲート型が安定してから着手しても遅くありません。焦って全部を一度にスキル化しようとしないのが、長続きするコツです。
SECTION 03
型① 品質ゲート型——レビュー・テスト・確認を半自動で回す
品質ゲート型は、タスク完了後の確認サイクルを自動化するスキルです。実際に運用しているのは、タスクの規模に応じて自動でプランモードを使うスキル、作業完了後に code-improver エージェントでレビューさせるスキル、その後 test-verifier でテストと確認を行うスキルの3つです。これを組み合わせると、タスクを投げた後の確認が半自動で回り始めます。
以前は「改善した → 動作確認 → また修正指示」という直列作業を全部自分が仲介していました。スキルとサブエージェントを組み合わせることで、AIが改善案を出し、そのまま自ら改善し、テストまで走るというループが内側で回る感覚に変わりました。自分がやることは意思決定と確認だけです。
品質ゲート型スキルの設計で重要なのは、各ステップを単一責任で分けておくことです。「レビューもテストもスクショも全部やるスキル」を1つ作ると、途中で止めたいときに困ります。
- レビュースキル: コードの正確性・セキュリティ・可読性を確認する
- テストスキル: 実行結果の検証とスクリーンショット撮影を行う
- 申請スキル: ストア申請やデプロイの手順を実行する
App Store への申請やデプロイ周りも、あらかじめプログラムで作っておいてスキルから呼び出す形にしています。手順書をドキュメントに書くのではなく、スキルとして登録することで、手順のブレがなくなります。誰がいつ実行しても同じ結果になる、というのが品質ゲート型の最大の強みです。
このパターンが回り始めると、開発がコードを書く作業から、方向を定める作業へと移行していく感覚があります。設計判断やアーキテクチャに集中できる時間が増えるのは、スキル化の一番わかりやすい恩恵です。
SECTION 04
型② 定期実行型——情報収集・レポートを時間で回す
定期実行型は、時間をトリガーにして決まった作業を自動で動かすスキルです。個人ツールとしてのスキル活用で一番気に入っているのは、デイリーメールの自動化です。サブエージェント、スキル、CLI を組み合わせて、AdMob・YouTube・X・note・RSS など複数の情報ソースを読み込ませたメールを毎日自動送信する仕組みを作りました。
Claude Code Cowork（定期実行の仕組み）を使えば、朝昼夜など決まった時間にニュースを収集してDiscordへ配信するといった運用も可能です。たとえばニュースサイトやRSSフィードを情報ソースとして指定し、自分の関心領域でフィルタリングして、チャンネルに投稿するスキルを組めます。
定期実行型スキルを設計するときのポイントは3つあります。
- 情報ソースの明確な指定: 何を読み込むかをスキル内に列挙しておく。曖昧にすると毎回違う結果になります
- 配信チャネルの固定: メール、Discord、Slackなど出力先を決めておく
- パーソナライズ条件の設定: 自分が興味ある領域や優先度の基準を書いておくと、ノイズが減ります
自分がXでツイートした内容をもとに、自動で記事を生成してくれる機能も定期実行型の応用です。これは誰かに使わせるためのものではなく、自分専用のワークフローとして運用しています。定型作業を片っ端からスキルに落とし込んでいくと、「いままで自分がやっていたこと」が丸ごと自動化されていく感覚があります。
定期実行型は一度セットアップすれば放置で回り続けるのが魅力ですが、情報ソースの変更やAPI仕様の変更には注意が必要です。月に一度はスキルの出力を確認して、期待通りの結果が出ているかチェックする習慣をつけておくと安心です。
SECTION 05
型③ 外部連携型——API・画像生成・メール送信をスキルに落とす
外部連携型は、外部のAPIやサービスをスキル経由で呼び出すパターンです。たとえば NanoBanana という画像生成サービスのAPIをスキル登録して、Claude Code から直接呼び出せるようにしています。ストア申請・デプロイ・画像生成・メール送信——手順が決まっている外部連携はスキルに落とし込んで、考える仕事だけ自分に残す切り分けです。
ここで「MCP（Model Context Protocol）を使えばいいのでは」と思うかもしれません。しかし現時点では、MCPはいったん保留にしています。理由はシンプルで、勝手にいろんなところに接続されて予期しない破壊が起きるのが怖いからです。
スキルの良さは、呼び出し方が明示的で、何が起きるかが自分でわかっている点です。MCPは便利そうな反面、まだどこまで任せていいか判断しにくいというのが正直な感覚です。スキルとサブエージェントで制御できる範囲でやっておいて、必要なら個別にプログラムで接続するスタンスにしています。
外部連携型スキルの設計ポイントは以下の通りです。
- 呼び出しの明示性: 何のAPIを叩くのか、スキル内に明記する。暗黙の接続を作らない
- 影響範囲の限定: 1つのスキルが触る外部サービスは1つに絞る。複数サービスをまたぐ場合はスキルを分ける
- エラー時の挙動を定義: API障害時にどう振る舞うかをスキル内に書いておく
外部連携型で大切なのは、「自分が何を実行しているか常に把握できる状態」を保つことです。自動化が進むほど、ブラックボックスになりがちです。スキルの中身を読めば何が起きるかわかる、という透明性が信頼につながります。
SECTION 06
スキルが思い通りに動かないときの対処法
スキルを作ったのに期待通りに呼び出されない、あるいは意図しないタイミングで発動してしまう——これは多くの人がぶつかる問題です。原因のほとんどは、スキルファイルの description の書き方にあります。Claude Code はこの description を見て、コンテキストに合うスキルを自動で選んでいます。
description が曖昧だと、似たような場面で別のスキルが呼ばれたり、本来呼ばれるべき場面でスルーされたりします。対策はシンプルで、「このスキルはいつ使うのか」「何をするのか」を具体的に書くことです。「コードを改善する」ではなく「タスク完了後にセキュリティ・可読性・パフォーマンスの観点でレビューする」くらいの粒度が必要です。
もう一つよくある失敗は、スキルの粒度の問題です。大きすぎるスキルと細かすぎるスキルには、それぞれ別の問題が起きます。
- 大きすぎるスキル: 「レビュー＋テスト＋デプロイ」を1つに詰め込むと、途中で止められない。部分的な再利用もできなくなる
- 細かすぎるスキル: 「変数名チェック」「インデント確認」のように分けすぎると、管理コストが爆発する。どれを呼べばいいかわからなくなる
単一責任で分割し、組み合わせて使うのが現実的な解です。レビューはレビュー、テストはテスト、デプロイはデプロイ。それぞれ独立したスキルとして作り、必要に応じて連続で呼び出す設計にしておくと、柔軟性と管理のバランスが取れます。
スラッシュコマンド呼び出しと自動呼び出しの使い分けも重要です。破壊的な操作や外部への影響がある作業は、スラッシュコマンドで明示的に実行するのが安全です。レビューやテストのように毎回走らせたい作業は自動呼び出しに任せ、デプロイやストア申請は /deploy のようにコマンドで叩く、という切り分けが実用的です。
SECTION 07
スキル設計で押さえておきたい実務のコツ
3つの型を理解した上で、スキルを実際に書くときの設計原則を整理しておきます。スキルはMarkdownファイルに指示を書くだけのシンプルな仕組みですが、書き方次第で使い勝手が大きく変わります。
まず、スキルファイルの冒頭に description を明確に書くことが最重要です。Claude Code はこの記述をもとにスキルの適用可否を判断します。「いつ使うか」「何をするか」「何をしないか」の3点を短く書いておくだけで、誤発動が大幅に減ります。
次に、スキル内の指示は手順書ではなく「ゴールと制約」で書くのがコツです。「ステップ1でこれをやり、ステップ2でこれをやり……」と細かく手順を書くより、「最終的にこうなっていること」「やってはいけないこと」を明示するほうが、Claude Code の柔軟性を活かせます。
- 良い例: 「テストが全件パスし、カバレッジが低下していないことを確認する。UIの変更がある場合はスクリーンショットを撮影する」
- 悪い例: 「まず npm test を実行し、次に結果をパースし、エラーがあれば修正案を出し……」
また、スキル同士の依存関係はできるだけ作らないようにします。「スキルAが終わったらスキルBを呼ぶ」という連鎖は、claude.md やワークフロー側で制御するほうが見通しが良くなります。スキル単体は独立して動作し、組み合わせは上位の設定で管理する——この分離が運用を楽にします。
最後に、スキルは作って終わりではなく育てるものです。最初から完璧なスキルを目指すより、まず動くものを作り、実際に使いながら description や指示を微調整していくほうが結果的に早く仕上がります。
SECTION 08
個人からチームへ——スキルを「環境ごと渡す」発想
スキルを個人で使い込んでいくと、ある時点で気づくことがあります。いまの自分の claude.md、メモリ、サブエージェント、スキルは全部が組み合わさって初めて回っているということです。レビューからテスト、スクリーンショット確認まで一気通貫で動くのは、個々のスキルではなく環境全体の設計があるからです。
ここから自然に生まれるのが、スキル単体ではなく環境ごと手渡すという発想です。新しいメンバーが同じ開発環境をセットアップするとき、claude.md とスキルファイル一式をコピーするだけで、同じワークフローが再現できる。これはドキュメントを読んで手順を覚えてもらうのとは、まったく違うオンボーディング体験になります。
ただし、チーム展開には個人利用とは異なる実務論点が出てきます。
- 命名規則: スキルが増えると名前の衝突や混乱が起きる。review-security、test-e2e のようにプレフィックスで分類するルールが必要です
- バージョン管理: スキルファイルはリポジトリに含めてGitで管理する。変更履歴が追えないと、誰がいつ何を変えたかわからなくなります
- 更新フロー: スキルの改善案が出たとき、誰がどうレビューして反映するかの仕組みを決めておく必要があります
個人の改善をチームのスキルへ還元する仕組みがないと、運用が属人化しやすいのも注意点です。「Aさんのスキルは動くけどBさんのは古いまま」という状況は、スキルの数が増えるほど起きやすくなります。定期的にスキルの棚卸しをする習慣を作っておくと、この問題を防げます。
将来的には、Claude Code で作ったスキルやサブエージェントを共有・販売できるマーケットが生まれるかもしれません。コードの次に売れるものが「AIへの指示の仕方」になる時代が来る可能性を考えると、いまスキルを作り込んでおくことは、自分の知見を資産化する行為とも言えます。
SECTION 09
まず最初の1つを作る——始め方のステップ
ここまで3つの型と設計原則を紹介してきましたが、一番大事なのは最初の1つを作ることです。完璧な設計を目指して構想だけ膨らませるより、今日使える小さなスキルを1つ動かすほうが学びは大きいです。
おすすめの始め方は、自分が一番よく打つ指示をそのままスキルファイルに書くことです。「コードをレビューして、セキュリティと可読性を確認して」と毎回打っているなら、それをそのまま .claude/skills/review.md に保存するだけで最初のスキルが完成します。
スキルファイルの基本構造はシンプルです。
- ファイル名: やりたいことが伝わる名前をつける（例: review.md、test-e2e.md）
- description: 冒頭にこのスキルがいつ・何をするかを1〜2行で書く
- 本文: Claude Code への指示をそのまま書く。特別な文法は不要です
最初のスキルが動いたら、1週間ほど使ってみて description を調整するのが次のステップです。意図しないタイミングで発動したら description を具体的にし、呼ばれるべき場面でスルーされたら条件を広げます。この微調整のサイクルが、スキルの質を上げていきます。
これまで多くのサービスを作ってきた経験から言えるのは、ツールの導入で一番効果が出るのは「最初の小さな成功体験」を早く得ることです。スキルも同じで、1つ目が便利だと実感できれば、2つ目以降は自然と増えていきます。まずは品質ゲート型のレビュースキルから始めてみてください。
SECTION 10
スキルは「指示」ではなく「インフラ」になる
Skills を使い始めた当初は、便利なショートカットくらいの認識でした。しかし運用を続けるうちに、スキルは単なる指示の短縮ではなく、開発ワークフローのインフラだと感じるようになっています。
スキルが「インフラ」だと言えるのは、それがなくなると開発が回らなくなるからです。レビュースキルを外せば品質チェックが手動に戻り、定期実行スキルを外せば情報収集が止まります。最初は補助ツールだったものが、いつの間にか開発プロセスの土台になっている——これがスキルの本質的な変化です。
「スキルとは何のためにあるか」という問いに対する答えは、定型作業をエージェントに委譲し、自分はアーキテクチャや設計判断に集中するためです。コーディングを速くするというより、「決まりきった作業を自分の手から外す」仕組みとして機能しています。
試行錯誤の中で見えてきたのは、スキルへの関心が「発見して使う」から「自分で作り、育て、渡す」へと移行しているという流れです。既製のスキルを試す段階から、プロジェクト固有のルールや手順をパッケージ化する自作スキルの段階へ。この移行を意識的に進められるかどうかが、スキル活用の分かれ目になります。
スキルは、コードと同じように書いて、テストして、改善して、共有するものです。最初の1つを作り、3つの型で整理し、チームに展開していく。その過程で、開発の重心が「手を動かす作業」から「仕組みを設計する作業」へと確実にシフトしていきます。
