スキルは、Claude Code の最もよく使われる拡張ポイントの 1 つになりました。スキルは柔軟で、簡単に作成でき、配布もシンプルです。
しかし、その柔軟性ゆえに、何が最適なのかを判断するのが難しくなっています。どのようなタイプのスキルを作る価値があるのか？良いスキルを書く秘訣は何か？いつ他の人と共有すべきか？
Anthropic では、Claude Code でスキルを幅広く活用しており、数百ものスキルが実際に使用されています。ここでは、開発を加速するためにスキルを活用して学んだ教訓を紹介します。
スキルとは？
スキルについて初めて知る方は、ドキュメントを読むか、Skilljar のエージェント スキルに関する新しいコースをご覧になることをお勧めします。この記事では、スキルについてある程度の知識があることを前提としています。
スキルに関するよくある誤解は、それが「単なる Markdown ファイル」であるというものですが、スキルの最も興味深い点は、単なるテキストファイルではないということです。スキルは、エージェントが発見、探索、操作できるスクリプト、アセット、データなどを含むフォルダーです。
Claude Code では、スキルにはさまざまな設定オプションがあり、動的なフックの登録も含まれます。
Claude Code で最も興味深いスキルのいくつかは、これらの設定オプションとフォルダー構造を創造的に活用していることがわかりました。
スキルのタイプ
すべてのスキルをカタログ化した結果、いくつかの繰り返し発生するカテゴリに分類されることに気づきました。最も優れたスキルは、これらのカテゴリのいずれかにきれいに当てはまります。逆に、わかりにくいスキルは複数のカテゴリにまたがっています。これは決定的なリストではありませんが、組織内で不足しているスキルがないかを考えるのに適した方法です。
1. ライブラリ & API リファレンス
ライブラリ、CLI、SDK を正しく使用する方法を説明するスキル。これらは、内部ライブラリと、Claude Code が時々うまく扱えない一般的なライブラリの両方に使用できます。これらのスキルには、多くの場合、リファレンス コード スニペットのフォルダーと、Claude がスクリプトを作成する際に避けるべき落とし穴のリストが含まれています。
例：
- billing-lib — 内部の請求ライブラリ：エッジケース、注意点など
- internal-platform-cli — 内部 CLI ラッパーのすべてのサブコマンドと、それらの使用タイミングの例
- frontend-design — Claude をデザイン システムに習熟させる
2. 製品検証
コードが正しく動作しているかをテストまたは検証する方法を説明するスキル。これらは多くの場合、検証を実行するための Playwright、tmux などの外部ツールと組み合わせて使用されます。
検証スキルは、Claude の出力が正しいことを確認するために非常に役立ちます。エンジニアが 1 週間かけて検証スキルを磨く価値は十分にあります。
Claude に出力のビデオを録画させてテスト内容を正確に確認できるようにしたり、各ステップでプログラムによるアサーションを実行したりする手法を検討してください。これらは、スキルにさまざまなスクリプトを含めることで実現されることが多いです。
例：
- signup-flow-driver — ヘッドレス ブラウザでサインアップ → メール確認 → オンボーディングを実行し、各ステップで状態をアサートするフックを備える
- checkout-verifier — Stripe のテストカードを使用してチェックアウト UI を操作し、請求し、実際に請求書が正しい状態になることを検証する
- tmux-cli-driver — 検証対象が TTY を必要とするインタラクティブな CLI テスト向け
3. データ取得 & 分析
データとモニタリング スタックに接続するスキル。これらのスキルには、認証情報を使用してデータを取得するためのライブラリ、特定のダッシュボード ID、一般的なワークフローやデータ取得方法に関する手順などが含まれる場合があります。
例：
- funnel-query — 「サインアップ → アクティベーション → 課金」を確認するためにどのイベントを結合するか、そして実際に正規のユーザー ID を持つテーブル
- cohort-compare — 2 つのコホートの保持率またはコンバージョンを比較し、統計的に有意な差異にフラグを立て、セグメント定義にリンクする
- grafana — データソース UID、クラスター名、問題 → ダッシュボードのルックアップ テーブル
4. ビジネス プロセス & チーム自動化
繰り返し発生するワークフローを 1 つのコマンドに自動化するスキル。これらのスキルは通常、比較的シンプルな指示ですが、他のスキルや MCP に依存する場合があり、より複雑になることもあります。これらのスキルでは、以前の結果をログ ファイルに保存することで、モデルが一貫性を維持し、ワークフログを維持し、ワークフローの以前の実行を振り返るのに役立ちます。
例：
- standup-post — チケット トラッカー、GitHub アクティビティ、以前の Slack メッセージを集約し、差分のみのフォーマット済みスタンドアップ投稿を作成する
- create-<ticket-system>-ticket — スキーマ（有効な enum 値、必須フィールド）を適用し、作成後のワークフロー（レビュアーへの ping、Slack でのリンク共有）を実行する
- weekly-recap — マージされた PR、クローズされたチケット、デプロイを集約し、フォーマット済みの週間レポートを作成する
5. コード スキャフォールディング & テンプレート
コードベース内の特定の機能向けにフレームワークのボイラープレートを生成するスキル。これらのスキルは、構成可能なスクリプトと組み合わせることができます。スキャフォールディングに、コードだけでは完全にカバーできない自然言語の要件がある場合に特に役立ちます。
例：
- new-<framework>-workflow — アノテーション付きで新しいサービス、ワークフロー、ハンドラーをスキャフォールディングする
- new-migration — 移行ファイルのテンプレートと一般的な落とし穴
- create-app — 認証、ログ、デプロイ設定があらかじめ組み込まれた新しい内部アプリ
6. コード品質 & レビュー
組織内のコード品質を強化し、コードのレビューを支援するスキル。最大限の堅牢性を実現するために、決定論的なスクリプトやツールを含めることができます。これらのスキルは、フックの一部として、または GitHub Action 内で自動的に実行することもできます。
- adversarial-review — 新しい視点を持つサブエージェントを起動して批評し、修正を実装し、指摘事項が細かい点だけになるまで反復する
- code-style — コードスタイルを適用する。特に Claude がデフォルトではうまく処理できないスタイルに効果的。
- testing-practices — テストの書き方と何をテストすべきかについての指示。
7. CI/CD & デプロイ
コードベース内でコードの取得、プッシュ、デプロイを支援するスキル。これらのスキルは、データを収集するために他のスキルを参照する場合があります。
例：
- babysit-pr — PR を監視 → 不安定な CI を再試行 → マージ競合を解決 → 自動マージを有効にする
- deploy-<service> — ビルド → スモークテスト → 段階的なトラフィック ロールアウトとエラー率の比較 → 後退時は自動ロールバック
- cherry-pick-prod — 隔離されたワークツリー → cherry-pick → 競合解決 → テンプレート付き PR
8. ランブック
症状（Slack スレッド、アラート、エラーシグネチャなど）を受け取り、複数のツールを使った調査を実施し、構造化されたレポートを生成するスキル。
例：
- <service>-debugging — トラフィックの多いサービスに対して、症状をツールやクエリパターンにマッピングする
- oncall-runner — アラートを取得 → 原因として疑わしい箇所を確認 → 調査結果をフォーマットする
- log-correlator — リクエスト ID が与えられると、そのリクエストに関与した可能性のあるすべてのシステムから一致するログを取得する
9. インフラ運用
定期的なメンテナンスや運用手順を実行するスキル。中には、ガードレールがあると便利な破壊的なアクションを含むものもあります。これにより、エンジニアは重要な運用においてベスト プラクティスに従いやすくなります。
例：
- <resource>-orphans — 孤立した Pod やボリュームを見つけ → Slack に投稿 → 待機期間 → ユーザー確認 → 段階的なクリーンアップ
- dependency-management — 組織の依存関係承認ワークフロー
- cost-investigation — 特定のバケットとクエリパターンを用いて「ストレージ/出力コストが急増した理由」を調査する
スキル作成のヒント
作成するスキルを決めたら、どのように書けばよいのでしょうか？ここでは、私たちが見つけたベスト プラクティス、ヒント、コツをいくつか紹介します。
また、Claude Code でのスキル作成を容易にするために、Skill Creator も最近リリースしました。
自明なことは書かない
Claude Code はコードベースについて多くのことを知っており、Claude はコーディングについて、多くのデフォルトの意見を含めてよく知っています。主に知識に関するスキルを公開する場合は、Claude を通常の考え方から押し出すような情報に焦点を当ててください。
フロントエンド デザイン スキルは良い例です。これは、Anthropic のエンジニアの 1 人が、Inter フォントや紫色のグラデーションといった古典的なパターンを避けパターンを避け、Claude のデザインセンスを向上させるために顧客と繰り返し対話しながら構築したものです。
落とし穴セクションを作成する
どのスキルでも最も価値の高いコンテンツは、落とし穴セクションです。このセクションは、スキルを使用する際に Claude が直面する一般的な失敗ポイントから構築する必要があります。理想的には、時間の経過とともにスキルを更新して、これらの落とし穴を捉えていくことです。
ファイル システムと段階的な開示を利用する
先ほど述べたように、スキルはフォルダーであり、単なる Markdown ファイルではありません。ファイル システム全体を、コンテキスト エンジニアリングと段階的な開示の一形態として考える必要があります。スキルにどのようなファイルがあるかを Claude に伝えると、Claude は適切なタイミングでそれらを読み込みます。
段階的な開示の最もシンプルな形式は、Claude が使用する他の Markdown ファイルを参照することです。例えば、詳細な関数シグネチャと使用例を references/api.md に分割することができます。
別の例としては、最終出力が Markdown ファイルである場合、コピーして使用するためのテンプレートファイルを assets/ に含めることが考えられます。
リファレンス、スクリプト、例などのフォルダーを用意することで、Claude の作業効率を向上させることができます。
Claude を過度に誘導しない
Claude は通常、指示に従おうとします。スキルは再利用可能であるため、指示を具体化しすぎないように注意する必要があります。Claude に必要な情報を提供しつつ、状況に適応できる柔軟性を与えてください。例えば：
セットアップを検討する
一部のスキルでは、ユーザーからのコンテキストを使ってセットアップが必要な場合があります。例えば、スタンドアップを Slack に投稿するスキルを作成する場合、Claude にどの Slack チャンネルに投稿するかを尋ねさせるとよいでしょう。
これを行うための良いパターンは、上記の例のように、この設定情報をスキルディレクトリ内の config.json ファイルに保存することです。設定がされていない場合、エージェントはユーザーに情報を尋ねることができます。
エージェントに構造化された多肢選択式の質問を提示させたい場合は、AskUserQuestion ツールを使用するように Claude に指示できます。
説明フィールドはモデルのためのもの
Claude Code がセッションを開始すると、利用可能なすべてのスキルとその説明の一覧を作成します。この一覧を Claude がスキャンして、「このリクエストに適したスキルはあるか」を判断します。つまり、説明フィールドは概要ではなく、この PR をトリガーするタイミングの説明です。
メモリとデータの保存
一部のスキルは、内部にデータを保存することで、一種のメモリを含めることができます。データは、単純な追記専用テキストログファイルや JSON ファイルから、SQLite データベースのような複雑なものまで、さまざまな形式で保存できます。
例えば、standup-post スキルは、作成したすべての投稿を含む standups.log を保持できます。これにより、次回実行時に Claude は自身の履歴を読み取り、前回から何が変わったかを把握できます。
スキルディレクトリに保存されたデータは、スキルをアップグレードすると削除される可能性があります。そのため、データは安定したフォルダに保存する必要があります。現在、データを保存するための安定したフォルダとして、プラグインごとに ${CLAUDE_PLUGIN_DATA} を提供しています。
スクリプトを保存し、コードを生成する
Claude に与えられる最も強力なツールの 1 つはコードです。Claude にスクリプトやライブラリを与えることで、Claude はターンを作成に費やし、ボイラープレートを再構築する代わりに次に何をするかを決定できるようになります。
例えば、データ サイエンス スキルでは、イベントソースからデータを取得する関数のライブラリを持つことができます。Claude が複雑な分析を行うために、次のようなヘルパー関数のセットを与えることができます：
Claude は、「火曜日に何が起こった？」といったプロンプトに対して、より高度な分析を行うために、この機能を構成するスクリプトをその場で生成できます。
オンデマンド フック
スキルには、スキルが呼び出されたときにのみアクティブになり、セッション中持続するフックを含めることができます。これは、常に実行する必要はないが、時々非常に役立つ、より意見のあるフックに使用します。
例えば：
- `/careful` — Bash の PreToolUse マッチャーを介して、
rm -rf、DROP TABLE、force-push、kubectl deleteをブロックします。本番環境に触れていることがわかっている場合にのみこれが必要です。常にオンにしておくと、気が狂いそうです。 - `/freeze` — 特定のディレクトリ以外での編集や書き込みをブロックします。デバッグ中に「ログを追加したいが、関係のないものを誤って修正してしまう」場合などに便利です。
スキルの配布
スキルの最大の利点の 1 つは、チームの他のメンバーと共有できることです。
スキルを他の人と共有するには、主に 2 つの方法があります：
- スキルをリポジトリにチェックインする (
./.claude/skills配下) - プラグインを作成し、ユーザーがプラグインをアップロードしてインストールできる Claude Code プラグイン マーケットプレイスを設置する（詳細はドキュメントをご覧ください）
比較的少数のリポジトリで作業する小規模なチームの場合、スキルをリポジトリにチェックインする方法がうまく機能します。しかし、チェックインされたすべてのスキルは、モデルのコンテキストに少しずつ追加されます。規模が大きくなるにつれて、内部プラグイン マーケットプレイスを使用することで、スキルを配布し、チームがどのスキルをインストールするかを決定できるようになります。
マーケットプレイスの管理
どのスキルをマーケットプレイスに掲載するかをどのように決定しますか？どのようにして人々がスキルを提出できますか？**
決定するための集中管理チームはありません。代わりに、最も有用なスキルを有機的に見つけようとしています。人々に試してもらいたいスキルがある場合は、GitHub のサンドボックス フォルダにアップロードし、Slack やその他のフォーラムで人々に紹介することができます。
スキルが注目を集めたら（これはスキル所有者が判断します）、マーケットプレイスに移動するための PR を作成できます。
注意点として、質の低いスキルや重複するスキルは簡単に作成できてしまうため、リリース前に何らかのキュレーション方法を確実にしておくことが重要です。
スキルの構成
互いに依存するスキルを作成したい場合もあります。例えば、ファイルをアップロードするスキルと、CSV を生成してアップロードするスキルがあるとします。この種の依存関係管理は、まだマーケットプレイスやスキルにネイティブに組み込まれていませんが、他のスキルを名前で名を参照するだけで、モデルはそれらがインストールされていれば呼び出します。
スキルの測定
スキルのパフォーマンスを把握するために、社内でのスキル使用状況を記録できる PreToolUse フックを使用しています（コード例はこちら）。これにより、人気のあるスキルや、期待に比べてトリガーが少ないスキルを見つけることができます。
結論
スキルは、エージェントにとって非常に強力で柔軟なツールですが、まだ初期段階であり、最適な使用方法は誰もが模索しているところです。
これを、決定的なガイドというよりも、実際に効果が見られた便利なヒント集と考えてください。スキルを理解する最善の方法は、実際に始めて、実験し、自分にとって何が効果的かを見つけることです。私たちのスキルのほとんどは、数行のコードと 1 つの落とし穴から始まり、Claude が新しいエッジケースに遭遇するたびに人々が追加していくことで、より良いものになりました。
お役に立てれば幸いです。ご質問があればお知らせください。
