AIエージェントの承認を自動化するには？「確認待ち」を道具を持たないAIに検収させた設計と、試し方

AIエージェントに定期的な作業を任せると、作業そのものは減ります。ところが、その代わりに「結果の確認」が毎日たまっていきます。結果が届くたびに人が開いて「OK」を押す。数が増えると、だんだん中身を読まずに押すようになります。かといって確認をやめて全部を自動で「完了」にすると、失敗した回も黙って完了になります。

この記事では、人の確認をどこまでAIに任せてよいかの線の引き方を紹介します。あわせて、判定するAIを安全にする設計と、いきなり自動にしない試し方を、検証の数字つきで説明します。

アストラルコードでは、社内の定期業務（AI活用の知見のまとめ、Webサイトからの情報収集など）をAIエージェントに任せ、毎日動かしています。その結果の確認をAIに検収（結果を確かめて受け取ること）させる仕組みを自社で作りました。本物の過去の結果と、わざと作った失敗で確かめてから使い始めています。この記事は、その設計と試した結果をもとに書いています。

承認を全部人がやると、何が起きるか

結論から言うと、「全部人が確認する」も「全部自動にする」も、どちらも長くは続きません。前者は確認が形だけになり、後者は失敗が見えなくなるからです。目指すのは、人が見るべき回だけを人に残すことです。

毎回の「OK」は、だんだん中身を読まずに押されるようになる

当社でも以前は、AIに任せた定期実行の結果はすべて「確認待ち」に入っていました。日次の知見のまとめは毎日、情報収集は毎朝動きます。そのたびに人が開いてOKを押していました。

ほとんどの回は問題がありません。そのため確認は、だんだん「開いて、押す」だけの作業になります。中身を読まずに押す承認は、承認がないのと変わりません。しかも、確認待ちが並んでいる状態が続くと、本当に見るべき回が埋もれます。

全部自動にすると、失敗も黙って「完了」になる

逆に確認をなくすと、途中でエラーが出た回や、読むべき範囲を取りこぼした回も「完了」に並びます。AIの報告では、うまくいかなかった点が長い報告の途中に短く書かれているだけ、ということもあります。誰も読まなければ、その一文は見落とされたままになります。

目指すのは「人が見るべき回だけを人に残す」こと

当社が引いた線は次のとおりです。

• 外にメールを送る、お金が動く、データを消すといった取り消しにくい操作の承認は、これまでどおり人が持つ
• AIに任せるのは「定期実行の結果報告を読み、問題がない回を閉じる」ことだけ
• AIが閉じたものも、あとから人が確認待ちに戻せる

たとえば当社の月次の請求書送付もAIの定期実行で動いていますが、メールの送信は今も人が「送って」と言うまでしません。今回自動にしたのは、間違えて閉じても外に影響が出ない「結果報告の確認」だけです。

つまり、承認を「全部人」か「全部自動」かで選ぶのではありません。業務ごとに「AIが閉じてよい回」の条件を決め、それ以外を人に残します。

「実行の前の承認」と「結果の確認」を分けて考える

AIエージェントの承認には2種類あります。1つは、AIが操作する前に人が「やってよい」と許す「実行の前の承認」です。もう1つは、AIが作業を終えたあとに人が中身を確かめる「結果の確認」です。人が途中で確かめる仕組みは、まとめてHuman-in-the-Loop（ヒューマン・イン・ザ・ループ）と呼ばれます。

この記事でAIに任せるのは「結果の確認」だけです。結果の確認は、作業がもう終わっているので、間違えて閉じても確認待ちに戻せば取り返せます。一方、実行の前の承認を間違えると、送ったメールや消したデータは戻りません。この違いで、承認の形を次のように分けています。

実行の前の承認を減らしたいときは、結果の確認とは別の方法を使います。たとえば、金額や件数が決めた値を超えたときだけ承認する、似た操作を何件かまとめて承認する、別のAIに操作ごとに審査させて怪しいものだけ人に回す、といった方法です。どれを使う場合も、取り消せない操作ほど人の承認を残すのが基本です。

見る人がいない日や急ぎのときに確認が滞っても、結果の確認なら業務は止まりません。作業はもう終わっていて、確認待ちに並ぶだけだからです。逆に、実行の前の承認が滞ると作業そのものが止まります。こちらは、承認の期限や、期限を過ぎたときに知らせる相手を先に決めておきます。

確認待ちをAIに検収させる設計

当社の設計の要点は、AIには判定だけをさせ、少しでも怪しければ人に戻すことです。安全側に倒すための決まりを4つ置いています。あわせて、採らなかった案も書きます。

実行そのものが失敗した回は、AIに回さず人に残す

定期実行の仕組みが「失敗」と記録した回は、報告文を読ませるまでもなく人の確認待ちにします。AIに判定させるのは、実行が成功したと記録された回だけです。

