賃貸管理会社が外国人の入居者に渡す設備の使い方・ごみ出し・緊急時の連絡の案内を、部屋ごとの設備に合わせて組み立て、入居者の言語に訳して送る

処理の起点を決める

時間主導型のトリガーを1時間ごとに1つ置きます。 依頼のシートで状態が「依頼」の行を拾い、1回の実行で処理します。時間主導型のトリガーは毎分から毎月の間隔で動かせ、インストール型トリガーは作成した人のアカウントで実行されます。 下書きもそのアカウントの Gmail に作られるため、入居者サービス課の共用のアカウントでトリガーを作ります。

1回の実行で処理するのは5件までにします。 1回の実行は6分までとされています。新しい部品の訳が多い案内は時間がかかるため、状態を「処理中」にしてから始め、終わったものだけ「確認待ち」にします。 処理中のまま30分を超えた行は、次の実行で「依頼」に戻します。

鍵渡しの日が3日後より近い依頼は、先に処理します。 依頼のシートを鍵渡しの日の順に並べて拾います。

物件の情報が変わったときの作り直しも、同じ依頼のシートで受けます。 ごみの収集日が変わった物件では、担当者がその物件の外国人の入居者の部屋を依頼に並べます。変わったのはごみの段落だけなので、ほかの部品は翻訳の記録から引かれ、新しく訳すのはその段落だけです。

入力データを集める

質を決めるのは、用語集です。 「燃やすごみ」を、ある部品では burnable garbage、別の部品では combustible waste と訳すと、入居者には別のものに見えます。 自治体が配っている外国語のごみの案内があれば、そこで使われている訳を用語集に入れます。入居者が集積所の掲示で見る語と、案内の語がそろいます。

部品の日本語は、やさしい日本語で書いておきます。 一文を短くし、「〜してください」で終わる形にそろえます。原文が短く主語がはっきりしているほど、どの言語への訳も崩れにくくなります。

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

部屋の設備は、設備台帳を部屋番号で引きます。 台帳の列ごとに、その部屋の機種の区分（給湯器A型・B型、ガスコンロ・IH など）を読みます。部品の一覧の「対応する設備の区分」と一致する部品を選びます。

収集日・時刻・電話番号は、部品の段落の中に差し込み欄として置きます。 「燃やすごみは｛曜日｝の朝｛時刻｝までに出してください」のように書き、訳す前には差し込みません。 訳すのは差し込み欄を残した段落で、差し込みは訳したあとにスクリプトが行います。こうすると、物件が違っても同じ部品の訳を使い回せ、曜日や番号をAIが書き換える余地がありません。

曜日と時刻は、言語ごとの表記の表をスクリプトが持ちます。 「月曜日」を各言語で何と書くか、時刻を何時の形で書くかを表にし、差し込むときに使います。

連絡先は、受け付ける時間帯と組にして差し込みます。 管理会社の窓口と夜間の窓口は番号も受け付ける時間も違うため、「平日9時〜18時はこの番号、それ以外はこの番号」という並びを部品の側で決めておきます。 番号だけを並べると、夜に昼の窓口へかけて誰も出ないことになります。

AIへ渡す前に整形する

1. 設備の欠けの確認 … 設備台帳に空の列があれば、その部屋の依頼を「台帳不足」にして担当者へ戻します
2. 部品の選び出し … 機種の区分に合う部品と、物件のごみ・緊急の部品、共通の部品を並べます
3. 翻訳の記録の引き当て … 部品IDと原文の版と言語が一致する訳があれば使います
4. 固定訳の確認 … 固定訳の部品で、その言語の訳が無ければ、AIに訳させずに依頼を「固定訳なし」で止めます
5. 訳す部品の束ね方 … 訳の無い部品を1回の要求にまとめ、部品IDを付けて渡します
6. 用語集の絞り込み … 渡す部品に出てくる語だけを用語集から選びます
7. 言語の確かめ … 依頼のシートの言語の欄を、用語集と固定訳がそろっている5つの言語の符号と照らします。符号の書き違い（「vn」と「vi」など）は、ここで止めます

3番目の「原文の版」は、部品の日本語を直すたびに1つ上げます。 翻訳の記録は部品IDと版と言語の組で引くので、原文を直した部品は自動的に訳し直しの対象になり、古い訳が新しい原文に付いたまま使われることがありません。 誤字を直しただけで版を上げると訳し直しが増えるため、意味が変わる直しのときだけ上げる約束にします。

4番目が、この構成の線引きです。 ガス漏れのときに窓を開けて火を使わないこと、119番に何を伝えるかは、訳の誤りがそのまま命に関わります。 その言語の固定訳が無いまま案内を出すより、止めて担当者に知らせるほうを選びます。

AIに処理させる

させるのは、渡した部品を、用語集の訳を守って入居者の言語に訳し、訳文に残った差し込み欄を一覧にすることです。

部品は、たとえば次の形で渡します。

ここでの｛時刻｝や｛曜日｝は、訳文の中でも同じ形で返ってきます。 「ふろ自動」は訳のあとに括弧で日本語が残り、入居者はリモコンの文字と見比べられます。

差し込み欄を残させるのが、この構成の要点です。 曜日や電話番号を訳文の中でAIが書くと、「火曜日」が「木曜日」に、電話番号の1桁が別の数字になる取り違えが、読める人のいない言語の中で起きます。 欄のまま返させ、差し込みはスクリプトが表から行います。

2行目がいちばん起きやすい失敗です。 ごみの段落を訳すとき、AIは親切のつもりで「日本では分別が厳しいので注意してください」のような一文を足します。物件のルールに無い一文は、入居者にとってはどれがその物件のルールなのかを分かりにくくします。

