誰がどのコネクタを使ってる？Power Platform「コネクタ列」＋V2コネクタで棚卸しする方法

Power Automate
スポンサーリンク

みなさん、こんにちは！業務ハックLabのようです。

梅雨の時期、ジメジメして気分が上がらないですが…そんなときこそ、地味に効く「棚卸し系」の話題で気分転換しましょう（笑）。今日は情シスの方に刺さりそうな、Power Platform管理センターの新機能を実機検証込みでお届けします！

📋 この記事の要点
※ 2026年6月時点の情報です

  • Power Platform管理センターのインベントリ（一覧）に「コネクタ列」がパブリックプレビューで追加され、各アプリ・フロー・エージェントが使うコネクタを一覧で確認できます。
  • ただしUIに表示されるのはコネクタ名とアクションのみで、用途区分（usedAs：Tool / Topic Tool / Knowledge）はAPI経由でしか取得できません。
  • 「Power Platform for Admins V2」コネクタの「Power Platform リソースのクエリを実行する」アクションを使うと、リソース種別を問わず特定コネクタの利用状況を横断的に棚卸しできます。
  • クエリはGUIでは骨組みしか組めず、条件式はコードビューでJSONを直接編集する前提です。正式な仕様は公式ドキュメント「Power Platform inventory API」に網羅されています。
  • 配列フィールド（powerPlatformConnectors）の正式な展開集計（mv-expand相当）は現時点では未対応のため、tostring()＋containsの部分一致検索で代替します。

こんな方におすすめ: 社内のコネクタ利用状況を棚卸ししたい情シス担当者、DLP・ACPなどのポリシー変更前に影響範囲を把握したい管理者の方。

Power Platform管理センターに「コネクタ列」が登場（2026年6月プレビュー開始）

このセクションでは、2026年6月にパブリックプレビューとして公開された「コネクタ列」が、どんな機能なのかを概観します。

みなさん、コネクタの棚卸しって、地味にしんどくないですか？

「誰がプレミアムコネクタを使ってるんだっけ？」「あの外部システムにつないでるフロー、どこにあったかな？」と、アプリやフローを1個ずつ開いて確認する…。あの作業、本当に時間が溶けますよね。

今回登場した「コネクタ列」は、まさにその悩みに刺さる機能です。Power Platform管理センターのインベントリ（一覧）画面で、各リソースが使っているコネクタを一覧でまとめて確認できるようになりました。今回は、この機能を実際に検証してきました！

何が見えるようになったのか（対象リソース・取得データの範囲）

このセクションでは、コネクタ列の対象となるリソースの種類と、取得できるデータの範囲を整理します。

Power Platformの「インベントリ（一覧）」は、テナント内のアプリ・フロー・エージェント・環境などを横断で見られる管理者向けの統合ビューです。

対象になるのは、Copilot Studioで作られたエージェント、Power Appsのアプリ、Power Automateのクラウドフローなど、Power Platformで作られたリソースが幅広く含まれます。そこに新しく「コネクタ」列を追加できるようになった、というのが今回の話です。

表示形式はシンプルで、コネクタの内部ID（たとえば shared_sharepointonline）がカンマ区切りで列記されます。複数のコネクタを使っている場合は、列幅を超えるとツールチップで全量を確認できます。

💡 Tips: アクセスにはPower Platform管理者、またはDynamics 365管理者のロールが必要です。一般ユーザーでは表示できないので、検証は管理者アカウントで行ってくださいね。

実際に管理センターで確認してみる（UI操作・スクショ中心）

このセクションでは、コネクタ列を有効化して一覧に表示するまでのUI操作を、4ステップで解説します。

ステップ1：インベントリ一覧を開く

まずは管理センターの「管理（Manage）」→「インベントリ（一覧）」を開きます。今回検証したテナントでは、559件のリソースが一覧に並んでいる状態でした。

ステップ2：コネクタ列を有効化する

検索ボックスの横にある「列の追加と削除」から、「コネクタ」にチェックを入れます。プレビューバッジが付いているので、すぐ分かります。

これだけで、一覧にコネクタ名が表示されるようになります。（設定はワンクリック、ここはとても簡単です）

ステップ3：Copilot Studio専用ビューで確認する

次に、Copilot Studio専用のエージェント一覧ビューでも見てみます。こちらは122件のエージェントが表示されました。

