💡 この記事の3行まとめ

  1. 「神ツール」という評価は、どの工程を消してくれるのかが言語化されていないと、自分の環境では再現しません。
  2. 拡張機能と画面OCRのアプリは守備範囲が違うので、同じ英文で2通り試し、1週間後に「戻した回数」で判定します。
  3. 『Zipp』は ⌃S で囲んで 0.3秒、Apple Visionの端末内処理。無料でダウンロード（登録不要）、1日15回まで試せます。

📌 この記事の対象読者

  • 「オンデバイスで速い」という評判を見て、VS Codeに入れるか迷っている方
  • 翻訳拡張をいくつか試して、どれもしっくりこなかった方
  • ツールの評価を、感想ではなく構造として理解したいエンジニア

「神ツール」と言われても、自分の環境で神になるとは限らない

VS Codeの翻訳ツールの評判を読むと、「入れた瞬間に作業が変わった」「もう戻れない」といった強い言葉が並びます。しかし、それを自分の環境で試すと、同じようには感じられないことがよくあります。理由は単純で、評価した人が消した工程と、自分が消したい工程が違うからです。

たとえば、ある人はエディタ内のコメントを読むために翻訳拡張を入れ、選択したテキストがその場で訳されることに感動しています。別の人は、統合ターミナルに出るビルドエラーの英語を読むために、同じ拡張を入れています。前者は拡張で完結しますが、後者は選択が難しく、拡張の守備範囲の外にいることがあります。同じ製品名でも、評価している対象が違うのです。

「神ツール」という言葉には、もうひとつ副作用があります。評価が極端になるぶん、合わない部分が見えなくなることです。合わない点を挙げると「使い方が悪い」と言われそうで、自分の環境の違和感を後回しにしてしまう。結果として、なんとなく使わなくなり、理由も分からないまま元のやり方に戻ります。

さらに、オンデバイスという言葉にも幅があります。端末内で処理するといっても、モデルを同梱して常駐するもの、OSのフレームワークに処理を委ねるもの、そもそも処理の場所を明示していないものがあります。何が端末内なのかを確認しないと、「オンデバイスだから安全で速い」という短絡が起きます。

ここで必要なのは、賛否を集めることではなく、この道具はどの工程を代替しているのかを1行で言えるようにすることです。それが言えれば、自分の環境で再現するかどうかを、短い試行で判定できます。

解決策：代替している工程を言語化し、守備範囲で比べる

手順1：消したい工程を1つに決める

翻訳の作業を、次の4つの工程に分解します。

  1. 選択（読みたい英文を範囲として切り出す）
  2. 送信（翻訳エンジンに渡す。コピーやタブ移動を含む）
  3. 待機（結果が返るのを待つ）
  4. 復帰（元の画面に戻り、どの行だったかを探し直す）

このうち、いま自分が最も苦痛に感じている工程を1つ選びます。エディタのコメントを読むなら「送信」、統合ターミナルのエラーなら「選択」と「復帰」、長いログなら「待機」が候補になります。

選んだ工程によって、評価すべき対象が変わります。「復帰」が苦痛なら、訳が別ウィンドウで開く道具は評価が下がります。逆に「選択」が苦痛なら、選択を必要としない経路が高く評価されます。工程を先に決めると、比較の軸がぶれなくなります。

手順2：同じ英文を、2つの経路で読む

次に、実際に比較します。題材は1つで構いません。エディタに表示した英語のエラーメッセージ1つと、統合ターミナルの英語出力1画面を用意します。

経路Aは翻訳拡張です。テキストを選択し、コマンドを実行して訳を出します。経路Bは画面OCRで、⌃S（Control + S） を押して読みたい範囲を矩形でドラッグします。囲み終えると 0.3秒 で訳が最前面に表示され、原文は隠れません。

比べる観点は3つだけです。選択に何秒かかったか、訳が出るまでに画面を何回移動したか、訳を見たあと元の行に戻れたか。この3つは、手順1で選んだ工程に直結します。

