Claude CodeにネイティブLSPサポート機能を追加

 (github.com/anthropics)
18 ポイント 投稿者 GN⁺ 2025-12-23 | 2件のコメント | WhatsAppで共有
  • ターミナルで実行されるAIベースのコーディングツールであるClaude Codeが、最新バージョンでLSP (Language Server Protocol) ツールを追加
  • これにより、定義へ移動 (go-to-definition)、参照の検索 (find references)、ホバー時のドキュメント表示といったIDEレベルのコードインテリジェンス機能を提供
  • /terminal-setup コマンドがKitty、Alacritty、Zed、Warpターミナルを正式サポート
  • /theme 画面でCtrl+Tでシンタックスハイライトの on/off を切り替え可能
  • macOSでAltショートカットが動作しない場合に備えたターミナル設定ガイドを追加し、macOSのショートカット表記を alt ではなく**opt に統一**して実際のキーキャップと一致させた
  • /context コマンドの出力が改善され、skill と agent を出所別にグループ化し、スラッシュコマンド基準で整理、トークン使用量基準のソートを提供

関連記事

2件のコメント

 
aqqnucs 2025-12-23

serena を使っていましたが、やはりビルトインが正解ですね
 
GN⁺ 2025-12-23
Hacker Newsの意見

  • JetBrainsがなぜリファクタリングツールをAIシステムに統合しなかったのか理解できない
    関数名の変更のような簡単な作業でも、何百ものファイルを編集する代わりに、はるかに小さなコンテキストで処理できたはずなのに残念
    LSP対応は良い出発点だが、コードの変形機能がなければ依然として不十分
    JetBrainsのLSP品質も一般的なものより優れているわけではない

    • 最近のJetBrainsは少し方向性を見失っている感じがする
      コミットモーダルをなくして料金プランを値上げしてから、10年以上使ってきたものを移そうかと考えた
      最近の失敗例はこのブログ記事でも見られる
    • これは典型的なイノベーションのジレンマのように見える
      JetBrainsはコードの意味を最もよく理解するPSIエンジンを持っているが、いまだに人間がIDEを直接操作するというパラダイムに縛られている
      Claude CodeやCursorはエディタをAIが自由に扱うキャンバスとして見ているのに対し、JetBrainsはAIを単なるサイドバーのプラグインとして扱っている
      内部のリファクタリングツールをエージェントに開放しなければ、VS Codeへの移行摩擦はなくなるだろう
    • JetBrainsは自社AIのJunieに固執せず、すでに定着しているツールとの統合に集中すべきだ
      そうしなければVS Codeが市場を飲み込むだろう
    • 問題は慢心だった
      かつては大きな参入障壁を持っていたが、VS Codeがそれを崩した
      変化の流れをまったく予想できず、今は方向を見失っているようだ
    • Microsoftも似たような失敗をしている
      RoslynとCopilotをうまく結び付けられていない
      Roslyn analyzerは単なるリンターではなく、コード変換まで可能な強力なツールなのに、AIがいまだに単純なfind/replaceで処理しているのを見るともどかしい
      Roslynベースのエージェントが登場すれば、大規模コードベースでの作業効率は爆発的に上がるだろう

  • 私はClaude Code / Codex CLI + LSPの組み合わせに非常に前向きだ
    週末にCodexを使ってみたが、関数名の変更やシンボル移動の際に参照を取りこぼすのが不便だったので、Python向けリファクタリングツールのRopeをつなぐスキルを自作してみた
    かなり満足している

    • OpenAIのエンジニアはF2キーの代わりにCopilotボタンを押してしまい、参照名の変更に失敗したようなものだ
      LSP対応がないのは本当に奇妙だ
    • Codex 5.1のときはいまひとつだったが、今はClaude Codeより良くなったのか気になる
    • OpenAI内部でもこうした機能を直接作らなければならないのは驚きだ
      まだこの分野にはやるべきことが多いことを示している

  • 公式ドキュメントが不足していたので、自分で調べた結果を共有する
    /pluginコマンドでClaude Codeのプラグインマネージャーを開き、Discoverタブでlspを検索してspacebarで有効化し、iでインストールすればよい

    • 私も最初はClaudeがGo LSPをインストールするか聞いてきて驚いた
      最近の変更ログを探してみたら、3日前に追加された機能だった
      まだ実験的なので無効化してある
    • 最新バージョンでもmcpを検索しても何も出てこない
      機能はまだ未完成の段階に見える
      今後Claudeが自動でLSPを認識するよう改善されることを望む
    • カスタムLSPを追加するには、Claude Code プラグインラッパーで包む必要がある
      関連ドキュメントはこちら

  • AnthropicのClaude Code UXは主要なAI製品の中で最悪だ
    単にテキストをコピー＆ペーストすることすら不便で、ユーザーフィードバックも無視している
    この状態なら、なぜChatGPTの代わりにこれを使うべきなのかわからない

  • 私はオープンソースのOpenCodeを6か月使っているが、すでにこうした機能を提供していた
    クローズドソフトウェアの進みの遅さには驚く
    ClaudeやCopilotのサブスクリプションと一緒に使えるのでおすすめだ

    • オープンソースとプロバイダー非依存性を好むのでOpenCodeを気に入りたかったが、実際にはClaude Codeのほうが安定していた
      OpenCodeには承認待ち中のCPU 100%使用、ポップオーバーによる誤動作などの性能問題があった
      それでもClaude Codeにもスクロール時のちらつきのようなバグはある
    • 私はOpenCodeをうまく活用できていない
      Claude Codeはすぐに良い結果を出してくれるが、OpenCodeはモデル接続も難しく効率が低い
      おそらくClaude Codeのプロンプトチューニングが長年積み重ねられてきたおかげだろう
    • オープンソースは意思決定構造が単純なので素早く動ける
      複数の利害関係者の説得やスプリント調整に時間を無駄にしない
    • OpenCodeの設定体験は他のCLIツールの中でも最も簡単で直感的だ
      ただし細かなバグやクラッシュは時々発生する
    • OpenCodeの開発速度は非常に速い
      誰かが朝にAGIを発表したら、夕方にはもう統合しているくらいだ
      私も複数のツールを行き来しながらテストしているが、OpenCodeは着実に進化し続けている

  • CLI形式のツールに熱狂するのは奇妙に感じる
    IDEベースのエージェントはすでにこうした機能を標準搭載しているのに、わざわざターミナルでdiffやLSPを実装するのが効率的なのか疑問だ
    Cursorはすでにかなり前からこうした機能をサポートしている

    • LSPはもともと1つのサーバーを複数クライアントで共有するよう設計されている
      CLIもLSPサーバーにつなぐ小さなクライアントを作れば十分だ
      IDEだけがLSPの恩恵を独占する理由はない
    • 非開発者でもClaude Code CLIのほうが自然に感じるという
      ターミナルは単なるコード編集ではなく、コンピュータ全体をオーケストレーションする空間だ
      kubectlがGUIへ進化しなかった理由と似ている
      関連記事: It's on your computer
    • IDE内のエージェントがLSPにアクセスできるのか気になる
      たとえばZedは、MCPサーバーがなければLSP情報を活用できない
    • 自分のエディタとチャットボットの両方がターミナル内にあるので、わざわざIDEへ移りたくない
      デスクトップアプリの不完全なUIよりCLIのほうがいいと感じる
    • CLIの利点は、特定のIDEに依存しない自由さだ

  • 最近の自分の記事でも書いたように、LLMを非効率に回しているせいでトークンの浪費とエネルギーの浪費が深刻だ
    LLMがツールをもっと簡単に使えるようにすることが核心だ
    これはコーディングだけでなく、あらゆる分野に適用できる原則だ

    • 数年後には、今の非効率なツールエコシステムを恥ずかしく振り返ることになるだろう
      エネルギー、水、資源の浪費による環境被害を考慮すべきだ
    • すでにこうした問題を解決しようとする試みはあった
      たとえばSerenaのようなプロジェクトがある

  • 私の気に入っているエージェントCrushはすでにLSPをサポートしている
    ただ、実際にはエージェントがその機能を頻繁に使ってはいない
    Crush GitHubリンク

    • AGENT.mdにインストール済みのLSPサーバーを明記しても違いがあったのか気になる

  • まだLSPが実際に使われている場面を見たことがない
    Opus 4.5はQAのタイミングが安定しており、lintチェックもIDEの外でうまく動く
    定義が深く隠れている場合にはLSPが役立つかもしれない
    Claudeが提供するLSP機能の一覧は次のとおりだ

    • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls など

  • LSPはシェルコマンド形式のAPIを提供すべきだ
    そうすればLLM統合が容易になり、人間にとっても有用になるだろう

    • すでにlsp-cliのようなCLIフロントエンドがある
      ただしLLMが専用ツールとしてLSPを使うほうが、単純なシェルコマンドより効率的だ