AIエージェントの提案を人が承認し、月100時間を取り戻す業務改革

朝の八時、青葉商事の経理部でプリンターが動き始めた。白い請求書が一枚ずつ吐き出され、由衣の机には確認待ちの書類が静かに重なっていった。赤い付箋は、昨日より少し多かった。

由衣は請求書の会社名、金額、振込先を画面へ写した。次に、勘定科目を選び、担当部署の共有フォルダーへ保存する。経費申請が届くと、領収書の添付を確かめ、規程に合っているかを見て、申請者の上司へ回した。

「この交通費は、会議費ではなく旅費交通費です」

由衣は申請画面の小さな選択欄を開いた。似た名前の科目が並び、前月の処理記録を別の画面で探す。ひとつの分類を終えるまでに、何度も画面を行き来した。

午前の半ば、仕入先から電話が入った。先月届いた請求書に、振込先の変更が書かれていたという。由衣は書類の束をめくったが、その一枚は「確認中」の箱の下に隠れていた。

「変更の登録は、まだでしょうか。今日の支払いに間に合いますか」

電話を切った由衣の手が止まった。過去の登録情報には古い口座が残っていた。別の担当者が変更内容に気づいていたため大事にはならなかったが、支払い処理は止まり、仕入先への返事も遅れた。

「すみません。私が先に見つけていれば……」

隣の席の真紀が、赤い付箋を一枚はがした。責める声ではなかったが、由衣の胸はきゅっと縮んだ。目の前には、まだ確認すべき請求書が残っている。

昼前には、別の申請も差し戻された。領収書の画像が添付されていないのに、由衣が見落として担当部署へ回していたのだ。申請者から「どこを直せばよいですか」と聞かれ、由衣は画面を見ながら説明文を作った。

「不備を見つけるだけでなく、直す場所まで伝えられたらいいのにね」

真紀の言葉に、由衣はうなずいた。単純な転記と分類に時間を使うほど、振込先の変更や規程外の申請のような判断が必要な案件は後ろへ流れていく。大切な確認ほど、夕方の静かな机に残っていた。

午後、部長が経理部の小さな会議室へ三人を集めた。机の中央には、青い画面を映したノートパソコンが置かれている。そこには、書類から読み取った情報や、確認が必要な箇所が並んでいた。

「生成AIに、支払いを決めてもらう話ではありません」

部長は画面を指で示した。AIエージェントは、書類の情報を抜き出し、勘定科目の候補を出し、社内規程に照らして気になる点を知らせる。何段階かの作業を進められるが、最後に決めるのは人だという。

「RAGという仕組みも使います。社内規程や過去の記録をAIが探し、根拠を添えて提案する仕組みです。答えを丸ごと任せるのではなく、理由と違いを人が確かめます」

由衣は、振込先変更の書類を思い出した。もし古い登録情報との差を先に知らせてくれたら、電話が来る前に確認できたかもしれない。けれど、便利そうだからという理由だけで、いきなり現場へ置く気にはなれなかった。

「まず、今の状態を残しましょう」

由衣は新しい表を開いた。請求書一件にかかる時間、差し戻しの回数、入力後の修正、確認漏れ、担当者が感じる負担を書き込む欄を作った。処理が終わった時刻だけでなく、途中でどの画面を探したかも、できる範囲で記録することにした。

AIに任せる候補は、情報の抽出、勘定科目の分類、二重申請や規程外の申請の検知、差し戻し文の下書き、担当者への通知に絞った。支払いの確定と社外への送信は、最初から人の承認が必要だと決めた。承認欄には、提案の根拠と、前の記録との差分を表示することになった。

夕方、由衣は最後の集計欄に今日の数字を入力した。赤い付箋はまだ机の端に残っている。青い画面は、まだ本番の仕事を動かしていない。

「導入した後に、何が変わったか比べられるようにしておきます」

由衣が保存ボタンを押すと、表の一行目に今日の日付が入った。便利さを先に追いかけるのではなく、今どこで時間が消えているのかを確かめるところから、青葉商事の業務改革は始まった。

朝八時半、青葉商事の経理部では、試験運用中の画面が静かに開いていた。由衣たちは、届いた請求書を読み込ませ、内容ごとに担当部署へ振り分ける作業を試していた。画面には、取引先名、金額、請求内容、担当部署が整然と並んでいた。

「読み取りは、ずいぶん早くなりましたね」

佐伯さんが画面を指でなぞった。AIは請求書の文字を拾い、支払い処理の下書きまで作っていた。人が一枚ずつ転記しなくても、下書きができれば、確認に時間を使えるはずだった。

そのとき、一枚の請求書が青い枠で囲まれた。取引先は、長く付き合いのある文具会社だった。金額も請求内容も、いつもの月と大きく変わらない。

AIの判定欄には、「通常案件」と表示されていた。

「これなら、そのまま担当部署へ回せそうです」

佐伯さんは、次の画面へ進むボタンに手を伸ばした。由衣も一度うなずきかけた。けれど、請求書の下に小さく書かれた一行が、ふと目に入った。

「振込先が変更されています」

由衣は、机の横に積んであった過去の請求書を取り出した。先月までの振込先と、今回の振込先を並べる。会社名は同じだったが、口座番号が違っていた。

「待ってください。この変更、確認が必要です」

部屋の空気が止まった。佐伯さんの指も、ボタンの上で止まった。もしそのまま処理を進めていたら、支払い先を誤る可能性があった。

「AIは、振込先の変更に気づかなかったのでしょうか」

「たぶん、気づかなかったというより、そこを確認する役目が決まっていなかったのです」

部長が後ろから画面をのぞき込んだ。AIの画面には、読み取った項目が並んでいる。けれど、「なぜ通常案件と判断したのか」という理由は見えなかった。

「判定の理由が分からないと、私たちは何を見ればいいのか迷います」

由衣が言うと、部長はゆっくりうなずいた。

「AIエージェントは、書類を読むだけの道具ではありません。情報を集めて、次に何をするかを考え、処理の準備まで進めます。だから便利ですが、走り出す前に、人が止める場所を決めておく必要があります」

部長は、画面の「承認待ち」という表示を指した。そこにはAIの提案と、人が押す承認ボタンが同じ場所に並んでいた。見た目だけなら、提案ではなく、もう確定した処理のようにも見えた。

「私たちは、誰がAIの提案を見るのかを決めていませんでした」

由衣は画面を見つめた。

「何を確認したら承認できるのかも、振込先が変わったら誰へ差し戻すのかも、決めていません。それに、承認前に送金処理へ進まないよう、どの操作を止めるのかも曖昧でした」

佐伯さんは、先ほどのボタンから手を離した。

「画面に出ているから、誰かが見ていると思っていました」

その言葉が、由衣の胸に残った。人が確認するはずの仕事が、誰の担当でもない場所に置かれていた。AIの誤りだけを責めても、同じことはまた起きる。

部長は、印刷した請求書の裏に四つの線を引いた。

「まず、AIに提案させる。次に、人が内容と理由を確認する。その人が承認する。最後に、別の仕組みが実行する。この順番を分けましょう」

「RAGも、確認に使えますか」

由衣が尋ねた。部長は、やさしく言い換えた。

「RAGは、社内規程や過去の記録を探して、AIの提案のそばに置く仕組みです。AIが思いつきだけで答えるのではなく、『この規程と、この過去の処理をもとに提案しています』と示せるようにします」

由衣は、振込先の違いを示す二枚の請求書を見比べた。必要なのは、AIにすべてを任せることではない。AIが見つけたものと、人が確かめたものを、同じ場所で混ぜないことだった。

「提案の欄、確認の欄、承認の欄、実行の欄を分けましょう。振込先の変更や規程外の申請は、承認できない状態にして、担当者へ差し戻します」

