海外から届いた引き合いを訳し、見積に足りない条件を先方の言語で聞き返す

処理の起点を決める

「引き合い」のラベルが付いた未読メールを、一定の間隔で取り出すことを起点にします。 返信の速さがこの構成の目的なので、1日1回の定時実行にはしません。 朝にまとめて処理すると、前日の午後に届いた引き合いは翌朝まで誰の目にも触れません。

ラベルは、メールボックス側の振り分け規則で付けます。代表アドレスには売り込みや求人の応募も混ざるため、広めにラベルを付け、引き合いでないものはAIの判定で落とします。

取り出したメールは既読にし、処理が終わったら「処理済み」のラベルに付け替えます。 付け替えは成功したときだけにします。「引き合い」のラベルが残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、2つ目と3つ目です。 見積条件の一覧が無ければ、AIは一般的な「見積に要りそうなこと」を並べ、自社では要らない質問まで先方に送ります。 製品の呼び名の一覧が無ければ、先方が書いた呼び名から製品分類を決められず、どの条件の一覧を使うかが決まりません。

見積条件の一覧の例（標準品と特注品）：

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

メールは Watch emails で取り出し、本文はテキストの形で受け取ります。 フォームの通知メールは「Country: 」「Quantity: 」のように項目名と値が並んでいるので、その並びを崩さずにそのまま渡します。 項目名があることで、AIが値を見つけやすくなります。

スレッドの照合を先に行います。 聞き返しへの返信なら台帳の既存の行に結び付け、2行目を作りません。

AIへ渡す前に整形する

1. 署名と引用の除去 … 「-----Original Message-----」「在 … 写道：」のような引用の区切りより下を落とします。過去のやり取りの条件を、今回の条件として読ませないためです
2. 定型文の除去 … フォームの通知メールの前置きや、送信元の免責文を落とします
3. 送信者の情報の分離 … 署名にある会社名・国・電話番号は、本文とは別の欄として渡します。国は仕向地の候補ではなく、送信者の所在として扱います
4. スレッドの確認 … 既存の引き合いへの返信なら、前回の判定結果を一緒に渡します
5. 添付の印付け … 添付がある場合は、ファイル名と「添付あり」を付けて渡します。添付の中身はこの構成では読みません
6. 長さの確認 … 本文が極端に長いもの（数十品目の一覧を本文に貼ったもの）は、判定に回さず人に回します

3番目を軽く見ないでください。 署名の住所が中国で本文に仕向地が無ければ、AIは「仕向地：中国」と書きたくなります。実際にはベトナムの工場へ納める引き合いかもしれません。

AIに処理させる

させるのは、次の3つです。 言語を判定して日本語に訳すこと、見積条件の8項目それぞれについて「書かれているか」を判定して根拠の原文を写すこと、そして別の呼び出しで、聞き返す項目だけを使った先方の言語の下書きを作ることです。

右端の列が、この構成でいちばん大事な区別です。 missing は書かれていないこと、unclear は書かれているが見積に使える値に決まらないことです。聞き方が違うので、分けて記録させます。 もう1つの conflicting は、本文の中で数量や納期が2通り書かれている場合です。

貿易条件は、Incoterms の規則名で書かれていることが多い項目です。 国際商業会議所（ICC）の現行版は Incoterms 2020 で、11の規則があるとされています。どの規則で見積るかは営業が決めることで、AIには選ばせません。 AIがするのは、書かれた規則名と場所を原文のまま写すことだけです。

1行目がいちばん起きやすい失敗です。 仕向地が無い引き合いを渡すと、署名の国から埋め、その瞬間、見積のやり直しにつながる質問が1つ消えます。

指示内容を固定する

1回目の呼び出し（訳と条件の判定）の指示です。

あなたは産業用部品メーカーの海外営業部で、新しい引き合いを受け付ける立場です。
渡された本文だけを見て判定してください。推測で埋めないでください。

【手順】
1. 本文の言語を判定し、日本語に訳してください。
   型番・数値・単位・固有名詞は訳さず、原文のまま残してください。
2. 引き合いかどうかを判定してください。売り込み、求人への応募、
   既存の注文の問い合わせは not_inquiry とし、条件の判定をしないでください。
3. 次の8項目について、status を選び、根拠にした原文をそのまま写してください。
   product / specification / quantity / delivery_date /
   destination / trade_terms / currency / application

【status の選び方】
- stated ....... 見積に使える値が書かれている
- missing ...... 書かれていない
- unclear ...... 書かれているが、値に決まらない（ASAP、large quantity、
                 単位の無い数字、国だけの仕向地、場所の無い貿易条件など）
- conflicting .. 本文の中で値が2通り以上書かれている
迷ったときに stated を選ばないでください。

【厳守事項】
- 書かれていない項目は missing にしてください。他の情報から補わないでください。
- 送信者の署名の国・住所を、仕向地として扱わないでください。
- 自社がよく使う貿易条件や通貨を、書かれていない項目に入れないでください。
- 「ASAP」「尽快」などを具体的な日付や期間に置き換えないでください。
- 数量の単位を換算しないでください。原文の単位のまま写してください。
- 型番は原文の文字列のまま写し、似た型番に直さないでください。
- 価格・納期の見込み、輸出の可否について何も書かないでください。
- evidence には、判定の根拠にした原文をそのまま写してください。
  missing の場合は空にしてください。

