［開発者向け］GitHub Copilot CLIに「本物のコード理解力」を——LSP Setupスキルで言語サーバーを導入する方法

2026-06-16

はじめに

　GitHubは2026年6月10日、Copilot CLI向けに言語サーバー(LSP)の導入を自動化する「LSP Setup」スキルを公開しました。本稿では、grepやバイトコード解析に依存していたCopilot CLIのコード理解を、言語サーバーによる構造的な解析に置き換える仕組みと、実際の導入手順について解説します。

参考記事

タイトル: Give GitHub Copilot CLI real code intelligence with language servers
著者: Bruno Borges
発行元: GitHub Blog
発行日: 2026年6月10日
URL: https://github.blog/ai-and-ml/github-copilot/give-github-copilot-cli-real-code-intelligence-with-language-servers/

要点

GitHub Copilot CLIは従来、JARファイルの展開やgrepによるバイトコード解析など、ヒューリスティックな手法でコード情報を収集していた
「LSP Setup」スキルは、言語サーバープロトコル(LSP)の導入と設定を自動化し、エージェントに正確な型解析・定義参照機能を与える
このスキルは7段階のワークフロー(言語選択、OS検出、サーバー特定、設定スコープ決定、インストール、設定ファイル生成、検証)で構成される
14言語に対応したサーバー情報を含む参照ファイルを備え、未対応言語の場合は手動設定をガイドする
設定ファイルはユーザーレベルまたはリポジトリレベルで配置でき、既存設定はマージされ上書きされない

詳細解説

LSPがない場合の課題

　GitHub Blogによれば、言語サーバーが設定されていない状態のCopilot CLIは、Javaであれば、依存ライブラリのAPI情報を調べる際にJARファイルを一時ディレクトリへ展開し、.classファイルをgrepで検索してAPIシグネチャを推測するといった作業を行っていました。Pythonであればsite-packages内のファイルをcatし、TypeScriptであればnode_modulesを歩き回るといった方法です。

　このようなテキストベースの手法は単純なケースでは機能するものの、ジェネリクスやオーバーロード、間接的な型情報の解析には限界があります。LSP（Language Server Protocol、エディタとプログラミング言語解析ツールの間で使われる標準プロトコル）は、VS Codeなどのエディタで「定義へ移動」や「参照の検索」を実現している仕組みであり、これをターミナル上のエージェントにも適用できれば、構造的にこの課題を解決できると考えられます。

Agent Skillという仕組み

　「LSP Setup」は、Agent Skill(エージェントスキル)という形式で提供されています。GitHub Blogでは、Agent Skillを「AIコーディングエージェントの機能を拡張する再利用可能な指示セット」と説明しており、YAMLフロントマター付きのMarkdownファイルとして、トリガーの説明・手順・参照データ・制約条件といった標準的な構造で定義されます。

　Agent Skillという考え方自体は、エージェントに特定のタスクの「型」を教え込む仕組みとして他のAIツールでも採用が進んでいます。コーディングエージェント向けのスキル活用については過去記事でも紹介していますので、関心のある方はあわせてご覧いただければと思います。

7段階のセットアップワークフロー

　LSP Setupスキルが起動すると、エージェントは以下の手順を実行します。

言語選択: ユーザーへの選択肢提示により、どの言語のLSPサポートが必要かを決定する
OS検出: uname -s(またはWindowsの$env:OS)を実行し、対象プラットフォームを判定する。インストールコマンドはOSによって異なる(例: macOSではbrew install jdtls)
LSPサーバーの特定: 14言語分のインストールコマンド・バイナリ名・設定スニペットをまとめた参照ファイル(references/lsp-servers.md)から該当エントリを選択する
設定スコープの決定: 設定先をユーザーレベル(~/.copilot/lsp-config.json、全リポジトリに適用)とリポジトリレベル(lsp.jsonまたは.github/lsp.json、単一プロジェクトに限定)のいずれにするか確認する。両方存在する場合はリポジトリレベルが優先される
インストール: 該当する言語のインストールコマンドを実行する(例: TypeScriptならnpm install -g typescript typescript-language-server、Rustならrustup component add rust-analyzer)
設定ファイルの生成: lspServersオブジェクトへエントリを書き込む。既存のエントリは保持され、上書きされない
検証: which <バイナリ名>(Windowsではwhere.exe)でサーバーへのアクセスを確認し、設定ファイルが正しいJSON形式かを検証する

設定ファイルのフォーマットと注意点

　設定ファイルはlspServersというオブジェクト内に、サーバーごとのエントリをキーとして持つ構造です。Javaの例は以下のようになります。

{
  "lspServers": {
    "java": {
      "command": "jdtls",
      "args": [],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

　各フィールドの意味は以下の通りです。

command: 実行ファイル名は$PATH上にあるか、絶対パスで指定する必要がある
args: 標準入出力(stdio)通信のために多くのサーバーは”–stdio”を必要とするが、jdtlsのように内部で処理するサーバーもある
fileExtensions: 各拡張子(先頭にドットを含む)を言語識別子にマッピングする

　なお、参考記事ではこのスキルが対象とするドメインをgithub.blogとしていますが、本稿執筆時点でJOBIRUNのGitHub Copilot CLI入門記事でも触れたように、Copilot CLIは継続的に機能拡張が行われており、今回のLSP対応もその一環と位置づけられそうです。

セットアップ後に変わること

　GitHub Blogでは、LSPサーバーの設定後にエージェントが以下を行えるようになると説明されています。

依存関係を越えた型解決(JARファイルやnode_modulesをgrepする必要がなくなる)
ソースがリポジトリにチェックインされていないサードパーティライブラリでも定義へ移動できる
プロジェクト全体でのシンボル参照検索
関数・クラス・型のホバードキュメント表示

　この変化により、エージェントが情報収集のために行うツール呼び出しの回数が減り、より精度の高いコードを最初の試行で生成しやすくなると考えられます。また、ユーザー側の視点では、エージェントがJARファイルを解凍したりnode_modulesをgrepしたりする待ち時間が減り、誤った型解釈に基づく見当違いな修正が減ることも期待できそうです。

導入方法

　LSP Setupスキルを利用するための手順は以下の通りです。

スキルのダウンロード: Awesome Copilot LSP Setupスキルのページからダウンロードボタンを押し、ZIPファイルを取得する
展開: 以下のコマンドで~/.copilot/skills/に展開する

unzip lsp-setup.zip -d ~/.copilot/skills/

Copilot CLIの再起動: 実行中の場合は/exitで終了し、copilotを再度起動してスキルを認識させる
言語サーバーのセットアップ依頼: 「Javaの言語サーバーを設定して」「Python用にコード理解を有効にして」のようにエージェントへ依頼する
動作確認: セットアップ完了後、再度/exitしてCopilot CLIを再起動し、/lspコマンドでサーバーの状態を確認した上で、依存ライブラリ内のシンボルに対する定義移動を試す

　このスキルはAwesome Copilotプロジェクトの一部としてオープンソースで公開されており、コミュニティからの貢献も受け付けているとのことです。

まとめ

　本稿では、GitHub Copilot CLI向けに言語サーバーの導入を自動化する「LSP Setup」スキルについて、その背景と7段階のセットアップワークフローを紹介しました。grepやバイトコード解析に依存していたコード理解が、LSPによる構造的な型解析に置き換わることで、エージェントの精度と効率の向上が期待できそうです。Copilot CLIの基本的な使い方については、過去記事でも紹介していますので、あわせてご覧いただければと思います。