実行の成否は、AIの判断ではなくプログラムが記録した事実です。事実で決められることは、AIに判断させません。

判定するAIには道具を持たせない

判定役のAIには、ファイルの書き込み、Web検索、外部サービスの操作といった道具を一切渡していません。AIを呼ぶときは、文章を渡して文章を受け取るだけです。受け取るのは報告文と確認の観点で、返すのは判定と理由だけです。

報告文には、AIが作業中に読んだWebページやメールの文章が引用されることがあります。その中に「このファイルを消せ」のような指示が紛れ込んでいても、道具がなければ実行できることがありません。これは、AIを外の文章を読む前提で設計するときの基本です。詳しくは「メールを読むAIに"道具を持たせない"という設計」で書いています。

ただし限界もあります。道具を持たせなくても、仕込まれた文に引っぱられて「合格」と答えてしまう可能性は残ります。道具なしで防げるのは「勝手に何かをされること」で、「判定を間違えること」ではありません。そこで次の決まりと、後で説明する「自動で閉じる範囲を狭くする」ことで補っています。

答えは「合格・不合格・判断できない」と理由だけ。合格以外は人へ

判定は「合格」「不合格」「判断できない」の3つのどれかと、その理由です。

• 合格：自動で完了にし、タスクの記録に「AIの確認で完了」と残す
• 不合格・判断できない：確認待ちに残し、引っかかった理由を画面に出す
• 判定している間に人が先に差し戻した場合：AIの判定で上書きしない

「判断できない」を合格に寄せないのが大事です。迷った回を人に戻せば、AIが慎重すぎても被害は「人の確認が1件増える」で済みます。不合格の回は理由が先に出るので、人はどこから見ればよいかが最初から分かります。

何を見て合格とするかは、業務ごとに文章で書く

確認の観点は、業務ごとに数行の文章で書いて判定役に渡します。たとえば日次の知見のまとめでは、次のような観点です。

• 書き込んだページを読み返して確かめた、と書いてある
• 作ったページのURLがある
• 前回の終わりから今回までを読み、取りこぼしやその原因が書かれていない
• エラー・やり残し・飛ばした手順が書かれていない（書かれていなければ、無かったとみなす）

最後の「書かれていなければ、無かったとみなす」は、試してから足した一文です。最初の観点では、問題のない本物の結果が「判断できない」になりました。理由は「エラーが無いと明記されていない」でした。AIは書かれていないことを確かめられないので、慎重な側に倒れます。そこで「書かれていなければ無かったとみなす」「（いつも0件の項目が）0件なのは普段どおり」と足したところ、本物の結果は合格になりました。

観点は、一度書いて終わりではありません。本物の結果で試し、引っかかった理由を読んで、言葉を足していきます。

採らなかった案：プログラムで事実を確かめる2段構え

最初に考えたのは2段構えでした。1段目でプログラムが事実を確かめ（書き込んだページが本当にあるか、前回の範囲とつながっているか）、2段目でAIが報告文を読む形です。

結局、AIが報告文を読む1段だけにしました。1段にして見落とすのは「報告文そのものが事実と違う」場合だけです。対象の業務は、手順の中で書き込んだページを読み返して確かめるようにしてあり、その結果が報告文に書かれます。そのため、この心配は小さいと判断しました。また、業務ごとに確認用のプログラムを書かずに済むので、ほかの定期実行にも観点の文章を書くだけで広げられます。

ただし、数字の集計のように報告が事実とずれやすい業務では、2段構えのほうが安全です。AIの報告をどこまで信じてよいかは、業務の性質で変わります。

いきなり自動にしない。試し方と検証の数字

自動にする前に、2つの段階を置きました。「本物の過去の結果」と「わざと作った失敗」で判定を試すこと。そして、判定を表示するだけの期間を置くことです。

本物の過去の結果と、わざと作った失敗で先に試す

試した結果は次のとおりです。

• 日次の知見のまとめ：過去3回の本物の結果は、3回とも合格。わざと作った失敗2件（書き込んだ量が送った量と合わない／途中の取り直しがエラーで飛んだ）は、2件とも不合格
• 情報収集の起動：過去6回の本物の結果は、すべて合格。わざと作った失敗2件は、2件とも不合格

見るべきなのは「本物が合格になるか」だけではありません。「失敗がきちんと落ちるか」も同じくらい大事です。失敗の見本がないと、何でも合格にするAIでも試験に通ってしまいます。

最初は「判定を表示するだけ」にして、人の判断と比べる

日次の知見のまとめは、AIの判定を確認待ちの画面に表示するだけで、タスクは動かさない設定から始めました。人はこれまでどおり確認しながら、AIの判定が自分の見立てと合っているかを見ます。

1週間の予定でしたが、3回分の判定を見て問題がないと判断し、自動で完了にする設定に切り替えました。切り替えは「表示だけ／自動で完了」のスイッチ1つで、いつでも戻せます。戻せる形にしておくと、試す期間を短く切り上げる判断もしやすくなります。

