AIの事故は、たぶん静かに進みます

会社でAIエージェントを動かすときの怖さって何だと思いますか？

ずっと「禁止リスト」が先だと思っており、前回の記事でもそれを書きました。

• やらせてはいけないことを先に決める

• 戻せる状態を確保する

• 漏れる場所を塞いで、戻せない操作は人間が承認する

この3本柱を最初に固定しておけば、ある程度の事故は防げます。

ただ、書いても、漏れます。私は「最悪のパターンを最初に考える」を癖にしているつもりですが、毎月のように「あ、その経路は考えてなかったな」と気づくことがあります。だから禁止リストと同じ重さで、「観測の仕組み」も組んでおかないといけない。

前回に続き、観測の話です。
前回記事：会社でAIエージェントを動かす前に、書いておきたい「禁止リスト」の話

物理的な事故は、たいてい気づきます

最初に、AIの事故が他の事故とどう違うかを書いておきます。ここが理解できないと、観測の重みが伝わらないので少し丁寧にいきます。

工場で機械が壊れたとき、人はすぐに気づきます。煙が出るとか、音が止まるとか、ラインが動かないとか、五感のどこかに引っかかるからです。
書類を間違って印刷すれば、紙が出てきて目に見える。コップを落とせば、割れる音がする。物理的な事故には「気づく合図」がセットです。

ところが、AIエージェントの事故にはこの合図がほぼ載りません。
AIは静かに動きます。間違ったファイルを参照しても、間違った内容を出力しても、間違った操作を実行しても、机の上では何も起きません。煙も出ないし、音もしない。仕事は淡々と進んでいるように見えます。

これが、AIの事故が一番こわい性質だと私は思っています。
事故が起きていること自体に気づけないまま、時間が過ぎてしまいます。

私たちが運用しているAIエージェントでも、後から「これ、もし気づけていなかったらどうなっていただろう」とヒヤッとする瞬間が、何度もありました。

観測の3軸——アクセス・出力・実行

ここからは、私たちが普段やっている観測の仕組みを書いていきます。3つの軸で記録を残しています。

1. アクセスログ：AIが何を読みに行ったか

AIエージェントは、与えられた仕事を進めるために、いろいろなファイルやデータを読み込みます。問題は、その読み込みの範囲が想定より広がりやすいことです。

私たちのケースだと、ある作業を指示したときに、AIが「このまま進めると認証情報にアクセスすることになりますが、いいですか」と事前に警告してくれたことがありました。
私はその指示の段階では認証情報まで読み込むつもりはなかったので、ヒヤッとしました。アクセス範囲が明示されていなければ、何にアクセスしたかも分からないまま処理が進んでいたはずです。

「AIが何を読んだか」を観測できる状態にしておくと、事前に止められることが増えます。逆にここが見えないと、ある日「実は機密情報がAIのコンテキストに乗っていました」と分かって、もう遅い、になり得ます。

2. 出力ログ：AIが何を生成したか、しようとしたか

AIが出力するものは、文章だけではありません。ファイルを書き換える内容、外部に送るメッセージの下書き、コードの差分、データの更新案。様々なものを「出力」します。

これらは実行する前に観測できる状態にしておくのが大事です。
我々は、AIが書こうとしている変更の内容を毎回見えるようにして、「本当にこれってやってよかったんだっけ」と、別の仕組みが問いかけてくる構造を入れています。これがあるおかげで、AIが暴走した出力をしたときも、実行される前に止められます。

「実行された後に振り返る」より、「実行される前に観測する」ほうが、事故の規模が小さくなります。

3. 実行ログ：AIが何を実行したか

3つ目は、実際に走った操作の記録です。ファイルを編集した、コマンドを動かした、外部に何かを送信した。こうした「実行」の事実を、すべて履歴として残します。

我々は、AIが触れる範囲のファイル変更は例外なくバージョン管理を通すルールにしています。これは前回も書いた「戻せる状態を物理的に確保する」と同じ思想です。
すべての変更ログが残っているので、何かおかしいと気づいたときに、簡単に巻き戻せます。「気づける」と「戻せる」がセットで効きます。

このアクセス・出力・実行の3軸で観測しておけば、AIの動きはかなり追えるようになります。ここまでが、たぶん多くの記事でも語られている観測の基礎です。

ただ、これだけで安心していると、まだ静かに進む事故があります。

観測の仕組み自体も、壊れます

ここからが、運用してみないと分かりにくい話です。観測の仕組みを作ったら終わり、ではないのです。観測の仕組みそのものが、いつの間にか壊れていることがあります。

私は実際に2つのパターンで踏み抜きました。どちらも一般化できる話なので、AIに限らず使える観点だと思います。

監視カメラの電源が、いつのまにか抜けていた型

1つ目は、ログを書いているはずの場所が、実は止まっていた、というパターンです。

