誕生の背景 Yomikomi

多くの日本語学習者と同様、デスクトップではYomitanを愛用していました。でもスマホでマンガや小説を読もうとすると、すべてが崩壊します。知らない単語を見つける → スクリーンショット → Google翻訳 → 日本語テキストをコピー → 'imiwa?'で検索。これは本当に疲れるし、読書の没入感を完全に壊してしまいます。

MokuroなどのOCRツールは存在していましたが、ローカル環境のセットアップが必要でパソコンに縛られていました。スマホのSafariで開いてただ読める何かが欲しかったのです。

きっかけは以前作ったプロジェクト「subtitles-hook」でした。シンプルなアイデア——ローカル動画を読み込み、Turboscribeで字幕を生成し、Yomitanで単語にホバーする。デスクトップでは完璧に動きました。

でもスマホでアニメを見るときYomitanが使えないことで気づきました。辞書そのものをブラウザに内蔵できないだろうか？その問いがWASM、ONNX、クライアントサイドAIモデルの世界への扉を開きました。

Yomikomiの前に、辞書検索を内蔵した日本語テキスト読書アプリ「jp-reader」を作りました。便利でしたが、やはりパソコンとサーバーが必要でした。どの解決策を作っても、同じ制約に引き戻されていました。

実はYomikomiはもともとAnkiデッキツールとして始まりました。Node.jsで.apkgファイルをSQLiteデータベースとして解析する方法を見つけましたが、バックエンドのみで動作しました。そこでsql.js——WebAssemblyにコンパイルされた完全なSQLite——を発見。突然、サーバー不要でブラウザだけでAnkiデッキを解析できるようになりました。

この発見がすべてを変えました。SQLiteをブラウザで動かせるなら、他に何が動かせるか？答えはONNX Runtime WebによるPaddleOCR——日本語テキスト認識がクライアントサイドで、クラウドなし、APIキーなしで実現しました。

最初はバックエンドサーバーでOCRモデルを動かすことを試みました——PaddleOCRやYomiTokuを使ったDockerコンテナです。品質は優れていましたが、自己ホスティングにはインフラ、VPS、継続的なメンテナンスが必要です。アプリはまだこのモードをサポートしていますが（リポジトリのserver/ディレクトリを参照）、私個人はもう使っていません。

ブラウザネイティブのアプローチはアクセシビリティで勝ります。インストール不要、費用不要、画像はデバイスから出ません。モデル品質はサーバーサイドより若干劣り、大きなTransformerモデルがiOS Safariをクラッシュさせることもありますが——これらは既知の制限として取り組んでいます。

拡張機能のインストールなし、サーバーの起動なし、コンテンツをGoogleに送信なし——スマホで本、マンガ、日本語テキストを読みたい日本語学習者なら、Yomikomiが求めていたものかもしれません。

Safari → 共有 → ホーム画面に追加でiPhoneのホーム画面に追加すれば、ネイティブアプリのように動きます。辞書、OCR、トークナイザー、翻訳——すべてローカル、すべてプライベート。