STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

生成AIを用いたバックオフィス業務の効率化事例

こんにちは、STORES でデータアナリストをしているsueshigeです。

生成AIの発展に伴い、文章作成、画像生成、データ分析など様々な分野での活用事例が報告されています。 一方で、バックオフィス系の業務に関しては報告事例が少なく、生成AIの活用があまり進んでいないように見受けられます。 そこで、今回の記事では、バックオフィス業務のうち、STORES決済の入出金に関する突合作業に生成AIが活用できた事例について報告します。

入出金の突合作業

まず、STORES決済における入出金の突合作業が何かというところを説明します。入金と出金はお金の流れる向きが違うだけで、実質的に重なっている部分が多いので、以下では出金を対象として話を進めていきます。

STORES決済では決済端末を通して流通したお金を、STORES決済を契約している利用者(以下、ユーザ)の口座に振り込む業務プロセスがあります。 振り込むパターンとしては、ユーザからリクエストがあった場合、もしくは毎月自動で振込設定をしている場合の2パターンがありますが、どちらであっても、前回振り込んだ日付から振込依頼があった日付までの取引金額を集計し、ユーザの口座に振り込むという手順で振込が行われます。

お金を振り込むまでのプロセスを図1に示しました。図1では、ユーザのお店でお客さんが1000円と1500円のカード決済を行ったと仮定しています。このとき、1000円と1500円のそれぞれについてユーザの口座に振り込むわけではなく、振込日が来るまでSTORES側でお金を貯めておき、振込日に一括してそれまで貯めたお金(図1では2500円)を振り込むというプロセスになっています。

図1 STORES決済を使用した時のお金の流れ

この時振り込むは金額が多くても少なくても問題が生じるので、この手順においてエラーがないかを検証するのは内部統制上重要となります。 そこでSTORESでは、(i)前回振り込んだ日付から(ii)今回ユーザから振込依頼があった日付の期間における各ユーザの取引金額を取引明細を元に再集計し、その金額と実際に振り込んだ金額に差分がないかを検証する内部統制を構築しています。

具体的には以下の図の通りです。例として図1のような振込テーブルがあったとします。このとき、各ユーザIDについて、それぞれ取引明細と突き合わせて前回の出金依頼日の翌日から今回の出金依頼日までの期間の取引金額合計と振込金額の一致を検証します(図2はユーザID = AAAについての例)。

図2 出金データの例

図3 出金データと取引明細データの突合例

通常取引のみであれば振込金額と取引金額を集計した値は一致しますが、様々な理由でこのプロセスにおいては差分が生じます。例えば、ユーザのお店で取引したものが、後日返品・返金された場合には、返金される時期によって差分が生じ得ます。また、例えば図3のようにSTORESのシステムの不具合により、集計プロセスのバッチ処理が適切に走らず、取引明細のうち一部しか振込金額として集計されない場合にも差異が出てきます(ちなみにシステムエラーが生じた場合でも、漏れた金額は次の振込依頼日にまとめて振り込まれる仕様になっています)。

図4 ユーザID = AAAについて差異が生じる例

どのように生成AIを活用したか

エラーが生じた場合には、従来データチームと経理チームで個別に打ち合わせして、打ち合わせ内容に基づき手動で差分検証を行ってきました。どのような理由で差分が生じているか判明している場合には数時間程度で解決できますが、例えば前述のシステムの不具合による差分など、事前に想定されてない理由で差分が生じている場合には、差異原因を特定するまで1,2日かかることもありました。

突合プロセスにおける差異検証の中でやりたいこととしては、ユーザごとに様々な取引金額が大量にある中で、差異となっている金額に該当する取引候補を探すことです。この大量のデータから候補となる少数の取引を特定する、というプロセスに生成AIが使えるのではと考えました。 そこで、出金データと取引明細データのカラムの意味と、金額が一致する条件をプロンプトとして与え、生成AIに差分を調査してもらったところ、例えば上記の不一致例について以下の回答が得られ、差分対象の特定ができていることがわかります。

金額が合わないものは 1 件だけでした。
ユーザIDはAAAで期間は2025-07-02 ~ 2025-07-31
実際にその期間の取引明細を合計すると07/02 → 10 000 07/05 → 4 000 07/25 → 13 000で合計 = 10 000 + 4 000 + 13 000 = 27 000
ところが出金データには14 000しか入っておらず、
07/25 の取引分(13 000)がまるごと抜け落ちています。
つまり、前回の支払日の翌日から今回の支払日で絞った際に 07/25 のレコードを取りこぼして
しまうフィルタ条件(あるいは日付の境界処理)のバグが原因でユーザID AAAの振込金額が正しくありません。

何が嬉しいか

今回の例では3件の取引なので目件でチェックするのは簡単ですが、ユーザ数が多岐にのぼり、かつ取引数が数百となると、エラーの発生について事前の知見がないケースではなぜ差分が生じるのか特定することは困難です。今回のブログでは簡素化した例について適用しましたが、取引数が多くなる実例でも生成AIが差異の特定に役立っており、数ある取引の中からどの取引が漏れているかを金額の差分を基点として数分で洗い出すことができるようになりました。また、入金側についても同じロジックで差分検証を行うことができるので、大量データから差分になりうる少数のデータを見つける、というポイントにおいて、生成AIは広く活用できる可能性があります。

さらに、このようなプロセスをシステムとして組み込んでおくことで、経理はデータチームに相談しなくとも、生成AIに聞くだけで解決できます。これにより、金額が厳密に一致する定型作業だけでなく、エラー特定のような非定型な作業も、生成AIの力を借りることで自動化やシステム化の対象とすることができるようになります。

生成AIの使用例としてバックオフィス系の業務はあまり取り上げられないですが、今回の記事を通してこのような使い方もあるのだと思っていただけると幸いです。