💡 この記事の3行まとめ
- Issue のスクリーンショットには、顧客名・社内URL・顧客IDが写り込んでいることが多く、翻訳のために画像をアップロードすると写り込みごと端末の外に出ます。
- 導入は「送信経路を3種類に仕分ける → 機内モードで検証する → チームの運用に1行足す」の順で進めると、止まらずに定着します。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionの端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回まで。
📌 この記事の対象読者
- 海外ユーザーや海外チームの Issue を、スクリーンショット経由で読んでいる方
- 翻訳のために画像をアップロードする行為が、社内ルールに触れないか気になっている方
- 情報管理の担当として、開発チームに翻訳の運用を提案したい方
スクリーンショットを翻訳に渡すとき、何が一緒に渡っているか
GitHub の Issue には、英語の説明と一緒にスクリーンショットが添付されます。UI の不具合報告なら画面全体、エラーの報告ならログの一部。この画像を翻訳サービスに渡して読む、という運用は珍しくありません。画像をそのまま翻訳サイトに投げる、あるいは画像から文字をコピーして貼る。どちらも手軽ですが、渡しているのは文字だけではありません。
画面全体のスクリーンショットには、次のようなものが写り込みます。ブラウザのタブに出る社内ツール名。アドレスバーのクエリに残る顧客ID。右側のパネルに並ぶ担当者名。デバッグ用に開いたままの別ウィンドウ。報告者にとっては「不具合の証拠」でも、読み手にとっては文脈ごと持ち出した情報です。
ここで起きやすいのが、判断の先送りです。「文字だけだから大丈夫だろう」と感じる一方で、社内ルールを確認すると画像の外部送信は禁止と書いてある。確認しないまま使い続けるか、使うのをやめて読めないままにするか。この二択になってしまうのが、いちばん良くない状態です。
実は、この問題は翻訳の精度とは無関係です。どれだけ訳文が自然でも、経路が外部送信なら同じ問題が残ります。逆に言えば、経路を先に決めてしまえば、そのあとの翻訳の質は二の次の話になります。導入でつまずくのは、機能の比較を先に始めてしまうからです。
解決策：経路の仕分けから始める3手順
手順1：送信経路を3種類に仕分ける
まず、いま使っている翻訳の経路を、次の3つに分類します。
- 経路A・画像アップロード型：スクリーンショットをそのままサービスに預ける。手軽だが、写り込みも一緒に渡る。
- 経路B・クリップボード型：画像から文字を選んでコピーし、貼り付ける。文字だけに見えるが、コピーした範囲は端末の外に出る。
- 経路C・端末内処理型：画面から文字を読み取り、翻訳までを端末内で完結させる。画像も文字も外に出ない。
分類してみると、経路AとBは「何を渡すか」が違うだけで、渡すという行為は同じだと分かります。この2つをまとめて「外部に渡す経路」と呼び、経路Cだけを別枠に置くと、判断が単純になります。棚卸しの目的は、禁止することではなく、自分がどの経路に立っているかを知ることです。
手順2：機内モードで、本当に端末内で完結するかを検証する
次に、経路Cが本当に端末内で完結するかを自分で確かめます。方法は単純で、Mac のネットワークを切って（機内モード、または Wi-Fi オフ）同じ操作をします。回線がなくても訳が出るなら、その処理は端末内で完結しています。
検証するときは、実際の Issue のスクリーンショットを使ってください。サンプル画像では、写り込みの有無も、読み取りの精度も分かりません。⌃S（Control + S）を押して、Issue の英文部分をドラッグで囲みます。0.3秒で訳が最前面に出て、原文の画面はそのまま残ります。ネットワークを切った状態で同じ結果が出れば、経路Cの検証は完了です。
この検証には副産物があります。回線が不安定な場所でも読めるという事実です。出張先、移動中、社内ネットワークの制限された環境。画面画像の外部保存ゼロの運用は、情報管理のためだけのものではありません。
手順3：チームの運用に1行だけ足す
最後に、検証した内容をチームの運用に落とします。README や CONTRIBUTING に、次の1行を足すだけで十分です。
> Issue のスクリーンショットを翻訳するときは、画像を外部サービスにアップロードせず、端末内処理の手段を使う。
1行にする理由は、長いルールが読まれないからです。経路の分類や検証の詳細は、必要になったときに口頭か社内ドキュメントで共有すれば足ります。大事なのは、判断に迷ったときに戻ってくる1行があることです。
導入の順序も大事です。先にルールを決めてから道具を探すと、選択肢が絞られて動きやすくなります。逆に道具を先に決めると、ルールに合うかどうかの確認が後回しになり、結局使われなくなります。経路、検証、運用の順で進めてください。
スクリーンショットの扱いを比べる
【端末の外に出るもの】
従来：画像そのものと、写り込んだ社内情報
Zipp：画面画像の外部保存ゼロ。画像も文字も端末内で処理
【写り込みの管理】
従来：囲み直すか、マスクしてから撮り直す必要がある
Zipp：画面から読むため、撮り直しが要らない
【検証の方法】
従来：サービスの仕様を読んで判断するしかない
Zipp：機内モードで試せば、その場で確認できる
【原文の確認】
従来：訳文と画像を見比べるのに往復が要る
Zipp：原文が隠れず、同じ画面で照合できる
【チームへの展開】
従来：サービスごとに許可申請の検討が必要
Zipp：「アップロードしない」の1行で揃う
【試しやすさ】
従来：アカウントや利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 文字だけをコピーするなら、外部送信になりませんか？ A. なります。コピーした文字列を翻訳サービスに貼れば、その時点で端末の外に出ます。画像か文字かの違いであって、送るか送らないかの違いではありません。
Q. 機内モードで試すと、翻訳の精度が落ちるのでは？ A. 端末内で完結する処理では、回線の有無は結果に影響しません。もし回線を切ると結果が変わったなら、その処理は外部に問い合わせています。検証としては、それ自体が有用な発見です。
Q. チーム全員に同じツールを入れさせる必要がありますか？ A. 必要ありません。まず自分が経路Cで読み、ルールを1行足すところから始めてください。強制より、実際に読めている人の手順が共有されるほうが定着します。
Q. 1日15回で Issue の対応は足りますか？ A. Issue 1件あたり、囲むのは本文と再現手順で2〜3回程度です。回数より、アップロードしない経路を選ぶ習慣のほうが情報管理には効きます。
経路を決めれば、翻訳の話は後回しにできる
スクリーンショットを翻訳に渡すとき、私たちは「読むため」だけを考えています。しかし渡しているのは文字ではなく、写り込んだ文脈ごと画面です。この事実に気づくと、翻訳の精度を比べる前に、決めるべきことが見えてきます。
今日、直近の Issue を1つ開き、そのスクリーンショットに何が写っているかを確認してください。社内の名前、URL、ID。それが外に出ない経路はどれか。⌃S で囲んで、回線を切ったまま訳が出ることを一度確かめれば、導入の最初の一歩は終わります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh