「どの項目を改善すれば仕訳の自動化率が上がるか」を試算するシミュレーターを作った話

0. はじめに

バクラク事業部で債務管理の開発をしております shoyan です。同事業部では「業務の自動運転」を目指し、KPI の一つとして自動化率をトラッキングしています。その一環として、初期補完で生成される仕訳の手修正を減らし、自動化率を上げたいと考えています。

そこで、「どの項目を改善すれば仕訳の自動化率に効くのか」を試算するシミュレーターを作りました。きっかけは、各項目の修正率を見ても、その項目を改善したときに全体の自動化率がどれだけ上がるかは直感に反することがある、という気づきです。修正率が高い項目を直しても、伝票単位の手作業はほとんど減らない、そんなケースが起こり得ます。これから取り組む項目が全体の自動化率にどれだけ効くのかを事前に試算できれば、改善の優先順位づけの参考になると考えました。

この記事では、その試算を支える確率モデルと、Streamlit で組んだ画面の設計を共有します。紹介する数値はすべてモックです。

完成イメージはこちらです。本記事用に項目は一部省略しております。各項目の「目標自動化率」をスライダーで動かすと、伝票全体の自動化率がどれだけ変わるか（＝その改善のインパクト）と、削減見込みの伝票数が試算されます。

image自動化率シミュレーターの画面（数値はモックされています）

以降では、なぜ単純な項目別修正率では足りないのかという課題から順に、この画面の裏側にある考え方とロジックを説明していきます。

1. 課題：修正率が高い項目を直しても、自動化率が上がるとは限らない

初期補完によって、請求書の内容から勘定科目・部門・税区分・摘要……といった仕訳項目を自動で埋めます。ユーザーはそれを確認し、必要なら手修正してから確定します。この「手修正」が利用者の手間であり、自動化でできるだけ減らしたいところです。

では、どの項目の自動化精度を上げれば、この手修正を効率よく減らせるでしょうか。その手がかりとして、まず思いつくのが 項目別の修正率 です。項目ごとに「どれくらいの割合で手修正されているか」を見るものです。

勘定科目 : 32% が修正される

部門 : 21%

摘要 : 45%

税区分 : 8%

...

これを見ると「摘要の自動化精度を上げれば一番効きそう」に見えます。ところが、ここに落とし穴があります。

伝票（請求書）単位で見ると、複数の項目が同時に修正されているケースが大半なのです。

伝票 A: 勘定科目 ✏️ 部門 ✏️ 摘要 ✏️ ← 3 項目を修正

伝票 B: 摘要 ✏️ ← 摘要だけ修正

伝票 C: 勘定科目 ✏️ 税区分 ✏️ ← 2 項目を修正

ここで「摘要の自動化を 100% にできた」としましょう。自動化できるのは 伝票 B だけ です。伝票 A は勘定科目と部門の修正が残るので、結局ユーザーは伝票を開いて手を入れます。「摘要修正率 45%」という数字は、伝票単位の手作業削減にそのまま直結するわけではありません。

つまり計測したいのは、項目別の修正率そのものではなく:

ある項目に効く改善を行ったとき、伝票全体の修正率（＝伝票単位で一度でも手修正が入る割合）が実際にどれだけ変わるか

これを試算するのが今回のシミュレーターです。

2. 何を測るか：指標の定義

シミュレーションの前に、比較する 2 つの状態と指標を定義しておきます。

用語

定義

初期仕訳

初期補完後の仕訳。ユーザーがまだ触っていない状態

修正後の仕訳

ユーザーが手修正したあとの最新状態

修正あり（項目）

項目ごとに「初期仕訳 ≠ 修正後の仕訳」

伝票の自動化率

どの項目も一度も修正されていない伝票の割合

3. 比較ロジック：修正フラグの作り方

初期仕訳と修正後の仕訳を項目ごとに突き合わせ、0/1 の修正フラグにします。借方・貸方の各行と伝票（請求書）単位の全項目のフラグを立てたら、最後にフラグの組み合わせ × 件数に畳み込みます。伝票 1 枚ずつではなく「同じ修正パターンの伝票は何件あるか」という形に集約するわけです。これがシミュレーターの入力になります。

集約後は次のような表になります。

勘定科目

部門

摘要

税区分

…

件数

1

1

1

0

…

1,200

0

0

1

0

…

3,400

1

0

0

1

…

800

0

0

0

0

…

9,500

（1 = その項目が修正された伝票群。最終行は「どこも修正なし」＝既に自動化できている伝票です）

伝票単位の全データを持ち回るのではなく、この「修正パターン × 件数」に畳んでおくことでシミュレーションを軽くしています。

4. シミュレーションロジック：確率モデルで試算する

基本原理

スライダーで各項目の「目標自動化率」を動かします。基本となる考え方はシンプルです。

その項目「だけ」が修正理由だった伝票は、その項目を自動化すれば自動化できる。他にも修正がある伝票は自動化できない。

先ほどのモック表でいえば、摘要だけ=1 の 3,400 件は摘要を自動化すれば丸ごと自動化できます。一方勘定科目=1, 摘要=1 の 1,200 件は、摘要を自動化しても勘定科目の修正が残るので自動化できません。

スライダーは「目標自動化率」

ただし現実には「100% 自動化」だけでなく「80% まで上げたら？」という中間も試したくなります。そこで各項目について、現在の自動化率 current から目標 target へ動かしたときに、以下を定義します。

• 改善方向（target > current）: 修正されていた伝票が修正なしになる確率

p_zero = (target - current) / (1 - current)

• 悪化方向（target < current）: 修正なしの伝票が修正ありになる確率

p_one = (current - target) / current

p_zero = 1 - p_one

p_zero は「その項目がこの伝票で修正なしになる確率」です。

直感的には、改善方向の式は「まだ自動化できていない残り (1 - current) のうち、どれだけを新たに自動化できたか」の比率になっています。

計算は伝票1枚ごとではなく、3章で畳み込んだ「修正パターン」の1行ごと（＝同じ修正パターンの伝票群）に対して行います。1つの修正パターンが「完全に修正なし（＝自動化できる）」になる確率は、各項目が独立に修正なしになると仮定し、各項目の p_zero を掛け合わせます1。

修正パターン：勘定科目=1, 部門=1, 摘要=0（この修正パターンの伝票が N 件あるとする）

スライダー : 勘定科目 70%→90%, 部門 80%→100%

勘定科目: p_zero = (0.90-0.70)/(1-0.70) = 0.667

部門 : p_zero = (1.00-0.80)/(1-0.80) = 1.000

摘要 : 修正なし(0) → 影響なし

p_all_zero = 0.667 × 1.000 = 0.667 （= 各項目の p_zero の積）

→ この修正パターンの N 件のうち 66.7%（= N × 0.667 件）が自動化できる

全パターンを合成して全体の自動化率を出す

あとは、これを全パターンに対して行うだけです。各修正パターンの件数に (1 - p_all_zero)（＝自動化できずに修正が残る確率）を掛けて足し合わせれば、シミュレーション後の「修正あり件数」が求まります。そこから伝票単位の自動化率が出ます。

p_all_zero = Π p_zero （1つの修正パターン内の全項目について）

修正あり件数 = Σ 件数 × (1 - p_all_zero) （全修正パターンについて）

新しい自動化率 = (総伝票数 - 修正あり件数) / 総伝票数

5. 結果イメージ

冒頭で見せた画面の読み方を、改めて具体的に見ていきます。ここでは例として 勘定科目（93.1%→100%）と部門（97.0%→100%） を自動化できたと仮定しています。

現在の自動化率 : 45.23%

シミュレーション後 : 49.85% (+4.63pt)

削減見込み伝票数 : 1,286 件

対象伝票数 : 27,783 件

ヘッドラインの「削減見込み 1,286 件」は、スライダー設定（勘定科目・部門の目標自動化率）に基づく確率モデルの期待値です。一方、以下は 勘定科目・部門を 100% 自動化したときに修正不要になる伝票（その2項目以外に修正がない伝票）の内訳（合計で最大 1,203 件）です。

修正理由（これだけ）

件数

全体に占める割合

勘定科目

839

3.02%

部門

344

1.24%

勘定科目 + 部門

20

0.07%

この表から「勘定科目を自動化できれば単独で 839 件（全体の 3.02%）自動化できる」と即座に分かります。さらに「勘定科目と部門のどちらも修正する必要があった伝票」が 20 件あり、これは勘定科目だけ・部門だけを自動化しても残り、両方が揃って初めて修正不要になる伝票です。スライダーは複数項目を同時に動かせるので、こうした「両方を直さないと自動化できない伝票」の効果もまとめて試算に反映されます。

6. おわりに

今回は、「どの項目を改善すれば伝票単位の自動化率が上がるか」を試算するシミュレーターを作りました。ポイントは、項目別の修正率を見るのではなく、「その項目だけが修正理由だった伝票」 を数え、伝票単位の自動化率への寄与から改善インパクトを捉えたことです。

確率モデルによる近似なので正確な予測値ではありませんが、改善の優先順位づけの方向感を掴む道具として活用しています。

最後に LayerX では、業務の自動運転を共に目指す仲間を募集しています。興味のある方はぜひエントリーしてください。

• LayerX 採用サイト

• 実際には項目間の修正には相関があるため、この掛け算（独立の仮定）はあくまで近似です。本ツールも正確な予測値ではなく、どの項目の改善が効きそうかを考えるための一つの参考資料として使っています。↩