LSP 統合でリアルタイムにコード品質を監視する

症状・対象

型エラーをファイル編集後すぐに見つけたい、またはシンボルの定義・参照を文字列検索だけで追っている人が対象です。LSP はファイル単位の診断とシンボル情報に使い、最終判定はプロジェクトの公式検証コマンドで行います。

最短解決

1. 対象言語の Language Server がプロジェクトで動くことを確認する。
2. OMC など、LSP server を提供する検証済みプラグインを有効にする。
3. 一つのファイルで診断を依頼し、同じ問題をコンパイラでも確認する。

コピペ例

TypeScript プロジェクトでは、まずコンパイラの基準値を取ります。

npx tsc --noEmit

OMC の LSP が有効なセッションで、対象と期待する出力を明示します。

> src/auth/login.ts の LSP 診断を実行して。
> error と warning を file:line、message、severity の順で返して。
> ファイルは変更しないで。

リファクタリング前の参照調査も、対象シンボルを限定します。

> authenticateUser の定義と全参照を LSP で調べて。
> 読み取りだけ行い、変更候補をファイル別にまとめて。

期待結果

• 診断結果にファイル、行、severity、message が含まれる。
• 定義検索は宣言元、参照検索は利用箇所を区別して返す。
• LSP 診断が空でも、npx tsc --noEmit の結果を別に確認できる。

検証

LSP の結果を得た直後に、プロジェクトの正式な型チェックを再実行します。

npx tsc --noEmit

OMC の更新後に LSP が見えない場合は、プラグインの更新状態と Claude Code の /doctor を確認します。

> /plugin
> /doctor

落とし穴

• 同期資料では手書き .lsp.json の完全な現行 schema を確認できないため、未検証の設定断片を貼り付けません。利用するプラグインの同梱設定を優先します。
• LSP が一つのファイルで成功しても、build 全体の成功とは限りません。コンパイラ・テスト・lint を別に実行します。
• Language Server の実行ファイルが PATH にない場合、LSP ツール名だけ見えても初期化に失敗します。
• rename は書き込み操作です。参照一覧を確認してから明示的に許可します。

次の一手

• Hook でツール実行を自動化する — 編集後の型チェックを自動化する
• MCP ツールをスラッシュコマンドとして呼び出す — 接続状態と権限を確認する