💡 この記事の3行まとめ
- VS Codeの翻訳で外に出るのは、訳したい英文だけではありません。ファイルパス・コード断片・統合ターミナルのログ・拡張のテレメトリが別々の経路で送られます。
- 送信面を3か所に絞って棚卸しし、翻訳の経路を画面のOCR側へ寄せると、コードを一切送らずに読めます。
- 『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回までです。
📌 この記事の対象読者
- 個人開発でも、顧客や勤務先のコードをローカルで触ることがある方
- 翻訳拡張を入れたいが、何が外部に送られるか分からず踏み切れない方
- エラーログにホスト名やトークンらしき文字列が出る環境で作業している方
VS Codeは「1つの画面」だが、送信経路は1つではない
VS Codeの便利さは、エディタ・統合ターミナル・出力パネル・問題パネル・拡張機能が1つのウィンドウに同居している点にあります。英語を読む場面もこの中に散らばっています。スタックトレース、npm の警告、リンタの指摘、拡張の設定エラー。どれも英語で、どれも読むのに時間がかかります。
ここで翻訳拡張を入れると、何が起きるでしょうか。翻訳の対象になるのは、多くの場合選択したテキストです。つまり、訳したい英文を拡張に渡す必要があります。一般に、翻訳拡張はそのテキストを翻訳エンジンへ送り、結果を受け取る設計になっています。エンジンがクラウドにあれば、テキストは端末の外に出ます。ローカルモデルを同梱した拡張なら送信されませんが、その場合はモデルの分だけディスクとメモリを使います。どちらの設計かを、利用者が確認しないと分からないのが最初の落とし穴です。
2つ目の経路はテレメトリです。VS Code本体にも拡張機能にも、利用状況の送信設定があります。設定画面で無効にできますが、初期状態や拡張ごとの扱いはさまざまです。翻訳した内容そのものではなくても、どの拡張がいつ動いたかという情報は送信対象になり得ます。
3つ目はコンテキストの同梱です。AI補完やチャット系の拡張は、訳すためではなく推論のために、開いているファイルや周辺コードを送ることがあります。翻訳拡張と補完拡張が同じワークスペースで動いていると、翻訳のつもりが別の経路でコードが出ていくことがあります。
問題は、これらが「見えない」ことです。送信はバックグラウンドで起き、失敗しても通知されません。だから「たぶん大丈夫」で運用が始まり、後から設定を確認して冷や汗をかく。個人開発でも、受託案件のコードや、顧客のログを貼った画面を扱うなら、この確認は他人事ではありません。
解決策：送信面を棚卸しし、翻訳を画面側へ寄せる
手順1：送信面を3か所だけ書き出す
まず、ワークスペースで動いているものを3つの欄に分けて書き出します。
- 翻訳系：翻訳拡張、翻訳コマンド、クリップボード監視ツール
- 補完・チャット系：開いているファイルを参照する拡張
- 本体設定：テレメトリの設定、Workspace Trust（信頼済みかどうか）
書き出すときに見るのは「設定で送信先が確認できるか」の一点です。送信先も無効化の手段も見当たらない拡張は、使わないという選択肢が現実的です。逆に、ローカル処理であることや無効化の方法が明記されているものは、そのまま残せます。この棚卸しは5分で終わります。終わらない場合は、入っている拡張が多すぎる合図です。
あわせて、統合ターミナルのログに何が出ているかを一度確認してください。接続文字列、ホスト名、社内のパス。翻訳したい英文のすぐ隣に、出したくない文字列が並んでいることがよくあります。翻訳の対象と、出したくない情報は、同じ画面に同居しています。
手順2：翻訳の経路を「画面のOCR」に寄せる
次に、翻訳の入口を変えます。テキストを選択して拡張に渡すのではなく、画面に描画された結果をOCRで読む経路にします。
やり方は、⌃S（Control + S）を押して、読みたい範囲を矩形でドラッグするだけです。文字を選択しないため、統合ターミナルのように選択が難しい画面でも同じ操作で済みます。囲み終えると 0.3秒 で訳が最前面に表示され、元の画面は隠れません。処理はApple Visionによる端末内処理で、画面画像の外部保存ゼロです。
この経路に変えると、送信されるデータの量が根本的に変わります。拡張に渡すのはテキストではなく、画面の見えている範囲だけです。しかも端末の外に出ません。翻訳のためにコードをコピーする必要がなくなるという点が、設定を並べるより大きな違いになります。
手順3：「何を囲んだか」だけを記録する
最後に、運用の記録を残します。送信ログの代わりに、囲んだ範囲と時刻をメモするのです。1行で構いません。「14:20 統合ターミナルのビルドエラー3行」といった具合です。
このメモには2つの効果があります。1つは、後から「あの英文は何だったか」を辿れること。もう1つは、囲んだ範囲に機密が入っていないかを後から検証できることです。OCRは画面を読むので、範囲の取り方がそのまま情報の取り方になります。記録が残っていれば、範囲の選び方の癖も見えます。
加えて、範囲を囲む前に「この画面にトークンは出ていないか」を一瞬確認する習慣を入れてください。端末内処理でも、訳文をスクリーンショットで共有したり、訳をそのままチャットに貼ったりすれば、そこで外に出ます。経路を閉じる作業と、出口を意識する習慣はセットです。
送信面の比較
【送信される内容】
従来：選択したコード断片、パス、拡張の利用情報
Zipp：画面の見えている範囲のみ。端末の外に出ない
【送信の確認方法】
従来：拡張ごとに設定と実装を調べる必要がある
Zipp：経路が1本なので、確認する対象が少ない
【統合ターミナルのログ】
従来：選択が難しく、コピーで余計な行まで運びがち
Zipp：見えている範囲を矩形で囲める
【オフライン時】
従来：クラウド翻訳は応答が返らない
Zipp：端末内処理のため、回線に依存しない
【ワークスペースへの影響】
従来：常駐プロセスとモデル分のリソースを使う
Zipp：拡張を追加しないため、環境が変わらない
【試しやすさ】
従来：拡張の導入と設定変更が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 端末内処理なら、何を囲んでも安全ですか？ A. 処理が端末内で完結するのは事実ですが、訳文を共有・投稿すればそこで外に出ます。囲む範囲を絞り、訳文の扱いを別に決めておくことが前提です。処理経路と情報の出口は、分けて考える必要があります。
Q. テレメトリを切れば、拡張の送信も止まりますか？ A. いいえ。本体のテレメトリ設定と、各拡張が独自に行う通信は別物です。拡張ごとに設定を確認するか、送信の有無が分からない拡張を外すかのどちらかになります。
Q. 翻訳拡張のほうが精度が高いのでは？ A. 長い文章の言い回しは、クラウドの翻訳エンジンが有利な場面があります。一方で、コードとログの読解に必要なのは自然な日本語より用語の同定です。何を優先するかで選択は変わります。
Q. 1日15回で、開発作業は回りますか？ A. 詰まったときだけ囲む運用なら、通常の日は足ります。詰まりが連続する日は、囲む範囲を「エラーの1文」に絞ると回数が減り、判断も速くなります。
外に出さない運用は、入口を1本にすると決まる
VS Codeの翻訳で怖いのは、訳文の質ではありません。どこから何が出ているか分からないまま、便利さを優先してしまうことです。翻訳拡張、テレメトリ、補完拡張。経路が増えるほど、確認すべき対象も増えます。
だから発想を変えます。翻訳の入口を画面のOCRに一本化し、コードを選択して渡す工程をなくす。⌃S で必要な数行を囲み、0.3秒で出た訳で判断する。そのうえで、囲んだ範囲を1行メモに残す。この流れなら、個人開発のコードも、預かったログも、端末の外に出さずに読めます。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh