💡 この記事の3行まとめ
- 翻訳が遅く感じる原因は、訳す速さではなく読む順序が毎回変わっていることにあります。
- 「結論 → 原因 → 触る語」の順に読む位置を固定し、囲む範囲をそれに合わせると、1件あたりの判断時間が短くなります。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理。無料でダウンロード（登録不要）、1日15回まで使えます。
📌 この記事の対象読者
- VS Code の英語エラーや警告を、毎回なんとなく上から読んでいる方
- 翻訳ツールはもう入れているのに、1件あたりの解決に時間がかかっている方
- 読む順序を固定して、コーディングのリズムを崩したくないエンジニア
遅いのは翻訳ではなく、毎回「読む順序」を考え直しているから
VS Code の画面には、英語が思った以上に多く出てきます。TypeScript の型エラー、ESLint の警告、npm の依存解決失敗、拡張機能の設定不足。どれも数行の英文で、意味さえ分かれば数秒で手が動きます。ところが実際には、その数行で数分止まります。
ここで多くの人が「翻訳が遅いからだ」と考えて、翻訳サービスを変えたり、より高機能なツールを探したりします。しかし、実際に時間を食っているのは翻訳の速度ではありません。読む順序を毎回ゼロから組み立て直していることです。
英語のエラーメッセージは、日本語の説明文と同じ順序では書かれていません。error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'. という1文を例に取ります。日本語なら「文字列型を数値型の引数に渡しているので型エラーです」と結論が先に来ますが、英語では error TS2345 という識別子が先頭に置かれ、型の説明が続き、最後に何が問題なのかが示されます。つまり上から順に読むと、結論にたどり着くのが一番遅い読み方になります。
さらに VS Code では、1つの問題が複数の場所に書かれています。エディタ内の波線、ホバー時のツールチップ、下部パネルの PROBLEMS タブ、そしてターミナルの出力。同じエラーでも表現が少しずつ違い、しかも長さが違います。ここで「どの面の、どの行から読むか」を毎回決めていると、判断のたびに小さな迷いが発生します。この迷いは1回では大したことありませんが、1日に何十回も積み上がると、作業の流れが細かく分断されます。
速く読むというのは、目の移動速度を上げることではありません。同じ種類のエラーに対して、同じ順序で同じ場所を見ることです。順序が固定されれば、翻訳の精度が上がらなくても、判断までの時間は確実に縮みます。逆に順序が定まらないまま翻訳ツールだけを速くしても、迷う回数は減りません。
もうひとつ見落とされがちなのが、読む順序と囲む範囲の関係です。翻訳する範囲を毎回アドリブで決めると、出てくる訳文の粒度も毎回変わります。粒度が変われば、どこまで読めば判断できるかも変わります。つまり順序の不安定さは、囲み方の不安定さを経由して、訳文の読みにくさに直結しています。だからこそ、最初に決めるべきは翻訳の手段ではなく、読む順序と囲む範囲のセットです。
解決策：読む順序を3手順で固定する
手順1：結論の行を先に特定する
英文を読み始める前に、まず結論が書かれている行を探します。探すときの合図は決まっていて、error、cannot、not assignable、is not defined、failed、missing といった語です。これらは英文の途中から現れ、その後ろに本当の原因が続きます。
たとえば Cannot find module 'foo' or its corresponding type declarations. なら、Cannot find module が結論で、'foo' が対象、or its corresponding type declarations が補足です。この3つを分けて見るだけで、どこを直せばいいかがほぼ確定します。
この手順を飛ばして上から読むと、error TS2307: のような識別子とファイルパスの情報を先に処理することになり、脳の作業領域を結論以外に使ってしまいます。結論の行を先に掴む、これが最速読解の最初の一手です。
手順2：結論の1文と直前の識別子だけを囲む
結論の行が分かったら、翻訳する範囲を絞ります。⌃S（Control + S） を押し、結論の行と、その直前に出ている識別子（ファイル名・型名・モジュール名）だけをドラッグして囲みます。
この囲み方には理由があります。結論の英文だけを囲むと、どの対象についての結論なのかが訳文から落ちます。逆に画面全体を囲むと、無関係な行の英文が混ざり、訳文のなかで結論の位置が分からなくなります。1文＋直前の識別子という単位は、VS Code のエラー表示の構造と一致しています。
囲み終えると 0.3秒 で訳が最前面に表示され、原文は隠れません。訳で結論の意味を掴み、原文で識別子の綴りを確認する。この往復が1回で終わるため、視線の移動が最小になります。
手順3：触る語は訳さず原文で確定する
訳文を読んだあと、最後に必ず原文へ戻って識別子を確認します。型名、関数名、ファイルパス、設定キー。これらは訳す対象ではなく、そのままコピーして検索したり修正したりする対象です。
ここを訳文で済ませると、存在しない日本語名を頼りに修正してしまい、二次的なエラーが増えます。tsconfig.json の strict を「厳格」と読んで理解するのは構いませんが、設定ファイルに書くのは strict という文字列です。理解は訳文で、操作は原文で。この分担を固定すると、翻訳の粗さが作業の質に影響しなくなります。
3つの手順を並べると、読む順序は「結論 → 原因句（囲む）→ 触る語」になります。この順序を、エラーの種類が変わっても崩さないことが重要です。順序が固定されれば、囲む範囲も自然に固定され、訳文の粒度も安定します。
読む順序の作り方を比べる
【読み始める位置】
従来：先頭の識別子から順に読むため、結論が最後になる
Zipp：結論の語を探してから読み始められる
【囲む範囲】
従来：毎回アドリブで決まり、粒度が安定しない
Zipp：1文＋直前の識別子に固定できる
【訳文と原文の関係】
従来：コピー元が隠れ、原文に戻るのに手間がかかる
Zipp：原文が隠れないため、その場で綴りを確認できる
【判断までの往復】
従来：コピー・貼り付け・画面切り替えで3回以上
Zipp：⌃S とドラッグの1往復で完結する
【処理の場所】
従来：サービス側で処理され、送信内容を意識する必要がある
Zipp：Apple Visionによる端末内処理で、画面画像の外部保存ゼロ
【試しやすさ】
従来：サービスごとに利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 結論の語を探すほうが、上から読むより時間がかかりませんか？
A. 最初の数回は視線が迷うため、遅く感じます。しかし探す語は十数個に絞られており、慣れると無意識に拾えるようになります。上から読む方法は毎回同じだけ時間がかかりますが、結論を探す方法は回数を重ねるほど短くなります。伸びしろがあるのは後者です。
Q. エラーが長文で、結論が1行に収まらない場合はどうすればいいですか？
A. その場合は文の区切りで分け、最後の文だけを先に囲んでください。英語の技術文では、because、since、due to の後ろに原因が来ることが多く、結論は最後の文に置かれる傾向があります。分けて囲めば、訳文も読みやすくなります。
Q. 囲む範囲を固定すると、逆に情報が足りなくなりませんか？
A. 足りないと感じたときだけ、2文目を追加で囲めば十分です。最初から広く囲むと、訳文のなかで必要な情報を探す作業が発生します。狭く囲んで足すほうが、広く囲んで削るより速く、精度も安定します。1日15回までという回数の範囲内でも、この使い方なら主要なエラーは処理できます。
Q. 順序を固定しても、エラーの種類が変わると崩れてしまいます。
A. 崩れたと感じたときは、その場で順序を作り直さず、いったん結論の語を探す手順だけを実行してください。順序のうち最初の1手が残っていれば、残りは自然に続きます。全部を維持しようとすると負荷が上がるので、核になる1手だけを守るほうが長続きします。
速さは、訳す前に決まっている
VS Code の英語を速く読むために、語彙を増やす必要はありません。必要なのは、同じ種類のエラーに対して同じ順序で画面を見るという小さな規律です。結論の語を先に探し、結論の1文と直前の識別子だけを ⌃S で囲み、触る語は原文で確定する。この3手順が固定されると、翻訳にかかる時間より、翻訳するかどうかを決める時間のほうが短くなります。
今日の作業でエラーが1つ出たら、上から読む前に一度だけ cannot や not assignable を探してみてください。訳文を読む前に結論の位置が分かる、その手応えが、最速読解の出発点になります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh