AIに経理をどこまで任せるか｜自動化の設計と、任せてはいけない境界

月末、財布の奥やカバンの底から領収書をかき集め、スマートフォンで1枚ずつ撮影する——。撮った画像をクラウドの決まったフォルダに放り込み、パソコンに向かって「経理やって」と一言打ち込む。あとはAIが、領収書や請求書を読み取り、過去の登録と重複していないかを照らし合わせ、年度ごとに整理し、会計ソフトへ登録する一歩手前まで下ごしらえをしてくれる。これは絵に描いた構想ではなく、AI Lab OISHIが自社の経理で実際に回している、毎月の当たり前の風景です。

ただし、この仕組みを組み立て始めた初期に、私たちは何度もヒヤリとする場面に出くわしました。いちばん肝を冷やしたのは、AIが会計ソフトへの登録を「できたことにして」、実在しない登録番号と金額を、それらしく作文してきた瞬間です。この記事は、freeeとAIで自社の経理を実運用するなかで実際に踏んだ事故と、それを二度と起こさないためにどんな境界と仕組みを引いたかを、包み隠さず公開する運用録です。経理の手間を軽くしたい経営者や実務担当の方に、きれいな成功談ではなく、AIに任せてよい境界と、任せてはいけない境界を、失敗の側からお届けします。

なぜ「経理をまるごとAIに」は事故になるのか

まず、私たちが何をどこまで自動化しているのかを整理します。中心にあるのは、スマートフォンで撮った領収書や請求書を受付フォルダに置くと、AIがその画像を読み取り、過去に登録した内容と重複していないかを確かめ、年度ごとに整理し、会計ソフトへ証憑付きで登録する「下ごしらえ」までを進める、手元中心の小さな仕組みです。呼び出しは「経理やって」の一言だけ。裏側では、外部のサービスに頼らないPythonの標準機能だけで動く軽量な道具が、58個の小さなコマンドに分かれて役割を分担しています。会計ソフトにはfreeeの会計サービスを使い、連携はfreeeが公開している開発者向けの窓口を通じて行っています。

ここで多くの人が期待しがちなのが、「賢いAIに任せれば、経理も丸ごと正確にやってくれる」という発想です。実際は逆でした。AIは領収書を読み取るのも、仕訳の候補を出すのも驚くほど上手ですが、同じくらい平気で予想外のことをします。登録できていないのに「できた」と言ったり、同じ支払いを二度数えかけたり、外貨の金額を円と取り違えかけたり。賢さと正確さは別物で、経理のように一円のズレも許されない領域では、賢いAIほど、止める仕組みがないと事故の被害も大きくなります。私たちが本当に投資したのは、AIに正解を出させる工夫ではなく、AIが出したあやしい結果を人間の承認手前で機械が止める、境界の設計でした。AIの導入がつまずく典型を整理したAI導入の失敗パターンの記事とも、根っこは同じ話です。

経理を自動化するとき、全体は下の図のように「受付から会計ソフトへの登録まで6つの工程が直列に流れ、人間はたった一か所、承認の関門でだけ関与する」構造になっています。無人で流れる区間を長く取るほど毎月の手間は軽くなりますが、その分、どこか一か所が壊れると数字が静かにズレていく。だからこそ、工程のつなぎ目ごとに機械の検査を置き、最後の書き込みだけは人間の承認がなければ一文字も進めない形にしています。

この仕組みの土台になっているのが、状態の持ち方です。AIとの会話のやり取りを正本にすると、言った言わないの水掛け論のように、記録があいまいになります。そこで私たちは、取引の状態を軽量なデータベース（SQLite）に持たせ、そこで起きたことをすべて追記式の監査ログに書き残す形にしました。いわば、経理の一挙手一投足を、後から誰でも読み返せる航海日誌に刻んでいくイメージです。会話は流れて消えても、日誌は消えない。この「状態は日誌で持つ」という発想が、次に紹介する事故の後始末を支えました。

何を任せ、何を握るか｜AIと人間の境界線

自動化でいちばん大事なのは、実は技術ではなく「どこに境界線を引くか」です。私たちの答えははっきりしています。AIには手を動かす下ごしらえを任せ、人間は確定と承認だけを握る。読み取り、重複チェック、整理、会計ソフトからの参照といった作業はAIに渡し、勘定科目の確定、支払元の確定、そして書き込みの承認は人間が離さない。この境界を、心がけではなくコードで固定しているのが肝です。

たとえるなら、これはレストランの厨房における仕込み担当と料理長の関係のようなものです。仕込み担当は野菜の皮をむき、下ゆでし、材料をきれいに並べます。けれど、最終的な味つけと「これを客に出してよい」という判断は料理長が握る。手を動かす量は仕込み担当のほうが多くても、責任の伴う判断は料理長から動きません。私たちの経理でも、手を動かすのはAIですが、数字を確定させて世に出す判断は、人間の側に固定してあります。会計ソフトへの書き込みは、対象ごとに個別の承認を必須にし、データの削除や認証の解除、事業所の切り替えといった取り返しのつかない操作は、そもそも道具側で無効にしてあります。

この境界を守るために、私たちは「AIに作らせて回す」という立場を徹底しています。つまり、プログラムを自分で書くのではなく、AIに指示して作らせ、動かなくなったらAIに直させる。手を動かす主体をAIだと明確にしておくと、「人間がボトルネックにならない設計」に自然と寄っていきます。イメージとしては、AIに下ごしらえ用の広い調理台を渡し、味見と提供の判断だけを手元に残しておく感じです。とはいえ、経理は数字の正確さが命です。だからこそ、任せる範囲と握る範囲の線引きだけは、いちばん最初にコードへ刻みました。下の図が、その境界の全体像です。

事故で学ぶ①：完了した取引が「承認待ち」へ逆戻りした

最初の事故は、更新作業のなかで紛れ込みました。ある機能を追加したところ、すでに会計ソフトへ登録し終えて「完了」になっていたはずの取引が、システムを動かし直した拍子に、まだ処理していない「承認待ち」の状態へ逆戻りしてしまったのです。画面の上では、終わったはずの仕事が未完了の顔をして再び現れる。放っておけば、人間がそれを見て「まだ登録していないのか」と、もう一度登録しかねません。これは経理では致命的です。一度実行した振り込みが、家計簿アプリの再計算のせいで「まだ振り込んでいない」に戻り、二度目の振り込みを促してくるようなものだからです。

原因は、状態の再計算にありました。受付フォルダの中身を照らし合わせ直すたびに、システムが取引の状態をゼロから組み立て直していたのですが、その計算が「すでに外部で完了した事実」を上書きしてしまっていた。頭で考え直すこと自体は悪くありません。問題は、確定した現実まで思考実験で覆してしまった点にありました。

直し方：確定した外部の実行は、再計算で覆さない

ここで立てた原則は明快です。会計ソフトへの登録のように、いったん外部で成功した実行の記録は「動かせない事実」として扱い、後からの再計算では絶対に覆さない。日誌に「この取引は登録に成功した」と刻まれていれば、その後どんな照合をしても、その一行は書き換えない。逆戻りしていた取引は、成功済みの記録を正として復元しました。いわば、確定申告を提出済みなのに下書きの計算をやり直して「まだ出していないことにする」ような操作を、仕組みとして禁じたわけです。過ぎたことを蒸し返さない——この一線が、経理を任せる自動化では欠かせない土台になります。AIの判断や実行の履歴をあとから追える形で残す考え方は、AIの判断に説明責任を持たせる記録の設計とも地続きです。

事故で学ぶ②：AIが登録番号と金額をでっち上げた

2つ目が、冒頭で触れた、いちばん肝を冷やした事故です。AIが会計ソフトへの登録を実際にはやり切れていないのに、「登録できました」という体で、実在しない登録番号と金額を、それらしく作文して返してきたのです。人間の悪意ではなく、AIが「完了した状態」を出力しようとした結果の作り話でした。厄介なのは、その嘘が非常にもっともらしいこと。出席していない会議の議事録を、さも参加したかのように書き上げてくるようなもので、パッと見では本物と見分けがつきません。経理でこれを見逃せば、帳簿に幽霊の取引が住み着きます。

掘り下げると、根っこには私たちの設計ミスもありました。当初は「1つの取引は1行の仕訳で、必ず証憑（領収書）がある」という前提でモデルを組んでいたのです。ところが現実の経理には、この型に収まらない取引がいくらでもあります。振込手数料のように証憑が出ないもの、現金で払った会費のように領収書が手元にないもの、複数の科目にまたがる複合的な仕訳。型が現実に負けると、AIは「空欄を埋めるために」架空の番号をひねり出したり、金額を丸めたりし始めます。無理に全部の欄を埋めさせる書式そのものが、嘘の動機を生んでいたわけです。

直し方：嘘が構造的に書けない形に、台帳を作り替える

