Emacs用のClaude Code IDE統合

概要

Claude Code IDE for Emacs は、EmacsとClaude Code CLIを Model Context Protocol (MCP) で統合するパッケージ。 Emacsの強力な機能（LSP、プロジェクト管理、Elisp関数等）を Claudeが直接活用 可能。 プロジェクト単位でのセッション管理 や高度なウィンドウ・ターミナル連携をサポート。 Flycheck/Flymake診断、ediff統合、選択範囲認識 など、Emacsエコシステムとの深い連携。 柔軟なカスタマイズ・デバッグ機能 を備え、マルチプロジェクト運用も容易。

Claude Code IDE for Emacs 概要

Claude Code CLIとEmacs を MCP で双方向接続する統合パッケージ
ターミナルラッパー以上 の連携で、EmacsのLSPやElisp関数をClaudeが活用
Emacs内でAIアシスタント としてClaudeがプロジェクト全体やエディタ状態を把握
プロジェクト検出・セッション管理 を自動化
vterm/eat によるフルカラー対応ターミナル統合
MCPツールサーバ によるEmacsコマンド呼び出し（xref, tree-sitter, project info等）
Flycheck/Flymake 診断、 ediff による差分表示連携
タブバー、選択範囲、バッファ追跡 など、文脈認識強化

Emacsツール連携

LSP（eglot, lsp-mode等） との連携で xref によるコードナビゲーション
tree-sitter でASTレベルの構文解析
imenu によるシンボルリスト・ナビゲーション
project.el 連携でプロジェクト単位の操作
任意のEmacsコマンド/関数 をMCPツールとして公開可能
- プロジェクト横断検索・リファクタリング
- 専用モード・機能へのアクセス
- カスタムElisp関数の実行

画面例・機能

アクティブファイル認識 ：現在閲覧中ファイルを自動把握
選択範囲認識 ：バッファ内選択テキストをClaudeが直接利用
高度な差分ビュー ：ediff連携＋診断データ（エラー・警告等）表示
自動テキスト参照 ：選択範囲をClaude会話内で自動参照
セッション復元 ：--resumeフラグで過去の会話を再開

インストール手順

前提条件

Emacs 28.1以上
Claude Code CLI （PATHに配置）
vtermまたはeatパッケージ （ターミナル用）

Claude Code CLIの導入

公式ドキュメントに従いインストール

Emacsパッケージの導入例

(use-package claude-code-ide
  :straight (:type git :host github :repo "manzaltu/claude-code-ide.el")
  :bind ("C-c C-'" . claude-code-ide-menu)
  :config (claude-code-ide-emacs-tools-setup))

基本コマンド一覧

| コマンド | 説明 | | --- | --- | | M-x claude-code-ide-menu | コマンド一覧のトランジェントメニュー | | M-x claude-code-ide-emacs-tools-setup | MCPツール（xref, project等）のセットアップ | | M-x claude-code-ide | 現在のプロジェクトでClaude Code起動 | | M-x claude-code-ide-send-prompt | ミニバッファからClaudeへプロンプト送信 | | M-x claude-code-ide-continue | ディレクトリ内の直近会話を継続 | | M-x claude-code-ide-resume | 過去の会話を復元 | | M-x claude-code-ide-stop | セッション停止 | | M-x claude-code-ide-switch-to-buffer | プロジェクトのClaudeバッファへ切替 | | M-x claude-code-ide-list-sessions | 全セッション一覧・切替 | | M-x claude-code-ide-check-status | CLIの動作確認 | | M-x claude-code-ide-insert-at-mentioned | 選択範囲をClaudeプロンプトへ送信 | | M-x claude-code-ide-send-escape | ターミナルへEscape送信 | | M-x claude-code-ide-insert-newline | プロンプトに改行挿入 | | M-x claude-code-ide-toggle | Claudeウィンドウの表示切替 | | M-x claude-code-ide-show-debug | デバッグバッファ表示 | | M-x claude-code-ide-clear-debug | デバッグバッファクリア |

マルチプロジェクト対応

project.el による自動プロジェクト検出
プロジェクトごとに 独立したClaudeセッション を保持（バッファ名例：claude-code[project-name]）
複数プロジェクト同時運用 が可能
claude-code-ide-list-sessions でアクティブセッションの一覧・切替

ウィンドウ管理

セッション起動時、既存セッションがあれば ウィンドウ表示をトグル
標準Emacsウィンドウコマンド（C-x 0等）で閉じてもセッションは維持

