💡 この記事の3行まとめ
- ローカルOCR認識は「すごいツールを入れること」ではなく、構成要素を減らすことで作れます。
- VS Codeは表示専用のまま、読み取りをOS側の処理に任せると、拡張ゼロ・常駐ゼロ・設定変更ゼロの構成になります。
- 『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionの端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回までです。
📌 この記事の対象読者
- 会社や学校の管理下にあり、VS Codeに拡張を追加できない方
- 拡張の更新で環境が壊れるのを避けたい方
- 回線が不安定な場所でも、同じ手順で英語を読みたいエンジニア
「ローカルOCR認識」は、ツールを足すことだと思われている
VS Codeで翻訳をローカルOCR認識にしたい、と相談すると、たいていは「ローカルモデルを動かす拡張を入れよう」という話になります。それは1つの答えですが、構成としては重くなります。モデルのダウンロード、常駐プロセス、メモリ消費、ときどき来る更新。ローカルOCR認識の目的が「外に出さないこと」なら、要素を増やすほど確認すべきことも増えるという矛盾を抱えます。
さらに、環境によっては拡張を入れられません。管理された端末ではマーケットプレイスからの導入が制限されていたり、入れる前に申請が必要だったりします。個人の端末でも、業務で使うワークスペースだけは拡張を絞っている、という運用は珍しくありません。入れられない、ではなく、入れないという設計を先に考える価値はここにあります。
拡張を入れない場合に残る課題は、英語をどう読むかです。エディタのコメント、統合ターミナルのビルドエラー、出力パネルの警告、launch.json の設定ミス。これらは拡張なしでも画面には表示されています。つまり読むための情報はすでに画面にあるのに、私たちは「翻訳するためにテキストを取り出す」という工程を無意識に足しています。
この工程を足さなければ、構成は驚くほど小さくなります。VS Codeは表示と編集に専念し、翻訳はOS側の機能に任せる。アプリを1つ入れるだけで、拡張もモデルも常駐プロセスも増えない。これが、拡張を入れないローカルOCR認識の姿です。
ただし、構成を減らすと別の課題が出ます。テキストを取り出さないということは、画面が読みやすい状態である必要があるということです。ここだけは、これまでと違う準備が要ります。
解決策：3層に分けて、画面を読ませる構成を作る
手順1：構成を3層に分ける
まず、役割を3つに分けて書き出します。
- 表示層：VS Code。編集と表示だけを担当し、拡張は追加しない。
- 読み取り層：OS側のOCR。画面に描画された文字を読む。
⌃S（Control + S） を押して範囲を矩形でドラッグするだけ。 - 確認層：原文。訳が最前面に出ても元の画面は隠れないため、識別子やパスは原文で確認する。
この3層に分けると、管理する対象がはっきりします。表示層は変更しない、読み取り層はアプリ1つ、確認層は習慣。VS Codeに拡張を追加しないという点が、この構成のいちばんの利点です。拡張を入れなければ、チームの他のメンバーと同じ環境を保ったまま、自分の読み方だけを変えられます。
処理はApple Visionによる端末内処理で、画面画像の外部保存ゼロ。囲んだ範囲は端末の外に出ません。回線が切れていても、直前まで画面に表示されていた内容は読めます。
手順2：OCRが読みやすい画面を、最小限だけ整える
次に、画面側を整えます。ここで目的は見た目を良くすることではなく、OCRが読み取りやすい状態にすることです。
具体的には4つだけです。エディタの文字サイズを上げる（拡大率でも可）、行の折り返しをオフにする（折り返された行は構造が崩れやすい）、統合ターミナルのパネルを固定する（出力が流れ続けると囲む瞬間を逃す）、背景と文字のコントラストを確保する（薄いグレーの注釈は読み取りにくくなります）。
これらは設定の変更ではありますが、翻訳のための設定ではなく、読みやすさのための設定です。他の作業にも良い影響が出るため、戻す必要が生じにくいのが特徴です。テーマを変える必要はありません。むしろ、コントラストが確保されていれば、暗いテーマのままで問題なく読めます。
整えたら、実際に1画面を囲んでみてください。囲んだ範囲に、読みたい英文と、その直前のコマンドやパスが入っているかを確認します。入っていなければ、囲み方の問題です。範囲を広げるのではなく、起点をずらすとうまくいきます。
手順3：オフラインで1回通し、記録を残す
最後に、回線を切って1回試します。Wi-Fiをオフにするか、機内モードにしてください。その状態で、エディタの英文と統合ターミナルの英文を1つずつ囲みます。
確認するのは2点です。訳が出るまでの時間が変わらないか、エラーや待機表示が出ないか。ここで待機が出るなら、その経路は外部に問い合わせています。端末内処理であれば、回線の状態で挙動は変わりません。
通しが終わったら、結果を1行で残します。「機内モードで エディタ1件・ターミナル1件、待機なし」といった具合です。この記録は、環境が変わったとき（OSのアップデート後、端末の入れ替え後）に同じ検証を繰り返す目印になります。ローカルOCR認識は状態ではなく、検証で維持する性質です。
なお、拡張を入れない構成でも、訳文をチャットやIssueに貼れば外に出ます。処理経路を閉じることと、訳文の扱いを決めることは別の作業です。社内のルールがある場合は、訳文の共有可否もあわせて確認しておいてください。
構成の比較
【導入するもの】
従来：拡張＋モデルファイル（数百MB規模になりうる）
Zipp：アプリ1つ。VS Code側は無変更
【VS Codeの設定】
従来：拡張の設定項目が増え、共有しづらくなる
Zipp：拡張の設定項目が増えない／共有設定はそのまま
【更新の影響】
従来：拡張の更新で挙動が変わることがある
Zipp：エディタ環境と切り離されている
【障害時の切り分け】
従来：拡張かモデルかエディタかの切り分けが必要
Zipp：表示と読み取りが分離され、原因を特定しやすい
【オフライン】
従来：モデルの読み込みに失敗することがある
Zipp：端末内処理のため、回線に依存しない
【試しやすさ】
従来：モデルの取得と設定に時間がかかる
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 拡張を入れないと、翻訳の精度は落ちますか？ A. 長文の言い回しは落ちる場面があります。一方、エラー文やログの読解は「どの種類の失敗か」を掴めれば足りるため、実務では大きな差になりにくい領域です。精度より経路の少なさを優先する判断が向いています。
Q. 管理端末でアプリのインストールも制限されています。 A. その場合は、まず何が許可されているかを確認してください。本記事の構成は「拡張を入れない」ことが主眼で、アプリの導入可否とは別の話です。許可の範囲内で経路を選ぶのが現実的です。
Q. 画面を読む方式だと、長いファイルの翻訳には向きませんか？ A. 向きません。長文は別の手段のほうが適しています。この構成が効くのは、その場で判断したい数行です。エラー、警告、設定の指摘といった短い英文が中心になります。
Q. 1日15回の範囲で、検証は足りますか？ A. 検証は数回で足ります。オフライン確認で2件、通常作業で数件。残りは実際の詰まりに使うのが、この構成に向いた配分です。
ローカルOCR認識は、足すより引いて作る
ローカルOCR認識という言葉から、大型のモデルを思い浮かべる人は少なくありません。しかし、外に出さないという目的に対して、要素を増やすことは必ずしも近道ではありません。拡張を入れず、モデルも置かず、VS Codeは表示のまま。読み取りだけをOS側に任せる。この引き算の構成で、⌃S から 0.3秒、端末内処理、画面画像の外部保存ゼロという状態が作れます。
まずは今日、回線を切って1画面を囲んでみてください。待機が出なければ、その構成はあなたの環境で成立しています。設定を増やさずに読める状態は、想像より静かで、想像より長く使えます。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh