Claude Code コマンド一覧｜使い方・カスタム・許可【2026年10月】

結論: Claude Code のコマンドは「会話の中で打つスラッシュコマンド」「起動時に付ける CLI コマンドとフラグ」「操作を速くするキーボードショートカット」の 3 系統で覚えると迷いません。本記事はこの 3 系統のコマンド一覧と、.claude/commands/ に .md を置くだけで作れるカスタムコマンドの使い方、会社で許可設定を決める手順をまとめたコマンド辞典です（2026年9月22日に v2.1.278 の実機と公式ドキュメントで確認）。インストールから業務への組み込みまでの基本の使い方は姉妹記事 Claude Code 使い方｜インストールから自動化まで にまとめているので、本記事は「どのコマンドを打てば何が起きるか」を引く用途で使ってください。

この記事の要点:

• 要点1: 組み込みコマンドは版で増減するので /help で自分の版の一覧を見るのが確実。v2.1.278 の実機では /compact・/review・/plan・/usage（/cost）・/status・/permissions・/mcp など日常の操作がコマンド化されている
• 要点2: カスタムコマンドは .md ファイルを1つ置くだけで完成。allowed-tools でツール制限、argument-hint で入力補助も設定可能
• 要点3: プロジェクトの .claude/commands/ をリポジトリに commit すれば、チーム全員が同じコマンドセットを使えるようになる
• 要点4: 法人では「どの操作を確認なしで通すか」を .claude/settings.json の許可ルールで決め、全部省略モードは管理者設定で止めるのが定石

対象読者: Claude Code を日常的に使い始めたエンジニア・チームリーダー・DX推進担当者
読了後にできること: 今日中に最初のカスタム Slash Command を作成してチームに共有する

「毎回同じプロンプトを打つのが面倒で……」

企業向けの AI 研修でよく耳にする悩みです。PR レビューのフォーマット、コミットメッセージの書き方、テストコード生成のルール——チームによって微妙に違うのに、毎回長いプロンプトを打ち込んでいる方がほとんどでした。

そこで紹介しているのが Slash Command のカスタマイズです。実際に受講者に「まずこれを作ってみて」と体験してもらうと、「え、これだけで動くんですか？」と驚かれることが多い。設定ファイルの記述量が少ないわりに、効果が体感しやすいからだと思います。

この記事では、Anthropic 公式ドキュメント・GitHub の実例をもとに、Slash Command の仕組みから実用パターン10選まで徹底解説します。コピペで使えるコマンドファイルも10個以上用意しました。

Claude Code をもっとカスタマイズしたい方の参考になれば幸いです。

Claude Code のカスタマイズ全般については、Claude Codeの仕様と全機能まとめ にまとめています。合わせてご覧ください。

まず試したい「5分即効」カスタムコマンド3選

最初に、今すぐ作れる実用コマンドを3つ紹介します。これだけでも十分に Claude Code の生産性が上がります。

即効コマンド1：PR レビューコマンド

研修先で「毎回 PR レビューのお願い文を書くのが手間」という声が多かったので、このコマンドを紹介しています。作成後、受講者全員の反応が良かった一品です。

~/.claude/commands/review-pr.md として保存してください。

---
allowed-tools: Read, Grep, Glob, Bash(git diff *), Bash(git log *)
description: PR の変更内容を包括的にレビューし、改善提案を出す
argument-hint: [ブランチ名またはコミットハッシュ]
---

## 変更の取得
!`git diff main...HEAD --stat`

## 差分詳細
!`git diff main...HEAD`

## レビュー観点

以下の観点で $ARGUMENTS のコードをレビューしてください：

1. **コード品質・可読性**: 命名規則、関数の長さ、複雑度
2. **セキュリティ**: インジェクション、認証漏れ、シークレットハードコード
3. **パフォーマンス**: N+1クエリ、不要なループ、メモリリーク
4. **テストカバレッジ**: 未テストのエッジケース、モックの適切さ
5. **ドキュメント**: コメント不足、変更に伴うドキュメント更新漏れ

