FoundryのMicrosoft Copilot harnessを解説（2026年）

モデルを差し替えるたびにオーケストレーション層まで作り直す――エージェント開発のスケジュールを狂わせがちな作業だ。Microsoft FoundryでパブリックプレビューとなったMicrosoft Copilot harnessは、その負担をMicrosoft側で引き受けるマネージド実行基盤である。Copilot Code、Copilot Studio、GitHub Copilot app、CLI、Visual Studio Codeの裏側で使われている実行レイヤーを利用でき、ランタイム料金は2026年12月1日まで無料だ（blogs.microsoft.com）。いま実験を始める価値はあるが、以下のプレビュー制約が解消されるまでは、本番環境は既存スタックで運用するのが無難だ。

Microsoft Copilot harnessが担う役割

Microsoft Copilot harnessは、モデルの推論を実際の作業完了までつなげる、モデル周辺のマネージド型オーケストレーション層だ。エージェントループ、サンドボックス、ガバナンス、最適化はMicrosoftが提供し、開発者は指示、スキル、ツール、利用モデルを用意する。

Microsoftの説明は端的だ。「モデルが知能を担うなら、harnessはモデルを取り巻くすべてを担う」（blogs.microsoft.com）。タスクの進行に合わせた作業コンテキストの管理、モデル呼び出しとツール呼び出しの調整、サンドボックスでのファイル操作・コード実行、組み込みサブエージェントへの範囲を限定したタスク委任、設定済みの上限とポリシー境界の適用までをharnessが処理する（devblogs.microsoft.com）。

20超のフロンティアモデルとBYOKを使うマルチモデルルーティング

Microsoft Copilot harnessは、モデルファミリーをまたぐ20超のフロンティアモデルとbring-your-own-key（BYOK）構成に対応し、タスクに応じて適切なモデルを1つまたは複数選んで処理を振り分ける（blogs.microsoft.com）。ただし、発表では20モデル超の完全な一覧は公開されていない。マルチモデル構成を計画する前に、対象のFoundryリージョンで実際に使えるモデルを確認しておきたい。顧客側が独自ルーターを維持しなくてよいことが、この仕組みの狙いだ。Microsoftは「指示、スキル、ツール、モデル選択を持ち込めばよい」としている。

初期利用者の1人は、モデルを変えるたびにオーケストレーション層を書き直さずに済む点を利点として挙げている。@ai_fengshou。

Rust化されたランタイムと既存の採用先

Microsoft Copilot harnessのランタイムは最近Rustへ移植された。Microsoftによれば、これによりセッションのオーバーヘッドと最初のトークンが出るまでの時間が削減されたという（blogs.microsoft.com）。改善率やレイテンシー表は公開されていないため、現時点では方向性を示す主張として受け止めるべきだろう。

Microsoftによると、同じharnessはすでにCopilot Code、Copilot Studio、GitHub Copilot app、GitHub Copilot CLI、Visual Studio Codeのほか、MicrosoftおよびGitHubの各種Copilot機能で使われている（blogs.microsoft.com）。この共通基盤は、数百の実運用ユースケースと数百万人のユーザーを通じて検証されているとMicrosoftは説明する（blogs.microsoft.com）。

拡張性はオープンで、Model Context Protocol（MCP）、agent skills、agent pluginsを利用できる（blogs.microsoft.com）。

2026年10月28日に変わったこと

Microsoftは2026年10月28日、関連する2つの発表を行った。Foundry Agent ServiceでMicrosoft Copilot harnessをパブリックプレビューとして提供開始し、同時に、ホスト型エージェントの長時間実行に対する回復性を一般提供した（devblogs.microsoft.com）。

名称も移行中だ。Copilot StudioのドキュメントではまだGitHub Copilot harnessと呼ばれている箇所があるものの、製品全体ではMicrosoft Copilot harnessへ名称変更が進められている。ページごとに切り替え時期は異なる（microsoft.com）。

Foundry Agent Serviceには現在、3つの抽象化レベルがある。harnessを使わないprompt agent、プレビュー中のMicrosoft Copilot harnessを使うprompt agent、そして開発者がフレームワークを制御するhosted agentだ（devblogs.microsoft.com）。数時間から数日にわたるワークフローの途中で中断しても復旧できるlong-running resilienceは、hosted agent向けの機能で、すでにGAとなっている。

Foundryでharness agentを作る流れ

Foundryのharness agentは宣言的に定義し、アプリケーションコードと同じ場所で管理する（devblogs.microsoft.com）。Foundryでエージェントを作成・テストし、定義をソース管理に置いたうえで、Azure Developer CLI（azd）またはFoundryポータルからデプロイする（devblogs.microsoft.com）。