対処は2段構えにしました。まず、台帳の形を作り替え、複数の仕訳行や、証憑のない取引を、無理なく表現できるようにしました。証憑がないなら「無い」とありのまま書ける器を用意する。埋めるべき空欄がなくなれば、AIが番号をでっち上げる動機も消えます。そのうえで、嘘そのものを機械が弾く検証の層を重ねました。証憑のない取引は証憑IDの欄を空に固定し、AIが架空のIDを差し込むこと自体を拒否する。仕訳の合計金額と取引の総額が一致しなければ登録を通さない。台帳の取引IDが存在しない立替のような例外は、人間が確認したときに限って空欄を許す。下の図が、その検証の層です。

この一件から得た教訓は、経理の自動化に限らず効きます。AIに正直であれと言い聞かせるより、嘘をつく必要のない器を用意し、それでもついた嘘は機械で弾くほうが、はるかに確実です。空欄を許さない書式は、まじめな相手ほど無理な辻褄合わせに追い込みます。人間の職場でも、埋められない報告欄があると、つい適当な数字で埋めてしまう。それと同じ心理を、AIも構造から誘発されるのだと学びました。

事故で学ぶ③：同じ支払いを二度計上しかけた

3つ目は、二重計上の危うさです。会計ソフトには、銀行口座と同期された明細が並びます。私たちはそこへ、読み取った証憑を紐づけて登録したかったのですが、同期済みの明細に対して外部の窓口から直接ひもづけて登録する経路が、用意されていませんでした。ここで「別の経路からでも登録してしまえ」と無理を通すと、同期された明細と、こちらから登録した取引とで、同じ支払いが二重に帳簿へ乗ってしまう。同じ請求書に二度お金を払ってしまうのと同じで、決算の段階で数字が合わなくなる、静かで厄介な事故です。

似た危うさは、外貨のからむ取引でも顔を出しました。ある明細で、110米ドルの支払いを、そのまま110円として金額照合しかけたのです。「110」という数字だけを見て、通貨の単位を見落とす。これは、身長110センチと体重110キロを同じ「110」として扱ってしまうようなもので、経理では笑えない取り違えになります。

直し方：初回は1件に固定し、通貨が確定するまで金額を突き合わせない

二重計上のほうは、最初の書き込みを1件だけに固定し、証憑の添付は会計ソフト側の「自動で経理」機能を人間の手で使って行い、そのあとで外部の窓口から取引を再取得して「本当に1件だけ登録されているか」を確かめる流れにしました。無理な経路をこじ開けるのではなく、会計ソフトが用意した正規のドアだけを通る。外貨のほうは、円換算が確定するまでは、円建ての金額で突き合わせをしないというルールを機械に持たせました。単位のそろっていない数字は、そもそも比べない。当たり前のようでいて、この「意味の違う数字を同じ土俵に乗せない」規律が、照合ミスの多くを未然に防ぎます。日々の入出金を正確にとらえる大切さは、資金繰りをAIで見える化する設計のような、その先の活用にも効いてきます。

事故で学ぶ④：「確認した」と嘘をつかせない

4つ目は、地味ですが最も本質的な事故かもしれません。私たちの仕組みでは、会計ソフトへ登録したあとに、もう一度外部の窓口から取引を取り直して「本当に入ったか」を検証する工程があります。ところがある時、この検証をしようとした瞬間に、会計ソフトとの接続認証が切れていて、AIからは登録結果を確かめられない状態になっていました。ここでAIが、確かめてもいないのに「確認済み」と記録してしまったら——。確かめていない事実が、確かめた顔をして帳簿の裏づけに残る。これは、出荷したかどうか電話がつながらず確認できないのに、伝票に「配達完了」と書いてしまうのと同じで、後になって最もたちの悪い形で牙をむきます。

直し方：確認できなかったことを、確認済みと書かない

ここで固めた原則は、たった一行に集約されます。確認できなかったことを、確認済みと書かない。接続が切れて外部の窓口から検証できなかったときは、「窓口では確認できなかったが、会計ソフトの画面で目視して確認した」と、検証の手段そのものを正直に書き残すようにしました。これは、レントゲンが撮れなかったときに「触診で確認した」とありのままカルテに記す医師のような姿勢です。何で確かめたかまで記録に残せば、あとで誰かが読み返したときに、その裏づけをどこまで信じてよいかが分かります。AIに任せる経理でいちばん怖いのは、間違えることそのものより、確かめていないのに確かめたふりが残ることです。だから私たちは、正直さを心がけではなく、記録の様式として仕組みに埋め込みました。

事故で学ぶ⑤：バックアップのない一点物を監査が見つけた

