Microsoft Foundry の Autopilot ライフサイクル

autopilot は、定義されたライフサイクルを通じて移動します。 Azure管理者がプラットフォームをプロビジョニングし、開発者がブループリントをビルドして発行し、テナント管理者が承認し、マネージャーが各インスタンスを雇用して実行します。 この記事では、各ステージ、それを所有するロール、およびロール間で責任が渡されるポイントについて説明します。

オートパイロットではなくブループリントを構築しているため、ライフサイクルは 3 つのレイヤーで進行します。つまり、1 回だけ公開するブループリント、そのブループリントからチームが利用するインスタンス、そしてテナントが全体として管理するインスタンス群です。 その背後にあるモデルについては、「Microsoft Foundry のオートパイロットとは」を参照してください。

ライフサイクル ステージの概要

誰が何をするのか

4つのロールが、オートパイロットを形作る4つの意思決定を担います。 その他のロールは省略可能であり、特定のデプロイ パターンでのみ表示されます。

これら 4 人が地面だけをカバーできない場合は、さらに 2 つの役割が表示されます。

• エグゼクティブビジネススポンサーは、エグゼクティブが組織全体のオートパイロットを望み、資金を提供する場合に参加します。
• そのインスタンスを雇う人が、オートパイロットに必要な権限を付与できない場合や、最小権限を判断する立場にあるべきでない場合は、アクセスマネージャー が加わります。

これらの決定は重複せず、プラットフォームの実行内容、ブループリントの役割と機能、テナントでのオートパイロットの動作と動作方法、各インスタンスの雇用など、重要な要素はありません。 他のすべての質問は、そのうちの 1 つに解決されます。

開発者の決定は、最初に見える以上のものを対象とします。 オートパイロットが できること だけではありません。 また、オートパイロットが構築およびテストされた条件も含まれます。これは、他のすべてのロールが承認して採用するときに信頼する運用エンベロープを形成します。 オートパイロットがそのエンベロープの外側で失敗した場合、エラーはエンベロープが記載されたかどうかによって異なります。

ガバナンスと比較したアカウンタビリティ

ガバナンスは、インスタンスを停止 できる ユーザーを決定します。設計上、ほぼすべてのユーザーが実行できます。 アカウンタビリティは、誰がそれを停止する 義務を負 うのかを決定します。 誰に責任があるかにかかわらず、常に責任を負うのはマネージャーです。なぜなら、故障したオートパイロットを、マネージャーが誰かの対応を待っている間も動作させ続けるべきではないからです。

アクセスエラーは、その違いを最も明確に示しています。 アクセス マネージャーは、マネージャーが行ったことのない許可を構成し、インスタンスが原因で不適切な動作をします。 マネージャーはまだそれを停止する義務があります。 障害と義務は設計によって分離されます。

その他の参加者

2 つのグループは決定を持っていませんが、それでも重要です。

チームメンバーは、Teams、メール、ドキュメントのコメントなど、チームがすでに作業している場所で Autopilot を使用します。 彼らはそれに定常的なタスクを割り当て、そのグラウンディングを更新するための客観的な修正を加えます。

ビジネス リードとは、同じ業務に関連するその他のリードを指します。 何も構成されておらず、何も応答しませんが、インスタンスを観察してブロックすることができます。 削除または転送することはできません。 その設計は意図的です。オートパイロットの誤動作を見るのに十分な作業に近い人は、それを止めることができるようにする必要があります。 マネージャーは、オートパイロットを管理し、毎日使用する唯一の役割です。そのため、それを停止する義務は彼らに当たります。

構成された対象ユーザー以外のテナント内のすべてのユーザーは、 チームメイト以外です。 autopilot がモデルを呼び出す前に、チームメイト以外は既定でブロックされます。

デプロイ パターンによってロールが変更されるしくみ

選択した オートパイロット パターン によって、表示されるロールが決まります。

• グループ オートパイロット — すべてのロールが関係します。 このパターンでは、Azure DevOps プロジェクトを許可できるユーザーが、インスタンスで作業するチーム リーダーになることはほとんどないため、アクセス マネージャーの分割が最も重要になります。
• 全社的なオートパイロット — 組織全体を対象に、1つのインスタンスと1人のマネージャーが対応するため、「チームメイト」という区別は意味をなさなくなります。
• 個人用オートパイロット - 通常はマネージャーであり、唯一のユーザーである開発者のみが関与します。

