17特 集変化の時代を生き抜くＦｉｎＴｅｃｈ活用46仕訳の日付、借方/貸方金額、摘要を生成する。支払いの場合には貸方勘定科目が、預かりの場合には借方勘定科目が当該の銀行口座となる（勘定科目が普通預金、補助科目がAA銀行BB支店など）。相手方の勘定科目については、摘要（「東京電力18/04利用分」など、もとは銀行明細上の取引内容）から推論する。 クレジットカードの利用明細もほぼ同様の処理であり、利用明細の利用日、利用額、利用内容から、仕訳の日付、借方/貸方金額、摘要を生成する。この場合、一般的に貸方勘定科目は未払金となる（勘定科目が未払金、補助科目がCCカードなど）。紙の証憑から取引データ化された場合は、取引日、取引額が仕訳の日付、借方/貸方金額となり、店舗名が摘要となる。 いずれの場合も、摘要を基に相手方の勘定科目の推論を行う。例えば、摘要が「東京電力18/04利用分」であれば水道光熱費と推論する。この推論処理は単なるキーワードマッチングではない。例えば、キーワードが「東京電力」、該当する勘定科目が水道光熱費であれば、東京電力は正しく水道光熱費と推論されるが、関西電力の推論結果は保証されない。そこで、キーワードの抽象度を上げ、キーワードを「電力」、該当する勘定科目を水道光熱費とすると、「電力中央研究所」というバス停名称が水道光熱費と推論されることになりかねない。そもそもキーワードマッチング方式の場合、キーワードのメンテナンス作業の負荷が大きく、継続的に、かつ正確に行うことは不可能ではないが、困難である。 このため、弥生では、単なるキーワードマッチングではなく、蓄積された仕訳データおよび推論対象となる摘要に対し、一定の統計的処理を行うことによって推論処理を行っている。推論処理は大きく三段階で構成される。まず、推論対象となる摘要を一定のロジックで文字列に分割する。次に分割された文字列それぞれに対し、蓄積された仕訳データにおける摘要と勘定科目の関係性に基づき、該当しうる勘定科目とその確率を計算する。最終的に、最も確率の高い勘定科目を選択する。 さらに、精度を向上させるために「全体推論」と「個人別推論」の二段構えで処理を行っている。あるユーザーが推論処理を行う際、当初はそのユーザー固有の蓄積データが存在しないため、まずは、ユーザー全体を母集団とした蓄積データを基に全体推論を行う。一方で、該当ユーザーの利用が進むことによって、該当ユーザー固有の蓄積データを基にした個人別推論が寄与するようになる。これに加えて、あくまでも補助ツールではあるが、推論を行わずにキーワードでマッチングさせる「仕訳ルール」も利用が可能である。 もっとも、仕訳データを自動生成するための推論処理はまだまだ発展途上であり、また、課題も多い。例えば同じ「Amazon」という摘要であっても、勘定科目は新聞図書費なのか、消耗品費なのか、雑費なのかは事業者によって異なる。さらに言えば、Amazonで販売している事業者にとっては、「Amazon」という摘要から勘定科目として売上高を導き出すべきケースも存在する。これらは、個人別推論が必要なケースであり、全体推論によって最初から正しく推論することは難しい。 全体推論と個人別推論の関係性で言えば、クレジットカードの利用明細は全体推論でカバーしやすいが、銀行明細は個人別推論が必要とされる傾向がある。これは、カードの利用内容（例えば「日経ID決済」）は事業者間での共通性が高いが、銀行振込での売掛金回収（「カ）ヘイセイショウジ」）は共通性が低い傾向があるためである。 また、推論処理での大きな課題は、自明なことではあるが、母集団が誤ると推論も誤るということである。特に推論学習の初期段階において、誤った推論結果を修正することなく受け入れてしまうユーザーが多いと、誤りが正しいものとして学習されてしまう。推論処理は100%正確な答えを保証するものではなく、誤りがあった場合にはそれを認識し、修正し、それによって推論にフィードバックが行われることが必須である。しかし現実的には、システムが提示する情報は正しいという思い込みが持たれがちであり、推論に対する正しいフィードバックが行われないことが往々にして発生している。会計データの高付加価値化５ 会計データは、仕訳の集合であり、事業者の経営状況を網羅的に表現する情報の宝庫と言える。一般的に事業者の経営状況を分析する場合には決算書が中心になるが、決算書というのは集約された、いわば抽象化
元のページ ../index.html#19