改善提案は Priority（高/中/低）を付けて番号リストで出してください。
不足情報があれば作業前に質問してください。

使い方: /review-pr feature/auth-refactor

即効コマンド2：コミットメッセージ自動生成

Conventional Commits 形式のメッセージを毎回ゼロから書くのは地味に時間がかかります。このコマンドで一発生成できます。

~/.claude/commands/commit.md として保存。

---
allowed-tools: Bash(git diff *), Bash(git status *), Bash(git add *), Bash(git commit *)
description: ステージされた変更からConventional Commitsのメッセージを生成してコミット
---

## 現在の状態
!`git status`

## ステージされた差分
!`git diff --cached`

上記の変更を分析して、Conventional Commits 形式のコミットメッセージを作成してください。

フォーマット: `(): `

types: feat / fix / docs / style / refactor / test / chore / perf

- 1行目は72文字以内
- body が必要な場合は2行目を空行にして3行目以降に記述
- Breaking Changes は `BREAKING CHANGE:` で明示

メッセージを提示して確認を取った後にコミットを実行してください。
仮定した点は必ず "仮定" と明記してください。

即効コマンド3：Issue トリアージ

GitHub Issue が溜まってきたときの整理に使います。gh CLI が入っていれば動きます。

~/.claude/commands/triage.md として保存。

---
allowed-tools: Bash(gh issue list *), Bash(gh issue view *), Bash(gh issue edit *)
description: GitHub Issues を優先度・カテゴリで整理してラベルを付ける
argument-hint: [リポジトリ名 or オーナー/リポジトリ]
---

## オープンIssue一覧
!`gh issue list --limit 50 --json number,title,labels,createdAt`

以下の観点でIssueを整理してください：

1. **優先度分類**: critical / high / medium / low
2. **カテゴリ分類**: bug / enhancement / documentation / question / duplicate
3. **アクション提案**: 即対応 / 次スプリント / バックログ / クローズ候補

分類結果を表形式で出力し、`gh issue edit` コマンドでラベルを付けるコマンド案を提示してください。
不足情報があれば最初に質問してください。

Slash Command とは何か ── Hooks との違いを整理する

Claude Code には「自動化」の仕組みが2種類あります。混同しやすいので最初に整理します。

一言で言うと、「呼ばれたら動く」のが Slash Command、「勝手に動く」のが Hooks です。

Hooks については Claude Code Hooks完全ガイド2026｜PreToolUse実装 で詳しく解説しています。

Claude Code スラッシュコマンド一覧（2026年9月・v2.1.278）

以下は公式ドキュメント（Commands・参照日 2026年9月22日）を元に、2026年9月22日に v2.1.278 の実機の /help で存在を確認したコマンドをカテゴリ別に整理したものです。コマンドは版で増減するので（例: /agents は v2.1.198 から案内表示だけになった）、迷ったら /help の Commands タブで自分の版の一覧を見てください。

コンテキスト管理

プロジェクト・設定

コード・レビュー

使用量・状態・接続（法人でよく聞かれるもの）

バンドル済みスキル（呼び出しも自動起動も可能）

ユーティリティ・その他

CLI コマンドとフラグ一覧｜起動・再開・非対話・連携（v2.1.278）

スラッシュコマンドが「会話の中」で打つものなら、CLI コマンドとフラグは「ターミナルで claude を起動するとき」に付けるものです。用途は 4 つに分かれます。値は公式 CLI reference（参照日 2026年9月22日）の記載で、「実機」と書いた行は2026年9月22日に v2.1.278 で実行して確認したものです。

コマンド（起動・再開・管理）

よく使うフラグ

公式の一覧にはこのほか --effort（推論の深さ）、--fallback-model（混雑時の代替モデル）、--background（背景セッションとして起動）などがあります。フラグは版で追加・廃止されるので（例: --enable-auto-mode は v2.1.111 で廃止され、--permission-mode auto に置き換え）、claude --help で自分の版の一覧を確認してください。

