顧問先から届く通帳の写しを読み取って、会計ソフトに取り込む仕訳の候補にする

処理の起点を決める

受付用フォルダを定時実行で見に行き、新しいファイルがあれば処理します。 事務所の業務時間中に1時間おき程度を想定します。通帳の写しは月初にまとまって届きますが、急ぎの仕事ではないので、保存した瞬間に動かす必要はありません。

処理の単位は「顧問先・口座・月」の1束です。 スマートフォンの写真は1ページ1ファイルで届くので、受付用フォルダの下に束ごとのフォルダを切り、その中のファイルをまとめて1束として扱います。 フォルダ名に顧問先コード、口座の識別名、対象月を入れる決まりにします。

処理が終わった束は処理済みフォルダへ移します。 移すのは最後まで成功したときだけです。受付用フォルダに残っている束の数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 前月の最終残高が無いと、束の最初の行を検算できません。対応表が無いと、すべての行がAIに渡り、付け方が前月とそろわなくなります。

科目の一覧を渡すのは、存在しない科目を作らせないためです。 顧問先によって「支払手数料」を「振込手数料」として分けていることがあり、一覧の外の名前が出ると、会計ソフトの取り込みで止まります。

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

読み取りは、スクリプトから Form Parser を呼ぶだけです。 返ってくる結果の中から、次のものを取ります。

セルの文字は、そのまま入っているわけではありません。 textAnchor の textSegments が startIndex と endIndex で文書全体の本文を指しているので、その範囲を本文から切り出して値にします。 Form Parser の表は行や列をまたぐセルを認識しないため、rowSpan と colSpan は常に1です。

列の意味は、見出し行の文字で決めます。 銀行によって「お支払金額」「お引出し」「出金」と呼び方が違い、列の順番も違います。見出しの呼び方を列の意味に対応させる一覧を、銀行ごとに持ちます。 見出し行の無いページは、前のページの列の並びを引き継ぎます。

前月の最終残高は、前月の処理結果として保存しておいたものを読みます。初めての口座は、担当者が前月末の残高を手で入れます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、GIF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます。iPhone の写真で多いHEICは一覧に無いため、JPEGに変換してから送ります
2. 解像度の確認 … スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされています。下回るものは読み取りに進まず、撮り直しを頼む一覧に入れます
3. ページの並べ替え … 写真のファイル名や撮影日時の順に並べます。順番は後の検算で確かめ直すので、ここでは仮の順番で構いません
4. ページ数の確認 … 同期処理は15ページまでです。超える束は15ページごとに分けて送ります
5. 表の整形 … 金額から「円」「¥」「*」「,」を取り除き、数字だけにします。日付は和暦の略記（06-07-12 など）を西暦の日付に直します
6. 行の種類の判定 … 「繰越」「前ページより」「合計」「おまとめ記帳」を含む行に印を付けます。これらは取引ではないので、仕訳にはしません
7. 重複の検知 … 同じ口座・同じ月の束が二度届いていないかを確かめます

2番目を軽く見ないでください。 スマートフォンの写真は画素数が多くても、通帳の1行の文字は小さく写ります。解像度が足りない写しは、検算が合わない行を大量に出し、人の確認を増やすだけです。

6番目の「おまとめ記帳」は、特に注意が要ります。 通帳の記帳をしばらくしないと、未記帳の取引が合計1行にまとめて印字されることがあります。検算は合いますが、中身の取引が分かりません。 仕訳にせず、明細を顧問先へ頼む一覧に入れます。

AIに処理させる

させるのは、対応表で引けなかった摘要について、勘定科目の候補とその理由を書くことだけです。 読み取りと検算は、AIより前に終わっています。

預金の側の科目は、スクリプトが決めます。 出金なら貸方が普通預金、入金なら借方が普通預金です。AIが選ぶのは相手側の1つだけなので、借方と貸方を取り違える失敗が起きません。

match_type を3つに分けるのが大事な区別です。 対応表に近い摘要があったか、摘要から推し量ったか、手がかりが無いかで、担当者の確認の重さが変わります。

1行目がいちばん起きやすい失敗です。 検算が合わない行をAIに渡して「直して」と頼むと、残高が合うように数字を書き換え、それらしい理由まで付けて返します。 読み間違いは消えず、見つけにくくなるだけです。だから、合わない行はAIに渡しません。

指示内容を固定する

あなたは税理士事務所で、顧問先の通帳の明細に勘定科目の候補を付ける立場です。
渡された明細はすべて、残高の検算を通って金額が確定したものです。
あなたが決めるのは、普通預金の相手側に来る勘定科目の「候補」だけです。

【渡すもの】
- 明細：行番号、日付、摘要、出金額、入金額
- 対応表：この顧問先の過去の仕訳から作った「摘要 → 勘定科目・補助科目・税区分」
- 科目の一覧：この顧問先が使っている勘定科目の名前

【match_type の選び方】
- table_similar … 対応表に、表記の違いを除いて同じ相手と読める摘要がある
- inferred ...... 対応表には無いが、摘要の内容から科目を推し量れる
- no_match ...... 手がかりが無く、候補を出せない
迷ったときに table_similar を選ばないでください。

【厳守事項】
- 金額・日付・摘要を書き換えないでください。渡された値をそのまま返してください。
- 勘定科目は「科目の一覧」の中からだけ選んでください。
  一覧に無い科目を作らないでください。選べなければ空欄にしてください。
