外国人の入居希望者から外国語で届く物件の問い合わせを訳して条件を台帳にそろえ、日本語で書いた返事を相手の言語に直して返す

処理の起点を決める

入ってくる側は、受付用アドレスへのメールの着信を起点にします。 Make の Gmail の Watch emails は、見張るフォルダやラベル、送信元、件名、含む語で絞り込め、1回の実行で取り込む件数の上限を500以下で設定します。物件ポータルの反響メールと自社フォームの通知メールは、Gmail のフィルタで「反響」のラベルを付けておき、そのラベルだけを見張ります。 受付用アドレスには業者からの営業メールも届くため、全部を見張ると関係のないメールまで訳すことになります。

見張る間隔は15分にします。 1日1回では遅すぎ、数分ごとにしても返事を書く人の手前で待つだけです。

出ていく側は、台帳の「状態」が「訳す」になった行を15分ごとに探して起点にします。 Google スプレッドシートには Watch Changes というセルの変更で動くモジュールがありますが、新しく足された行を見ないこと、スクリプトや API による変更では動かないことが書かれています。担当者が画面で状態を変える運用には合いますが、行の追加と変更が混ざる台帳では取りこぼしが読みにくいため、Search Rows で「訳す」の行を探す定時の実行にします。

入力データを集める

質を決めるのは、いちばん下の用語集です。 用語集が無いと、同じ「礼金」が返事ごとに違う訳になり、相手は別の費用だと受け取ります。 用語集は、入居者に渡している英文・中文の契約の説明書があればそこから作ります。

前のやり取りを渡すのは、聞き返しを繰り返さないためです。 2通目の返信には予算しか書かれていなくても、1通目で入居日が分かっていれば、聞き返す項目から入居日を外せます。 送り主のアドレスで台帳を引き、同じ人の行があればその条件を一緒に渡します。

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

DeepL も Translate a Text ではなく Make an API Call で呼びます。 用語集の glossary_id と、訳には影響するが訳されない context を自分で指定したいためです。context には「賃貸住宅の仲介会社が、入居を希望する外国人に送る返事」と書いておきます。context の文字数は料金の計算に入りません。

AIへ渡す前に整形する

1. 定型部分を分ける … 物件ポータルの反響メールは、物件番号や物件名などの定型部分と、入居希望者が書いた自由記述の部分に分かれています。ポータルごとの区切りの文字列で分け、AIに訳させるのは自由記述の部分だけにします。 定型部分の物件番号は、そのまま台帳に入れます
2. 引用と署名を落とす … 返信のメールには前のやり取りが引用されています。引用を残すと、前に分かった条件をもう一度拾い、前の返事の日本語まで訳してしまいます。 引用の行と署名を落としてから渡します
3. 日本語のものを外す … 本文に日本語の文字が一定以上含まれるものは、この先の処理に回しません。最終的な言語の判定は Claude API にさせます
4. 添付ファイルを渡さない … 在留カードやパスポートの画像が添付されて届くことがあります。問い合わせの段階では受け取る必要が無いものなので、AIに渡しません。 台帳には「添付あり」とだけ記録し、扱いは担当者が決めます
5. 重複を除く … 同じ人が複数のポータルから同じ物件に問い合わせることがあります。送り主のアドレスと物件番号が同じで、24時間以内の行があれば、新しい行を作らずに書き足します

AIに処理させる

入ってくる側で Claude API にさせるのは、言語の判定、日本語への翻訳、条件の欄分け、聞き返す項目の列挙の4つです。

右端の列が、この構成でいちばん大事な決まりです。 書かれていない条件を「不明」と残すから、聞き返す項目が正しく並びます。学校の名前が書かれているから在留資格は「留学」だろう、と埋めると、聞き返すべき項目が消えます。

出ていく側で Claude API にさせるのは、訳文の点検だけです。 日本語の返事と DeepL の訳文を並べて、金額、日付と期間、否定（「ありません」「できません」）、物件名と部屋番号、数（人数・部屋数）の5つが原文どおりかを見ます。訳文を直させるのではなく、食い違いの箇所を挙げさせます。 直すのは担当者が日本語の返事を直して、もう一度訳す形にします。

指示内容を固定する

あなたは賃貸住宅の仲介会社で、外国語で届いた問い合わせを日本語の担当者に
引き継ぐ係です。本文を日本語に訳し、入居の条件を決まった欄に分けてください。

【やること】
1. 本文の言語を判定し、ISO の言語コードで language に書く
2. 本文を日本語に訳し、translation_ja に書く（敬語は不要、意味を正確に）
3. 条件を conditions の各欄に分ける
4. 書かれていない条件を ask_back に日本語で並べる

【conditions の欄】
budget（家賃の上限と通貨、管理費込みか）／move_in（入居希望日または時期）／
occupants（人数と続き柄）／residence_status（在留資格と在留期間）／
work_or_school（勤務先または学校）／guarantor（日本にいる保証人の有無、
保証会社の利用の希望）／viewing（内見の希望日時、オンラインの希望）／
contact（日本の電話番号の有無、希望する連絡の手段）

【厳守事項】
- 本文に書かれていない条件は「不明」とし、推測で埋めないでください。
- 在留資格を、職業・学校・国籍から推し量らないでください。
  本人が書いていなければ「不明」です。
- 金額は原文の数字と通貨のまま書いてください。円に換算しないでください。
- 「来月」「春から」のような時期は、原文の言い方をそのまま書き、
  日付に直さないでください。
- 入居できるか、審査に通りそうかを書かないでください。
- 各欄の evidence には、根拠にした原文の箇所をそのまま写してください。
- 前のやり取りで分かっている条件は {previous_conditions} にあります。
  今回の本文に新しい記載が無ければ、前の値を残してください。
  前の値と今回の記載が違うときは、両方を書き、changed を true にしてください。
