税務AI「ZoooU」について②

 

仕訳処理の自動化について思うことがあったので、備忘になります（私の勝手な考えです）。

 

 

まず、このような専門的な処理について自動化を行う時は、その事業領域の専門知識を持った人間自身が開発・制作にかかわることが大前提かと思います（これはRPA等でも同様）。

 

 

次に、このような専門的な行為を、汎用AIに全て委ねることはナンセンスな場合が多いと思われます（その前段階のアイデア出し、簡単な試行錯誤なら汎用AIの方が簡単にできる場合も有り得る）。そもそもが限られた事業領域での話であることから、その専門家自身が深く関わるような形で専用AI（というかアルゴリズム）を開発し、さらにその専用AIを用いて自動化のトライ＆エラーを行うのが理想となります。

 

つまり、専門家　＋　専門家が設計する（もしくは深く携わった）専用AI　の状態が理想的では…という考えが頭をよぎりました。

 

 

さらに、税法は毎年改正があるため、2024年版、2025年版、2026年版…と各年度でアルゴリズムを用意するといったことも検討が必要か？などとも考えておりました（トリガーが毎年同じならいいが、大幅に異なる年度が混じると厄介）。ただ、会計年度と税制改正の区切りって一致するとも限らないので、たとえば、税制が異なるタイミングでアルゴリズムも分ける方がいい…？

 

そうなると、そもそも仕訳処理する範囲を絞った方が早いですね…

 

弥生やJDLのCSV取込も、かなりの部分でよく反映されるので、こういったものでも難しいものに絞って（やはり振替取引中心か）、自動化を考えた方が早いような気が…

（そもそも、そういった自動取込から漏れたものに対して、仕訳テンプレートを当てはめる…といったことは既にやってきました）

 

 

CSVを貼り付けたら、IF分岐で消費税課税区分の適否を判定するワークシートとかの方が、小回りもきくし便利かも…

 

 

などと色々悩んでました。

 

いずれにしろ、専門領域には専用ＡＩ（アルゴリズム）が一番かと。

 

 

 

 

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃
仕訳自動化・専用AI・ルール設計・専門家の役割・汎用AIとの関係を、一つの「一貫した理論」で。

0. 全体の前提と問題意識

仕訳自動化を本気で考えるときの論点は、大きく分けて次の通り。

  • 誰がロジックを考えるべきか
    • 税理士などの専門家か
    • システムエンジニアか
    • 現場担当者か
  • どのようなAI・アルゴリズム構造が望ましいか
    • 汎用AI（ChatGPTのようなLLM）を中核に据えるのか
    • 会計・税務に特化した専用AI＋ルールを作るのか
  • どのような処理パターンがあり、どんな業種・状況に向くのか
    • ML → ルール
    • ルール → ML
    • ML → ML（二段階）
    • ML ↔ ルール（相互補完）
    • ルール → ルール（階層）
  • ルールベースはどのように設計しないと危険か
    • 境界条件
    • 粒度
    • 肯定条件 vs 否定条件
    • 更新容易性
    • リスクの重みづけ

これらを一つの体系として整理する。

1. なぜ二段階処理が必要なのか

1-1. ML単独の限界

機械学習（ML）単独には以下の特徴がある。

  • 強み
    • 未知パターン・曖昧なケースに対応できる
    • 大量データから統計的な傾向を学習できる
  • 弱み
    • 法令遵守・税務リスクを“確実に”制御することが難しい
    • 例外処理（少数だが超重要なケース）に弱い
    • 説明責任（なぜその仕訳になったか）を構造的に示しにくい

1-2. ルール単独の限界

ルールベース単独には以下の特徴がある。

  • 強み
    • 透明性・説明可能性が高い（if条件・フローチャートで表現可能）
    • 法令遵守・税務リスクを狙ってコントロールしやすい
  • 弱み
    • 網羅性が低い（想定していないパターンに対応しにくい）
    • 例外が増え、維持が困難になりやすい
    • 現場の多様な取引パターンをルールだけでカバーするのは現実的でない

1-3. 二段階処理の本質

二段階処理とは、MLとルールベースを組み合わせて使う構造を指す。

  • MLの「網羅性・柔軟性」
  • ルールの「法令遵守・説明責任」

これらを掛け合わせることで、

  • 精度
  • 再現性
  • 説明可能性

を同時に高いレベルで達成しようとするアプローチである。

2. 二段階処理のパターンと特徴

