ReadAny：ローカル埋め込みとWebDAV同期を選んだ電子書籍リーダーの設計と制約

ReadAnyが埋めようとしている「読んだのに残らない」問題

ReadAnyのREADMEは、動機を3つの問いの形で提示している。「Why do I forget what I read? Why are my notes scattered? Why can I only search by keywords?」つまり対象は、読書そのものではなく読書の後工程に困っている人だ。読了後に内容を思い出せない、ハイライトが各アプリに散らばる、キーワードが一致しないと検索でヒットしない、という3つの不満が設計の出発点になっている。

想定読者は個人の読書家であり、チームや組織のナレッジ基盤ではない。READMEの機能一覧には共有リンクや共同編集、権限管理の類は見当たらず、代わりにハイライト、Markdownノート、書き出し、読書統計といった一人で完結する機能が並ぶ。ローカルのベクトルストアを採用している点も、蔵書を外部サービスに預けたくないという個人の事情を反映している。逆に言えば、複数人で同じ蔵書を検索したい用途は最初から視野に入っていない。

Tauri + Expoの二重構成と、ローカル完結のRAGパイプライン

リポジトリはTypeScriptで書かれ、トピックにtauriとexpoの両方が挙がっている。デスクトップはTauri、モバイルはExpo（React Native）という分担で、macOS、Windows、Linux、iOS、Androidの5プラットフォームを同じコードベースから出す構成だ。READMEのプラットフォームバッジもこの5つを列挙している。

データの流れは、書籍を取り込む、テキストを埋め込みに変換する、ローカルのベクトルストアに保存する、という順序になる。検索時はベクトル検索とBM25を組み合わせたハイブリッド検索が走り、チャットでは現在の読書位置、選択中のテキスト、既存のハイライトがコンテキストとして渡される。READMEは「AI knows your position, selected text, and highlights」と説明しており、質問が書籍全体ではなく今読んでいる箇所に紐づく設計だと読み取れる。

埋め込みをローカルで計算するため、機内やオフラインでも検索とチャットの土台が動く。ただし後述するように、生成側のモデルをどこに置くかでこの利点は変わる。SQLiteとvector-searchがトピックに含まれることから、保存層はSQLite上にベクトル検索を載せる形だと推測できるが、インデックス方式や次元数といった詳細は提供資料からは確認できない。

対応フォーマット10種と、TXT・UMDがEPUBに変換される理由

対応形式はEPUB、PDF、MOBI、AZW、AZW3、FB2、FBZ、CBZ、TXT、UMDの10種。READMEの比較表ではCalibreの15種、KOReaderの10種、Apple Booksの2種と並べられている。数字だけを見ればCalibreに劣るが、Calibreは変換と管理に特化したデスクトップアプリであり、読書中のAI操作を前提にしていない。比較表の軸がそもそも違う。

注目したいのはTXTとUMDの扱いだ。READMEは「TXT and UMD are imported by converting them to EPUB for reading, notes, search, and sync」と明記している。つまりこの2形式は直接描画されず、取り込み時にEPUBへ変換される。変換を挟む以上、章分割の粒度や改行の扱いが元ファイルと一致しない可能性がある。青空文庫のTXTを大量に持っている読者にとっては、ここが実用上の分岐点になる。ノート、検索、同期をEPUB前提のパイプラインに一本化するための割り切りであり、設計としては筋が通っているが、変換結果の見た目は自分のファイルで確かめるしかない。

導入の実際：Homebrew、TestFlight、APKという3つの入口

デスクトップ版はGitHub Releasesから.dmg（Apple Silicon / Intel）、.msi、.AppImageを取得する。macOSはHomebrew経由でも入る。

brew tap codedogQBY/readany brew install --cask readany

モバイルは配布経路が分かれる。iOSはTestFlight、AndroidはAPKの直接ダウンロードだ。READMEのバージョン表記には「v2.0 Update: Mobile apps (iOS/Android) now available」とあるが、Releasesに並ぶ最新はv1.3.6（2026-08-16）、その前がv1.3.5（2026-07-08）とv1.3.4（2026-06-09）で、v2.0というタグは資料からは確認できない。READMEの記述とリリース一覧の間にずれがある点は、そのまま受け取っておくのが安全だ。

初期設定はREADMEによれば3ステップで、書籍をライブラリにドラッグ&ドロップし、ダブルクリックで開き、必要ならSettingsからAIを構成する。AI設定は任意とされているので、まずリーダーとして使い、後からプロバイダを足す進め方も成立する。プロバイダはOpenAI、Claude、Gemini、Ollama、DeepSeek、およびcustom-compatible providersが挙がっている。

オフラインを売り文句にしながら、生成はクラウドに逃げられる

ReadAnyの中心的な主張はプライバシーだ。READMEは「Local embeddings and a local vector store keep your books, highlights, and notes offline-capable」とうたい、比較表でも「Local Vector Store」を他リーダーとの差として挙げている。埋め込みと保存がローカルなのは事実だろう。