手順を再利用可能にするskills

再利用可能なskillsには、複数のタスクでエージェントが適用する指示、スクリプト、補助リソース、手順をまとめられる。ドキュメントの例では、skills/research-brief/SKILL.mdにあるresearch-brief skillを使う。このskillは、質問、対象読者、範囲、対象期間を確認し、承認済みツールで根拠を集め、出典と日付を明記し、事実と解釈を区別し、根拠が食い違う場合はフラグを立てるようエージェントに求める。

接続ツールも統制下で利用する

接続ツールを使うと、明示的に設定した認証と承認のもとで、Microsoft Foundry toolsおよびMCP toolsをエージェントから利用できる。この承認ステップはガバナンス上の制御点である一方、後述するRedditの報告が示すように、エンドユーザーに同意ダイアログが繰り返し表示されると本番では摩擦にもなり得る。

コード実行、ファイル操作、サブエージェントへの委任

エージェントはファイルを扱い、コードを実行し、範囲を限定したタスクを組み込みサブエージェントへ委任できる。主エージェントはその結果を取りまとめる。Copilot Studioのharness比較では、GitHub系統のharnessはWord、Excel、PowerPoint、PDFファイルの作成・編集をネイティブで行え、skillsとmemoryもサポートするとされている（learn.microsoft.com）。

ソース管理できる定義と1行のharness指定

エージェント定義はコードと並べて管理する。Foundryのサンプルでは、azure.yamlでharnessを次のように宣言する（devblogs.microsoft.com）。

harness:
  type: microsoft_copilot_preview

このサンプルでは、research-brief prompt agentに、Web検索（public-research）とCode Interpreter（research-analysis）を使うresearch-brief-skill skillを接続する。環境入力にはFOUNDRY_PROJECT_ENDPOINTとMODEL_DEPLOYMENT_NAMEを使用する（devblogs.microsoft.com）。デプロイと呼び出しはプレビュー版CLIで実行する。

azd deploy --all
azd ai agent invoke research-brief \
  "Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."

そのほかの作成方法として、Foundryポータル、Visual Studio Code向けFoundry Toolkit、GitHub Copilot app向けFoundry pluginがある（devblogs.microsoft.com）。

用途別：Foundry agentの選び方

正解となる抽象化レベルは1つではない。Microsoft自身も、アプリケーションの要件を満たす範囲で、インフラ所有の度合いが最も低い選択肢を選ぶよう案内している（devblogs.microsoft.com）。プレビュー中は作成時に選択が固定されるため、作成ボタンを押す前に決めておく必要がある。

Microsoftが紹介した初期顧客の事例には、Confluence Technologiesがインフラではなく設計に集中することで1週間未満でソリューションを出荷した例や、Fashableが商取引上の拘束力を持つ判断は人間の管理下に置きつつ、統制されたソーシングワークフローにharnessを使った例がある（devblogs.microsoft.com）。

2026年12月1日以降の料金

Microsoft Copilot harnessランタイムの課金は、従量制で2026年12月1日に始まる。それ以前のランタイム利用は無料だが、モデル推論、個別課金のツール、接続先サービスには期間中も別途料金がかかる。

料金はリージョンや顧客契約によって異なる場合がある（devblogs.microsoft.com）。プレビュー期間中、実行環境のCPU、メモリ、アイドル設定はFoundryが管理する（devblogs.microsoft.com）。サポート対象リージョン、モデル、ツール、プレビュー制約は別ドキュメントで確認する形だ。

Copilot Studioでは、GitHub系統のharnessを使うエージェントはCopilot Creditsによる従量課金となる。これはFoundryのサンドボックスメーターとは別の課金体系である（learn.microsoft.com）。パイロットの費用を見積もるなら、実測したサンドボックスのvCPU時間とGiB時間に上記単価を掛け、そこへモデルトークンとツールの料金を加える。

構築前に確認したいプレビューの制約

プレビューを本番に近い形で試せるかどうかは、細かな条件で決まる。特記のないものはMicrosoftのFoundry投稿に基づく制約で、ユーザー報告として示したものは公式情報ではない。

• harnessの選択は現時点で戻せない。 agent作成時にharnessを選ぶ必要があり、既存agentは変更されない。作成後にharnessを切り替えることも、現時点ではサポートされていない。初期の読者もまさにこの点を指摘している。「agent作成時にCopilot harnessを選択する。既存agentは変わらず、作成後のharness切り替えはまだサポートされていない」―― @navaneethan_es。
• リージョンとモデルには対象範囲がある。 Foundryは対応リージョン、モデル、ツール、プレビュー制限の完全な一覧をドキュメントに委ねている。あるユーザーのまとめでは、対応はおよそ9リージョンで中東は対象外、bring-your-own-modelも完全には対応していないとされる。@HeshamSaadZaki。これは公式のリージョン表ではなくユーザーによる読み取りなので、必ずドキュメントで確認したい。
• 長時間実行の復旧はアプリケーション側の仕事。 Foundryは中断したhosted workを再起動し、元の入力を再送する。しかし、進捗の保存、チェックポイントからの再開、同じ外部レポートを二度作るような重複アクションの防止はアプリケーション側で実装しなければならない。会話履歴だけでは進行中の作業は復元されない。
• ベンチマーク値やSLAはローンチ時点で示されていない。 「業界最高水準のパフォーマンス」といった定性的な主張はあるが、レイテンシー、スループット、精度の表は期待できない。

初期ユーザーが本番運用で直面したこと

GitHub系統のharnessを利用するCopilot Studioユーザーからは、プレビューと本番の差に関する懸念が繰り返し報告されている。以下はFoundryプレビュー前のCopilot Studio GitHub harnessに関する報告であり、Microsoftが説明する共通の系統（blogs.microsoft.com）から推測するために掲載している。Foundryの計測結果ではない。

本番環境では、コネクタが1日たりとも接続を維持できない。 — u/roberts2727 in r/copilotstudio

フローが動くときもあれば、agentが何も渡さないときもある。 — u/donstazz in r/copilotstudio

業務ユーザーにはこうしたapp regsなどはできない。IT管理者が、しかもagentごとに対応する必要がある。 — u/Teemu_St in r/copilotstudio

これらのスレッドで報告されている主な問題は次のとおり。

• SharePointをナレッジソースにしたagentの応答が遅く、r/copilotstudioでは代替手段より大幅に遅いと報告されている。
• Studioのテストペインでは動くのに、TeamsまたはM365 Copilotへデプロイすると汎用的なエラーで失敗するagentがある。r/copilotstudio。
• コネクタとフローの不安定さに加え、認証やMCP同意を繰り返し求められる問題。r/copilotstudio。
• M365 Copilotライセンスでharnessランタイムまでカバーされるのか、それともCopilot Creditsが引き続き必要なのかという課金上の混乱。r/microsoft_365_copilot。

これらの報告だけでFoundryプレビューの価値が否定されるわけではない。ただし、導入検証では実際のナレッジソース、実際の配信チャネル、実際のエンドユーザー同意フローを使ってテストしてから、スケジュールを約束すべきだ。

FAQ

Microsoft Copilot harnessはGitHub Copilot harnessと同じもの？

はい。GitHubで構築された同じ系統の仕組みを、Microsoftの新しい名称で呼んでいる。一部のCopilot Studioドキュメントでは移行期間中、旧名称が残っている。

Foundry harnessはどのモデルに対応している？

20超のフロンティアモデルとBYOKに対応し、タスクベースでルーティングする。ただしMicrosoftは完全な一覧を公開していないため、対象リージョンのFoundryドキュメントで確認してほしい（上記のマルチモデルの項を参照）。

既存のFoundry agentをharnessへ移行できる？

プレビュー中はインプレースで切り替えられない。並行評価を行い、プロンプト、ツール、認証、状態管理の要件を棚卸ししたうえで、プレビュープロジェクトにmicrosoft_copilot_previewを指定してagentを作り直す。その後、品質、レイテンシー、サンドボックス使用量、復旧性を比較してから切り替えたい。

M365 Copilotライセンスでharnessの利用料金はカバーされる？

自動的にはカバーされない。Foundryではモデル推論とは別にサンドボックスのコンピューティングとメモリを計測する一方、Copilot Studioではこのharness系統はCopilot Creditsで課金される。利用する画面・サービスごとのメーターを確認する必要がある。

harnessとhosted agentはどちらを選ぶべき？

オーケストレーションを自分で所有せず、マネージドなループ、サンドボックス、skills、サブエージェントを使いたいならharnessを選ぶ。フレームワークやランタイムを制御する必要があり、チェックポイントと冪等性を自ら担えるならhosted agentが向く。

まずはプレビューでresearch-brief skillのパターンから始め、同じタスクをharnessなしのprompt agentでも実行して、サンドボックス料金とトークン料金を比較するとよい。移行、リージョン、同意の挙動が自社テナント向けに明確になるまでは、本番は実績のある経路で維持したい。