経理 AI 効率化｜タイ拠点の承認型90日導入ガイド

タイの製造業・現地法人で経理 AI 効率化を進めるとき、AI-OCRの読取率だけを比較しても、月次締めは速くなりません。証憑がメール、紙、e-Taxデータ、共有フォルダに散在し、検証・承認・仕訳・例外処理が人の記憶に依存したままなら、入力の一部を自動化しても別の工程に滞留が移るからです。本稿では、証憑取得から月次締めまでを「AIが候補を出し、ルールで検証し、人が承認する閉ループ」として設計する方法を解説します。RFPに入れるべき要件、TOMAS TECHが提案する90日PoC、監査証跡、効果試算まで、CFO・経理責任者が実務で使える形にまとめました。

結論：経理 AI 効率化は「無人化」ではなく承認可能な閉ループで設計する

結論は明確です。タイ拠点の経理AIは、自動仕訳を無人運転させる仕組みではなく、①証憑を漏れなく取得し、②原本と抽出値を検証し、③権限者が判断できる根拠を提示し、④承認後に仕訳候補をERPへ連携し、⑤例外を担当者へ戻し、⑥月次締めで未処理と変更履歴を確認できる仕組みにすべきです。

AIの役割は、タイ語・英語・日本語が混在する文書から項目を抽出し、勘定科目や税区分の候補を提示し、類似案件を探すことです。ルールエンジンは、税番号、通貨、PO、受入、金額、期間、重複、承認権限など、会社が説明可能な条件を検証します。最終承認は人が行い、誰が、何を見て、どの候補を採用・修正・却下したかを監査証跡として残します。この責任分界なら、AIの利便性と内部統制を両立できます。

TOMAS TECHでは、現状診断、RFP整理、90日PoCの範囲設計だけの段階でもご相談いただけます。タイ拠点の証憑経路やERPを前提に、どこを自動化し、どこに人の承認を残すかを整理したい方は、お問い合わせページからご連絡ください。

なぜAI-OCR導入だけでは請求書処理の自動化が止まるのか

請求書の文字を読めることと、会計処理を安全に完了できることは別問題です。AI-OCRが請求書番号、日付、取引先名、税額を抽出しても、その文書が正規の証憑か、同じ請求書を二重登録していないか、発注・受入と整合するか、源泉税やVATの扱いが妥当か、費用をどの期間へ計上すべきかは、周辺データと業務ルールを使わなければ判断できません。

タイ拠点では、紙やPDFに加えてe-Tax Invoice & e-Receiptの電子データ、取引先ポータル、メール添付、スキャン画像など入口が増えます。タイ歳入局はe-Tax Invoice & e-Receiptの公式ポータルを提供し、電子税務取引に関するICT標準として情報セキュリティ、電子データ保管、データ形式、データ交換、電子署名等を公開しています。したがって、経理システム側も「画像から値が取れた」だけで終わらず、原本、構造化データ、検証結果、承認結果を関連付けて保持する設計が必要です。

よくある失敗は、OCRのデモでは精度が高く見えたのに、本番で例外が増えるケースです。原因は、評価対象がきれいな請求書に偏る、手書き追記やスタンプがある、複数言語・複数通貨が混在する、クレジットノートや前払が通常請求書と同じ経路に入る、といった業務のばらつきをPoCに含めていないことです。もう一つは、抽出後の確認画面が使いにくく、担当者が結局Excelへ転記するケースです。これはAIの問題ではなく、閉ループ全体の設計不足です。

既に三点照合を検討している場合は、タイ製造業の入荷・請求書照合も参照してください。本稿はその前後、つまり証憑の入口、承認、仕訳候補、例外、月次締めまでを対象にしています。製品比較の評価軸はタイ製造業向けAI-OCR比較・RFPで補完できます。

タイ拠点で作る「人が承認する閉ループ」

1. 証憑取得：メール・紙・e-Tax・ポータルを一つの受付台帳へ

最初に統一すべきものはファイル形式ではなく、受付台帳です。どの経路から届いた証憑にも受付ID、受領日時、送信元、法人、拠点、文書種別、原本の保管場所、処理状態を付けます。メール添付はメールIDと結び、スキャンはスキャン担当と機器を記録し、電子データは受信ファイルと検証情報を保持します。ファイルを上書きせず、原本は変更不可領域に保存します。

