AI社員の事故15件と再発防止の仕組み｜自社運用の記録【2026年10月】

当社のAI社員の運用では、2026年5月20日から10月2日までに記録に残る事故が15件起き、そのたびに検査・ガード・フックを1つずつ足してきました。15件を5つの型に分けると、AIエージェントを業務に入れ始めた会社が先に入れるべき仕組みは、ほぼ3つに絞れます。

2026年10月1日、当社の問い合わせフォームが、検索から初めて来た人の送信を8月6日から止めていたことが分かりました。原因は迷惑メール対策プラグインのURL検査です。流入元を記録する隠し項目（例: https://www.google.com/）まで検査の対象になっていました。エラーは本文欄に付くので欄名からは原因が分からず、エラー理由の記録を見てようやく確定しました。

当社はAI社員62体を毎日動かし（2026年8月時点の社内実測）、自社メディア8サイトを運営しています。AI社員とは、決まった時間に自分で動き出し、データを取り、処理して、下書きの形で納品するAIエージェントのことです。外部への送信・公開は100%人が承認してから実行しています。それでも、この記事に並べる15件の事故は起きました。事故のたびに足したのは、担当者への注意喚起ではなく、検査・ガード・フック・手順といった仕組みです。

この記事では、15件を日付順の表にし、5つの型に分けて「なぜ起きるか」「仕組みでどう止めるか」「読者の会社で先に入れる1つ」を書きます。顧客名・取引先名・製品名は伏せ、日付と数字は当社の記録のまま載せています。

AI社員の全体像はAI社員一覧（62体）、61体の時点で得た教訓はAI社員61体の運用でわかった9つの教訓にまとめました。この記事はその続きで、失敗の側だけを扱います。

15件の事故一覧（2026年5月〜10月・日付順）

当社の記録（2026-10-03 時点）から、15件を日付順に並べました。各行は「起きたこと／原因／入れた仕組み」の3列で、右端の型は次の節の分類です。

15件を5つの型に分けると、先に入れる仕組みが決まる

15件を「どこで起きたか」で分けると、次の5つの型になります。件数は当社の記録で、業界全体の傾向を示すものではありません。

Webセキュリティの非営利団体OWASPの「LLMアプリケーションのTop 10（2025年版）」も、過剰な権限（LLM06 Excessive Agency）と際限のない消費（LLM10 Unbounded Consumption）を独立した項目に挙げています。当社の型2と型4は過剰な権限と、型3は際限のない消費と重なる部分があります。

共通の原則：人の注意力で防がず、失敗のたびに1つ足す

15件のあとに当社が守っている方針は3つです。

1. 同じ失敗を人の注意力で防がない。「次から気をつける」で終えず、検査・ガード・フックのどれかを1つ足します。
2. 足す仕組みは、原因に合わせて1つずつ。事故の原因を見て、そこで止まる検査・ガード・フック・手順を選びます。
3. 外部送信・公開・本番反映・決済の実行は100%人。AI社員は「送れる状態」まで用意し、実行の1クリックは人が押します。

例えば9月15日のNo.3のあとは、引数の順番に気をつけるのではなく、名前やパターンでプロセスを止めるコマンドそのものをフックで使えなくしました。9月19日のNo.5のあとは、試作を目視しないと全量の生成に進めない順番を道具に組み込みました。どちらも、次に同じ型の失敗が起きた時に、人ではなく機械が先に止まる形です。

自社の失敗を同じ形で整理したい時は、次のプロンプトが使えます。

あなたはAIエージェント運用の事故記録を整理する担当です。
次のメモを読み、事故1件ごとに「日付／起きたこと（数字つき）／原因（1文）／入れた仕組み」の表にしてください。
入れた仕組みは「検査」「ガード」「フック」「手順」のどれに当たるかも書いてください。
「気をつける」「注意する」だけの対策は仕組みに数えず、「未対策」と書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。

[事故メモを貼る]

型1：公開・反映の工程で起きた事故（6件）

なぜ起きるか

