こんにちは。
LayerXのバクラク事業部 機械学習チームのテックリードを務めております機械学習エンジニアの島越（@nt_4o54）です。
最近、カジュアル面談や学会などで「AI-OCRってもうほぼ完成で、運用フェーズですよね」「やることあるんですか？」など頻繁に聞かれることがあります。
「いやいや課題が山のようにあるんです」という話をいつもしているので、今回は我々が作っているAI-OCRがどれだけ複雑で難しい問題を扱っているか、という部分についてお話しさせていただければなと思います。
少し、経理ドメインの話が多く恐縮ですが、お付き合いいただけると嬉しいです。
AI-OCRについて
まず、そもそも弊社のバクラクで提供しているAI-OCRについてご存知じゃない方も多いと思うので説明させてください。
バクラクシリーズは、請求書処理や経費精算、稟議申請、法人カードなどのお客様の支出管理業務を効率化するプロダクト群です。
2024年7月現在では、以下のような6つのプロダクトが存在しています。(バクラク申請とバクラク経費精算を分けてカウントしています)
これらのプロダクトの中で、仕訳作業、書類管理などの経理業務に必要な項目を抽出するために、AI-OCR機能というものを提供しています。 例えば、バクラク請求書受取の場合は「取引先名」「支払い期日」「支払い金額」「銀行口座」などの値を書類から抽出しています。
AI-OCR機能については、過去の学会やイベントでの資料で紹介しているので、気になる方はそちらもご参照ください。
AI-OCRが扱う問題の複雑さ
上記で説明したようにAI-OCR機能は、バクラクの様々な場所で使用されています。
以下に簡単に整理しましたが、プロダクトによって扱われる帳票の種類、必要な項目、そしてその使われ方も異なります。
(この表以外にも実際は適格請求書判定を行うために、適格請求書発行事業者番号なども読み取っていますが、今回の話とはずれるので割愛しています。)
このようにプロダクトが増えるにつれて、扱う帳票の種類が増え、その使われ方も様々になり、当初想定していたよりも様々な課題が出てきています。
今回は、そのうちのいくつかを紹介させてください。
| プロダクト名 | 主に扱う帳票 | 帳票から抽出する項目 |
|---|---|---|
| バクラク請求書受取 | 請求書 | 取引先・支払い期日・支払い金額・振込先口座 |
| バクラク経費精算 | 領収書 | 支払い先・支払い金額・日付 |
| バクラク申請 | 契約書・請求書・ECサイトの購入画面など | 取引先(契約先)・支払い期日・支払い金額など申請による |
| バクラク電子帳簿保存 | 電子取引に関わるあらゆる書類 | 電子帳簿保存法の検索要件に必要な項目 (取引先・取引日・取引金額) |
ドメインへの深い理解が必要
例えば、会社員の方であれば馴染みのある経費精算プロダクトについて考えてみます。
領収書における支払い先とはなんでしょうか？
単純に考えれば、タクシー会社の名前や飲食店の名前などが支払い先になると考えられます。
では、飲食店が何かしらの運営会社によって運営されており、運営会社も領収書に記載されている場合はどうでしょうか？
Amazonで商品を購入した際の領収書の場合は、Amazonに出荷している元会社が支払い先になるのでしょうか、それともAmazonが支払い先になるのでしょうか。
このように一つの取引には、実はさまざまな関係者が存在しており、どの会社名や店名を実際に抽出するのか、という問題は、そのプロダクトで抽出する値がどのように使われるのか、お客様はどういう理由でその値を入力しているのか、などドメインへの深い理解やデータに対する注意深い観察が必要です。
LayerXでは、ドメインエキスパートが所属しており、気軽に質問できる環境が整っています。それらを活用することでAI-OCRとしてプロダクトに対して必要な値とはなんなのか、というのを日々探究しています。
ちなみに今回例で挙げた経費精算の取引先名の場合は、経理業務的には仕入税額控除のために必要な値になります。国税庁の説明では、以下のように書かれており、基本的に法人名が書かれているなら法人名だが、屋号名でも問題はないというようになっています。こうなるとお客様の運用次第で屋号か法人名のどちらを入力するのかが曖昧になったりするので、それを踏まえた上での機械学習モデル開発が必要になります。
帳簿の記載事項として法定されているのは、課税仕入れの相手方の「氏名又は名称」ですから、例えば、個人事業者であれば「田中一郎」と、また、法人であれば「株式会社鈴木商店」と記載することが原則です。 ただし、課税仕入れの相手方について正式な氏名又は名称及びそれらの略称が記載されている取引先名簿等が備え付けられていること等により課税仕入れの相手方が特定できる場合には、例えば「田中」、「鈴木商店」のような記載であっても差し支えありません。 また、飲食店であれば「日比谷食堂」、フランチャイズのコンビニエンスストアであれば「ABチェーン霞が関店」のように屋号等による記載でも、電話番号が明らかであること等により課税仕入れの相手方が特定できる場合には、正式な氏名又は名称の記載でなくても差し支えありません。
上記以外にも、よくある難しい例として以下のような請求書のパターンがあります。
この請求書は、先月に株式会社バクラクに対して請求した218,000円のうち180,000円のみ支払われており、今月分に100,000円繰越されているという請求書になります。
このような繰越金額が記入されている請求書を見たとき、請求書受取プロダクトの支払い金額としてはどの金額を抽出するのが正解でしょうか？パッとみただけだと左上に記載されているご請求金額の318,000円を取るのが正解のように思えます。
しかし、経理業務としては前の月の取引から続いているので、前回の請求金額である218,000円は既に仕訳が切られている状態です。その場合は今回請求金額(税込)の218,000円のみを抽出するのが正解になります。
ただ、今回は繰越金額が0円ではない場合を紹介しましたが、繰越金額が0円の場合はどうでしょうか？
その場合は、ご請求金額に書かれている金額も値としては正解になります。しかし、同じフォーマットに対して繰越金額の有無でアノテーションする位置がぶれてしまうと、ラベルノイズになってしまいます。そのため、繰越金額の有無などに左右されないようなラベルの付け方が必要になります。
同じ書類であってもコンテキストによって抽出したい値が異なる
少し幅広い言葉で、「コンテキスト」と使ってしまっているのですが、ここでは以下のようなものをコンテキストとして定義しています。
- 帳票の受領側か送付側か
- 利用されるプロダクト
- お客様の運用方法
では、これらのコンテキストによって、どのような問題が発生するのでしょうか？
まず、一つ目の「書類の受領側か送付側か」についての例です。元々、バクラクでは請求書受取のプロダクトしかなかったため、請求書を受け取る側という前提のAI-OCR機能になっていました。しかし、バクラク電子帳簿保存などのプロダクトができたことにより、自社で発行した書類をプロダクトにアップロードされるようになりました。そのため、同じ請求書でも請求書を発行した側なのであれば送付先が取引先名になり、受領した側なら発行元が取引先名になります。
次に二つ目の「どのプロダクトでの利用なのか」によって求める値が変わる例です。
例えば、バクラク電子帳簿保存では、電子帳簿保存法の検索要件に必要な項目を抽出することが必要で、その中に取引日というものがあります。また、バクラク経費精算などでも日付を入力する必要があります。
前者の電子帳簿保存法の場合は、国税庁が指定する検索要件を満たす必要があります。取引年月日については、電子帳簿保存法取扱通達解説（趣旨説明）の4-39項などに記載があり、請求書であれば請求日、領収書であれば領収日など、書類種別に応じた取引の日付を抽出することが必要になります。
また、経費精算の場合の日付は、最終的には仕訳を行う際に帳簿に記載する日付になります。この場合、基本的に発生主義という考え方によって日付が記載されるので、サービスの提供が完了した段階の日付が必要になります。
例えば、1ヶ月後の出張のホテルを自分のクレジットカードなどで予約した際は、領収書には領収日としてクレジットカードで支払った日付などが記入される場合があります。しかし、実際にサービスを受けるのは1ヶ月後なので、ホテルに宿泊した際のチェックアウトした日付がサービスの提供が完了した日付になります。なので、バクラク電子帳簿保存では書類単体で見た時の領収日が欲しいが、経費精算観点では、チェックアウト日が欲しいといったことが発生します。
最後に三つ目の「お客様がどういう運用なのか」によって求める値が変わる例です。
先ほど領収書の取引先名や電子帳簿保存における取引日などの例を紹介しましたが、このような値はある程度国税庁から基準が示されているとはいえ、解釈の余地が残されています。
前述したホテルの経費精算の例でもチェックアウト日を取引日として扱うお客様もいらっしゃいます。
そのため、お客様が運用によってルールを定めることで、会社の中では一貫性を持たせることがあります。そうなると、異なる会社で異なるルールが適用された場合に、同じ書類でも抽出する場所が異なる、といった問題が発生します。
ここまで説明したような話以外にも、税抜経理方式または税込経理方式のどちらの運用で仕訳を切るかによって、抽出したい金額が税抜き金額なのか、税込金額なのか、というのが変化したりするので、お客様の運用に合わせて欲しい値を調整して提供していくことが、本当にお客様の課題を解決するために必要になります。
このようにコンテキストによって同じ書類に対して解釈が変わる例がバクラクでは多く存在します。このような問題を機械学習的に解こうとした際に、コンテキストによって別々の場所にラベルをつけてしまうと、機械学習モデルが混乱する要因になることが容易に想像できると思います。このような問題を解くためには、単純に取引先のラベルをつけるだけでは難しく、機械学習としての問題の解き方を再定義してデータセットを構築していく必要があります。
まとめ
ここまで、バクラクのAI-OCRで扱っているデータが、ドメイン的にもデータ的にもいかに複雑なのか、ということについて紹介させていただきました。 今回紹介させていただいたもの以外にも、請求書だけを扱っていた時だけとは比べ物にならないほど問題が複雑化しているなと感じています。 このブログを読んでくださった方も経理ドメインって大変だな、、と敬遠する方がいらっしゃるかもしれませんが、逆にここまで複雑なものを紐解いて自動化していくことはとても大きな価値につながると私は考えています。
最後に
機械学習チームでは、AI-OCRを本当に良いものにしていくために、ドメインにDeep Diveしていき、「機械学習としてはどう解くべきか」、「ユーザのデータをどう貯めていくべきか」、「アノテーションはどうしていくべきか」、など多角的な視点を持って「お客様が欲しい値を提供する」方法を日々見つめ直しています。そのための基盤作りや分析などの重要性も上がってきており、まだまだ人が足りていません。分析やモニタリングの課題については、7月から機械学習チームのリーダーとして取り組んでくださる深澤が以下の記事でも触れてくれています。
複雑な課題、データに対して一緒に機械学習による課題解決していくことに少しでも興味が湧いた方、まずはカジュアルにでもお話しさせてください！
機械学習エンジニアやMLOpsエンジニア、ソフトウェアエンジニア、インターン生など多方面で積極採用中です！
