AIに編集を任せたら、VSCodeを開かなくなった｜Local Reader Appを作った理由
Local Reader App を開発してから、あれほど毎日開いていたVSCodeをまったく開かなくなった。
これは、VSCodeが悪いという話ではない。無料で使えて、多くの機能を備えた優れた道具だと思っている。私も長く使ってきたし、VSCodeを基にしたIDEも含めて、かなり助けられてきた。
ただ、私が日々行っていたのは、プログラミングではなかった。Markdownを読み、ソースコードを確認し、画像やPDFを開き、Gitの変更を見る。
ファイルを編集しない日でも、その入口としてIDEを起動していた。
あるとき、その状態が不自然に思えた。読むだけなら、編集、ターミナル、拡張機能まで備えた綜合開発環境（IDE）を毎回立ち上げる必要はない。
私が欲しかったのは小さなIDEではなく、ファイルを読むことにほぼ特化した場所だった。
ファイルを見るだけなのに、IDEを開いていた
もちろん、Macで使えるファイルビューアはほかにもある。私が知らなかっただけで、優れた製品もあるはずだ。それでも、自分が使い続けたいと思えるものは見つけられなかった。
以前なら、不満があっても既存の道具へ自分を合わせていたと思う。しかし今の時代は、AIと相談しながら自分のためのアプリを作れる。だから「理想のビューアを探す」より、「自分ならどう作るか」を試したくなった。
最初に欲しかったのは、機能の多さではない。よく読むフォルダを登録し、ツリーからファイルを選び、内容と周辺情報を落ち着いて確認できることだった。
Markdown、コード、画像、PDF、Gitの状態が、同じ流れの中で読めればいい。
Local Reader Appは、そこから始まった。自分専用の道具として作り始めたが、毎日使ううちに、自分以外の人にも扱いやすい形へ整えることに意味を感じるようになった。
現在は、ソースを GitHubで公開 している。
AIが編集するなら、人間は「読む」に集中できる
Local Reader Appを単なる軽量エディタにしなかった理由は、私自身がファイル編集をAIへ任せるようになったからだ。
自分で文字を打ち換えることが前提なら、読む場所にも編集機能が必要になる。しかし、変更内容をAIへ伝え、AIが実装し、人間が結果を確認するのであれば、人間側の道具は「読む」と「判断する」に集中できる。
そこで、Local Reader Appの通常閲覧には、汎用的なファイル編集機能を持たせなかった。登録したフォルダを読むだけでは元ファイルを書き換えない。
登録したフォルダへの書き込みが起こり得るのは、利用者がAI Chatを有効にし、対象となるCurrent repoを明示して変更を依頼した場合だけだ。
これは、編集機能を作れなかった結果ではなく、あえて残した境界である。
その代わり、短い誤字をすぐ手で直したい人には回りくどい。デバッグ、ターミナル操作、拡張機能、精密な手動編集が必要なら、IDEのほうが適している。
Local Reader AppはIDEの代替を名乗るのではなく、IDEを開く前からIDEを使い続けるまで、すべてを一つの道具へ押し込む必要はないと考えて作った。
私自身は、編集したい内容を言葉にしてAIへ渡し、変更後のファイルやGitの差分を読む流れのほうが合っていた。その役割分担が定着すると、VSCodeを開く理由がほとんど残らなかった。
直接編集を捨てたことで、道具の輪郭が決まった
直接編集を持たせない判断は、画面の細部にも影響した。
中央には、選択したファイルを読む場所を置く。左側ではフォルダとファイルの関係をたどり、右側ではファイル情報や見出しを確認する。
文章を書き換えるためのボタンを増やすより、今どこを読んでいるのか、どのファイルとつながっているのかを見失わないことを優先した。
AIへ編集を任せるほど、人間が内容を確認する場所は重要になる。指示する前には、何を変えたいのかを理解しなければならない。
実行後には、AIが何を変えたのかを確認し、残すか戻すかを人間が決めなければならない。
「AIに任せる」と「AIへ丸投げする」は同じではない。コードの生成やファイル操作をAIが担当しても、目的、採否、公開範囲、結果への責任までAIへ移るわけではない。
Local Reader Appの開発では、Codex Appを使った。初期はGPT-5.5、その後はGPT-5.6を使い、コード生成と実装作業のほぼ全てをCodexが担った。
私は、どのような道具にするか、何を実装しないか、提案を採用するか、どこまで公開するかというオーケストレーター（総括者）の役割を務めた。
完成図を一度渡して終わったわけではない。実際に使って摩擦を見つけ、Codexへ伝え、直した結果を確かめる。その往復を粘り強く重ねて、少しずつ現在の形へ近づけた。
この記事の構成、下書き、推敲にもCodex Appを使っている。ただし、ここに書いた体験と判断は私が提供したものであり、どの表現を残し、何を公開するかも私が確認して決める。
AIに任せれば、何でもうまくいくわけではなかった
一方で、AIによる編集機能は、最初から期待どおりに実装できたわけではない。
AI APIとLocal AIからもファイルを変更できるように、アプリ側で編集操作を管理する仕組みを試した。対象を登録フォルダ内へ限定し、AIの提案を検査してから反映する考え方だった。
安全に止める仕組みは作れても、さまざまなモデルから、実際に適用できる編集指示を安定して受け取るところまでは届かなかった。
編集方法の基盤を変えて試しても課題が残ったため、初期公開ではAI APIとLocal AIを選べない状態にした。
将来用の項目や実装があることと、いま安心して使える機能であることは別だ。動くように見せるために検査を緩めるより、提供範囲から外すほうを選んだ。
現時点の利用条件と制約は、公開リポジトリの README日本語版 にまとめている。
この失敗は、「AIが編集する」という考えを撤回する理由にはならなかった。むしろ、AIへ任せる範囲を広げるほど、何を任せないか、どこで止めるか、人間が何を確認するかを明確にする必要があると分かった。
詳しい開発順、Electron版からブラウザ版OSSへ移った経緯、公開前に確認したことは、Local Reader Appを公開しました｜「読む」を中心にしたローカルOSSの開発記録 に分けて書いている。
Local Reader Appを作って、VSCodeを開かなくなった
Local Reader Appは、今では私が毎日使う道具になった。ファイルを見るためだけにIDEを起動し、ワークスペースを選び直すことがなくなっただけでも、仕事へ入るまでの感覚は軽くなった。
処理時間やPC負荷を測定したわけではないので、客観的に生産性が何％上がったとは言えない。
それでも、読む場所が一つに定まり、編集はAIへ依頼するという流れができたことで、私は以前より快適に仕事ができている。
だからといって、誰もがIDEを捨てるべきだとは思わない。自分で細かくコードを書く人、デバッガやターミナルを頻繁に使う人、拡張機能を組み合わせたい人には、IDEのほうが向いている。
私が伝えたいのは、別のことだ。毎日使っている道具に小さな違和感があるなら、それを当然の前提として受け入れ続けなくてもよい。
AIを使えば、既存の製品を探すだけでなく、自分が本当に欲しい道具を自分で形にできる。
Local Reader Appのソースは公開している。実装を見たい場合は、自分のPCで動かし、コードについてAIへ質問してみるのも一つの使い方だ。
AIが編集を担えるようになった今、人間に必要なのは、編集機能をすべて抱えた場所だけではない。内容を読み、前後関係を理解し、結果を判断するための場所も必要になる。
私にとって、その場所がLocal Reader Appになった。