当サイトではアフィリエイトプログラムを利用して商品を紹介しています。掲載リンクからご購入いただいた場合、当サイトに報酬が発生することがあります。

経理の仕訳を自動化する|摘要辞書とAIと人の三層で、経理担当者と税理士が納得する仕組みにする

月末になると、経理担当者の机に通帳のコピーとカードの明細と領収書の束が集まります。1件ずつ内容を読んで、勘定科目を決めて、会計ソフトに入力する。100件なら半日、300件なら丸2日。しかもその作業の大半は、先月とまったく同じ相手への、まったく同じ支払いです。

この繰り返しを、ルールとAIと人の三層で自動化する仕組みを、設計図から順に説明します。ただし、経理の自動化は営業のそれより慎重に進める必要があります。仕訳は税務申告の元になる記録で、間違いが半年後に見つかることも珍しくないからです。だからこの記事では、AIに任せてよい仕訳と、人が最後に見るべき仕訳の線引きに、いちばん分量を割いています。

この記事でわかること

  • 銀行・カード明細の仕訳を、摘要辞書(自動仕訳ルール)→生成AI→人の確認の三層で処理する仕組み。既存の会計ソフトとスプレッドシートで動き、追加費用はほぼ生成AIのAPI利用分だけ
  • AIに任せてよい仕訳と、人が最後に見るべき仕訳の線引き。経理担当者と税理士の反対にどう答えるか
  • 仕訳を自動化しても外せない、消費税の帳簿記載事項と電子取引データの保存、AIに渡してはいけない情報の線引き

ムダの現状:同じ仕訳を毎月手で入力している

中小企業の経理担当者の月次の作業を分解すると、仕訳入力に使っている時間の多くが「先月と同じ仕訳」に消えています。家賃、通信費、サブスクリプションの利用料、給与、社会保険料、税理士の顧問料。相手も金額も科目も毎月同じなのに、明細を見て、科目を選んで、入力する。300件の明細のうち、判断が要るのは1〜2割というのが実感に近いはずです。

もうひとつの問題は、判断が人に紐づいていることです。「この相手はいつも会議費で切っている」「あの振込は預り金」といったルールが担当者の頭の中にだけあり、担当者が休むと仕訳が止まる。引き継ぎのときに科目がずれて、決算で税理士から差し戻される。会計ソフトの自動仕訳機能を使っていても、ルールを誰も整理していないので、半分は結局手で直している、という会社は少なくありません。

仕訳は3種類に分かれる

自動化の前に、月次の明細を3種類に分けます。この分け方が、そのまま「機械に渡す部分」と「人に残す部分」の線になります。

種類 例 割合の目安 誰がやるべきか
定型 家賃・通信費・サブスク・顧問料・社会保険料 6〜8割 ルール。摘要が一致すれば確定
準定型 初めての相手への少額の支払い、交通費、消耗品 1〜3割 AIが候補、人が確認
判断が要る 固定資産の取得、役員への支払い、前受・前払、返金、高額の取引 数% 人。必要なら税理士に確認

自動化するのは上の2段だけです。3段目まで機械に任せると、経理担当者は「責任だけ残って判断を奪われた」と感じ、仕組みを使わなくなります。そして税理士は、AIが決めた仕訳を丸ごと疑うようになります。この線引きが、あとで出てくる合意形成の土台です。

スキームの全体図:ルール・AI・人の三層

仕組みは三層です。銀行やカードの明細を取り込み、まず摘要辞書(会計ソフトでいう自動仕訳ルール)に照らして定型の仕訳を確定する。辞書に無い明細だけを生成AIに渡して候補を出させる。最後に人が、AIの候補と判断が要る仕訳を確認して、会計ソフトに登録する。

1. 明細の取り込み 銀行・カード連携、またはCSV 2. 摘要辞書で照合(ルール層) 摘要と金額の範囲が一致 → 科目を確定 定型の6〜8割はここで終わる 3. 生成AIが候補を出す(AI層) 辞書に無い明細だけ。科目・根拠・確信度 確定はしない。候補のまま次へ 4. 人が確認する(人の層) AIの候補を承認・修正。判断が要る仕訳はここで起票 修正した内容は辞書に戻す ここは自動化しない 5. 会計ソフトに登録 仕訳CSVの取り込み、または画面で承認 辞書が育つループ 人が直した仕訳を辞書に追加すると 翌月からルール層で確定する
濃い緑が機械、薄い緑が人。AI層は「候補を出すだけ」で、確定は常に人の層で行う

