GitHub Copilot SDKとは｜6言語のエージェント組み込みSDKをCLI取得方式の実測で解説

Copilotを「エディタの中で補完してくれるもの」として使っている人は多いが、同じエンジンを自分のアプリから呼びたくなると話が変わる。計画を立て、ツールを呼び、ファイルを編集し、失敗したらやり直す——このループを自前で書くのは重い。GitHub Copilot SDKは、そのループごとGitHubに任せてしまうための公式SDKだ。

github/copilot-sdk は、GitHubが公開しているMITライセンスのマルチプラットフォームSDKである。リポジトリの説明文は「Multi-platform SDK for integrating GitHub Copilot Agent into apps and services」、READMEの見出しは「Agents for every app.」。2026年1月14日に作成され、2026年8月2日時点でGitHubスターは10,270、フォークは1,385、mainのコミットは897本ある。

なお、AIによるコーディング支援ツール全体の見取り図と選び方は Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026 にまとめている。

GitHub Copilot SDKとは——CLIのエンジンを外から呼び出す公式SDK

Copilot SDK を理解する近道は、「新しいAI機能が増えたわけではない」と押さえることだ。READMEの表現を借りれば、このSDKが公開しているのは the same engine behind Copilot CLI——つまり Copilot CLI の背後で動いている、実運用に投入済みのエージェントランタイムそのものである。

ここが重要な分かれ目になる。多くの「AI SDK」は、モデルへのHTTPリクエストを薄く包んだクライアントだ。プロンプトを送り、テキストを受け取る。その先の「どのツールを呼ぶか」「ファイルをどう書き換えるか」「失敗したらどう再試行するか」は利用者が書く。Copilot SDK はそこを引き受ける側に立っている。READMEは「オーケストレーションを自分で作る必要はない——エージェントの振る舞いを定義すれば、計画立案・ツール呼び出し・ファイル編集などはCopilotが処理する」と書いている。

「エディタのCopilot」との関係

同じCopilotブランドでも、レイヤーが違う。エディタ拡張やCopilot CLIは完成した製品で、Copilot SDKはその製品を組み立てている部品を外に出したものだ。したがって用途も分かれる。社内のレビューボットにCopilotのエージェントを埋め込む、独自のCIツールにコード修正機能を持たせる、SaaSのダッシュボードに「この不具合を直す」ボタンを付ける——といったケースがSDKの領分になる。

エディタや対話UIとしてのCopilotそのものの使い方・プラン差については GitHub Copilotの使い方｜導入・基本操作・Agent Mode・料金体系を2026年最新版で解説 を参照してほしい。デスクトップアプリ化を含む製品側の動きは GitHub Copilotがネイティブアプリ化、デフォルトモデルもPolarisへ——Build 2026の主戦場 にまとめている。

数字で見た規模

npmの @github/copilot-sdk は2026年7月2日〜7月31日で 3,302,148ダウンロード。スター数10,270に対してこの桁になるのは、SDK自体が他のツールから依存として引かれている可能性が高いことを示す。ただしダウンロード数はCIの繰り返し実行でも増えるため、そのまま「利用者数」とは読めない点は補っておく。

リポジトリの言語構成を見ると、Javaが約4.49MB、Rustが約3.90MB、TypeScriptが約2.52MB、C#が約1.68MB、Goが約1.53MB、Pythonが約1.44MBと、6言語がかなり均等に書かれている。片手間の移植ではなく、各言語のSDKが本体として維持されているモノレポだ。

アーキテクチャ——Copilot SDKの実体はJSON-RPCクライアント

READMEのArchitectureセクションは、拍子抜けするほど簡潔なASCIIアートでこう説明している。アプリケーション → SDKクライアント → JSON-RPC → Copilot CLI（serverモード）。

この設計から、実運用に効く性質がいくつか導ける。

第一に、SDKを入れただけでは動かない。CLIバイナリが手元に無ければ何も起きない。後述するとおり、このバイナリをどう手に入れるかが言語ごとに違い、本記事の主題になる。

第二に、プロセスがひとつ増える。SDKはCLIプロセスのライフサイクルを自動管理する。コンテナで動かすなら、そのプロセス分のメモリとPID、そして終了時のクリーンアップを見込む必要がある。なお、外部で起動済みのCLIサーバーに接続する構成も選べる。