レイヤーの合わせ方

ライフサイクルは、一度に 3 つのレイヤーで実行されます。

• ブループリント - プロビジョニングから承認まで 1 回実行されます。 承認後も、開発者の作業は、すべてのインスタンスの稼働時間に及び、ブループリントが削除されたときにのみ終了する永続的なアクティビティとして継続されます。 最適化により、新しいバージョンがビルド ステージに戻されます。
• インスタンス - 1 人の雇用ごとに 1 回実行されます。 多くのインスタンスが同時に生きているため、あるチームがインスタンスをオフボードでき、別のチームが同じブループリントから 1 つを採用します。
• Fleet はステージではありません。 これはテナント管理者が常時実行するアクティビティであり、承認された時点で開始されます。これは、その時点でフリートが存在し始めるためです。

承認は、1 つの承認されたデザインが多数のインスタンスになるポイントです。 ブループリントを削除すると、そのブループリントから作成されたすべてのインスタンスに連鎖します。

常時実行されるアクティビティは、インスタンスの各段階の後に説明されています。というのも、その時点で、それらのアクティビティが対象とする範囲が定まるためです。

1 つの例は、プラットフォーム チームによって構築され、多くのチームによって採用されたワークストリーム マネージャーというすべてのステージで実行されます。 段落の例には Example というラベル が付き、省略可能です。

ブループリント レイヤー

ブループリント ステージは 1 回実行されます。 ブループリントから作成されたすべてのインスタンスは、その結果を継承します。

インフラストラクチャのプロビジョニング — Azure 管理者と開発者

Azure管理者は環境を設定し、開発者が環境を構築、テスト、デプロイするために必要な最小限のアクセス許可を開発者に付与します。 このセットアップは、autopilot ごとではなく、環境ごとに適用されます。 これは 1 回発生し、そこに構築されたすべてのブループリントがそれを継承します。

また、Azure管理者は、追跡対象のアイテムやメモリのストレージなど、この特定のオートパイロットの実行に必要なものもプロビジョニングし、それらのリソースへのオートパイロットの組み込み ID アクセスを許可します。 このインフラストラクチャはブループリントに属し、チームのデータには属していません。 リソースのプロビジョニングとアクセス許可の割り当ては、開発者が自分で実行できないことの 2 つです。 Azure管理者は、autopilot がユーザーに到達する前に完了する唯一のロールです。作業は、開発を開始するときに行われます。

例: Contoso では、Azure管理者が Foundry アカウントとプロジェクトを設定し、モデルをデプロイします。 Azure Container Registry、Log Analytics ワークスペース、および Application Insights が、レジストリおよび Application Insights 用のプロジェクト接続とともに作成されます。 プロジェクトマネージド ID には、AcrPull と Log Analytics Reader が付与されます。 また、ダイレクト メッセージ許可リスト用と追跡対象作業項目用の 2 つのテーブルを含むストレージ アカウントも作成します。 エージェントが作成されると、その ID には Storage Table Data Contributor が割り当てられます。 各開発者には、プロジェクトをスコープとする Foundry User、レジストリをスコープとする AcrPush、および Monitoring Reader が付与されます。

ビルドと公開 — 開発者

開発者は、ブループリントの役割と能力、すなわち何をするのか、どのように振る舞うのか、いつ応答し、いつ沈黙を保ち、いつ承認を求めるのか、そして決して何をしてはならないのかを定義します。 このプラットフォームは、メモリ、ルーチン、自己改善などの基本的な機能を提供するため、開発者はそれらを構築するのではなく、それらを有効にして構成します。 開発インスタンスを使用すると、開発者は変更ごとにテナントの承認を再入力することなく反復処理できます。

公開時には、宣言されたアクセス許可のスコープと 2 つの上限も記録されます。つまり、誰がオートパイロットを起用できるか、そして後でマネージャーが付与できるアクセス権の最大範囲です。 オートパイロットが構築およびテストされた条件と共に、これらの値は、すべてのダウンストリーム ロールが信頼する運用エンベロープを形成します。

この段階では何もアクセスを許可しません。 これらの値は宣言のみです。 公開すると、ブループリントがガバナンスの対象として提示されますが、ブループリントを実際に機能させるわけではありません。

例: Contoso では、ワークストリーム マネージャーは、ID パススルー、組み込みのMicrosoft 365 ツール、およびカスタム作業項目トラッカーを使用して、Azure DevOpsツールを取得します。 応答ロジックは、チャネルでいつ話し、いつ無音のままかを決定します。 Autopilot は、未承認の参加者を含むグループ チャットを拒否し、クロステナント メッセージに対して固定の no-op 応答を返します。 公開する前に、開発者は同意が必要なスコープを宣言し、両方の天井を設定します。

承認、構成、および同意 - テナント管理者

このステージは、3 つのアクションを持つ 1 つのゲートです。 テナント管理者は、公開されたブループリントを確認し、宣言されたスコープに同意を与え、これを承認して、誰がこのブループリントを利用できるかを選択します。 同意と採用者の選択は、個別の結果を伴う個別の決定です。管理者は、要求した内容の一部のみに同意しながらブループリントを承認できます。

この段階では、オートパイロットがお使いのテナント内で動作できるかどうか、またどのポリシーに基づいて動作するかという、フリート レベルでの判断が行われます。 同意によってトークンが制御されます。これによって、オートパイロットで許可される呼び出しの種類が決まります。 チームのデータは誰にも付与されません。

新しいブループリントと拡大されたすべてのスコープがこのゲートに再び入るので、ロールアウト計画に管理者のレビュー時間を含めます。

例: Contoso では、管理者はMicrosoft 365 管理センターで保留中のワークストリーム マネージャー要求を開き、スコープ セットに同意して公開し、組織のチーム リーダーを有資格の採用者として名前を付けます。

承認により雇用が可能

承認はブループリント レイヤー全体の終了条件です。少なくとも 1 人のマネージャーがインスタンスを雇用できるようになりました。 ブループリント レイヤーとインスタンス レイヤーが出会う唯一のポイントです。 ここまでで、能力の宣言とそれへの同意を行います。 まだ何も許可されていません。 オートパイロットは、必要なすべてのスコープを保持でき、データにまったく到達しません。

インスタンス レイヤー

インスタンス ステージは、採用ごとに 1 回実行されます。 多くのインスタンスは、それぞれ独自のステージで同時に実行されます。

採用 — マネージャー

採用はフェーズではなく単一のアクションです。 次の 2 つのオブジェクトが作成されます。

• エージェント ID。これは、認証を行い、アクセス許可を保持するサービス プリンシパルです。
• メールボックス、Teams プレゼンス、組織図の場所、およびマネージャーを保持する エージェント ユーザー アカウント。

オートパイロットを採用した人がそのマネージャーになります。

例: Contoso では、3 人のチーム リーダーが同じブループリントから 3 人のワークストリーム マネージャーを雇います。 1 つのデザインが今や一連のデザインとなり、この時点から先のすべての処理は、独立して 3 回ずつ行われます。

オンボード — マネージャー

オンボーディングは、雇用が本当に始まる場所です。 マネージャーは 5 つの設定を構成します。

アクセス許可 (セキュリティ グループ メンバーシップ、Azure DevOps プロジェクト、SharePoint サイト) は、ライフサイクル内の任意の場所でビジネス リソースの最初の付与です。 彼らは、優れた設計図を実際に機能するチームメイトに変える。

各オーディエンスは、最初はマネージャー本人のみから始まり、最大で開発者レベルまで広がりますが、それを超えることはありません。 構成された対象ユーザー以外のテナント内のユーザーは既定でブロックされ、autopilot はユーザーに代わってモデルを呼び出すことはありません。

同意とアクセスは異なるゲートです。 スコープと同意によってトークンが制御され、許可される呼び出しの種類が決まります。 グループ メンバーシップとロールによってアカウントが管理され、これらの呼び出しが到達するデータが決まります。 Microsoft Entra ID は、最初の関門を強制します。 各リソースは、独自のメンバーシップ リストに対して 2 番目のゲートを適用し、同意を確認しません。 個人にとっては、IT が初出勤の前の段階の時点で、この両方の扉を閉ざしてしまいます。 オートパイロットの場合、採用時には両方のゲートが新規に導入されるため、オンボーディングには「本来ならすでに完了しているはず」と思われる作業が含まれてしまいます。