この図でいちばん大事なのは、AI層が「確定しない」ことと、人が直した結果が辞書に戻るループです。AIの候補をそのまま登録する設計にすると、間違いが帳簿に入ったまま気づかれません。逆に、人が直した内容を辞書に足していけば、AIに渡す件数は月を追うごとに減り、3か月もすればAI層はほとんど動かなくなります。AIは辞書が育つまでのつなぎと考えるのが、経理の自動化では安全です。

必要なツールと費用(2026年9月10日時点)

使うのは、いま使っている会計ソフトと、Googleスプレッドシート、Google Apps Script、そして生成AIのAPIの4つです。会計ソフトは新しく契約しません。銀行・カードの明細連携と、仕訳のCSV取り込み、自動仕訳ルールに相当する機能があれば、主要なクラウド会計ソフトはどれでも同じ考え方で組めます。

ツール 役割 費用
会計ソフト(既存) 明細の取り込み、仕訳の保存、申告 既存契約のまま
Googleスプレッドシート 摘要辞書と、確認待ちの一覧 無料
Google Apps Script 辞書の照合、AIへの問い合わせ、CSVの生成 無料
生成AIのAPI 辞書に無い明細の科目候補 入出力の文字数で課金。明細1件は数百文字なので、月に数百件でも各社の料金表の最小単位に近い額。単価は必ず公式の料金表で、確認日つきで見る

会計ソフトの「自動仕訳」機能と、この仕組みの関係

主要なクラウド会計ソフトには、明細の摘要をもとに科目を自動で当てる機能があります。名称はソフトによって違い、条件の書き方や「自動で登録するか、確認待ちにするか」の挙動も違います。この記事の「ルール層」は、その機能をそのまま使っても、スプレッドシートの辞書で代替しても構いません。

それでもスプレッドシートに辞書を持つことを勧めるのは、理由が2つあります。1つ目は、辞書が会計ソフトの外にあると、経理担当者と税理士が同じ表を見ながらルールを議論できること。2つ目は、ソフトを乗り換えても辞書が残ることです。会計ソフトの中にルールを溜め込むと、乗り換えのたびにルールがゼロに戻ります。ソフト側の自動仕訳を使う場合も、辞書の正本はスプレッドシートに置き、ソフトには写しを入れる、という順番にしてください。

導入手順:摘要辞書から始める

導入は5つのステップです。AIから始めないでください。最初に辞書を作ると、AIに渡す件数が最初から少なくなり、確認の負担も費用も小さくなります。

Step 1:過去3か月の明細から摘要辞書を作る

会計ソフトから過去3か月の仕訳をCSVで書き出し、「摘要」と「科目」の組み合わせを数えます。スプレッドシートに貼って、ピボットテーブルで摘要ごとの件数と科目を集計すれば、同じ摘要が毎月出ていて科目も同じもの、つまり定型の仕訳が一覧になります。これがそのまま辞書の初期値です。

辞書のシートは次の5列にします。

列 内容 例
キーワード 摘要に含まれていれば一致とみなす文字列 NTT/サクラインターネット/東京電力
科目 確定させる勘定科目 通信費
税区分 課税仕入10%、8%、対象外など 課税仕入10%
金額の範囲 この範囲を外れたら辞書で確定しない 5,000〜15,000
相手先 帳簿に記載する相手方の名称 東日本電信電話株式会社

金額の範囲を持たせるのが要点です。家賃の摘要が一致していても、金額が倍なら更新料や敷金の可能性がある。範囲を外れた明細は辞書で確定せず、次の層に送ります。こうしておくと「ルールが勝手に間違った科目で登録した」という事故が起きにくくなります。

Step 2:会計ソフトから明細を書き出す

銀行やカードの連携を設定済みなら、会計ソフトの「未登録の明細」をCSVで書き出します。連携していない口座は、ネットバンキングの入出金明細をCSVでダウンロードします。必要な列は、日付・摘要・入金額・出金額・口座名の5つです。この5列にそろえたシートを「明細」タブとして用意します。口座が複数ある場合も、1つの「明細」タブにまとめて、口座名の列で区別してください。口座ごとにタブを分けると、スクリプトも辞書も口座の数だけ増えて、保守が追いつかなくなります。

Step 3:辞書と照合するスクリプト

Apps Scriptで、明細の各行を辞書に照らします。一致した行には科目と税区分と相手先を書き込み、状態を「確定」にする。一致しなかった行は状態を「AI」にして次の層に回す。金額が範囲外の行は「確認」にして、人の層に直接送ります。次のコードは、そのまま貼って動きます。シート名と列の順番だけ、自社の表に合わせてください。

