海外ベンダーのサポートとやり取りする英文のチケットを、受信は日本語の要点に、送信は用語集にそろえた英文に訳して経緯を残す

処理の起点を決める

受信は、共有のメールボックスにベンダーのサポートからのメールが届いたことを起点にします。 差出人のアドレスと件名のチケット番号の形で、サポートからの更新だけを拾います。ベンダーの営業や請求のメールは対象外にします。

送信は、担当者が Teams のチャネルで「英訳する」を押したことを起点にします。 日本語の返信の下書きを貼り、チケット番号を選んで依頼します。メールの下書きフォルダを監視する形にはしません。 下書きの途中で訳が動き、書きかけの文が訳されることがあるからです。

これとは別に、毎朝9時に期限の点検を動かします。経緯の記録から、依頼事項の期限と自動クローズの予告が今日か明日に来るチケットを拾い、担当のチャネルに並べます。届いたメールを訳すだけでは、返信していないチケットに気づけません。

入力データを集める

質を決めるのは、用語集です。 3種類の行を持たせます。

3つ目の行がいちばん効きます。 ベンダーは深刻度をそれぞれの定義で受け付けます。担当者の日本語が同じでも、訳が揺れればベンダーの優先度が揺れます。 ベンダーの一覧に、そのベンダーが深刻度を何と呼ぶか（Severity 1、P1、Critical など）を持たせ、用語集の言葉と結び付けておきます。

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

受信のメールは、Power Automate のメールの受信のトリガーで取ります。本文はHTMLから文字だけにし、過去のやり取りの引用部分を外します。

引用部分を外すのは、訳の対象を絞るためです。 ベンダーのメールには、それまでの往復が全文で引用されていることが多く、そのまま渡すと毎回すべての往復を訳し直し、要点に古い依頼事項が混ざります。 新しく書かれた部分だけを訳し、文脈は経緯の記録の要約で補います。

添付ファイルは訳しません。 ログやスクリーンショットは、そのまま経緯の記録にリンクを残します。

AIへ渡す前に整形する

1. 差出人の確認 … ベンダーの一覧にあるサポートのアドレスからのメールだけを通します
2. 引用部分と署名の除去 … 返信の区切りの行より下を外し、署名の定型を外します
3. 訳さない部分の退避 … 次のものを ⟦T01⟧ のような記号に置き換え、元の文字列を表に退避します
4. 用語集の該当行を選ぶ … 本文に出てくる語の行だけを指示に入れます
5. 個人の情報の点検 … 本文に社員の氏名・メールアドレス・電話番号があれば、記号に置き換えます

3番目で退避するもの：

退避の前と後は、たとえば次のようになります（文面は説明のための例です）。

【退避の前】
Thanks for the logs. The error "AUTH_TOKEN_EXPIRED (0x8004)" in
2026-10-06 09:14:22 sync-agent[3321] indicates the connector v4.12.3
could not refresh the token. Please run: connector-cli token --refresh
If we don't hear back within 72 hours, this case will be auto-closed.

【退避の後（AIに渡す文）】
Thanks for the logs. The error ⟦T01⟧ in
⟦T02⟧ indicates the connector ⟦T03⟧
could not refresh the token. Please run: ⟦T04⟧
If we don't hear back within 72 hours, this case will be auto-closed.

最後の1文は退避しません。 期限の文は訳して拾う対象だからです。退避するのは、ベンダーの側で検索や照合に使われる文字列だけです。

3番目を省かないでください。 AIに「エラーメッセージは訳さないで」と指示するだけでも多くは守られますが、守られなかった1件はベンダーとのやり取りを1往復無駄にします。 記号に置き換えておけば、AIはそもそもその文字列を見ません。

AIに処理させる

ChatGPT にさせることは、受信の訳と送信の訳の2つです。

受信の訳でさせること

期限は、書かれた文をそのまま引用させます。 「3営業日以内」「72時間以内」のように相対的に書かれた期限を、AIに日付へ直させません。営業日の数え方はベンダーの所在地の祝日で変わるからです。 日付への換算は、受信日時からワークフローの側で行い、換算できないものは引用のまま担当者に見せます。

送信の訳でさせること

4行目がいちばん起きやすい失敗です。 AIは丁寧な英文にしようとして、"We will get back to you by tomorrow." のような一文を足します。担当者が書いていない約束がベンダーに届き、守れなければこちらの信用が落ちます。

指示内容を固定する

受信の訳には、次の指示を使います。

あなたは情報システム部門で、海外ベンダーのサポートから届いた英文を
社内の担当者のために日本語にする立場です。

【守ること】
- ⟦T01⟧ のような記号は、訳さずにそのままの位置に残してください。
  記号の中身を推測して書かないでください。
- 下の用語集にある語は、用語集の日本語で訳してください。
  「訳さない語」は英語のまま残してください。
- 依頼事項は、こちらがすべき作業を1つずつ分けて書いてください。
  ベンダー自身が行う作業は依頼事項に入れないでください。
