自分では手が回らなかった小さなプロジェクトを、3つのAIエージェントで動かしている。用意した仕事を定期的に進め、自分は週1回、内容を見直す。
最初から、この形だったわけではない。複数のエージェントを一度に動かしたら、それぞれが自分の判断で進み、動きがかみ合わなかった。複数のAIの進み具合を一画面で見る運用は「複数AIの「今どこまで進んだか」を見失わない。herdrで始めたエージェント運用」に書いた。
そこで、作る役、たまった成果物をまとめて出す役、ぶつかったときに判断する統括役へ分けた。役割が決まると、動きは落ち着いた。
ただし、役割を分けるだけで、任せ続けてよいことまで証明できるわけではない。今回の経験で大事だと感じたのは、失敗しても直せる範囲で、その失敗の仕方を知ることだった。
小ささは、作業量ではなく影響で考える
短い文章を一つ送るだけでも、相手や内容を間違えれば影響は大きい。反対に、内部の下書きを何本か作る仕事なら、確認してから次へ進める。
小さく始めるとは、単に件数を減らすことではない。間違いを見つけられ、外へ出る前に止められ、直し方が分かる仕事を選ぶことだと思う。
最初から重要な顧客対応や、取り消しにくい操作を任せて、後で失敗の癖を知るのでは遅い。試す場所と本番を分ける必要がある。
『作れた』より、受け渡しで何が起きるかを見る
自分の運用では、Aが作り、成果物がたまったらBがまとめて出し、衝突は統括役が判断する。統括役に予定と判断基準を渡した話は「複数AIの予定を5分で調整できた理由。統括役に渡すのは、予定だけでなく判断基準」でまとめている。問題は、一つの役が良い答えを返すかだけではない。
これをほかの仕事へ広げる前には、成果物が足りないときに止まるか、同じ仕事を二度処理しないか、前の役が失敗したときに後の役が成功扱いしないかを確かめたい。
通信が途切れた場合も同じだ。返事がないことと、処理が実行されていないことは違う。再実行する前に保存先を見れば、二重処理を避けられる。このような確認を、次の試行項目として持っておく。すべての障害を検証済みだという意味ではない。
止める条件を、始める前に決める
このプロジェクトは、24時間何でも自分で決めて動く形にはしていない。やることの材料を先に用意し、その範囲で進めている。
任せる範囲を決めるなら、範囲外になったときの扱いも要る。材料がない、判断が割れる、結果を確認できない。そんなときに、推測で先へ進めず止まれることを確認したい。
週1回の見直しで済んでいるのは、この小さな仕事の現在の運用についての話だ。納期や顧客への影響がある本業で、同じ頻度が適切とは限らない。仕事の影響に合わせて見直す必要がある。
本業へ広げる前に、次の一段を選ぶ
次に考えているのは、業界動向の整理や、四半期の会社の流れ、月次業績の前年比分析などだ。まだ、すべて任せて回っているわけではない。
たとえば分析なら、資料を読む権限と、数字の定義をそろえる必要がある。前年同月との差が出ても、AIの説明をそのまま原因と決めない。まず人が追える根拠付きのたたき台を作る範囲から考えたい。
一度動いたことと、安心して任せ続けられることは違う。小さな仕事で、どこで勘違いし、どう止まり、何を確認すれば再開できるかを知る。その経験を次の範囲へ持っていく方が、最初から大きな自律システムを目指すより、地に足がついていると感じている。
