海外の仕入先から届く英文の品質保証協定書を和訳し、自社の品質基準と条項ごとに並べて、条件の違いと確かめるべき点を購買と品質の担当に示す

処理の起点を決める

受付のフォルダに協定書が保存されたことを起点にします。 Python のスクリプトを30分おきに動かし、新しいファイルを拾います。保存のときに、仕入先名と新規・更新・改訂の別をファイル名か添えた一覧に書かせます。 この2つが無いものは処理せず、保存した人に戻します。

更新・改訂のときは、前の版の対照表も一緒に読みます。 前の版から変わった条項に印を付けると、担当は変わったところから見られます。 前の版が見つからなければ、新規と同じ扱いにします。

入力データを集める

質を決めるのは、2つ目の自社の基準の項目一覧です。 基準の文書をそのまま渡すと長く、項目の単位もぶれます。項目ごとに1行で、求める条件と数値を書き出し、番号を付けます。 数値の条件は、プログラムが比べられるよう「90日」「事前」のように単位と向きを分けて持たせます。

3つ目の訳語集は、訳をそろえるためです。 同じ deviation が、ある協定書では「逸脱」、別の協定書では「特別採用」と訳されると、対照表を並べて見たときに同じものだと分かりません。

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

定義の条項を先に取るのは、定義された用語の意味が協定書ごとに違うからです。 「Product」がその仕入先の全製品を指すのか、特定の品目だけを指すのかで、協定書の適用範囲が変わります。 定義の条項は最初に訳させ、以降の条項の訳で同じ訳語を使わせます。

別紙を落とさないでください。 変更の通知の期限や受入の不良率の上限が、本文ではなく別紙の表に書かれていることがあります。本文だけを読むと、数値の条件が「協定書に記載なし」に見えます。

AIへ渡す前に整形する

1. テキスト化 … PDFからテキストを取り出し、ワープロの形式はテキストに変換します
2. 条項の分割 … 「1.」「1.1」「Article 3」のような番号付きの見出しで条項に分け、番号を付けます
3. 定義の取り出し … 「Definitions」の条項から、定義された用語の一覧を作ります
4. 数値の取り出し … 「thirty (30) days」「five (5) years」「100 ppm」のように、数値・単位・前後の言葉（prior to、within、after、at least）を一覧にします
5. 前の版との比較 … 更新・改訂のときは、条項ごとに前の版の本文と比べ、変わった条項に印を付けます

4番目で、数字の表記ゆれをそろえます。 英文の契約では「thirty (30) days」のように数字を2回書くことが多く、そのまま数えると同じ数値が2つになります。「(30)」の括弧書きを優先して1つにそろえ、単位を日・年・月・ppm・％に直します。 「business days」と「calendar days」は分けて持ちます。営業日と暦日で、30日の重みが変わるからです。

AIに処理させる

させることは2つです。1つ目は条項ごとの和訳と対応づけ、2つ目は自社の基準の項目ごとの違いの区分です。

1つ目は、条項ごとに次のものを返させます。

義務を負う側を分けて返させるのは、同じ条項の中で主語が入れ替わるからです。 「Supplier shall notify Buyer」と「Buyer may audit Supplier」が並んでいると、訳を読むだけでは誰の義務かが曖昧になります。

留保の文言を別に返させるのも同じ理由です。 「Buyer may audit Supplier's facility upon prior written consent of Supplier」は、監査の権利があるように見えて、仕入先の書面の同意が条件になっています。 訳文の中に溶かさず、別の欄に出させます。

2つ目は、自社の基準の項目ごとに、1つ目の結果と数値の比較の結果を見て、違いの区分と確かめる点を書かせます。

4行目が起きやすい失敗です。 自社の基準を一緒に渡すと、AIは協定書の訳の中に自社の基準の条件を混ぜることがあります。「通知する（90日前まで）」のように、原文に無い数値が訳に入ると、違いが消えます。 訳は原文だけから作らせ、引用の照合で確かめます。

指示内容を固定する

1つ目（条項ごとの和訳と対応づけ）の指示です。 システムプロンプトに「英語の原文を日本語に訳す」ことを書いたうえで、次の指示を渡します。

あなたは製造業の品質保証部で、海外の仕入先から届いた
英文の品質保証協定書を検討する担当です。
条項ごとに、英語の原文を日本語に訳し、自社の基準の項目に対応づけてください。

【条項ごとに返すもの】
- quote: 条項の英文を、そのまま写してください。言い換えないでください。
- translation: 日本語訳。訳語集の訳を使ってください。
  定義の条項で定義された用語は、定義の条項と同じ訳にしてください。
- modal: 義務を表す語。shall / must / will / should / may / none から選んでください。
  1つの条項に複数あるときは、文ごとに分けて返してください。
- obligor: 義務を負う側。supplier / buyer / both / none から選んでください。
- qualifiers: 「upon prior written consent」「to the extent reasonable」
  「unless otherwise agreed」のような留保の文言を、英文のまま写してください。
- mapped_items: 対応する自社の基準の項目番号。無ければ空にしてください。

【厳守事項】
- 訳は原文だけから作ってください。自社の基準の条件を訳に書き足さないでください。
- shall と should と may を、同じ日本語にしないでください。
  shall・must は「〜しなければならない」、should は「〜すべきである（推奨）」、
  may は「〜することができる」と訳してください。
