「やってほしいこと」だけ書いて、やってほしくないことを放置する。これ、Claude Code への依頼でかなり危ない。余計な編集、勝手な要約、触ってほしくないファイルの改変まで一気に起きる。禁止事項は、気を使ってぼかすより、先に切っておいたほうが早い。
Claude Code は、雑に言えば「範囲が広いほど働きすぎる」タイプだ。だからこそ、禁止事項の伝え方が効く。
たとえばファイル整理なら、「古いものを片付けて」と言うだけでは、思い切りよく削除されて困ることがある。文書作成なら、「読みやすくして」と頼んだだけで、表現をいじられすぎて意図がずれる。開発なら、関連しない設定ファイルまで手を入れて差分が肥大化する。筆者も最初はこの手の依頼で何度か戻した。うまくいくときより、余計なことをして手戻りが出るときのほうが面倒だ。
コツは単純で、「何をしてほしいか」と同じ熱量で「何をしてほしくないか」を書くことだ。しかも、あいまいにではなく、対象を切って書く。
たとえば、こう書く。
このフォルダ内の文書を整理してほしい。
ただし、次は触らないでほしい。
- 元の本文の意味を変える書き換え
- すでにある見出しの追加削除
- PDF や画像ファイルの中身の変更
- 削除の提案だけで終わること
やってほしいのは、重複しそうなファイル名の整理案と、不要そうな下書きの候補を挙げることだけ。
この書き方の強みは、禁止事項が「雰囲気」ではなく「操作」で書かれている点にある。
「丁寧に」「勝手に変えないで」では弱い。「書き換えない」「削除しない」「移動しない」のように、動詞で止めるほうが効く。
Claude Code にコードやファイル編集を任せるなら、禁則はさらに具体的にしたほうがいい。
この変更を進めてください。
ただし、次はしないでください。
- package.json の依存関係変更
- .env ファイルの編集
- テストコード以外の既存コードの大規模な書き換え
- フォーマットだけを目的にした全体整形
必要なら、まず変更候補だけを箇条書きで出してから作業してください。
ここで効くのは、「やるな」だけで終わらせず、代替行動を渡すことだ。
「勝手に直すな」では止まり切らないが、「まず候補を出せ」「確認を待て」と書けば、動き方が変わる。禁止事項は、単なるストップ看板ではなく、別ルートへの誘導でもある。
非エンジニア向けの作業でも考え方は同じだ。たとえば案件ごとのフォルダ整理で、Claude Code に重複ファイルの洗い出しを頼む場面がある。ここで「不要なものを整理して」と丸投げすると、削除に寄りすぎることがある。そうではなく、こう縛る。
このフォルダを点検して、整理候補を出してほしい。
ただし、削除はまだしないでください。
- 元の文書
- 署名済みのPDF
- 提出済みのファイル
- 画像やスキャンデータ
やってほしいのは、重複候補、古い下書き候補、名前の揺れの候補を一覧にすることです。
これなら、実務で怖い「先に消された」が起きにくい。
ファイル整理は、削除より先に把握が要る。そこをはっきり書くべきだ。
一方で、禁止事項を書きすぎると逆効果にもなる。ここが意外と大事だ。
禁止文を長くしすぎると、指示全体が重くなって、結局なにを優先すべきかぼやける。筆者は一度、やってほしくないことを十個くらい並べたせいで、Claude Code がかなり慎重になりすぎて、肝心の作業まで進みが鈍ったことがある。禁止は要るが、全部を壁にする必要はない。
見極め方はこうだ。
本当に困るものだけを止める。たとえば次の三つだ。
壊れたら困る対象
.env、本番用の設定、提出済み文書、原本、写真の元データなど。
意図がずれやすい操作
大幅な書き換え、勝手な削除、要約しすぎ、名前の変更。
まず確認が必要な操作
追加インストール、依存関係変更、フォルダの移動、外部送信に関わること。
この三つを先に押さえるだけで、作業の事故率はかなり下がる。
逆に、「全部禁止」に見える依頼文はだいたい使いにくい。Claude Code も人間も、動けなくなる。
禁止事項を書くときの文面は、こんな型が使いやすい。
ただし、以下はしないでください。
- 既存の意味を変える編集
- 削除
- 名前の変更
- 設定ファイルの変更
- 確認なしの実行
必要があれば、先に候補だけ出してください。
この「ただし、以下はしないでください」はかなり使える。
命令の本体と禁止事項が分かれるので、読み手が迷わない。箇条書きは、ここみたいに本当に制約を列挙するときだけに絞るといい。だらだらした説明より、止めるポイントが見える。
ただ、禁止事項は「前に置く」と効きやすい。作業の最後に小さく書くより、依頼文の早い段階で見せたほうがいい。Claude Code は、最初に見えた制約を強く持つ。後ろに埋めると、ふつうに見落とすことがある。だから実務では、最初の数行で「やること」と「やらないこと」を両方出す。長文の途中でこっそり禁止するのは、あまり賢くない。
もうひとつ、禁止事項は「成果物」に結びつけると強い。
たとえば文書作成なら、
この文章を整えてください。
ただし、次はしないでください。
- 事実の追加
- 意味の言い換え
- トーンを堅くしすぎること
- 章立ての大変更
出力は、修正版と変更点の要約だけにしてください。
こうすると、「何を避けるか」だけでなく「どの形で返すか」まで揃う。
禁止事項は、単独で置くより、返却形式と一緒に設計すると破綻しにくい。
実際の運用でいちばん効くのは、禁止事項を毎回ゼロから考えず、よくある地雷だけ自分用に持っておくことだ。
ファイル整理なら「削除しない」「移動しない」「元ファイルは残す」。
文書作成なら「意味を変えない」「要約しすぎない」「勝手に章を増やさない」。
開発なら「設定ファイルを触らない」「依存関係を変えない」「テストなしで大改修しない」。
このくらいの定番を押さえておけば、毎回の依頼文がかなり安定する。
要するに、禁止事項は遠慮して書くものではない。
曖昧に「気をつけて」では足りないし、長々と説教しても効かない。止めたい操作を、動詞で、対象つきで、先に書く。必要なら代替行動も渡す。これだけで Claude Code の暴れ方はかなり減る。
作業の事故は、たいてい「やってほしいこと」ではなく「やってほしくないこと」が抜けて起きる。そこを塞いでおくのが、いちばん地味で、いちばん効く使い方だ。