工場に海外の設備メーカーの技術者が据付・修理に来たときの会話を音声で訳して画面に出し、作業内容・交換部品・注意点を保全の作業記録に残す

処理の起点を決める

保全員がタブレットのアプリで「立ち会いを始める」を押したときに、訳を始めます。 技術者の作業は数時間から丸1日に及ぶため、作業の区切りごとに「区切り」を押して、会話を作業の単位に分けます。 区切りは、後で作業記録の行を作るときの単位になります。

「立ち会いを終える」を押したときに、下書きを作ります。 区切りごとに下書きを作ることもできますが、技術者は後の作業で前の説明を訂正することがあるため、1日分の会話をまとめて下書きにします。

会話の途中で、自動で下書きを始めることはしません。 作業の途中の暫定の説明が記録に入ると、後で訂正された内容と混ざります。

入力データを集める

質を決めるのは、来訪の情報です。 設備の型式と関係する部品の一覧があると、下書きの段階で会話に出てきた部品の名前を、部品マスタの名前に結び付けられます。 一覧がないと、「the bearing on the left side」がどの部品かを、保全員が思い出して書くことになります。

写真と入力値は、会話の記録と時刻で結び付けます。 「この値をこう変えた」という発話の近くに、入力した値と写真が並ぶようにしておくと、下書きが値を音声から拾わずに、入力欄の値を使えます。

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

会話は、Speech SDK の TranslationRecognizer で取ります。 公式の手順では、認識する言語を SpeechRecognitionLanguage に地域付きの形（ja-JP、en-US など）で指定し、訳す先を AddTargetLanguage で足します。結果は Recognizing（暫定）と Recognized（確定）のイベントで返り、確定した結果の Translations に、訳す先の言語ごとの訳文が入ります。長い会話は連続認識（StartContinuousRecognitionAsync）で取ります。

マイクは話者ごとに分け、TranslationRecognizer も話者ごとに1つ立てます。 保全員側は ja-JP を認識して技術者の言語へ、技術者側はその言語を認識して ja へ訳します。話者を音声から判定させるより、マイクで分けるほうが確実です。 騒音のある現場では、相手の声が自分のマイクに入らないよう、口元に近いマイクのヘッドセットを使います。

技術者が英語とドイツ語を行き来する場合は、言語の判定を使えます。 公式の手順では、候補を渡す言語の判定で最大10の入力言語を判定して訳せるとされています。入力の言語をまったく指定しない多言語の翻訳もありますが、その場合は暫定の訳の結果が返らないとされているため、この構成では候補を渡す方式にします。

専門用語は、2つの方法を試します。 1つはフレーズリストです。公式のページでは、業界や組織に固有の語や略語を事前に渡して認識されやすくする機能で、2,000語を超えないこととされています。ただし、対応先として挙げられているのはリアルタイムの文字起こしなどで、音声翻訳で使えるかはページに明記されていません。試験で確かめます。 もう1つは、訳語をそろえるための Custom Translator のカテゴリの指定で、公式の手順では v2 のエンドポイントと複数サービスのリソースが要るとされています。

AIへ渡す前に整形する

1. 用語の一覧を作る（導入の前に1回、設備ごとに足す） … 設備の部位の名前、メーカーの呼び方、社内の呼び方を対にします
2. 定型文を作る（導入の前に1回） … 安全の指示と、よく使う作業の言い回しを、英語の話せる2名が訳を確かめて登録します
3. 来訪の前日に、設備と部品の一覧を登録する … 型式・号機・関係する部品を、部品マスタから選んで登録します
4. 暫定の結果を記録から除く … 会話の記録に残すのは確定した結果だけにします
5. 短すぎる発話をまとめる … 「OK」「Yes」だけの発話は、直前の発話への応答として結び付けます
6. 部品番号の発話を記録しない値として扱う … 発話の中の英数字の並びは、下書きで部品番号として使わず、写真の側を正とします
7. 区切りごとに会話を分ける … 下書きを作るとき、区切りの番号ごとに会話を渡します

1番目と2番目の作業が、運用に乗るかどうかを決めます。 用語の一覧が無いと、同じ部位が日によって違う訳語で出て、作業記録を検索しても過去の記録に当たりません。

AIに処理させる

させるのは、1日分の会話の原文と訳文、写真、入力値から、作業記録の項目を区切りごとに下書きすることです。

2行目が、この構成でいちばん大事な制限です。 音声で「fifteen」と「fifty」は取り違えやすく、訳文でも数字のまま出てしまいます。値は入力欄、部品は写真という決まりを、下書きの段階でも守らせます。

指示内容を固定する

あなたは工場の保全課で、海外メーカーの技術者の作業に立ち会った記録から、
保全の作業記録の下書きを作る立場です。
渡された会話の記録・写真の記録・入力値だけを根拠にしてください。

【作る項目（区切りごとに）】
1. 行った作業（1〜2文）
2. 交換部品（名前と、対応する写真の記録ID）
3. 調整値（入力欄の値をそのまま）
4. 原因の説明（技術者が述べたもの）
5. 注意点（技術者が述べたもの）
6. 次回の点検（技術者が述べた時期と内容）
7. 根拠にした発話ID

【厳守事項】
- 会話に出てこない原因、対策、推奨を書かないでください。
  一般的な知識で補わないでください。
- 部品番号と数値は、会話の文字から拾わないでください。
  部品は写真の記録、数値は入力値だけを使ってください。
  会話の数字と入力値が違う場合は、mismatch に両方を書いてください。
