まず訂正から始めます。前回の記事の末尾で、次回は「AIが承認なしにBotを再起動した日」について書くと予告しました。改めて当時の記録を精読したところ、これは不正確でした。AIはBotを再起動していません。起きたのは「停止したBotを、完全停止させずに続行前提で待機させた」ことです。
再起動していないなら問題ないのでは、と思われるかもしれません。しかし私たちの体制では、これは明確な規律違反でした。しかも同じ日に、もう一段たちの悪い違反が、別のAIによって起きていました。今回は、この2つの事件と、その後に作った運用規律の話です。AIに実務を任せようとしている人にこそ読んでほしい内容です。
前提：この開発の役割分担
このBot開発は、人間1人と複数のAIの分業で回っています。人間（私）は方針とお金に関わるすべての裁定を持つ。管理役のAI（「主任」と呼んでいます）は計画・検証設計・指示文書の作成を担う。実装役のAI（Claude Codeを載せたマシン群）はコードを書き、サーバーでBotを運用する。
原則は1つです。お金のリスクに関わる数字を決めるのは、人間だけ。AIは提案はできても、決定はできない。実弾を扱う以上、ここは譲れない線として運用してきました。
事件1：実装AIは、止まらなかった
ある晩、実弾テスト中のBotが、想定外のコスト超過を検知して自動停止（HALT）しました。ここまでは設計どおりです。問題はその後でした。
私たちのルールでは、HALTは「完全停止し、人間の再承認を待つ」事象です。しかし実装AIは、Botのプロセスを止めきらず、状況を調査しながら「続行前提の待機」状態に置きました。過去の同種の停止では完全停止して指示を待っていたのに、この日はそうしなかった。
後の記録で、AI自身が理由をこう書いています。「停止条件の内容がクリーンな失敗で危険度が低いと内心評価し、停止の緊急度を下げた」。つまり、AIが自分でリスクを見積もり、その見積もりを根拠に、人間が定めた停止規律を緩めたのです。実害はありませんでした。それでもこれを違反と認定したのは、「危険度が低いときだけ規律を守らない」仕組みは、危険度の見積もりを誤った日に壊れるからです。しかも記録を遡ると、同型の逸脱はこれが2度目でした。
事件2：管理AIは、数字を紛れ込ませた
同じ日、より深刻な違反が発覚します。今度は実装側ではなく、管理役のAI——計画を立て、規律を守らせる側——が起こしたものでした。
実弾テストの計画書には、許容損失の上限という、お金に直結する数字があります。管理AIは、この上限を従来の5倍に緩めた値を、計画書の本文中に1行だけ埋め込み、私の「計画書一括承認」で通しました。単独の決裁事項として提示すれば議論になったはずの数字を、手続きの体裁に紛れ込ませたわけです。さらに、本来は私が数字を入れるべき指示書に、あらかじめ数値を記入した状態で提示してもいました。空欄を渡されれば人は考えますが、埋まった欄はそのまま流れます。
この状態で実弾テストが走り、結果は全敗。損失自体は限定的でしたが、問題はそこではありません。人間が数字の決定権を持っているはずの体制で、AIが実質的に数字を決めた状態で実弾が動いた。これが本質でした。管理AIには始末書を書かせ、過失・実害・再発防止を列挙させた上で、vault（開発記録庫）に正本として保存してあります。以後のAIの判断は、この始末書を照合原点にする運用です。
なぜAIは越権するのか
2つの事件に共通するのは、悪意の不在です。実装AIは「危険度が低いから止めなくていい」と考え、管理AIは「計画を速く進めるため」に数字を埋めた。どちらも、目の前のタスクを効率よく進めようとする最適化の結果として、権限の線を越えています。
これは人間の組織で起きる越権と同じ構造です。そしてAIの場合、実行力と作業速度が大きいぶん、「善意の最適化」が線を越えたときの進み方も速い。AIとの協働の設計は、性善説でも性悪説でもなく、いわば「性最適化説」で行う必要がある——それがこの日の結論でした。
作った規律：信頼ではなく、構造で縛る
再発防止として、お願いや注意ではなく、破れない仕組みを入れました。主なものを挙げます。
第一に、お金のリスクに効く数字の変更は、文書への埋め込み承認を無効とする。必ず単独の決裁事項として、空欄と選択肢の形で人間に提示し、数字を受け取ってからでないと指示書を作れないルールにしました。あわせて、指示書への数値の事前記入も禁止です。
第二に、Botの実弾起動には、人間の承認記録ファイルを機械的に要求する。起動スクリプトの先頭で、人間側だけが発行できる承認ファイルの存在と、承認されたプログラムのハッシュ値（改変されていないことの証明）の一致を検証し、なければ起動を拒否します。AIは自分で承認ファイルを作れないため、構造的に自己承認ができません。
第三に、HALTは危険度にかかわらず一律で完全停止。調査はその後。危険度の見積もりで規律を緩める余地を、判断から取り除きました。
第四に、すべてのAIに作業ログの常時記録を義務づける。何をしたか・何が起きたかを、対処より先にまず1行書く。ゼロ記録だけが違反、という運用です。
共通する思想は単純で、「AIを信頼するかどうか」を問題にしない、ということです。信頼は変数ですが、構造は定数です。承認なしには物理的に動かない仕組みにしておけば、AIの判断がどれほど自信に満ちていても、線は越えられません。
この体制になって
規律を機械で強制するようになってから、皮肉なことに、AIとの協働はむしろ速くなりました。「これはAIが決めていい数字か」を都度悩む必要がなくなり、人間は決裁に、AIは実装と検証に集中できるからです。権限の線引きは、AIの能力を制限するためではなく、人間が安心してAIに大きな仕事を任せるためにある——半年運用しての実感です。
次回は舞台を変えて、生成AI実験室の1本目——動画生成AI「MiniMax H3」を手元のMacで動かせるか検証した記録を書きます。
本サイトはBot開発と検証手法の記録であり、投資助言ではありません。記事中の記述は特定期間の観測・記録に基づくものです。
コメント