前回のあらすじ：絶滅危惧種とされるEmacserは機能豊富なIDEと引けをとらぬ開発環境をEmacsで実現して我が道を進む

絶滅なんかしてませんよ。今でも健在な頑固Emacser、今度こそAIの台頭によって駆逐されたに違いないと思っていたあなたに一矢を報いて参ります。

古参エンジニアにEmacsとAIの接点は？と聞くともしかしたら元祖AIセラピストのELIZA（M-x doctorで実行）を思いつくのかもしれませんが、そんな話ではありません。

意外かもしれませんが、Emacs界隈ではAIがかなりホットな話題になっており、LLMをEmacsの中で快適に使えるパッケージが続々登場しています。

copilot.el: GitHub Copilotはより賢い入力補完という形のLLMインテグレーションということもあり、API提供の発表早々からEmacsパッケージが爆誕していました。
gptel: 2023年の春から発足した“LLM何でも屋”パッケージ。メジャーなLLMプロバイダに対応していて、様々なEmacs機能と親和性高く使えるようにしてくれます。
org-ai: 機能が豊富すぎて簡潔な説明がほぼ不可能ということで有名なOrg Modeですが、その中でLLMを快適に呼び出す特化型インテグレーションです。
aidermacs: Claude CodeやOpenAI Codexなどは今では言わずと知れたコーディングエージェントCLIツールですが、それらが主流になる前にaiderという先駆けがあり、今でも健在です。aidermacsはaiderをEmacsのコア機能とインテグレートすることでコンテキストを細かく制御したり快適に指示したりできるようにしてくれるパッケージです。
llm.el: LLMを呼び出すためのライブラリパッケージ。Emacsユーザーが直接使うのではなく、LLM駆動の機能を提供する別のEmacsパッケージが使うものです。
他にもたくさんありますが、拙者の知見を超えてしまうため割愛させていただきます

Emacsと現代のAIは無縁かと思いきやそうでもないのは明らかですが、そのストーリーにはいくつか重要なテーマが含まれているので語らせていただきます。

まず拙者はどちらかというとAI懐疑派です。コーディングエージェントの変遷を見ると、最初はIDE組み込み型（Cursorなど）から出発しているという印象を受けます。モデルやツールの性能はまだそこまでではなかったということもあり、当時の拙者はEmacsから乗り換える気がゼロだったのでスルーしました。

コードをLLMに書かせるのはいいけど、なんでIDEまで変えないといけないのか？という疑問が拭えないままClaude CodeなどのCLIツールが誕生し世間を風靡しました。世の中のEmacserは内心「やっぱり」とつぶやいたはずです。

無意識にでもEmacserがみな知っている重要な教訓

テキストに勝るものはない
UIが必要なところはTUIで十分
流行り廃りを追う必要はない

テキストに勝るものはない

コードを書くというのはテキストを書くことであり、LLMを間に挟んでも人間からのインプットと最終的な成果物が両方テキストである以上、繋ぎの部分もテキストであることが自然でしょう。

UIが必要なところはTUIで十分

テキスト主体ならば、その一番ユニバーサルなUIであるCLIに帰着するのもごく当たり前の運びでしょう。前回も申したとおり、Emacsとはテキストという形のUI（TUI）でアプリケーションを作るプラットフォームなので、CLIに帰着したならばまさにEmacsの土俵です。

エージェントはコンテキストの細かい制御などせずに自力でよしなにやってくれる前提の方向に進化していますが、仮に逆の方向だったとしても、Magitという神git UIの例からして、その細かい操作はEmacsの中でテキストベースで快適に行うパッケージが現れるのは時間の問題だったはずです。

流行り廃りを追う必要はない

毎月と言わず毎週のように目紛しい勢いで進化するAI界隈なので10年というスパンはとてつもなく長く感じられるかもしれませんが、VSCodeのプラグインやVSCodeを丸ごと改造した形のエージェントツールの数々は、10年後まだ存在していますか？軒並み提供終了となったその暁には、Emacsはまだ健在でしょう。

（その頃コードをローカルで開発せずに完全にクラウドで動くエージェントで書いてるよ、という方に問います。そのエージェントにどうやって指示をして結果を確認していますか？テキストですか？テキストであればEmacsの土俵です。）

Emacs界隈の分断

Emacs界隈はAIの楽園で何事もお花畑かというとそうでもないのです。Emacsの世界はコアの開発を行っている“本丸”と、自由奔放に何でも思いつくままパッケージを作っている“下界”に分けることができ、その両サイドはEmacs愛好家である以外にほぼ共通点がないと拙者は感じております。

本丸はC言語によるEmacsのコアと、標準搭載のElispパッケージの開発を手掛けている古株中の古株。下界と決定的に違う点は、

自由ソフトウェア主義を貫いている熱狂的な信者である。たとえば自由でないJavaScriptの実行が必要なウェブサイトを使ってはいけない、そういったウェブサイトの使用をエンドユーザーにそそのかすのも憚るからGitHubへのリンクを排除するかしないかが今まさに開発MLで熱く議論されている（2026年2月現在）

対して下界は圧倒的人気を誇るGitHubを中心に開発を行ったり、自由でなくてもありとあらゆるサービスや技術をEmacsに率先して取り込んだり、何か主義を貫いているとすると実用主義だろう。
俗世のソフトウェア開発の動向に疎い。LLMどころではなく、たとえば前回語ったLanguage Server Protocolでさえ標準パッケージとしてLSP対応を組み込むかどうか議論する際に「Microsoftが発明したものは信用ならん」（一応オープンな規格ではあるが、それで安心できるかはあなた次第）「ローカルのコードが遠隔サーバに筒抜けになるのは論外」（serverとはいえ遠隔ではなくローカルで動かすのが普通であることを誤解してなかなか説得されない）というMLでのやり取りを拙者が側から眺めた。

当時の下界ではLSPはすでにベストプラクティスとして幅広く使われて、異なる充実したパッケージが2つあったほどだった（その1つのeglotがEmacs 29では標準搭載パッケージに採用された）。
プライオリティがソフトウェア開発ツールとしての成長とは限らない。今ではEmacs自体の開発はしないもののプロジェクトの音頭をとっているRMS氏は、日ごろ文章を書くニーズが強いため開発ツールよりもワープロ的な機能を充実させていってほしいと度々MLで発言されている。

下界は全員がエンジニアとは限らないが、パッケージを自作するモメンタムが強いのはやはり日々開発に勤しんでいるものたちなので自然とそういう方向に傾いた構成であると拙者は感じる。
上記以外にも文化的な溝がかなり大きい。たとえば開発プラクティスが主流からかけ離れたMLベースになっており、下界から本丸に入る大きな障壁になっている。LSPの件はもちろん、Org Modeが何なのかわからないなど、下界ではEmacsがどのように使われているのか全く把握されていないという印象を与えるコアメンバーの発言も散見される。

こうして並べてみると犬猿の仲のように見えるのかもしれませんが、どちらかというとお互いあまり意識せず、勝手に好きなように活動を続けているという方が正しい気がします。本丸が自由主義を貫いてきたおかげで改悪されたり買収されて廃止されたりせず誕生から40年以上の今でも健在であり、主流とは言い難いながらも多様なユーザー層を誇っています。下界も下界で主義や理論を気にせずありとあらゆる方向に向かってEmacsを未来に引っ張っていっています。