💡 この記事の3行まとめ
- 矩形選択と行選択は優劣ではなく、訳したい情報が縦に並んでいるか横に並んでいるかで決まります。
- ログやスタックトレースは矩形、エラー文やコミットメッセージは行選択。この切り分けを先に決めると迷いません。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理。無料でダウンロード（登録不要）、1日15回まで使えます。
📌 この記事の対象読者
- VS Code の矩形選択（Option + ドラッグ）を、なんとなくで使っている方
- ログやスタックトレースを翻訳すると、訳文がごちゃごちゃになる方
- 範囲選択の使い分けを、判断せずに反射でできるようにしたいエンジニア
訳文がごちゃつくのは、選択の向きと情報の向きがずれているから
VS Code には、大きく分けて2種類の選択があります。行単位で上から下へ選ぶ行選択と、桁を揃えて四角く選ぶ矩形選択です。行選択は Shift + 矢印や Shift + クリックで、矩形選択は Option を押しながらドラッグ、または Shift + Option + 矢印で行います。
翻訳のために範囲を選ぶとき、多くの人はこの2つを意識せず、いつも同じ方法で選んでいます。ところが、訳文の読みやすさは選択の向きと、情報が並んでいる向きが一致しているかで大きく変わります。
たとえばスタックトレースを考えます。at Object.<anonymous> (/app/index.js:12:5) という行が、呼び出しの深さごとに縦に並びます。この縦の列を翻訳したいのに、行選択で上から下まで丸ごと選ぶと、パスや行番号まで訳文に混ざります。逆に、1行だけを横に選べば、その行の意味は分かっても、呼び出しの連なりが分かりません。
もうひとつの例が、エディタ下部の PROBLEMS パネルです。ここには ts(2345) のようなコード、ファイルパス、エラー文が横に並びます。横に並んだ情報を矩形で縦に切り取ると、コードだけ、パスだけが抜き出せます。つまり矩形選択は「横に並んだ複数行から、同じ桁位置の情報だけを抜く」操作であり、行選択は「1つの文のまとまりをそのまま取る」操作です。
この違いを理解しないまま使い分けると、翻訳のたびに「なぜか訳文が読みにくい」という感覚だけが残ります。原因は翻訳の精度ではなく、選んだ範囲に、訳す必要のない情報が混ざっていることです。選択の向きを情報の向きに合わせるだけで、同じ翻訳でも得られる情報が変わります。以下の3手順で、場面ごとの使い分けを固定します。
解決策：情報の向きで選択方法を決める3手順
手順1：まず「縦に揃っているか」を見る
範囲を選ぶ前に、訳したい情報が縦に揃っているか、横に連なっているかを一目見ます。判断の基準は単純です。
- 行の先頭が同じ桁位置から始まり、同じ種類の情報が並んでいる → 矩形選択
- 1つの文が長く、行をまたいで続いている → 行選択
スタックトレース、ログのタイムスタンプ、git log --oneline の出力、CSV のような表形式は、行の先頭が揃っています。これらは矩形選択の対象です。一方、TypeScript の型エラー文、ESLint のルール説明、コミットメッセージ、README の段落は、文が横に連なります。こちらは行選択です。
この判定は、囲む前に1秒だけ行います。判定の基準が「縦か横か」の1つだけなので、迷いが残りません。迷わない基準を持つことが、最速の使い分けになります。
手順2：矩形は「桁を揃えて、必要な列だけ」を囲む
矩形選択を使うと決めたら、⌃S（Control + S） を押し、訳したい列の範囲だけをドラッグします。Zipp は画面上の範囲をそのまま読み取るため、選択の形がそのまま翻訳対象になります。
コツは、訳さなくてよい列を最初から外すことです。スタックトレースなら、行番号やファイルパスの列を外し、関数名とメッセージの列だけを囲みます。git log --oneline なら、ハッシュの列を外して件名の列だけを囲みます。ハッシュは訳す対象ではなく、コピーして検索する対象です。
囲み終えると 0.3秒 で訳が最前面に表示され、原文は隠れません。矩形で抜き出した列が、訳文でも列のまま対応するため、どの行がどの訳に対応するかを目で追えます。これが矩形選択の最大の利点です。行選択では失われる「行と訳の対応」が、矩形では保たれます。
手順3：行選択は「1文の切れ目」で止める
行選択を使うと決めた場合は、文の切れ目で選択を止めます。英文は , や ; で節が分かれ、. で文が終わります。日本語の感覚で句点を探すのではなく、英語の区切り記号を目印にします。
長い型エラーでは、Argument of type 'X' is not assignable to parameter of type 'Y'. までを1つの単位とし、そのあとの Types of property 'z' are incompatible. は別の単位として囲みます。1回で囲むと訳文が長くなり、どこが結論か分からなくなります。分けて囲めば、訳文も短く、判断も速くなります。
行選択の弱点は、選択した行に含まれる識別子まで訳文に入ることです。しかし原文が隠れないため、訳文で意味を掴み、原文で綴りを確認する往復が1回で済みます。行選択は「意味を掴む」用途、矩形選択は「対応を保つ」用途と覚えておくと、使い分けが反射になります。
矩形選択と行選択を比べる
【向いている情報】
従来：文が横に連なる説明文
Zipp：縦に揃ったログ・スタックトレースも囲める
【訳す列の絞り込み】
従来：行番号やパスも一緒に訳文へ入る
Zipp：必要な列だけを矩形で抜ける
【行と訳の対応】
従来：訳文が連結され、どの行か分からなくなる
Zipp：矩形のまま対応が保たれる
【1回あたりの結果】
従来：範囲が広いと訳文が長く、結論が埋もれる
Zipp：⌃S から 0.3秒で短い訳が出る
【原文の確認】
従来：コピー元が隠れ、綴りの確認に戻る必要がある
Zipp：原文が隠れないため、その場で照合できる
【試しやすさ】
従来：サービスごとに利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 矩形選択は VS Code の標準機能ですか？
A. はい。macOS では Option を押しながらドラッグすると矩形選択になり、Shift + Option + 矢印キーでも同じ操作ができます。エディタだけでなく、ターミナルの出力やパネルの表示でも、文字を選択できる場所なら同じ考え方で範囲を取れます。ただしアプリによっては選択の挙動が異なるため、まずはエディタで試すのが確実です。
Q. 矩形で囲むと、行の長さが揃っていないときに文字が欠けませんか？
A. 欠けることはあります。行の長さが揃っていない箇所は、短い行の末尾が選択範囲から外れます。その場合は、いちばん長い行に合わせて矩形の右端を広げるか、その行だけ行選択に切り替えてください。揃っている列は矩形、揃っていない行は行選択という併用が現実的です。
Q. 結局どちらか1つに決めたほうが速いのでは？
A. 1つに決めると、判定の手間はなくなりますが、場面によって訳文の質が落ちます。ログを毎回行選択で囲むと、パスや行番号が訳文に混ざり、読む時間が増えます。判定の基準が「縦か横か」の1つだけなら、迷う時間は1秒未満です。基準を1つに絞り、選択方法は2つ持つのが、結果として速くなります。
Q. 1日15回までで、両方の使い分けを練習できますか？
A. 練習は種類を絞るほうが定着します。まず3日間は「ログは矩形、エラー文は行選択」だけを守ってください。回数が限られているぶん、1回ごとに「今どちらを選んだか」を意識するようになり、判定が反射になります。回数を増やすより、判定の回数を減らすほうが早く身につきます。
選択の向きを合わせるだけで、訳文は静かになる
矩形選択と行選択のどちらが優れているか、という問いには意味がありません。意味があるのは、訳したい情報がどちら向きに並んでいるかです。縦に揃ったログは矩形で列を抜き、横に連なる説明文は行選択で文の切れ目まで囲む。この2つを、判定基準ひとつで切り替えられるようにします。
今日の作業でログを1つ翻訳するとき、行番号の列を外して ⌃S で囲んでみてください。訳文から行番号が消えて、関数名とメッセージだけが残る。その静かさが、選択の向きを合わせる意味を教えてくれます。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh