「月次決算が3日遅れた」安易なAI-OCR×Make連携が招いた現場の混乱と、止まらない経理DXの現実解

「来月から、領収書の入力業務はゼロになります」

DX推進担当者のその言葉に、経理部のメンバーは目を輝かせました。しかし、その3ヶ月後、彼らを待っていたのは「ゼロ」どころか、終わりの見えない修正作業と、3日間の決算遅延という悪夢でした。

近年、AI-OCR（光学文字認識）の進化と、Make（旧Integromat）のようなノーコードツールの普及により、これまで多額のコストがかかっていたシステム連携が、驚くほど手軽に実現できるようになりました。特に「紙の領収書をAIで読み取り、自動で会計ソフトに登録する」というフローは、経理DXの鉄板シナリオとして多くの企業で検討されています。

しかし、実務の現場における一般的な傾向として、この「手軽さ」こそが最大の落とし穴になり得ます。

「ツールをつなげれば動く」ことと、「業務としてまわる」ことは、まったく次元の異なる話です。特に、1円のズレも許されない経理業務において、安易な自動化は組織全体を混乱させるリスクをはらんでいます。

今回は、あえて「失敗事例」から話を始めます。AI-OCRとMakeを導入して大混乱に陥った企業での導入事例を解剖し、そこから見えてきた「本当に止まらない経理システム」の作り方を、技術と運用の両面から解説していきます。

失敗を恐れるのではなく、失敗のメカニズムを知ることで、確実な成功への道筋を描きましょう。

なぜ「理想的なペーパーレス化」は3ヶ月で崩壊したのか

従業員数300名規模の中堅企業での導入事例では、月間約1,500枚発生する領収書処理の完全自動化を目指していました。DX推進室主導のもと、高精度のAI-OCRとMakeを組み合わせ、Googleドライブにアップロードされた領収書画像を自動で解析し、会計システムへ仕訳データとして流し込む——そんな「理想的なパイプライン」が設計されました。

プロジェクトの全貌：目指したのは「入力ゼロ」の世界

当初の計画は非常にスマートなものでした。

1. 収集: 全社員がスマホで領収書を撮影し、指定のGoogleドライブフォルダへアップロード。
2. 解析: Makeが新規ファイルを検知し、AI-OCRのAPIへ送信。
3. 変換: OCR結果（日付、金額、取引先、インボイス登録番号）を受け取り、JSON形式で整形。
4. 登録: 会計システムのAPIを叩いて仕訳登録完了。

試算では、経理担当者の入力工数を80%削減できるはずでした。PoC（概念実証）段階では、綺麗にスキャンされたPDF数枚をテストし、見事にデータ化される様子に経営層も納得し、本番導入が決定しました。

稼働初日に起きた「エラー通知」の嵐

ところが、全社展開初日、DX担当者のチャットツールには絶え間なくエラー通知が飛び込んできました。

「400 Bad Request」「Timeout」「Data Validation Error」...

原因は多岐にわたりました。スマホで撮影された写真は、手ブレ、照明の反射、さらには机の木目までが写り込んでおり、AI-OCRが誤認識を連発したのです。さらに、Makeのシナリオは「正常に読み取れること」を前提に組まれていたため、必須項目である「日付」が読み取れなかった瞬間に処理が停止。後続の処理もすべて詰まってしまいました。

現場からの悲鳴：目視確認の手間が逆に増加

最も深刻だったのは、システムエラーではなく「サイレントキラー（静かなる失敗）」でした。

エラーにならずに会計システムまで到達したデータの中に、微妙な間違いが混入していたのです。例えば、「8,000円」が「3,000円」と誤認されたり、「株式会社」が「株」と省略されてマスタと不一致になったり。

経理担当者は、自動登録されたデータを信用できず、結局すべての仕訳を元画像と突き合わせて確認する羽目になりました。「これなら最初から手入力した方が早いです...」。疲弊した経理課長の一言が、プロジェクトの事実上の敗北宣言でした。結果としてその月の月次決算は、確認作業の遅れにより3日間の遅延を余儀なくされました。

技術的要因：ノーコード連携に潜む「例外処理」の落とし穴

なぜこのような事態に陥ったのでしょうか。技術的な側面から見ると、ノーコードツール特有の「作りやすさ」が、逆に「堅牢性（けんろうせい）」を損なっていたことが分かります。

AI-OCRの「99%の精度」が招く1%の致命傷

