市役所の窓口で外国人の住民と職員の会話を音声で訳して画面に出し、手続きの説明と聞き取った内容を受付の記録に残す

処理の起点を決める

職員が画面の「会話を始める」を押したときに、2つの認識を同時に始めます。 職員のマイクと住民のマイクは、別々の認識として動かします。1つのマイクで2人の声を拾うと、どちらが話したかが分からず、日本語を日本語へ訳そうとすることが起きます。

その前に、住民が自分の画面で言語をタップします。言語を最初に住民に選んでもらうのは、自動の言語の判定より確かだからです。 選べない住民のために、判定にも対応させます（後述）。

「会話を終える」を押したときに、会話の記録を中継の処理へ送り、受付の記録の下書きを作り始めます。 押し忘れたまま次の住民の会話が始まらないよう、住民が言語を選ぶ画面に戻った時点で、前の会話は自動で終えます。

入力データを集める

定型文の一覧は、たとえば次のように持ちます（国民健康保険の加入の例。文面は例です）。

訳の列には、誰がいつ確かめたかを必ず付けます。 確認者のいない訳は、定型文として使いません。文面は手続きの担当課が、訳は通訳の職員か翻訳の専門家が責任を持つように分けておくと、制度が変わったときに直す順番が決まります。

質を決めるのは、定型文の一覧です。 期限や必要な書類の説明の訳が、翻訳の専門家や通訳の職員に確かめられていること。この一覧が薄いと、大事な説明まで音声の翻訳に頼ることになります。

受付の記録の下書きに使うのは、会話の記録だけです。 住民の住所や在留カードの番号のように、書類で確かめる情報は、会話から取りません。

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

窓口のアプリは、Speech SDK の翻訳の認識（TranslationRecognizer）を2つ作ります。

職員の側の設定は、たとえば次のようになります（Python の Speech SDK の例）。

config = speechsdk.translation.SpeechTranslationConfig(endpoint=..., subscription=...)
config.speech_recognition_language = "ja-JP"   # 職員は日本語で話す
config.add_target_language("vi")               # 住民が選んだ言語へ訳す
recognizer = speechsdk.translation.TranslationRecognizer(
    translation_config=config, audio_config=staff_mic)
recognizer.recognized.connect(on_final)        # 確定した訳文だけを住民の画面へ
recognizer.start_continuous_recognition()

住民の側は、speech_recognition_language に住民の言語（vi-VN）、add_target_language に ja を入れ、audio_config に住民のマイクを指定した、もう1つの認識を動かします。on_final で受け取った結果に発話IDを振り、会話の記録に追記します。

住民の画面には、確定した訳文だけを出します。 暫定の結果は話している途中で変わるため、画面の文字が次々に書き換わると、読み手が混乱します。 職員の画面には、自分の発話の暫定の認識を薄く出し、言い間違いや認識の誤りにすぐ気づけるようにします。

住民が言語を選べないときは、言語の判定を使います。 候補の言語を渡すと、その中から話されている言語を返す仕組みで、最初の数秒で1回判定する方式は候補4つまで、会話の途中で切り替わる言語に追随する方式は候補10までです。候補にない言語が話されても、候補のどれかが返る点に注意します。判定した言語は、住民の画面にその言語で表示し、合っているかを押してもらいます。

入力の言語を指定しない多言語の翻訳もありますが、この構成では使いません。 暫定の結果が返らず、専用のエンドポイントが要るためです。

AIへ渡す前に整形する

1. 言語を確かめる … 住民が選んだ言語を、その言語の文字で画面に出して確かめます
2. 定型文を手続きで絞る … 職員が選んだ手続きの定型文だけを、職員の画面に並べます
3. マイクを分ける … 職員と住民のマイクを別の入力として扱い、指向性のあるマイクを置きます
4. 発話IDを振る … 確定した結果ごとに、話者・時刻・原文・訳文と一緒に発話IDを付けます
5. 会話の記録を日本語にそろえる … 職員の発話は原文、住民の発話は日本語の訳文を使い、記録の下書きの入力にします。住民の原文も並べて残します
6. 氏名と番号を置き換える … 会話に出た氏名、電話番号、在留カードの番号などは、生成AIに渡す前に記号に置き換えます

3番目を軽く見ないでください。 窓口はたいてい隣の窓口とつながっていて、隣の会話や庁内の放送が入ります。住民のマイクが職員の声を拾うと、職員の日本語を「住民の発話」として訳そうとします。

AIに処理させる

この構成のAIの仕事は2つです。 会話をその場で訳すこと（Azure AI Speech）と、会話の文字から受付の記録の下書きを作ること（Azure OpenAI）です。

記録の下書きで取り出すのは、会話に出たことだけです。

2行目がいちばん起きやすい失敗です。 機械の訳文はときに不自然で、記録の文体に整えたくなります。整えた瞬間に、住民が言ったことではなく、AIが解釈したことが記録になります。 不自然な訳文は不自然なまま、uncertain として残します。

指示内容を固定する

受付の記録の下書きに使う指示です。

あなたは市役所の窓口で、外国人の住民との会話の記録から
受付の記録の下書きを作る立場です。
会話の記録に書かれていることだけを使ってください。推測で補わないでください。

【会話の記録の読み方】
- 発話ごとに発話ID、話者（staff / resident）、日本語の文があります。
- resident の日本語は、機械翻訳の訳文です。不自然な訳がありえます。
- template は、職員が画面に出した確認済みの定型文です。
  response は住民が押したボタン（understood / repeat / none）です。
- <氏名1> <番号1> などは置き換えた記号です。中身を推測しないでください。

【取り出す項目】
1. explained … 説明した事項。定型文は template_id と response をそのまま書く。
   職員の発話で説明したものは、その要点と発話IDを書く
2. heard … 住民から聞き取った事項。発話IDを付ける
3. pending … 次回に持ってくる書類、後日の手続き。期限が言われていなければ due は null
4. handover_needed … 通訳者への引き継ぎが要りそうなやり取り

【厳守事項】
- 住民の発話の訳文を、自然な日本語に書き直さないでください。
  意味が取りにくい訳文は、そのまま写して uncertain を true にしてください。
- 会話に出ていない説明を、説明したことにしないでください。
- response が repeat のまま終わった定型文を、伝わったと書かないでください。
- 手続きの要件を満たすかどうかは書かないでください。
- 各項目に、根拠にした発話IDを付けてください。

【手続きの種類】{procedure}
【会話の記録】{conversation}

「訳文を書き直さない」を明記するのが要です。 生成AIは、ぎこちない日本語を読むと、意味を推し量って自然な文に直します。直した文が正しいかどうかは、誰にも確かめられません。

「repeat のまま終わった定型文を、伝わったと書かない」も明記します。 会話の流れから、最後には分かったように見えることがあります。伝わったかは、住民が押したボタンで決めます。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力では、すべての項目を必須にし、決まらないものは null との共用体型で表し、オブジェクトに additionalProperties: false を付けます。

{
  "session_id": "C-20261007-1035-07",
  "procedure": "national_health_insurance_enroll",
  "language": "vi",
  "explained": [
    { "template_id": "NHI-03", "summary": null, "response": "understood | repeat | none",
      "utterances": ["U-12"] }
  ],
  "heard": [
    { "text": "", "uncertain": false, "utterances": ["U-15"] }
  ],
  "pending": [
    { "item": "", "due": null, "utterances": ["U-21"] }
  ],
  "handover_needed": [
    { "reason": "", "utterances": ["U-18", "U-19"] }
  ]
}

1つ目の理由は、何を説明したかを定型文のIDで残せることです。 NHI-03 が「加入の届け出は14日以内」の定型文なら、その文をどの言語で示し、住民が何を押したかが記録に残ります。 後で問い合わせがあったとき、記録から当時の画面の文面を再現できます。

2つ目は、utterances で会話の原文に戻れることです。 下書きの1行ごとに発話IDが付いているので、職員は確認のときに会話の記録の該当箇所を開けます。住民の原文と訳文を並べて見られるので、訳の誤りにも気づけます。

3つ目は、handover_needed を窓口の改善に使えることです。 どの手続きのどの説明で通じなかったかが集まると、定型文を足す場所が分かります。

システムへ連携する

受付の記録への登録は、職員が確かめたものだけです。 各課のシステムに登録のAPIが無いことも多いので、最初は下書きを職員が写す形で始めます。 写すだけでも、何を説明したかを思い出して書く時間は無くなります。

人が確認する

1. 会話の最中に、自分の発話の認識を見る … 職員の画面に出る自分の日本語の認識が誤っていれば、言い直します
2. 定型文の応答を見る … 「もう一度」が押されたら、別の言い方をするか、図やチラシを使います。2回続いたら、通訳者への引き継ぎを考えます
3. 記録の下書きを確かめる … uncertain の聞き取りと、handover_needed を中心に読み、直してから登録します
4. 引き継ぎを決める … 通じなかったやり取りがあれば、電話通訳か通訳の職員に引き継ぎ、記録に残します

1番目がいちばん効きます。 翻訳の誤りの多くは、日本語の認識の誤りから始まります。職員が自分の発話の認識を見て言い直せば、誤った訳が住民に届く前に止められます。

目標は、1件15分です。 手続きの説明と聞き取りに12分、記録の下書きの確認に3分という想定です。

例外に対処する

対象外の相談は、最初に決めておきます。 生活保護、児童虐待、DVの相談などは、言葉の細かな違いが住民の生活に直結します。窓口の職員が、話の途中で対象外と気づいたら機械の翻訳をやめる、という決まりを先に作ります。

記録を残す

• 会話の記録（発話ID、話者、原文、訳文、時刻）。音声は保存しない設定にし、文字だけを残す
• 定型文の表示と、住民の応答（どの定型文を、どの言語の版で示したか）
• 住民の同意の記録（どの言語の文面で同意を得たか）
• 生成AIが返した下書きのJSONと、職員が直した差分
• 通訳者に引き継いだ会話と、その理由
• 定型文の一覧の版

定型文の版を残すのは、文面が後から直るためです。 訳を直したら、過去の会話で示した文面とは違うものになります。当時の版が残っていないと、住民に何を示したかを再現できません。

引き継いだ理由は、定型文を足す材料です。 同じ手続きの同じ説明で引き継ぎが続くなら、その説明を定型文にします。