税理士法人の社内DX実録④｜税理士は毎月の帳簿のどこを見る？マネーフォワード連携の自動チェックとAIの2階建て

税理士事務所の月次業務の中心は、顧問先の帳簿を毎月確認することです。残高はおかしくないか、税区分は合っているか、前月・前年と比べて説明のつかない増減はないか。決算期には、決算書類や申告書のチェックも加わります。社内では「月次監査」と呼んでいますが、公認会計士が行う会計監査とは別のものなので、この記事では「月次の確認」と書きます。

この仕事は経験に左右され、同じ帳簿でも人によって気づく点が違います。そこで当法人は、この「見る」工程を2階建てに作り替えました。1階はマネーフォワード クラウド会計と連携した自動チェックのスプレッドシート、2階はその結果を税理士の判断基準で読み解くAIです（以下、マネーフォワード クラウド会計をMF、同社のクラウド経費・クラウド債務支払をMF経費・MF債務支払と書きます）。

本記事は社内DX実録の第4回です。シリーズでは、当法人がAIコーディングツール「Claude Code」と一緒に社内の業務システムを作り替えてきた過程を、実際の数字と失敗談を含めてお伝えしています。前回は、自動化で起きた事故と、壊れにくい設計に変えるまでを紹介しました。今回は、社内でいちばん規模の大きい仕組みの話です。

MFなどのクラウド会計をお使いで、「顧問税理士は毎月の帳簿のどこを見ているのか」「AIを使うと何が変わるのか」を知りたい経営者・経理ご担当者の方に向けた記事です。前半でお客様にとっての変化とチェックの中身を、後半で動かして分かった失敗と直し方を紹介します。

全体像：1階が絞り込み、2階のAIが判断の下書きを作る

GASは、Googleのスプレッドシートなどを動かすプログラムです。APIは、ソフト同士がデータをやり取りする窓口です。

大事なのは、2階は1階のチェックをやり直さないことです。機械でできる照合は機械が受け持ち、AIは「その検出をどう判断するか」だけに集中します。役割を混ぜると、どちらも中途半端になります。

なぜ2階建てにしたのか：AIの使いどころを絞る「トークンマネジメント」

AIは急速に賢くなり、帳簿の確認も「全部AIに任せる」ことが技術的には見えてきました。それでも当法人は、あえてAIの使いどころを絞っています。理由は、AIの利用料の先行きです。

AIの利用料は、やり取りする文章の量（トークン）に応じて決まります。AIを提供する大手企業の多くが大きな赤字を計上していると報じられている状況を見ると、いつかトークンの単価が上がる、あるいは性能の高いAIを今の条件では使えなくなる、というリスクがあると考えています。帳簿の確認のように毎月・全社で繰り返す仕事をAIに丸ごと預けてしまうと、そのときに費用が跳ね上がるか、仕組みそのものが止まります。

そこで、次の役割分担で設計しています。

• 定型的な処理は、できるだけ確実に安価に動くプログラム（GAS）に任せる。 金額・摘要・税区分・重複・消込のように、ルールに書き下せる照合は、全社でほぼ共通の仕訳チェックとしてGASが行います。何度動かしても結果が同じで、費用はほとんどかかりません
• AIは、プログラムで実現することが難しい部分を主に担当する。 検出された仕訳をその会社の事情に照らして判断する、やり取りの文脈と帳簿を突き合わせる、報告書の文章を書く、といった部分です

社内ではこれを「トークンマネジメント」と呼んでいます。AIに渡す文章の量を、AIにしかできない部分に絞ることで、費用を抑えるだけでなく、AIの条件が変わっても1階の自動チェックはそのまま動き続けます。

AI側で顧客ごとに何を確認させるか、GAS側で全社共通として何をチェックさせるかは、固定したものではありません。AIに頼んでいた判断のうち、ルールに書き下せると分かったものは1階に下ろし、1階で拾えなかった見落としはAIの判断基準に足す。この行き来を、日々の運用の中で繰り返しています。