2-1. (A) ML → ルール補完

  • 流れ
    • MLで仕訳候補を推定
    • ルールで補正・監査・再分類・税区分補正などを行う
  • 特徴
    • 精度と説明可能性のバランスが良い
    • 大量データをMLで処理しつつ、法令部分はルールでガードできる
  • 向くケース
    • データ量が豊富でMLが強く働ける業種
    • 法令遵守が必須の領域
    • 例：飲食業のPOSデータ → MLで売上仕訳推定 → ルールで軽減税率判定

2-2. (B) ルール → ML補完

  • 流れ
    • ルールで明確な仕訳を処理（確定領域）
    • ルールで処理できなかった残りをMLで推定
  • 特徴
    • 誤判定リスクを最小化できる
    • 「絶対に間違えてはいけないところ」をルールに集中させられる
  • 向くケース
    • ルールで処理できる領域が多い業種
    • 法令や基準で明確に線引きできる領域が多い業種
    • 例：建設業の工事進行基準はルールで確定 → 外注費比率など曖昧部分をMLで補完

2-3. (C) ML → ML（二段階モデル）

  • 流れ
    • 軽量モデルで粗分類（一次モデル）
    • 高精度・高コストなモデルで精緻分類（二次モデル）
  • 特徴
    • 大規模データのリアルタイム処理に向く
    • 説明性・法令ベースのガードは低め（別の仕組みで補う必要）
  • 向くケース
    • 取引量が膨大
    • 法令判断よりスループットやリアルタイム性が重視される
    • 例：EC取引の大量仕訳処理

2-4. (D) ML ↔ ルール相互補完（ハイブリッド）

  • 流れ
    • MLが仕訳・科目・税区分などを提案
    • ルールが監査・検証
    • ルールNGの場合、MLが別候補を再推定
  • 特徴
    • 双方向のやり取りで精度を上げつつ、学習循環も作れる
    • 高リスク領域でも使える構造
  • 向くケース
    • 税務調査のリスクが高い領域
    • 説明責任が強く求められる業種・取引（例：建設業の大規模工事、軽減税率判定）

2-5. (E) ルール → ルール（階層型）

  • 流れ
    • 大分類ルール → 詳細ルール → 最終仕訳
  • 特徴
    • 透明性は最大
    • 学習効果はない（ルールを手で増やすしかない）
  • 向くケース
    • 取引パターンが固定的で変化が少ない
    • 仕訳パターンが限定されている業種
    • 例：公益法人・学校法人など

3. 二段階にすると精度が“ほぼ倍増”する理由

3-1. 一段処理での問題

  • ML単独：例外・法令境界に弱い
  • ルール単独：網羅性に欠け、例外処理だらけになりやすい

3-2. 二段処理での補完関係

  • ML → ルール
    • MLが曖昧な領域を含めて候補を拾う
    • ルールが法令遵守・税務リスクの観点でフィルタ
  • ルール → ML
    • ルールで明確領域を処理し、誤判定リスクの高い部分を抑える
    • 残りの曖昧領域をMLが推定

この結果、

  • 精度（Accuracy）
  • 再現性（同じ入力なら同じ結果）
  • 説明可能性

が、一段処理と比べて理論上・実務上ともに大きく向上する。

4. 業種別の適用イメージ

4-1. 建設業

  • 推奨パターン
    • ルール → ML補完
    • ML ↔ ルール（ハイブリッド）
  • 理由
    • 工事進行基準など、ルールで確定できる部分が多い
    • 外注費比率、工期遵守率など、曖昧・統計的要素はMLが有効
    • 高額・長期・税務リスクが高いため、説明責任が重要

4-2. 飲食業

  • 推奨パターン
    • ML → ルール補完
    • ML ↔ ルール（ハイブリッド）
  • 理由
    • POSデータなど大量データはMLに適する
    • 軽減税率・消費税区分はルールで厳格に管理すべき
    • 膨大な取引数と税務調査リスクの両方が存在

4-3. EC・金融取引

  • 推奨パターン
    • ML → ML（二段階）
  • 理由
    • データ量が膨大でリアルタイム処理が重視される
    • 説明性は他の仕組み（別レポート・サマリ）で補う設計が現実的

4-4. 公益法人・学校法人等

  • 推奨パターン
    • ルール → ルール（階層型）
  • 理由
    • 取引パターンが固定的で、年月を経てもパターンが大きく変化しにくい
    • 学習効果よりも、透明性・安定運用が重視される

5. ルールベース設計の注意点（ここが甘いと全て崩れる）

