Chapter 13

第13章: スキルとスラッシュコマンド ─ プロンプトを部品にする

日常的に Claude Code を使っていると、同じ指示を何度も打っていることに気づく。

「コードレビューして。観点は責務分離、命名、テストの抜け、セキュリティ」 「この PR の概要を、commits を見ながら 3 行で書いて」 「今日の作業を CHANGELOG.md に追記して、Conventional Commits 形式で」

同じプロンプトを毎日コピペする ── これはソフトウェア工学の原則からすると、明らかに 関数化されるべき 場面だ。

「コードレビューしてくれ」を /review 一発で呼びたい。 さらに大きな「方法論一式」も束ねたい。Claude Code はその両方に答えを持っている。

13.1 そもそも、プロンプトを再利用したい

前章の MCP は「外の世界と繋ぐ」道具だった。 だがエージェント運用の現場で増えていく不満は、外部接続だけではない。

同じプロンプトを何度も打ち直したくない ── これも切実な悩みだ。

第5章で見たとおり、LLM の挙動はプロンプトに強く依存する。 「責務分離・命名・テストの抜け・セキュリティの順で見て、指摘は引用付きで」── こういう 指示の細かい組み合わせ が良い結果を生む。 だがその細かい組み合わせを毎回手で打つのは、人間の頭に優しくない。

良いプロンプトは “資産”。 資産を毎回その場で書き直すのは、関数を毎回コピペで書き直すのと同じ。 プロンプトもコードと同じく、名前を付けて、再利用可能な部品 にすべきだ。

Claude Code は、この「プロンプトの部品化」を 二段構え で提供する。 小さい部品が スラッシュコマンド、大きい部品が スキル だ。

13.2 スラッシュコマンド ── 動詞 1 個の置き換え

まず小さいほうから。 スラッシュコマンド は、ユーザーが / で始まる名前で呼ぶ短い指示の置換だ。 公式が用意した /clear /compact /init などが代表例で、これらは Claude Code 本体に組み込まれている（第Ⅱ部で詳述）。

そして、自分でも作れる。 .claude/commands/<name>.md に Markdown でプロンプトテンプレートを書くだけ。

たとえば .claude/commands/review.md に次のように書く:

変更されたファイルを次の観点でレビューしてください:
1. 責務分離 ── 1 関数 1 責務になっているか
2. 命名 ── 概念と一致しているか
3. テスト ── 抜けはないか
4. セキュリティ ── 入力検証は妥当か

指摘は必ずファイル名と該当行の引用とセットで報告すること。

これを保存しておけば、以降は Claude Code 内で /review と打つだけで、上の指示文がそのまま LLM に送られる。

スラッシュコマンド

/ で始まる名前で呼び出せる、プロンプトテンプレートのショートカット。 公式コマンド (/clear 等) と、ユーザーが .claude/commands/<name>.md に置く カスタム slash command の二種類がある。

引数や bash 実行、ファイル参照も書ける。たとえば:

PR 番号: $ARGUMENTS

次の手順で PR レビューを行ってください:
1. `gh pr view $ARGUMENTS --json title,body,files` で PR の概要を取得
2. 変更ファイルを順にレビュー（観点は責務分離・命名・テスト・セキュリティ）
3. レビュー結果を Markdown でまとめる

これで /review-pr 1234 のように引数付きで呼べる ── プロンプトが、ほぼ シェルスクリプトのような部品 になる。

13.3 スキル ── 方法論 1 セットを束ねる

スラッシュコマンドが「動詞 1 個」だとすれば、もう一段大きい部品が スキル だ。 スキルは「方法論 1 セット」── 複数のドメイン知識・手順・例・参照ファイルを束ねたパッケージ。

たとえば「半導体テーマの章を書くときの作法」を考えてほしい。 これは 1 行のプロンプトでは到底収まらない。動機先行のルール、未定義語追放のルール、章末のテンプレート、検証手順、過去のアンチパターン ── ぜんぶをまとめて一つの 方法論 として扱いたい。

そういうとき、.claude/skills/<name>/SKILL.md に長めの Markdown を書く。 SKILL.md の冒頭には トリガー (description) が書かれていて、ここに「いつこのスキルを読むべきか」を自然言語で書いておく。

---
name: tomokaku-writing
description: 「ともかく入門」サイトで教科書スタイルの章を書く・直すときの作法。
  新章を執筆するとき、既存章をリライトするとき、章間の整合性をレビューするときに
  必ず参照する。動機先行・未定義語追放・冗長排除・章間飛躍防止を最優先する。
---

# スキル本体（数百行のドメイン知識・ルール・テンプレート）
...
スキル (Skill)

.claude/skills/<name>/SKILL.md に置かれる、再利用可能な方法論のパッケージ。 ドメイン知識・手順・例・参照ファイルを束ねた長文プロンプト。 description (トリガー) を見て、Claude Code が 必要なタイミングで動的に本体を読み込む。

