ハクソク

世界を動かす技術を、日本語で。

ソフトウェアのエマックス化

2026年5月13日原文(sockpuppet.org)

概要

  • Markdownビューア の重要性と現状の不満点
  • AIエージェント によるネイティブUI開発の進化
  • Emacs文化 の「Emacsification」が広がる現象
  • 個人向けソフトウェア開発と プログラマビリティ の新時代
  • 今後の 開発体験 とコミュニティの変化への期待

Markdownビューアの必要性と現状の課題

  • Markdown はソフトウェア開発の共通言語
  • TUI（ターミナルUI）ツールの復権による Markdown閲覧体験の悪化
    • 例：glowやMarklessなど優秀なTUIビューアの存在
    • 端末の 等幅フォント による読みにくさ
  • macOS向けの グラフィカルUIエディタ （Obsidian, Typora, Bear等）は読みやすいが「エディタ」であり、環境を乱される問題
  • App StoreのMarkdownビューアは 機能不足や使い勝手の悪さ が目立つ
    • 検索機能やコピペ不可、課金要素など
  • 「まともなMarkdownビューア」を探すのは 時間の無駄 との気付き

AIエージェントによるMarkdownビューア開発体験

  • Claudeなど AIエージェント を活用し、短時間で高品質なMarkdownビューア（MDV.app）を開発
    • 事前準備：Macbook, Xcode, git, Claude設定, Swift/macOSデザイン習得
    • 実装自体は 30分程度の対話 で完成
  • MDV.appの主な特徴
    • テキストの選択・コピー、全文検索、SQLite FTSインデックス
    • ホットキー付きブックマーク、目次ナビゲーション
    • ドキュメント間の位置記憶、カラーテーマ、タイポグラフィ
    • .mdファイルをダブルクリックするだけで快適な閲覧体験

Electronアプリの問題点とネイティブUIへの回帰

  • Electronアプリ （例：Signal）は見た目はネイティブでも実体はChromiumベース
    • 多くの現代UIアプリがElectron依存
    • 画面のフリッカーやパフォーマンス低下 などの問題
  • 本来のネイティブUI開発は 人材難や難易度の高さ が課題
  • ClaudeのようなAIは SwiftUI開発者としても優秀 で、これまでの課題を解決

Emacs文化の拡張と「Emacsification」

  • Emacs文化 ：個人のためのソフトウェアを自作し、他人のアイデアを参考に改善
    • elispで作られたアプリケーションが個人のニーズに合わせて進化
  • Emacsの弱点： UIの醜さ・遅さ・発見性の悪さ
  • AIエージェントの登場で Emacs文化が一般化
    • ネイティブUIも個人仕様で 自在にカスタマイズ可能
  • これからのソフトウェアは「 Emacsified」＝個人仕様・アイデア重視
    • ソースコードよりも プロンプトや発想 が価値を持つ時代へ

個人向けソフトウェアと新しい開発体験

  • AI時代の開発は「 構築(building)」より「 設定(configuring)」に近い
  • 個人の課題解決 に特化したソフトウェアが簡単に作れる
  • 使い捨て・忘れ去られることも多いが、時に 他人にも有用なツール が生まれる
  • 新しい開発体験
    • 副業プロジェクトやニッチなツール の完成率向上
    • 使いやすく、楽しいソフトウェアが増える
  • Emacs自身の存在意義 も相対的に薄れる可能性
  • ターミナルアプリの改善余地 が大幅に広がる
    • 例：iostatやbpftraceの可視化体験の劇的向上
  • ネイティブUI開発 の楽しさと可能性
    • 個人のための「 馬鹿げたほど特化したツール」を気軽に作り、共有する文化の到来

まとめ：今後の展望

  • AIとエージェント技術 による個人向けソフトウェア開発の革新
  • Emacsification によるアイデア共有とプログラマビリティの拡張
  • ネイティブUI開発 の民主化と新しい開発者体験
  • コミュニティの変化 と、より面白い「オタク向けソフトウェア」の増加への期待

Hackerたちの意見

記事は主にスタンドアロンのソフトウェアについてだけど、僕が重視しているワークフローツールの一つは拡張性なんだよね。誰かのneovimプラグインをちょっと試してみて、実際に必要かどうかを判断できるし、必要なら自分の思考モデルにぴったり合うようにカスタマイズできる。自分が欲しいちょっとした機能を追加したり、あまり興味がない便利な機能を取り除いたりもできるし。あと、サプライチェーンの問題についてもあまり心配しなくてよくなった。これまでに、始めた頃に使っていたプラグインの90%を置き換えたよ。それに、面倒なNIH症状からもいい気分転換になるしね。

└

僕も同じだよ。正直言うと、初めて空の設定でEmacsを立ち上げたときは、ひどい見た目だった。でも、プラグインを追加したり、自分の独特なワークフローをサポートするコードを加えていくうちに、だんだん無視できないくらい生活の中で強力になっていくんだ。13年間ずっと手放せなかったよ。AIが開発体験を支配するようになって、Emacsやneovimはさらに良くなった。今はAIに自分のカスタムワークフローを設定に組み込んでもらえるからね。Emacs/neovimはすべてのワークフローツールのゴールドスタンダードであるべきだと思う。

著者はここで本当にチャンスを逃した気がするな。「ソフトウェアのエマクス化」