5-1. ルールは「例外処理」ではなく「境界条件」として設計

  • ありがちな誤り：
    • 「MLが外したときの例外処理」としてルールを位置付ける
  • 正しい位置付け：
    • ルールは“絶対に破ってはいけない境界条件”として設計する

例：

  • 消費税率の判定
  • 工事進行基準の適用可否
  • 資本的支出 vs 修繕費の閾値
  • 補助科目の使用禁止パターン

これらは「例外」ではなく、「AIの自由度を制約するガードレール」である。

5-2. 「業務ルール」より「会計・税務ルール」を優先

  • よくある失敗：
    • 現場の運用ルール（社内ルール）をそのままAIルールにしてしまう
  • 正しいアプローチ：
    • 会計・税務の法令・基準に基づくルールを優先
    • 現場ルールは補助的・上書き的に扱う

理由：

  • 現場ルールは属人的・可変的
  • 法令ルールは普遍性があり、AIの再現性・説明責任の基盤となる

5-3. ルールの「粒度」を統一する

粒度（どの単位でルールを定義するか）がバラバラだと、MLとの境界が曖昧になり、誤判定が増える。

統一すべき粒度の例：

  • ルールは取引単位か、明細単位か
  • 金額閾値における境界（以上／超過／未満）
  • 勘定科目判定の優先順位（上書き順）
  • 補助科目付与条件の階層（大分類 → 中分類 → 小分類）

粒度が揃っているルールはMLとの連携がスムーズで、結果も安定する。

5-4. 否定条件ではなく肯定条件で書く

  • 否定条件の例：
    • 「飲食費でない場合は交際費」
  • 肯定条件での例：
    • 「飲食費の条件を満たす場合のみ飲食費。それ以外は交際費。」

肯定条件の利点：

  • バグが発生しにくい
  • 説明がしやすい
  • MLの出力との組み合わせが明瞭

5-5. 説明責任を前提にしたルール記述

ルールは、監査・税務調査で問われたときに説明できなければならない。

説明可能なルールの例：

  • 「軽減税率対象の飲食料品であるため、税率8%を適用した」
  • 「工事進行基準の要件（契約金額・進捗率）を満たしているため、当期に売上計上した」

このように、一文で理由を言語化できるルールが理想。

5-6. MLの弱点を補う方向でルールを設計する

MLが苦手な領域：

  • 法令の境界
  • 税率判定
  • 補助科目の細かな分岐
  • 金額閾値
  • 例外処理（特に少数だが重要なケース）

ルールは、これら**「絶対に誤ってはいけない領域」をカバーするように設計**すべき。

5-7. 業種別テンプレートとしてルールを分離

業種横断的なルールを無理に共通化しすぎると破綻する。

業種ごとの例：

  • 建設業：工事進行基準、外注費、材料費の振替
  • 飲食業：軽減税率、テイクアウト・イートイン区分、POS取引の集計
  • EC：決済手数料、チャネル別売上、返品・キャンセル処理

業種別ルールセットとして分離し、独立して調整できる構造が望ましい。

5-8. ルールとMLの入出力形式を完全に整合

  • 科目名の表記揺れ
  • 補助科目階層のずれ
  • 金額の丸め方
  • 税区分コードの体系

これらがズレると、

  • ルールが発火しない
  • 想定外のパスを通る

といった事故が発生する。
入出力形式の整合は必須。

5-9. 更新容易性と差分更新の構造

税制改正・業務変更は必ず発生する。

  • ルールを階層化する（基礎ルール／業種ルール／顧客別ルール）
  • 個別のルールを差分更新できるようにする
  • 過去のバージョンを保持し、年度ごとに適用ルールを切り替えられるようにする

これにより、長期運用時の保守コストを大幅に削減できる。

5-10. MLの学習データとの整合性

  • MLが学習した過去仕訳の分布
  • 科目の出現頻度・偏り
  • 過去の運用判断

これらとルールが矛盾すると、

  • MLは「こう学習したのに、ルールがそれを否定する」という構造になる

そのため、ルール策定時には、学習データの世界観との整合を意識する必要がある。

6. 「誰がロジックを考えるべきか」についての厳密検討

6-1. 仕訳は法的判断の圧縮表現である

仕訳は、外形的には「取引を勘定科目に分類しているだけ」に見えるが、本質は以下の通り。

  • その取引をどの法的概念として評価するのか
    • 収益か預り金か
    • 資本的支出か修繕費か
    • 工事進行か完成基準か
  • その評価を税法・会計基準上どのように扱うか

