朝礼で読む安全連絡と作業変更の連絡を、用語集をそろえて外国人作業者の母語に訳し、掲示用と配信用の文面を毎日作る

処理の起点を決める

フォームの送信を起点にします。 Apps Script のインストール型トリガーには、フォームへの回答で動くものがあります。職長が送信したその場で処理が始まるので、朝礼の30分前に入力すれば、数分後には確認カードが届きます。

時間主導型のトリガーは使いません。 公式ドキュメントでは、時間主導型のトリガーは毎分から月1回まで設定できる一方、時刻がわずかにランダム化されるとされ、午前9時に設定すると9時から10時の間のどこかで動く例が示されています。朝礼の開始時刻が決まっている業務で、1時間の幅は使えません。

インストール型トリガーは、作成した人のアカウントで動きます。 職長の誰かのアカウントで作ると、その人が異動した日に止まります。トリガーは製造部の共用のアカウントで作り、所有者を記録しておきます。 また、トリガーにはクォータの上限があるので、1回の送信で動く処理を短く保ちます。

入力の締め切りは、朝礼の30分前とします。それを過ぎた送信も処理はしますが、確認カードに「締め切り後」と表示し、職長が発行を急いで確認を飛ばさないようにします。

入力データを集める

質を決めるのは用語集です。 用語集が無いと、「第2通路」「3号機」「ピッキング台車」のような社内の呼び方が、そのたびに別の訳になります。用語集は最初から完璧にしません。 よく使う80語から始め、第7章の「例外処理」で拾った未登録の用語を毎週足していきます。

区分と重要度は、職長に選ばせます。 本文から自動で判定させることもできますが、「重要」を決めるのは現場の責任者です。 重要の連絡は、掲示用シートの先頭に色を変えて出し、配信用の文面にも見出しを付けます。

前日の連絡を持つのは、同じ連絡が続く日のためです。 通行止めが3日続くとき、前日の訳文と用語が同じなら、確認カードに「前日と同じ訳語」と出して職長の確認を短くします。

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

フォームの回答は、トリガーのイベントから受け取ります。区分と重要度は選択式にして、自由記述にしません。 表記がぶれると、掲示の並び順と配信の見出しが決まりません。

用語集は全件を渡しません。 本文に出てくる用語だけを照合して取り出し、その行だけを指示に入れます。 全件を渡すと、連絡に関係ない訳語まで持ち込まれることがあり、指示も長くなります。照合は長い語から先に行います。「フォークリフト通路」を先に当てないと、「フォークリフト」と「通路」に分かれて別々の訳語が付きます。

AIへ渡す前に整形する

1. 本文の整形 … 全角・半角をそろえ、連続した空白と改行を1つにします
2. 記号への置き換え … 数字、時刻、日付、温度、重さ、号機（「3号機」）、場所の記号（「第2通路」「Bエリア」）を取り出し、{{T1}} {{T2}} … に置き換えます
3. 置き換え表の保存 … どの記号が元の何だったかを、受付番号と一緒に記録します
4. 用語の照合 … 本文に出てくる用語集の語を、長い語から順に当てます
5. 未登録の語の候補出し … カタカナ語や「〜機」「〜台車」のような設備らしい語で、用語集に無いものを候補として拾います
6. 長さの確認 … 1件が200字を超えるものは、分けて入力するよう職長に返します

2番目が、この構成でいちばん大事な処理です。 記号にしておけば、AIは「10時」を別の書き方に直すことも、「3号機」を落とすこともできません。訳し終えたあとで元の文字に戻すので、数字は原文の1文字もそのまま掲示に出ます。

場所の記号は、日本語のまま残します。 床や柱に書かれている表示は日本語なので、訳してしまうと現場の表示と一致しなくなります。掲示用シートでは、記号の横に写真や配置図の番号を付けることもできます。

AIに処理させる

させるのは、1件ずつの連絡を5つの版に訳し、それぞれを日本語に戻すことだけです。

2行目の「足す・省く」がいちばん起きやすい失敗です。 安全の連絡を訳させると、丁寧にしようとして「十分に注意してください」「必ず守ってください」を足すことがあります。原文にない強調は、どれが本当に大事な連絡なのかをかえって分からなくします。

指示内容を固定する

システム指示（毎回同じ）：

あなたは工場の朝礼で読む安全連絡を、外国人作業者向けに訳す担当です。
職長が書いた日本語の連絡を、指定された言語に訳してください。

【訳す言語】
vi（ベトナム語）、id（インドネシア語）、tl（タガログ語）、pt（ポルトガル語）、
ja_easy（やさしい日本語）

【厳守事項】
- {{T1}} のような記号は、訳文の中にそのまま残してください。
  記号を訳す、消す、数字や別の語に置き換えることをしないでください。
- 用語集で訳語が指定されている語は、必ずその訳語を使ってください。
  より自然な言い方に直さないでください。
- 原文にない言葉を足さないでください。
  「注意してください」「必ず守ってください」などの強調を加えないでください。
- 原文の内容を省かないでください。1文も落とさないでください。
- 意味が決められない語があれば、推測で訳さず unclear_terms に書き出してください。
  その語は訳文の中で原文のまま残してください。
- 各言語の訳文を、日本語に戻した文を back_translation に書いてください。
  戻すときは訳文だけを見て、原文を見ないでください。
- やさしい日本語は、1文を短くし、難しい漢語を言い換えてください。
- 安全上の判断や助言は書かないでください。訳すことだけをしてください。

ユーザー側に入れるもの（毎回変わる）：

【連絡】受付番号 {receipt_id}／区分 {category}／重要度 {priority}
{source_text_with_tokens}