取得時点でウイルス検査、ファイル破損、パスワード保護、ページ欠落、同一ハッシュ、既知の請求書番号などを確認します。読めない文書も捨てず、「要再取得」としてキューに残すことが重要です。経理 AI 効率化の入口で欠落を許すと、月末に未計上費用の探索が発生し、後工程の自動化効果を打ち消します。

2. 抽出とデータ入力自動化：AIは値と根拠位置を返す

AI-OCRは、抽出値だけでなく、元ページ、座標、原文、信頼度、使用モデルの版を返すようにします。担当者が請求書番号を確認するとき、原本を別画面で探す必要がなく、抽出箇所をすぐ比較できるUIが望まれます。タイ語の会社名と英語表記が混在する場合、正規化後の取引先マスター候補と原文の両方を表示します。

データ入力自動化の対象は、ヘッダー項目だけではありません。明細、VAT、源泉税に関する情報、PO番号、契約番号、原価センター候補、支払条件も候補化できます。ただし、AIが返した値をそのまま正とせず、必須項目の有無、桁数、日付範囲、合計と明細の整合、通貨、マスター存在確認をルールで検証します。

3. 検証：ルールと参照データで「説明できる判定」にする

検証層では、AIの確信度だけを合否に使いません。たとえば税番号が取引先マスターと一致する、請求書番号が過去伝票と重複しない、請求日が会計期間内にある、POと受入情報が存在する、合計金額が内訳計算と一致する、といった決定論的ルールを優先します。ルールの版、実行日時、入力値、結果、例外理由を保存すれば、後から同じ判定を説明できます。

e-Withholding Taxについて、タイ歳入局は、参加銀行を通じて支払い、銀行が正確で完全な情報を送信した場合、税・支払情報を支払日から6営業日以内に検索できると案内しています。したがって、支払直後に検索結果がないことだけでエラーと断定してはいけません。処理状態には「待機中」を持たせ、公式に示された時間差を前提に再確認する運用が必要です。

4. 承認：金額と例外に応じて人へルーティングする

承認者には、原本、抽出値、変更箇所、ルール違反、PO・受入・契約の参照、仕訳候補、過去の類似処理を一画面で提示します。承認権限は法人、部門、金額、費目、取引先、関連当事者などで分けます。代理承認の期間と理由も記録し、自己承認や職務分離違反をシステムで防ぎます。

重要なのは、担当者がAI候補を修正できるだけでなく、修正理由を選択・記述できることです。「税区分誤り」「取引先マスター違い」「費用期間変更」「例外的な契約条件」などを構造化して蓄積すれば、モデル改善とルール改善を区別できます。何でも再学習に回すと、例外的判断を通常ルールとして学習する危険があります。

5. 転記作業自動化 AI：承認済みの仕訳候補だけをERPへ

ERP連携は、AIが直接本番台帳へ書き込む構成を避け、承認済みの仕訳候補をインターフェース台帳へ渡します。連携ID、会計伝票番号、送信日時、応答、再送回数、取消・逆仕訳との関係を保持します。ERP側でエラーになった場合、同じ伝票を重複送信せず、冪等キーで再処理します。

勘定科目、税コード、原価センターの候補は、取引先、品目、契約、部門、過去の承認済み仕訳を使って提示できます。しかし、候補の採用条件と人の承認を残し、AIだけでマスターを新規登録しないことが基本です。転記作業自動化 AIの価値は、キー入力をなくすことよりも、承認されたデータを同じ意味のままERPへ届け、照合可能なIDを戻すことにあります。

6. 例外処理：正常系より先にキューを設計する

実務では、例外処理の速度が月次締めを決めます。例外は「OCR低信頼」の一種類ではありません。証憑不足、取引先未登録、POなし、受入差異、税務判断待ち、重複疑い、期間外、承認者不在、ERPエラーなどに分け、所有者、期限、エスカレーション先を設定します。

キューには優先順位だけでなく、締めへの影響を示します。金額が小さくても前払・固定資産・関連当事者取引などは判断が必要です。反対に、ルールに完全一致する反復取引は確認を簡素化できます。ただし、どの条件で簡素化したかを記録し、サンプルレビューやルール変更時の再評価を可能にします。

7. 月次締め：未処理・変更・連携失敗を一つの統制画面で見る

締め画面では、受領済み未処理、承認待ち、例外、ERP未連携、連携エラー、取消、翌月繰越を法人・拠点・担当者別に表示します。件数だけでなく、証憑IDから原本、判断、仕訳、ERP伝票まで追跡できる必要があります。締め後にデータが変わった場合は、変更前後、実行者、承認者、理由を残します。

この閉ループが完成すると、経理責任者は「AIが何件読んだか」ではなく、「どの証憑が、どの統制を通り、誰が承認し、どの伝票になり、何が未処理か」を管理できます。それが監査可能な経理 AI 効率化です。

AI-OCR導入のRFPに入れるべき要件

RFPは機能一覧ではなく、受入判定ができる質問と証跡要件で書きます。「AI対応」「ERP連携可能」だけでは、責任範囲も完成条件も判断できません。次の表をベンダー回答の共通様式にすると、比較しやすくなります。

RFPには、ベンダーが「標準機能」「設定」「個別開発」「外部製品」「顧客運用」のどれで満たすかを明記させます。データの保存国・保存期間、学習利用の有無、サブプロセッサー、モデル変更時の通知、ログの取得方法も確認します。契約書の説明と実システムの設定が一致するか、PoC中に証拠で確かめます。

実務では、RFP回答を受け取った後に「証跡デモ台本」を作ると比較の質が上がります。同じ匿名化サンプルを各社へ渡し、受領、抽出、ルール違反、差戻し、再承認、ERPエラー、再送、取消までを同じ順序で操作してもらいます。画面が動くことだけでなく、各時点の状態が台帳に残り、後日検索・出力できるかを確認します。さらに、設定変更を誰が申請し、誰が承認し、どの環境で試験し、いつ本番へ反映したかも提示させます。契約部門だけで採点せず、経理実務、IT、情報セキュリティ、内部監査が同じ証跡を見て評価し、未充足要件には代替統制、担当者、解消条件を付けます。デモ当日の口頭回答は議事録に残し、契約条件、設定表、受入テストのどこへ反映するかを明確にします。本番移行後の問い合わせ窓口、障害時の判断者、手作業へ切り替える条件も、PoC終了前に運用手順へ落とし込みます。これにより、製品の多機能さではなく、自社の月次締めを安全に支えられるかで選定できます。

AIガバナンスは抽象論にしません。NIST AI RMFは任意利用の枠組みで、Govern、Map、Measure、Manageの4機能を示しています。これを経理へ読み替えると、責任と方針を定め、利用場面と影響を整理し、精度・例外・統制を測り、問題を是正・停止する流れになります。Generative AIを仕訳説明や問い合わせ補助に使う場合は、NISTのGenerative AI ProfileやETDAのガイドも、リスク項目の見落とし防止に使えます。

ETDAはAI 2026の発表で、利用可能なAIガバナンスのガイドライン／ツールキットを12件とし、2026年に2件を追加開発中と説明しています。これは製品認証や法令適合を自動的に意味する数字ではありません。RFPでは、参照したガイド名、対象範囲、実装した統制、残るリスクをベンダーに具体化させてください。

TOMAS TECHの90日PoC：請求書処理自動化を段階検証する

以下の90日は法令上の期間や公的な標準ではなく、TOMAS TECHが提案する導入モデルです。目的は、AI-OCRの単体テストではなく、限定した法人・拠点・文書群で閉ループを運転し、業務、統制、連携、運用の受入可否を判断することです。

Day 1–15：基準値を測り、対象を絞る

最初に代表的な正常文書だけを選ばず、主要取引先、言語、通貨、紙・PDF・電子データ、POあり・なし、クレジットノート、読みにくいスキャンを含む評価セットを作ります。個人情報や機密情報の取扱いを決め、PoC環境へ持ち込めるデータだけを使います。

基準値は、受付から承認までの所要時間、手作業の接触時間、差戻し、重複、未処理、ERP連携エラーを、自社で定義して測ります。ここで外部の平均値を目標にしないことが大切です。拠点ごとに証憑経路と承認段階が違うため、自社基準と比較しなければ投資判断に使えません。

Day 16–30：データ契約とルールを先に固める

抽出項目の名前、型、必須条件、原文保持、欠損表現を「データ契約」として定義します。ERP側の取引先、科目、税コード、原価センターとどのキーで結ぶかを決めます。AIモデルを変更してもインターフェースが壊れないよう、AI出力を直接ERP仕様に依存させず、正規化層を挟みます。

Day 31–60：人の修正を計測し、例外分類を改善する

