AI社員の停止条件はどう決めるか
# AI社員の停止条件はどう決めるか
AI社員を1体作ると、最初はかなり頼もしく見える。メールを読ませれば要点を拾うし、議事録を渡せば要約も返る。条件がそろえば、下書きまで一気に進めることもできる。
けれど、現場で本当に効くかどうかはそこでは決まらない。問題になるのは、どこで止めるかだ。送信してよいのか、更新してよいのか、再試行して よいのか。ここが曖昧だと、AI社員は「動くけれど怖い」状態になる。
AI社員の作り方を考えるとき、役割分担だけでは少し足りない。役割は「何をするか」を決める。停止条件は「いつ止まるか」を決める。両方がそろって、はじめて運用できる。
GIZIN の AI社員の作り方 でも、1体から始めて段階的に育てる流れが示されている。だが、育てるほど重要になるのが停止条件だ。止め方が決まっていない1体は、便利さより不安が先に立つ。
AI社員の停止条件は「失敗したら止める」では足りない
よくある誤解は、停止条件をエラー処理のことだと思うことだ。実際にはもっと広い。
停止条件は、AI社員がそのまま進むと危ないときに、どの線で手を離すかを決めるルールだ。
たとえば、次のような場面はどれも停止条件になる。
- 承認者が見つからない
- 権限が足りない
- 入力が足りず、判断材料が欠けている
- 同じ処理を何度も繰り返している
- 外部送信の前提が崩れている
AI社員の導入方法を解説する GIZINの導入記事 でも、最初の1体は環境構築だけでなく、運用の仕組みまで含めて考える前提になっている。停止条件は、その運用の芯だ。
停止条件は3つに分けると漏れにくい
現場で扱いやすいのは、停止条件を3つに分けるやり方だ。
1. 権限で止める
誰が読めて、誰が書けて、誰が送れるか。ここを曖昧にすると、AI社員は一気に危なくなる。
たとえば、読み取りは許しても、社外メールの送信は止める。下書きは作れても、CRMの確定更新は人間に戻す。こうした線引きは、最初に明示しておいた方がいい。
AIエージェントの権限設計を整理した ailead Blog では、Read / Write / Execute を分けて考える。NexTech Journal の 権限設計テンプレート も同じで、任せる範囲と人間が持つ判断を切り分けることが出発点になっている。
2. 状態で止める
同じ仕事でも、状態が変われば扱いも変わる。
下書き、確認待ち、差戻し、承認済み。ここが混ざると、AI社員は前の状態を前提に次の処理を進めてしまう。人間なら「今は止めておこう」と気づける場面でも、AIは前提を補完して進みやすい。
だから、停止条件には「どの状態なら止めるか」を入れる。例外条件と状態遷移を先に閉じる発想は、AI要件定義は例外条件を先に決める と AI要件定義は状態遷移を先に決める にもつながる。
3. 不確実性で止める
AIは、たまに自信ありげに外す。ここがいちばん厄介だ。
再試行を3回しても同じエラーが出る。参照元が足りない。入力の文脈が薄い。そういうときは、続けるより止めた方がいい。
停止条件の記事として参考になる engineer.notes の解説 では、再試行回数、権限エラー、対象件数、環境違い、ガードレール違反などを止める観点として整理している。要は、「まだ頑張れそう」ではなく、「続ける根拠があるか」で判断することだ。
要件定義では、停止条件を4行で書く
実務で一番使いやすいのは、停止条件を文章でだらだら書かず、4行に分けることだ。
| 項目 | 書くこと | 例 |
|---|---|---|
| トリガー | 何をしたときに動くか | 新着メールを受信したとき |
| 停止条件 | どこで止めるか | 外部送信、権限不足、情報不足 |
| 引き継ぎ先 | 止まった後に誰へ渡すか | 担当者、PM、承認者 |
| 記録 | 何を残すか | 停止理由、対象ID、再開条件 |
この4行があるだけで、AI社員の仕様はかなり読みやすくなる。言い換えると、停止条件は「止めるためのルール」ではなく、「人間に戻すためのルール」だ。
AIエージェント要件定義の考え方は、AIエージェント要件定義は評価設計から と相性がいい。評価できないものは改善できないし、止める条件も決められない。
1体目のAI社員は、送信前で止めるくらいがちょうどいい
最初の1体に全部やらせようとすると、だいたい重い。
おすすめは、読む・まとめる・下書きを作るところまでをAI社員に任せて、送信や更新は人間に残す形だ。これなら、AI社員の価値を出しつつ、事故の確率をかなり下げられる。
実際、AI社員の役割を整理した AI社員の作り方は役割分担から でも、読む・書く・確認するを分ける構成にしている。そこに停止条件を足すと、1体目の運用がかなり安定する。
現場では、次の線引きから始めるとよい。
- 読む: 直近メール、商談メモ、会議メモまで
- 書く: 要約、下書き、ToDo案まで
- 止める: 外部送信、確定更新、承認が必要な操作
ここで重要なのは、止める範囲を狭くしすぎないことだ。止めすぎると、AI社員は何もできなくなる。逆に、広げすぎると怖くて使えない。ちょうどいいのは、人間が責任を持つ境界を先に決めるやり方だ。
導入前のチェックリスト
AI社員を本番に入れる前に、次の5点を確認しておきたい。
- 権限が読取・書込・送信で分かれているか
- 停止条件が状態遷移と結びついているか
- 不確実なときの引き継ぎ先が決まっているか
- 停止ログが後から追える形で残るか
- 例外時に人間が判断しやすい画面や通知になっているか
この確認があるだけで、AI社員は「便利なデモ」から「運用できる仕組み」に近づく。
Atsumellの視点
Atsumellが見ているのは、AI社員を増やすことそのものではない。AIが読める仕様に変え、判断の境界を明文化し、運用で壊れない形にすることだ。
その意味では、Kakusill のように要件定義や設計を構造化する発想と、AI社員の停止条件はかなり近い。どちらも、AIに「何をするか」だけでなく「どこで止まるか」を渡す仕事だからだ。
AI社員を作るとき、機能を足すのは簡単だ。難しいのは、止め方を決めることだ。そこまで詰めると、AI社員はようやく現場で回り始める。
