記事公開日 2026/07/21

【Copilot Studio】エージェントの所有者を変更する方法を解説！

この記事のポイント

Microsoft Copilot Studio のエージェント所有者は「共有」では引き継げません。
所有者を正式に付け替える方法は2つあり、本記事では「Microsoft 365 管理センターの GUI」と「Power Platform API の Reassign」の両方を、手順・必要な権限・使い分け・変更後の確認まで、公式ドキュメントと筆者の検証結果に沿って解説します。

共有 ≠ 所有者変更：
共有（Editor）は編集権限を「増やす」操作で、所有者は元のままです。所有者そのものを付け替えるには、これから紹介する再割り当ての操作を使います。
変更方法は2つ、やりやすい方を選べます：
ノーコードで手軽な「Microsoft 365 管理センターの GUI」と、細かく制御・自動化できる「Power Platform API」。API の成功の合図は HTTP 204 No Content です。
本体だけでは終わらない：
どちらの方法でも、クラウドフロー・接続・データソースの権限は別途点検が必要です。クラシックチャットボット（旧 Power Virtual Agents）はいずれの方法でも対象外です。

こんにちは！DXソリューション営業本部の大和矢です。

「このエージェント、作った担当者が異動するので所有者を引き継いでおいて」——運用が始まった Microsoft Copilot Studio のエージェントで、こんな依頼を受けたことはありませんか？
とりあえず新しい担当者に「共有」して編集権限を渡せば大丈夫、と思いがちですよね。
ですが、それでは所有者は元の担当者のままです。
元の担当者が退職・異動でアカウントごといなくなると、いわゆる「孤立したエージェント（orphaned agent＝管理する所有者が不在になったエージェント）」になってしまいます。

では、所有者そのものを正式に付け替えるには、どうすればよいのでしょうか。
その方法は共有とはまったく別に用意されていて、しかも2つの方法があります。
1つは Microsoft 365 管理センターの画面から行う方法、もう1つは Power Platform API を使う方法です。
本記事では、両方の手順を、必要なロール・使い分け・変更後の確認まで、公式ドキュメントの記述に沿って整理します。
あわせて、筆者が実際に検証環境で実行して確認した結果や、つまずいたポイントも添えます。

対象読者：Power Platform / Microsoft Entra の管理者、運用担当者
対象エージェント：Copilot Studio で作成したエージェント（旧 Power Virtual Agents のクラシックチャットボットは対象外です。詳細は第1章で説明します）

なお、そもそも Copilot Studio の「共有」自体にも複数の種類があり、付与される権限や裏側の Dataverse ロールが異なります。
「共有」の中身の設計については、こちらの記事で詳しく解説していますので、あわせてご覧ください。

【Power Platform】Copilot Studio の「共有」は1つじゃない－権限と裏で動く Dataverse ロールを最小権限で整理
「このエージェント、〇〇さんにも共有しておいて」——そう言われたとき、あなたは何を共有しますか？　チャットできるようにするだけか、一緒に編集できるようにするのか。実は Copilot Studio では、この「共有」という言葉の中身が一段深くなっています。

まず押さえるポイント：「共有」と「所有者変更」はまったくの別物
所有者を変更する2つの方法（GUI と API）
方法A：Microsoft 365 管理センター（GUI）で変更する
方法B：Power Platform API（Reassign）で変更する
変更後の確認：本当に所有者が変わったか
よくあるエラーと対処
「孤立したエージェント」を生まない運用設計
よくある質問（FAQ）
まとめ：所有者変更は「共有」ではなく「再割り当て」で

1. まず押さえるポイント：「共有」と「所有者変更」はまったくの別物

結論から言うと、共有（Editor 付与）では所有者は変わりません。
担当者の交代で本当にやりたい「引き継ぎ」は、所有者そのものを付け替える「再割り当て」で行います。
まずは、混同しやすい「共有」と「所有者変更」の違いを、下の図と表で整理しておきましょう（表には、対象外となるクラシックチャットボットもあわせて示します）。

