Emacs向けClaude Code IDEの統合

 (github.com/manzaltu)
1 ポイント 投稿者 GN⁺ 2025-08-07 | 1件のコメント | WhatsAppで共有
  • Claude Code IDE for Emacsは、Emacs内でClaude Code CLIをネイティブに統合し、強力なAIコーディングアシスタント環境を提供する
  • **Model Context Protocol（MCP）**ベースの双方向ブリッジにより、ClaudeはEmacsのLSP、プロジェクト管理、Elisp関数などの多様な機能を活用できる
  • 自動プロジェクト検出、マルチセッション、診断（エラー/警告）連携、高度なdiff、tab-bar、選択/バッファ追跡など、Emacs向け最適化機能を提供する
  • Emacsコマンドと拡張性を基盤に、MCPサーバー経由で直接コマンドを公開し、カスタムワークフロー連携を実現可能
  • ClaudeとEmacs全体のエコシステム間で深く統合し、クラウドベースのAI支援開発環境を構築する

概要

Claude Code IDE for Emacsは、Claude Code CLIとの連携によりEmacs環境内でClaude AIの機能を最大限活用するオープンソースプロジェクトである。従来の単純なターミナルラッパーと異なり、本パッケージは双方向通信が可能なMCP（Model Context Protocol）ベースのブリッジを提供し、ClaudeがEmacs内部機能を実際に利用できるよう設計されている。LSP、プロジェクト管理、Elisp関数などEmacsの強力なエコシステムと接続し、Emacsユーザー向けの生産的でインテリジェントなAI開発支援環境を実現する。

主な機能

  • 自動プロジェクト検出とセッション管理

    • Emacs標準のproject.elを活用し、プロジェクトを自動認識してセッションを分離
    • プロジェクトごとに独立したClaude Codeインスタンスとバッファを提供

  • ターミナル統合とカラーサポート

    • vtermまたはeatを介したカラーターミナルサポート
    • Emacs内でClaudeと対話可能

  • MCPプロトコルによるIDE統合

    • コード閲覧、シンボル参照、AST解析など、さまざまなEmacsコマンドをMCPサーバーとして公開
    • ClaudeがEmacsコマンドとユーザー定義関数を実行可能

  • 拡張性の高いMCP Toolsサーバー

    • カスタマイズされたMCP toolの追加/定義が可能（例：プロジェクト全体の検索、グローバルリファクタリングなど）

  • コード診断とdiff

    • Flycheck、Flymake連携によるコードエラー/警告の診断情報提供
    • ediffを用いた高度なdiffビューと診断情報アクセスのサポート

  • 状態/コマンド切り替え管理

    • tab-bar、選択/バッファ追跡などによりClaudeがユーザーの現在コンテキストを理解可能

Emacsツール統合

Claude Code IDEはMCP toolシステムとしてEmacsの様々なコマンドと情報をClaudeに直接公開する

  • LSP統合（xref）

    • Go-to-definition、プロジェクト全体のシンボル/参照探索など、LSPベースのインテリジェントな探索をサポート

  • Tree-sitterサポート

    • 構文木解析とAST（抽象構文木）ベースのコード構造理解を提供

  • Imenu、Project統合

    • シンボル一覧、プロジェクトファイルおよび構造情報を自動提供

  • ユーザー定義Elisp関数

    • MCP toolとして直接公開し、独自ワークフロー/ドメイン特化機能を活用可能

この統合により、ClaudeはEmacsエコシステムの文脈情報を活用し、コードレベルの精密なAI支援を提供できる

使い方

基本コマンド

  • M-x claude-code-ide-menu：すべてのコマンドを視覚的に表示するトランジェントメニューを呼び出す
  • プロジェクト内でClaude Codeを有効化、プロンプト送信、前回の会話を引き継ぎ、各種ステータス/セッション管理を提供
  • 複数のプロジェクトを同時に管理でき、各プロジェクトごとの固有Claudeセッションを運用

ウィンドウとセッション管理

  • 新規セッションが既に実行中の場合は、ウィンドウのトグル/表示機能のみを実行
  • 標準Emacsコマンド（C-x 0）でウィンドウを閉じてもClaude自体は終了しない

設定

  • Claude Code CLI、ターミナルバックエンド、診断バックエンド、ウィンドウ位置/サイズ、デバッグオプションなどの詳細なカスタマイズをサポート
  • フラグ追加、システムプロンプト指定、バッファ命名関数など高度なオプションを提供
  • MCPサーバーの有効化および利用ツール/ポート指定が可能