- 原因の説明・注意点・次回の点検は、技術者が述べたものだけを書き、
  speaker に「技術者」と付けてください。保全員の推測は書かないでください。
- 技術者が前の説明を訂正した場合は、訂正後の内容を書き、
  訂正前の発話IDも corrected_from に残してください。
- 訳文に意味の通らない箇所がある場合は、原文を併記して unclear に入れてください。
- 設備を再稼働してよいかどうかは書かないでください。
- 区切りの中に作業の会話がなければ、その区切りは空にしてください。

【来訪の情報】{visit_info}
【用語の一覧】{glossary}
【会話の記録（区切りごと・確定した結果のみ）】{transcript}
【写真の記録】{photos}
【入力値】{inputs}

「保全員の推測は書かない」を入れているのは、立ち会った保全員が会話の中で推測を口にするからです。 「たぶん冷却水のせいですよね」という保全員の発話に技術者が「Maybe」と答えただけの場面を、原因の説明として記録に残さないためです。

mismatch を返させるのは、聞き違いを見つけるためです。 会話では「15」と言っていたのに、入力欄には「50」が入っている。どちらが正しいかは、保全員が技術者に確かめるか、写真で確かめます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力では、Chat Completions は response_format、Responses API は text.format にJSONスキーマを指定し、すべてのフィールドを必須にして、決まらないものは null との共用体で表します。オブジェクトには additionalProperties: false を設定します。

{
  "visit_id": "",
  "equipment": { "model": "", "unit_no": "" },
  "segments": [
    {
      "segment_no": 1,
      "work_done": "",
      "parts_replaced": [{ "name": "", "photo_id": "" }],
      "adjustments": [{ "item": "", "before": "", "after": "", "input_id": "" }],
      "cause": { "text": null, "speaker": "技術者", "utterance_ids": [] },
      "precautions": [{ "text": "", "speaker": "技術者", "utterance_ids": [] }],
      "next_inspection": null,
      "corrected_from": [],
      "mismatch": [],
      "unclear": []
    }
  ]
}

構造化出力を使う理由は3つです。 1つ目は、保全の管理システムの項目に、そのまま当てはめられることです。2つ目は、utterance_ids で、記録の各行から会話の原文に戻れることです。次の故障のときに「メーカーは何と言っていたか」を原文で確かめられます。3つ目は、mismatch と unclear を必ず返させられることで、確認の順番が決まります。

公式のページでは、スキーマは最大100のオブジェクトのプロパティ、5段の入れ子までとされています。区切りの数が多い日でも、この形なら入れ子は浅いままです。

システムへ連携する

保全の管理システムへは、責任者の確認の後にしか登録しません。 下書きを自動で登録すると、確かめていない原因の説明が、設備の履歴として残り続けます。

部品の在庫の引き落としも、この構成からは行いません。 交換部品は写真と部品マスタで結び付けた候補までにし、引き落としは保全員がこれまでどおり行います。

人が確認する

1. mismatch を先に見る … 会話の数字と入力値が違うものは、写真や技術者への確認で正しい値を決めます
2. unclear を見る … 意味の通らない訳文は、原文を読んで直します。分からなければ英語の話せる2名に聞きます
3. サービスレポートと突き合わせる … 交換部品と作業の項目が、レポートと合っているかを見ます
4. 原因の説明と注意点を読む … 技術者が言ったことかを、根拠の発話の原文で確かめます
5. 責任者が確認する … 再稼働の判断と、作業記録の登録を責任者が行います

3番目のサービスレポートは、これまでどおり紙かPDFで受け取ります。 レポートとの突き合わせは保全員が目で行い、レポートを生成AIに読ませて照合させることは、この構成では行いません。

unclear が多い日は、英語の話せる2名に原文をまとめて見てもらいます。 1日分の unclear を一覧にして渡せば、2名は現場に行かずに、席で十数分あれば読めます。2名の時間の使い方が、立ち会いから原文の確認に変わるのが、この構成のもう一つの効き目です。

目標は、1件あたり45分です。 立ち会いの調整がほぼ無くなり、作業記録は下書きを直す作業になります。残る時間の多くは、mismatch の確認とサービスレポートとの突き合わせです。

例外に対処する

上から3行目は、運用の決まりとして最初に周知します。 作業に慣れてくると、安全の話も音声翻訳で済ませたくなります。「安全の話は定型文」を、技術者にも来訪の初めに定型文で伝えておきます。

通信が途切れた時間帯は、記録の上で分かるようにしておきます。 Canceled を検知した時刻と復旧した時刻を会話の記録に残し、下書きの段階でその時間帯の作業は会話の根拠が無いことを示させます。保全員のメモで補った部分は、メモから書いたことが分かる形で作業記録に入れます。

記録を残す

• 会話の記録（確定した結果のみ。発話ID・話者・原文・訳文・時刻・区切り）
• 写真と入力値、定型文の表示記録
• 生成AIの下書き（segments、mismatch、unclear）
• 保全員が直した箇所と、責任者が確認した日時
• サービスレポート（紙はスキャン）と、突き合わせの結果
• 技術者の録音への同意の有無

会話の記録は、作業記録の根拠として、設備の履歴と同じ期間残します。 次の故障のときに、「前回メーカーは何と言っていたか」を原文で引けることが、この構成の価値の半分です。

音声そのものは残しません。 残すのは文字の記録だけにします。公式のページでは、リアルタイムの音声認識と音声翻訳では、Microsoft は顧客から受け取ったデータを保持・保存しないとされています。自社の側でも、音声を保存する仕組みを作らないことで、保存の範囲が文字の記録に限られます。