「共有（Editor）」と「所有者変更（Reassign）」の違いを対比した概念図。共有では所有者はAさんのままEditorとしてBさんが加わるだけだが、所有者変更ではBさんに所有権が付け替わりAさんはアクセスを失う。

操作	実体	結果 / 注意点
所有者の再割り当て	GUI（Microsoft 365 管理センター）または Power Platform API	新しい所有者に標準の所有者権限が付与され、元の所有者はアクセスを失います。共同所有者には影響しません。
共有（Editor）	他ユーザーへ編集権限を付与	編集・構成・共有・公開は可能ですが、所有者そのものの変更ではありません。所有者は元のままです。
対象外：クラシックチャットボット	旧 Power Virtual Agents 世代のチャットボット	再割り当ては GUI・API とも非対応です。API で実行すると 405（Method Not Allowed）が返ります。

つまり、「共有」はチームで一緒に触れるようにするための操作、「所有者変更（再割り当て）」は責任の主体そのものを付け替える操作です。
共有と引き継ぎは同義ではなく、共有は「アクセスを増やす」操作、所有者変更は「責任を移す」操作、と方向が違うわけですね。
担当者交代で本当にやりたいのは後者であることがほとんどです。

なぜ「クラシック」の意味に注意が必要なのか：
「クラシック」という言葉が別々のものを指す場合があるため、混同しないよう整理しておきます。

クラシックチャットボット：
Copilot Studio の旧バージョンおよびその前身である Power Virtual Agents で作成されたボットで、生成 AI 機能をサポートしません（公式ドキュメントに明記されています）。所有者の再割り当てが対象外なのはこちらです。
クラシックエクスペリエンス：
「新しいエクスペリエンス」の対になる、モダンな Copilot Studio エージェントの作成 UI です。クラシックエクスペリエンスでも、クラシック／生成のオーケストレーションモードを選べます（従来のエージェントエクスペリエンスと新しいエージェントエクスペリエンス）。これはクラシックチャットボットとは別物で、再割り当ての対象です。

クラシックチャットボットは生成 AI 機能を持たないため、生成オーケストレーションを使っているエージェントはクラシックチャットボットではなく、再割り当ての対象と判断できます。

重要：この手順で変更できるのは「Copilot Studio のエージェント本体」の所有者です。
エージェントに関連するクラウドフロー・接続・SharePoint / Dataverse のアクセス権などは、この操作の対象外なので、別途点検が必要です（第5章のチェックリストで確認します）。

2. 所有者を変更する2つの方法（GUI と API）

所有者の再割り当てには、2つの方法が用意されています。
どちらも「共有」ではなく所有者そのものを付け替える操作で、結果（新しい所有者に権限が移り、元の所有者はアクセスを失う）は共通です。
まずは全体像を、下の比較表で押さえておきましょう。

観点	方法A：Microsoft 365 管理センター（GUI）	方法B：Power Platform API（Reassign）
操作	画面から「新しい所有者の割り当て」を選ぶだけ	PowerShell 等で REST API を呼び出す
手軽さ	◎ 手軽	△ 事前準備が必要
事前準備	管理者ロールでのサインインのみ	値の収集（Environment ID / Bot ID / オブジェクト ID）＋アプリ登録＋トークン取得
自動化・一括処理	手動向き	スクリプト化・自動化しやすい
対象	Copilot Studio / エージェントビルダーのエージェント	Copilot Studio のエージェント（クラシックは 405）
注意点	IP ファイアウォールがアクティブ強制モードの環境では失敗する（後述）	ファイアウォール環境でも直接実行できる

使い分けの目安：まずは手軽な方法A（GUI）で十分なことが多いです。
複数エージェントをまとめて処理したい・スクリプトで自動化したい、あるいは GUI が使えない（IP ファイアウォールのアクティブ強制モード環境など）場合は方法B（API）を選びます。
次章以降で、それぞれの手順を見ていきましょう。

3. 方法A：Microsoft 365 管理センター（GUI）で変更する