キーボードショートカット一覧｜入力・履歴・効率化（v2.1.278）

ショートカットは /help の General タブの Shortcuts 欄に出るものが基本です。下の表の「実機」は2026年9月22日に v2.1.278 の /help 画面で表示を確認したもの、「公式」は公式 Interactive mode ドキュメント（参照日 2026年9月22日）の記載です。macOS で Option キーの組み合わせを使うには、ターミナル側で Option を Meta として送る設定が要ります。

入力

履歴

効率化

使用量確認と権限のコマンド｜法人の運用ルールの決め方

法人導入で最初に聞かれるのは「いくら使っているか」と「どこまで勝手にやらせてよいか」の 2 つです。前者は /usage（/cost）と /status、後者は /permissions と権限モードで答えます。

使用量の確認: /usage と /status

/usage はセッションのコストとプランの利用上限、アクティビティを表示します（Pro・Max・Team・Enterprise ではプラン上限に対する内訳も出ます）。/status は版数・モデル・アカウント・接続状態を 1 画面で出すので、社内のサポート窓口が「まず /status を貼ってください」と決めておくと問い合わせ対応が速くなります。スクリプトからの実行は claude -p の JSON 出力に total_cost_usd が入るので、非対話実行のコストはそこから集計できます（2026年9月22日に v2.1.278 で実行して確認）。

権限モードは「確認の省き方」の段階

権限モードは 6 つあり、Shift+Tab で切り替えるか、起動時に --permission-mode で指定します。公式 permission-modes（参照日 2026年9月22日）の整理をそのまま段階で並べると次のとおりです。

--dangerously-skip-permissions は bypassPermissions で始めるフラグです。名前のとおり危険なので、会社の PC や本番に触れる環境では使わせない前提で設計します。

allowed-tools と permissions.allow の関係

カスタムコマンドの frontmatter に書く allowed-tools は「そのコマンドを実行している間だけ」の許可、.claude/settings.json の permissions.allow / ask / deny は「そのプロジェクト（またはユーザー・組織）全体」の許可です。導入支援で見る詰まり方は 2 つで、ひとつは許可ルールを何も書かずに始めて権限確認が多すぎて止まること、もうひとつはその反動で全部許可にして事故を招くことです。前者は次の失敗例のとおり allowed-tools と permissions.allow を書けば解け、後者は後述の管理者設定で止めます。

よくある詰まり: allowed-tools を設定しないと権限確認が頻発する

❌ allowed-tools なしでファイル変更を伴うコマンドを作る
⭕ 必要なツールを明示的に指定する

設定しないと、コマンド実行のたびに「Bash を実行してよいですか？」という確認が入ります。特にチームで使う場合、この確認フローが手間になります。

# NG: 確認プロンプトが毎回表示される
---
description: テストを実行する
---
npm test を実行してください。

# OK: Bash の使用を事前に許可
---
description: テストを実行する
allowed-tools: Bash(npm test *), Read
---
npm test を実行してください。

会社標準の許可設定を決める 4 手順

1. よく使う操作を仕分ける: 1〜2 週間の利用で確認が出た操作を集め、Bash(npm test *) のように「許可（allow）」、本番や決済に触れるものは「確認（ask）」、rm -rf や秘密情報の読み出しは「拒否（deny）」に分ける
2. プロジェクトの設定ファイルで共有する: 仕分けた結果を .claude/settings.json の permissions に書き、リポジトリに commit する（個人の ~/.claude/settings.json に書くと人によって挙動が変わる）
3. 全部省略モードは管理者設定で止める: 公式 Permissions（参照日 2026年9月22日）のとおり、permissions.disableBypassPermissionsMode を "disable" にすると bypassPermissions が使えなくなる（disableAutoMode で auto も止められる）。組織のポリシーとして効かせるなら managed settings に置く
4. 使用量を月に一度見る: /usage の上限到達と claude -p の total_cost_usd を集計し、上限に当たる人が多ければプランか許可ルールを見直す

