Copilot Studioを使ってエージェントを作成する場合には、まずどこの環境で作るかを選択します。
会社によっては既定の環境に作成することを禁止して、エージェントを作成するための環境を別に用意しているということも多いでしょう。

環境の種類や運用についてはMicrosoftの佐々木さんの記事が詳しくて勉強になります。

しかしながら、既定の環境はCopilot Studioを開くと最初に選択されているため、何も考えずに作り始めるとそこに作成されてしまいます。これはルール化したり大きく告知をしても利用者が多くなればしかたのないことです。

既定の環境では生成 AI を無効化していたり、DLP ポリシーで厳しく制限していたりすることがあります。
その結果、「使えないんですけどー」という問い合わせが寄せられます。

そして作成途中で放棄されたエージェントだけが残り、環境には澱のようにエージェントが溜まっていくのです。

以前からこの問題には頭を抱えていて、Dataverseから行削除したら消せる？とMicrosoftにSRを投げたもののおすすめしないとの回答。（まあそうでしょうね。）ゴミではあるが良しとするかと諦めておりました。

管理コネクタにあるじゃない！

さて、とある休日の朝。9ヶ月連続Qiita投稿のバッジを逃したくないのに、記事を書くネタがないなぁとぼやいていたところ、Microsoft Learnにこんな記述を見つけました。

なんですと！ MicrosoftはPower Platform 管理者向けV2コネクタに素敵なアクションを用意してくれたのです。

さっそくアクションを見てみる

本当にあった！

環境IDとBOT ID（古い呼び方が残っているあたりは定番）を使うだけのシンプル設計。

ところでAPIバージョンが2024年10月とか。SRなげたときにはAPIすでにあったんかい！？

環境に存在するエージェントはこんな感じでした。試しに一番上のエージェントを削除してみます。

環境 ID とエージェント ID は、対象のエージェントを開くことで確認できます。

HTTP ステータスコード 204 が返ってきました。これはリクエストが正常に処理されたことを意味します。

エージェントの一覧を見てみると、消えた！！
ちなみに、１つのエージェントを削除するのに34秒かかっていました。以前の SR では「複数のテーブルで管理されている」と説明を受けていたため、内部的にはそれなりに複雑な処理が行われているのかもしれません。

ならば次はエージェントの一覧を

エージェントを削除するならば、BOT IDを取得しておく必要があることがわかります。
確認してみましたが、クラウドフローのアクションにはそれらしいものがありませんでした。

DataverseからBOT IDを取得する

Copilot Studio で作成されたエージェントは表示名「エージェント」、内部名「bot」というテーブルで管理されています。

中身をみるとご覧のとおりです。ここからは既定環境では怖いのでテスト用の環境を使います。作成者が「SYSTEM」というエージェントが環境に作られていました。何者？これは後で削除対象から除くことにします。

内部列名もチェックします。

行の一覧をそのまま取得すると情報過多なので、取得する列を指定します。

行を選択する

botid,_ownerid_value,name

環境上に存在するエージェントの一覧が取得できました。BOT IDが取得できているので、これを使えばエージェントが削除できます。

SYSTEM が所有者のエージェントを対象から取り除く

「行の一覧を取得」アクションのODataフィルタだとうまくいかなかったので、「アレイのフィルター処理」アクションを使います。

アレイのフィルター処理

@not(equals(item()?['_ownerid_value@OData.Community.Display.V1.FormattedValue'], 'SYSTEM'))

テスト実行の結果であるJSONの中身をちゃんとテキストエディタなどで開き、オーナーがSYSTEMのエージェントが含まれていないことを確認します。

一気にエージェントを削除する

ここから先は禁断の操作です。環境の中のエージェントを一気に削除するため、必要なエージェントまで削除する可能性があります。
真似をしたら大事故を起こした！　等の責任は実行した本人にあり、当方では責任を負えませんのであしからず。

いよいよガッツリ削除します。BOT IDを取得しているのであとはループを回すだけです。
削除前のテスト環境内に存在するエージェントはこんな感じです。

Apply to each の中に削除アクションをいれました。ここで対象を「アレイのフィルター処理」ではなく「行を一覧にする」を指定してしまうと、SYSTEMが所有者であるエージェントも削除してしまうので気をつけましょう。

以前の手順から出力を選択

@{body('アレイのフィルター処理')}

ボットID

@{item()?['botid']}

実行した結果、2分16秒で5つのエージェントが削除されました。除外指定したSYSTEMが所有者のエージェントだけは残すこともできました！

GitHub Copilot Harness のエージェントはどうなる？

ここで気になるのが、新しいエージェントの作成方式で作った場合です。

このあたりについては、益森さんの記事が参考になります。これまで肝だった「トピック」がなくなってしまって驚きました！

この新方式でひとつエージェントを作りました。Powered by Github Copilot と表示されています。

さきほどのフローを再度実行してみると・・・・。消えてない。
ステータス的には削除成功なのに。エージェントを開いてみると開けてしまいます。

テーブルを見ても、残ってますね。

もういっかいフローを動かすと、こんどはなんと404 NotFound!!

GitHub Copilot Harness Agent は、Power Platform管理者向けV2コネクタで削除すると、変なことになっちゃうっぽいので要注意です。

まとめ

Power Platform 管理者向け V2 コネクタを利用することで、環境内の Copilot Studio エージェントを Power Automate から削除できることがわかりました。

また、Dataverse の bot テーブルを参照することでエージェント一覧や Bot ID の取得も可能です。

ただし、GitHub Copilot Harness を利用して作成された新しい方式のエージェントについては挙動が異なり、削除アクション実行後もエージェントが残存する現象を確認しました。

少なくとも現時点では、本操作は Standard エージェントを対象とするものと考えた方が安全そうです。

環境のお掃除フローとしては便利ですが、本番環境で利用する際は十分に検証してから実施することをおすすめします。

こんな人が書いてます

普段はPower Platformの管理者をしていて、Qiitaには主にPower AutomateのTipsのようなものを書いてます。ブログも書いているのでよろしかったらご覧ください！
関西のPower PlatformやMicrosoft系のイベントに時々顔を出しますので、ぜひ「DDさん？」と声をかけてください！