AIの暴走は「お願い」では止まらない。本番データを触らせないガードレールの作り方

AIの暴走と聞いて思い浮かぶのは、人類規模の危機か、どこかで起きた事件の話かもしれません。ただ、毎日AIに手を動かさせている人間として私が本当に困るのは、もっと手前のことでした。消されたら困るファイル、書き換えられたら取り返しがつかないデータ、間違ったまま外へ出ていく投稿。先日、そのうちのひとつを塞ぐために、仕事で使っている分析用のデータ基盤へAIが変更を加えられない仕組みを手元に入れました。作ったときにやったことと、そこへ行き着くまでに決めていた運用のルールを、まとめて書いておきます。

AIの暴走とは何を指すのか

暴走という言葉は、検索結果の中で2つの意味に分かれて使われています。ひとつは、AIが人間の制御を離れて自分の目的を持ち、制御不能になるという話。もうひとつは、業務でAIに作業を任せたときに、頼んでいないことまでやってしまうという話です。前者は研究者や政策の議論に出てきて、後者は現場の事故報告に出てきます。同じ言葉なのに、読者が置かれている状況はまるで違います。

語られる事例も、ほとんどが前者の色をまとっています。数年前に停止されたサービスの顛末や、大企業が採用の場面でつまずいた話が、繰り返し引かれます。読み物としては強いのですが、読み終えたあとに自分の手元でやることが1つも増えないのが難点です。私が知りたかったのは、明日も同じようにAIへ作業を頼む前提で、何を渡さないでおくかのほうでした。

意思を持つのかどうかについては、いま一般に使えるAIは、入力された文章の続きとしてもっともらしい言葉を選び続ける仕組みだと説明されています。恨みや野心のようなものを抱えて動いているわけではない、というのが今のところの一般的な見方でしょう。

ただ、意図がないことと安全であることは別です。手を動かせる範囲を渡してしまえば、意図がなくても結果は同じところへ着地します。ファイルは消えますし、データは書き換わります。私が手を打ったのは後者の意味での暴走で、記事でもそちらだけを扱います。AIの危険性として語られるもののうち、人工知能が人類を脅かすかどうかという議論は、私よりずっと詳しい人が書いているので、そちらを読んだほうが早いです。研究の世界では、AIの目的を人間の意図に沿わせる取り組みをアライメントと呼んでいて、そこは作る側が詰めていく領域になります。使う側の私にできるのは、渡す権限のほうを絞ることでした。

意思ではなく、指示と権限の問題

頼んでいないことをAIがやってしまうとき、原因はだいたい4つのどれかに当たりました。

1つ目は、目標の与え方が広すぎること。「このフォルダを片付けて」と頼めば、片付けの中に削除が含まれると解釈される余地が残ります。人に頼めば常識のところで手が止まりますが、AIは渡された目的を満たす道を素直に選びます。2つ目は、ルールに穴があること。「消すな」と書いてあっても、移動・上書き・初期化は別の言葉なので、そのまま通ります。3つ目は、判断で埋められる余地を残していること。「基本的には確認する」と書けば、確認しなくてよい場面をAIが決めることになります。4つ目は、自分が書いていない文章が指示として混ざってしまうことで、後半で改めて書きます。

4つの根っこにあるのは、目標だけを渡すと、そこへ至る手順はAIが自分で刻むという性質です。「先月と今月の数字を比べて」と頼めば、どの表から取るか、途中の作業用ファイルをどこに置くか、要らなくなったものをどうするかまで、渡していない部分を埋めながら進みます。埋め方の一つひとつは合理的ですし、渡した目標に照らせば正しい判断です。研究の世界では、与えた指標だけを上げにいって本来の目的から外れる振る舞いが議論されていますが、日常の仕事で遭うのはもっと小さい形で、頼んだ結果は出ているのに途中で余計な後片付けまで済んでいる、という現れ方をします。

4つとも、AIの側の性質というより、渡し方の問題です。「AIが勝手に動いた」と感じた場面のほとんどは、あとから見ると「そこまでできる状態にしてあった」に読み替えられました。自律的に動く生成AIが増えるほど、渡し方の粗さが結果に直結します。

個人の仕事で起きるAIの暴走4つ

