タイ工場の輸入通関書類をAI照合｜発注・船積・申告前の導入設計

タイの工場が海外から設備、補修部品、原材料を調達するとき、購買担当者が発注した内容と、仕入先が作ったインボイス、梱包明細、運送書類、通関用のデータが同じ内容を指しているとは限りません。型番の末尾、数量の単位、通貨、荷受人、箱数などの小さな違いが、輸入担当者と通関業者の確認往復を生みます。現場では「通関書類をAI-OCRで読めば解決する」と考えがちですが、読んだ文字が正しいかと、複数の書類の内容が業務上整合しているかは別の問題です。

本稿はタイに拠点を持つ製造業の輸入者側に向け、AIで差異候補を見つけ、人と通関業者が判断・承認する仕組みの導入方法を示します。対象は発注書（PO）、商業インボイス、パッキングリスト、船荷証券または航空運送状、申告用の準備データです。輸出者が発行書類を作る仕組みや、HSコードをAIに自動決定させる仕組みとは目的を分けます。輸入申告そのものの法的判断は、担当者と適切な専門家の作業として残します。

既存の輸出書類のAI-OCR記事は輸出者が発行・確認する側を扱います。またHSコード分類へのAI活用記事は分類判断の支援を主題にしています。本稿は輸入者が複数の受領文書を突き合わせ、申告前の差異を人へ渡す工程に限定します。

なぜ「同じ貨物の書類を横に並べる」ことが先なのか

タイ税関のレムチャバン港税関の案内は、輸入申告と関連書類を挙げ、船荷証券・航空運送状、インボイス、パッキングリスト、該当する場合の許認可や原産地証明を示しています。また、輸入者または通関業者がe-Customsへ申告する流れを説明しています。米国商務省のタイ向けガイドも、輸入申告に商業インボイス、パッキングリスト、運送書類などの標準的な船積書類が伴うとしています。実際に必要な資料や提出形式は貨物・輸送経路・制度によって異なります。ここで挙げた一覧を、すべての輸入案件に同じ書類が必須という意味で使わないでください。

書類間の照合は、文書を一つずつ正しく読み取るだけでは成立しません。インボイスの品名は仕入先の商品名、POは自社の品目コード、運送書類は輸送単位、パッキングリストは箱やパレットの単位で表されます。「500 PCS」と「50 BOX × 10 PCS」は数量として一致するかもしれませんが、単位換算と梱包構成を確認して初めて判断できます。「Model AB-100」と「AB100-R」は似ていても別仕様の可能性があります。AIが見た目だけで同一品目と断定してしまうと、差異を見逃すことになります。

輸入者側の仕事は、海外仕入先から届いた書類をそのまま申告へ流すことではありません。発注時の期待値、実際の船積内容、輸入する法人・拠点、契約条件、マスタデータを照らし、申告データに渡す前の疑問を解消することです。書類が揃ってから検査するのでは遅い案件もあります。船積前のドラフト・インボイスから差異を拾えば、仕入先が原本を確定する前に確認を返せます。一方、出荷後にしか確定しない運送番号や箱数は後段の確認に回します。工程ごとに「その時点で確定している情報」を分ける必要があります。

対象を「輸入申告を作るAI」ではなく「申告前の照合ワークフロー」に絞る

最初の導入範囲は、書類受領から差異の確認、修正版の再受領、承認済みデータの引き渡しまでにします。受信箱、共有フォルダ、仕入先ポータルなどからファイルを取り込み、案件番号とPO番号で束ね、原本と版を保存します。AI-OCRや文書解析は書類の種類と明細を読み取り、照合エンジンは正規化した値を比較します。結果は「一致」「要確認」「読取不明」「対象外」のように分け、人が根拠画像を見ながら解消します。承認後に必要な項目だけを通関業者や既存システムへ渡します。

この境界が重要なのは、AIの推測と申告責任を混同しないためです。タイ税関の案内では輸入者または通関業者による申告が説明され、WCOのデータモデルも取引書類の情報と運送書類の情報を区別しています。AIは入力を整え、相違を可視化できますが、貨物の実体、関税分類、原産地、評価、規制対象の判断を無条件に承認できません。たとえばAIがインボイスの品名からHSコード候補を表示しても、それは候補です。適用するコードと根拠は、商品仕様を理解する担当者と通関の専門家が確認してください。判断が難しい場合は、タイ税関の事前教示制度など適切な正式手続を検討します。

「すべての行が一致したら自動申告」という条件も避けます。異なる書類が同じ誤りを共有している場合、相互照合だけでは発見できません。POそのものが旧版、仕入先の品名マスタが誤り、設備の構成部品が別梱包になっている場合もあります。システムは差異検出と証跡保存を担当し、案件の承認権限と申告の責任は業務上の役割に置きます。自動化率よりも、重大な不整合を申告前に見つけ、担当者が説明できる状態を優先します。

書類を結ぶキーを決める。ファイル名だけでは案件にならない

設計の出発点は「何を同じ輸入案件とみなすか」です。PO一件に複数のインボイスが紐づくことも、一つのコンテナに複数のPOが入ることもあります。インボイス一件に複数の運送書類が対応する場合もあります。したがって、ファイル名やメール件名だけから一対一対応を決める方式は危険です。案件IDを内部で採番し、発注番号、仕入先、インボイス番号、輸送番号、納入先、予定到着日を関係として保存します。関係が不確かなものは「紐付け候補」に留め、担当者が確定します。

POを基準にできる案件では、承認済みの発注版を期待値にします。POの改訂があれば旧版と新版を保存し、どの版に対して仕入先のインボイスが作られたかを記録します。発注数量と船積数量に差がある場合、分納やバックオーダーの承認記録を確認します。購買側がPOを修正したばかりで仕入先側の文書が旧版なら、単純に「仕入先の誤り」と扱うべきではありません。差異の責任先を機械的に決めず、改訂履歴を画面に並べます。

POの無い緊急部品や無償サンプルでは、別の承認済み依頼書や案件台帳を基準にします。基準文書が無い案件をAIが勝手に「一致」と判定することはできません。基準未設定という独立した例外にし、輸入担当者が期待値を登録してから照合します。これにより、見かけの照合成功率を上げるために曖昧な文書を処理済みにすることを防げます。

どの項目を照合するか：書類の列を増やす前に、業務上の意味を定義する

初期の照合対象は、識別、数量、金額、輸送、通関判断の五群に分けると整理しやすくなります。識別には輸入者名、仕入先名、PO番号、インボイス番号、品目コード、型番、品名を含めます。数量には明細数量、単位、梱包数量、総箱数、必要に応じた正味・総重量を含めます。金額には単価、通貨、明細金額、合計、値引きや別建て費用を含めます。輸送には荷受人、船積地、到着地、船荷証券・航空運送状番号など、案件に適用される項目を含めます。通関判断には品目仕様、原産地表示、許認可の有無、社内で承認済みの分類候補とその根拠を置きます。

各フィールドには、比較元、比較先、正規化方法、許容条件、承認者を明記します。たとえば仕入先名は表記ゆれ辞書で同一法人候補を出せますが、銀行口座や法的な輸入者が違えば自動で同一扱いしません。品目番号は先頭ゼロや記号の有無をどう扱うかを決めます。数量はPCS、SET、KG、BOXをひとまとめにせず、換算根拠を品目マスタか梱包明細から取得します。インボイスの金額は四捨五入のルールや通貨を明示し、異なる通貨を単純比較しません。税額や関税評価に関わる判断は、単なる書類一致とは別のレビュー項目にします。

比較表には「値の差」と「差の理由」を分けて見せます。PO 1,000個、インボイス900個なら差は100個ですが、分納の承認があれば例外として解消できます。梱包明細で90箱、各箱10個なら計算上900個と一致します。ただし箱内訳が明記されていなければ、AIが勝手に10個入りと補完しない設計が必要です。推測した内容は原文と別欄に表示し、確認者が根拠を見られるようにします。

読取と照合を分け、低品質な入力を「不一致」と混ぜない

スキャンが斜め、表の列が重なっている、ページが欠けている、スタンプが金額を覆っているなど、読取に失敗する理由は多様です。AI-OCRの出力を比較する前に、ファイルの種類、ページ枚数、画質、重複、明細行の連続性を確認します。文字が読めない項目を空欄として取り込んだ結果、POとの「不一致」に分類してしまうと、担当者は仕入先に不要な修正依頼を送ることになります。低信頼の読取は「画像の再取得・人の転記確認」、読めた上での値の違いは「業務上の差異」として別キューにします。

