「Bill One」は生成AIを使わない Sansanがあえて時流の逆を行く理由（3/4 ページ）

[斎藤健二，ITmedia]

精度を支える「人単位」のデータ設計

　例えば、通販サイトを運営するアスクルから届く請求書には、店舗で購入した備品が並ぶ。ペン代は消耗品費、お茶代は会議費。さらにお茶代でも、営業部門が使ったのか、事務部門が使ったのかで按分が必要になる。こうした判断を、担当者は請求書の明細を見ながら一つずつ行っている。Bill Oneはこの判断をAIで自動化するために、独自のデータ設計を採用した。

　1つ目は「人単位のつながり情報」だ。笠場氏は「誰から誰に請求書が送られたかを、Bill Oneであれば人単位で特定できる。他社は法人単位のケースが多い」と説明する。

　なぜ人単位が重要なのか。笠場氏はSansanを例に挙げる。「当社からお客さまに請求書を送る場合、Bill One事業部から送ることもあれば、Sansan事業部やEight事業部から送ることもある。受け取る側から見ると、同じSansanとの取引でも、届く請求書の性質は全く異なる」

　さらに受け取り側の担当者によっても意味が変わる。「Sansanの請求書であっても、営業部門の佐藤さんが受け取るのか、情シスの管理グループが受け取るのかで、内容が違う。情シスなら名刺管理システムの利用料だろうし、営業部門なら販売委託を受けているケースかもしれない」

　法人名だけを見て「Sansanからの請求書」と認識しても、科目は判定できない。「Bill One事業部の山田さんから、経理部門の田中さんに届いている」という人単位の情報があって初めて、「これはBill Oneのサービス利用料だ」と特定できる。請求書に明記されていない暗黙知を、送受信の「つながり」データとして蓄積しているわけだ。

Bill Oneの「つながり」管理。発行側の担当者と受領側の担当者の組み合わせごとにユニークキーを生成し、請求書に記載されていない暗黙知をデータベース化する（Sansan提供）

　2つ目は「明細の構造化」だ。グループ会社の言語理解研究所の技術を活用し、請求書の明細を品名・数量・金額といった項目ごとに表形式でデータ化する。派遣社員の請求書を例にすると、「所定時間」という項目には「雑給」、「出張手当」には「旅費交通費」という科目が紐づく。この組み合わせを学習し、次に同じ明細が来たときには自動で科目を判定する仕組みだ。

　学習は法人（テナント）単位で閉じている点も重要だ。「同じ商品名でも、企業によって科目の切り方が違うケースがある」と笠場氏。ある会社では消耗品費に分類するものを、別の会社では福利厚生費にする場合もある。全ユーザーのデータを混ぜて学習すると、かえって精度が落ちてしまう。企業ごとの運用ルールを尊重する設計が、精度向上につながっている。