第三に、バージョン整合が必要になる。SDKとCLIは別々に配布されうるため、両者が同じ言語を話せるかを接続時に確認する仕組みが要る。それがプロトコルバージョンの検証で、これも後述する。

そして v1.0.7 では、この「子プロセス」前提を外す道が追加された。CHANGELOGによれば、ネイティブランタイムライブラリをC ABI（FFI）経由で読み込み、同一プロセス内でCopilotランタイムをホストするトランスポートである。子プロセス生成のオーバーヘッドが消える一方、CHANGELOGはこれを実験的（experimental）と明記している。

セッションが進む流れ

エージェント実行の一往復は、おおむね次のように進む。

注目したいのは権限ハンドラの位置だ。READMEのFAQは、既定でCLIのファーストパーティツールが --allow-all 相当で露出すると書きつつ、「ツール実行は各SDKの権限ハンドラによって統制されるため、アプリケーションは承認・拒否・カスタマイズができる」と続けている。つまり既定が緩いこと自体より、権限ハンドラを書くかどうかがアプリ側の責任になる、と読むのが正しい。

「CLI同梱」の中身は言語ごとに違う——実際に入れて確かめた

ここからが本題である。READMEはCLIの入手について、こう書いている——Node.js・Python・.NETではCLIが自動的に同梱され別途インストールは不要、Go・Java・Rustでは手動インストールかPATHへの配置が必要、と。

この一文は間違いではない。ただし「同梱」の実装は言語ごとにまったく違い、運用上の帰結も違う。実際にインストールし、リポジトリのソースを読んで確かめた結果を整理する。

Python：wheelにバイナリは入っていない

まずPythonから。仮想環境を作って公式パッケージを入れ、中身を数えた。

python3 -m venv venv && ./venv/bin/pip install github-copilot-sdk
# → Successfully installed ... github-copilot-sdk-1.0.8

# 入ったのは純Pythonの依存だけ（pydantic / httpx / python-dateutil ...）
find ./venv -type f -name "copilot*" -not -name "*.py" -not -name "*.pyc"
# → 何も出ない

./venv/bin/python -c "from copilot import _cli_version as v; print(v.CLI_VERSION)"
# → 1.0.73

find は何も返さない。CLIバイナリはwheelに含まれていない。PyPIの配布物を確認すると github_copilot_sdk-1.0.8-py3-none-any.whl の約0.41MB、プラットフォーム非依存の純Pythonホイールである。pyproject.toml の依存も python-dateutil / pydantic / httpx の3つだけだ。

ではどう調達するのか。パッケージ内の _cli_download.py が答えで、これは実行時ダウンローダである。_cli_version.py にはプラットフォームごとの配布アセット名（copilot-linux-x64.tar.gz、copilot-darwin-arm64.tar.gz、Alpine向けの copilot-linuxmusl-* を含む8種）と、取得元 https://github.com/github/copilot-cli/releases/download が定義されている。そして CLI_VERSION は公開時に具体値へ差し替えられる仕組みで、1.0.8のwheelでは 1.0.73 がピン留めされていた。

運用上の含意ははっきりしている。pip install が成功していても、初回実行時にネットワークが要る。イメージビルド時に依存を固めてからエアギャップ環境へ持ち込む構成や、ファイルシステムが読み取り専用のコンテナでは、実行段階で初めて失敗する。回避するなら、CLIを別途配置して COPILOT_CLI_PATH を指す。

なお CLI_VERSION のコメントには、ソースからの開発インストール（editable install）では値が None のままで自動ダウンロードが無効になる、と書かれている。リポジトリをクローンして動かす場合は明示的なパス指定が必要になるということだ。

Node.js：npmの依存として本当に降ってくる

対照的に、Node.jsは素直だ。nodejs/package.json の dependencies に @github/copilot@^1.0.77 が入っている。この @github/copilot 自身がCLIの配布パッケージで、optionalDependencies にプラットフォーム別のバイナリパッケージ（@github/copilot-darwin-arm64、@github/copilot-linuxmusl-x64 など8種）を持ち、bin で copilot コマンドを提供する。

つまり npm install の時点でバイナリが手元に来る。インストール済みのイメージはオフラインで動くし、ロックファイルにバージョンが記録されるので再現性もある。Pythonとは性質がまるで違う。

