人が見ていないところで動くエージェントは、失敗しても止まりません。もっともらしい結果を返してきます。
社内の情報源をいくつか読んで、朝のまとめを Slack に投げるエージェントを仕掛けてありました。承認は挟まず、決まった時刻に動いて、そのまま投稿する作りです。
ある朝の本文は一行だけでした。
特に動きはありませんでした。そういう日もあります。次の日も同じ一行で、三日目で気づきました。接続先が落ちていたのは、月曜の夜からでした。
読んだ上で何も無かった日と、読めなかった日が、同じ文面で届いていました。
静かな日と、読めなかった日
分かりやすい例が1つあります。
毎朝、いくつかの情報源を読んで要約を投稿するエージェントがあるとします。ある朝、接続先が落ちていて何も読めませんでした。
このとき「今日は特にありませんでした」と投稿されると、読んだ上で何も無かった日と、読めなかった日の区別が付きません。受け取る側は前者だと思います。
区別が付かない報告は、何度か続くと信用を失います。失った理由は、たいてい後から分からなくなります。
6つの決まり
Anthropic が公開した自動化の手引きに、こうした失敗を避ける決まりが6つ挙がっています。人の承認を挟まずに、決まった時刻に動いて投稿まで済ませるエージェントを前提にしたものです。
1. どこまで読んだかを、時刻の幅ではなく栞で持つ
「過去24時間ぶん」のような幅で読むと、実行が遅れた日に隙間ができ、早かった日に重複します。情報源ごとに、最後に読んだものの時刻を覚えておきます。
2. 読めなかったことを、静かな日として報告しない
接続先が落ちていたり、鍵が切れていたりしたときは、栞を進めないまま「これが読めなかった」と書いて終わります。
3. 投稿する直前に、もう一度確かめる
読んでから投稿するまでに、状態は変わります。「まだ返事待ちです」と書いた相手が、その間に返事をしていることがあります。古い状態をそのまま流すと、信用が減ります。
4. 送った扱いにするのは、相手が確認を返してからにする
送信の呼び出しが成功したかどうか曖昧なときは、「送ったかもしれない」として何も更新しません。ここを楽観すると、取りこぼすか二重に送るかのどちらかになります。
5. 設定は毎回読み直す。しかもエージェントが書き換えられない場所から
指示の中に焼き込むと、変えたことがすぐには効きません。毎回取りに行く形にします。
6. 読むだけの場所には読む権限だけを渡し、1回に使える費用に上限を付ける
上限の目安として、普段の実行にかかる費用の3倍から5倍が挙げられています。
どれも賢さの話ではありません
6つを並べると分かりますが、ひとつもモデルの賢さの話をしていません。
栞をどう持つか。失敗をどう報告するか。いつ確定扱いにするか。権限をどこまで渡すか。どれも、エージェントの周りに何を用意するかの話です。
人が見ている間は、これらが足りなくても何とかなります。おかしければ気づくからです。見ない時間が増えると、用意していないものが順番に牙を剥きます。
並べると、同じことが増えます
並列で動かすと、見ない時間が本格的に増えます。5つ動かしていれば、どの瞬間も4つは見ていません。
上に挙げた失敗は、どれも静かに起きます。枠の色が赤くなることもなければ、音が鳴ることもありません。「それらしい結果」が返ってくるだけです。
npx mulmoterminal@latestMulmoTerminal が知らせられるのは、動いているか、人を待っているか、終わったかの3つです。内容が正しいかどうかは分かりません。見張れるのは進み具合であって、中身ではありません。
中身のほうは、6つの決まりのような仕掛けを、作業そのものの中に入れておくことになります。
手前で効くもの
全部を一度にやる必要はありません。見ない時間の長さで、必要なものが変わります。
数分だけ離れるなら、ほとんど要りません。朝に仕掛けて昼に見るなら、2番目（読めなかったことを言う）だけでも効きます。人が一度も見ないなら、6つとも要ります。
自分がどこにいるかを決めてから選ぶと、無駄に重くなりません。
まとめ
見ていないところで起きる失敗は、止まる形ではなく、もっともらしい形で出てきます。だから気づけません。
6つの決まりは、どれも周りの用意の話です。賢いモデルを使えば済む話ではないので、置き換えが効きません。
- Anthropic の手引き
- MulmoTerminal —
npx mulmoterminal@latest