並行運転では、現行手順をすぐ停止せず、AI候補と現行処理を比較します。不一致を単に「AI誤り」とせず、原本不備、マスター不足、ルール不足、UI誤操作、AI抽出、会計判断に分類します。AI以外の原因を分けることで、適切な改善先が見えます。

Day 61–75：月次締めと障害をリハーサルする

平常時だけでなく、承認者不在、ネットワーク断、ERP停止、同一ファイル再送、マスター変更、締め後修正を試します。復旧後に二重伝票が作られないこと、未処理が消えないこと、操作履歴が残ることを確認します。

Day 76–90：Go判断を定量と統制で行う

Go判断はOCR精度一つにしません。対象範囲内で、手作業の接触時間がどう変わったか、例外がどこに残ったか、承認者が根拠を確認できたか、ERP連携が追跡できたか、監査証跡を再現できたか、運用担当が障害へ対応できたかを評価します。合格しない項目がある場合、条件付きGoとして対象を狭める選択肢もあります。

効果試算：データ入力自動化を仮定で比較する

以下は特定企業の実績や業界平均ではなく、投資評価方法を示すための仮定試算です。自社の件数と時間で置き換えてください。通貨換算や市場価格も使っていません。

計算は、5,000件×8分＝40,000分、5,000件×3分＝15,000分です。時間は分を60で除し、金額は時間に仮定の400 THBを掛けています。丸めがあるため、表示値には「約」を付けています。この差額をそのまま現金削減とみなしてはいけません。削減時間を再配置できるか、ライセンス、導入、保守、例外対応、内部管理、監査の費用がいくらかを別に評価します。

さらに、処理時間だけでなく、締め時点の未処理、重複疑い、差戻し、ERPエラー、承認滞留の変化を測ります。ただし目標値はPoC開始時に自社基準から決め、外部根拠のない成功率を約束しないことが重要です。

監査証跡とAIガバナンスを実装要件に変える

最低限残すべき監査証跡

監査証跡は操作ログの山ではありません。一件の証憑について、次の因果関係を再現できることが必要です。

1. どの原本を、いつ、どの経路で受領したか。
2. どのモデル版が、どの値を、どの原文位置から抽出したか。
3. どのルール版が、どの参照データで、何を合否判定したか。
4. 誰が候補を修正し、理由を記録したか。
5. 誰がどの権限で承認・差戻し・却下したか。
6. どの連携IDでERPへ送り、どの伝票番号が返ったか。
7. 取消、再送、逆仕訳、締め後修正がどうつながるか。

ログは時刻、利用者、役割、操作、対象、変更前後、理由、システム応答を含め、一般利用者が変更できないようにします。検索とエクスポートができ、監査人へ必要範囲だけ提示できるアクセス制御も必要です。タイ歳入局のICT標準が扱う情報セキュリティ、電子データ保管、データ形式、データ交換、電子署名などを、自社の対象取引に照らして確認します。具体的な法令・税務判断は資格を持つ専門家へ確認してください。

AI変更管理と停止手順

モデル、プロンプト、抽出スキーマ、ルール、マスター連携の変更は、それぞれ版管理します。変更前の評価セットで再テストし、承認後に本番へ反映します。モデルの提供者が版を更新する場合も、自社が受入確認できる契約と構成が望まれます。

異常を検知したら、AI候補提示だけを停止し、手作業の受付・承認・ERP連携へ切り替えられるようにします。停止が全業務停止を意味する設計では、月次締めの継続性を損ないます。NIST AI RMFのGovern、Map、Measure、Manageを使い、責任、利用場面、測定、対応を運用会議の項目へ落とし込みます。

システム構成とデータ境界

推奨構成は、受付層、原本保管、抽出層、正規化・検証層、ワークフロー、連携台帳、ERP、監査ログを分けます。生成AIを使う場合は、社外サービスへ送る項目、マスキング、保存、学習利用、越境、削除を明確にします。プロンプトへ不要な個人情報や契約全文を入れず、目的に必要な最小範囲を渡します。

BOTのPaymentページは、タイの決済統計と統計APIに関する案内として参照できますが、一般企業が個別の銀行明細を取得するAPIの仕様ではありません。RFPで「BOT API連携」と曖昧に書かず、必要なのが統計データなのか、自社口座の取引データなのか、銀行または決済事業者との契約APIなのかを区別してください。

e-Tax連携を別途設計する場合は、タイe-Tax InvoiceとERP連携も合わせて確認すると、原本・電子署名・連携の論点を整理できます。