言葉にすると、画面の形が少しずつ見えてきた。通常案件なら、AIが項目を読み取り、理由を添えて担当部署へ送る。例外なら、赤い印を付け、必要な資料や確認先を示す。人は、その内容を見てから次へ進める。

由衣は、空白のまま残っていた手順書を引き寄せた。そこに、最初の線を引く。

「小さな範囲から、作り直してみます」

部長がうなずいた。止まった請求書は、すぐには支払われなかった。けれどその朝、青葉商事には、AIを働かせるために人が決めるべき仕事が、はっきり見え始めていた。

三原は朝一番、会議室のホワイトボードに青い付箋を並べた。由衣が机の上の請求書を抱えて入ると、白い壁に業務の流れが少しずつ見えてきた。

「今日は、AIに任せる仕事と、人が承認する仕事を分けます」

三原は、最初の付箋に「書類や申請の受付」と書いた。共有メールに届いた請求書や、経費申請システムから送られた領収書を、SharePointの受付フォルダーへ集める流れである。次の付箋には「AIによる情報抽出」と書き、AI Builderが日付、取引先、金額、税額、勘定科目、添付の有無を読み取る絵を描いた。

「読み取るだけなら、AIは速そうですね。でも、判断まで任せるのですか？」

「判断の材料をそろえるところまでです。AIエージェントは、答えを返すだけではありません。順番を考え、必要な画面を開き、下書きまで進められます。ただし、最後の決定は人が持ちます」

三原は三枚目に「分類と自動チェック」と書いた。SharePointに保存した社内規程や過去の処理記録を検索し、その文章を根拠にして提案するのがRAGである。難しい言葉を、三原は「社内の本棚から関係するページを探し、そのページを見ながら案を作る仕組みです」と言い換えた。

その下には、「異常や不足情報の検知」「下書きと担当者の自動割り当て」と続いた。Power Automateが受付をきっかけに処理を動かし、AIが不足している領収書や二重申請の可能性を示す。問題がなければ担当部署を選び、経費申請の下書きを作ってMicrosoft Teamsへ知らせる。

「ここで止めます」

由衣が青い付箋を一枚、太い線の下へ移した。そこには「人による確認」とある。三原はPower Automateの承認画面に、AIが見つけた取引先名や金額だけでなく、参照した規程のリンク、判断の理由、注意点、元の書類との差分を表示する設計を見せた。勘定科目がAIの案から修正されたときは、修正前と修正後が並ぶ。

「提案とは、結論を押しつけることではありません。確認に必要な材料を、同じ画面にそろえて見せることです」

ホワイトボードの次の列には、「承認または差し戻し」と書かれた。承認者は内容を確かめてから承認し、添付漏れがあれば不足している書類を指定して差し戻す。申請者には、Microsoft Teamsの通知で「領収書の宛名を追加してください」と具体的に伝わるようにした。

由衣は、付箋の端に赤い丸をつけた。振込先の変更、規程外の申請、情報不足、重要顧客に関する処理は、AIが問題なしと表示しても、必ず人へ引き継ぐ決まりにした。さらに、少しでも判断に迷うときは、担当者を飛ばさず、経理部の確認箱へ送る。

三原は最後の列に、「システムへの登録・通知・進捗追跡」「操作履歴の保存」と書いた。承認後にだけ会計システムへ登録し、関係部署へ通知する。誰がいつ何を見て、どの案を修正し、どの理由で承認したかは、Power Automateの履歴に残す。

「AIに送信や削除の権限を渡したら、間違いがそのまま外へ出ます」

三原はホワイトボードの隅に、権限を階段のように描いた。下から「読み取り」「下書き」「変更」「送信・削除」と並べ、上へ行くほど慎重にする。最初の試験では、AIに許すのは読み取りと下書きだけで、変更、送信、削除は人の操作に限定した。

午後、二人は実際の請求書で小さな試験を始めた。由衣が共有メールに届いたPDFを受付フォルダーへ移すと、AI Builderが情報を読み取り、Power Automateが承認案を作った。ところが、同じ請求書が二つの下書きとして表示された。

