Azure 管理グループとはWhat are Azure management groups?

組織に多数のサブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがあります。If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure 管理グループの範囲は、サブスクリプションを上回ります。Azure management groups provide a level of scope above subscriptions. "管理グループ" と呼ばれるコンテナーにサブスクリプションを整理して、管理グループに管理条件を適用できます。You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。All subscriptions within a management group automatically inherit the conditions applied to the management group. 管理グループを使うと、サブスクリプションの種類に関係なく、大きな規模でエンタープライズ レベルの管理を行うことができます。Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. 単一の管理グループ内のすべてのサブスクリプションは、同じ Azure Active Directory テナントを信頼する必要があります。All subscriptions within a single management group must trust the same Azure Active Directory tenant.

たとえば、仮想マシン (VM) の作成に使えるリージョンを制限するポリシーを管理グループに適用できます。For example, you can apply policies to a management group that limits the regions available for virtual machine (VM) creation. そのリージョンでの VM の作成を許可するだけで、その管理グループの下にあるすべての管理グループ、サブスクリプション、リソースに、このポリシーが適用されます。This policy would be applied to all management groups, subscriptions, and resources under that management group by only allowing VMs to be created in that region.

管理グループとサブスクリプションの階層Hierarchy of management groups and subscriptions

管理グループとサブスクリプションの柔軟な構造を作成し、リソースを階層に整理して、統一されたポリシーとアクセス管理を適用できます。You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. 次の図は、管理グループを使用した管理のための階層を作成する例を示します。The following diagram shows an example of creating a hierarchy for governance using management groups.

サンプル管理グループの階層の図。

管理グループとサブスクリプションの両方を包含しているルート管理グループの図。Diagram of a root management group holding both management groups and subscriptions. 一部の子管理グループは管理グループを包含し、一部はサブスクリプション、一部はその両方を包含しています。Some child management groups hold management groups, some hold subscriptions, and some hold both. サンプル階層の例の 1 つは、子レベルがすべてサブスクリプションである、4 つのレベルの管理グループです。One of the examples in the sample hierarchy is four levels of management groups with the child level being all subscriptions.

ポリシーを適用する階層を作成できます。たとえば、"運用" というグループの VM の場所を米国西部リージョンに制限できます。You can create a hierarchy that applies a policy, for example, which limits VM locations to the US West Region in the group called "Production". このポリシーは、その管理グループの子孫であるすべての Enterprise Agreement (EA) サブスクリプションに継承され、それらのサブスクリプションの下にあるすべての VM に適用されます。This policy will inherit onto all the Enterprise Agreement (EA) subscriptions that are descendants of that management group and will apply to all VMs under those subscriptions. このセキュリティ ポリシーは、ガバナンスを改善するためにリソースまたはサブスクリプションの所有者が変更することができません。This security policy cannot be altered by the resource or subscription owner allowing for improved governance.

管理グループを使用するもう 1 つのシナリオは、ユーザーに複数のサブスクリプションへのアクセスを提供する場合です。Another scenario where you would use management groups is to provide user access to multiple subscriptions. その管理グループの下で複数のサブスクリプションを移動することで、管理グループ上に 1 つの Azure ロール割り当てを作成することができます。これにより、すべてのサブスクリプションへのアクセスが継承されます。By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group, which will inherit that access to all the subscriptions. さまざまなサブスクリプションに Azure RBAC を割り当てるスクリプトを作成しなくても、管理グループへ 1 つ割り当てることで、ユーザーは必要なものすべてにアクセスできます。One assignment on the management group can enable users to have access to everything they need instead of scripting Azure RBAC over different subscriptions.

管理グループに関する重要な事実Important facts about management groups

  • 1 つのディレクトリでは、10,000 個の管理グループをサポートできます。10,000 management groups can be supported in a single directory.
  • 管理グループのツリーは、最大 6 レベルの深さをサポートできます。A management group tree can support up to six levels of depth.
    • この制限には、ルート レベルまたはサブスクリプション レベルは含まれません。This limit doesn't include the Root level or the subscription level.
  • 各管理グループとサブスクリプションは、1 つの親のみをサポートできます。Each management group and subscription can only support one parent.
  • 各管理グループには、多数の子を含めることができます。Each management group can have many children.
  • すべてのサブスクリプションと管理グループは、各ディレクトリの 1 つの階層内に存在します。All subscriptions and management groups are within a single hierarchy in each directory. ルート管理グループに関する重要な事実」を参照してください。See Important facts about the Root management group.