読取結果には、原文、正規化値、出典文書ID、ページ、位置、版、抽出モデルの版を持たせます。画面で赤く示した差異をクリックすると、左右の原本の該当箇所へ飛べることが重要です。「AIが違うと言った」だけでは仕入先や通関業者に説明できません。PDFのテキスト層を利用する場合でも、埋め込みテキストが画面表示と異なる可能性があります。重要項目では表示画像との照合を評価に入れます。

同一項目が複数箇所に出る書類にも注意します。インボイスのヘッダーに合計数量、明細に品目別数量、フッターに箱数があるとき、どれを比較したかを区別します。単に「Quantity」という語の隣の数字を拾うだけでは不十分です。複数ページの明細が続くときは、ページ境界をまたいだ行の重複・欠落を試します。手書き訂正、訂正印、改訂版の差替えは、通常の清書版とは別のサンプル群で検証します。

ルールエンジンとAIをどう分担させるか

確定した同値比較や算術は、説明可能なルールで行います。PO番号の完全一致、インボイス番号の重複、明細金額の合計、数量×単価、梱包の内訳、必須項目の欠落などは、入力値が十分に確かなら決定的に計算できます。AIは表の読み取り、文書種類の判定、名称や型番の候補紐付け、差異の説明文案で役立ちます。ただしAIの「似ている」は承認の根拠ではありません。型番の末尾一文字が安全仕様や電圧を変える部品なら、文字列距離が近いほど危険な見逃しになります。

照合ルールは「不一致なら全部赤」では運用が続きません。致命的な差異、仕入先に確認する差異、社内マスタの補正、単なる表記差を区別します。重要度は項目ごとの業務リスクから決めます。たとえば別法人宛、別通貨、商品仕様の違いは出荷・申告前の停止候補になります。社内略称と正式名称の差は承認済みの対照表があれば表示だけでよいかもしれません。閾値は部署が承認した文書にし、モデルの確信度と混同しません。

「99%精度」という宣伝値よりも、重大な誤りをどれだけ見逃したかを評価します。文字単位の認識率が高くても、インボイス番号や数量の一桁を間違えた案件は手戻りにつながります。PoCでは、照合項目別の抽出正解率、重大差異の検出率、誤警報率、人の確認時間、未読取率、再提出率を別々に計測します。入力文書と業務判断の正解データは自社の代表案件から作り、仕入先や品目の偏りが出ないようにします。

差異の処理先を設計する：誰が何を直すのか

差異には少なくとも四つの処理先があります。仕入先が発行したインボイスや梱包明細の誤りは仕入先へ照会します。社内POの古い版や誤発注は購買担当へ戻します。運送番号や荷受人の相違は物流担当・フォワーダーが確認します。商品仕様、原産地、HS分類の疑問は技術担当と通関担当・通関業者の確認が必要です。一人の輸入担当者の受信箱にすべてを戻すと、AIで差異を見つけても待ち行列が移るだけです。

差異チケットには、案件ID、差異の種類、原文の引用位置、期待値、受領値、重要度、担当者、期限、質問先、回答、添付した修正版、承認履歴を記録します。回答がメールで届いたら、その内容と新しい書類の版を結び付けます。旧版を上書き削除すると、何が変わり、なぜ承認したかを後で追えません。版は残し、「この版を通関準備に採用」と明記します。承認者が差異を許容した場合も、理由と根拠文書を残します。

多言語の現場では、画面の項目名やエラー説明をタイ語・英語・日本語で揃える一方、原本の文言は翻訳で置き換えないことが大切です。訳語で商品仕様が丸められると、通関業者への伝達が変わる可能性があります。原文、必要な翻訳、承認済み品目マスタの名称を別々に表示します。翻訳は担当者の理解を助ける層であり、原本や許認可文書の正式な記載を変更するものではありません。

申告用データとの連携は、承認済みの範囲だけにする

WCOデータモデルは、取引書類や運送書類などの異なる情報を、通関・越境手続向けに構造化して扱う考え方を示しています。輸入者側のシステムでも、この発想を使い、どのデータがどの書類から来たかを追える形にします。ただしWCOの標準を採用しただけでタイの申告仕様に適合するわけではありません。実際の連携項目、形式、権限は利用する通関業者や対象システムの仕様で確認します。