ここで気づくことがある。同じSDK v1.0.8でも、参照するCLIのバージョンが言語で異なる。PythonがピンするCLIは1.0.73、Nodeが要求するのは ^1.0.77 である。SDKのバージョン番号を揃えても、下で動くCLIまで揃うとは限らない。

.NET：NuGetパッケージがnpmレジストリから取りに行く

.NETはさらに変わった経路をとる。GitHub.Copilot.SDK.csproj を読むと、ビルド時に次のコマンドでCLIのバージョンを決めている。

node -e "console.log(require('./nodejs/package-lock.json')
  .packages['node_modules/@github/copilot'].version)"

Nodeのロックファイルを正とし、そこからCLIのバージョンを読み取っている。決まった値は .props ファイルに書き出されてNuGetパッケージに同梱され、対になる .targets が利用者のビルド時に働く。.targets の中身は RuntimeIdentifier（win-x64、osx-arm64、linux-musl-arm64 など）をCopilotのアセット名へ写す対応表で、取得元としてnpmレジストリのURL（CopilotNpmRegistryUrl）を持つ。

取得の実体は _DownloadCopilotCli というターゲットで、MSBuild標準の DownloadFile タスクで copilot.tgz をキャッシュディレクトリへ落とし、続く Exec で tar -xzf して展開する。つまり、NuGetパッケージがビルド時にnpmレジストリへ取りに行く。社内プロキシしか許可されていない環境では、NuGetのフィードだけでなくnpm側の到達性も確認対象になる。

なお逃げ道も用意されている。CopilotSkipCliDownload を true にすればダウンロード自体を止められ、CopilotCliBinaryPath で手元のバイナリを指定できる。ファイル中のコメントは、DownloadFile タスクが認証情報に対応しないため、プライベートなnpmフィードを使う場合は npm pack などで別途取得する想定だと説明している。

Rust・Go・Java：READMEの3分類より実態は細かい

READMEはこの3言語を「同梱なし」側にまとめているが、中身は三者三様だった。

Rust は Cargo.toml の [features] に default = ["bundled-cli"] と書かれている。つまり cargo add github-copilot-sdk した既定の状態で、CLIを取得する機能が有効になる。build.rs は bundled-in-process featureの有無で分岐し、bundled-in-process は bundled-cli に加えて libloading を引く構成だ。「手動インストールが必要」という説明は、既定featureを外した場合の話と読むのが実態に近い。

Go は go/internal/embeddedcli というパッケージを持つ。ドキュメントコメントによれば、CLIバイナリとそのハッシュを渡すとキャッシュディレクトリへ導入し、バージョンごとの子ディレクトリに分けて共存させられる。client.go は「CLIパスが指定されなければ埋め込みCLIを試し、それも無ければPATHの copilot に落とす」という順で解決する。つまりGoはアプリ側が明示的に組み込むときだけ同梱になる。

Java はどうか。CLIのダウンロードや埋め込みに相当するモジュールが見当たらず、in-processトランスポートに言及する非テストコードも0件だった。6言語のうちJavaだけが、PATHの copilot に完全に依存する構成である。

一覧で見る

プロトコルバージョンは「3」で固定——互換範囲は1つしかない

SDKとCLIが別配布である以上、両者の整合を取る仕組みが要る。リポジトリのルートにある sdk-protocol-version.json がその起点で、中身は3行しかない。

{ "version": 3 }

この値がどう使われるかを追うと、開発フローが見えてくる。nodejs/scripts/update-protocol-version.ts がこのJSONを読み、5言語ぶんの定数ファイル（nodejs/src/sdkProtocolVersion.ts、go/sdk_protocol_version.go、python/copilot/_sdk_protocol_version.py、dotnet/src/SdkProtocolVersion.cs、rust/src/sdk_protocol_version.rs）を生成する。単一の値から各言語へ配る形だ。

実際の検証はクライアントの接続処理で行われる。Node.js側の該当メソッドは、connect を投げて返ってきた protocolVersion を、自分の下限・上限と突き合わせる。下限は nodejs/src/client.ts に MIN_PROTOCOL_VERSION = 3、上限は生成された SDK_PROTOCOL_VERSION = 3。Python側も _MIN_PROTOCOL_VERSION = 3、Rust側も MIN_PROTOCOL_VERSION: u32 = 3 と揃っている。

範囲を外れたときのメッセージは、そのまま検索できる形で書かれている。

SDK protocol version mismatch: SDK supports versions 3-3,
but server reports version N. Please update your SDK or server
to ensure compatibility.

サーバーがバージョンを返さない場合は別の分岐になり、「but server does not report a protocol version.」というメッセージになる。ログにこの文字列が出たら、SDKとCLIの組み合わせを疑えばよい。

もうひとつ、実装には後方互換の逃げ道がある。connect メソッド自体を持たない古いサーバーに当たった場合（MethodNotFound か “Unhandled method connect”）は、ping へフォールバックしてそこからバージョンを読む。ただしコメントによれば、このときトークンは黙って捨てられる——古いサーバーはトークンを強制できないためだ。古いCLIに繋いだときに認証まわりの挙動が変わりうる、ということは知っておいて損はない。

認証・BYOK・課金の扱い

READMEは認証方式を4つ挙げている。copilot CLIでログイン済みのOAuth資格情報を使う方式、OAuth GitHub Appのユーザートークンを渡す方式、環境変数（COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN）、そしてBYOKである。

BYOK（Bring Your Own Key）は、OpenAI・Microsoft Foundry・AnthropicなどのプロバイダのAPIキーを自分で設定する方式で、この場合はGitHub認証なしにSDKを使える。READMEのFAQも「BYOKを使う場合を除き、Copilotのサブスクリプションが必要」という書き方でこれを裏づけている。

ただし制約が明記されている。BYOKは鍵ベース認証のみで、Microsoft Entra ID（Azure AD）・マネージドID・サードパーティのIDプロバイダには対応しない。クラウド上のマネージドIDで認証を統一している組織では、ここが設計上の分岐点になる。

課金については、READMEはCopilot CLIと同じモデルで、プロンプト単位で利用量に計上されると説明している。SDK経由だからといって別枠になるわけではない、と読める。加えて docs/features/session-limits.md にはセッション単位でAIクレジットの予算を設定し、予算イベントを監視する機能が用意されている。プログラムから大量にプロンプトを投げる用途では、この上限設定が実質的な安全弁になる。

Copilot全体のプラン体系と単価そのものについては、Anthropic側のエージェントSDKにおけるクレジット消費の考え方をまとめた Claude プラン（Pro/Max）で Claude Agent SDK を使う方法｜月次クレジット制度を読み解く が、同種の「サブスクリプション枠でエージェントを回す」設計の比較材料になる。

Copilot SDKのインストールと、最小構成で確かめること

各言語のインストールコマンドはREADMEの一覧表にまとまっている。

npm install @github/copilot-sdk          # Node.js / TypeScript
pip install github-copilot-sdk           # Python
go get github.com/github/copilot-sdk/go  # Go
dotnet add package GitHub.Copilot.SDK    # .NET
cargo add github-copilot-sdk             # Rust
# Java は Maven 座標 com.github:copilot-sdk-java

入れたあとに確認しておきたいのは、ここまで見てきた3点だ。CLIバイナリが手元にあるか、SDKとCLIのバージョンがどうなっているか、プロトコルバージョンがいくつか。自分の環境で次のように確かめられる。

# 1. CLI が PATH にあるか（Java/Go では必須、他でも外部CLI利用時に効く）
which copilot && copilot --version

# 2. Python：wheel にバイナリが無いことと、ピン留めされた CLI バージョン
pip show github-copilot-sdk | grep -E "Version|Location"
python -c "from copilot._cli_version import CLI_VERSION; print('pinned CLI:', CLI_VERSION)"
python -c "from copilot._cli_download import get_cached_cli_path; print('cached:', get_cached_cli_path())"

# 3. Python：SDK が話すプロトコルバージョン
python -c "from copilot._sdk_protocol_version import SDK_PROTOCOL_VERSION as v; print('protocol:', v)"

# 4. Node：実際に降ってきた CLI パッケージのバージョン
npm ls @github/copilot

3番目が 3 を返し、繋ぎ先のCLIも3を返すなら整合している。2番目の get_cached_cli_path() が None を返す状態は「まだCLIを取得していない」という意味で、その状態で実行するとダウンロードが走る。オフライン環境へ持ち込む前にここを潰しておくと、初回実行時の事故を避けられる。