各ディレクトリのルート管理グループRoot management group for each directory

各ディレクトリには、"ルート" 管理グループと呼ばれる 1 つの最上位管理グループがあります。Each directory is given a single top-level management group called the "Root" management group. このルート管理グループは階層に組み込まれており、すべての管理グループとサブスクリプションはルート管理グループにまとめられます。This root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. ルート管理グループにより、グローバル ポリシーと Azure ロールの割り当てをディレクトリ レベルで適用できます。This root management group allows for global policies and Azure role assignments to be applied at the directory level. Azure AD 全体管理者は自分自身を昇格させて、最初にこのルート グループのユーザー アクセス管理者ロールにする必要があります。The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. アクセス権の昇格後、管理者は、任意の Azure ロールを他のディレクトリ ユーザーまたはグループに割り当てて階層を管理することができます。After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. 管理者の場合は、自分のアカウントをルート管理グループの所有者として割り当てることができます。As administrator, you can assign your own account as owner of the root management group.

ルート管理グループに関する重要な事実Important facts about the Root management group

  • 既定では、ルート管理グループの表示名は Tenant root group です。By default, the root management group's display name is Tenant root group. ID は Azure Active Directory ID です。The ID is the Azure Active Directory ID.
  • 表示名を変更するには、ルート管理グループの所有者または共同作成者ロールを自分のアカウントに割り当てる必要があります。To change the display name, your account must be assigned the Owner or Contributor role on the root management group. 管理グループの名前を更新するには、「管理グループの名前を変更する」を参照してください。See Change the name of a management group to update the name of a management group.
  • 他の管理グループと異なり、ルート管理グループを移動または削除することはできません。The root management group can't be moved or deleted, unlike other management groups.
  • すべてのサブスクリプションと管理グループは、ディレクトリ内の 1 つのルート管理グループにまとめられます。All subscriptions and management groups fold up to the one root management group within the directory.
    • ディレクトリ内のすべてのリソースは、グローバル管理用のルート管理グループにまとめられます。All resources in the directory fold up to the root management group for global management.
    • 既定では、新しいサブスクリプションは作成時に自動的にルート管理グループに設定されます。New subscriptions are automatically defaulted to the root management group when created.
  • すべての Azure ユーザーはルート管理グループを表示できますが、すべてのユーザーがルート管理グループを管理するアクセス権を持つわけではありません。All Azure customers can see the root management group, but not all customers have access to manage that root management group.
    • サブスクリプションへのアクセス権を持つすべてのユーザーは、階層内にそのサブスクリプションが存在するコンテキストを参照できます。Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.
    • 既定では、ルート管理グループには誰もアクセスできません。No one is given default access to the root management group. Azure AD 全体管理者は、自分自身を昇格させてアクセス権を取得できる唯一のユーザーです。Azure AD Global Administrators are the only users that can elevate themselves to gain access. ルート管理グループへのアクセス権を取得した全体管理者は、他のユーザーが管理できるように任意の Azure ロールを割り当てることができますOnce they have access to the root management group, the global administrators can assign any Azure role to other users to manage
      it.
  • SDK では、ルート管理グループ ("Tenant Root") が管理グループとして機能します。In SDK, the root management group, or 'Tenant Root', operates as a management group.

重要

ルート管理グループでのユーザーのアクセス権またはポリシーの割り当ては、ディレクトリ内のすべてのリソースに適用されますAny assignment of user access or policy assignment on the root management group applies to all resources within the directory. そのため、すべてのユーザーは、このスコープで定義されている項目を所有する必要性を評価する必要があります。Because of this, all customers should evaluate the need to have items defined on this scope. ユーザーアクセスやポリシーの割り当ては、このスコープでのみ "必須" である必要がありますUser access and policy assignments should be "Must Have" only at this
scope.

管理グループの初期セットアップInitial setup of management groups

