Claude Codeのコマンドを覚えたのに手が止まる人へ、最初の一手を安全に出す型

金曜の夜、僕は後輩のSlackに「Claude Code、コマンド全部覚えたんですけど、次に何を打てばいいか分からなくて固まってます」というメッセージをもらいました。彼は /init も /clear も claude -p も言える。なのに、自分のリポジトリを前にすると指が止まる。

これ、能力の問題じゃないんですよね。コマンド表は「道具の名前」のリストでしかなくて、「最初に何を、どこまで、どう確かめて任せるか」までは書いてない。だから覚えれば覚えるほど、逆に動けなくなる人がいます。

この記事は、その「覚えたのに手が止まる」を抜けるための、いちばん小さい一手の出し方の話です。

この記事の要点

• コマンドを覚えても止まるのは、許可する範囲・触らせないファイル・戻し方・確かめ方の4つが決まっていないから。
• 最初の成果は「一段落だけ直す」「失敗テストの意味だけ説明させる」くらい小さくていい。
• 任せる前に、編集ではなく「計画だけ返して」と頼むと事故が激減する。
• 確かめ方は人の目より、git diff のような機械で分かるコマンドを先に決めておく。
• 慣れてきたら、安全だと分かった操作だけ少しずつ自動に格上げする。

なぜ表を覚えても固まるのか

コマンド一覧は地図でいえば「道路標識の一覧」です。標識の名前を全部言えても、行き先と曲がる場所が決まってなければ、車は発進しません。

止まる人に足りないのは知識ではなく、この4つを言葉にする習慣です。

• どのファイルを読ませて、どこは触らせないか
• 最初の変更を、どれだけ小さく切るか
• うまくいったと言える条件は何か（何を見れば成功か）
• 失敗したとき、どう元に戻すか

僕も最初は「このプロジェクト、いい感じにして」と丸投げして、30ファイル書き換わった差分を前に固まりました。読めない差分は確認できない。確認できない変更は、怖くて採用できない。だから最初は、笑えるくらい小さく始めるのが正解です。

最初の一手は、これくらい小さくていい

「成果」と聞くと大きな機能追加を想像しがちですが、最初はこのレベルで十分です。

• READMEの導入文を、3行だけ読みやすく直す
• 記事下の案内文を、一文だけ足す
• 落ちているテストの意味を「直さずに」説明させる

3つ目がとくにおすすめです。コードを1行も変えないので、壊れようがない。なのに「Claude Codeに自分のリポジトリを読ませて、答えが返ってきた」という最初の感触がちゃんと得られます。固まっている人は、まずここから指を動かすといいです。

任せる範囲と、人が決める範囲

Claude Codeに任せる仕事と、人が握っておく判断は、最初からはっきり分けておきます。曖昧なまま走らせると、たいてい人が判断すべきところまで勝手に進みます。

場面	Claude Codeに任せる	人が決める
範囲決め	候補のファイルを探して提案	触ってよい範囲の最終決定
編集	文章・コードの下書き	採用するかどうか
確認	テスト実行・差分の要約	公開してよいかの判断
危険操作	やり方の提案まで	削除・本番反映・課金の実行

ポイントは右の列です。削除、本番への反映、お金が動く操作、git push --force のような戻しにくい操作は、最初は全部「人が押す」に固定します。安全だと自分で確認できたものだけ、あとから左に移していく。この順番を守るだけで、夜中に冷や汗をかく回数がぐっと減ります。

まず「計画だけ」返してもらう

いきなり編集させないのがコツです。最初の依頼では、手を動かさせず、計画だけ言わせます。下のプロンプトをそのまま貼って使えます。

これから1つだけ小さな変更をお願いします。まだ編集はしないでください。
最初に、次の4点を箇条書きで返してください。

1. 触るファイル（1つだけ）
2. 触らないファイル（.env や認証・課金まわりは絶対に触らない）
3. 変更内容（ふるまいは変えず、文章だけ直す）
4. 変更後に私が確認するコマンド（git diff など）

この4点に私がOKを出してから、編集を始めてください。

返ってきた4点を見て、触るファイルが1つに絞れていて、確認コマンドまで書いてあれば、依頼の粒度は合っています。逆に「リポジトリ全体を見直します」みたいな返事なら、まだ頼み方が広すぎる合図です。範囲を狭めて、もう一度同じ形で頼み直します。

依頼文をうまく書けないと感じたら、Claude Codeのプロンプト設計 と CLAUDE.mdの書き方 が土台になります。プロジェクトのルールを先に渡しておくと、計画の質が一段上がります。

コピペで動く、最初の一手チェックリスト

頭の中の4点を、毎回ファイルに書き出すのは面倒です。そこで、答えるだけで「最初の一手メモ」ができる小さなスクリプトを置いておきます。Node.jsがあれば動きます。

// first-win.mjs — 最初の一手を1分で言語化するメモ生成
// 使い方: node first-win.mjs

