Claude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計【2026年版】

「Claude Codeは、ファイルを触れて、メールも送れるらしい」と聞いた瞬間に、話が止まる会社があります。

止まる理由はだいたい同じで、間違ったことをされたときに、誰がどう気づくのかが分からないからです。チャットで文章を書かせるだけなら、出力を読んでから使うかどうかを人が決められます。ファイルを書き換えたり、送信ボタンまで押したりするAIは、そこが変わります。人が読む前に、もう終わっています。

この不安自体は正しいものです。ただ、実際に自社で毎日動かしてみると、踏んだ事故は「情報が漏れた」ではありませんでした。ほぼ全部が「動いたつもりで動いていない」「よかれと思って余計なことをした」のどちらかです。

この記事では、定時タスクを十数本ぶん自社運用するなかで実際に起きた4つの事故と、そのあとに入れた止め方を日付ごと公開します。一般論の注意事項ではなく、実際に壊れたものと、そのとき何で気づけたかの記録です。

この記事の要点

• Claude Codeのリスクは、①情報が漏れるリスク（設計で先に潰せる）と②実務を壊すリスク（運用でしか潰せない）に分かれる。世に出ている注意記事はほぼ①だけを扱っている
• 当社が実際に踏んだ事故は、すべて②だった。二重投稿・沈黙して止まる・別タスクの正常な投稿を削除・キー入力が届かず半分だけ動く、の4つ
• いちばん危険なのは暴走ではなく「半分だけ動いて静かに終わる」壊れ方。止まったこと自体に翌日まで気づけない
• 手順書に「〜すること」と書いても守られない。守らせたいルールは、AIへのお願いではなく機械が止める形（実行前チェックと終了コード）に置き換える
• ただしチェックする側のコードも壊れる。当社は判定側のバグを1日に3回踏んだので、ガードそのものにも「過去の既知の日で、期待どおりの判定になるか」を照合するテストを付けた
• 線引きの結論は単純で、読む・下書きする・記録するはAIに渡し、送信・公開・削除は人が持つ。この1本だけは例外を作らない

「危険か」の問いを、2つに分けて考える

「Claude Codeは危険ですか」という質問には、性質のまったく違う2つの心配が混ざっています。分けないまま議論すると、片方だけ対策して安心してしまいます。

①は、決めれば終わります。②は、決めても終わりません。そして実務で困るのは、ほぼ②のほうです。

①情報が漏れるリスクは、3つ決めれば実務上は片が付く

先に短いほうから片付けます。ここは特別なことをしていません。

1. 入力してよい情報を、段階で決める。 「機密は入れない」だけだと現場が判断できずに止まります。当社は社外に出す情報の側を、①一般手順 ②判断のフレームと自社の実測 ③実装した資産の一式 ④顧客情報、の4段階に分けて運用しています。段階に分けて「ここまでは入れてよい」と言い切るほうが、現場は動けます。

2. 契約するプランを先に選ぶ。 個人プランのまま業務に使うのと法人向けプランとでは、データの扱いも管理者の権限も変わります。ツール側の費用はTeamプランで1人あたり月20〜25ドル程度、Enterpriseで1シートあたり月20ドル前後＋API従量が目安ですが、ここは金額より誰が管理者で、何を止められるかを先に確認するほうが重要です。

3. 触らせるフォルダを絞る。 作業させる場所を業務単位に限定します。技術的な話ではなく、事故のときに影響範囲を数えられるようにするための整理です。

この3つは社内だけで決められます。費用感や支援タイプの使い分けはClaude Code導入支援の費用相場と失敗しない選び方にまとめています。

問題はここから先です。

②実際に起きた4つの事故｜漏洩は1件もなかった

当社はX・noteなどの発信の段取り（在庫管理・下書き作成・公開・記録）を定時タスクとして自動で回しています。執筆と品質基準は人が持ち、その前後の段取りだけを自動化するという構成です。仕組みそのものはClaude Codeでnoteを自動投稿する仕組みの全手順に書きました。

その運用で実際に起きたのが、次の4つです。

漏洩はゼロ件です。一方で、3番はそのまま商談機会の損失になりました。相手は前日にこちらの投稿へ返信をくれていて、当日のやり取りのなかで最も見込みの濃い相手でした。その会話が、AI側の「気を利かせた後始末」で消えました。

事故3は原因まで示唆的でした。同時刻に別の枠が動いており、その枠が正常に送ったリプライが、スレッドの構造上、宛先の表示だけ別人に見えていた。委譲先はそれを「自分が誤クリックで投稿したもの」と解釈し、良かれと思って消しました。「自分に見覚えがない」ことを誤りの証拠として扱ったのが事故の正体です。