ここが個人的にお気に入りでして！モデル列（Claude Opus系やGPT-5 Chatなど）と、コネクタ列が横並びで見えるんです。「どのエージェントが、どのモデルで、どのコネクタを使っているか」が一覧でつかめます。

ステップ4：エージェント詳細パネルを開く（ここで限界が見える）

エージェントを1つ選んで詳細パネルのコネクタタブを開くと、ここで重要な事実に気づきます。

表示されているのは「コネクタ」と「アクション」の2列だけ。例として「障害報告対応」というエージェントを見ると、コネクタ名（shared_sharepointonline）は出ていますが、アクション列は空欄でした。

実は、後ほど登場するAPI側で同じエージェントを調べると、このコネクタは usedAs: "Knowledge"、つまり「ナレッジとして使っている」という用途まで取得できます。ところが、その情報はUIには一切出てこないんです。

⚠️ ここがポイント: UIで一覧性は確保できますが、用途区分（usedAs）やisEnabledといった詳細はUIに表示されません。ガバナンス用途の深い分析には、この後紹介するAPI連携が必須、という結論が実機で確認できました。

というわけで、ここからギアを上げて、フローからデータを取りにいきます！

Power Platform for Admins V2コネクタでフローから取得してみる

このセクションでは、「Power Platform for Admins V2」コネクタを使い、Power Automateのフローからインベントリデータを取得する手順と、そこで待っている落とし穴を解説します。

使うのは「Power Platform for Admins V2」コネクタ。Power Automateで検索すると、日本語の表示名はPower Platform リソースのクエリを実行するです。OAuthで接続を追加すれば、ここまではスムーズに進みます。

パラメータを見ると、APIバージョンは 2024-10-01、テーブル名は PowerPlatformResources 固定。そして「Clauses」で $type を選ぶリピート形式のコントロールが出てきます。ドロップダウンには where project summarize count など、KQLっぽい演算子が並んでいます。

⚠️ 最大の落とし穴: GUIでは $type を「選ぶ」ことしかできず、肝心の条件式や列名を入力する欄が出てきません。実際の入力は「コードビュー」タブに切り替えて、JSON配列を手書きで編集するのが前提でした。「GUIで簡単に組めそうに見えて、実はJSON手書き」。これは知らないとハマります。

502エラーは「サーバー障害」とは限らない

このサブセクションでは、検証中に頻発した502 BadGatewayエラーの正しい読み解き方を紹介します。

試しに project 句だけを書いて実行すると、ステータスコード502、BadGatewayが返ってきました。「502って…サーバー落ちてる？」と思いますよね。でも、ここで諦めないのが大事です。

レスポンスの中身を見ると、innerErrorに FieldList cannot be null or empty と書いてあります。つまり「project句にはFieldListというプロパティが必要だよ」と教えてくれているわけです。

"body": {
        "error": {
            "code": 502,
            "source": "usa002-004.azure-apihub.net",
            "clientRequestId": "d58c5f68-9813-4edb-b28a-f6348f8e25be",
            "message": "The response is not in a JSON format.",
            "innerError": "One or more validation errors occurred during clause validation. (FieldList cannot be null or empty)"
        }
    }

💡 コラム：502を見たら、まずinnerErrorを開く
このコネクタは、こちらの入力ミス（必須プロパティ不足）でも502を返してくる実装になっています。「502＝サーバー障害」と決めつけず、必ず body.error.innerError の中身を確認する習慣を持ってください。なお、再試行ポリシーを「なし」に変更しておくと、1回の実行でエラー詳細がきれいに取得できておすすめです。

同じ要領で where 句も試していくと、必須プロパティが FieldName・Operator・Values の3点セットだと分かってきます。

正解は、最初から公式ドキュメントに載っていた

このサブセクションでは、試行錯誤の末にたどり着いた「正しい順序」をお伝えします。

……と、ここまで僕は割と回り道をしたんですが、最後に大きな反転がありました。公式ドキュメント「Power Platform inventory API」に、すべての句の正式な書き方が載っていたんです。サンプルJSONも、対応するKQLも、Power Platform管理センターのデフォルトクエリの実体まで、全部です。

なので、みなさんには最初からこのページを案内します。当て推量でエラーと格闘する前に、まずここを開く。これが正しい順序です。

📖 必読: Power Platform inventory API（公式ドキュメント）
Power Platform インベントリ API

