【Claude Codeを一段上に】10個のコマンドを「使える」状態に並べ直す話

朝比奈幸太郎リリース：音のアプリ使い放題プラットフォーム『空音開発』

Claude Code、みなさんお使いでしょうか。
もはや生活の一部？人生の一部？これがなければもう仕事が成り立たないという方も多いのではないでしょうか。

今回はスラッシュコマンドについて。
料理で言えば調味料に近くて、振りかける順番と量を間違えると、せっかくの素材が台無しになる。。。そんな存在です。

一般的に言われている10個くらいを並べただけでは料理にならないので、ここでは私なりに「どの順番でどう使うか」「どこにどの数値を入れるのか」という観点から組み直してみたいと思います。

さらに実務でかなり効くコマンドや設定もいくつか追加していきます。

作業のフェーズで分けて捉え直す

私が思うに、Claude Code関連のコマンドは大きく五つの層に分けられます。
仕込みの層、思考の層、実行の層、修復の層、振り返りの層です。
料理で言えば仕込み、味の設計、調理、リカバリ、片付けに相当します。

この順に整理すると、それぞれのコマンドが何のために存在しているのかが、ようやく見えてきます。

仕込みの層、ここで勝負が9割決まる

最も大事なのは実は仕込みです。
Claude Codeを一段上に押し上げたいなら、ここに時間を使うのが結局いちばん近道だと感じています。

CLAUDE.mdとdesign.md、双子のドキュメント

CLAUDE.mdはプロジェクトルートに置くマスター設定ファイルで、Claudeが起動するたびに自動で読み込まれます。

CLAUDE.mdに関しては過去の記事で詳細に紹介していると思います。

mdファイルの中身として書くべき項目は概ね決まっていて、プロジェクトの概要、技術スタック、ディレクトリ構造の説明、命名規則、テストの実行方法、コミット規約、避けてほしい実装パターン、この辺りです。

具体的にどう書くかというと、たとえばこんな粒度で記述します。

Copy# プロジェクト概要
React + TypeScript + Viteの構成。Tailwind CSSを使用。

# ディレクトリ規約
- src/components/ui に汎用UIコンポーネント
- src/features/ に機能単位のフォルダ
- src/lib/ にユーティリティ

# コーディング規約
- コンポーネントは関数型で書く、クラスは使わない
- propsの型定義は必ずinterfaceで切る
- any型は禁止
- console.logは本番コードに残さない

# テスト
- vitestを使用、`pnpm test`で実行
- 新規ファイル作成時は必ずテストも作成する

# 避けてほしいこと
- 既存のファイル構造を勝手に変えない
- npm/yarnではなくpnpmを使う

これを最初に整備するだけで、Claudeとの会話で毎回説明していた前提が消えます。

design.mdはその上に乗る設計意図のドキュメントです。
Google StitchやFigma系のツールから書き出されるDESIGN.mdの形式が一つの標準になりつつあって、画面の構造、データフロー、ユーザー操作の流れを構造化して記述。

Claudeに「design.mdを参照して実装して」と一言伝えるだけで、設計に沿ったコードが返ってくるようになります。

ここで力を抜くと、後段でいくらコマンドを駆使しても、Claudeは毎回ゼロから推測することになります。

私はこの仕込みフェーズが、AIコーディング時代における「腕の見せ所」になりつつあると思っています。

コードを書く能力よりも、Claudeに自分の頭の中を読み取らせるための文書を書く能力のほうが、相対的に価値を増しているのが2026年のAIの取説といったところでしょうか。

/effort、火加減のレバー

/effortはClaudeがどれだけ思考リソースを使うかを制御するパラメータで、low、medium、highの三段階を切り替えられます。

デフォルトは中庸に設定されているので、複雑な設計判断が必要な場面ではhighに、単純な修正ならlowに、と意識的に切り替える。

これを知らずに使っていると、簡単な作業に過剰なトークンを溶かしたり、逆に難しい判断を浅く済まされたりするわけです。

/effort highに切り替えるのが効くのは、アーキテクチャの設計判断、複雑なバグの原因究明、リファクタリングの方針決定など、Claudeに「考えてから動いてほしい」場面です。

逆に/effort lowが向くのは、明確に決まったテンプレ作業、コメント追加、フォーマット修正など、判断を必要としない単純作業。

料理に例えるなら火加減とでもいいましょうか。

常に強火で焼いていたら焦げる、というだけの話なんですが、これを意識しているかどうかで結果は変わります。

料理だって基本的に急いでいる時以外は弱火調理が最高ですよね。

Auto modeと/fewer-permission-prompts、信頼の設計