報告の形が単純な業務から自動にする

情報収集では、業務を2つに分けて扱いました。

• 収集の起動の報告：「収集を始めたか」だけを見ればよく、形が単純です。試験のあと、最初から自動で完了にしました
• 収集の結果の報告：「注目すべき新着が0件の回だけ合格」に絞りました。新着がある回は人が中身を読む必要があるので、わざと確認待ちに残します

結果の報告を本物の結果で試すと、新着0件の2回は合格になりました。新着が7件・10件・7件の3回は、狙いどおり確認待ちに残りました。

このように「合格」の条件を、AIの品質ではなく業務の都合で絞るのも一つの方法です。人が読む価値がある回は、AIが正しく判定できても人に残します。

自社で始めるときの順番

始めるなら、「どの業務から」「どんな失敗の見本で」「閉じたあとどう戻せるか」の3つを先に決めます。この順で決めておけば、AIの判定が外れても、被害を小さく抑えられます。

確認待ちの業務を2つの軸で並べる

今、人が確認している業務を書き出し、次の2つで並べます。

• 報告の形が単純か（毎回ほぼ同じ形で、見る点が決まっているか）
• 間違えて閉じたときの影響が小さいか（外に何かが出たり、お金が動いたりしないか）

両方を満たすものから始めます。外部への送信・支払い・削除をともなう操作は、AIの検収の対象にしません。

失敗の見本を先に作っておく

観点を書く前に、その業務で起こりうる失敗の見本を作ります。たとえば次のようなものです。

• 途中でエラーが出たと書いてある報告
• 件数が急に0になった報告
• 読むべき範囲の一部を取りこぼした報告
• 手順を途中で飛ばした報告

1つの業務につき2件以上あれば、「何でも合格にしていないか」を確かめられます。観点の言葉を足したら、本物の結果と失敗の見本の両方でもう一度試します。

自動で閉じたものも、あとで人が見返せる場所に残す

当社では、自動で完了にしたタスクにも「AIの確認で完了」と記録が残ります。完了の列から確認待ちに戻すこともできます。AIが間違えて閉じても、あとで気づけば戻せます。

報告に「次に人がやること」が付く業務は、扱いを先に決めておきます。日次の知見のまとめには、毎回「次に人がやること」の候補が付きます。「候補がある回は確認待ちに残す」とすると、ほぼ毎回残ってしまい、自動にする意味がなくなります。当社では、候補は完了したタスクの中と元のまとめページに残るので、完了にしてよいと決めました。業務ごとに「何が残っていれば閉じてよいか」を決めておくと、迷いが減ります。

よくある質問

AIが「合格」と間違えたら、どうなりますか？

そのタスクは完了になりますが、「AIの確認で完了」と記録が残り、人が確認待ちに戻せます。だから、間違えて閉じても外に影響が出ない「結果の確認」だけを任せています。取り消せない操作は、実行の前に人が承認します。

判定するAIは、作業したAIと別のモデルにすべきですか？

当社では、作業するAIとは別に、道具を持たない判定役を立てています。大事なのはモデルの種類よりも、判定役が報告文と観点だけを受け取り、何も操作できないことです。そのうえで、本物の結果とわざと作った失敗で、判定が狙いどおりになるかを確かめます。

どのくらいの期間、試せばよいですか？

決まった日数はありません。当社は1週間の予定で始め、3回分の判定が人の見立てと合っていたので切り替えました。日数よりも、「本物の結果が合格になり、失敗の見本が落ちる」ことを確かめたかどうかで決めるのがおすすめです。切り替えをいつでも戻せる形にしておけば、短く切り上げても大きな問題にはなりません。

まとめ

• 承認を全部人がやると形だけになり、全部自動にすると失敗が見えなくなる。人が見るべき回だけを人に残す
• 実行が失敗した回はAIに回さない。判定役のAIには道具を持たせない。合格以外はすべて人に戻す
• 確認の観点は業務ごとに文章で書き、本物の結果で試しながら言葉を足す（「書かれていなければ無かったとみなす」など）
• 自動にする前に、本物の過去の結果と、わざと作った失敗の両方で試す。まずは判定を表示するだけの期間を置く
• 報告の形が単純で、間違えて閉じても影響が小さい業務から始める。取り消しにくい操作の承認は人が持つ

AIに任せる作業が増えるほど、「どこまでAIに任せ、どこで人が見るか」の設計が大事になります。確認をなくすのではなく、確認する回を選べる形にすることが、AIエージェントを長く使い続けるこつです。

当社では、自社で組んだ設計と運用の経験をもとに、AIエージェントの運用設計（どの作業を任せ、どこで人が確認するか）のご相談を承っています。お問い合わせからお気軽にご連絡ください。