新しい輸出案件の該非判定の前に、過去の該非判定書から型番・仕様・用途の近い品目を探し、当時の判定と根拠の項番を判定時の法令の版と並べて担当者に示す

処理の起点を決める

担当者が画面で「過去の判定を探す」を押したことを起点にします。 該非判定は、営業から案件を受け取ってから始まります。出荷の日から逆算して判定を急ぐ案件が多いので、受け取ったその場で過去の判定を引けるようにします。

索引の更新は、判定書の決裁のたびに行います。 決裁された判定書をファイルサーバーの決まったフォルダに置くと、その判定書だけを読み取って索引に入れます。 今日決裁した判定が、明日の別の案件の検索に出るようにします。

改正の表の更新は、法令の改正のたびに人が行います。 改正の情報が出たら、貿易管理室が改正された項番と施行の日を表に書き足します。 この表が古いと、第5章の3番目の印が付かなくなるので、更新の担当と期限を決めておきます。

入力データを集める

質を決めるのは、判定時の法令の版です。 判定書に版が書かれていないと、改正の表を引けません。過去の判定書は決裁の日から版を割り当て、割り当てたことを印で残します。 今日からの判定書には、版を書く欄を足します。

型番の系列の表は、fuzzy の結果を読むためのものです。 末尾の記号が「H」なら高精度、「N」なら通信の機能付き、といった意味が分かれば、型番が1文字違う判定書を見たときに、どの仕様が違うかがすぐに分かります。 経済産業省のページでも、法令等に記載の名称は一般に使われている名称と異なる場合があるとされており、名称の読み替えの表も同じ役割を持ちます。

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

判定書1件を、索引の1件にします。 照合した項番ごとの仕様の対比は、項番ごとに分けて持たせます。 一つの判定書が複数の項番を照合していることがあるためです。

組み合わせると、検索の要求はおおよそ次の形になります。

{
  "size": 8,
  "query": {
    "bool": {
      "should": [
        { "fuzzy": { "model_no": { "value": "MX-4200HN", "fuzziness": "AUTO", "prefix_length": 4 } } },
        { "match": { "spec_text": { "query": "測定範囲 0.1μm 分解能 外部通信", "boost": 2 } } },
        { "match": { "usage_text": "半導体の検査工程" } }
      ]
    }
  },
  "highlight": {
    "fields": { "rationale_text": { "number_of_fragments": 3, "fragment_size": 150 } }
  }
}

prefix_length を4にしているので、MX-4 までは完全に一致する型番だけが対象です。 系列の違う型番が、1文字違いというだけで候補に混ざるのを防ぎます。fuzzy は検索語を近い語に広げて探すもので、広げる語の数の上限 max_expansions の既定は50です。 公式のドキュメントでは、prefix_length が0で max_expansions を大きくすると性能が落ちうるとされています。

highlight は、当たった箇所だけを返させます。 公式のドキュメントでは、number_of_fragments の既定は5、fragment_size の既定は100文字です。根拠の記述のうち、今回の仕様の言葉に当たった数か所だけを画面に出し、 判定書の全文は開けば読めるようにします。

AIへ渡す前に整形する

1. 判定書を文字にする … PDF の判定書は文字を取り出し、取り出せないものは読み取りをかけます。項番ごとの仕様の対比の表は、表の形を保って取り出します
2. 項番ごとに分ける … 一つの判定書の中の、照合した項番ごとの対比と結論を分けます
3. 判定時の版を割り当てる … 版が書かれていない判定書は、決裁の日から版を割り当て、「推定」の印を付けます
4. 型番を正規化する … 全角と半角、ハイフンの有無、空白をそろえます。fuzzy は1文字の違いを数えるので、表記の違いだけで距離が増えるのを防ぎます
5. 系列の部分を切り分ける … 型番の系列の表で、先頭の系列の部分と末尾の記号を分けて持たせます
6. 名称を読み替える … 品名に名称の読み替えの表を当て、法令での名称も検索の対象に足します
7. 他社の判定書を分ける … 購入品について仕入先から受け取った判定書は、「他社の判定」の印を付けます