【本文】{body}
【送信者の情報】{sender}
【前回の判定（返信の場合のみ）】{previous_result}
【製品の呼び名の一覧】{product_names}

「送信者の国を仕向地にしない」は、明記しないと必ず起きます。 禁じるのは、書かれていない値を別の欄から持ってくる判断そのものです。

2回目の呼び出し（聞き返しの下書き）は、ワークフローが決めた「聞く項目」の一覧だけを渡します。

次の引き合いに対し、{language} で返信の下書きを書き、同じ内容の日本語訳を付けてください。
- 最初に、問い合わせへのお礼と、見積の準備を始めたことを1文で書いてください。
- 聞くのは【聞く項目】だけです。【書かれていた条件】は聞き直さず、
  「〜と承りました」と復唱してください。
- unclear の項目は、答えやすいよう選択肢か具体的な例を添えて聞いてください。
- 価格、納期、在庫の見込みは書かないでください。
- 件名には {inquiry_no} を入れてください。
【聞く項目】{questions}
【書かれていた条件】{stated_items}

「書かれていた条件を復唱する」のは、第3章の（d）への対策です。 復唱があれば、先方は読まれたことが分かり、AIが読み違えていた場合は先方が訂正してくれます。

出力形式を固定する

1回目の呼び出しは、次の形のJSONで受け取ります。

{
  "is_inquiry": true,
  "detected_language": "zh",
  "translation_ja": "",
  "sender": { "company": "", "country": "", "contact_name": "" },
  "product_category": "standard | custom | unknown",
  "conditions": [
    { "item": "quantity",
      "status": "stated | missing | unclear | conflicting",
      "evidence": "", "value_ja": "" }
  ],
  "has_attachment": false,
  "notes_for_sales": ""
}

conditions には、この形の要素を8つ並べます。Make の Generate a response で Output Format を JSON schema にし、このスキーマを渡します。

1つ目の理由は、スキーマどおりの形が保証されることです。 OpenAI の Structured Outputs は、応答が渡したJSON Schemaに従うようにし、必須のキーが抜けたり、enum にない値が作られたりする心配をなくすとされています。status を enum で4つに絞れば、「partially stated」のような5つ目の値は返りません。

スキーマの作り方には決まりがあります。 strict を有効にする場合、すべての項目を required に並べ、additionalProperties を false にする必要があるとされています。値が無いことを表したい項目は、null との組み合わせ（例：["string", "null"]）で表します。安全上の理由で応答を断った場合は、スキーマの代わりに refusal の欄が返るとされているので、その場合は人に回します。

2つ目の理由は、status と「聞くかどうか」を別の層に置けることです。 conditions はAIが埋め、聞く項目はワークフローが見積条件の一覧で決めます。

要は、質問を増やしすぎないことです。 最初の返信で7つも聞くと、先方は答えずに他社へ移ります。聞き方の方針が変わっても、直すのはこの規則だけです。

2回目の呼び出しは、reply_body（先方の言語）と reply_body_ja（日本語訳）、subject の3つを返させます。 担当者は日本語訳の側で、聞いている項目が合っているかを確かめます。

システムへ連携する

メールは送りません。下書きまでです。 送信を自動にすると、訳の誤りや読み違いがそのまま先方に届きます。最初の返信は、その会社の第一印象そのものなので、人の手を通します。

台帳の「状態」は、ワークフローが決めます。 聞く項目があれば「聞き返し待ち」、無ければ「見積可」、引き合いでなければ「対象外」です。

人が確認する

人が確かめるのは、台帳に新しく追加された行すべてです。 ただし訳文を全文読み直すことはしません。

1. 数値と型番を原文と照らす … evidence に写された原文と、訳文の数量・型番・日付が合っているかを見ます。ここは必ず見ます
2. missing が本当に無いかを確かめる … 本文の後半や署名の下に書かれていないかを原文で見ます。書いてあることを聞き返すのが、いちばん印象を損ねます
3. 下書きを直して送る … 日本語訳を見て、聞いている項目と復唱している条件が合っているかを確かめ、送ります
4. 判定を覆したら記録する … どの項目を、どの status からどれに変えたかを台帳に残します

2番目を省かないでください。 AIの読み落としは、長い本文の後半で起きやすくなります。原文の検索で「pcs」「port」「deliver」「交期」を探すだけでも、見落としの多くは拾えます。

読めない言語の原文でも、1番目はできます。 数字と型番は言語に関係なく原文の中で見つけられます。

例外に対処する

上から2行目を軽く見ないでください。 本文が「Please see attached RFQ」の1行だけの引き合いを本文だけで判定すると、8項目すべて missing の聞き返しを送ることになります。

記録を残す

• 元のメール（本文、送信者、受信日時、スレッドの識別子）
• 1回目の呼び出しの出力（訳、conditions、製品分類）と、そのとき使った見積条件の一覧の版
• 2回目の呼び出しの下書きと、実際に送った文面
• 人が判定を覆した記録（どの項目を、どの status からどれに変えたか）
• 受信から最初の返信を送るまでの時間
• 聞き返しに先方が答えたか、何往復で見積に進んだか

2つ目で一覧の版を残すのは、一覧が後から変わるためです。 当時の基準が分からないと、過去の判定と比べられません。

最後の2行が、成果を測る材料です。 工数より、最初の返信までの時間と往復の回数を見てください。