Microsoft Copilot HarnessがFoundryで公開、内製か導入かの判断を変える
Microsoftは10月28日、Microsoft Copilot harnessをFoundry経由で公開し、運用管理の主導権を維持しつつ、社内の実行基盤を開発者へ拡張した。ハーネスとは、指示、コンテキスト、ツール、実行を整理するAIモデル周辺のソフトウェアを指す。この発表により、企業が自ら構築せずに購入できるものは変わるが、その結果として生じる業務への責任がなくなるわけではない。
中心となる選択肢は、その実行機構を社内で保守するか、Microsoftの管理型アプローチを採用するかだ。エージェント、すなわちモデルとツールを用いてタスクを遂行するソフトウェアには、有能なモデルへのアクセス以上のものが必要となる。継続方法、障害への対処、事業上の境界内での運用を誰かが決めなければならない。
Anthropicはすでに競合する管理型アプローチを提供しており、購入者にMicrosoft製品群以外の有用な比較対象を与えている。Microsoftの特徴的な訴求は、共有インフラを通じて異なるモデルファミリーへアクセスできる点にある。開発チームにとって実務上の問いは、どの責任を委譲しやすくなり、どの責任に引き続きアプリケーション固有の判断が必要かということだ。
Microsoft Copilot HarnessがFoundryのパブリックプレビューへ
Microsoftは、共有の製品基盤を顧客アプリケーション向けの管理型ビルディングブロックへ転換している。
Microsoftのマルチモデルハーネスに関する発表によると、GitHubのエンジニアリングチームは、MicrosoftがCopilotの各体験に採用する前にこのハーネスを開発した。同社は利用例として、Copilot Code、Copilot Studio、GitHub Copilot app、コマンドラインインターフェース、VS Codeを挙げている。
エージェントの構築と運用のためのMicrosoftプラットフォームであるFoundry Agent Serviceは、このハーネスをパブリックプレビューで提供する。このステータスは重要だ。今回の発表は、実績ある社内技術と、新たに利用可能になった管理型サービスを組み合わせているからである。Microsoft製品内での経験が、すべての外部顧客ワークロードへの準備完了を自動的に意味するわけではない。
Microsoftは、実行機構を自社が運用し、顧客はアプリケーション固有の指示と接続を提供するという責任分担を説明している。この構成により、今回の公開はコーディング支援ツールを超えた意味を持つ。リサーチアシスタントや業務エージェントを開発する企業は、従来は社内のエンジニアリング作業と見なされていたインフラを購入する選択肢を検討できる。
発表では、開発者が技術をアプリケーションへ統合するために使うパッケージである、ダウンロード可能なソフトウェア開発キットについても説明している。この経路を、管理型のFoundry体験と混同すべきではない。配布方式の選択と、サービスを誰が運用するかの選択は関連する判断だが、答える問いは異なる。
企業の購入者にとって、直近の変化は実装選択肢が一つ増えたことだ。エージェントを評価するチームは、異なるモデルのサポートには独自の周辺実行システムの保守が必要だと、もはや前提にする必要がない。Microsoftはその共有基盤を顧客に代わって保守すると提案している。
この提案は正確に読む必要がある。管理型ハーネスを購入しても、特定のワークフローが正しい回答や適切な行動を生み出すことは保証されない。変わるのは、機構の一部を誰が提供するかである。購入者は依然として、完成したアプリケーションが自社の要件を満たすという証拠を必要とする。
たとえば、サプライヤーの発表を比較し、社内向けブリーフィングを作成する仮想的なリサーチアプリケーションを考えてみよう。有用な成果には、正確な出典、明確な日付、相反する情報の明示的な扱いが含まれる。機能する実行システムはその業務を支援するが、組織に代わってこうした編集上の要件を定義することはできない。
したがって今回の公開は、アーキテクチャに関する議論の出発点を変える。チームは、どのモデルが要求に答えるべきかだけでなく、エージェント実行のどの部分にカスタムエンジニアリングの価値があるかを問えるようになる。これは、選択メニューに別のモデルが表示されるかどうかよりも重要な問いだ。
自前の実行機構を保守するチームに圧力がかかる
Microsoftの提案は、事業上の優位性を生まずに機能を再現している社内インフラプロジェクトを精査の対象にする。
最も強い圧力を受けるのは、エージェント向けの周辺機構をすでに保守しているアプリケーションチームだ。その管理者には、検討すべき外部の代替案が生まれた。カスタム実装を継続することは、エージェントを出荷するための自動的な前提条件ではなく、正当化を要する判断になる。
その正当化には、なお説得力があり得る。企業は、特殊な実行動作、専門的な統合、または作業の進め方に対する直接的な制御を必要とするかもしれない。重要なのは、こうした要件がアプリケーションに実質的な影響を与えるかどうかだ。組織がその制御によって何を実現するのかを明確にできる場合、カスタム所有はより合理的となる。
インフラを購入すると、別の責務が生じる。すなわち、プロバイダーの境界を理解することだ。開発チームは、デモで示された機能だけで管理型サービスを評価することはできない。プラットフォームがどこで終わり、自社のソフトウェア、手順、監督がどこから始まるのかを特定しなければならない。
Microsoftの管理型エージェント実行に関する発表では、スキル、接続ツール、ファイルおよびコード実行、範囲を限定した委任が概説されている。スキルは、指示と支援リソースをまとめた再利用可能な手順である。ツールは、エージェントに外部情報やアクションへのアクセスを与える。これらの機能は、テキスト生成だけを超える幅広いアプリケーション基盤を示している。
同じ発表は、初期顧客の見解も紹介している。Confluence Technologiesの最高技術責任者であるChris Evans氏は、同社が1週間未満でソリューションを稼働させたと述べている。これは有用な実装事例だが、典型的な導入スケジュールや長期的な運用成果を示すものではない。
購入者にとって重要なのは、最初の稼働状態に到達することと、信頼できるサービスを維持することの違いだ。社内プロトタイプは、運用アプリケーションでは許容できない仮定を許せる場合がある。管理型基盤は一部のエンジニアリング作業を短縮できる一方で、統合レビュー、受け入れ基準、所有権に関する判断は未解決のまま残る。
したがって有用な財務比較では、単一のモデル応答ではなく、完全なワークフローを検討すべきだ。関連する考慮事項には、エンジニアリング保守、障害の調査、人によるレビュー、接続システムの変更が含まれる。これらの責務は組織ごとに異なるため、今回の公開から普遍的な計算式は導けない。
この圧力は、モデルを取り巻く製品を提供するインフラベンダーにも及ぶ。Microsoftの配布は、顧客がどの個別コンポーネントを必要とするのかを見直す新たな理由となる。これは独立系製品が不要になることを意味しない。追加で提供する制御、可視性、専門性を説明する基準が高まることを意味する。
ナレッジワーカーにとって、影響は別の形で現れる。エージェントが実用的な成果物を完成させるか、適切な証拠を保持するか、不確実性を適切にエスカレーションするかを、彼らは体験する。アーキテクチャの変更が重要になるのは、不完全な作業を減らし、誤りを特定・修正しやすくする場合だ。
だからこそ、内製か購入かの議論はエンジニアだけでなく、プロダクトオーナーも含めて行う必要がある。どのインフラ構成がそれを実現するかを決める前に、組織は満足できる結果を定義しなければならない。そうでなければ、技術的に成功した導入であっても、実際の事業課題はほとんど解決されないままになり得る。
モデル選択とランタイム制御は別の判断である
異なるモデルへのアクセスがあっても、顧客が管理型サービスによる業務実行を無制限に制御できるわけではない。
Microsoftのharness利用可否に関するFAQは、プレビューの境界を示している。独自モデルの持ち込みは利用できない。顧客は新しいプロンプトエージェントを作成する際にハーネスを選択し、その後で切り替えることはできない。利用可否は、リージョン、クライアント、ツール、ネットワーク、クォータによっても異なる場合がある。
こうした制限は、マルチモデル対応の意味を明確にする。顧客は、サービスの境界内でサポートされる選択肢を評価できる。より広い戦略が選択肢を強調しているからといって、あらゆるモデル、接続、導入構成が利用できると想定することとは異なる。
この違いは調達時に重要となる。ベンダーのポートフォリオの別の場所にモデルが存在していても、それが特定の管理型体験でサポートされるかどうかの答えにはならない。購入者は、関連するデプロイ先と接続システムを含め、実際に使用する組み合わせを評価する必要がある。
モデルを変更することと、アプリケーションの動作を維持することにも違いがある。インターフェースが一貫していても、異なるモデルは異なる判断や出力を生む可能性がある。アプリケーションの所有者は、モデル変更を単なる管理上の置換ではなく、事業要件に照らして評価すべきものとして扱う必要がある。
サプライヤー提案書をレビューする仮想的な調達アシスタントを考えてみよう。あるタスクでは納入日を抽出する。別のタスクでは曖昧な契約解除条項を解釈する。組織はこうした作業に異なるモデル特性を望むかもしれないが、それでも許容可能な証拠とエスカレーションについて一貫した定義が必要となる。
共有実行基盤は、その比較を整理しやすくできる。ただし、同じ指示がサポートされるすべてのモデルで等しく機能することを保証するものではない。有用な成果は、何が変わり、なぜ変わったのかを明確に記録しながら、結果を比較できる統制された機会にある。
Anthropicの管理型エージェントアーキテクチャは、関連する競争上の比較対象となる。同社の2026年4月のエンジニアリング報告は、モデルとハーネスを実行環境および永続的なセッション記録から分離する設計を説明している。示された狙いは、安定したインターフェースの背後で実装を進化させられるようにすることだ。
この比較は、業界の競争がモデル選択を超えて広がっている理由を示している。プロバイダーは、顧客が依存できるインターフェースを維持しながら、どの実行責務を引き受けられるかでも競争している。複数のモデルファミリーを重視するMicrosoftの姿勢は、より広範な購買判断の一側面に対応するものだ。
どちらのアーキテクチャ説明も、普遍的な勝者を示すものではない。管理型アプローチを比較する企業は、実際のワークフロー、必要な統合、運用上の制約を照らし合わせる必要がある。あるアプリケーションに適したサービスが、別のアプリケーションには不適切な前提を課す可能性もある。
より深いトレードオフは、柔軟性をどこに置くかにある。チームは、プロバイダーの実行設計を受け入れつつ、サポート対象モデル間の選択肢を維持できる。あるいは、より大きな実行制御を維持し、その保守責任を引き受けることもできる。これらは異なるエンジニアリング上の帰結を持つ、別種の柔軟性である。
Microsoft Copilot harnessにとって最も実践的な解釈は、選択肢が限定されているということだ。顧客はエージェント開発のための追加のマネージド経路を得る。その経路は、より広範なブランディングを普遍的な互換性の約束として捉えるのではなく、文書化された機能に基づいて評価すべきである。
Microsoftの評価による成果には慎重な解釈が必要
Microsoftの社内結果は追加評価を支持するが、すべてのFoundryアプリケーションで同等の改善が得られることを示すものではない。
Microsoftは、エージェント評価結果において、Copilot StudioのCopilot harnessをStandard harnessと比較している。OpenAIモデルでは合格率が10.8ポイント、Anthropicモデルでは22.1ポイント改善したと報告している。
Microsoftはまた、評価対象ケースの84〜91%で、ツール呼び出し失敗後も試行を継続したと報告している。Standard harnessでは7%未満だった。付随する注記では、ツール利用の継続や再試行の成功と、タスク全体の完了成功を明確に区別している。これらは企業が報告した調査結果であり、ここで独立した検証が確立されているわけではない。
この留保は、発表を解釈するうえで重要である。永続性は、何かがうまくいかなかった後の挙動を表す。完了は、要求された結果に到達したかを表す。システムは作業を継続していても、タスクを誤解したり、不適切な根拠を用いたり、受け入れられない結果を生成したりする可能性がある。
この違いは、仮想的なカスタマーサービスのワークフローで具体化できる。エージェントはケース記録へのアクセスを正常に再試行できても、誤った解決策を推奨する可能性がある。失敗した接続からの回復を測定することは、実行時の挙動を説明する助けにはなる。しかし、それだけで顧客が正確な回答を得たかどうかは判断できない。
同様に、より高い評価合格率は、評価で何を問うかに左右される。購入者は、結果を自社環境へ適用する前に、関連するタスク、受け入れ基準、構成を理解する必要がある。パーセントポイントでの改善は、それが測定したテストとの関係においてのみ有益な情報となる。
これは、周辺の実行システムの重要性を低下させるものではない。Microsoftが報告した比較は、モデル能力だけではエージェントの成果を決定しないという主張と整合する。顧客には、帰属と制約を明示したまま、モデルの選択と並行して実行方式も検証する理由を与える。
Microsoftはまた、社内のサポートアプリケーションが2026年8月に完全自律解決率35%超を達成したと説明している。同社はこの指標を、人の介入なしにケースを解決した割合と定義している。これは具体的に報告された導入事例だが、比較対象として適切かどうかは、対象ケースと運用条件に依存する。
同様のアプリケーションを評価する企業では、自律性を正確性や結果の影響と併せて検討すべきである。介入なしに解決されたケースは、その解決が正確かつ適切であれば有用な証拠となり得る。介入がなかったことだけでは、結果が組織の基準を満たしたことは示せない。
評価では、レビュー担当者へ移転される作業も考慮すべきである。エージェントがより多くの成果物を生成しても、大幅な修正を必要とするなら、出力量は実務上の貢献を誤って表す可能性がある。ビジネス上の問いは、完了し受け入れ可能な作業と、それを得るために必要な労力に関するものだ。
同じ論理は、後になって初めて見える失敗にも当てはまる。根拠のない主張を含む洗練されたブリーフィングは、納品時には成功に見える可能性がある。証拠と帰属を確認する評価なら、異なる結果が明らかになる。受け入れ基準は、結果が実際にどのように利用されるかを反映すべきである。
現時点では、Microsoftの数値は、同社がテストした環境についての有用な証拠である。顧客固有のテストに取って代わるものではないが、調査を正当化する。購入者は、ベンダーによる比較を、報告された評価に含まれていないワークロードの予測へと置き換えるべきではない。
マネージド実行でも事業責任は顧客に残る
インフラを委任しても、エージェントに何を許可するかを決める責任まで移転するわけではない。
最も明確な境界は、重大な結果を伴うアクションに関するものだ。推奨を準備するエージェントと、その推奨に組織を拘束するエージェントには、異なる統制が必要である。マネージド実行サービスはどちらの設計にも対応できるが、権限がどこで始まりどこで終わるかは組織が決めなければならない。
Fashableは、Microsoftのローンチ資料の中で顧客の視点を提示している。最高経営責任者のOrlando Ribas Fernandesは、商業的拘束力を持つ意思決定を人間の統制下に置いたまま、ソーシングワークフローにおける機会について説明している。これは、提案されたすべての機能がすでに測定可能な成果をもたらした証拠ではなく、意図された運用上の境界である。
この例は、説明責任を自動化から推論できない理由を示している。ソーシング支援ツールは、仕様を比較し、不足情報を特定し、交渉資料を準備できるかもしれない。購入を承認することには別の責任が伴う。こうした活動が1つの会話内に現れる場合でも、その区別は明確に保つべきである。
長期にわたる作業には、別の境界がある。起きたことを記憶することと、何が依然として有効なのかを知ることの違いだ。エージェントは以前の結果を保持できても、状況が変化したことを認識できない可能性がある。アプリケーション所有者は、以前の情報をいつ再確認すべきか、どの意思決定が最新の証拠に依存するかを決定する必要がある。
Anthropicの長期稼働エージェントに関する研究では、セッションをまたいだ未完了作業や早すぎる完了宣言に関する失敗が説明されている。同社が提案するアプローチは、明示的な進捗記録と段階的な作業を用いる。より広い教訓は、実行を継続するには、未完了の義務を信頼できる形で把握する必要があるということだ。
企業にとって、この教訓は完了を事業上の条件として扱うことを示唆する。タスクは、必要なレビューや確認を含む受け入れ基準が満たされた時点で完了する。自信に満ちた最終メッセージは、それらの条件が満たされている証拠の代わりにはならない。
中断された作業を再開することにも関連する懸念がある。レポートを作成し、別のシステムに送信する仮想的なエージェントを想像してみよう。送信には成功したものの確認が失われた場合、アクションを繰り返すと重複レコードが作成される可能性がある。アプリケーションには、未完了のアクションと未確認のアクションを区別する方法が必要だ。
Microsoftは別途、顧客が独自の実行ロジックを持ち込むホスト型エージェント向けに、長時間実行レジリエンスの一般提供を発表した。そのドキュメントでは、保存済み進捗と重複防止の責任をアプリケーションコードに置いている。この別機能を、新しいharnessプレビューに対する包括的な保証として扱うべきではない。
情報品質は、さらなる責任を生み出す。古いガイダンスに接続されたエージェントは、指示を一貫して実行していても、不適切な作業を生成する可能性がある。検索可能なナレッジベースを検討するチームは、ソースの整理と保守をアプリケーションの一部として扱うべきである。
この関係は、特定の統合を示唆することなく、ナレッジ管理を今回のローンチと関連づける。インフラは作業がどのように進むかを決定し、利用可能な証拠はエージェントが合理的に結論づけられる範囲を制約する。一方を改善しても、他方の弱点がなくなるわけではない。
したがって、組織は完全なワークフロー全体で責任者を割り当てるべきである。ソース資料、権限、受け入れ基準、結果が失敗した際の修正について、誰かが責任を負う必要がある。マネージド実行はエンジニアリング上の負担を変えられるが、こうした組織上の意思決定をなくすものではない。
最も信頼できる導入事例は、プロバイダーが引き受ける作業と、顧客に残る義務の両方を特定している。この明確さにより、サービスが全体として複雑さを減らすかどうかを判断しやすくなる。また、成功したプロトタイプが、誰も完全には所有しないアプリケーションになることを防ぐ。
マネージドアプローチの実効性を示す3つのシグナル
次に有用となる証拠は、追加のローンチ主張ではなく、サービスの成熟度、比較結果、顧客運用に関するものだ。
最初のシグナルは、Microsoftが今後数か月でFoundryプレビューをどのように発展させるかである。購入者は、より明確な提供状況、サポートされる構成、移行オプション、本番運用ガイダンスに注目すべきだ。より広範な文書化されたサポートは、より多くのアプリケーションで共通のマネージド基盤を採用する根拠を強める。
最も意味のある拡張は、現時点で実際の導入を妨げている要件に対応するものだ。追加でサポートされる構成は、組織が技術的・事業的制約の範囲内で運用できるようになる場合に重要である。機能一覧が長くなるだけでは、特定のアプリケーションが実行可能になるかについては、あまり語らない。
プレビューの制約が顧客の想定環境にとって依然として大きい場合、その顧客にとって即時導入の根拠は弱まる。これはワークロード固有の判断である。ある制約は研究用プロトタイプには無関係でも、機密性の高い運用システムに接続するアプリケーションでは決定的になり得る。
2つ目のシグナルは、モデルの変更と実行の変更を分離する比較証拠である。評価では、どのコンポーネントが変更され、成功をどのように測定したかを明確にすべきだ。それにより購入者は、報告された利点がharness、モデル、あるいは両者の相互作用のどこから生じたのかを判断できるようになる。
独立した評価は、特に失敗カテゴリとレビュー要件を開示する場合に、信頼性を高める。完了した作業に焦点を当てた比較は、活動だけに焦点を当てた比較よりも、Microsoftの主張をより直接的に強める。構成への依存度が高いことを示す結果は、この主張をどこまで広く適用すべきかを限定する。
競合の動向も、同じ比較の中で重要である。Anthropicのマネージド提供、または他社の実行アプローチの変化は、利用可能な選択肢を変え得る。購入者は、変化する市場が評価を終わりのない機能追跡に変えないよう、安定したアプリケーション要件に照らしてサービスを比較すべきである。
3つ目のシグナルは、初期導入の速度を超えた顧客報告である。有用な事例は、継続運用、受け入れ可能な結果、修正に要する労力、顧客に残った責任を説明する。信頼できる結果とともに保守負担の低下を示す証拠は、共有実行レイヤーを購入する根拠を強める。
広範なカスタム作業に関する報告には、より慎重な読み解きが必要である。カスタマイズは、価値ある事業上の専門化を反映している場合もあれば、マネージドサービスの不足を反映している場合もある。顧客がどれだけコードを書いたかを単純に数えるよりも、どちらの説明が当てはまるかを理解することのほうが重要だ。
これらのシグナルは、以前の判断を再検討する実践的な方法も提供する。チームは、今日独自の実行システムを構築し、後からマネージドサービスを採用することも合理的にできる。別のチームはマネージドインフラから始め、その取り決めが要件を満たし続ける間だけ維持することもできる。
Microsoft Copilot harnessを、自組織が十分に理解しているワークフローで評価してください。許容できる結果を定義し、承認が必要なアクションを特定し、人による修正が依然として必要な箇所を記録します。管理型オプションと既存のアプローチを、同じ証拠と完了基準で比較してください。情報源の品質、復旧時の挙動、ミスの調査に必要な工数も含めます。判断は、チームが実際に委任可能な責任範囲に結び付け、その後、文書化されたサポート情報や顧客事例が蓄積されるにつれて見直してください。Microsoftのローンチは、実行基盤全体を社内で維持することに代わる具体的な選択肢を生み出します。次に有用なのは、その選択肢が自社のワークフローのどの部分を改善するのか、そしてどのような証拠が判断を変えるのかを明確にすることです。
