Power Automate で「接続の新規作成だけ弾かれる」理由——Connection Reference と Environment Maker ロールの関係

接続の切り替えは通るのに、新規作成だけ失敗する。このエラーの原因は画面操作の問題ではなく、Connection Reference という Dataverse テーブルへの書き込み権限が Environment Maker ロールに紐づいているという構造にある。この構造を理解せずに「既存接続への切り替えで凌ぐ」運用を続けると、新規接続が必要になった瞬間に必ず詰まる。

前提：本記事は Power Platform 環境（M365 または Dataverse あり）でフローの引き継ぎ・接続設定を担う立場の話。Basic User ロールのみ付与されたユーザー環境での動作が出発点。

接続と Connection Reference は別物——権限が分かれる場所

Power Automate では「接続（Connection）」と「接続参照（Connection Reference）」が別の概念として動いている。この分離を把握していないと、エラーメッセージの意味がつかみにくい。

**接続（Connection）**は、コネクタへのサインインで生成される認証トークンのセット。Outlook や SharePoint へのサインインを完了した時点で、接続自体は作成される。この操作は Basic User ロールでも実行可能で、「接続の切り替え（既存接続を別の接続に変更する）」もここで完結する。

**接続参照（Connection Reference）**は、フローやアプリがコネクタに直接バインドせず間接的に参照するための中間レイヤーで、Dataverse の connectionreference テーブルに格納されるリソースだ（Microsoft Learn 公式エンティティリファレンス、2024年）。新規コネクタをフローに追加したとき、または新規フローを作成したときに、この Connection Reference が Dataverse テーブルへ新規書き込みされる。

Dataverse テーブルへの新規書き込みには、Environment Maker ロールが必要になる。接続トークンは作れる。しかし Connection Reference という Dataverse レコードを新しく作る権限がない——それが「切り替えは通るのに新規作成だけ弾かれる」現象の構造的な理由だ。

Environment Maker と Basic User、権限の実質的な差

「Environment Maker（環境作成者）」という名称は直感的にわかりにくい。実態は「環境上で新しいリソースを作成できるロール」であり、接続・フロー・アプリ・カスタム API がすべてその対象に含まれる（Microsoft Learn「Role-based security roles for Dataverse」2024年）。

表を見ると、Basic User は「既存リソースを動かす」ためのロールであり、「新しいリソースを作る」ためには設計されていない。一方で Environment Maker は「作成」に特化しており、皮肉なことに Dataverse データへのアクセス権は持たない（データアクセスには System Customizer や Business Unit 単位のセキュリティロールが別途必要になる）。

引き継ぎ作業でよくある誤解として「サインインして接続が見えているから使えるはず」というものがあるが、「見える（Read 権限）」と「新しく作れる（Create 権限）」は別の話だ。

裏口ルートが破綻するタイミング

Environment Maker ロールが付与されていない状態でも、既存の Connection Reference への接続切り替えは通る。このため「切り替え操作で何とかなっている」状態が続くことがある。

ただしこれは、すでに誰かが作成した Connection Reference が環境内に存在しているから動いているに過ぎない。以下のタイミングで必ず詰まる。

• 新しいコネクタをフローに追加するとき（既存 Connection Reference が存在しないため、新規作成が必要になる）
• 新規フローを作成して接続するとき（フロー自体が新規 Connection Reference の生成を伴う）
• 環境移行・ソリューションインポート時に接続を再設定するとき

コミュニティ報告（Sharepains.com、2026年2月・5月）でも、「既存編集の範囲内では問題なかったが、新規コネクタ追加で突然 Create 権限エラーになった」というパターンが多く報告されている。「今日は動いている」は「常に動く」を意味しない。

正しい対処：最初から Maker ロールを付与するためのチェック

問題の根本はロールの欠落なので、対処は設計段階で行うのが正解だ。引き継ぎ後に権限エラーが出てから対処すると、フロー停止・再設定・テストの工数が重なる。

引き継ぎ・接続設定前に確認するチェックリスト

• 作業するユーザーに Environment Maker ロールが付与されているか（Power Platform 管理センター → 環境 → ユーザー → セキュリティロール）
• 引き継ぎ先がソリューション管理フローか、マイフロー（非ソリューション）かを確認した
• 新規コネクタを追加する予定がある場合、Maker ロール付与を事前に管理者に依頼した
• 既存 Connection Reference への「切り替え」で凌いでいる運用が現状にないか確認した
• Dataverse データへのアクセスが必要な場合は、Maker ロールに加えて System Customizer またはカスタムセキュリティロールが必要であることを確認した（2026年時点の仕様）

ロールの付与は Power Platform 管理センターから行う。テナント管理者またはシステム管理者権限が必要になるため、フリーランス・外部委託の立場で作業する場合は、クライアント側管理者への依頼を引き継ぎスコープに含めておくことを推奨する。なお Environment Maker はリソース作成全般を許可するロールであるため、作業完了後に最小権限への見直しを管理者と合意しておくと過剰権限の積み上がりを防ぎやすい。

Send As は Exchange の話——接続エラーと混同しない

Outlook コネクタを使う設定で「代理送信（Send As）」が絡むと、接続権限エラーと混同されやすい。ここは明確に分けて理解しておく。

Send As 権限は Exchange Online のメールボックスレイヤーで管理される。Power Platform の Environment Maker ロールや Dataverse セキュリティロールとは構造的に独立した別レイヤーであり、付与する管理者も権限の適用範囲も異なる（Microsoft Learn「Manage permissions for recipients in Exchange Online」2024年）。

「共有メールボックスからメールを送れない」というエラーが出たとき、まず確認すべきは接続アカウントの Send As 権限が Exchange 側で付与されているかどうかだ。Maker ロールを付与しても Send As は解決しない。逆に Send As を付与しても接続新規作成のエラーは解消しない。

Send As 権限の反映は、Exchange Online（クラウド環境）では通常数分以内に完了し、遅くとも最大 30 分程度で反映される（コミュニティ報告の傾向値）。オンプレミス Exchange Server は別製品のため参考値として扱う。

フローの引き継ぎ全体（所有者変更・接続再設定・ロール付与）をチェックリスト形式で整理した記事は「Power Automate フロー引き継ぎの2層権限チェックリスト」にまとめている。本記事はそのメカニズム解説として機能する。

まとめ

Power Automate で「接続の切り替えは通るのに新規作成だけ弾かれる」のは、Connection Reference が Dataverse テーブルへの新規書き込みを必要とするためであり、その Create 権限は Environment Maker ロールにのみ付与されている——この構造を把握していれば、引き継ぎ設計の段階でロール付与を先手で要件に含められる。

次の一歩

1. Power Platform 管理センターで対象ユーザーのセキュリティロールを確認する（環境 → ユーザー → セキュリティロール）
2. 新規コネクタ追加・新規フロー作成が発生するなら、事前に Environment Maker ロール付与を管理者に依頼する
3. Outlook コネクタで代理送信が絡む場合は、Exchange 管理者への Send As 付与依頼を別件として立てる

関連記事

• Power Automate フロー引き継ぎの2層権限チェックリスト