Microsoft Copilot Studio、Agentsを獲得し、旧App Modelを失う

Microsoft Copilot Studio は、以前のアプリモデルよりもエージェントを強調するようになりました。この変更は、自動化に関するより大きな主張への推進を示しています。同時に、基盤となるエンタープライズソフトウェアは依然として実際の作業プロセスとデータルートを制御しています。

この動きは、Microsoft がエージェントをビジネス業務の次のレイヤーとして推進する中で到来しました。チームはスタジオ内でエージェントを構築し、以前は別々のアプリを必要としたステップを処理できます。これらのエージェントは、SharePoint、Dynamics、および古い業務システムなどの既存システムからデータを引き出すコネクタに依存しています。

このセットアップは緊張を生み出します。エージェントは計画と実行を行う柔軟なヘルパーとして提示されます。実際には、エージェントはホストシステムによってすでに設定された権限、データモデル、および統合制限を継承します。古いスタックがアクションを制限する場合、エージェントは停止するか不完全な結果を返します。

Microsoft Copilot Studio のエージェントは、事前定義されたコネクタと Power Automate フローを通じて動作します。スタジオは、これらのエージェントを作成するためのテンプレートとドラッグアンドドロップインターフェースを提供します。各エージェントは、Microsoft 365 サービスおよび承認されたサードパーティエンドポイント全体でアクションを呼び出すことができます。

エージェントレイヤーはソースアプリケーションを置き換えません。エージェントは上に位置し、それらのアプリケーションが強制するルールに従います。顧客レコードの更新を求められたエージェントは、顧客関係データベースで定義されたセキュリティロールを依然として尊重する必要があります。それらのロールがフィールドをブロックする場合、エージェントは要求を完了できません。

エンタープライズ顧客はすでに Dynamics および SharePoint 内で数千のカスタムワークフローを実行しています。これらのワークフローは長年にわたって構築され、監査証跡、承認、およびコンプライアンス設定を保持しています。同じデータに到達するエージェントは、それらをバイパスするのではなく、同じ制約を継承します。

エージェントがエンドツーエンドの作業を処理するという約束は、既存の権限構造と衝突します。Microsoft はエージェントをツール全体で推論できると説明しています。ドキュメントでは、エージェントがタスクをステップに分割し、複数のサービスを順番に呼び出すことができると述べています。しかし、各呼び出しは人間のユーザーが使用するのと同じ ID および承認レイヤーを通過します。

セキュリティチームは、エージェントの権限をサービスアカウントのレビューと同じ方法でレビューします。要求が部門の境界を越えたり、規制されたデータに触れたりする場合、エージェントは依然として明示的な許可を必要とします。これらの許可は、エージェントビルダーではなく元のシステム管理者によって管理されたままです。

アナリストは、このアーキテクチャが予期しない失敗を減らすと指摘しています。また、人間の介入なしにエージェントが真に完了できるタスクの範囲も制限します。承認ステップがレガシープロセス内にある場合、エージェントは確立されたチャネルを通じてそのステップが完了するのを一時停止して待つ必要があります。

ServiceNow や Salesforce などの競合プラットフォームも同様の制限に直面しています。これらもコアデータモデルと承認エンジンに基づくエージェントスタイルのインターフェースを公開しています。違いはマーケティングの強調にあります。Microsoft はスタジオを、どのユーザーでも拡張できる汎用エージェントビルダーとして位置づけています。技術的な現実では、すべてのベンダーが維持する基盤プラットフォームへの同じ依存が示されています。

独立したオブザーバーは、真のエージェント自律性には生データストアへの直接アクセスとビジネスルールをオーバーライドする能力が必要になると指摘しています。そのレベルのアクセスを許可する組織はほとんどありません。代わりに、組織は現在のソフトウェア資産のためにすでに交渉済みのガードレール内にエージェントを保持しています。

古いアプリモデルからの移行は、したがって制御よりもインターフェースと言語をより多く変更します。ビルダーは、別々のアプリケーション間を移動する代わりに単一のスタジオで作業するようになりました。彼らが作成するエージェントは、依然として同じテーブルとレコードから読み書きします。複数の承認またはクロスシステムハンドオフを必要としたプロセスは、それらの要件をそのまま保持します。

初期のエージェントテンプレートをテストしているチームは、1つのシステム内の単純なタスクは迅速に動作すると報告しています。メール、ドキュメントライブラリ、および外部 ERP システムにまたがるタスクは、多くの場合、エージェントが少なくとも1回は人間にハンドオフする必要があります。スタジオは、管理者が各ハンドオフを追跡できるようにログを提供します。

残る質問の1つは、Microsoft が今後数四半期でコネクタのカバレッジをどのように進化させるかです。新しいエージェントが Microsoft 以外のソースからのデータを必要とする場合、同社は承認されたエンドポイントを拡張するか、同じセキュリティモデル下でカスタム API 呼び出しを許可する必要があります。これらの拡張なしでは、エージェントは元の約束がより広い範囲を示唆していたとしても、Microsoft エコシステム内に留まります。

IT リーダーは2つのシグナルを注視しています。まず、Microsoft が Dynamics および SharePoint の外部に大規模に到達するコネクタを追加するかどうか。次に、エージェントからの監査ログが追加のマッピング作業なしで現在のコンプライアンスフレームワークを満たすかどうかです。両方のシグナルは、エージェントレイヤーがデモンストレーションから日常的な本番利用に移行できるかどうかを示します。