既存の.claude/commands/ファイルは、手動でSkillディレクトリ構造にすべて書き直す必要がありますか？
必要ない。公式ドキュメントは既存の.claude/commands/ファイルが引き続き正常に動作し、システムの統合によって無効になることはないと明確に説明している——これは強制的な移行ではなく、公式が「新しい自動化」にはSkillディレクトリを推奨する方法として位置づけているだけだ。手元にあるシンプルな単一指示のコマンドがうまく機能しており、追加のスクリプトや参考資料も必要ないなら、新しいやり方に追いつくためだけにわざわざ書き直す必要はまったくない。
より合理的なやり方は段階的なものだ。新しいワークフローを追加する際はSkillディレクトリを優先的に検討し（特に将来スクリプトや参考資料を拡張する必要がありそうな場合）、既存のシンプルなコマンドファイルは、本当に機能拡張が必要になったとき、あるいはちょうどそのロジック部分をリファクタリングするタイミングで、まとめて移行すればよい。移行のためだけに移行する必要はない。
あるSkillを自分だけが手動でトリガーできるようにし、Claudeが自分の判断で状況を見て読み込むことを望まない場合、具体的にどう設定すればよいですか？
そのSkillのSkill.mdフロントマターにdisable-model-invocation: trueフィールドを追加する。設定すると、このSkillの説明はClaudeが読み込むかどうかを判断する際に参照するコンテキストに含まれなくなり、Claudeが自分でこれをトリガーすることは一切なくなる。あなたが手動で/名前と入力した場合にのみ実行される。公式ドキュメントは特に、副作用のあるワークフローや、自分でタイミングを制御したいワークフロー——デプロイやメッセージ送信のように「Claudeが機が熟したと判断して勝手に実行してほしくない」操作——にこの設定が適していると述べている。
このフィールドは、単一ファイルのコマンドを選ぶかSkillディレクトリ構造を選ぶかとは独立している。つまり、ワークフローを完全なSkillディレクトリ（スクリプトや参考資料付き）として書いた場合でも、このフィールドを追加すれば手動トリガー専用のままにできる。トリガー方式の選択と、どちらのファイル構造を使うかは、まったく別の問題だ。
組み込みの/simplifyや/batchといったコマンドも、今回のSkillシステムへの統合の一部ですか？
関連はあるが完全に同一のメカニズムではない。公式ドキュメントは/doctor、/code-review、/batch、/debug、/loopといったコマンドを「Bundled Skills（組み込みSkill）」として分類しており、その特徴は「プロンプトベース」であること——つまりClaudeに詳細な操作手順を与え、手持ちのツールを使って自分で実行させる仕組みだ。これは、自分で.claude/skills/配下に書くカスタムSkillと同じ動作原理を持つ。これは、/helpや/compactのように固定ロジックを直接実行し、Claudeの推論判断を伴わない組み込みコマンドとは異なるものだ。
ユーザーから見れば、トリガー方法に違いはなく、どちらも/に名前を続けて入力する。違いは背後の動作ロジックにある——組み込みSkillは、与えられた手順に従ってClaudeが考え、ツールを使ってタスクを完了させるのに対し、純粋な固定ロジック型の組み込みコマンドは、書き込まれたプログラムの動作を直接実行し、モデルの推論を伴わない。すべての組み込みSkillをオフにしたい場合はdisableBundledSkillsという設定を使えるが、/doctorはこの設定をオンにしても入力可能なままだ。
このシステムの統合はいつ起きたのですか？自分のClaudeCodeのバージョンが対応しているか確認する必要がありますか？
コミュニティがまとめた記事によれば、この統一はバージョン2.1.3で導入された——それ以前は、コマンドとSkillは完全に独立した二つのシステムであり、個別に開発・保守されていた。これが、古いチュートリアル記事に見られる「両者の動作は本質的に異なる」という説明の出所でもある。それ以降のバージョンを使っているなら、二つのシステムはすでに統一されて動作しており、追加の設定や有効化は必要ない。
より確実な確認方法は、現在使用しているバージョン番号を直接調べることだ（ClaudeCode内では通常バージョン確認用のコマンドで確認できる）。バージョンがその時期より明らかに古い場合、あるいは不確かな場合は、テストする前にアップデートコマンドを実行しておく方が安全だ——ClaudeCodeの更新頻度がかなり高いことを考えると、現在積極的に使っているほとんどの人はすでに統合後のバージョンで動いているはずだが、もし自分の環境が長期間更新されていないなら、自動的に最新だと思い込むのではなく、10秒かけてバージョンを確認する価値はある。
最近「ClaudeCodeのコマンドとSkillの違いは何ですか」と検索したことがあるなら、おそらく複数の記事が示し合わせたように同じ答えを出しているのを見かけたはずだ。コマンドは手動で/commandと入力しない限り実行されず、Skillは状況をClaudeが自分で判断して自動的に読み込む——両者の核心的な違いは「誰がトリガーを引くか」だという説明だ。この説明は数か月前は正しかったが、公式ドキュメントの現在の表現はすでに変わっている。
ClaudeCodeの現行ドキュメントは、Skillシステムを説明する際、非常に率直な一文を使っている：「カスタムコマンドはSkillシステムに統合されました（Custom commands have been merged into skills）」。具体的には、.claude/commands/deploy.mdに置かれたファイルと、.claude/skills/deploy/Skill.mdに置かれたSkillは、どちらも同じ/deployコマンドを作り出し、まったく同じように動作する——既存の.claude/commands/ファイルは引き続き正常に動作し、システムの統合によって無効になることはないが、公式は現在、新しい自動化にはSkillディレクトリを推奨する方法として位置づけている。
かつて核心的な分岐点として扱われていた「手動トリガー vs 自動トリガー」は、今では実際どちらの書き方でも実現できる——違いはもはや「コマンドは手動でしかできず、Skillは自動でしかできない」ことではなく、Skillのフロントマターがこれを直接制御する明確なスイッチを提供している点にある。disable-model-invocation: trueを設定すると、そのSkillは自分で/名前と手動入力した場合にのみトリガーされ、Claudeが自分の判断で読み込むことは決してない——これはまさに旧来のチュートリアルが「コマンドの特性」として説明していたものに対応する。逆に、このフィールドを設定しない場合（デフォルト）、Claudeはdescriptionフィールドに基づいて自動的に読み込むかどうかを判断でき、同時にあなたが手動でトリガーすることもできる。二つのトリガー方式が同時に存在しており、互いに排他的で一方の動作に固定された二つのシステムではない。
トリガーの仕組みがもはや分岐点でなくなった以上、両者の実際の違いはファイル構造そのものにある：.claude/commands/配下は単一のMarkdownファイルであり、ロジックがシンプルで追加のリソースを必要としない場合に適している。.claude/skills/<name>/はディレクトリであり、核となるSKILL.mdに加えて、scripts/（実行可能なスクリプト）やreferences/（本当に必要なときにのみ読み込まれる拡張参考資料）といったサポートファイルも置ける。あるワークフローが複雑になり、追加のスクリプトや大量の参考資料が必要になったとき、Skillのディレクトリ構造ならそれらを分離して管理でき、すべてを一つのファイルに詰め込む必要がない。単に頻繁に使う固定的な一つの指示にすぎないなら、単一ファイルのコマンド形式で依然として十分であり、公式も既存のシンプルなコマンドをすべて移行するよう求めているわけではない。
実務上知っておく価値のあるもう一つの詳細：.claude/commands/deploy.mdと.claude/skills/deploy/SKILL.mdが同時に存在する場合、公式ドキュメントはSkillバージョンが優先されると明確に説明している——/deployはSkillディレクトリで定義された内容を実行する。つまり、古いコマンドを段階的にSkillへ移行している最中に、両方のファイルが一時的に併存してもエラーは起きず、新しいバージョンが自然に引き継ぐ。新しいバージョンを有効にするために、先に古いファイルを手動で削除する必要はない。
これは無害な表現の食い違いではない。もし旧来の区分法に基づいてチームの自動化ワークフローを設計すると——例えば「このワークフローは自動トリガーが必要だから必ずSkillとして書かなければならない、あのワークフローは手動制御だけにしたいから必ずコマンドとして書かなければならない」と決めつけてしまうと——本来シンプルで単一ファイルに適していたロジックを、無理やり複雑なディレクトリ構造に分割してしまったり、コマンド形式ではClaudeに状況を自動判断させることが決してできないと誤解し、本来達成できたはずの自動化をあきらめてしまったりする可能性がある。どちらの形式を使うべきかを判断する正しい基準は、今では「このワークフローの複雑さに追加のサポートファイルが必要かどうか」であり、「自動トリガーにしたいか手動トリガーにしたいか」ではない。
次に新しいワークフローを追加する前に、まず構造的な問いを立てよう：このワークフローは、指示文の一塊以外に、スクリプト、テンプレート、大量の参考資料を必要とするか？必要なら、Skillディレクトリを使い、コアロジックをSKILL.mdに置き、拡張内容をscripts/やreferences/に分割する。必要でなければ、単一ファイルのコマンド形式で完全に十分であり、「Skillの方が新しくて推奨されているらしい」というだけの理由でシンプルなロジックを過剰に設計する必要はない。Claudeに自動トリガーさせたいかどうかは、disable-model-invocationという独立したスイッチが扱うべきことであり、どちらのファイル構造を選ぶかとは無関係だ。