海外の拠点・仕入先とやり取りする品質の是正要求と回答を、用語をそろえて双方向に訳す

処理の起点を決める

起点は3つあります。往復だからです。 出すときと受け取るときで、動かす処理が違います。

①は状態の変化を起点にします。 起票時ではなく、原稿が書き上がって「要求確定」になった時点です。書きかけの原稿を訳しても意味がありません。

②は受信箱の定期確認で組むのが確実です。 返信は件名も差出人もばらつくので、専用のアドレスに集めて15分おきに見に行き、件名に入れておいた case_id で結びつけます。 拾えないメールは人に回し、推測で結びつけません。 別の案件のものとして処理されるほうが、放置されるより害が大きいからです。

③は日単位の Schedule Trigger で組みます。 「Days Between Triggers」を1、「Trigger at Hour」を朝の時刻にします。②と③は複数のトリガールールとして1つのワークフローに追加できるので、往復の状態を持つ場所を分けずに済みます。

入力データを集める

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

書き込みは最後の1つだけで、それ以外はすべて読み取りにします。 人が受理を決める前に台帳が動くと、どこまで進んだかが分からなくなります。

AIへ渡す前に整形する

この構成の質を決めるのは用語集で、整備にいちばん手間がかかります。 200語もあれば足ります。全社の用語を網羅しようとすると終わりません。

「訳さない語」の一覧を別に持つことが、この構成のいちばん効く工夫です。 型番の英数字は、訳の過程で桁が落ちたり、ハイフンが消えたり、似た番号に寄せられたりします。そのまま通す語を一覧で渡し、出力にも do_not_translate として残します。 型番が変わると相手は別の部品の話を始め、1〜2週間を捨てます。訳語の1対1を崩さないことも同じで、「対策」に3つの英語を当てていると、暫定対策と恒久対策の区別が英語の側で消えます。

前処理では、このほかに次を行います。

1. 項目への切り分け … 原稿を8つの項目に分けます。様式に沿っていれば機械で切れます。
2. 表記ゆれの正規化 … 「暫定処置」「応急対策」を「暫定対策」に寄せます。
3. 型番の抜き出し … 正規表現で拾い、訳さない語の一覧に動的に足します。
4. 客先の名称の伏せ字化 … 客先名と担当者名を CUST_A の形に置き換えます。
5. 過去の往復の添付 … 同じ仕入先の直近3件を訳語の参考に渡します。

AIに処理させる

させることは2つです。用語集を当てて訳すことと、要求の項目と回答の記述を対応づけることです。

訳のほうは、項目ごとに日本語と英語を同じ要素の中に持たせます。別々の配列にすると片方の要素が増減したときに項目がずれ、ずれたことは並べて読むまで分かりません。

突き合わせのほうが中心です。是正要求を項目に分けて出し、回答書を同じ項目に割り付けます。 様式がこちらと違っていても、内容がどの項目に答えているかで割り付けます。 そのうえで、項目ごとに次の判定を1つ付けます。

unclear を必ず置くことが、この設計の要です。 これが無いと、判断できないものが partial か not_answered に流れ込み、訳の問題なのか回答の中身の問題なのかを切り分けられなくなります。 原文を必ず添えさせます。

3行目と4行目は、判定そのものを壊します。 数量が書き換えられれば answered の根拠が消えますし、書かれていない内容を補われれば not_answered が partial になります。突き合わせの価値は「足りないものが足りないと出る」ことにあります。

指示内容を固定する

出すときの指示（日本語から英語）

あなたは自動車部品メーカーの品質保証部門で、海外の仕入先に出す
是正要求の英訳を担当します。渡された用語集に従って訳してください。

【守ること】
- 項目は8つ（occurrence / scope / interim_action / cause / root_cause /
  permanent_action / effect_verification / due_date）です。順番を変えないでください。
- 各項目の原文を ja にそのまま入れ、訳文を en に入れてください。
- 用語集にある語は必ず用語集の英語に置き換え、
  glossary_applied に「日本語 = 英語」の形で並べてください。
- 「訳さない語」の一覧にある型番・図番・設備の固有名は、
  大文字小文字もハイフンも桁数も変えずにそのまま英文に入れ、
  do_not_translate に並べてください。
- 用語集に無い品質の用語の訳語を、自分で決めないでください。
  その項目の status を unclear にし、needs_human の reason に
  「用語集に無い語: （その語）」と書いてください。
- 原文に記載が無い項目は en を空にし、status を not_answered に、
  内容は「不明」として扱い、推測で文章を作らないでください。
- 数量・日付・ロット番号は原文の表記をそのまま使ってください。

【用語集】{glossary}  【訳さない語】{do_not_translate_list}
【是正要求の原稿】{request_draft}  【過去の要求と回答】{past_exchanges}

受け取るときの指示（英語から日本語と突き合わせ）

あなたは同じ立場で、返ってきた回答書を読み、
こちらが出した是正要求の項目に答えているかを確かめます。

【手順】
1. 回答書の記述を、是正要求の8つの項目に割り付けてください。
   見出しが違っていても、内容で割り付けてください。
2. 割り付けた記述を和訳して ja に入れ、原文は en に残してください。
3. 項目ごとに status を次の5つから1つ選んでください。
   answered / partial / not_answered / off_topic / unclear
4. status の根拠になった英語の原文を、要約せず source_quote に引用してください。

【守ること】
- 書かれていないことを補わないでください。
  「おそらく実施済みと思われる」のような補いを書いてはいけません。
  記述が無ければ not_answered です。
- 迷ったら unclear にし、何が判断できなかったかを reason に書いてください。
  partial と not_answered に寄せないでください。
- 回答の内容が妥当かどうかを評価しないでください。
  「対策として不十分である」と書いてはいけません。
  判定するのは、対応する記述があるかどうかだけです。
- 用語集にある語は必ず用語集の日本語に戻し、
  cause と root_cause を同じ語で訳さないでください。
- 型番・図番・数量・日付は、回答書の表記をそのまま写してください。
- 回答が無い項目を missing_items に並べてください。

【用語集】{glossary}
【こちらが出した是正要求】{outbound_items}
【仕入先からの回答書】{inbound_document}

「迷ったら unclear」を明示するのは、何も言わないと判定が partial に集まるからです。 どちらとも言えない記述が「触れてはいる」として処理されると、再要求の対象から落ち、落ちたことは一覧から分かりません。 「評価しない」も要ります。放っておくと対策の是非まで書き始めますが、それは担当者の仕事で、その一文が社内で事実として扱われます。

出力形式を固定する

output_config.format に、次の形のJSONスキーマを渡します。

{
  "case_id": "CAR-2026-0418",
  "direction": "inbound",
  "due_date": "2026-10-09",
  "items": [
    {
      "key": "occurrence",
      "ja": "2026年8月22日出荷のロットで、1,200個中37個に打痕があった。",
      "en": "In the lot shipped on 2026-08-22, 37 of 1,200 units had dents.",
      "status": "answered",
      "source_quote": "We confirmed 37 dented units in that lot.",
      "glossary_applied": ["打痕 = dent", "受入検査 = incoming inspection"],
      "do_not_translate": ["PN-4471-02"]
    },
    {
      "key": "interim_action",
      "ja": "", "en": "",
      "status": "not_answered",
      "source_quote": "",
      "glossary_applied": [], "do_not_translate": []
    }
  ],
  "missing_items": ["interim_action", "effect_verification"],
  "needs_human": {
    "required": true,
    "reason": "暫定対策と効果の確認方法に対応する記述が無い"
  }
}

構造化する理由は3つあります。1つ目は、ja と en を同じ要素の中に持たせるためです。 別々に作ると項目が1つずれたときに全体がずれますが、同じ要素に入れてあれば、ずれようがありません。

2つ目は、glossary_applied を残すためです。 確認する担当者は訳文を読み直すのではなく、どの語をどう置き換えたかの一覧を見ます。 暫定対策と恒久対策が正しい語に当たっているかが1秒で分かり、頭から読むより速く、しかも見落としません。

3つ目は、status を enum で固定できることです。 5つ以外の値は出力できず、additionalProperties: false でスキーマに無い項目も足されません。missing_items から再要求の文面の骨格も機械で組めます。

使えるJSON Schemaの機能には範囲があります。 enum、const、required、additionalProperties: false、$ref／$def、date などの文字列フォーマットは使えますが、minLength／maxLength、minimum／maximum、正規表現の pattern は使えません。 配列の minItems は0と1だけで、再帰的なスキーマと外部の $ref も使えません。型番の書式をスキーマで縛ることはできないので、そこは後段のプログラムで確かめます。

システムへ連携する

最後の行が、この構成の設計上の決めごとです。 送信経路を作らなければ、自動送信が起きる余地そのものが無くなります。

人が確認する

全件、人が確認します。往復のどちら側でもです。

出すときの確認は、訳文を頭から読み直すことではありません。 それでは35分が戻ります。見るのは当てた語の一覧とそのまま通した型番の2つだけです。

受け取るときの確認は、answered を飛ばします。 読むのは not_answered、partial、unclear、off_topic の4つです。source_quote があるので、訳を疑うときは原文をその場で読めます。 判定が違うと思えば担当者が上書きし、上書きを記録に残します。

例外に対処する

最後の行は軽く見ないでください。 引用が空のまま answered が付くのは、根拠を示せていないということです。全項目 answered の回答書ほど、そのまま受理されやすくなります。

記録を残す

• 是正要求の原稿（日本語）と、送信した訳文（英語）、送信した日時と宛先
• 当てた用語集の語（glossary_applied）と、そのまま通した語（do_not_translate）
• 回答書の原文と、和訳、項目ごとの判定と source_quote
• 担当者が上書きした判定と、上書きの理由
• 受理・再要求の別と、再要求なら何回目の往復か
• 用語集に無くて unclear になった語の一覧

4つ目と6つ目が、次の往復を短くします。 上書きが特定の項目に偏っていれば、要求の書き方かプロンプトを直します。unclear の語は用語集に足す候補になります。