Local Reader Appを公開しました｜「読む」を中心にしたローカルOSSの開発記録

手元のフォルダをブラウザで読むローカルOSS、 Local Reader App を公開しました。現在のバージョンは0.1.0です。

始まりは、2026年5月に私が感じていた「VSCode依存から離れたい」という課題でした。負担になっていたのは、次のような操作の繰り返しです。

• 複数のリポジトリを横断して文書やコードを読むたびに、VSCodeのワークスペースやウインドウを開き直す。
• 画像やPDFを確かめるために、別のアプリへ移る。
• Gitの変更を確認するために、また表示を切り替える。

編集を始める前の「状況を把握する時間」に、道具を行き来する負担が積み重なっていました。

そこで、人はブラウザでリポジトリを読み、必要な変更はCodexなどのCLIへ依頼する、という分担を考えました。ただし、最初からAI編集まで一体化したわけではありません。まず「読むだけ」の初期版を作り、有料販売も想定したElectronアプリとして育てた後、誰でも利用できるブラウザ版OSSへ方針を広げました。AI Chatでも4つの入口を試し、初期公開で提供できる範囲を絞っています。

現在の形は、最初に描いた完成図をそのまま実装した結果ではありません。 読むことを中心に置く、通常閲覧では元ファイルを書き換えない、AIは任意にする という三つの境界を、試作と失敗のたびに確かめ直した結果です。

VSCodeから離れ、複数のリポジトリをブラウザで読む構想から始まった

最初の課題は、VSCode自体の機能不足ではなく、読む行為までエディタの操作体系に寄せていたことでした。編集する予定がないときもワークスペースを開き、対象のリポジトリへ移動し、ファイルツリーをたどる。その繰り返しを減らすには、エディタを置き換えるより、読むための入口を別に作るほうが筋が通ります。

VSCodeには編集、検索、ターミナル、拡張機能など、開発に必要な機能が揃っています。だからこそ、同じものを別のアプリで再現しようとすると、読むための小さな道具ではなく、もう一つのエディタを作ることになります。欲しかったのは機能の多さではなく、変更を始める前にリポジトリ全体を落ち着いて見直せる場所でした。

読むための道具を、編集するためのエディタの縮小版にはしない。 この線引きを置いたことで、何を作らないかも決まりました。ファイルを保存するボタンやアプリ内ターミナルを急いで加えるより、フォルダ構造、文書の見出し、関連ファイル、Gitの状態を同じ流れで確認できることを優先しました。

初期案では、複数のリポジトリをアプリ内へ登録し、左側のツリーからファイルを選び、右側のビューアで内容を確認する構成を置きました。登録先はGitで管理されたリポジトリだけに限らず、文書をまとめた通常のフォルダも対象にします。毎回Finderから場所を探すのではなく、よく読むフォルダへの入口をアプリ側に持たせるためです。

読む対象もマークダウンだけでは足りませんでした。設計資料のマークダウン、設定を記したYAML、ソースコード、画像、PDF、Gitの差分は、同じ制作物の前後関係を構成しています。マークダウンは整形表示と原文を切り替え、コードやYAMLは行番号を保ち、画像やPDFも同じフォルダ構造から開ける必要がありました。

一方、オンラインストレージへファイルを移す案は出発点に合いません。欲しかったのは新しい保管場所ではなく、すでに手元にある情報への新しい読み方です。この判断により、アプリは自分のコンピュータ上で動き、登録したフォルダを直接読むElectronアプリとして始まりました。

最初の実用版は、編集しないローカルビューアへ絞った

最初の実用版では、編集、ターミナル、プラグイン、AI Chatを対象から外しました。将来不要だと判断したのではありません。読む仕組みの価値と、元ファイルを変更する仕組みの安全性を、同時に検証しないための切り分けでした。

候補に挙がっていた機能をすべて入れると、ファイルが表示できない問題と、書き込み権限の問題が同じ場所へ混ざります。さらに、AIへ編集を任せるなら、認証、利用者の承認、実行中の状態表示、対象リポジトリの限定、失敗後の復旧まで決めなければなりません。閲覧機能の価値を確かめる段階としては範囲が大きすぎました。

