フェリー会社が運航の変更・ダイヤ改正・乗船の案内を英語・中国語・韓国語に訳し、港名と便名の訳語と時刻の表記をそろえる

処理の起点を決める

担当が日本語のお知らせを書き、確認の画面で「訳す」を押したときに動かします。 日本語のお知らせをWebサイトに出した瞬間に自動で動かす形にはしません。日本語のお知らせは出した後に直すことが多く、直す前の文で訳文ができてしまうからです。

運航の変更のお知らせは、日本語を出した直後に押す運用にします。 天候による欠航の判断は出航の数時間前に決まることが多く、外国語のお知らせが遅れると、外国人の旅客だけが港に来てしまいます。 押してから訳文が出るまでを1分以内に収め、担当がその場で確かめて出せるようにします。

ダイヤ改正のお知らせは、掲載の日より前に押します。 新しい時刻表が決まった時点で日本語の案を作って訳し、中国語・韓国語の分かる人に読んでもらう時間を、掲載の前に確保します。 急ぎのお知らせと同じ流れで作り、確認の時間の取り方だけを変えます。

入力データを集める

質を決めるのは、用語集です。 港名を英語で「Port」とするか「Ferry Terminal」とするか、船名にローマ字の長音を付けるかは、一度決めて全部のお知らせで同じにすることに意味があります。 決め方の正解を探すより、乗り場の案内板と同じつづりにそろえることを優先します。

中国語は簡体字と繁体字で列を分けます。 港名や船名の漢字は、日本語の字体をそのまま使えないことがあり、簡体字と繁体字でも字体が違います。1つの列に混ぜると、繁体字のお知らせに簡体字の港名が入ります。 訳語は、中国語の分かる人に一度確かめてもらってから用語集に入れます。

用語集の1行には、日本語の表記ゆれも持たせます。 「新門司」「新門司港」「新門司フェリーターミナル」を同じ行に入れ、どれが書かれても同じ目印に置き換わるようにします。

書式の規則の例：

時刻を3言語とも24時間制にそろえるのは、乗り場の時刻表と同じ表記にするためです。 午前・午後の書き間違いが、この規則だけで起きなくなります。

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

用語集と定型文の一覧は、Azure Functions が起動のたびに SharePoint のリストから読みます。 件数は数百行なので、毎回読み直しても時間はかかりません。キャッシュを長く持つと、用語集を直したのに古い訳語で戻ることになります。

日付・時刻・便の番号・金額は、正規表現で探します。

「11/3」の解釈は、日本語の原文で一度だけ行います。 置き換えのときに年月日の値として持ち、戻すときに言語ごとの書式で書き出します。生成AIに日付の形を任せないので、月と日の取り違えが起きません。

「午後2時30分」のような書き方も、置き換えの段で14:30の値に直します。 日本語の原文に12時間制と24時間制が混ざっていても、対応表には24時間制の値だけを持たせます。 戻すときに言語ごとの書式で書き出すので、訳文の側で揺れることはありません。「正午」「深夜0時」のような語も、値として持てるよう正規表現の一覧に入れておきます。

時刻表の表は、表のまま扱います。 行と列を分けて、見出しの行だけを訳し、数字のセルは訳さずにそのまま使います。表の数字のセルを生成AIに渡さないことが、第3章の（c）への対策です。

AIへ渡す前に整形する

1. 用語集による置き換え … 長い表記から順に照合します（「新門司フェリーターミナル」を「新門司」より先に）
2. 数字の置き換え … 日付・時刻・便の番号・金額を目印にし、元の値を対応表に残します
3. 定型文の照合 … 文単位で定型文の一覧と照合し、当たった文は定型の訳文に置き換えて、生成AIに渡さないようにします
4. 表の分離 … 時刻表の表を本文から分け、見出しの行だけを訳す対象にします
5. 目印の数の記録 … 置き換えた目印の種類と数を記録し、訳した後の照合に使います
6. 用語集に無い固有名詞の印 … 「◯◯港」「◯◯丸」のように港や船らしいのに用語集に無い語に印を付け、担当の画面で知らせます

1番目で長い表記から照合するのは、短い表記が先に当たると目印の後ろに文字が残るからです。 「新門司」が先に当たると「{{PORT_01}}フェリーターミナル」となり、戻したときに「Shin-Moji Port Ferry Terminal」のような重複が生まれます。

1. 目印の番号の振り方 … 同じ港が文中に2回出てくれば、同じ目印を2回使います。別の番号を振ると、戻したときに同じ港が違う訳語になる余地が生まれます

6番目は、用語集を育てる仕組みです。 新しい寄港地や代替船の名前は、最初は用語集にありません。印が付いた語を担当が用語集に足せば、次のお知らせからは同じ訳語で戻ります。

AIに処理させる

させるのは、目印を残したまま、日本語のお知らせの文章を3言語に訳すことだけです。

文章ごと訳させて後から名前を直す方法を取らないのは、直す場所を探す作業が残るからです。 生成AIが港名を「Port of ◯◯」「◯◯ Harbor」と訳した後で用語集の訳語に直すには、訳文の中から港名を探し当てる必要があります。目印にして渡せば、探す作業そのものがなくなります。

最後の行は、運航のお知らせでいちばん大事な約束です。 「欠航（その便は出ない）」「遅延（遅れて出る）」「条件付き運航（引き返す・寄港地を変えることがある）」「抜港（その港に寄らない）」は、旅客の行動を変える語です。 これらは用語集に「運航の状態の語」として3言語の訳語を持たせ、目印に置き換えて渡します。

指示内容を固定する

あなたはフェリー会社のお知らせを訳す担当です。
日本語のお知らせを、英語・中国語（簡体字）・中国語（繁体字）・韓国語に訳してください。

【目印の扱い】
- {{ と }} で囲まれた目印（{{PORT_01}}、{{TIME_02}}、{{STATUS_01}} など）は、
  そのままの形で訳文に入れてください。訳さない、消さない、増やさないでください。
- 目印の位置は、訳す言語の自然な語順に合わせて動かしてかまいません。

【厳守事項】
- 日付、時刻、数字を訳文に書かないでください。すべて目印で渡しています。
- 港、ターミナル、船、便、航路の名前を訳さないでください。目印で渡しています。
- 原文に無い説明やお願い（「ご了承ください」など）を足さないでください。
- 港や船の名前らしいのに目印になっていない語は、訳さずに原文のまま残し、
  untranslated_terms に挙げてください。
- 意味が二通りに取れる文は、訳したうえで unclear に原文を挙げてください。
- 文体は、乗り場の掲示として丁寧で短い文にしてください。

【お知らせの種類】{notice_type}
【お知らせ】{source_with_tokens}

「目印の位置を動かしてよい」と書いているのは、語順が言語ごとに違うからです。 日本語の「{{PORT_01}}発{{TIME_01}}の便」は、英語では時刻が先、港が後になることがあります。位置を固定させると不自然な訳文になるので、動かすことは許し、数と形だけを守らせます。

指示の順番は、変わらない部分を先に置きます。 公式のページでは、プロンプトのキャッシュは1,024トークン以上で、最初の1,024トークンが同一であることが条件とされ、最初の1,024トークンのうち1文字でも違うとキャッシュに当たらないとされています。キャッシュは対応するモデルで既定で有効とされています。指示と定型の例文を先頭に固定し、お知らせの本文を最後に置くと、件数の多い日に応答が速くなります。 構造化出力のスキーマはシステムのメッセージの前に付く形でキャッシュの対象になるとも書かれているので、スキーマも変えずに使い回します。

出力形式を固定する

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

{
  "translations": [
    { "lang": "en", "title": "", "body": "" },
    { "lang": "zh-Hans", "title": "", "body": "" },
    { "lang": "zh-Hant", "title": "", "body": "" },
    { "lang": "ko", "title": "", "body": "" }
  ],
  "untranslated_terms": [],
  "unclear": []
}

