2026 年 10 月 28 日、Microsoft は Microsoft Copilot harness を Microsoft Foundry で使えるようにすると発表しました。Foundry のブログと、Microsoft の公式ブログ（Foundry の CVP の Tina Schuchman 氏と、GitHub の CTO の Vladimir Fedorov 氏の連名）で紹介されています。
この記事では、発表の中身と Microsoft Learn のドキュメントをもとに、次のことを図で整理します。
- Copilot harness とは何か（GitHub Copilot・Copilot Studio との関係）
- Foundry で何ができるのか（ツール・スキル・サンドボックス）
- どこを任せるか（Microsoft と自社の分担）と、ハーネスを任せてスキルと MCP・API に集中する考え方
- Copilot Studio・Foundry のほかのエージェントとの使い分け
- 制限・費用・セキュリティで気を付けること
パブリックプレビューです
Foundry の Copilot harness は、2026 年 10 月 28 日の時点でパブリックプレビューです。SLA はなく、Microsoft は本番の利用を勧めていません。内容は変わることがあります。
Copilot harness とは
ハーネスは「モデルと仕事の間」にいる実行基盤
AI エージェントは、モデルだけでは仕事ができません。モデルに何を渡し、返ってきた答えをどう解釈し、どのツールを呼び、失敗したらどうやり直すか。この「モデルの周りの仕組み」を ハーネス と呼びます。
ハーネスの考え方は、以前の記事で詳しく書きました。
なぜ今、AI に「ハーネス」が必要なのか最近、Copilot Studio や AI エージェントの解説をしていると、「ハーネスとは何ですか？」という質問をよくいただきます。 名称の変更（2026 年 10 月 28 日…
GitHub が作り、Microsoft 全体で使っているハーネス
公式ブログによると、Copilot harness は GitHub のエンジニアリングチームが作り、Microsoft が全社で採用したものです。いまは GitHub Copilot のアプリ・CLI・VS Code、そして Copilot Studio を動かしています。Copilot Studio では、推論の多い複数の手順の仕事に向いたハーネスとして提供されています（Microsoft Learn）。
名前が「Microsoft Copilot harness」になりました
これまで Copilot Studio で GitHub Copilot harness と呼んでいたハーネスは、今回の発表で Microsoft Copilot harness という名前になりました。Foundry の SDK でも、
GitHubCopilotHarnessは互換のために残す前の名前とされ、新しいプロンプトエージェントにはMicrosoftCopilotHarnessを使うよう案内されています（Azure SDK for Java のリファレンス）。Copilot Studio の画面やドキュメントでは、しばらく前の名前が残っている所があります。
Copilot Studio の 3 つのハーネス（Microsoft Copilot・Customer Conversation・standard）の違いは、こちらの記事にまとめています。
Microsoft Copilot Studio の「ハーネス」 の違いを抑えておこうMicrosoft Copilot Studioで何かを作るとき、必ず裏側で動いているのが「ハーネス（harness）」という実行基盤です。今回はMicrosoft Learnの公…
今回の発表は、同じハーネスを、Azure の開発者が Foundry の上で、自分のアプリから使えるようにしたものです。公式ブログでは、Foundry の管理されたサービスとして使う方法のほかに、SDK をダウンロードして自分の環境で動かす方法も示されています。
Foundry で何ができるのか
プロンプトエージェントの「実行基盤」を選ぶだけ
Foundry では、Copilot harness は プロンプトエージェントの、任意で選べる管理された実行基盤（ランタイム） です（Microsoft Learn）。ハーネスを選んでも、次のことは変わりません。
| 変わらないもの | 内容 |
|---|---|
| エージェントの種類 | プロンプトエージェントのまま |
| 定義 | モデル・指示・ツールなどを、これまでどおり設定する |
| 呼び出し | アプリからは Responses API で呼ぶ |
| ID とガバナンス | Foundry のプロジェクトのロール、エージェントの ID、接続、ポリシーがそのまま効く |
| 運用 | ハーネスの環境は Foundry が運用する。別のリソースとして管理しなくてよい |
つまり、ハーネスのコードを自分でデプロイ・保守せずに、GitHub Copilot と同じ仕組みで、複数の手順の仕事（ツール・スキル・ファイル・コマンド）をこなすエージェントを作れます。
使えるもの
- ハーネスのツール（5 つ）：ファイルの読み取り、ファイルの書き込み、シェル、Web（URL の内容を取る）、サブエージェント。既定ですべて有効
- スキル：Foundry のバージョン付きのリソース。1 つのエージェントに最大 50 個まで参照できる
- 関数ツール：アプリ側で実行して結果を返すツール
- Foundry の Web 検索：Bing で検索する。プロジェクトの接続は要らない
- ツールボックス：Foundry が提供する対応ツール（MCP など）をまとめて付ける
会話ごとのワークスペースとサンドボックス
ハーネスは、会話ごとに別のワークスペースを使い、ファイルや実行の状態を持ちます。ファイルの処理やコマンドの実行は、Foundry が管理する隔離された実行環境（サンドボックス）で行います。サンドボックスは止まったり、再開したり、入れ替わったりしますが、会話とワークスペースの状態は保たれます。
サンドボックスは保存場所ではない
サンドボックスは利用者が管理するリソースでも、長く残す保存場所でもありません。大事な成果物は Foundry Files などに保存します。新しい会話は、新しいワークスペースで始まります。
どこを任せるか：Microsoft と自社の分担
エージェントを動かすのに要るものを層に分け、「自分で全部作る」「Foundry の hosted agent」「Foundry の Microsoft Copilot harness」で、誰が受け持つかを並べました。Code Apps の記事で描いた、オンプレミス・IaaS・Code Apps の比較と同じ見方です。
| 層 | 自分で全部作る | Foundry hosted agent | Foundry ＋ Microsoft Copilot harness |
|---|---|---|---|
| スキル（仕事の仕方・手順） | 自社 | 自社 | 自社 |
| 業務のデータ・接続（MCP・API・関数） | 自社 | 自社 | 自社 |
| 権限・ネットワーク（ID・ロール・出口の制限） | 自社 | 共同：基盤は Microsoft、設定は自社 | 共同：基盤は Microsoft、設定は自社 |
| エージェントのループ（ハーネス） | 自社 | 自社（自分のフレームワーク） | Microsoft |
| 実行環境（サンドボックス・セッション） | 自社 | 共同：ホストは Foundry、コンテナは自社 | Microsoft |
| インフラ保守運用（サーバー・更新・スケール） | 自社 | Microsoft | Microsoft |
Microsoft Copilot harness を選ぶと、ハーネス・実行環境・インフラの 3 つの層を、まるごと Microsoft に任せられます。自社に残るのは、スキル・業務のデータと接続・権限の設定です。
ハーネスを「外に任せて」いいのか
「エージェントの心臓部を自社で持たなくていいのか」と思う方もいるかもしれません。
でも、私たちはもう、毎日そうしています。GitHub Copilot や Claude Code で開発するとき、モデルに何を渡し、どのツールを呼び、失敗したらどうやり直すかというハーネスの部分を、自分で作ってはいません。基盤として抽象化されたものを使い、その上で「何を作るか」「どう作るか」に集中しています。
ハーネスは、世界中の開発者の使い方から毎日改善されています。そこを自社で作り直し、追いかけ続けるのは、スピードの面でもったいないと私は考えます。自社が力を入れるべきなのは、ほかの会社がまねできない部分です。
- 仕事の仕方（スキル）：業務の手順、判断の基準、チェックリスト、開発標準。ベテランの「やり方」をスキルとして書きためると、どのハーネスの上でも、エージェントがその通りに働きます
- 仕事の情報（MCP・API）：自社のデータと業務システムを、MCP や API で、安全に、必要な分だけ渡します。ここは自社にしか作れません
ハーネスは任せて、スキルと MCP・API に集中する。エージェントの価値の差は、ハーネスではなく、その上に載せるスキルと情報で決まります。
制限（パブリックプレビュー）
Microsoft Learn の制限の表から、設計に効くものを抜き出しました。
| 項目 | 内容 |
|---|---|
| リージョン | Australia East、Canada Central、Central US、Germany West Central、Japan East、Sweden Central、UK South、West Europe、West US |
| モデル | 推論とツールの呼び出しに対応したモデル |
| 独自のモデル（BYOM） | 未対応 |
| Foundry Memory | 未対応（会話の履歴とワークスペースのファイルは使える） |
| ハーネスの選択 | エージェントを作るときだけ。既存のエージェントを切り替えることはできない |
| 呼び出し | すべての要求に conversation が必要。store: false と previous_response_id は使えない |
| ハーネスが決める設定 | temperature や max_output_tokens などは指定できない（指定するとエラー） |
| 入力 | テキスト・画像・ファイル（HTTP）。音声と WebSocket は未対応 |
日本の東リージョン（Japan East）が最初から入っているのは、日本の企業にはうれしい点です。
Copilot Studio・hosted agent とどう使い分けるか
Microsoft は、Copilot harness と hosted agent（自分のフレームワークで作ったエージェントを Foundry で動かす形）の使い分けを、次のように説明しています。
- Copilot harness：複数の手順のツール・スキル・ファイル・コマンドの仕事が要り、実行基盤の運用は Foundry に任せたいとき
- hosted agent：フレームワーク・オーケストレーション・ミドルウェア・実行のポリシー・依存関係を自分で持ちたいとき
ここに Copilot Studio を加えて、「自分で管理する範囲」と「作り方の自由度」で並べると、次のようになります。
| Copilot Studio（Microsoft Copilot harness） | Foundry（Microsoft Copilot harness） | Foundry（hosted agent） | |
|---|---|---|---|
| 主に作る人 | 業務の担当者・メーカー | Azure の開発者 | 基盤まで持つ開発者 |
| 作り方 | ローコード（自然言語・画面） | SDK・REST・azd・ポータル | 自分のフレームワークのコード |
| 呼び出し・公開 | Teams・Microsoft Copilot など | 自分のアプリから Responses API | 自分のアプリから |
| 実行基盤の運用 | Microsoft | Foundry | 自分（Foundry がホスト） |
| 費用 | Copilot Credits（作るときから消費） | Azure の従量課金（後述） | Azure の従量課金 |
| 向いている仕事 | 社内の業務プロセス（請求書の照合など） | 自社のサービス・アプリに組み込むエージェント | 独自のオーケストレーションが要るもの |
社内の業務なら Copilot Studio、自社のアプリやサービスに組み込むなら Foundry、というのが基本の分け方です。これは、以前の記事で書いた「社内は Code Apps、外向けは Azure」と同じ考え方です。
相次ぐ個人情報漏えいから考える ― 巨人の肩に乗り、システムの「主権」を取り戻す2026 年秋に相次いだ個人情報の漏えいを、社名を伏せて業種ごとに整理しました。ID 管理を自前で作らず Entra ID に任せること、自社の開発標準とテストケースを持つこと、継続して運用することを、事例とテストケースとともに解説します。AI CoE が担う役割にもつなげます。
道具の使い分け全体（GitHub Copilot・Cowork・Copilot Studio・Agent Builder）は、こちらの記事のロングテールの図を見てください。
GitHub Copilot・Cowork・Copilot Studio・Agent Builder の使い分け ― ユースケース × インパクトのロングテールで考える「どれを使えばいいのか」は、ユースケースの数とインパクトのロングテールで考えると整理できます。少数で大きな効果を出す GitHub Copilot と Code Apps、個人の仕事を任せる Cowork、組織で共有する Copilot Studio、少量多品種の Agent Builder。判断の分かれ目をまとめます。
費用の考え方
Foundry Agent Service の費用は、基本的にモデルの推論（入力と出力のトークン）と、使ったツール・ストレージの合計です（FAQ）。
Copilot harness そのものの費用は、Foundry のブログで次のように案内されています。
Copilot Studio で使うときとは、費用の仕組みが違う
Copilot Studio の Microsoft Copilot harness は、作り始めた時点から Copilot Credits を消費し、Microsoft Copilot（旧 Microsoft 365 Copilot）のライセンスでは賄われません（Microsoft Learn）。Foundry は Azure の従量課金です。同じハーネスでも、どこで使うかで請求のされ方が変わります。Copilot Credits の仕組みはこちらの記事にまとめています。
セキュリティで気を付けること
ハーネスは強力なぶん、権限の設計が大事です。ドキュメントには、次の注意が書かれています。
- シェルが最も強いツール：シェルはファイルの読み書きも、許されたネットワークへの通信もできます。ファイルの読み取り・書き込み・Web を止めても、シェルを有効にしたままなら、厳密な境界にはなりません。要らないならシェルを止めます
- ネットワークの出口を絞る（プレビュー）：RAI ポリシーにネットワークのルールを付けると、ハーネスの実行環境からの通信を絞れます。ポリシーを変えたら、新しい会話で試します
- 接続は最小の権限で：MCP などの接続を使うツールは、いちばん狭い認証方式と権限にします
- データが外に出る道を知る：外部のツール・接続・エンドポイントを設定すると、データはその先のサービスの条件で扱われます
- トレースで確かめる：ツールを足したら、応答のトレースで、期待どおりのツールが呼ばれたかを確かめます
これは、前に書いた「巨人の肩に乗る」と同じ話です。ハーネスとサンドボックスは Microsoft に任せ、何をさせるか（権限・ツール・ネットワーク）は自分たちで決めて、テストする。この分担がはっきりしているのが、Copilot harness のよいところだと思います。
試してみる
Foundry ポータルから作成すると以下のようにチェックを入れるとこで簡単に作成する事ができます。
Microsoft Copilot harness が設定されている事がわかります。
Azure Developer CLI（azd）で、ハーネスを使うプロンプトエージェントを作る流れです。ドキュメントの手順を短くしたものなので、実際に試すときは手順の全体を見てください。
# プレビューを有効にする（シェルごと・CI のジョブごとに）
export AZD_ALPHA_ENABLE_AGENTS_MANAGED_HARNESS=true
# プロンプトエージェントを作る
AGENT_NAME="my-harness-agent-001"
MODEL="<推論とツール呼び出しに対応したモデル>"
azd ai agent init "$AGENT_NAME" --kind prompt --agent-name "$AGENT_NAME" --model "$MODEL"
cd "$AGENT_NAME"生成された azure.yaml に、ハーネスの選択を足します。
services:
<agent-service-name>:
host: azure.ai.agent
harness:
type: microsoft_copilot_previewazd up --no-prompt
azd ai agent show --output json # kind: prompt と harness.type を確かめる前提として、azd 1.37.0 以降と Foundry の拡張機能、プロジェクトの Foundry User のロールが要ります。ポータル（新しい Foundry）なら、エージェントを作るときに「Use the Microsoft Copilot harness」を選ぶだけです。
AI CoE にとっての意味
最後に、AI CoE の立場から見たポイントです。
- 同じハーネスが、3 つの場所で動く：開発者は GitHub Copilot、業務の担当者は Copilot Studio、自社のサービスは Foundry。使う道具が違っても、エージェントの動き方の考え方（ツール・スキル・サンドボックス・権限）は共通になります。研修とガイドラインを 1 つにまとめやすくなります
- スキルが資産になる：Foundry のスキルはバージョン付きのリソースで、エージェントのバージョンごとに固定されます。業務の手順をスキルとして書きためることが、AI CoE の資産になります。AI ファースト開発標準でも、手順をスキルにまとめています
- 費用の管理は場所ごとに：Copilot Studio は Copilot Credits、Foundry は Azure の従量課金です。どの仕事をどこで動かすかは、費用の管理とセットで決めます
AI CoE の全体の歩みは、こちらの記事にまとめています。
AI CoE のジャーニー ― 本部と事業部に分かれ、予算を持つ部門で外注費を内製で減らすAI CoE の概要と、これからの形をまとめます。本部 AI CoE が標準と基盤を持ち、事業部 AI CoE が自分の予算に載っている外注費を内製で減らす。JUAS・IPA・Gartner の調査結果と図で、AI CoE のジャーニーと、担当者が読む記事の順番を紹介します。
まとめ
- Microsoft Copilot harness（旧称 GitHub Copilot harness）は、モデルの周りでエージェントのループを回す実行基盤。GitHub が作り、GitHub Copilot と Copilot Studio を動かしている
- 2026 年 10 月 28 日から、Foundry のプロンプトエージェントの実行基盤として選べるようになった（パブリックプレビュー、Japan East も対象）
- ハーネスのツール（ファイル・シェル・Web・サブエージェント）、スキル、関数、Web 検索、ツールボックスが使え、会話ごとのワークスペースとサンドボックスを Foundry が運用する
- ハーネス・実行環境・インフラは Microsoft に任せ、自社はスキル（仕事の仕方）と MCP・API（仕事の情報）に集中する
- 社内の業務は Copilot Studio、自社のアプリ・サービスは Foundry、独自の基盤が要るなら hosted agent
- シェルは最も強いツール。権限・ネットワーク・接続は自分たちで絞り、トレースで確かめる
「どのモデルが一番賢いか」より、「モデルの周りをどう作るか」。その周りの部分を、Microsoft が 1 つの共通の基盤にそろえてきた発表です。
参考
- Introducing the Microsoft Copilot harness in Foundry Agent Service（Microsoft Foundry Blog）
- Introducing the Microsoft Copilot harness: Unlocking the potential of truly multi-model agentic work（The Official Microsoft Blog、2026 年 10 月 28 日）
- Use the Microsoft Copilot harness with prompt agents（Microsoft Learn）
- Foundry Agent Service limits, quotas, and regional support（Microsoft Learn）
- Harnesses in Copilot Studio（Microsoft Learn）
- Manage costs for agents powered by the Microsoft Copilot harness（旧称 GitHub Copilot harness、Microsoft Learn）
メルマガで新しい記事を受け取る
新しい記事や講座のお知らせを、メールでお届けします。いつでも配信を停止できます。
ご登録いただいたアドレスは、メルマガの配信にだけ使います。
あわせて学びたいオンライン講座
どの講座から始めればよいか、学ぶ順番をまとめています。
コメントを残す