お客様にとっての変化：毎月同じ観点で確認し、決算の論点も月次で

MFをお使いで、この仕組みで毎月の確認を行っている顧問先では、次のようになります。

• 毎月、同じ観点で帳簿を確認します。 金額の大きい仕訳、摘要の未入力、税区分の相違、重複仕訳、売掛金・買掛金の消込などを、担当者の経験に左右されにくい同じルールで拾います。消込は、入金や支払いがどの請求に対応するかの突き合わせです
• 大きく動いた科目を、月次の段階で確かめられます。 月次平均に対して±20%以上、かつ差額1万円以上動いた科目を、推移表（月ごとの金額を並べた表）から拾います
• 決算期に見つかりがちな論点が、月次の段階で挙がります。 来期の消費税の課税方式（原則課税か簡易課税か）を検討すべき時期と届出の期限、期ズレ、未払の漏れなどです。期ズレは、売上や経費が本来とは違う月・期に計上されることです
• 前月に指摘した点のその後を、翌月の確認の最初に追いかけます。 検出→判断→報告の流れが記録に残るためです

月次の確認は、当法人の顧問契約の全プランに含まれます。顧問契約では、記帳のチェックから決算・税務申告までを担当します。この記事で紹介した自動チェックは、マネーフォワード クラウド会計をお使いの会社が対象です。

帳簿づくりの作業そのものまでお任せいただく場合は、顧問契約とセットでご提供する経理代行プランをご用意しています。このプランでは、AIで処理できない取引の入力や修正、残高の照合、月次の締めといった作業までお任せいただけます。

1階の自動チェック：毎月決まった日に、11のステップで絞り込む

月次の確認用の管理シートに顧問先を登録し、実行をオンにしておくと、決められた日に時間トリガーで次の処理が進みます。時間トリガーは、決めた時刻にプログラムを動かすGoogleの機能です。

1. その会社の設定シートを作る
2. MFから仕訳・残高・推移表を一括で取得する
3. 勘定科目・取引先などの一覧（マスタ）を取得する
4. 前期比較レポートを作る
5. 仕訳をチェックする（科目ごとに決めた金額を超える仕訳、摘要の未入力、税区分の相違、重複仕訳）
6. 売掛金・買掛金の消込を確認する（1対1の照合に加えて、複数の入金を合算して一致するかも探す）
7. 勘定科目別の税区分の集計表を作る
8. MF経費の、期末の未払経費を抽出する
9. MF経費の、期間外の経費を抽出する
10. MF債務支払の、期末の未払債務を抽出する
11. MF債務支払の、期間外の債務を抽出する

8〜11は、MF経費・MF債務支払をお使いの会社だけで行います。

最後に結果を「月次レビュー結果」シートにまとめ、社内のBacklog（タスク管理ツール）に、その会社の月次の確認のタスクとして起票します。このまとめの処理の中では、上の「お客様にとっての変化」で触れた「大きく動いた科目」を推移表から拾う処理（以下、月次の異常検出）も動きます。

決算期には、担当者が画面のボタンから次の2つを実行します。

• 決算書類（残高証明書・固定資産台帳・借入金返済予定表など）のAIによるチェック
• 申告書の、税制の適用漏れのチェック（22項目）

2階のAI：検出結果を仕分けて、報告書の下書きを作る

1階の検出結果は、そのままでは「数字が並んだシート」です。担当者がAI（Claude Code）に「この会社の9月分」のように頼むと、2階が次の順で進めます。2026年10月からは、社内のBacklogの課題をAIに割り当てて頼む形でも動かしています（第5回で紹介します。近日公開）。

1. その会社の月次の確認用のスプレッドシートを特定し、事業者番号（MFが会社ごとに付けている番号）で照合する。別の会社のデータを読まないための照合です
   • 対象の月のシートがまだ無ければ、AIが1階に作成を依頼する
   • 出来上がったシートは、他の会社の名前が無いこと、貸借対照表・損益計算書の合計がMFの試算表と一致することを確かめてから使う
   • 確かめた点が1つでも合わなければ、そこで止めて人に返す
