Microsoft、GitHub Copilotを支える実行基盤を外部開放：AIエージェント開発はどう変わるのか

AIエージェントの開発では、基盤となるAIモデルの推論性能だけでなく、その能力を実際の作業に結びつける実行環境の重要性が増している。どれほど高性能なモデルを採用しても、プロンプトやコンテキストの管理、外部APIの呼び出し、ファイル操作、実行状態の管理などが適切に機能しなければ、エージェントは期待どおりに作業を完了できない。

Microsoftは2026年10月28日、GitHub CopilotやCopilot Studioなどを支えるエージェント実行機構「Microsoft Copilot harness」を、クラウドサービス「Microsoft Foundry Agent Service」のパブリックプレビューとして公開した。開発者は独自のオーケストレーション基盤を一から構築・保守することなく、複数のツールを使って複雑な作業を進めるAIエージェントを開発できるという。ただし、今回の提供はあくまでプレビュー段階であり、本番運用に必要なサービス保証や機能がすべて整っているわけではない。導入にあたっては、Microsoftに任せられる処理と、開発者側が引き続き管理しなければならない領域を見極める必要がある。

AIモデルを取り囲む「ハーネス」とは何か、プレビュー版の制約

AIエージェントにおける「ハーネス（harness）」とは、AIモデルの周囲で動作し、モデルが外部の環境とやり取りしながら作業を進めるための仕組みを指す。具体的には、システムプロンプトやコンテキストの管理、MCP（Model Context Protocol）などを利用した外部ツールの呼び出し、コードを実行するサンドボックスの提供、モデルによる判断と操作の繰り返しを管理するエージェントループなどが含まれる。モデル自体の推論能力とは別に、その推論結果を具体的な操作へ結びつけ、作業全体の進行を制御する役割を担う。

エージェントの実行時には、ユーザーからの入力に応じて必要なコンテキストやプロンプトが用意され、モデルが次に実行すべき処理を判断する。その判断に従い、ファイルの読み書き、シェルコマンドの実行、ウェブコンテンツの取得、サブエージェントへの作業委譲などが行われる。コードやコマンドの実行には、CPUやメモリなどのリソースが管理されたサンドボックスを使用する。こうした一連の処理を統制し、モデルと外部環境の間を取り持つのがハーネスの役割だ。

今回Microsoftが公開したのは、GitHubのエンジニアリングチームが開発を進めてきたこの実行機構を、Microsoft Foundryの「プロンプトエージェント（prompt agents）」で選択できる追加ランタイムとして提供する仕組みである。これにより開発者は、エージェントループや実行インフラを自前でデプロイして保守する負担を減らし、エージェントに与える知識や作業手順、利用するツール、モデルの選定に集中できる。特に、ファイル操作やコード実行を伴う複雑なワークフローを、マネージド環境で構築しやすくなる点が特徴だ。

ただし、FoundryでのCopilot harnessは現時点でパブリックプレビューとして提供されている。サービス品質保証契約（SLA）は付帯しておらず、Microsoftの公式ドキュメントでも、商用の本番ワークロードでの利用は推奨されていない。プレビューである以上、機能や制限事項が今後変更される可能性もあり、企業の基幹業務に導入する際には慎重な判断が必要になる。

また、同時期にMicrosoftが発表した「長時間実行時の回復機能（long-running resilience）」の一般提供（GA）と、今回のハーネスの提供状況は区別する必要がある。中断された処理を復旧させるこのGA機能は、開発者が独自のランタイムを構築する「ホステッドエージェント（hosted agents）」を対象としている。Copilot harness自体が一般提供に移行したわけではなく、プレビュー版に本番環境向けのSLAが適用されることも意味しない。

一方、エージェントを呼び出す仕組みは、従来のFoundryプロンプトエージェントと大きく変わらない。Copilot harnessを利用するエージェントもResponses APIを通じて実行されるため、既存のAPIを利用した開発方式と組み合わせやすい。ただし、呼び出し方法が共通であることと、背後のランタイムが同等の運用品質を備えていることは別の問題だ。

標準ツールとサブエージェントを統合、マルチモデル対応には制約も

FoundryのCopilot harnessは、再利用可能なスキル、外部ツールとの接続、サンドボックス内でのファイル操作やコード実行、サブエージェントへの作業委譲を統合した実行環境を備えている。新規作成したエージェントでは、ファイルの読み取り、ファイルの書き込み、シェルコマンドの実行、ウェブコンテンツの取得、サブエージェントへの委譲という5つの組み込みツールが、初期状態で有効になっている。