3番目を軽く見ないでください。 版を割り当てないと、改正の印を付けられず、古い判定と新しい判定が同じ重さで並びます。 推定の印は、決裁の記録で確かめられたものから外していきます。

7番目は、責任の所在を分けるためです。 経済産業省のページでは、メーカー等の該非判定書に誤りがあって該当のものを非該当として輸出した場合も、責任を問われるのは輸出を行う者とされています。他社の判定は、自社の判定と同じ扱いで並べません。

AIに処理させる

探すのは検索基盤で、版と改正の印は改正の表から規則で付けます。生成AIには、見つかった判定書の根拠を、担当者が読み比べられる形に並べさせます。

1行目がこの構成でいちばん大事な線引きです。 過去の判定書が「非該当」で、今回の品目の型番が1文字違うだけなら、生成AIは「同等品のため非該当と考えられます」と書きたくなります。 それを担当者が読めば、判定の筋道を飛ばして結論を写すことになります。過去の結論は事実として並べ、今回の結論には触れさせません。

4行目は、第3章の（c）への手当てです。 経済産業省のページでは、工作機械のように一つの貨物が複数の項番で規制される場合があり、見落としがないよう確認するよう注意が示されています。似た品目の別の判定書が2つの項番を照合しているのに、この判定書は1つしか照合していないときに、それを指摘させます。

指示内容を固定する

あなたは貿易管理室で、該非判定の担当者に過去の判定書を示す立場です。
渡した判定書だけを根拠にしてください。

【今回の品目】型番 {model_no}、品名 {name}、主な仕様 {specs}、
  用途 {usage}、部分品か {is_part}、元の製品 {parent_product}
【型番の系列の表から分かる違い】{suffix_meaning}
【過去の判定書】判定書ごとに文書として渡します。
  各文書には、判定時の版、版の推定か、改正の印（照合した項番が
  判定の後に改正されたか）、自社か他社の判定か、が付いています。

【やること】
1. 判定書ごとに、照合した項番と、項番ごとの結論を書く
2. 項番ごとに、結論を分けた仕様の値を、判定書の記述から書く
3. 今回の品目の仕様と比べて、値が違う項目を書く
4. 似た品目の判定書どうしで、照合した項番が食い違うときは、
   どの判定書がどの項番を照合していないかを書く

【厳守事項】
- 今回の品目が該当か非該当かを書かないでください。
  「同等品」「同じ結論と考えられる」とも書かないでください。
- 判定書に書かれた結論は、判定書の結論としてだけ書いてください。
- 改正の印が付いた判定書は、その項番について最初に
  「判定の後に改正あり」と書いてください。
- 他社の判定書は、最初に「他社の判定」と書いてください。
- 判定書と仕様書に無い値を推測で埋めないでください。
  無いものは「記載なし」と書いてください。
- 項番の意味を説明したり、法令を解釈したりしないでください。

「同等品と書かない」を明記しないと、ほぼ必ず書きます。 型番が近く、過去の結論が一つにそろっていれば、それを今回に当てはめる文章がいちばん自然だからです。結論を写す道を、言葉の段階で塞ぎます。

判定書は、Citations を有効にした文書として渡します。 公式のドキュメントでは、文書を渡して Citations を有効にすると、回答の文章に、元の文書のどこを引いたかが付いて返り、 引用の箇所は渡した文書を必ず指すとされています。カスタムの内容の文書にすると、渡したブロックがそのまま引用の単位になり、ブロックの番号で引用の箇所が返ります。 判定書を項番ごとのブロックに分けて渡し、どの項番の記述を根拠にしたかを番号で受け取ります。

出力形式を固定する

Citations は構造化出力と併用できません。 公式のドキュメントでは、構造化出力を Citations と同時に有効にするとエラー（400）になるとされています。そのため、生成AIからは引用付きの文章で受け取り、Lambda が次の形のJSONに組み直して画面に流し込みます。

