なぜ、AIだけでは記帳代行が自動化できないのか ＜税務会計の「判断」と業務設計＞

公認会計士・税理士の手島です。
kubellさん主催のBPaaS/AI+BPO Advent Calendarでは、BPaaSやAI-BPOに関する技術的・実務的な取り組みが日々投稿されており、そのクオリティの高さに刺激を受ける毎日です。

業務をどこまで分解し、どの技術で再構成するのか。各記事からは、現場に根ざした試行錯誤が伝わってきます。
そうした議論を踏まえつつ、本稿では、僕が身を置く税理士業界における「記帳代行でのAI活用」を、少し引いた視点から整理してみます。

本稿で扱いたいのは、特定のシステムや実装手法の紹介ではありません。むしろ、なぜ税理士業界ではAIへの期待が先行し、後から違和感が生まれるのか。なぜその構図が繰り返されるのか。その「構造」の話です。

「AIが記帳を完全に自動化する」という期待はどこから生まれ、なぜ現実とズレていくのか。 そして、そのギャップを埋めるには、AIをどこに置き、何を任せ、何を任せないのか。

本稿では、AIそのものの優劣を論じるのではなく、税務会計という文脈の中で、AIをどう捉え、どう使うべきかを考えていきます。

AIに対する過剰な期待と現実

GeminiやChatGPTをはじめとした生成AIの登場・発達によって、「AIで仕訳が完全自動化できるのではないか」という期待が、税理士業界でも広がっています。証憑の画像をアップロードすれば、AIが内容を読み取り、仕訳を起こし、最終的には試算表まで自動で完成させてくれる。そんな未来像を想像する人も少なくありません。

実際、AIを活用したデモ動画を見ると、証憑を投げた瞬間に仕訳候補が次々と出てきます。あの光景を見れば、「もう人が記帳する時代は終わるのでは」と感じてしまうのも自然です。

ただし、この期待には見落とされがちな前提があります。
それは「仕訳は、証憑だけを見れば自動的に決まる」という暗黙の仮定です。

税務会計を前提とした仕訳は、単なる分類作業ではありません。
なぜその勘定科目なのか。なぜその消費税区分なのか。なぜその処理を選ぶのか。こうした背景、つまりコンテキストを前提に成立しています。

では本当に、「証憑をアップロードするだけで、税務会計として正しい試算表が完成する」のでしょうか。ここから順に整理していきたいと思います。

繰り返されてきた「自動化」への期待

実は税理士業界では、これまでも同じ構図が何度も繰り返されてきました。

数年前、税理士業界では「RPA」が注目を集めるようになりました。
人が行ってきた定型作業をロボットが代替し、入力や転記といった作業はほぼ自動化できる。そうした触れ込みのもと、多くの税理士事務所がRPAの導入を検討するようになっていきます。

その後、「DX」という言葉が急速に広まりました。会計ソフトのクラウド化、証憑の電子保存、ワークフローのオンライン化が進み、業務そのものをデジタル前提で作り変えれば、記帳も自動化できるのではないか、という期待が語られるようになりました。
実際、紙は減り、入力工数は削減され、処理スピードも向上するなど、業務効率が改善したのは事実です。

では、記帳代行そのものは自動化されたのでしょうか。
この点については、現在でも「完全に自動化された」と言い切れる状況にはありません。

というのも、RPAやDXは、本質的には既存の業務フローをより効率よく回すための取り組みにとどまっていたからです。
どれだけデジタル化が進んだとしても、前提となる判断基準が人に依存している限り、最終的な確認や修正、意思決定を人が担う構造は変わりませんでした。

税務会計の記帳業務では、証憑に書かれている内容だけを見て処理を決めることはできません。
実務では、証憑の外側にある情報が判断の前提になります。たとえば次のような観点です。

これらはいずれも、証憑単体からは読み取れない情報です。
DXは、こうした業務を「見える化」し、「早く」することはできましたが、判断そのものを置き換えることはできなかったのです。

ここまでを振り返ると、「なぜ記帳代行は完全自動化されなかったのか」という問いは、単に技術の進化が足りなかった、という話ではないことが見えてきます。

記帳代行が自動化されなかった構造的理由

この問題には、少なくとも次の2つの構造的な要因が存在します。

要因1：前提にしている会計が違っていた