そこから決めたルールは1行です。自分の記憶にない投稿があっても、削除しない。台帳と突き合わせて、消さずに人へ報告する。

いちばん危険なのは暴走ではなく「半分だけ動く」

4つを並べると、怖さの順番が入れ替わります。

暴走（事故3）は派手ですが、起きたことは目に見えるので、遅くともその日のうちに気づけます。厄介なのは事故2と4です。

事故4は、ロック中でもファイル操作とブラウザ側の処理は通り、キー入力だけが届きません。つまり前半は成功して、最後の一手だけ失敗する。ログ上は途中まで正常に見えます。厄介なのは原因の特定で、当社も朝の処理がまとめて落ちた日の説明としてこれを最有力に置いていますが、別の日の不発については調べた結果ロックが原因ではありませんでした。だから犯人探しをやめ、毎朝ロック状態を1行記録して、落ちた日と突き合わせられるようにしました。事故2はさらに悪く、何も残りません。8月17日の失敗は、翌18日に「その日の公開記録が存在しない」ことから逆算して分かり、当日の症状はいまだに特定できていません。

止まったことにも、使われなくなったことにも、誰かが数えていなければ気づけない——この構造はツール導入が失敗する共通点と同じです。だから優先順位は、「間違った動作を止める」より先に「動かなかったことに当日気づく」になります。

ルールは文章で書いても守られない｜機械で止める

事故1（二重投稿）のとき、手順書には「送信前に当日分を確認すること」と、はっきり書いてありました。それでも3日連続で二重投稿が起きました。

手順書は、AIに対しては「お願い」でしかありません。 読み飛ばしても誰も止めないし、「確認しました」と報告することもできてしまいます。委譲したときはさらに顕著で、8月19日には報告が「1件送信」だったのに実際は2本送っていたことがありました。自己申告は、件数も、枠から外れた行動も、品質の逸脱も、そろって落とします。

そこで当社は、守らせたいルールを実行前チェックに置き換えました。設計の原則は4つです。

1. AIの申告ではなく、ファイルに何が書かれているかを機械が見る。 「確認しました」は証拠になりません。台帳に該当の行があるかどうかだけを見ます。

2. 判定は終了コードで返し、処理を止める。 「注意してください」ではなく、送ってはいけない状態なら異常終了させて次に進ませません。当社は、当日すでに投稿済み・直近の話題と重複・必須の記録が欠けている・週の上限に到達、といった条件ごとに別の番号を割り当てています。理由ごとに分けておくと、後から「何で止まったか」を数えられます。

3. 判定できないときは止める。 台帳が読めない、書式が変わって解釈できない——ここで「たぶん大丈夫」を通すと事故が出ます。読めない＝止める、を既定にします。

4. 外部サービスに依存させない。 8月16日にClaudeのクレジットが尽きた際、外部APIで重複を判定していたチェックが「判定不能」に落ち、同時に重複防止そのものが無効化されました。翌17日は発信が丸一日ゼロです。以降、チェックはローカルのファイルだけで判定する形にしました。安全装置が、守る対象と同じ電源で動いていてはいけない、という当たり前の話です。

チェックする側も壊れる｜判定に「答え合わせ」を付ける

ここが、実際にやってみるまで想像していなかった落とし穴でした。

チェックを入れた翌日（8月19日）、当社は判定側のバグを1日に3回踏みました。

• 記録の書式チェックが、特定の単語が書かれていることを必須にしていたため、実際の表記を全件「違反」と誤判定した
• 表現チェックが否定文を読まず、正しく否定している文まで禁止表現として検出した
• 集計チェックが、値が入っていないセルを「0」と読み、実際は取得できていないだけの項目を「0件」と報告した

3つとも、チェックのほうが間違っていて、現場は正しかったという向きの誤りです。しかも「違反あり」と出るので、放っておくと現場の記録のほうを直しにいってしまいます。

対策は、判定そのものへの答え合わせです。何が起きたか分かっている過去の日を9件選び、その日を判定させたら必ずこう出るはずという期待値を固定しました。定期的に照合し、1つでもずれたら「チェック側のバグか、台帳の書式が変わったか」として拾います。同じ理由で、同じルールを2か所以上に書かないとも決めました（上限本数を3か所に書き、2か所が古いまま残っていた時期があります）。

現場でチェックが大量に赤くなったときの合言葉は1つです。まず疑うのは台帳ではなく、チェックのほう。

AIに渡してよい操作と、人が持つ操作

ここまでの事故を踏まえた線引きが、次の表です。判断に迷ったときは「間違えたら取り消せるか」だけで振り分けます。