手軽に済ませたいなら、こちらの GUI がおすすめです。
Microsoft 365 管理センターの「エージェント」から、画面操作だけで所有者を再割り当てできます（公式ドキュメント）。

手順

Microsoft 365 管理センターにサインインします。
エージェント > すべてのエージェントを選択します。
エージェントの一覧から、再割り当てするエージェントを選択します。プラットフォームフィルターで Copilot Studio を選ぶと、目的のエージェントを素早く見つけられます。
エージェントの詳細ウィンドウで、エージェント名のすぐ下にある [新しい所有者の割り当て] を選択します。
[新しい所有者の割り当て] ウィンドウで、組織から新しい所有者を入力し、[割り当て] を選択します。

「新しい所有者を割り当てる」ウィンドウで、新しい所有者となるユーザーを選び「割り当てる」を選択する様子。

再割り当て後は、次のように権限が移ります。

新しい所有者：
完全な編集・削除の権限に加え、以前の所有者がアップロードしたファイルへのアクセス権を取得します。
以前の所有者：
読み取り権限を含むすべてのアクセス権を失います。

GUI が使えないケースに注意：
公式ドキュメントによると、対象環境で IP ファイアウォールが「アクティブな適用（強制）モード」になっていると、Microsoft 365 管理センターからの管理アクションは失敗します。
これは、要求の送信元が管理者のクライアント IP ではなくアップストリームサービスの IP になり、ファイアウォールに拒否されるためです。
この場合は、次章の方法B（Power Platform API）を直接実行してください。

共有エージェントの所有権の再割り当ては、エージェントビルダーと Copilot Studio のエージェントでのみサポートされます（クラシックチャットボットは対象外です）。

4. 方法B：Power Platform API（Reassign）で変更する

細かく制御したい・スクリプトで自動化したい・GUI が使えない、といった場合は Power Platform API の Reassign（再割り当て）操作を使います。
GUI より事前準備は増えますが、そのぶん一括処理や自動化に向いています。
必要な条件・集める値・実行手順の順に見ていきましょう。

4-1. 必要な管理者ロールと新しい所有者の条件

Reassign は管理者が実行する API 操作です。
条件は孤立したエージェントの所有権を Power Platform API で再割り当て（公式ドキュメント）に明記されています。

実行者（あなた）に必要なもの：

管理者ロール（いずれか1つ）：
グローバルテナント管理者、AI 管理者、Power Platform 管理者、または環境管理者
ユーザーアクセストークン：
API 呼び出しには Microsoft Entra ID の OAuth2 ユーザーアクセストークンが必要です
アプリ登録の権限：
トークン取得に使うアプリ登録に、Power Platform API の CopilotStudio.AdminActions.Invoke スコープと管理者同意が必要です

新しい所有者に必要な条件：

同一テナントのユーザーであること
対象環境へのアクセスと必要な Copilot Studio ライセンスを事前に確認しておくこと
再割り当て後、新しい所有者には対象環境の Environment Maker（環境作成者）権限が付与されます

なぜ「ユーザーアクセストークン」なのか：
Reassign はサービスプリンシパル（アプリ単独の権限）ではなく、管理者ユーザーのコンテキストで取得したトークンで実行します。
つまり「誰が実行したか」がそのユーザーのロールで判定されるため、実行者自身が上記の管理者ロールを持っている必要があります。

4-2. 事前に取得する4つの値とアプリ登録

API を叩く前に、次の4つの値を集めます。
ここを正確に集めておくことが、後のエラーを防ぐ最大のコツです。

値	取得場所	確認ポイント
Environment ID	Copilot Studio：設定 > 上級 > メタデータ	対象エージェントが存在する環境と一致しているか（GUID）
Bot ID	エージェントを開いたときの URL の /bots/ 直後の GUID（＝CDS bot ID）	表示名や Entra エージェント ID ではなく GUID を使う
NewOwnerAadUserId	Microsoft Entra 管理センター：ユーザー > 対象ユーザー > プロファイル > オブジェクト ID	UPN（メールアドレス形式）ではなくユーザーのオブジェクト ID（GUID）
Access token	CopilotStudio.AdminActions.Invoke を許可したアプリ登録で取得	対象リソースは Power Platform API（Bearer token）

Environment ID を確認する

Copilot Studio で対象エージェントを開き、設定 > 上級 > メタデータを開くと、Environment ID（GUID）を確認できます。
同じ画面には「テナント ID」「Entra エージェント ID」「スキーマ名」も並びますが、Reassign で使うのは Environment ID です。

Copilot Studio の「設定 > 上級 > メタデータ」画面で Environment ID を確認している様子。

Bot ID を確認する

Bot ID（CDS bot ID）は、Copilot Studio でエージェントを開いたときの ブラウザの URL から取るのが確実です。
URL は「.../environments/{Environment ID}/bots/{Bot ID}/...」という構造になっており、/bots/ の直後の GUIDが Bot ID です。
/environments/ の直後が先ほどの Environment ID と一致することも、あわせて確認できます。

管理者向けの Copilot Studio エージェントインベントリの properties.botId からも取得できますが、こちらはプレビュー機能（2026年7月時点）です。
まずは URL 方式が手軽です。

ここが一番の落とし穴：
「表示名」「Entra エージェント ID」「Bot ID」はすべて別物です。
特にメタデータ画面に出てくる「Entra エージェント ID」を Bot ID と取り違えると、後述の 400 Bad Request になります。
使うのは URL の /bots/ 直後の GUID です。

新しい所有者のオブジェクト ID を確認する

Microsoft Entra 管理センターで ユーザー > 対象ユーザー > プロファイルを開き、オブジェクト ID（GUID）を控えます。
UPN（メールアドレス）ではなく、オブジェクト ID である点に注意してください。
手順の詳細は Microsoft Entra 管理センターでのユーザープロファイルを参照してください。

Microsoft Entra 管理センターのユーザープロファイルで、新しい所有者のオブジェクト ID を確認している様子。

アプリ登録と API 権限を準備する

トークンを取得するためのアプリ登録は、次の手順で準備します（Power Platform API の認証）。

アプリ登録を作成：
Microsoft Entra 管理センターで単一テナントのアプリ登録を作成し、Application (client) ID と Directory (tenant) ID を控えます。
Power Platform API を追加：
「API のアクセス許可」で Power Platform API を検索します。公式文書では、サービスプリンシパルの GUID 8578e004-a5c6-46e7-913e-12f58912df43 が示されています。一覧に出ない場合は、テナントにサービスプリンシパルが未作成なので、公式手順の force-refresh で作成します。
委任された権限を追加：
CopilotStudio.AdminActions.Invoke を追加し、管理者の同意を付与します。

アプリ登録の「API のアクセス許可」に Power Platform API の CopilotStudio.AdminActions.Invoke を追加し、管理者同意を付与した状態。

4-3. アクセストークンを取得する

管理者ユーザーのコンテキストでアクセストークンを取得します。
ここでは、リダイレクト URI 用のローカルサーバーが不要で扱いやすいデバイスコードフローの例を示します。
アプリ登録の「認証」で、あらかじめ「パブリッククライアントフローを許可する」を「はい」にしておいてください。

# 初回のみ: MSAL.PS モジュールをインストール
Install-Module MSAL.PS -Scope CurrentUser -Force

$clientId = "<アプリのApplication (client) ID>"
$tenantId = "<Directory (tenant) ID>"