ここで見えてくる違いは、優劣ではなく守備範囲の違いです。拡張はエディタの中のテキストに強く、ファイルの内容を文脈として扱えます。一方、統合ターミナル、出力パネル、OSのダイアログ、VS Codeの外のウィンドウは、拡張の届きにくい領域です。画面OCRはその逆で、アプリを問わず見えている範囲を読める代わりに、ファイルの文脈は持ちません。

つまり、どちらか一方が「神」なのではなく、自分の作業時間のうち、どちらの守備範囲が広いかが答えになります。VS Codeの中で完結する作業が多い人は拡張が合い、ターミナルや他アプリを行き来する人は画面OCRが合います。

手順3：1週間後に「戻した回数」を数える

最後に、判定の基準を決めます。使うのは満足度ではなく、別のやり方に戻った回数です。

1週間のあいだ、翻訳のたびに「いつものやり方に戻ったか」を数えます。戻った回数がゼロに近ければ、その経路は定着しています。半分以上戻ったなら、守備範囲が合っていません。この数字は、使っていくうちに無意識に上がる満足度より正直です。

戻る回数が多い場合、原因はたいてい2つです。キーの取り合い（他のショートカットと衝突して押せない）か、範囲の取りにくさ（拡大率やフォントで囲みにくい）です。前者はキーを変えるか、使う場面を限定することで解消できます。後者は文字サイズを一時的に上げる、囲む範囲を1行に絞るといった調整で改善します。

戻る回数が減らないなら、その道具は自分には不要です。それを結論として受け入れることも、見極めのうちです。

拡張機能と画面OCRの守備範囲

【エディタ内の英文】
従来：選択してコマンド実行。文脈も扱える
Zipp：見えている範囲をそのまま囲める

【統合ターミナル・出力パネル】
従来：選択が難しく、守備範囲外になりやすい
Zipp：アプリを問わず、描画された文字を読む

【OSのダイアログや他アプリ】
従来：基本的に対象外
Zipp：画面上なら同じ操作で読める

【常駐とリソース】
従来：拡張とモデルが常駐し、環境に影響しうる
Zipp：拡張を追加しないため、VS Code側は無変更

【キーの取り合い】
従来：拡張ごとにショートカットを占有する
Zipp：⌃S の1つに集約でき、競合を管理しやすい

【試しやすさ】
従来：拡張の導入と設定が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで

よくある質問（FAQ）

Q. 結局、拡張とどちらが優れているのですか？ A. 優劣ではなく守備範囲の違いです。VS Code内のテキストを文脈ごと扱いたいなら拡張、ターミナルや他アプリを含めて広く読みたいなら画面OCRが向いています。両方を場面で使い分けるのも現実的です。

Q. 「オンデバイス」かどうかは、どう確認すればいいですか？ A. 処理が端末内で完結するか、外部のエンジンに問い合わせるかを、設定や説明から確認します。確認できないものは、確認できるまで保留するのが安全です。

Q. 0.3秒という速さは、体感できますか？ A. 囲んだ直後に訳が出るため、待ち時間を意識する場面が減ります。ただし効果を感じるのは速さそのものより、画面移動がなくなることによる中断の減少です。

Q. 1週間も試す余裕がありません。 A. 短縮するなら、同じ英文を2つの経路で読む1回の試行だけでも傾向は見えます。判定は「戻りたくなったか」で構いません。戻りたい理由が守備範囲のずれなら、長く試しても変わらないことが多いです。

見極めは、評価ではなく構造の理解から始まる

「神ツール」という言葉は便利ですが、そのまま受け取ると、自分の環境で再現しない理由が分からなくなります。必要なのは、その道具が選択・送信・待機・復帰のどこを消しているのかを知ること。そして、拡張と画面OCRでは守備範囲が違うと理解することです。

同じ英文を2つの経路で読み、1週間で戻った回数を数える。この2つだけで、評判に振り回されずに自分の答えを出せます。まずは統合ターミナルのエラー1画面を ⌃S で囲むところから試してみてください。拡張が届かなかった場所が読めるかどうかが、最初の判断材料になります。

▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh