数年分の決算が止まっていた法人があり、銀行明細のパースから仕訳の起票、検算、そして申告書に載せる数値の確定までを、Claude CodeからfreeeのAPIを叩かせながら一気に進めました。会計ソフトの画面を手作業でポチポチする代わりに、「銀行明細を読んで、仕訳を起こして、検算して、申告書用の数字を出す」ところまでをAIに任せてみた事例です。
結果として、複数期分・仕訳4,000件超の処理と、そこから申告書の別表・内訳書・概況書に転記する数値の確定までを、実質数日で終えることができました。ただしその過程では、AIが間違えた場面も、会計ソフトのAPI特有の罠にはまった場面もありました。
この活用の概要
| 項目 | 内容 |
|---|---|
| 使った期間 | 実質数日 |
| 使用ツール | Claude Code（Opus）、freee会計API、Python |
| やりたかったこと | 数年分止まっていた法人の記帳・決算・申告書作成を進めること |
| できるようになったこと | 複数期分・仕訳4,000件超の処理と、申告書用数値の確定を数日で完了すること |
| つまずいた点 | 銀行明細のパース、freee APIと画面の挙動の不一致、freeeが出せない期の試算表の再現 |
| 結果 | 複数期分の決算処理と申告書数値の確定を完了 |
結論：戻せる設計にすれば、会計処理もAIに任せられる
一番伝えたいのは、「パースと分類は自動化する」「検算は必ず二重でやる」「巻き戻せる形で実行する」という3つを先に用意すれば、AIに任せられる範囲は一気に広がるということです。逆にこの3つを用意しないまま自動化すると事故ります。会計データは間違いがそのまま税額に効くので、速さより戻せることを優先した方が安全です。
銀行明細のパースと入出金判定でつまずいた点
PDFの明細は、摘要が金額行の上下に分割印字されており、入出金の判定も列位置では当てにならず、折り返し行でズレました。この問題は、列で判定するのをやめて残高の増減で入出金を判定する方針に切り替えたら一発で通りました。「列で判定するとズレるので残高差分を使え」という設計判断を、実データを見ながらその場で出せるのがAIの強みだと感じた場面です。また、全銀CSVは決済の加盟店名が落ちるため、PDFを優先するという使い分けも実測して決めました。
摘要から勘定科目を当てるルール化
数千件の明細を人力で仕訳するのは現実的ではないため、摘要のキーワードから勘定科目を当てるルールを170個ほど作り、金額レンジや入出金の向きも条件に入れました。面白かったのは、同じ経営者の別会社でもルールがほぼそのまま使い回せたことです。事業内容が同じなら摘要の傾向も同じで、300件弱の未処理明細が未分類ゼロで分類できました。
freee APIと画面の挙動のズレ
freeeのAPIで取引を作っても、口座明細側の「消込」はできません。つまり帳簿には仕訳が入っているのに、画面上は未処理明細として残り続けます。ここで画面から一括登録すると全部が二重計上になります。この手の「APIと画面で挙動が違う」罠は、ドキュメントを読むだけでは気づけず、実際に動かして残高を検算して初めて分かりました。
巻き戻せる設計にした理由
一括登録は必ず登録IDをログに残し、ログから一括削除できるようにしました。実際、分類の方針を途中で変えて、登録済みの286件を全部消してやり直した場面がありました。これができないと怖くて自動化できません。「間違えたら戻せる」を先に作るのが、AIに任せる作業の前提条件だと考えています。
出せない数字の再現とその他の工夫
freeeは会計期間を「当年度＋翌年度」の2期しか開かないため、複数期まとめて処理していると3期目の試算表が画面から出せません。そこで仕訳帳を全件エクスポートし、勘定科目の区分マスタと突き合わせて、自前で試算表を再計算しました。既に数字が確定している2期分で検算したところ1円まで一致したため、出せない期の数字も信頼できると判断しました。「正解が分かっている部分で検算してから、未知の部分に適用する」というのが、AIに計算をやらせるときの基本動作だと思います。
証憑を探すのにメールを漁る必要があった際は、メールアプリの検索が壊れていたため、ローカルに保存されているメール2万6千通を全部デコードして、1通1行のJSONL索引を自作しました。日本語は文字コードの都合で生のgrepが効かないため、デコードを挟むのがポイントです。また、複数の決済代行サービス経由の入金が手数料控除後の純額で売上計上されていた問題では、入金額を手数料率で割り戻して総額を復元しました。割り戻した金額が決済単価の組み合わせとして成立する丸い数字になるかを検証し、後から実額が取れたサービスで答え合わせをしたところ差は1円でした。
よくある質問
なぜ会計ソフトの画面ではなくAPIを使ったのですか？
数千件規模の明細を人力で処理するのが現実的ではなかったためです。 銀行明細のパースから仕訳の起票、月末残高の突合まで、APIを叩いて自動化することで大量データの処理を圧倒的に速く進められました。
AIに仕訳を任せて、間違いはなかったのですか？
間違いはありました。 作業中、提出方法の前提や帳票の名称、金額の取り違えなど、判断を何度か訂正しています。そのため数字は必ず別経路で検算するようにしました。
巻き戻せる設計とは具体的に何をしたのですか？
一括登録の際に登録IDをログに残し、ログから一括削除できるようにしました。 実際に分類方針を変えて286件を全部消してやり直した場面があり、この仕組みがなければ怖くて自動化できなかったと思います。
税務の最終判断もAIに任せたのですか？
いいえ、最終判断は専門家に任せています。 処理の選択肢を整理するところまではAIでできますが、どれを採るかは責任の伴う判断になるため、事実確認や最終判断は人間側で行いました。
同じ手法は他の会社でも使えますか？
摘要から勘定科目を当てるルールは、同じ経営者の別会社でほぼそのまま使い回せました。 事業内容が同じであれば摘要の傾向も似ているため、300件弱の未処理明細が未分類ゼロで分類できています。
まとめ
- 残高差分で入出金を判定する方針に切り替えたことで、明細パースのズレが解消しました
- freee APIと画面で挙動が違う罠は、実際に動かして残高を検算しないと気づけませんでした
- 巻き戻せる設計（登録IDのログ化と一括削除）があったからこそ、途中で方針を変えても安全にやり直せました
- 正解が分かっている部分で検算してから未知の部分に適用するのが、AIに計算を任せるときの基本動作でした
- 事実確認と税務の最終判断は人間の役割であり、AIに任せられるのはそこに至るまでの処理と整理でした
会計ソフトのAPIは「画面でできること」と「APIでできること」がズレていることが多く、そのズレを踏まえた設計をしない限り事故につながります。パースと分類の自動化、二重の検算、巻き戻せる実行という3つを先に用意することが、AIに会計処理を任せるための前提条件だと感じた事例でした。