はじめに
最近、会計士・税理士のAI活用事例が増えている。スタッフなしで数十社を回している、処理時間が数分の一になった、コードはすべてAIが書いてくれた。読むと「すごい」「自分もやってみよう」という気持ちになる。
実際に試すと、思ったより大変だ。
難しいのはツールの使い方でもコードでもない。事例記事が「前提」として書かずに飛ばしているステップが、実はいくつもある。その話をする。
事例記事が見せているのは「完成品」だけだ
AI活用事例の多くは、動いているシステムの画面と処理結果の数字を見せる。毎晩自動で仕訳が終わる、月に何十時間削減できた、といった話だ。
読んでいて爽快感がある。だが、そのシステムが完成するまでに何をしたかは、ほとんど書いていない。どうやってルールを決めたか、どんな失敗があったか、顧問先にどう協力してもらったか。このプロセスが丸ごと抜けている。
結果として読者は「やってみよう」と思い、思ったより手前で詰まる。
前提1：データはきれいな形で届かない
事例記事が暗黙に置いている条件
AI活用事例で紹介されるシステムは、たいていfreeeやマネーフォワードのAPIを叩いて動いている。つまり「データがすでにクラウド会計ソフトに入っている」ことを前提にしている。
しかし、この前提が整っていない顧問先は多い。
日本商工会議所が2024年9月に公表した調査（※1）によると、売上高1千万円以下の事業者の92.0%が1人で経理事務を担い、78.1%が代表者や営業担当者が兼務している。こうした事業者から届くのは、紙の領収書・FAXの注文書・Excelのまとめ表・メール添付のPDFだ。
Sansanの調査（※2）では、2024年時点で請求書を「紙中心」で発行している企業は71.0%に上る。受発注でFAXを使う中小企業は約76%というデータもある（※3）。
紙やFAXがあると、話が一段変わる
紙やFAXをデジタルデータに変換するには、スキャン・OCR・データ入力というプロセスが必要だ。顧問先ごとに入口の形が違うため、一律の設計はできない。しかもこれはAIに頼んで解決する問題ではなく、顧問先との業務フローを変える交渉が先に必要になる。
FAXが残り続けている理由もシンプルで、取引先もFAXを使っているため自社だけでは廃止できないという相互依存構造がある。「うちはデジタル化する」と決めても、相手がFAXを送ってきたら受け取るしかない。デジタル化をするにしても結局スキャンするための人員や時間を確保しなければならないし、それは結構大変だ。
事例記事が語る「自動仕訳」は、この入口の整備が終わった後の話だ。
前提2：マスタの下地づくりが思った以上に重い
「ルールを決める」前に整えることがある
入口が整ったとして、次に壁になるのがマスタの問題だ。
「飲食店で1人1万円以下は会議費」というルールを決めても、どの支出が会議費で何人いたかという判定などは、いちいち人間が判断しなければならない。このあたりの判断ロジックについてはAIだけにやらせても信頼が十分におけないため、人間がルールメイクする必要がある。
事例記事は完成したシステムを見せるため、このマスタ整備やルール整備の話が出てこない。だが実際にやってみると、ここの準備に一番時間がかかることが多い。
会計ソフトによって整え方が変わる
さらに、顧問先が使っている会計ソフトによって整え方も変わる。
例えば、freeeはAPIが整備されているが、勘定科目はソフト側で事業所ごとに別管理されているため、連携前に各社のマスタ状況を確認する必要がある。その他の会計ソフトではAPI連携があまり使われていないため、CSVインポートが主流であるが、そのインポートの形式や表記揺れの許容度によっても処理プロセスが変わる。
顧問先の数だけソフトとマスタの状況が違う。「一度作ればあとは自動」というシステムを作る前に、まず顧問先の数だけ状況を整理するという作業が必要になるだろう。
下地づくりはAIが得意な仕事ではない
マスタの整備は判断の連続だ。この取引先は個人か法人か。この勘定科目は既存のものに統合するか新設するか。税区分の設定は正しいか。こうした判断は、税務と業務の両方を知っている人間がやらないと積み上がらない。
AIは「決まったルールを速く正確に処理する」のは得意だ。しかし「ルールの土台を整える」という作業は、知識と判断が必要なため、自動化しにくい。事例記事が見せる「速くなった処理」の前には、この地道な下地づくりがある。
本当に難しいのは「業務をデータとして設計する」ことだ
感覚でやっている業務は言語化が必要
マスタが整ったとして、次に必要なのがルールの言語化だ。
「飲食1万円以下→会議費」というルールは、税理士としての知識があれば正しいと判断できる。しかしシステムに落とすには、条件を言語で定義しなければならない。相手は個人か法人か。社内の関係者への支出か外部への支出か。取引日は当月か前月か。こうした条件を全部拾わないと、誤仕訳が出る。
多くの税理士はこの判断を頭の中で処理が自動化されているが、システムが処理できる形で言語化したことがない。これはプログラミングの問題ではなく、業務設計の問題だ。
会計とITの両方が必要な理由
この設計作業には、会計の知識とシステム設計の知識が両方いる。
会計の知識だけあれば、ルールは正しく判断できる。しかしそのルールをデータの流れとして設計することはできない。ITの知識だけあれば、設計はできる。しかし正しい判断基準を知らない。両方がそろって初めて「業務のデータフローを設計できる」状態になる。
AI活用の事例記事が「現場の知識が重要」と書くのは正しい。だがその知識をシステムに落とす作業こそが最も重く、そこが事例記事にはほぼ出てこない。
まとめ
AI活用の事例は本物だし、効果も本物だ。だが完成品の前に、書かれていないステップがある。
データがきれいな形で届いているか。紙・FAX・混在の状態では、自動化の話は始まらない。マスタの下地が整っているか。ここの準備が実は一番時間がかかる。業務ルールをシステムが扱える形で言語化できるか。この3つが整って初めて、事例記事のような世界が実現する。
「思ったより大変だった」の正体は、たいていこのどこかにある。
関連記事
参考資料
- ※1：中小企業におけるインボイス制度、電子帳簿保存法、バックオフィス業務の実態調査（日本商工会議所、2024年9月公表）
- ※2：請求書の発行に関する実態調査（Sansan株式会社、2024年9月）
- ※3：中小企業の受発注業務に関する調査（帝国データバンク、経済産業省委託、2019年）
