「共同所有者として共有したのに、なぜメールが送れない？」
この問いに答えるには、権限の問題が2つの独立したレイヤーに分かれていることを理解する必要がある。
Exchange Online 側の Send As 権限と、Power Platform 側の Environment Maker ロール——この2つが揃ってはじめて、フローの完全な引き継ぎが成立する。
2つの権限レイヤーが存在する理由
Power Automate のフローが「共有メールボックスからメールを送信する」動作をしている場合、権限は2か所で管理されている。
| レイヤー | 管理場所 | 必要な権限 |
|---|---|---|
| Exchange Online（メール送信） | Exchange 管理センター (EAC) | Send As（代理送信） |
| Power Platform（フロー操作） | Power Platform 管理センター | Environment Maker ロール |
Exchange Online の Send As（代理送信）は、あるユーザーが共有メールボックスから「その共有メールボックスが送ったもの」としてメールを送れる権限だ（公式定義）。これは Power Platform の権限体系とはまったく独立した管理系で動いており、Power Platform 側でどれだけ権限を付与しても、Exchange 側の Send As がなければ共有メールボックス経由の送信は機能しない。
Power Platform 側の Environment Maker ロールは、環境内でアプリ・接続・フローを作成する権限を付与する（公式定義）。「共同所有者として共有」の操作だけでは、このロールは付与されない。
「共同所有者として共有」だけで止まってしまう落とし穴
2025年6月以降、環境メンバーでないユーザーと共有されたフローはそのユーザーからアクセスできなくなった（Microsoft Learn）。つまり「共有しただけ」の引き継ぎは、制度上も機能しなくなっている。
しかし問題が表面化しにくい理由がある。共同所有者の権限では、フローの実行履歴閲覧・起動・停止・デザイン編集が可能だ（公式）。軽微な文言修正程度なら動いてしまう。だから「引き継ぎできた」と誤解したまま運用が続き、接続切れや本格的な構造変更が必要になったタイミングで初めて問題が露出する。
Connection Reference（接続参照）と Environment Maker の関係
ソリューションとして管理されている Power Automate フローは、接続を「Connection Reference（接続参照）」というソリューションコンポーネントを通じて参照する（公式）。非ソリューションフローとの根本的な違いはここだ。
引き継ぎ担当者が Connection Reference に対する接続を設定・更新するには、Connection Reference テーブルへの書き込み権限が必要になる。Environment Maker ロールのみではこのテーブルへの「ユーザーまたはチームレベル」のアクセス権にとどまる（公式）。
実際の制約は次のとおりだ。
| 操作 | 共同所有者のみ | Environment Maker ロール付与後 |
|---|---|---|
| フローのデザイン編集 | 可 | 可 |
| 既存 Connection Reference の接続を更新 | 不可なケースあり | 可（ほとんどのケース） |
| 新しい Connection Reference を作成 | 不可 | 環境設定によっては不可（System Customizerロールが追加で必要なケースあり） |
重要な留保として、新しい Connection Reference の作成に関しては Environment Maker ロールだけでは不十分な環境設定もある。ソリューション内で Connection Reference を新規作成する場合は、System Customizerロールの追加が必要なケースを想定しておくことが安全だ。
接続切れ（パスワード変更後の再認証）への対応
接続切れが発生したとき、必要な操作は状況によって2つに分かれる。
既存接続の認証情報を更新する（共同所有者でも可）
共同所有者には「接続の管理（認証情報の更新を含む）」が可能とされている（公式）。パスワード変更後に既存の接続情報を再入力して更新するだけなら、この操作で対応できる。
Connection Reference の接続を再設定・新規作成する（Environment Maker ロールが必要）
接続自体を作り直したり、Connection Reference に紐づく接続を別アカウントの接続に切り替えたりする場合は、Environment Maker ロールが必要になるケースがある。
「パスワードを変えただけなのに、更新できない」という状況では、自分が Environment Maker ロールを持っているかを最初に確認する。これが接続切れ対応で最初に見落とされるポイントだ。
Exchange Send As 権限の付与手順
共有メールボックスからメールを送るフローを引き継ぐ場合、Exchange 管理センター（EAC）での操作が必要になる。
EAC での手順
- EAC で「受信者」→「メールボックス」を開く
- 対象メールボックスを選択し「委任」タブを開く
- 「代理送信」セクションの「編集」をクリック
- 「アクセス許可を追加」で引き継ぎ担当者を選択して保存
Microsoft 365 管理センター経由の手順
- Microsoft 365 管理センターで「ユーザー」→「アクティブなユーザー」（または「共有メールボックス」）
- 対象メールボックスのページを開き「メールの送信」設定から引き継ぎ担当者を追加
反映時間
Send As 権限の設定後、変更が有効になるまで最大60分かかる可能性がある（公式）。稀に24時間を超えるケースも報告されているが、公式の主要数値は「最大60分」だ。設定直後に「まだ動かない」という状況でも、60分は待ってから再確認する。
なお「Send As（代理送信）」と「Send on Behalf（代理で送信）」は別物だ。後者は受信者の受信トレイに「○○の代理で」と送信者名が表示される。共有メールボックスから送信者情報を隠したい場合は Send As を使う。
フロー引き継ぎ完全チェックリスト
引き継ぎ前にこれをすべて確認する。1項目でも欠けると、後から問題が表面化するリスクが高い。
Power Platform 側
- 引き継ぎ担当者が対象環境のメンバーになっているか（2025年6月以降の必須要件）
- 引き継ぎ担当者にEnvironment Maker ロールが付与されているか
- フローがソリューション内に含まれているか（非ソリューションフローの場合は別途確認）
- ソリューション内のConnection Referenceの接続が引き継ぎ担当者の認証情報で動作するか
- 新しい Connection Reference の作成が必要な場合、System Customizer ロールの追加も検討したか
- 元の所有者が退職・異動する場合、フローのプライマリ所有者の変更が完了しているか
Exchange Online 側
- 共有メールボックスから送信するフローがある場合、引き継ぎ担当者（または実行アカウント）にSend As 権限が付与されているか
- Send As 権限付与後、最大60分の反映待機を見込んでいるか
- 使用しているのが「共有メールボックスからメールを送信する (V2)」アクションか（公式推奨アクション）
引き継ぎ後の動作確認
- フローを手動実行して、正常に動作するか確認したか
- 共有メールボックス経由のメール送信が「共有メールボックスから送られたもの」として届くか確認したか
- 接続の認証情報を意図的にリセットして、引き継ぎ担当者が自力で更新できるか確認したか
ベストプラクティス：サービスアカウントへの権限集約
担当者の退職や役割変更のたびに権限設定をやり直すコストは、案件が増えるほど無視できなくなる。
Microsoft 公式の推奨では、業務上重要なフローにはサービスアカウントまたはサービスプリンシパルをプライマリ所有者として設定することが推奨されている。個人アカウントをフローの所有者にした場合、その人が退職した瞬間にフローが停止するリスクがある。
設計の基本パターンはこうだ。
- フローのプライマリ所有者：サービスアカウント（またはサービスプリンシパル）
- メンテナンス担当者：共同所有者として追加
- Exchange 側 Send As 権限：サービスアカウントに付与
担当者が変わっても、サービスアカウントへの権限を引き継がせる設計にしておけば、Send As の再付与も Environment Maker ロールの再付与も不要になる。
チェックリスト対応の都度対応から、この設計への移行を、担当者の入れ替わりが繰り返されるようになったタイミングで検討することを勧める。
個人テナント（Microsoft 365 Developer Program で無料取得可能）で環境を作り、引き継ぎシナリオを事前に試しておくと、本番環境での作業が確実に速くなる。
→ Power Platform の環境設計・ガバナンス全体については「Power Platform 社内申請ワークフロー設計の判断軸」も参照。
まとめ
Power Automate フローの引き継ぎは、Exchange Online と Power Platform という2つの独立した権限レイヤーを、それぞれ正しく設定してはじめて完結する。
次の一歩：Power Platform 管理センターで引き継ぎ担当者のロールを確認し、Environment Maker が付与されているかをまず見る。Exchange 側の Send As は EAC または Microsoft 365 管理センターで別途確認する。2か所を同時に確認する習慣をつけると、引き継ぎ案件での手戻りはほぼなくなる。