# Skill vs Command vs Subagent: 判断フローチャート
Claude Code を本格運用すると、必ずぶつかるのが「これは Skill にすべきか、Command にすべきか、Subagent に切り出すべきか」という問いである。三者は機能が重なる部分があり、ドキュメントを読んだだけでは迷いやすい。本稿では公開情報をもとに、呼び出し主体・文脈分離・自動起動という三軸で使い分けるためのフローチャートを整理する。
三者の役割の輪郭を改めて押さえる
公開情報によれば、Skill と Command は 2026 年に入り事実上統合されつつある。`.claude/commands/review.md` も `.claude/skills/review/SKILL.md` も同じ `/review` を生むが、Skill のほうが自動呼び出し・サブエージェント化・補助ファイル参照といった上位機能を持つ。両者が共存する場合は Skill が優先される仕様だ。Subagent は別個の Claude インスタンスで動き、独立した文脈を持って結果のサマリだけを返す存在である。これら三者は対立項ではなく、入口の違い・実行コンテキストの違い・自動性の違いという軸で分かれる仲間として捉えるべきだ。実務では「同じ機能を Skill にするか Command にするか」で迷うより、「呼び出し主体は誰か」「文脈を分けたいか」「自動発火させたいか」という三つの問いに先に答え、結果として導かれる箱に入れる方が早い。
軸 1: 呼び出し主体は誰か
最初に問うべきは「誰が呼ぶか」である。ユーザーが明示的にスラッシュコマンドで叩くなら Command 寄り、モデルが文脈から判断して呼ぶなら Skill 寄りになる。ユーザー入口を残しつつ自動起動も認めたい場合は、Skill として定義しつつフロントマターの `disable-model-invocation` を未設定にしておくのが定石だ。逆に「人間が儀式的に叩くこと自体に意味がある」コマンド、例えばリリース前チェックのようなものは Command として明示的に残し、自動発火させない方がチーム運用上わかりやすい。呼び出し主体を最初に確定させることで、後段の判断が一気に楽になる。チームによっては「ユーザー操作の引き出しに並ぶもの」と「モデルが裏で適宜使う道具箱」を物理的に分けて管理しており、この分離は運用の透明性を大きく高める。
軸 2: 文脈は分離すべきか
次に「メイン会話の文脈を汚すか」を考える。30 ファイルを横断する調査や、長大な出力を生む変換処理を本流に流すと、後続のやりとりに必要なトークンが圧迫される。例えば認証フローの解析を依頼すると、Claude が 30 個のファイルを読み込んで、それらすべてがメインの会話履歴に乗ってしまう。こうした重い処理は Subagent に切り出し、サマリのみを戻すのが正しい。Skill のままだと文脈が肥大し、後の応答の質が落ちる。逆に「軽い変換」「短い助言」のような処理は Subagent に分けるとオーバーヘッドの方が大きくなるため、Skill のままで動かす方がよい。経験則として、出力が 50 行を超えるものは Subagent 化を検討し、それ以下なら Skill のままで十分という判断を採るチームも多い。境界の数字は組織や領域によって変わるため、自社で計測しながら調整するのがよい。
軸 3: 自動起動の頻度はどれほどか
三つ目は「どのくらい自然発火させたいか」だ。毎日のレビュー作業のように頻繁に呼びたいものは Skill に寄せ、デプロイ前の儀礼的な確認のように人間が意識して呼びたいものは Command に寄せる。自動起動を許すと便利な反面、意図しない場面で発火し履歴を汚すリスクもあるため、起動条件を記す説明文は厳密に書くべきである。Skill の説明文には「何ができるか」だけでなく「いつ呼ぶべきでないか」まで書いておくと、過剰発火を抑えられる。これは LLM が文章で判断する以上、避けて通れない設計責務である。説明文は単なるドキュメントではなく、実行制御を担うコードに近い役割を持つと意識するとよい。曖昧な表現は曖昧な判断を生み、結果としてユーザー体験を不安定にする。
三軸を貫くフローチャートと Hook の併用
判断は次の順で進める。第一に、ユーザーが必ず手で起動するなら Command。第二に、モデルが自動判断で呼んでよいが本流の文脈で完結するなら Skill。第三に、出力が長大か、ツール権限を絞りたいか、独立した文脈で動かしたいなら Subagent。第四に、決定論的な遮断やログ記録が要件なら Hook を併用する。Hook はプラグインの中で唯一「LLM の確率性に依存しない決定論的な制御点」であり、PreToolUse で危険コマンドを遮断したり、PostToolUse で監査ログを残したりするのに適している。三者と Hook を組み合わせる前提で設計すると、後から要件が増えても破綻しにくい。逆に三者だけで安全性まで担保しようとすると、確率的な振る舞いに依存した脆い設計になりやすい。安全性の壁は Hook、機能の入口は Command、知能の発火点は Skill、重い独立処理は Subagent、と役割を割り切って組み合わせる思考様式を持っておきたい。
落とし穴・運用上の注意・まとめ
最大の落とし穴は、「全部 Subagent にすれば安全」と誤解することだ。Subagent は文脈分離の代償として、メイン会話との情報共有が制限される。デバッグ時に必要な中間出力が見えづらくなり、運用負荷が上がる。逆に「全部 Skill にすれば便利」とすると、過剰発火で履歴が汚れトークン消費が膨らむ。KGA IT のチームでは、新規プラグインを設計する際にまず三軸でラベル付けし、必要に応じて Hook を足す運用を徹底している。Skill・Command・Subagent は対立項ではなく、呼び出し主体・文脈分離・自動起動という三軸で役割を分け合う仲間であると改めて意識すれば、設計判断のブレは大きく減るはずだ。三軸を貫いて設計したものは、後で見返したときに「なぜこの形なのか」が読み取りやすく、メンバーの入れ替わりにも耐える。逆に勢いで決めたものは数か月で意味を失い、誰も触れない化石になりがちである。判断フローを言語化することは、生態系を持続可能に保つための小さな投資として、大きなリターンを生む。