税理士事務所で、小規模な顧問先から毎月届く手書きの現金出納帳を読み取り、仕訳の下書きにして会計ソフトの取込形式にそろえ、残高の合わない行を拾う

処理の起点を決める

担当者が出納帳のコピーを顧問先のフォルダの「出納帳_取込」に保存することを起点にします。 Apps Script の時間主導型トリガーが15分おきに、全顧問先の取込フォルダを順に見ます。ファイル名は「顧問先コード_年月」にし、何月分の出納帳かをファイル名で決めます。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1件で2〜4ページ、Document AI と Gemini API を呼ぶので、1回に3件までとし、残りは次の実行に回します。 処理済みのフォルダへ移すのは、取込形式の下書きと確認の一覧の書き込みまで成功したときだけにします。

月初に預かった分は、預かった日のうちにスキャンします。 1か月分を月の半ばにまとめると、今の打ち込みの集中がそのまま残ります。訪問のときに顧問先の店で預かる場合は、事務所に戻ってからスキャンし、スマートフォンの写真では取り込みません。 斜めの写真は列の位置での割り当てが崩れるためです。

入力データを集める

質を決めるのは、前月の確定した残高です。 検算の起点が出納帳の「前月繰越」の行だけだと、顧問先が繰越を書き間違えた月に、全行が食い違いになります。 起点は前月に担当者が確定した値に置き、出納帳の繰越の行はそれと比べる対象にします。

帳面の列の位置は、表として取れなかったときのために持ちます。 市販の帳面は顧問先ごとに決まっているので、最初の1回に列の境目を登録すれば、翌月からはそのまま使えます。

データの取得方法を決める

読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

位置は、ページの左上を原点とする値で返ります。 表として取れなかったページは、全文のテキストの行ごとに横の位置を見て、登録した列の位置の範囲に当てはめて「入金」「出金」「残高」を決めます。 金額の列を取り違えると入金と出金が逆になるので、範囲の境目に近い数字は column_uncertain の印を付けます。

信頼度は、行ではなく金額の欄ごとに持ちます。 残高が合わない行で、どの欄の信頼度が低いかを見れば、読み取りの誤りか、顧問先の書いた数字そのものの問題かの手がかりになります。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存形式は PDF にします
2. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。複合機を300dpiに設定します
3. 圧縮の確認 … 非可逆の形式は画質と精度を落とすことがあるとされています。「高圧縮」の設定を使いません
4. ページの順の確認 … ページの見出しの年月と、最初の行の月日で順を確かめます
5. 数字の正規化 … 「1,200」「1200」「1.200」のような区切りを除き、全角を半角に直して数値にします。 正規化できない文字が混ざる欄は数値にせず、そのまま残します
6. 書き直しの検知 … 二重線で消した数字の上に書き直した欄は、文字が2つ重なって読まれます。1つの欄に数字の塊が2つあれば overwritten の印を付けます

6番目を軽く見ないでください。 書き直しの欄を1つの数字として読むと、桁が倍になった金額が生まれます。残高の食い違いの原因として、いちばん見つけにくい型です。

AIに処理させる

させるのは、対応表に当たらなかった摘要を、勘定科目の候補に対応付けることだけです。 金額の読み取り、残高の計算、食い違いの判定はさせません。

候補は、顧問先の科目の一覧の中からしか選ばせません。 一覧に無い科目名を作らせると、取込のときに会計ソフトの科目と合わず、取り込みが止まるか、新しい科目が勝手にできます。

3行目がいちばん起きやすい失敗です。 残高の合わない行を見せると、AIは「入金は3,800円の誤りと思われます」と書いてきます。それが正しくても、顧問先が実際に何を書いたかという記録が消えます。 だから、AIには金額も残高も渡しません。渡すのは摘要の文字だけです。

指示内容を固定する

あなたは税理士事務所で、顧問先の現金出納帳の摘要を読み、
勘定科目の候補を付ける立場です。
渡された摘要の文字だけを見てください。推測で埋めないでください。

【やること】
1. 各行の摘要について、下の科目の一覧から勘定科目の候補を1つ選んでください。
2. 下の区分の一覧から、消費税の区分の候補を1つ選んでください。
3. 判断の根拠にした摘要の中の語を basis に写してください。

【厳守事項】
- 科目と区分は、必ず一覧の中から選んでください。一覧に無い名前を作らないでください。
- 摘要だけでは決められないときは undecided にし、ask_client を true にしてください。
  迷ったときに、それらしい科目を選ばないでください。
- 金額、残高、日付については何も書かないでください。
- 取引の内容を摘要の文字以上に補って説明しないでください。
- 同じ摘要の語でも、顧問先の業種によって科目が違うことがあります。
  下の業種を踏まえ、決められなければ undecided にしてください。

【顧問先の業種】{client_industry}
【科目の一覧】{account_list}
【区分の一覧】{tax_class_list}
【摘要（行番号つき）】{descriptions}