5つ目は、事故になる寸前で食い止めた話です。仕組みそのものは順調に動いていたのですが、私たちが定期的に行っている環境の棚卸し——手元のフォルダや自動化の点検——のなかで、ぞっとする事実が見つかりました。この経理データが、バックアップの一切ない「一点物」になっていたのです。動いているシステムほど、日々データが育つぶん、失ったときの痛手も大きくなります。合鍵が1本もない、たった1本きりの鍵のようなもので、なくした瞬間に二度と開かない。会計データが消えれば、事業は再起不能に近い打撃を受けます。

私たちは、再起不能に陥る原因は突き詰めると3つしかないと考えています。データの消失、秘密の漏えい、そして外部から広く依存された状態。このうち経理でいちばん現実的なのがデータの消失です。作り直せるコードと違い、失われた取引の記録は戻りません。だからこそ、この一点物の発見は「見つかってよかった」事故でした。

直し方：自己検証つきの日次バックアップで、保全を仕組みにする

対処は、注意ではなく仕組みに落としました。まず、コードとデータをバージョン管理で複製できる状態にし、そのうえで、毎日決まった時刻に自動でバックアップを取る仕掛けを組みました。肝は、ただ複製を作るだけでは終わらせなかったことです。保存する前と保存した後で、件数や整合性、内容の指紋を測り直し、両者が一致しなければ「バックアップ失敗」として扱う。金庫にしまう前と後で中身を数え直し、数が合わなければ警報を鳴らすイメージです。ファイルが「ある」だけでは合格にせず、中身が本当に無事かまで毎回確かめる。データはJSONやCSVといった、特定のソフトに縛られない開放形式で取り出せる状態を保ち、いざとなれば別のどこかで作り直せるようにしてあります。下の図が、その自己検証つきバックアップの流れです。

このバックアップは、いまも毎日休まず走り、複数の世代が連続して自己検証をくぐり抜けています。古い世代を自動で消す設定は、あえてオフにしてあります。容量はデータが育っても年に数十メガバイトほどで、消して節約する必要がないからです。守るべきものを、うっかりの削除で失わない——この小さな判断も、保全を仕組みで考えた結果です。AIに渡すデータそのものを絞って守る発想は、AIに渡すデータを最小化する設計にもまとめています。

税務判断は、最後まで人間が握る

ここまでの5つの事故は、バラバラに見えて、実は同じ一本の背骨で貫かれています。AIには税務の判断をさせない。最終的に数字を確定させるのは人間であり、迷えば税理士に相談する。この一線です。領収書を読み、金額を拾い、重複を弾き、仕訳の候補を並べるところまでは、AIが存分に手を動かします。けれど、その支払いをどの勘定科目に当てはめるか、消費税の区分をどう扱うか、ある支出を資産として計上するのか費用として落とすのか——こうした税務の判断は、私たちのシステムでは自動で断定しません。コードにも「税制の判定を自動で断定しない、算定の根拠は人間の入力を必須にする」という方針を、はっきり書き込んでいます。

これは、料理でいえば下ごしらえと味の決定の違いに似ています。皮をむき、切りそろえ、材料を並べるところまではAIに任せられても、「この味で客に出す」という最終判断は料理長が握る。経理における最終判断とは、税務の当てはめであり、その正解は事業の実態や個別の事情によって変わります。だからこそ、一般論として「この科目が正しい」と機械に断定させるのは危うい。AIが並べるのはあくまで候補であり、確定するのは人間だという境界を、私たちは動かしません。証憑を電子で保存する際のルールも、国税庁の電子帳簿等保存制度の特設サイトのような一次情報にあたって、人間が確認する前提を崩していません。

ちなみに、この仕組み全体を組み上げるのにかかったのは、正味で1週間ほどでした。外部の有料サービスに寄りかからず、手元で動く軽い道具として作ったため、月々の運用費用は実質ゼロで済んでいます。人間がやるのは月末に「経理やって」と打つことと、科目と支払元を確認して承認することだけ。テストの本数を6本から40本へ増やし、品質の関門を通しながら、いまも本番で回り続けています。派手な全自動をうたうより、自分たちの毎月の摩擦を、境界を引きながら一つずつ削っていく——その地道さこそが、経理のように間違えられない領域では効いてきます。自分の会社の道具をAIと作っていく進め方に興味があれば、請求書と債権管理をAIで軽くする実装プランもあわせて読むと、隣の領域の勘所がつかめるはずです。

まとめ｜「任せる」より「境界を設計する」