連携方式は、承認済みCSVの安全な受け渡し、通関業者のポータル入力、API連携、ERPからの出力などから選びます。どの場合も「AIが読んだ値」を直接提出用に上書きしないようにします。承認済みスナップショットを作り、担当者、版、日時、対象書類を固定し、その後に修正が入れば新しい版として再承認します。通関業者から修正依頼が来たときは、何の根拠で値が変わったかを差分として残します。

ERP連携で特に難しいのは、品目マスタの粒度です。購買システムでは「製造装置一式」、インボイスでは構成品ごと、梱包明細では箱ごとの記載になり得ます。一対一の品目コード前提で自動マッピングすると、未照合の構成品が消えて見えることがあります。機械やスペアパーツの初回導入では、仕様書や部品表を確認し、マッピングの例外ルールを作ります。品目マスタを改善できるなら、AIの後処理で無理に吸収するより先にマスタを整えた方が安定します。

小さなPoCの作り方：まず実案件の差異を見つけられるか

評価セットを作るときの落とし穴

過去の案件を集めるだけでは、評価セットとして不十分なことがあります。社内に保存された最終版しか残っていない場合、実際に苦労した訂正前のインボイスや、仕入先から来た読みにくいスキャンが抜けます。可能なら、受領した順のファイルと問い合わせ履歴を残し、「最初の受領時点で何を発見できたか」を再現します。そうしないと、完成した文書をAIに読ませて高い正解率を出しても、手戻り削減の検証になりません。

評価セットには「差異がある案件」だけでなく、「差異がない案件」も含めます。全件に警告を出すシステムは重大差異の見逃しが少なく見えますが、人が一件ずつ開くので業務効果はありません。確認者が受け入れられる誤警報の量、警告を見たときに実際の問題へ到達できるまでの時間を測ります。また、品目コードの末尾や通貨のような重大項目では、平均正解率より見逃し事例を個別にレビューします。たまたま一つの書式で成功した結果を、全仕入先に一般化しないためです。

別の落とし穴は、正解ラベルを一人で作ることです。インボイスの読み取り値は輸入担当者が確認できても、品目の実体や型番の互換性は技術担当の判断が必要です。分納の承認は購買が持ち、運送書類の訂正は物流担当が知っています。曖昧なケースでは二人以上で根拠を照らし、正解がまだ決まらないものは「判定不能」と記録します。AIに一つの正解を強制するより、人へのエスカレーションが正しく働くかを評価します。

失敗を先に定義する

PoCでは正常系のデモだけでなく、失敗時の操作を要求します。文書の種類を誤認した、別案件へ紐付けた、AIが明細を一行落とした、仕入先から同じ番号の改訂版が届いた、ネットワーク障害で連携が途中まで終わった、といった場面です。失敗を検知した際にどの状態で止まるか、担当者へ何を示すか、再処理で二重登録しないかを見ます。静かに誤った値を出力する失敗は、単に処理が止まる失敗より危険です。

ベンダーのデモ画面で原本の一部分をハイライトできても、実運用の承認証跡になるとは限りません。承認画面で見た値が後から変わらないか、承認者以外が設定を変えられないか、再処理後に過去の判断と新しい候補を区別できるかまで試します。後で通関業者から問い合わせが来たとき、どの文書のどの版を誰が採用したかを数分で取り出せることが、案件単位の照合システムの価値です。

PoCはページを何枚読めたかではなく、輸入担当者の確認仕事が改善したかを測ります。対象を一つの調達カテゴリ、二〜三の主要仕入先、一つの輸送ルートなどに絞り、標準的な案件と例外案件を混ぜます。実案件には社外秘情報が含まれるため、サンプルの持ち出し条件、保存先、閲覧権限、保持期間を先に決めます。委託先やクラウドサービスに資料を渡す場合は契約・社内規程に沿って扱います。

評価用の正解データは、担当者が原本と購買・物流記録を見て確定します。「書類に書いてあった数字」と「業務上採用すべき数字」は異なることがあるため、両方を保存します。サンプルに入れるべき例は、分納、複数POの混載、通貨変更、単位換算、型番の類似、箱数の変更、差替えインボイス、スキャン欠損、複数言語の品名です。実際に起きていない問題を人工的に作るだけでなく、過去の手戻り事例を匿名化して使うと評価の意味が増します。

PoCの合格条件は導入前に決めます。たとえば「指定した重大差異を一件も見逃さない」「確認画面で原本箇所へ到達できる」「一つの差異の担当者と承認履歴を追える」「同じファイルを再投入しても案件が二重にならない」といった条件です。数値目標は自社の実測値に合わせて設定し、他社の精度や工数削減を保証値として転用しません。合格できない場合は、書類の標準化、受領方法、マスタの改善、対象の絞り込みを見直します。

RFPでベンダーに渡すべき項目と、デモで確認する手順

要件を「一枚の帳票」ではなく「案件の状態遷移」で書く

現場の入力から申告準備までを、受領、案件紐付け、読取、照合、差異割当て、修正版受領、承認、引渡しの状態に分けます。各状態について、誰が進められるか、何が不足していれば止まるか、差戻し後にどの状態へ戻るかをRFPに書きます。たとえばインボイスの訂正版が届いたら、前版の承認をそのまま引き継がず、変更された金額・品目・数量に関わる照合を再実行します。梱包明細だけ差し替わった場合でも、箱数や重量の関連項目を再確認します。全件を最初からやり直す必要はありませんが、変更点と依存する項目を追えなければ、既存の「承認済み」という表示が誤解を招きます。

購買、物流、経理、輸入担当、通関業者の間には、同じ項目でも保有する情報の時点が違います。PO番号は購買が早く知り、実船名や運送番号は物流が後で知り、インボイス確定額は仕入先が持ちます。システムには「未受領」「受領したが未確定」「確定・承認済み」を区別する状態が必要です。空欄をすべてエラー扱いすると早期のドラフト確認に使えず、空欄をすべて無視すると提出前の不足を見逃します。工程ごとの必須項目を別に定義し、承認時だけ厳しいゲートを設けます。

また、書類はメール本文、PDF添付、Excel表、スキャン、ポータル上のデータとして届きます。どの経路を正式な受領とするかを決め、メールの件名だけで輸入案件を特定しないようにします。同じインボイス番号で「final」「revised」「corrected」と名付けられたファイルが並ぶとき、ファイル名ではなく文書番号・発行日・内容差分・送付者を確認して採用版を記録します。旧版を破棄する運用を選ぶ場合でも、変更の証跡が残る保管方針を事前に定めます。

RFPには「AI-OCRで通関書類を読めること」だけを書かず、対象文書と照合ルール、承認フローまで指定します。文書ごとの年間・月間量、ページ数、仕入先別の書式、言語、PDFと画像の割合、明細行の最大数、差替え頻度を整理します。参照するPO・品目マスタ・仕入先マスタの取得方法、通関業者への引渡し方式、保管とアクセス制御、ログ出力も記載します。未確定の制度や業者固有の仕様は「確認項目」とし、RFPでベンダーに断定させないようにします。

デモでは、ベンダーが選んだきれいなサンプルだけを見ないことです。自社で許可した匿名化案件を渡し、原本受領から差異表示、担当者への割当て、修正版の再投入、承認、出力まで一連で実演してもらいます。型番の一文字違いと同一品目の別表記を混ぜれば、AIの誤判定が分かります。複数POと一つのインボイスが交差する案件では、紐付けの曖昧さをどう扱うか確認できます。途中で人が「この候補は違う」と直した内容が、次回処理と監査ログへどう反映されるかも見ます。

見積もりはOCR単価だけで比べません。受信・仕分け、読取、品目マッピング、照合ルール、承認画面、ERP連携、通関業者とのインターフェース、運用監視、保守を分けて出してもらいます。低価格の読取APIでも、例外処理を手作業で抱えれば総費用が増えます。逆に、件数が少なく書式が安定しているなら、固定ルールと簡易ワークフローで十分な場合もあります。自社文書でのPoC結果と運用費を合わせて判断してください。一般的なAI-OCR導入プロセスはこちらの実践ガイドでも整理しています。

本番運用のKPIは「早く通った」だけで測らない

投資対効果は案件単位で組み立てる

導入費の妥当性を測るには、帳票一ページの単価より、一案件にかかる全作業時間を見ます。現行業務の代表案件を記録し、書類の受領・案件整理、読み取り、差異確認、仕入先への問い合わせ、修正版の再確認、通関業者への引渡しにかかる時間を分けます。AI導入後も、レビューと例外対応の工数は残ります。導入費にはOCR利用、ワークフロー、ERP接続、運用監視、サプライヤー書式変更への対応も含めます。回収を試算する際は、削減できる反復作業と、新たに発生するチェック・保守作業を両方計上します。

初期PoCの値をそのまま全社へ掛け算しないことも重要です。PoC対象の仕入先が文書品質の高い会社ばかりなら、書式がばらつく取引先を含めたときに再確認率が上がります。逆に、初期に難しい書類だけを集めると、全体の効果を過小評価します。仕入先、品目、輸送経路、書類品質の層ごとに案件数と処理時間を見て、拡大時の前提を明記します。短縮時間を「通関日数」に直接置き換えず、まず自社が制御できる確認工程のリードタイムを評価します。

マスタとルールの変更管理を運用費に入れる

照合が安定するかどうかはモデル単体よりも、取引先マスタと品目マスタの品質に左右されます。仕入先の会社名変更、工場移転、新しい型番、包装単位の変更、POシステムの改修があるたびに、照合辞書やルールの更新が必要です。変更者、承認者、適用日、影響する過去案件の扱いを決めます。たとえば「1 BOX = 10 PCS」という換算値を品目マスタに登録する場合、その値がどの製品・どの包装仕様・どの期間に有効かを限定します。普遍的な換算として扱うと、仕入先の梱包変更を見逃します。

モデルの改善についても、承認者の修正を無条件に正解として学習させないでください。承認者が誤って許容したケースや、暫定対応として手入力した値が混ざるからです。差異チケットから学習候補を抽出し、業務オーナーが確認したものだけをルール・辞書・抽出設定へ反映します。更新前後の比較セットを保存しておけば、新しい仕入先への対応で既存仕入先の抽出が悪化していないか確認できます。

開始後は、受領から差異検出までの時間、差異解消までの時間、仕入先への差戻し件数、重大差異の見逃し、誤警報、未読取率、再提出率、承認待ちの滞留を追います。通関処理時間は税関審査や輸送の外部条件に左右されるため、システム単独の効果として扱いません。「AI導入後に通関が何日短縮」といった主張は、比較対象と外部要因を分けて測ってから行うべきです。

運用では、新しい仕入先の書式、品目の追加、通貨や契約条件の変更、文書版の増加が性能を変えます。月次で誤検出・見逃しの実例をレビューし、ルール辞書やマスタを更新します。モデルの更新時は、以前の代表サンプルを再実行し、重大項目の退行がないか確認します。承認者が頻繁に理由なしで例外を許容しているなら、閾値設定や業務ルールが現場と合っていない可能性があります。

情報管理面では、インボイスに取引価格、仕入先情報、場合によっては連絡先が含まれる点に注意します。利用者ごとの権限、保存期間、暗号化、委託先のアクセス、ログの扱いを調達・IT・法務の担当者で決めます。個人情報が含まれる場合の法令対応も、扱うデータと委託形態に応じて確認します。AIサービスへの入力を学習に利用するかどうかは、サービスの契約条件と設定を個別に確認してください。

導入を決める前のチェックリスト

部門間で決めておく三つの境界

第一は「書類の誤り」と「契約変更」の境界です。インボイスの数量がPOと異なっても、仕入先の単純な誤記とは限りません。分納の合意、購買側の変更、サンプルの同梱などの可能性があります。AIは差を示し、購買が商流上の変更を承認したかを確認します。仕入先へ訂正を依頼する前に、どの文書が最新の合意を表すかを確認できるフローにします。

第二は「書類にある値」と「申告に採用する値」の境界です。たとえば品名が社内略称で書かれていても、申告用には商品の実体を表す説明が必要かもしれません。AIが社内名称から説明を自動生成しても、その説明が仕様書と一致するかは人が確かめます。価格、数量、原産地、HS分類などの重要項目は、原本の値、調整後の値、調整理由を別に残します。どちらかを上書きして消すと、後から差の説明ができません。

第三は「社内承認」と「通関業者の確認」の境界です。社内で書類の整合を承認しても、通関実務上の要件が満たされたとは限りません。通関業者が追加資料や修正を求めた場合は、輸入者側の承認済みデータに戻して再確認します。メールだけで新しい数値を伝え、システム側は古いままにすると、次の輸入で同じ誤りを繰り返します。通関業者からの指摘を案件の差異履歴へ戻し、必要ならマスタとルールの改善につなげます。

これらの境界を会議で決める際は、実際の書類を机に並べてください。抽象的な業務フロー図だけでは、どの欄が確定値で、どの欄が暫定値か見落としやすくなります。過去の差戻し案件を一つ選び、最初に誰が違いに気づき、どの証拠で解消し、いつ通関業者へ渡したかを時系列で確認すると、必要な画面と権限が具体化します。

• [ ] 発注版、インボイス、梱包明細、運送書類を同じ案件へ結ぶルールがある
• [ ] POなし、分納、混載、訂正インボイスを例外として扱える
• [ ] 読取不明と書類間の不一致を別のステータスにできる
• [ ] 数量単位、通貨、品目コードの正規化ルールと根拠が明文化されている
• [ ] 原本のページ・位置・版と、訂正・承認履歴を追える
• [ ] HSコード・原産地・評価・許認可の判断者が決まっている
• [ ] 通関業者への引渡しが承認済みデータに限られる
• [ ] 重大差異の見逃し、誤警報、確認時間を自社の実案件で測る
• [ ] 保管、権限、委託先、削除の条件が契約と運用に入っている

ここまで決めれば、AI-OCR製品の比較は具体的になります。認識精度だけでなく、輸入案件の束ね方、差異の根拠、担当者の承認、通関業者との連携を同じ条件で比べられるからです。既にAI-OCRの候補製品を調べている方は、価格を六つの層で比べる記事も併せてご覧ください。

よくある質問

Q. インボイスとパッキングリストの数字が一致すれば自動申告できますか？

それだけでは判断できません。PO、運送情報、商品仕様、必要な許認可など他の確認対象があり、二つの書類が同じ誤りを共有している可能性もあります。AIは一致と差異の候補を示し、輸入担当者と通関業者が採用するデータを確認します。

Q. HSコードはAIに選ばせられますか？

商品説明から候補を探す補助には使えますが、最終分類をAIの推測だけで確定しないでください。仕様、用途、構成、適用する税番の解釈を確認し、必要に応じて専門家や正式な事前教示を使います。本稿の照合システムでは、承認済みコードと文書の記載に差があれば人に知らせる設計にします。

Q. 書類がPDFならOCRは不要ですか？

テキストを抽出できるPDFなら文字認識を省ける場合があります。ただし明細表の構造、画像として埋め込まれたページ、表示とテキスト層の差、改訂版の扱いは残ります。導入前に実際のファイルで抽出と照合を試してください。

Q. 最初はどの案件から始めるべきですか？

処理件数が一定以上あり、PO・インボイス・梱包明細が揃い、確認に時間がかかっている調達カテゴリが適しています。制度判断が複雑な特殊貨物を最初から広く含めるより、差異を測定できる範囲で承認フローを完成させ、その後に対象を広げる方が評価しやすくなります。

TOMAS TECHへの相談：資料を見て、どこを照合するかから決める

TOMAS TECHはタイの製造業・物流業向けにAI-OCRの導入支援と業務システム連携を提供しています。輸入通関書類のAI照合を検討している場合は、匿名化したPO、インボイス、パッキングリスト、差戻し事例をご用意ください。対象項目、例外、既存ERP・通関業者との受け渡し、PoCの評価条件を一緒に整理します。AIで差異を見つけ、人が根拠を確認して承認する運用を設計したい方は、お問い合わせからご連絡ください。

参考資料

1. タイ税関レムチャバン港税関「Import Procedures」 — 輸入申告、関連書類、e-Customsの流れ。
2. タイ税関サダオ税関「輸入通関手続」 — 陸路の手続、運送書類・インボイス等の例。
3. 米国商務省「Thailand: Import Requirements and Documentation」 — 輸入書類と対象品目による追加要件。
4. 米国商務省「Thailand: Customs Regulations」 — e-Customs、分類と事前教示の概説。
5. 世界税関機構「WCO Data Model」 — 越境手続の標準化されたデータ定義。
6. 世界税関機構「Guidance on Main Class Levels」 — 取引書類と運送書類の情報源の区別。
7. タイ税関「Customs Act（非公式英訳）」 — 関税分類等の事前教示に関する規定。法的判断にはタイ語原文と最新の所管案内を確認。

*本稿は輸入者側の業務システム設計を説明するもので、個別貨物の通関・法務判断を代行するものではありません。制度の適用は最新のタイ税関・所管官庁の案内と通関専門家に確認してください。*