自動化の文脈で語られてきた取り組みの多くは、主に財務会計を前提としていました。一方、税理士業界が日常的に扱っているのは、税務会計を前提とした仕訳です。

どちらも「仕訳」という形式を取りますが、求められる判断軸や前提条件は大きく違います。ここを整理しないまま「仕訳＝自動化できるもの」と捉えてしまうと、期待が先行しやすくなります。

要因2：システム導入と自動化が混同されていた

RPAやDXの議論では、「システムを導入すれば自動化できる」という発想が先に立ちがちです。しかし実際には、自動化が成立するかどうかはシステムの有無ではなく、業務の中で判断をどう配置するかにかかっています。

設計しないといけないのは、たとえば次の点です。

問題は技術が足りなかったことではありません。
技術をどう配置し、どの工程にどの役割を持たせるか。その設計が十分ではなかったのです。

そして今、AIが登場し、「今度こそ判断まで自動化できるのではないか」という期待が再び高まっています。

前提にしている会計が違うと、話が噛み合わない

ここで一度立ち止まり、自動化の議論でしばしば混同される会計そのものの違いを整理しておきます。

同じ「記帳」という行為であっても、前提としている会計が異なれば、求められる判断や評価軸も変わってきます。
この前提を整理しないまま自動化やAI活用を進めると、処理自体は正しいはずなのに話が噛み合わなかったり、システム上は成立しているのに実務では使えなかったりといった問題が生じてしまうのです。

そのため、まずは実務の視点から財務会計・税務会計・管理会計の違いを整理してみましょう。

財務会計：外部に説明するための会計

財務会計は、株主や金融機関といった外部ステークホルダーに対して、企業の経営成績や財政状態を説明するための会計です。そのため、処理の巧拙よりも、次のような点が重視されます。

すなわち実務上、勘定科目は「取引の実態を説明するラベル」というよりも、表示ルールに基づいて統一的に分類するための記号として扱われる側面が強くなります。

同じ支出であっても、金額の大きさや発生頻度、性質によって「どの科目に表示するか」が重視されるのが、財務会計の特徴です。

税務会計：申告と説明責任のための会計

一方で、税務会計において勘定科目は、申告の合理性と説明可能性を担保するための手段として位置づけられます。
ここで問われるのは、科目の名称そのものではなく、次の点です。

税務会計では、仕訳そのもの以上に、仕訳の背後にある事実関係や判断プロセスが重要になります。

税務調査の場面では、数字だけでなく「なぜこの処理をしたのか」を説明できることが求められ、それができなければ、修正申告や追徴課税といったリスクに直結します。

管理会計：意思決定のための会計

管理会計は、経営判断を支援するための会計です。

その目的は意思決定に資する情報を提供することであり、勘定科目の厳密な定義や法的な整合性よりも、経営判断に役立つかどうかが優先されます。
たとえば、プロジェクト別の収益性を把握したい場合には、財務会計や税務会計には存在しない管理用の科目を設け、費用を意図的に細分化することも珍しくありません。

その結果、実務では次のような数字が併存することになります。

これらが必ずしも一致しないことは、管理会計においてはむしろ自然な状態です。

会計の目的を揃えないまま自動化すると何が起きるか

ここで重要なのは、どの会計を主軸にして業務やシステムを設計しているのかを明確にすることです。特に中小企業では、会計実務が最終的に向かう先は税務申告であるケースが大半です。

そのため、日常の記帳や判断基準も、税務会計としての合理性を担保する形で設計されていなければ、現場の負担やリスクは、むしろ増えてしまいます。

この「会計の目的の違い」を整理せずに、仕訳を一律に自動化しようとすると、財務会計的には正しく見えるが、税務的には説明がつかないといった問題が、必ず表面化します。

なぜ「同じ仕訳」でも、税務会計では自動化できないのか

同じ取引であっても、なぜ税務会計では判断が分かれるのでしょうか。

財務会計は、外部への説明責任や比較可能性を重視するため、科目や表示方法に関するルールが優先されます。
一方で税務会計は、適正な申告と課税の公平性を目的とするため、税法の要件に合致しているかどうかが最重要になります。

この違いは、単なる帳票フォーマットや集計方法の差にとどまりません。
税務実務上は、同じ証憑・同じ取引であっても、結論に至るまでの判断プロセスそのものが異なるという形で表れます。

その違いを具体的に理解するため、実務でよく起こり得る事例を一つ見てみましょう。

