Read Frog（陪读蛙）を導入前に読む：WXT製ブラウザ拡張の仕組みとGPL-3.0の境界

Read Frogが埋める穴：翻訳と語学学習の分断

既存の翻訳拡張は、ページを読めるようにすることを目的にしている。読んだ語彙が定着するかどうかは利用者の自己管理に委ねられ、辞書を別タブで開くか、単語帳アプリに手で移すしかなかった。Read Frogはこの分断を、同じブラウザ画面の中で処理しようとする。READMEの説明では、没入型翻訳、記事分析、複数AIモデルへの対応を掲げ、対象は「language learners of all levels」とされている。想定読者は、英語や日本語の記事を読みながら語彙を拾いたい個人、あるいは中国語話者で英語学習をしている層だ。トピックに chinese、english、japanese、english-learning が並んでいることからも、言語ペアの重心がうかがえる。学習管理システムではなく、閲覧中のページをそのまま教材に変える道具である点が、他の翻訳拡張との出発点の違いになる。

WXTとTypeScriptで組まれた拡張の構造

リポジトリのメタデータでは、主要言語がTypeScript、トピックに wxt、react、browser-extension が含まれる。WXTはブラウザ拡張のビルドツールで、Manifest V3のエントリポイントやcontent scriptの注入を扱う。つまりRead Frogは、ページのDOMを書き換えて対訳ノードを差し込む処理をcontent script側で行い、設定画面やポップアップをReactで構成する形が読み取れる。翻訳対象の抽出、AIプロバイダへのリクエスト、結果のDOM反映という流れは、この構成から自然に導ける。READMEが挙げる機能のうち、Context-Aware Translationはページ全体の文脈をプロンプトに含める設計を示唆し、Batch Requestsは複数のテキスト断片をまとめて送ることで往復回数を減らす。Subtitle TranslationとTTSが並んでいることから、動画の字幕要素も対象に入る。ただし、これらの実装詳細はREADMEの記述以上のことは確認できない。

20以上のプロバイダを差し替えられる意味

READMEは「20+ AI Providers」を掲げ、トピックには deepseek、gpt、openai、llm が並ぶ。OpenAI互換のエンドポイントを想定した構成であれば、モデル名とベースURLを差し替えるだけで別のプロバイダに切り替えられる。この設計の実利は、翻訳の品質とコストを利用者側が選べる点にある。安価なモデルで下訳を出し、精度が要る箇所だけ上位モデルに投げる、といった運用が理論上は可能だ。一方で、この構成はBYOK（Bring Your Own Key）を前提にする。拡張機能にAPIキーを保存する以上、キーの管理責任は利用者に移る。READMEにはキー保管の方式についての記述がないため、同期ストレージに置くのかローカルに留めるのかは、導入前にソースか設定画面で確かめる必要がある。プロバイダの選択肢の多さは、そのまま鍵の管理対象の多さでもある。

導入の手順と確認すべき設定

配布経路はストア経由が基本で、READMEのDownload表はChrome Web Store、Microsoft Edge Addons、Firefox Add-onsの3つを挙げ、中国本土向けに crxsoso のミラーが併記されている。ストアから入れればビルドは不要で、インストール後に拡張の設定画面でAIプロバイダとAPIキーを登録する流れになる。ソースから動かす場合は、リポジトリをcloneし、package.jsonのscriptsに従ってWXTの開発サーバを起動し、ブラウザに未パッケージ拡張として読み込む。READMEはビルドコマンドの具体形までは示していないので、ここはリポジトリのscriptsを直接確認するしかない。設定面では、翻訳の表示形式（対訳か翻訳のみか）を選ぶトグル、Custom AI Actionsの定義、Batch Requestsの有効化が主要なつまみになる。READMEのドキュメントへのリンクは readfrog.app/docs で、機能の詳細はそちらに置かれている。

向かない場面：APIキーとレイテンシの制約