- 期限は、本文の文をそのまま英語で引用し、日付に直さないでください。
  自動でクローズする旨の文があれば、必ず期限に入れてください。
- 本文に書かれていない原因や対策を補わないでください。
- 状態は、次の5つから1つ選んでください：
  waiting_on_us / vendor_investigating / solution_proposed / closure_warning / closed

【これまでの経緯（要点）】{history}
【用語集】{glossary}
【ベンダーの深刻度の呼び方】{severity_terms}
【本文】{body_with_placeholders}

「自動でクローズする旨の文があれば、必ず期限に入れる」を名指しで書きます。 書かないと、AIはこの定型文を「挨拶の一部」と見なして要点から落とします。人が読み落とすのと同じ理由で、AIも落とします。

送信の訳の指示の中心は、次の5行です。

- 担当者の日本語に書かれていない約束、期限、謝罪、断定を足さないでください。
- 深刻度や影響を表す言葉は、用語集の対応どおりに訳し、強めたり弱めたりしないでください。
- ⟦T01⟧ のような記号は、そのままの位置に残してください。
- 訳した英文を日本語に戻した文を back_translation に入れてください。
- 日本語の原文に無い内容を英文に入れた場合は、その部分を added_content に書いてください。

出力形式を固定する

受信の訳は、次の形のJSONで受け取ります。

{
  "ticket_no": "",
  "summary_ja": "",
  "translation_ja": "",
  "requests": [ { "action_ja": "", "quote_en": "" } ],
  "deadlines": [ { "type": "request | auto_close | next_update", "quote_en": "" } ],
  "status": "waiting_on_us | vendor_investigating | solution_proposed | closure_warning | closed"
}

送信の訳は、次の形で受け取ります。

{
  "ticket_no": "",
  "text_en": "",
  "glossary_applied": [ { "ja": "", "en": "" } ],
  "back_translation": "",
  "added_content": [ "" ]
}

1つ目の理由は、依頼事項と期限が欄として残ることです。 経緯の記録に、要点・依頼事項・期限・状態の列を持たせておけば、毎朝の期限の点検は、その列を読むだけで済みます。 和訳の文章から期限を探し直す必要がありません。

2つ目は、quote_en で原文の該当箇所に戻れることです。 依頼事項の訳に迷ったら、担当者は英文の該当の1文だけを見れば確かめられます。

3つ目は、added_content で点検の結果が欄として返ることです。 空の配列なら、日本語に無い内容は足されていません。空でなければ、送る前に担当者が必ず目を通します。 すべての項目を required にし、additionalProperties を false にしたスキーマで渡すので、点検の欄が抜けたまま返ることはありません。

ワークフローは、受け取ったあとに次を確かめます。

システムへ連携する

メールを自動で送りません。 送信の訳は Teams に返すだけで、担当者がメールの返信に貼って自分で送ります。 ベンダーとのやり取りは、契約にもとづくサポートの記録として残るからです。

ベンダーのサポートの画面には書き込みません。 チケットの画面への直接の書き込みは、ベンダーごとに方式が違い、利用環境に応じた個別実装になります。メールの往復で足りるベンダーから始めます。

人が確認する

受信は、要点と依頼事項を読むことが確認です。 全文の和訳は、要点だけで判断がつかないときに開きます。

1. closure_warning のチケットを最初に見る … 返信の期限が近いものから手を付けます
2. 依頼事項を読み、作業の担当を決める … 経緯の記録の担当の欄を埋めます
3. 記号の照合で止まったものは、原文で確かめる

送信は、毎回人が確かめてから送ります。

1. added_content が空かを見る … 空でなければ、その英文を消すか、日本語の原文に書き足すかを決めます
2. back_translation を読む … 自分の日本語と意味がずれていないかを確かめます
3. 深刻度の言葉を確かめる … glossary_applied に深刻度の語が入っているかを見ます
4. 自分で送る

目標は、240件をならして1件4分です。 受信は要点を読んで1〜2分、送信は逆訳と点検の欄を読んで5〜6分という想定です。

例外に対処する

上の2行が、運用の初めに最も多く出ます。 1行目は退避の規則の漏れ、2行目はベンダーの一覧の整備不足です。どちらも一度直せば同じベンダーでは起きなくなります。

記録を残す

• 受信・送信の原文と訳文、チケット番号、日時
• 要点、依頼事項、期限、状態（経緯の記録の1行として）
• 退避した記号と元の文字列の対応表
• 送信の訳で added_content が出た記録と、担当者が消したか残したか
• そのときに使った用語集の版

経緯の記録が、この構成のもう一つの成果物です。 チケットが閉じたあとも残し、同じ製品で同じ症状が出たときに、日本語で前回の経緯を引けるようにします。 担当が替わっても、後任は英文の往復を読み返さずに済みます。

added_content の記録は、指示の見直しに使います。 同じ型の付け足し（謝罪の定型、期限の約束）が続くなら、送信の指示にその型を名指しで書き足します。