💡 この記事の3行まとめ
- 「ローカルOCR認識」が必要になるのは、翻訳を速くしたいときではなく、ネットワークが存在しない・使ってはいけない環境のときです。
- 経路を潰す発想ではなく、最初から経路がない前提でIssueを読む順番を組み立てると、閉域でも読解は止まりません。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回まで試せます。
📌 この記事の対象読者
- 社内規定や取引先のNDAで、Issueの本文を外部サービスに一切通せない方
- 出張先・客先・検証室など、ネットワークが繋がらない場所でリポジトリを読むことがある方
- プロキシもDNSも通らない閉域環境で、
gitとGitHubの英語に毎回つまずいているエンジニア
閉域環境で詰まるのは、翻訳の精度ではなく「経路の有無」
ふだん私たちは、英語のIssueを読むときに無意識にネットワークを使っています。翻訳サイトを開く、ブラウザの拡張機能を呼ぶ、クラウドの翻訳APIに投げる。どれも当たり前に動いていたので、経路そのものを意識していません。ところが閉域環境に入った瞬間、この当たり前が全部止まります。プロキシが通らない、DNSが引けない、そもそもWi-Fiが繋がっていない。翻訳の質を上げる以前に、翻訳にたどり着けない状態です。
ここで起きるのが、「読まない」という選択です。英語のIssueを開き、タイトルだけ見て、ラベルを見て、本文はスクロールして閉じる。読めないのではなく、読む手段がないから飛ばす。この判断は合理的に見えますが、実際には大きなコストを生みます。再現手順を取り違えて無関係な修正を試したり、すでに書かれている回避策を見落として同じ調査をやり直したり、メンテナの意図と違う方向に手を入れてレビューで差し戻されたりします。Issueを読まない節約は、後工程で3倍になって戻ってきます。
閉域環境でのもうひとつの落とし穴は、「コピーして持ち出す」が禁止されていることです。ネットが無いから別の端末に移す、という発想も封じられます。USBメモリも、クリップボード同期も、スクリーンショットの共有も、ポリシーで塞がれていることが多い。つまり、Issueが表示されているその画面の中で完結させるしかないという条件が課されます。
この条件は厳しく見えますが、実は読解の設計を単純にします。選択肢が「画面のまま読む」しかないなら、その一手を磨けばいい。問題は、その一手のための道具を、ネットワークに依存しないものに変える必要がある、という点だけです。閉域対応とは、特別な回避策を足すことではなく、道具の依存先を外へ出さないことです。
解決策：閉域で完結する読解の3手順
手順1：Issueを「画面に描画された状態」に固定する
まず、読む対象を画面に固定します。これは当たり前に見えて、閉域では重要な工程です。クラウドの翻訳拡張を入れた状態でページを開くと、拡張が外部に問い合わせようとして待ち、レイアウトが崩れたり、本文が一瞬空になったりします。閉域では、外部に問い合わせる仕組みを画面から外しておくほうが安定します。
具体的には、Issueのページを開いたまま、本文とコメントを表示させ、必要ならブラウザの拡大率を上げて文字を大きくします。狙うのは、判定に使う行がスクロールなしで1画面に収まる状態を作ることです。閉域では、ページの再読み込みすら失敗することがあるので、一度表示できた画面は貴重です。表示できた時点で、その画面が作業台になります。
手順2：翻訳を端末内処理に閉じる
次に、翻訳そのものを端末の中で完結させます。⌃S（Control + S） を押し、訳したい範囲をドラッグして囲みます。囲み終えると 0.3秒 で訳が最前面に表示されます。処理はApple Visionによる端末内処理で、画面画像の外部保存ゼロです。ネットワークの有無に関係なく動きます。
ここが「経路を潰す」という発想との分かれ目です。経路を潰すのは、送らないように設定する作業であり、設定が漏れれば送られます。端末内処理は、送る経路が最初から存在しないので、確認すべき設定がありません。閉域環境では、この違いが運用の差になります。監査で「どこに送られますか」と聞かれたときに答えるのは、設定の説明ではなく、仕組みの説明です。
手順3：Issueの構造を単位にして囲む
3つ目は、囲む単位をIssueの構造に合わせることです。Issueの本文は、自由文ではなく型を持っています。タイトル、環境、再現手順、期待する動作、実際の動作、補足。この5〜6のブロックは、それぞれ独立して意味を持ちます。
そこで、ブロックを1つずつ囲むようにします。再現手順のブロックだけを囲めば、手順の番号とコマンドが一度に訳されます。期待値と実測値のブロックを囲めば、差分がどこにあるかが訳文で見えます。全文をまとめて囲むと、環境情報と推測と愚痴が混ざり、訳文が長くなるだけで判断は速くなりません。
閉域では、この「ブロック単位」が特に効きます。ネットが使えない状況では、用語を調べ直すこともできないからです。訳文の中に知らない語が出てきたら、その語を含むブロックだけを囲み直す。同じ画面の中で、必要な粒度に何度でも切り直せることが、閉域での読解力を決めます。
閉域環境での読み方を比べる
【ネット接続の要否】
従来：必須。閉域では動作しない
Zipp：不要。端末内で完結する
【データの行き先】
従来：外部サービスへ送られる
Zipp：画面画像の外部保存ゼロ
【閉域での可否】
従来：経路が無いため利用できない
Zipp：経路が無くても同じ手順で読める
【囲む単位】
従来：全文をまとめて貼りがち
Zipp：Issueのブロック単位で切り直せる
【原文の可視性】
従来：別画面へ移動し、原文が見えない
Zipp：訳が重なるだけで原文は隠れない
【試しやすさ】
従来：契約と通信環境の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 端末内処理なら、閉域でも初回だけ通信が必要ではありませんか？ A. 翻訳の処理そのものは端末内で完結するため、通信を前提にしていません。ただしアプリの入手自体はネットワークが必要です。閉域に入る前にダウンロードしておく、という順序になります。無料でダウンロード（登録不要）なので、検証用の端末にも入れておけます。
Q. Issueの本文をスクリーンショットで持ち出すのも禁止されています。 A. その場合でも、画面に表示して ⌃S で囲む操作は、ファイルを作らずクリップボードも経由しません。持ち出しではなく、その場で読む行為です。ポリシーの解釈は組織ごとに異なるので、判断に迷う場合は情報システム部門に「画面表示のみで外部送信しない読み方」として確認してください。
Q. 閉域だと用語を検索できないので、訳語の確認ができません。 A. 閉域での読解は、正しい訳語を確定させることより、判断に必要な情報を取り出すことが目的になります。訳語が不確かな語は、原文のまま残して読み進め、ブロックの意味が通るかを優先してください。ネットが戻ったときに確認すれば十分です。
Q. 1日15回で、閉域作業は足りますか？ A. ブロック単位で囲めば、1つのIssueは3〜5回で読み切れます。むしろ回数が限られていることで「全文を訳す」癖が抜け、必要なブロックだけを囲む習慣が付きます。閉域作業のように1画面を長く見る場面では、この習慣がそのまま速度になります。
閉域で強くなるのは、外に頼らない読み方
ネットが使えない、送ってはいけない。その条件は、翻訳を諦める理由にはなりません。Issueを画面に固定し、翻訳を端末内に閉じ、ブロック単位で囲み直す。この3つを決めておけば、閉域でも英語のIssueは読めます。そして副産物として、ネットがある環境でも同じ手順が速く動きます。外に頼らない読み方は、環境を選ばない読み方でもあるからです。
次の閉域作業の前に、Issueを1つ開いて、再現手順のブロックだけを ⌃S で囲んでみてください。全文を訳さなくても判断できることを確かめる。その一度が、環境の制約を読解の設計に変える最初のステップになります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh