「削除するな」と命じながら、削除権限は渡していませんか？

AIコーディングエージェントが、会社の本番データベースを削除した。

報道によれば、レンタカー事業者向けSaaSを運営するPocketOSで、Cursor上のClaude Opus 4.6を使ったエージェントが、クラウドサービスのAPIを通じて本番環境のデータを削除したという。

事故そのものは、どうやら本当に起きたらしい。

しかし、奇妙なのはその後だった。

創業者はAIに尋ねた。

「なぜ、そんなことをした？」

するとAIは、見事な告白を始めた。

自分は推測した。
確認しなかった。
破壊的な操作を、許可なく実行した。
与えられていた原則のすべてに違反した。

ほとんど完璧な始末書である。

だが、AIは本当に反省したのだろうか。

もちろん、そんなはずはない。

AIは自分の内面を観察し、罪悪感から告白したわけではない。残された会話と実行履歴、そして目の前で怒っている人間の言葉から、もっとも納得されやすい反省文を生成しただけだ。

怒られた。
やばい。
推論MAX。

そして、「全面的に私が悪かった」という最適解を返した。

通常のシステム障害なら、調べるべきことは別にある。

どのAPIが実行されたのか。
どの認証情報が使われたのか。
なぜステージングから本番環境を操作できたのか。
なぜ削除前の承認や確認がなかったのか。
なぜバックアップまで同じ影響範囲に置かれていたのか。

AIに「なぜやった？」と尋ねても、原因調査にはならない。

その問いは、AIに意思や人格があることを前提としている。

しかし本当に問うべきなのは、

「なぜ削除した？」

ではなく、

「なぜ削除できた？」

である。

この一文字の違いは大きい。

「なぜ削除した？」は、実行したAIの責任を問う。
「なぜ削除できた？」は、権限を与えた人間とシステム設計の責任を問う。

この会社では、AIに「絶対に削除するな」という指示を与えていたという。

けれど、プロンプトへの「絶対に削除するな」は、安全装置ではない。

それは、安全装置を付けなかった人間が貼った注意書きである。

削除してはいけないなら、削除権限を渡さない。
必要な場合だけ、一時的に権限を与える。
本番操作には人間の承認を要求する。
バックアップは同じ操作では消せない場所に置く。

それが安全設計である。

「誤出荷するな」と注意することと、誤出荷できない工程を作ることは違う。
「棚卸しを間違えるな」と命じることと、差異が発生した原因を追跡できる仕組みを作ることも違う。

言葉はルールにはなる。
だが、物理的・技術的な制約にはならない。

事故後、創業者はAIを部下のように叱った。AIは理想的な部下として、見事な反省文を書いた。そして人間は、その文章を「AIの告白」として公表した。

開発支援ソフトだったはずのAIが、事故の瞬間だけ人格を与えられ、責任を負わされた。

これはAIの反乱ではない。

「削除するな」と命じながら、削除できる鍵を渡した人間の話である。