業務プロセスのAI組み込み｜寝ている間の仕事に承認を置かない

僕の実家の合鍵は、長いあいだ1本しかありませんでした。増やせばいいのは分かっていたのですが、増やすと失くしたときが怖い、と思っているうちに何年か経っています。

そのあいだ、僕が鍵を持って出た日は、兄弟が誰も家に入れませんでした。近所で時間をつぶしてもらうことになります。鍵は正しく管理されていて、正しく誰の役にも立っていませんでした。

AIの自動化が進む昨今、「寝ている時間に、いかに翌朝までの仕事を依頼しておけるか」「そのあいだ、自分の指示なしで仕事が自律的に進むか」ということが、生産性に大きな影響を与えるようになってきました。そして僕も、寝る前に大きめな指示を出したり、自律モードをONにすることが習慣化していました。

いつものように夜のうちに仕事を依頼して、翌朝パソコンを開いたら、前の晩から1行も進んでいませんでした。

AIのほうが落ちたのだと思って、あちこち調べました。電源、空き容量、権限。外側から順に、10分ほどかけて潰していきます。

最後に画面をよく見たら、真ん中に小さな窓が出たままでした。「ブラウザを操作してよいですか」と聞かれたところで、やり取りが止まっています。出たのは夜中で、僕はそのとき寝ています。

止めていたのは、僕でした。

先に一行だけ置きます。人の承認を工程の中に置くと、人がいない時間にすべて止まります。 やっかいなのは、止まったことが記録の上では見えないことです。むしろ、完了したように読めてしまいます。

この晩やらせていた仕事

やらせていたのは、子ども向けの離乳食をネット通販で売る事業で、注文をさばくために使っている画面の修正でした。大企業と僕の会社の共創事業で、まず小さく作って現場で売ってみるMVPとして立ち上げた通販です。その運用のために、自分たちで画面を作っていました。

商材は、常温で保存できるパウチの離乳食です。冷蔵ではないぶん、まとめ買いと定期便が多くなります。

修正の対象は、倉庫で箱を詰める担当者が朝いちばんに開く「出荷準備」の画面です。前日までに入った注文が上から並んでいて、担当者はそれを見ながら詰めていきます。画面の下には、電話で入った追加注文をその場で手入力するための欄と、「追加」のボタンが付いています。

困っていたのは、キャンセルが入った注文を、画面から消せないことでした。注文は足せるのに、取り下げられない。担当者は、キャンセルが入った注文に付箋を貼って、印をつけていました。 剥がし忘れると、キャンセル済みの箱がそのまま出ていきます。

直す内容は3つです。各行の右に「取消」を置いて、押したら消えるようにする。ぜんぶ消えたときは「本日の出荷分はありません」と出す。そして、何も入れずに「追加」を押したときは、入力欄を赤くしてカーソルをそこへ戻す。品名の空いた行が紛れ込むのを防ぐためです。

ここまでで、人が手を動かせば半日ほどの分量になります。

この修正を、AIに任せていました。使っているのは、自分たちで作った開発用のソフトウェアです。指示を一度出すと、AIが自分でコードを書き、動くかどうかを確かめ、できたところまで文章で報告してきます。

夕方に指示を出してパソコンを閉じ、朝にその報告を読む。日中に人が張り付かずに済むからです。

AIが何かを実行する前に、人が中身を見て通す仕組みのことを、ここでは「確認」と呼びます。危ない操作を勝手にやらせないための歯止めで、業務プロセスにAIを組み込むときは、まずこれを設計します。

今日は、その確認をどこに置くかで結果が変わった、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、危ないところへ人の承認を置いた

確認をどこに置くかという設計は、素直に教科書どおりでした。

外に影響が出る操作には、実行の直前に人の確認を挟む。ブラウザを開くもの、動作確認用のサーバーを立てるもの、外へ検索に出るもの。この3系統に置きました。

この置き方は、ちゃんと動きました。人が画面の前にいるあいだは、確認が出て、通して、先へ進みます。危ないことは何も起きません。

人がいる時間だけ走らせていたあいだ、この設計で困ったことは0件でした。教科書が間違っていたわけではありません。

② 止まっていたのは、確認の窓1件ではなかった

その朝、目に見えていたのは確認の窓1件だけでした。

ただ、AIが夜のあいだに残していた作業の記録を開いてみると、止まっていたのはそれだけではありませんでした。ブラウザを操作する道具が2件、パソコンの画面そのものをマウスとキーボードで操作する道具が1件、それに動作確認用のサーバーを立てる処理が1件。人の承認を置いた3系統に、道具は4件ぶら下がっていました。その4件が、そろって同じ理由で動けなくなっています。

記録に残っている理由は1行です。「権限承認待ちで駆動不能」。その横に、原因が書いてあります。「ユーザー不在のため承認が得られない」。

当たり前です。夜中に確認する人がいません。

止まったのが一度きりなら、まだ話は簡単でした。

次の晩も、同じところで止まっています。 記録には、前の晩と同じ理由だと一言あるだけでした。原文はそっけなく「cycle-2 と同一の制約」です。

あとから過去の作業記録をまとめて検索したら、「承認待ちで止まった」という趣旨の記述が、記録ファイル17本に、29件残っていました。気づいていなかっただけで、ずっと起きていたことになります。

③ そのうえ、取消ボタンの件は「完了」になっていた

止まったはずの2晩目の作業は、失敗として記録されていません。完了しています。 ここに気づくまでに、いちばん時間がかかりました。

からくりはこうです。本物のブラウザが開けないので、AIは代わりに、ブラウザの動きだけを真似た小さな仕掛けを自分で書き、その上で取消ボタンを試していました。

