💡 この記事の3行まとめ

  1. 「訳が崩れる」と感じる原因は精度ではなく、識別子の翻訳・訳語の不一致・対の切断という3つの故障が同時に起きることです。
  2. レビューの観点を5つに固定すると、どの翻訳手段が自分の現場に合うかを短時間で判定できます。
  3. Mac専用OCR翻訳『Zipp』は ⌃S で囲んで 0.3秒、Apple Visionによる端末内処理。無料でダウンロード（登録不要）、1日15回まで使えます。

📌 この記事の対象読者

  • VS Code の英語エラーや英語コメントを翻訳して読み、用語の訳が毎回ぶれて困っている方
  • 翻訳拡張機能をいくつか試したが、どれが良いかの判断基準を持てていない方
  • レビューや学習のために、訳語の一貫性を自分で管理したいエンジニア

「訳が崩れる」の正体は、精度ではなく3つの同時故障

VS Code の画面には、性質の違う文字列が同じ行に並びます。TypeError: Cannot read properties of undefined (reading 'map') というエラー1行のなかに、型名、プロパティ名、メソッド名、そして英文の説明が同居しています。これを翻訳サービスに貼ると、たいてい日本語になります。しかし読んだあとに「で、どこを直すのか」が決まらない。ここで「訳が崩れた」という感想が生まれます。

崩れ方は3種類に分けられます。1つ目は識別子の翻訳です。reading が「読み取り」、map が「地図」と訳されると、直すべきコードの手がかりが消えます。2つ目は訳語の不一致です。同じ property が、ある画面では「プロパティ」、別の画面では「所有物」「財産」と出てくると、人はそれを別の概念として記憶してしまいます。3つ目は対の切断です。expected と actual のように対で意味を持つ語が行をまたいだ時点で別々に訳され、比較の構図が失われます。

つまり、翻訳の精度を上げても解決しない部分がかなりあります。評価すべきは「日本語が自然か」ではなく、壊れてはいけないものが壊れていないかです。逆に言えば、観点を先に決めておけば、新しいツールを試すたびに同じ土俵で比べられます。

レビューが主観的になりがちなのは、観点が毎回変わるからです。今日は速度、明日は訳文の自然さ、明後日はインストールの手軽さ。基準が動けば結論も動きます。まず観点を固定することが、乗り換え疲れを減らす最短の方法になります。

解決策：5つの観点で見て、3手順で判定する

手順1：観点を5つに固定する

評価の前に、見る場所を決めます。次の5つで十分です。

  • 観点1・識別子の保存：型名、変数名、メソッド名、パスが訳されずに残るか。
  • 観点2・訳語の一貫性：同じ語が同じ訳で出るか。画面を変えても維持されるか。
  • 観点3・対の保存：expected / actual、before / after のような対が対のまま読めるか。
  • 観点4・折り返しの扱い：長い1文が折り返されても語順が壊れないか。
  • 観点5・原文の可視性：訳を読みながら、原文を同じ画面で確認できるか。

5つに絞る理由は、これ以上増やすと毎回の確認が重くなり、結局「速い／遅い」の印象に戻ってしまうからです。観点は判定に使う道具であって、網羅するための台帳ではありません。

手順2：自分の現場の詰まりを1つ選び、その観点だけで試す

5つすべてを毎回採点すると続きません。直近1週間で一番止まった場面を1つ思い出し、対応する観点を1つだけ選びます。

たとえば「エラーは読めるのに、どの変数が原因か分からない」なら観点1です。「同じ単語の訳が毎回違って、用語集を作り直している」なら観点2です。「長いログが途中から変な日本語になる」なら観点4です。1回の試用で1観点だけ見ると、比較の結論がぶれません。

このとき、題材は実際の自分のコードにしてください。サンプル文では、識別子も対の構造も出てきません。VS Code の統合ターミナルに出た実際のエラーを1つ、そのまま題材にします。

手順3：囲む範囲を固定し、原文と訳を並べて確認する

VS Code では、⌃S（Control + S）を押してから、読みたい範囲をドラッグして囲みます。囲む範囲はエラー1〜2行と、その直前のスタックトレース1行に絞ります。0.3秒で訳が最前面に表示され、原文は隠れません。

この囲み方が評価に向いている理由は、観点1から5までが同じ1画面で確認できるからです。訳文のなかに properties や undefined がそのまま残っていれば観点1は合格。原文と訳が上下に並べば観点5も合格。範囲を狭くしているので、折り返しの影響（観点4）も切り分けられます。評価の手順そのものを固定すると、比較が作業の一部になります。特別な検証時間を作らなくても、日々のデバッグがそのまま試用になります。

評価の観点を比べる

【識別子の保存】
従来：型名やメソッド名まで訳され、手がかりが消えることがある
Zipp：原文が隠れないため、識別子をそのまま読める

【訳語の一貫性】
従来：サービスと文脈ごとに訳語が変わる
Zipp：同じ囲み方なら、同じ位置で同じ語を確認できる

【対の保存】
従来：行をまたぐと expected / actual の対応が切れやすい
Zipp：2行をまとめて囲めるので、対が対のまま残る

【折り返し】
従来：長文を貼ると語順が崩れることがある
Zipp：見た目どおりに囲むため、折り返しの影響を受けにくい

【原文の可視性】
従来：訳文だけを見ることになり、照合に往復が要る
Zipp：訳と原文を同じ画面で見比べられる

【試しやすさ】
従来：サービスごとに利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで

よくある質問（FAQ）

Q. 観点が5つあると、比較に時間がかかりませんか？ A. 実際に使うのは1つか2つです。5つは「どれを選ぶか」を決めるための一覧で、毎回すべてを採点する必要はありません。迷ったときに戻ってくる場所として持っておくだけで機能します。

Q. 訳語の一貫性は、ツール側が保証してくれるものですか？ A. 保証されません。一貫性は、同じ範囲を同じように囲むことで自分側が作るものです。だからこそ、範囲の決め方（手順3）を先に固定する価値があります。範囲が安定すれば、訳語の揺れも比較しやすくなります。

Q. 識別子が訳されてしまう翻訳サービスは、避けるべきですか？ A. 用途によります。日本語の意味をざっと掴みたいだけなら問題ありません。コードを直すための読解では、識別子が消えると手がかりが失われるため、原文が残る手段のほうが向いています。

Q. 1日15回でレビューは足りますか？ A. 観点を1つに絞れば、10回もあれば傾向は見えます。回数を増やすより、同じ題材で同じ範囲を囲むほうが比較の精度は上がります。

評価の基準は、ツールより先に自分で決める

翻訳ツールのレビューを読むと、たいてい「精度が高い」「速い」と書かれています。しかしその言葉が自分の現場のどの詰まりに対応するのかは、記事からは分かりません。基準を自分で持てば、レビューは参考情報になり、判断は自分の手元に残ります。

今日、VS Code の実際のエラーを1つ選び、⌃S で2行だけ囲んでみてください。訳のなかに識別子が残っているか。原文が隣に見えているか。その2点を確認するだけで、次に別の手段を試すときの見方が変わります。

▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh