担当者の退職で Power Apps / Power Automate はどう壊れるか — フローの所有者変更・接続・Dataverse 所有権の引き継ぎチェックリスト

退職は突発事故ではありません。少なくとも2週間前、たいていは1ヶ月以上前に分かっている予定されたイベントです。

それなのに、Power Platformの現場では退職のたびにシステムが壊れます。「あの人が辞めてからフローが動かない」「このレコード、退職した人が所有者のままなんだけど」。私はこの光景を何度も見てきました。

壊れるのは、何が退職者に紐づいているかを誰も把握していないからです。この記事では、退職・異動で壊れるものを整理し、引き継ぎチェックリストと、そもそも壊れない事前設計をまとめます。

退職で壊れるもの5つ

1. レコードの所有権（Owner）

退職者がOwnerのレコードは、本人がいなくなっても残り続けます。Dataverseの標準では、レコード作成者がそのままOwnerになるため、長く働いた人ほど大量のレコードを「所有」したまま去ります。

これ自体ではすぐにエラーは起きません。だからこそ放置され、「このレコード誰のだっけ」が半年後の会議室で繰り返されることになります。この問題の根本はDataverse の所有者を個人にするなで書いたとおり、Ownerを個人にする設計そのものにあります。

2. Power Automateフローの所有者

退職者が作ったクラウドフローは、本人のアカウントに紐づいています。アカウントが無効化されると、所有者のいないフローが残ります。共同所有者が設定されていれば管理は継続できますが、ソロ所有のフローは「中身を確認できる人がいない」状態になります。

業務部門が善意で作った「野良フロー」ほど、この問題を踏みます。どこに何のフローがあるか、ITサイドが把握していないからです。

3. コネクション（これが一番怖い）

フローの所有権よりも先に業務を止めるのが、コネクション（接続）の失効です。

フロー内のDataverseコネクタ、Outlookコネクタ、SharePointコネクタは、作成した人の認証情報で動いています。退職者のアカウントが無効化されると、そのアカウントで張られたコネクションは認証エラーになり、フローは次の実行から失敗し始めます。

しかも、コネクションは他人に「移管」できません。フローの所有権を引き継いでも、中のコネクションは新しい所有者のものに張り替える作業が必要です。フローが10本あれば10本ぶん、中のアクションを開いて接続を差し替えることになります。

4. アプリの所有者と共有設定

キャンバスアプリ・モデル駆動型アプリにも所有者がいます。退職者が所有していたアプリは、編集できる人がいなくなる（または管理者による所有者変更が必要になる）状態で残ります。本人が個人的に共有していたアプリの共有設定も、棚卸しされないまま残ります。

5. 管理権限とセキュリティロール

環境管理者、システム管理者ロール、特定のチームのメンバーシップ。退職者がどの権限を持っていたかが記録されていないと、「あの操作はあの人しかできなかった」が退職後に発覚します。逆に、本人の権限が残り続けるのはセキュリティ監査上の問題です。

退職が決まったらやること（チェックリスト）

時系列で並べます。ポイントは、アカウント無効化の前にやるべき作業が大半だということです。

退職2週間前まで

退職者が所有するクラウドフローを棚卸しする（Power Platform管理センターの環境 → リソース → フローで所有者から確認できます）
各フローに後任者を共同所有者として追加する（本人が在籍中なら本人の操作で済み、最も確実です）
退職者が所有するアプリを棚卸しし、共同所有者を追加する
退職者がOwnerのレコード件数をテーブルごとに確認する（高度な検索またはビューで所有者フィルター）
本人にしか分からない設定・手順（採番ルールの意図、帳票テンプレートの修正方法など）をヒアリングして文書化する

最終出社日まで

フロー内のコネクションを後任者の接続に張り替える（共同所有者になった後任者が、各フローの接続を自分のものに差し替えて保存し、テスト実行する）
退職者がOwnerのレコードを移管する（一括で後任者またはチームに割り当て）
管理権限・セキュリティロールの棚卸しと、後任者への付与

アカウント無効化後

主要フローの実行履歴を1週間監視する（接続エラーが出ていないか）
退職者のロール・チームメンバーシップを削除する
共有設定に残っている退職者を整理する

標準機能の限界 — 「一括移管」はできる、でも「誰に」が分からない

レコードの所有権は、管理者権限があれば一括で再割り当てできます。機能としては困りません。

困るのは判断のほうです。退職者が3,000件のレコードを所有していたとして、そのうちどれを誰に引き継ぐべきかは、Owner列を見ても分かりません。Ownerは「作った人」であって「現在の担当者」ではないからです。

結局、後任者が1件ずつ中身を見て判断するか、「とりあえず全部課長に」のような雑な移管をして、本当の担当が分からないレコードが量産されます。これは引き継ぎ運用の問題ではなく、担当者という業務上の概念をOwnerという技術上の概念に背負わせた設計の問題です。

事前の設計で、退職を無痛にする

退職のたびに上のチェックリストを全部回すのは大変です。設計段階で次の3つを入れておくと、退職対応は劇的に軽くなります。

1. Owner はチーム、担当者はカスタム列

レコードのOwnerは部署別チームに固定し、担当者はカスタムのルックアップ列で持つ。退職時の作業は「担当者列の付け替え」だけになり、所有権の移管は発生しません。設計の詳細はこちらの記事に書きました。

2. 業務フローは個人アカウントで所有しない

業務の基幹になるフローは、個人ではなくサービスアカウント（共有用のアカウント）所有に寄せ、コネクションもサービスアカウントで張る。本格的にやるなら、Dataverse接続はサービスプリンシパル（アプリケーションユーザー）化し、ソリューションの接続参照で管理します。少なくとも、共同所有者を2名以上にするルールだけでも先に入れるべきです。

3. 「誰が何を持っているか」を定期的に棚卸しする

四半期に1回、環境内のフロー・アプリ・管理権限の所有者一覧を確認する運用を入れます。退職が決まってから調べるのではなく、平時から台帳がある状態にしておく。退職対応は「台帳どおりに引き継ぐだけ」になります。

まとめ

退職で壊れるのは、レコード所有権・フロー所有・コネクション・アプリ共有・管理権限の5つ
特にコネクションは移管不可で、アカウント無効化と同時にフローを止めます。在籍中の張り替えが必須です
チェックリストの大半は「アカウント無効化の前」にしかできません。退職が分かった時点で動き始めてください
根本対策は事前設計です。チーム所有+担当者列、フローのサービスアカウント所有、定期棚卸し

「退職者のフローが止まった」「所有者が退職者のままのレコードが大量にある」という状況からの立て直しもよくやっています。現状の棚卸しから始めたい方は、無料の診断でお手伝いできますので、お気軽にどうぞ。