会社としての基本の使い方（インストール・初期設定・業務への組み込み）は Claude Code 使い方｜インストールから自動化まで、全 OS の入れ方は Claude Code インストール方法｜全OS対応 を参照してください。

カスタム Slash Command の作成方法

カスタムコマンドは、指定ディレクトリに Markdown ファイルを置くだけで完成します。

ファイルの置き場所（プロジェクト vs グローバル）

ファイル名（拡張子なし）がそのまま /コマンド名 になります。review-pr.md なら /review-pr で呼び出せます。

注意: 公式ドキュメントでは .claude/commands/ はレガシーフォーマットとされており、現在は .claude/skills/ が推奨されています。ただし commands/ は引き続き動作し、シンプルなコマンドには今でも使いやすい形式です。

Markdown コマンドの構造

コマンドファイルは YAML frontmatter + Markdown 本文で構成されます。

---
description: コマンドの説明（/help 一覧に表示される）
argument-hint: [引数名1] [引数名2]
allowed-tools: Read, Bash(git *), Grep
model: opus
---

ここからがコマンドのプロンプト本文。

## コンテキスト取得（!バッククォートでシェルコマンドを実行）
!`git status`

## タスク
$ARGUMENTS を受け取って処理する内容を書く。

frontmatter の各フィールド詳解

description

/help コマンドや / を打ったときのコマンド一覧に表示される説明文です。

---
description: セキュリティ脆弱性スキャンを実行する
---

argument-hint と $ARGUMENTS

argument-hint は入力補完のヒント表示に使われ、$ARGUMENTS は実際に渡された引数に展開されます。

---
argument-hint: [ファイルパス] [修正方針]
description: 指定ファイルをリファクタリング
---

$ARGUMENTS で指定されたファイルをリファクタリングしてください。
修正方針: $ARGUMENTS の2つ目の引数を優先してください。

使い方: /refactor src/auth.ts "可読性重視"

引数は $1、$2 のように個別に参照することもできます。

---
argument-hint: [issue番号] [優先度]
---

Issue #$1 を優先度 $2 で修正してください。

allowed-tools でのツール制限

allowed-tools を指定すると、そのコマンド実行中に使えるツールを限定できます。セキュリティ上重要な設定です。

---
allowed-tools: Read, Grep, Glob
description: コードを読み取るだけで変更は加えない分析コマンド
---

コードを分析して問題点を報告してください。ファイルの変更は行わないでください。

よく使うツール指定パターン:

# 読み取り専用
allowed-tools: Read, Grep, Glob

# Git操作込み
allowed-tools: Read, Bash(git diff *), Bash(git log *), Bash(git status *)

# フルアクセス
allowed-tools: Read, Write, Edit, Bash, Grep, Glob

# 特定コマンドのみ
allowed-tools: Bash(npm test *), Bash(npm run lint *)

! でのシェルコマンド実行

プロンプト本文中に !`シェルコマンド` と書くと、コマンドが実行されてその出力がコンテキストに挿入されます。

---
allowed-tools: Bash(git *), Read
description: 変更の要約レポートを生成
---

## 変更ファイル
!`git diff --name-only HEAD~1`

## コミット履歴（直近10件）
!`git log --oneline -10`

上記の変更をまとめてスプリントレポートを作成してください。

@ でのファイル参照

@ファイルパス と書くと、そのファイルの内容がコンテキストに読み込まれます。

---
description: 設定ファイルの一括レビュー
---

以下の設定ファイルを確認してください：
- パッケージ設定: @package.json
- TypeScript設定: @tsconfig.json
- ESLint設定: @.eslintrc.js

セキュリティ問題・古い依存関係・設定ミスを指摘してください。

チーム共有パターン：リポジトリ配下に commit する

プロジェクトコマンドをチームで統一するには、.claude/commands/ ディレクトリをリポジトリに commit するだけです。