指示内容を固定する

あなたは賃貸管理会社の入居案内を、入居者の言語に訳す担当です。
下の【部品】を {target_language} に訳してください。

【守ること】
- 【用語集】にある語は、必ず決められた訳を使ってください。言い換えないでください。
- ｛曜日｝｛時刻｝｛電話｝｛場所｝などの差し込み欄は、そのままの形で訳文に残してください。
  欄に値を入れたり、欄を消したりしないでください。
- 原文に無い説明・注意・補足を足さないでください。
- 原文を短くまとめたり、順番を入れ替えたりしないでください。
- 機種の名前、ボタンの表示（「運転」「おいだき」など）は、訳のあとに
  日本語を括弧で残してください。入居者が実物の表示と見比べるためです。
- 用語集に無い語で訳を決めにくかったものは、hard_terms に書いてください。

【用語集】{glossary}
【部品】{parts}

「ボタンの表示は日本語を括弧で残す」を入れているのは、実物が日本語だからです。 給湯器のリモコンには「おいだき」と書いてあり、訳だけを読んでもどのボタンかが分かりません。訳と日本語の表示を並べると、入居者はリモコンの文字と見比べて押せます。

「短くまとめない」を明記しないと、手順の段落が要約されます。 「1. 電源を入れる 2. 温度を選ぶ 3. 運転を押す」が1文にまとめられ、手順の番号が消えます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力を使い、要求の output_config の format に type を json_schema として下の形のスキーマを入れます。

{
  "target_language": "vi",
  "parts": [
    {
      "part_id": "WH-A-01",
      "translation": "",
      "placeholders": ["｛時刻｝"],
      "glossary_used": ["追いだき"],
      "hard_terms": [""]
    }
  ]
}

1つ目の理由は、placeholders をスクリプトで照らせることです。 原文の部品にある差し込み欄の一覧と、placeholders と、訳文の中に実際に残っている欄の3つが一致するかを確かめます。1つでも合わない部品は「欄の不一致」として下書きに印を付け、翻訳の記録には書きません。

2つ目は、glossary_used で用語集が守られたかを確かめられることです。 原文に用語集の語があるのに glossary_used に無い、または訳文に決めた訳が含まれていない部品に印を付けます。

3つ目は、hard_terms が月1回の確かめの材料になることです。 訳しにくかった語が同じものばかりなら、原文の書き方を変えるか、用語集に足します。

照合は、差し込みのあとにもう一度行います。 差し込んだ訳文の中の数字の列を取り出し、日本語の側の数字の列と並べます。電話番号・時刻の数字が、順番も含めて一致するかを見ます。 曜日は、言語ごとの表記の表で日本語に戻して比べます。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にして、失敗の応答でも例外で止まらないようにします。 失敗したときは状態を「依頼」に戻し、次の実行で再試行します。

API キーは、スクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されるため、スクリプトの編集権限は課の管理担当に限ります。

下書きは、日本語と訳文を段落ごとに並べたHTMLの本文で作ります。 上に訳文、下に日本語を置き、入居者が日本人の知人や会社の担当に見せても通じる形にします。 件名は「入居のご案内／部屋番号」に言語の名前を添えます。

人が確認する

担当者が下書きを確かめてから送ります。 自動で送る設計にはしません。

1. 印の有無を見る … 「欄の不一致」「用語集の不一致」の印があれば、その部品を開きます。印のある下書きは送らず、課の管理担当へ回します
2. 日本語の側を読む … 部屋の設備と段落が合っているか（無い設備の段落が無いか）を見ます
3. 差し込みを見る … 収集日・時刻・電話番号が、物件のルールと連絡先の表と合っているかを見ます
4. 送る … 下書きを開いて送ります。鍵渡しの日に紙でも渡す場合は、同じ内容を印刷します

下書きは、上から「訳文」「日本語の原文」「照合の結果」の順に並べます。 照合の結果の欄は、送る前に担当者が消します。印の無い下書きは、この欄に「照合：すべて一致」とだけ出ます。 担当者は欄を見て消し、日本語の側を読んで送ります。

訳文の中身は、担当者は確かめません。 読めない言語を確かめることはできないためです。その代わりに、新しく訳した部品を「未確認」として翻訳の記録に残し、月1回、話者に見てもらいます。 確認済みになった部品だけが、次からの案内に使われる状態をめざします。

目標は、60件をならして1件10分です。 すべて確認済みの部品で組み上がった案内は数分で送れ、新しい部品を含む案内は印を確かめるので10分を超えます。

例外に対処する

2行目と最後の行は、同じ考え方です。 確かめた訳の土台が無い言語で、命に関わる段落をAIだけで訳して出すことはしません。新しい言語は、固定訳と用語集をそろえてから足します。

記録を残す

• 依頼ごとの部屋番号・言語・使った部品の一覧と、各部品の原文の版と訳の確認の状態
• AIに渡した部品と、返ってきたJSONの全文
• 照合の結果（欄の不一致・用語集の不一致・数字の不一致）
• 送った下書きの件名と送った日時
• 月1回の話者の確認の結果と、直した訳

hard_terms と話者の確認の結果は、用語集を足す材料にします。 同じ語が何度も訳しにくい語に挙がるなら、用語集に決めた訳を足すか、原文をその語を使わない書き方に直します。

1つ目は、原文を直したときに使います。 給湯器の段落の原文を直したら、その部品を使って送った部屋を一覧にし、直した版の案内を送り直すかを決められます。