翻訳は止められない。それでも設定はできる
翻訳ボタンは軽い。
でも、その裏は軽くない。
ワンタップで言語が変わると、端末の中だけで完結している気がする。
実際には、そうとは限らない。見えない場所で処理が動く。
ここから先は、その「ずれ」を整地する話。
翻訳は「機能」じゃなく「環境」
いまの翻訳は、追加機能というより生活環境に近い。
翻訳のために、わざわざ翻訳サイトを開く必要性はあまりない。
Chromeでページを翻訳する。
Google翻訳ページに貼り付けて翻訳する。
どちらも「同じ系統の翻訳」に乗る。
細かいことを言えば、ページ翻訳はHTMLをほどきながら訳す。
だから結果が揺れることはある。
でも本質は、翻訳が環境として常駐していることだ。
国によって割合は大きく異なるけど、こと日本で言えばバイリンガルは少数派だ。
大体の人には有難い機能だと思う。
問題は、Webエンジニアにとっては有難い存在でないことがあるということ。
例えば管理画面でラベルが翻訳されると、操作ミスが起きる。
「停止」「削除」みたいな単語ほど怖い。
そして translate="no" を付けても、無視されることがある。
エンジニア視点で見ると翻訳は設計者の手を離れやすく、扱いに困ることがある。
翻訳ボタンは機能というより環境に近い。これを制御しようとするのは、レスポンシブより厄介かもしれない。
クラウドとオンデバイスで「境界」が変わる
あんまり意識してこなかったけども、翻訳には大きく2種類ある。
- クラウド翻訳：テキストが外に出て処理される
- オンデバイス翻訳：端末内で完結する
違いはシンプルで、
その文字列が、どこまで自分の世界に留まるか
が変わる。
機密性が絡むなら、まずここを意識したほうがいい。
これは意外と盲点であることが多い。
例えば、HTMLを勉強するついでにあなたの個人情報をマークアップして、ブラウザに表示した。
このときクラウド翻訳では、翻訳サーバーと連携して処理する必要がある。
これは僕の感覚だけれど、ECサイトで決済する時ほど「送信」が行われていることを大抵の人は意識しないと思う。
でも境界線の意味は、同じだ。
境界線をどう定めるか？
つまるところ翻訳は「制御しない」方向に倒すといい。
これは「何もするな」という意味ではない。
ベストエフォートで抑制するのは予防策になる。
ただ、翻訳が環境である以上、「制御できる前提」に倒すほどリスクが高まる。
例えば極端な話。
クラウドで動く社員情報管理のWebアプリを運用するとして、利用規約やプライバシーポリシーへの同意を考える。
このとき「クラウド翻訳で通信が発生しないこと（つまり制御できること）」を保証するべきではない、という話になる。
なので翻訳の是非は、機能で決めない方がよく。
「外に出るか」を先に決めた上で、開発の方針に組み込んだ方が良いと思う。
- その文字列に個人情報 / 機密が混ざるか
- 誰が押すか（ユーザー / 社内 / 代理店 / 端末共有）
- どこで処理されるか（クラウド / オンデバイス / 不明）
- 規約上、入力していいか（例：DeepL 無料版は機密情報や個人データを含むテキストの翻訳に使えない）
- ログや学習に回る可能性を許容できるか
- 画面の中で「翻訳していい領域」と「ダメな領域」を分離できるか
- 誤って流れたとき、取り戻せるか（スクショ / コピー / 二次共有は戻らない）
- オンデバイスに寄せられるか（Apple Translate は入出力の言語を端末にダウンロードして揃えると、端末内で処理できる）
迷ったら、「外に出る」と見なす。
境界は、推測で設計しない。
設計の話：止めるより「流さない」を作る
そろそろしつこくなってきたけど、翻訳を完全に止めるのは難しい。
だから設計で境界線を引く。
- そもそも翻訳させない前提で作る。ただしベストエフォート（抑制の仕掛けを入れるが保証はしない）
- 外に出さないUIを作る。ユーザーの意識に依存しない導線に寄せる
「翻訳を禁止」より、「誤って流さない」が現実的。
翻訳抑制の最低限セット
翻訳抑制は、単発だと抜ける。
現場は多層でやったほうが事故りにくい。
<html lang="ja" class="notranslate" translate="no">
<head>
<meta name="google" content="notranslate" />
</head>
- ページ全体を止めるなら、テンプレートの
htmlに固定する - 部分的に止めるなら、機密ブロックだけ
class="notranslate"で切り分ける translate="no"だけに寄せない（notranslate/metaを重ねる）- 完全停止は前提にしない（だから「流さない導線」も併用する）
UIは、境界を見えなくする
翻訳だけじゃない。 写真アップロード、SNS投稿、AI解析。どれもワンタップで境界を超える。
なめらかなUIは、距離感を消す。 目に見えるのは“変換結果”だけ。 でも実態は“送信”のことがある。
これからの翻訳は「変換」へ広がる
翻訳は、言語の置換だけで終わらない。 音声、字幕、画像、チャット。いろんな変換が混ざっていく。
だから設計者が見るべきは、
- 翻訳を止めるか
ではなく
- どこで境界を引くか
のほう。
期待：翻訳はもっと自然になる（でも境界は消えない）
これから翻訳は、精度というより「自然さ」で進化していくと思う。 文章だけでなく、音声や字幕、画像内テキストまで、変換が一体化していく。
同時に、オンデバイス処理の選択肢も増えていく。 外に出さずに済む場面が増えるのは、素直にありがたい。
ただ、便利さが増えるほど境界は見えにくくなる。 だから設計は引き続き「外に出るか」を軸にしておくのが安全だと思う。
まとめ
- 翻訳はもはや「機能」ではなく「環境」
- クラウドかオンデバイスかで、データの境界が変わる
- 迷ったらチェックリストで「外に出る前提」を判定する
- 止めるより「流さない設計」「境界線の可視化」が効く
- 翻訳抑制は
translate="no"単発ではなく、多層でやる - プラットフォームは、翻訳を前提に二次流通を整備したほうが強い