mkdir -p .claude/commands
# コマンドファイルを作成
echo "---
description: チーム標準のPRレビューを実施
allowed-tools: Read, Grep, Bash(git diff *)
---
..." > .claude/commands/review.md

git add .claude/commands/
git commit -m "feat: Claude Code チーム共有コマンドを追加"
git push

これで git clone したメンバー全員が、同じ /review コマンドを使えるようになります。

ディレクトリ構造の整理

コマンドが増えてきたらサブディレクトリで整理できます。

.claude/commands/
├── git/
│   ├── commit.md       # /commit として呼び出し
│   └── pr-review.md    # /pr-review
├── test/
│   ├── unit.md         # /unit
│   └── e2e.md          # /e2e
├── docs/
│   └── changelog.md    # /changelog
└── deploy.md           # /deploy

サブディレクトリ名はコマンド名には影響しません。git/commit.md は /commit で呼び出せます。ただし /help の一覧では「git: コマンドの説明」のようにサブディレクトリ名がプレフィックスとして表示されます。

プロジェクトコマンド vs グローバルコマンドの使い分け

実務では「グローバルに個人の定番コマンドを置き、プロジェクト固有のコマンドはリポジトリに含める」という使い分けが多いです。

スキル（/skills）との使い分け

Claude Code v2.1.101 以降、Slash Command の推奨形式は .claude/skills/ に移行しています。混乱しやすいので比較します（スキルの作り方そのものは Claude Code スキルの作り方ガイド にまとめています）。

シンプルな定型コマンドなら commands/ で十分です。「Claude に適切なタイミングで自動使用させたい」「複数ファイルで構成したい」場合は skills/ が向いています。

Hooks との連携パターン

Slash Command と Hooks を組み合わせることで、より強力なワークフローが作れます。

パターン1：コマンド実行後に自動フォーマット

settings.json の PostToolUse Hooks でファイル変更後に自動実行:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write "$CLAUDE_FILE_PATHS""
          }
        ]
      }
    ]
  }
}

カスタムの /refactor コマンドでファイルを書き換えると、自動的に Prettier が走るようになります。

パターン2：デプロイコマンド実行前の確認

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "if echo "$CLAUDE_TOOL_INPUT" | grep -q 'deploy\|kubectl apply'; then echo 'WARNING: 本番デプロイコマンドが含まれています' >&2; fi"
          }
        ]
      }
    ]
  }
}

実用パターン10選

パターン1：テストコード自動生成

.claude/commands/gen-tests.md

---
description: 指定ファイルのユニットテストを自動生成
allowed-tools: Read, Write, Bash(npx jest *), Bash(npm test *)
argument-hint: [対象ファイルパス]
---

@$ARGUMENTS

上記のコードに対して、以下の方針でテストを生成してください：

1. テストフレームワーク（Jest/Vitest/pytest等）を自動検出
2. 正常系・異常系・境界値のケースを網羅
3. 各テストに日本語コメントで意図を説明
4. モック・スタブが必要な依存を適切に処理
5. テストファイルの命名規則はプロジェクトに合わせる

生成後に `npm test [ファイル名]` を実行して通ることを確認してください。
不足情報があれば最初に質問してください。

パターン2：リファクタリング支援

~/.claude/commands/refactor.md

---
description: コードの可読性・保守性を改善するリファクタリングを実施
allowed-tools: Read, Write, Edit, Grep
argument-hint: [ファイルパス]
---

@$ARGUMENTS を以下の観点でリファクタリングしてください：

**必須対応**:
- 関数が50行を超えている場合は分割
- ネストが4階層を超えている場合はフラット化
- マジックナンバーは定数化
- 重複コードはDRY原則で統合

**命名の改善**:
- 1文字変数名を除去（ループカウンタは除く）
- 動詞+名詞の動詞で関数を命名
- ブール変数は is/has/can プレフィックスを使用

変更前後のコードを比較して説明してください。
テストが存在する場合は変更後に実行して通ることを確認してください。

