9月17日、CircleCIが「How to build a Language Server Protocol (LSP) plugin for Claude Code」と題した記事を公開した。この記事では、既存のLanguage Server Protocol（LSP）サーバーをClaude Codeプラグインとしてラップし、AIコーディング中にリアルタイムで診断情報やベストプラクティスの警告を受け取る仕組みの作り方について詳しく紹介されている。以下に、その内容を紹介する。
LSPをClaude Codeに繋ぐ、何がうれしいのか
Claude Codeは構文的に正しいコードをほぼ書けるが、編集時にしか現れないような警告——非推奨の使い方、ベストプラクティス違反、バージョンが古いライブラリの指摘——はそのまま素通りしてしまう。LSPはこういった情報をエディタにリアルタイムで届ける仕組みだが、Claude Codeはデフォルトではそのフィードバックを受け取れない。
本記事が解決するのはこの問題だ。既存のLSPサーバーをClaude Codeのプラグインとしてラップすることで、Claude自身の編集ループの中にエディタと同等のフィードバックを流し込める。
CircleCIは自社の.circleci/config.yml向けに、公式のCircleCI YAMLランゲージサーバー（VS Code拡張の裏側と同じもの）をClaude Codeプラグインとしてラップする実装を公開した。プラグインはMITライセンスのオープンソースで、CIRCLECI-GWP/circleci-yaml-lsp-for-claudeから入手できる。
3コマンドで動かせる
Claude Codeセッション内で以下を実行するだけで試せる。
/plugin marketplace add CIRCLECI-GWP/circleci-yaml-lsp-for-claude
/plugin install circleci-yaml-lsp@circleci-lsp
/reload-plugins
LSPはプッシュ型なので、Claudeが.circleci/config.ymlを編集したタイミングでエラー・警告・ヒントが流れてくる。単にファイルを読むだけでは何も起きない点は注意が必要だ。
内部構造：3つの核心部品
アーキテクチャは3層に分かれている。
ランチャー（bashスクリプト）
言語サーバーのバイナリをバンドルせず、初回起動時にCircleCIのGitHub ReleasesからダウンロードしてSHA-256で検証する。検証が通れば、バージョン付きキャッシュに格納して再利用する。SHA-256ツールがない環境では実行そのものを拒否する設計だ。
スコーピングプロキシ（最も再利用価値が高い部分）
Claude Codeは言語サーバーを拡張子だけでルーティングする。.ymlを丸ごとCircleCI専用サーバーに向けると、docker-compose.ymlやHelmチャートにも誤った診断が流れ込む。プロキシはJSON-RPCストリームに割り込み、次の正規表現にマッチするファイルだけをサーバーへ転送する。
/(^|\/)\.circleci\/([^/]*_)?config\.ya?ml$/i
この手法は、幅広い拡張子をカバーしつつ特定のファイルサブセットのみを受け付けるべき他の言語サーバーにもそのまま流用できる。
スキーマホバー
CircleCIの設定スキーマからホバードキュメントを返すプロキシ。設定キーの意味をClaudeが問い合わせると、スキーマから該当する説明を返す。
ベンチマーク：正確さより「ベストプラクティス」に効く
CircleCIは6種類の典型的な設定変更タスク（デプロイワークフロー、Orbコマンド、壊れた設定の修復、マトリックスジョブ、キャッシュ、エグゼキューター）について、プラグインあり／なしを比較した。Claude Opus 4.8とSonnet 5の両モデルで計84回実行し、出力はすべてcircleci config validate（CircleCIのサーバーサイドコンパイラ）で評価した。
結果1：コンパイラレベルの正確さは変わらない
84件すべて、プラグインの有無にかかわらず正常にコンパイルが通った。幻覚したOrbコマンドや未定義ジョブ参照といったコンパイルエラーは全モデル・全条件で発生しなかった。
結果2：ベストプラクティスの適用に差が出た
コンパイラは通るが編集時にLSPが指摘するような改善——store_test_resultsの追加とOrbのバージョン更新——で明確な差が現れた。
| 設定 | store_test_results を追加 | Orbを最新に保った |
|---|---|---|
| プラグインなし | 24件中0件 | 8件中1件 |
| プラグインあり（エラーのみ修正を指示） | 16件中0件 | 6件中2件 |
| プラグインあり（LSPの指摘に従うよう指示） | 16件中5件 | 6件中6件 |
重要な発見は、プラグインの効果はプロンプト次第という点だ。「エラーのみ修正せよ」と指示した場合は改善が起きなかった。「LSPのフィードバックに従え」と明示した場合に初めてベストプラクティスが適用された。
自動メンテナンスの仕組み
ランチャーはバイナリをSHA-256でピン留めし、ホバードキュメントのテーブルも特定バージョンのスキーマから生成している。CircleCIがランゲージサーバーの新バージョンをリリースするたびにこれらを手動で更新するのは現実的でないため、専用のCircleCIパイプラインで自動化している。
workflows:
ci:
jobs:
- lint
- test
maintenance:
when: << pipeline.parameters.run-maintenance >>
jobs:
- upstream-update:
context:
- gh-bot
maintenanceワークフローは上流のリリースを確認し、新版があればSHA-256、バイナリサイズ、ホバーテーブル、プラグインバージョンを一括更新してPRを自動作成する。mainへの自動マージは行わず、人間がレビューして取り込む設計になっている。
他のLSPへの転用
記事が提示する実装パターンは、CircleCI固有の部分（ホバープロキシ）を除けばそのまま他の言語サーバーに応用できる。必要な要素は3つだ。
- バイナリの安全な取得・検証（ランチャー）
- ファイルスコープの絞り込み（スコーピングプロキシ）
- Claude Codeが直接サポートしない挙動のプロキシ実装
なお本プラグインはCircleCIの公式サポート対象外であり、あくまで実装例として公開されている。
詳細はHow to build a Language Server Protocol (LSP) plugin for Claude Codeを参照していただきたい。
