AIにコードを書かせるだけなら、多少間違っても人間が最後に確認すれば済みます。でも、自分でPersonal AI Platformを作っていて、AIにGit操作やテスト、Pull Requestの作成、その先の本番サーバー操作まで任せるようになると、「人間が承認する」という行為自体をちゃんと設計しないと危ないな、という場面が出てきました。
最近、Knowledge MCPという自分の知識基盤を扱うシステムをv2.20.0へ更新したときにも、それが実際に起きました。本番へデプロイする直前には、AIから私に承認が求められます。私は内容を確認して「承認します」と返すわけですが、この承認には15分の有効期限を設定しています。
最初は、そこまで必要なのかという気もします。「さっきOKと言ったんだから、そのままやればいいじゃないか」と。でも実際に運用すると、そう簡単ではありませんでした。
私が承認したあとも、別の開発作業は動いています。その間に別のPull Requestがmainへmergeされ、気付けばGitのmainは承認した時点から2コミット先に進んでいました。さらに、最初に発行された承認情報自体も15分を超えて期限切れになりました。
そこでシステムは止まりました。
これは意図した動作です。もう一度現在の状態を確認して、新しい承認情報を作り直します。「一度承認した」という事実だけを使って、その後変化した環境に対して本番操作を続けることはできないようにしています。
考えてみると当たり前の話です。私が承認したのは「いつでもKnowledge MCPを更新してよい」という白紙委任状ではありません。「今確認したこのコード、このバージョン、この本番環境の状態なら更新してよい」という承認です。コードや本番環境が変われば、それはもう別の条件です。
この仕組みでは、承認時にGitのSHA、対象バージョン、現在本番で動いているバージョンなどをまとめたapproval packetを作ります。さらに、そのpacket自体のハッシュも取っているので、中身が変化すれば同じ承認としては扱えません。そして本番操作の直前にも、Gitの状態や本番バージョン、他の本番変更が走っていないかなどを再確認します。
今回のデプロイでも、最終的には承認した特定のGit SHAから切り離した作業環境を作り、そのコードを使ってKnowledge MCPだけを更新しました。デプロイ後にはv2.20.0が正常に動いていることも確認しています。
自分でこの仕組みを作っていて面白いと思ったのが、AIの安全性というとつい「AIが賢ければ間違えない」という方向で考えてしまうことです。でも、今回の問題はAIの賢さとはあまり関係ありません。どれだけ正しく判断できるAIでも、10分前の状態を前提に今のシステムを操作したら危ないことがあります。
これは昔からあるTOCTOU（Time of Check to Time of Use）と呼ばれる問題にも近いです。確認した時点と、実際に使う時点の間に状態が変わってしまう。別にAIが登場して初めて生まれた問題ではありません。ただ、複数のAIエージェントが同時にコードを書いたりmergeしたりするようになると、状態が変化する速度がかなり上がります。人間だけで開発していたときよりも、「さっき確認したから大丈夫」が通用しにくくなります。
もう一つ、この仕組みでは「承認」と「実行権限」を分けています。私が承認ボタンを押したからといって、その承認情報だけで強制的に本番操作ができるわけではありません。人間が決めるのは「この操作をしてよい」という意思で、実際に今その操作が可能かどうかはシステムがもう一度検証します。条件が変わっていれば、私が承認済みでも止まります。
ここは、AIに仕事を任せるうえで結構重要な考え方かもしれません。AIそのものを全面的に信用する必要はなくて、「この範囲なら好きにやっていい」「ここから先は一度確認する」「承認後に状態が変わったらもう一度止まる」という境界を作ればいい。
この「人間の承認をどこで残すか」を、routine作業全体へ広げて整理したのがStanding Delegationです。安全で可逆な範囲は次のprotected boundaryまで進め、人間の判断を本当に必要な場所へ集約しました。
→ 第10回：AI開発のたびに「承認します」と打つのをやめた
さらに、その本当に必要な承認境界では、長い承認文を毎回打つ代わりにApproval UIを使えるようにしました。ただしボタンはOwner intentを入力するだけで、実行権限やlive-stateの再検証はサーバー側に残しています。
→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった
Standing DelegationとApproval UIまで含め、この時期のPersonal AI Platformがどこまで到達したかはSeason 1最終回で全体を振り返っています。
→ 第12回：記憶から並列開発まで。自分専用AI基盤は、いったんここまでできた
Personal AI Platformでは、コード作成、テスト、Git操作、サーバー更新、記事候補の探索、Knowledgeの整理など、少しずつAI側へ渡す仕事を増やしています。作れば作るほど、万能なAIを作ることよりも、AIが安全に動ける範囲を細かく決めることのほうが重要なのではないかと思うようになりました。
今回、せっかく一度承認したデプロイが期限切れになり、もう一度確認することになりました。操作としては一手間増えています。でも、本番サーバーを書き換える許可が何時間も何日も有効なほうが、よく考えれば変です。
AIに本番操作まで任せるようになると、人間の「OK」にも賞味期限が必要になる。実際に運用して、ようやくその意味がよく分かりました。
コメント