パターン3：ドキュメント自動生成

.claude/commands/docs.md

---
description: 関数・クラスのJSDoc/docstringを自動生成
allowed-tools: Read, Edit
argument-hint: [ファイルパス]
---

@$ARGUMENTS のコードを分析して、以下のドキュメントを追加してください：

- TypeScript/JavaScript: JSDoc形式（@param, @returns, @throws, @example）
- Python: Google スタイルの docstring
- Go: GoDoc 形式

既存のコメントがある場合は内容を保持・補完してください。
英語で書くか日本語で書くかはプロジェクトの既存コメントに合わせてください。

パターン4：依存関係の更新確認

.claude/commands/check-deps.md

---
description: 依存パッケージのバージョンアップ可能な項目を確認
allowed-tools: Bash(npm outdated), Bash(npm audit), Read
---

## 現在の依存関係状況
!`npm outdated 2>/dev/null || pip list --outdated 2>/dev/null || echo "パッケージマネージャーを検出できませんでした"`

## セキュリティ監査
!`npm audit 2>/dev/null || safety check 2>/dev/null || echo "audit コマンドが見つかりません"`

以下を分析してください：
1. 重大度別の脆弱性一覧
2. メジャーバージョンアップで破壊的変更がある依存
3. 優先的に更新すべきパッケージと理由
4. 更新手順のコマンド案

パターン5：API レスポンス型定義生成

~/.claude/commands/gen-types.md

---
description: JSON・APIレスポンスからTypeScript型定義を生成
allowed-tools: Read, Write
argument-hint: [JSONファイルパスまたはAPI仕様URL]
---

$ARGUMENTS の JSON 構造を分析して TypeScript 型定義を生成してください：

- interface と type alias を用途に応じて使い分け
- nullable なフィールドは `T | null` または Optional（`?`）を明示
- 配列は具体的な要素型を指定
- 型名は PascalCase で命名
- 必要に応じて DTO / Entity / Response の役割で分離

生成後に `tsc --noEmit` で型エラーがないか確認してください。

パターン6：コードレビューチェックリスト

.claude/commands/checklist.md

---
description: マージ前の最終チェックリストを実行
allowed-tools: Read, Bash(git diff *), Bash(npm run lint *), Bash(npm test *)
---

## 変更内容
!`git diff main...HEAD --stat`

## マージ前チェックリスト

以下を順番に確認して結果を ✅/❌ で報告してください：

1. **テスト**: `npm test` が全て通るか
2. **Lint**: `npm run lint` でエラーがないか
3. **型チェック**: `npm run type-check` でエラーがないか
4. **変更規模**: 300行超の変更が1PRに含まれていないか
5. **環境変数**: ハードコードされたシークレットがないか
6. **コメント**: TODO/FIXME が残っていないか
7. **ドキュメント**: 公開APIの変更でドキュメントが更新されているか

パターン7：スプリントレビュー資料生成

~/.claude/commands/sprint-review.md

---
description: スプリントの変更内容をビジネス向け資料にまとめる
allowed-tools: Bash(git log *), Bash(git diff *), Bash(gh pr list *)
argument-hint: [開始コミットハッシュ or 日数]
---

## スプリント内のコミット
!`git log --oneline --since="$ARGUMENTS days ago" 2>/dev/null || git log --oneline $ARGUMENTS..HEAD`

## マージ済みPR
!`gh pr list --state merged --limit 20 --json number,title,mergedAt 2>/dev/null || echo "gh CLI が見つかりません"`

上記の変更を非エンジニア向けにまとめてください：

**スプリントサマリー**（3〜5行）

**主な変更点**（箇条書き・ユーザー視点で記述）

**次スプリントへの持ち越し課題**（もし把握できれば）

技術用語は括弧内に補足説明を入れてください。

パターン8：ローカライズ確認

.claude/commands/i18n-check.md

---
description: 多言語対応漏れを検出する
allowed-tools: Grep, Read
argument-hint: [対象ディレクトリ]
---