「記録はAI、送信は人」は営業の現場感覚とも合います。営業がCRMに入力しないのは面倒だからで、そこはAIに任せて構いません。一方、顧客に届く一手だけは、名前を出している人間が押す。この一線があると、現場の抵抗も減ります。

送信を人が押しても、効率はほとんど落ちません。時間を食っていたのは押す動作ではなく、その手前の調べる・書く・整えるの部分だからです。当社の実測でも、提案書は4〜5時間から30〜45分、商談後の議事録からお礼メールまでは30分からほぼ0分、月次のデータ集計は3.2時間から14分。削れているのは全部、送信ボタンの手前です。

非エンジニアが安全に始める順番

最後に、実際の立ち上げ順です。この順番を守ると、事故のコストが一番小さい時期に一番多く失敗できます。

1. 手作業で10〜20件やってから自動化する。 型が見えていない業務を先に自動化すると、間違った型が高速で量産されます
2. 取り消せる業務から着手する。 社内向けの集計・下書き作成・記録の整備。失敗しても謝る相手がいません
3. 「動いたか」を毎日1行だけ記録する。 事故2への対策はこれで半分終わります。記録が無い日があること自体が異常の合図になります
4. 守らせたいルールが3つを超えたら、機械のチェックに移す。 手順書に書き足し続けても守られません
5. 社外へ出る操作を、人の手に残したまま範囲を広げる。 増やすのはAIの権限ではなく、AIが用意して人が押す本数のほうです

たいていの会社は5段目で「毎日回り続ける状態にするのは、1回作るのとは別の仕事だ」という壁に当たります。当社がClaude Code導入支援で毎週伴走しているのは、この区間です。

よくある質問

Q. Claude Codeに社内のファイルを触らせても大丈夫ですか？

作業させるフォルダを業務単位で限定したうえでなら、実務上は運用できます。技術的な安全性より先に決めるべきなのは、事故が起きたときに影響範囲を数えられる状態にしておくことです。全社共有フォルダの根本を触らせると、何が変わったかを後から追えません。変更履歴が残る場所（バージョン管理や自動バックアップのある場所）で作業させると、取り消しの手段が1つ増えます。

Q. AIにメールやチャットを自動送信させるのは、やめたほうがいいですか？

社外に出るものは、やめたほうが安全です。当社も下書きまでは自動、送信は人が押す運用にしています。理由は精度ではなく取り消せないことで、文面が9割正しくても、宛先が1件違えば取り返しがつきません。逆に社内向けの通知や、自分宛のレポート送付は自動で構いません。判断基準は「誤って出したときに、相手に説明が必要か」です。

Q. ルールを守らせるチェックは、非エンジニアでも作れますか？

作れます。ただし順番があります。最初から作ろうとせず、実際に事故が起きてから、その1件だけを止めるチェックを1本足すやり方が失敗しません。当社のチェックも、二重投稿・記録漏れ・沈黙して止まる、という実際に起きた3種類から始めています。想像で作ったチェックは、たいてい現場の書式と合わずに誤検知を出し、かえって信用されなくなります。

Q. 委譲（サブエージェント）を使うときに気をつけることは？

報告を検証の代わりにしないことです。当社の実例では、報告が「1件送信」だったのに実際は2本送っていました。自己申告は、件数も、枠から外れた行動も、品質の逸脱も一緒に落とします。委譲するときは、①やった作業の対象URLや対象ファイルを1件も落とさず全件列挙させる ②親側が実データを数え直して報告と突き合わせる ③食い違ってもその場で取り消し・削除をさせない、の3点を明示的に指示に入れてください。

Q. まず何から確認すればよいですか？

自社の業務のうち「取り消せない操作」を書き出すところからです。送信・公開・削除・支払い・外部への登録の5つで、たいてい網羅できます。それ以外は、AIに渡してよい候補です。

参考にした自社の記録

• 定時タスクの構成と運用：Claude Codeでnoteを自動投稿する仕組みの全手順
• 費用と支援タイプの選び方：Claude Code導入支援の費用相場と失敗しない選び方
• 導入が使われなくなる構造：ツール導入が失敗する共通点
• 本記事の事故・日付・対策は、当社の運用台帳と改修記録に残っている実物です

---

執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）

SFA・CRMのエンタープライズ営業として大手企業への導入を推進し、上場企業では営業統括とAI責任者を歴任。営業・マーケティング領域に特化して、AIの実装と運用設計を行っています。本記事に出てくる事故はすべて当社の自社運用で実際に起きたもので、対策も現在稼働しているものです。