ユーザーが管理グループの使用を開始する際には、初期セットアップ プロセスが発生します。When any user starts using management groups, there's an initial setup process that happens. 最初の手順として、ディレクトリでルート管理グループが作成されます。The first step is the root management group is created in the directory. このグループが作成されると、ディレクトリ内に存在するすべての既存のサブスクリプションがルート管理グループの子になります。Once this group is created, all existing subscriptions that exist in the directory are made children of the root management group. このプロセスが実行される理由は、ディレクトリ内に管理グループ階層が 1 つだけ存在するようにするためです。The reason for this process is to make sure there's only one management group hierarchy within a directory. ディレクトリ内に 1 つの階層が存在することにより、ディレクトリ内の他のユーザーがバイパスできないグローバル アクセス権とポリシーを管理ユーザーが適用できるようになります。The single hierarchy within the directory allows administrative customers to apply global access and policies that other customers within the directory can't bypass. ルートに割り当てられている内容はすべて、階層全体に適用されます。これには、この Azure AD テナント内におけるすべての管理グループ、サブスクリプション、リソース グループ、リソースが含まれます。Anything assigned on the root will apply to the entire hierarchy, which includes all management groups, subscriptions, resource groups, and resources within that Azure AD Tenant.

サブスクリプションの表示の問題Trouble seeing all subscriptions

2018 年 6 月 25 日より前のプレビューで初期に管理グループの使用を開始した数個のディレクトリでは、一部のサブスクリプションが階層内にないという問題が発生していました。A few directories that started using management groups early in the preview before June 25 2018 could see an issue where not all the subscriptions were within the hierarchy. すべてのサブスクリプションを階層に含めるプロセスは、ディレクトリ内のルート管理グループに対してロールまたはポリシーの割り当てが行われた後に導入されました。The process to have all subscriptions in the hierarchy was put in place after a role or policy assignment was done on the root management group in the directory.

この問題を解決する方法How to resolve the issue

この問題を解決するためのオプションは 2 つあります。There are two options you can do to resolve this issue.

  • ルート管理グループからすべてのロールとポリシーの割り当てを削除しますRemove all Role and Policy assignments from the root management group
    • ルート管理グループからすべてのポリシーとロールの割り当てを削除することによって、次の夜間サイクルで、すべてのサブスクリプションがサービスにより階層にバックフィルされます。By removing any policy and role assignments from the root management group, the service backfills all subscriptions into the hierarchy the next overnight cycle. このプロセスの目的は、テナントのサブスクリプションに誤ってアクセスやポリシーの割り当てが行われないようにすることです。This process is so there's no accidental access given or policy assignment to all of the tenants subscriptions.
    • サービスに影響を与えずにこのプロセスを実行する最善の方法として、ルート管理グループの 1 つ下のレベルのロールまたはポリシー割り当てを適用します。The best way to do this process without impacting your services is to apply the role or policy assignments one level below the Root management group. 次に、ルート スコープからすべての割り当てを削除します。Then you can remove all assignments from the root scope.
  • API を直接呼び出して、バックフィル プロセスを開始しますCall the API directly to start the backfill process
    • ディレクトリ内の任意のユーザーは、TenantBackfillStatusRequest API または StartTenantBackfillRequest API を呼び出すことができます。Any customer in the directory can call the TenantBackfillStatusRequest or StartTenantBackfillRequest APIs. StartTenantBackfillRequest API が呼び出されると、すべてのサブスクリプションを階層に移動する初期セットアップ プロセスが開始されます。When the StartTenantBackfillRequest API is called, it kicks off the initial setup process of moving all the subscriptions into the hierarchy. このプロセスでは、すべての新しいサブスクリプションが強制的にルート管理グループの子になります。This process also starts the enforcement of all new subscription to be a child of the root management group. このプロセスを実行するには、ルート レベルで割り当てを変更する必要があります。This process can be done without changing any assignments on the root level. この API を呼び出すことで、ルートに対するポリシーまたはアクセスの割り当てをすべてのサブスクリプションに適用できることを示します。By calling the API, you're saying it's okay that any policy or access assignment on the root can be applied to all subscriptions.