6件のうち4件（No.2・7・8・9）は、「出す」工程に検査が無いか、検査が見ていない項目がありました。8月26日のNo.2は、7月に仕込んだ定時ジョブに日次上限の判定がなく、古い下書きが毎日1本ずつ公開されていたものです。残る2件（No.6・12）は、反映する中身を確かめずに流したものです。9月23日のNo.6では、共有ファイルの反映がHEADを丸ごと出すため、別のAIセッションが途中まで書いた編集が28ページに出ました。AI社員を並列で動かすと、自分の差分だけを出しているつもりで、他の作業の差分も一緒に出る構造が生まれます。

仕組みでどう止めるか

• 出す前：当日の公開本数（予約を含む）まで見る機械ゲートを通す（No.2）。
• 出す前：反映する差分の中身を見る。コミット履歴の見た目では判断しない（No.6）。
• 出す処理そのもの：本文の長さが0なら更新しないガードを置き、コマンドはヒアドキュメントで渡す（No.12）。
• 出した後：本文の目印の文字列が0件か、カテゴリが付いているかを取り直して確かめ、自動の図は毎日人が検品する（No.7・8・9）。

反映のあと：変更台帳を残し、再クロール日から数える

直したページの効果を見る時は、変更の記録（台帳）を残し、順位や表示の変化を変更日ではなく再クロール日から数えます。Googleの検索セントラルのヘルプは、クロールには数日〜数週間かかることがあり、同じURLの再クロールを何度依頼しても早くはならないと説明しています。変更日から数えると、まだ反映されていない期間を「効果なし」と読み違えます。

先に入れる1つ

公開・反映の後にページを取り直し、「本文が空になっていないか」「目印の文字列が残っていないか」「カテゴリが付いているか」を機械で見る検査です。No.7・9・12は、どれも公開直後に取り直せば見える種類の事故でした。検査項目を作る時は、次のプロンプトから始められます。

あなたはWebサイトの公開手順を点検する担当です。
次の公開手順を読み、事故を防ぐ検査を「公開前」「公開の処理そのもの」「公開後の取り直し」の3段に分けて挙げてください。
各検査には、機械で判定できる条件（例: 本文の文字数が0なら止める）と、失敗した時に止める工程を書いてください。
人の目視が必要な検査は、目視する人と頻度も書いてください。
仮定した点は必ず「仮定」と明記してください。

[自社の公開手順を貼る]

型2：外部送信と認証の事故（3件）

なぜ起きるか

外へ出る経路では「誰に、何を送るか」を確かめる場所が抜けやすくなります。10月2日のNo.14は、認証なしのルートが呼び出し側の文字列を本文と宛名にそのまま入れていた穴です（同日に修正。悪用の痕跡は確認されず）。ボット対策のTurnstileに合格していても、それは宛先の持ち主の確認にはなりません。Cloudflareの公式ドキュメントが検証の対象として説明しているのはトークン（有効期限300秒・1回限り）で、メールアドレスの持ち主の確認には触れていません。

10月1日のNo.11は逆向きで、迷惑メール対策の検査が広すぎて正しい送信まで止めました。同じ日のNo.13は、送る前に過去の接触を調べなかったため、同じ会社へ同じ登録フォームを2回送ったものです。

仕組みでどう止めるか

• 外部送信・公開の実行は人の1クリックに残す（当社は100%）。
• 認証なしで外へメールを出す経路には、呼び出し側の文字列を入れない。本文はサーバー側に保存した生成結果だけにする（No.14）。
• 送信シートに「過去の接触」の列を必須にし、ありの相手は既存のスレッドで続ける（No.13）。
• 迷惑メール対策の検査は入力欄だけに当て、共通部品を直したら全サイトの版ずれを機械で確かめる（No.11）。

OWASPのLLM06（過剰な権限）も、影響の大きい操作は実行の前に人が承認する仕組み（human-in-the-loop）を対策に挙げています。

先に入れる1つ

外部への送信・公開の実行を、AIではなく人の1クリックにする承認線です。AI社員は宛先・本文・添付を「送れる状態」まで用意し、人が見て押します。どこに承認線を引くかは、次のプロンプトで洗い出せます。

あなたは業務フローの点検担当です。
次の業務一覧から、AIエージェントが「社外へ送る」「公開する」「本番へ反映する」「お金を動かす」操作をすべて挙げてください。
操作ごとに、いま実行しているのが人かAIか、送る前に確かめる項目（宛先・本文・添付・過去の接触）は何かを表にしてください。
AIが実行している操作には「人の承認に戻す」と書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。

[業務一覧を貼る]

型3：運用資源の使い切りと費用（2件）

なぜ起きるか

AI社員は指示どおりに量を回せるので、量の見積もりが抜けると一度に大きく使います。9月18日のNo.4では、競合14サイト×1,000行の取得を見積もりなしで3回回し、SEOツールのAPI枠（月80万ユニット）をその日のうちに使い切って、翌月9日までAPIが止まりました。翌日のNo.5では、題名を24字で機械的に切った文言でサムネイル119枚を試作なしで作り、文字の途中切れで全滅しました（約4,200円）。様式の検査は全部合格していたので、検査が見ていない場所で失敗した例でもあります。

仕組みでどう止めるか

• 実行前に残量と見積もりを比べ、見積もり×1.2が残量を超えたら止まる（No.4）。
• 取得結果はキャッシュし、再集計は追加の消費なしで回す（No.4）。
• 大量生成は、文言の機械検査→先頭3枚の試作を人が目視→費用上限（既定1,500円）→画像の文字の読み取り検査→一覧の目視、の順を道具で強制する（No.5）。

OWASPのLLM10（際限のない消費）も、一定時間あたりの利用回数の制限と利用者ごとの上限（クォータ）を対策に挙げています。

先に入れる1つ

大量に回す前に、見積もりと上限を機械で比べるガードです。費用の上限を金額で1つ決めておくだけでも、上限を超える実行は人の判断に戻ります。

あなたはAPIと生成処理の費用を管理する担当です。
これから実行する処理（対象件数・1件あたりの消費量・繰り返し回数）を読み、合計の消費量と費用を見積もってください。
見積もりに1.2を掛けた値と、現在の残量・今月の上限を比べ、超える場合は「実行しない」と判定してください。
同じデータを再取得していないか、保存済みの結果で代わりにできないかも確認してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

[処理の内容と残量を貼る]

型4：機械の操作そのものの事故（2件）

なぜ起きるか

影響範囲の広い操作を、範囲を確かめずに実行すると起きます。9月15日のNo.3では、AIがプロセスを止めるコマンドの引数順を誤り、名前で広く一致してMacのアプリを多数落としました。10月2日のNo.15では、セキュリティヘッダー（CSP）を静的な監査だけで強制化し、実行時の通信先とWASMの実行許可を見落として、無料ツール1本を一時停止させました。

仕組みでどう止めるか

• 名前・パターン・一覧で対象を選んで止めるコマンド（pkill など）はフックで禁止し、止めてよいのは自分が起動したプロセス1つだけにする（No.3）。
• CSPはReport-Onlyで24〜48時間の違反を集め、新規違反ゼロを確かめてから強制化する（No.15）。

MDNのContent-Security-Policy-Report-Onlyの解説によると、このヘッダーはポリシーを強制せずに違反を監視するためのもので、強制の前に違反を試したり直したりするのに使えます。

先に入れる1つ

広く効く操作を、AIが確かめずに実行できないようにすることです。止める・消す・強制するの3種類は、対象を1つに絞るか、観察期間を置いてから実行する形にします。

あなたはAIエージェントの実行権限を点検する担当です。
次のコマンド・設定変更の一覧から、名前やパターンの一致で複数の対象に一度に効くもの、元に戻せないもの、本番の守りを強制に切り替えるものを挙げてください。
それぞれについて「禁止する」「対象を1つに絞る」「観察してから強制する」のどれにするかと、その理由を書いてください。
仮定した点は必ず「仮定」と明記してください。

[コマンドと設定変更の一覧を貼る]

型5：外部依存の停止（2件）

なぜ起きるか

手の届かない場所で止まると、止まったこと自体に気づくのが遅れます。5月20日のNo.1では、資料ダウンロードのフォームが改ざん防止トークン（nonce）の検証の不整合で本番だけ送信できず、6日間止まっていました。利用者の画面から本番までの経路は、手元の確認では見えません。9月29日のNo.10では、13時47分から、利用しているAIサービス側の組織設定の変更でVM上のAI社員2口が止まり、全自動便が止まりました。

仕組みでどう止めるか

• フォームは送信経路を監視し、フォーム系の変更は本番で実送信して確かめる（No.1）。
• AI側の停止は、出力サイズ（162バイトの定型エラー）で機械検知する（No.10）。
• 止まった時に、手元のMacで代替便を回す手順を先に用意しておく（No.10）。

先に入れる1つ

「止まったこと」を数値で検知する見張りです。送信の成功件数や出力の大きさのように、止まると必ず変わる数字を1つ選び、変わったら人に知らせます。

公開前ゲートで機械が止める項目

当社は、公開前の機械ゲートを通らない記事を公開しません。ゲートが検査する項目は次の8つです。

ゲートは公開の前に止める仕組みで、公開の後の取り直し（本文の目印の文字列が0件か・カテゴリが付いているか）は別に回しています。公開後の取り直しは、No.7とNo.9のあとに足した仕組みです。

【要注意】AI社員の事故対策でよくある失敗4つ

失敗1：事故のあとに注意喚起で終える

❌ 関係者に「次から気をつけて」と共有して終わる
⭕ 検査・ガード・フックを1つ足し、次は機械が止める形にする

なぜ重要か：注意は人にもAIにも残りにくく、同じ型の事故が別の場所で起きます。当社でも9月28日には、型1の事故が2件（No.7・8）同じ日に見つかりました。

失敗2：検査が合格したから大丈夫と判断する

❌ 様式の検査が全部合格したので、全量を流す
⭕ 検査が見ていない項目（文字の途中切れなど）を、試作の段階で人が見る

なぜ重要か：9月19日のNo.5は、帯と色の検査に全部合格したサムネイルが、文字の途中切れで全滅した事故です。検査の合格は「検査した項目が正しい」ことしか示しません。

失敗3：履歴の見た目で、反映する中身を判断する

❌ コミット履歴に他の作業が見えないので、そのまま反映する
⭕ 反映の前に差分の中身を開き、他の作業の途中版が混ざっていないか見る

なぜ重要か：9月23日のNo.6では、履歴の見た目では分からない別セッションの編集が28ページに出ました。AI社員を並列で動かすほど、この確認の重みは増します。

失敗4：本番の守りをいきなり強制する

❌ 静的な監査だけで、セキュリティヘッダーを強制に切り替える
⭕ Report-Onlyで24〜48時間の違反を集め、新規違反ゼロを確かめてから強制化する

なぜ重要か：10月2日のNo.15は、実行時にしか出ない通信先とWASMの実行許可を静的な監査が見落とし、無料ツール1本が一時停止した事故です。

自社のAIエージェント運用に当てはめるチェックリスト10項目

15件から、AIエージェントを業務に入れ始めた会社が確かめておきたい項目を10個に絞りました。「いいえ」の項目から1つ選び、今週中に仕組みを入れてください。

1. 社外への送信・公開・本番反映・決済の実行は、人の1クリックになっているか
2. 送信先ごとに、過去の接触を調べてから送る手順があるか
3. 認証なしで外へ出る経路（フォーム・メール）に、利用者の入力がそのまま入っていないか
4. 公開の前に、機械で止まる検査（題名・本数・重複など）があるか
5. 公開・反映の後にページを取り直し、本文が空になっていないか・目印が残っていないかを確かめているか
6. 反映の前に差分の中身を見て、別の作業の途中版が混ざっていないか確かめているか
7. 大量実行の前に、残量と見積もりを機械で比べているか
8. 費用の上限が金額で決まっていて、超える実行は止まるか
9. 広く効く操作（名前一致のプロセス停止・セキュリティ設定の強制化など）を、確かめずに実行できない仕組みがあるか
10. AIサービスや外部のAPIが止まったことを数値で検知し、代替の手順を用意しているか

業務ごとに「その仕事をAIに任せてよいか」から確かめたい場合は、AIに任せる前の安全度の無料診断で、承認ゲートや検証の要否を業務単位で見られます。