- 本文が物件の問い合わせでない（営業メール・迷惑メールなど）と判断したら、
  inquiry を false にして、それ以外の欄を空にしてください。

【物件の定型部分】{portal_fixed_fields}
【本文】{body}
【受け取った日時】{received_at}

「推し量らない」を在留資格だけ別に書いているのは、いちばん埋めたくなる欄だからです。 「〇〇大学に通っています」と書かれていれば、何も言わなければ「留学」と埋めます。埋めた値が当たっていても、本人に確かめていないという事実が消えます。

前のやり取りとの食い違いを changed で残させるのは、予算や入居日が途中で変わることが多いためです。 新しい値だけを上書きすると、担当者は変わったことに気づかないまま、前の条件で物件を探し続けます。

返事の点検に使う指示は短くします。「日本語の原文と訳文を比べ、金額・日付と期間・否定・物件名と部屋番号・数が原文と違う箇所だけを挙げてください。訳の自然さや言い回しには触れないでください。訳文を書き直さないでください」。言い回しまで見させると指摘が増え、数字の食い違いが埋もれます。

出力形式を固定する

入ってくる側は、次の形の JSON を構造化出力で受け取ります。

{
  "inquiry": true,
  "language": "en",
  "mixed_language": false,
  "translation_ja": "",
  "conditions": {
    "budget":            { "value": "", "evidence": "", "changed": false },
    "move_in":           { "value": "", "evidence": "", "changed": false },
    "occupants":         { "value": "", "evidence": "", "changed": false },
    "residence_status":  { "value": "", "evidence": "", "changed": false },
    "work_or_school":    { "value": "", "evidence": "", "changed": false },
    "guarantor":         { "value": "", "evidence": "", "changed": false },
    "viewing":           { "value": "", "evidence": "", "changed": false },
    "contact":           { "value": "", "evidence": "", "changed": false }
  },
  "ask_back": ["入居を希望する時期", "日本にいる保証人の有無"]
}

1つ目の理由は、台帳の列にそのまま当てられることです。 Parse JSON で欄に分ければ、conditions の8つの value を台帳の8つの列に書けます。自由文で受け取ると、どこからどこまでが予算かをもう一度切り出す処理が要ります。

2つ目は、evidence で担当者が原文に戻れることです。 台帳の日本語訳だけでは、訳が正しいかを確かめられません。根拠の原文の箇所が並んでいれば、外国語が読めない担当者でも、数字と固有名詞だけは原文と見比べられます。

スキーマには使えない書き方があります。 数値の minimum や文字列の maxLength は対応していないため、欄の値はすべて文字列にし、長さの制限はワークフローの側で見ます。

出ていく側の点検は、issues の配列で受け取ります。要素は type（amount ／ date ／ negation ／ property ／ count）、source_ja（日本語の原文の箇所）、target（訳文の箇所）、note の4つです。issues が空なら下書きを作り、1件でもあれば台帳の状態を「要確認」にして下書きを作りません。

システムへ連携する

Gmail へは送信しません。下書きまでです。 Make の Gmail には Send an email と Reply to an email もありますが、この構成では使いません。 下書きは Create a draft email で、受け取ったメールのスレッドの ID を指定して作ります。下書きの本文は、訳文の下に区切り線を入れ、日本語の原文を並べます。 相手が日本語の分かる知人に確かめてもらうこともあるためです。

台帳の Add a Row と Update a Row は、列の ID を使う設定にします。 列の ID を使わない設定では、列の名前を変えても動きますが、列を足したり並べ替えたりすると動かなくなるとされています。運用しながら列を足していく台帳なので、列の位置に頼らない設定にします。

人が確認する

人が見るのは、すべての問い合わせの日本語訳と条件、そしてすべての返事の下書きです。 入ってくる側も出ていく側も、人を通さずに外へ出るものはありません。

1. 台帳の日本語訳と条件を読む … evidence の原文と見比べ、金額と日付だけは原文の数字を目で確かめます
2. 空室と条件を確かめて、日本語で返事を書く … ask_back の項目をまとめて1通で聞きます。状態を「訳す」にします
3. 点検の結果を見る … issues が出た返事は、日本語の原文の言い方を変えてからもう一度訳します。よくあるのは、主語の無い否定の文です
4. 下書きを開いて送信する … 宛先、件名、物件名を確かめてから送ります

目標は、360件をならして1件4分です。 台帳の確認に1分、返事を書くのに2分、下書きの確認と送信に1分という内訳で、訳す時間と、条件を拾う時間がまるごと無くなる想定です。

例外に対処する

3行目と4行目を分けているのは、DeepL の対応の度合いが言語によって違うためです。 公式の対応言語の表では、たとえばネパール語は訳せても用語集には対応していません。用語集が無いまま訳すと、礼金や敷金の訳が返事ごとに揺れます。 その言語の返事は、点検の結果をいつもより丁寧に見ます。

記録を残す

• 受け取ったメールの ID、受け取った日時、ポータルの名前、物件番号
• 原文、日本語訳、Claude API が返した JSON の全文
• 担当者が書いた日本語の返事、DeepL の訳文、使った用語集の版
• 点検の結果（issues）と、担当者が日本語の返事を直した記録
• 下書きを作った日時と、送信した日時
• 言語ごとの件数と、点検で食い違いが出た件数

3つ目で「用語集の版」を残すのは、用語集を後から直すためです。 礼金の訳を直したとき、どの返事が古い訳で送られたかが分からないと、相手に訂正の連絡をする範囲が決まりません。