Claude Code使い始めたんですけど、毎回同じ長い指示を書くのが面倒で…なんかいい方法ないですか？
それ、カスタムコマンドを作れば一発で解決できるよ。/review って打つだけでコードレビューが始まる感じ
こんにちは！Renです！
Claude Codeを使っていると、こんな経験ありませんか？
今回は、そのすべてを解決するカスタムコマンドの作り方と使い方を完全解説します。
僕自身、iOSアプリ開発で毎回コードレビューを依頼するたびに同じ長い指示を書いていました。カスタムコマンドを導入してから、レビュー依頼の準備時間がほぼゼロになったのが本当に快適です。
さらに記事の後半では、Skillsとカスタムコマンドはどちらもスラッシュコマンドとして使えるのに何が違うのか、という混乱しやすいポイントも整理します。
Claude Codeのカスタムコマンドとは？
カスタムコマンドとは、よく使う指示やプロンプトをスラッシュコマンド（/コマンド名）として登録できる機能です。
Macの「テキスト置換」やキーボードショートカットをイメージしてもらうと分かりやすいです。毎回長い文章を打つ代わりに、短いコマンドひとつで全部呼び出せる仕組みです。
よく使う指示・プロンプトをMarkdownファイルに保存し、/コマンド名 で瞬時に呼び出せる機能。ファイル名がそのままコマンド名になる
たとえば、コードレビューの指示をまとめた review.md というファイルを作っておけば、Claude Codeのターミナルで /review と打つだけで、その指示がすべて実行されます。
Markdownファイルを置くだけでコマンドになるんですか？すごくシンプルですね
そう、この仕組みのシンプルさがいい。特殊な設定ファイルは一切不要で、Markdownが書けるならすぐ作れる
カスタムコマンドの3つのメリット
メリット①：長いプロンプトをワンコマンドで呼び出せる
最大のメリットは、何十行もの指示を毎回書かなくて済むことです。
コードレビューを例にすると、「セキュリティの観点で確認してください。次にパフォーマンスの問題がないか見てください。SwiftのベストプラクティスやAppleのガイドラインに沿っているか…」という長い指示を毎回書く必要がなくなります。
カスタムコマンドを作ってから、コードレビュー依頼の準備が $ARGUMENTS に対象ファイルを渡す1行で完結するようになった。1日あたり5〜10分の節約、1ヶ月で2〜4時間の差になる
メリット②：プロンプトをチームで共有・標準化できる
カスタムコマンドはGitで管理できます。つまり、チーム全員が同じ高品質なプロンプトを使えます。
「Aさんのレビューは細かいのに、Bさんのレビューはざっくりしている」という品質のバラつきを解消できるのは、チーム開発をしている人には刺さるメリットです。
メリット③：指示を考える認知負荷がゼロになる
「どう指示すればいいかな」と毎回考えることは、思ったより脳のリソースを使います。
カスタムコマンドがあれば、その判断をすべて省略できます。開発という本質的な作業に100%集中できるのが、地味だけど大きなメリットです。
カスタムコマンドの作り方【ステップ解説】
ステップ①：保存場所を決める（プロジェクト用 or 個人用）
カスタムコマンドを保存できる場所は2種類あります。目的に応じて使い分けましょう。
| 項目 | プロジェクト用 | 個人用 |
|---|---|---|
| 保存場所 | .claude/commands/ |
~/.claude/commands/ |
| 誰が使える | リポジトリの全員 | 自分だけ |
| Git管理 | できる（チーム共有） | できない |
| 向いている用途 | レビュー・テスト・標準化 | 個人のこだわり設定 |
個人開発なら基本的にプロジェクト用（.claude/commands/）だけで十分です。チーム開発の場合は、チームで使うコマンドはプロジェクト用、自分だけのこだわりコマンドは個人用に分けるのがおすすめです。
.claude/commands/ ディレクトリの中にファイルが並んでいるターミナル画面ステップ②：Markdownファイルを作成する
コマンドの中身はただのMarkdownファイルです。ファイル名がそのままコマンド名になります。
review.md というファイルを作れば /review コマンドが使えるようになります。
コマンド名は5文字以内が理想。review、test、commit のように短くて直感的な名前を付ける。run-code-review-for-pr のような長い名前は打つ気にならない…
ファイルの中身は普通のMarkdownで指示を書くだけです。そして$ARGUMENTSという特殊変数を使うと、コマンド呼び出し時に追加情報を渡すことができます。
/review ContentView.swift と入力したとき、ContentView.swift の部分が $ARGUMENTS に入る。コマンドを書き換えずに対象ファイルを毎回変えて使い回せる便利な変数
review.md ファイルの中身（エディタ画面）ステップ③：Claude Codeで呼び出してみる
ファイルを保存したら、Claude Codeのターミナルで / を打ってみましょう。登録したコマンドが補完候補として表示されます。
review が表示されている様子スラッシュを打つと補完候補が出てくるのが地味に便利。コマンド名を覚えてなくてもリストから選べる
あとは /review ContentView.swift のように呼び出すだけ。コマンドファイルに書いた指示が全部実行されます。
/review ContentView.swift を実行してレビュー結果が返ってきている様子一番効果的な使い方：定型タスクの「型」を作る
カスタムコマンドが最も光るのは、毎回やっている定型タスクを型化することです。
ポイントは「コマンド化する前にプロンプト自体を磨く」こと。雑な指示をコマンド化しても雑な結果しか返ってきません。一度丁寧に指示を作り込んでから、それをコマンドにするのが正しい順序です。
・コードレビュー（/review）
・テストコード生成（/test）
・コミットメッセージ作成（/commit）
・バグ調査・原因特定（/debug）
・リファクタリング提案（/refactor）
コマンド化すべきタスクを選ぶ基準は「週3回以上やっていて、指示が5行以上になる」ものです。この条件に当てはまるタスクはコマンド化の優先候補です。
$ARGUMENTS って何でも渡せるなら、指示を全部 $ARGUMENTS に書けばいいんじゃないですか？
それやると毎回指示を書くのと同じになっちゃう。コマンドの中に固定の高品質な指示を入れておいて、$ARGUMENTS はファイル名や補足くらいに留めるのがコツ
僕の場合：アプリ開発のコードレビューに使っている
実際に僕がどう使っているか、具体的に紹介します。
iOSアプリを個人開発している中で、Claudeにコードレビューを依頼する機会が毎日のようにあります。最初は毎回こんな指示を書いていました。
「以下のSwiftコードをレビューしてください。
①Appleのガイドラインに沿っているか
②メモリリークやパフォーマンスの問題がないか
③セキュリティ上の問題がないか
④可読性・保守性の観点で改善点があるか
⑤より良い実装があれば改善後のコードも提示してください」
これを毎回書くのが面倒になって review.md を作りました。
実際どれくらい変わりましたか？
コードを渡して /review ContentView.swift って打つだけになった。レビュー依頼の準備がほぼゼロ。それだけじゃなく、毎回観点が統一されるからレビューの品質も上がったよ
・レビュー依頼の準備時間がほぼゼロに
・毎回同じ観点で統一されたレビューが来る
・「今日どう指示しようか」と考える時間がなくなった
・コマンドを育てるたびにレビュー品質が上がっていく
最初に作った指示が3ヶ月後には自分のニーズとズレてくることがある。僕は月1回程度 review.md の内容を見直して、レビュー観点を追加・削除している
Claude Codeを使ったアプリ開発の全体的な進め方については、Claudeでアプリ開発する完全ガイド【非エンジニアでもできる】で詳しく解説しているので、合わせて読んでみてください。
Skillsとカスタムコマンドはどこがどう違うのか
ここが一番混乱しやすいポイントです。
SkillsもスラッシュコマンドとしてClaude Codeから呼び出せます。となると「カスタムコマンドと何が違うの？」という疑問が生まれます。
Skillsもスラッシュで使えるなら、カスタムコマンドと同じじゃないですか？
使い方が似てるから混乱するよね。でも本質的な役割が全然違う。Skills は「知識・ルール」を渡すもの、カスタムコマンドは「作業を実行させる命令」なんだ
Skillsとは何か（おさらい）
Skills（SKILL.mdファイル）は、Claudeに「どう振る舞うか」を定義するためのものです。
たとえば「このブログはです・ます調で書く」「コードはSwiftのみ」「レスポンスは日本語で」といったルールや背景知識をSkillsとして持たせることで、毎回説明しなくてもClaudeが自動で考慮してくれます。
Skillsの作り方については、Claude Skillsの作り方｜初心者でも10分で自分専用AIアシスタントが作れるで詳しく解説しています。
2つの本質的な違い
一言で言うと、「Skills = 知識・設定を渡す」「カスタムコマンド = 作業を実行させる命令」です。
| 比較項目 | Skills | カスタムコマンド |
|---|---|---|
| 目的 | 知識・ルールを与える | 作業を実行させる |
| ファイル形式 | SKILL.md（固定） | 任意のMarkdown |
| 保存場所 | skillsフォルダ | .claude/commands/ |
| 引数（$ARGUMENTS） | × | ○ |
| 具体例 | コーディング規約・口調設定 | レビュー・テスト・commit作成 |
最強の組み合わせ：SkillsでコンテキストをセットしてCommandで動かす
この2つは競合するものではなく、組み合わせることで真価を発揮します。
Skills（背景知識）：「このアプリはSwift/SwiftUI製、iOS 17以上対象、コーディング規約はXX」という仕様書を持たせる
カスタムコマンド（実行）：/review でレビューを実行
結果：アプリの仕様を理解した上でレビューしてくれる、まるで自分のプロジェクトを知り尽くした専属レビュアー
Skillsで「このプロジェクトはこういう仕様です」という背景知識を持たせ、カスタムコマンドで「じゃあこの作業をやって」と命令する。この組み合わせが、Claude Codeを最大限に活かす使い方です。
僕の場合は、Skillsにアプリの仕様書とSwiftコーディング規約を持たせて、その上で /review を使ってる。仕様を理解した上でレビューしてくれるから、的外れなコメントがほとんどなくなった
カスタムコマンドを作るときのよくある失敗
失敗①：コマンド名が長すぎる
「分かりやすくしよう」と思ってコマンド名を長くしてしまうのは逆効果です。
・
/run-code-review-for-pull-request・
/generate-unit-test-code・
/create-commit-message-from-diffOK例:
・
/review・
/test・
/commit
失敗②：指示が曖昧で毎回違う結果が出る
「コードをレビューしてください」だけの指示では、毎回違う観点でレビューが来て品質が安定しません。観点・フォーマット・深さを具体的に定義することが大事です。
①観点が明確：何の視点でチェックするか具体的に書く
②出力フォーマットを指定：問題点を番号付きリストで出す、など
③改善例も求める：問題だけでなく修正後のコードも提示させる
失敗③：全部を$ARGUMENTSに依存してしまう
「$ARGUMENTSに全部書けば何でもできる」と思ってしまうと、コマンドの意味が薄くなります。
コマンドファイルの中には変わらない高品質な指示を固定しておき、$ARGUMENTSはファイル名や「今日は特にパフォーマンスを重視して」といった補足用途に留めるのがベストです。
まとめ：カスタムコマンドはClaude Codeの「自分専用ショートカット」
カスタムコマンドの本質は、毎回やっている定型タスクを型化して、指示を考える時間をゼロにすることです。
.claude/commands/ フォルダを作る/コマンド名 で呼び出してみる最初は1個だけ作ってみて、慣れたら増やせばいいですね
そう。僕も /review 1個から始めて、今は5個に増えた。使っていくうちに「これもコマンド化できる」って気づく感じで自然と育っていくよ
Claude Codeをもっと深く使いこなしたい方は、ClaudeCodeは初心者に向いてない？学習効率を比較してわかった真実やClaude Skillsの作り方｜初心者でも10分で自分専用AIアシスタントが作れるもあわせて読んでみてください。
ではまた！
コメント