Claudeのスキル・スラッシュコマンド・サブエージェント比較

目次

2026年8月更新。

TL;DR： スラッシュコマンドは、よく使うプロンプトの省略形だ——名前を指定して自分で呼び出す。サブエージェントは独自のコンテキストウィンドウを持つ並列ワーカーで、範囲が明確なタスクのために自分（またはClaude）が起動し、結果を受け取る。スキルはパッケージ化された専門知識で、あなたが何も名指ししなくても、リクエストの内容に応じてClaudeが自分の判断で読み込む。多くの人はスラッシュコマンドで済む場面でカスタムエージェントに手を伸ばし、本当はClaudeが自動で発動できるスキルが必要な場面でスラッシュコマンドに手を伸ばしてしまう。

[オペレーターの視点] 私は2つの事業にまたがって30以上の本番エージェントを運用しているが、「コマンドか、サブエージェントか、スキルか」というこの混同は、そのほぼすべてで最初に突き当たる設計上の問い掛けだ。ここを間違えると、誰も名前を覚えていない10個のコマンドを作ってしまうか、逆に広すぎて確実に発動しない1つのスキルを作ってしまうかのどちらかになる。解決策は経験則ではなく、実行のたびに何が変わるのかを問うことだ。

3つのプリミティブは異なる問題を解決する

3つとも、指示を一度パッケージ化して使い回せるようにする点は共通している。似ているのはそこまでで、それこそが人々が混同する理由でもある——外から見れば「短いものを入力して有用な結果を得る」という点は、裏で何が動いていようと同じに見えるからだ。

本当の違いは、誰がそれを呼び出すと決めるのか、そしてどのコンテキストで実行されるのかだ。

• スラッシュコマンドはあなたが名前を指定して呼び出す。/deploy や /review と入力すると、Claudeがそれをより詳細な指示に展開し、今の会話の中で実行する。
• サブエージェントはあなたまたはClaudeが、境界の明確なタスクのために呼び出す。独自のコンテキストウィンドウを持ち、作業をこなし、結果を報告する——あなたの会話全体は見えず、あなたも求めない限り途中経過は見えない。
• スキルはClaudeが、あなたのリクエストがそのスキルの説明に書かれた対象と一致したときに、自動的に呼び出す。あなたはその名前を一度も入力しない。スキルが扱う内容を求めなければ、それは決して読み込まれない。

その3つ目の性質——明示的な呼び出しがないこと——こそ、人々が最も活用しきれていない部分だ。同時に、パッケージ化したワークフローが数個を超えたときに最もレバレッジが利く部分でもある。何を何という名前にしたか覚えておく必要がなくなるからだ。

スラッシュコマンド：よく使うプロンプトの省略形

「毎回だいたい同じ指示を入力している」ことがきっかけなら、スラッシュコマンドを作るべきだ。あなたが選んだ短い名前から展開され、今行っている会話の中で、常に同じ元のプロンプトに解決されるコマンド。別のコンテキストも、自律的な呼び出しもない——実行するかどうかは毎回あなたが決める。

向いている用途：固定のリリースチェックリスト、自分のハウスルールを組み込んだコードレビュー、「このPRを要約して」というショートカットなど。コマンドは実行すべきかどうかの判断を必要としない——それを決めるのはコマンドを入力するあなた自身だ。

失敗パターンは、本来モデルが「この状況が該当するかどうか」を判断する必要があるものにコマンドを作ってしまうことだ。使い方の半分が「待って、これは該当するのか?」であるなら——それはコマンドの問題ではなくスキルの問題だ。コマンドには自分で自分を発動する手段がないからだ。

サブエージェント：独自のコンテキストウィンドウを持つ並列ワーカー

タスクの範囲が明確で、委任可能で、放っておくと見る必要のないステップでメインの会話を汚してしまう場合には、サブエージェントを作るべきだ。サブエージェントは独自のコンテキスト——独自のツール呼び出し、独自のやり取り——を実行し、結果を返す。これはコンテキストエンジニアリングについて書いた内容と同じ原則だ。追加のツール呼び出しや途中のステップはすべて、メインスレッドが持ち続ける必要のないコンテキストであり、サブエージェントはそのノイズを締め出す手段になる。

向いている用途：「これを調べて報告して」「この5つの独立したチェックを並列で実行して」「このファイルだけ単独で直して」など。タスクには開始があり、終了があり、成果物がある——それはまさに私がエージェントを出荷するために使っている評価ハーネスが単一の採点可能な単位として扱う形だ。

失敗パターンは、次のステップがサブエージェントの要約で落とされた詳細に依存しているために、本来メインコンテキストに残しておくべきだった作業をサブエージェントに投げてしまうことだ。「待って、正確には何を見つけたんだっけ」とサブエージェントに聞き直し続けているなら、境界の引き方が間違っている——メインスレッドに戻すか、翻訳の過程で何も失われないよう、サブエージェントの報告を十分に構造化するかのどちらかだ。

スキル：Claudeが自分の判断で読み込むパッケージ化された専門知識

発動条件が、あなたが名指しして覚えておくべきものではなく、あなたのリクエストからClaudeが認識すべきものであるなら、スキルを作るべきだ。スキルとは説明文に加え、指示とスクリプトの束だ。Claudeが説明文を読み、あなたのリクエストが一致するかを判断し、一致した場合にのみ完全な指示を読み込む。あなたは /skill-name を一度も入力しない。

私が挙げられる最も分かりやすい例は、このブログの背後にあるパイプラインを動かしているものだ。alejandrorioja.comは13言語で公開しており、生成 → 翻訳 → レンダリング → レビューという一連の流れ全体が1つのスキルの中に収まっている。使用すべきタイミング（「新しい記事を生成する」「全ロケールに翻訳する」「プロモを下書きする」）を記述した SKILL.md ファイルと、実際の作業をこなすスクリプトだ。私は4つの別々のコマンドを実行し、その順番を覚えておく必要はない。ただ普通の言葉で欲しいものを言うだけで、スキルの説明文が十分に具体的なので、Claudeがそれを拾い上げて正しい手順を実行する——Facebook広告のスキルが、コマンド名を一切入力しなくても「広告をチェックして」で発動するのと同じ仕組みだ。

スキルが自分で「自分が適用されるかどうか」を判断するというこの設計上の選択こそ、コマンドやサブエージェントよりも安全策が重要になる理由でもある。スラッシュコマンドはあなたが入力したときにしか実行されないが、スキルはモデルが「実行すべきだ」と思ったときに実行される。私のコンテンツスキルはデフォルトで下書きを書くだけであり、何かを公開したりプッシュしたりする前には明示的で別個の承認ステップを必須としている——これは、スキルが自分で発動して実際に影響のあるアクションに至る可能性がある場面ならどこでも使っているヒューマン・イン・ザ・ループのパターンと同じだ。

向いている用途：「レポートを生成して」「この提出物を採点して」「Slack用の要約を下書きして」など、認識可能なトリガーフレーズとその背後にある再現可能な手順を持つもの全般。失敗パターンは、スキルの説明文が広すぎて望まないときに発動してしまうか、逆に狭すぎて必要なときに発動しないことだ。説明文は関数の命名のようにではなく、新入社員にトリガーを説明するときのように書くべきだ。

意思決定フレームワーク

問い	イエスなら →	理由
これを発動するとき、常に自分で名前を入力したいか?	スラッシュコマンド	モデルではなくあなたがトリガーだから
タスクの範囲が明確で、委任可能で、メインコンテキストの外に置いたほうがよいか?	サブエージェント	独自のコンテキストウィンドウを持ち、結果を返す
何も名指ししなくても、Claudeがその必要性を認識すべきか?	スキル	説明文に基づいて自動的に呼び出される
お金、公開、または取り消しが難しいことに関わるか?	3つのいずれでも、加えて明示的な承認ゲートを	自動呼び出しは自動実行とは違う

