ソフトウェアのEmacs化
(sockpuppet.org)- AIエージェント によって個人向けネイティブアプリを数時間で作れるようになり、ソフトウェアはEmacs的なカスタム構成の領域へ移りつつある
- MDV.appはmacOS向けの Markdownビューア で、検索・SQLite FTSインデックス・ブックマーク・目次・位置記憶を数時間で実装した
- Electronアプリがそれぞれ Chromiumのコピー を抱えている問題と、ネイティブUI開発の難しさは大きかったが、ClaudeはSwiftUIを巧みに扱う
- Emacs文化のように、それぞれの不便を解決する 超特化ツール が増え、完成品よりもアイデア・観察・プロンプトの価値が大きくなる
- エージェントコーディングはサイドプロジェクトやターミナルツールに 使いやすいUI を付けやすくし、ネイティブUI制作を楽しい作業へ変えてくれる
Markdownビューアを自作した理由
- ソフトウェア開発で Markdown はLLM以前から共通語のように使われており、エージェント以後はTUIツールが再び増えたことで、ターミナルでMarkdownを延々とスクロールして読む体験がさらに耐えがたいものになった
- TUI MarkdownビューアにはCharmの glow、Joshが作った Markless があり、Marklessは目次ナビゲーションにも対応しているが、ターミナルはたいてい 等幅フォント のため長時間読むには疲れる
- macOSには Obsidian、Typora、Bear のようなグラフィカルUIのMarkdownエディタがあり読みやすいが、どれも エディタ なので
.mdファイルを開いた瞬間に既存の編集環境やウィンドウ配置が崩れてしまう - App StoreのMarkdownビューアは最初は良さそうに見えても、実際に使うと検索がなかったり、アプリ内課金があったり、選択したテキストをクリップボードにコピーできなかったりする問題が見えてくる
- 2026年には、ほどよいビューアを探し続けるより、自分が欲しいMarkdownビューアを AIエージェントで生成 できると判断して方向転換した
Claudeで作ったMDV.app
- MDV.app はApp Storeで見つけた専用Markdownビューアより良い水準のものを数時間で作れ、実際のインタラクション時間は約 30分 だった
- 古いMacBookにXcodeとgitを設定し、Claude環境を整え、SwiftやmacOSデザイン関連の助けを調べておく事前準備は数週間前から進めていた
- MDVが最高のmacOSアプリケーションでも、特別に有能なソフトウェアでもないが、専用のmacOS Markdownビューアとしては十分に優れており、生活の質を大きく改善した
- MDVの主な機能は、文書での テキスト選択・コピー、固定文字列検索、編集可能な履歴内のすべてのMarkdownファイルに対するSQLite FTSインデックス、ショートカットブックマーク、目次ナビゲーションだ
- 文書間を行き来するときに位置を記憶し、再起動後も続きから開けて、カラーテーマと読みやすいタイポグラフィを提供するため、
.mdファイルをクリックすると望んでいた読書環境がすぐ開く
Electronの限界とネイティブUIの変化
- Signalのメッセージが来るたびに画面が点滅し、Signalアプリを明示的に隠すまで止まらず、その微妙な点滅が偏頭痛の一歩手前まで続いた
- この現象はSignalが Electronアプリ だからで、見た目はネイティブなmacOSアプリでも、実際にはChromiumのコピーが秘密のWebページをレンダリングしている構造だ
- この10年で登場したほぼすべてのUIアプリは、それぞれ Chromiumのコピー を持ち歩いているように見え、Electronはベストではないが十分に実用的な選択肢として生き延びてきた
- 本物のネイティブUIを作ることは歴史的に難しく、その仕事を任せられる平均的な人材を見つけることすら難しく、有能なmacOSネイティブUI開発者はまれだった
- Claudeは並のSwiftUI開発者を置き換える程度を超え、実際に SwiftUI を巧みに扱う開発者だと見なせる
Emacs文化がソフトウェア全体へにじみ出す方式
- MDVはインストールして使ってもらう完成品というより、Emacsユーザーが光る
.emacs設定を見るように、アイデアを盗んでもっと良いものを作る対象として捉えるほうが近い - Emacs文化では、長く使っているユーザーがelispで、テキスト編集から始まった個人的な不便を解決するアプリケーションを作り、その道具はテキストエディタが担うべき合理的な範囲を超えて拡張される
- /r/emacsはProduct Hunt式の製品宣伝より 見せる文化 に近く、広く使われるelispパッケージもあるが、Magit を除けば各自がより光るバージョンとして作り直す傾向が強い
- Emacs文化の弱点は、Magitを除くパッケージがおおむね見た目が悪く遅く、elispを長く使った後でなければ気づけないような悪いユーザー体験を持っていたことだった
- AIエージェントはこの文化をEmacsの外へ押し出し、画面と入力にアクセスできればネイティブUIを安定して作れるようになったことで、ネイティブUIは専門的にパッケージ化されたプログラムの領域から 個人向けカスタム構成 の領域へ移っていく
個人向けネイティブツールの可能性
- Emacsification されたソフトウェアは大半が作った本人にしか役立たない個人ソフトウェアであり、
.emacsの中に残った古いelispプログラムのように忘れられる道具が増えていくだろう - ときには、こうしたプログラムが境界を越えて複数の人がインストールするほど有用になることもあるが、その場合でも最も重要なのは配布された成果物やソースコードではないかもしれない
- エージェントがSwiftUIコードをすべて書いたのなら、ソースコードを詳しく読むことよりも、「こういうものも作れて、しかもうまく動く」という アイデアと観察 のほうが重要になる
- この種のソフトウェアでは、ソースコードより プロンプト のほうが価値を持つかもしれず、自分でソフトウェアを回して作ることに慣れた人にとっては、あらゆるものが技術的にだけでなく実用的にもプログラム可能になる
- エージェントで作ったソフトウェアを「ビルドした」と呼ぶには投入した労力が少なすぎる感じがあり、実際の感覚は、突然はるかに設定可能になったプラットフォームの上で 構成(configuring) していることに近い
- AIを使う開発者たちは、数年にわたって積み上げてきたランダムなサイドプロジェクトをついに終わらせつつある
- いまやそうした超特化ツールも、ただ完成するだけでなく 使いやすいUI を持てるようになり、EmacsのぎこちないUIを我慢しなければならないという従来の理由の一部を弱めている
- ターミナルアプリをはるかに簡単に改善できる可能性が高まり、
iostatや複数ホストにまたがるiostat、bpftraceのようなツールも、より理解しやすい形にできる - Brendan Greggが
bpftraceのターミナル可視化のために受け入れなければならなかった複雑さは、もはやそのまま我慢する必要がなく、実際に 自作した例 もある - 脆弱性研究者として、2026年上半期におけるエージェントコーディングベースのエクスプロイト開発の進展は興味深かったが、多くの人にとっては恐れを伴う変化でもあり、ネイティブUIを作ることが楽しくなったという変化は、純粋に良い知らせにかなり近い
- 自分の問題に合わせた 過度に具体的なツール を作ってしばらく楽しんだあと、共有するか、あるいはもっと良いのはスクリーンショットと使ったプロンプトを共有することだ
1件のコメント
Hacker Newsの意見
今では大半があらかじめパッケージ化された専用ソフトウェアになっている領域を、そろそろ nerd たちが取り戻してもいいと思う。たとえばポッドキャストアプリ、音楽再生アプリ、フィードリーダー、Blueskyクライアント、ノートアプリ、デスクトップのブックマーク／あとで読むアプリ、チャットやメッセンジャー、時間追跡ツール、レシピ管理のようなものだ
Claude を使えば、代替品より良い結果を十分に得られる。最高峰や世界レベルで競争力のあるアプリではなくても、自分だけの変わった作業スタイルにはるかによく合うアプリは作れる
Music.app は使うのがつらいが、Apple はずっと前に中核機能を MusicKit に切り出している。今や本当の製品はMusicKitなのに、なぜまだ Music.app を使っているのかわからない。これは新しい変化だ
それに向けた実験が https://github.com/dharmatech/9social だ
最初のクライアントは plan9 向けに書いた。そうすることで設計が誠実に保たれる。plan9/rc/acme で動くなら筋が通っている
動画デモは https://youtu.be/q6qVnlCjcAI で、現在の実装はコード 3000 行未満だ
Emacs の話で言えば、9social は Org Social という Emacs プロジェクトから大きな影響を受けている: https://github.com/tanrax/org-social
時間を入力するための未完成なスプレッドシートベースのインターフェースだ。コンサル向けに作ったが、データ保存まではできていない。人が自然に時間を入力するほぼあらゆる方法を扱えるかわいいアルゴリズムがあって、既存の時間追跡ツールが構造化入力を強制するのが嫌で作った: https://stackoverflow.com/a/49185071/59087
レシピ管理: https://repo.autonoma.ca/repo/recipe-fiddle
LLM 時代には、材料を分類して PDF 出版用の TeX に整形するのはずっと簡単になるはずだ。このプロジェクトのアイデアは、Web レシピや手書きスキャンをほぼコピペするだけで自動整形させることだった
F-Droid にはこの条件を全部満たすアプリがなかったので、ただ自分で APK を作った
LLM 時代のおかげでソフトウェア生産があまりにも簡単になり、すべてが**.emacs ファイルのようになったと思う。つまり各個人が、完全に私的で無限にカスタマイズ可能なソフトウェアの繭を持つようになる
OP の言い方を借りれば、既存のものをインストールしたり学んだりするより、自分の解決策を作るほうが簡単になった
Lisp も良い比喩だ。Lisp マクロへの古い批判は、すべてのプログラマが自分だけの私語に変えてしまい、他人が読めなくなるというものだった
Mark Tarver の 2007 年の文章 "The Bipolar Lisp Programmer" も思い出す: https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
彼は "brilliant bipolar mind" について語っていたが、最近皮肉でも本気でもよく出てくるAI psychosisとも興味深くつながっている
Tarver の文章 https://www.marktarver.com/bipolar.html には、Lisp コミュニティの "throw-away design" が BBM にぴったり合うとある。Lisp は何かをあまりに気軽に作り捨てできるので、各人が自分の解決策を作り、それが自分に返ってくれば十分だと考える
一方 C/C++ では何か意味のあるものを作るのがあまりに難しいため、それ自体が達成となり、文書化や協業の動機が生まれる。雇用主の立場では、意思疎通し、文書化し、協力できる 10 人のほうが、代替しにくい Lisp ハッカー 1 人より魅力的だ
生産が簡単になると消費がボトルネック**になり、共有が難しくなる。.emacs ファイルは指紋のように個人的なので、断片を取り込むことはあっても、他人のものを丸ごと使いたいとは思わない
こうした繭がよりカスタマイズされるほど、他人が理解したり使いたがったりするのは難しくなる。認知コストも大きいし、他人の服を着るような居心地の悪さもある。これを AI psychosis というより、AI 独我論と呼べるかもしれない
ソフトウェアでは設定管理が難所になりつつある。ソースはどう共有し、どうバージョン管理するのか。そもそもソースとは何か。プロンプトなのか。OP も最後には、コードよりスクリーンショットとプロンプトを共有しようという方向に寄っている
Show HN でも、生成コードはもはやソースではないのだからプロンプトを共有しよう、という観測気球を上げていたが、事情を知る人たちからかなり反発を受けていた: https://news.ycombinator.com/item?id=47213630
GitHub が受ける圧力も、こうした流れゆえに避けられないのかもしれない。後継がどんな姿になるかは不明だが、結局は必要になるだろう。まだ無言の馬車の段階に見える
もっと重要なのはチームワークだ。全員が BBM になるか、各自が自分のためだけに 24 時間生成し続ける狂気の BBM 軍団を抱えるなら、どうやって一緒に働くのか。繭同士はどう通信し、どう相互運用するのか。AI 独我論者たちのチームというのは矛盾のように聞こえる
AI 主導・エージェント型開発の最前線にいるチームやスタートアップは、今まさにこの問題に直面しているはずだ。自分の生成コードとあなたの生成コードをどう合成するのか、という問題だ。こうした摩擦のせいで、生成コードの生産性向上の一部は相殺される可能性が高い
まだ公の場でこういう話があまりされていないのが残念だ。皆、義務的なスタンディングオベーションの中で最初に座りたくないのだろうが、欠点のないただ飯のように装えば、議論は退屈になり、進化も遅くなる
新しい道具で最も真剣で先進的な仕事をしている人たちが欠点を語らないなら、AI はソフトウェア開発に価値がないと見る冷笑的な側にしか、欠点についての話が残らない。人類滅亡よりもバグ増加や生産性停滞を語るほうが難しい空気だ
実際に何が起きているのか、人々がどう対応しているのか、時間とともにどう変わるのかを知りたい。ミートアップのような場に行くべきなのかもしれない
関連論文のタイトルも "Easier to Write, Harder to Read" だった: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
なぜ LLM との特定の対話の産物を読まなければならないのか。話題さえわかれば、自分でもっと良い対話をすればいい
こういうソフトウェアも似ている。多少の好みはあるだろうが、大半はアイデアとレシピが重要だ
月例の "Vibe HN" スレッドがあるといい
それより短い時間で、カスタム WhatsApp を作る動画を共有できるのか気になる。即席メッセンジャーに他人を引き込む問題は、まだ始まってすらいないのだから
今では「このチケットを Claude に投げてみるから、あなたは Copilot でやって結果を比べよう」とか、「自分の粗い結果で PR を作るから、あなたは自分のツールでレビューして」が主流になった。正直ほとんど無意味に感じられるし、ペアプログラミングは完全に死んだ
複数のエージェントを回し、別々の作業ツリーで問題を直し、agents.md の不整合を修正する様子を誰が見たいだろうか
自律的に動く完全自動のクラウドパイプラインを作ろうと強く推しているが、経営陣は静かに抑え込もうとしているようだ。それが本当に飛ぶと証明された瞬間、何人かは居心地のよい地位を失うのが明らかだという単純な理解があるのだろう
UNIX は製品ではなく道具を作り、実問題を解決することに最適化された環境であり、道具は C で書かれていた。その間 BBM たちは Boston で Lisp に夢中だったのだろう
C++ はまったく別の話で、そこには IDE が必要だ
Emacs がそういう性質を持つのは Lisp を使っているからだ。プログラマが皆自分で作り始める一般的な傾向は Lisp で観察され、The Lisp Curseと呼ばれていた
呪いと呼ばれるのは、プログラマたちが協業をやめてしまうからだ。皆が自分の塔に閉じこもった魔法使いになり、全体の進歩が止まり、暗黒時代が来る
LLM 時代のおかげで個人ソフトウェアを作れるようになったのは確かだ
でも正直、Emacs を使っていた時間が個人ソフトウェアの作り方を教えてくれたわけではなかった。自分の Emacs 設定は極端に壊れやすく、Windows と macOS で共用しようとすると悪夢だった
大学プロジェクトは org-mode と何かしらのワークフローを混ぜて美しい LaTeX ファイルを作る奇妙な組み合わせで書いたが、今それをどう再コンパイルするかは説明できない。やるとしたら LLM にそのまま LaTeX へ翻訳させると思う
自分の人生では、できるだけ保守が少ないほうがよく、何でも自作することが常にその目標に合うわけではない
NETFX アプリケーションを Rust に書き直したことはある。インストールに 20 分かかるのが腹立たしかったからだ: https://github.com/bevan-philip/wlan-optimizer
プログラマの日常業務は、ローカル、リモート、クラウド、組み込みなどのコンピュータシステムの振る舞いを変えることだ。要求は変わり、スコープは揺れ、問題空間は進化し、堆積は避けられない
言語スタック、データ型、フォーマット、CLI と Web ツール、プロトコル、パラダイム、オープンソースと独占アプリの間を絶えず移動しなければならない
だから適応し続ける必要があり、自分の制御プレーンも変化に合わせなければならない。要は自動化だ。小さないらだちはすべて自動化できるし、そうすべきだ。それはワークフローを絶えず変形していくこと、つまり道具の継続的な保守だが、苦痛な反応的保守ではない
プログラマでありながら、自分のためのソフトウェアを作り続けたくないというのは思い違いだ。店では火を使うのに、家では包丁も握らない料理人のようなものだ
Emacs は料理人の自宅の台所だ。保守には、壊れたものを直し変化を追う反応的保守と、理解の進化に合わせて道具を形作る生成的保守がある。プログラマは前者を嫌い、後者に惹かれるべきだ
Emacs は道具と仕事が同じ気質を共有しているので、生成的保守にほとんど唯一無二に向いている
Emacs に「設定に手間がかかりすぎる」と不満を言うのはよくあるが、たいていは「価値を得る前に投資したくない」という意味だ。これは長期的には賢い戦略ではない。Emacs はキャリアと生涯にわたる総保守負担を減らす汎用ツールとして見るほうがよい
Emacs や VIM の設定は単なるテキストファイルなので、普通のエディタで開いて必要に応じて直せるし、どこに何があるかもわかる。自分の VIM 設定は 20 年物で、1〜2 年前に手動パッケージ管理をやめてプラグインマネージャを使い始めたくらいだ
ここにはゲートキーパーも依存関係もない
一方で今のやり方は、サードパーティ企業に 20〜200 ドル払うか、ローカル実行のためにかなり強い GPU が必要で、テキストファイルに指示を書き込み、思いどおりになるまで延々と修正し続ける必要がある
これは自分から依存関係を追加しているのであり、人間がレビューしづらいほどもつれれば、その依存は強い依存になるだろう。高価な GPU であれ、株主を満足させなければならない企業にデータを送ることであれ同じだ
この二つがどう違うのか、そして自分たちが払っている本当の代償は何かを見分ける必要がある
個人ソフトウェア、つまり自分のためにプログラムを書くという発想は、1960 年代の家庭向けコンピューティングの本来のビジョンだった
PC が正確に予見されていたわけではないが、誰もが家にコンピュータ端末を持ち、必要なことを行うためのプログラムを書くようになると考えられていた。プログラミングは誰でも学べるほど簡単になると想像されていた
まだそこまでは来ていないが、LLM のおかげで近づいている
非専門家が、よく設計された部品と理解しやすいメタファーを備えたオーサリング環境の中で、面白いソフトウェアを作れるという考え方だ。偶発的だったり過剰設計だったりする複雑性の層は取り除かれていなければならない
このビジョンでもソフトウェアには慎重な論理的思考が必要だが、その思考を実行コードに移す面倒は大幅に減る。ツールチェーンやビルドシステムの悪夢もない
その代わり、自分たちはあまりに強力なモデルを作ってしまい、複雑な呪文を代わりに唱えたり組み替えたりさせている。しかし複雑性は依然として残っており、非専門家にはやはり不透明だ
それでも LLM がその複雑性の一部を取り除く助けになる可能性はある。LLM が生成したソフトウェアを個人が容易に理解し、自分で修正できる方向性はまだ可能であり、LLM 世界ともよく補完し合える
これは可能かどうかの問題ではなく、時期の問題で、長くても 10 年、おそらくもっと早い。すでにコーディングを知らない親戚たちがこういうことをしている
この未来のコンピューティングは本当に愛らしく、ものすごく力を与えてくれる方向だ
現在の Swift アプリは 1.5 万行で、そのうちテストが 5000 行、実装が 1 万行だ。もうほぼ終わっていて、必要なことはできる。20 時間かかった
Swift は未経験だったので、自力で作っていたら個人的には 500 時間はかかったと思う
自分たちの大半は怠け者だから、たぶんそこまでは行かないだろうが、十分考える価値はある
アプリケーションという概念自体が、はるかに流動的になる
アプリが動的言語で作られているなら、ユーザー自身にコードを書き換えさせ、まったく新しい機能を追加させない理由はない
記事本文と直接は関係ないが、ターミナルはほぼ常に等幅なので長文を読むのに疲れる、という話には同意しない。個人的には等幅フォントで長文を読むほうがずっと楽だ
著者は興味深い点を突いている。作用している変数は、道具を作る難しさ、公開する難しさ、他人にとっての有用性、公開したときの社会的報酬、依存関係を増やす負の誘因だ
既製ソリューションを見つけにくくなる度合いは、誰かが作らなければならないコストと、誰かが公開方法を見つけなければならないコストに応じて上がる。逆にコミュニティに有用であるほど、人が教えてくれるので見つけやすくなる
作る難しさと公開の難しさに大きな差があり、とくに作るほうがずっと高いと、人は自分で作って忘れる傾向がある。公開の難しさが低いと、問題解決策はさらに少なくなる
両方が低く、他人への有用性と社会的報酬が依存コストより高ければ、leftpad のような状況が生まれる。NPM の多くのパッケージは、高い有用性と報酬、低い依存コストで成り立っている
Emacs Lisp では、以前は作る難しさが高かったが今は低く、学習曲線を越えれば公開の難しさも低い。有用性、報酬、依存コストもどちらに大きく振れてはいない
すると、道具があるか調べる前に、ただ作ってしまうシナリオが生まれる。VSCode や昔の Eclipse は公開の難しさが高かったので違っていた
自分より若い誰かが、これを論文テーマとして世に出しそうだ
この記事は、LLM コーディングがもたらすまだ実現していない変化の一つを示唆している。そろそろElectron/React Nativeを捨てて、LLM に Figma・ワイヤーフレーム・動作仕様を各プラットフォームの本物のネイティブアプリへ変換させられないだろうか?
CRUD アプリなら、API 仕様と UI モック、さらにはすでに実装済みの別プラットフォームの画面写真だけでも、かなり先まで行ける。こうした定義の明確な作業は LLM が得意な種類だ。同等性テストもかなりの部分を自動化できるはずだ
「いつか Android も追加するかも」や「Mac/Linux ユーザーは十分多くない」といった言い訳は、まだ通用するのだろうか。iOS アプリでパスワード再設定のような利用頻度の低いフローを実装せず、適当な WebView を開くことも正当化できるのだろうか
デバイス内にそれなりのロジックがあるアプリでも、LLM は Go や Rust のようなクロスコンパイルしやすい言語への書き換えにかなり可能性を見せている
もっと挑発的に言えば、この時点でなぜSwiftUIを学ぶ必要があるのか? ほとんどの仕事では、SwiftUI の専門性は「Microsoft Word をとても深く学ぶ」ことに近いカテゴリに入っている
そういう時間を注ぐ人たちは尊敬するが、そうするかどうかで結果の差はミリ単位に近い
プログラミング全般についてそう思っているわけではない。ただ、今では一部の言語は、専門化する理由がより複雑になったと思う