シライショウタ（Bot開発エンジニア）
去年、海外製のチャットBot管理画面を日本語化したとき、モーダル右上の「Close」が「近い」になった。灰色の丸い×アイコンの脇に、小さくそう出た。自動翻訳の初回候補だった。担当デザイナーはFigmaに流し込み、私はWebhookの失敗通知を追っていて、その一語を飛ばした。変なのに、クリックすれば閉じる。操作が成立するせいで、違和感だけが後回しになった。
翌週のQAでも、その文言は残った。Jiraには「日本語が不自然」と書かれたが、優先度は最低だった。閉じるボタンとして機能する、リリース判定には影響しない、という理由で棚上げされたからだ。さらにまずかったのは、その画面を使ってCS向け手順書が作られたことだ。「右上の近いを押してください」とPDFに入り、社内FAQにも同じ文が貼られた。原文キーはbtn_closeのままなのに、日本語だけが別系統で増えた。
一か月後、問い合わせが二件来た。「近いとは何ですか」「閉じるのことですか」。どちらも、こちらが配ったPDFの文言をそのまま引用していた。利用者は画面そのものより、案内文のほうを正解として読む。だから短いラベルの誤訳はしぶとい。通知やボタンは前後の文脈が薄く、位置とアイコンで意味が補われるぶん、変でも進めてしまえる。読めるから直らない。ここがいちばん厄介だ。
誤訳は事故ではない。見逃され、転記され、再利用された時点で運用になる。
Botの翻訳で崩れやすい場所は、だいたい決まっている。単語だけ切り出されたボタン、主語のない通知、設定画面の短い説明、英語では名詞でも日本語では動詞にしないと収まりが悪い項目だ。しかもレビューでは、先に見るのが画面遷移、権限、APIの戻り値で、日本語は最後に回る。結果として「保存しました」と「保存されています」の差は流れ、「招待済み」と「招待しました」のねじれも残る。日本語のチェックはいつも混雑している。
いま翻訳ログを見るとき、私は文の善し悪しより先に、その一行が次にどこへ貼られるかを考える。管理画面、手順書、FAQ、返信テンプレート。そこで止めなければ、あとから修正しても古い文が残り続ける。雑な日本語はモデルだけでは作れない。急ぎの修正を優先した私、動けばよしで流したチーム、画面をそのまま写した運用、その全部で作る。開発側にいるなら、その増え方まで引き受けるしかない。