2. 前月の確認の記録があれば、前回の指摘がどうなったかを確認する
3. 1階の検出事項を1件ずつ、重要度と判断区分で仕分ける
4. 貸借対照表の残高、損益計算書、消費税の論点、期ズレ・計上漏れ、定期的な支払いとの照合を見直す
   • あわせて、その会社とのやり取り（Backlogの課題のテキスト）やWebMTGの議事録に書かれた内容と、帳簿の仕訳が整合しているかを確かめる。たとえば「来月から新しい取引先と契約する」「設備を買い替える」と話していたのに、帳簿にその動きが無い、あるいは逆に、聞いていない大きな取引が計上されている、といった食い違いを拾う
   • 読むテキストが別の会社のものと混ざっていないかは、帳簿と同じように、その会社の事業者番号・プロジェクト・フォルダで確かめてから使う
5. 重要度「高」の項目を深掘りする
6. 報告書の下書きを作る
7. 社内で確認する（頼み方で流れが違う）
   • 担当者が直接AIに頼んだとき：担当者が下書きを確認して承認してから、報告書をその顧問先のフォルダに保存し、社内のチャットに知らせる
   • Backlogで頼んだとき：その依頼そのものを、作業を進めてよいという承認とみなす。報告書（Excel）はBacklogの社内の課題に添付し、依頼した担当者が確認する

判断基準は、「貸借対照表の残高レビュー」「消費税」など項目ごとにMarkdown（文書の書式の一つ）で書いています。合計で約2,100行です（2026年10月時点）。

たとえば消費税なら、決算月の3か月前から決算月までの確認で、次のような点を見ます。

• 基準期間の課税売上高から、来期の課税方式を検討すべきかを判定する
• 検討する場合は、原則課税と簡易課税の有利・不利の試算と、届出の要否・期限を、月次のフォロー項目に載せる
• インボイスの経過措置や2割特例の適用条件を確認する

どちらの方式にするかは、試算をもとに税理士がお客様と決めます。

AIに守らせている規律：もっともらしく書かせない

AIに判断の下書きをさせるとき、いちばん気を使ったのは「もっともらしく書かない」ことです。ルールとして次を固定しています。

• 出典のない数値を書かない。推測で数値を補わない。 分からなければ「【要確認】」と書く
• 「問題なし」と判断するときは、その理由も書く
• エラーで終わったチェックや、実行されなかったチェックは、該当がゼロでも報告書に書く。調べられなかったことを「異常なし」と書かないためです
• 営業日の判定に必要な祝日データが取得できなければ、推測せず「【要確認】」にする
• 重要度（高・中・低）や判断区分の言葉を、同義語で言い換えない。報告書の版ごとに表現が揺れると、読む側が比較できなくなるためです
• お客様に届く連絡は、AIからはしない。報告書は社内で担当者・税理士が確認してから、お客様にご説明する

「AIが賢いかどうか」より、AIが黙って推測しないための約束事が、実務ではずっと重要でした。

帳簿のデータをAIで扱うときの取り決め

顧問先の情報をAIサービスで扱う場合は、法人向けのプランまたは有料のサービスを、入力した情報をAIモデルの学習に利用しない設定又は契約のもとで利用しています。マイナンバー（個人番号）はAIサービスに入力しません。取り決めの全体はAIの活用についてにまとめています。

動かして分かった失敗：止まったら気づく、推測で直さない

この仕組みは、作るより「安定して動かし続ける」ほうが難しいものでした。お客様の帳簿に関わるので、失敗も含めて書きます。どれも「黙って失敗しない」「推測で補正しない」ための直しです。

「1時間に1回」の制約で、3社分の処理が抜け落ちた