事例：20万円のスニーカーを購入した場合

ある会社で、20万円のスニーカーを購入したとします。証憑上は金額・日付・支払方法が明確で、一見すると単純です。

財務会計の視点では、金額の重要性や表示ルールに沿った分類ができていれば、大きな問題にならないケースもあります。しかし税務会計では、ここから話が変わります。

税務会計における判断の起点は「事実関係」

税務会計で最初に確認されるのは、勘定科目ではありません。問われるのは、取引の事実関係です。具体的には、実務では次のような点が確認されます。

これらの情報が揃わなければ、税務上の結論を出すことはできません。
同じ20万円のスニーカーであっても、事実関係によって処理は大きく分岐します。

ケースA：業務上必要な支出と認められる場合
撮影・舞台・イベント等の業務に不可欠であり、私的利用がほぼ想定されないと合理的に説明できる場合には、事業の用に供したものとしての処理が検討されます。
この場合、20万円という取得価額から、以下のような選択肢が生じます。

どの処理を選択するかによって、損金算入のタイミングや将来の税務リスクは変わります。そのため、金額だけでなく、購入目的や使用実態を踏まえた慎重な判断が求められます。

ケースB：私的利用が明白な場合
役員や従業員が私服として使用しているなど、私的利用であることが明らかな場合には、そもそも経費として認められない可能性があります。
このようなケースでは、実務上、次のような対応が検討されます。

いずれの対応を取る場合でも、単なる勘定科目の修正では済まず、課税関係や付随する手続きまで含めた判断が必要になります。

ケースC：贈答・接待に該当する場合
取引先への贈答や接待として使用された場合には、交際費としての扱いになります。
ただし、交際費には損金算入の限度や不算入ルールがあり、金額・相手先・目的の記録が不十分であれば、税務上の問題に発展します。

税務会計は「判断の集合体」

すなわち、同一の証憑、同一の金額であっても、税務会計上の結論は必ずしも一つではありません。
その分岐を決めるのは、金額や勘定科目といった形式的な要素ではなく、誰が、何のために、どのように使ったのかという取引の事実関係です。

税務会計において決定的に重要なのは、仕訳そのものではなく、その仕訳に至るまでに行われた判断と、それを後から第三者に説明できるかどうか、という点にあります。
AIや自動化技術がどれだけ進歩したとしても、証憑だけを見て、その支出がどのような意味を持つのか、税務上どの論点に該当するのかを一意に決めることはできません。

税務会計の現場で求められるコンテキストとは、単なるデータの前後関係ではなく、誰が、いつ、なぜその取引を行い、それがその事業においてどのような意味を持つのかという、立体的な理解です。

このコンテキストを欠いたままでは、会計処理は単なる記録作業になってしまい、税務会計としての本来の価値を失ってしまいます。
このように、税務会計の記帳業務は、個別の判断を前提として成立している仕事なのです。

システム導入だけでは自動化できなかった理由

ここまで見てきたとおり、税務会計の記帳は「仕訳を作る作業」ではなく、「判断を積み上げて説明可能性を担保する仕事」です。

では、こうした判断を含む業務を、私たちはこれまでどのように業務として成立させてきたのでしょうか。
税理士業界では、これらの判断は長らく業務フローの中に暗黙的に組み込まれ、人の作業として処理されてきました。判断基準は明文化されることなく、経験や慣習の中で共有され、業務として回ってきたのです。

その結果、記帳代行の業務フロー図は、多くの場合、 「取引発生 → 証憑受領 → 仕訳作成 → レビュー → 確定」 といった、非常にシンプルな形で表現されてきました。

業務フローの外側で、人は何を判断していたのか

しかし、この業務フロー図は、あくまで外形を示したものにすぎません。
以下に例示されるような、各工程の中で人が実際にどのような判断を行っているのかまでは表現できていません。

こうした「行動の中身」は、業務フロー図にはほとんど記載されないのです。しかし実際には、この見えない判断こそが、記帳代行の品質と再現性を支えてきました。

システム導入が直面した壁

一方で、人の判断に支えられたこの業務構造は、処理量の増加や人材不足といった現実的な制約の中で、次第に限界を迎えるようになりました。
そこで近年、RPA、クラウド会計、ワークフロー、そしてAIといった技術を用いて、業務全体をシステムに置き換えようとする試みが進められてきたのです。

