Copilot harnessとは|料金・SDK・始め方
「GitHub Copilot SDKが『Microsoft Copilot SDK』に名前を変えたけれど、コードは直す必要があるのか」「FoundryのCopilot harnessは何者で、いつからお金がかかるのか」——2026年10月28日のGitHub Universeで発表が重なり、何が新しく何が名前だけの変更なのか、見分けにくくなっています。
結論から言うと、Copilot harnessはGitHub CopilotやCopilot Studioの裏で動いている「エージェントを回す仕組み」そのもので、今回それがMicrosoft Foundryのマネージドサービスとしてパブリックプレビューになりました。SDKとCopilot Studioの改称は名前だけの変更で、既存のコードやエージェントはすぐには直さなくて構いません。Foundry側の実行環境の利用料は2026年11月30日まで無料で、12月1日から従量課金が始まります。
株式会社Fyveは、Mac miniの上で自前のエージェント実行環境(いわば自作のハーネス)を組み、記事の執筆・監査・公開までを無人で毎日回しています。本記事では公式発表の中身を整理したうえで、Microsoftが「開発者の責任」として残した部分を、私たちが自前の環境で実際にどう踏み、どう塞いだかとあわせてお伝えします。
Copilot harnessとは|GitHub Copilotの裏側をそのまま使える実行基盤
Copilot harness(正式名称はMicrosoft Copilot harness)は、AIモデルの周りで動く部分の総称です。Microsoft公式ブログ(2026年10月28日)は「モデルが知能を担うなら、ハーネスはモデル以外のすべて」と説明しています。具体的には次のものを受け持ちます。
- エージェントのループ(考える→ツールを呼ぶ→結果を読む→次を決める、の繰り返し)
- プロンプトと作業中のコンテキストの管理
- ファイルの読み書き・シェルの実行・Web取得などのツール呼び出し
- コードを安全に動かすためのサンドボックス
- 小さな作業を別のエージェントに任せる「サブエージェント」への委任
このハーネスはGitHubのエンジニアリングチームが作ったもので、公式ブログによればGitHub Copilotアプリ、CLI、VS Code、Copilot Studioなどを同じハーネスが動かしています。最近Rustに移植され、セッションの立ち上げや最初の応答までの時間が短くなったとも書かれています。対応モデルは「20以上のフロンティアモデルと、自前のAPIキーの持ち込み(BYOK)」です。
要するに、これまでGitHub Copilotの中に閉じていたエージェントの土台を、自社のアプリやサービスに組み込めるようにした、というのが今回の発表の中心です。
10月28日に発表された3つのこと
同じ日に3つの発表が出たため、混同されがちです。新機能は1つで、残り2つは改称です。
発表 | 中身 | 既存ユーザーへの影響 |
|---|---|---|
FoundryでCopilot harnessをパブリックプレビュー | Foundry Agent Serviceで、エージェントのループとサンドボックスをMicrosoftが運用する形で使える(新機能) | 新しく作るエージェントで選ぶもの。既存エージェントは変わらない |
GitHub Copilot SDK → Microsoft Copilot SDK | SDKを「Microsoft Copilot harnessを操作するためのインターフェース」と位置づけ直し、リポジトリもMicrosoftの組織へ移す予定 | すぐの変更は不要。パッケージ名や名前空間はしばらく旧名のまま |
Copilot Studioの「GitHub Copilot harness」→「Microsoft Copilot harness」 | 名称の変更のみ。製品内の表記は数週間かけて切り替わる | 機能・課金の変更なし(Microsoft公式発表) |
GitHubのchangelog(2026年10月28日)は、SDKについて「移行は段階的に進むので、パッケージ名・名前空間・一部のドキュメントは当面GitHub Copilot SDKのまま」「既存ユーザーはすぐに変更する必要はなく、サポートも変わらない」と明記しています。つまり、今 pip install github-copilot-sdk や npm install @github/copilot-sdk で入れているコードは、そのまま動きます。