「金額について何も書かない」を明記するのは、渡していなくても書くからです。 摘要に「釣銭補充」とあれば、AIは「現金の移動なので残高に影響しない」と添えます。担当者がそれを読むと、検算の結果より先に、AIの説明を信じたくなります。

「迷ったときにそれらしい科目を選ばない」も同じ理由です。 「○○さん 立替」のような摘要は、顧問先に聞かないと科目が決まりません。選ばせると、聞くべき行が確認の一覧から消えます。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、Interactions の response_format に JSON スキーマを渡すと、そのスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。科目の一覧と区分の一覧は、顧問先ごとにスキーマの enum に入れます。

{
  "rows": [{
    "row_no": 0,
    "account": "<科目の一覧の値> | undecided",
    "tax_class": "<区分の一覧の値> | undecided",
    "basis": "",
    "ask_client": false
  }]
}

金額と残高は、このJSONには入りません。 Apps Script が表から作った行の記録と、row_no でつなぎます。

この表が、出力を分けた理由です。 食い違いの型は、金額と信頼度だけで決まる規則で、AIの判断が入りません。client_calc_error は1行だけで計算を誤り、次の行からはその誤った残高を起点に書き続けている型です。差額がその行だけで閉じているか、後ろへ持ち越されているかで、書き間違いか書き漏れかを分けます。

例で見ると分かりやすくなります。 5日の行で顧問先の残高が計算より1,000円少なく、6日の行からは顧問先の残高を起点にすると計算が合う。これは5日の行だけの計算違いです。一方、5日から月末まで計算より1,000円少ないまま続くなら、5日より前に1,000円の出金が書かれていないか、5日の入金が1,000円多く書かれています。前者は担当者が直せ、後者は顧問先に聞くしかありません。

negative_balance は書き漏れの強い手がかりです。 手元の現金がマイナスになることは無いので、その日までに書かれていない入金があるはずです。 公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。科目の候補が一覧の中にあるかも、Apps Script がもう一度確かめます。

システムへ連携する

対応表に当たった摘要は、Gemini API に渡しません。 毎月同じ「○○商店」「電気代」が並ぶ顧問先では、2か月目から AI に渡る行が大きく減ります。 費用と、科目がぶれる余地の両方が減ります。

取込形式の CSV は、担当者が確定の列に印を付けた行だけで作ります。 列の並びは会計ソフトによって違うので、事務所で使っている会計ソフトの取込の説明に合わせて定義を作ります。

人が確認する

人が見るのは、食い違いのある行と、undecided の行だけです。 ok で対応表の科目が当たった行は、一覧で流し見て確定の印を付けます。全行を画像と見比べる設計にすると、第10章の10.0時間には収まりません。

1. ocr_suspect を画像で見る … 読み取りの誤りなら値を直します。直した値で検算をやり直し、ok になるかを見ます
2. client_calc_error を確かめる … 顧問先の書き間違いと確かめたら、正しい残高で仕訳を作り、顧問先への連絡に「○日の残高の計算違い」と書きます
3. possible_omission と negative_balance を顧問先への質問にする … 書き漏れの取引は、事務所で仕訳を作らず、顧問先に聞きます
4. 科目の候補を確定する … undecided と ask_client の行を決め、確定した摘要を対応表に足します
5. 取込用の CSV を作って取り込む … 取り込んだ日時と件数を一覧に残します

3番目を省かないでください。 差額だけ「雑費」や「事業主貸」で埋めれば残高は合いますが、その月の売上や経費が抜けたまま申告の数字になります。 書き漏れの判断は顧問先に確かめてからです。

目標は、40件をならして1件15分です。 食い違いと undecided が全行の1割前後という想定で、それより多い顧問先は、帳面の書き方か列の位置の登録を見直します。

例外に対処する

4行目がいちばん大事な例外です。 繰越を出納帳の値で始めると、顧問先が繰越を1か所書き間違えただけで全行が食い違いになり、本当の書き漏れが埋もれます。

記録を残す

• 元の出納帳の PDF と、預かった日・スキャンした日時
• Document AI が返した Document のJSONの全文
• Apps Script が作った行の記録（読み取り値、数値への変換の結果、信頼度、印）と、検算の過程
• Gemini API に渡した摘要と、返ってきたJSON
• 担当者が直した値・確定した科目と、その日時・担当者
• 顧問先に質問した内容と、その答え

3つ目の検算の過程は、顧問先への説明に使います。 「○日の行で残高が1,000円ずれ、そのまま月末まで続いています」と、行と金額で示せば、顧問先も帳面を見て思い出しやすくなります。

保存の期間は、事務所と顧問先の取り決めで決めます。 国税庁のページでは、個人で事業を行う方の帳簿は法定帳簿が7年、任意帳簿が5年の保存とされています。原本の出納帳は顧問先に返し、事務所のPDFとJSONの扱いを契約で決めておきます。