設定・カスタマイズ

主な変数

claude-code-ide-cli-path : CLIのパス（デフォルト"claude"）
claude-code-ide-buffer-name-function : バッファ名生成関数
claude-code-ide-cli-debug : CLIデバッグモード有効化
claude-code-ide-cli-extra-flags : 追加CLIフラグ
claude-code-ide-debug : Emacsデバッグログ有効化
claude-code-ide-terminal-backend : ターミナルバックエンド（'vtermまたは'eat）
claude-code-ide-use-side-window : サイドウィンドウ利用有無
claude-code-ide-window-side : Claudeウィンドウの表示位置
claude-code-ide-window-width/height : サイドウィンドウの幅・高さ
claude-code-ide-focus-on-open : ウィンドウ表示時に自動フォーカス
claude-code-ide-system-prompt : システムプロンプト追加
claude-code-ide-enable-mcp-server : MCPツールサーバ有効化
claude-code-ide-diagnostics-backend : 診断バックエンド（'auto, 'flycheck, 'flymake）
claude-code-ide-prevent-reflow-glitch : ターミナルリフローバグ回避

サイドウィンドウ例

左側に表示

(setq claude-code-ide-window-side 'left)

下部に高さ指定で表示

(setq claude-code-ide-window-side 'bottom
      claude-code-ide-window-height 30)

通常ウィンドウ利用

(setq claude-code-ide-use-side-window nil)

ターミナルバックエンド切替

eat利用

(setq claude-code-ide-terminal-backend 'eat)

vterm利用（デフォルト）

(setq claude-code-ide-terminal-backend 'vterm)

ターミナルキーバインド

M-RET : プロンプトに改行挿入
C-<escape> : Escapeキー送信

ターミナルリフローバグ回避

デフォルト有効。不要時は無効化可能
```
(setq claude-code-ide-prevent-reflow-glitch nil)
```

診断バックエンド指定

自動判定（デフォルト）

(setq claude-code-ide-diagnostics-backend 'auto)

flycheck/flymake指定

(setq claude-code-ide-diagnostics-backend 'flycheck)
(setq claude-code-ide-diagnostics-backend 'flymake)

バッファ名カスタマイズ例

(setq claude-code-ide-buffer-name-function
      (lambda (directory)
        (if directory
            (format "*Claude:%s*" (file-name-nondirectory (directory-file-name directory)))
          "*Claude:Global*")))

CLIフラグ追加例

特定モデル利用

(setq claude-code-ide-cli-extra-flags "--model opus")

複数フラグ

(setq claude-code-ide-cli-extra-flags "--model opus --no-cache")

システムプロンプト追加例

全体設定

(setq claude-code-ide-system-prompt "You are an expert in Elisp and Emacs development.")

プロジェクトごと（.dir-locals.el）

((nil . ((claude-code-ide-system-prompt . "Focus on functional programming patterns and avoid mutations."))))

デバッグ

CLIデバッグモード （-dフラグ）
```
(setq claude-code-ide-cli-debug t)
```
Emacsデバッグログ （WebSocket/JSON-RPC等）
```
(setq claude-code-ide-debug t)
```
- M-x claude-code-ide-show-debug : デバッグバッファ表示
- M-x claude-code-ide-clear-debug : デバッグバッファクリア

複数Claude Codeインスタンス（Git worktree活用）

git worktree で異なるブランチごとに独立Claudeセッション運用
- 例：
```
git worktree add ../myproject-worktree feature-branch
```
- 各worktreeで Emacsのproject.el が独立プロジェクトとして認識
- Claudeセッションもバッファも独立（例：claude-code[myproject-worktree]）

Claude Code IDE for Emacs は、Emacsユーザーのための 真のAIアシスタント体験 を実現。既存ワークフローに溶け込み、 柔軟なカスタマイズ性 と 高度なEmacs連携 を両立。開発効率と知的生産性を最大化する モダンなEmacs拡張。

Hackerたちの意見

かなりいいね！この戦闘実績のあるエディタ（emacsと(n)vim）が新しい技術に対応してるのが好きだな。年齢的に考えるとそうは思えないかもしれないけど。これがvimにも来るといいな！

└

IDEの技術革新をリードするのが普通で、後追いすることは少ないよね。特にNeovimはそう。

└

Neovimやある程度のemacsは、企業のIDEベンダーがアイデアを得る場所だよ。UXの使いやすさ、パフォーマンス、ポータビリティ、デザインセンス、テーマ作りとか？90年代のSunとGNUみたいな感じ。完璧なHSLホイールや黒のバランスがPMにいじられて怒ってるUI/UXの人たちがいるけど、だからこそGitHubのテーマは素晴らしいけど伝説的ではないんだよね。彼らは家に帰ってArchやNixOSを使って、日常の仕事をバカにする。こういう人たちはアーティストで、ハックする人たちはその後を追う。編集: 僕の黒のバランスは、HSL空間変換を使ってヒーローカラーから計算されてる。NixOSのモジュールツリーから背景をSVGとして自分のソースコードから作り出して、特定のディスプレイ用にダウンサンプリングする前にレンダリングするんだ。ベータテストを手伝ってくれた二人も「別のデスクトップを使うのはATMの画面を使うみたい」と言ってた。DHHもArchで似たようなことをやってるけど、まだそこまで進んでない。でも、これが未来だよ。

Neovimで似たようなもので良い結果出た人いる？

└

https://github.com/greggh/claude-code.nvim https://github.com/coder/claudecode.nvim

└

claude codeを開いたneovimのターミナルを開いておくのが好きなんだ。

└

CodeCompanionプラグインを試してみたけど、いい結果が出たよ。そんなに頻繁には使わないけど、試してみると楽しいね。

mcpサーバーにツールを追加できるのが好きだな。emacsから期待することだよね :) 長いことemacs使ってるけど、最近やっと自分のelispツールを書き始めたんだ。でもclaudeはelispを書くのが上手だから、そっちにもっと取り組んでるよ（時々カッコを見失うこともあるけど、全体的にはかなりいい感じ）。これ、steve yeggeのefritと一緒に試してみるつもり。efritはエージェントに任せて自由にelisp式を評価させることでemacsを11に引き上げてくれるからね。https://github.com/steveyegge/efrit

└

長いことYeggeのファンなんだけど、彼はまだ「バイブコード」のハネムーン期にいる気がする。バイブコードの二日酔いはまだ来てないね。でも、彼のemacsに関する知識は誰にも負けないと思う。12～18ヶ月前に気づいたのは、LLMがelispに異常に強いってこと。これが今やってるハイパーモダンなことのきっかけになったんだ。efritには何かあると思うけど、まだうまく使いこなせてない。でも、すごく期待できるよ。

今はhttps://github.com/stevemolitor/claude-code.elを使ってて、これは単なるターミナルラッパーなんだけど（便利なTransientメニューも含まれてる）。Emacsの中で動かすだけでかなりのパワーが得られるから、効率的でカスタマイズされたワークフローを作るのにあまり努力しなくてもよかった。前のiTermの使い方よりずっとスムーズに感じたよ。でもこの新しいものには注目しておくつもり。clojure-lspの作者が作ったhttps://github.com/editor-code-assistant/eca-emacsもあるし、これはClojureコミュニティでとても人気のあるパッケージなんだ。これも試してみたいと思ってた。もっと高度なツールに関しては、信頼して生産性を任せるツールを採用するのはちょっと慎重になるかな。大きなプロジェクトは「ビッグバン」フェーズで色々な問題を解決する必要があるからね。

└

ちょっと試してみたけど、結局ターミナルでclaude codeを使う方に戻っちゃった。Emacsではちょっと不安定だったし、別のターミナルウィンドウを開く理由がなかったんだよね（その時は）。このプロジェクトがうまくいくか気になるな。既存のmcp.elパッケージ[0]と連携しないのは残念だけど、そもそもそれを設定する時間がなかったし。これってパッケージの制限なのかな？それとも別の依存関係を増やしたくないのかな？（ちなみに、claude codeはあまり触ってないから、自分の仕事で使えるコードを書くレベルには達してないんだ。）[0] https://github.com/lizqwerscott/mcp.el

LSPやtree-sitterのように、Claude CodeやAiderのようなAIコーディングツールは、EmacsやVimのようなニッチなエディタにとっては良いニュースだと思う。高度なIDEのような機能を実装するのに苦労する代わりに、これらのツールと比較的簡単に統合できるし、他の編集関連の機能に集中できるからね。実際、これらのエディタはカスタマイズ性が高く、これらのツールとの統合が容易だから、競争力が増すと思う。

└

エディタにエージェントコーディングツールを統合するための標準ってあるの？LSPが言語特有の機能を統合するのと似たような感じで。

└

ずっとそうだったよね。Emacsは、私が覚えている限り、ずっと高度なIDEっぽい機能を持ってたし、Vimもそう。LSPやTSのおかげで、エディタや言語間の標準化が楽になったね。

似たようなプロジェクト（claude-code.el）を試してみたことがある。evil-modeでSpacemacsを使ってるんだけど、Claude Codeのテキストボックスに入力するのがすごくイライラした。カーソルが変なところに行っちゃったり、ターミナルエミュレータが挿入モードじゃないことを「理解」してない感じだったんだ。結局、ターミナルでClaude Codeを使う方がいいと思ったよ。Claude Codeのテキストボックスもそこでイライラするから、指示をファイルに書いて（emacsで）CCに読ませることが多い。これのプロジェクトには、一時的なバッファでプロンプトを作成する機能とかあるのかな？

└

試してみたけど、似たような問題があったよ。Claude Codeは他のところに埋め込むには良い「市民」じゃなくて、ターミナルを完全にコントロールしたがるんだ。デフォルトのemacsキーバインディングを使ってるけど、これはbash/readlineのキーバインディングに似てるから、ちょっとは使いやすい。でも、やっぱり違和感があるね。

最近、EmacsコミュニティからこういうツールをEmacsに統合することに対する軽蔑的な意見をよく見るけど、正直それは助けになるどころか、もっと傷つけてると思う。今のソフトウェア開発におけるAIの開発と使用が当時の技術と似てないかもしれないけど、Emacsの歴史はMIT AIラボと切り離せないと思う。だから、そんなワーキンググループから生まれたツールにAI統合を拒むのは変だよね。

└

これはリチャード・ストールマンのせいだね。彼は「非自由」な代替手段を統合することが、自由な代替手段がまだ存在しない時に自由ソフトウェアの開発を遅らせると思ってる。自由というのは、単に自由な選択肢だけじゃなくて、GPLライセンスのものだけでもなく、FSFが管理するプロジェクトのこと。彼はGCCへのリンク拡張や、emacsへのLLVMデバッガ統合（これはちょっと曖昧だけど）、emacsへのtreesitter、emacsのコードソース管理でのbzrとgit、emacs用のCIビルドファームでも同じことをした。どのケースでも、最終的には彼は譲歩して、コアプロジェクトは数年後に非自由な代替手段を統合した。その間に、この遅延は非自由な代替手段を止めることはなかったけど、コアプロジェクトの採用を遅らせた。これはひどいプロジェクト管理で、みんなを非自由ソフトウェアに向かわせてる。最もひどいケース（bzrとCIビルドファーム）では、彼のエゴとFSFを重要にしたいがために行われた。

└

でもEmacsの魅力は、ユーザーが完全にコントロールできるところなんだよね。Emacsの中で何かを変更するのを止めるものは何もない（少なくともElispのレイヤーでは）。だからこそ、こんなパッケージがあるんだ。VS Codeは逆に、[1]を分断するように設計されてる。MSは、自社のツールにプロプライエタリなAPIアクセスを与えて、他の人たちは能力の低い拡張APIを使わざるを得なくなってるから、vscodeのフォークがたくさん生まれてるんだよね。もし最新のLLMとのインタラクションに取り組みたい熱心なグループがいたとしても、たぶんフォークせざるを得ないだろう。一方で、やる気のあるElisp開発者が一人いれば、好きなように実装して、外部パッケージを統合することができるんだ。Emacsコミュニティからの軽蔑はちょっと大げさかもしれないと思う。AI/LLM関連のプラグインがEmacsに登場して、結構いい感じで使われてるのをよく見るしね（例: https://github.com/karthink/gptel）。[1] https://ghuntley.com/fracture/

└

MIT AIラボが現代のAIブームに関わってたなんて知らなかった、面白いね。

EmacsはAIエージェントにとって究極のエディタだと思ってる。エージェントはエディタの状態にかなりアクセスできるし、elispでエディタの動作を簡単に変更できるからね。VimやEmacsのようにカスタマイズ性を持つエディタは、大きなアドバンテージになる可能性があると思う。

これ、OpenCode（他のモデルプロバイダーを許可するClaude Codeのフォーク: https://github.com/sst/opencode）と連携できるかな？特定のプロバイダーやモデルに縛られるのはあまり好きじゃないんだ。モデルを切り替えることで、ブロックを乗り越えたり、お金を節約したりするのがすごく助かってる（特にDeepseekで！）。それに、仕事でGithub CopilotのOpen AI互換APIを使う必要があるし…。

[遅延]

ハクソク