しかし、結果として「完全な自動化」には至りませんでした。
なぜなら、置き換えられたのは業務フローの「外枠」であり、内側にあった判断や例外対応は、整理されないまま残ったからです。

言い換えると、システム導入によって「工程の流れ」は整備されても、「なぜこの処理になるのか」「どこで判断が分かれるのか」「判断に必要な情報は何か」といった部分が、判断が必要な工程としてブラックボックス化していきました。

そして最近では、その空白を埋める存在として、「判断まで担ってくれるのではないか」という期待がAIに向けられるようになったのです。

前提が整理されていない業務では、AIは力を発揮できない

AIは、あらかじめ定義された前提条件の中で処理を行うことに長けています。
裏を返せば、前提が曖昧で、判断に必要な情報や基準が整理されていない状態では、安定した成果を出しづらいという性質があります。

ところが記帳代行の現場では、まさにその「前提」が未整理なまま運用されているケースが少なくありません。

この状態でAIを導入すると、仕訳候補自体は大量に生成できますが、それらを最終的に確認し、責任を持って確定させる作業は、結局人に集中してしまいます。
判断が分かれる取引ほど介入が増え、オペレーションは自動化されるどころか、かえって複雑化するのです。

これはAIの性能不足が原因ではなく、業務側の前提（判断ポイント・判断基準・必要情報）が整理されないまま、技術だけを当てはめてしまったことが原因だと言えます。

判断を整理しなければ、自動化は始まらない

ここで重要になるのが、As-Is / To-Be の整理です。

前述の通り多くの現場では、業務の現状（As-Is）が十分に言語化されないまま運用されています。
誰がどこで判断しているのかは曖昧で、判断基準は暗黙知に依存し、例外が出るたびにその場で対応する、という状態です。

本来目指すべき姿（To-Be）は、こうした属人的な運用から脱し、どこで判断が発生しているのか、その判断を人が担うのか機械に任せるのか、例外処理をどのように位置づけるのかを、あらかじめ整理した状態です。

行動の中身や As-Is / To-Be が整理されていない状態では、それがAIであれ、RPAであれ、GASであれ、どのような技術を使っても記帳代行の自動化は成立せず、判断がブラックボックスのまま残り続けてしまうのです。

AIとコードベース技術の役割分担

ここまでの話を踏まえると、記帳代行の自動化において本質的に問われているのは、「AIか、それ以外か」といった技術選択の問題ではありません。

重要なのは、業務の中にどんな性質の処理が存在しているかを見極め、その処理に合う技術を割り当てる設計です。

そこで本章では、会計業務で用いられる技術を大きく二つに分け、それぞれがどのような場面で力を発揮し、どこに限界があるのかを整理します。

一つは、生成AIやAIエージェントに代表される AI系の技術。
もう一つは、GASやRPAといった コードベースの技術です。

AIはどうやって答えを出しているのか

生成AIは、文脈を踏まえて次に来そうな語や表現を予測する仕組みで動いています。スマートフォンの予測変換を高度化したものだと考えると理解しやすいでしょう。

この仕組み上、AIの出力は常に確率的であり、同じ入力であっても結果が微妙に変わることがあります。また、学習されていない前提や、その場固有の事情については十分に扱えません。

そのためAIは、解釈や仮説提示、判断を支援する役割には向いていますが、結果が一意に定まらなければならない処理や、百発百中の正確性が求められる業務をそのまま代替することには適していません。

コードベース技術の「決められたことしかできない」という価値

一方、GASやRPAといったコードベース技術は、あらかじめ定められたルールを忠実に実行することしかできません。状況を解釈したり、その場で判断を変えたりすることはありません。

しかし、会計業務では、この性質がむしろ重要になります。
同じ条件には必ず同じ結果が返ること、想定外の事態が起きたら処理が止まり、人が確認して次の判断を引き受けること。

この挙動こそが、会計業務に求められる安定性です。

AIとコードベースの関係は「代替」ではなく「分担」

すなわち、AIとコードベース技術は、優劣を競う関係にはありません。それぞれが得意とする処理の性質が、根本的に異なっています。

問題が生じるのは、この違いを意識しないまま技術を導入したときです。
規則的に処理すべき業務をAIに任せたり、判断が揺れやすい業務をコードで無理に固定化したりすると、現場では必ず歪みが生まれます。

だからこそ必要になるのが、As-Is / To-Beで業務を分解し、判断の性質を見極めたうえで、どの工程にどの技術を配置するかを設計することです。

最適な場所に、最適な技術を配置する

ここまでの考え方を具体化すべく、自社の記帳代行業務を工程単位に分解したうえで、各工程に対して「どの技術」を「どの役割」で配置しているのかをご紹介します。
重要なのは、自動化できる／できないを技術の性能で語るのではなく、「どの工程にどんな判断が含まれているか」を見極めたうえで、最適な配置を行うことです。

記帳代行フローの全体像

今回は、記帳代行業務を次の8工程に分解しました。
（※①は顧客側で起きる取引そのものですが、以降の工程設計の起点になるため含めています。）

重要なのは、この工程分解そのものではなく、それぞれの工程で「どのような判断が行われているか」を見極めたうえで、最適な技術を配置している点です。

各工程における技術の配置

たとえば、②の「証憑の受領・収集」は、そもそも顧客からの提出行為を伴うため、人の関与が不可欠な工程です。
一方で、電子証憑については、形式が比較的安定しているため、AIを活用して一部の収集作業を自動化しています。

③の「証憑の整理・内容確認」は、書式の揺れや記載内容のばらつきが大きく、事前に厳密なルールを定めにくい工程です。そのため、文脈を踏まえた解釈が可能なAIを中心に配置しています。

④の「明細データ作成」では、取引内容をどう捉えるかという思考の部分と、会計システムに取り込める形式に整える作業が混在します。
ここでは、考える部分をAIが担い、決められたフォーマットへの変換はGASが担当する形を取っています。

⑤の「明細データ取込」は、結果が一意に定まり、判断の余地がほとんどありません。
この工程では、API連携を含むコードベース技術を用い、安定した処理を優先しています。

⑥の「自動登録ルール適用」についても同様で、ここではAIを使わず、クラウド会計に備わっている明示的なルール機能をそのまま活用しています。

あえて自動化しない工程

⑦の「入力内容のレビュー」は、現時点では人が担っています。
この工程には、税務リスクを最終的に引き受ける判断や、例外処理に関する背景説明が必要となる判断が集中するためです。

一方で、AIをまったく使っていないわけではありません。
取引全体を俯瞰したうえで、不自然な点や注意すべき箇所を洗い出したり、確認すべきポイントを整理して提示したりといった形で、あくまで判断を支援する補助的な役割に留めています。

おわりに：業務設計から始まるAI活用

税務会計の記帳は、証憑だけでは結論が決まらない取引が一定数存在します。誰が、何のために、どのように使ったのか。この事実関係と説明可能性が、処理を分岐させます。したがって、AIの性能が上がったとしても、「証憑を入れれば常に税務的に正しい結論が一意に出る」という形での完全自動化には、構造的な限界があります。

一方で、それは「AIが役に立たない」という意味ではありません。AIが現場で力を発揮するのは、判断を置き換える場面というより、判断の前段で情報を整えたり、見落としやすい論点を洗い出したりする場面です。
逆に、結果が必ず一つに定まらなければならない処理や、ルールに厳密に従う必要がある工程では、コードベース技術の方が安定します。
結局のところ、実務で効くのは「AIか、それ以外か」ではなく、AIとコードの役割分担を、業務の性質に合わせて切ることです。

この前提に立つと、記帳代行の自動化の正体も見えてきます。
自動化は、特定のシステムを導入した瞬間に完成するものではありません。
業務を工程単位に分解し、判断ポイントと判断基準を言語化し、To-Beの構造を先に描いた上で、技術を最適な場所に配置する。
この順序を踏むことで、初めて現実的なものになります。

だからこそ「AIをどう使うか」よりも先に、「どこを人が最終判断を引き受ける設計にするか」を明確にしておくことが重要です。
税務判断や説明責任、リスクの引き受けが集中する領域は、現時点では人が担う前提で組んだ方が、業務全体として安定します。

なお、この「最終判断は人が担う」という整理は永続的な結論ではありません。判断基準の言語化とデータの蓄積が進めば、人が担う領域は狭まっていく可能性があります。
ただし、その未来に至るためにも、まずは業務の構造を設計し直す必要があります。

「AIで何ができるか」ではなく、「業務をどう設計するか」。
税理士業界のAI活用は、この問いから始まり、この問いに立ち返り続ける領域だと考えています。