Microsoft Foundry のオートパイロットとは

autopilot は、組織の永続的な名前付きメンバーとして独自の ID で動作するエージェントの一種です。 一度に 1 つの要求に応答するのではなく、永続的な役割を果たします。 テナントには独自のセキュリティ プロファイルがあり、その役割を担うマネージャーがいます。

すべての Foundry エージェントには、作成した時点から Microsoft Entra エージェント ID があります。 autopilot が異なるのは、Entra エージェントのユーザー アカウントも持っていることです。 このアカウントは、オートパイロット独自のメール、予定表、OneDrive、Teams プレゼンス、組織図内の場所をオートパイロットに提供し、オートパイロットが自身としてMicrosoft 365アクションを実行できるようにします。

オートパイロットが存在する理由

エージェント ユーザー アカウントがない場合、エージェントは、サインインしているユーザーに代わってのみ、電子メールの送信やドキュメントの編集などのMicrosoft 365アクションを実行できます。 これは 1 対 1 のアシスタントに適していますが、2 つの一般的な状況で分解されます。

  • ループ内にユーザーがいない。 イベントによってトリガーされるエージェントには、アクションを実行するサインインユーザーがいないため、Microsoft 365アクションを実行することはできません。
  • グループ設定。 グループ チャットでは、エージェントは誰の代わりに行動を推測する必要があり、正しい答えはありません。 選択したユーザーには、そのユーザーのアクセス許可がスレッド全体に適用されます。 アクションが依頼していない人のものとして扱われたり、メンバーがアクセス権のないコンテンツを表示されてしまったりする可能性があります。

エージェント ユーザー アカウントは両方の問題を解決します。 autopilot はMicrosoft 365アクションをそれ自体として実行するため、チーム全体で一度に動作し、ユーザーが存在しないときにトリガーに応答できます。

オートパイロットを定義しないもの

オートパイロットは、多くの場合、メモリ、自律性、推論、計画、学習といった一連の能力によって説明されることがよくあります。 これらの機能は、オートパイロットでできることについて説明します。 誰が行動を行っているのかを確認するわけではありません。また、リリースごとに変更されます。 機能でカテゴリが定義されている場合、後のリリースでメモリを追加するエージェントは、それが誰であるか、何ができるか、誰がそれに答えるかについて何も変えずにオートパイロットになります。 これは機能リストで、定義ではありません。

自律性はオートパイロットも定義せず、2 つは独立しています。 バックグラウンド サービス エージェントは、一日中単独で実行でき、オートパイロットではありません。 オートパイロットは完全に自律的である必要はありません。組織は、応答するタイミング、操作できるユーザー、アクセスできる内容、実行できるアクションを制御します。

機能は、オートパイロットを説明します。 ID によって確立されます。

オートパイロットで有効にする機能

エンタープライズ作業を単独で行うことはめったにありません。 ほとんどのエンタープライズ作業は共同作業と継続的であり、チーム、会議、ドキュメント、グループ チャットにまたがっています。 Autopilot は、このような作業用に構築されています。 一度に 1 人のユーザーではなくチーム全体で作業し、メッセージを受け取ることなく行動できます。

オートパイロットはロールとそれに付随するジョブを担い、そのコンテキストはサーフェスやユーザーに関係なく、あらゆるやり取りに及びます。 Outlookで機能するように割り当て、Teams で結果を要求します。 その役割は永続的であり、アクセス許可はそれ自体であるため、定義したスコープ内に留めながら、必要なときにプロアクティブに動作できます。

アカウンタビリティには自律性が伴います。 すべてのオートパイロットには、それに回答するマネージャーがいます。これは、既に実行されているセキュリティ、プライバシー、ガバナンスの制御の対象となります。

オートパイロットと他の Foundry エージェントの比較

Autopilots とその他の Foundry エージェントは、保持している ID、それらを構築する方法、およびそれらを使用するユーザーに到達する方法が異なります。

ID モデル

通常の Foundry エージェントには、1 つのエージェント、1 つのブループリント、1 つのエージェント ID、およびエージェント ユーザー アカウントのない 1 対 1 の形状があります。 ブループリントは、エージェント ブループリント アプリケーションと、セキュリティ コンテキストと資格情報を提供するエージェント ブループリント サービス プリンシパルで構成されます。

エージェント ユーザー アカウントを使用せず、エージェント ID を 1 つだけ作成する Foundry カスタム ブループリントを示す図。

autopilot には、1 対多のシェイプがあります。1 つのブループリントと、多数の採用されたインスタンスで、各インスタンスが独自のエージェント ID 独自のエージェント ユーザー アカウントを取得します。

2 つのチーム インスタンスに採用された 1 つの Foundry ブループリントを示す図。それぞれに独自のエージェント ID とエージェント ユーザー アカウントがあります。

2 つの ID オブジェクトは異なるジョブを実行し、交換されることはありません。

