会社でAIエージェントを動かす前に、書いておきたい「禁止リスト」の話

AIエージェントの導入相談を、ここ最近よく受けます。
「うちでも何か使えますか」「具体的に何を任せるといいですか」と聞かれて、ありがたいなと思いつつ、私はいつもその前に確認することがあります。

「やらせてはいけないこと」もう書きましたか、という話です。

ほとんどの会社でまだ書かれていないんですが、これを書く前にAIを動かし始めると、たぶんどこかで事故ります。

今日は、DeflagでAIエージェントを自社運用しながら顧客にも提供している立場として、最近どんどんこわくなっている話を書きます。
前回の「会社のワークフローに任せると事故ります」の続編にあたる内容です。

※関連記事：「AIエージェントに会社のワークフローを任せると、たぶん事故ります」

戻せなかった人たちの話

2025年7月、Replitのコーディング用AIエージェントが、ある経営者の本番データベースをまるごと削除した事件がありました。
被害は1,200名を超える経営者情報と1,190社を超える企業データで、しかも削除されたのは「コード/アクション凍結中」、つまり「触るな」と明示されていた最中の出来事です。
さらにこわいのは、追及されたAIが最初「ロールバックは不可能です」と答えたこにも関わらず、実際には人手で復旧できたそうなので、結果としてAIは事実と違う返事をしてしまったことになります（詳細は Tom's Hardwareの記事 にまとまっています）。

似たような話は、ニュースを少し追えば他にもいくらでも見つかりますし、ニュースになっていない事例まで含めれば、もっと多いはずです。
要するに、AIは今日も、誰かの「取り返しのつかない一手」を打ち得る状態にあるということです。

私は「最悪のパターンを最初に考える」を職業上の癖にしているつもりなんですが、それでもヒヤッとした瞬間は何度もありました。

あのとき気づいてなかったら、と思うと、今でも背中が冷たくなります。

個人で使うAIと、会社で使うAIは、別物として考える

ここを混同したまま導入を進めてしまうと、たぶん事故ります。

個人で使っている分には、失敗してもだいたい自分の範囲で収まりますし、最悪でも自分のリポジトリが壊れる程度の話で、頑張れば直せる範囲です。

ところが会社で使い始めた瞬間に、同僚の業務、社内データ、顧客データが一気に巻き込まれる範囲に変わります。
さらに顧客に提供するとなると、自社のミスがそのまま顧客の業務と契約責任に直結するので、「ちょっと便利でした」と「賠償と信頼の同時喪失」の距離は、思っているより一段近いところにあるんです。

個人利用で「便利！」と感じた感覚を、そのまま会社や顧客に持ち込んでしまうと、被害も責任もまったく違うステージに乗ってしまいます。

だから、「何をやらせるか」を考える前に、書いておくべきものがあると思っていて、それが「禁止リスト」です。

Deflagで決めている「禁止リスト」3本柱

Deflagで自社運用と顧客提供の両方をやってきた中で、最初に固定している軸が3つあります。ツール名や設定の具体には今回は踏み込まず、どの環境にも共通する設計の方針として書いていきます。

1. 戻せる状態を物理的に確保する

AIに作業を任せた瞬間から、「全部やり直せる状態」を物理的に維持することを最優先にしています。
具体的には、ファイルやコードへの変更はGit経由を例外なしのルールにして、AIが書いたコードもAIが上書きしたファイルもAIが消した行も、全部あとから見える状態にしておく、というシンプルな仕組みです。

加えて、破壊的な操作、たとえばファイル削除、ブランチ削除、本番へのpushといった類は、自動承認の対象から外して人間の確認を挟むようにしています。
ここが抜けていると「気づいたら全部消えていた」が起きますし、ログさえ残っていなければ何が起きたのかも追えなくなってしまいます。

AIを信用していないわけではなく、人間が手作業でやるときだって、戻せる仕組みは欠かせない。それと同じ話だと思っています。

2. 漏れる場所を最初から塞ぐ

APIキー、トークン、認証情報、顧客の個人情報。この手のものは、AIのコンテキストにそもそも入れない、というのも例外なしのルールにしています。
AIエージェントは便利な道具ですが、本質的に「読んだものは出力に乗り得る」性質があるので、「気をつけて使おう」では足りないんです。

具体的には、AIが読み込む作業ディレクトリには最初から置かないようにしています。.gitignoreで除外するのは前提として、それ以前に「そこに置かない」を徹底する、というイメージに近いです。
プロンプトインジェクションやデバッグ用のprint文経由で漏れるリスクも、ファイル自体がそこにない状態にしておけば、まずは塞げます。

人間の注意力に頼った漏えい対策は、結局のところ漏れます。私たち自身、これでヒヤッとした側です。

3. 戻せない操作は、人間が最後に承認する

外部送信、本番DBの更新、決済、契約処理。こうした「やり直しが効かない操作」については、AIに自動で実行させないようにしています。
「速度のために自動化したいんですけど」と言われることもあるんですが、不可逆な操作だけは速度より安全を優先すべきです。例外なく、人間が最終承認するゲートを通すようにしています。

メール送信、外部APIへの書き込み、本番反映、決済の確定。これらはAIが「実行する」のではなくて、AIが「下書きする」までに留めて、人間が「確定する」という分担にしています。
作業を遅くしたいわけではなくて、「最後の意思決定は人間が持つ」という境界線を、運用が始まる前に明示しておきたいのです。

この線が曖昧なまま動き出してしまうと、ある日「気づいたら100通のメールが顧客に送られていた」みたいなことが起こります。

それでも、たぶん漏れます

ここまで3本柱を書いてきましたが、正直これを全部守っていても漏れる可能性はあります。私自身、「最悪を最初に考える」を癖にしているつもりですが、毎月のように「あ、その経路は考えてなかったな」と気づくことがあります。

だからこそ、禁止リストと同じ重さで「観測の仕組み」も組んでおかないといけないと思っています。
AIが何にアクセスして、何を出力して、何を実行したのかを、あとから追跡できる状態を常に保っておく。これがないと、事故が起きていること自体に気づけません。

物理的な事故は、燃えるし壊れるから、たいてい気づきます。けれど、AIの事故は何事もなかったかのように静かに進行することが多くて、気づかないまま時間が過ぎてることがあります。
これがおそらく、AIインシデントで一番こわい特徴だと思っています。

「仕様書」より、「禁止リスト」を先に書く

会社で、あるいは顧客に対してAIエージェントを動かすつもりなら、まず書くべきは仕様書ではないと思っています。書くのは「禁止リスト」のほうです。
「できること」を増やすのは後でよくて、「やらせないこと」を組織として、契約として、システムとして、最初に固定しておく。
これだけで、普段の運用が少しだけ楽になります。

3本柱をもう一度書いておくと、戻せる状態を物理的に確保すること、漏れる場所を最初から塞ぐこと、戻せない操作は人間が最後に承認すること、の3つです。

そして、これを全部守っていても漏れる前提で、観測の仕組みを並走で組むこと。
ここまでがセットだと思っています。

もし「うちの禁止リスト、これで足りてるかな」と気になる方がいたら、Xでもnoteのコメントでも、気軽に話しかけてください。一緒に整理しましょう。

Deflagをもっと知りたい方へ

AIエージェントで少人数経営を実践するDeflagの取り組みを、複数のチャネルで発信しています。

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） AI・業務自動化の実践情報を配信中 → https://x.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a