function matchDictionary() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var dict = ss.getSheetByName('辞書').getDataRange().getValues().slice(1);
  var sheet = ss.getSheetByName('明細');
  var rows = sheet.getDataRange().getValues();
  // 明細の列: A日付 B摘要 C入金 D出金 E口座 F科目 G税区分 H相手先 I状態 J根拠
  for (var i = 1; i < rows.length; i++) {
    var r = rows[i];
    if (r[8] === '確定' || r[8] === '登録済') { continue; }
    var memo = String(r[1]);
    var amount = Number(r[2]) || Number(r[3]) || 0;
    var hit = null;
    var outOfRange = false;
    for (var d = 0; d < dict.length; d++) {
      var key = String(dict[d][0]);
      if (key === '' || memo.indexOf(key) === -1) { continue; }
      var min = Number(dict[d][3]) || 0;
      var max = Number(dict[d][4]) || Number.MAX_VALUE;
      if (amount < min || amount > max) { outOfRange = true; continue; }
      hit = dict[d];
      break;
    }
    if (hit) {
      sheet.getRange(i + 1, 6, 1, 5).setValues([[hit[1], hit[2], hit[5], '確定', '辞書: ' + hit[0]]]);
    } else if (outOfRange) {
      sheet.getRange(i + 1, 9, 1, 2).setValues([['確認', '辞書に一致したが金額が範囲外']]);
    } else {
      sheet.getRange(i + 1, 9).setValue('AI');
    }
  }
}

辞書の列は「キーワード・科目・税区分・金額の下限・金額の上限・相手先」の順を想定しています。初月は「AI」と「確認」が3割くらい出ますが、Step 5のループで辞書に戻していくと、翌月には1割台まで落ちます。

Step 4:辞書に無い明細だけAIに候補を出させる

状態が「AI」の行だけを、生成AIのAPIに渡します。ここで守ることは3つです。1件ずつではなく、まとめて渡す(費用と時間が減る)。自社の科目一覧と辞書の内容を一緒に渡す(一般論の科目ではなく、自社の使い分けに沿った候補が返る)。確信度と根拠を返させる(人が確認するときの手がかりになる)。渡す指示文は、次の型で十分です。

あなたは中小企業の経理担当者を補助する役割です。
次の「科目一覧」と「辞書」に沿って、各明細の勘定科目と税区分の候補を出してください。
確定はしないでください。人が確認します。
出力は明細ごとに1行、次の形式で返してください。
明細番号 | 科目 | 税区分 | 確信度(高・中・低) | 根拠(30字以内) | 人が確認すべき点
判断できない場合は科目を「不明」にし、確信度を「低」にしてください。
固定資産・役員・前受・前払・返金・10万円以上の取引は、必ず「人が確認すべき点」に理由を書いてください。
■科目一覧:
(自社で使っている勘定科目と、使い分けの注意を貼る)
■辞書(参考):
(辞書シートのキーワードと科目を貼る)
■明細:
(番号 | 日付 | 摘要 | 金額 の形で貼る)

APIの呼び出しは、Apps Scriptの UrlFetchApp から各社のエンドポイントに送るのが一般的ですが、生成AIの管理画面に上の文をそのまま貼って結果をシートに戻す運用でも、月に数百件なら十分に回ります。最初はAPIを組まず、手で貼る運用から始めて、件数と効果を見てからスクリプト化するほうが、経理担当者の納得が得やすいです。

Step 5:人が確認し、直した内容を辞書に戻す

「AI」と「確認」の行を、経理担当者が見ます。AIの候補が正しければ状態を「確定」に、違えば科目を直して「確定」にする。このとき、直した内容を辞書に1行追加するのを忘れないでください。ここがこの仕組みの心臓部で、辞書に戻さないとAIに渡す件数がいつまでも減りません。

「確定」になった行は、会計ソフトの仕訳CSVの形式に整えて取り込みます。取り込み形式はソフトごとに違うので、ソフトのヘルプで「仕訳のインポート」の列順を確認して、Apps Scriptで並べ替えて書き出します。取り込みの前に、必ず日付の範囲と件数と合計額を、明細の合計と突き合わせてください。件数が合わないまま取り込むと、二重登録の原因になります。

現場の合意の取り方:経理担当者と税理士

ここからが本題です。経理の自動化で反対するのは、経理担当者と税理士の2者です。営業の自動化と違って、どちらも「間違いの責任を負う立場」なので、反対の理由はもっともです。だから、説得ではなく設計で答える必要があります。