LLMの時代のおかげで、個人ソフトウェアを作ることに完全に取り組んでるよ。[0] でも正直言うと、Emacsを使っていた時間が「個人ソフトウェアを作る」ことを教えてくれたわけじゃないんだ。僕のEmacsの設定はすごく脆弱で、WindowsとmacOSで使おうとすると悪夢だった。大学のプロジェクトは、org-modeと何かのワークフローを使って美しいLaTeXファイルを作るための、なんとも言えない組み合わせで書かれていて、再コンパイルの方法なんて教えられないよ（もし試みるなら、LLMにLaTeXに翻訳してもらうかも）。僕は生活のメンテナンスをできるだけ少なくしたいし、すべてのことに自分のソフトウェアを作るのは必ずしもそれに合ってるわけじゃない。[0]: NETFXアプリケーションをRustで書き直したのは、20分のインストール時間が気に障ったから: https://github.com/bevan-philip/wlan-optimizer

└

自分の生活はできるだけメンテナンスが少ない方がいいんだけど、すべてのソフトウェアを自分で作るのはそれに合わないこともあるんだよね。だから、LLMは個人用ソフトを作るには十分だけど、維持するにはまだ足りないのかな？

└

「ツールを作る時間がないと言ってる人は、実際には作らない余裕がない人たちだ。」

└

15年間、Linux、Windows、macOSで同じEmacsの設定を使ってる。正直、これがコンピュータライフの中で一番の宝物だよ。

└

自分の生活はできるだけメンテナンスが少ない方がいい。正直、これがどういう意味か全然共感できない。俺はプログラマーだから、毎日の仕事はコンピュータシステムの挙動を変えることなんだ。ローカル、リモート、クラウド、組み込みとかね。要件は変わるし、スコープも揺れるし、問題の領域は進化する。成長したり縮んだり、蓄積は避けられない。言語スタックやデータタイプ、フォーマット、CLIやウェブツール、プロトコル、パラダイム、OSSやプロプライエタリアプリの間をルーチンで移動しなきゃいけない。だから、常に適応し続けなきゃならないし、コントロールプレーンもその変化に追いつかなきゃ。自動化が鍵だよ。そういう考え方を持たないといけない。ちょっとした煩わしさはすべて自動化できるし、すべきなんだ。これは俺のワークフローの終わりのない、止まらない変革だよ。ツールの継続的なメンテナンスなんだ。でも、これは面倒な反応的メンテナンスじゃない。自分のために常にソフトウェアを作りたくないプログラマーだと思うのは妄想だよ。レストランでしかコンロを使いたくない料理人みたいなもんだ。Emacsは料理人の自宅のキッチンだよ。メンテナンスには二種類あると思う：反応的（壊れたものを直す、変化に追いつく）と生成的（ツールを進化する理解に合わせて形作る）。プログラマーは本能的に前者が嫌いで、後者に惹かれるべきだと思う。Emacsは生成的メンテナンスにほぼ唯一適してる。ツールと作業が同じ基盤を共有してるからね。Emacsに関する不満は分かるよ。「設定が面倒すぎる」っていうのはよくあることで、たいていは「価値を得る前に投資したくない」ってことなんだけど、正直それは賢い戦略的思考じゃない。Emacsをキャリアや人生を通じてのメンテナンス負担を最小限にするための普遍的なツールとして扱うのが大事だよ。

「個人ソフトウェア」、つまり自分のために書くプログラムは、1960年代のホームコンピューティングの元々のビジョンだったんだ。PCは本当に予想されていなかったけど、みんなが家にコンピュータ端末を持っていて、必要なことをするプログラムを書くという考えだった。プログラミングは誰でも学べるくらい簡単になると想像されていたんだ。まだそこには達していないけど、LLMのおかげで近づいてきてるね。

└

僕は非コンピュータ専門家として、まさにそれをLLMに使ってるよ。

└

LLMは問題の探求に最適だと思う。特にGoogleの衰退を考えると、タスクを達成するための何かをLLMに出させるのが、実際にインターネットで見つけるよりも難しくなくなってきたと思う。でも、そのタスクが繰り返されるか修正される場合、LLMはプリビルドソフトウェアに対して常に不利だと思う。たとえそのプリビルドソフトウェアが誰かがLLMを使って出力を受け取って、それを受け入れテストに通すだけのものであっても、多くの人は奇妙なエッジケースのデバッグの面倒を避けたいし、「自分も開発者だ！」という新しさはすぐに薄れてしまう。ビジネスクリティカルなロジックを持つエクセルシートの奇妙なグレーゾーンが、LLMがそのロジックを理解できないほど複雑にして、実際のエンジニアリングリソースに押し付けられるのが消えるのは楽しみだ。痛みを伴うかもしれないけど、たぶんそれが最善だと思う…でも、日常的に使う実際のツールについては、そのツールが機能するという保証が、AIの盛り上がりが理解している以上に価値があると思う。

└

まだ取られていない道、それはHyperCardsやVisual Basics、Macromind DirectorsやFlashesの完全な開花だと思う。つまり、非専門家が良く考えられたビルディングブロックと理解しやすいメタファーを使って、著作環境で興味深いソフトウェアを作るというアイデアだ。偶然の複雑さや過剰設計の層を取り除いてね。このビジョンでは、ソフトウェアは依然として慎重な論理的思考を必要とするけど、その思考を実行可能なコードに翻訳するのがずっと楽になる。ツールやビルドシステムの悪夢もなくね。代わりに、私たちのために複雑な呪文を再生産し、再結合できる強力なモデルを発明してしまった。複雑さはまだそこにあるし、非専門家には依然として理解できないけど、もしかしたら彼らがその一部を排除する手助けをしてくれるかもしれない？その道はまだ可能だと思うし、LLMの世界ともうまく補完し合えるかもしれない。LLMが個々の人間がまだ簡単に理解し、手動で修正できるソフトウェアを生成するのを助ける形でね。

Hacker Newsで議論の続きを見る