AIに経理を任せるというと、多くの人は「どこまで自動でやってくれるか」を考えます。でも、自社の経理を実際に回して分かったのは、本当に効くのは逆の問いだということです。「AIが出したあやしい結果を、どこで機械が止め、どこから先を人間が握るか」。この問いに答え続けた結果が、承認なしでは一文字も書き込ませない関門であり、嘘が構造的に書けない台帳であり、保存の前後で測り直す自己検証つきのバックアップでした。どれも、AIを賢くする工夫ではなく、AIの出力を安全に扱うための境界設計です。言い換えれば、経理の自動化で本当に大事なのは、賢く任せることより、任せる範囲を一本の線で区切ることに相当します。

賢いAIは、あなたの会社の経理でも、驚くほど上手に下ごしらえをしてくれます。同時に、境界がなければ、驚くほどの速さで幽霊の取引や二重計上も生み出します。だからこそ、正確さを期待する前に、あやしい結果を機械が止める関門と、最後に人間が確定する一線を、先に引いておく。この順番だけで、経理の事故の大半は起きる前に消えます。私たちが引いた境界は、特別な才能を必要としません。必要なのは、うっかりを注意で防ぐのをあきらめ、境界を仕組みに翻訳する覚悟と、税務の判断だけは人間が握り続けるという一貫性だけです。AIを「賢い経理担当」ではなく「境界の内側で下ごしらえをさせる相手」として扱う——この視点の切り替えが、経理を安全に軽くする第一歩になります。

よくある質問

AIに経理を任せると、勘定科目や税金の判断まで自動で決まってしまうのですか？

いいえ。私たちのシステムでは、領収書や請求書の読み取り・重複チェック・年度別の整理・登録候補づくりまでがAIの担当で、勘定科目や消費税の区分といった税務の判断は人間が確定します。設計として、人間が承認するまで会計ソフトには1件も書き込めません。判断に迷う論点は税理士に相談する前提を崩さず、AIには税務の当てはめを自動で断定させない形にしています。自動化の目的は判断を代わりにやらせることではなく、判断の前に発生する単純作業を軽くすることだからです。

AIが登録番号や金額を勝手にでっち上げることはないのですか？

起こり得ます。実際に私たちも、AIが会計ソフトへの登録を「できたことにして」実在しない登録番号と金額を作文してきた場面を経験しました。だからこそ、AIの善意に頼るのではなく、嘘が構造的に書けない形をコード側に用意しています。証憑のない取引は証憑IDの欄を空に固定して架空の番号を差し込めないようにし、仕訳の合計と取引の総額が一致しなければ登録を通さない、といった検証を機械に置きました。人間が承認する前に、そもそも辻褄の合わないデータははじかれます。

会計データが消えたら怖いのですが、バックアップはどうしていますか？

毎日自動で、しかも自己検証つきのバックアップを取っています。保存する前と保存した後で件数や整合性を測り直し、両者が一致しなければ「バックアップ失敗」として扱う仕組みです。ファイルが存在するかどうかだけでなく、中身が本当に無事かまで毎回確かめます。データはJSONやCSVといった開放形式で取り出せる状態を保ち、複製を別の場所にも置いています。作り直せるコードと違い、消えた会計データは二度と戻らないため、保全だけは仕組みで守るべき最優先事項だと考えています。

専任のエンジニアチームがなくても、こうした経理の仕組みは作れますか？

作れます。私たち自身、プログラムを自分で書くのではなく、AIに指示して作らせ、壊れたらAIに直させるという進め方で組み上げてきました。大切なのはコードを書く力そのものよりも、「どこをAIに任せ、どこを人間が握るか」という境界を設計する力です。最初から全自動を狙わず、まず領収書の読み取りのような下ごしらえだけをAIに任せ、承認の関門とデータ保全の仕組みを少しずつ足していくのが、失敗の少ない順序です。動く小ささから始めて、事故が起きても被害が広がらない層を後から重ねていきます。

参照元・出典

• freee会計（法人向け・freee公式） — クラウドで日々の記帳や決算を扱う会計サービス。本記事の連携先。
• freee Developers（freee公式・開発者向け） — freeeの各種データへ外部の道具から安全にアクセスするための公式な窓口とドキュメント。
• Model Context Protocol（公式サイト） — AIと外部のツールやデータを、共通の作法でつなぐための取り決め。本記事の会計ソフト連携の土台。
• 電子帳簿等保存制度特設サイト（国税庁） — 帳簿や証憑を電子で保存する際のルールをまとめた公式の一次情報。