Microsoft Copilot harnessをFoundryで使う｜スキル・ツール・長時間実行の設計

Microsoftは2026年10月28日、Microsoft Foundry Agent ServiceでMicrosoft Copilot harnessを公開プレビューとして提供しました。対象は、プロンプトと単発のツール呼び出しだけでは足りず、ファイルを扱い、複数の手順を進め、必要に応じてサブエージェントへ作業を分けるAIエージェントを作る開発者です。モデルの呼び出しループや作業用サンドボックスを自前で組み立てず、Foundryが管理する実行基盤を選べるようになりました。

導入判断で最初に押さえる点は、Copilot harnessが新しいモデルではなく、既存のprompt agentへ選択する管理ランタイムだということです。エージェントは引き続きモデル、instructions、tools、skillsを持ち、アプリケーションからはResponses APIを使って呼び出します。公開プレビューのためSLAはなく、Microsoftは本番ワークロードを推奨していません。既存エージェントへ後から切り替えることも現時点ではできないため、検証用の新規エージェントとして評価します。

Copilot harnessが管理する範囲

通常のprompt agentでは、指示と対応ツールで完結する処理を軽く構成できます。Copilot harnessを選ぶと、Foundryがエージェントループと実行環境を運用し、会話ごとの作業領域、ファイル操作、コマンド実行、Web取得、サブエージェントへの委譲をまとめます。開発チームは、業務固有の手順をskillsとして用意し、外部サービスとの接続や合格条件へ集中できます。

一方、独自フレームワーク、独自のオーケストレーション、ミドルウェア、依存パッケージ、プロセスモデルまで制御したい場合はhosted agentsが適します。管理ハーネスを使うかどうかは、機能の多さではなく、実行ループを製品の差別化要素として自社が所有する必要があるかで決めます。

方式	向く処理	自社が持つ主な責任
通常のprompt agent	指示と対応ツールで完結する短い処理	モデル・指示・ツール設定と評価
Copilot harness付きprompt agent	skills、ファイル、コマンド、サブエージェントを使う複数段階の処理	業務手順、接続、権限、評価、永続化
hosted agent	独自フレームワークや実行ループが必要な処理	アプリケーションの実装とチェックポイント設計

利用条件は一般のAgent Serviceより狭い

Foundry Agent Service自体は一般提供されていますが、Copilot harnessは一部地域だけの公開プレビューです。2026年11月4日にMicrosoft Learnの対応地域・制限で確認できた地域は、Australia East、Canada Central、Central US、Germany West Central、Japan East、Sweden Central、UK South、West Europe、West USです。日本で試す場合はJapan Eastが候補になります。モデルはreasoningとtool callingに対応し、同じプロジェクト地域でprompt agentに提供されている必要があります。BYOMは未対応です。

Azure Developer CLIを使う場合はazd 1.37.0以降とFoundry拡張が必要で、プレビュー機能をシェルごとに有効化します。SDKの最低版やNode.js 22以降など、言語別の前提もあります。ポータルで表示されたから導入可能と判断せず、使用する地域、モデル、ツール、SDKの組み合わせを同じ検証環境で確認してください。

export AZD_ALPHA_ENABLE_AGENTS_MANAGED_HARNESS=true

# azure.yaml の要点
harness:
  type: microsoft_copilot_preview

会話・作業領域・成果物を分けて考える

Copilot harnessでは、各リクエストにconversationが必要です。会話履歴はconversationに残り、ファイルと実行状態はconversationごとに分離されたworkspaceへ置かれます。Foundryはsandboxをアイドル化、再開、置換できますが、通常の置換後もworkspace状態は保たれます。ただしsandboxは顧客が管理する永続ストレージではありません。重要な成果物はFoundry Filesや自社のストレージへ保存します。

Responses APIではstoreを省略するかtrueにし、previous_response_idではなく同じconversationへ次の入力を送ります。store:falseや個別responseの削除には対応しません。会話を削除すると背後のハーネスセッションも整理されます。既存のResponses API実装を流用するときは、状態の持ち方と削除手順の差を先に洗い出す必要があります。

組み込みツールは最小構成から有効にする

新規エージェントでは、ファイル読み取り、ファイル書き込み、shell、Web取得、subagentsの五つの組み込み機能が有効です。検証では、必要な機能だけを許可する設定から始めます。特にshellは、実行環境が許す範囲でファイルやネットワークへ触れられるため、file read、file write、Webを無効にしてもshellを残せば厳密な境界にはなりません。

tools:
  - type: microsoft_copilot_toolset_preview
    defaultConfig:
      enabled: false
    configs:
      - name: filesystem_read
        enabled: true
      - name: web
        enabled: true

