PaPoo
cover

止めてほしい条件を先に書く:安全なブレーキのかけ方

Claude Code に雑に「やっといて」と投げると、速いぶんだけ派手に外す。特に危ないのは、何を止めればいいかを書かずに走らせるやり方だ。中断条件、失敗時の停止、ブレーキ条件を先に置く。これだけで、暴走した修正を途中で止めやすくなり、あとから手で戻す量がかなり減る。

この話は開発だけの話ではない。ファイル整理でも、文書作成でも、ディスク掃除でも同じだ。たとえば「重複ファイルっぽいものを探して」と頼んだとき、何を重複扱いにするか、どこまで削除していいか、どの条件で止めるかが曖昧だと、あとで痛い目を見る。Claude Code はこちらの意図を汲んでくれる場面もあるが、止めどころまで自動で空気を読む道具ではない。

だから最初に書くべきなのは、作業内容より先にブレーキだ。

たとえばこうだ。

この作業では、次の条件に当てはまったら必ず止まって確認してほしい。
- 変更対象に .git 配下、node_modules、vendor、バックアップ、キャッシュが含まれるとき
- 既存ファイルの削除や上書きが発生するとき
- 影響範囲が 10 ファイルを超えるとき
- 依存関係やビルド設定を直す必要が出たとき
- 判断に必要な情報が足りないとき

止めたら、何が問題か、どのファイルに影響するか、次に確認したいことを短く報告してから待ってください。

こう書くと、Claude Code は「進める前に確認すべき場面」を先に意識する。これが大事だ。人間は途中で気づくが、エージェントは作業を続けながら広げがちだ。特にファイル名が似ている整理、古い文書の置換、巨大な差分の作成は、止める条件がないと平気で余計な範囲に触る。

実務では、依頼文の頭にこの一文を置くだけでも効く。

まず停止条件を守ってから作業してほしい。
止めていい条件は次の通り。
- 既存データの削除
- もとの内容を失う上書き
- 変更理由が確定できない場合
- 想定と違うファイル種別に触れそうな場合

止めるときは、何が引っかかったかを1〜3行で説明して、次の指示を待ってください。

ここでのコツは、禁止事項を「やってはいけないこと」として書くだけで終わらせないことだ。Claude Code は、ただの禁止よりも「止めるべき条件」がはっきりしているほうが扱いやすい。たとえば「削除しない」だけだと、削除以外の危険、つまり上書き、移動、置換、まとめ直しに対する警戒が抜ける。ブレーキ条件は操作種別ではなく、事故の起点で書くほうが強い。

筆者は最初、ここを甘く見ていた。古い資料の整理を頼むときに「不要ファイルをまとめて」とだけ書いたら、似た名前のフォルダまで広く見に行って、差分が妙に大きくなった。結果として、こちらが意図していない場所まで確認が走り、手戻りが増えた。あれは生成結果の出来が悪いというより、止める合図を渡していなかったこちらの負けだ。

安全にするなら、ブレーキ条件は三層で考えるといい。

まず一つ目は、破壊的な操作で止めることだ。削除、上書き、移動、リネーム、置換のように元に戻しにくい操作は、実行前に止める。特に文書整理やディスク削減では、この条件がそのまま命綱になる。

二つ目は、影響範囲で止めることだ。ファイル数が増えすぎた、対象ディレクトリが広すぎる、変更差分が大きすぎる。こういうときは、一度止まって範囲確認をさせる。人間でも一気に全部は見ない。エージェントにだけ根性論を求めるのは無理がある。

三つ目は、判断不能で止めることだ。曖昧な命名、重複っぽいが中身が違う、古い書式かどうか断定できない。こういう場面で勝手に進ませると、便利どころか面倒が増える。迷ったら止める、を先に教えるのが安全だ。

実際の依頼は、こんなふうに書くと使いやすい。

以下の資料フォルダを整理してほしい。
ただし、次の条件のどれかに当てはまったら止まって確認してほしい。

停止条件:
- 削除、上書き、リネーム、移動が必要になる
- 重複判定に自信が持てない
- 10個以上のファイルに影響する
- 仕様書、契約書、請求書のような重要文書に触れる
- 拡張子が違うファイルが混ざっている

止めたら、候補を列挙して、どれを残すべきか確認してから続けてください。

ここで気をつけたいのは、「止めて」と書いたのに、止まった理由が伝わる形で報告させることだ。単に止まるだけだと、こちらは状況を把握できない。ブレーキはサイドブレーキではなく、状況報告つきの安全停止にしておくといい。

もう一つ、よくある失敗がある。ブレーキ条件を後ろに長々と書くことだ。これだと、最初の主作業の指示に引っ張られて、停止条件が埋もれる。先に書く、が効く理由はそこにある。Claude Code に最初に見せる文面で、何を止めるかが目に入る位置にあると、暴走しにくい。

簡単な型にするとこうなる。

停止条件
- 〜のときは止める
- 〜の場合は確認する
- 〜の範囲を超えたら中断する

作業内容
- 何をするか
- どのフォルダ、どの文書を対象にするか
- 完了したら何を返すか

この順番は地味だが効く。先にブレーキ、あとでアクセルだ。逆にすると、走り出してから慌てて手を上げることになる。

少し進めるなら、停止条件を「確認してほしい点」とセットにするのがいい。たとえば「古い書類を残すか捨てるか判断に迷ったら止まる」だけでなく、「ファイル名、更新日、内容の見出しを並べて確認を求める」とまで書く。そうすると、止まったあとに何を見ればいいかが揃う。再開も早い。

Claude Code は、指示が具体的だと強い。逆に言えば、止め方が曖昧だと、危ない場面でも続けてしまう。だから「この条件なら止めろ」を先に渡すのが、いちばん地味で、いちばん効く。派手なテクニックより、こちらの意図を先頭に置くほうが、結局は手戻りが少ない。そこを雑にしないだけで、作業の事故率はかなり下がる。

関連 TIPS

同じ著者の記事