💡 この記事の3行まとめ

  1. 「囲むだけ」で読めるのは、翻訳の前に囲む範囲を1つの意味の塊に決めるという工程があるからです。
  2. 押す → 囲む → 突き合わせる、の3ステップを毎回同じ順序で行うと、GitHubの英語は作業を止めずに読めます。
  3. Mac専用OCR翻訳『Zipp』は ⌃S で 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回までです。

📌 この記事の対象読者

  • ツールは入れてみたものの、実際の使い方がいまひとつ掴めていない方
  • 囲む範囲を毎回迷って、結局画面全体を選んでしまう方
  • GitHubのIssue・PR・READMEを、コピーも画面移動もせずに読みたいエンジニア

「囲むだけ」が上手くいかないのは、囲む前に決めることがあるから

⌃S を押して範囲を囲むだけ。説明としてはこれで終わります。ところが実際に使ってみると、うまくいかない人が少なくありません。理由ははっきりしています。囲む前の判断が抜けているからです。

GitHubの画面は、1つの意味の塊ではありません。Issueの本文には、見出し、説明文、番号付きの再現手順、コードブロック、環境情報のリスト、スクリーンショットが混ざっています。PRには、説明、レビューコメント、差分、チェック結果が並びます。この画面を丸ごと囲むと、訳文は長くなり、どこに何が書いてあるか分からなくなります。逆に1単語だけ囲むと、文脈が落ちて意味が取れません。

つまり「囲むだけ」の実力は、囲む範囲の決め方で決まります。範囲が決まっていれば、操作は2秒で終わり、訳は0.3秒で出ます。範囲が決まらなければ、迷う時間のほうが長くなります。この記事では、操作の手順と、範囲の決め方をセットで固定します。一度決めてしまえば、以後はGitHubのどのページでも同じ判断が使えます。

もうひとつ、使い始めにありがちな誤解を潰しておきます。翻訳は原文を置き換えるのではなく、原文の上に重なって表示されるだけです。下の英語は消えません。だから「訳が正しいかどうかを原文で確認する」という使い方ができ、これが実務では決定的に効きます。技術文書の翻訳は、用語が文脈で変わるため、訳だけを信じるより原文と並べるほうが安全です。

解決策：押す・囲む・突き合わせるの3ステップ

手順1：押す前に「1つの塊」を決める

⌃S を押す前に、囲む範囲を心の中で決めます。基準は1つの意味の塊です。GitHubで実際に使う塊は、次の4種類にほぼ集約されます。

  • 段落1つ … 説明文が続く部分。見出しの直後から次の見出しまで。
  • 手順ブロック … 1. 2. 3. で始まる番号付きリスト。番号ごと囲むと、手順の順序が訳文でも保たれます。
  • コードブロック1つ … バッククォートで囲まれた範囲。コマンドとエラーメッセージが入ります。
  • コメント1つ … 1人の発言のまとまり。途中で切ると、誰の発言か分からなくなります。

この4種類のどれかに当てはめてから押します。当てはまらない範囲は、たいてい囲む必要がありません。迷ったら塊を小さくするのが原則です。小さく囲めば、訳文が短く、判断が速くなります。

手順2：⌃S を押して、ドラッグして、離す

⌃S（Control + S） を押し、そのままマウスで範囲をドラッグします。指を離すと囲みが確定し、0.3秒 で訳が最前面に表示されます。操作はこれだけです。アプリを切り替える必要も、テキストをコピーする必要もありません。

慣れないうちに起きやすいのが、押す前にドラッグを始めてしまうことです。先に押す、次にドラッグする。この順序を体に入れてしまえば、意識せずにできるようになります。また、囲んだ結果が意図と違ったときは、もう一度 ⌃S からやり直せます。失敗しても原文は無傷なので、やり直しのコストはほぼゼロです。

手順3：出た訳を原文と突き合わせる

訳が出たら、訳文で意味を掴み、原文で固有名詞を確認します。役割を分けるのがコツです。

  • 訳文を見る対象：文の意味、条件（〜の場合）、否定（〜ではない）、原因と結果の関係。
  • 原文を見る対象：コマンド名、オプション、パス、ブランチ名、ファイル名、エラーの種類（fatal / error / warning）。

この分担にすると、OCRが多少読み違えていても判断を誤りません。訳文が「〜を削除してください」と言っていても、原文が git restore なら、実際の操作は削除ではありません。訳は方向、原文は固有名詞。この合言葉で読むと、GitHubの英語は作業を止めずに処理できます。

そして、確認が終わったら訳は閉じて次へ進みます。訳を開いたまま別のIssueを読むと、どの訳がどの原文に対応しているか分からなくなります。1塊につき1回、確認したら閉じる。このリズムが、結果として一番速くなります。

囲むだけの読み方を比べる

【操作の数】
従来：選択、コピー、画面移動、貼り付け、戻る
Zipp：押す、囲む、確認するの3つ

【範囲の決め方】
従来：その場で毎回考える
Zipp：段落・手順・コード・コメントの4種類から選ぶ

【原文の扱い】
従来：別画面に移り、原文が見えなくなる
Zipp：訳が重なるだけで原文は隠れない

【確認のしやすさ】
従来：訳だけを見て判断しがち
Zipp：訳で意味、原文で固有名詞を分けて確認できる

【アプリの切り替え】
従来：発生する
Zipp：発生しない

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

よくある質問（FAQ）

Q. 囲んだのに訳が出ないときは？ A. ドラッグの途中で指を離していないか、押す前にドラッグを始めていないかを確認してください。押す、ドラッグ、離す、の順序です。それでも出ない場合は、範囲が極端に小さいか、逆に画面全体に近い大きさになっていることがあります。塊を1つに絞って囲み直すと安定します。

Q. 画面全体を囲んだほうが、まとめて読めて楽では？ A. 最初は楽に感じますが、訳文が長くなり、どこが結論か分からなくなります。GitHubの画面は要素が多く、無関係なテキストも混ざります。塊を小さく囲むほうが、結果として読む量も翻訳の回数も減ります。

Q. コードブロックを囲むと、コマンドまで訳されて危険では？ A. 訳文は原文の上に重なるだけで、原文は残ります。実行するコマンドは必ず原文で確認してください。訳は「このブロックが何をするのか」を掴むために使い、コマンド文字列そのものは原文から写すのが安全です。

Q. 1日15回で足りないときは？ A. 塊を小さくするほど、1回で読める情報が濃くなります。逆に1回で画面全体を囲むと、情報密度が下がって回数だけ消費します。15回という上限は、囲む範囲を絞る練習台になります。まずは今日のIssueで、段落1つだけを囲んでみてください。

囲むという行為は、読む範囲を決める行為

⌃S を押して囲むだけ、という説明は正しいのですが、足りません。正しくは、読む範囲を決めてから囲む。段落、手順、コード、コメント。この4種類のどれかを選ぶだけで、囲む操作は2秒で終わり、訳は0.3秒で出ます。そして訳で意味を掴み、原文で固有名詞を確認する。この分担が身につくと、GitHubの英語は「読む対象」から「確認する対象」に変わります。

今日、Issueを1つ開いて、段落を1つだけ囲んでみてください。訳を閉じて、また別の段落を囲む。その往復が、コピーと画面移動を消した読み方の最初の一歩になります。

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