そこで初期実装は、アプリ内の登録情報、フォルダツリー、ファイル表示という最短の流れに限定しました。ファイル取得の経路も読み取り専用にし、登録した範囲の外側へパスが出ないことを先に検証しました。マークダウンのフロントマターは整形表示では隠し、原文表示では確認できるようにしています。読む場面ごとに必要な情報量が異なるためです。

この段階では、画面上の情報を増やせば読みやすくなるとも考えませんでした。整形したマークダウンだけを表示すると、文書としては読みやすくても、フロントマターや記法を確認できません。反対に原文だけでは、長い文書の構造をつかむのに時間がかかります。整形表示と原文表示を切り替えられるようにしたのは、同じファイルでも「内容を読む」と「記述を確かめる」で必要な見え方が違うからです。

人が内容と前後関係を確認し、必要な変更をCodexへ依頼するという分担でも、この読みやすさが土台になります。AIへ依頼する前に対象を自分で確かめ、実行後にはGitの差分を読む。最初の実用版は閲覧専用でしたが、その制約が後のAI Chatと無関係だったわけではありません。むしろ、AIへ何を任せる場合でも、人が確認できる面を先に作る順序になりました。

2026年5月7日に形になった最初の版は、完成した製品ではありませんでした。それでも、複数のリポジトリを登録して切り替えるだけで、エディタを開き直す回数は減らせると確認できました。ここで得た結論は、編集機能がないことを弱点とみなす必要はない、ということです。

後から振り返ると、この絞り込みが現在の製品境界になりました。Local Reader Appは万能なファイル操作ソフトではなく、 元のフォルダ構造を保ったまま、内容と前後関係を読むための道具 です。通常の閲覧と例外的なAI編集を分離できたのも、最初の実用版で「読む」を独立させたからでした。

現在のブラウザ版でも、この境界は画面構成に残っています。登録したフォルダのツリー、選択した文書、ファイル情報とアウトラインを一度に見渡せるため、編集を始める前の状況確認を一つの場所で進められます。

三つの領域を同時に見せる目的は、情報量を増やすことではありません。いま選んでいるリポジトリとファイルを見失わず、内容と周辺情報を同じ前後関係で読めるようにすることです。

日々使う中で、「読む」ための細部が製品の輪郭になった

初期版の後に増えた機能は、最初に作った一覧を順番に消化したものではありません。実際に使い、読む流れが止まった場所を直した結果です。大きな機能を一度に足すより、小さな摩擦を一つずつ取り除く過程で、ローカルビューアからワークスペースへ輪郭が変わっていきました。

たとえば、長い原文を読むときには行が画面外へ伸びるため、折り返しを選べるようにしました。マークダウン内の相対リンクは、同じリポジトリの別文書へ移るために必要でした。一方、コードブロック内の文字列まで自動リンクにすると、読む対象そのものを変えてしまいます。リンクとして扱う場所と、原文を保つ場所を分ける必要がありました。

画像の表示、PDFの閲覧、HTMLの確認も、形式を増やすこと自体が目的ではありません。READMEから設計図を開き、仕様書からサンプルへ移り、関連するPDFを確かめる流れを一つの画面で完結させるためです。ファイルタブは、その往復で位置を失わないようにする役割を持ちました。

Gitの状態と差分も同じです。ターミナルを完全に置き換えるのではなく、「いま読んでいるファイルが変更中か」「リポジトリ全体にどのような差分があるか」を、内容と並べて確認できるようにしました。変更前の把握がしやすくなるほど、編集を別の道具へ任せても文脈を保ちやすくなります。

この時期には、ファイル情報、アウトライン、複数タブ、ローカルHTTPでの表示、メモなども加わりました。個々の機能だけを見れば小さな改善です。しかし、読む途中で別のアプリへ離れる理由を一つずつ減らすという判断基準は共通していました。 製品の輪郭を決めたのは機能数ではなく、読む流れをどこまで途切れさせないか でした。

原文とGitの状態を確かめる場面では、整形表示とは異なる読み方が必要です。次の画面では、マークダウンの原文、変更中のファイルを示すマーカー、ファイル情報を同じ場所で確認できます。

原文表示とGit表示を一体にしたことで、別の道具へ編集を任せた後も、何が変わったかを読む場所が残りました。閲覧機能を先に固めた判断は、後のAI Chatでも人が結果を確認するための土台になっています。

販売を想定したElectron版から、より多くの人へ開くブラウザ版へ方針を変えた

Local Reader Appは当初、私が使うファイル閲覧専用アプリとしてElectronで開発し、将来は有料で販売することも想定していました。まず自分が日常的に使える道具を作り、その実装を製品へ育てていく考え方です。

販売を前提にすれば、アプリとして起動できること、利用者が内部のサーバー構成を意識しなくてよいこと、導入から更新までを製品側でまとめることにも意味があります。Electron版は、そのようなデスクトップ製品の形を考えながら、私自身が毎日使って不足を見つける場所でもありました。自分の用途に合わせて改善し、その完成度を上げてから提供する流れを想定していました。

しかし、Codexと一緒に開発を続ける中で、「この内容なら有料製品として閉じるより、なるべく多くの人に使ってもらうほうが、作る側にも使う側にも得がある」という思いが強くなりました。以前から、自分で作ったプロダクトをGitHubへ公開することにも憧れがありました。この二つが重なり、Electron版の実装をもとに、より多くの人が利用できるブラウザ版をOSSとして作る方針へ変わりました。

有料化を諦めたのではなく、届け方の優先順位を変えた。 これが当時の判断に近い表現です。販売できるかどうかだけで考えるのではなく、ソースを公開し、興味を持った人が自分の環境で試し、必要なら実装も確認できる状態にする。そのほうが、このアプリの内容と開発段階には合っていると考えるようになりました。

GitHubへの公開には、単にファイルをアップロードする以上の意味もありました。以前から抱いていた「自分のプロダクトをオープンソースとして公開したい」という憧れを、実際に使っているアプリで形にできます。一方で、公開すれば、私の環境だけを前提にした設定や説明不足も、そのまま外から見える問題になります。憧れを実現するには、公開に耐える境界へ作り直す必要がありました。

最初から作り直したわけではありません。Electron版でファイルツリー、各形式の表示、Gitの状態確認などが動いていたため、ブラウザ版では既存の判断と実装を参照できました。私だけが使う道具として試した土台があったことは、ブラウザ版を比較的快適に開発できた大きな理由です。

移し替えるときは、Electron版の画面をそのまま複製するのではなく、どこまでがファイルを読むための中核で、どこからがElectron固有の起動・配布機構なのかを分けました。表示や操作の中核を残し、デスクトップアプリの殻に依存する部分は公開版へ持ち込まない。すでに動く実装が比較対象になったため、ブラウザ版で不足しているものと、最初から不要なものを判断しやすくなりました。

公開版は、Electron固有のアプリ殻を前提にせず、Node.jsとpnpmで起動するlocal HTTP構成にしました。ここでいうブラウザ版は、ファイルをオンラインサービスへ預ける仕組みではありません。処理は自分のコンピュータ上で動き、既定では 127.0.0.1 からアクセスします。

この変更は、販売方法だけを変えたものではありません。自分一人の環境で動けばよかったアプリを、不特定多数の人がソースを確認し、自分の環境で導入できる形へ組み直す転換でした。 有料販売を想定した個人用アプリが、より多くの人へ開くOSSへ変わったこと が、その後の対応環境、AI機能、公開前監査の判断にも影響しました。

ブラウザ版のAI Chatは、4つの入口を同じ仕組みに揃えられなかった

Electron版は私だけが使う想定だったため、AI ChatはCodex CLIだけに対応していました。自分の環境にあるCLIを前提にすれば、認証方法や編集能力を一つに絞れます。しかし、不特定多数の利用者へ開くブラウザ版では、全員が同じAIサービスや実行環境を使うとは限りません。