【この連絡に出てくる用語と訳語】
{glossary_rows}

「戻すときは原文を見ない」を明記しないと、逆翻訳が確認になりません。 何も言わないと、原文をそのまま写したような逆翻訳が返り、訳文がずれていても逆翻訳だけは正しく見えます。 同じ呼び出しの中で原文が見えている以上、この指示で完全に防げるとは限らないため、本格構成では逆翻訳を別の呼び出しに分け、訳文だけを渡します。

「強調を加えない」を具体的な言い回しで書いているのも同じ理由です。 「足さないでください」だけでは、足した一言を足したものと扱いません。例を挙げて禁じます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "receipt_id": "",
  "translations": [
    {
      "lang": "vi | id | tl | pt | ja_easy",
      "text": "",
      "back_translation": "",
      "glossary_used": [""],
      "unclear_terms": [""]
    }
  ]
}

translations には5つの要素を並べます。lang は enum で5つに限ります。言語の名前を自由に書かせると、「Vietnamese」「ベトナム語」「vi-VN」が混ざり、配信先のチャットを引けなくなります。

1つ目の理由は、記号の照合を機械で行えることです。 Apps Script が各 text の中の {{T1}} 〜 {{Tn}} を数え、置き換え表の数と1つでも合わなければ、その言語を発行させません。 自由文で受け取ると、どこからどこまでが訳文なのかが決まらず、数えられません。

2つ目は、back_translation を訳文と同じ要素に持たせられることです。 確認カードでは、原文と5つの逆翻訳を縦に並べます。どの言語の訳がずれているかが、読み比べるだけで分かります。

3つ目は、glossary_used で用語集が効いているかを後から数えられることです。 用語集にある語が本文に出ていたのに使われていない回数が多ければ、用語集の訳語か、照合の仕方に問題があります。

システムへ連携する

配信は、Google Chat の着信 Webhook で行います。 公式ドキュメントでは、Webhook は外部のサービスからチャットのスペースへ一方向・非同期の通知を送る仕組みで、ユーザーからのメッセージに応答したり受け取ったりはできないとされています。先輩作業者からの指摘は、Webhook ではなくスペースへの通常の返信で受けます。

送信の間隔を空けます。 Webhook には、スペースごとに1秒あたり1リクエストの上限があり、そのスペースのすべての Webhook で共有されます。1回の朝礼で送るのは言語ごとに1通ですが、重要の連絡を分けて送る日は、同じスペースへの送信を1秒以上空けます。

Webhook の URL は、スクリプトのプロパティに置きます。 URL にはセキュリティ用のトークンが含まれ、公開しないよう求められています。スプレッドシートの見える列には書きません。 また、Webhook を使えるのは Business または Enterprise の Google Workspace アカウントで、組織が Webhook の追加と利用を許可している場合です。

人が確認する

全件を職長が確認します。この構成に、確認を飛ばす経路はありません。 安全の連絡で、訳の誤りがそのまま掲示に出ることは許されないためです。

1. 記号の照合が ok かを見る … token_mismatch の言語は、確認カードに出る前に止まっています
2. 原文と逆翻訳を読み比べる … 意味がずれていないか、足された言葉や抜けた文がないかを見ます
3. unclear と glossary_miss を処理する … 該当の語を言い換えて入力し直すか、そのまま発行するかを決めます
4. 発行を押す … 押した職長の名前と時刻が記録されます
5. 先輩作業者の指摘を受ける … 配信後に気になる点があれば、チャットで返してもらいます

1件あたり5分を目安にします。 逆翻訳を5つ読むのが中心で、ずれがなければ数十秒、unclear があれば言い換えの入力で数分かかります。確認が5分を大きく超える日が続くなら、用語集が足りていないか、原文が長すぎます。

5番目は、2段目の確認です。 逆翻訳は、訳文が原文の意味を保っているかは教えてくれますが、その言語の作業者にとって自然な言い方かどうかは教えてくれません。 先輩作業者の指摘は、用語集の訳語を直す材料として記録します。先輩作業者に全件の確認を頼む形には戻しません。

例外に対処する

上から2行目までが大半を占めます。 どちらもAIの失敗というより、用語集がまだ育っていないことの表れです。 運用の最初の1か月は未登録の語が多く出ますが、毎週の登録を続けると、確認カードの赤い表示は目に見えて減ります。

4行目の「前日までの定型の訳文」は、先に用意しておきます。 暑さ対策、保護具の着用、通路の通行止めのように毎月必ず出る連絡は、職長と先輩作業者が確かめた定型の訳文を10本ほど持っておき、APIが止まった日に使います。

記録を残す

• フォームの入力（本文、区分、重要度、ライン、交替、入力した職長、入力時刻）
• 記号の置き換え表（受付番号ごと）
• Gemini API に渡した指示と、返ってきたJSONの全文
• 記号の照合の結果（ok／token_mismatch／unclear／glossary_miss）
• 発行を押した職長と時刻、発行前に直した箇所
• 掲示用PDFと、各言語のチャットへ送った文面
• 先輩作業者からの指摘と、それを受けて直した用語集の行

発行者と時刻を残すのは、掲示の責任を明確にするためです。 訳を作ったのはAIですが、掲示してよいと判断したのは職長です。 後から訳の誤りが見つかったとき、どの確認を通って掲示されたかをたどれるようにします。

最後の行は、用語集を育てる記録です。 同じ語に何度も指摘が来るなら、訳語そのものを見直します。用語集の変更には、日付と直した人を残します。 訳語が変わった日を境に、掲示の言葉が変わったことを作業者に伝えられるようにするためです。