AI Agentに、ファイルの書き出しをつけた。
それまでは、画面に回答を返すだけだった。便利になったと言われた。出力をレポートに使える。手で写し直さなくていい。
その数日後、agentが前の出力を上書きした。整理するつもりだったのかもしれない。更新するつもりだったのかもしれない。とにかく、前のファイルは消えた。
目の前で、使っていた人に指摘された。
読むのと書くのは、やり直しの意味が違う
それまでagentがしてきたのは、読むことと考えることだった。
読み間違えても、世界は変わらない。間違いは画面の中にある。もう一度聞けば、別の答えが返ってくる。
書き出しは違う。ファイルを書き換えた瞬間に、元がない。
この違いを、権限を渡すときに考えていなかった。できることを増やした、としか思っていなかった。
checkpointなら戻せると思った
中断から復帰できるように、checkpointは入れてあった。途中で閉じても、そこから続けられる。
状態を保存してあるのだから、上書きの前に戻せるのではないか。
やってみた。
stateは戻った。agentは上書きする前のノードまで、きれいに巻き戻った。
ファイルは戻らなかった。
上書きされたファイルは、上書きされたままそこにあった。checkpointが戻したのは、agentがどこまで進んだかだけだった。
今なら当たり前に見えますが、そのときは本当に戻ると思っていました。
checkpointは、agentの中を戻す仕組みだ。外に書いたものは、agentの外にある。
事前のガードでは、この話は終わらない
この手の話でよく出てくるのは、事前に防げ、だ。
確認を入れろ。書き込める場所を限定しろ。危険な操作は拒否させろ。
その通りで、入れた。
だが、ガードだけで、すべてを防げるとは限らない。想定していなかった経路から、変更が起きることもある。LLMの出力は揺れるので、同じ入力でも違うことをする。
そして、事前に防ぐという話は、やってしまったあと戻せるかを一つも語っていない。
防げなかった回のことが、設計に入っていなかった。
戻せなさを、agentに背負わせていた
ここで、順番が逆だったと気づいた。
agentに戻す力を持たせようとしていた。checkpointを伸ばせば、undoが作れるのではないかと。
だが、agentのstateを巻き戻しても、それだけでは、外に与えた変更は戻らない。
一方で、上書きしても前に戻れる仕組みは、日常的に使われている。クラウドの文書サービスにも、版を残すストレージにも、トランザクションを持つDBにもある。
agentが特別に戻せないわけではなかった。書き込む先を、戻せる場所にしていなかっただけだった。
上書きで前が消える場所に書いていた。だから消えた。
戻す責任を、戻せるように作られた層へ渡す。agentを強くするのではなく、置き場所を変える。
で、中と外をどう合わせるのか
checkpointが中を戻す。書き込み先が外を戻す。
この二つを別々に持っているだけだと、次は別のところで壊れる。stateは三回目の直前に戻ったのに、参照しているファイルは五回目のもの、という状態が起きる。
中と外と、その対応。三つ揃って、はじめて戻せる。
その三つ目をどう結ぶかは、ここでは書きません。測って直した記録のほうに入れてあります。
本番に入れる前に
PoCが通って、次は本番、という段階でこの話に当たる人が多いと思います。
読むだけのagentなら、この問題は起きない。書き込みをつけた瞬間に、設計の問題に変わる。
壊れる場所は、入れてから見つけるより、入れる前に知っておいたほうが安いです。
オンプレ・ローカルモデル・高機密という制約の下で、RAGをAI Agentへ育てて本番運用へ進んだ、最初の三ヶ月の記録を、PDFにまとめています。この章では、中と外と、その対応をどう結んだかまで、実装と一緒に書いています。