ここでも、利用者の範囲が設計を変えました。Electron版なら、私がCodex CLIをインストールし、認証し、その挙動を理解していることを前提にできます。ブラウザ版では、Codexを使う人、Claude Codeを使う人、契約中のAIサービスへAPIで接続したい人、外部へ送らずローカルモデルを動かしたい人がいます。一つの入口だけでは、公開版として考えた利用範囲を狭めてしまいます。

そこでブラウザ版では、Codex CLI、Claude Code CLI、AI API、Local AIという4つのAI Entryを用意しました。CLIを使いたい人、任意のAIサービスへAPIで接続したい人、自分のコンピュータ上で動かすAIを使いたい人まで、異なる利用方法を一つの設定画面から選べる構想でした。

4つの入口は、ファイル操作を担う仕組みと0.1.0で確認できている状態を分けると、次のようになります。

同じ設定画面に並ぶことと、同じ提供状態であることは一致しません。Claude Code CLIは実際に動く接続処理まで実装していますが、管理者はClaudeの対象アカウントを使った認証、モデル一覧の取得、準備確認、モデルへの送信を実環境で検証していません。

設定画面では4つを同じ「入口」として並べられますが、その先で動くものは同じではありません。Codex CLIとClaude Code CLIは、会話だけでなく、ファイルを探し、内容を読み、複数の変更を組み立てるための道具を持っています。AI APIとLocal AIは、基本的には入力に対して文章を返すモデルへの接続です。ファイル編集まで行うには、その文章を具体的な操作へ変換する仕組みをLocal Reader App側で用意しなければなりません。

Codex CLIとClaude Code CLIは、それぞれがファイルの読み取りや編集に使う強力な機能を持っています。Local Reader Appからは、選択中のリポジトリを作業場所としてCLIを起動し、認証状態や利用可能なモデルを確認できます。ファイル操作の詳細は各CLIの仕組みへ任せられるため、会話から編集へ進む流れを比較的素直に組み立てられました。

CLIは、単に高性能なモデルへ文章を送る窓口ではありません。対象ファイルを追加で探す、変更前に読む、複数ファイルをまとめて直す、実行結果を確認するといった一連の作業を、自身の機能として扱えます。Local Reader Appは作業対象となるリポジトリを指定し、各CLIはその中で自分の道具を使う。この役割分担ができたことが、実装を進めやすかった理由です。

一方、AI APIとLocal AIには、ファイル操作を任せられる共通のCLIがありません。接続先のモデルも利用者ごとに変わり、指示の理解、文章の置換、複数ファイルの扱い、決められた形式への応答などに性能差があります。APIへ接続できることと、手元のファイルを安定して編集できることは別の問題でした。

高性能なモデルで一度成功しても、別のモデルが同じ形式で応答するとは限りません。ローカルモデルでは、コンピュータの性能、モデルの規模、推論設定によっても結果が変わります。公開版では利用者がどのモデルをつなぐかを事前に断定できないため、特定のモデルで成功した事例だけをもって、AI APIやLocal AIによる編集を提供済みとは判断できませんでした。

同じAI Chatという画面でも、背後にある実行能力は同じではない。 4つを一つのUIへ並べたことで、かえってこの違いが明確になりました。画面を共通化することと、権限、失敗条件、編集結果まで共通化することは別でした。

4つのAI Entryを画面上で揃えても、同じ権限と実行方法へまとめることはできませんでした。会話UIの共通化より難しかったのは、能力の異なるAIに対して、どの編集を許可し、何をアプリ側で検査するかという境界です。

アプリ側で編集を守る方式を試したが、2つのAI Entryは初期公開から外した

AI APIとLocal AIでもファイルを編集できるようにするため、編集権限をLocal Reader App側に持たせ、4つのAI Entryによる変更をアプリ側で確認する方式を試しました。AIへ自由なファイル操作を渡すのではなく、選択中のリポジトリ内で許可された変更だけを適用する考え方です。

この「保護付き編集」では、提案をそのまま書き込まず、次の条件をすべて確認してから適用します。

• 選択中のリポジトリ内にある、許可された相対パスと操作だけを受け付ける。
• 既存ファイルは変更前に読み直し、提案が前提とした内容と現在の内容が一致するかを確かめる。
• 対象の重複、不一致、途中での外部変更を検出した場合は、書き込みを始めずに止める。
• 複数の変更を一まとまりとして扱い、完了条件を満たせなければ部分的な変更を戻して結果を検査する。

AI APIやLocal AIには、変更対象のパス、置換前の文章、置換後の文章などを、アプリが理解できる決められた形で返してもらいます。Local Reader Appは、その提案が選択中のリポジトリ内に収まっているか、対象が現在の内容と一致するか、すべての変更を一まとまりとして適用できるかを確認します。モデルへ直接ファイルシステムを渡さず、提案と適用を分けるための仕組みでした。

実装を試したとき、置換対象の文章が現在のファイルと正確に一致せず、変更が拒否されたことがありました。別の試行では、変更予定のファイルをすべて読み直していないため実行できませんでした。どちらも元ファイルを変更せずに止まったため、危険な変更を拒否する仕組みとしては期待通りです。

安全に止められることと、利用者の意図どおりに完了できることは別の評価軸です。 厳しい検査は、古い内容や曖昧な置換を通さないために役立ちます。しかし、モデルが必要な形式を安定して返せなければ、安全に失敗する回数ばかりが増え、編集機能としては使いにくくなります。

しかし、利用者が求めた編集を完了できるかという点では、期待通りになりませんでした。特にAI APIとLocal AIは、接続するモデルを事前に限定できません。同じリポジトリ内へ操作を制限しても、モデルごとの理解力や出力形式の差を、Local Reader App側の実装だけで吸収することは困難でした。

検査を緩くすれば、より多くのモデルが返した提案を受け付けられるかもしれません。その代わり、対象を取り違えた変更や、途中までしか適用できない変更を通す危険が高まります。反対に検査を厳しくすると元ファイルは守りやすくなりますが、性能差の大きいモデルを幅広く受け入れるという当初の狙いから離れます。この二つを、初期公開までに満足できる形で両立できませんでした。

そこで、Codex CLIとClaude Code CLIは、それぞれのCLIが持つ編集機能と権限管理を使う方式へ戻しました。AI APIとLocal AIは、将来の開発に備えて接続設定や保護付き編集の実装をソースへ残しつつ、初期公開版では通常UIから選択できないようにしています。

4つのAI Entryを用意した当初の構想を、なかったことにはしていません。設定項目と将来用の実装を残すことで、モデルや編集方式を改めて検証する余地を保っています。ただし、コードが残っているからといって、利用者が使える機能であるかのようには見せません。 初期公開で選べない状態にすることも、公開品質を守るための実装 だと判断しました。

記事公開時点の0.1.0では、対応する実行環境でCodex CLIを利用できます。Claude Code CLIは接続処理と模擬・静的テストを整えた段階であり、対象アカウントを使った実環境での互換性は未確認です。AI APIとLocal AIのカードは4つの入口の構想を示すために残していますが、操作ボタンは Coming soon と表示され、有効化できません。実装が存在することと、公開機能として提供できることを分けた判断です。

実際の設定画面にも、4つの入口と提供状態の違いを同時に表示しています。カードが存在するだけでは利用可能と誤認しないよう、AI APIとLocal AIの操作は無効なComing soonにしています。

この画面で重要なのは、将来像を隠さずに残しながら、現在使える範囲も曖昧にしないことです。UI上の存在、実装の存在、実環境で検証済みの提供機能を別々に扱う境界が、初期公開の誤解を減らします。

通常のファイル閲覧には、どのAI Entryも必要ありません。CLIを使う場合も、仕組みが利用者の代わりに最終判断を引き受けるわけではありません。 AIへ渡す情報と、実行後の変更は利用者自身で確認してください。

