仕訳をAIに任せようとしたら、8割はAIが不要だった

銀行口座やクレジットカードの明細を会計ソフトに取り込むと、まだ仕訳になっていない明細が並びます。仕訳とは、ひとつの取引を借方と貸方に分け、それぞれの勘定科目（取引の内容に付ける分類のラベル）を決めて帳簿に記録することです。毎月の顔ぶれはほとんど同じで、一件ごとの判断もほとんど変わりません。それでも一件ずつ選んで登録する以上、件数のぶんだけ時間は必ず掛かります。

この作業をAIに任せたい気持ちがあっても、会計データは間違えると決算や申告に響きます。試しに動かして壊すわけにいきません。結論から言えば、仕訳登録は「全部AIに任せる」形にはしませんでした。過去の実績だけで答えが確定する明細だけを自動登録し、判断が混じるものは人に戻します。自社の会計データでこの線引きを決めた記録がこの記事です。土台にしたのはマネーフォワード クラウド会計の外部連携機能で、会計ソフトの外側から仕訳を登録できることはベンダーが公式に案内しています[1]。

摘要の8割は、過去の実績だけで答えが決まっていました

取り込んだ明細には摘要が付きます。摘要は取引の内容を示す短い文字列で、銀行やカード会社が付けた店名や振込先の名義が入ります。過去の仕訳帳を摘要ごとに集計すると、分布は極端に偏っていました。明細件数の8割超が上位のごく一部の摘要に集中し、残りの摘要がそれぞれ件数の少ない長い裾を作ります。同じ摘要には、同じ勘定科目と同じ税区分が繰り返し使われていました。

この偏りが設計方針を決めました。件数の8割を占める部分は、摘要の一致でほぼ答えが決まるので、毎月AIに考えさせる価値はありません。実際、この8割の明細の大半は、後述する自動登録の条件を満たしました。AIが要るのは残りの裾、つまり前例の乏しい取引だけです。先に必要だったのは、AIに判断させる工夫ではなく、AIが判断しなくていい領域を切り出すことでした。

確信度に応じて、処理を4段階に分けます

全件を人の確認に回すと、過去の実績だけで決まる明細にも手間がかかります。反対に全件を自動登録すると、判断が必要な明細まで確実なものと同じ処理に入ります。そこで、勘定科目を過去の実績だけで一意に決められるかどうかを基準に、明細を4段階に分けました。

判定	処理	条件
確定	自動登録	自動登録の3条件をすべて満たす
高確度	人が承認	表記を揃える処理で一致した
判断が必要	社内で判断	前例が乏しく、税務の判断は要らない
専門判断	税理士に確認	税区分が揺れている、仕訳先が内訳で変わる

確信度が下がるにつれて、処理が自動から人へ寄っていきます。税理士に回す取引は、総額が明細から分かっても、明細だけでは勘定科目や税区分を決められません。

自動登録するのは、3条件をすべて満たす明細だけです

• 完全一致：摘要が過去のものと文字どおり同じ
• 実績の厚み：同じ摘要での登録が繰り返し積まれている
• 税区分の収束：その摘要の税区分が一つに定まっている

どれか一つ欠けても推測が混ざります。税区分は消費税の扱いを示す分類で、同じ相手への支払いでも用途で変わるため、揺れている摘要は自動登録から外しました。カード会社が書く店名は同じ相手でも時期によって変わるので、表記を揃える処理での一致は推測を含みます。実績が積まれた時点で自動登録に上げます。なお、勘定科目そのものの収束は条件に入れていません。集計上、同じ摘要には同じ勘定科目が繰り返し使われていたためで、この前提が崩れる摘要が現れたときは条件の見直しが要ります。

登録の経路は会計ソフトの外部連携機能です[2]。一部は公開仕様だけでは判断できなかったため、実際の挙動を確認しています。調べ方と権限まわりの切り分けは ドキュメントに載っていないAPIの仕様は、どう調べるのか に記載しています。

誤登録は未処理に戻せないので、基準は保守側に倒します

自動化では、2種類の誤りを同じ重さで扱わない方がよい場合があります。このケースでは、登録すべき明細を保留するより、誤った仕訳を確定するほうが修正の負担が大きくなります。見送った明細は人がレポートで承認するだけで済みます。一方、誤って登録した仕訳は、削除しても元の明細が未処理には戻らず「対象外」になります（公式仕様[2]）。実機検証では、この明細への外部連携からの再登録は拒否され、是正は画面での手作業になりました。

そのため既定は「迷ったら登録しない」に置きました。条件を厳しくすると人が見る明細は増えますが、増えるのは安いほうの手間です。取り消せない操作を含む処理の組み立て方と、そこにAIの判断をどこまで入れてよいかの線引きは 取り消せない操作を含む処理は、どう自動化するのか に記載しています。

人が一度した判断は、翌月からルールとして使います

人が一度判断しても、記録しなければ翌月に同じ質問が戻ってきます。そこで判断の結果を追記式の台帳に残し、次回以降の判定に使います。各項目には、システムが提案しただけの状態と人が承認した状態があり、判定に効くのは承認されたものだけです。決めた日付と、科目を選んだ理由も併せて書きます。訂正や削除の履歴が残る仕組みは、国税庁が「優良な電子帳簿」の要件の一つに挙げています[3]（この台帳自体がその制度の対象という意味ではなく、履歴を残す設計の参考としての引用です）。

材料にする過去の仕訳は、厚いほど一致する明細が増えます。ただし複数年度のデータを使うと、一致が増えると同時に、古い記帳ルールまで復活する問題が起きました。記帳の方針は年度をまたいで変わるので、直近の年度に出現しない摘要は材料から外し、一致の厳密さより実績の新しさを優先しています。

なお、過去の帳簿をルール作成に使う前に、元データの確認も必要でした。過去の誤記帳をそのままルール化すると、誤りまで自動化されるためです。実際に見つかった欠陥は 経理を自動化しようとすると、なぜ先に帳簿の誤りが出てくるのか に記載しています。

残ったのは、毎回相手が変わる取引と税理士に聞く取引だけでした

手作業が残ること自体は失敗ではなく、残るべきものが残った状態です。人が毎月確認するのは、自社の口座間の振替のように過去の摘要だけでは仕訳先が決まらない取引と、税務判断が必要な取引です。摘要の分布から見て明細の大半は自動または半自動で処理できますが、今回の検証では、区分ごとの正確な比率までは測定していません。

仕訳登録の自動化で重要だったのは、AIにどこまで判断させるかではありませんでした。過去の実績だけで答えが決まる領域と、判断が必要な領域を分けること。そして誤りの修正の重さが釣り合わないときは、自動化の基準を保守側に置くことでした。TARVOでは、こうした設計と実装を受託で承っています。詳しくは AI受託開発 をご覧ください。