Power Automate も Power Apps も Azure Logic Apps も、Dataverse に対しては同じ Web API を叩いている。
「このツールではできない」と止まるとき、問題は API に届いていないことではなく、そのコネクタが必要な機能を露出しているかどうかに 9 割ある。
壁の正体を理解すれば、問い直すべき場所が変わる。
全ツールが同じ API に届いている
Dataverse の入口は、すべてのツールで共通だ。Power Automate のコネクタも、Power Apps のフォームも、Azure Logic Apps のアクションも、最終的には Dataverse Web API（OData v4 実装） を経由してサーバーと通信する。
この構造は公式ドキュメントで裏付けられている。Dataverse Web API は「Organization service のすべてのメッセージを functions/actions として露出している」（Microsoft Learn: Web API types and operations, 2025 年時点）。コードで直接 Web API を呼べば、サーバーが持つ全操作にアクセスできる。
コネクタの内部も同様だ。「Connectors create a proxy or wrapper around an API that allows the underlying App Service Environment to talk to Microsoft Power Automate, Power Apps, Azure Logic Apps and Power BI」（dev.to/wyattdave: The 4 APIs of the Power Platform）。コネクタは直接の接続ではなく、Azure APIM（API Management）を経由した OpenAPI ラッパーとして機能する。すべてのコネクタホストは、この APIM 経由で同一の Dataverse バックエンドに到達している。
つまり、「Power Automate は Dataverse の API に届いていない」という問いの立て方は、最初から的を外している。
サーバーは全集合、コネクタは部分集合
問題は API の手前ではなく、コネクタという抽象化層が何を露出しているかにある。
レストランで例えるなら、厨房（Dataverse サーバー）はメニュー全品を作れる。ただし、各テーブル係（コネクタ）が持ってくる注文票（OpenAPI 定義）に書かれた項目しか頼めない。厨房が何を作れるかではなく、そのテーブル係がどこまで注文を受けるかで、食べられるものが決まる。
2026 年 6 月時点で、Power Automate の Dataverse コネクタが露出しているアクションは 12 件、トリガーは 3 件だ（Microsoft Docs: connect-to-other-environments.md, 2025 年 4 月更新）。
| カテゴリ | 操作 |
|---|---|
| 行の CRUD | Create a new row / Update a row / Get a row / List rows / Delete a row |
| 検索 | Search rows with relevance search |
| 関連付け | Relate rows / Unrelate rows |
| バッチ | Execute a changeset request |
| ファイル | Download file or image content / Upload file or image content |
| カスタム | Perform bound and unbound actions |
これは Dataverse Web API が持つ全操作セットの部分集合だ。バルク削除、ソリューション管理、カスタム API の直接呼び出しなどは、コネクタの外にある。コードで Web API を直接叩いたときだけ、それらの全集合に届く。
GUI 同士でも露出が違うのは製品判断
「GUI ツール同士なのになぜ差が出るのか」という疑問は自然だが、答えは技術的制約ではない。コネクタチームが何を実装・露出したかという製品判断で決まっている。
同じコネクタ ID（commondataserviceforapps）を Power Automate と Azure Logic Apps は共有している。それでも「When a row is selected」トリガーはPower Automate 専用で、Logic Apps では使えない。公式ドキュメントで “available only for Power Automate” と明記されている。同じ ID を持ちながら、ホストによって露出が異なる。これは技術的な限界ではなく、コネクタ定義側の判断だ。
Power Apps は事情が異なる。「Power Apps doesn’t use a connector to work with Dataverse. It connects directly to Dataverse outside of the connector framework.」（Microsoft Docs: dataverse-canvas-app.md, 2025 年確認）。Canvas App は APIM を経由せず、Dataverse バックエンドに直接接続している。コネクタの制約を受けない代わりに、その最適化の複雑さは Power Apps 側が吸収する。
露出機能はバージョン更新で変わる——壁は今日の壁とは限らない
「このツールでは無理だと聞いた」という情報も、いつの時点の話か確認が必要だ。コネクタの露出機能は更新で実際に変化してきた。
| 時期 | 変更内容 |
|---|---|
| 2020 年 5 月 | Dynamics 365 connector 非推奨発表 |
| 2022 年 8 月 | 現行 Dataverse コネクタへの移行完了。「Search rows」「Execute changeset」「Upload/Download file」等が追加 |
| 2022 年 10 月 | Dataverse (Legacy) が新規 Logic Apps で使用不可 |
| 2022 年 10 月 31 日 | Dynamics 365 connector が Power Automate / Canvas Apps で完全無効化 |
| 2023 年 10 月 | “selected environment” アクション（クロス環境操作）Preview 開始 |
| 2025 年 4 月（doc 更新） | “selected environment” アクション GA。ただし「Search rows」「Perform a changeset」は Environment パラメータ未対応が継続明記 |
出典：Microsoft Docs: important-changes-coming.md / power-platform/blog 2023 年 10 月 26 日
2022 年の移行で追加された「Search rows」も、2025 年 4 月時点では “selected environment” バリアントでは動かない。「追加された」と「すべての文脈で使える」は別の話だ。現在の制約を確認するには、最新の公式ドキュメントを見るしかない。
壁に当たったときの 3 段問い直し
「このツールではできない」と感じたとき、問いを 3 段階に分解すると判断が速くなる。
① サーバーはその機能を出しているか
Dataverse Web API が持つ operations（functions/actions）の一覧は、Microsoft Learn: Web API types and operations で確認できる。ここにない機能は Dataverse 側の制約だ。あれば次の問いに進む。
② どの表面（コネクタ・直接接続）がその機能を露出しているか
Power Automate の 12 アクションに含まれないなら、Logic Apps / Power Apps / Web API 直呼びで対応できるか確認する。Power Apps の直接接続（コネクタフレームワーク外）や Custom Connector の作成、Azure API Management ラッパーの構築も選択肢に入る。
③ どれだけの責任を引き受けるか
コードで Web API を直接呼べば全操作に届くが、エラーハンドリング、再試行ロジック、認証管理、監査ログ——コネクタが吸収していた責任をすべて自前で実装することになる。また「Dataverse builds on top of 25+ services, including Azure SQL, Azure Cosmos DB, and Azure Storage」（codemag.com, 2023）という多層スタックの上で動く API を扱う以上、操作の副作用の把握も書き手の仕事になる。
この 3 段を問い直した後、「最も薄い適切な層」を選ぶ。目的に必要な機能を露出している表面の中で、引き受ける責任が最小のものが、今の設計に適したツールだ。
「コードで直接書けば全部できる」は半分正しく、半分の話
「コネクタの制限があるなら全部コードで書けばいい」という発想は半分正しい。Web API を直接叩けば全集合に届くのは事実だ。ただし、その全集合が意味するのは権限だけではない。
Dynamics 365 connector が 2022 年 10 月 31 日に Power Automate / Canvas Apps で完全無効化されたとき、そのコネクタ経由で動いていたフローは全停止した。コネクタが吸収していた互換性維持の責任が、その日に利用者側へ転嫁された。コードで直接書いた場合、同様の変更があったとき、追随も自分の仕事になる。
コネクタを使う選択は、制限を受け入れる代わりにコネクタチームが負う保守責任に乗る選択でもある。全集合に届く自由と、その自由に付随する保守コストは、セットで評価する必要がある。
まとめ
Dataverse コネクタの能力差は、API へのアクセス可否ではなく、各コネクタ（抽象化層）がサーバー機能をどこまで露出しているかという製品設計の差だ。壁に当たったとき最初に問うのは「不可能か」ではなく「サーバーはこの機能を持っているか、どの表面が露出しているか、その責任を引き受けられるか」の 3 段だ。
次の一歩：まず Microsoft Learn の「Dataverse Web API types and operations」で、目的の操作が Web API として存在するかを確認する。次に Power Automate コネクタの最新アクション一覧（connect-to-other-environments.md）と照合する。差分があれば Custom Connector か Web API 直呼びが選択肢に入る。
→ 関連記事：Dataverse 取込ツールを能力 2 軸で選ぶ——「緑（成功）」は行セキュリティの着地を保証しない
→ 関連記事：Power Platform：抽象度と制御権の全体像