GASをGoogleのアドオン（スプレッドシートに組み込んで使う社内ツール）として動かす場合、時間トリガーは1時間に1回までという制約があります。ある日、1社目の処理に4分54秒かかり、1回の実行で使える時間を使い切りました。残り3社を次のトリガーに引き継ごうとしたところ、Googleに拒否されました。

問題は、拒否されてエラーが出たこと自体より、残り3社の処理が、通知も記録（ログ）も残さずに抜け落ちたことです。しかもこの引き継ぎの経路は、本番で一度も動いたことがありませんでした。それまでトリガーが123回すべて「今日は該当なし」で終わっていたためです。

今は、新しいトリガーを作って引き継ぐのをやめ、毎時1本のトリガーが「回せるだけ回し、残りは次の回が拾う」形にしました。どこまで終わったかは管理シートの最終実行日時とステータスから読み直すので、途中で止まっても続きから進みます。1時間以上「実行中」のまま止まった会社は、「中断（要確認）」として人の確認に回します。

見やすくした変更で、異常の検出が約7週間止まっていた

2026年8月末、帳票の金額に桁区切りを付けて読みやすくしました。ところが、推移表の「2026年2月」のような月の見出しにもその書式がかかって数値に変わり、月次の異常検出が対象の月を見つけられなくなりました。

10月に直すまでの約7週間、この処理は毎回「抽出エラー」で終わり、この観点の指摘は1件も出ていませんでした。社内のBacklogに起票される本文でも、エラーの中身が意味の読めない文字列で表示されていたため、気づくのが遅れました。

10月、月次の確認を進める中で、「エラーで終わったチェック」として報告に挙がっていたことから見つかりました。原因は直し、その間に作ったシートも、作り直さずに異常検出をやり直せるようにしています。

上の規律のとおり、2階のAIには「エラーで終わったチェックは、該当がゼロでも報告書に書く」と決めてあります。「見つからなかった」と「調べられなかった」を取り違えないことが、この仕組みでいちばん大事にしている約束です。

番号で照合するはずが、会社名の一致だけで通っていた

このツールで扱ってよい顧問先かどうかを、MFの事業者番号で照合するつもりでした。ところが、こちらの登録一覧では番号が数値として保存され、ハイフンと先頭の0が落ちていました。

そのため番号での照合は1件も成立せず、登録していたすべての会社が、会社名の一致だけで通っていたことが分かりました。照合を厳格に運用する前に見つかったのが救いでした。今は番号から記号を除き、桁数をそろえてから照合しています。

【画像読み取り機能】途中で止まった処理が、仕訳の二重登録を招くおそれがあった

ここからの2つは、月次の確認とは別の機能の話です。同じアドオンにある、通帳や領収書などの画像を読み取って仕訳を作り、MFに登録する機能です（月次の確認の仕組みは、MFの帳簿に書き込みません）。

画像の読み取りと登録は、時間を区切って少しずつ進めます。区切りの途中で処理が強制的に打ち切られると、画面の側が同じデータで自動的にやり直し、MFに仕訳が二重に登録される（＝帳簿の二重計上）おそれがありました。コードの見直しで分かったことです。

今は、次の3段構えで二重登録を起こしにくくしています。

• 登録が確定した分は、すぐ処理対象から外す
• 送信の直前に処理中の印を立て、印が残っていたら自動では送り直さず要確認に回す
• 時間切れが近ければ送信を始めない

なお、毎月の1階の仕訳チェックでも、重複仕訳は確認の対象にしています。

【画像読み取り機能】AIの「自信」は、読み取りの正しさを保証しない

通帳や領収書の読み取りには、Googleの生成AI「Gemini」を使っています。ただ、モデルが返す「確からしさ」の値は文章の流暢さの指標であって、読み取りが正しいことを保証しません。実際、全項目が埋まっていても取引先名が揺れる例がありました。

今は、印字残高の増減と入出金の向きを検算することを主軸にしています。入出金が逆に読まれていれば、自動で反転します。ただし、確定できない不整合は補正せず、警告に回します。「誤った補正は誤った登録と同罪」という方針です。