Auto modeと/fewer-permission-promptsはClaude Codeのパーミッション疲れを解消するための新しい仕組みで、コマンドの安全性をClaude自身が分類器で判定して、安全なものは自動承認してくれます。

具体的な設定としては、プロジェクトの.claude/settings.jsonに許可するコマンドのパターンを明示的に書いておくのが安全です。

Copy{
  "permissions": {
    "allow": [
      "Bash(pnpm test:*)",
      "Bash(pnpm lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push:*)",
      "Edit(.env*)"
    ]
  }
}

こうしておけば、読み取りやテスト実行は黙って通すが、破壊的なコマンドや本番ブランチへのプッシュは必ず確認、という設計ができます。

安全と効率はトレードオフで、自分のプロジェクトの性質に合わせて設定する必要があります。

仕込みコマンド、/hooksと/mcp

ここからは仕込みフェーズで本気で効いてくるものを補足しておきます。

hooksはClaude Codeの動作にフックを差し込む仕組みで、PreToolUse（ツール実行前）、PostToolUse（ツール実行後）、Stop（セッション終了時）などのイベントに任意のスクリプトを噛ませられる。

たとえばClaudeがファイルを編集した直後に自動でlintを走らせる、テストを実行する、コミット前にフォーマッタをかける、といった処理を自動化できます。

.claude/settings.jsonにこう書きます。

Copy{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "pnpm lint --fix" }
        ]
      }
    ]
  }
}

これでClaudeがファイルを書き換えるたびに、自動でlinterが走って整形してくれます。

手動で「lintかけて」と頼む必要がなくなります。

MCP（Model Context Protocol）は、Claude Codeに外部ツールやサービスを接続するための仕組みです。GitHub、Notion、Slack、PostgreSQL、Figmaなど、多種多様なMCPサーバーが公開されていて、claude mcp addコマンドで追加可能です。

たとえばGitHubのMCPを入れれば、Claudeが直接Issueを読みに行ったり、PRを作成したりできるようになる。

最近の実感として、Claude Codeを単独で使うのとMCPを組み合わせて使うのとでは、もはや別のソフトと言っていいくらい体験が違います。

仕込みの段階で、自分の作業に必要なサービスのMCPを揃えておく、というのが新しい当たり前になりつつある。

思考の層、走り出す前に考えさせる

Claude Codeには三つの動作モードがあって、Shift+Tabを押すたびに循環で切り替わります。
通常モード、Auto-Acceptモード、Plan Modeの三つです。
Plan Modeに入ると、Claudeはファイルの変更を一切行わず、調査と計画立案だけを行う状態になる。

私の使い方としては、新しい機能を実装するときや、大きなリファクタリングに着手するときは、必ずまずPlan Modeで「これからやろうとしていることの計画を立てて」と指示します。

Claudeはコードベースを調査し、変更するファイル、追加するファイル、想定される影響範囲を文書化して返してくれる。

これを読んで修正指示を出してから、通常モードに戻して実装に入る。

この一手間が、後段で発生する「Claudeが意図と違う方向に走り出す」事故を激減させます。

設計フェーズと実装フェーズを明確に分ける、というだけの古典的な開発手法を、AIコーディングの文脈で再導入する次第であります。

thinkとultrathink、思考の深さの呪文

これは知っているかどうかで体験が大きく変わる機能なんですが、プロンプトにthink、think hard、think harder、ultrathinkという単語を含めると、Claudeの拡張思考（extended thinking）が段階的に有効化されます。

ultrathinkが最も深く、最大3万トークン近くを思考に使うことをご存じでしょうか。

「このバグの原因を調査して」と頼むよりも、「このバグの原因をultrathinkで徹底的に調査して」と頼むほうが、思考の深さが桁違いになります。

コードを生成させる場面というよりは、原因究明、設計判断、トレードオフの検討、こういった「考えること自体が目的」の場面で効きます。

私はClaude Codeに難しい問いを投げるとき、頭の中で「これはthinkで足りる質問か、ultrathinkを呼ぶべき質問か」を一瞬考えてから入力するようにしています。
これも火加減の調整の一種です。

ちなみに〜に回答

/btwは私が個人的に最も面白いと感じたコマンドです。
Claudeが長いタスクを処理している最中に、本流の文脈を汚さずに「ちなみに」と横から別の質問を投げられる機能で、フォークされた別チャンネルで一回答だけ返してくれるコマンド。
大変に便利です。

具体的には、Claudeが大規模なリファクタリングを処理している最中に、/btw このAPIのレスポンス形式ってどうなってた？と打つと、本流の作業のコンテキストを巻き戻さずに、その質問だけに答えて元の作業に戻れる。

思考の脱線を許容しつつ本流を守る、という設計思想がとても良いと思います。

！（バン）コマンド、シェルへの直通回線

！（バン）コマンドはClaude Codeの中から直接シェルコマンドを実行する機能です。

!ls、!git status、!pnpm testと打てば、その場で結果が表示される。

VSCodeのターミナルに切り替えなくていい、というだけの小さな効率化ですが、これが積もると一日の集中力の総量がだいぶ変わってくる。

Ctrl+Bを使えばバックグラウンド実行もできるので、!pnpm devで開発サーバーを起動したまま作業を続けられる。
地味ですが、これも知っているかどうかで体験が違います。

/batchとサブエージェント、並列処理の世界

/batchに関連する話として、Claude Codeはサブエージェントを使った並列実行に対応しています。

Taskツールを使って、複数のサブエージェントに別々の調査や作業を並行で投げられます。

実用的な使い方の例としては、大規模なコードベースで「認証周り、決済周り、通知周りの実装を同時に調査して」と指示すると、Claudeが三つのサブエージェントを立ち上げて並列に作業し、結果を統合してくれる。

一つずつ順番に調べるより、体感で数倍速くなります。

Claudeに「複数の自分自身を起動して並行作業させる」という指示を出せるんです。

私はまだここをあまり使いこなせていないんですが、おそらく今後一年で、ここの巧拙が生産性を大きく左右する領域になると見ています。

カスタムスラッシュコマンド、自分専用の道具を作る

これは絶対に紹介すべき機能だと感じています。

.claude/commands/ディレクトリにMarkdownファイルを置くと、ファイル名がそのままスラッシュコマンドになります。

たとえば.claude/commands/review.mdにこう書いておくと。

Copy直近の変更について、以下の観点でレビューしてください。
1. 型の安全性
2. エラーハンドリングの妥当性
3. テストカバレッジ
4. パフォーマンスへの影響
5. セキュリティ上の懸念

各観点について、問題があれば具体的な修正案も示してください。

これで/reviewと打つだけで、毎回同じ観点のレビューを実行できるようになります。

自分の作業パターンに合わせて、/commit（コミットメッセージ生成）、/test-gen（テスト生成）、/refactor（リファクタ提案）など、好きなだけ作れます。

私の経験では、同じ指示を3回以上繰り返したら、それはカスタムコマンドにすべきサインです。

修復の層、ここで事故から戻れる

/rewind、近年最高の発明の一つ

/rewindは私の感覚では、近年のAIコーディングツールにおける最も重要な発明の一つです。
Claudeに作業させていると、時々、致命的に間違った方向に走り出すことがありますよね。

普通に使っていれば事故は必ず起きる前提で、/rewindはその事故から復帰するための機能です。

仕組みとしては、Claudeが各プロンプトの実行前にチェックポイントを自動生成しておき、Escを二回押すかコマンドを入力すれば、その時点のファイル状態に戻せる。

作成されたファイルは削除され、変更されたファイルは元の内容に復元される。

これはバージョン管理（Git）とは少し性質が違っていて、コミットに依存しない、より手前の安全網です。

私はClaudeに大きな変更を投げる前に、頭の中で「ここで失敗したら/rewindで戻ればいい」というセーフティネットを意識的に張ってから走らせるようにしています。

これがあるのとないのとでは、Claudeに対して大胆な指示を出す心理的なハードルが大きく変わります。

/resume、止めた場所から再開する

/resumeはもう少し性質が違っていて、過去のセッションそのものを呼び戻す機能です。

claude --resumeでセッション一覧から選んで、止めた場所から再開できる。

文脈をもう一度説明する手間が消えます。

claude --continueは直前のセッションを即座に再開、claude --resumeはセッション一覧から選択して再開、という違いがあります。

複数のプロジェクトを並行で進めているときは--resume、同じ作業の続きをすぐ再開したいなら--continue、と使い分けるのが定石です。

/compactと/clear、文脈の管理術

ここも元投稿に載っていないですが、長く作業していると必ず必要になる機能です。

/compactは会話の履歴を要約して圧縮する機能で、文脈は保ちつつトークン消費を抑えられます。

長い作業セッションの途中で、Claudeの反応が鈍くなってきたな、と感じたら/compactを打つ。
重要な決定や変更履歴は残しつつ、冗長な部分が圧縮されます。

/clearは会話の履歴を完全にリセットする機能で、別の作業に切り替えるときに使います。

前の作業の文脈を引きずらせたくないときの選択肢です。

使い分けの目安としては、「同じ作業を継続したいが文脈が膨らみすぎた」なら/compact、「全く別の作業に移る」なら/clear。

一日のうちで作業の話題が変わるたびに/clearを挟む習慣を持つだけで、Claudeの応答精度がかなり安定します。

振り返りの層、自分の使い方を観察する

/insights、外在化された自己

/insightsは過去30日間のClaude Codeセッションを分析して、HTMLレポートを生成してくれる機能。自分がどのモデルをどれくらい使っているか、どこで摩擦が起きているか、CLAUDE.mdの改善余地はどこか、といった観点で分析されます。

実はこれが、個人的に最も哲学的に興味深いと感じているコマンドです。

自分の作業の癖を、Claude自身に観察させて報告させる。
鏡を持たされる感覚に近いわけですね。
人間は自分の手癖や非効率を、自分では意識できませんが、それを外側のシステムが客観的に見せてくれる、というのは、心理療法における外在化の作業に少し似ています。

/insightsがやっているのはまさにそれで、コマンドの実用性以上に、自分の作業を俯瞰する視点を与えてくれることに本質的な価値があると思っています。

一日の流れにどう組み込むか

ここまでの内容を、実際の一日の作業フローに落とし込むとこうなります。

朝、作業を始める。
プロジェクトディレクトリでclaude --resumeを実行し、昨日の続きから再開する。
今日のタスクを確認したら、Shift+Tabを二回押してPlan Modeに入り、「今日やる予定の機能Aについて、変更範囲を洗い出して計画を立ててください、ultrathink」と指示する。
返ってきた計画を読んで修正点を伝え、合意できたら通常モードに戻す。

実装に入る前に/effort highに切り替え、「計画に従って実装してください」と投げる。Auto modeが有効なので、ファイル編集やpnpm testの実行は自動で進む。
途中で「ところでこのAPIの認証方式って何だっけ」と気になったら、/btw このプロジェクトの認証方式を簡単に教えてで本流を汚さず確認する。

実装が終わったら自作のカスタムコマンド/reviewを実行してレビューしてもらい、修正を反映。

シェルで!pnpm testと!pnpm lintを確認して、!git diffで変更内容を見る。
問題なければカスタムコマンド/commitでコミットメッセージを生成してもらう。

途中でClaudeが妙な方向に走り出したら、迷わずEsc二回で/rewindして戻す。
文脈が膨らんできたら/compactで圧縮。
午後に全く別のタスクに移るタイミングで/clearを挟む。

一日の終わりに/insightsを眺めて、自分の作業の癖を一週間に一度くらいの頻度で観察する。

これが私が現時点で考えている、Claude Codeを一段上に押し上げるための作業フローです。

結局、コマンドは思想を運ぶ容器に過ぎない

ここまで具体的なコマンドや設定を並べてきましたが、振り返ってみると、これらは個別の便利機能というよりも、Claude Codeというツールが提示している「人とAIの協働のあり方」についての思想の現れだと感じます。

仕込みのコマンドは、AIに自分の意図を理解させるための前提作業を重視する思想。思考のコマンドは、走り出す前に立ち止まる古典的な設計手法の再導入。

実行のコマンドは、人間の集中力と思考の流れを途切れさせない設計。

修復のコマンドは、失敗を前提とした安全網の思想。振り返りのコマンドは、自己観察を通じた継続的な改善の思想。

これらが合わさって、ようやくClaude Codeは「賢いコード生成機」から「協働するパートナー」に近づいてくるわけです。

コマンドを覚えただけでは、その協働関係には到達できないのです。
それぞれのコマンドが、どういう前提の下で、どういう思想を運んでいるのかを理解した上で使う必要があります。

私自身、ここに書いたことを完璧に実践できているわけではありません。
仕込みが甘いままClaudeに走らせて事故ったり、/rewindの存在を忘れて手作業で復元しようとしたり、ultrathinkを忘れて浅い回答に妥協してしまったりしています。

まだまだ使いこなすには時間がかかりそうです。
ただ、便利コマンドのリストを暗記するよりも、自分が今どの層の作業をしているのかを意識する方が、結局は一段上に行くための近道なんだと思っています。

道具の進化に追いつくのではなく、道具が運んでいる思想に追いつく。
そういう向き合い方が、AI時代のリテラシーとして要求されているのかもしれません。

私たちはコードを書く者からコードを設計する者へ、さらにそこから「AIに何をどう考えさせるか」を設計する者へと、立ち位置を移しつつあります。

Claude Codeのコマンド一つひとつは、その移行を支えるための足場のようなものです。

この記事で便利だなと思ったら、そこからもう一歩踏み込んで、足場の組み方そのものを設計し始めるのが、次の段階なのだと思っています。