以下のパターンを $ARGUMENTS 以下のファイルで検索してください：

1. **ハードコードされた文字列**: JSX内の日本語・英語のハードコード
2. **翻訳キー未定義**: i18n キーが翻訳ファイルに存在しない
3. **未使用の翻訳キー**: 翻訳ファイルにあるがコードで使われていない
4. **数値フォーマット**: `toLocaleString()` を使わない数値表示

検出結果をファイル・行番号付きで報告してください。

パターン9：環境変数の整合性チェック

.claude/commands/check-env.md

---
description: .env.example と実際の使用箇所の整合性を確認
allowed-tools: Read, Grep
---

## .env.example の内容
@.env.example

## 環境変数の使用箇所
!`grep -rn "process.env." --include="*.ts" --include="*.js" src/ | grep -v "node_modules" | sort | uniq`

以下を確認してください：
1. `.env.example` に定義されているがコードで使われていない変数
2. コードで `process.env.*` として使われているが `.env.example` にない変数
3. デフォルト値なしで必須になっている変数のリスト
4. ドキュメント不足の変数（コメントがない）

パターン10：オンボーディング資料自動生成

.claude/commands/onboarding.md

---
description: 新メンバー向けコードベース説明資料を生成
allowed-tools: Read, Glob, Bash(git log *)
---

## プロジェクト構造
!`find . -type f -name "*.md" | grep -v node_modules | head -20`

## 最近の変更傾向
!`git log --oneline -20`

このリポジトリのコードを分析して、新しいチームメンバー向けの説明資料を作成してください：

1. **プロジェクト概要**: 何を解決するシステムか
2. **技術スタック**: 主要ライブラリと選定理由
3. **ディレクトリ構造**: 各フォルダの役割
4. **開発フロー**: ブランチ戦略・テスト・デプロイ手順
5. **よくある作業**: 機能追加・バグ修正の典型的な手順
6. **注意点・ハマりやすい箇所**: 既知の落とし穴

Markdown 形式で出力してください。

【要注意】よくある失敗パターン3選

失敗1：$ARGUMENTS を検証せずに使う

❌ ファイルパスを引数に取るコマンドでパスの存在確認をしない
⭕ ファイル参照前に存在確認のロジックを入れる

# OK: 引数がなかった場合の挙動を明示する
---
argument-hint: [ファイルパス]
---
$ARGUMENTS で指定されたファイルを処理してください。
引数が指定されていない場合は、現在のディレクトリの主要なファイルを推定して処理してください。
不足情報があれば最初に質問してください。

失敗2：プロジェクト固有のパスをグローバルコマンドに書く

❌ グローバルコマンドに特定プロジェクトのファイルパスを直書きする
⭕ $ARGUMENTS や自動検出を使う

# NG: 特定プロジェクトに依存したグローバルコマンド
!`cat /Users/alice/my-project/config/deploy.yaml`

# OK: 相対パスまたは自動検出
!`find . -name "deploy.yaml" | head -1 | xargs cat`

失敗3：コマンド名が組み込みコマンドと衝突する

❌ /review、/init、/compact など組み込みコマンドと同名にする
⭕ プロジェクト固有のプレフィックスを付ける

組み込みコマンドと同名のカスタムコマンドを作ると、どちらが優先されるか予測しづらくなります。pr-review、myinit のように識別できる名前にしましょう。

よくある質問

Q1. スラッシュコマンドと CLI コマンドは何が違いますか？

打つ場所が違います。スラッシュコマンド（/compact など）は Claude Code の会話の中で打ち、CLI コマンドとフラグ（claude -p、--model など）はターミナルで Claude Code を起動するときに付けます。同じ目的でも両方ある場合があり（例: サインインは /login でも claude auth login でも可、診断は /doctor でも claude doctor でも可）、スクリプトから使うなら CLI 側です。

Q2. カスタムコマンドとスキル（/skills）はどちらを作ればよいですか？

