MicrosoftはGitHub由来のエージェント実行基盤をFoundryで提供します。SDKとクラウド実行を案内し、モデル選択と実行環境をまとめて扱います。 自前で維持する部分と管理サービスへ任せる部分の整理が焦点です。モデル変更後も権限、実行履歴、費用を業務単位で評価する必要があります。 モデルの周囲にある実行基盤を共通化 Microsoftは10月28日、Microsoft Copilot harnessをFoundryで提供すると発表しました。GitHubのチームが開発し、同社のCopilot製品でも採用している仕組みです。モデルに指示、文脈、ツール、実行環境を与える層を共通化します。SDKの利用と、Foundryが管理するクラウド実行が案内されています。モデル自体の新発表ではなく、複数のモデルを実際の作業へ接続する基盤の提供です。能力の変化が速い中で、接続先を変えるたびに周辺の仕組みを作り直す負担を減らす狙いがあります。既存製品での利用実績と、自社の業務に適合するかは別に確認する必要があると見られます。 開発者が持ち込む指示とツールは残る 発表では20以上の先端モデルと、利用者自身のAPIキーへの対応を説明しています。MCP、Agent Skills、プラグインなどの標準や拡張も対象です。Microsoftがエージェントのループとサンドボックスを運用し、利用者は指示、スキル、ツール、モデル選択を用意する構図です。このため企業の開発者にとっては、実行基盤の保守作業が変わる可能性があります。一方で、業務に必要なデータや操作権限の設計まで自動的に完成するわけではありません。モデルごとに得意な処理や出力形式が違う場合、ルーティングの判断が品質に影響すると見られます。既存のツールをつなぐ際には、誰の資格情報で何を実行するのかが論点になります。共通基盤の更新が複数の業務へ及ぼす範囲も把握する必要があります。 保守の移管と評価の責任を分けて考える MicrosoftはランタイムをRustへ移したことや、セッションの負担と初回応答までの時間の改善を説明しています。ただし記事には、個々の業務での料金や応答時間を保証する値はありません。導入側では、従来の実装に掛かっていた維持費と、管理サービスで発生する利用費を同じ工程で比べることが考えられます。モデルの切り替えが容易になっても、結果の確認を省けるとは限りません。失敗した操作の記録、再開の手順、外部システムへの書き込み前の確認が実務上の論点になります。既存のフレームワークも持ち込めるという説明を踏まえ、移行する範囲を限定した検証が判断材料になると見られます。基盤の性能向上と、自社で必要な統制が満たされるかを合わせて見ることが焦点です。 共通更新の影響を追えるか 運用開始後は、実行基盤とモデルのどちらが変わったかを追えることが確認点になります。同じ指示でも周辺の仕組みの更新で挙動が変わる可能性があります。更新前後の記録を残せば、問題が起きた際に原因を絞る手掛かりになると見られます。利用者へ返す結果に失敗した工程を含められるかも、実際のサービスで確かめる余地があります。基盤を共有する利点を生かすには、業務側で受け入れる出力の条件を明確にすることが次の課題と考えられます。