このメディアの記事制作は /article という自作のコマンドで回しています。作業しているプロジェクトのフォルダ(リポジトリ)の中に .claude/commands/article.md として手順を書いておいて、毎回それを呼ぶだけ。半年近くこの形で使ってきました。

先日そのファイルを開いたとき、公式ドキュメントの見出しが変わっていることに気づきました。カスタムコマンドのページが、スキルのページに吸収されていたのです。

置いたはずのページが見当たらなくなった

最初は移動しただけだと思いました。ところが説明を読むと、単なるページの引っ越しではありませんでした。

Custom commands have been merged into skills.

カスタムコマンドはスキルに統合された、と書かれています。スキルは、やってほしい手順をファイルに書いてClaudeに持たせておく仕組みです。カスタムコマンドという独立した呼び名が、そのスキルという大きな枠に入った形になります。

Extend Claude with skills(Anthropic公式・英語。2026年7月時点)

code.claude.com

同じ /deploy を、2つの書き方で作れる

統合後の状態は、具体例で見ると早いです。公式は次の2つを並べています。

.claude/commands/deploy.md というファイルを置く。あるいは .claude/skills/deploy/SKILL.md というファイルを置く。どちらでも /deploy というコマンドが作られ、同じように動きます。

違いは形だけです。前者は1枚のファイル、後者はディレクトリの中にある SKILL.md。呼び出したときの挙動は変わりません。

いま動いているコマンドは、そのまま動く

いちばん気になるのはここでした。公式には「既存の .claude/commands/ のファイルは動き続ける」と明記されています。フロントマター(ファイル先頭の設定欄)も同じものが使えます。

実際、私の /article は何も直さずに今も動いています。統合という言葉から想像したような、書き直しを迫られる変更ではありませんでした。

ただし1つだけ順番の決まりがあります。スキルとコマンドに同じ名前があった場合は、スキルのほうが優先されます。 移行の途中で両方に /deploy が存在する状態を作ると、コマンド側は呼ばれなくなります。片方を消すまで気づきにくいので、移すなら古いほうを残さないほうが安全です。

スキルの形にすると増えるもの

では、わざわざディレクトリの形にする意味はどこにあるのか。公式が挙げているのは3つです。

1つめは補助ファイルを置けること。スキルはディレクトリなので、SKILL.md の隣にテンプレートや参考資料、スクリプトを同居させられます。本体は短く保ったまま、詳しい資料は必要なときだけ読ませる形にできます。公式は SKILL.md を500行以内に収めることを勧めています。

2つめは呼び出しを制御できること。disable-model-invocation: true を書くと、あなたが /名前 と打ったときだけ動き、Claudeが勝手に判断して実行することはなくなります。デプロイや送信のような、タイミングを自分で決めたい作業に向いています。逆に user-invocable: false にすると、メニューには出さずClaudeだけが使う背景知識にできます。

3つめは関連しそうなときに自動で読み込まれること。フロントマターの description を手がかりに、Claudeが必要と判断すれば自分で持ってきます。「今の変更を要約して」と頼んだだけで、それ用のスキルが立ち上がる、という動き方です。

Claude Codeのスキルそのものの使い方は、以前まとめた記事があります。

Claude Codeのスキルが勝手に読み込まれる仕組み

claudecodelab.jp

置き場所は4種類あって、優先順位が決まっている

スキルは置いた場所によって、誰が使えるかが変わります。個人用は ~/.claude/skills/ で全プロジェクトから使え、プロジェクト用は .claude/skills/ でそのリポジトリだけ。ほかに組織で配る管理者向けの置き方と、プラグインに同梱する形があります。

同じ名前が重なったときは、組織の設定が個人を上書きし、個人がプロジェクトを上書きします。 プラグインのスキルだけは名前の頭にプラグイン名が付くので、ほかとぶつかりません。

置き場所の選び方と、実際に1つ作る手順はこちらにまとめました。

Claude Codeで自分のコマンドを1つ作るClaude Codeのプラグインマーケットプレイス

claudecodelab.jp

移すべきか、置いたままにするか

私の結論は「困っていないなら急がなくていい」です。公式が動き続けると明記している以上、.claude/commands/ のままで支障はありません。

移す価値があるのは、ファイルが長くなってきたときです。手順書と一緒にテンプレートやチェックリストを渡したくなったら、そこがディレクトリの形にする合図になります。私の /article も、レビュー観点の資料が増えてきたのでスキルへ移すつもりです。

もう1つ、Claudeに自動で使ってほしいものがあるなら移行の理由になります。コマンドは打って呼ぶものですが、スキルは条件が合えば向こうから出てきます。「毎回自分で呼んでいるが、本当は気づいてほしい」という手順があるなら、スキルの形が合っています。

なお、スキルは Agent Skills という他のAIツールとも共通の規格に沿っています。書いたものが1つのツールに閉じない、という点も移行を後押しする材料になりそうです。

変わったのは器で、中身ではない

統合と聞いて身構えましたが、実際に確かめると、既存のファイルを壊す変更ではありませんでした。カスタムコマンドという呼び名が、スキルという広い呼び名に吸収された。増えたのは選択肢のほうです。

いま .claude/commands/ で動いているものがあるなら、まずはそのままで問題ありません。長くなってきたファイルから順に、ディレクトリの形へ移していくのが現実的だと思います。