# デバイスコードで対話サインイン（案内に従い、管理者ロールを持つ自分のアカウントでサインイン）
$msal = Get-MsalToken -ClientId $clientId -TenantId $tenantId -DeviceCode `
        -Scopes "https://api.powerplatform.com/CopilotStudio.AdminActions.Invoke"

$accessToken = $msal.AccessToken

# スコープに CopilotStudio.AdminActions.Invoke が含まれることを確認（トークン本体は表示しない）
$msal.Scopes

筆者がつまずいたポイント：
「パブリッククライアントフローを許可する」を有効にする前に実行すると、AADSTS7000218（client_assertion または client_secret が必要）というエラーで失敗しました。
デバイスコードフローはパブリッククライアント設定が前提なので、アプリ登録の「認証 > 詳細設定」でこのトグルを「はい」にすると解消しました。

4-4. Reassign API を実行する

この操作は元に戻しにくい変更です：
Reassign を実行すると、元の所有者は対象エージェントへのアクセスを失います。
初めて試すときは、本番エージェントではなく検証用のテストエージェントで行ってください。
元に戻すには、新旧を入れ替えて再度 Reassign を実行します（新しい所有者→元の所有者の方向）。

収集した Environment ID・Bot ID・新しい所有者のオブジェクト ID をセットして、Reassign を POST します。
REST API リファレンスに合わせ、api-version=2024-10-01 を使用します（Power Platform API の操作リファレンス）。
すべての GUID に余分な空白がないことを確認しましょう。

$environmentId = "<EnvironmentId>"
$botId         = "<BotId>"
$newOwnerId    = "<NewOwnerAadUserId>"   # 新しい所有者のオブジェクト ID（UPNではない）

$uri = "https://api.powerplatform.com/copilotstudio/environments/$environmentId/bots/$botId/api/botAdminOperations/reassign?api-version=2024-10-01"

$headers = @{
    Authorization  = "Bearer $accessToken"
    "Content-Type" = "application/json"
}

$body = @{ NewOwnerAadUserId = $newOwnerId } | ConvertTo-Json

# ステータスコードを目視するため Invoke-WebRequest を使用（-UseBasicParsing で解析警告を回避）
$resp = Invoke-WebRequest -Method Post -Uri $uri -Headers $headers -Body $body -UseBasicParsing
$resp.StatusCode   # 期待値: 204

成功時の応答は 204 No Content です。
本文が空でも正常なので、慌てないでください。
筆者の検証環境でも、再割り当ての実行に対して HTTP 204 が返り、所有者が正しく付け替わりました。
400 や 500 が返る場合は、ID・権限・トークン・対象種別を第6章で切り分けます。

PowerShell で Reassign API を実行し、HTTP 204 No Content が返った様子。

項目	内容
Method	POST
Endpoint	https://api.powerplatform.com/copilotstudio/environments/{EnvironmentId}/bots/{BotId}/api/botAdminOperations/reassign?api-version=2024-10-01
Request body	{"NewOwnerAadUserId":"<Entra user object ID>"}
Success	204 No Content

トランスクリプトの注意：
新しい所有者が既存のトランスクリプト（会話の書き起こし）を参照するには、別途 Bot Transcript Viewer などの権限が必要です。
所有者変更だけで過去のトランスクリプト閲覧が保証されるわけではありません。

5. 変更後の確認：本当に所有者が変わったか

GUI・API のどちらの方法でも、再割り当てが成功したら、Copilot Studio のエージェント一覧で所有者の列を見比べてみましょう。
筆者の検証でも、下のように所有者の列が元の担当者から新しい担当者へ切り替わりました。

Copilot Studio のエージェント一覧で、再割り当て前は所有者が元の担当者になっている様子。

Copilot Studio のエージェント一覧で、再割り当て後は所有者が新しい担当者に変わっている様子。

「元の所有者はアクセスを失う」の但し書き：
公式ドキュメントには「再割り当て後、元の所有者はエージェントへのアクセスを失う」と明記されています。
ただしこれは「所有者としてのアクセス」の話です。
筆者が検証したときは、システム管理者（System Administrator）やシステムカスタマイザー（System Customizer）といった、環境内の全エージェントを見られるロールを持っていたため、所有者を譲渡した後もエージェントが一覧に表示され続けました。
これらのロールは Dataverse の bot（エージェント）テーブルに「組織」レベルでアクセスできる一方、環境作成者（Environment Maker）は「自分が所有・共有されたエージェントだけ」です（ロール別の権限表）。
「アクセスを失うか」は元の所有者が持つ他のロール次第、と理解しておくとよいでしょう。
きれいにアクセス喪失を確認したい場合は、所有者権限しか持たないユーザーを元の所有者にして試すのが確実です。

冒頭でも触れたとおり、所有者変更はエージェント本体だけでは完結しません。
次のチェックリストで、依存リソースまで含めて点検しましょう。

対象	判定基準
エージェント本体	新しい所有者で表示・編集・保存・公開ができる
元の所有者	所有者としてのアクセスを失っている（他ロールがあれば残る点に注意。必要なら Editor として再共有）
共同所有者	既存の共同所有者のアクセスが維持されている
トランスクリプト	必要な場合、閲覧権限を付与して参照できる
クラウドフロー	所有者 / 共同所有者、接続参照、実行ユーザーを確認
接続・資格情報	旧担当者の個人接続に依存していないことを確認
データソース	SharePoint、Dataverse、外部 API 等への新しい所有者のアクセスを確認
公開チャネル	Teams / Microsoft 365 Copilot / Web 等で公開済み版が動作する
監査証跡	変更日時、実行者、新旧所有者、対象 Environment ID / Bot ID を記録

6. よくあるエラーと対処

再割り当て時につまずきやすいエラーと、その切り分けポイントをまとめます。

方法A（GUI）でつまずくとき

管理アクションが失敗する：
対象環境の IP ファイアウォールが「アクティブな適用（強制）モード」だと、Microsoft 365 管理センターからの操作は失敗します。この場合は方法B（API）を直接実行します。
「新しい所有者の割り当て」が見当たらない：
対象がクラシックチャットボットでないか、Copilot Studio / エージェントビルダーのエージェントか確認します。

方法B（API）でつまずくとき

401 / 403：
トークンの対象リソース、CopilotStudio.AdminActions.Invoke、管理者同意、実行者ロールを確認します。
400 Bad Request：
Environment ID / Bot ID / NewOwnerAadUserId の形式（GUID か）と、対象テナントを確認します。UPN をオブジェクト ID と取り違えていないか、表示名や Entra エージェント ID を Bot ID と取り違えていないかもここでチェックです。
405 Method Not Allowed：
対象がクラシックチャットボット（旧 Power Virtual Agents）でないか確認します。Reassign API はクラシック非対応です。
500 Internal Server Error：
同じ値で連続実行せず、対象 ID とサービス状態を確認して管理者ログを採取します。
AADSTS7000218（トークン取得時）：
アプリ登録の「パブリッククライアントフローを許可する」が「はい」になっているか確認します（デバイスコードフローの前提）。
変更後にエージェントが開けない：
新しい所有者の環境アクセス、ライセンス、関連コンポーネント / 接続の権限を確認します。

7. 「孤立したエージェント」を生まない運用設計

最後に、そもそも「孤立したエージェント」を生まないための運用設計のヒントです。

個人アカウントだけに所有権を依存させず、少なくとも複数の管理可能な担当者を Editor として設定しておくことをおすすめします。
あわせて、退職・異動時の引き継ぎ手順と、エージェントが依存するリソース一覧（クラウドフロー・接続・データソース）を台帳化しておくと、いざというときの再割り当てがぐっと楽になります。
共有（Editor）と所有者変更（再割り当て）の使い分けも、運用ルールとして明文化しておくと、担当者交代のたびに迷わずに済みますね。
所有者変更は「起きてから対応する」より「起きても困らないように備える」方が、運用としてはずっと安全です。

よくある質問（FAQ）

Q. GUI と API、どちらの方法を使えばよいですか？

まずは手軽な GUI（Microsoft 365 管理センター）で十分なことが多いです。
複数エージェントをまとめて処理したい・スクリプトで自動化したい、あるいは IP ファイアウォールのアクティブ強制モードで GUI が使えない場合は、Power Platform API を選びます。

Q. 共有（Editor）では所有者は引き継げないのですか？

はい。共有（Editor）は編集権限を追加する操作で、所有者は元のままです。
責任の主体そのものを付け替える「引き継ぎ」には、GUI または API の再割り当てを使います。

Q. クラシックチャットボットも同じ手順で所有者を変更できますか？

いいえ。クラシックチャットボット（旧 Power Virtual Agents）は GUI・API とも対象外で、API で実行すると 405 が返ります。
対象は Copilot Studio で作成したエージェントです。

Q. API を実行したのに応答が空です。失敗ですか？

いいえ。成功時の応答は HTTP 204 No Content で、本文が空なのが正常です。
ステータスコードが 204 であれば成功しています。

まとめ：所有者変更は「共有」ではなく「再割り当て」で

Microsoft Copilot Studio のエージェント所有者を正式に変更する方法は、共有（Editor 付与）ではなく、所有者そのものを付け替える「再割り当て」でした。
今回の学びを3つに整理します。

共有と所有者変更は別物：
共有は編集権限を「増やす」操作、所有者変更（再割り当て）は責任を「移す」操作です。担当者交代で必要なのは後者です。
変更方法は2つ、やりやすい方を：
手軽さなら Microsoft 365 管理センターの GUI、細かい制御・自動化なら Power Platform API（成功は HTTP 204 No Content）。GUI が使えない環境では API を選びます。
本体だけでは終わらない：
クラウドフロー・接続・データソースの権限は別途点検が必要です。日ごろから複数 Editor 設定とリソースの台帳化で「孤立したエージェント」を予防しておきましょう。

担当者交代のたびに「所有者どうする問題」に悩まされてきた方は、まずは検証用のテストエージェントで、手軽な GUI から一度試してみてはいかがでしょうか。
一連の流れを体験しておくと、いざというときに落ち着いて対応できるはずです。

本記事の情報について：
Microsoft の管理 UI・API・ロール名称は更新されることがあります（本記事は2026年7月時点の情報です）。
実施前に、下記の Microsoft Learn 公式ドキュメントで最新の記述をあわせてご確認ください。

公式リファレンス

Microsoft 365 管理センターのエージェントのガバナンスとライフサイクルのアクション（GUI での「新しい所有者の割り当て」）
孤立したエージェントの所有権を Power Platform API で再割り当て（前提条件・必要ロール・権限・再割り当て後の挙動）
Power Platform API：Copilot Studio Bots 操作リファレンス（エンドポイント・要求本文・api-version・HTTP 204）
Power Platform API の認証（アプリ登録・API 権限・トークン取得）
Copilot Studio エージェントインベントリ（Bot ID などの取得。プレビュー）
エージェントの共有を制御する（Editor / Viewer の権限差）
従来のエージェントエクスペリエンスと新しいエージェントエクスペリエンス（クラシック／新しいエクスペリエンスの違い）

なお本記事では、方法B（API）の前提として Microsoft Entra ID のアプリ登録・API 権限（スコープと管理者の同意）も扱いました。
アプリ登録やサービスプリンシパル、権限・スコープといった Microsoft Entra ID の権限管理・ガバナンスまわりのテーマは、QESブログの「Microsoft Entra ID Governance」カテゴリでもまとめて発信しています。あわせてご覧いただけますと幸いです。

Microsoft Entra ID Governance ブログ一覧 | QES ブログ
QESのエンジニアが Microsoft Entra ID Governance のアクセス制御・権限管理・ID統制の自動化ノウハウを発信中！

また、QESでは、Power Platform導入時の支援から、アプリケーション開発、導入後の保守サポートまで対応しています。
以下のリンクからご提供しているサービスの詳細をご確認いただけます。

Power Platform（ローコード開発）｜ QES
ローコード開発ツール「Microsoft Power Platform」で現場からアプリ開発・DXを推進！...

※このブログで参照されている、Microsoft、Microsoft Copilot Studio、Copilot、Power Platform、Power Apps、Power Automate、Power Virtual Agents、Microsoft Entra、Microsoft 365、Microsoft Teams、SharePoint、Dataverse は、米国およびその他の国における Microsoft Corporation の商標または登録商標です。