開発

Microsoft Copilot SDKとは:旧GitHub Copilot SDKの使い方・料金・権限制御【2026年10月】

Microsoft Copilot SDKとは:旧GitHub Copilot SDKの使い方・料金・権限制御【2026年10月】

Microsoft Copilot SDKは、GitHub Copilot CLIと同じエージェントの実行ループを、自社のアプリケーションからコードで呼び出すためのSDKです。2026年10月28日、GitHub Copilot SDKがMicrosoft Copilot SDKへ段階的に移行すると告知されました。本記事では、名称変更で変わる範囲と変わらないパッケージ名、Copilot CLIをJSON-RPCで動かす構成、Node.jsとPythonでの導入手順、自社関数を呼ばせるツール定義と権限ハンドラー、AI CreditsとBYOKで分かれる料金を、公式リポジトリとドキュメントで確認した値で整理します。

まとめ:Microsoft Copilot SDKの要点と導入前に決める権限・課金の扱い

中身は旧GitHub Copilot SDKそのものです。10月30日時点で、npmの@github/copilot-sdkもPyPIのgithub-copilot-sdkも旧名のまま配布されており、既存のコードを書き換える必要はありません。アプリはSDKのクライアントを通じてCopilot CLIをサーバーモードで起動し、JSON-RPCでセッションを操作します。

導入前に決めるのは2点です。1つ目はツール実行の許可方針で、サンプルにあるapproveAllのまま本番に出さず、権限ハンドラーで自社ツール以外を拒否します。2つ目は課金先で、ログイン中の開発者、OAuthで認可した利用者、組織向けのserver-to-server、BYOKのどれで認証するかによって、AI Creditsが誰の枠から減るかが変わる仕組みです。社内ツールに既存のエージェントループを載せる案件なら採用し、Entra IDでの認証が必須の業務アプリでは見送ります。

GitHub Copilot SDKからMicrosoft Copilot SDKへの改称

移行は名前の付け替えだけでなく、SDKの位置付けがGitHub Copilot専用からMicrosoft全体のCopilot基盤向けへ広がる変更です。ただし、利用者側の手当ては現時点ではほとんど要りません。

10月28日の告知で変わったリポジトリ表記と当面変わらないパッケージ名

GitHubのchangelog(2026年10月28日)によると、SDKはGitHub Copilotのハーネス向けから、Microsoft Copilotのハーネス向けのプログラマブルなインターフェースへ拡張されます。リポジトリはMicrosoftの組織へ移す準備に入り、ブランドとドキュメントの更新が始まりました。移行は段階的で、期間中は既存のパッケージ名や名前空間、一部のドキュメントが旧名を指したままになる可能性があると明記されています。

既存の利用者に即時の対応は不要で、サポート内容も変わりません。10月30日時点でgithub/copilot-sdkリポジトリの見出しは「Microsoft Copilot SDK」に変わった一方、URLはgithub/copilot-sdkのままです。依存関係の記述は、パッケージ名の変更が正式に案内されるまで触らない判断で問題ありません。

Microsoft Copilot harnessとFoundryの実行基盤とSDK

同日のMicrosoftの公式ブログは、モデルの周囲にある実行ループやツール呼び出しの仕組み全体を「ハーネス」と呼び、Copilot Studio、GitHub Copilotアプリ、CLI、VS Codeなどが同じCopilot harnessで動いていると説明しています。20以上のモデルと持ち込みキー(BYOK)に対応し、ランタイムはRustへ移植済みです。

このハーネスはMicrosoft Foundry経由でも提供が始まり、エージェントループとサンドボックスの実行をFoundryに任せる形も選べます。SDKはそのハーネスをローカルや自社サーバーから操作する入口という位置付けです。複数モデルの結果を束ねる機能はCopilot Fusion(旧HydraFusion)のVS CodeとCLIでの試し方で扱っています。

Copilot SDKの仕組みとCopilot CLIをJSON-RPCで動かす構成の確認

SDKはモデルAPIを直接呼ぶライブラリではありません。Copilot CLIという実行エンジンを子プロセスとして抱え、その上で会話とツール実行を管理します。

アプリからSDK経由でCLIサーバーを呼ぶ3層構成と同梱ランタイム

構成は「アプリ→SDKクライアント→(JSON-RPC)→サーバーモードのCopilot CLI」の3層です。SDKがCLIプロセスの起動と停止を受け持ち、アプリはCopilotClientでセッションを作ってメッセージを送ります。会話履歴の保持、モデルの選択、ストリーミング、コンテキストが上限に近づいた際の自動圧縮もCLI側の機能をそのまま使えます。

Node.js版のREADMEによると、npm版はプラットフォーム別のオプションパッケージに検証済みのCLIランタイムを同梱し、起動時にダウンロードは走りません。既にインストール済みのCLIを使いたい場合は環境変数COPILOT_CLI_PATHでパスを指定します。

Node.js・Python・Go・.NET・Rust・Javaの6言語の導入条件

リポジトリのREADMEでは、SDKは一般提供(GA)でセマンティックバージョニングに従うとされています。npmとPyPIの最新版は、10月30日時点でいずれも1.0.28(10月28日公開)でした。

言語 ランタイムの前提 Copilot CLI
Node.js 20.19以上の20系か22.12以上 同梱
Python 3.11以上 同梱
.NET 8.0以上 同梱
Go 各SDKのREADMEで確認 別途導入
Rust 各SDKのREADMEで確認 別途導入
Java 各SDKのREADMEで確認 別途導入

導入コマンドとパッケージ名は次のとおりです。Javaだけはコマンドではなく、MavenかGradleに座標を書き足します。

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

Go、Rust、Javaでは、Copilot CLIを自分で入れてcopilotコマンドにPATHを通すか、各SDKのアプリ側同梱機能を使います。なお、Microsoft Learnの学習モジュールには「Technical Preview」と書かれていますが、これは2026年2月時点の記述です。提供段階はリポジトリのREADMEを正とします。

Node.jsとPythonでCopilot SDKを導入して初回応答を受け取る手順

ここからは公式のGetting Startedに沿って進めます。認証は、事前にcopilotコマンドでGitHubにサインインしておけばSDKがその資格情報を自動で使います。

npm installからnpx tsxで実行するTypeScriptの最小コード

空のディレクトリでESモジュールのプロジェクトを作り、SDKとTypeScript実行用のtsxを入れます。

mkdir copilot-demo && cd copilot-demo
npm init -y --init-type module
npm install @github/copilot-sdk tsx

# index.ts を保存してから実行
npx tsx index.ts

index.tsの中身は次の8行です。model: "auto"はCopilotの自動モデル選択を使う指定です。

import { CopilotClient } from "@github/copilot-sdk";

const client = new CopilotClient();
const session = await client.createSession({ model: "auto" });

const response = await session.sendAndWait({ prompt: "What is 2 + 2?" });
console.log(response?.data.content);

await client.stop();
process.exit(0);

応答を逐次表示したい場合は、streaming: trueを付けてassistant.message_deltaイベントを購読します。完了はsession.idleイベントで分かります。

pip installとdownload-runtimeで始めるPythonの最小コード

Python版のREADMEでは、インストール後にpython -m copilot download-runtimeでランタイムを先に取得する手順を勧めています。省略しても初回接続時に同じ処理が走りますが、CIやコンテナでは事前取得のほうが起動時間を読めます。

pip install github-copilot-sdk
python -m copilot download-runtime

# main.py
import asyncio
from copilot import CopilotClient
from copilot.session import PermissionHandler

async def main():
    client = CopilotClient()
    await client.start()

    session = await client.create_session(on_permission_request=PermissionHandler.approve_all, model="auto")
    response = await session.send_and_wait("What is 2 + 2?")
    print(response.data.content)

    await client.stop()

asyncio.run(main())

ランタイムの保存先はWindowsなら%LOCALAPPDATA%\github-copilot-sdk\cli\配下です。社内プロキシでGitHub Releasesに出られない環境では、COPILOT_CLI_DOWNLOAD_BASE_URLで取得元を差し替えるか、COPILOT_SKIP_CLI_DOWNLOAD=1で自動取得を止めて手配したバイナリを指定します。

defineToolで自社関数を呼ばせるツール定義とシェル実行を拒否する権限制御

SDKを使う価値は、エージェントに自社のAPIや業務データを触らせられる点にあります。同時に、CLIの持つシェル実行やファイル書き込みも同じセッションで動けるため、許可の線引きをコードで書く必要があります。

受注照会ツールを例にしたカスタムツールと権限ハンドラーの実装例

次の例は、受注番号から出荷状況を返すget_order_statusツールだけを許可し、それ以外の操作はすべて拒否します。defineToolとonPermissionRequestの書き方はNode.js版READMEの記述に合わせています。

import { CopilotClient, defineTool } from "@github/copilot-sdk";
import type { PermissionRequest, PermissionRequestResult } from "@github/copilot-sdk";

// 実際の案件では社内APIの呼び出しに置き換える
const getOrderStatus = defineTool("get_order_status", {
    description: "受注番号から出荷状況を返す",
    parameters: {
        type: "object",
        properties: {
            orderId: { type: "string", description: "受注番号(例: SO-1024)" },
        },
        required: ["orderId"],
    },
    handler: async (args: { orderId: string }) => {
        return { orderId: args.orderId, status: "出荷済み", shippedAt: "2026-10-29" };
    },
});

const client = new CopilotClient();
await client.start();

const session = await client.createSession({
    model: "auto",
    streaming: true,
    tools: [getOrderStatus],
    onPermissionRequest: (request: PermissionRequest): PermissionRequestResult => {
        // 組織の管理ポリシーが人の承認を求める操作は、自動で許可しない
        if ("managedApprovalRequired" in request && request.managedApprovalRequired === true) {
            return { kind: "no-result" };
        }
        if (request.kind === "custom-tool" && request.toolName === "get_order_status") {
            return { kind: "approve-once" };
        }
        return { kind: "reject", feedback: "このアプリでは受注照会以外の操作を実行しません。" };
    },
});

session.on("assistant.message_delta", (event) => {
    process.stdout.write(event.data.deltaContent);
});

await session.sendAndWait({ prompt: "受注SO-1024の出荷状況を教えて" });
await session.disconnect();
await client.stop();

rejectに添えたfeedbackはエージェントに返るため、モデルは拒否の理由を踏まえて回答を組み直します。ツールの戻り値はJSONにできる値なら何でもよく、モデルはその結果を読んで文章にまとめます。

approveAllの本番利用とPermission Result Kindsの選択

公式サンプルの多くはapproveAllを渡していますが、これはシェル実行、ファイル書き込み、URL取得、MCPツール呼び出しまで無条件に通します。さらにREADMEによると、組織の管理設定(enableManagedSettings)が有効なセッションではapproveAllが例外を投げる仕様です。手元の検証用と割り切り、配布するアプリでは必ず自前のハンドラーに置き換えます。

kind 意味 向く使い方
approve-once この1回だけ許可 自社ツールの呼び出し
approve-for-session セッション中は同種を許可 対話型の社内ツール
approve-for-location プロジェクト単位で記憶 開発者向けの補助ツール
reject 拒否し理由を返す シェルや書き込み
user-not-available 確認者不在として拒否 夜間バッチ
no-result 判断を他の接続先に委ねる 管理ポリシーの承認待ち

受託案件で迷ったら、approve-onceとrejectの2種類だけで組み始めます。記憶するタイプの許可は、誰がどの範囲を許したかを後から追えるログ設計とセットでないと、監査で説明できません。

認証方式と料金の扱いをAI CreditsとBYOKの2系統で見積もる手順

READMEのFAQは、SDKの課金はCopilot CLIと同じ仕組みで、送ったプロンプトが利用枠に数えられると説明しています。見積もりで先に決めるのは単価よりも「誰の枠から減るか」です。

認証の優先順位と課金先がログイン中の開発者になる条件と落とし穴

認証のドキュメントでは、SDKに直接渡したgitHubToken、GITHUB_COPILOT_API_TOKEN、環境変数(COPILOT_GITHUB_TOKEN→GH_TOKEN→GITHUB_TOKEN)、CLIの保存済みログイン、GitHub CLIの資格情報の順に使うと定めています。

落とし穴は、開発者のPCで動かした社内ツールが、本人のCopilot枠を黙って消費する点です。社員それぞれが使うツールならOAuthで利用者ごとのトークンを渡し、マルチユーザーのサーバーではセッションごとにgitHubTokenを設定します。夜間処理などの組織の自動化には、個人契約が要らず組織に直接請求されるserver-to-server認証が用意されています。

単価は個人向け課金のドキュメントで1 AI Creditが0.01米ドル、月の枠はCopilot Proで1,500、Pro+で7,000、Maxで20,000です。組織プランの枠と使用量の集計方法はAI Credits移行後のCopilot料金とBilling APIでの集計にまとめています。

BYOKでAzure OpenAI・Anthropic・Ollamaを使う設定と制約

BYOKを使うと、GitHubの認証もCopilot契約もなしにSDKを動かせ、推論費用はモデル提供元へ直接請求されます。BYOKのドキュメントに載る接続先は、OpenAI、Microsoft FoundryとAzure OpenAI、Anthropic、Ollama、Foundry Local、vLLMやLiteLLMなどのOpenAI互換APIです。

設定はcreateSessionのproviderにtype、base_url、api_keyを渡すだけですが、制約が1つあります。BYOKはキー認証のみで、Microsoft Entra ID、マネージドID、外部のIDプロバイダーには対応していません。Azureでキー認証を無効化している組織では、この時点でBYOKが使えなくなります。ローカルモデルの動かし方はCLI側の手順になりますが、Copilot CLIでOllamaのローカルモデルを使う設定が参考になります。