公開前には、コードだけでなく履歴と対応環境も検査した

OSSの公開は、現在のソースコードがビルドできれば完了するものではありません。公開ページから見えるファイル、Gitで到達できる履歴、導入手順、ライセンス、対応環境、サポート範囲が同時に読まれます。公開前には、これらを別々の検査対象として扱いました。

監査は、確認対象が混ざらないように次の順序で進めました。

1. 現行ファイルの公開面とGit履歴から到達できる面を点検し、公開用の説明、連絡先、ライセンス、セキュリティ方針を整える。
2. 新しく取得した環境で、依存関係の導入、型検査、テスト、ビルド、ループバックアドレスでの起動を公開手順どおりに再現する。
3. ソースが継続的インテグレーションを通る環境と、利用者向け手順を実機で確認した環境を分ける。
4. 対応機能と未提供物を列挙し、「アプリが起動する」と「すべての機能が使える」を混同させない。

現在、利用者向けの導入手順を案内しているのはmacOSとネイティブWindowsです。LinuxとWSL2はソースレベルの継続的インテグレーション対象ですが、利用者向けの導入・運用手順を実機で検証した対応環境とはしていません。

ネイティブWindowsでは通常のファイル閲覧を利用できますが、AI ChatのCLI連携は現在の提供範囲に含めていません。この違いを曖昧にすると、「アプリが起動する」と「すべての機能が同じように動く」が混同されます。対応環境はOS名だけでなく、確認済みの機能範囲と一緒に示す必要がありました。

公開前監査で重視したのは、完全無欠に見せることではなく、確認できた範囲と未提供の範囲を分けることです。現在はソースコードから導入する形であり、 .dmg 、 .exe 、App Store向けパッケージ、オンラインアカウント、ワンクリックのインストーラーは提供していません。 公開時点の制約も、利用者が導入を判断するための製品情報 として扱っています。

これは、Electron版を私だけが使っていた段階との大きな違いでした。自分の環境なら、必要な依存関係や起動方法を知っているため、説明がなくても動かせます。不特定多数へ公開する場合は、何が必要かだけでなく、何をまだ提供していないか、どの環境まで確認したか、AI機能のどこが選べないかまで、利用者が事前に判断できるようにする必要があります。

紹介サイト、GitHub、READMEの役割を常設の入口として整理した

公開後の入口は、一つのページへすべてを詰め込まず、読者の目的に合わせて分けました。画面と利用イメージを短時間で確かめる場所、ソースコードと最新状態を確認する場所、実際の導入手順を読む場所では、必要な情報の細かさと更新頻度が異なるからです。

紹介サイト は、どのような画面で、何を読むためのアプリかを把握する入口です。GitHub公式リポジトリ は、公開ソース、変更履歴、ライセンス、Issuesへの入口を担います。README.ja.md には、必要なNode.jsとpnpm、起動手順、安全上の注意、現在の制約をまとめています。

開発経緯を扱うこのページは、機能一覧や導入手順だけでは伝わりにくい判断の理由を補います。「なぜ通常閲覧を書き込み不可にしたのか」「なぜElectron版からブラウザ版へ方針を変えたのか」「なぜ2つのAI EntryをComing soonにしたのか」を知ると、現在の制約が単なる未完成部分なのか、意図した境界なのかを区別できます。

それぞれの入口を分けても、事実関係が食い違っては意味がありません。バージョン、対応環境、導入条件、AIが扱う情報は、実装とREADMEを基準に更新し、紹介サイトは利用判断に必要な要点へ絞ります。役割分担は情報を隠すためではなく、必要な詳細へ最短で到達できるようにするためです。

ブラウザ版が追いついた後、追加機能をElectron版へ逆輸入する流れが生まれた

ブラウザ版の開発当初は、先に動いていたElectron版が手本でした。表示方法や操作の判断を参照できたため、Electron固有の部分を除きながら、必要な機能を順に移せました。この土台があったことで、ブラウザ版は比較的早くElectron版と同じ水準まで追いつきました。