「フォルダーへ移したあと、ファイル名を直したので、もう一度処理が始まったようです」

三原は慌てず、処理の条件を確認した。請求書番号、取引先名、金額を組み合わせた照合キーを作り、同じキーが登録済みなら新しい下書きを作らないようにした。さらに、受付済み、確認中、承認済みという状態をSharePointに記録し、状態が変わったときだけ次の処理へ進むように直した。

再試行すると、今度は一件だけが表示された。別の申請では、古い社内規程を根拠にした注意が出たため、由衣は参照元のリンクを開いた。三原は古い版を検索対象から外し、現行版に更新日と適用範囲を付けた。

「根拠が見えるから、間違いを見つけられました。見えないまま自動化するより、ずっと安心です」

最後に、由衣は評価表を作った。処理時間だけでなく、AI提案の採用率、修正した量、エラー率、差し戻しの回数を記録し、確認する人が感じた心理的な負担も短いメモで残す。三原は、導入直後に表れる下書きの速さと、しばらく運用してから見える誤りの減少や確認のしやすさを、別々に確かめることにした。

青い付箋の列には、まだ空白が残っていた。けれど、AIが提案し、人が理由を確かめ、承認してから次へ進む道筋は、もう白い壁の上にまっすぐ伸びていた。

経費申請だけに絞った試験運用が始まり、由衣の机から赤い付箋の山が少しずつ消えていった。代わりに、画面には元の申請とAIの下書きが並び、確認すべき場所だけが静かに光っていた。

「最初は、請求書ではなく経費申請からにしましょう」

三原がそう決めたのは、申請の形が似ていて、判断する範囲を決めやすかったからだ。由衣たちは過去の対応履歴、社内規程、よくある質問、差し戻しになった理由を一つの知識の棚に整理した。

「RAGは、必要な規程や記録を探して、AIの下書きのそばに置く仕組みです。AIが思いつきだけで判断しないようにします」

由衣は、古い規程を棚から外し、改定日を確認した。三原は、同じ領収書が別の申請に添付されていないか、過去の記録と照らす手順を加えた。準備が終わると、青い箱の中に新しい申請が届いた。

AIは申請書から、社員名、部署、費目、添付書類、申請理由を拾った。規程に合っているか、同じ内容の申請がないか、必要な添付が抜けていないかも調べた。いつもの申請と違うときは、その理由とともに「確認が必要」と表示した。

下書きの横には、参照した規程の場所と判断理由が出た。金額を読み取った根拠や、重複の可能性を見つけた記録も開けるようになっていた。

「理由が見えると、確かめる順番がわかりますね」

由衣は元の申請を左に、AIの下書きを右に置いた。下書きに誤りがなければ承認する。直したいところがあれば修正する。足りない書類があれば差し戻す。迷う案件は「人へ引き継ぐ」に送る。画面の下部には、その三つの操作だけが置かれていた。

承認されるまでは、会計システムへの確定登録も、申請者への通知も動かない。AIは担当部署を割り当て、進み具合を更新するが、最後の扉を開ける鍵は由衣の手元に残った。この流れは、AIが情報の抽出や不備の検知を担い、人が最終判断をする経費精算の例とも重なっていた。グロービスキャリアノートで紹介されていた考え方を、青葉商事の小さな仕事に置き換えた形だった。

けれど、初日の午後、画面の光が急に増えた。同じ会社名の表記が少し違う。部署名に空白がある。領収書のファイル名が、前の申請と似ている。AIはそれらをすべて異常として拾い、確認待ちの箱をふくらませた。

「これでは、赤い付箋が画面の中に移っただけです」

由衣が苦笑すると、三原も小さくうなずいた。AIは間違いを見つけようとしていたが、すぐに人の手を止めるほどではない違いまで、同じ強さで知らせていた。

二人は警告を二つに分けた。規程違反の可能性や重複の疑いは、目立つ警告にする。表記ゆれや確認だけで済むものは、申請のそばに小さく表示する。部署名の空白は自動でそろえるが、費目の変更は人の確認を待つことにした。

