はじめに

税理士事務所の日常業務のひとつに、「領収書の山をJDL(会計ソフト)の仕訳データに変換する」という作業があります。スキャンした領収書PDFを1枚ずつ開き、日付・金額・勘定科目・摘要を確認して入力していく。地味ですが、毎月確実に発生する作業です。

この作業を、Claude API(Anthropic社のAIモデル)を使って自動化するツールを、自分で設計・開発しました。名前は「JDL記帳自動化ツール」。この記事では、開発の背景と、税理士業務にAIを組み込む際に一番悩んだポイントについて書きます。

なぜ「自分で作る」ことにしたか

世の中にはOCR付きの経理ソフトやクラウド会計サービスがすでにあります。それでも自作を選んだ理由は、既存ツールの多くが「読み取りから判断まで全部AI(またはOCR)にやらせる」設計になっており、税理士業務で求められる正確性の水準に届かないと感じたからです。

領収書の読み取りには、ある程度の「揺れ」がどうしても発生します。手書きの文字、感熱紙の劣化、レイアウトの違い。AIによる読み取りは非常に強力ですが、100%ではありません。問題は、その「揺れ」を、どの工程で・どう扱うかです。

設計の一番の軸:「AIは読み取りだけ、判断はローカル」

JDL記帳自動化ツールを設計するうえで、最初に決めたルールがひとつあります。

AIにやらせるのは「読み取り(転記)」だけ。勘定科目の判定・税区分の判定・金額の確定といった「判断」は、すべてローカルのルール表とマスタデータで行う。

たとえるなら、AIは「領収書の文字を読み上げてくれるアシスタント」であって、「経理判断をする人」ではない、という役割分担です。読み上げた内容をどう仕訳に落とし込むかは、事務所側で管理するルールが決める。

なぜこの分離にこだわったかというと、AIの判断ロジックはブラックボックスになりがちで、「なぜこの勘定科目になったのか」を後から説明しづらいからです。税務の仕事は、後で説明できることが重要です。読み取りと判断を分離しておけば、判断部分は自分で書いたコードなので、いつでも中身を追跡できます。

つまずいたポイント:「似たような領収書」の扱い

開発の途中で、地味に厄介だった問題があります。同じ日に同じ取引先から、似た内容の領収書が複数枚出てくるケースです。最初は「重複していそうなものは自動で1件にまとめる」処理を入れていたのですが、これはすぐにやめました。

理由は、静かに合体・削除される仕訳が、後から見て「本当に重複だったのか、実は別の取引だったのか」を人間が判断できなくなるからです。そこで方針を変え、自動で削除・統合はせず、「これは重複の可能性があります」という印(バッジ)を付けて、人間が最終確認する方式に変更しました。

AIやプログラムに「よかれと思って」判断を肩代わりさせすぎると、かえって後工程での検証が難しくなる。この経験は、他の業務効率化を考えるときにも役立つ教訓になりました。

後編について

ここまでが無料公開部分です。後編では、このツールを開発する中で実際に直面した「API費用の問題」と、それを約62%削減できた具体的な工夫(プロンプトキャッシュという技術の使い方)について、実装レベルの話を書きます。AIツールを自分の業務に組み込みたいと考えている税理士・士業の方に向けた、実践的な内容にする予定です。

(後編は有料記事として近日公開予定です)