多くのAI-OCRベンダーは「認識精度99%以上」を謳（うた）います。しかし、これはあくまで「条件が良い活字データ」での話です。手書き文字、くしゃくしゃになった感熱紙、特殊なフォントのロゴなどが混在する実務環境では、精度は如実に低下します。

仮に99%の精度だとしても、1,500枚の領収書には数千箇所の読み取り項目があります。1%のエラー率でも、毎月数十件の間違いが混入することになります。システム開発の経験がある方ならご存知かと思いますが、「99回の成功」よりも「1回の失敗」をどうハンドリングするかが、業務システムの肝です。

この導入事例では、この「読み取りミス」を検知し、人間にアラートを出す仕組みがMakeのシナリオ内に組み込まれていませんでした。AIが出した答えをそのまま正解として処理してしまったのです。

Makeシナリオが複雑化する「スパゲッティ化」現象

Makeは視覚的にモジュールをつなげるだけで処理が組める素晴らしいツールです。しかし、例外処理を真面目に実装しようとすると、途端に複雑化します。

• 日付が空欄だったらどうするか？
• 金額にカンマが含まれていたら除去するか？
• APIがタイムアウトしたらリトライ（再試行）するか？

これらをすべて条件分岐（Router）で記述していくと、画面いっぱいにクモの巣のような線が張り巡らされ、いわゆる「スパゲッティ化」した状態になります。こうなると、どこでエラーが起きたのか追跡するのが困難になり、メンテナンス性が著しく低下します。

インボイス制度対応で見落とされた「登録番号」の照合プロセス

さらに追い打ちをかけたのがインボイス制度です。AI-OCRで「T」から始まる登録番号を読み取るまでは良かったのですが、その番号が「国税庁のデータベースに実在するか」「有効期間内か」を確認するプロセスが抜けていました。

単に番号を文字列として読み取るだけでは不十分です。Makeを使って国税庁の適格請求書発行事業者公表サイトのAPIを叩き、返ってきた法人名と、OCRで読み取った領収書の宛名を照合する必要があります。このロジックは非常に複雑で、ノーコードだけで完結させようとすると無理が生じやすい部分です。

組織的要因：経理実務とエンジニアリングの「共通言語」不在

技術的な問題以上に根深かったのが、組織的なコミュニケーション不全です。DX推進担当者（エンジニア思考）と経理担当者（実務思考）の間には、大きな認識の溝がありました。

「承認フロー」をシステムに落とし込めなかった理由

経理の実務には、暗黙知とも言える複雑なルールが存在します。

• 「交際費は5,000円基準で科目が変わる」
• 「この取引先の場合は、請求書払い扱いにする」
• 「部門コードはプロジェクトごとに按分（あんぶん）する」

DX担当者は「領収書をデータ化する」ことだけに注力し、その後の「仕訳の意味づけ」という経理の本質業務を理解しきれていませんでした。結果として、Makeで作られたシステムは「データ形式は合っているが、会計的には間違っている仕訳」を量産してしまったのです。

運用保守担当者の不在と属人化のリスク

MakeのようなiPaaS（Integration Platform as a Service）は、個人のアカウントで作成されることが多く、作成者が退職すると誰も触れなくなる「ブラックボックス化」のリスクが高いです。

この事例でも、初期構築を行った担当者が異動になった後、エラーが発生しても誰も修正できない状態に陥りました。エラーログの見方すら共有されておらず、経理担当者は「システムが動かない」と嘆き、情シスは「Makeは管轄外」と突き放す。この運用体制の不備が、トラブルを長期化させました。

法対応（電帳法・インボイス）解釈のズレ

電子帳簿保存法（電帳法）では、スキャナ保存における解像度やタイムスタンプ、検索要件などが厳密に定められています。DX担当者は「Googleドライブに保存してあれば検索できるからOK」と軽く考えていましたが、経理責任者から見れば「訂正削除の履歴が残らないドライブ保存は、法的要件を満たさない可能性がある」という重大なリスクでした。

法対応を甘く見たシステム設計は、後から監査が入った際に企業の存続に関わる問題になりかねません。

再建へのロードマップ：失敗から導き出された「Human-in-the-loop」設計

このような崩壊したプロジェクトを立て直すために有効なのが、「Human-in-the-loop（ヒューマン・イン・ザ・ループ）」という考え方です。

これは、AIによる完全自動化を目指すのではなく、「AIが下処理をし、人間が最終判断をする」というプロセスをシステムの中に意図的に組み込む設計です。

「完全自動化」を捨て、「確認プロセスの最適化」へ