「AIに静かにしてもらうのではなく、知らせ方を整えるんですね」

「そうです。大事なものまで、細かな音に埋もれないようにします」

修正のたびに、AIの判断を変えた履歴を残した。差し戻しの理由、承認した人、処理した日時も記録した。あとで見返せば、なぜその申請が進み、どこで人の判断が入ったのかがわかる。由衣は、記録が増えるほど、次の見直しがやさしくなることに気づいた。

数日が過ぎると、由衣の画面に並ぶのは、書類を一枚ずつ開くための印ではなく、判断を待つ短い列になった。例外案件だけが経理へ届き、通常の申請は理由を確かめてから、落ち着いて承認できるようになった。以前なら夕方まで残っていた添付漏れの確認も、申請が来た流れの中で見つかるようになった。

夕方の経理部には、紙の擦れる音の代わりに、キーボードを打つ小さな音が続いていた。由衣は赤い付箋を一枚手に取り、机の端から青い箱へ移した。

「なくなったわけではないけれど、貼る場所が変わりましたね」

三原は、承認済みの記録と引き継ぎ中の案件を見比べた。画面の中には、AIが進めた仕事と、人が確かめた仕事の境目が残っていた。小さな範囲でつまずきを直せたことで、二人は次に扱う業務の候補を、静かな声で話し始めた。

導入から三か月が過ぎた朝、由衣たちは会議室に集まり、中間評価を始めた。大きなモニターには、導入前の記録と、三か月分の運用ログが左右に並んでいた。

処理時間、AI提案の採用率、修正量、エラー率、差戻し件数、承認待ち時間。項目ごとのグラフが、青と灰色の線になって画面を走っている。由衣は、数字の動きだけでなく、その数字がどんな仕事から生まれたのかを一つずつ確かめた。

「処理件数が増えたことだけでは、成功とは言えませんね」

部長が椅子を少し前へ引いた。

「AIの提案をそのまま採用した割合と、人が直した量も見ましょう。必要なところで、ちゃんと立ち止まれているかが大切です」

由衣は、採用率の下にある小さな表を開いた。そこには、提案がそのまま承認されたもの、勘定科目だけを直したもの、添付書類の確認を人へ引き継いだものが分かれて表示されていた。修正量は、申請全体ではなく、どの項目を何度直したかまで記録されている。

「この修正理由は、あとから追えます。前は、誰がなぜ直したのか、メールを探さないと分かりませんでした」

「記録が残ると、次に直す場所も見えますね」

部長はそう言って、エラー率のグラフに目を移した。エラー率が下がっていても、担当者がAIの提案を信用できなければ、青い箱は使われなくなる。由衣は、先週行った現場への聞き取り結果を開いた。

経理の佐伯は、画面を見ながら話したという。

「前より確認は早いです。ただ、理由が短いときは、もう一度書類を開きます。何を根拠にした提案なのかが分かると、安心して承認できます」

営業部の田辺からは、別の声が届いていた。

「差し戻しの箇所が具体的になりました。直す場所が一つずつ出るので、申請を最初からやり直さずに済みます」

由衣は、その言葉を聞き取り表に残した。RAGで社内規程や過去の記録を参照していても、提案の理由が人に伝わらなければ、協働にはならない。難しい言葉を減らし、参照した規程の名前を表示する小さな改修も、次の候補に加わった。

次に、由衣は異常検知の一覧を二つに分けた。一つは、振込先の変更や二重申請の疑いを早く見つけ、承認前に確認できた案件だった。もう一つは、領収書の画像が読みにくいものや、規程に似た例が見つからず、AIが判断せずに人へ引き継いだ案件だった。

「人に渡った案件は、失敗ではありません」

部長の声は静かだった。

「判断できないときに止まり、理由を残して渡せたなら、それも設計どおりです。大事なのは、例外がどこで滞ったかを見つけることです」