標準ツール	主な役割	新規作成時の状態
ファイル読み取り	ファイルの内容を取得・参照する	有効
ファイル書き込み	ファイルの作成や変更を行う	有効
シェル実行	コマンドやスクリプトを実行する	有効
ウェブ取得	ウェブ上のコンテンツを取得する	有効
サブエージェント委譲	別のエージェントに作業を任せる	有効

これらを組み合わせることで、例えばソースコードを調査し、必要なスクリプトを実行し、エラーが発生した場合には原因を分析して修正を試みるといった一連の作業を進められる。開発者が個々のツールの呼び出し処理や作業の反復制御をすべて実装する必要がないことは、開発負担を減らすうえで大きな利点だ。ただし、ツールが標準で利用できることは、外部システムとの連携が無条件で可能になることを意味しない。

MCPを通じて接続する外部ツールや、Foundryがサポートする各種サービスには、それぞれ固有の認証方式やネットワーク要件、承認ポリシーがある。利用できるモデルやAzureリージョンにも制約があり、組み込みツールと同じようにすべての外部連携を扱えるわけではない。企業が実際に導入する場合は、既存のアクセス制御やセキュリティポリシーとの整合性を確認する必要がある。

モデルの選択についても、Microsoftの発表全体とFoundryのCopilot harnessプレビューで利用できる機能を分けて考える必要がある。同社は製品群全体の取り組みとして、20種類以上のフロンティアモデルへの対応、独自のAPIキーを利用するBYOK（Bring Your Own Key）、タスクに応じたモデルの自動ルーティングなどを掲げている。しかし、これらの機能がFoundryのCopilot harnessですべて利用できるわけではない。

特に、FoundryのCopilot harnessでは、BYOM（Bring Your Own Model、独自モデルの持ち込み）はサポートされていない。エージェントには、推論とツール呼び出しに対応し、利用するAzureリージョンのプロンプトエージェントで使用可能なモデルを指定する必要がある。Microsoftが全社的に対応を進めている幅広いモデル群を、そのままFoundryのプレビュー環境で自由に利用できるわけではない。

また、Microsoftはタスクに応じて適切なモデルへ処理を振り分ける仕組みを打ち出しているものの、今回の公開資料からは、FoundryのCopilot harnessで複数モデル間の自動ルーティングが一律に有効になるとは確認できない。Rust製ランタイムへの移行によるセッションのオーバーヘッド削減や、最初のトークンが生成されるまでの時間の短縮、数百万人規模での利用実績なども、Microsoftの製品群全体に関する説明だ。これらはFoundryのプレビュー環境で独立した第三者機関が測定した性能値ではないため、実際の導入環境で同じ結果が得られるとは限らない。

ローカルSDKとFoundryのマネージド版は何が違うのか

Microsoft Copilot harnessを利用する方法には、大きく分けて二つの経路がある。一つは、開発者がローカル環境や自社インフラで制御する「Microsoft Copilot SDK」、もう一つはMicrosoftがクラウド上で管理する「Foundry Agent Service」だ。両者は同じハーネス技術を利用する選択肢だが、実行環境の管理主体や認証方式、運用上の責任範囲が異なる。また、Foundryには独自のエージェントコードをホストする「ホステッドエージェント」という別の選択肢もある。

アプローチ	実行環境の管理主体	主な用途	提供状況と制約	コスト・認証上の考慮点
Microsoft Copilot SDK（ローカル・自社環境）	開発者がローカル環境やコンテナなどを管理	開発環境の自動化、CI/CDへの組み込み、独自の実行制御	GitHubで公開中。名称移行の過渡期にあり、パッケージ名などに差異が残る	GitHub Copilot契約、または対応プロバイダーのAPIキーによるBYOK
Foundry Copilot harness（マネージド版）	Microsoftがクラウド上のサンドボックスを管理	標準ツールを利用したエージェントの迅速な開発、実行環境の管理負担軽減	パブリックプレビュー。本番SLAなし。既存エージェントからの切り替え不可	2026年12月1日からサンドボックスの従量課金。モデル推論費は別途発生
Foundry Hosted Agents（ホステッドエージェント）	エージェントのコードや実行ロジックは開発者、ホスティング環境はFoundryが管理	独自フレームワークやミドルウェアを維持したクラウド運用	ホステッドエージェント向けの長時間実行時の回復機能などが一般提供	コンテナの稼働に伴うインフラ費用とモデル推論費が発生

GitHubでは、以前「GitHub Copilot SDK」と呼ばれていたインターフェースを「Microsoft Copilot SDK」へ名称変更する作業が進められている。このため、ドキュメントやパッケージ名の一部には旧称が残っており、導入時には名称や設定方法の違いに注意する必要がある。対応言語はNode.js/TypeScript、Python、Go、.NET、Rust、Javaと幅広く、既存の開発環境に組み込みやすい構成となっている。

SDKは、アプリケーションがバックグラウンドで起動するCopilot CLIサーバーと、JSON-RPCを通じて通信する仕組みを採用している。通常はSDKがCLIプロセスの起動や終了を自動的に管理するが、その動作は言語環境によって異なる。Node.js、Python、.NET向けにはCLIの実行ファイルが同梱されている一方、Go、Java、Rustでは開発者がCLIを別途インストールするか、実行ファイルのパスを設定しなければならない。

認証方式にも違いがある。SDKを標準的な方法で利用するには、有効なGitHub Copilotサブスクリプションが必要だ。対応プロバイダーのAPIキーを使うBYOK方式であればGitHub認証を使わずに利用できるが、現行のBYOK認証はAPIキー方式に限られている。Microsoft Entra IDやマネージドID、外部IDプロバイダーを使った認証・アクセス制御は、SDKのBYOK機能では直接サポートされていない。

一方、Foundryのマネージド版では、CLIプロセスやサンドボックスの管理をAzure側に任せられる。開発者は実行環境を直接管理する必要がなくなる代わりに、サービス側が定めるリソースや承認ポリシーなどの制約を受ける。SDKの柔軟なローカル統合と、Foundryが提供するクラウド上の管理機能は、それぞれ異なる要件に適している。同じCopilot harnessという名称でも、両者を同一の運用形態として扱うべきではない。

長時間実行と障害復旧で残る開発者側の責任

AIエージェントに長時間の複雑な作業を任せる場合、実行環境の管理だけでなく、処理が中断された際の復旧方法も重要になる。Microsoftが提供する長時間実行時の回復機能は、中断を検知した場合にエージェントを再起動し、元の入力を使って処理を再開する仕組みだ。ただし、こうした機能があっても、エージェントが中断前にどこまで作業を終えていたかを正確に復元できるとは限らない。

例えば、会話履歴が保持されていても、作業途中のファイルや外部システムの状態まで自動的に復元できるとは限らない。処理のチェックポイントや中間生成物を保存する仕組みがなければ、エージェントは最初から作業をやり直す必要が生じる。長時間のタスクを確実に継続するには、開発者側でも進捗や処理結果を永続化し、再実行時に参照できるようにしておくことが重要だ。

特に注意すべきなのが、外部システムへの更新処理が重複するリスクである。例えば、エージェントがAPI経由でデータベースを更新したり、GitHubにプルリクエストを作成したりした直後に処理が中断されたとする。再起動したエージェントが同じ操作を繰り返すと、更新が二重に適用されたり、同じプルリクエストが複数作成されたりする可能性がある。こうした問題を防ぐには、すでに処理が完了しているかを確認したうえで操作を実行する必要がある。

このように、同じ操作を繰り返しても結果が変わらない性質を「冪等性（べきとうせい）」と呼ぶ。外部APIが冪等性キーなどを提供している場合は、それらを利用する方法もあるが、すべての外部サービスが対応しているわけではない。エージェントの再実行によって副作用が重複しないようにする設計は、実行基盤をMicrosoftに任せても、開発者側に残る重要な責任だ。

さらに、Foundry Copilot harnessのパブリックプレビューには、次のような制約がある。

• 既存エージェントからの切り替えは不可: Copilot harnessは新規エージェントの作成時に選択する必要があり、作成済みのプロンプトエージェントを後から切り替えることはできない。
• サンドボックスのリソースは固定: CPUやメモリ、アイドル時間などの実行リソースはMicrosoft側が設定しており、利用者が自由に変更することはできない。
• 組み込みツールの承認ポリシーはMicrosoftが管理: 利用者が設定できるrequire_approvalフラグは追加のMCPツールを対象としており、組み込みツールの承認ポリシーを任意に変更することはできない。
• 外部サービスへのデータ送信には別途注意が必要: 外部ツールやエンドポイントに接続した場合、データはFoundryの管理範囲を離れ、接続先サービスの利用条件に従って処理される。