{
  "query_item": { "model_no": "MX-4200HN", "is_part": false },
  "precedents": [
    {
      "ruling_id": "GH-2024-0318",
      "model_no": "MX-4200H",
      "law_version": "2024-05",
      "version_estimated": false,
      "amended_after": ["(項番)"],
      "issuer": "own | supplier",
      "items_checked": [
        { "item": "(項番)", "conclusion": "該当 | 非該当", "basis_value": "",
          "citation": { "document_index": 0, "block_index": 3 } }
      ],
      "differences": [{ "spec": "外部通信", "this_item": "あり", "precedent": "記載なし" }],
      "highlight": [""]
    }
  ],
  "coverage_warnings": [""]
}

1つ目の理由は、amended_after を結論より前に表示できることです。 照合した項番のうち、判定の後に改正されたものがあれば、その判定書は見出しの段階で色を変えます。 担当者は、改正の後の判定書を先に読めます。

2つ目は、citation で判定書の該当のブロックを開けることです。 根拠の値を画面で読んだあと、判定書のその項番の記述を開いて確かめられます。 生成AIの要約だけで判断させないためです。

3つ目は、coverage_warnings で照合の抜けを一覧にできることです。 似た品目の判定書どうしで照合した項番が食い違っていれば、今回の判定で両方の項番を見るべきことが分かります。

システムへ連携する

判定書と該非判定の一覧には書き込みません。 今回の判定書は、これまでどおり担当者が作り、責任者の決裁を経てファイルサーバーに置きます。この画面から判定書を作れる作りにすると、過去の判定書の記述をそのまま写した判定書が増えます。

受注の仕組みにもつなぎません。 出荷を止める・進める判断は、判定と決裁の結果を見て人が行います。

人が確認する

担当者が過去の判定を読み、今回の判定は法令に照らして担当者が行い、責任者が決裁します。

1. 版と改正の印を見る … 改正の印が付いた判定書は、その項番について、改正の後の法令で照合し直す前提で読みます
2. 照合した項番をそろえる … coverage_warnings があれば、似た品目が照合した項番を今回も照合します
3. 仕様の違いを確かめる … differences と根拠の値を見て、今回の品目の値が閾値のどちら側にあるかを仕様書で確かめます
4. 他社の判定を読み直す … 他社の判定は、型番と仕様が今回の品目と合っているか、判定の理由が明確か、最新の法令で確かめているかを見ます
5. 判定書を作り、決裁を受ける … 判定書に判定時の法令の版を書きます

3番目を省かないでください。 型番が1文字違うだけの派生品でも、その1文字が、閾値をまたぐ精度の違いを表していることがあります。過去の判定と同じ結論になるかどうかは、値を見て初めて分かります。

目標は、1件18分です。 過去の判定を読み、改正の印と照合の抜けを確かめ、仕様の違いを書き出すまでの時間です。判定書を探す時間と、版をさかのぼって調べる時間が、ほぼ無くなります。

例外に対処する

4行目を必ず作ってください。 改正の表の更新が遅れると、改正の印が付かないまま、古い判定が新しい判定のように並びます。 表がいつ更新されたかを画面に出すことが、印の信頼を保つ条件です。

6行目は、経済産業省のページの注意に沿ったものです。 リスト規制は装置全体だけでなく部分品や附属品も対象になる場合があり、元となる製品の名称で探して確かめる方法が示されています。

記録を残す

• 今回の品目の入力と、検索の条件
• 返した判定書の番号、判定時の版、改正の印、highlight の箇所
• 生成AIに渡した判定書と、返ってきた文章と引用の全文
• 担当者が開いた判定書と、照合し直した項番
• 今回の判定書の番号と、決裁の日（判定書の側の記録と結び付ける）
• 改正の表を参照したときの表の最終更新日

4行目は、照合の筋道を後から追うためです。 判定の根拠を問われたとき、どの過去の判定を見て、どの項番を照合し直したかが残っていれば、判定の経緯を説明できます。

最後の行は、改正の表の更新の遅れを後から確かめるためです。 改正の施行の日より後に、古い表で検索していた件数が分かれば、その期間の判定を見直す範囲が決まります。