基本の project 句だけのクエリは、こんな形です。

[
  { "$type": "project", "FieldList": ["name", "type", "properties.displayName"] }
]

これでテナント全体のリソースが取得できます。ただし1回のクエリで返るのは最大1,000件まで。resultTruncated: 1 のフラグが立っていたら、skipToken でページングする前提です。

続いて、Copilot Studioエージェントだけに絞り込むクエリがこちら。

[
  { "$type": "where", "FieldName": "type", "Operator": "==", "Values": ["'microsoft.copilotstudio/agents'"] },
  { "$type": "project", "FieldList": ["name", "type", "properties.displayName"] }
]

⚠️ クォートの罠:Values に入れる値は "'microsoft.copilotstudio/agents'" のように、JSON文字列の「中に」さらにシングルクォートを入れる必要があります。これは、サーバー側がValuesの文字列をKQLコードとして展開するためで、シングルクォートがないと識別子と誤解されて解決に失敗します。JSONの引用と、KQL内の文字列リテラルの引用は別レイヤー、と覚えておくと混乱しません。

ちなみに、project でドット区切りのプロパティ名（properties.displayName）を指定すると、レスポンスではアンダースコア区切り（properties_displayName）に変換されます。地味にハマるので頭の片隅に。

【実践】特定コネクタを使っているリソースをリソース種別を問わず横断検索する

このセクションは本記事の核心です。特定のコネクタを使っているリソースを、エージェント・フロー・アプリの種別を問わず横断的に洗い出すクエリを完成させます。

ターゲットは、以前作った「Claude API」のカスタムコネクタ。これを使っているリソースを探します。

絞り込みを外して、全リソースを対象に変更。コネクタ情報をいったん文字列に変換して、その中に claude という文字が含まれるものを探す形にしました。

これが、コピペでそのまま使える最終形クエリです。

[
  { "$type": "extend", "FieldName": "connectorsText", "Expression": "tostring(properties.powerPlatformConnectors)" },
  { "$type": "where", "FieldName": "connectorsText", "Operator": "contains", "Values": ["'claude'"] },
  { "$type": "project", "FieldList": ["name", "type", "properties.displayName", "connectorsText"] }
]

実行すると…見事に3件ヒット！フロー側でClaude APIが使われていました。

ここで大きな発見がありました。コネクタ情報を持つ properties.powerPlatformConnectors というフィールド、これをエージェント専用だと思い込んでいたのですが、実はクラウドフローにも共通で存在していたんです。だからこそ、種別を問わない横断検索ができた、というわけですね。

💡 このクエリの応用ポイント: 上のクエリの 'claude' の部分を、任意のコネクタ名キーワードに置き換えるだけで、さまざまなコネクタの棚卸しに使い回せます。プレミアムコネクタの利用状況調査に、汎用的に応用できる一本です。

⚠️ なぜ「文字列化＋部分一致」なのか: 本来は配列フィールドを展開して集計する mv-expand 相当の操作が欲しいところですが、現時点の公式ドキュメントのクエリ句一覧には該当する句が見当たりませんでした。そこで tostring() で配列全体を文字列化し、where contains で部分一致検索する「力技」アプローチを採用しています。

💡 完全一致より部分一致が安全: カスタムコネクタのIDは、作り直すと末尾のハッシュ値が変わります（同じ「Claude API」でも別インスタンス扱いになる）。完全一致だと同じコネクタの全インスタンスを拾いきれないことがあるため、contains による部分一致（例: 'claude'）の方が実務ではむしろ確実です。

【実践】エージェントのAIモデル利用状況を集計してみる

このセクションでは、同じ仕組みを横展開し、エージェントが利用しているAIモデルの分布を集計する方法を紹介します。

コネクタだけでなく、モデルの利用傾向も同じ枠組みで可視化できます。ただし、ここでKQLの定番の制約にぶつかります。

⚠️ dynamic型は直接グループ化できない:properties 配下のフィールド（model など）は内部的にdynamic型として扱われ、summarizeのグループ化キーに直接は使えません。エラーメッセージにも「explicit castを使え」と出ます。

解決策は、extend 句で先に tostring() による明示的な文字列キャストを行い、新しい列を作ってから集計することです。summarize 句の正式な書き方は、SummarizeClauseExpression というネストオブジェクト形式になります。