- 数値は原文の数値と単位を残してください。
- 意味が一つに決まらない文は、訳の後ろに【解釈が分かれる】と書いてください。
- 受け入れてよいかどうかは書かないでください。

【訳語集】{glossary}
【定義の条項の訳】{definitions}
【自社の基準の項目一覧】{own_items}
【条項（番号付き）】{clauses}

2つ目（項目ごとの違いの区分）の指示です。

自社の基準の項目ごとに、協定書の対応する条項と比べて違いを判定してください。

【区分】
- same ........ 自社の基準と同じか、それより厳しい
- looser ...... 自社の基準より緩い
- conditional . 留保の文言が付いている
- missing ..... 対応する条項がない
- unclear ..... 対応する条項はあるが、意味が一つに決まらない

【決まり】
- 数値の比較は、与えられた比較の結果をそのまま使ってください。
  自分で数値を比べ直さないでください。
- 自社の基準が shall で、協定書が should や may なら looser にしてください。
- evidence には、根拠にした協定書の英文をそのまま写してください。
- 確かめる点は、仕入先に英語で聞ける具体的な問いにしてください。
- 迷ったときは same を選ばず、unclear にしてください。

【自社の基準の項目一覧】{own_items}
【条項ごとの結果】{clause_results}
【数値の比較の結果】{number_compare}

1つ目の指示で shall と should と may の訳し方を決めているのは、訳を読む人が助動詞を見なくても強さが分かるようにするためです。 そのうえで modal の欄にも原文の語を残し、訳と原文の二重で確かめられるようにします。

2つ目の指示で「数値を比べ直さない」と書いているのは、比較をプログラムに置いた意味を守るためです。

出力形式を固定する

2つの呼び出しとプログラムの結果を、次の形のJSONにまとめて対照表にします。

{
  "agreement_id": "",
  "supplier": "",
  "type": "new | renewal | revision",
  "rows": [
    {
      "own_item_id": "QA-05",
      "own_requirement": "",
      "clauses": [
        { "clause_no": "7.2", "quote": "", "translation": "",
          "modal": "shall | must | will | should | may | none",
          "obligor": "supplier | buyer | both | none",
          "qualifiers": [], "quote_found": true, "changed_from_prev": false }
      ],
      "numbers": [
        { "own": "90日・事前", "agreement": "30 calendar days・prior",
          "result": "looser" }
      ],
      "verdict": "same | looser | conditional | missing | unclear",
      "question_to_supplier": ""
    }
  ]
}

1つ目の理由は、行が自社の基準の項目だということです。 協定書の条項は clauses の中に入り、1つの項目に複数の条項が対応しても、対応する条項が無くても、行は必ず1つあります。 missing の項目が表から消えません。

2つ目は、quote_found で引用を確かめられることです。 AIが写した quote が協定書の本文にあるかを、プログラムが文字列で確かめます。Anthropic の公式ページは、長い文書を扱う作業では、先に原文の引用を逐語で取り出させてから作業させると、実際の文に根ざした応答になり、作り話が減るとしています。見つからない引用は、その行を unclear にして人に回します。

3つ目は、modal と qualifiers を訳と別に持てることです。 対照表で looser と conditional の行だけを抜き出すと、仕入先に修正を求める候補の一覧になります。

構造化出力は、enum の値の大文字・小文字が保証されないとされているので、大文字・小文字を区別せずに比べます。拒否や max_tokens での打ち切りではスキーマに合わない出力になりうるので、stop_reason を見て、打ち切りなら条項をいくつかに分けて呼び直します。

システムへ連携する

仕入先へのメールにはつなぎません。 修正の依頼は、品質保証と購買の担当が決めてから、購買の担当が送ります。

人が確認する

品質保証の担当が全件を確かめます。 見る順番を決めておきます。

1. quote_found が false の行を先に見る … 引用が協定書に無いものは、原文で該当の条項を探します
2. looser と missing を見る … 品目の重要度と照らして、修正を求めるか、受け入れるかを決めます
3. conditional を見る … 留保の文言の英文を読み、実際に権利が使えるかを考えます
4. unclear を見る … 原文を読み、解釈が分かれる点を仕入先に確かめるか決めます
5. 責任・補償の条項を法務に回す … 保証の期間、損害の範囲、補償の上限は法務が確かめます
6. 判断を記録する … 受け入れた・修正を求めた・確かめたを、項目ごとに残します

修正の依頼は、question_to_supplier の英文の下書きをもとに購買の担当が書きます。 対照表の行番号と協定書の条項番号を添えると、仕入先の側も、どの条項の話かをすぐに追えます。

3番目の conditional を軽く見ないでください。 留保の付いた監査の権利は、いざ不具合が起きたときに使えないことがあります。 品目の重要度が高い仕入先では、留保を外す修正を求めるのが基本です。

例外に対処する

6行目は、見落とされやすい違いです。 「30 days」が営業日なら約6週間、暦日なら1か月です。単位があいまいなまま same にすると、自社の基準より短い期限を受け入れることになります。

記録を残す

• 協定書の原本と版、受け取った日、仕入先名
• 使った自社の基準の項目一覧と訳語集の版
• 2回の呼び出しの指示と応答の全文、使ったモデル
• 引用の照合と数値の比較の結果
• 担当が受け入れた・修正を求めた・確かめたの記録と、その理由
• 仕入先とのやり取りと、締結した版

5つ目は、次の更新のときの比較元になります。 前回「受け入れた」と決めた条件が、更新でさらに緩くなっていないかを見られます。