組み込みWebはURLの内容を取得する機能で、Foundry Web Searchとは別です。外部MCPをつなぐ場合はproject connectionを作り、エージェントのinstance identityへ必要な役割を与え、MCP側の承認設定を行います。公開プレビュー中、組み込みツールの承認ポリシーはサービス側が管理し、MCPのrequire_approvalは組み込みツールには適用されません。画面上で同じ『ツール』に見えても、認証、承認、ネットワーク境界を別々に確認します。

skillsは手順の再利用単位にする

skillsには、指示だけでなくスクリプトや補助資料をまとめられます。Microsoft Learnではトップレベルのskill参照は最大50件で、各エージェント版は変更されないskill版を参照します。日常の業務手順を一つの長いsystem promptへ埋め込むより、調査、データ検査、報告書作成のように作業単位で分けると、変更の影響と評価対象を追いやすくなります。

skillを更新したら、エージェントの新しい版を作り、保存された定義で参照版を確認します。説明文だけを直したつもりでも、対象とする入力や使用ツールが変われば結果は変わります。skill名、版、エージェント版、モデル、ツール構成を一組として評価結果へ残してください。

長時間処理は再開と再実行を区別する

同じ発表で、hosted agentsのlong-running resilienceが一般提供されました。これはCopilot harnessそのものとは別の機能ですが、Microsoft Learnの長時間実行の責任分担を読むと、再開できる範囲が分かります。Foundryは作業ID、入力の保存、leaseによるプロセス消失検出、handlerの再実行、ストリーム再送を提供します。しかし、ローカル変数や途中のcall stackまで自動復元するわけではありません。

プロセスが止まるとhandlerは先頭から入り直します。アプリケーション側は、完了した段階を示すcheckpoint、外部操作のidempotency key、送信済みかを示すwatermarkを永続化します。報告書の生成を再開できても、メール送信やチケット作成を二重に実行すれば業務上の失敗です。エージェントの会話履歴だけを進捗記録として使わず、外部システムの最終状態まで照合します。

12月以降はモデル以外の実行費用も測る

Microsoftの発表では、Copilot harnessのランタイム課金は2026年12月1日に始まります。それまではハーネス実行が無料ですが、モデル推論、個別課金のツール、接続サービスは対象外です。12月1日以降の公表価格は、sandboxのCPUが1 vCPU時間当たり0.0994米ドル、メモリが1 GiB時間当たり0.0118米ドルで、地域や契約により異なる場合があります。

評価時はモデルのトークン費用だけでなく、sandboxの稼働時間、メモリ、Web検索、Code Interpreter、MCP先のAPI、再試行を一つのタスクへ集計します。サブエージェントを増やして処理時間が短くなっても、並列実行の総CPU時間とモデル呼び出しが増えることがあります。成功した一件当たりの費用と、p95の完了時間を合わせて比較します。

小さな検証を七段階で進める

1. 既存の単一業務を選び、入力、期待成果物、禁止操作、合格条件を固定する
2. 通常のprompt agentで成立するか確認し、管理ハーネスが必要な理由を明記する
3. 対応地域とモデルを選び、検証用の新しいCopilot harnessエージェントを作る
4. 組み込みツールを原則無効にし、必要な機能だけを一つずつ追加する
5. skill、エージェント定義、接続、モデルを版管理し、保存後の定義を読み戻す
6. 途中でプロセス停止やツール失敗を起こし、checkpointと重複防止を確認する
7. 品質、重大失敗、総費用、完了時間、人の修正量を通常構成と比較する

導入の価値は、エージェントが多くの機能を使えることではありません。自前で管理していた実行ループを減らしながら、業務手順と成果物の評価へ開発時間を移せるかにあります。公開プレビュー中は仕様や対応範囲が変わる可能性があるため、最初から本番の中核へ置かず、終了しても業務を継続できる検証経路で試します。

導入判断のチェックポイント

• 既存prompt agentを切り替えるのではなく、新規エージェントで検証している
• Japan Eastなど対応地域と、reasoning・tool calling対応モデルの組み合わせを確認した
• workspaceと永続ストレージを分け、重要な成果物を外部へ保存している
• shellを含む組み込み機能とMCPの権限・承認を別々に点検した
• 再開時のcheckpoint、idempotency key、side-effect watermarkを実装した
• 12月1日以降のsandbox費用を含む成功タスク単価を見積もった

関連記事

• マルチエージェントを本番へ移す条件｜Deep Insightに学ぶ分業・検証・監視
• AIの改善を勘で判断しないために｜評価データと回帰テストの始め方

参考資料

• Microsoft Foundry Blog「Introducing the Microsoft Copilot harness in Foundry Agent Service」
• Microsoft Learn「Use the Microsoft Copilot harness with prompt agents」
• Microsoft Learn「Foundry Agent Service limits, quotas, and regional support」
• Microsoft Learn「Resilience for long-running Microsoft Foundry hosted agents」