この業務は「確認をどう設計するか」がすべて
会計の仕事で AI が作ったものをそのまま確定させることはできません。 間違えた仕訳は決算に残り、責任は事務所に来ます。
だから設計すべきは自動化率ではなく、確認をどこに置くかと、誰が持つかです。幸い、この分野の製品はそこを最初から前提にして作られています。
製品側が「候補」で止めている
マネーフォワード クラウド会計の「AI-OCRから入力」は、公式サポートが 3 段階で説明しています。
- 事前準備 — 証憑データの用意と、事業者画面での設定
- アップロード — クラウド会計・確定申告の画面、またはクラウド Box から
- 仕訳登録 — 作成された仕訳候補を確認・修正して登録
3 段階目が「確認・修正して登録」になっているのがこの手順の要です。機械が作るのは候補であって仕訳ではありません。
「仕訳の形式で表示されている状態です」
仕訳の「形」で表示されるので、確定済みに見えます。 ここを流し読みして一括登録する運用にすると、確認工程が形だけになります。工程 4 を human_check として独立させているのはそのためです。
1 つの証憑を複数の仕訳にできる
同機能は1 つの証憑を複数の日付で仕訳作成することにも対応しています。前払費用の期間按分や、1 枚の請求書に複数月分が乗っている場合がこれに当たります。
逆に言うと、機械が 1 対 1 で作った候補が正しいとは限りません。 分割すべきものを分割していない候補は、形としては正しく見えます。
落とし穴: 従量課金がファイル数で効く
公式が明記しています。
「AI-OCRから入力」機能を利用して仕訳に添付したファイル数に応じて、登録件数の制限や従量課金が発生します
枚数課金です。 「とりあえず全部投げてみる」「試しに二重に上げる」がそのままコストになります。
導入前に月あたりの証憑枚数を数えてください。 費用の上限を先に決めるで書いた「見積もれないので実測する」がここでも当てはまりますが、この機能に関しては枚数×単価で先に読めるぶん扱いやすい部類です。
API で繋ぐとき
件数が増えて画面操作が回らなくなったら API になります。freee 会計のファイルボックス（証憑ファイル）は 4 つのエンドポイントで扱えます。
| メソッド | パス | 用途 |
|---|---|---|
POST | /api/1/receipts | 証憑ファイルのアップロード |
PUT | /api/1/receipts/{id} | 証憑ファイル情報の更新 |
GET | /api/1/receipts | 一覧の取得 |
GET | /api/1/receipts/{id} | 個別の取得 |
古い手順書が残っている問題
freee 公式が仕様変更を告知しています。
POST・PUT時のリクエストパラメーター「issue_date（発生日）」を廃止しました
今後、issue_dateに代わり created_at をご利用ください
今後、file_srcに代わり、ファイルボックス（証憑ファイル）のダウンロードAPI をご利用ください
社内に残っている手順書やスクリプトが issue_date / file_src を使っていたら、そこは既に動きません。 これは AI に「freee の API で証憑を上げるコードを書いて」と頼んだときにも起きます。学習時点の古い仕様で書かれたコードが返ることがあるので、生成されたコードは必ず現在のリファレンスと突き合わせてください。
freee は「証憑管理にファイルボックスを利用し、それを API で管理したい方」向けのガイドラインを別に用意しています。
生成AI を使う範囲
マネーフォワード公式の整理では、AI-OCR による証憑の自動データ化・自動仕訳と、生成AI による税法リサーチ・文書起案を組み合わせる形が示されています。
この 2 つは性質が違います。
| AI-OCR | 生成AI | |
|---|---|---|
| やること | 書いてあるものを写す | 書いていないものを作る |
| 間違いの見つけ方 | 原本と突き合わせる | 原本が無い |
| 確認の重さ | 軽い | 重い |
税法リサーチの出力には突き合わせる原本がありません。 条文番号も判例も、それらしい形で存在しないものが出てきます。この工程を human_check にしているのは、確認が形式的にならないようにするためです。
具体的には、生成AI に条文や通達の番号を出させたら、必ず原典に当たってください。 「合っていそう」で通すと、根拠が存在しない書面が出ます。
電子帳簿保存法について — ここは確認できていない
工程 2 の確度を C にしています。理由を書きます。
国税庁の電子帳簿保存法特設サイトを確認しましたが、「すべての事業者に電子取引データの電子保存が義務」と読める記述を、このページ上で確認できませんでした。 制度が電子帳簿保存・スキャナ保存・電子取引の 3 区分に分かれていることまでは確認できます。
ベンダー資料には「すべての事業者が一定の要件を満たして電子保管する必要があります」という趣旨の記述がありますが、この図書館は税務の解釈を確度 A で書ける立場にありません。
この工程だけは、この手順書ではなく原典と顧問先の判断で決めてください。 ここを製品の説明で済ませるのが、この分野でいちばん危ない省略です。
事務所として決めておくこと
- 月あたりの証憑枚数（課金が枚数で効く）
- 誰が仕訳候補を確認するか。 「担当者が確認」では確認になりません。何を見るか（金額・日付・勘定科目・税区分のどれか）まで決める
- どの証憑を API 経由にするか。 全部を自動化する必要はありません。件数の多い定型だけで効果は出ます
- 生成AI の出力を成果物に入れる条件。 原典に当たったかどうかの記録を残すか
この分野で分かっていないこと
- 電子帳簿保存法の要件を、この図書館では一次情報で確認できていない（上記）
- freee の AI-OCR 相当機能を確認していない。 マネーフォワード側の機能は公式ドキュメントを確認したが、freee 側は API しか見ていない
- 確認工程の実データが無い。 「仕訳候補の何割を修正したか」という数字を、実名の事例として見つけられていない
- セブンセンス税理士法人の事例は Claude Code の利用であって、この手順（証憑→仕訳）とは別の話。同じ事務所の話でも工程が違うので混ぜないこと