実際のワークフローのほとんどは、これらのどれか1つではなく、複数を積み重ねたものだ。私のコンテンツパイプラインは、「記事を書いて」で自動発動するスキルであり、その内部でサブエージェント（ロケールごとに1つ、並列実行）を呼び出し、公開という——絶対に私が明示的に指示しない限り起きてはいけない——1つのステップのためにスラッシュコマンド（/publish）を公開している。

私が最もよく見る失敗

本来はコスチュームを着たスラッシュコマンドに過ぎないものに対して、独自のスケジューリング、独自の状態管理、独自のデプロイを持つフルスペックのカスタムエージェントを構築してしまうことだ。タスクが「私が言ったときに、この正確な手順を実行する」であるなら、自律性も、記憶も、発動条件も必要ない。必要なのは名前とプロンプトだけだ。サブエージェントとスキルの仕組みは、境界（サブエージェント)やトリガー（スキル）が実際に仕事をしている場面のために取っておくべきであり、すでにシンプルだったものにインフラを足すためだけに使ってはいけない。

オペレーターとしての結論

どう作るかを考える前に、誰がそれを呼び出すと決めるのかを問おう。あなたが毎回名前を指定して決める → スラッシュコマンド。メインコンテキストの外に置きたい、範囲の明確なタスク → サブエージェント。Claudeが自分でその必要性を認識する → スキル、そして取り消せないことには承認ゲートを。この一つの問いさえ正しく立てられれば、ファイルに何を書くか、どれだけの指示をまとめるかといった残りの部分は、たいていおのずと決まってくる。

FAQ

Claudeのスキルとスラッシュコマンドはどう違うのか?

スラッシュコマンドは、実行したいたびに名前を指定して明示的に呼び出す。スキルは自動的に呼び出される——Claudeがあなたのリクエストをスキルの説明文と照合し、あなたが何も名指ししなくても読み込む。常に自分で発動を決めたいならコマンドを、モデルが自分でトリガー条件を認識すべきならスキルを使うとよい。

スキルの代わりにサブエージェントを使うべきなのはどんなときか?

タスクの範囲が明確で委任可能であり、それをメインの会話とは別の独自のコンテキストウィンドウで実行したいとき——これはどう発動するかではなく、どこで作業が行われるかの問題だ。スキルとサブエージェントは互いに排他的ではない。スキルが内部でサブエージェントを起動することもできる。たとえば翻訳スキルが、ロケールごとに1つのサブエージェントに記事を振り分けるように。

スキルに公開やお金の支払いのようなアクションを自動的に発動させても安全か?

結果に影響するステップに明示的な承認ゲートを設けている場合に限り安全だ。スキル自体の自動呼び出しは問題ない——それは単に、Claudeがあなたの求めているものを認識したというだけのことだ。リスクは、取り消しが難しいことの自動実行にある。下書き作成、読み取り、報告は自動発動するスキルの内部にとどめ、公開・支払い・削除には別個の明示的な確認を必須にすること。

3つすべてをいずれ構築する必要はあるか?

あなたのワークフローが実際にこの3つの形をすべて持っているなら、その通りだ。反復可能なタスクをいくつか抱えるだけの単独オペレーターなら、長期間スラッシュコマンドだけで十分にやっていけるかもしれない。スキルやサブエージェントが必要になるのは、コマンド名を覚えきれないほど発動条件の種類が増えたとき、あるいはメインコンテキストに残しておくと品質を損ない始めるほど範囲の明確なサブタスクが増えたときだ。

---

関連記事： Facebook広告を運用するClaudeスキルを作った · コンテキストエンジニアリング：コンテキストウィンドウに何を入れるか · ヒューマン・イン・ザ・ループAIエージェント：承認ゲートを設けるべきとき · 30以上の本番エージェントを運用する私のエージェントスタック

何を自動化すべきか、どう進めるべきか迷っているなら？ お問い合わせください——オペレーターチーム向けに本番エージェントシステムを設計しています。