[
  { "$type": "where", "FieldName": "type", "Operator": "==", "Values": ["'microsoft.copilotstudio/agents'"] },
  { "$type": "extend", "FieldName": "modelName", "Expression": "tostring(properties.model)" },
  { "$type": "summarize", "SummarizeClauseExpression": { "OperatorName": "count", "OperatorFieldName": "agentCount", "FieldList": ["modelName"] } }
]

実行すると、122件のエージェントがモデル別に集計されました。検証したテナントでは、標準モデルが最多で78件、次いでGPT-5 Chatが27件。残りはClaude系やMicrosoft 365 Copilotなどに分散する、という結果でした。（数字はあくまでこのテナントの例ですが、傾向がひと目で見えるのは便利ですね）

この機能が役立つ場面（DLPポリシー・ACP設計・野良エージェント対策など）

このセクションでは、ここまでのテクニックが実務のどんな場面で効いてくるかを整理します。

DLPポリシー変更前の影響範囲調査

「このコネクタを制限したら、実際どのリソースが止まるのか？」を、変更前に横断クエリで把握できます。冒頭でお話しした「怖くて踏み切れない問題」の、ひとつの答えがこれです。

Advanced Connector Policy（ACP）の検討材料

ACPは、認定コネクタを厳格な許可リスト方式で管理する次世代のコネクタガバナンス機能で、GAが段階的に進んでいます。ポリシー適用前の影響調査に、今回のクエリがそのまま使えます。

⚠️ ACPの対象範囲に注意: 2026年6月時点で、ACPは「認定コネクタ」が対象です。カスタムコネクタやHTTPコネクタはまだ対象外で、これらは当面クラシックなデータ損失防止（DLP）ポリシーでの管理になります。今回見つけたClaude APIは「カスタムコネクタ」なので、その点は混同しないようにしてください。今回の横断クエリは、DLP・ACPのどちらのポリシー検討においても、影響範囲調査の実例として活用できます。

野良エージェント・属人化リソースの発見

無効化された接続（isEnabled: false）もAPIレスポンスに含まれるため、設定ミスや使われていない接続の発見に役立ちます。また、MCPサーバー接続も type: "MCP" として識別できます。作成者以外には見えにくかったリソースの実態を、棚卸しの形で可視化できるわけです。

📋 仕様メモ
・正式名称: Power Platform Inventory（コネクタ列／Connectors column）
・リリース状態: パブリック プレビュー
・リリース日: 2026年6月2日（パブリック プレビュー開始）
・アクセス要件: Power Platform 管理者 または Dynamics 365 管理者ロール
・関連コネクタ: Power Platform for Admins V2（操作「Power Platform リソースのクエリを実行する」／QueryResources）
・APIバージョン: 2024-10-01（Power Platform inventory API）
・参考: https://learn.microsoft.com/power-platform/admin/power-platform-inventory ／ https://learn.microsoft.com/power-platform/admin/inventory-api

まとめ・今後の展開（GA時期は要追跡）

このセクションでは、今回の検証の振り返りと、今後ウォッチすべきポイントをまとめます。

今回やってみて感じたのは、「UIは一覧性、APIは深さ」という役割分担がハッキリしているな、ということです。コネクタ列で全体をざっと俯瞰しつつ、深い分析が必要なところはフロー（API）で掘る。この使い分けがコツですね。

一方で、制約も見えました。配列フィールドの正式な展開集計は、現時点では対応する句が確認できていません。今回はtostring()＋containsの部分一致で代替しましたが、このあたりは今後のアップデートで改善されるか、引き続き追いかけたいところです。GA時期の情報とあわせて、また続報をシェアします。

💡 検証の余地メモ:powerPlatformConnectors フィールドは、Copilot Studioエージェントとクラウドフローでの存在は確認済みです。Power Apps（キャンバスアプリ／モデル駆動型アプリ）単体での存在は今回未検証なので、ここは別途検証の余地があります。

まずは、みなさんのテナントでインベントリの「コネクタ列」を有効にするところから試してみてください！そこから先のクエリは、本文で案内した公式ドキュメントを片手に進めれば、回り道せずにたどり着けるはずです。

ちなみにこの記事の内容はYouTubeでも配信しています。
動画で見たいよという方はこちらをチェックしてみてください。

それでは皆さん、良い業務ハックライフを〜！

コメント