1つ目の理由は、言語ごとの訳文を決まった欄で受け取れることです。 lang は列挙型で4つに限り、Webサイトの言語ごとの欄にそのまま対応させます。

2つ目は、untranslated_terms で用語集の不足が分かることです。 前処理の印と合わせて、担当の画面に「用語集に足す候補」として並べます。

3つ目は、照合をしやすくすることです。 Azure Functions は body から目印を数え、前処理で記録した目印の種類と数と比べます。1つでも違えば、その言語の訳文を赤く表示し、目印を戻す前に担当に見せます。 さらに、目印を戻した後の訳文に、目印以外の数字が出ていないかも確かめます。

スキーマの制約は公式のページに合わせます。 配列の minItems・maxItems はサポートされないキーワードとされているので、4言語がそろっているかは Azure Functions で確かめます。 入れ子は5段まで、オブジェクトのプロパティは最大100個とされ、この形なら収まります。

システムへ連携する

運航情報をメールで配信している場合も、配信の文は確かめた訳文から作ります。 配信の仕組みに日本語と外国語の欄が分かれていれば、言語ごとの欄に貼るだけです。配信の登録者が選んだ言語で届くかは、配信の仕組みの設定で確かめてください。

用語集への書き込みは、担当が SharePoint のリストで行います。 確認の画面から「用語集に足す」を押すと、リストの入力画面が開くだけにします。訳語を決めるのは人で、仕組みが勝手に足すことはしません。

人が確認する

担当が見る順番を決めておきます。

1. 赤い箇所を見る … 目印の数のずれ、目印以外の数字。ここが0件になるまで出さない
2. 運航の状態の語を見る … 欠航・遅延・条件付き運航・抜港が、原文と同じ訳語になっているか
3. untranslated_terms と印の付いた語を見る … 用語集に足すか、原文のまま出すかを決める
4. unclear を見る … 日本語の原文を直したほうが早いことが多い
5. 英語の文を読む … 英語のできる担当がいれば全文、いなければ見出しと最初の文

急ぎのお知らせでは、確認にかける時間の目安を決めておきます。 欠航のお知らせなら、赤い箇所が0件で運航の状態の語が合っていれば、日本語を出してから10分以内に外国語も出すことを目標にします。待たせるより、照合の済んだ訳文を早く出すほうが旅客のためになります。

中国語と韓国語は、全文を読める人がいない前提で作ります。 その代わりに、目印と運航の状態の語と数字は機械で照合済みなので、担当は「何がいつどうなるか」が正しいことを確かめられます。ダイヤ改正のように影響の大きいお知らせは、出す前に中国語・韓国語の分かる人（社内の他部署や外注）に1回読んでもらいます。

例外に対処する

「訳した後に直された」の行は、運航の変更のお知らせでよく起きます。 「遅延」が「欠航」に変わるのはよくあることで、日本語だけ直して外国語が古いまま残るのがいちばん危ない状態です。日本語のお知らせと訳文に同じ版の番号を付け、版が違う訳文は確認の画面で出せないようにします。

記録を残す

• 日本語のお知らせ（版の番号付き）と、目印に置き換えた文、目印と元の値の対応表
• 生成AIの出力（3言語の訳文、untranslated_terms、unclear）
• 照合の結果（目印の数、目印以外の数字）
• 担当が直した箇所と、掲載した訳文と掲載の日時
• そのとき使った用語集の版

照合の結果は、赤く表示された理由ごとに月ごとに数えます。 目印を消した件数が多ければ指示を、用語集に無い語が多ければ用語集を直します。直す先が数で分かります。

最後の行の用語集の版は、訳語を変えたときに要ります。 港の英語の表記を変えると、過去のお知らせとつづりが違ってきます。どのお知らせがどの版の用語集で訳されたかが分かれば、直すべき掲示を探せます。