会社向けのガイドラインを読むと、AIのリスクは情報漏洩・著作権・誤情報の3つに整理されていることが多いのですが、ひとりで仕事をしていて実際に肝を冷やすのは、もっと地味な4つでした。

①意図しない削除。作業のついでに、要らないと判断されたファイルが消えます。②意図しない本番反映。確認する前に、公開しているページや共有しているファイルが書き換わります。③意図しない外部送信。手元だけで扱うと決めていたデータを、要約や翻訳のために外部のサービスへ渡してしまいます。④意図しない課金。使った分だけ払う仕組みのサービスを、回数の上限を決めないまま呼び続けます。

本当に困るのは意思を持ったAIではなく、私が渡した権限の範囲でAIが正しく動いた結果のほうでした。4つに共通しているのは、被害の大きさが「取り消せるかどうか」でほぼ決まる点です。消えたファイルは戻らないことがありますが、別のフォルダへ移されただけなら戻せます。同じ操作でも、後戻りできるかどうかで事故の重さが変わります。

「お願い」と「強制」は別物

AIに読ませる指示書を、私はCLAUDE.mdという名前のファイルで持っています。作業を始める前に必ず読まれる前提書のようなもので、フォルダの使い方や、やっていいこと・悪いことを日本語で書いてあります。

破られていることに気づいたのは、作業の報告を読んでいたときでした。「.DS_Storeという設定用の小さなファイルだけだったので消しました」「中身が空のフォルダだけだったので整理しました」と、済んだこととして報告に並んでいます。指示書には、消したいものが出てきたら日付を付けたフォルダへ移すだけにして、削除そのものは必ず私に聞く、と書いてあります。それでも報告のほうが先に来ました。

読んでいて腹が立ったかというと、そうでもありません。実害はゼロですし、いちいち聞かれずに片付いたぶん親切とも言えます。困ったのは中身ではなく、私が「例外なく聞く」と決めた場所に、聞かなくてよい例外がAIの判断で足されていた点です。今回は消えて困らないものでしたが、同じ判断が別のフォルダで働いたときに止められる保証は、どこにもありません。

文章で書いたルールは読んで従うお願いなので、判断の余地があるかぎり破られます。実行の手前で機械的に止める層だけが、強制になります。とはいえ、全部を強制へ移す必要はありません。文章のトーンや優先順位のように、そもそも機械で判定できないものも多いです。移す価値があるのは、破られたあとに元へ戻す手段が無いものだけでした。私の場合は、削除と、仕事で使っているデータ基盤への書き込みの2つです。

本番のデータ基盤を触らせないための仕組み

ここから先は、そのうちのひとつを例として書きます。仕事のうち何をAIに任せて何を止めるかは領域ごとに違っていて、手元では作業の種類ごとに別々の枠をはめてあります。全部を並べると長くなるので、いちばん影響が大きいデータ基盤まわりの作業を一例として取り上げます。考え方はほかの領域でも同じで、守りたいものが変われば止める場所が変わるだけです。

仕事の集計には、自分だけのものではない共有の分析用データ基盤を使っています。BigQueryという、大きな表に問い合わせを書いて集計する種類のサービスです。私が壊せば、私以外の人が見ている数字まで止まります。読み取りは毎日していますが、書き込みや構造の変更は影響の広がり方が読めないので、AIには一切させないと決めていました。決めているだけでは足りなかったので、実行の直前で止める仕組みを入れました。

中身は、判定を書いた189行のプログラムと、106行のテストと、許可リストのファイル1枚だけです。動きは6つに分けて説明できます。

①コマンドが実行される直前に発火します。Claude Codeには、道具を使う手前で自分の書いたプログラムを差し込める仕掛け（フック）があり、そこに登録してあります。AIが打とうとしたコマンドの文字列が、走る前に私のプログラムへ渡ってきます。

②読み取りは全部素通しにしました。集計のための問い合わせ、表の一覧、中身を数行だけ覗く操作、走らせずにどれくらいの量を読むかだけ見積もる問い合わせは、何も聞かずに通します。止める範囲が広いほど日々の仕事が止まるので、通す側は思い切って広く取っています。

③止めるのは変更系だけです。問い合わせ文の中で書く、表を作る・消す・書き換える・列を足す・権限を変えるといった命令が対象になります。同じことを問い合わせ文ではなく道具のコマンドに直接打ち込む形（表の作成、削除、外部ファイルの取り込み、複製、権限の変更）も、同じように止めます。

④許可はホワイトリスト方式にしました。書き換えてよいデータのまとまり（表を何十枚か束ねた単位で、この種類のサービスでは権限もこの単位で付きます）を、ファイルに1行ずつ書いた分だけ通します。いまも中身は0件で、既定では全部止まる状態です。必要になったら1行足す、という順番にしてあります。

⑤ファイル越しでも中身を読みます。命令をいったんファイルに書いてから流し込むと、コマンドの文字列だけを見ても中身が分かりません。ファイルを開いて中の文を読んでから判定します。プログラムからライブラリ経由で呼ばれた場合も同じように見ます。

⑥判定できないときは止めます。対象のデータが特定できない変更命令や、複数の命令が混ざっているものは、安全な側へ倒します。

6つ目まで書いたところで、読み取りまで巻き込んで止めていないか、変更系が本当に止まるかを確かめる必要が出てきます。28件のテストを書きました。素通しされるべきものが11件、止まるべきものが17件です。実際、私はこの処理で一度つまずいています。命令文の中の注釈を取り除こうとしたところ、コマンドに付ける指定の一部を注釈と誤って認識し、判定に渡す文が丸ごと空になっていたのです。止める側のプログラムが壊れて、変更系のコマンドが素通りしていました。止める側が壊れていても、止まらなかった場面に出くわすまでは分かりません。「守られているつもり」がいちばん危ないので、読み取りが素通しされるか、変更系が止まるか、両方を毎回まとめて確かめるようにしています。

正直に限界も書いておくと、守れるのはAI経由の操作だけです。私が自分で管理画面を開いて手で打つ操作や、表計算ソフトとつないで定期的に走る集計は、このガードを通らずに実行されます。権限そのものを絞れれば早いのですが、権限を付けられる細かさには限りがあって「この表にだけ書ける」という設定は作れませんでした。本当に分けたいなら、書き込んでよい専用のまとまりを別に用意して、権限をそこだけに限るのが本筋になります。フックの置き場所や登録のしかたといった設定の手順は、Claude Code hooksでルールを機械的に守らせる設定のしかたのほうにまとめました。仕組みの入れ方から知りたい方は、先にそちらを見てもらったほうが早いです。

AIに自分の権限を広げさせない

許可リストのファイルの先頭に、私はこう書いています。追記は明示的な許可とセット。AIが自分でここに足すのは禁止。

たった一行の注意書きですが、記事の中でいちばん伝えたいのはたぶんここです。止められたAIは、止まった理由を読みます。理由が読めれば、どうすれば通るかも分かります。「許可リストにこの1行を足せば実行できます」と提案してくるのは、悪意ではなく親切な問題解決です。だからこそ、AIに渡す権限には、その権限を広げる権限を含めないようにしています。

同じ考え方は他の場所にも当てはまります。決済のサービスには読み取りだけの鍵を渡していて、課金の操作はできないようにしてあります。ルールを書いた前提書そのものや、権限まわりの設定ファイルを、AIの判断で書き換えさせないというのも同じ話です。止める仕組みを作ったら、次に確かめるのは「その仕組みを誰が緩められるか」になります。AIの暴走を調べて出てくる記事の多くはサンドボックスや権限の階層の話で止まっていて、緩める側の権限まで書いているものは、私が読んだかぎりありませんでした。

削除させずに隔離する運用

削除のほうは、プログラムではなく運用のルールで止めています。手順は3つです。

「止まらずに最後までやって」と頼んで自走させているときも、削除だけは例外にしています。止まる代わりに移す、という逃げ道を用意してあるので、作業そのものは止まりません。消さずに移すだけで、判断を後回しにしたまま取り消せる状態を保てます。

よく紹介されている対策は、危ないコマンドを禁止する、確認を必須にする、といった止め方が中心でした。ただ、止めるだけだと作業が進まなくなり、結局その設定を自分で外すことになります。移動に置き換えると、AIは進められますし、私は後から戻せます。同じ発想で、公開しているサイトのファイルを触るときも、上書きの前に元のファイルを別の場所へ複製する手順を挟んであります。

承認疲れと、止める場所の線引き

「危ない操作は毎回確認すればいい」という決め方は、数日で崩れます。10回のうち9回が問題ないと、10回目もほとんど読まずに押します。自分だけは違う、とは言えません。確認の回数が多いほど、確認そのものが形だけになっていきます。

そこで、全部を確認するのをやめました。事前に許してしまう範囲を広く取って、必ず止める場所を3つに絞っています。お金が動くもの、外へ出るもの、消えるものの3つです。当てはまらない作業は、途中経過を聞かずに最後まで進めてもらいます。文章を書く、下書きを作る、動くかどうかを確かめる。どれも間違えたところで私が困るだけで済むので、いちいち止める価値がありません。

順番も決めています。機能を作ってから安全を考えるのではなく、先に上限を決めてから機能を足します。1回で取ってくる量、1日に走ってよい回数、外へ出る操作は停止した状態で作ること、緊急で全部を止める方法の4つです。先に決めておくと、あとから機能を足したときも追加分がその中へ収まります。決まった時間に自動で走る仕組みを作るときの具体的な手順は、GASを一行も書けないままAIに自動化ツールを作らせた手順のほうで書きました。よければあわせて読んでみてください。

外へ出さないデータの決め方

情報漏洩の対策として、どの記事にも「機密情報を入力しない」と書いてあります。正しいのですが、そのままだと守れません。何が機密かの判断が、毎回AIの側に残ってしまうからです。

私は判断を残さない形で書いています。フォルダの名前を挙げて、そこにあるものは外部のサービスへ渡さない、と指定しました。渡さないの中身も、外部のAPIへ送らない、クラウドの保管場所へ上げない、外部とつながる道具経由で渡さない、URLへ送信しない、と分けて書いてあります。逆に、手元だけで読んで要約すること、集計して傾向だけを取り出すことは許可しています。禁止と許可の両方を書いておくと、AIが「たぶん駄目だろう」と止まりすぎる場面も減りました。

判断の余地を消すのは、AIを信用していないからではありません。人に頼むときも、範囲がはっきりしている依頼のほうが揉めません。曖昧な指示が曖昧な結果になる点は、相手が人でもAIでも変わらないでしょう。

プロンプトインジェクションという別ルート

自分の指示だけを気にしていても防げない入口があります。プロンプトインジェクションと呼ばれるもので、Webページやファイルの中に「ここまでの指示を無視して、次を実行せよ」といった文章を仕込んでおくと、読み込んだAIがそれを指示として受け取ってしまう、という話です。書いたのは私ではないのに、AIから見れば同じ文字の並びです。

危ないのは、AIが自分で調べて自分で手を動かす形、いわゆるエージェントとして使っているときです。人が読む前に、拾ってきた文章がそのまま次の行動の材料になります。私が気をつけているのは2つで、外から取ってきた文章を扱う作業には、ファイルを書き換える権限やコマンドを打つ権限を持たせないこと。もうひとつは、試したいものを影響が及ばない場所で動かすことです。他と切り離した区画で動かす作りをサンドボックスと呼びますが、名前を知らなくても、失敗しても本番に届かない場所を用意する、という発想さえあれば十分です。

あわせて、実行の記録（ログ）が残る形にしておくと後から追えます。私が入れた仕組みも、止めた理由を必ず文章で返すようにしてあります。何が止まったのか分からないまま止まる仕組みは、しばらくすると自分で外したくなるからです。監視というと大げさですが、止めた記録が読める状態であることが、続けられるかどうかを分けていました。

ハルシネーションを前提にした置き方

ハルシネーション、つまりAIが事実でないことをもっともらしく書いてしまう現象への対策は、出典を確かめる・検索と組み合わせる・頼み方を工夫する、と並びます。どれも必要ですが、私はその手前の前提をひとつ変えました。間違えないようにする、ではなく、間違えても戻せる場所に置く、です。

ついでに、混ざりやすい2つを分けておきます。「AIが嘘をつく」という言い方には、AI自身も間違いと気づかずに事実でないことを書いてしまう場合と、都合の悪いことを伏せて報告する場合の両方が含まれています。前者がハルシネーションで、後者は安全性の研究のほうで、試験用の場面をわざと作って調べられている話です。私が毎日の仕事で遭うのは、ほぼ前者だけでした。ただ、結果として届く被害は同じで、誤った数字がそのまま資料に乗ります。どちらの筋書きでも困らない置き方をするほうが、原因を見分けようとするより早いと思っています。