「自分が打って動かす定型プロンプト」はカスタムコマンド、「Claude が状況に応じて自分で読みに行く手順書」はスキルです。v2.1.101 以降は .claude/skills/ が推奨形式なので、新しく作るものはスキルにし、既存のコマンドは動くうちはそのまま使うのが現実的です。詳しくは前述の「スキル（/skills）との使い分け」と スキルの作り方ガイド を参照してください。

Q3. VS Code 拡張やデスクトップアプリでも同じコマンドが使えますか？

スラッシュコマンドは使えます。公式の VS Code ドキュメント（参照日 2026年9月22日）では、プロンプト欄で / を打つか Customize の Slash commands から組み込み・カスタムコマンドを選んで実行でき、/usage・/btw・/compact・/copy などが例示されています。一方、CLI のフラグはターミナルで起動するときのものなので拡張側には当てはまらず、キーボードショートカットも端末と拡張で一部異なります。拡張の導入手順は Claude Code の VS Code 連携ガイド にまとめています。

Q4. バージョンを更新するとコマンドは変わりますか？

変わります。例えば /agents は v2.1.198 から案内表示だけになり、起動フラグの --enable-auto-mode は v2.1.111 で廃止されました（公式 Commands・CLI reference・参照日 2026年9月22日）。社内手順書にコマンド名を書くときは版数を併記し、更新後は /help と claude --help で差分を確認してから配り直すと事故が減ります。

Q5. 会社標準の許可設定はどう決めればよいですか？

前述の 4 手順のとおり、①1〜2 週間の利用で出た確認を許可・確認・拒否に仕分け、②.claude/settings.json の permissions に書いてリポジトリで共有し、③permissions.disableBypassPermissionsMode を "disable" にして全部省略モードを止め、④/usage で月に一度使用量を見る、の順です。最初から完璧な一覧を作ろうとせず、確認が出た操作から順に仕分けるのがコツです。

まとめ：今日から始める3つのアクション

Slash Command の全体像をまとめます。

• コマンドはスラッシュ・CLI・ショートカットの 3 系統。組み込みコマンドは /help で自分の版のものを見る（v2.1.278 で /compact・/review・/plan・/usage・/permissions を確認）
• カスタムコマンドは .md ファイルを1つ置くだけ。allowed-tools・argument-hint・!`shell`・@ファイル で柔軟に拡張できる
• .claude/commands/ を git commit すればチーム全員が同じコマンドセットを使える

今日からできるアクションを3つ示します。

1. 今日やること: 「即効コマンド1」の PR レビューコマンドを ~/.claude/commands/review-pr.md に保存して試してみる
2. 今週中: チームで「毎回同じプロンプトを打っているもの」を洗い出し、上位3つをコマンド化する
3. 今月中: .claude/commands/ をプロジェクトのリポジトリに commit してチームに展開する

あわせて読みたい:

• Claude Code Hooks完全ガイド2026｜PreToolUse・PostToolUse実装 — Slash Command と組み合わせて自動化をさらに強化
• 【2026年最新】Claude Code完全ガイド｜できること・料金・使い方 — Claude Code の全体像をおさらい
• Claude Code ベストプラクティスTOP10｜現場で効果があった設定 — 実務で使える設定集

参考・出典

• Commands — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• CLI reference — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• Interactive mode（キーボードショートカット） — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• Permission modes — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• Permissions — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• VS Code — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-09-22）
• Claude Code v2.1.278 の実機出力（claude --version・/help・claude auth status・claude mcp list・claude -p --output-format json）— Uravation 社内で 2026-09-22 に実行
• Slash Commands in the SDK — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-05-06）
• GitHub: wshobson/commands — プロダクション向けSlash Commandコレクション — wshobson（参照日: 2026-05-06）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

あわせて読みたい: Slash CommandをPlugin内にバンドルしてチームに一括展開する方法は、Claude Code Plugin開発ガイド2026｜Hooks/MCP統合で解説しています。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。