また、Copilot harnessのプレビューで対応しているAzureリージョンやクライアント、ネットワーク構成、利用可能なクォータは、Foundry Agent Service全体よりも限定されている。企業が導入を検討する際には、必要なリージョンでサービスが利用できるか、既存のネットワーク構成やセキュリティ要件に適合するかを確認しなければならない。マネージドサービスを利用しても、外部連携や業務処理に伴う障害のすべてをMicrosoft側が解決してくれるわけではない。

12月1日からサンドボックス課金開始、導入判断の焦点は実効コスト

Copilot harnessの導入を判断するうえで、もう一つ重要なのが料金体系だ。Microsoftは、Foundry Agent Serviceで提供するCopilot harnessのサンドボックスについて、2026年12月1日から従量課金を開始すると発表している。プレビュー開始から11月末まではハーネスのランタイム利用料は無料だが、モデルの推論費用や個別に課金される接続サービスの利用料は、プレビュー期間中も発生する。

12月1日以降は、これらに加えてサンドボックスのコンピュート費用が課金される。公表されている標準単価は、vCPUが1時間当たり0.0994米ドル、メモリが1GiB・1時間当たり0.0118米ドルだ。ただし、実際の単価はAzureリージョンや企業ごとの契約条件によって変動する。

課金対象	公表されている標準単価
vCPU	0.0994ドル／vCPU・時間
メモリ	0.0118ドル／GiB・時間

出典：Microsoft Foundryの公式発表。2026年12月1日から適用される標準料金で、リージョンや契約条件によって異なる。

この料金体系では、AIモデルが消費するトークンだけでなく、サンドボックスの稼働時間もコストに影響する。例えば、エージェントが長時間アイドル状態で稼働し続けたり、非効率なループ処理を繰り返したりすれば、その間のコンピュート費用が積み上がる可能性がある。実際の費用を見積もるには、推論に使用するトークン数だけでなく、CPUとメモリの割り当て、サンドボックスの稼働時間、外部サービスの利用料を合わせて考える必要がある。

また、すべてのエージェントにCopilot harnessが必要なわけではない。単純な質問への応答や、単一の検索ツールを呼び出すだけの処理であれば、従来のハーネスなしのプロンプトエージェントで十分な場合がある。こうした用途では、Copilot harnessを導入することで実行基盤が複雑になり、追加のコンピュート費用が発生する可能性があるため、必ずしも合理的な選択とはいえない。

一方、独自のフレームワークや特殊なミドルウェアを使用する必要がある場合、あるいは実行プロセスを細かく制御しなければならない基幹業務では、Foundryのホステッドエージェントが適している場合がある。開発者がエージェントの実行ロジックを維持しながら、クラウド上のホスティング環境を利用できるためだ。こうした構成では、自社で制御できる範囲が広い一方、実行ロジックや関連コンポーネントの保守責任も大きくなる。

Copilot harnessが有力な選択肢となるのは、その中間に位置する用途だ。ファイル操作やコード実行、サブエージェントへの作業委譲など、複数の標準ツールを組み合わせる自律的なワークフローを構築したい一方、実行基盤そのものの運用負担は抑えたい場合に適している。特に開発支援や調査、ファイル処理など、複数段階の操作を伴うタスクでは、既存のハーネス機能を利用することで独自実装を減らせる可能性がある。

ただし、導入によって開発工数や運用コストがどれだけ削減できるかは、実際のワークロードによって異なる。モデルの選択肢が多いことや、標準ツールが豊富であることだけでは、導入の経済的な合理性を判断できない。比較すべきなのは、対象タスクの完了率、人間による修正や承認が必要になる頻度、処理全体にかかる時間、そして推論費用とサンドボックス費用を合算した実効コストだ。

Microsoft Copilot harnessの外部提供は、AIエージェントの開発において、モデルの性能だけでなく、その能力を安定して活用する実行基盤の重要性が高まっていることを示す動きだ。これまで開発者が個別に実装してきたツール連携やエージェントループをマネージドサービスとして利用できることには、開発と保守の負担を減らす可能性がある。しかし、現時点のFoundry版はパブリックプレビューであり、本番SLAやリソース設定、モデル選択、既存エージェントの移行などに制約が残る。

今後は、12月1日の課金開始後に実際の運用コストがどの程度になるかに加え、複数モデル間の自動ルーティングがFoundry上でどこまで利用できるようになるかが注目される。また、既存エージェントの移行や本番環境向けのサービス保証が整備されるかどうかも、企業での採用を左右する。Copilot harnessの価値は、エージェントの処理をどこまでMicrosoftに任せられるかだけでなく、開発者が引き続き管理すべき領域を明確にしたうえで、実際の業務における信頼性と費用対効果を改善できるかによって決まる。