Analyzegear
「開発現場で Claude Code を使い倒す」シリーズ3回目。今回は危険な操作を安全に任せる話です。AIに任せると速い。でも、削除・本番反映・外部への送信のような「事故ると戻せない操作」は、速さより先に関所を設計しておく必要があります。読み取りやローカル編集は自由に速く、外向き・破壊的操作には確認を挟む――このメリハリが肝です。
原則：巻き戻せない操作は、着手前に同意を取る
破壊的、または巻き戻しが難しい操作の前には、必ず人の同意を取る。これを最初のルールにしています。具体的には、本番データベースの更新、ファイルの削除・上書き、外部サービスへの送信・公開などです。「送信＝公開」で、いちど外に出たものはキャッシュやインデックスに残る前提で考えます。ある文脈で許可されたからといって、次の文脈まで許可が続くわけではない、とも考えます。
dev → 本番の順を崩さない
反映は必ず検証環境（dev）で確認してから、承認を得て本番へ。正直に書くと、私たちは一度これを崩してdev確認の前に本番へ反映してしまったことがあります。すぐに気づいて戻しましたが、それ以来「dev確認 → 承認 → 本番」を明文化して、AIにもこの順で動いてもらうようにしています。失敗を手順に変えるのが、再発を防ぐいちばん確実な方法でした。
DRY-RUN を既定にする
破壊的なスクリプトは、何もしない（DRY-RUN）を既定の動作にしておきます。実際に変更するのは明示的にフラグを付けたときだけ。たとえば外部APIを叩いてリソースを作るような処理は、まず「これから何を送るか」を表示するだけにして、確認してから本番実行に切り替えます。AIが勢いで実行しても、既定では空振りするので事故りません。
消す・上書きする前に、対象を見る
削除や上書きの前には、必ず対象の中身を確認します。「不要なはず」で消すと、たまに必要なものが混ざっています。とくに他人が書いたファイルや、内容を見ずに配布しようとしているファイルは、必ず開いて確認してから扱います。「中身は見なくていい」と言われても、配布や削除の前には見る。ここは省きません。
権限モードと、拒否されたときの振る舞い
Claude Code はツール実行を許可制で動かせます。ある操作が拒否されたら、それは「別のやり方を考えろ」の合図で、同じコマンドをそのまま押し通さない。拒否も一種のフィードバックとして扱い、手を変えます。危険度の高い操作ほど、この関所が効きます。
検証をセットにする
反映して終わり、にしないこと。本番に出したら curl でHTTPステータスや中身を確認し、「本当に意図どおりになったか」を見ます。結果は正直に扱う――テストが落ちたら落ちたと報告し、スキップしたらスキップしたと言う。「できたはず」で完了にしないのが、任せるうえでの信頼の土台です。
まとめ
- 巻き戻せない・外向きの操作は、着手前に同意。読み取りやローカルは自由に速く。
- dev → 承認 → 本番の順を崩さない。失敗は手順に変えて再発を防ぐ。
- 破壊的スクリプトは DRY-RUN を既定に。消す・上書きの前に対象を見る。
- 反映後は必ず検証。結果は正直に報告する。
次回は「レガシーな巨大コードに手を入れる」――数千行に育ったファイルを、壊さずに安全に変更していく進め方を書きます。