Microsoftが持つもの・開発者が用意するもの
公式ブログは分担を一文でまとめています。「Microsoftがエージェントのループとサンドボックスを動かす。あなたは指示・スキル・ツール・モデルの選択を持ち込む」。Foundryの開発者ブログ(2026年10月28日)が挙げている構成要素は次の4つです。
構成要素 | 何をするか |
|---|---|
スキル(再利用できる手順) | 指示・スクリプト・補助資料を1つにまとめ、エージェントが複数の作業で使い回す。例として |
接続するツール | FoundryのツールとMCP(Model Context Protocol)ツール。認証と承認は明示的に設定する |
実行と委任 | ファイルとコードを扱い、範囲を区切った作業を組み込みのサブエージェントに任せる |
定義のソース管理 | Foundryの画面で作って試すか、エージェントの定義をアプリのコードと一緒にリポジトリで管理する |
注目したいのは、スキルの書式が SKILL.md だという点です。Claude CodeやCodexで使われている「Agent Skills」と同じ形の書式で、手順書をMarkdownで書いてフォルダごと渡します。私たちも業務手順をこの形で90本近く持っていますが、書式が揃ってきたことで、同じ手順書を別のハーネスに載せ替える現実味が出てきました。ただし、書式が同じでも、ツール名や権限の前提が違えばそのままは動きません。この点は別の記事で詳しく検証しています。
Agent Skillsのオープン標準とは|そのまま動くは誤解
Foundryで新しくエージェントを作ると、ファイルの読み取り・書き込み、シェルの実行、Web取得、サブエージェントへの委任の5つの組み込みツールが既定で有効になる、と報じられています(Xenospectrum、2026年10月29日確認)。
Copilot harnessの料金|11月30日まで無料、12月1日から従量課金
料金はFoundryの開発者ブログ(2026年10月28日)に書かれています。2026年10月30日時点の公表値は次のとおりです。
項目 | 2026年11月30日まで | 2026年12月1日から |
|---|---|---|
ハーネスの実行(サンドボックスのCPU) | 無料 | 1 vCPU・1時間あたり 0.0994米ドル |
ハーネスの実行(メモリ) | 無料 | 1 GiB・1時間あたり 0.0118米ドル |
モデルの推論 | 別料金(選んだモデルの料金がかかる) | |
別料金のツール・接続サービス | それぞれの料金がかかる | |
いずれも米ドル建ての標準価格で、ブログには「地域や契約によって変わる」とあります。税の扱いはAzureの通常の請求条件に従うため、ここでは税抜の公表値として扱っています。契約前に最新の公式情報をご確認ください(Microsoft Foundry Blog)。
どのくらいかかるかの試算
CPUとメモリの割り当てはMicrosoftが決めるため、利用者は選べません。ここでは仮に「2 vCPU・4 GiB」のサンドボックスが動いたとして計算します。
- CPU: 0.0994 × 2 = 0.1988米ドル/時間
- メモリ: 0.0118 × 4 = 0.0472米ドル/時間
- 合計: 約0.246米ドル/時間(モデルの推論料は含まない)
1日8時間・月22日動かし続けると176時間で約43米ドルです。実際にはタスクが終わればサンドボックスは止まるので、ここまでかかるのは「常にどこかで作業が走っている」使い方の場合です。私たちの経験では、エージェントの費用の大半はモデルの推論料で、実行環境の費用は小さい側に入ります。費用を見積もるときは、先にモデル側の単価と1タスクあたりのトークン量を押さえるほうが外しません。
なお、無料期間は「ハーネスの実行」だけが対象で、11月中もモデルの推論料はかかります。「プレビュー中は全部タダ」ではない点に注意してください。
Copilot harnessの始め方|3つのルート
1. Foundryの画面から作る
Foundryのポータル(ai.azure.com)でエージェントを新規作成し、作成時にCopilot harnessを使う設定を選びます。海外の開発者による手順記事では、Build → Agents → New agentと進み、「Use the Microsoft Copilot harness」にチェックを入れてプレイグラウンドを開く流れが紹介されています。スキルは、その場で書く・既存の SKILL.md をアップロードする・Foundryのスキルカタログから参照する、の3通りで足せるとされています。
2. Azure Developer CLI(azd)で定義をコードとして管理する
公式ブログが示しているのは、azure.yaml にエージェントを定義し、skills: でスキルのフォルダを紐づけ、azd deploy --all で配備して azd ai agent invoke で呼び出す流れです。エージェントの定義をアプリと同じリポジトリでレビュー・管理したい場合はこちらが向いています。ほかに、VS CodeのFoundry Toolkitや、GitHub CopilotアプリのMicrosoft Foundryプラグインからも作れます。
3. Microsoft Copilot SDKで自分のアプリに組み込む
実行環境を自分で持ちたい場合はSDKを使います。対応言語はNode.js/TypeScript・Python・Go・.NET・Rust・Javaの6つです(GitHubのリポジトリREADMEで確認)。Pythonの最小構成は次のとおりです。
pip install github-copilot-sdkimport 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("この請求書の合計を確認して")
print(response.data.content)
await client.stop()
asyncio.run(main())パッケージ名はまだ github-copilot-sdk のままです。SDKを使うにはGitHub Copilotの契約(使用量に上限のある無料枠あり)か、対応するプロバイダーのAPIキーを使うBYOKが必要です。BYOKはAPIキーによる認証だけに対応しており、Microsoft Entra IDやマネージドIDでの認証はできない、とREADMEに書かれています。社内でAPIキーを配らない運用をしている会社は、ここが最初の壁になります。
上の例の PermissionHandler.approve_all は、ツールの呼び出しをすべて自動で許可する設定です。動作確認には便利ですが、そのまま本番に持ち込むと、エージェントがファイルの削除や外部への送信を誰の確認もなく実行できてしまいます。本番では、許可する操作を絞った承認処理に置き換えてください。
SDKではエージェントごとに使えるツールとスキルを絞れます。customAgents にエージェントを並べ、skills に読み込ませるスキル名を書くと、セッション開始時にそのスキルの全文がコンテキストに入ります。スキルは明示したものだけが入り、サブエージェントは親のスキルを引き継ぎません。
プレビューの制約|本番に入れる前に確認すること
- 既存のエージェントは切り替えられない: ハーネスはエージェントを作るときに選ぶもので、作った後の切り替えはまだできません(公式ブログ)。今あるFoundryのエージェントをハーネスに移すには作り直しになります
- サンドボックスの性能は選べない: CPU・メモリ・アイドル時の設定はFoundryが管理します(公式ブログ)。組み込みツールの承認ポリシーもMicrosoft側が管理する、と報じられています
- 使える地域・モデル・ツールが限られる: 対応範囲はMicrosoft Learnの制限ページに載っており、Foundry Agent Service全体より狭い、とされています。推論とツール呼び出しに対応したモデルのうち、その地域で使えるものに限られます
- 本番向けの保証がない: プレビューのためサービスレベルの保証(SLA)がなく、商用の本番での利用は推奨されていない、と報じられています(Xenospectrum)
- 名前の切り替え中の不整合: Azure Developer CLIのプルリクエストでは、新しい名前での配備が地域ごとの展開待ちでエラーになるという報告が出ています。名前の移行期は、ドキュメントの名前と実際の設定値が食い違うことがあると考えておくのが安全です
私たちなら、12月1日の課金開始までの無料期間を「社内の小さな業務1つで試す期間」に充て、本番の顧客向け処理には入れません。プレビューのうちに見ておきたいのは、性能より止まったときの振る舞いです。次の節がその理由です。
Microsoftが開発者に残した3つの責任と、私たちが自前の環境で踏んだ穴
ハーネスを任せても、すべてを任せられるわけではありません。Foundryのドキュメントや報道では、開発者に残る責任として次の3つが挙げられています。
- 冪等性(べきとうせい): 中断して再開したときに、同じ外部操作(データベースの更新やプルリクエストの作成など)が二重に実行されないようにする
- チェックポイント: 長い作業を再開できるよう、途中経過を保存する
- 外部との接続: つないだサービスごとに認証・ネットワーク・承認の決まりがあり、送ったデータはそのサービスの規約に従う
Foundryの開発者ブログも、ホステッドエージェントについて「中断された作業は元の入力で再開される。進捗の保存と、再開時の重複操作の防止はコードの側でやる」と書いています。
この3つは、私たちが自前のハーネスで実際に事故を起こしかけた場所と、ぴったり重なります。私たちはMac mini上でClaude Codeをヘッドレス(画面なし)で動かし、1日3回、記事の種選び→執筆→別プロセスのAIによる監査→公開までを人の手を介さずに回しています。以下は、その運用で起きたことです。

