How to implement Copilot harness in your program

In this article, I will explain how to embed the Microsoft Copilot harness into your own applications using the Microsoft Copilot SDK.

The Copilot harness is more than an AI model. It includes instructions, context, tools, execution environments, permissions, and session management. I will explain how these components work together and how the same harness is used across products such as Visual Studio Code, Copilot CLI, Microsoft Foundry, and Copilot Studio.

I will also compare the main options for running models with the harness, including GitHub Copilot models, Copilot Fusion, Bring Your Own Key with Microsoft Foundry or other providers, and local models through Foundry Local or Ollama. The session will clarify the differences between using a Foundry-hosted model through the SDK and running the entire Copilot harness as a managed service in Foundry.

The second half of the session will focus on practical application design. I will cover runtime connection choices, user and server-to-server authentication, session lifecycle management, permission handling, usage tracking, and safe BYOK configuration. I will also discuss common implementation risks, such as exposing the host file system, automatically approving tool requests, sharing sessions without application-level locking, and relying on preview APIs without contract tests.

By the end of the session, you will understand how to choose the right Copilot integration approach for desktop applications, developer tools, server-side workloads, managed agents, and environments where code or data must remain on the local device.

Transcript

1. Copilot DevDay 2026 ― Microsoft Copilot SDK、Foundry、BYOK、Copilot Fusion をどう使い分けるか Kazushi Kamegawa ｜ 情報の基準日 2026-10-29
2. This contents based on 2026/10/31 ※今作っているアプリの経験に基づいた情報です Images created by Adobe Firefly
3. https://dev.azure.com/tfsug/tfsuginfo https://kkamegawa.hatenablog.jp https://dev.to/kkamegawa https://www.clueup.org https://devblog.connpass.com/
4. リポジトリの設定、初期ファイル、Actions、ルールセット、セキュリティ機能などを設定ファイルに記述 し、計画を確認して適用する GitHub CLI 拡張機能です。既存リポジトリの設定は import で取り込めます。 gh-repospec — kkamegawa
5. winget 風の YAML manifest を CI から Microsoft Intune の LOB アプリとして公開する ためのツール。 GitHub Actions と Azure Pipelines の workflow 例を用 意しています。 RelayPublisher — kkamegawa
6. ContextRelay for VS — kkamegawa ContextRelay — kkamegawa Microsoft 365 CopilotをVisual Studio / Visual Studio Codeから呼び出す拡張機能
7. INTRO Agenda 1 「Copilot harness」 はそもそも何？ 2 GitHub Copilot SDK からの変更点 3 どこで動かす？ BYOK Foundry ローカル 4 事故が起きやすい場所
8. Copilot SDK とは？ 普段使っている Copilot の「エージェントの中身」を、自分のアプリから呼べる部品 いつもの使い方 利用者 VS Code / Copilot CLI Copilot の エージェント モデル Copilot SDK (TS/Py/Go/.NET/Rust/Java) runtime（CLI） = 同じエージェント モデル SDK を使うと 自分のアプリ JSON-RPC チャット UI ではなく、セッション・ツール・権限・イベントを「API」として扱う、というのが SDK の世界 ※内部ではVS Code / Visual Studioも Copilot SDKベースへ移行中。CLIバンドル時はライセンスに注意
9. 「harness」= モデルの外側すべて 同じ harness が VS Code、Copilot CLI、GitHub Copilot app、Copilot Studio をまたいで使われる 指示 システムメッセージ、プロンプト 実行環境 harness コンテキスト ファイル、会話、skill 作業ディレクトリ、sandbox 制御 モデル 権限、承認、使用量 ツール 状態 ファイル読み書き、Shell、MCP セッション、再開 SDK は「Microsoft Copilot harness のプログラマブルなインターフェース」
10. GitHub Universe 2026 Before/After 2026-06-02 2026-10-27 2026-10-28 2026-10-28 2026-10-28 Copilot SDK GA S2S 認証 SDK 改名を発表 Foundry で提供 Copilot Fusion GA 6言語、Rust・Javaも 正式対応、API安定 化 server-to-server 認証が public preview GitHub Copilot SDK → Microsoft Copilot SDK Microsoft Copilot harness を Foundry で提供（ preview） モデルの自動ルーテ ィングと複数モデルの 連携
11. 改名でかわること、かわらないこと 変わったこと • SDK =「Microsoft Copilot harness のプログラマブ ルなインターフェース」 • repo は Microsoft org へ移行予定（日程は未発表） • 改名後のパッケージ名・移行時期は未発表 当面そのまま使えるパッケージ npm NuGet crate @github/copilot-sdk GitHub.Copilot.SDK github-copilot-sdk 既存ユーザーはすぐ対応しなくてよい。 ※ 将来的には移行必須（Legacyってついたら移行） 依存のバージョンを厳密に固定し、契約テストで移行できる手順を今のうちに作る
12. 4つの「Copilot harness」を見分ける 今日いちばん持ち帰ってほしい表 何？ 呼びだし方法 課金 向いている用途 (a) Copilot SDK アプリに組み込む SDK と runtime JSON-RPC （stdio / URI / in-process） Copilot / S2S組 織 / BYOK 自分のアプリ・ツールに組み込 む (b) Foundry Copilot harness prompt agent の managed runtime （sandbox は Foundry） Responses API + conversation Azure サーバーをマネージドで動かす (c) Foundry hosted agent 自作コードをコンテナで運用 Responses / Invocations Azure 実行環境やフレームワークを自 分で持つ (d) Copilot Studio の harness ローコードでエージェントを作る Copilot Studio のチャネル Copilot Credits ローコードの業務エージェント 名前は似ていても、データの流れも課金も別物。アプリに部品として組み込むのは (a) と (b)
13. SDKのバージョンアップと破壊的変更の歴史 GA になったから安心、ではない。AIの移り変わりは早い 技術プレビュー 2026年初頭 v0.2.0 03-20 public preview 04 GA v1.0 06-02 v0.2.0 Python の設定API刷新、on_permission_request 必須化、autoRestart 廃止 v1.0.5 getBearerToken → bearerTokenProvider v1.0.13 session.destroy の置き換え（CHANGELOG では detach、ドキュメントでは disconnect） v1.0.28 10-28
14. 接続方式: 3つの RuntimeConnection どの方式でもプロトコルは JSON-RPC。セッション・ツール・フック・権限の機能は同等 RuntimeConnection. RuntimeConnection. RuntimeConnection. ForStdio() ForUri(url) ForInProcess() SDK が runtime を子プロ セスとして起動（既定、CLI 同梱） 起動済みの headless runtime に TCP で接続 copilot --headless -port ネイティブ runtime を自分 のプロセスにロード 安定 共有 runtime experimental (GHCP001)
15. モードと認証 Mode 既定モード = CLI 相当 認証の選択肢 1 何もしないと ホストのファイルシステムが見える Mode = Empty 組込みOSツールを無効化。ツール、MCP、skill は allowlist で明示。サーバーでは必須 2 3 4 ログイン済みユーザー copilot login セッション単位の GitHubToken 1つの runtime で複数ユーザーを分離 S2S（public preview） GitHub App インストールトークン ghs_、1時間で失効、組 織課金 BYOK Foundry / Foundry Local / Anthropic / Ollama な ど
16. モデルはどこで動かす？ 5つの選択肢 同じ Copilot harness の下で、モデルの出どころと課金だけが変わる あなたのアプリ → Copilot SDK → Copilot runtime（harness） Copilot のモデル Copilot Fusion BYOK: クラウド BYOK: ローカル Foundry harness サインイン（copilot login / GitHubToken）でモ デルを指定 モデルではなく「ルー ター」を選ぶ。effort を指定 Foundry / Azure OpenAI / OpenAI / Anthropic Foundry Local / Ollama / vLLM な ど harness ごと Foundry で動かす（ SDK ではなく Responses API） Copilot サブスクリ プション 使ったモデルごとの 標準料金 プロバイダーの課金 PCのリソース（課金 なし） Azure サブスクリプ ション
17. Copilot Fusion: モデルを選ばず「努力レベル」を選ぶ 2026-10-28 GA。Auto のモデル選択と Project HydraFusion の複数モデル連携を統合 effort level 実行パターン（プロンプトごとに選ばれる） Fusion Standard なモデル 日常のコーディング。versatile Single 1つのモデルがそのまま解く Fusion High 難しいタスク、深い推論 Cascade 効率のよいモデルが下書き → 判定で受理 or 強いモデルへ Fusion Max 最も難しいタスク。最も能力の高 いモデル Critique 1つが下書き → 別モデルがレビュー → 元の モデルが修正 管理者は Fusion が使えるモデルを組織のモデルポリシーで制御可能。 課金は使われたモデルごとの標準料金。 ローカルモデルへの振り分けは実験的プレビュー ※ 2026/11/30までは30%割引
18. PART 3 ｜ MODELS Fusion とアプリ組み込みの関係 「モデルを選ぶ」ことをアプリ側の責務から外せるか Fusion が効く場面 アプリ側でモデルを決めたい場面 • 対話的なコーディング（VS Code、Copilot app、Copilot CLI など） • 処理ごとにコストや応答時間を固定したい • 構造化出力のように特定モデルの挙動に依存する タスクの難しさが毎回違う • • モデルの入れ替わりに追従したくない • BYOK で自分のモデルを使う（Copilot のルーティングは 通らない） 2026/10/31時点でSDK のセッションから Fusionは指定できない、みたい ※ Auto の Balance, Intelligence, efficiencyは可能
19. Copilot の BYOK でもいけるのか？ → いける 自分のモデル（プロバイダー）を Copilot の harness で使う。GitHub 認証なしでも動く プロバイダー type メモ Microsoft Foundry / Azure OpenAI openai / azure /openai/v1/ なら openai OpenAI openai OpenAI 互換も同じ Anthropic anthropic Claude 系 Foundry Local / Ollama openai ローカル、キー不要 vLLM / LiteLLM など openai OpenAI 互換 session = createSession({ model: "<デプロイ名>", provider: { type: "openai", baseUrl: "https://<resource>.openai.azure.com/openai/v1/", wireApi: "responses", bearerTokenProvider: () => Entra トークン } }) モデルの条件: tool calling と streaming に対応している こと（128k 以上のコンテキスト推奨）
20. BYOK の落とし穴と、おすすめの設定 落とし穴 4つ おすすめ: Entra 認証に限る キーは保存されない [byok] provider = "foundry" # | "foundry-local" base_url = "<foundry-openai-v1-endpoint>" wire_api = "responses" credential = "azure-cli" # | "azure-developer-cli" resume のたびに provider を渡し直す モデル一覧は runtime が知らない OnListModels で自分で返す 使用量が見えない • bearerTokenProvider が PC の資格情報からトークンを都度取得 Copilot の quota には計上されない • 静的 API キー、bearerToken、apiKeyCommand は受け付けない • 設定はユーザーの PC のローカルだけに置く • ほかのコーディングエージェントにはdeny設定して絶対に触らせない Copilot のルーティングを通らない Fusion などは対象外。モデルは自分で選ぶ
21. 「Foundry を使う」には2通りある モデルだけ Foundry か、harness ごと Foundry か SDK + BYOK（Foundry のモデル） Foundry Copilot harness harness が動く場所 自分のプロセス（SDK の runtime） Foundry（managed、sandbox も Foundry） 呼びだし方法 SDK（JSON-RPC） Responses API + conversation ファイル・ツール ローカルの作業ディレクトリ、自分で allowlist Foundry の sandbox、harness ツールを設定 モデル Foundry のデプロイ（BYOK） Foundry のモデル（BYOM 不可） 状態 GA の SDK preview・SLA なし・リージョン限定 向いている用途 PC 上のリポジトリを扱うコーディング サーバー側の計画・レビュー・業務処理
22. ローカルモデルで動かす: Foundry Local / Ollama データを PC の外に出さずに Copilot の harness を使う よいところ 気をつけるところ • プロンプトもコードも PC の外に出ない • tool calling と streaming に対応したモデルが必要 • キーが要らない（認証なし） • コンテキスト長と PC の性能に左右される • 従量課金がない • Foundry Local はポートが動的 → 起動のたびに foundry service status で解決 • Ollama は OpenAI 互換の /v1 を指す 「クラウドに出せない」要件には BYOK ローカル。ただし、モデルの能力が足りるかは必ず試す(グラボ高い）
23. 選択肢ごとの課金と使用量の見え方 「誰の課金で何が動いたか」をアプリが説明できるようにする 選択肢 課金 アプリから見える使用量 Copilot のモデル（サインイン） ユーザーの Copilot サブスクリプション（AI credits） account.getQuota の providerQuotas Copilot Fusion 使われたモデルごとの標準料金 UI では使用モデルを確認できる （SDK からは今のところ無理っぽい） S2S（GitHub App） App をインストールした組織 組織の課金 BYOK（クラウド） プロバイダー（Foundry など） Copilot の quota には出ない BYOK（ローカル） なし なし Foundry Copilot harness オペレーターの Azure サブスクリプション Azure 側 session.usage.getMetrics の totalNanoAiu（AI credits）は experimental。欠けても動くように作る
24. セッション、イベント、使用量 アプリに組み込むとき一番効いてくるところ セッション 人に尋ねるイベント 使用量 • sessionId がないと resume できない • permission.requested • • user_input.requested disconnect = メモリだけ解 放 • elicitation.requested account.getQuota の providerQuotas が正（ snapshots は legacy） exit_plan_mode.requested • • • deleteSession = 完全削 除 • subagent.*、session.idle など session.usage.getMetri cs の totalNanoAiu = AI credits（experimental） • セッションロックはない（並 行アクセスは未定義） •
25. 組み込みの参照構成: エッジとサーバー 例: 複数のコーディングエージェントを束ねるアプリ（実装はユーザーPC、計画とレビューはサーバー） ユーザーPC（エッジ） あなたのアプリ 自前のプロトコル Copilot SDK サーバー バックエンド（計画・レビュー） stdio Copilot / Fusion （ユーザーのサインイン） Copilot runtime Foundry Copilot harness Copilot SDK (S2S) BYOK（Entra） Foundry / Local Responses API オペレーターの Azure runtime（Empty） + App token 原則: ユーザーの資格情報はサーバーに預けない。個人のサブスクリプションをサーバーから使わない
26. パターン①: 接続は stdio、in-process は使わない ✕ in-process の制約 • runtime がホストプロセスの cwd と環境を共有（クライア ントごとの作業ディレクトリ指定不可） • プロセス分離なし（runtime の障害がアプリ全体に波及） • 1プロセスに読み込めるネイティブライブラリは1バージョン だけ • 全SDKで experimental 「新しいから使う」ではなく、自分のアプリの並行モデルに合うかで選ぶ ✓ stdio の子プロセス worktree 1 runtime（子） worktree 2 runtime（子） worktree 3 runtime（子）
27. パターン②: セッションと権限 sessionId = "{app}-{taskId}-g{generation}" // 決定的に生成 → アプリ再起動後も resume できる 直列キュー すべて人に尋ねる SDK にロックがないため、セッションごとに1本のキューで execute / follow-up / 回答を処理 権限、入力、elicitation、プラン終了の要求を アプリの承認 UI に 出し、回答まで待つ 自動承認は禁止 二重の読み取り専用 ApproveOnce を即返すサンプルをそのまま使わない。タイムアウト しても承認にしない availableTools の allowlist + OnPreToolUse で書き込み系・ Shell を deny
28. パターン③: セッションのライフサイクルと使用量 実行 中断・完了 disconnect deleteSession execute / follow-up abort → プロセス グループ終了 メモリだけ解放 ディスク状態は残す worktree 片付け時に 完全削除 follow-up の渡し方 使用量 • 実行中ターンあり → steering / queueing • サインイン時: providerQuotas を報告 • ターンなし → ResumeSession してから送信 • totalNanoAiu は補助（experimental。欠けても動く） • 保存先は SDK 既定（COPILOT_HOME）。DB へはリダイレク トしない • BYOK 時: Copilot の quota は報告しない • session_limits_exhausted.requested → タスクを paused
29. パターン④: Foundry harness を計画・レビューに サーバー側の計画・レビュー処理に使う（preview） 構成 指定するとエラー（無視されない） • configuration のバージョン×ロールごとに prompt agent を 作成（MicrosoftCopilotHarness） • harness ツールは既定 OFF。review のみ filesystem_read text.format temperature top_p tool_choice max_output_tokens parallel_tool_calls truncation … • Shell は常に OFF、egress は Deny • 1リクエスト = 1 conversation、キャンセル = conversation 削除 • harness は作成後に変更不可 → 新しいエージェントで作り直 す → structured output に頼らず、JSON スキーマ検証 + 1回 だけリトライ 可用性 preview・SLA なし・リージョン限定（Japan East 可）・BYOM 不可 → 明示オプトイン
30. Foundry harness の呼び出しパターン アプリのバックエンド抽象を Foundry に写す バックエンドの操作 Foundry での実装 開始 conversation を作成し、アプリのリクエストIDに対応付けて保存 完了待ち JSON スキーマで検証 → 失敗したら同じ conversation で1回 だけ修正依頼 → それでも失敗ならリクエストを失敗 キャンセル conversation を削除（responses.delete には非対応） ロールごとに toolset が違うので、エージェント名にロールを含める agent name = "{app}-{role}-{configId}-v{version}" // role = plan | review • Azure.AI.Projects.Agents / Azure.AI.Extensions.OpenAI を 3.0.0beta.5 に固定 • 呼び出し側に Foundry User ロール • egress は Audit で確認してから Enforce
31. レビューのデータの流れ diff 本体が届くかどうかで分岐する Yes: diff 本体が届く → サーバー側 review 対象 worker（エッジ） タスク結果 diff 本体を サーバーへ送る設定？ → 生成とは別の provider がレビュー。diff はオペレーターの Azure（Foundry project）へ No: changedFiles / insertions / deletions のみ → 理由を記録して review を失敗。他 provider で代替実行し ない ユーザーが送ると決めたデータだけを扱い、データの行き先をドキュメントに明記
32. パターン⑤: S2S で Copilot をサーバーから使う 1リクエスト = 1クライアント。使ったら捨てる Key Vault トークン発行 クライアント起動 破棄 App 秘密鍵 インストールトークン （1時間で失効） Empty / ForStdio ツールなし deleteSession + 停止 new CopilotClient { Mode = CopilotClientMode.Empty, Connection = RuntimeConnection.ForStdio(), GitHubToken = installationToken, UseLoggedInUser = false // availableTools は空 } サーバーが持つ資格情報 ユーザーのトークンは持たない。持つのは組織が所有する GitHub App の資格情報と、そこから発行した短命のトークン だけ
33. S2S: トークンとエラー処理 秘密鍵の置き場所 スコープ azure: Key Vault（managed identity） local: user-secrets organization_copilot_requ ests: read タイムアウト ログ 契約のタイムアウトは1時間より 十分短く。超えたらクライアント停 止 トークンは保存もログ出力もしな い（スクラブ） 401（失効） 再発行して1回だけ再試行 403（組織で未有効化） 理由を記録して失敗 無効時 機能フラグで明示的に有効にしたときだけ 動かす 共有 runtime + セッション単位 GitHubToken は採らない：S2S トー クンでの動作を一次情報で確認できていないため
34. 検証方針: 契約テストで確かめる ドキュメントの表記が揺れている以上、動く事実をテストで固定する エッジ / サーバー Foundry S2S • セッション作成と再開（決定的ID） • • トークン発行・失効をモック • permission.requested で回答ま で止まる 禁止フィールドを送らない （単体テスト） • 401 のときの再試行 モックでconversation 作成・削 除 • • ログにトークンを出さない • モックでスキーマ検証 + 1回リト ライ • project への結合テストは有効 時のみ実施する（節約） • availableTools の制限 • account.getQuota の形 • detach • BYOK で provider を渡し直す
35. どれを選ぶか: 用途別の早見表 やりたいこと 選ぶもの 自分のツールやデスクトップアプリに Copilot のエージェントを入れる Copilot SDK + ユーザーのサインイン モデル選びを Copilot に任せたい Copilot Fusion（現在はCopilot App/CLI/VS Codeのみ） 自社の Foundry のモデルや契約で動かしたい Copilot SDK + BYOK（Entra 認証） コードやデータを PC の外に出したくない Copilot SDK + BYOK ローカル（Foundry Local or Ollama） サーバーから組織として Copilot を呼びたい Copilot SDK + S2S（GitHub App、preview） サーバー側でエージェントをマネージドに動かしたい Foundry Copilot harness（preview） フレームワークや実行環境を自分で持ちたい Foundry hosted agent ローコードで業務エージェントを作りたい Copilot Studio の GitHub Copilot harness
36. 組み込み時の注意点 トップ10 1 依存は厳密に固定、契約テストを通してから上げる 6 in-process は cwd・環境・ネイティブ lib を共有 2 preview は オプトイン。使えないときは代替実行せず 失敗 7 BYOK: キー非保存、quota なし、モデル一覧は自前 で処理 3 サーバーでは必ず Empty モード。builtin:* 禁止 8 ユーザー認証はセッションの GitHubToken で分離 しよう 4 OnPermissionRequest のサンプルをそのまま使わ ない 9 Foundry harness は禁止フィールドでエラーになる 5 sessionId は自分で決め、ロックはアプリ側で用意 10 Shell は境界にならない。egress とデータ所在を明 記
37. まとめ 1 2 3 4 「Copilot harness」は4種類 アプリに部品として組み込むのは (a) SDK と (b) Foundry harness 違いは名前だけではない 接続、モード、認証、セッション、使用量のすべてに及ぶ モデルは選べる Copilot のモデル、Fusion、BYOK（Foundry・ローカル）、Foundry harness。課金と使用量の見え方が変わる 事故はサンプルのコピペから Empty モード、自動承認の禁止、セッションロック、禁止フィールド。契約テストで確かめる ありがとうございました