つまり、仕訳は法的判断の圧縮表現であり、
自動化のロジック設計には、条文・通達・裁決例・実務経験への深い理解が必須である。

6-2. しろうと設計の危険性

素人が設計した仕訳自動化にありがちなパターン：

  • 「なんとなく消耗品費」「なんとなく交際費」といったラベル貼り替え発想
  • 税法の境界線を知らずに、金額だけ見て一律処理（少額＝経費など）
  • 稀だが税務上重要な例外を、MLに丸投げしてしまう

これらは、

  • 短期的には「それなりに動く」ように見える
  • 長期的には、税務・監査リスクとして顕在化する

という構造的な危険を内包している。

6-3. 専門家（税理士など）が中核にいる必要性

ロジック設計の中核は、次を担当する人間である必要がある。

  • リスクの線引き（どこを絶対に間違えてはいけないか）
  • 法令解釈（条文・通達・裁決例・実務慣行の理解）
  • 「どこをルールで、どこをMLで、どこを人間レビューで行くか」の切り分け決定
  • 最終的な運用方針への責任

この役割を担えるのは、税理士などの専門家であり、単なるシステムエンジニアや現場担当では担えない。

6-4. ただし「税理士であれば誰でもよい」わけではない

ロジック設計には、以下の能力の組み合わせが必要。

  • 専門知識（法令・実務）
  • 抽象化・形式化能力（条件式・フローチャートへの落とし込み）
  • テキスト化・説明力（他者・システムに伝わる形にする）

専門家であっても、

  • 頭の中では判断できるが、形式化が苦手
  • 例外処理を言語化できない

という場合、設計はうまくいかない。
この意味で、専門家＋仕組み化の能力を持つ人の協働が望ましい。

7. 汎用AIではなく「専用AI＋アルゴリズム」が必要な理由

7-1. 汎用AIの限界

  • 基本的には「文章生成モデル」であり、法的境界・税務リスクに対する構造的理解は持たない
  • モデル更新で挙動が変わり得るため、年度別の説明責任に耐えにくい
  • 誤りの重み（致命的 vs 軽微）を明示的に制御しづらい

7-2. 専用AIの要件

専用AIとは、次のような特徴をもつ。

  • 世界観が会計・税務に固定されている
  • 出力が文章ではなく、構造化された仕訳データ
  • 判断ロジックがバージョン管理され、年度ごとに適用ロジックを説明できる
  • MLとルールを統合し、「二段階処理」が標準機能として組み込まれている
  • 税務リスクの重みづけに基づいて、誤りの許容範囲を制御できる
  • 根拠説明エンジンを備え、「なぜこの仕訳なのか」を条文・実務ベースで説明できる

7-3. 汎用AIの適切な位置づけ

汎用AIは、中核の判定エンジンではなく、次のような用途に非常に有用。

  • 専門家の頭の中のロジックをテキスト化・整理する
  • ルール仕様書やフローチャートの下書きを作る
  • 過去仕訳のパターンを言語化して整理する
  • 開発チームとのコミュニケーション資料を作る

つまり、「設計・説明・文書化の補助ツール」としては極めて強力だが、「責任ある最終判断者」としては不適である。

8. 専用AIのレイヤー構造と権限

専用AIは、少なくとも以下の4レイヤーに分けて考えるのが望ましい。

  • L1：法令・方針レイヤー
    • 担当：税理士など専門家のみ
    • 内容：法令、通達、裁決例、業種別判断基準、リスクの閾値
  • L2：仕訳ロジックレイヤー
    • 担当：専門家＋仕組み化担当
    • 内容：条件分岐、例外処理、業種別テンプレート、ルール階層化
  • L3：AI・アルゴリズムレイヤー
    • 担当：仕組み化担当＋エンジニア
    • 内容：MLモデル、特徴量設計、ルールエンジン、ログ・監査機能
  • L4：UI・現場運用レイヤー
    • 担当：現場担当者も含めて利用可能
    • 内容：入力画面、例外レビュー、承認フロー、ログ確認

9. 全体の一行要約

仕訳自動化とは、技術の問題ではなく「専門家が自分の頭の中の法的・実務的判断ロジックに責任を持って形にする問題」であり、その中核には税理士などの専門家が設計する専用AI＋ルールエンジン構造を置き、汎用AIは“設計・説明・文書化の補助”として周辺で用いるのが、最も安全かつ合理的なアーキテクチャである。