Go back

Claude Codeのスラッシュコマンドを、自分が打つ順に棚卸しした

Posted on:

Claude Codeのスラッシュコマンドを、いつも同じ5個くらいしか打っていません。公式ドキュメントの一覧には100個以上が並んでいるので、一度自分の作業の流れに沿って並べ直してみました。ついでに、チャットから使うときとターミナルから使うときで一覧が違う件も整理しておきます。

コマンドの扱われ方を先に知っておく

個々のコマンドの前に、共通の挙動を3つ押さえておくと迷いが減ります。

メッセージの先頭でしか認識されない。 文章の途中に /compact と書いても、ただの文字列として渡ります。コマンド名の後ろに続けたテキストは引数として扱われます。

スキルだけはチェーンできる。 v2.1.199以降、/skill-a /skill-b やっといて のように書くと、先頭に並べたスキルがすべて読み込まれ、末尾のテキストが各スキルへ引数として渡ります。最大6つまで繋げられます。

応答中に打つとキューに入る。 Claudeが喋っている最中に送ったコマンドは、そのターンが終わってから実行されます。ただし /status /tasks /usage のような一部は、応答を止めずにその場で走ります。作業を眺めながらコストを確認したいときに使えます。

リポジトリに入った最初のセッションで打つもの

新しいリポジトリで最初にやることは、だいたい決まっています。

  • /init:スターターの CLAUDE.md を生成する
  • /memory:生成された CLAUDE.md を開いて手で直す
  • /mcp:そのプロジェクトで必要なMCPサーバーを設定する
  • /permissions:承認ルールを決める。毎回聞かれて鬱陶しいコマンドはここで通す

/init は叩き台を作るだけなので、/memory で手を入れるところまでがワンセットになります。ここを雑にすると後で毎回同じ説明をする羽目になるので、最初のセッションで一番時間をかける価値があります。

タスク中に効くもの

作業に入ってから使うのは、モデルとコンテキストの制御が中心になります。

  • /plan:Plan Modeに切り替える。大きめの変更の前に挟む
  • /model:使うモデルを変える
  • /effort:推論をどれだけ厚くするかを変える(low〜max)
  • /context:今コンテキストウィンドウを何が埋めているかを表示する
  • /compact:会話を要約して空ける
  • /btw:本流を止めずに脇道の質問をする

自分がよく効くと感じたのは /context/btw の2つです。/context は「なんか重いな」と思ったときに中身を見せてくれるので、/compact を打つ前に一度挟むと判断がつきます。/btw は「これ関係ないけど聞きたい」を会話履歴に残さず処理できるので、本流の文脈を汚さずに済みます。

並行して走らせるもの

1つのセッションで待っているのがもったいないときに使います。

  • /tasks:バックグラウンドで動いているものを一覧する。完了したサブエージェントも含む
  • /background:セッションごと切り離してバックグラウンドで走らせ、ターミナルを解放する
  • /batch:大きい変更を独立した単位に分解し、それぞれを別のworktreeで走らせる

/batch はコードベース全体にまたがる修正、たとえば「全ファイルのimport順を直す」みたいなときに向いています。worktreeごと分かれるので、互いに踏みません。

出す前に通すもの

レビュー系はコマンドが複数あって紛らわしいので、違いを書いておきます。

  • /diff:変更内容を表示する
  • /code-review:diffの正確性のバグとクリーンアップを見る。--fix を付けると検出結果をそのまま適用する
  • /review:GitHubのPRに対する高速な単一パスのレビュー。読み取り専用
  • /security-review:diffのセキュリティ脆弱性を見る
  • /code-review ultra:クラウドでマルチエージェントのレビューを回す

普段は /code-review で足ります。/review はPRに対する軽い確認、ultra は腰を据えて見たいときという住み分けになります。

セッションをまたぐもの

  • /clear:コンテキストを空にして新しいタスクを始める。プロジェクトメモリは保持される
  • /resume:前の会話に戻る
  • /branch:今の地点で会話を分岐させる
  • /teleport:Webのセッションをこのターミナルに引き込む
  • /remote-control:このローカルセッションを別のデバイスから続ける

/clear/compact は用途が違います。同じ話を続けるなら /compact、話題を切り替えるなら /clear です。迷ったら「この後の作業で前の話を参照するか」で決めればいいと思います。

何かおかしいときのもの

  • /rewind:コードと会話をチェックポイントまで巻き戻す
  • /doctor:インストールと設定の問題を診断する
  • /debug:ランタイムの問題を診断する
  • /feedback:セッションのコンテキストを添えてバグを報告する
  • /usage:セッションのコストとプランの使用状況を見る

/rewind は「AIに壊されたコードを戻す」ためだけのものではなく、会話の一部を要約する使い方もできます。

