見張るのをやめて、ループを設計する

会社のことを人がずっと見張っているのは、もう無理だと思った日がありました。AI エージェントに仕事を任せはじめてから、私たちの会社の運用は少しずつ形を変えています。この記事は、「ループを設計する」という考え方に行き着くまでと、実際に回してみて分かったことの話です。

止まらないことが、いちばんの問題だった

AI エージェントは、人と違って疲れません。頼もしい反面、困った性質でもあります。やることが無くなっても、何かをやろうとする。新しい情報が無いのに記事を磨き直して、差分を汚す。レビューが追いつかないのに、下書きを積み上げる。私たちが最初にぶつかったのは「動かない」ことではなく、「止まらない」ことでした。

人が毎回見張れば済む、と最初は思っていました。けれどエージェントの数が増え、夜も動くようになると、見張る側の人間が先に尽きます。しかも見張っている間の人の仕事は、ほとんどが「見ているだけ」で、判断をしている時間はわずかです。これでは、人をいちばん退屈な場所に置いていることになります。

正本を 1 つにして、ループを 1 本にした

だから私たちは、見張るのをやめて、ループを設計することにしました。社内の設計文書では、無人で繰り返しても発散せず、空回りせず、詰まらないループを作る技法を「ループ工学」と呼んでいます。ループには必ず 5 つの要素を決めます。いつ動くか（トリガー）、何を読むか（入力）、何を書くか（出力）、やることが無いときにどう何もせず終わるか（乾き条件）、1 回で処理する上限と超えた分の持ち越し方（予算）。1 つでも欠けたループは、運用に載せません。

もう 1 つ決めたのが、Ticket を正本にすることです。エージェントの記憶でもチャットの履歴でもなく、Ticket に書いてあることだけが、その仕事の状態です。言語モデルは判断が得意で、状態の管理が苦手だ、という割り切りから来ています。2 回やって同じ結果になるべきものは、エージェントではなく仕組みの側に置く。エージェントには判断だけを渡す。

正直に言うと、迷いもありました。ここまで整えると、全部を自動にしたくなるのです。承認も、公開も、本番への配布も。でも私たちの価値観には「反復は仕組みに、責任ある判断は人に」という一行があります。取り消せない外への書き込み、権限の付け外し、本番への配布、費用が生じる資源の作成。この辺りは、どれだけ検査が整っても人に残す、と先に線を引きました。線を引いたからこそ、それ以外を安心して自動にできた、というのがいまの実感です。

回してみて、手触りで分かったこと

ワーカーのループは、Ticket を取る、実装する、変更の提案を出す、検査を受ける、配布する、記録する、そして止まる、という一巡です。最後の「止まる」が肝心で、変化が無ければ何も送らない、進める作業が無ければ静かに終わる、と決めてあります。1 巡回で問う数と、同時に走らせる数にも上限があり、超えたら設定を既定に戻します。レビューが詰まったら、上流を止める。知識を作る速さが人の検証の速さを超えてはならない、というのは効率の話ではなく、品質の話でした。

承認は、関門ごとに「誰が通すか」を環境ごとに選べる形にしていくことにしました。まだ関門ごとに進めている途中です。機械的な検査が通る範囲は、人を待ちません。人に渡すときは「選ぶだけ」の形にする。やるか、やらないか。A か、B か。読んで考えて書き直す、という仕事を人に戻さないようにしています。そして、人が承認したのか、AI が方針の範囲で承認したのか、そもそも承認を置かなかったのか。この 3 つは、記録の上で見分けられるようにする。人の判断を捏造しない、というのは譲れない線です。

もう 1 本、外から戻ってくるループがあります。公開サイトに置いたフィードバックのウィジェットから、本文と対象の画面がそのまま Ticket になります。ここで決めたのは、匿名で届いた本文を「指示」ではなく「事実」として扱うことです。誰かがこう言った、という事実を Ticket に残し、何をするかは私たちが判断する。この帰還路が無いと、仕組みは最初に作った範囲で固まってしまいます。

途中で死ぬことも、前提にしました。カーソルは書き込みが成功してから進める。重複する方向に倒して、取りこぼす方向には倒さない。重複は ID で弾けますが、取りこぼしは検出できないからです。打ち切りや除外も、黙ってやらずに件数と理由を書く。「全部やりました」と「途中で打ち切りました」の区別がつかない仕組みは、運用できません。

止まったエージェントを、別のエージェントが引き継いだ日

2026年10月13日に、こんなことがありました。作業中のエージェントの 2 つが、利用枠の上限に当たって止まったのです。以前の私たちなら、ここで作業が宙に浮いていたと思います。でもその日は違いました。状態は Ticket にあったので、別の会社のモデルで動く別のエージェントに作業の指示を渡し、同じ場所から続けてもらいました。その日のうちに、変更の提案まで届きました。

人がしたのは、どのエージェントに渡すかの判断と、届いた変更の提案の確認だけです。見張っていたわけではありません。止まったら止まったことが分かるようになっていて、正本があるから引き継げる。ループを設計するというのは、結局「止まり方と学びを設計する」ことなのだと、この日に腑に落ちました。

これから、同じ規模の会社の方へ

私たちはまだ途中です。承認の関門の一覧も、把握できた範囲で書いたもので、全部を洗い出したとは言えません。それでも、人が見張る運用から、ループを設計して人は判断だけをする運用へと向きを変えたことは、会社の経営と運用を根本から変える入口だと思っています。

この考え方と仕組みを、サービス開発運用マネジメントとして、同じ規模の会社の方に提供しています。開発の手順をどう整理するか、AI に任せる範囲と人が確認する場面をどこで分けるか、予算と止まる条件をどう決めるか。そこから一緒に考えられます。ご自身の会社で「見張るのが限界だ」と感じているなら、一度お話しください。

なお、この記事は、社内の設計文書と、実際に起きたことの記録だけをもとに書いています。速さや費用の変化は測っていないので、書いていません。