💡 この記事の3行まとめ
- Stack Overflow の質問文には、社内のコード断片・設定値・ホスト名がそのまま載っていることが多く、翻訳サイトへの貼り付けは実質「外部送信」です。
- 送らない方法は難しくなく、読む範囲を決める → 端末内で処理する → 残すのは判断だけにするの3手順で足ります。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Vision による端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回まで使えます。
📌 この記事の対象読者
- 業務で扱っているコードや設定を含む質問を Stack Overflow で読むことがある方
- 翻訳サイトに貼ってよい情報かどうか、毎回少し迷っている方
- 社内規程や NDA の都合で、外部サービスへの入力を控えたい環境で働いている方
「貼ってから、これは出してよかったのか」と考える順番になっている
Stack Overflow の質問を読んでいるとき、私たちはほぼ無意識に英文を選択してコピーし、翻訳サイトのタブに貼ります。貼ってから訳文を読み、そこで初めて「このコードは社内のものだった」と気づく。順番が逆なのです。
問題は、その順番のせいで判断のタイミングがなくなることです。コピーの時点では、まだ内容を読んでいません。読んでいないものを送ってしまう。これは注意力の問題ではなく、手順そのものが判断を後回しにする構造になっているということです。
Stack Overflow の質問には、性質の異なる情報が混ざっています。エラーメッセージ、再現手順、そして最小再現コードです。この最小再現コードは、質問者が自分の環境から切り出した断片です。切り出したつもりの断片に、社内のパッケージ名、社内向けのホスト名、.env から写したキー名、顧客名を含むテストデータが残っていることがあります。公開されている質問だから安全、と短絡できないのは、回答を読みたいのは自分で、読む対象には自分の環境の情報が混ざりうるからです。
もう一つの詰まりは、翻訳サイトに貼った文字列がその後どう扱われるかを、利用者が正確に把握していないことです。多くのサービスは改善のために入力を保存しうると規約に書いています。規約を読んで判断するのが正しい態度ではありますが、質問を読むたびに規約を確認する人はいません。毎回判断が必要な手順は、いずれ判断されなくなる。だから、判断を手順の外に出さない形に作り替えるほうが現実的です。
さらに実務的な問題として、貼る行為は文脈を壊します。コードブロックを翻訳サイトに貼ると、インデントが潰れ、記号が全角に化け、変数名が訳されることがあります。訳文を読んでも、元のコードのどこを指しているのか分からない。結局もう一度原文に戻ることになり、往復が増えます。外部に出さない読み方に変えると、この往復も同時に減ります。
解決策：送らない読み方に切り替える3手順
手順1：囲む前に「これは自分の環境の文字列か」を線引きする
翻訳する前に、画面のどこが自分の環境由来かを一度だけ確認します。判断は3秒で足ります。
- 自分の環境の文字列：社内パッケージ名、社内ホスト名、顧客名、APIキーの断片、社内パスの一部。これは訳す必要がありません。
- 公開情報の文字列：エラーメッセージ、標準ライブラリの関数名、公式ドキュメント由来の用語。これは訳して構いません。
- 判断がつかない文字列：訳さずに原文のまま読むか、その部分だけ囲みから外します。
この線引きの面白いところは、訳さないと決めた範囲が、そのまま安全な範囲になることです。翻訳の質を上げる話ではなく、翻訳に渡す面積を減らす話です。線を引く癖が付くと、コピーの前に手が止まるようになります。
手順2：画面から直接、端末内の処理で訳す
次に、コピー＆貼り付けを使わず、画面に表示されている状態のまま訳します。⌃S（Control + S） を押し、訳したい範囲をドラッグして囲むだけです。
Zipp は Apple Vision フレームワークを使い、画像の認識と翻訳を端末内で完結させます。スクリーンショットを外部のサーバーに送らないため、囲んだ範囲の文字列が外に出る経路がありません。画面画像の外部保存ゼロというのは、この経路の話です。
囲んだ結果は 0.3秒 で最前面に表示され、原文の上に重なる形で出ます。原文が消えないので、訳文と原文を同じ画面で見比べられます。手順1で「訳さない」と決めた識別子は、訳文に混ざらず原文のまま残ります。これが、貼って翻訳するやり方との一番大きな違いです。
手順3：残すのは訳文ではなく「判断」だけにする
訳文を読んだあと、私たちが本当に必要としているのは日本語の文章ではなく、次の一手です。「この回答は自分の環境に当てはまるか」「この設定はビルド構成のどこに対応するか」といった判断です。
そこで、訳文をコピーして残すのをやめ、判断だけをメモにします。「回答の2番目の手順は bundler の設定なので、自社の monorepo では使えない」といった一行です。原文の英文を残さない、というのも同じ理由です。残した英文が後で別の場所に貼られると、手順1の線引きが無かったことになります。
この3手順は、慣れると1回の読解で十数秒です。回数にすると、1日15回までという範囲でも、読むべき質問を絞る訓練になります。全部を訳すのではなく、判断に必要な部分だけを訳す。制約があるほうが、範囲を選ぶ目が育ちます。
外部に出す／出さないを比べる
【文字列の渡し方】
従来：クリップボード経由で外部サービスへ送る
Zipp：画面を囲むだけで、端末内の処理に閉じる
【外部送信の有無】
従来：サービスの保存方針に依存する
Zipp：画面画像の外部保存ゼロ（Apple Vision による端末内処理）
【社内規程との相性】
従来：貼るたびに可否の判断が必要になる
Zipp：送らない前提なので、判断の回数が減る
【コードの崩れ】
従来：インデントや記号が変換されることがある
Zipp：原文が隠れず、訳文と並べて確認できる
【手数】
従来：選択・コピー・タブ移動・貼り付け・戻る
Zipp：⌃S とドラッグのみ
【試しやすさ】
従来：サービスごとに利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 公開されている質問を読むだけなら、外部に送っても問題ないのでは？ A. 質問文そのものは公開情報ですが、あなたが読む動機や、同時に開いている画面の情報は公開情報ではありません。また、質問に含まれるコード断片が自分の環境のものと一致しているとは限りません。送らない経路を既定にしておくと、判断を毎回しなくて済みます。
Q. 端末内処理なら、翻訳の精度は落ちませんか？ A. 用途による部分はありますが、技術文書の読解では十分に実用的です。むしろ、訳文と原文を同時に見られるため、訳語の違和感に気づきやすくなります。精度だけでなく、確認しやすさを含めて評価するほうが実際の速度に合います。
Q. 1日15回で足りないときはどうすればいいですか？ A. まず囲む範囲を見直してください。画面全体を囲むと1回で消費する情報量が増え、読む側の負担も増えます。質問文の要点と回答の該当箇所に絞れば、同じ15回でも読める質問数は増えます。
Q. 社内規程でツールの利用自体が制限されている場合は？ A. その場合は規程が優先です。本記事の手順は、規程で認められた範囲のなかで「送る量を減らす」考え方として読んでください。判断に迷う場合は、規程の管理者に確認するのが確実です。
送らない読み方は、判断の順番を前に戻す
翻訳サイトに貼る行為は、便利さの代わりに判断を後回しにします。読む前に送り、送ってから考える。この順番を、読む前に線を引き、送らずに訳し、判断だけを残す順番に戻す。それだけで、外部に出る情報は減り、読解の往復も減ります。
今日読む質問をひとつ選び、コピーの代わりに ⌃S で囲んでみてください。訳文の下に原文が残っていることを確かめられたら、その読み方が次回の既定になります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh
`