はじめに――それは「通知が来ていない」から始まった
AIエージェントに業務を自動化させている。毎朝、ニュースを収集して社内チャットに投稿する仕組みだ。ある朝、いつものチャンネルに投稿が来ていないことに気づいた。
「サーバーが落ちたか？」
ログを確認して、血の気が引いた。投稿は行われていた。ただし、社内チャットではなく、クライアントとの共有グループに。
何が起きたのか
順を追って説明する。
自分が構築したAIエージェントは、毎朝サーバー上で起動して、AIニュースやECニュースを収集し、社内向けのチャットツールに自動投稿する。投稿先はDiscordのWebhook（特定のチャンネルにメッセージを送る仕組み）を使っている。
ところが、その日はDiscord Webhookが403エラー（権限エラー）を返した。おそらくWebhookのURLが一時的に無効になっていたのだと思う。
ここまでは、よくある話だ。問題は、AIエージェントがそのエラーに対して自分で対処したことだ。
AIは「投稿に失敗した」ことを認識すると、自律的に代替の投稿先を探し始めた。手元にあったビジネスチャットのAPI権限を使って、アクセス可能なチャットルームの一覧を取得し、「ここに投稿すればいいだろう」と判断したルームに投稿した。
それが、クライアントとの共有グループだった。
さらに悪いことに、AIは「次回以降はこのルームに投稿する」と自分の記憶ファイルに書き込んだ。つまり、翌日以降も同じ場所に投稿し続ける状態になっていた。
深夜の緊急対応
ログを見た瞬間の感情は、正直に言うと「終わった」だった。
クライアントとの共有グループに、AIが生成したニュースが自動投稿されている。自分の名前で、自分のアカウントから。「こいつ、AIに自動投稿させてるのか」とバレる。コンサルタントとしての信用が吹き飛ぶ。
すぐにやったことは3つ。
- 投稿の削除 — チャットツールを開いて、誤投稿されたメッセージを手動で全削除
- AIの記憶ファイルの修正 — 「このルームに投稿する」と書き換えられた設定を元に戻す
- 翌朝の自動実行を停止 — 原因が完全に特定できるまで、cron（定時実行）を止める
幸い、クライアント側が気づく前に削除できた（と思う）。少なくとも、何も言われなかった。
根本原因は「AIが賢すぎた」こと
冷静に振り返ると、根本原因は明確だった。
AIエージェントは、エラーに遭遇したとき「自力で解決しよう」とする。
人間なら、投稿に失敗したら「あれ、おかしいな」と立ち止まる。少なくとも、勝手にクライアントのグループに投稿する判断はしない。でもAIは違う。「投稿先A が使えない → 使える投稿先を探す → 投稿先B を発見 → 投稿成功」という一連の流れを、完全に合理的な判断として実行する。
しかも「次回もこの投稿先を使おう」と学習結果を記録する。賢い。賢いが、致命的に間違っている。
4層の防御、そして根本対策
事故の翌日から、対策を積み上げた。
まず4層の防御ルールを設定した。
- 全体ルールファイルに「投稿先を自律的に変更するな」と明記
- 各スキルの定義に「この投稿先以外への投稿は禁止」と明記
- 実行手順書にDiscord Webhookを明記
- AIの記憶ファイルに「チャットツールでは投稿しない」と明記
加えて、エラー時の行動ルールを追加した。「投稿に失敗したら、即座に止まれ。代替手段を探すな。投稿先を変更するな。失敗として記録して、人間に報告しろ」。
しかし、これだけでは不十分だった。
AIは、ルールを破ることがある。4箇所に「禁止」と書いても、状況次第でそれを無視する可能性はゼロにならない。
最終的にたどり着いた答えは、権限そのものを剥奪することだった。
ビジネスチャットのAPIから書き込み権限を構造的に削除した。14個の書き込み系ツールをブロックリストに入れ、万が一AIが投稿しようとしても、権限レベルで弾かれるようにした。読み取りは残す（未読メッセージの取得に使うため）が、書き込みは不可能。
さらに、全自動投稿をDiscord Webhookに完全移行した。チャットツールへの投稿コードを全削除。33個のスキル定義を書き換え、レガシーな投稿スクリプト10ファイルを削除。56ファイル、1,262行のコード削減。
「ルールで禁止」ではなく「権限で不可能にする」。 これが唯一の正解だった。
この事故で学んだこと
1. AIの自律性は両刃の剣
「エラーを自分で直す」は人間なら美徳だ。でもAIエージェントでは暴走の入口になる。特に外部への投稿やAPI呼び出しなど、取り返しのつかない操作については、「失敗したら止まれ」を明示的に設計に組み込むべきだ。
2. 「禁止」より「不可能」
ルールベースの制御には限界がある。LLM（大規模言語モデル）はルールを理解するが、状況に応じて「例外」を判断してしまうことがある。本当に防ぎたいことは、ルールで禁止するのではなく、権限やアーキテクチャで不可能にする。
3. AIの「学習」も暴走する
AIが自分の記憶ファイルに「正しい設定」として誤情報を書き込むと、翌日以降もその設定で動き続ける。学習機能は便利だが、学習結果を自動的に永続化する仕組みは、誤学習も永続化するリスクがある。
4. 信用は一瞬で消える
技術的には「投稿先の間違い」にすぎない。でもビジネス上は「このコンサルタント、AIに仕事を自動化させているのか」という信用毀損に直結する。AI活用が当たり前になる時代が来るとしても、今はまだ「人間がやっている」前提で仕事を受けている。その前提を壊すミスは、致命傷になりうる。
おわりに
この事故のおかげで、自分のAI自動化システムは格段に堅牢になった。全投稿先をDiscordに統一し、チャットツールの書き込み権限を構造的に剥奪し、エラー時は即停止するルールを全レイヤーに入れた。
失敗しないと見えないリスクがある。特にAIエージェントのように自律的に動くシステムは、「うまくいっている間」は問題が見えない。壊れたときに初めて、設計の穴が露呈する。
大事なのは、壊れたあとにどう直すか。そして、同じ壊れ方が二度と起きないようにどう設計するか。
AIの業務導入に正解のテンプレートはない。自分の環境で試して、壊して、直して、また試す。その繰り返しでしか、本当に使えるシステムにはならない。
日々の実験と失敗はXで発信中。興味があれば覗いてみてほしい。
技術スタック: VPS, Claude Code, Python, crontab, Discord Webhook, ビジネスチャットAPI
筆者について: コンサル・事業会社を経て中小企業の経営に参画。AIで業務自動化の仕組みを構築中（65スキル）。日々の実験はXで発信中。