興味深かったのは、その後に開発の向きが逆転したことです。不特定多数の利用者や複数の環境を考えるブラウザ版では、新しい設定、AI Entry、表示機能、安全確認などを先に実装する場面が増えました。ブラウザ版で動作と境界が固まった後、その成果を元のElectron版へ移す流れが生まれました。

最初はElectron版からブラウザ版へ実装を移していたのに、途中からブラウザ版が先行し、Electron版へ「逆輸入」する。私にとっても面白い経験でした。公開版を派生版として固定せず、利用者の範囲が広い側で先に設計を鍛えた結果、元の製品版にも改善を返せるようになりました。

この逆転は、最初から計画していた開発方式ではありません。ブラウザ版をElectron版へ追いつかせることが当初の目標であり、同じ位置まで来た後もElectron版が先行し続けると考えるほうが自然でした。ところが、公開に必要な設定や安全確認をブラウザ版で考えるうちに、そちらで先に解決した問題をElectron版でも使いたい場面が増えていきました。

ブラウザ版はElectron版の派生ではなく、互いに改善を返せるもう一つの開発線になりました。 公開版で得た知見が製品版へ戻り、製品版で試した閲覧体験が公開版へ移る。この往復ができるようになったことは、OSS化を決めた時点では予想していなかった結果です。

二つの版の関係を整理すると、最初の移植と、その後の逆輸入という二方向の流れになります。

上側の矢印は、Electron版で育てたファイルツリー、各形式の表示、Gitの状態確認を公開版へ移した流れです。下側の矢印は、公開範囲で鍛えた設定、AI Entry、安全確認をElectron版へ返す流れを示しています。

実装の移動は常に一方向ではありません。たとえば、後からMemo機能のライブマークダウン表示をブラウザ版へ移したときは、Electronのアプリ殻や個別環境に依存する設定を持ち込まず、必要な中核部分だけを選びました。両方を分けているからこそ、機能ごとに適した向きを選べます。

二つの版を分けた目的は、同じコードを二重に持つことではありません。Electron版には個人利用と製品版の都合があり、ブラウザ版には公開OSSとしての説明責任と幅広い環境への配慮があります。それぞれの境界を保ちながら、有用な実装を相互に戻せる関係になりました。

「読む」を中心に、AIを任意にする境界は現在も続いている

現在のLocal Reader Appは、手元のフォルダを別のサービスへ移さず、自分のコンピュータ上のブラウザで読むためのOSSです。通常閲覧では登録したフォルダのファイルを書き換えず、AI Chatを使うかどうかは利用者が選べます。AI以外の閲覧機能に、AIサービスのアカウントやAPIキーは必要ありません。

開発の途中では、編集を外した初期版、有料販売を想定したElectron版、OSSとして公開するブラウザ版、4つのAI Entry、アプリ側で変更を検査する保護付き編集を順に試しました。採用した案だけでなく、期待通りに編集できなかった方式や、初期公開から外した機能も、現在の境界を決める材料になっています。

この経緯から得た教訓は、機能を足す前に、その機能が越える境界を決めることです。特にローカルファイルとAIを同じ画面で扱う場合、便利な会話UIより先に、読み取り範囲、書き込み条件、失敗時の挙動、利用者が確認する場所を決める必要があります。公開時点では、 Codex CLIを提供し、Claude Code CLIは実環境での互換性未確認、AI APIとLocal AIはComing soonと明示する ことが、その条件を満たす選択でした。

Local Reader Appは無償のOSSで、ライセンスは Apache License 2.0 です。有償製品に相当する個別の導入支援やサポート契約は含まれません。重要なフォルダで使う場合は、登録する範囲、実行するコマンド、必要なバックアップを確認してください。

画面と利用イメージは紹介サイトで、導入条件と最新の制約はGitHubとREADMEで確認できます。最初の課題だった「読むためだけにエディタを開き直す状態」から離れたい人にとって、Local Reader Appが新しい入口の一つになれば幸いです。