第7章 スラッシュコマンドと Plan Mode の深掘り
ここまで、スラッシュコマンドにほとんど触れてきませんでした。実際、僕自身もスラッシュコマンドをほぼ使わずに3週間で複数のアプリを作っています。
でも、知っておくと圧倒的に楽になる場面もあるんです。第7章では、
- 最低限知っておくと便利な3つのスラッシュコマンド
- 必要になったら使う、その他のコマンド
- 第4章で先送りした「Plan モード」の深い使い方
- 良い Plan と悪い Plan の違い
- Plan を CLAUDE.md に資産化するテクニック
このあたりを扱います。繰り返しますが、知らなくても作業は進められます。困った時の引き出しとして持っておく、くらいの位置づけです。
7-1. スラッシュコマンドはゼロでも進める — でも知っておくと便利な3つ
【学習目標】
- スラッシュコマンドが何か理解する
- 最初に覚えておくと便利な3つを把握する
【前提知識】
- 第6章まで完了していること
【概念解説】
スラッシュコマンドとは、Code の入力欄で / を頭につけて打つ特殊な命令のことです。
/clear
/compact
/context
こんな形。普通の会話と違って、Code に直接的な指示を出すための「ショートカット」と思ってください。
なぜ最初は使わなくてもいいのか
僕がスラッシュコマンドをほぼ使わなかったように、普通の作業はスラッシュコマンドなしで完結します。
「フォルダの中身を見て」「テスト用ファイルを作って」「コードを書き換えて」みたいな普通の依頼は、全部自然な日本語でOK。Code が解釈してくれます。
スラッシュコマンドが活きるのは、「普通の会話では伝えにくい、Code の内部状態の操作」です。たとえば、「会話履歴をクリアして」「コンテキストを圧縮して」「現在のコンテキスト使用量を見せて」のような。
まず覚えるべき3つ
僕が「3週間でほぼ使わなかったとはいえ、知っていれば便利だったな」と振り返ったのが、この3つ。
1. /clear
- セッションの会話履歴を全部クリアする
- コンテキストウィンドウをリセットする
- 6-7 で「セッションを区切る」と言ったやつの、ライトバージョン
2. /compact
- 会話の内容を「要約」する
- 長い会話を圧縮して、コンテキストを節約
- セッションを保ったまま、整理だけしたい時に
3. /context
- 現在のコンテキスト使用量を表示
- 「もうそろそろ満杯？」を確認できる
この3つを覚えておけば、第6章で学んだ「コンテキスト肥大化」への対処の選択肢が増えます。
使い分けの目安
[会話が長くなってきた]
↓
/context で使用量を確認
↓
余裕がある → そのまま続ける
↓
そろそろ満杯 → /compact で圧縮
↓
もう限界 / 別のタスクに移る → /clear（または新セッション）
【ハンズオン手順】
▼ Code 側でやること（3つを試してみる）
- 何か簡単な会話を Code としてみる
/contextと入力して Enter- 現在のコンテキスト使用量が表示される
- 続けて何回か会話してから、
/compactを実行 - 会話の要約が作られる
- もう一度
/contextで使用量が減ったことを確認
▼ Code 側でやること（クリアの体験）
- 別の練習として、テスト用の会話を何回かしてから
/clearを実行 - 「クリアしますか？」のような確認が出ることもある
- 実行すると、それまでの会話が消える
- ただし CLAUDE.md と Auto Memory は引き継がれている
▼ スクショ伴走のチェックポイント
/contextで表示された使用量の画面/compact前後の使用量比較
【つまずきポイント】
/clearは元に戻せない。大事な会話は事前にメモするか、CHANGELOG / TODO に反映してから実行/compactは要約なので、細部の情報は失われる。重要な詳細はファイルに記録しておく- スラッシュコマンドの場所がバージョンによって違うこともある。最新はブラウザに「現在の Code の
/clearの使い方」と聞くのが手っ取り早い
【確認問題】
- 会話履歴を完全にクリアするコマンドは何ですか？
- 現在のコンテキスト使用量を確認するコマンドは何ですか？
【次のレッスンへの橋渡し】
最低限の3つが分かりました。次は、それ以外で「必要になったら使う」コマンド群を紹介します。
7-2. /init /resume /model — 必要になったときに使う
【学習目標】
- 主要なスラッシュコマンドの存在と用途を知る
- どんな場面でどれを使うかをイメージできる
【前提知識】
- 7-1 で基本3つを覚えていること
【概念解説】
7-1 で扱った /clear /compact /context 以外にも、覚えておくと便利なコマンドがいくつかあります。全部覚えなくていいです。「こんなのあったな」を頭に入れておけば、必要になった時に思い出せます。
/init
新しいプロジェクトを始める時、Code に「これからこのフォルダで作業します」と宣言するコマンド。
- フォルダ指定の確認
- CLAUDE.md の読み込み
- プロジェクトの初期化
5-2 で「フォルダ指定」をやりましたが、/init はそれをコマンドで一気にやる方法、と思ってください。
/resume
前回のセッションを再開するコマンド。
- 「あの作業の続きから」と言う時に便利
- セッション履歴から選んで再開
- サイドバーの Recents をクリックするのと同じ役割
/model
使う AI モデルを切り替えるコマンド。
- Claude には複数のモデルバージョンがある（Sonnet、Opus など）
- それぞれ得意分野や速度・精度のバランスが違う
- たとえば「速度優先なら Sonnet、精度優先なら Opus」みたいな使い分け
- 初心者は気にしなくてOK。デフォルトで十分
/logout
ログアウトするコマンド。
- 別アカウントに切り替えたい時
- 普通は使わない
/usage
利用量の確認。
- 「今月どれくらい使ったか」を確認
- プラン制限に近いかを把握できる
いつ使うか、の感覚
- 通常作業：スラッシュコマンドゼロでOK
- コンテキスト管理：
/clear/compact/context（7-1） - セッション管理：
/resume - セットアップ：
/init（必要に応じて） - アカウント：
/logout/usage（必要に応じて）
僕は「通常作業ゾーンだけで全部回ってる」と言っているので、本当に大半の人はスラッシュコマンドを意識しなくて大丈夫。
【ハンズオン手順】
▼ Code 側でやること（コマンド一覧を見る）
- 入力欄に
/だけ打つ - 使えるコマンドの一覧が表示される
- それぞれの説明を眺めてみる
- 「使いそうかも」と思ったものをメモ
▼ Code 側でやること（/usage を試す）
/usageを実行- 今月の使用量が表示される
- 自分が「今月どれくらい使ったか」を把握
▼ スクショ伴走のチェックポイント
- スラッシュコマンドの一覧画面のスクショ
/usageの表示のスクショ
【つまずきポイント】
- コマンドを覚えようとしない。「こんなのあったな」を残しておけば充分
- 困った時はまずブラウザに「○○したいんだけど、どのスラッシュコマンドを使う？」と聞く。最新版でのコマンド名が分かります
【確認問題】
- 前回のセッションを再開するコマンドは何ですか？
- 今月の利用量を確認するコマンドは何ですか？
【次のレッスンへの橋渡し】
スラッシュコマンドの全体像が見えました。ここからは Plan モードの深い使い方に入ります。
7-3. Plan Mode の深い使い方 — 良い Plan と悪い Plan
【学習目標】
- Plan モードで Code が出してくる「Plan」の良し悪しを判断できる
- 不十分な Plan に対して、改善要求を出せる
【前提知識】
- 4-6 で Plan モードの概要を知っていること
- 5-3 でモード切り替えを実践したこと
【概念解説】
Plan モードで Code が提示してくる「計画書」には、質の差があります。
良い Plan は、作業が始まってから「あ、思ってたのと違う」が起きにくい。逆に悪い Plan は、「OK」と言って実行に入ったら全然違うことが始まる、なんてことが起きます。
ここで、良い Plan の特徴と、不十分な Plan に対する対処法を見ていきます。
良い Plan の特徴
-
何のファイルをどう変えるかが明示されている
- 「index.html の○○セクションに△△を追加」のように具体的
- ファイル名と変更内容がセットになっている
-
新しく追加するライブラリ・ツールが明示されている
- 「npm install ○○ をします」「Supabase の○○テーブルを追加します」
- 後で「あれ、勝手にライブラリ入った」が起きない
-
手順がステップ番号で整理されている
- 1, 2, 3 と順番が見える
- 各ステップの依存関係（「2が終わってから3」）も書かれている
-
想定される副作用やリスクが書かれている
- 「これを変えると、○○の挙動が変わります」
- 「データベースのスキーマが変わるので、既存データは…」
-
完了条件が書かれている
- 「以下が動けば完成です」
- 自分が「成功した」と判断できる基準
悪い Plan の特徴
逆に、こんな Plan が出てきたら要注意。
-
抽象的すぎる
- 「ログイン機能を実装します」だけ
- どんな実装かが見えない
-
影響範囲が不明
- どのファイルを触るかが書かれていない
-
「お任せください」感が強い
- 「私が全部やります」だけで、何をやるかが見えない
悪い Plan に対する対処
不十分な Plan が出てきたら、こう返してください。
Plan の内容をもう少し具体化してほしいです。特に次の点を教えてください：
- どのファイルをどう変えるか
- 新しく追加するライブラリは何か
- 想定される副作用やリスク
- 完了条件
Code は「あ、もっと詳細が必要なんですね」と理解して、改良された Plan を出してくれます。
僕のチェックリスト
僕は Plan を見たら、頭の中で次のチェックを通しています。
✓ どのファイルが変わるか、書いてあるか？
✓ 新しいライブラリやサービスは追加されるか？
✓ 想定外のことが書かれていないか？
✓ 自分が「OK」と言えるレベルまで具体的か？
このチェックが全部 ✓ になるまで、Plan の見直しを依頼することがあります。
【ハンズオン手順】
▼ Code 側でやること（良い Plan を体験する）
- Plan モードで、ある程度複雑な依頼を出す（例：「カフェ紹介ページに、お客様の声を表示するセクションを追加して」）
- Code が Plan を提示
- 上記のチェックリストで Plan を確認
▼ Code 側でやること（悪い Plan を改善する）
- もし Plan が抽象的すぎる場合、次のように依頼
Plan をもう少し具体化してください。
- どのファイルをどう変えるか
- 新しいライブラリは追加されるか
- 完了条件は何か
を明示してください。
- Code が改善版を出す
- 改善版を確認してから「OK」
▼ スクショ伴走のチェックポイント
- Plan の初版のスクショ
- 改善後の Plan のスクショ
- 違いを目で確認
【つまずきポイント】
- 「Plan を細かく見るのは面倒」と感じるかもしれませんが、見るのと見ないのとで成果が大きく変わります
- Plan を見ずに OK を返さない。Plan モードの意味がなくなります
- 改善依頼は何度でもしていい。Code は嫌な顔せず付き合ってくれます
【確認問題】
- 良い Plan の特徴を3つ挙げてください
- 抽象的すぎる Plan が出てきた時、どう対処しますか？
【次のレッスンへの橋渡し】
良い Plan が分かりました。次は、その Plan を「使い捨て」にせずに、プロジェクトの資産にする方法です。
7-4. Plan を CLAUDE.md に織り込んで資産化する
【学習目標】
- 良い Plan を、プロジェクトの永続的な資産として残せる
- 過去の Plan が次の Plan の質を上げる流れを作れる
【前提知識】
- 7-3 で良い Plan の特徴を理解していること
- 6-3 で CLAUDE.md の書き方を知っていること
【概念解説】
Plan モードで作った「良い Plan」を、その場限りで使い捨てにするのはもったいないんですよ。
僕が体得したノウハウとして、**「いい Plan が出てきた時の典型パターンを CLAUDE.md に書き残す」**というやり方があります。
具体例：認証機能の Plan を資産化する
たとえば「ログイン機能の追加」を Plan モードで進めたとします。Code が次のような良い Plan を出してくれました。
## ログイン機能追加 Plan
### 1. Supabase Auth のセットアップ
- Supabase ダッシュボードで Authentication を有効化
- メール+パスワード認証を ON
- メール確認をオフ（開発時のみ）
### 2. アプリ側の実装
- auth.js を新規作成（ログイン・ログアウト・登録の関数）
- index.html にログインフォームを追加
- app.js でログイン状態を監視
### 3. アクセス制御
- ログイン状態に応じて、各機能の表示を切り替え
- 未ログイン時はトップページのみ表示
これ、すごく綺麗な Plan ですよね。じゃあ次に別のプロジェクトでログイン機能を追加する時、また同じレベルの Plan を期待できるか？
期待できないこともあるんです。なぜなら、Code は毎回新しいセッションで考え直すから。だから、この Plan を CLAUDE.md に「テンプレート」として残しておくんです。
CLAUDE.md への書き方
# 過去に成功した Plan のテンプレート
## ログイン機能を追加する時のテンプレート
1. Supabase Auth のセットアップ
- メール+パスワード認証
- 必要に応じてメール確認
2. アプリ側の実装
- auth.js を作成
- HTML にフォーム追加
- 状態監視
3. アクセス制御
- ログイン状態に応じた表示切り替え
このように CLAUDE.md に書いておくと、
- 次のセッションで「ログイン機能追加して」と言った時、Code がこのテンプレートを参考にする
- 別のプロジェクトでも、CLAUDE.md ごとコピペできる
- 自分自身が「以前どうやったか」を思い出せる
過去 Plan の自動振り返り
僕は、プロジェクトの節目で Code にこう依頼しています。
これまで Plan モードで進めた作業のうち、特に上手くいった
パターンを CLAUDE.md にテンプレートとして書き足してください。
すると Code が、過去のセッションを振り返って「これは再利用価値ありそう」と判断したパターンを抽出してくれる。これで CLAUDE.md がどんどん「自分のプロジェクト専用ガイド」として育っていきます。
【ハンズオン手順】
▼ Code 側でやること（過去 Plan の資産化）
- 過去に Plan モードで進めた作業を1つ思い出す（例：第1章でカフェ紹介ページを作った時）
- Code に次のように依頼
以前の作業を振り返って、「○○を作る時のテンプレート」として
CLAUDE.md に書き残してください。次に同じような作業をする時の
参考になるように。
- Code が CLAUDE.md に追記
- 内容を確認
▼ Code 側でやること（新セッションで効果を確認）
- 新しいセッションを開く
- 「○○を作りたい」と依頼
- Code が CLAUDE.md のテンプレートを参考に、より良い Plan を出してくる
▼ スクショ伴走のチェックポイント
- CLAUDE.md にテンプレートが追加された画面
- 新セッションでテンプレートを参考にした Plan が出てきた様子
【つまずきポイント】
- テンプレートを増やしすぎない。10個も20個も入れると CLAUDE.md が肥大化します。よく使うパターンに絞る
- テンプレートは「縛り」ではなく「ガイド」。プロジェクトごとに調整が必要なのは普通
【確認問題】
- 良い Plan を CLAUDE.md に書き残すメリットは何ですか？
- テンプレートを入れすぎるとどうなりますか？
【次のレッスンへの橋渡し】
良い Plan を資産として積み上げる習慣ができました。次のレッスンでは、スラッシュコマンドをもう一歩深掘りします。実は Code には「自分専用のコマンドを作る」機能があって、それが日々の作業を驚くほど楽にしてくれるんですよ。
7-5. 自分専用のスキルを作る（Customize タブ）
【学習目標】
- Code の「スキル」機能が何かを理解する
- Customize タブで自分だけのスラッシュコマンドを1つ作れる
【前提知識】
- 7-1 でスラッシュコマンドの基本を知っていること
- Code の Customize タブの存在を知っていること
【概念解説】
Code の画面左サイドバーには「Customize」というタブがあります。ここで作れるもののひとつが「スキル（Skills）」です。
スキルは、自分がよく使う指示をコマンドとして登録しておく機能です。登録すると / に続けてスキル名を入力するだけで、その指示を毎回入力しなくて済むようになります。
たとえばこんな使い方ができます。
/review→ 「このコードを読んで、改善できそうな点を3つ挙げてください」を実行/changelog→ 「今日の変更内容を CHANGELOG.md の形式でまとめてください」を実行/deploy-check→ 「デプロイ前の確認リストを出してください」を実行
繰り返しやっている作業が「スラッシュ1回」で済むようになる、という感覚です。
スキルの仕組み
スキルは「名前」と「プロンプト（指示文）」の2つで構成されます。
名前：review
プロンプト：このコードを読んで、改善できそうな点を3つ具体的に挙げてください。それぞれについて、なぜ改善が必要かも説明してください。
これを登録すると、次のセッションから /review と入力するだけで、上のプロンプトが送信されます。
第9章との繋がり
スキルは「自分でプロンプトを登録する」シンプルな仕組みですが、第9章で登場する MCP（Model Context Protocol）を使うと、さらに踏み込んで「外部のツールやデータを Code に接続するコマンド」を追加することもできます。今は「スキル＝自分が書いたプロンプトのショートカット」と覚えておけば十分です。
【ハンズオン手順】
▼ Code 側でやること（スキルを作る）
- 左サイドバーの「Customize」をクリック
- 「Skills」のセクションを探す
- 「+ Add skill」（または「＋」ボタン）をクリック
- 「Name」に
changelogと入力 - 「Prompt」に以下を入力
今日の作業で変更したファイルと内容を確認して、CHANGELOG.md に追記すべき内容を提案してください。フォーマットは既存の CHANGELOG.md に合わせてください。
- 保存する
▼ Code 側でやること（スキルを呼び出す）
- 新しいセッションを開く（またはチャット欄にフォーカス）
/を入力する- 登録したスキル名が候補に出てくることを確認
changelogを選んで Enter- 登録したプロンプトが実行されることを確認
▼ スクショ伴走のチェックポイント
- Customize タブの Skills 一覧に追加したスキルが表示されている画面
/を入力したときにスキルが候補に出てきた画面
【つまずきポイント】
- 「Customize タブが見つからない」場合、左サイドバーの下の方にあります。スクロールするか、画面サイズを確認してください
- スキル名はシンプルに。スペースや日本語が使えるかはバージョンによって異なるので、最初は英数字のみで試すのが安心
- スキルは「呼び出すたびに毎回同じプロンプトを送る」だけ。魔法のように何でもやってくれるわけではなく、あくまで入力の省略です。プロンプト自体がしっかりしていないと、出力も大雑把になります
【確認問題】
- スキルを使う利点を一言で言うと何ですか？
- スキルを呼び出すには何を入力しますか？
【次のレッスンへの橋渡し】
第7章はこれで完了です。次は第8章で、ここまで「いずれちゃんと学ぶ」と言ってきた Git と GitHub の世界に踏み込みます。スキルで作業を省力化する感覚が身についたところで、バージョン管理という「セーフティネット」を手に入れましょう。