「どこまで自動化するか」は業務の単位では決まらない
AIエージェントの導入を検討すると、この業務は任せられるか、という形で話が始まります。この問いには答えが出ません。ひとつの業務の中には、毎回同じ手順で終わる部分と、担当者が過去の例を思い出しながら決めている部分と、間違えると取引先や社外に影響が出る部分が混ざっているためです。業務ごと任せるか任せないかで決めると、任せた側では危ない工程まで含まれ、任せなかった側では機械で済む工程まで人が抱えます。
判断できる単位は工程です。業務を工程に割ってから、ひとつずつ置き場所を決めます。ここで扱うのは、どの工程を誰が持つかという線引きです。既製ツールを契約するか自分たちで組むかという話は AIエージェントは既製ツールか自作か で扱っており、軸が違います。何で作るかを決める前に、そもそも何を作るのかがこの仕分けで決まります。
置き場所は3つ
工程の行き先は3つです。どれが優れているという順位はなく、工程の性質で決まります。
| 置き場所 | どういう工程が入るか | 扱い方 |
|---|---|---|
| 通常のプログラム | 判断が入らず、同じ入力なら毎回同じ結果になる工程 | 条件を書き切って組む。費用が小さく、処理の記録が残り、書いたとおりにしか動かない |
| AIエージェント | 判断は入るが、過去の判断例が十分にあり、間違えたときの損失が小さい工程 | 任せたうえで出力を毎回測る。測る仕組みごと作る |
| 人の承認 | 損失が大きい工程、または過去の材料が足りない工程 | 人が確定させる。AIは判断材料を揃えるところまでを担う |
3つのうち、検討で抜けやすいのは1つ目です。AIの導入という枠で話し始めると、条件分岐を書けば済む工程まで生成AIに投げる構成になりがちです。取引先名の表記ゆれを対応表で吸収する、金額の合計が一致するかを確かめる、期限までの日数を数える。こうした工程は、条件を書けばそのとおりに動き、費用も動作の説明もつきます。同じ処理をAIに投げると、動くことは動きますが、なぜその結果になったかを毎回確かめる必要が出ます。
3つ目の「人の承認」も、AIを外す判断ではありません。人が確定させると決めた工程でも、必要な資料を集める、社内規程の該当箇所を引く、過去の似た案件を並べる、といった準備はAIが担えます。人が持つのは最後に決める部分だけで、そこへ至るまでの作業は移せます。
仕分けの物差しは4つ
工程ごとに次の4つを見ます。順に答えていくと、置き場所が決まります。
| 物差し | 何を確かめるか | 答えが示す置き場所 |
|---|---|---|
| 判断が入るか | 入力が決まれば出力も一意に決まるか。担当者の頭の中で条件を照らし合わせる場面があるか | 決まるなら通常のプログラム |
| 過去の判断例の量 | 同じ判断を過去に何件行い、その入力と結果が取り出せる形で残っているか | 少なければ人の承認 |
| 間違えたときの損失 | 誤りが社内で止まるか、社外・金銭・個人の権利に届くか。気づくまでに何日かかるか | 社外や金銭に及ぶなら人の承認 |
| やり直しがきくか | 取り消しの操作があるか。取り消しても相手側に記録が残らないか | 戻せないなら人の承認 |
判断が入るか
最初に見るのはここです。同じ入力を10人の担当者に渡して、10人とも同じ結果を出すなら、判断は入っていません。手順書に書いてある、あるいは書けるということです。この工程はプログラムで組みます。
迷うのは、手順書には書けるが例外が多い工程です。目安は、例外を条件として書き出したときに数え上げられるかどうかです。20行の分岐で書けるなら書きます。書き出そうとして条件が際限なく増えるなら、それは判断が入っている工程で、次の物差しへ進みます。
過去の判断例がどれだけあるか
AIに任せる工程では、過去の判断が見本になります。見本が無ければ、任せた結果が正しいかどうかを確かめる手段もありません。確かめられない工程は、任せた瞬間に誰も見ていない工程になります。
確かめるのは件数だけではありません。入力と、そのときの結論と、迷った場合の理由が組で取り出せるかを見ます。結論だけが残っていて、なぜそう決めたかが人の記憶にしかない工程は、材料が足りない側です。この場合はまず人が処理を続けながら記録を残し、材料がたまってから移します。何をどれだけ集めるかは AIエージェントの精度をどう評価するか で扱っています。
間違えたときに誰がどれだけ困るか
損失の大きさは金額だけでは測れません。見るのは3点です。誤りがどこまで届くか(社内で止まるか、社外の相手に渡るか)、誰が困るか(自部門か、他部門か、取引先か、個人か)、気づくまでに何日かかるかです。
社内で止まり、その日のうちに気づける誤りは、影響が小さい部類です。社外へ出てしまう工程や、金銭が動く工程は、正しさの割合がどれだけ高くても人が確定させます。1000件のうち999件が正しくても、残り1件が支払として出ていけば、取り戻す作業は999件分の削減を上回ります。
やり直しがきくか
同じ誤りでも、取り消せるかどうかで扱いが変わります。社内の管理表への書き込みは直せます。送信したメール、実行した振込、外部サービスへ登録した情報は、取り消しの操作があっても相手側に記録が残ります。
戻せない工程は、正しさの割合ではなく、戻せないという性質で人の承認に置きます。逆に、下書きの作成、分類、参考情報の付与のように、次の工程で人が見る前提の出力は、間違えても捨てて作り直せます。AIに任せる範囲を広げやすいのはこちら側です。
性質の違う業務に当てはめる
同じ物差しでも、業務によって効く場所が変わります。3つの業務で見ます。
| 業務 | 通常のプログラム | AIエージェント | 人の承認 |
|---|---|---|---|
| 支払の処理 | 金額の合計の照合、支払期日の計算、登録番号の形式の確認 | 書類からの項目の読み取り、勘定科目の候補の提示、過去の同じ取引先の処理との突き合わせ | 支払の実行、初めての取引先の登録、金額が想定と食い違う件の扱い |
| 契約書の確認 | 自社ひな形との文字単位の差分の抽出、更新期限の計算と通知 | 差分のうち注意すべき条項の絞り込み、過去の類似条項での対応の提示 | 修正を求めるかどうかの判断、相手方へ返す文面の確定 |
| 社内からの問い合わせ | 担当部署への振り分け、申請書式の案内、受付の記録 | 社内文書を根拠にした回答の下書き、質問の分類、過去の同じ質問の提示 | 権限や例外の付与、規程の解釈が分かれる質問への回答 |
支払の処理では、照合と計算が大きな割合を占めます。数を合わせる作業に判断は入らないため、プログラムで組めます。AIが効くのは、書式がばらばらの書類から項目を取り出す部分です。人が残るのは、お金が外へ出る一点です。
契約書の確認は、差分の抽出そのものは機械的な処理です。判断が入るのは、その差分を受け入れるかどうかで、ここは相手との関係や取引の規模で変わります。過去の判断例は残っていることが多い一方、1件あたりの損失が大きいため、人が確定させます。
社内からの問い合わせは、件数が多く、1件あたりの損失が小さい業務です。回答を間違えても社内で止まり、その場で訂正できます。この性質から、AIに任せる範囲を広く取れます。ただし権限を与える判断だけは、取り消しても与えた事実が残るため、人が持ちます。
3つを並べると、業務の性質が違っても、人が残るのは同じ形の工程だと分かります。お金が外へ出る、相手に渡る、権限が変わる、この3つです。
全部をAIに寄せた場合と、全部を人に寄せた場合
仕分けを飛ばすと、どちらかの側へ倒れます。両方とも同じ回数だけ見かけます。
全部をAIに寄せると、承認が形だけになります。人の承認は残っているのに、担当者は毎日200件の下書きを前にして、内容を見ずに通すようになります。この状態は承認率で見つかります。差し戻しがひと月ゼロ件で、1件あたりの確認時間が数秒なら、その承認は判断として機能していません。件数を減らすか、確認する項目を絞るか、そもそも人が見る必要のない工程だったのかを決め直します。
全部を人に寄せると、件数で詰まります。慎重に見えますが、承認を待つ列が伸び、処理そのものより待ち時間が長くなります。この状態は、1件が到着してから完了するまでの時間で見つかります。作業時間の合計が10分の案件が完了まで3日かかっているなら、詰まっているのは作業ではなく待ちです。待ち時間の測り方は 業務のリードタイムが縮まらない理由 で扱っています。
| 倒れ方 | 現れる形 | 何を見れば気づけるか |
|---|---|---|
| AIへ寄りすぎ | 承認が通過の作業になり、誤りが下流で見つかる | 差し戻しの件数、1件あたりの確認時間、誤りが見つかった工程の位置 |
| 人へ寄りすぎ | 承認待ちの列が伸び、処理の速さが担当者の在席で決まる | 到着から完了までの時間、承認待ちの滞留件数、承認者ひとりが持つ件数 |
どちらも、仕分けの表を作った時点では起きません。運用を始めてしばらく経ってから出ます。そのため、上の欄の数字は最初から取れるようにしておきます。
仕分けを書き残し、条件が変わったら動かす
仕分けの結果は、工程ごとに1行の表として残します。並べるのは、工程名、4つの物差しの答え、置き場所、そう判定した理由です。理由の欄が要るのは、あとで見直すときに何が変われば動かせるかを判断するためです。
置き場所は固定ではありません。次の2つの向きで動きます。
- 人の承認からAIへ動かす … 過去の判断例が足りずに人へ置いた工程は、記録がたまれば移せます。移す条件は件数で書きます。何件たまったら評価用のデータを作り、どの水準を満たしたら任せるか、を先に決めます
- AIから人の承認へ戻す … 任せた工程で、下流での修正が増えた、あるいは業務ルールが変わって過去例が当てにならなくなった場合は戻します。戻す判定の数値も先に決めておきます
書き残した仕分けは、そのまま次の工程の入力になります。どの工程を誰が持つかが決まると、AIが決めてよい範囲、人が確定させる単位、差し戻しの経路を仕様として書けます。項目の埋め方は AIエージェントの要件定義の書き方、その前後を含めた進め方は AIエージェント開発の進め方 を参照してください。
見直す時期も決めておきます。四半期ごと、あるいは業務ルールの改定に合わせると、都合のよい区切りになります。時期を決めていないと、最初の仕分けがそのまま数年残り、記録がたまっているのに人が処理し続ける工程と、条件が変わったのに任せたままの工程が同時に生まれます。
まとめ:工程を3つの置き場所へ仕分ける
- 「この業務を任せられるか」では答えが出ない。ひとつの業務の中に性質の違う工程が混ざっているため、工程の単位で決める
- 置き場所は3つ。判断が入らない工程は通常のプログラム、過去例が足りて損失が小さい工程はAIエージェント、損失が大きい工程と材料が足りない工程は人の承認に置く
- 条件分岐で書ける工程までAIに投げない。プログラムで組めば費用が小さく、同じ入力なら同じ結果になり、動作の説明もつく
- 物差しは、判断が入るか、過去の判断例がどれだけあるか、間違えたときに誰がどれだけ困るか、やり直しがきくかの4つ。1つでも人へ寄る答えが出たら人の承認に置く
- 人が残るのは、業務が違っても同じ形の工程になる。お金が外へ出る、相手に渡る、権限が変わる、の3つ
- 全部をAIに寄せると承認が形だけになり、全部を人に寄せると承認待ちで詰まる。差し戻しの件数と、到着から完了までの時間を最初から測る
- 仕分けは工程名・4つの答え・置き場所・理由の表で残し、記録がたまったらAIへ、修正が増えたら人へ動かす
Augueでは、業務の工程を洗い出して置き場所を決めるところから、AIエージェントの構築と社内で運用できる形への引き継ぎまで支援しております。どの工程を人が持つべきかを一緒に整理したい方は、是非ご相談ください。
関連する記事
- AIエージェント開発の進め方|対象業務の選び方と4工程の全体像、次へ進む前に決めること
- AIエージェントの要件定義の書き方|項目ごとの記入例と、設計レビューで見る観点
- AIエージェントの精度をどう評価するか|合格ラインの決め方と、本番に出す前の確認手順
よくある質問
仕分けは誰が集まって決めるべきですか?
対象業務の責任者、実際に手を動かしている担当者、承認の権限を持つ人の3者で決めます。責任者は例外の頻度を、担当者は手順のどこで迷うかを、承認者は自分が何を見て通しているかを知っています。特に承認者が抜けると、人に残すと決めた工程で実際には何が確認されているのかが分からないまま仕様に進み、あとから承認の画面を作り直すことになります。
すでにRPAなどで自動化している工程は、どう扱えばよいですか?
動いているなら、そのまま通常のプログラムに分類された工程として扱います。作り直す必要はありません。見直すのは、対象の書式や画面が変わるたびに止まっていて、修理の頻度が月に何度も発生している場合です。止まる原因が入力のばらつきの吸収にあるなら、その工程だけをAI側へ寄せ、後続の登録処理は既存のまま残す形が取れます。
開発を外部に依頼する場合、仕分けは自社とベンダーのどちらが行いますか?
判断の材料は自社にしかないため、仕分けの原案は自社で作ります。過去に何件処理したか、間違いが起きたときに誰が困るか、やり直せるかは、社外からは調べられません。ベンダーが担うのは、その原案を実現方式に落とす部分です。仕分けをまるごと任せると、実現しやすい形に寄った線引きになり、承認の負担が現場へ残ります。
件数が少ない業務でも、この仕分けは必要ですか?
必要ですが、力の入れ方は変わります。年に数十件の業務なら、AIに任せて出力を測り続けるための手間のほうが、処理そのものより大きくなることがあります。その場合は仕分けの結論として、当面は人が処理すると書き残す形で構いません。仕分けの価値は自動化の範囲を広げることではなく、どこを人が持つかを決めた根拠を残すことにあります。