できていないこと・限界

15件を公開したからといって、当社の運用が完成しているわけではありません。正直に書くと、限界は次のとおりです。

• 気づくまでに時間がかかった事故がある。フォームの2件は、止まっていた期間が6日間（No.1）と8月6日〜10月1日（No.11）でした。見張りは足しましたが、記録に残っていない停止がないとは言い切れません。
• 検査を足すほど、確認の手間も増える。61体の教訓の記事でも、コストの本丸はトークン代より確認待ちだったと書きました。人の目視を含む仕組みを足すほど、この確認待ちは増えやすくなります。
• AIに任せていない仕事がある。お金の実行（決済）、外部への送信・公開の実行、取引先との関係づくり、事業の判断は人が持っています。AI社員の仕事は、判断と実行に必要な材料を「送れる状態」「決められる状態」まで用意するところまでです。
• 15件は当社の環境での記録。件数や型の割合は、業種や使う道具で変わります。

よくある質問

5月から10月はじめまでで15件は、事故が多すぎませんか？

多いか少ないかの基準は持っていません。当社が見ているのは、1件ごとに仕組みを1つ足したかどうかで、この記事の15件はすべて「入れた仕組み」の列が埋まっています。

自社の事故を公開しても大丈夫ですか？

顧客名・取引先名・製品名を伏せ、仕組みを入れた後の記録だけを載せています。メール送信経路の穴（No.14）は同日に修正し、悪用の痕跡は確認されていません。攻撃の手がかりになる具体的な経路や設定は書いていません。

小さい会社でも同じ仕組みが要りますか？

15件分の仕組みを全部そろえる必要はありません。ただ、AIエージェントを1体でも社外とつなぐなら、外部への送信・公開の実行を人の1クリックに残すことだけは先に入れてください。

最初に入れる1つは何ですか？

外部への送信・公開の実行を人が行う承認線です。OWASPのLLM06も、影響の大きい操作の前に人の承認を挟むことを対策に挙げています。その次に、公開前の機械ゲートと、大量実行の前の見積もりガードを足します。

AIに承認まで任せることはできませんか？

当社は任せていません。AI社員は宛先・本文・添付を送れる状態まで用意し、実行の1クリックは100%人が押します。外へ出たものは取り消せないことが多いからです。

まとめ：今日から始める3つのアクション

1. 今日：自社のAI運用で、社外へ送る・公開する・お金を動かす操作を書き出し、実行しているのが人かを確かめる。
2. 今週中：直近の失敗を「起きたこと／原因／入れた仕組み」の3列で書き、「気をつける」だけの行に仕組みを1つ足す。
3. 今月中：公開・送信の前後に機械の検査を1つ入れる（公開後の取り直し、または大量実行の前の見積もりガード）。

あわせて読みたい：

• AI社員61体の運用でわかった9つの教訓（職務記述書・承認・検品・並列実行の運用ルール）
• AIメディア7サイト・2,420本の実測データ（2026年6月時点の自社メディア運用の数字）
• AIエージェントの権限設計｜最小権限3段階と停止手順
• AIエージェント暴走事故7件｜本番削除・DB消失とリスク対策（他社で起きた事故の整理）

承認線と停止の条件を最初から入れてAI社員を組む進め方は、AI社員構築代行のページにまとめています。

参考・出典

• OWASP Top 10 for LLM Applications 2025 — OWASP GenAI Security Project（参照日: 2026-10-03）
• LLM06:2025 Excessive Agency — OWASP GenAI Security Project（参照日: 2026-10-03）
• LLM10:2025 Unbounded Consumption — OWASP GenAI Security Project（参照日: 2026-10-03）
• Validate the token（Turnstile） — Cloudflare Docs（参照日: 2026-10-03）
• Content-Security-Policy-Report-Only — MDN Web Docs（参照日: 2026-10-03）
• Ask Google to recrawl your URLs — Google 検索セントラル（参照日: 2026-10-03）
• 事故15件の日付・数字 — 当社の記録（2026-10-03 時点）
• AI社員62体・自社メディア8サイト・外部送信の100%人間承認 — AI社員一覧（2026年8月時点の社内実測）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。