freee会計向けにも移植中：MF固有の前提が見えてきた

同じ仕組みを、freee会計向けにも移植しています。移植して初めて「MF固有の前提だった」ことが見えるのが、面白いところです。

• 税区分のチェックは、freeeのほうが堅牢に作れた。 MFでは税区分の略称と正式名称を名前で突き合わせる必要がありましたが、freeeはコードで照合できます
• freeeには補助科目がないので、補助元帳を「勘定科目×取引先」で作り直しました
• 固定資産の種類コードが判定できない明細は、無理に既定値を当てず、CSVに出さないようにしました。種類コードを間違えると耐用年数まで間違うので、人が仕分けるほうが安全です

Claude Codeとの分担で効いたこと

規模を書いておくと、2026年10月時点で次のとおりです。

• GASのコード：約100ファイル・約8万行
• 自動テスト：約100本
• これまでの変更の記録（コミット）：約480回

この記事の下書きを書いた2026年8月には約6万1千行だったので、運用しながら2か月で3割ほど増えたことになります。規模が大きいぶん、AIとの付き合い方も変わりました。

ルールブックが「設計台帳」になった

Claude Codeに渡すルールブック（CLAUDE.md）は、約260KBになりました（2026年10月時点。8月は約120KB）。ファイルごとの役割、壊してはいけない前提、そして上に書いたような事故の実測値が、日付付きで書いてあります。

記録の一例を挙げます。マスタの一括取得に93秒かかっていたので調べたところ、実作業は20秒でした。約73秒（78%）は、進捗ログを送る待ち時間でした。ログを1行送るたびに1.5秒待っていたためで、送り先を変えて解消しました。

別のAI用に同じ内容を複製していた時期があり、片方だけ更新されて193行ずれたことがありました。今は1か所にしか置かず、もう一方はそこへの案内だけです。

テストを「規約の番人」にした

「列の番号を直書きしたら失敗するテスト」「結果のログを進捗ログに混ぜたら失敗するテスト」のように、過去の事故を繰り返さないためのテストを置いています。半年後にAIが「ここは簡略化できそう」と提案しても、テストが止めてくれます。

個人情報の混入を機械で見張る

AIは、作業ログや例をコードに書き込むことがあります。そこで、コードを共有の保管場所（リポジトリ）に送る前にチェックを走らせています。社内ドメインのメールアドレスやスプレッドシートIDのパターンを検出して止めるチェックです。

4回に共通するのは「AIに何をさせないか」を先に決めたこと

ここまで4回にわたって、当法人の社内システムを紹介してきました。共通しているのは、「AIに何をさせるか」より「AIに何をさせないか」を先に決めたことです。

• 判定できないファイルは動かさない（第1回）
• 削除は自動でやらない（第3回）
• 出典のない数字を書かせない。調べられなかったことを「異常なし」と言わせない（第4回・本記事）

この考え方は、お客様のバックオフィスをクラウド化・自動化するバックオフィスDX化支援にも、そのまま持ち込んでいます。

次回（第5回・近日公開）は、ここまでの仕組みを「AIが使う側」に回した話です。担当者がBacklogの課題をAIに割り当てると、AIが申告ソフトへの入力や仕訳のチェックを進め、「人が確認すべき点」とあわせて報告します。その報告を税理士が確認する仕組みを紹介します。

シリーズ

1. e-Taxの控えを共有ドライブへ自動振り分けし、Backlogで報告する仕組み
2. AppSheet（スプレッドシート）×GAS×Backlogで顧問先管理とタスク起票を自動化した話
3. 自動化で起きた3つの事故と、壊れにくい設計に変えるまで
4. 税理士は毎月の帳簿のどこを見る？マネーフォワード連携の自動チェックとAIの2階建て（本記事）
5. Backlogで頼むと、AIが申告書の入力と仕訳チェックを進め、税理士が確認する仕組み（近日公開）