誰が 反対の中身 設計で答える
経理担当者 「AIが間違えても責任を取るのは自分」 AIは確定しない。確定は常に担当者。確定の履歴(誰が・いつ)を残す
経理担当者 「自分の仕事が無くなる」 減るのは入力で、増えるのは辞書の設計と例外の判断。役割の変化を先に言葉にする
税理士 「AIが決めた仕訳は信用できない」 辞書の表を税理士と一緒に作る。税理士が承認した辞書だけがルール層で確定する
税理士 「チェックの手間が増える」 状態列で「辞書/AI/人」の由来が分かる。税理士はAI由来と人由来だけを見ればよい

反対1「責任は自分に来る」に、履歴で答える

経理担当者の反対でいちばん多いのは、責任の所在です。これに「AIは精度が高いから大丈夫」と答えてはいけません。精度の話をした瞬間に、担当者は「間違えたときに自分が責められる」と確信します。答えは設計です。AIは候補を出すだけで確定しない。確定するのは担当者で、その履歴が残る。つまり、いまと責任の所在は変わらず、入力の手間だけが減る。この説明を、仕組みの画面を見せながら行います。

あわせて、役割の変化を言葉にしておきます。減るのは入力で、増えるのは辞書の設計と例外の判断です。辞書を育てる仕事は、経理担当者にしかできません。「入力係」から「ルールを設計する人」へ役割が変わる、という位置づけを、上司の口から伝えてもらってください。

反対2「税理士が嫌がる」に、辞書の共同作成で答える

税理士の反対は、AIそのものより「知らないところで仕訳のルールが変わること」に向いています。だから、辞書の表を税理士と一緒に作ります。過去3か月の集計を持っていき、「この摘要はこの科目で確定してよいか」を1行ずつ確認してもらう。税理士が承認した行だけを辞書に入れる。これで、ルール層の仕訳は税理士が決めたものになります。

AI層についても、「AIの候補は必ず人が確認してから登録する」「状態列で由来が分かるので、税理士はAI由来の行だけを重点的に見ればよい」と伝えます。チェックの範囲がむしろ絞られる、と分かれば、多くの税理士は反対しません。

渡す順番

順番を間違えると、正しい設計でも定着しません。最初に、過去3か月の集計を経理担当者と一緒に見て、定型の割合を確認する。次に、辞書の初期値を担当者に作ってもらう(作ってあげない)。それを税理士に確認してもらう。ルール層だけで1か月回して、確定した仕訳に間違いが無いことを確認する。AI層を足すのは、その後です。AIは最後に足す。この順番だけで、反対の大半は出なくなります。

失敗パターンと限界:帳簿の記載事項・電子データの保存・AIに渡してはいけない情報

経理の自動化で「効率化したつもりが、あとで高くつく」のは、たいてい次の3つのどれかです。

失敗1:AIが要約した摘要で、帳簿の記載事項が欠ける

消費税の仕入税額控除を受けるための帳簿には、法定の記載事項があります。国税庁のタックスアンサー(No.6497、令和7年4月1日現在の法令に基づく)では、課税仕入れについて、相手方の氏名または名称、年月日、資産または役務の内容、支払対価の額を帳簿に記載することとされています。

AIに摘要を「読みやすく要約」させると、ここが欠けます。銀行の摘要にある相手方の名称を「通信費」とだけ書き換えてしまえば、記載事項を満たさない帳簿になりかねません。対策は単純で、AIには科目と税区分の候補だけを出させ、摘要そのものは元の明細の文字列を保つことです。辞書の「相手先」列を帳簿の相手方として使い、AIに摘要を書かせない。この線を最初から引いておいてください。

失敗2:電子取引のデータを保存せずに捨てる

請求書や領収書をメールやウェブで受け取った場合、電子帳簿保存法により、その電子データの保存義務が定められています。仕訳を自動化する過程で、明細だけをスプレッドシートに集めて元のPDFやメールを整理せずに消してしまう、という事故が起きます。自動化の対象は「仕訳の判断」であって、「証憑の保存」は別の要件として残ります。保存の方式や検索の要件は改正されることがあるので、国税庁の電子帳簿等保存制度の特設サイトで、その時点の要件を確認してください。

失敗3:AIに渡してはいけない情報を渡す

明細には、取引先の名称、個人名、口座番号、給与の額が含まれます。生成AIのAPIに渡す前に、必ず各社の利用規約とデータの取り扱い方針を確認してください。特に「入力データを学習に使うか」「保存期間」「事業者向けの契約か個人向けの契約か」の3点です。個人向けのチャット画面に給与明細を貼る運用は、たとえ便利でも避けるべきです。渡す前に、口座番号と個人名を伏せる処理をスクリプトに入れておくと安全です。