承認はここから始まりますが、完了することはありません。 チームは変わり、リソースも変わり、付与された権限は取り消されます。 Autopilot では、最終的に採用時には誰も想定していなかった SharePoint サイトが必要になります。

採用者がこれらの付与を行えない場合、ステージは分割されます。 マネージャーは、多くの場合、セキュリティ グループまたはAzure DevOps組織にアカウントを追加する権限を保持していないナレッジ ワーカーであり、最小限の特権は、ほとんどのチーム リーダーが行う必要のないセキュリティ判断です。 代わりに、アクセス マネージャーは、インスタンスを雇用、オンボード、承認し、そのインスタンスを使用するリーダーにマネージャー ロールを転送します。 雇用の決定自体は動きません。

例: Contoso では、あるリードが担当するワークストリームのメンバーをチームメイトに設定し、エンジニアリング リードとプロダクト リードをビジネス リードに設定します。 チームのセキュリティ グループと配布リストにエージェント アカウントを追加します。これは、Azure DevOps プロジェクトとSharePoint サイトに付与されるものであり、GitHub組織への書き込みアクセス権を付与します。 別のチームでは、リードはAzure DevOps プロジェクトを許可できないため、アクセス マネージャーがインスタンスをオンボードし、マネージャーロールを引き渡します。

運用 — マネージャー、チームメイト、ビジネス リーダー

インスタンスが存在する限り、4 つのアクティビティが同時に実行され、各アクティビティには異なるロールのセットが含まれます。

使用対象 — 同僚とマネージャー オートパイロットは、Teams ダイレクト メッセージ、グループ チャットとチャネル、電子メール、ドキュメント コメントなど、構成されたサーフェイス全体でその役割を実行します。 そのコンテキストは、サーフェスやユーザーに関係なく、すべての操作にまたがっています。 チームメイトはルーチンを割り当てます。ルーチンは、1 つのメッセージで提供される永続的な指示です。

観察 — マネージャーと事業責任者。 彼らは、インスタンスが何をしたか、誰のために、どのようなコストで、そして何かが調査する必要があるかどうかを確認します。 日々の説明責任はここで起こります。

統括する — マネージャーと業務部門の責任者。 これらの制御はすべて元に戻すことができます。アクセスの強化、アクセスの取り消し、インスタンスのブロックなどです。 何かを観察した結果としてブロックを行うのですから、制御は観察に基づいて行われます。 ブロックは意図的に非対称です。 問題を確認するのに十分な作業に近いユーザーは、インスタンスを停止できますが、もう一度開始できるのはテナント管理者だけです。

指導とカスタマイズ — 管理者。 改善は、2 つの等しくないチャネルを通じて到着します。 日付のずれや担当者の誤りといった客観的な修正は、そのインスタンスに関わる人であれば誰からでも寄せることができ、インスタンスの根拠情報を更新します。 コーチングとカスタマイズ――スタイル、メモリの編集、形成ルーチン――はマネージャーのみが担うため、競合は自動的に解消され、マネージャーが設定した内容が優先されます。 コーチングは、1 つのチームのオートパイロットを変更します。 開発者がブループリントを最適化すると、すべてのインスタンスの内容が変更 されます。

例: Contoso では、チームメイトはそれぞれ、金曜日の内部要約、リードが承認するまで未送信の外部の週次ドラフト、およびすべての所有者に開いているアイテムをメンションするエンド オブ デイ ダイジェストという単一のメッセージで作業を設定します。 マネージャーは、インスタンスの最近のアクティビティを確認します。 インスタンスが要約をまとめの中で度々埋もれさせてしまう場合、責任者が一度指導することで、その新しいスタイルが定着します。

インスタンスを管理対象から削除 — マネージャー

オフボーディングは、唯一の不可逆なインスタンス操作です。 エージェント ユーザー アカウントが削除され、そのメンバーシップが取り消され、そのアクセスが直ちに終了します。 影響を受けるチームは 1 つだけで、他のインスタンスは影響を受けなくなります。 何も復元できません。