導入前チェックリスト

• 対象法人、拠点、文書種別、言語、通貨、件数を定義したか。
• 全ての証憑経路を受付台帳へ集約できるか。
• 原本を上書き不可で保持し、抽出値から追跡できるか。
• AI出力を候補として扱い、決定論的ルールで検証するか。
• 承認権限、代理、職務分離、差戻しを設定できるか。
• 修正前後と修正理由を保存できるか。
• ERP連携に冪等キー、応答、再送、取消の証跡があるか。
• 例外に所有者、期限、締め影響、エスカレーションがあるか。
• モデル、プロンプト、ルールの版と評価結果を管理するか。
• AI停止時の代替手順と復旧テストがあるか。
• 保存、削除、アクセス、委託先、学習利用を契約と設定で確認したか。
• KPIを自社の基準値から定義し、外部根拠のない効果を前提にしていないか。

よくある質問

経理 AI 効率化とは、仕訳を完全自動化することですか？

いいえ。本稿で推奨するのは、AIが抽出値と仕訳候補を提示し、ルールエンジンが説明可能な検証を行い、権限を持つ人が承認する方式です。承認済みデータだけをERPへ連携し、原本から伝票まで追跡します。反復的な確認を減らしつつ、責任の所在を消さないことが目的です。

請求書 処理 自動化はAI-OCRだけで実現できますか？

AI-OCRは入口の重要機能ですが、それだけでは不十分です。受付、重複検知、マスター・PO・受入との検証、承認、仕訳候補、ERP連携、例外管理、月次締め、監査ログまでつながって初めて、処理全体が効率化します。

データ入力 自動化で最初に対象にする項目は何ですか？

請求書番号、日付、取引先、通貨、税抜額、税額、合計、PO番号など、原本とマスターで検証しやすい項目から始めます。勘定科目や税区分は候補提示にし、根拠と承認を残します。対象は自社文書の品質と例外頻度を見て決めます。

転記作業 自動化 AIでERPへ直接登録してもよいですか？

AIが未承認の値を本番台帳へ直接書く構成は推奨しません。承認済み候補を連携台帳からERPへ送り、冪等キー、ERP応答、伝票番号、再送・取消を記録する方式が安全です。例外は人へ戻します。

AI-OCR 導入のRFPでは精度をどう評価しますか？

単一の平均精度ではなく、言語、文書種別、取引先、項目、画像品質ごとに評価します。抽出だけでなく、修正時間、例外分類、承認、ERP連携、監査証跡も受入条件にします。評価データに本番の難しい文書を含め、ベンダーの学習用データと分離します。

90日PoCは公的な標準期間ですか？

いいえ。90日はTOMAS TECHの提案モデルです。Day 1–15、16–30、31–60、61–75、76–90の段階で、現状、構築、並行運転、締め・障害リハーサル、Go判断を進めます。対象範囲や社内承認に応じて調整します。

e-Withholding Taxの情報が支払直後に見つからない場合は異常ですか？

直ちに異常とは限りません。タイ歳入局は、参加銀行で支払い、銀行が正確で完全な情報を送信した場合、支払日から6営業日以内に検索できると説明しています。システムでは待機状態と再確認日を管理し、必要に応じて銀行・専門家へ確認します。

まとめ

タイ拠点の経理 AI 効率化は、OCRの読取率競争ではなく、証憑取得、検証、承認、仕訳候補、例外処理、月次締めを一つの閉ループにする経営課題です。AIは候補提示に使い、説明可能なルールと人の承認を中心に置きます。RFPでは証跡と責任分界を質問に変え、90日PoCでは難しい文書と障害を含めて運転し、自社基準で効果と統制を判断します。

現状の証憑経路が複雑で、PoC範囲やRFP要件から整理したい場合も対応できます。TOMAS TECHはタイ拠点の業務・ERP・内部統制を一緒に確認し、実行可能な閉ループを設計します。お問い合わせからお気軽にご相談ください。

参考情報・出典

• Thai Revenue Department: e-Tax Invoice & e-Receipt
• Thai Revenue Department: ICT Standards for Electronic Tax Transactions
• Thai Revenue Department: e-Withholding Tax portal
• ETDA: AI 2026 / Driving Trust AI Governance
• ETDA: Generative AI Governance Guideline
• NIST: AI Risk Management Framework
• NIST AI 600-1: Generative AI Profile
• Bank of Thailand: Payment statistics and API information