ただしチャットの応答生成は別問題である。プロバイダ一覧の先頭にOpenAI、Claude、Geminiが並び、Ollamaはその一つとして同列に置かれている。クラウドのLLMを選べば、質問文とコンテキストとして切り出された本文が外部に送信される。ローカルのベクトルストアは「蔵書全体をアップロードしない」ことを保証するが、「読書中の断片が外部に出ない」ことは保証しない。この区別はREADMEでは明示されていない。完全なオフライン運用を求めるなら、Ollamaなどローカルの生成モデルを選ぶ必要がある。ここは宣伝文句と実際の設定の間に落とし穴がある箇所で、導入判断で最も注意すべき点だ。

もう一つの制約はDRMだ。対応形式にAZWやAZW3が含まれるが、これはAmazonの形式であり、DRMなしのファイルを指すと解釈するのが自然だ。DRM付きの購入済み書籍が読めるという記述はどこにもない。

Calibre、KOReaderとの違いは「読書後」に何をするか

代替として最も現実的なのはCalibreだ。違いは明確で、Calibreはフォーマット変換と書誌管理のツールであり、15種以上の形式を扱い、プラグインで機能を足せる。読書中の意味検索やRAGチャットは持たない。ReadAnyは逆で、対応形式は10種にとどまる代わりに、読んでいる最中の質問と検索を中心に据える。蔵書の整理とメタデータ修正が主目的ならCalibreのままでよく、ReadAnyに移る理由は薄い。

KOReaderは電子ペーパー端末を含む幅広い環境で動くリーダーで、ReadAnyと同じく10種の形式を扱う。比較表ではTTSが「Limited」とされている。KOReaderの強みは表示の作り込みと端末対応であり、AI機能は持たない。縦組みやルビを含む日本語組版を重視するなら、現時点でKOReader側に分があると考えるのが妥当だ。ReadAnyのREADMEにはCJK最適化フォントテーマが5種と書かれているが、これは書体の話であり、組版規則への対応を示す記述ではない。

つまり選択軸は「何が読めるか」ではなく「読んだ後に何ができるか」にある。ハイライトをObsidianやNotionへ書き出し、そのまま知識ベースに流し込みたい読者にとっては、ReadAnyのMarkdown、HTML、JSON、Obsidian、Notionという5形式の書き出しが効いてくる。

ライセンス表記の曖昧さと、更新頻度から見る保守コスト

最初に確認すべきはライセンスだ。GitHub上のライセンス識別子はNOASSERTIONであり、これは自動判定が既知のライセンスに一致しなかったことを意味する。READMEのバッジはLICENSEファイルへのリンクを張っているが、条文の内容は提供資料からは分からない。オープンソースかどうかを判断するには、リポジトリのLICENSEファイルを直接読む必要がある。ここを確認せずに業務利用を決めるのは危険で、特に再配布や商用利用の可否は条文を見ない限り判断できない。法的助言はできないので、必要なら専門家に確認してほしい。

保守の観点では、リリース間隔がおよそ1か月から2か月で、v1.3.4（2026-06-09）、v1.3.5（2026-07-08）、v1.3.6（2026-08-16）と続いている。継続的に手が入っていることは分かる。ただしREADMEが案内するv2.0のモバイル版と、Releasesに並ぶv1.3系の番号が一致しないため、モバイルを使う場合はTestFlightとAPKのどちらがどのバージョンに対応するのかを配布ページで確かめる必要がある。

アップグレードのコストは構成によって変わる。ローカルのベクトルストアを持つ以上、埋め込みモデルを変更すると既存のインデックスを再構築する必要が生じる可能性が高い。これは提供資料から確認できる記述ではないが、ローカル埋め込みを採用する設計では一般的に付いて回る制約だ。WebDAV同期を使っている場合、書籍本体、ハイライト、ノートのどれが同期対象に含まれるかをREADMEは明示していない。同期の範囲は自分の目で確認したい。

編集部の結論

ReadAnyが向くのは、蔵書を外部クラウドに預けずに意味検索とRAGチャットを使いたい個人、特にOllamaなどローカルLLMをすでに動かしている読者だ。逆に、DRM付き書籍の読書や縦組み・ルビの精密な表示、共同編集を前提とする用途には向かない。導入前に確認すべきは3点で、第一にリポジトリのライセンス表記がNOASSERTIONであり、LICENSEファイルの実際の条文を自分の目で読むこと。第二に、TXTとUMDはEPUBへ変換してから取り込まれる仕様なので、変換後のレイアウトを自分の書籍で確かめること。第三に、埋め込みモデルとLLMの選択が検索品質と応答速度を直接左右するため、Settings画面でプロバイダを設定したうえで、手元の1冊に対して検索とチャットを試すこと。この3つを確認してから常用するかどうかを決めればよい。

公式情報源

1. codedogQBY/ReadAny on GitHub
2. Issues
3. Project website
4. README
5. Releases