決定はマネージャーに属しており、インスタンスがまだ実行を正当化するのに十分な値を提供するかどうかという、他の誰もできない判断の 1 つです。 管理者はフリート全体のシグナルに基づいて対応できますが、個々のインスタンスが引き続きそのコストに見合う価値を生み出しているかどうかを見極めることはできません。 オフボーディングは、運用段階における管理策を強化したものではありません。 すべてのコントロールは元に戻すことができますが、オフボードはできません。これが別のステージである理由です。

例: Contoso では、あるワークストリームが完了し、その担当者が当該インスタンスからオフボードしました。 そのメンバーシップは取り消されます。 他の 2 つのワークストリーム マネージャーは影響を受けません。

現行のブループリントとフリート活動

2 つのアクティビティは、各インスタンスのライフサイクル全体を通じて行われます。すなわち、開発者によるブループリントの運用と、テナント管理者によるフリートの管理です。

ブループリントを操作する - 開発者

開発者は、ブループリントを管理、観察、評価、および最適化します。 既定では、プライベートな会話の内容を受け取ることなく、本番環境へのデプロイを監視できます。 バージョン別とインスタンス別にテレメトリをフィルター処理してロールアウトを監視し、autopilot が構築およびテストされた操作エンベロープに対して評価を実行します。 修正は新しいバージョンとして提供され、すべてのインスタンスに行き渡ります。

スコープを広げる新しいバージョンでは、ガバナンスはバイパスされません。 アクセス許可が追加されたため、同意画面が再表示されます。 ゲートは変更自体ではなく上限に対して適用されるため、テナント管理者の決定は一時的なものではなく継続的なものになります。

開発者はブループリント レベルのガバナンスも保持します。 自分たちが出荷したブループリントをブロックすることはできますが、他の人と同様に、それを解除することはできません。 この活動をマネージャーの指導と混同しないでください。 開発者は、すべてのインスタンス の内容を変更します。 マネージャーは、1 つのインスタンス の動作を変更します。

フリート管理 — テナント管理者

テナント管理者は、ブルー プリントが承認段階に入った時点から、フリートの監視、管理、およびセキュリティ確保を行います。 1 つのレジストリには、チーム、ブループリント、バージョンを持つすべての採用者と、その ID に起因するすべてのアクションが一覧表示されます。 管理者はシステム内で最も幅広い制御を保持します。ブループリントをブロックすると、すべてのインスタンス トークンがブループリントの資格情報にチェーンバックされるため、すべてのインスタンスが一度に停止します。

このコントロールには、ブループリントの失敗方法が反映されます。 ブループリントの欠陥は常に全身的です。 ワークストリーム マネージャーがテナントの外部で電子メールを送信した場合、それは 1 つのチームのインスタンスの不適切な動作ではありません。 すべてのインスタンスは同じ欠陥を抱え、同じ条件がそろうのを待っています。 ブロックはブループリントに適用され、誰かが気付いたインスタンスには適用されません。

ブループリントの廃止と削除 - テナント管理者と開発者

ブループリントには 2 つの出口があります。

• 廃止 — テナント管理者は新規採用を停止し、アクティブなインスタンスが残っていない場合はブループリントが終了します。 廃止すると、現在のインスタンスに影響を与えることなく、将来の採用を防ぐことができます。
• 削除 — ブループリントから作成されたすべてのインスタンスが、そのブループリントと共に削除されます。 Delete は、単一のインスタンスをマネージャーがオフボーディングすることに相当する、ブループリント レイヤーでの操作です。

その違いは、ライフサイクル全体を整理する線です。 運転段階および待機アクティビティのすべての操作は取り消すことができます。 ブルー プリントは削除できません。

関連するコンテンツ

• Microsoft Foundry のオートパイロットとは何ですか。ID モデルと、オートパイロットでブループリントが使用される理由について説明します。
• クイック スタート: 最初の autopilot の構築 では、最初のインスタンスのプロビジョニング、ビルド、発行、承認、採用について説明します。
• Microsoft Agent 365 と Foundry の統合には、レジストリの同期、データ収集、データ所在地が含まれます。