受託開発で見たCopilot SDKの採用条件と他のエージェントSDKを選ぶ場面

判断の軸は、CLIが持つ実行ループと道具立てをそのまま使いたいのか、モデル呼び出しから自分で組みたいのかです。

採用する場面は社内ツールにCopilotの実行ループを載せる開発支援の案件

社員がすでにCopilotを契約していて、リポジトリの調査、定型的なコード修正、社内APIを引く問い合わせボットのような開発寄りの道具を作るなら、Copilot SDKが近道です。計画、ツール呼び出し、反復、コンテキスト圧縮をCLIと同じ品質で受け取れ、モデルの切り替えもmodelの指定だけで済みます。費用も既存のCopilot契約の枠に乗るため、新しい請求先を起こさずに試せます。

業務フローに組み込む段階で、権限ハンドラーの方針や監査ログの設計から相談したい場合は、一創のAIエージェント開発で要件整理と見積もりを含めて支援しています。

見送る場面はEntra ID必須の業務アプリと利用者課金が読めない公開サービス

Azureのリソースをキー認証禁止で運用している企業の業務アプリには、Copilot SDKを選びません。GitHub認証にもBYOKにも乗せられず、認証基盤の例外申請から始まるためです。.NETやPythonで同じ基盤の上に組むなら、Microsoft Agent Framework 1.0の構成と使い方のほうが素直です。

不特定多数が使う公開サービスも採用を見送る対象です。利用者ごとにGitHubアカウントとCopilot契約を求めるか、運営側のBYOKで推論費用を丸ごと負担するかの二択になり、どちらも料金設計が読みにくくなります。Claudeのモデルを軸にした実行ループが欲しいなら、Claude Agent SDKの使い方と料金と比べてから決めます。

よくある質問

導入の検討でよく確認される点を5つにまとめました。

GitHub Copilot SDKで書いたコードはMicrosoft Copilot SDKで動きますか?

動きます。2026年10月28日の告知では、既存の利用者に即時の対応は不要で、サポート内容も変わらないとされています。10月30日時点ではnpm、PyPI、NuGetのパッケージ名も旧名のままです。今後パッケージ名や名前空間が変わる場合は段階的に案内されるため、リポジトリのchangelogとリリース一覧を見ておけば十分です。

Copilot SDKは無料で使えますか?

Copilotの無料プランにも利用枠があり、SDKからの利用も可能です。ただし無料プランで選べるのは自動モデル選択のモデルに限られ、枠を使い切ると翌月1日(UTC)のリセットまで待つことになります。BYOKなら契約自体は不要ですが、モデル提供元への従量課金が発生する仕組みです。業務で継続して使うなら有償プランか組織課金を前提に見積もります。

Copilot SDKとCopilot CLIはどう違いますか?

Copilot CLIは人が端末で対話するためのツールで、SDKはそのCLIをサーバーモードで起動し、JSON-RPCでプログラムから操作するためのライブラリです。エージェントの実行ループ自体は同じものを使います。SDKでは独自のツール定義、権限の判定、イベントの購読をコードで書ける点が違います。課金の数え方も同じです。

Copilot StudioやCopilot Managed Runtimeとはどう使い分けますか?

Copilot Studioはローコードでエージェントを組む製品で、Copilot SDKはコードから実行ループを呼び出す開発者向けの部品です。Microsoft 365のテナントで社内アプリを動かす基盤が必要なら、Copilot Managed Runtimeの作成手順と統制の領分になります。GitHubリポジトリや開発作業に近い道具を作るならCopilot SDKが合います。

エージェントにシェルコマンドを実行させない設定はできますか?

シェル実行を拒否する設定は可能です。onPermissionRequestに渡すハンドラーでrequest.kindが"shell"のときに{ kind: "reject" }を返せば、シェル実行は止まります。ファイル書き込みは"write"、URL取得は"url"で同じように判定する仕組みです。種類は今後増える可能性があるため、許可するものだけを列挙して、それ以外は既定で拒否する書き方にします。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.28 テックブログ リンツ不正アクセス:314万件の対象確認とパスワード強制リセット後の対処
  2. 2026.10.29 テックブログ ソニー生命の不正アクセス:38.5万件の対象確認と窓口、停止中の手続き
  3. 2026.10.27 テックブログ Brotli 脆弱性:CVE-2026-111497の影響確認とNode.js・Python・.NETの更新手順
  4. 2026.01.30 コラム 税務調査は個人と法人で何が違う?担当部署・件数・調べられる点と追徴税額を比較【令和6事務年度】
  5. 2026.09.26 コラム 価格転嫁とは?価格交渉促進月間の調査に回答義務はあるか・取適法の協議記録まで

RELATED POSTS 関連記事

目次