穴1:再実行で、既存の記事を上書きできてしまう(冪等性)
公開に使うAPIは「指定したIDの記事を作る、またはあれば上書きする」動きをします。つまり、IDを1つ間違えるか、途中で落ちて同じ処理をやり直すだけで、すでに検索で読まれている記事を消してしまえます。
私たちが入れた仕組みは2つです。1つは公開の直前に「そのIDの記事がまだ存在しない」ことを確認し、存在したら書かないこと。もう1つは、既存の記事に関連リンクを足すときは専用のスクリプトだけを通し、「追記した部分を取り除くと元の本文と1バイトも違わない」ことを確かめてから保存し、保存後に読み戻して違っていれば自動で元に戻すことです。同じリンクがすでにあれば何もしないので、何度実行しても結果は1回分にしかなりません。
既存の記事が壊れても、検索の数字には数週間後の「クリックが減った」としてしか表れず、後から気づいても取り返せません。だからこそ、人の確認を挟まずに機械で止める作りにしました。
穴2:途中経過をどこに置くか(チェックポイント)
1日3回のジョブは、毎回まっさらな状態から始まります。前回どの種を使ったか、どれを見送ったかを覚えていないと、同じ記事を2本書いたり、同じ種を何度も検討したりします。
私たちは台帳のファイル1つに状態をすべて書き、書き込むのはこのジョブだけにしました。種の在庫・執筆済み・公開済み・見送り(理由つき)を1行ずつ持ち、ジョブは最初に台帳を読み、最後に台帳を更新します。書き手を1つに限ったのは、複数の仕組みが同じファイルを書くと、どちらの記録が正しいのか分からなくなるからです。実際、同じ変更が別々の経路で2回記録され、統合できなくなったことがありました。
穴3:入れ子のプロセスに認証が渡らない(外部との接続)
監査は、書いたAIとは別のプロセスで立ち上げたAIに任せています。2026年8月12日の夜、この監査用のプロセスが使っていた保存済みのログイン情報が期限切れになりました。親のプロセスの認証情報は子のプロセスに自動では引き継がれない作りだったため、その日から25回続けて監査が「判定できない」で終わりました。
事故にならなかったのは、「判定できないときは公開せず下書きに退避する」と最初に決めていたからです。25本は公開されずに下書きに残り、原因が分かってから認証情報を読み直す手順を加えて復旧しました。外部につなぐ部分は、壊れたときに安全側へ倒れるように作っておくのが一番効きます。
Copilot harnessを使えば、ループやサンドボックスの面倒はMicrosoftが見てくれます。しかし、上の3つはハーネスの外、つまり業務の側の問題なので、誰がハーネスを運用しても残ります。「ハーネスは薄く、業務の知識はスキルの側に厚く持つ」という設計の考え方については、こちらで解説しています。
「Thin Harness, Fat Skills」とは?ハーネスエンジニアリングでClaude Codeの生産性が変わる設計パターン
どれを選ぶか|SDK・Foundry harness・Hosted Agents・Copilot Studio
選択肢 | 実行環境を持つのは | 向いている場面 |
|---|---|---|
Microsoft Copilot SDK | 自分(手元のPC・自社サーバー) | 自社アプリにエージェントを組み込みたい。社内のファイルや閉じたネットワークの中で動かしたい |
Foundryの Copilot harness(プレビュー) | Microsoft | サンドボックスや実行基盤を自分で運用したくない。Azureの中で完結させたい |
Foundryの Hosted Agents | Microsoft(コードは自分) | 自前のフレームワークやエージェントのループを持ち込み、置き場所だけ任せたい |
Copilot Studio | Microsoft | コードを書かずに、業務部門が社内向けのエージェントを作りたい |
中小企業がまず検討するなら、コードを書く担当者がいなければCopilot Studio、社内に開発者がいてAzureを使っていればFoundryのハーネスを無料期間中に1業務で試す、という順番がおすすめです。GitHub CopilotとMicrosoft 365 Copilotがそもそも別物である点は、こちらの記事で整理しています。
よくある質問
GitHub Copilot SDKで書いたコードは書き換えが必要ですか?
すぐには必要ありません。GitHubのchangelog(2026年10月28日)は、パッケージ名・名前空間は移行期間中も旧名のままで、既存ユーザーはすぐに変更しなくてよいと明記しています。リポジトリがMicrosoftの組織へ移る予定なので、依存関係の取得元が変わるお知らせが出たら、そのときに対応すれば足ります。
Copilot Studioで作ったエージェントの課金は変わりますか?
変わりません。Microsoftの発表(2026年10月28日)は、「GitHub Copilot harness」から「Microsoft Copilot harness」への改称について、既存のエージェントの機能・課金に変更はないとしています。
Foundryの既存のエージェントをCopilot harnessに切り替えられますか?
2026年10月30日時点ではできません。ハーネスはエージェントを新しく作るときに選ぶもので、作った後の切り替えは未対応です。
11月中に試せば完全に無料ですか?
無料なのはハーネスの実行(サンドボックスのCPUとメモリ)だけです。モデルの推論料と、別料金のツールや接続サービスの料金は11月中もかかります。
Microsoft 365 CopilotのCopilotとは別物ですか?
別物です。Copilot harnessはエージェントを作る開発者向けの実行基盤で、WordやExcelの中で使うMicrosoft 365 Copilotの利用ライセンスとは関係ありません。名前に同じ「Copilot」が付いているだけなので、社内で話すときはどちらの話かを最初に揃えておくと混乱を防げます。
まとめ|任せられるのはループまで、業務の安全は自分で持つ
- Copilot harnessは、GitHub CopilotやCopilot Studioを動かしているエージェントの実行基盤。2026年10月28日にFoundryでパブリックプレビューになった
- SDKの「Microsoft Copilot SDK」への改称と、Copilot Studioの改称は名前だけの変更。既存のコードとエージェントはすぐには直さなくてよい
- 料金はハーネスの実行が11月30日まで無料、12月1日から1 vCPU・1時間0.0994米ドル、1 GiB・1時間0.0118米ドル。モデルの推論料は別
- スキルは
SKILL.mdの書式で持ち込める。手順書を別のハーネスへ載せ替えやすくなった - 冪等性・途中経過の保存・外部接続の認証は、ハーネスを任せても開発者の側に残る。壊れたときに安全側へ倒れる作りにしておく
株式会社Fyveでは、エージェントを業務に入れるときに、まず「止まったとき・二重に動いたときに何が起きるか」を洗い出してから仕組みを選ぶようにしています。Copilot harnessの無料期間は、その洗い出しを実物で試すのにちょうどよい機会です。
御社の業務に合わせたCopilot導入・定着支援
「ライセンスを配ったのに使われない」を終わらせる。
業務の棚卸しから、効く業務の切り分け、社内への定着まで一貫して支援します。