Microsoft Copilot Harness：マルチモデルAIエージェントの実行基盤が重要な理由

要点：エージェントの実行基盤が製品選択になる

Microsoftは2026年10月28日、複数モデルとツールを使うエージェント向けの管理型ランタイムとして、Microsoft Copilot HarnessをFoundry Agent Serviceに導入しました。重要なのは新しいモデルだけではありません。指示、コンテキスト、スキル、ファイル、サブエージェント、ツール連携、サンドボックス、復旧、ガバナンスをまとめて提供する点です。

モデルはエージェントの一部にすぎません。実運用では、次の行動、必要な情報、ツール呼び出し、失敗からの復旧、安全な停止を設計する必要があります。Harnessはモデルの周囲にあるソフトウェアであり、デモを再現可能なワークフローに変えます。

2026年10月28日の発表内容

Microsoftによれば、このHarnessはGitHub、Copilot Studio、VS Code、CLIなどのCopilot体験を支えています。Foundryでは、実行基盤全体を自分で保守せずにエージェントを構築できます。Microsoftの公式発表とFoundryの技術記事で詳細を確認できます。

Foundryには複数の抽象度があります。指示と対応ツールだけで足りるならPrompt Agentで十分です。管理された実行、ファイル、スキル、サブエージェント、複雑なツール連携が必要ならCopilot Harnessが適します。フレームワーク、ミドルウェア、依存関係、実行動作を自分で管理したい場合はHosted Agentを選びます。

「エージェント」は一つの製品カテゴリではありません。チームがどこまで実行スタックを所有するかを、差別化要件から決めるべきです。

モデルよりHarnessが重要になる理由

モデルは推論できますが、関連するファイル、安全なツール、タイムアウト時の復旧方法、完了条件を自動で理解するわけではありません。Harnessは状態を保持し、複数モデルへ処理を振り分け、ツールとスキルを公開し、管理された環境にエージェントを置きます。

Microsoftは20以上のフロンティアモデルと独自キー持ち込みをサポートすると説明しています。分類には高速モデル、計画には推論モデル、コードや文書変換には別のモデルという使い分けが可能です。モデルを交換してもワークフローを作り直さずに済みます。

また、ランタイムをRustへ移植し、セッションのオーバーヘッドと最初のトークンまでの時間を削減したとしています。ただし、起動が速くても、ツール呼び出しや実行時間が増えれば総費用は下がりません。自分のタスクで測定する必要があります。

実際に試すための技術チェックリスト

1. エージェントの境界を決める

読み取り、作成、変更、公開、削除の範囲を明文化します。本番変更、秘密情報、決済、アカウント復旧、外部メッセージは別の権限クラスにします。管理型Harnessは制御を助けますが、ポリシーの代わりにはなりません。

2. デモではなく完了タスクを測る

不完全なコンテキスト、実ファイル、遅いツール、時々起きる失敗を含む課題で試します。質問の有用性、完了率、無関係な編集、リトライ、信頼できる結果までの時間、人の介入、ロールバック費用を記録します。

3. データと根拠の経路を確認する

タスク、使用モデル、ツール、変更ファイル、承認、エラー、最終的な根拠を残します。ログは量を増やすためではなく、エージェントがなぜ結論に至ったか、結果を再現できるかを確認するために必要です。

4. 移植性を要件にする

MicrosoftはMCPやAgent Skillsなどのオープン標準を強調しています。別のHarnessやフレームワークを持ち込めるかを実際に確認してください。書き出せるプロンプト、文書化されたツール契約、通常のファイル、明確なモデルルーティングが将来の移行費用を下げます。

5. 長時間実行の費用を計算する

FoundryのCopilot Harnessは公開プレビューです。Microsoftはランタイム課金を2026年12月1日から開始すると説明し、サンドボックスはvCPU時間あたり0.0994米ドル、メモリはGiB時間あたり0.0118米ドルとしています。モデル推論と接続ツールは別料金です。地域と契約を確認し、自分のワークロードで見積もります。

最初に試すべきチーム

複数ステップの業務はあるが、エージェントランタイムを保守したくないチームに向いています。引用付き調査、リポジトリ分析、文書作成、チケット分類、承認付きの社内業務が候補です。取り消せない本番操作、曖昧な目的、管理境界の外へデータを出せない処理は最初の用途にしません。

AIエージェントや自動化ソフトを比較するなら、まずBTTCソフトウェア一覧を確認し、BTTC技術ブログの評価記事も読んでください。比較すべきなのは最も賢そうなモデルではなく、根拠、制御、費用、復旧を含めて仕事を完了できるシステムです。

導入時に確認したい運用条件

実験では、エージェントを単独のチャットとしてではなく、状態を持つ処理として評価します。入力が途中で変わった場合、ツールが空の結果を返した場合、セッションが切れた場合に、どのように停止して再開するかを決めておきます。自動的に再試行する操作と、人へ引き継ぐ操作を分けることも重要です。

また、モデルを入れ替えたときに結果がどの程度変わるかを確認します。より高価なモデルを選ぶだけで解決する問題もありますが、実際には不明確な指示、欠けたファイル、弱いツール契約、承認不足が原因であることも多いからです。Harnessを評価するなら、モデルの性能だけでなく、ワークフロー全体の観測可能性と復旧性を比較してください。

ソフトウェア選択で見落としやすい点

管理型サービスを選ぶと、初期構築の負担は減ります。一方で、対応モデル、保存期間、リージョン、ネットワーク境界、削除手順、障害時のサポートに制約が生まれる可能性があります。導入前に、通常時の便利さだけでなく、解約時にデータと設定を取り出せるか、エージェントを停止したときに未完了タスクを安全に処理できるかを確認しましょう。

この観点は、AIツールを比較するすべてのチームに役立ちます。機能表の項目数より、失敗を見つけ、説明し、取り消せるかどうかが長期的な差になります。

よくある質問

Microsoft Copilot Harnessは新しいAIモデルですか？
いいえ。モデル、ツール、コンテキスト、スキル、制御をまとめるオーケストレーションと実行の層です。

すべてのチームが管理型Harnessを使うべきですか？
いいえ。管理の利点が制御を失うコストを上回る場合に使います。独自ミドルウェアやポリシーが差別化要件なら自前のランタイムを検討します。

公開プレビューを本番で使えますか？
Microsoftの文書ではプレビューで、制限やSLAなしの可能性が示されています。非重要タスクから始め、対応地域とモデルを確認し、承認を残します。

結論

Microsoft Copilot Harnessは、AIの長期的な価値がモデル周辺のシステムへ移っていることを示します。コンテキスト、ツール、ファイル、スキル、ルーティング、復旧、ガバナンス、根拠が、エージェントが役立つ仕事を終えられるかを決めます。取り消し可能で測定しやすいワークフローから評価を始めましょう。