Read Frogは翻訳エンジンを自前で持たない。品質も速度も、選んだプロバイダのAPIに依存する。ページ全体を対象にした没入型翻訳では、抽出したテキストを分割して送るため、往復回数がそのまま待ち時間になる。Batch Requestsはこの往復を束ねる仕組みだが、レイテンシそのものを消すものではない。もう一つの制約は、組織で配る用途に合わないことだ。利用者ごとにAPIキーを用意させる設計は、キーの配布と失効を管理したい情シスには受け入れにくい。加えて、READMEは「currently under active development」と明記しており、破壊的な変更が設定や保存データに及ぶ可能性を否定していない。翻訳結果を業務成果物として扱う使い方は、この成熟度の宣言と噛み合わない。

Immersive Translateとの設計差

同じ没入型翻訳の領域にはImmersive Translateがある。Read Frogのトピックに immersive-translate が入っていることからも、比較対象として意識されていることがわかる。両者の違いは、翻訳の宛先にある。Immersive Translateはページを読むための翻訳機能を軸に据え、対応サービスを増やす方向で広げてきた。Read FrogはREADMEが language learning を前面に出す通り、読んだ内容を学習に接続する侧、つまり選択範囲の処理、Custom AI Actions、記事分析に重心を置く。プロバイダを20以上から選ばせるのも、翻訳のためというより、学習用途ごとにプロンプトとモデルを組み替えるためだと読める。どちらが優れているかではなく、読むための道具か、読んで覚えるための道具かという用途の違いである。

GPL-3.0と商用ライセンス付与の関係

ライセンスはGPL-3.0。拡張機能を改変して配布する場合、対応するソースの公開が求められる。社内で改変版を配るだけなら頒布に当たらないことが多いが、顧客に配布する製品へ組み込むと話が変わる。READMEには Commercial License Grant という節があり、商用利用向けの別条件が用意されていることが示されている。GPL-3.0のままで自分の用途が成立するのか、それとも商用ライセンスの付与が必要なのかは、この節の本文とLICENSEファイルを突き合わせて確認するしかない。ここは法務判断の領域で、技術記事の範囲では結論を出せない。少なくとも、ライセンス条項が2種類あるという事実を把握せずに製品へ組み込むのは危険である。

更新頻度とメンテナンスの読み方

リポジトリの最終pushは2026-09-09で、同じ日にv1.46.9が公開されている。直前のリリースはv1.46.8が2026-09-05、v1.46.7が2026-09-02で、数日おきにパッチ版が積まれている。この刻み方は、ストア審査を通す単位で細かく修正を出している運用を示す。利用者にとっては、バグ修正が比較的早く届く代わりに、更新のたびに設定や挙動が動く可能性を想定しておく必要がある。バージョン番号が1.46台まで進んでいることも、リリース回数そのものが多いことを示唆する。追従コストを見積もるなら、GitHubのリリースノートを購読し、自分の設定（Custom AI Actions、プロバイダ設定）が壊れていないかを更新後に確認する流れになる。

編集部の結論

Read Frogは、APIキーを自分で用意でき、Chrome・Edge・Firefoxのいずれかで読書しながら語学学習をしたい個人に向く。逆に、APIキーを配布したくない組織、翻訳品質のSLAが必要な業務利用、GPL-3.0のソース公開義務を避けたい製品組み込みには向かない。導入前に確認すべきは3点で、第一にreadfrog.appのドキュメントにあるCustom AI Actionsのプロンプトがどの程度外部送信されるか、第二にリポジトリ直下のLICENSEがGPL-3.0のままか、第三にREADMEのCommercial License Grantが自分の用途を覆うかどうかである。判断は、自分のAPIキーとGPL-3.0の受け入れ可否で決まる。

公式情報源

1. License: GPL-3.0
2. mengxi-ream/read-frog on GitHub
3. Project website
4. README
5. Releases