輸入する商品の関税分類（HSコード）の候補を仕様から出して、通関前の確認資料を作る

処理の起点を決める

SharePoint の判定依頼フォルダにファイルが作成されたことを起点にします。商品部が新商品の仕様書を置くと、処理が始まります。

依頼のときに、仕様書だけでなく「輸入予定の時期」も一緒に入れてもらってください。 入港までの日数が短い案件は、事前教示の申請が間に合いません。優先順位をつけるために必要な情報です。

仕様変更の案件は、変更前の型番を一緒に登録してもらいます。変更の前後で分類が変わるかどうかが論点なので、元の判定を並べて見られる形にします。

入力データを集める

データの取得方法を決める

仕様書： PDFまたはExcelで受け取ります。PDFはそのままAIへ渡せます。表形式の材質構成（綿60％／ポリエステル40％など）が読み取れるかは、実物で確認してください。

関税率表： 税関が公表している実行関税率表を取り込み、社内のテーブルにします。更新があるため、取り込みの時期を記録し、定期的に入れ替える運用にします。 日本の関税率表は、統一商品説明及び符号化体系に関する国際協約（HS条約）に基づいており、国際的な改正の際には構造が変わることがあります。

過去の判定台帳： 材質・用途・加工の程度で検索できる形にしておきます。型番だけで引ける状態だと、似た商品を探せません。この台帳の整備が、この構成でもっとも手間のかかる準備です。

AIへ渡す前に整形する

1. 材質構成の正規化 … 「綿60％ ポリエステル40％」「Cotton 60%, Poly 40%」を同じ形に直します。構成比は分類の分かれ目になることが多い項目です
2. 用途の言い換えの統一 … 「収納用」「整理用」「小物入れ」を同じ用途として扱えるよう、社内の用途コードへ寄せます
3. 加工の程度の抽出 … 「原材料のまま」「一次加工」「完成品」の区別を、仕様書の記述から判定します
4. セット品の分解 … 複数の物品が1つの梱包に入っている場合、それぞれの材質と用途を分けて記録します。セット品は分類が特に難しいため、機械的に候補を出さず、人の確認へ回す印を付けます

AIに処理させる

2つの工程に分けます。

仕様の構造化（1回目の呼び出し）：

候補と根拠の生成（2回目の呼び出し）：

「反証を必ず書かせる」ことが、この構成の要です。 候補だけを出させると、もっともらしい説明が1つ付いてきて、人はそれを信じます。そうではない理由を並べて初めて、人が検証できる材料になります。

指示内容を固定する

あなたは、輸入貨物の関税分類を検討する貿易実務の担当者を支援します。
下の商品情報と、絞り込んだ関税率表の範囲から、分類の候補を挙げてください。

【厳守事項】
- 下に示した「関税率表の候補範囲」に含まれる項からのみ選んでください。
  記憶している番号を書かないでください。範囲外の番号を出さないでください。
- 候補は最大3つです。1つに断定しないでください。
- 各候補について、必ず次の3つを書いてください。
  (1) その項に当たると考える根拠（品名または類注の該当部分を引用する）
  (2) その項ではないと考えられる理由（反証）
  (3) 判断を確定するために必要な追加情報
- 商品情報に書かれていない材質・用途・機能を前提にしないでください。
  必要な情報が欠けている場合は missing_info に列挙してください。
- 税率、税額、原産地の判定は書かないでください。ここでは扱いません。
- 「この分類で申告してください」という書き方をしないでください。
  候補と根拠の提示までが役割です。

【商品情報（構造化済み）】
{product_spec}

【関税率表の候補範囲（類・項・号／品名／類注の本文）】
{tariff_candidates}

【自社の過去判定（材質・用途が近いもの・上位5件）】
{past_decisions}

「記憶している番号を書かない」の1行は必須です。 関税分類の番号は桁数が多く、生成AIは形式が正しい番号を容易に作れます。渡した範囲の中からしか選ばせない制約がないと、実在しない番号が出ます。

出力形式を固定する

{
  "product_id": "",
  "extracted_spec": {
    "main_material": "",
    "sub_materials": [],
    "material_ratio": "",
    "use": "",
    "function": "",
    "processing_level": "",
    "is_set_item": false
  },
  "candidates": [
    {
      "tariff_code": "",
      "description": "",
      "supporting_reason": "",
      "counter_reason": "",
      "confidence": "high | medium | low"
    }
  ],
  "similar_past_cases": [],
  "missing_info": [],
  "needs_advance_ruling": false,
  "reason": ""
}

needs_advance_ruling は、税関の事前教示を申請したほうがよいと考えられる案件の印です。候補の確信度がそろって low、または候補間で税率が大きく違う場合にここを true にします。人が判断する材料であり、自動で申請するわけではありません。

システムへ連携する

判定シートは SharePoint 上の Microsoft Lists に1件1行で作られます。貿易課が確認して分類を確定すると、次の2つへ流れます。

販売管理システムへの登録は、人が確定してから行います。 AIの候補をそのままマスタへ書き込む構成にしないでください。

通関業者への申告情報の連携は、この構成では扱いません。申告そのものは通関業者を通す前提です。

人が確認する

全件、貿易課の担当が確認して確定します。段階的な自動化もしません。

理由は、関税分類の誤りが税額の誤りに直結し、修正申告や追徴の対象になるためです。申告の内容についての責任は輸入者にあります。 この構成で減らしているのは「調べる時間」であって、「判断の責任」ではありません。

確認を速くするための設計が効きます。

• 候補3件を、根拠と反証を左右に並べて表示する
• 過去の判定台帳の近い事例を、同じ画面に出す
• missing_info に挙がった項目を、商品部への質問文の形で表示する
• confidence がそろって low の件を、リストの先頭に出す

missing_info の扱いが、実は効果を大きく左右します。 従来は「仕様書に書いていないから商品部に聞く」という往復が発生していました。聞くべきことが最初にまとまって出ると、この往復が1回で済みます。

例外に対処する

記録を残す

この業務のログは、税関から質問を受けたときの説明材料になります。

• 入力した仕様書と写真（原本）
• 抽出された構造化データ
• 提示された候補3件と、それぞれの根拠・反証
• 人が選んだ候補と、選ばなかった理由
• 確定した日、確定した担当者
• 参照した関税率表テーブルの版（取り込み時点）

最後の項目を忘れないでください。 関税率表は改正されます。「いつ時点の表に基づいて判断したか」が残っていないと、後から検証できません。

事前教示を取得した案件は、回答書の内容と取得日を台帳に紐づけます。 税関の事前教示回答書は、発出から3年間、輸入申告の審査の際に尊重されます。有効な期間を過ぎたものが台帳に残り続けないよう、取得日から管理します。