const plan = {
  目標: "Claude Codeで小さな変更を1つ、安全に通す",
  触るファイル: ["README.md"],          // 1つに絞る
  触らないファイル: [".env", "認証", "課金", "本番DB"],
  最初のコマンド: "git status --short", // 今の状態を確認
  変更内容: "導入文を3行だけ読みやすく。ふるまいは変えない",
  確認方法: "git diff -- README.md",     // 差分が読める範囲か
  戻し方: "git checkout -- README.md",   // ダメなら即やり直し
};

// チェック: 触るファイルが1つに絞れているか
if (plan.触るファイル.length !== 1) {
  console.error("⚠ 触るファイルは最初は1つに絞ってください");
  process.exit(1);
}

console.log("=== 最初の一手メモ ===");
for (const [key, value] of Object.entries(plan)) {
  const text = Array.isArray(value) ? value.join(", ") : value;
  console.log(`${key}: ${text}`);
}
console.log("\nこのメモをClaude Codeに貼って『編集前に計画を返して』と頼む");

実行はこれだけです。

node first-win.mjs

出てきたメモをそのままClaude Codeに貼り、上の「計画だけ返して」プロンプトと合わせて使います。触るファイルが2つ以上になると最初の行で止まる作りにしてあるので、つい欲張ったときの歯止めにもなります。

実際に効いた使いどころ3つ

僕や周りが「最初の一手」に選んで、ちゃんと前に進んだ例を3つ挙げます。

1. READMEの導入文を直す。 コマンドを調べに来た読者向けに、最初の3行だけ平易にする。確認は git diff だけで済むので、差分が読める実感を最短で得られます。ここで自信がつきます。

2. 記事下の案内文を一文足す。 説明が薄い箇所に一文だけ追加し、リンク先が生きているか公開URLで開いて確かめる。文章だけの変更なので、コードを壊す心配がありません。

3. 落ちているテストの意味を説明させる。 ここでは直させません。「エラーの意味」「関係しそうなファイル」「次に人が見る場所」の3つだけ返してもらう。コードを1行も触らずに、原因の見当をつける練習になります。

3つに共通するのは、確認が1コマンドで終わることと、失敗しても1秒で戻せることです。非エンジニアの方は 非エンジニア向けのClaude Code活用 も合わせて読むと、文章まわりの一手を選びやすくなります。

よくある落とし穴と、その直し方

落とし穴1: 表を見た直後に「このリポジトリを良くして」と頼む。 範囲が広すぎて、返ってくる差分が読めなくなります。直し方は単純で、「1ファイル・1段落」まで絞ること。狭めるほど、最初の成果は確実になります。

落とし穴2: 確認方法を後回しにする。 何を見れば成功かを決めずに走らせると、それっぽい結果が出ても採用してよいか分かりません。依頼文に最初から git diff などの確認コマンドを書いておきます。

落とし穴3: いきなり危険操作を任せる。 ファイル削除や本番反映を最初から自動にすると、戻せない事故につながります。最初は全部「人が押す」に固定し、安全だと確認できたものだけ自動に格上げします。

よくある質問

Q. コマンドはどれくらい覚えてから始めればいいですか。 A. 3つで十分です。/init、/clear、それと変更を確認する git diff。残りは使う場面が来たときに調べれば間に合います。覚える前に小さく動かすほうが、結局早く身につきます。

Q. 最初の一手にいちばん向いている作業は何ですか。 A. 落ちているテストの意味を「説明だけ」させる作業です。コードを変えないので壊れようがなく、リポジトリを読ませる感触だけ得られます。基本の流れは 入門ガイド にもまとめています。

Q. 計画を頼んだのに、すぐ編集を始めてしまいます。 A. プロンプトの先頭に「まだ編集はしないでください」を置き、最後に「私のOKを待ってください」と添えます。それでも進む場合は、変更範囲が曖昧なことが多いので、触るファイルを名指しで1つに限定します。

Q. 確認は人の目で見れば十分では。 A. 忙しい日に必ず破綻します。文字数、差分、テストの合否のように機械で分かる確認を先に決めておくと、見落としが減ります。人の判断は「採用するかどうか」に集中させるのがコツです。

Q. 慣れてきたら次は何をすればいいですか。 A. 同じ「最初の一手メモ」を、少し大きい作業に広げます。確認コマンドが増えても、危険操作を人が握る原則は変えない。作業を速くする工夫は 生産性を上げるコツ が参考になります。

実際に試した結果

冒頭の後輩には、まず「落ちているテストの意味だけ説明させる」一手をやってもらいました。コードは触らない。返ってきたのは、原因のファイル名と、次に見るべき関数の場所。彼は「これならできる」と言って、その日のうちにREADMEの3行直しまで進めました。

僕自身も、丸投げをやめて「計画だけ返して」を挟むようにしてから、読めない差分を前に固まる時間がほぼ消えました。git diff で確認できる範囲しか頼まない、危険操作は人が押す。この2つを守るだけで、最初の一手は驚くほど軽く出せます。コマンドを全部覚える必要はありません。小さく動かして、戻せる範囲を確かめる。そこから始めれば十分です。

学習を一段進めたい人は 教材一覧 を、会社の業務にどう入れるか相談したい人は 研修・相談 を見てください。詳しいコマンドの挙動は公式ドキュメントが一次情報として確実です。