ここで構造の違いに気づいてほしい。スラッシュコマンドは .claude/commands/<name>.md という 単独ファイル で済むのに対し、スキルは .claude/skills/<name>/ という ディレクトリ を切る。これは形式上の趣味ではなく、スキルが補助スクリプト・参照テンプレート・サンプルデータといったリソースファイルを伴うことが多いから だ。SKILL.md から ./templates/chapter.md や ./scripts/validate.sh を参照する、といった構成が当たり前に出てくるので、最初から「フォルダごと 1 つのスキル」として扱う設計になっている。

13.4 トリガー読み込み ── context を節約する設計

スキルとスラッシュコマンドには、設計上の決定的な違いがある。

スラッシュコマンドはユーザーが打って初めて発動する。打たれない限り context に何も影響しない。

スキルは “トリガー読み込み” だ。 仕組みはこう動く:

  1. Claude Code 起動時、各スキルの description (短いトリガー文) だけ を一覧として LLM に渡す
  2. ユーザーから「半導体の第5章を書き直して」のような依頼が来る
  3. LLM はトリガー一覧を見て、「これは tomokaku-writing スキルが関連する」と判断
  4. そのスキルを呼ぶと、SKILL.md 本体 (数百行) が読み込まれて context に追加される
  5. その方法論に従って作業が進む

スキルが偉いのは、普段は description 数行しか context に乗っていない こと。 必要になった瞬間だけ、本体の数百行が呼び出される。

これは第4章 (context window) の有限性に対する、遅延読み込み (lazy loading) のアプローチ だ。 何十個のスキルを登録していても、起動時の context 圧迫はわずかで済む。

逆に、MCP server の tool list は 起動時から全部 system prompt に乗る。 ここがスキルと MCP の決定的な設計差で、用途が違うことの根拠でもある。

13.5 三者の住み分け ── コマンド / スキル / MCP

ここまでで、Claude Code を拡張する三つの軸が出揃った。 頭の中で混ざりやすいので、一枚の図で並べておく。

スラッシュコマンド動詞 1 個/review/summarize-pr 1234.claude/commands/*.md短いプロンプト置換ユーザーが明示的に呼ぶスキル方法論 1 セットtomokaku-writingmy-archi-guardrail.claude/skills/*/SKILL.md長文の知識+手順+例LLM がトリガーで自動読込MCP server外部接続gmail-mcpchrome-devtoolsプロトコル経由のサーバTool / Resource / Prompttool list は常時 context解いている問題が違う「指示を短く呼ぶ」「方法論を再利用する」「外の世界に触る」
図 13.1 — Claude Code 拡張の三層。それぞれが解いている問題は別物で、どれかが他を代替するわけではない。

実用の場面ではこの三つが 同じセッションで同時に動く ことが多い。

たとえば「Gmail から先週の問い合わせを集計してレポートにまとめる」という依頼なら:

それぞれが担う役割が違うので、混ざらずに 積層的に効く。

13.6 落とし穴 ── 何でもスキルにしない

スキルは強力だが、注意点もある。

何でもスキルにすると、トリガーが乱雑になり、LLM がどれを選ぶか迷い始める。 description が曖昧だったり、似たような名前が並んだりすると、必要なスキルが呼ばれなかったり、関係ないスキルが呼ばれたりする。

ガイドラインはシンプルだ:

迷ったときは「これは 動詞 か、それとも 方法論 か」と自問するのが早い。

試しに、自分が直近一週間で Claude Code に同じ指示を 3 回以上打ったプロンプトを思い出してほしい。 それは コマンド化の最有力候補 だ。

さらにその指示の中に「これは状況によって判断する」「複数の手順を踏む」「失敗パターンを避ける」のような要素があれば、スキル化 を検討すべき。

13.7 自作の積み重ねが、自分専用のエージェントになる

公式コマンドや既存スキルは便利だが、本当に効くのは 自分のチーム・自分のプロジェクトに固有の部品 だ。

これらを少しずつ .claude/commands/ と .claude/skills/ に貯めていくと、Claude Code は 自分専用にチューニングされた助手 に育っていく。

そして次章で扱う通り、Claude Code 自身に「この作業からスキルを抽出して、SKILL.md として書き出して」と頼むこともできる。 エージェントが、自分が後で再利用するための部品を、自分で書く ── ここから自己改善ループが回り始める。

スキルを書き始めると、不思議な感覚が湧いてくる。 プロンプトを書いている のではなく、自分の暗黙知を言語化している ような感覚だ。

「責務分離・命名・テストの抜け・セキュリティの順で見る」── これは自分が普段やっているコードレビューの手順を、初めて文字に起こした瞬間でもある。 スキルファイルが増えていくほど、自分の頭の中の方法論が外部化されていく。

これは AI のためというより、自分自身が思考を整理するための副産物 でもある。

この章の振り返り

この章で読めるようになるツイート / ブログ

次章は、本書のクライマックスのひとつ ── 自己改善ループ に踏み込む。 本章で書いたスキルやコマンドを、Claude Code 自身が拡張・更新する ようになる、その仕組みと実例だ。