01/harnessとは
Microsoft Copilot harnessの定義と、エージェントループ・サンドボックスの役割
Microsoft Copilot harness（コパイロット ハーネス）は、AIモデルの周囲で、指示・コンテキスト・実行環境・制御をまとめて提供するオーケストレーション層です。Microsoftは、モデルが知能を担い、harnessがモデル以外のすべてを担うと説明しています。GitHubのエンジニアが開発した実行基盤で、Microsoft全体のCopilot体験の共通基盤として採用されました。新しいAIモデルや、モデルを切り替える機能、プロンプトのテンプレート集ではありません。
「harness（ハーネス）」は馬具を指す言葉で、モデルを業務で安定して働かせるための外側の仕組みを表します。この考え方を設計の手法として扱うのがハーネスエンジニアリングで、Microsoft Copilot harnessは、その仕組みの一部をMicrosoftがマネージドで提供する製品と位置付けられます。
harnessの構成要素
指示・Skills何を達成し、どの手順・方法で進めるか
コンテキスト管理必要な情報と途中経過を保つ
ツール実行MCP・検索・コードなどで外部システムを使う
エージェントループモデルの判断とツール実行を繰り返し、作業を進める
実行環境（サンドボックス）ファイル処理とコマンド実行を隔離して行う
制御認証・承認・ポリシーの範囲内で実行する
Microsoftの公式発表の説明をもとに作図
用語整理
ハーネスエンジニアリング
モデル以外の環境（ツール、権限、検証、観測、停止、記録）を設計し、失敗のたびに改善する取り組みです。
Microsoft Copilot harness
エージェントループとサンドボックスを含む実行基盤の製品です。Copilot Studio、GitHub Copilot、Microsoft Foundryなどで使われます。
Foundry Agent Service
Microsoft Foundryのエージェント実行サービスです。Prompt agentの作成時に、Copilot harnessを実行方式として選べます。
02/注目される背景
マルチモデル化と実行基盤の共通化：2026年10月28日の3つの発表
Microsoftは、性能・品質・コストを両立するにはマルチモデル対応が必要で、そのためには複数のモデルと製品で動く実行基盤が欠かせないと説明しています。先端のモデルは短期間で入れ替わるため、各社が自前のharnessやモデルの振り分けを作り直し続けるのは負担が大きく、MicrosoftとGitHubが自社製品で使う基盤を、保守の負担なく使えるようにしたのが今回の発表です。共通基盤は20以上のフロンティアモデルと、APIキーの持ち込み（BYOK）への対応を掲げ、MCP、エージェントスキル（Agent Skills）、エージェントプラグインといったオープンな仕組みにも対応します。
1つのharnessが支える製品
Microsoft Copilot harnessGitHubで開発し、Microsoft全体で採用
→
Copilot Code
Copilot Studio
GitHub Copilotアプリ
GitHub Copilot CLI
Visual Studio Code
Microsoft Foundry（プレビュー）
Microsoftの公式発表の記載をもとに作図
発表 1
GitHub由来の実行基盤をMicrosoft共通へ
Copilot体験をこの基盤へ標準化する方針です。全社的な共通化の方針と、各製品への適用状況は、製品ごとに確認します。
発表 2
Foundry Agent Serviceでパブリックプレビュー
Microsoftがエージェントループとサンドボックスを運用し、利用企業は業務知識・手順・ツール・モデル選択を持ち込みます。
発表 3
Copilot Studioでの名称変更
「GitHub Copilot harness」を「Microsoft Copilot harness」へ改称しました。既存エージェントの機能と課金は変わりません。
同日には、Hosted agentの長時間実行の回復機能の一般提供（GA）も発表されました。これはCopilot harnessとは別の項目で、Copilot harness自体は2026年11月2日時点でパブリックプレビューです。
03/構成要素
Foundry版の4つの構成要素：Skills・ツール接続・実行と委任・ソース管理
Foundry Agent Serviceのプレビューでは、次の4つが主な構成要素です。作業コンテキストの管理と、モデルとツールの手順の調整はharnessが担い、設定した上限とポリシーの範囲で、求められた成果へ向けて作業を進めます。組み込みの機能として、ファイルの読み書き、シェル、Web、サブエージェントが既定で有効になっています。
構成要素内容業務上の意味
再利用できるSkills
指示、スクリプト、関連資料を、タスクをまたいで使える手順としてパッケージ化します。
業務の進め方を、エージェントの手順として再利用できる
ツール接続
対応するFoundryのツールとMCPのツールを接続します。認証と承認は明示的に設定します。
社内外の情報とシステムへ、権限を決めて接続できる
実行と委任
ファイルとコードを扱い、範囲を限ったタスクを組み込みのサブエージェントへ委任し、メインのエージェントが結果をまとめます。
一度の回答で終わらない作業を、分担して進められる
ソース管理されたエージェント定義
Foundryで作成・テストするか、エージェントの定義と関連リソースをアプリケーションのコードと一緒に管理します。
変更管理とテストの対象にできる
運用の分担
Microsoftが運用する部分
エージェントループ
サンドボックス
作業コンテキストの管理
組み込みのサブエージェント
harnessの継続的な改善
利用企業が持ち込む部分
指示と業務知識
Skills（手順）
ツールと認証・承認
モデルの選択
結果の評価
Microsoft Foundry Blogの記載をもとに作図
公式の例は、質問に答えるだけのエージェントではなく、調査、根拠の収集、データ分析、出典付きのレポート作成までを進めるエージェントです。SKILL.mdに、問いと範囲の確認、出典と日付の明記、事実と解釈の区別、取得した内容を指示ではなくデータとして扱うこと、機密情報をWeb検索に含めないことを書き、手順として再利用します。Skillsの仕組みは、当社エンジニアの技術解説も参照してください。
04/選び方
Prompt agent・Copilot harness・Hosted agentの使い分け
Copilot harnessはMicrosoft Foundryの代替ではなく、Foundry Agent Serviceの中で選べる実行方式の一つです。Microsoftは、どこまでを自社で作り、どこからをマネージドに任せるかで、次の3つを使い分けるよう示しています。既存のフレームワークや別のharnessを持ち込む選択肢も残されています。
指示＋対応ツール
Prompt agent（harnessなし）
指示と対応ツールだけで、仕事が成立する場合に向きます。最も簡素で、管理する範囲が小さい構成です。
Skills・ツール→harness（Microsoft運用）
Copilot harness付きPrompt agent
Skills、ファイル、サブエージェント、複雑なツール連携を、実行基盤を自作せずに使いたい場合に向きます。
自社のフレームワーク・ループ→Foundryがホスト
Hosted agent
フレームワーク、実行ループ、ミドルウェア、依存関係を自社で制御したい場合に向きます。中断からの再開と重複処理の防止は、アプリケーション側で設計します。
業務の性質から選ぶ目安
1
検索して答えるだけの業務
→ RAGと、通常のPrompt agentをまず検討
2
処理の順序が固定された業務
→ 既存のワークフローと比較して選ぶ
3
状況に応じて調査・分析・作業を組み立てる業務
→ Copilot harness付きPrompt agentを有力候補に
4
実行ループや依存関係まで細かく制御したい業務
→ Hosted agentなど、自社で制御できる方式を検討
Microsoftの使い分けの説明をもとに、当社で整理
検索して答える業務は、RAGとPrompt agentで足りることが多く、処理の順序が決まった業務は、Agentic Work Flowなどのワークフローと比較します。外部ツールの接続は、MCPを共通の接続方式として設計します。
05/公表された評価
Standard harnessとの比較：合格率・失敗からの回復・入力コスト
Copilot Studioチームは、同じタスクとモデルでStandard harnessと比べた内部評価を公開しています。評価では、モデルを変えても合格率への影響は小さく、harnessを変えると大きな差が出たと説明しています。
評価項目Microsoftの公表値
同じタスクでの評価の合格率
OpenAIのモデルで10.8ポイント、Anthropicのモデルで22.1ポイント改善
ツール呼び出しの失敗後も、解決を試み続けた割合
84〜91%（Standard harnessは7%未満）
失敗したツールを後で再試行し、成功する可能性
7倍超
入力処理の正味コスト
キャッシュの効率化で15〜21%削減（モデル呼び出しは約2倍）
出典：Microsoftの社内分析（2026年10月）。評価データまたは本番のテレメトリに基づき、日・ビルド・モデル・構成によって変わります。再試行の成功は、タスク全体の完了を意味しません。15〜21%は入力処理の正味コストの削減で、総利用料金の削減率ではありません。
Microsoftのカスタマーサービス部門は、この基盤で動くサポート案件の解決エージェントで、2026年8月に、人の介入なしで解決した割合（完全自律解決率）が35%を超えたと公表しています。モデルの性能だけでなく、失敗からの立て直し方、コンテキストとキャッシュの扱い方が、エージェントの結果を左右することを示す評価です。
06/提供形態と制約
SDK・Foundryマネージド版の違いと、プレビューの制約・料金
共通基盤としての「20以上のモデル・BYOK対応」と、Foundryのプレビューで使える範囲は異なります。Foundryのマネージド版では、プロジェクトのリージョンで使える、推論とツール呼び出しに対応したモデルを選び、独自モデルの持ち込み（BYOM）には対応していません。すべてのエージェントで複数のモデルが自動的に振り分けられるわけではない点にも注意が必要です。
SDK
harnessの実行エンジンをアプリケーションに組み込む方式です。GitHubで公開され、対応プロバイダーのAPIキーを持ち込めます（BYOK）。
Foundryのマネージド版
Foundry Agent ServiceのPrompt agentで、実行方式として選びます。パブリックプレビューで、エージェントループとサンドボックスをMicrosoftが運用します。
Copilot Studio
以前のGitHub Copilot harnessとして、すでに利用されています。エージェントアカウント、業務プロセスのメモリ、トリガーなどの機能も、このharnessで追加されています。
項目Foundryプレビューの内容（2026年11月2日時点）
提供段階
パブリックプレビュー。機能と制約は変更される可能性があります
対応リージョン
Japan Eastを含む9リージョン（Australia East、Canada Central、Central US、Germany West Central、Japan East、Sweden Central、UK South、West Europe、West US）
モデル
推論とツール呼び出しに対応したモデル。独自モデルの持ち込み（BYOM）は非対応
作成と切り替え
新しいエージェントの作成時に選択。既存のエージェントは変わらず、作成後の切り替えは未対応
作業領域
会話ごとの作業領域。重要な成果物は、Foundry Filesなどの永続的な保存先へ保存
メモリ
Foundry Memoryは非対応。会話履歴と作業領域のファイルは利用可能
実行環境
サンドボックスのCPU・メモリ・アイドル設定はサービス側で管理。送信通信の制御はプレビューで提供
料金
harnessの実行環境は2026年12月1日から従量課金（vCPU時間あたり0.0994米ドル、GiB時間あたり0.0118米ドル。地域・契約で異なる場合あり）。それ以前もモデル推論と別課金のツールは課金対象
プレビューの機能と制約は変更される可能性があります。リージョン・モデル・ツールの対応状況は、構成を決める時点でMicrosoft Learnの最新情報を確認します。
07/向いている業務
ゴールが決まり、調べる対象と手順が変わる業務の活用イメージ
特に向くのは、成果物は決まっているものの、途中で調べる対象や使うツール、作業の順序が変わる仕事です。RAGで回答を返したあと、人が分析や資料作成を続けている業務が候補になります。以下は当社が想定する活用イメージです。
例：製造業の不具合調査
1
不具合報告を受け取る
入力：報告書・添付ファイル
2
関連仕様と過去事例を検索
ツール接続：検索・MCP
5
調査報告書のドラフトを作成
成果物：出典付きの報告書
熟練者の仕事の進め方のエージェント化
提案準備なら、顧客情報を集めるだけでなく、案件条件の確認、類似事例の選定、提案の論点と確認事項の整理までを対象にします。会議や資料から抽出した判断・経験則を、Skillsとして実行させる先になります。
自社のSaaS・業務アプリへの作業代行機能
資料を受け取り、確認・分析してレポートを返すといった、サービスの中で仕事を進める機能の実装候補です。利用者ごとのデータ分離、権限、承認、費用の上限は、別途設計します。
08/当社の支援内容
業務文脈・Skills・実行制御・評価改善の4領域の支援
Microsoftが実行ループとサンドボックスを担うほど、その上に載せる業務知識、Skills、ツール接続、評価基準、承認の設計が成果を分けます。当社は、Copilot harnessを実装手段の一つとして、顧客固有の業務を、安全に実行でき、評価と改善を続けられるエージェントへ実装します。Copilot harnessでなければならない業務かどうかも、他の方式と比べて判断します。
支援の流れ
支援 1業務文脈の設計用語・データの関係・判断ルール
→
支援 2Skills・Playbook化手順・例外対応・評価ケース
→
支援 3実行制御の設計権限・承認・停止・人への引き継ぎ
→
支援 4評価と改善完遂率・手戻り・確認負荷・費用
伴走体制：X-Tech FDE（現場への常駐型の
実装支援）で、技術と知識を移転し、顧客が自ら手順と評価を更新できる状態へ移します。
支援 1
業務文脈から実行までをつなぐ設計
データを接続するだけでなく、どの情報と判断基準に基づいて仕事を進めるかを設計します。データ整備、意味と関係の構造化、検索、権限を層に分けて組み立てます。
支援 2
現場の知見を、再利用できるSkillsへ
会議や資料から判断と例外対応を抽出し、Skill・Playbookとして整えます。個別のエージェントを作って終わらず、次の業務にも使える手順と評価基準を残します。既存の手順がそのまま動くかは、必要なツール・実行環境・権限を含めて検証します。
支援 3
安全性を、業務の実行条件として設計
harnessは制御の仕組みを備えますが、顧客固有の権限、ツールの認証、承認、データの取り扱いは引き続き設計の対象です。何を実行でき、どこで承認・停止・人への引き継ぎが必要かを業務に組み込みます。
技術解説：Foundryのツール設定に必要な権限 →
支援 4
顧客自身が改善できる運用体制
完遂率、手戻り、人の確認負荷、処理時間と費用を測り、失敗した手順や不足する知識をSkillsと評価ケースへ戻します。更新手順、変更管理、運用責任の分担まで設計します。
09/検証の観点
プレビュー期間の検証項目：業務手順・接続・実行制御・品質と費用
Foundry版はパブリックプレビューのため、まず検証の対象として扱います。動作のデモで終わらせず、情報不足、権限不足、ツールの失敗といった例外を含めて、次の4点を確かめます。
検証項目確かめること
業務手順の実装
どの業務知識をSkillsにし、どこまでの作業を任せられたか
データ・ツール接続
どの情報とシステムを、誰の権限で利用させたか
実行制御
どこを自動化し、どこで承認・停止・人への引き継ぎを行うか
品質・費用の評価
完遂率、手戻り、人の確認負荷、処理時間と費用がどう変わったか
10/関連ソリューション
業務に特化したエージェントを、
ローコードで。
Copilot Studio. Copilot Studioの内製化支援と、AIエージェントのソリューション開発、AgentOpsを支援します。
権限・承認・検証・停止を、
業務実装へ。
ハーネスエンジニアリング. コンテキスト管理・ルール・ツール接続・評価と検証・安全と制御の5要素を、段階的な委任設計で組み込みます。
コンテキスト設計×現場実装を、
一気通貫で。
コンテキストエンジニアリング. エージェントに渡す動的文脈の設計・供給・統制・改善を、5つの支援領域で提供します。
ファイルにない判断も、
会議から業務資産に。
SyncLect Agent Garden. Teams会議や業務資料の判断・経験則を抽出し、AIエージェント向けの仕事の型（Skill・Playbook）へ変換します。
AI駆動開発を、
組織標準にする。
AI駆動開発（SAIDDar）. 案件の改善を標準・テンプレート・エージェント定義へ還元し、人のレビューを前提にAI駆動開発を組織標準へ進めます。
検索と推論を重ねて、
根拠のある回答へ。
Agentic RAG. エージェントが検索と推論を繰り返し、根拠付きの回答を返すRAGの品質改善サービスです。
最初の1業務を、
2日間で試作する。
HWS Agent Camp. 専門エンジニアが伴走する2日間の集中ハッカソン。約2週間の事前準備のうえで、AIエージェントのプロトタイプを構築します。
11/よくあるご質問
Q. Microsoft Copilot harness（コパイロット ハーネス）とは何ですか。
A. AIモデルがツールを使い、複数の手順を進めて仕事を完遂するための、Microsoftの共通の実行基盤です。指示・コンテキスト・実行環境・制御をまとめて提供し、Copilot Studio、GitHub Copilot、Visual Studio Codeなどを支えています。2026年10月28日に、Microsoft Foundryでの提供（パブリックプレビュー）が発表されました。
Q. 新しいAIモデルですか。
A. いいえ。モデルの周囲で働く実行基盤です。共通基盤としては20以上のフロンティアモデルとBYOKへの対応を掲げており、Foundry版では、リージョンで使える、推論とツール呼び出しに対応したモデルを選びます。
Q. GitHub Copilot harnessとの違いは何ですか。
A. 同じ技術です。Copilot Studioで「GitHub Copilot harness」と呼ばれていたものが、Microsoft全体での役割を反映して「Microsoft Copilot harness」に改称されました。既存エージェントの機能と課金は変わりません。
Q. ハーネスエンジニアリングとの関係を教えてください。
A. ハーネスエンジニアリングは、ツール・権限・検証・観測・停止といったモデル以外の環境を設計する取り組みです。Microsoft Copilot harnessは、そのうちエージェントループやサンドボックスなどの実行基盤をマネージドで提供する製品で、業務に合わせた権限・承認・評価の設計は引き続き必要です。
Q. Foundry Agent Serviceの通常のエージェントと、どう使い分けますか。
A. 指示と対応ツールで足りる場合は通常のPrompt agent、Skills・ファイル・サブエージェント・複雑なツール連携を基盤を自作せずに使いたい場合はCopilot harness付きのPrompt agent、実行ループや依存関係を自社で制御したい場合はHosted agentが目安です。
Q. 既存のエージェントをCopilot harnessに切り替えられますか。
A. 2026年11月2日時点のプレビューでは、新しいエージェントの作成時に選択します。既存のエージェントは変わらず、作成後の切り替えには対応していません。
Q. 日本のリージョンで使えますか。
A. Japan Eastが対応リージョンに含まれています。利用するモデルとツールの対応状況は、構成を決める時点でMicrosoft Learnの最新情報を確認します。
Q. 料金はかかりますか。
A. harnessの実行環境は、2026年12月1日から従量課金が始まる予定です。それ以前もモデル推論と別課金のツール・接続サービスは課金対象です。公表単価はvCPU時間あたり0.0994米ドル、GiB時間あたり0.0118米ドルで、地域と契約によって異なる場合があります。
Q. 本番業務で使えますか。
A. Foundry版はパブリックプレビューのため、まず検証の対象として扱うことをおすすめします。業務手順、データとツールの接続、実行制御、品質と費用の4つの観点で検証し、本番の構成はその結果と提供条件を確認して判断します。
Microsoft Copilot harnessの活用についてのご相談
対象業務の選定、実行方式の比較、Skills・ツール接続・承認の設計から、検証と運用まで、貴社の状況に合わせてご提案します。
お問い合わせ
