AIエージェント初回導入の事例｜請求書処理を現場で試して見えた課題

会計業務に使うAIの仕組みを、初めて現地で導入しました。手順とコードは事前に用意し、当日はCodexのセットアップと使い方の説明から始めました。その後、過去の10月分の資料を通して試運転しました。

そこで見つかったのは、AIの操作方法よりも、請求書の一件と会計ソフトの一件が必ずしも一致しないという業務上の問題でした。準備段階で想定した資料だけでは、処理の条件を決めきれなかったのです。

この記事は、初回導入と試運転で分かったことの記録です。本番業務での削減時間や処理精度は、まだ測定していません。

請求書1枚を、そのまま会計上の一件にはできなかった

今回扱った自動車関連の請求書には、月をまたぐ取引の記録が1枚にまとまっているものがありました。その月の処理には不要な記録も含まれています。会計ソフトのfreeeでは1レコードずつ扱う一方、手元の資料には複数のレコードが一緒に載っていました。

資料によっては、それぞれのレコードを分ける必要があります。別の資料では、合算して扱う場合もあります。文字と金額を読み取るだけなら処理できても、freeeのどの記録に対応させるかは決まりません。ここに人の業務判断が入ります。

従来のプログラムで資料ごとの条件を書き分ける方法もあります。ただ、形式や扱い方が顧問先ごとに違うため、私はこうした個別対応を諦めていた部分がありました。今回は資料の扱いをAIに教え、現地で実データを通しながら、分けるか合算するかの判定をその場で調整できました。試した範囲では改善が見られ、これまで手を付けにくかった業務にも効率化の可能性を感じました。

ただし、本番業務で使い続けた場合の精度や、作業時間がどれだけ減るかは、これから確かめる段階です。試運転で動いたからといって、導入効果を数字で語るには早いと思います。

導入前の仕様だけでは、資料の癖を拾いきれない

これまで私が作ってきたシステムでは、仕様を決め、想定どおりに動くことを確かめてから納品する進め方が中心でした。今回は実際の資料を通して初めて、新しい条件が見つかりました。

人が作る請求書には、取引先や業種ごとの癖があります。事前のヒアリングは欠かせませんが、そこで全ての例外を挙げてもらうのは難しい。何を処理対象にし、何を除き、どの記録へ対応させるか。現場の人と実物を見て確認し、仕組みに反映する必要があります。

この作業では、AIに判断を任せる範囲も決めなければなりません。資料から読み取れる条件はAIへ渡せます。一方、記録の扱いが曖昧な場合や、金額に影響する判断は、担当者に確認できる流れを残したいと考えています。判断をAIに渡すには、まず業務としての正解を人が説明できることが前提です。

AIエージェント導入後も、運用を決める仕事が残る

今回の試運転では、資料のルールを追加して判定を調整できました。別の資料を通せば、また違う例外が見つかるかもしれません。導入後も、誤った結果に誰が気づき、誰が正しい扱いを決め、誰が仕組みへ反映するかを決めておく必要があります。

精度を評価するなら、処理した件数だけでなく、担当者が確認・修正した件数や時間も見たいところです。自動化されたように見えても、後で人が全件を直しているなら業務は軽くなっていません。今回はまだ、その効果を測るだけの運用実績はありません。

運用が始まれば、使っているライブラリやランタイムの更新、脆弱性への対応も必要になります。利用する人からは見えにくい仕事だからこそ、何を保守の対象とし、どのように知らせるかを説明したいです。今回、脆弱性を検知・修正したという意味ではありません。

画一的なSaaSは、多くの利用者に共通する仕事を支えます。今回、私が現地で行ったような資料ごとの最終調整は、個別の現場へ入るからこそできる仕事でした。SaaSの開発に長く関わってきた私には、その違いが印象に残っています。

AI導入を考えるなら、普段の資料を一緒に試したい

AIエージェントを業務へ入れる前に、見栄えのよいデモだけで判断せず、普段使っている資料をいくつか通してみてください。今回なら、複数の記録が載った請求書や、月をまたぐ資料が欠かせませんでした。

そのうえで、結果が違ったときに誰が正解を判断できるか、修正を誰へ伝えるかを決める。導入を一度の納品で終えるより、実際の仕事で試しながら調整する進め方が、このような業務には合うと感じています。

AIエージェントの基本的な仕組みや、人が判断を残す場面については、AIエージェントとは何かでも説明しています。