Object それは何か 含まれる内容
エージェント ID サービスプリンシパル エージェント ID、エージェント名、スポンサー、およびエージェントが認証するアクセス許可。 オートパイロットの場合、この ID はエージェントを実行するインフラストラクチャをセキュリティで保護します。
エージェント ユーザー アカウント ユーザー オブジェクト Microsoft 365 内でオートパイロットを識別するための表示名、マネージャー、ユーザー プリンシパル名。

エージェントとオートパイロットの区別はバイナリです。 エージェントには独自のエージェント ユーザー アカウントがあるか、そうでないかのどちらかです。これにより、ID が信頼できる定義になります。

いずれかの種類のエージェントを作成すると、同じ方法で開始されます。Foundry では、エージェント ID ブループリントとエージェント ID が作成されます。 通常のエージェントの場合、エージェント ID は実行時にエージェントを表します。 オートパイロットの場合、エージェント ID はそのインフラストラクチャ ID として機能し、エージェント ユーザー アカウントは、Microsoft 365アクションを実行するときにオートパイロットを表します。

Foundry で構築できるエージェントの種類

Foundry は 3 種類のエージェントをサポートしており、そのうちの 1 つだけがオートパイロットです。

タイプ Identity できること 最適な用途
支援機能 サインインしたユーザー コンテキストでのエージェント ID 情報 ユーザーの代理として機能します。 そのユーザーのアクセス許可内でのみアクションを実行できます。 要求に応じてデッキを下書きする会議準備エージェントなど、個人の生産性。
バックグラウンド サービス エージェント識別子 サインインしているユーザーまたはエージェント ユーザー アカウントを使用せずに、アプリ専用のアクセス許可を通じてそれ自体として機能します。 自律的に動作することはできますが、Microsoft 365アクションを実行することはできません。 アラートに応答して仮想マシンを再起動する操作エージェントなど、アプリの自動化とバックエンド ワークフロー。
オートパイロット エージェント ID とエージェント ユーザー アカウント グループ設定を含め、Microsoft 365でそれ自体として機能します。 定義したスコープ内で自律的に動作できます。 Teams グループ チャットで作業を調整するリリース マネージャーなどのデジタル同僚。

オートパイロットではなくブループリントを構築する理由

オートパイロットはビルドしません。 チームが独自の autopilot インスタンスを作成するために使用するブループリントを作成します。それぞれに独自の ID とチーム スコープのアクセス権があります。

エージェントをビルドすると、それを 1 つのチームに直接結び付けられます。これは、役に立つアクセスがロックダウンされるのと同じアクセスであるためです。 エージェント ユーザー アカウントをチームのセキュリティ グループに追加し、プロジェクトとSharePoint サイトに付与すると、そのアクセス権がエージェントのポイントになります。 また、他の誰も再利用できないのは、自分が持つべきではないアクセス権を継承し、独自のアクセス権を構築する理由でもあります。 10 チーム後、組織にはほぼ同一のエージェントが 10 個あり、それぞれが個別に管理されています。 制御は次第にずれていき、改ざんされたツールを追跡するには、各エージェントごとに追跡しなければなりません。

すべてのチームのエージェントの再構築と、ロジックを共有しながら個別のアクセスを保持するチームごとのインスタンスを生成する 1 つのブループリントを比較した図。

ブループリントでその問題を解決します。 呼び出し可能な API など、エージェントが認識する方法と、エージェントが必要とするプラットフォーム インフラストラクチャ (追跡対象の項目とメモリのストレージなど) の 2 つを定義します。 決して付与されないのは、特定のチームのビジネス リソースへのアクセスです。 エージェントには、Azure DevOps のワークアイテムを更新し、SharePoint を読み取る機能があらかじめ備わっていますが、各マネージャーは、そのインスタンスがアクセスできる Azure DevOps プロジェクトと SharePoint サイトを決定します。 ブループリントから作成されるすべてのインスタンスには、独自の ID、アクセス許可、割り当てがあります。

その分離は実行時にも保持されます。 ツールを保持することは、その背後にあるデータへのアクセスを保持するのと同じではありません。 SharePoint ツールをオートパイロットにしても、SharePoint サイトは提供されません。また、メールボックスを指定しても、メールを送信することはできません。

ポリシーは別のガバナンス レイヤーです。 ポリシーを 1 回構成すると、すべてのインスタンスがポリシーを継承します。 ブループリントを更新すると、すべてのインスタンスも更新されます。 ブループリントをブロックし、すべてのインスタンスが停止します。

Autopilot ブループリントとして発行できるのは、Foundry でホストされているエージェントだけです。

ビルドできるオートパイロットの種類

Autopilot は3つのパターンに分かれており、それぞれ対象とするユーザーが異なります。

  • グループ オートパイロット — チームに適しています。 チームが作業する場所に存在し、チーム全体が共有するコンテキストを保持し、一度に 1 つずつサービスを提供するのではなく、ユーザー間で調整します。
  • 全社的なオートパイロット — 組織内のすべてのユーザーが一元的に管理できる機能を提供します。通常は、ビジネス プロセスごとに 1 つの運用インスタンスとして使用できます。
  • 個人用オートパイロット — 1 人のユーザーに対して、そのユーザーによって作成および使用される分離インスタンスとして機能します。