チャットとターミナルで使えるコマンドが違う

ここが今回一番はっきりさせたかったところです。デスクトップのチャットUIから / を打つと、上に挙げたコマンドの大半が出てきません。/model/config/permissions/resume もありません。

理由はシンプルで、これらがターミナル上に対話UIを描くタイプのコマンドだからです。モデル選択の画面も、権限設定の画面も、セッション一覧も、ターミナルに描画されることを前提に作られています。チャットには描画先がありません。

チャットでもそのまま使える組み込みコマンドは、実際に数えたら13個でした。

/autocompact /btw /clear /compact /context /goal /mcp /pause-memory /recap /reload-plugins /reload-skills /skill-doctor /usage

これに加えて、/init /code-review /security-review のようなバンドルスキル(実体はMarkdownの手順書)と、自分で書いたコマンドが並びます。逆に言えば、画面を出すコマンドはターミナル専用と覚えておけば大体合います。

もう一段ややこしいのは、アカウント側のフィーチャーフラグで出し分けられているコマンドがあることです。/autofix-pr/heapdump がそれにあたります。フラグが立っていないと、打っても動かないのではなく、一覧に存在しません。同僚と画面を見比べて「そのコマンド無いんだけど」となるのはこれが理由です。

実務上の結論はひとつで、チーム内の手順書に組み込みコマンドを書かないほうがいいです。「まず /config で設定して」と書いた手順書は、チャットから入った人の手元で1行目から詰まります。共有するなら、環境によらず動くところに寄せます。

自分で足したコマンドはどこでも動く

.claude/commands/.claude/skills/ に置いた自作コマンドは、中身がMarkdownの手順書なので、ターミナルでもチャットでもクラウドセッションでも同じように呼べます。

自分の場合はObsidian Vault側に /kb-compile /kb-report /kb-lint を、このブログ用に /blog を置いています。使う側では意識していませんでしたが、これらがどこからでも動いていたのは、対話UIを持たない形式だったからでした。逆に言えば、チームに配る前提なら最初からこの形で書けばいいことになります。組み込みコマンドを覚えてもらうより、リポジトリに置いた手順書を1個共有するほうが確実に届きます。

並列開発に踏み込むならターミナルに居る

コマンドの話の延長で、エージェントチームにも触れておきます。複数のClaude Codeインスタンスをチームとして協調させる機能で、まだ実験的扱いのため環境変数で有効化します。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

サブエージェントとの違いは、チームメイト同士が直接やり取りする点です。サブエージェントは結果をメインに返すだけですが、チームメイトは独立したコンテキストウィンドウを持ち、共有タスクリストとメールボックスを通じて互いに通信します。サーバーワークスの入門記事が、この差を「部下」と「それぞれの専門領域を持つプロジェクトメンバー」と表現していて分かりやすかったです。

そして、これもターミナル前提の機能になっています。

  • チームメイトの選択と切り替えは、プロンプト下のエージェントパネルで上下矢印とEnter
  • リーダーが自分で実装を始めるのを止めるDelegate Modeは Shift+Tab
  • 各チームメイトを別ペインに出す分割ペインモードは tmux か iTerm2 が必要で、VS Codeの統合ターミナルやWindows Terminalでは動かない

操作系がキーバインドとペインでできているので、チャットからは回せません。自分はチャットUIから入ることが多いのですが、並列で走らせる日はターミナルに移ると決めました。

運用面で拾っておきたかったのは次の点です。

  • チームサイズは3〜5人から。チームメイトあたり5〜6タスクが目安で、独立した15タスクなら3人が出発点になる
  • ファイルの所有権を分ける。同じファイルを複数人が編集すると上書き競合が起きるので、担当ディレクトリを指示に明示する
  • まず読み取り専用のタスクから。並列コードレビューなら競合のリスクがない
  • チームメイトはリーダーの会話履歴を引き継がない。ただし作業ディレクトリの CLAUDE.md は読む
  • コストは人数に比例する。チームメイトのモデルにSonnetを指定すれば抑えられる

4つ目が、前の節と同じ話に行き着きます。人間のチームメイトにもAIのチームメイトにも、確実に渡るのはリポジトリに置いたファイルだけです。会話の中で共有したつもりの前提は、どちらにも届きません。並列度を上げるほど、CLAUDE.md.claude/ に何を書いてあるかが効いてきます。

棚卸しして変わったこと

結局のところ、100個を覚える必要はありませんでした。作業の流れに沿って並べ直すと、常用するのは各フェーズに2〜3個ずつで、合計しても15個くらいに収まります。むしろ収穫は、コマンドを覚えることではなく、環境によって使えるものが変わる前提で手順書を書くようになったことでした。

一覧そのものは公式ドキュメントにまとまっているので、全部見たい場合はそちらが正確です。