Claude Codeの失敗例と対策、制作会社で起きる「削除・暴走・コスト超過」──チェックポイント、権限、利用額の上限など公式の安全機能で先に止める

この記事は、制作会社でClaude Codeを使うときに起きやすい失敗例と、公式の安全機能を使った対策を扱います。

「気づいたら、消してはいけないファイルが消えていた」

Claude Codeの失敗は、たいてい、使い始めて慣れてきた頃に起きます。
確認の画面が面倒になり、何でも許可するようにした頃です。

意図しない削除、指示を超えた変更、気づかないうちに増えた利用額。
どれも、機能の問題というより、設定と運用の問題です。

この記事の機能の説明は、すべて code.claude.com の公式ドキュメントで、2026年10月27日に確認したものです。機能は更新されるので、導入の前に、必ず最新の公式ドキュメントを確認してください。

Claude Codeの失敗の対策とは、戻せる仕組み・止める設定・上限の3つを、事故が起きる前に決めておくことである

黒字化の外科医です。Claude Codeで起きやすい失敗と、先に止める設定を解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

事故の前に決めるべき理由は、三つあります。

第一に、戻せる範囲には限りがあるから。
公式ドキュメント「Checkpointing」では、/rewind（または入力欄が空のときにEscを2回）で、コードや会話を前の時点に戻せると説明されています。
一方で、Bashのコマンドだけで変更されたファイルは追跡されず、Gitなどのバージョン管理の代わりにはならない、とも書かれています。

第二に、「確認しない設定」は、強い力を持つから。
公式ドキュメント「Configure permissions」では、bypassPermissions というモードは確認を省くもので、損害が出ないコンテナや仮想マシンのような隔離された環境だけで使うよう警告されています。

第三に、利用額は、使い方で大きく変わるから。
公式ドキュメント「Manage costs effectively」では、利用額は使うモデルやコードの規模、使い方で大きく変わると説明されています。上限を決めずに使うと、月末の請求で気づくことになります。

よくある失敗例と、公式の安全機能

失敗1：意図しない削除・上書き

【起きること】
指示より広い範囲のファイルを書き換える、消す

【対策】
・作業の前に、Gitでコミットしておく（戻す場所を作る）
・/rewind で戻せるのは、Claude Codeのファイル編集の範囲が中心
　Bashだけで変更したファイルは、Gitで戻す
・大きな変更は、計画モード（plan）で先に方針を出させる
　公式の説明では、計画モードでは読み取りと調査だけを行い、ソースを編集しない

失敗2：触らせたくないファイルに触れる

【起きること】
.env（接続情報）や、顧客から預かった資料を読んでしまう

【対策】
・権限のルールで、Read(./.env) のように deny（禁止）を書く
・公式の説明では、ルールは deny → ask → allow の順に評価され、
　allowで deny の例外を作ることはできない
・ただし deny は、スクリプトが自分でファイルを開く場合には効かないと
　公式に書かれている。OSの段階で止めたいならサンドボックスを検討する

失敗3：確認なしで走らせる

【起きること】
確認を省くモードで、本番の環境や共有の作業フォルダで動かす

【対策】
・bypassPermissions は、隔離した環境でだけ使う（公式の警告どおり）
・設定の permissions.disableBypassPermissionsMode を "disable" にすると、
　そのモードを使えなくできる。会社で配る設定に入れておく

失敗4：コスト超過

【起きること】
長い会話を続ける、大きなモデルのまま使う、自動の実行を繰り返す

【対策】
・/usage で、使用量を確認する
・Team・Enterpriseでは、管理者が組織・グループ・メンバーの単位で
　利用額の上限（spend limit）を設定できる
・Claude Console（API）では、ワークスペースの利用額の上限を設定できる
・自動の実行（-p）では --max-budget-usd で上限を指定できる。
　ただし公式の説明では、上限は手元の見積もりで判定され、
　上限を超えることもあるため、余裕を持たせるよう書かれている
・関係のない作業に移るときは /clear で会話を切る

今すぐ試せる：自社の事故の芽を洗い出すプロンプト

私はWeb制作会社の経営者です。社内でClaude Codeを使うときの事故の芽を洗い出してください。

【前提】
・使う人数と職種：〔　〕
・扱うリポジトリ（顧客のサイト、社内ツールなど）：〔　〕
・本番の環境に、手元から接続できるか：〔　〕
・契約しているプラン：〔　〕

1. 「削除・上書き」「触らせたくない情報」「確認を省く運用」「コスト超過」の4つで、起きうる場面を3つずつ出す。
2. それぞれに、Gitの運用、権限の設定、上限の設定のどれで止めるかを書く。
3. 公式ドキュメントで確認が必要な点を、一覧にする。

機能の有無を断定せず、「公式で要確認」と書くこと。

事故対策工場：導入前の点検表

□ 作業の前にコミットする決まりがある
□ 本番の環境に、手元から直接つながない
□ .env など、触らせないファイルを deny に書いた
□ 共有の設定ファイルで、bypassPermissions を使えなくした
□ 利用額の上限を、プランに合った方法で決めた
□ 使用量を、月に1回 /usage や管理画面で確認する担当がいる
□ 事故が起きたときの報告の先を決めた

事故が起きたときの損失は、例えばこう計算できます。

例：復旧に、エンジニア2人が3時間ずつ
2人 × 3時間 × 8,000円（時間単価の例）＝ 48,000円

検算：2×3＝6時間、6時間×8,000円＝48,000円です。この金額に、取引先への説明と、信頼の損失が加わります。

構造的なリスク

逆説を指摘しておきます。

設定を固くしすぎると、確認の画面が増え、社員は面倒になって、個人の設定で緩めます。
共有の設定で「禁止」を最小限に固定し、残りは使いながら広げてください。チーム導入の順番は、こちらで扱っています。

▶ Claude Code・Cursorのチーム導入は「試行→ルール→案件→評価」の順番で進める──全員に一斉配布して失敗する理由、4週ずつの段取り、共有する設定ファイルと、続けるかを決める計算例

よくあるQ&A

Q. チェックポイントがあれば、Gitは要らないか？

要ります。公式ドキュメントでも、チェックポイントはセッションの中での素早い復旧のためのもので、恒久的な履歴にはGitを使うよう書かれています。

Q. 事故が起きたら、取引先に伝えるべきか？

取引先の情報や成果物に影響があれば、早く伝えることをおすすめします。契約上の通知の義務は、契約の専門家に確認してください。

Q. コストの管理は、誰がやるべきか？

社長か、管理の担当を1人決めます。席・使用量・案件への配賦の見方は、こちらにまとめました。

▶ AIコーディングツールのコスト管理、制作会社は「席・使用量・案件への配賦」の3つで見る──使われない席、上限のない従量、どの案件の費用か分からない請求を、月1回で整える手順と計算例

最後に

Claude Codeの失敗は、機能の問題ではなく、戻す・止める・上限の3つを決めないまま使い始めることから起きます。

この点検表を、顧客への導入支援のメニューにする型は、こちらにまとめています。

▶ Claude Code導入支援サービス設計キット──診断・初期設定・研修・伴走のメニューと料金表、提案書の構成、設定の雛形、契約の確認点

事故の前に、戻せる仕組みと止める設定と上限を決めた会社だけが、Claude Codeの速さを、安心して案件に使えるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #ClaudeCode #失敗例 #セキュリティ #コスト管理 #リスク管理 #制作会社経営 #中小企業 #AI駆動開発 #生成AI