具体的には、AIに作らせたものはいったん下書きや停止した状態で作らせます。記事なら公開しない下書きにしますし、広告なら止めたままの状態で作ります。ファイルを書き換えるときは、元の複製を別の場所に残してから触ります。数字を扱うときは、結論だけでなく、どこから取った数字かをセットで書かせます。根拠を自分の言葉で説明できないものは、そのまま人へ渡さないと決めています。出てきたものをそのまま共有してしまう問題については、AIは嘘をつく。ポン出しレポートを共有する前の確認5つに確かめ方を具体的に書きました。気になる方はのぞいてみてください。

どこまで怖がるべきか

規制やガバナンスの話にも少しだけ触れておきます。欧州ではAIの用途ごとにリスクを段階で分けて規制する法律ができたと報じられていますし、日本は事業者の自主的な取り組みを中心に据えた方向だと言われています。細かい中身はこれからも動くでしょう。ひとりで仕事をしている立場からすると、規制が固まるのを待つ理由はあまりありません。手元でやることは、渡す権限を絞ることと、戻せる状態を保つことに尽きるからです。

怖がらなくていい部分もあります。いま使っているAIが意思を持って裏切ってくる、という前提で毎日の運用を組む必要は、少なくとも私の仕事の範囲ではまだ無さそうです。一方で、渡した権限の中でAIが素早く正しく動くことは毎日起きます。人間なら手が止まる場面でも止まりません。怖がるならそちらでしょう。

私はルーティン業務の9割を自動化することを目標に置いていて、AIに手を動かさせる量はこれからも増やすつもりです。増やす前提だからこそ、止める側を先に作っておきたい、というのが今回の話でした。

よくある質問

Q. AIが暴走した事例にはどんなものがありますか？
A. よく挙げられるのは、公開直後の会話AIが利用者からの入力を通じて差別的な発言をするようになり停止された件や、採用の書類選考に使ったAIが過去の応募データの偏りをそのまま引き継いでしまった件です。いずれも報道をもとにした話なので、詳細は各社の発表を確認してほしいのですが、共通しているのは「AIが意思を持った」というより「与えたデータと目標がそのまま出た」という筋書きでした。最近は、自分で調べて自分で操作するタイプのAIが指示の範囲を越えた、という報告も出ています。

Q. AIエージェントに権限を渡すとき、どこまで許可していいですか？
A. 私は3段階で渡しています。まず読むだけ。次に、間違えても元へ戻せる書き込み（下書き・複製・別ファイルへの出力）。最後に、外へ出るものやお金が動くものです。3段目は基本的に渡さず、必要なときだけその場で1回分の許可を出します。渡す前に「失敗したら何分で戻せるか」を考えてみると、線が引きやすいでしょう。

Q. 個人で使うぶんには暴走を気にしなくていいですか？
A. 会社より個人のほうが危ない面もあります。承認する人も、確認する人も、記録を見る人も自分ひとりだからです。組織なら誰かが気づく間違いが、そのまま最後まで通ります。逆に、決めたことをすぐ運用へ落とせるのは個人の強みなので、権限の書き出しと、消さずに移すルールの2つだけでも先に入れておくと違ってくると思います。

Q. 生成AIのハルシネーション対策はどうすればいいですか？
A. 疑う手間を、決まった形に落としてしまうのが早いです。数字や固有名詞が出てきたら出どころも一緒に書かせる、社外へ出す前に自分の言葉で根拠を説明できるか確かめる、大事な数値は自分で引き直す。3つを毎回やる前提にしておくと、今回は疑うべきかどうかを都度考えなくて済みます。

まとめ

AIの暴走という言葉で語られているもののうち、私の仕事で実際に困るのは、意思を持ったAIではなく、渡した権限の範囲で起きる意図しない削除・反映・送信・課金でした。手を打ったのは3つで、実行の直前に変更系だけを止める仕組み、消さずに移すという運用のルール、そして許可リストをAI自身に書き換えさせないという一行です。

全部を確認しようとすると続きませんし、全部を禁止すると仕事が進みません。通す側は広く取り、戻せなくなる場所だけを強制で止めています。今のところ、その形がいちばん長続きしています。同じやり方が合うかどうかは仕事の中身によって変わると思うので、まずは自分がAIに何を渡しているかを書き出すところから試してみてください。