この仕組みが向かない条件

月の明細が50件に満たない会社は、辞書を作る手間のほうが大きい。会計ソフトの自動仕訳機能をきちんと設定するだけで足ります。逆に、明細が月に数千件を超える会社や、複数の事業部で科目の使い分けが複雑な会社は、スプレッドシートとApps Scriptでは処理時間の上限に当たります。その規模なら、会計ソフト側の機能か、専用の仕訳自動化サービスを検討するほうが早いです。

効果の測り方

見る数字は3つです。

指標 見方 目安
辞書で確定した割合 状態「確定」のうち根拠が「辞書」の件数 ÷ 全明細 初月5〜6割 → 3か月目に8割
AIの候補が修正された割合 人が科目を直した件数 ÷ AIに渡した件数 2割を超えるなら、渡している科目一覧か指示文を見直す
税理士からの差し戻し件数 月次・決算で指摘された仕訳の数 導入前より減っていること。増えたら辞書に誤りがある

入力時間の削減だけを見せると、経理担当者は「自分の仕事を減らされた」と受け取ります。税理士からの差し戻しが減ったこと、月次の締めが早まったことを、一緒に見せてください。それが担当者の成果として社内に伝わる形が、仕組みを続けさせます。

まとめ

経理の仕訳は、摘要辞書(ルール層)、生成AI(AI層)、人(確認の層)の三層で自動化できます。定型の6〜8割は辞書で確定し、辞書に無い明細だけAIが候補を出し、確定は常に人が行う。人が直した内容を辞書に戻すループがあれば、AIに渡す件数は月ごとに減っていきます。

導入の順番は、辞書 → ルール層だけで1か月 → AI層、の順。AIは最後に足します。経理担当者には「確定は自分、履歴が残る」で答え、税理士には「辞書を一緒に作る」で答える。帳簿の記載事項、電子取引データの保存、AIに渡す情報の3つの線は、最初に引いておく。この順番と線引きを守れば、仕組みは半月で動き、3か月で現場に定着します。

よくある質問

会計ソフトの自動仕訳機能があれば、スプレッドシートの辞書は不要ではありませんか

ルール層としては、どちらでも構いません。スプレッドシートを勧めるのは、経理担当者と税理士が同じ表を見て議論できることと、ソフトを乗り換えても辞書が残ることの2点です。ソフト側の機能を使う場合も、辞書の正本はスプレッドシートに置き、ソフトには写しを入れる順番にしてください。

AIの候補をそのまま登録してはいけませんか

いけません。AIは確定しない、という線がこの仕組みの土台です。候補をそのまま登録すると、間違いが帳簿に入ったまま気づかれず、経理担当者と税理士の信頼を失います。確認の手間が惜しいなら、辞書を育ててAIに渡す件数を減らすのが正しい方向です。

生成AIのAPIは、どの会社のものを使えばよいですか

どれでも組めます。選ぶ基準は精度より、事業者向けの契約で入力データを学習に使わない設定ができるか、保存期間が明示されているか、料金表が公開されているかの3点です。各社の利用規約と料金表を、確認日を控えて読んでください。

領収書や請求書の画像から仕訳を起こすことはできますか

できますが、この記事の仕組みとは別の層です。画像の読み取り(OCR)は誤読が混ざるため、明細の自動仕訳より人の確認が多く要ります。まず銀行・カード明細で三層を回し、辞書が育ってから画像に広げる順番を勧めます。

税理士に反対されたら、どうすればよいですか

辞書の表を持って行き、1行ずつ確認してもらってください。税理士の反対は「知らないところでルールが変わること」に向いているので、ルールを一緒に決める形にすれば、多くは解消します。AI層は、税理士が承認した後に足します。

月の明細が少ない会社でも意味がありますか

月50件に満たないなら、辞書を作る手間のほうが大きいです。会計ソフトの自動仕訳機能を丁寧に設定するだけで足ります。件数が増えて担当者が月末に残業するようになった時点で、この仕組みに移ってください。

部門ごとの自動化スキームを、1つずつ

営業・経理・人事総務・サポート・現場。部門ごとに、1つのムダを消す設計図と、現場の合意の取り方を書いています。

スキーム一覧を見る

同じ部門の記事だけを追うなら、経理・請求の記事一覧からたどれます。

上部へスクロール