Claude Codeで開発が速くなった僕の実務Tips：段取り・CLAUDE.md・確認の省力化

導入したばかりの頃、僕はClaude Codeに向かって毎回こう打っていました。「このバグ直して」。

返ってくる修正は、半分は当たり、半分は的外れ。同じファイルを何度も読み直させ、「いや、そっちじゃなくて」と打ち直す。気づけば、自分で直したほうが速いんじゃないかという時間まで使っていました。

転機は、使い方じゃなくて段取りを変えたときでした。何を読ませ、どこまで任せ、どこで確認するか。これを先に決めるようにしたら、同じモデルなのに体感速度が変わったんです。今日はその、地味だけど効いたTipsをまとめます。魔法のプロンプトの話ではありません。毎日の往復回数を減らす話です。

この記事の要点

• 速さを決めるのは「賢い1発のプロンプト」ではなく、読ませる範囲・任せる範囲・確認の段取り。
• CLAUDE.md に毎回言っていることを書くと、同じ指示の打ち直しが消える。長く書くほど効くわけではない。
• 権限は「危ない操作だけ確認、安全な操作は素通し」に設計すると、確認ダイアログ疲れが減る。
• /clear と /compact の使い分け、画像・ログの貼り方など、つまずきを先回りで潰す小ワザが効く。

まず直したのは「丸投げ」をやめたこと

一番効いたのは、頼み方をひとつ変えただけでした。「直して」ではなく、「どこを・どうしたいか・どう確かめるか」を一行ずつ渡す。

新人にお願いするのと同じです。「いい感じにやっといて」では、相手は何が正解か分からない。Claude Codeも同じで、ゴールがぼやけていると、まず探索に時間を使い、見当違いの場所をいじり始めます。

僕がよく使う頼み方の型はこれです。

渡す要素	悪い例	良い例
対象	「ログイン直して」	「src/auth/login.ts のセッション期限切れ処理」
期待	「うまく動くように」	「期限切れ時に401を返し、再ログインへ誘導」
確認	（指定なし）	「npm test -- auth が通ることを確認してから報告」

右の列で渡すと、探索の往復が一気に減ります。特に最後の「確認方法を一緒に渡す」が効きます。テストや型チェックという機械の物差しを先に握らせると、Claude Codeが自分で直して、通ってから戻ってくるようになるからです。

よく使うワークフロー3つ

毎日のように回している段取りを、そのまま書きます。

1. 調べる→計画→実装の三段 いきなり書かせず、最初に「まず計画だけ立てて。実装はまだしないで」と区切ります。計画を読んで、ずれていたらそこで直す。設計が固まってから実装に進むと、できあがったコードの手戻りがほとんど消えます。Claude Codeには計画を見せてから実行に移すモード（プランレビュー）もあるので、大きめの変更はそれを使います。

2. 失敗ログを「最後の行」で渡さない エラーが出たとき、最後の一行だけ貼ると、Claude Codeも最後の一行だけ見て的外れな修正をします。スタックトレース全体と「再現手順」をセットで渡す。これだけで命中率が変わります。

3. 差分でレビューさせる 書かせたあと、/review で自分の変更をレビューさせます。「このdiffの抜け・危ない箇所を3つ挙げて」と頼むと、自分では見落とす境界条件を拾ってくれます。

CLAUDE.mdに「毎回言っていること」を移す

同じ注意を毎セッション打ち直していたら、それは CLAUDE.md に書くサインです。

CLAUDE.md はプロジェクトのルート（やホーム）に置くMarkdownで、Claude Codeが起動時に必ず読みます。コーディング規約、使うライブラリ、テストの回し方、レビューの観点——「うちの現場の前提」を一度書けば、毎回伝える手間が消えます。

最初に置く CLAUDE.md はこのくらいで十分です。

# プロジェクトの前提

## コマンド
- テスト: npm test
- 型チェック: npm run typecheck
- Lint: npm run lint

## ルール
- 変更後は必ず npm test と npm run typecheck を通してから報告する
- 既存のフォーマット（Prettier 設定）に従う。整形だけのdiffは混ぜない
- ライブラリ追加は事前に提案し、勝手に入れない

ここで僕がやらかしたのは、欲張って何でも書いたこと。500行の CLAUDE.md を作ったら、肝心の指示が埋もれて守られなくなりました。短く、よく破られるルールだけを書く。これが結局いちばん効きます。粒度・更新タイミング・「何を書かないか」の考え方は CLAUDE.mdは「何を書かないか」で決まる に詳しくまとめました。

もうひとつ。Claude Codeは作業しながらビルドコマンドやデバッグの気づきを自動で覚えていく仕組み（auto memory）も持っています。手で書くルールと、勝手にたまる学習。この二段で、セッションをまたいでも前提が引き継がれます。

権限の段取りで「確認疲れ」を消す

最初の頃、僕はファイルを書くたびに出る確認ダイアログに、ほぼ反射でYesを押していました。これは危ない。惰性でYesを押す癖がつくと、本当に止めたい操作まで素通ししてしまいます。

解き方は、確認の重みづけです。安全な操作は黙って通し、危ない操作（削除・本番への反映・課金・force push）だけ確認させる。Claude Codeは settings.json で allow（許可）・deny（禁止）・ask（毎回確認）を細かく決められます。

たとえばこんな設計です。

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run typecheck:*)",
      "Edit(src/**)"
    ],
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