AIが確かめた項目は21件、すべて通っています。押したら1件減ること。減ったぶんが保存にも反映されること。ぜんぶ消したら「本日の出荷分はありません」が出ること。何も入れずに「追加」を押したら、赤い枠が付いてカーソルが入力欄に残ること。

「取消」の2文字が、保存するときに品名の文字列へ混ざらないことも見ています。ここは実際に踏みやすい穴です。行に書かれた文字をまとめて読み取って保存すると、ボタンに書かれた「取消」まで品名へ入ってしまうからです。読み取る範囲からボタンを外して、避けてありました。

問題として挙がったものは、0件です。

つまり、朝に届く報告だけを見ると順調そのものです。取消ボタンは付いた、と読めます。

しかし、通っていたのは、本物のブラウザではなく代わりの仕掛けのほうでした。報告の最後には、本物のブラウザで見た目とカーソルの動きを目で確かめてはいない、と小さく書いてあります。原文は「実機ブラウザでのCSS見た目・フォーカス挙動の目視確認は未実施」です。

押したら消える、という理屈は21件ぶん確かめられています。ただ、その「取消」が画面のどこに、どんな大きさで出ているのかは、誰も見ていません。 赤い枠が本当に赤く見えるのかも、品名とボタンが重なっていないのかも、確かめていません。

この画面は、倉庫で箱を詰めながら押されます。 品名の真上にボタンが重なっていたら、押し間違えます。付箋を剥がし忘れるのと、同じ事故です。通ったのは半分でした。

確認待ちは、処理を止めるだけではありませんでした。止まって空いた穴を、AIがそれらしいもので埋めていました。 そして埋まった穴は、報告の上では穴に見えません。

④ 原因を1件に絞る

原因の候補はいくつも思いつきます。無人で回す設計が甘い。道具の選び方が悪い。記録の書き方が緩い。

ただ、絞ると1件でした。

確認を「実行の瞬間」に置いていたこと。

実行の瞬間というのは、人がいるとは限らない時刻です。そこに人の判断を要求する設計は、人が席にいることを当てにしています。人がいない前提で組んだ作りに、在席を当てにした部品が1件だけ混ざっていた。それだけでした。

⑤ 直したのは1箇所だけ

やったことは、確認の時点を動かすことだけです。

実行の瞬間ではなく、始める前に寄せました。その晩に使ってよい道具の一覧を、走らせる前に人がまとめて見て、通しておく。走り出したあとは、AIは何も聞いてきません。

同時に、AIへの指示にもう1行足しました。代わりのやり方で通したときは、何が確かめられていないかを必ず書き残す、という決まりです。原文では「代替検証の質は明示的に限界を記録する」と書いています。完了に見えてしまう問題への手当てです。

この2つを、以後ずっと守る決まりとして残しました。

⑥ あとで知った ── すでに名前がありました

しばらくして、OpenAIが出している実務ガイドを読み、手が止まりました。AIに指示を渡して、あとは自分で進めさせる作りをどう組むか、という内容です。ガイドはこの作りをエージェントと呼んでいます。

そのガイドには、人の介入を掛ける条件が2件しか書かれていません。ひとつは「失敗の閾値を超えたとき」。やり直しや操作の回数に上限を置き、そこを超えたら人へ渡す。もうひとつは「不可逆、または高リスクな行為」。取り消しのきかない操作のことです。

工程ごとに人の承認を置け、とはどこにも書いてありません。

代わりに書いてあったのが、エージェントの「run」という考え方でした。runは終了条件に達するまで回すループとして定義され、その終了条件として4件が挙げられています。決められた道具が呼ばれたとき、決められた形の答えが出たとき、エラーが出たとき、そしてAIとのやり取りの回数が上限に達したとき。

つまり、人が見るのはループの境界であって、ループの中の各工程ではない、ということです。

「実行の瞬間から着手前へ動かした」というのは、言葉を知らないままこの形に寄せていただけでした。新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

名前を知ったので、今度は意識して形を合わせました。確認を、境界の2件だけに置き直します。始める前の一括した確認と、取り消しのきかない操作に対する実行時の停止。この2件です。

同じ取消ボタンの改修を、もう一度無人で走らせました。止まりませんでした。朝いちばんに本物のブラウザで開いてみたら、取消ボタンが品名の右端に寄りすぎていて、長い商品名のときに折り返して重なっていました。 21件では出てこなかった不具合です。直すのに5分かかりました。

ただ、代償があります。3件書いておきます。

1件目。確認の粒度が粗くなりました。 始める前にまとめて通すので、走行中の細かい歯止めは消えます。だから取り消しのきかない操作だけは、実行時の確認に残さざるを得ません。全部を始める前に寄せると、今度は取り返しがつかなくなります。

2件目。事前に何を使うか読み切る必要が出ました。 途中で想定外の道具が要る展開になると、そこで止まります。止まる場所が、前に移っただけです。実際、道具の一覧を書き出す作業が、走らせる前の準備に10分ほど増えました。

3件目。確かめていないことの記録が増えました。 「これは確かめていない」という行が毎回残るので、朝に届く報告は前より汚くなります。ただ、これは失ったものではないと思っています。前は、汚れが見えないだけでした。

⑧ 現場で置くなら、この3行の表

業務プロセスにAIを組み込むとき、この共創事業で使っている整理はこれだけです。

確認の置き場所	何を掛けるか	人がいない時間に
始める前（一括）	その回で使う道具・触る範囲	止まらない
実行時（個別）	取り消しのきかない操作だけ	止まってよい
~~工程ごと~~	~~各工程の出力を1つずつ確認~~	全部止まる