はじめに

Claude Codeには多くのコマンドがあります。
/init、/memory、/plan、/diff、/review、/security-review、/loop など、業務で使えるものは多い一方で、全部をチーム標準にしようとすると運用が散らかります。

重要なのは、便利なコマンドを覚えることではありません。
どの業務フェーズで、どの判断を支えるために使うのかを決めることです。

この記事では、最近の開発業務で使いやすいClaude Codeコマンドを、レビュー視点で使い分けます。

まず /help で利用可能なコマンドを確認する

Claude Codeのコマンドは、環境、プラン、OS、管理者ポリシーによって表示や利用可否が変わることがあります。
そのため、チーム標準を作る前に、まず各メンバーの環境で /help を確認します。

/help

チーム用ドキュメントに「必ず使うコマンド」として書くなら、次も確認しておきます。

  • そのコマンドが全員の環境で使えるか
  • 追加ツールが必要か
  • 権限や外部連携が必要か
  • ローカルだけで完結するか
  • PRや本番環境に影響する可能性があるか

コマンド運用のレビューでは、「便利そうか」ではなく「チームで再現できるか」を見ます。

1. プロジェクト導入時は /init と /memory

新しいプロジェクトでClaude Codeを使い始めるなら、最初に見るべきは /init と /memory です。

/init は、プロジェクト向けの CLAUDE.md 作成を支援します。
既存のビルドコマンド、テストコマンド、プロジェクト構造を整理する入口として使えます。

/init

ただし、生成された CLAUDE.md をそのまま信頼するのは危険です。
チームでレビューし、古いコマンド、曖昧なルール、個人設定の混入がないかを確認します。

/memory は、読み込まれている CLAUDE.md やメモリ関連の確認に使えます。

/memory

レビュー観点は次の通りです。

  • どの CLAUDE.md が読み込まれているか
  • チーム共有ルールと個人メモが混ざっていないか
  • 古いコマンドや矛盾した指示が残っていないか
  • AIが繰り返し間違える内容がルール化されているか

Claude Codeの品質は、毎回のプロンプトだけでなく、最初に読み込ませる文脈で大きく変わります。

2. 実装前は /plan を使う

複雑な変更をいきなり実装させると、意図と違う方向に進むことがあります。
設計変更、影響範囲の広い修正、レビュー指摘対応では、先に /plan を使います。

/plan fix the authorization boundary around project settings

/plan の成果物として見るべきなのは、作業手順そのものではありません。
レビューアーとしては、次を確認します。

  • 影響範囲が適切に切られているか
  • 先に読むべきファイルが挙がっているか
  • テストや検証が計画に含まれているか
  • 変更しない範囲が明示されているか
  • 危険な操作が混ざっていないか

計画レビューを挟むことで、実装レビューの手戻りを減らせます。

3. 作業中は /context と /compact を使い分ける

Claude Codeで長めの作業をしていると、会話やファイル読み込みが増え、文脈が膨らみます。
その状態で作業を続けると、古い前提を引きずったり、重要なルールが埋もれたりします。

現在の文脈使用状況を確認したいときは /context を使います。

/context

会話を続けたいが文脈を整理したいときは /compact を使います。

/compact Focus on the current auth refactor, changed files, open risks, and verification results.

レビュー観点としては、/compact に何を残すかが重要です。

  • 変更目的
  • 触ったファイル
  • 未解決のリスク
  • 実行済みコマンド
  • 失敗した検証
  • ユーザーが明示した禁止事項

単に文脈を圧縮するのではなく、レビューに必要な判断材料を残すように指示します。

4. 差分確認は /diff を使う

実装後にまず見るべきなのは、Claudeの説明ではなく実際の差分です。
/diff は、未コミット差分やターンごとの差分を確認する入口になります。

/diff

レビューでは、次を確認します。

  • 要求外のファイルが変更されていないか
  • フォーマットだけの差分が混ざっていないか
  • 生成されたコードが既存スタイルから外れていないか
  • テストやドキュメントの変更が過不足ないか

AIの最終報告が正しく見えても、差分を見ると不要な変更が入っていることがあります。
/diff は、Claude Code作業のレビューで最初に使うべきコマンドです。

5. PR前は /review と /security-review

PR前のセルフレビューには /review と /security-review が使えます。

/review
/security-review

/review は、ローカルでPRや変更内容を確認する用途に向いています。
/security-review は、認証、認可、入力処理、機密情報、外部通信などのリスクを洗うときに使います。

ただし、これらの出力は「通ったから安全」という証明ではありません。
レビューアーは次のように扱います。

  • 指摘は候補として読む
  • 誤検知や文脈不足を疑う
  • 高リスク領域は人間が再確認する
  • PRコメントにする前に、自分の言葉で設計論点に変換する

AIレビューは、レビューの代替ではなく、見落とし候補を増やすための補助です。

6. 繰り返し確認は /loop

ビルド待ち、テスト追加、レビュー指摘対応、PRコメント確認のように、同じ確認を何度も行う作業には /loop が向いています。

/loop 15m check the current diff and report only new review risks

チームで使うなら、/loop には必ず制約を入れます。

  • 何分ごとに実行するか
  • 何を対象に見るか
  • 編集してよいか、報告だけか
  • 同じ指摘を繰り返すか
  • いつ止めるか

/loop は強力ですが、放置すると同じ出力や不要な修正が増えます。
繰り返し実行するほど、停止条件と権限境界が重要になります。

7. 権限管理は /permissions で見直す

Claude Codeに任せる作業が増えるほど、権限設計が重要になります。
/permissions は、許可、確認、拒否のルールを見直すために使います。

/permissions

チーム運用では、次のように分けると安全です。

種類 方針
読み取り系 git diff, rg, ls などは許可しやすい
検証系 npm test, pnpm lint などはプロジェクトごとに判断する
変更系 ファイル編集はタスク単位で確認する
危険操作 deploy, reset, migration, delete は原則拒否または明示確認

権限は一度設定して終わりではありません。
新しいコマンドや自動化を追加したら、権限もレビューします。

チーム標準にしやすいコマンドセット

最初から多くのコマンドを標準化する必要はありません。
まずは次のセットから始めると、実務に乗せやすいです。

フェーズ コマンド 目的
導入 /init CLAUDE.md の初期作成
文脈確認 /memory 読み込まれている指示の確認
計画 /plan 実装前の方針レビュー
作業中 /context, /compact 文脈量と要約の管理
差分確認 /diff 変更内容の確認
PR前 /review, /security-review セルフレビュー
繰り返し /loop 定期確認
安全管理 /permissions ツール権限の見直し

この表をそのまま CLAUDE.md に入れるのではなく、自分のプロジェクトで使うものだけに絞ります。

まとめ

Claude Codeのコマンドは、単体で覚えるより、業務フェーズに紐づけて使うほうが実務で効きます。

  • /init と /memory は、チーム共有文脈を整える
  • /plan は、実装前に影響範囲と検証方針をレビューする
  • /context と /compact は、長い作業の文脈劣化を防ぐ
  • /diff は、AIの説明ではなく実差分を見るために使う
  • /review と /security-review は、PR前の見落とし候補を増やす
  • /loop は、繰り返し確認を任せるが、停止条件を必ず決める
  • /permissions は、チームの安全境界として定期的に見直す

チームでClaude Codeを使うなら、「便利なコマンド集」ではなく「レビュー可能な業務フロー」として整理することが重要です。
どのコマンドをいつ使い、何を成果物にし、どこから人間が判断するのかを決めておくことで、Claude Codeは単なる補助ツールから、チームの開発プロセスに組み込める作業基盤になります。

参考