勢いで全部やらせると、たいてい後で面倒になる。Claude Code でも同じだ。
修正、整理、削除、要約。どれも便利だが、いきなり最後まで走らせると、思っていたものと違う場所まで触られることがある。だからこそ、承認ゲート、段階的確認、次工程への進行条件を置く。要するに「ここまでは進めていい、ここから先は止まれ」を先に決めるやり方だ。
この手の制御は、開発作業だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも効く。Claude Code に「まず候補を出せ」「差分を見せろ」「削除前に止まれ」と言わせるだけで、手戻りがかなり減る。筆者は最初、全部まとめて任せて、あとから「そこは残したかった」と何度かやり直した。あの手戻りは地味にだるい。ゲートを置くと、その無駄が消える。
まず押さえるべきなのは、Claude Code に「最終実行」ではなく「確認用の下ごしらえ」をやらせることだ。たとえば不要ファイルの整理なら、いきなり削除させず、候補一覧を出させる。文書作成なら、いきなり全文を書かせず、章立てと論点を先に確認する。コード変更なら、いきなり大改修ではなく、影響範囲と変更方針を出させる。ここで止めるのがゲートだ。
実際の依頼は、こういう形にすると使いやすい。
この作業は段階的に進めてください。
1. まず対象を調べて、候補を一覧で出す
2. 次に、実行前に確認すべき点を3つ挙げる
3. 私が「進めて」と言うまで、削除や変更はしない
4. 最後に、実行する前の手順だけ示す
これだけでもかなり違う。Claude Code は「何をやるか」は得意だが、「どこで止まるか」は指示しないと流れで進む。流れ任せにしないのがコツだ。
ファイル整理で使うなら、もう少し具体的に切るといい。たとえば写真やダウンロードフォルダの掃除なら、候補の抽出と削除を分ける。
Downloads フォルダを整理したいです。
削除候補と保管候補を分けて一覧化してください。
次の条件で止めてください。
- 同名ファイルの扱いは確認する
- 30日以上前のファイルでも、拡張子が pdf / docx / xlsx のものは保留にする
- 削除実行は私の承認後だけにする
まずは判断材料だけ出してください。
この頼み方のいいところは、Claude Code が勝手に「いらないだろう」と決める余地を減らせることだ。整理系の作業は、本人よりもAIのほうが大胆に見切る。そこが便利でもあり、危ないところでもある。自分にとって重要なファイルは、たいてい機械が「ただの古い書類」に見える。ゲートがないと、そこで事故る。
文書作成でも同じだ。いきなり完成稿を出させるより、構成→本文→推敲の順で止めたほうが質が上がる。特に長文は、途中で「この筋で本当にいいのか」を挟まないと、あとから全面修正になりやすい。
以下の順で進めてください。
1. まず章立てを3案出す
2. 私が1案を選ぶまで本文は書かない
3. 選ばれた章立てに基づいて、各章の要点だけ先に出す
4. 私が確認したら本文に展開する
5. 文章を増やす前に、事実関係と用語の確認ポイントを示す
こうしておくと、途中で方向を変えやすい。しかも、Claude Code に無駄な本文を大量に吐かせないので、コンテキストの浪費も抑えやすい。長い指示を一気に投げて全部やらせると、出力は増えるが、確認したいポイントが埋もれる。確認点を先に出すほうが、実務ではずっと扱いやすい。
開発用途なら、ゲートはもっと効く。たとえばリファクタリングや削除を含む変更では、まず計画だけ出させ、差分は小分けにする。ここで大事なのは「全部直してから見せて」ではなく「小さく見せて、承認を挟んで進める」ことだ。
この変更は次のゲートで進めてください。
- 先に変更計画を要約する
- 影響するファイルを列挙する
- 実際の編集は、私が計画を確認してから始める
- 編集後は、差分の要点を説明してから次へ進む
筆者は一度、修正をまとめて走らせたあと、意図しない箇所まで整形されていて顔が固まったことがある。小さな見た目の変更ならまだいいが、削除や置換が混じると話が違う。ゲートを置いていれば、その手前で止められる。結果、差分も読みやすいし、レビューも楽だ。これはかなり大きい。
ここで注意したいのは、ゲートを細かくしすぎると、逆に作業が止まりすぎる点だ。何でもかんでも「確認してください」と言うと、ただの足止めになる。止めるべきなのは、取り返しがつきにくいところだけでいい。削除、上書き、移動、名称変更、公開文の確定。このあたりは止める価値が高い。逆に、候補出しや下書きの段階まで毎回止めると、テンポが悪くなる。
使い方としては、次のように線を引くのが現実的だ。
以下の操作だけは必ず止めてください。
- ファイル削除
- 既存ファイルの上書き
- 一括置換
- 外部送信が発生する操作
それ以外は、まず案を出して進めて構いません。
この一文があるだけで、Claude Code の動きがかなり安定する。何を止めるかを明示するのが大事で、「全部確認して」だけでは曖昧だ。曖昧な指示は、結局こちらの確認回数を増やす。だったら最初から、止めたい地点をはっきり書いておくほうがいい。
もうひとつ大事なのは、ゲートの粒度を作業の性質に合わせることだ。整理作業は「一覧→保留→実行」で十分なことが多い。文書作成は「構成→要点→本文→最終確認」が向いている。コード変更は「計画→差分→テスト→適用」の順が扱いやすい。どれも同じに見えて、止める場所は違う。ここを雑にすると、確認の価値が薄れる。
非エンジニアなら、こう考えるとわかりやすい。Claude Code は頼れる事務員に近いが、勝手に捨てられると困る書類まで処理しがちだ。だから「処分前に机の上に並べて」「封を切る前に見せて」と頼む。これが承認ゲートだ。作業を遅くする仕組みではない。むしろ、やり直しを減らして速くするための仕組みだ。
最後に、迷ったときの基本形を置いておく。これを土台にして、あなたの作業に合わせて止める箇所だけ変えればいい。
この依頼は段階的確認つきで進めてください。
- まず現状把握と候補出し
- 次に実行前の確認ポイント整理
- 私の承認があるまで変更はしない
- 承認後も、小さな単位で進めて途中報告する
Claude Code を雑に走らせると、速いようで遅い。手戻りが増えるからだ。逆に、ゲートを置くと、一見ゆっくりでも全体は締まる。確認してから次へ進める。この一手間が、いちばん効く。