海外の顧客から届く問い合わせを訳して担当に回し、日本語で書いた回答を用語をそろえて原語で返す

処理の起点を決める

受信のZap：共有アドレスに届いたメールに、ラベルが付いたことを起点にします。 Gmail のフィルタで、サポート用のアドレス宛てのメールすべてに「CS受信」のラベルを付けます。言語はこの時点では判定しません。判定はAIの側で行い、Gmail のフィルタに言語の条件を書かないようにします。フィルタで言語を絞ろうとすると、件名だけ英語で本文が日本語のもの、その逆のものが漏れます。

返信のZap：対応表の行が更新されたことを起点にします。 Google Sheets のトリガーには新しい行と、新しい行または更新された行があります。担当者が日本語の回答を書き、状態の列を「翻訳依頼」に変えたら動くようにします。書きかけの段階で動かないよう、状態の列を後段の Filter で見ます。

受信と返信を1つのZapにしないのは、間に人の作業が入るからです。担当者が回答を書く時間は数分のこともあれば翌日のこともあり、1つのZapで待たせる設計は向きません。

入力データを集める

質を決めるのは用語集です。 1行が1つの語で、列は「日本語」「英語」「繁体字中国語」「韓国語」「タイ語」「訳さない」「種類（製品名／型番／言い回し）」です。型番は全行で「訳さない」にします。 製品名は、英語の正式名が製品ページにあるものだけ訳語を埋め、ほかは空欄にします。

返品・保証の言い回しは、文の単位で持ちます。 「未使用で、到着日から30日以内であれば返品を受け付けます」のように文ごと登録し、言語ごとの確定訳を並べます。語の単位で持つと、組み合わせ方で起算日が変わります。

注文番号や受注の内容は、この構成ではAIに渡しません。 担当者が受注管理画面で確かめ、回答の原稿に必要な分だけ書きます。

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

用語集は、版を切ってプロンプトに入れます。 シートを直接読む構成にもできますが、途中で誰かが書き換えると、同じ日のうちに訳が変わります。版番号をログに残し、どの版で訳したかを後から追えるようにします。 約400品目のうち、問い合わせに出てくるのは一部です。全件を毎回渡すと長くなるので、型番と返品の言い回しは全件、製品名は販売中のものに絞ります。

AIへ渡す前に整形する

1. テキスト化 … Formatter の変換で、HTMLのメールをプレーンテキストにします
2. 引用の切り落とし … Formatter の Split Text で、返信の引用の区切り（"On … wrote:" や "-----Original Message-----" など）で分け、先頭だけを取ります
3. 長さの制限 … Formatter の Truncate で上限の文字数に切ります。切った場合は印を付けます
4. カード番号の伏せ字 … Formatter の正規表現の置換で、カード番号に見える数字の並びを伏せ字にします
5. 重複の確認 … 同じスレッドの識別子で処理中のものがあれば、新しいメッセージとして扱います

引用の切り落としは完全にはできません。 区切りの文言はメールソフトと言語で変わり、Formatter の余分なテキストを落とす変換も、前後の空白の除去と文字数の切り詰めで、署名や引用を見分けるものではありません。取り切れなかった引用は、AIへの指示で「最新のメッセージだけを訳す」として受けます。

Formatter のステップは、Zapier のタスクの数に数えられないとされています。前処理を細かく分けても費用は増えません。

AIに処理させる

させることは3つの呼び出しに分けます。 1つにまとめると、分類を誤ったときに訳まで進んでしまいます。

逆翻訳に日本語の原稿を見せないのが大事です。 原稿を見せると、AIは原稿に寄せて戻します。ずれを見つけるための逆翻訳が、ずれを消してしまいます。

分類の3つの区分は、次のとおりに決めます。

迷ったら当たる側に倒します。 人に回るものが少し増えても、安全の申し出を通常の流れで訳して送るよりは軽い失敗です。

指示内容を固定する

受信時の翻訳（原文から日本語へ）：

あなたは工具メーカーのカスタマーサポートで、海外の顧客からの問い合わせを
日本語に訳す担当です。訳すだけで、回答や助言は書かないでください。

【守ること】
- 最新のメッセージだけを訳してください。引用された過去のやり取りは訳しません。
- 段落ごとに、原文と訳を対にしてください。
- 用語集にある語は、用語集の日本語で訳してください。
- 用語集にない製品名・商品名は訳さず、原文のまま残してください。
  そのうえで unlisted_terms に書き出してください。
- 数字、日付、注文番号、型番は、原文の表記のまま写してください。
  換算や言い換えをしないでください。
- 意味の取れない箇所は推測で埋めず、「（不明：原文を参照）」と書いてください。
- 顧客の感情や強い表現は弱めず、そのまま訳してください。

【用語集 v{glossary_version}】{glossary}
【原文】{message}

返信時の翻訳（日本語から原語へ）：

あなたは工具メーカーのカスタマーサポートで、担当者が日本語で書いた回答を
{target_language} に訳す担当です。

【守ること】
- 原稿に書かれていることだけを訳してください。足さない、省かない。
- 約束の強さを変えないでください。「検討します」を「対応します」にしない、
  「対応します」を「検討します」にしないでください。
- 用語集の「言い回し」にある文は、登録された訳文をそのまま使ってください。
  語順を変えたり、一部だけ使ったりしないでください。
- 用語集に訳語がない製品名は、原稿の表記のまま残し unlisted_terms に書いてください。
- 型番、数字、日付、金額、日数は原稿の表記のまま写してください。
- 敬語の度合いは、{target_language} の丁寧な顧客対応の文体にそろえてください。

【用語集 v{glossary_version}】{glossary}
【日本語の原稿】{reply_ja}

逆翻訳：

次の {target_language} の文を日本語に直訳してください。
読みやすく整えず、原文の語の強さと順序をできるだけ残してください。
意味の取れない箇所は「（不明）」と書いてください。
【原文】{reply_target}

「約束の強さを変えない」は、例を挙げて書きます。 抽象的に「正確に」と書くだけでは、顧客対応の文体に整える過程で「検討します」が丁寧な確約の表現に変わります。窓口の訳でいちばん困るのは、この種の変化です。

逆翻訳の指示に、元の原稿のことは書きません。 何を確かめたいかを伝えると、それに合わせて戻してきます。

出力形式を固定する

3つの呼び出しとも、Structured Outputs で JSON の形を固定します。 スキーマを渡し、strict を true にすると、応答は必ずそのスキーマに沿うとされています。必要なキーが抜けたり、決めていない値が区分に入ったりしないので、後段の Paths の条件がそのまま使えます。すべての項目を必須にし、additionalProperties を false にする必要があります。

分類の出力：

{
  "language": "en",
  "is_japanese": false,
  "flags": {
    "refund": false,
    "legal": false,
    "safety": false
  },
  "evidence": "",
  "route": "normal | escalate | stop"
}

翻訳の出力：

{
  "direction": "to_ja | to_target",
  "target_language": "en",
  "glossary_version": "",
  "segments": [
    { "source": "", "translation": "" }
  ],
  "unlisted_terms": [""],
  "unclear_parts": [""],
  "fixed_phrases_used": [""]
}

segments を段落の対にするのは、担当者が原文と訳を並べて読むためです。 対応表には、原文と訳を左右の列に書き込みます。

unlisted_terms が空でなければ、承認依頼の冒頭に出します。 用語集に足すべき語の候補でもあります。fixed_phrases_used には、用語集の言い回しから使った文を並べます。 返品条件を書いた回答でこれが空なら、登録された訳文を使っていないということです。

AIが応答を断った場合は、refusal の欄に理由が入り、スキーマどおりの出力は返りません。 出力の上限に達して途中で切れた場合は、incomplete_details の reason が max_output_tokens になります。どちらもワークフローの側で検知して、人へ回します（第7章の「例外処理」）。

システムへ連携する

Paths の枝は3本にします。 route が stop の枝で終了、escalate の枝で責任者への通知、normal の枝で翻訳と対応表への書き込みです。normal を明示の条件にし、フォールバックの枝は責任者への通知に向けます。 どの条件にも当たらない出力が来たときに、黙って訳す側へ流れないようにするためです。

Gmail へは送信のアクションを使いません。 返信の下書きの作成だけを使い、送信は担当者が下書きを開いて行います。

人が確認する

確認は Human in the Loop の承認依頼で行います。 Zap をその場で止め、担当者に承認、却下、データの変更を求める機能です。

1. 承認依頼に並べるもの … 日本語の原稿、逆翻訳、unlisted_terms、fixed_phrases_used、原語の回答の順に並べます。担当者が読むのは上の2つです
2. 見比べる点 … 約束の強さ、数字と日数、否定の向き（「できます」と「できません」）、宛先の取り違え
3. 却下したら … 対応表の日本語の原稿を直し、状態を「翻訳依頼」に戻します。原語の文を担当者が直接直すことはしません
4. 承認したら … 返信の下書きが作られ、担当者が開いて送ります

承認依頼では、依頼を受けた人がデータを書き換えられるかを選べます。本構成では書き換えを「いいえ」にします。 原語の回答をその場で直せるようにすると、逆翻訳と食い違ったまま下書きになります。直すのは日本語の原稿だけにし、訳し直しと逆翻訳をもう一度通します。

応答がないまま期限が来たときは、「続行」ではなく「実行を終了」を選びます。 承認のないものが下書きに進まないようにするためです。期限の前に催促を送る設定もできます。

承認を送れる相手はプランで変わります。 Professional では自分にしか送れず、窓口の3名に送るには Team 以上が必要です。 承認者は Zapier のアカウントを持っている必要があります。

返金・法的・安全の枝は、この承認の流れに乗りません。 責任者が原文から扱いを決め、訳が必要な場合も、責任者の判断で参考訳として取り、送る文は責任者が確かめます。

例外に対処する

上の2行が最も起きやすい例外です。 タイ語と英語が1通に混ざる、件名は英語で本文は中国語、といったメールは珍しくありません。判断のつかないものを通常の流れに流さない設計を、分岐の側で守ります。

記録を残す

• 受信したメールの識別子、受信日時、言語、分類の結果と evidence
• 受信時の訳（segments）と、そのとき使った用語集の版番号
• 担当者が書いた日本語の原稿と、原語の回答、逆翻訳
• 承認・却下の記録と、却下の理由
• unlisted_terms と、その後に用語集へ足したかどうか
• 送信した日時と担当者

用語集の版番号を残すのは、言い回しを後から変えることがあるからです。 顧客から「前はこう書いてあった」と言われたとき、どの版の訳で送ったかが分かれば、当時の条件で答えられます。

却下の理由は、指示を直す材料になります。 同じ種類のずれが続くなら、プロンプトの「守ること」に1行足します。