このバックフィル プロセスについて質問がある場合は、managementgroups@microsoft.com までお問い合わせください。If you have questions on this backfill process, contact: managementgroups@microsoft.com

管理グループ アクセスManagement group access

Azure 管理グループでは、すべてのリソース アクセスとロール定義について、Azure のロールベースのアクセス制御 (Azure RBAC) がサポートされます。Azure management groups support Azure role-based access control (Azure RBAC) for all resource accesses and role definitions. これらのアクセス許可は、階層内に存在する子リソースに継承されます。These permissions are inherited to child resources that exist in the hierarchy. 管理グループには任意の Azure ロールを割り当てることができます。ロールは階層を継承し、各リソースに割り当てられます。Any Azure role can be assigned to a management group that will inherit down the hierarchy to the resources. たとえば、VM 共同作成者の Azure ロールは、管理グループに割り当てることができます。For example, the Azure role VM contributor can be assigned to a management group. このロールには、管理グループに対するアクションはありませんが、その管理グループに属するすべての VM に継承されます。This role has no action on the management group, but will inherit to all VMs under that management group.

次の図に、管理グループのロールとサポートされているアクションの一覧を示します。The following chart shows the list of roles and the supported actions on management groups.

Azure ロール名Azure Role Name 作成Create [名前の変更]Rename 移動**Move** 削除Delete アクセス権の割り当てAssign Access ポリシーの割り当てAssign Policy ReadRead
所有者Owner XX XX XX XX XX XX XX
ContributorContributor XX XX XX XX XX
MG Contributor*MG Contributor* XX XX XX XX XX
ReaderReader XX
MG Reader*MG Reader* XX
リソース ポリシー共同作成者Resource Policy Contributor XX
User Access AdministratorUser Access Administrator XX XX

*:MG Contributor と MG Reader は、管理グループのスコープのみでのこれらのアクションの実行をユーザーに許可します。*: MG Contributor and MG Reader only allow users to do those actions on the management group scope.
**: ルート管理グループに対するロールの割り当ては、それとの間でのサブスクリプションまたは管理グループの移動に必要ありません。**: Role Assignments on the Root management group aren't required to move a subscription or management group to and from it. 階層内の項目の移動について詳しくは、「Manage your resources with management groups (管理グループを使用してリソースを管理する)」を参照してください。See Manage your resources with management groups for details on moving items within the hierarchy.

Azure カスタム ロールの定義と割り当てAzure custom role definition and assignment

管理グループに対する Azure カスタム ロールのサポートは、現在プレビュー段階にあり、いくつかの制限事項があります。Azure custom role support for management groups is currently in preview with some limitations. 管理グループのスコープは、"ロールの定義" の割り当て可能なスコープで定義できます。You can define the management group scope in the Role Definition's assignable scope. その後、その Azure カスタム ロールを、当該の管理グループと、その下にあるすべての管理グループ、サブスクリプション、リソース グループ、またはリソースに割り当てることができるようになります。That Azure custom role will then be available for assignment on that management group and any management group, subscription, resource group, or resource under it. あらゆる組み込みロールと同様、このカスタム ロールも階層に沿って継承されます。This custom role will inherit down the hierarchy like any built-in role.

定義の例Example definition

カスタム ロールの定義と作成は、管理グループを追加しても変化することはありません。Defining and creating a custom role doesn't change with the inclusion of management groups. 管理グループは、完全パスを使用して定義します ( /providers/Microsoft.Management/managementgroups/{groupId} )。Use the full path to define the management group /providers/Microsoft.Management/managementgroups/{groupId}.

管理グループの表示名ではなく、管理グループの ID を使用してください。Use the management group's ID and not the management group's display name. どちらも管理グループを作成する際にカスタムで定義されるフィールドであるため、このエラーがよく見られます。This common error happens since both are custom-defined fields when creating a management group.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id", 
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementgroups/delete",
    "Microsoft.Management/managementgroups/read",
    "Microsoft.Management/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

ロールの定義を割り当ての階層パスから切り離すことによって生じる問題Issues with breaking the role definition and assignment hierarchy path

