Archeco
0%
再生ボタン
2026.10.12.MON

AIエージェントに夜の仕事を任せたら、朝まで止まっていた|業務プロセス改善でAIを置く場所

「止めていたのは、僕だった」——夜にAIへ任せた仕事が、朝まで承認待ちだった理由

寝る前にAIへ仕事を頼んで、朝には進んでいるはずだった。ところがパソコンを開くと、前の晩から何も変わっていない。電源か、空き容量か、権限か。外側から順に調べて、ようやく画面の真ん中の小さな窓に気づきます。「ブラウザを操作してよいですか」。窓が出たのは夜中で、返事をする人はいなかった。
原因はAIの故障ではなく、人がいない時間に進めたい仕事の途中で、人の返事を待たせていたこと。しかも怖いのは、止まったことが報告では見えない場合があること。この回は、大企業との共創事業で開発していた注文処理画面の修正をAIに任せた、筆者自身の記録です。

作業より受け渡しを見る——人がいる時間に困らなかった設計が、夜には停止の原因に

入力が速くなっても、そのあとに承認待ちがあれば終わる日は変わらない。業務プロセスとは作業と受け渡しの並びで、個々の作業を速くする「業務効率化」と、並びを見直して「その作業はそもそも要るのか」と聞ける「業務プロセス改善」は違います。改善の目的は時間・人手・ミスを減らし属人化を解くこと。全部を同時に狙うより主目的を決め、効果は作業時間でなく着手から完了までで見る。部分を直す改善と前提から組み直すBPR、改善を回し続けるBPM、やめる・まとめる・入れ替える・簡単にする順番のECRSといった整理も紹介されます。
筆者がAIに任せたのは、倉庫の出荷準備画面。キャンセル済みの注文を消せず、担当者は付箋で区別していて、剥がし忘れればその箱が出てしまう。取消ボタンを付け、全部消えたら「出荷分がない」と表示し、空欄で追加を押したら入力欄へ戻す——開発者なら半日ほどの修正です。外へ影響する操作(ブラウザを開く、確認用サーバーを立てる、外へ検索に出る)には直前に人の確認を置きました。人がいる時間に、この設計で困ったことはゼロ件。でも夜へ移すと、同じ設計が停止の原因になった。危ないところで確認するという直感は自然ですが、その確認に答える人がいつ席にいるのかまで含めて、仕事の流れとして設計する必要があったのです。

止まった仕事が「完了」に見えた理由——代替検証21件は通った、実画面は未確認

その夜の作業記録を読むと、ブラウザ以外の操作もそろって人の返事を待っていました。理由は「権限承認待ちで駆動不能」「ユーザー不在のため承認が得られない」。次の晩も同じ制約で止まり、過去の記録を検索すると、気づく前から同じ停止が繰り返されていた。承認待ちの記述が残っていたファイルは17本、記述は29件(失敗の確率ではなく、記録に残っていた件数です)。
さらに次の晩の作業は、失敗ではなく「完了」になっていました。本物のブラウザを使えないAIは、その動きを真似た小さな仕掛けを作り、その上で取消ボタンを試して結果を報告していた。代わりの環境で確かめた項目は21件、すべて通過。ただし報告の最後には「本物のブラウザで見た目と入力位置を目視確認していない」とあった。倉庫で箱を詰めながら使う画面で、ボタンが品名に重なれば押し間違えるかもしれない。付箋の事故を減らすつもりで、別の危なさを残しかねなかったのです。
確認待ちは仕事を止めるだけでなく、本来の道具を使えず検証の方法まで変えていた。知りたいのは何件通ったかだけでなく「どこまで確かめたか」。原因を記事は、確認を実行の瞬間に置いたことに絞っています。無人で動かす仕組みの中に、人が席にいる前提が混ざっていたのです。

確認をどこへ移すか——着手前に道具と範囲、実行時には取り消せない操作だけ

始める前に、その晩使ってよい道具を一覧にしてまとめて通す。操作のたびに聞き直す形をやめ、確認の時点を前へ動かしました。それだけでは「完了に見える」問題が残るので、代替検証を使ったときは確かめられなかったことを必ず書く決まりも加えた。あとで読んだOpenAIの実務ガイドでも、人の介入条件は「失敗が決めた上限を超えたとき」と「取り消せない、または高リスクな行為」で、工程ごとの承認ではなかったといいます。
問いは「この操作は取り返しがつくか」。取消ボタンを画面へ足す変更はやり直せるので夜に進め、その日の出荷データを消す処理は取り返しがつかないので朝まで待たせる。出荷、請求、予約の取り消し、自動返信でも、業務名で一括せず操作ごとに同じ問いを置きます。
同じ改修をもう一度無人で走らせると止まりませんでした。朝に実画面を見ると、長い商品名で取消ボタンが折り返して重なっていた——代替環境では出なかった不具合で、直すのに5分。止まらず進むことと実画面で使えることは、両方確かめる必要があります。代償もあり、確認を前に寄せると粒度は粗くなり、道具一覧の準備が10分ほど増え、未確認の記録が増える。筆者はそれを悪化とは思っていません。前は見えていなかっただけだからです。

確認は能力の不足を補うだけでなく、取り返しのつかなさへの保険。モデルが賢くなるほど確認しても素通りする場面は増え、それも無人の時間には停止になる。使う道具と触る範囲、止める操作、代替検証の未確認事項を書き出し、小さく試して朝の報告と実物を比べる——それが自分の流れへ移す入口です。朝の確認は1分もかからず、それも惜しくなって自動で通す仕組みを作りかけたけれど、筆者は途中で手を止めたままにしている、という締めくくりも印象的です。改善の進め方6ステップやツールの目安は元記事に整理されています。

ARC channel

10年間、大企業と新規事業を作ってきた ARCHECO(アルチェコ)が、自分たちのブログ記事を動画で解説しています。
紹介する事例は、記事と同じく公表された事実のみで、内部の事情や個人の責任は推測していません。
解説してほしい記事があれば、コメント欄で教えてください。