- 税区分は、table_similar のときに対応表の値を写すだけにしてください。
  inferred と no_match のときは空欄にしてください。
- 摘要に書かれていない取引先名や取引の内容を補わないでください。
  「カ）ヤマダ」を正式な社名に直さないでください。
- reason には、判断の根拠を一文で書いてください。
  table_similar のときは、根拠にした対応表の摘要をそのまま写してください。
- 確定した科目として書かないでください。すべて候補です。
- 1つの明細に候補を2つ以上付けないでください。
- 取引ではない行（繰越・合計など）が混ざっていたら、
  科目を付けず note に「取引ではない行」と書いてください。

【明細】{rows}
【対応表】{mapping_table}
【科目の一覧】{account_list}

「金額を書き換えない」を最初に置いているのは、検算を通った値を守るためです。 摘要の読み取りに違和感があると、AIは金額のほうを疑って直そうとすることがあります。直した瞬間に、検算を通ったという事実が意味を失います。

「迷ったときに table_similar を選ばない」も必要です。 対応表に近い摘要があると言われれば、担当者は確認を軽くします。確認を軽くしてよいかどうかの判断を、AIの側に楽観させないための一文です。

税区分を table_similar のときだけに限っているのも同じ理由です。 推し量った科目に税区分まで付くと、候補が一式そろって見え、確認が素通りになります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力を使い、output_config.format に type: "json_schema" とスキーマを渡します。スキーマに従った、解析できるJSONが返ることが保証されます。

{
  "bundle_id": "C023-main-2026-08",
  "rows": [
    {
      "row_no": 0,
      "date": "2026-08-05",
      "description": "",
      "withdrawal": 0,
      "deposit": 0,
      "direction": "withdrawal | deposit",
      "account_candidate": "",
      "sub_account": "",
      "tax_category": "",
      "match_type": "table_similar | inferred | no_match",
      "reason": "",
      "note": ""
    }
  ]
}

ただし、金額の範囲はスキーマで縛れません。 構造化出力は minimum や maximum といった数値の制約をサポートしていません。返ってきた金額が渡した値と同じかは、スクリプトが行番号で突き合わせて確かめます。 1つでも違えば、その束の結果を使いません。

スキーマの中のオブジェクトには additionalProperties: false を付けます。 構造化出力ではこれが必須です。余計な項目が返らないので、CSVの列との対応が崩れません。

AIの出力とは別に、検算の結果をスクリプトが行ごとに持ちます。

mismatch の並び方で、どのセルを読み違えたかの見当が付きます。 1行だけ合わなければ、その行の出金か入金の読み違いです。続く2行が合わなければ、1行目の残高を読み違えていることが多く、確認する場所が絞れます。

束の最後には、全体の検算を1回します。 前月の最終残高＋入金の合計−出金の合計が、束の最後の残高と一致するかです。行ごとの検算がすべて合っていても、ページが1枚抜けていればここで分かります。

システムへ連携する

会計ソフトへは書き込みません。 この構成が出すのは取り込み用のCSVまでです。取り込みを自動にすると、検算が合わない行が混ざったまま帳簿に入る経路ができます。

取り込み用CSVには ready の行と、担当者が確認を終えた行だけを入れます。 列の並びは、使っている会計ソフトの取り込み形式に合わせます。

対応表は読み取りだけです。 担当者が候補を採用しても、対応表には自動で足しません。月に1回、採用した候補をまとめて見直し、足すものを人が決めます。

人が確認する

人が開くのは needs_reread と needs_account の行だけです。 ready の行は一覧で件数を流し見ます。全行を開く設計にすると、第10章の16.0時間には収まりません。

1. needs_reread を先に見る … 確認用の一覧に、その行の写しの切り抜きを並べます。写しを見て正しい金額を打ち直し、検算が通るかをもう一度確かめます
2. 束の全体の検算を見る … 合わなければ、ページの抜けか順番の入れ違いです。顧問先に写しの撮り直しを頼みます
3. needs_account の候補を確かめる … no_match から、inferred、table_similar の順に見ます。no_match の多くは、顧問先への問い合わせになります
4. 候補を覆したら記録する … どの摘要に、どの科目を付けたかを残します。対応表の見直しの材料です

1番目で、AIに読み直させないでください。 同じ写しを同じ仕組みで読めば、同じ所で間違えます。読み直しは、写しを見る人の仕事です。

目標は、80束をならして1束12分です。 検算の合わない行が1束に数行、科目が候補止まりの行が十数行という想定です。それより多い月は、写しの解像度が落ちているか、対応表が古くなっています。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、写しの受け取り方の問題です。 顧問先に撮り方の案内を1枚渡すほうが、仕組みを直すより効きます。

記録を残す

• 元の写しのファイルと、受け取った日時・経路（郵送のスキャン／PDF／写真）
• Document AI が返した結果の全文
• 行データ、検算の結果（balance_check、row_status）、束の全体の検算
• AIに渡した行と、返ってきたJSONの全文。そのとき使った対応表の版
• 人が金額を打ち直した記録と、候補を覆した記録
• 会計ソフトへ取り込んだCSVと、取り込んだ日時
• 顧問先ごとの needs_reread の発生率

4つ目で「対応表の版」を残すのは、対応表が月ごとに育つためです。 後から科目の付け方を問われたとき、当時の対応表が残っていないと、なぜその候補になったかを説明できません。

最後の行は、顧問先との相談の材料になります。 特定の顧問先だけ読み直しが続くなら、撮り方か紙の状態に理由があります。