テストと型チェックは素通し、src 配下の編集も素通し。git push は毎回確認、rm -rf と force push は最初から禁止。こうすると、Yesを押す回数が激減して、出てきたダイアログは「本当に考えるべきもの」だけになります。評価順やパターン構文（Bash・Edit・Read など）の早見表は Claude Code 権限設定リファレンス にまとめてあります。

確認を「人の目」から「コマンド」に移す

省力化でいちばん効いたのは、確認の主役を自分の目からコマンドに替えたことでした。

人間の目視チェックは、忙しい日に必ず抜けます。だから「機械で分かること」は機械に任せる。テストが通るか、型が合うか、Lintが綺麗か、ビルドが通るか。これらを CLAUDE.md の「報告前に通すこと」に書いておけば、Claude Codeが自分で回してから戻ってきます。

CLIをパイプでつなぐと、確認そのものを自動化できます。-p を付けると、対話せず一発で実行して結果だけ返すモードになります。

# 変更したファイルだけセキュリティ観点でレビューさせる
git diff main --name-only | claude -p "これらの変更ファイルを危険な箇所がないかレビューして"

# 直近のログに異常がないか見てもらう
tail -200 app.log | claude -p "気になる異常があれば3行で教えて"

この「人が見る前に門番で弾く」という発想は、エージェントに安全に仕事を任せる足場づくりそのものです。考え方の土台は ハーネスエンジニアリングとは？ で、最小のコード付きで解説しています。

つまずきを減らす小ワザ

細かいけれど、知っているかどうかで速度が変わるものを並べます。

• /clear と /compact を使い分ける。 話題が完全に変わったら /clear で履歴をまっさらに。長い作業を続けたいが文脈が重いときは /compact で要約して圧縮。だらだら続けると、関係ない過去の文脈に引きずられて精度が落ちます。
• 画像を貼って指示する。 UIの崩れやエラー画面は、言葉で説明するより画像を貼るほうが速い。「この赤枠の余白を詰めて」で通じます。
• 新規プロジェクトは /init から。 リポジトリの構造を読み取って CLAUDE.md の下書きを作ってくれます。ゼロから書くより速い。
• 繰り返す手順はスキル（カスタムコマンド）にする。 同じ指示を何度も貼っているなら、.claude/commands/deploy.md に書いて /deploy として呼べます。チームで共有もできます。
• 一度に欲張らない。 「これとこれとこれを全部」は、どれも中途半端になりがち。1タスクずつ区切ると、結局そのほうが速いです。

/clear を押すのを忘れて、前のタスクの設計を引きずったまま別の修正をさせ、見当違いの差分を量産した——これは僕の実話です。話題が変わったら履歴を切る。たったこれだけで、無駄な往復が消えます。

よくある質問

Q. プロンプトを工夫するのと、段取りを整えるの、どっちが効きますか？ A. 僕の体感では段取りです。同じ一行でも、CLAUDE.md で前提が揃い、確認がコマンド化されているだけで、打ち直しの回数が大きく減ります。

Q. CLAUDE.md は長く書くほど守ってくれますか？ A. 逆です。長いほど指示が埋もれて守られません。よく破られるルールだけを短く書くのが効きます。詳しくは CLAUDE.mdの記事 を参照してください。

Q. 権限を全部 allow にして速くするのはアリですか？ A. やめたほうがいいです。削除・本番反映・force push まで素通しになり、事故ったときに戻せません。危ない操作だけ deny か ask に分けるのが、速さと安全の両立点です。

Q. 履歴が長くなって遅い・的外れになるときは？ A. 話題が変わったら /clear、作業を続けたいが文脈が重いなら /compact で要約圧縮。これだけで精度が戻ることが多いです。

Q. 確認の手間を減らしつつ、品質は落としたくない場合は？ A. 確認を人の目からコマンドに移します。テスト・型・Lintを「報告前に通すこと」として CLAUDE.md に書けば、機械が先に弾いてくれます。

実際に試した結果

冒頭の「直して」を打っていた頃と比べて、いちばん変わったのは1タスクあたりの往復回数でした。以前は5〜6回打ち直していた修正が、今は1〜2回で終わります。

効いた順に並べると、(1) 確認方法を一緒に渡す、(2) CLAUDE.md に「報告前にテストと型を通す」と書く、(3) 危ない操作だけ権限を絞る、の3つでした。どれも賢いプロンプトとは関係ない、ただの段取りです。

逆に、設計のセンスが要る判断や、要件そのものの良し悪しは、相変わらず自分で大きく直しています。そこは人の仕事として残る。だから僕の結論はこうです。Claude Codeを速くするコツは、賢い一発を狙うことではなく、往復を減らす足場を先に組むこと。地味ですが、これがいちばん効きました。

まとめ

Claude Codeで開発を速くする近道は、魔法のプロンプトではありません。読ませる範囲・任せる範囲・確認の段取りを先に決めること。具体的には、頼み方に「対象・期待・確認」を入れる、毎回言うことを CLAUDE.md に移す、危ない操作だけ権限を絞る、確認をコマンドに肩代わりさせる、/clear で文脈を切る——この5つです。

公式の機能一覧は Claude Code 公式ドキュメント と CLAUDE.md / メモリの解説 が一次情報として正確です。まずは今日の1タスクで、「確認方法を一緒に渡す」だけ試してみてください。

チームで「うちの開発フローのどこをClaude Codeに任せられるか」を整理したくなったら、教材一覧 ものぞいてみてください。