ログを残す仕組みも、それ自体が何かのプログラムです。動いている何かに依存しています。動いている何かは、ある日止まることがあります。

自社の業務エージェントで「ある日からログが1行も書かれていなかった」現象が起きたことがありました。原因は権限まわりの細かい設定で、再起動の影響でログを書く権限が失われていました。
怖いのは、ログがないという状態は「何も起きていない」と見分けがつかないことです。エラーすら出ないので、画面上は平穏そのものでした。

監視カメラの電源が抜けていても、コンセントが目に入らなければ気づかないのと同じです。

対策としては、ログを書く側ではなく、ログがちゃんと書かれているか自体を別の仕組みで監視する、という二重化を入れています。
「最後にログが書かれたのが何時間前か」「今日のログ件数は普段と比べて少なくないか」みたいな、監視の監視です。これがないと、観測層が落ちたことに気づけません。（もちろんこれで完璧にはなりませんが）

家計簿と銀行通帳で、月をまたぐと数字が合わなくなる型

2つ目は、複数のログを組み合わせて使っているときに、保存期間や扱いがズレていて、辻褄が合わなくなるパターンです。

観測は1種類のログだけで足りないことが多いです。
たとえば「ユーザーが完了と押した記録」と「AIが未対応と判断する元データ」のように、複数の記録を組み合わせて運用します。このとき、片方のログの保持期間が短くて、もう片方のロジックがそれより長く遡って判断しに行くと、思わぬ矛盾が出ます。

私たちの例で言うと、ユーザーが「これはもう対応済み」と完了マークを付けた記録が2日で消えるのに、別のロジックが3日前まで遡って未対応のものを拾いに行く、という状態になっていたことがあります。
結果として、完了したはずのタスクが2日後に再び「未対応」として復活してしまいました。

ユーザーから見ると「ちゃんと完了押したのに、なんで復活するの」になりますし、観測する側から見ると、どちらのログも嘘はついていないのに、組み合わせると矛盾が出る、という見えにくい不具合です。

観測ログは、揃って初めて意味を持ちます。1本ずつは正しくても、合わせたときに辻褄が合っていないと、観測そのものが信用できなくなります。

この2つのパターンは、AIエージェントに限らず、複数の記録を組み合わせて運用するシステムなら誰でも起き得る話です。
ただAIエージェントの場合は、観測層が壊れていることに「事故が起きるまで」気づかないことが特に多いと感じています。なぜなら、AIは静かに動くので、観測が止まっていても画面上に違和感が出ないのです。

「禁止」より「観測」のほうが、ずっとコストがかかります

ここでひとつ、最近のガバナンス論に対して感じている違和感を書いておきます。

AIエージェントの話になると、「ガバナンス」という言葉がよく出てきます。
ただその中身が、「禁止リスト」のほうにかなり偏っている、という印象を持っています。やらせないことを決めて、それを社内ルールにして、終わり。これだけで安心するのは、たぶん早いです。

禁止リストは、書けば終わるんです。一度ちゃんと議論して、文書にして、契約に入れれば、ある程度の安心は手に入ります。
一方で観測は、作ったあともずっと運用し続けないと意味を持ちません。ログを取り続け、ログがちゃんと書かれているかをチェックし続け、複数のログの辻褄が合っていることを確認し続ける。これは禁止リストよりも、はるかに継続コストがかかります。

そしてもうひとつお伝えしたいことがあります。これはAIを「自社で使うだけの会社」と、「お客様に提供している会社」の両方の立場で見えてくる話なのですが、観測の責任は、提供する側にもかなりの重さで乗ります。

お客様の業務にAIエージェントを入れる以上、何が動いているか、何が起きているかを、観測できる状態で渡さないと、事故が起きたときに「お客様側で気づかなかったのが悪い」では済まないことが起きます。

私たちはお客様に提供する側でもあるので、ここは深く意識しています。禁止リストだけ揃えて、観測の仕組みがついていない状態でお客様にAIを使ってもらうのは、提供する側の責任放棄に近いと、私は思っています。

観測は、事故を防ぎません

最後に大事なことを書きます。

ここまで観測の話を書いてきましたが、観測は事故を防ぎません。観測は、事故が起きていることに気づける状態を作るだけです。

ただ、それで十分なんです。AIの事故が一番こわいのは、起きていること自体に気づけないことです。
気づけてさえいれば、戻すこともできるし、止めることもできるし、お客様に説明することもできるし、二度目を防ぐこともできます。ただ、気づけないと何も始まりません。

会社でAIエージェントを動かそうとしている方は、ぜひ、禁止リストの次に観測の仕組みを考えてみてください。そして、観測の仕組みが壊れていないかも、たまに確認してみてください。

「観測の仕組み、これで足りてるかな」と気になる方がいたら、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