docs/ 配下には16本の機能ガイドが置かれており、agent-loop.md（ツール利用ループとターンの扱い）、hooks.md（セッション挙動の差し込み）、custom-agents.md（スコープを絞ったサブエージェント定義）、fleet-mode.md（サブエージェントの並列実行）、mcp.md（MCPサーバー連携）、streaming-events.md（40以上のイベント型の購読）などが一次情報として読める。troubleshooting/compatibility.md にはSDKとCLIの機能対応表も用意されている。

Copilot SDKと他のエージェント組み込みSDKの比較

同じ「エージェントをアプリに組み込む」層には複数の選択肢がある。設計思想の差を、確認できた事実の範囲で並べる。

どれが優れているかは用途で変わる。エージェントの挙動そのものを細かく制御したいなら実行ループを自分で持つ構成に利があるし、Copilotの実運用済みの挙動をそのまま使いたいならSDKが近道になる。判断材料として決定的なのは、Copilotのサブスクリプション（またはBYOKの鍵）を前提にできるか、そしてローカルにCLIプロセスを置ける実行環境かどうかだ。

コミュニティ製として、READMEはClojure（copilot-community-sdk/copilot-sdk-clojure）とC++（0xeb/copilot-sdk-cpp）を紹介している。ただし「非公式・コミュニティ主導であり、GitHubのサポート対象外。自己責任で利用のこと」と警告つきで書かれている点は押さえておきたい。

成熟度の見立て

READMEのFAQは「一般提供でセマンティックバージョニングに従う」と述べている。一方、Pythonの pyproject.toml に残る分類は Development Status :: 3 - Alpha のままだ。これは分類メタデータの更新漏れの可能性が高く、それ自体で品質を判断する材料にはならないが、言語ごとに成熟度が揃っているとは限らないことの傍証にはなる。

リリースの刻み方も言語で分かれている。タグを見ると、共通の v1.0.9-preview.2 に加えて rust/v1.0.9-preview.2、java/v1.0.9-preview.2 のように言語プレフィックス付きのタグが並ぶ。Javaはさらに java/v1.0.6 のような独自の安定版タグも持つ。共通リリースとは別のペースで動く言語がある、ということだ。

2026年8月2日時点の最新安定版は v1.0.8（2026-07-22公開）、プレビューは v1.0.9-preview.2（2026-07-31公開）である。本記事の実測はすべてv1.0.8系に対するものなので、後続バージョンでは挙動が変わりうる。

まとめ——SDKを入れる前に確認すべきこと

GitHub Copilot SDK は、Copilot CLI のエージェント実行エンジンをそのままプログラムから呼べるようにした公式SDKだ。自前でオーケストレーションを書かずに済む、というのが提供価値のすべてと言ってよい。

一方で、READMEを読んだだけでは見えない実装差がある。本記事で実測して確かめたのは次の3点だった。

・「CLI同梱」は言語ごとに6通り。Nodeは npm install 時、.NETとRustはビルド時、Pythonは初回実行時、Goはアプリが明示した場合のみ、Javaは同梱されない
・PythonのwheelにはCLIバイナリが入っていない（py3-none-any・約0.41MB）。エアギャップ環境や読み取り専用FSでは COPILOT_CLI_PATH の事前指定が要る
・プロトコルバージョンの許容幅は1つだけ（下限3・上限3）。ずれると接続時に SDK protocol version mismatch で落ちる

どれも導入初日ではなく、コンテナへ載せた日やCLIを更新した日に効いてくる種類の差だ。使う言語を決める段階で、この表を一度見ておくと手戻りが減る。

参照ソース

・github/copilot-sdk — GitHub リポジトリ（README・sdk-protocol-version.json・各言語ディレクトリのソース。2026-08-02 時点で確認）
・copilot-sdk CHANGELOG.md（v1.0.7 の in-process（FFI）トランスポート追加など）
・github-copilot-sdk — PyPI（配布物の形式・サイズ・依存関係）
・@github/copilot-sdk — npm（依存パッケージとダウンロード実数）
・copilot-sdk Features ドキュメント（16本の機能ガイド一覧）