ターミナルバックエンド設定

  • デフォルトはvtermで、必要に応じてeatバックエンドへ切り替え可能
  • eatは純粋なElispベースのターミナルで、vtermのビルド問題が発生した場合に有用
  • 専用キーバインドを提供（M-RET：プロンプトで改行、C-<escape>：終了/キャンセルなど）

診断/デバッグオプション

  • Flycheck、Flymakeを自動検出/連携、または強制指定可能
  • Claudeターミナルのリフロー（再整列）バグ（#1422）を回避するための一時的なオプションを内蔵
  • EmacsおよびCLIレベルでの詳細なデバッグログをサポート（WebSocket、JSON-RPCメッセージなどを確認）

高度: 複数のworktreeとセッション運用

  • git worktreeを活用し、同一プロジェクト内でブランチごとに複数の独立セッションを実行可能
  • 作業グループごとに固有のバッファとコンテキストを維持し、並列開発ワークフローをサポート

Emacs MCPツールの詳細

組み込みMCPツールの例

  • xref-find-references: プロジェクト内の特定シンボル参照を全件探索
  • xref-find-apropos: パターンベースのシンボル/コード全体検索
  • treesit-info: tree-sitterベースのAST解析データ提供
  • imenu-list-symbols: ファイル内のすべての関数・変数一覧を出力
  • project-info: 現在のプロジェクトメタ情報/ファイル情報を提供

ユーザー定義ツールの追加

  • ユーザーは自身のEmacs関数をMCP tool形式に従って追加可能
  • 例えば、ripgrepを用いたコード検索ツール、特定ドメイン専用コマンドを定義し、Claudeから直接呼び出すことができる

ライセンスと関連プロジェクト

  • GNU GPL v3.0以上で提供
  • 関連プロジェクトとして、VS Code、Neovim（claudecode.nvim）統合プラグインなどが紹介されている

重要性と利点

Claude Code IDE for Emacsは従来のLLM/AI統合ツールとは異なり、Emacs内の固有の作業コンテキストとエコシステム情報を積極的に活用できる強力なAI IDE環境を提供する。
比較的初期段階であるにもかかわらず、様々な内蔵機能、高いカスタマイズ可能性、マルチプロジェクト対応を備えており、Emacsユーザーとオープンソース開発者にとって非常に強力な選択肢となる

関連記事

1件のコメント

 
GN⁺ 2025-08-07
Hacker Newsのコメント
  • LSPやtree-sitterのように、Claude CodeやAiderのようなAIコーディングツールは、EmacsやVimのようなニッチ向けエディタにとって非常に心強い。以前のように高度なIDE機能を自前で実装しようとする必要がなく、こうしたツールと簡単に連携して、各自の編集体験の差別化に集中できる。実際、こうしたカスタマイズと柔軟な連携が、これらのエディタの競争力をかなり高めてくれる。
    • LSPのように、エージェント型のコーディングツールをエディタに簡単に統合できる標準があるのか気になっている。
    • 昔からそう思っていた。EmacsとVimは昔から高度なIDE機能を備えてきた。LSPとtree-sitterのおかげで、今はエディタと各言語をまたぐ標準化がずっと容易になっている。
    • EmacsとVimがニッチエディタだという言い方には賛同しない。すでに主要なエディタだ。
  • EmacsはAIエージェントにとって最高のエディタだとずっと思ってきた。エージェントがエディタの状態を簡単に丸ごと覗け、elispで挙動まで変更できる。VimやEmacsレベルのカスタマイズを許すエディタは、これからも大きな優位性を持つと思う。
    • VimやEmacsは実際に常に大きな強みを持っていたと感じる。価値判断は人によって違うが、個人的にはVSCodeやIntelliJのクローズドな拡張性が大きなデメリットだ。クローズドというのは、制約のあるプラグインAPI、サンドボックス実行環境、企業の承認フロー、内部ロジックの不透明さなどを指す。以前は新機能を探して別のIDEに移ろうとしたが、今はEmacsを学ぶだけで自分の目的により近づけるように感じる。Emacsで問題解決するほうが、IDEを使うよりずっと満足感が高い。
    • Emacsの強みはLispインタープリターコアにある。AIエージェントはランタイムでユーザーが使うのと同じ評価メカニズムでエディタ全体の状態を直接覗き込み、変更できる。大半のエディタは、プラグインAPIが硬く固定されているだけだ。
  • claude-code.el プラグインを快適に使っている。純粋なターミナルラッパーだが、強力なTransientメニューも提供してくれる。Emacs内でだけ動かすだけでもワークフローの効率はかなり上がる。以前のiTerm環境より、ずっとカスタマイズされた流れを簡単に作れるようになった。今後出てくるパッケージも引き続きよく見ていく予定だ。 eca-emacs も楽しみ。生産性を左右するツールは導入初期に慎重に入るタイプで、たいていは大きなプロジェクトがかなりの仕上げを必要とする「ビッグバン」フェーズを経験する。
    • 少し使ってみたが、結局はまたターミナルでclaude codeだけを使うことになった。Emacsでは少しもたつく感じがあり、わざわざ別にターミナル窓を使う理由がなかった。mcp.elパッケージと連携しないのも残念だった。実際、claude codeを試したとき、私の業務では使えるレベルのコード品質まではまだ持っていけなかった。mcp.el も参考になる。
  • EmacsがLSP、tree-sitter、そしてClaude Codeのような最新ツールを統合する流れは嬉しいが、同時にセットアップの難易度が本当に上がったと感じる。20年目のEmacsユーザーだが、最近は環境構築が簡単ではない。Claude CodeはIDE統合以前のほうが最も簡単だったように思う（そのまま動き、バッファの自動同期で気にすることがほとんどなかった）。新しいmacOSではtypescript-lsはどうにか動いたが、goplsはまだダウンロードできていない。1〜2時間あれば修正できそうだが、どこで詰まっているか探すのが手間だ。最近のEmacsユーザーがどうしているのか気になったので共有している。最近はZedで楽しくコーディングしている。20年分のEmacs適応力を手放すのは簡単じゃない。Emacsの小さな設定ファイル編集から大規模プロジェクト支援、そして超高いカスタマイズ性は依然として特別だ。NeoVimのほうがこの方向で優れているかどうか気になる。elispデバッグをもっとちゃんと学べば、私が使うコマンドが環境でどう動くかをもう少し理解できるのか悩んでいる。これまでEmacsのキーバインド（Dvorakまで！）に慣れてきたので、Neovimの感覚はまた違ってくるだろうかと心配でもある。
    • elispデバッグは必ずおすすめする。数十年Emacsを使っていても、組み込みプロファイラー、edebug、apropos、マクロ拡張、advising system、indirect bufferなどを知らない人は多い。Emacsを車に例えると、走行中にパーツを組み替えて潜水艦にまで変えられる機械だが、当然基本的なトラブルシューティングと予想外の状況を受け入れる姿勢が必要になる。問題点をすぐ見つけて、gptel bufferでhookやadvise関数向けのelispを書いてすぐ試せるが、その解放感は体験してみないと分からない。最近は「クリーンな」設定維持は気にせず、モジュール化だけはきちんとしておいて必要なときにelispを追加している。ほとんどは他パッケージの更新など外部要因で壊れるだけで、むしろ原因を見つけ代替手段を用意するのは数分で終わり、頻度も高くない。
    • 環境問題を管理するためにEmacsをDocker環境で回している。 emacs-native-dockerfiles を参照するとよい。
    • 新しい言語エコシステムをEmacsに統合するには、パッケージと外部ツール（LSPサーバーなど）の選定自体がかなり手間だ。dabblingレベルのプロジェクトも多く、毎回考える必要がある。実際、外部ツールのダウンロード/インストールにはNix（devenv.sh）、direnvなどを使ってEmacsが直接ダウンロードしないよう、パスだけを設定している。関連設定ファイルもdevenvに保存して、チームメンバーも同じ環境を使えるようにしている。
  • 8年目のEmacsユーザーだが、2か月前から完全にnvimへ移行し、一か月間はEmacsを全く起動していない。lazy.vimを入れてAIプラグインを交互に使っている。nvim側のエコシステムとコミュニティは最近ではむしろもっと活発で、ThePrimeagenも参考になる。
    • Neovimの経験もずいぶん進化した。bareboneからフルIDE機能まで幅広く設定できるし、事前設定済みのディストリビューションも多い。lazy.vim系を試すなら LazyVim が参考になる。AIプラグインは awesome-neovim #ai も参照。
  • org modeとのさらに強力な統合、または全体的なノートテイキング関連のAI機能がより必要だ。GitHub Copilotは30日を過ぎると会話履歴を消してしまうため、AIで知識ベースを構築する際に大きな支障があることを身をもって感じた。Googleのnotebookllmのように、研究と記録をローカルで直接管理できる方式が強く必要になる。
    • gptel-modeを使ってみることをおすすめする。会話がorg bufferに保存され、セッションを簡単に保存・復元できる。mcp.elとも相性がよい。
    • ob-aiderも参考になる。ob-aider
  • mcpサーバーに自由にツールを追加できる機能が非常に満足だ。まさにEmacsらしい。何年も使ってきたものの、最近はelispをさらに頻繁に自分で書いている。Claudeはelispを生成するサポートもかなりよく、より頻繁に使うようになった（時々括弧のインデントは自分で修正する必要があるが、全体的には良い）。Steve Yeggeのefritも必ず使ってみるつもり。エージェントが任意のelisp式を使って実行する機能は、Emacsの限界を一段階引き上げる。
    • 長年のYeggeファンでフォロワーでもある。まだVibe Codeのハニー月（honey moon）だと思うが、Emacsの力量は誰よりも際立っている。1〜2年前から、大型LLMがEmacs Lispに妙に強いことに気づいていて、これがハイパーモダンなプロジェクトの発端だった。efritもとても有望だと思う（まだ完璧にセットアップできていないが）。
  • 同時に5つ以上のEmacs/Claude Code連携パッケージが登場していて、2、3個はRedditなどで激しく競争しているのを見るのが面白い。しかし実際に優れたプラグインは静かに存在していて、誰も言及していないように見える。yuya373/claude-code-emacs パッケージは競合の機能をほぼすべて実装している。
    • 人気がどれくらいあるかは分からないが、インストールは一番簡単そうに見える。melpa claude-code を見て。
    • ただそのパッケージには、claude-code-ideの/ide統合がないようだ。
  • eca もぜひ試してほしい。EmacsでAIペアプログラミングの最強ツールを作ることに力を入れている。
  • 最近Emacsコミュニティで、このAI統合の議論自体を批判する雰囲気を感じているが、正直言ってその反応はメリットよりデメリットが大きいと思う。AIが現世代と違う進み方をしていても、Emacsの源流はMIT AI Labにある。AI working groupで始まったツールにAI統合を渋る雰囲気はおかしく思える。
    • Emacsの良さはユーザー中心の制御にある。Elispレイヤーで望むものは何でも変更できるため、この種のパッケージが次々出現する。一方VS Codeは構造的に分裂を誘発する。Microsoftは独自ツールには専用APIを使い、外部にははるかに限定的な拡張APIしか出さないため、無数のvscodeフォークが生まれる。Emacsでは、熱量と実力のあるEmacs Lispデベロッパーが一人いれば何もかも変更でき、新しいAI/LLM連携モジュールもいくらでも出現可能だ。Emacsコミュニティの批判も多少大げさな部分があると思う。実際、AI/LLM関連プラグインも着実に出てきて良い反応を得ている。例えば gptel を推したい。
    • この空気の原因はリチャード・ストールマンだと思う。彼はフリーソフトウェアプロジェクトが準備できていない状況で「非フリーソフトウェア」の代替を統合するのは避けるべきだと考える。こうした姿勢がGCC拡張、LLVMデバッガ、tree-sitter、git/bzr、CIビルドファームなど複数の意思決定で採用が遅れることを招き、その間、Emacsのような中核プロジェクトの代替採用速度だけが鈍化した。結果としていつも後から受け入れることになる。時にはFSFの地位を守ろうとする姿勢にも見えた。
    • Emacsコミュニティは非常に多様だ。どこにでも批判はあるが気にしなくてよい。サードパーティのモジュールで望みの機能をいくらでも追加でき、コアメンテナーが阻止する方法がない。
    • MIT AIラボが現代AIブームとつながっていることを初めて知ったが、面白い。
  • この種のツールは本当に期待している。EmacsとAIをコーディングフローに組み込むのが好きだ。だが何より、これを$2000以下のコンピュータでローカル実行したい。今か近い将来に可能かどうか、ローカルモデルでコーディングするエージェントを実際に使っている人がいるのか知りたい。
    • メモリ効率の高い推論やオープンソースのコード特化モデルは劇的に進歩している。最近は Qwen3-Coder 系列のモデルがかなり注目されている。OllamaやLM Studioなどのツールを使えばローカル実行できる。モデルサイズや量子化量で差はあるが、$2000の予算ならかなり多くのモデルを回せる。MシリーズMacもコスパが良い。ローカルLLMの活用情報は LocalLlamas サブレディットに多数ある。大規模AI研究室レベルとは差があるが、完全ローカル構成を好むなら十分に面白く、試してみる価値があるプロジェクトだ。
    • gptelはローカルを含むさまざまなモデルをサポートしている。
    • MacMiniや frame.work desktop、あるいは Nvidia DGX Spark も選択肢だ（最低3k）。