ロールの定義は、管理グループの階層の範囲内であれば、どこでも割り当てることができます。Role definitions are assignable scope anywhere within the management group hierarchy. ロールの定義は親管理グループに対して定義できますが、実際のロールの割り当てが存在するのは子のサブスクリプションです。A role definition can be defined on a parent management group while the actual role assignment exists on the child subscription. この 2 つの項目間には関係があるため、割り当てをその定義から切り離そうとするとエラーが発生します。Since there's a relationship between the two items, you'll receive an error when trying to separate the assignment from its definition.

実際に見た方がわかりやすいので、ある階層のごく一部分を例に見てみましょう。For example, let's look at a small section of a hierarchy for a visual.

サンプル管理グループの階層のサブセットの図。

この図では、子の IT およびマーケティング管理グループを持つルート管理グループに焦点を当てています。The diagram focuses on the root management group with child I T and Marketing management groups. IT 管理グループには、運用環境という名前の子マネージメント管理グループが 1 つありますが、マーケティング管理グループには無料試用版の子サブスクリプションが 2 つあります。The I T management group has a single child management group named Production while the Marketing management group has two Free Trial child subscriptions.

Marketing 管理グループに定義されたカスタム ロールがあるとします。Let's say there's a custom role defined on the Marketing management group. その後、そのカスタム ロールが 2 つの無料試用版サブスクリプションに割り当てられています。That custom role is then assigned on the two free trial subscriptions.

そのいずれかのサブスクリプションを Production 管理グループの子に移動しようとすると、サブスクリプションに対するロールの割り当てから Marketing 管理グループに対するロールの定義へのパスが断ち切られてしまいます。If we try to move one of those subscriptions to be a child of the Production management group, this move would break the path from subscription role assignment to the Marketing management group role definition. このシナリオでは、その関係が壊れるため移動は許可されないという内容のエラーが発生します。In this scenario, you'll receive an error saying the move isn't allowed since it will break this relationship.

このシナリオを解決するためには、いくつかの選択肢があります。There are a couple different options to fix this scenario:

  • サブスクリプションからロールの割り当てを削除した後で、サブスクリプションを新しい親管理グループに移動します。Remove the role assignment from the subscription before moving the subscription to a new parent MG.
  • "ロールの定義" の割り当て可能なスコープにサブスクリプションを追加します。Add the subscription to the Role Definition's assignable scope.
  • ロールの定義内の割り当て可能なスコープを変更します。Change the assignable scope within the role definition. 上の例では、階層の両方の分岐から定義に到達できるよう、割り当て可能なスコープを Marketing から Root Management Group に更新することができます。In the above example, you can update the assignable scopes from Marketing to Root Management Group so that the definition can be reached by both branches of the hierarchy.
  • もう一方の分岐の中で定義するカスタム ロールを新たに作成します。Create another Custom Role that is defined in the other branch. 新しいロールを使用するためには、サブスクリプションに対するロールの割り当ても変更する必要があります。This new role requires the role assignment to be changed on the subscription also.

制限事項Limitations

管理グループでカスタム ロールを使用する際には制限事項があります。There are limitations that exist when using custom roles on management groups.

  • 新しいロールの割り当て可能なスコープに定義できる管理グループは 1 つだけです。You can only define one management group in the assignable scopes of a new role. この制限は、ロールの定義とロールの割り当てが切り離される状況の発生回数を減らすために設けられています。This limitation is in place to reduce the number of situations where role definitions and role assignments are disconnected. この状況は、ロールを割り当てたサブスクリプションまたは管理グループが、そのロールの定義が存在しない別の親に移動されると発生します。This situation happens when a subscription or management group with a role assignment moves to a different parent that doesn't have the role definition.
  • 管理グループのカスタム ロールでリソース プロバイダー データ プレーンのアクションを定義することはできません。Resource provider data plane actions can't be defined in management group custom roles. この制限は、データ プレーン リソースプロバイダーを更新する際の待ち時間の問題があるために設けられています。This restriction is in place as there's a latency issue with updating the data plane resource providers. この待ち時間の問題は現在対応中であり、これらのアクションは、リスクを軽減するためにロールの定義では無効にされる予定です。This latency issue is being worked on and these actions will be disabled from the role definition to reduce any risks.
  • ロールの定義の割り当て可能なスコープに管理グループが存在するかどうかは、Azure Resource Manager では確認されません。The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. 入力ミスや間違った管理グループ ID が記載されていても、ロールの定義は作成されます。If there's a typo or an incorrect management group ID listed, the role definition is still created.
  • dataActions を含んだロールに対するロールの割り当てはサポートされません。Role assignment for a role with dataActions aren't supported. ロールの割り当ては、サブスクリプション スコープで作成してください。Create the role assignment at the subscription scope instead.

重要

AssignableScopes への管理グループの追加は、現在プレビューの段階です。Adding a management group to AssignableScopes is currently in preview. このプレビュー バージョンはサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。This preview version is provided without a service level agreement, and it's not recommended for production workloads. 特定の機能はサポート対象ではなく、機能が制限されることがあります。Certain features might not be supported or might have constrained capabilities. 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

管理グループとサブスクリプションの移動Moving management groups and subscriptions

管理グループまたはサブスクリプションを別の管理グループの子に移動するには、3 つのルールが true として評価されなければなりません。To move a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

移動操作を行う際は、次のことが必要です。If you're doing the move action, you need:

  • 子のサブスクリプションまたは管理グループに対する、管理グループの書き込みアクセス許可とロールの割り当ての書き込みアクセス許可。Management group write and Role Assignment write permissions on the child subscription or management group.
    • 組み込みロールの例: 所有者Built-in role example Owner
  • 移動先の親管理グループに対する、管理グループの書き込みアクセス権限。Management group write access on the target parent management group.
    • 組み込みロールの例: 所有者共同作成者管理グループ共同作成者Built-in role example: Owner, Contributor, Management Group Contributor
  • 既存の親管理グループに対する、管理グループの書き込みアクセス権限。Management group write access on the existing parent management group.
    • 組み込みロールの例: 所有者共同作成者管理グループ共同作成者Built-in role example: Owner, Contributor, Management Group Contributor

例外: ターゲットまたは既存の親管理グループがルート管理グループである場合、この管理の要件は必要ありません。Exception: If the target or the existing parent management group is the Root management group, the permissions requirements don't apply. すべての新しい管理グループとサブスクリプションは既定でルート管理グループに追加されるため、項目を移動するためにこのグループに対するアクセス許可は不要です。Since the Root management group is the default landing spot for all new management groups and subscriptions, you don't need permissions on it to move an item.

サブスクリプションの所有者ロールが現在の管理グループから継承される場合、移動先は制限されます。If the Owner role on the subscription is inherited from the current management group, your move targets are limited. サブスクリプションは、所有者ロールを持つ別の管理グループにのみ移動できます。You can only move the subscription to another management group where you have the Owner role. サブスクリプションの所有者ではなくなってしまうので、ご自分が共同作成者である管理グループには移動できません。You can't move it to a management group where you're a contributor because you would lose ownership of the subscription. サブスクリプションの所有者ロールに (管理グループから継承しているのではなく) 直接割り当てられている場合、ご自分が共同作成者である任意の管理グループに移動できます。If you're directly assigned to the Owner role for the subscription (not inherited from the management group), you can move it to any management group where you're a contributor.

アクティビティ ログを使用した監査管理グループAudit management groups using activity logs

管理グループは、Azure アクティビティ ログ内でサポートされます。Management groups are supported within Azure Activity Log. 他の Azure リソースと同じ一元的な場所で、管理グループに発生するすべてのイベントを検索できます。You can search all events that happen to a management group in the same central location as other Azure resources. たとえば、特定の管理グループに対して行われた、ロールの割り当てまたはポリシーの割り当ての変更を、すべて確認できます。For example, you can see all Role Assignments or Policy Assignment changes made to a particular management group.

選択した管理グループに関連するアクティビティ ログと操作のスクリーンショット。

Azure portal の外部で管理グループに対するクエリを使用する場合、管理グループのターゲット スコープは、 "/providers/Microsoft.Management/managementGroups/{yourMgID}" のようになります。When looking to query on Management Groups outside of the Azure portal, the target scope for management groups looks like "/providers/Microsoft.Management/managementGroups/{yourMgID}".

次のステップNext steps

管理グループについて詳しくは、以下をご覧ください。To learn more about management groups, see: