Claude Code に雑に「これ直して」と投げると、だいたい途中で迷う。迷っている間にコンテキストを食い、変更が広がり、最後は「で、どこで終わればいいんだ」という顔になる。そこで先にやるべきなのが、終了条件を明示すること、つまり出口を決めることだ。
これは大げさな話ではない。Claude Code は手を動かすのが速いぶん、終わり方が曖昧だと仕事がどんどん膨らむ。ファイル整理でも同じで、「不要ファイルを消して」とだけ言うと、似た名前のログやキャッシュまで気にし始めて、確認事項ばかり増える。文書作成でも、「整えて」と丸投げすると、構成をいじるのか、表現だけ直すのか、段落を増減するのかがぶれる。
先に止まりどころを言っておくと、作業はかなり安定する。Claude Code に期待するのは、万能な判断ではなく、決めた出口までの到達だ。そこを外すと、出力は増えるのに満足度は下がる。
たとえば、こんな頼み方にする。
この作業は、次の終了条件を満たしたら止めてください。
- 対象は docs/ 配下だけ
- 変更は文章の修正のみ
- 見出し構成は変えない
- 事実関係の不明点は推測で埋めず、該当箇所をコメントで残す
- 1 回の実行で終わる範囲に限定する
- 終わったら、変更したファイル一覧と、未解決の論点だけを短く報告する
この書き方の肝は、作業内容より先に「どこで止まるか」を置いている点だ。Claude Code は途中で確認材料が増えるほど、止まり方も増える。だから、完了の定義を先に渡す。そうすると、モデルは「ここまでやれば終わり」と判断しやすくなる。
もう少し実務寄りにすると、こうも書ける。
次の条件を満たした時点で作業を止めてください。
- README.md の説明文だけを整える
- コマンド例はそのまま残す
- 新しい機能説明は追加しない
- 文章の重複だけを削る
- 変更後は差分を確認し、内容に自信がない箇所があればそこで止める
ここでわざわざ「自信がない箇所があれば止める」と書くのが効く。雑に進めるより、立ち止まる条件を渡したほうが事故が減る。特に Claude Code は一気に編集できるから、曖昧なままだと「直した気になって広げた」差分が出やすい。筆者は最初、この手の作業で「必要ならついでに見やすくして」と書いて痛い目を見た。見やすさの名目で段落構成まで触られて、意図していない差分の説明に時間を取られた。出口がない指示は、あとで説明コストを食う。
ファイル整理やディスク削減でも、終了条件はかなり効く。たとえば、重複画像や古いキャッシュを片付けたいなら、「容量を空ける」だけでは弱い。削除の対象、残す基準、確認の止まりどころを先に決める。
次のルールで整理してください。
- 対象は Downloads/ のみ
- 30 日以上前の一時ファイル候補を洗い出す
- 実際の削除はまだしない
- サイズが大きい順に一覧化する
- 不明な拡張子は勝手に消さない
- 一覧を出したら止める
この依頼だと、Claude Code は「消す」より「選別して止まる」ほうに寄せられる。先に出口を決めると、確認のしすぎで手が止まることもなくなる。逆に出口がないと、対象範囲を広げてしまいがちだ。Downloads だけで済む話なのに、デスクトップまで見始める。そういう広がり方は、だいたい後でだるい。
文書作成なら、終了条件はさらに露骨に効く。たとえば契約書のたたき台、社内手順書、議事録の整形では、「完成」の定義が人によって違う。だから、Claude Code には「何をもって完了にするか」をはっきり渡す。
この原稿は、次の状態になったら作業を終了してください。
- 誤字脱字の修正はする
- 主張の追加はしない
- 構成は変えない
- 3 箇所以上の書き換えが必要なら、修正案を出して止まる
- 直した箇所は箇条書きで報告する
この「3 箇所以上なら止まる」が地味に大事だ。全面改稿に流れそうなときにブレーキになる。Claude Code は、ちょっとした修正からでも全体最適の誘惑に引っ張られることがある。悪い癖ではないが、用途によっては邪魔だ。こちらが「そこまでやらなくていい」と先に決めるべきだ。
注意したいのは、終了条件を「やってほしいこと」で埋め尽くしすぎないことだ。出口を決めるつもりが、ただの長い指示書になると、今度はどこが終わりなのか見えなくなる。条件は少なく、判断できる言葉にするほうがいい。
悪い例はこうだ。
できるだけいい感じに、読みやすく、漏れなく、きれいに、必要に応じて整理して、適切なところで止めてください
これは何も決めていないのと同じだ。人間でも困る。Claude Code ならなおさらだ。出口を決めるなら、対象、変更範囲、禁止事項、止める条件、この4つくらいに絞ると扱いやすい。
終了条件:
- 変更対象が 1 ファイルに収まる
- 意味が変わる編集をしていない
- 追加確認が必要な箇所を 1 つでも見つけたら止まる
このくらいで十分だ。細かい制約を足すより、止まる線を明確にしたほうが強い。
もう一つ、見落とされやすいのが「完了報告も出口に含める」ことだ。作業だけ終わって、何をやったか分からないと、結局こちらが確認で詰まる。Claude Code には、止まるだけでなく、止まった理由を短く返させるといい。
作業を終えるときは、次の順で報告してください。
1. 変更したファイル
2. 何を変えたか
3. まだ確認が必要な点
4. ここで止めた理由
この報告形式まで決めておくと、終了条件がただの精神論で終わらない。作業の終わりが見えるので、こちらも次の判断に移りやすい。
要するに、Claude Code には「何をするか」だけでなく「どこで止まるか」を先に渡すべきだ。終了条件を明示する、出口を決める。たったそれだけで、作業は膨らみにくくなるし、確認も短くなる。曖昧な依頼で広がった差分をあとで眺めるより、最初に終わり方を縛ったほうがずっと楽だ。
もし次に迷うなら、指示文の最後に「ここまでやったら止めてください」を一文だけ足してみるといい。たいてい、それだけで挙動が変わる。