まず、「入力ゼロ」という目標を撤回し、代わりに「確認作業の高速化」を目指すことが重要です。

具体的には、AI-OCRの結果をいきなり会計ソフトに流すのではなく、その間にkintoneやスプレッドシートなどの「確認用インターフェース」を挟むアプローチをとります。

1. MakeがOCR結果を取得。
2. 確認用データベースに「未承認」ステータスでレコード作成。
3. 経理担当者が画面で元画像とデータを比較し、必要なら修正して「承認」ボタンを押す。
4. 「承認」されたデータだけが、Makeによって会計ソフトへ連携される。

このワンクッションを入れるだけで、会計ソフト内が汚れることを防げます。経理担当者にとっても、「勝手に登録される恐怖」から解放され、心理的安全性が確保されます。

Makeシナリオのモジュール化とエラー通知の選別

スパゲッティ化したMakeのシナリオは、機能ごとに分割（モジュール化）することが推奨されます。

• 受信・OCR処理シナリオ
• 確認データ作成シナリオ
• 会計連携シナリオ

これらをData Store（Make内部のデータベース機能）やWebhookで疎結合につなぐことで、どこでエラーが起きても全体が止まらないようにします。また、エラー通知も「APIの一時的な不具合（自動リトライで解決）」と「データ不備（人の判断が必要）」に分け、本当に対応が必要なものだけをSlackに通知するように改善することが効果的です。

信頼できるAI-OCR選定のための新・評価軸

AI-OCRエンジンの選定基準も見直す必要があります。単なる「文字認識精度」ではなく、「確信度（Confidence Score）を返してくれるか」を重視することがポイントです。

優秀なAI-OCRは、「この文字は90%の確率で『8』ですが、もしかしたら『3』かもしれません」というスコアを出してくれます。このスコアを活用し、確信度が低いデータだけを人間に重点的にチェックさせることで、確認工数を効率化できます。

自社導入のための「失敗回避チェックリスト」

もし今、あなたがAI-OCRとMakeを使った内製化を検討しているなら、以下のチェックリストで「失敗の芽」を事前に摘んでおいてください。

事前検証（PoC）で確認すべき3つの「意地悪なテスト」

ベンダーが用意した綺麗なサンプルデータでテストしても意味がありません。現場のリアリティを反映した「意地悪なデータ」で検証しましょう。

1. 汚損データのテスト: くしゃくしゃのレシート、コーヒーのシミがついた領収書、斜めに撮影された画像を読ませてみる。
2. 異常値データのテスト: 合計金額がマイナスのデータ、日付が未来のデータなどを流し、システムがどう反応するか（止まるか、エラー通知が出るか）を確認する。
3. 大量データの負荷テスト: 月末の締め日を想定し、短時間に100件以上のリクエストを投げて、API制限（Rate Limit）に引っかからないか確認する。

運用体制：エラー対応フローは確立されているか

システムは必ずエラーを出します。その時、誰がどう動くか決まっていますか？

• Makeのエラーログを確認できる権限を持つ人は複数いるか？
• APIの仕様変更があった際、シナリオを修正できるエンジニア（または詳しい社員）は確保されているか？
• システムが完全に停止した場合の手動運用フロー（BCP）はあるか？

コスト試算：API利用料と保守工数を含めたTCO

MakeやAI-OCRは従量課金が一般的です。特にMakeは「オペレーション数（処理ステップ数）」で課金されます。複雑なエラー処理を組めば組むほど、1回の処理にかかるコストは増大します。

「月額数千円でできる」と思っていたら、エラーの無限ループで数万円の請求が来た、というのもよくある話です。ツールのライセンス費用だけでなく、エラー対応にかかる人件費も含めたTCO（総保有コスト）でROI（投資対効果）を判断してください。

まとめ：自動化の主役は「AI」ではなく「人」である

AI-OCRとMakeは強力な武器ですが、それはあくまで「人間の業務を支援するツール」に過ぎません。この導入事例が教えてくれるのは、「業務プロセスそのものの整理」と「例外を許容する設計」なしに、ツールだけで課題は解決できないという事実です。

「完全自動化」という魔法の言葉に惑わされず、まずは「泥臭い手作業」をどう効率化するか、という視点で足元を固めていきましょう。人が判断すべきところは人が判断する。そのための情報をAIが整える。この役割分担こそが、持続可能な経理DXの正解です。

地に足のついたDXを進めていくことが、ROI最大化への近道となります。