由衣は参考資料をめくった。popbitsのバックオフィスAI化では、対応工数を半減した事例が紹介されている。ただし、その数字は青葉商事の成果ではない。由衣は資料の端に、自社の導入前記録と運用ログだけを使って確かめる、と書き添えた。

会議の最後に、次の改善項目が画面に残った。異常検知の条件を見直すこと、承認者の割り当てを整理すること、ログを確認する曜日と担当を決めること。部長が保存ボタンを押すと、項目は「承認待ち」の青い箱へ移った。

その日の夕方、由衣の机の上には赤い付箋が一枚だけあった。そこには、読みにくい領収書を確認する担当者の名前が、丁寧な字で書かれていた。

翌朝、プリンターから出てきた紙は少なかった。由衣は紙を手に取る前に、画面の青い箱を開いた。提案の理由と、前に誰かが残した修正の記録が並んでいる。

「今日は、考える時間から始められそうです」

窓から入った光が、承認待ちの画面をやわらかく照らしていた。由衣は一件を開き、急がずに確認の印をつけた。

夕方の経理部では、プリンターの音よりも、画面をめくる小さな音が響いていた。机の上に書類の山はない。AIエージェントが整理した案件が、承認待ちの一覧に静かに並んでいる。

由衣は一番上の申請を開いた。画面には、AIが作った下書き、参照した社内規程、注意点、過去の処理との差分が順に表示されていた。金額の写し間違いがないか、勘定科目の理由が合っているか、添付された領収書が申請内容と結びついているかを、由衣は一つずつ目で追った。

「参照元が見えると、どこを確かめればいいか分かりやすいね」

隣の席で、後輩の真希が画面をのぞいた。由衣は、社内規程や過去の記録を探して提案に使うRAGについて、短く説明した。難しい仕組みも、ここでは根拠をたどるための小さな道しるべになっていた。

問題のない申請では、由衣は内容を確認して承認ボタンを押した。画面の表示が「承認済み」に変わり、誰が、いつ、どの項目を見たのかが記録に残る。紙に赤い付箋を貼る代わりに、確認した理由が次の人にも読める形で残っていく。

「これは、領収書が一枚足りないね」

由衣は申請を差し戻し、理由の欄に「交通費の明細を添付してください」と入力した。するとAIが差し戻しの内容を整理し、申請者へ通知する準備を始めた。以前なら、由衣がメールを書き、担当者を探し、返事を待っていた仕事だった。

別の請求書には、前回と違う振込先が表示されていた。AIは差分を黄色く示し、過去の登録情報と新しい請求書を並べている。由衣は承認せず、担当部署への引き継ぎを選んだ。

「振込先の変更は、担当の確認をお願いしよう」

引き継がれた案件は、一覧の中で担当者と期限に結びついた。対応が止まると、AIが担当者へ知らせる。由衣の受信箱にも通知が届くが、急かすような文面ではなく、「確認待ちの案件があります」と、次に見る場所をそっと示していた。

月末のレビューでは、画面に残った記録を部長と真希が見返した。AIの提案は適切だったか、差し戻しの理由は伝わったか、例外の処理に時間がかかっていないかを確かめる。承認した案件だけでなく、修正した箇所や、承認しなかった理由も同じログに並んでいた。

「人が最後に見るからこそ、何を見るかも残しておきたいね」

由衣はそう言って、「要確認」と表示された案件を開いた。元の請求書には小さな手書きの変更があり、AIの下書きにはその部分が反映されていなかった。由衣は提案を修正し、注意点に「手書き変更のため原本確認」と残した。

AIは仕事を持っていったのではなかった。書類を探し、同じ内容を写し、返事を待つ時間を整えて、人が判断する場所を画面の上に見えるようにしていた。由衣の机には、確認が必要な案件と、誰かへ渡すべき案件だけが残っている。

窓の外が薄紫色に変わるころ、最後の申請に承認印がついた。由衣は隣の席の担当者へ顔を向けた。

「この案件は確認をお願い」