合同会社小村ソフト
相談する
メニュー

Power Automateの属人化対策 ── 作った人が辞めてもフローが止まらないために

· · Power Automate, 属人化, 引き継ぎ, 運用保守, ガバナンス, Microsoft 365, 業務自動化, 技術相談

「Power Automateに詳しい社員がいて、社内のあちこちの業務を自動化してくれた。ところがその人が来月退職することになり、どのフローが何をしているのか誰も分からない」── こういう相談が、最近目に見えて増えています。すでに退職済みで、「先月から注文の通知メールが届かなくなったが、直せる人がいない」という段階で持ち込まれることもあります。

以前「ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順」という記事で、作った人がいなくなったシステムの引き継ぎを扱いました。Power Automateのフローはノーコードで作れる分だけ同じ状況がさらに起きやすく、しかも実行ファイルのように「そこに在り続ける」保証がありません。フローは作成者のアカウントと接続(コネクション)に強く紐づいており、アカウントが無効化・削除された瞬間に壊れ方が変わるからです。この記事では、所有者がいなくなったときにフローがどうなるのかという事実関係をMicrosoftの公式ドキュメントで確認しながら、退職前にやるべきこと・退職後にできること・そもそも属人化させないための棚卸しと実行アカウントの設計を、中小企業の実務の順番で整理します。

1. まず結論

  • フローは作成者が所有者になり、実行に使う接続(SharePointやOutlookへの認証)は作成した本人のアカウントに紐づきます。共有された接続はそのフローの中でしか使えず、他人が作った接続の資格情報は共同所有者でも変更できません。1
  • 所有者が退職しても、共同所有者が残っていればフロー自体は動き続けます。ただし退職者の接続を使うアクションは失敗するようになるため、接続の差し替えが必要です。12
  • 有効な所有者が誰もいないフローは「孤立フロー(orphaned flow)」になります。管理者はPower Platform管理センターの環境ページ(リソース→フロー)で発見し、「共有」から新しい所有者を追加できます。PowerShell(Get-AdminFlow、Set-AdminFlowOwnerRole)での一括処理も可能です。2
  • 退職前なら「共同所有者の追加」と「所有者の変更」の2段構えです。所有者の付け替え(在籍中の引き継ぎ)はソリューション対応フローでのみ可能で、非ソリューションフローはソリューションへの追加かエクスポート/インポートで作り直します。34
  • 通知メールが本人名義で飛び続ける問題は、共有メールボックスからの送信(「共有メールボックスからメールを送信(V2)」アクション)に寄せておくと退職の影響を受けません。Microsoftのガイダンスも、定型的な通知は個人名義でなく共有の送信元を使うことを推奨しています。56
  • ユーザーアカウント共用型のサービスアカウントはベストプラクティスとしては非推奨で、ミッションクリティカルなフローはサービスプリンシパル所有が公式の推奨です。ただし中小企業では設定・ライセンスのハードルがあるため、この記事の5章で現実的な使い分けを整理します。478
  • 対策の第一歩は技術ではなく棚卸しです。社内にどんなフローがあるかを管理センターとGet-AdminFlowで一覧化し、最低限のフロー台帳(名前・目的・所有者・接続・影響業務)を作ることから始めます。9

2. フローの属人化はどう起きるか

Power Automateの属人化は、悪意や怠慢からではなく、善意の積み重ねで起きます。典型的な経過はこうです。

  1. 現場の詳しい人が、自分の作業を楽にするためにフローを作る。「Formsの回答をExcelに転記する」程度の小さなものです。
  2. 便利なので周囲が乗ってくる。「その通知、うちの課にも送って」「注文書の保存もできない？」と要望が集まり、フローが増え、育ちます。
  3. いつの間にか業務の基幹に入り込む。受注の一次連絡、請求書の保存、承認の回付といった「止まると業務が滞る」処理が、その人の個人アカウントのフローで回るようになります。
  4. 誰も中身を知らないまま安定稼働する。動いているものを触る理由がないので、引き継ぎもドキュメントも作られません。「動いているから触れない」がそのまま「誰も触れない」に変わります。

ここまでの構図は、開発担当者の退職でソースも仕様書もないシステムが残る話と同じです。ただしPower Automateには、レガシーシステムより厄介な点が2つあります。第一に、作られる場所が個人の「マイフロー」であり、本人以外からは存在自体が見えないこと。サーバーに実行ファイルが残るシステムと違い、フローは棚卸ししない限り一覧にすら出てきません。第二に、フローの実行が作成者のアカウントと接続に依存していることです。退職処理でアカウントを無効化・削除した瞬間、影響が顕在化します。次章でこの挙動を正確に確認します。

3. アカウントが消えるとフローはどうなるか

フロー自体は消えないが、「孤立フロー」になる

まず前提として、退職者のアカウントをMicrosoft Entra IDから削除しても、その人が作ったフローは自動では削除されません。フローと接続は「管理者が手動で確認・削除するもの」に分類されており、勝手に消えることはない一方、実行履歴はアカウント削除で自動的に削除されます。過去の実行記録を証跡として当てにしている場合は注意が必要です。10

フローが残っても、有効な所有者が1人もいなくなったフローは孤立フロー(orphaned flow)と呼ばれる状態になります。Microsoftのサポート文書は、孤立フローを「有効な所有者がいないフロー」と定義し、退職したユーザーのアカウントに紐づく接続を使っている場合、フローが失敗し得ると明記しています。2

接続が本人のアカウントに紐づいている

ここが一番の急所です。フローの各アクションが使う接続(SharePoint、Outlook、Teams等への認証)は、作成したユーザーの資格情報で動いています。共有フローの作成者が退職した場合の公式FAQは、次のように整理しています。1

  • 共同所有者など有効な所有者が残っていれば、フロー自体は動き続ける
  • ただし、退職者名義の接続を使っているアクションは失敗し得るため、接続の資格情報を更新(実際にはフロー編集画面で各アクションの接続を別のアカウントの接続に差し替え)する必要がある

さらに、共有された接続はそのフローの中でしか使えず、共同所有者であっても他の所有者が作った接続の資格情報を変更することはできません。1 つまり「共同所有者を追加してあるから大丈夫」は半分だけ正解で、退職者の接続をフローから追い出す作業(各アクションで自分の接続に差し替えて保存)をして初めて、引き継ぎが完了します。

ライセンスの巻き添え ── 14日でオフになるケース

プレミアムコネクタなどを使うフローは、所有者のライセンスで動いています。公式のライセンスFAQによると、所有者が退職するなどしてライセンスの裏付けを失ったプレミアムフローはパフォーマンスが低下した状態に格下げされ、所有者全員に通知の上、対応がなければ14日でオフになります。4 「なんとなく遅くなった」の2週間後に止まる、という時限付きの挙動です。標準コネクタだけのフローならこの問題は起きにくいですが、どのフローがプレミアム機能を使っているかは棚卸しで把握しておくべき情報です(標準/プレミアムの境界は「Power Automateのライセンスと標準/プレミアムコネクタの境界」で整理しています)。

メールが本人名義で飛び続ける問題

見落とされがちなのが通知の「名義」です。「メールの送信(V2)」アクションは接続したユーザーのメールボックスから送信されるため、フローが動き続ける限り、通知メールは作成者個人の名義で飛び続けます。在職中は「なぜあの人から毎朝メールが？」で済みますが、退職後はアカウント無効化とともに送信自体が失敗します。逆に共同所有者が接続だけ自分に差し替えると、今度はその人の名義で全通知が飛ぶことになります。

Microsoftのガイダンスは、業務として定型化された通知を個人名義で送ることを避け、共有の送信元を使うことを推奨しています。Outlookなら「共有メールボックスからメールを送信(V2)」アクションで共有メールボックス(例: noreply-flow@例社.co.jp)から送信でき、送信履歴も共有メールボックスの送信済みフォルダーに残ります(送信にはメールボックスへのアクセス許可が必要です)。Teamsへの通知なら「フローボットとして投稿」系のアクションが同じ役割を果たします。あわせて「このメールはPower Automateから自動送信されています。問い合わせは◯◯まで」という署名を入れておくと、担当者が替わっても受信側が迷いません。56

4. 退職前にやること・退職後にできること

退職前 ── 2週間あれば間に合う

退職や異動が決まったら、次の順で進めます。

はいいいえ退職・異動が決まった本人のマイフローを一覧化業務で使われているものを特定後任・情シスを共同所有者に追加ソリューション対応フローか?詳細画面から所有者を変更ソリューションに追加して所有者変更またはエクスポート/インポートで作り直し各アクションの接続を新しいアカウントの接続に差し替え通知の送信元を共有メールボックス等へ退職者のアカウントが無効でも動くことをテスト実行で確認
  1. 本人のフローを一覧化する。マイフローの画面を本人と一緒に開き、「業務で使われているもの」「個人の効率化」「実験の残骸」に仕分けます。ここで6章のフロー台帳の初版を作ってしまうのが効率的です。
  2. 共同所有者を追加する。後任者と情報システム担当(いなければ管理者権限を持つ人)をフローの所有者に追加します。共同所有者は実行履歴の確認、フローの編集・停止・削除、所有者の追加までできます。1 なお共同所有者の追加は最低限の応急処置で、日常的な共有はできるだけ実行専用(run-only)にとどめるのが公式の推奨です。7
  3. 所有者を付け替える。ソリューション対応フローであれば、フローの詳細画面から所有者を後任者(またはサービスアカウント)に変更できます。変更後は元の所有者と新しい所有者が共同所有者になり、スケジュール実行・自動実行のフローは新しい所有者のライセンスで動くようになります(反映に最大7日。フローを開いて保存すれば即時反映)。3 非ソリューションフローは所有者がフローの識別情報の一部になっているため、その場での所有者変更ができません。Dataverseが使える環境ならソリューションに追加してから変更し、使えなければエクスポート/インポートや「名前を付けて保存」で新しい所有者の下に作り直します。34
  4. 接続を差し替える。前章の通り、ここを飛ばすと引き継ぎは完了しません。フローの編集画面で各アクションの接続を新しいアカウントの接続に切り替えて保存します。所有者から退職者を外す際も、その人の資格情報を使っていた接続の更新が必要です。1
  5. テストする。可能であれば退職者のアカウントを無効化した状態(または休暇中など本人が操作しない期間)で一巡実行し、退職後と同じ条件で動くことを確認します。

退職後 ── 管理者にできること

すでに退職済みで所有者がいない場合でも、手はあります。

  • 管理センターで孤立フローを見つける。Power Platform管理センターで環境を選び、「リソース」→「フロー」を開くと環境内のフロー一覧が表示されます。所有者(Owners)列が空のフローが孤立フローです。2
  • 「共有」から新しい所有者を追加する。一覧から対象フローを選び、「共有」で新しい所有者のアカウントを追加して保存します。2 なお、管理者がフローの中身を修正したい場合も、まず自分を所有者・共同所有者に追加するのが前提です。3
  • 数が多ければPowerShellで一括処理する。管理用モジュール(Microsoft.PowerApps.Administration.PowerShell)のGet-AdminFlow -CreatedBy <退職者のオブジェクトID>で退職者が作ったフローを列挙し、Set-AdminFlowOwnerRole -RoleName CanEditで共同所有者を付与できます。現在の権限はGet-AdminFlowOwnerRoleで確認します。2
  • 接続を作り直す。所有者を引き継いだ後、退職者名義の接続を新しいアカウントの接続に差し替えます。退職者のアカウントがすでに削除されている場合、元の接続は復旧できないので、新しい接続を作って各アクションに割り当て直すことになります。1

補足として、承認フローに限っては「承認待ちの要求が退職者に割り当たったまま」という別の詰まり方もあります。承認者側の再割り当てやエスカレーション設計は「Power Automateで承認フローを作る」の5〜6章で扱ったので、そちらを参照してください。

5. 実行アカウントの設計 ── 個人・サービスアカウント・サービスプリンシパル

引き継ぎ騒動を繰り返さないためには、「業務フローを誰の名義で動かすか」を最初に決めておくのが根本対策です。選択肢を比較します。

観点 個人アカウント サービスアカウント(共用のユーザーアカウント) サービスプリンシパル
退職・異動の影響 直撃(接続・ライセンス・名義すべて) 受けない。ただし作成者退職時にパスワード変更が必要 受けない(人に紐づかない)7
導入の手間 なし。作ればそのまま アカウント作成とライセンス割り当てのみ Entra IDアプリ登録+アプリケーションユーザー作成。IT側の知識が必要8
パスワード・MFA 本人管理 共有が前提になるのが弱点。誰が変更したか追跡しにくく、パスワード管理自体がリスク。MFAを設定すると認証手段を誰が持つかという運用問題も出る4 パスワード共有なし。シークレット/証明書の管理は必要
ライセンス 本人のライセンスで実行 ユーザーライセンスが1人分必要。多人数で資格情報を共用してプレミアム機能を使う形はライセンス違反(多重化)になり得る4 ユーザーライセンスは持てない。プレミアム機能を使うフローはProcessライセンスが必要(標準コネクタのみなら不要)8
公式の位置づけ 個人の生産性向け ベストプラクティスとしては非推奨(セキュリティリスク)4 ミッションクリティカルなフローに推奨78

実務的な使い分けの目安はこうです。

  • 個人の効率化ツールは個人アカウントのままで構いません。全部を厳格に管理しようとすると、現場の自動化そのものが萎縮します。
  • 部署が依存する業務フローは、少なくとも通知の送信元を共有メールボックスに寄せ5、共同所有者を2名以上にします。実行用のサービスアカウントを立てる場合は、権限を必要最小限にし、資格情報にアクセスできる人を数名に絞ります。Microsoft自身、サービスアカウントを使うくらいならサービスプリンシパルで、と案内していますが4、標準コネクタ中心の中小規模の運用では「専用アカウント+厳格なパスワード管理」が現実解になる場面も多いです。
  • 全社の基幹に関わるフロー(受注・請求・支払いに直結するもの)は、サービスプリンシパル所有を検討する価値があります。所有者が人でなくなるため退職の影響を受けず、所有者のライセンス剥奪でフローが止まる事故も防げます。8 ただしサービスプリンシパルは共同所有者にはなれない(所有者にする使い方のみ)、プレミアム機能にはProcessライセンスが必要、といった制約があるので、ここまで来たらIT部門か外部の専門家を交えて設計すべき段階です。8

なお、サービスアカウントを立てる場合でも、フロー作成やちょっとした修正を全部その名義でやるのは避け、作る人は自分のアカウントで作り、所有と実行だけをサービスアカウントに寄せる形にすると、「誰がいつ変更したか」の追跡可能性を保てます。

6. 棚卸しとドキュメント ── まず「何があるか」を知る

属人化対策の出発点は、社内にどんなフローがあるかを組織として把握することです。ブラックボックス化したシステムの引き継ぎで最初にやるのが実行ファイルとタスクの棚卸しだったのと同じで、フローにも棚卸しの定石があります。

フローの一覧を取る

  • 管理センターから: Power Platform管理センターの環境ページで「リソース」→「フロー」を開くと、環境内のフローが所有者付きで一覧できます。孤立フローの発見もここです。2
  • PowerShellから: 管理用コマンドレットGet-AdminFlowは、環境管理者なら管理下の全環境、全体管理者ならテナント内の全フローを返します。Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv'でそのままCSVの台帳の種になりますし、Get-AdminFlowWithHttpActionでHTTPアクションを使うフロー(外部連携している可能性が高いもの)だけを絞り込むこともできます。9 PowerShellに不慣れであれば「PowerShellコマンドの基本 ── 「使いこなす」への最初の一歩」も参考にしてください。

最小限のフロー台帳

台帳は凝らないことが長続きのコツです。SharePointリストかExcelで、1フロー1行、次の列だけ持たせます。

列 書くこと
フロー名 実際の表示名(後述の命名規則に合わせる)
目的 「何の業務の、どの作業を置き換えているか」を1〜2文
トリガー 起動条件(毎朝7時/Forms回答時/メール受信時など)
所有者・共同所有者 主担当と副担当。退職・異動時にここを見る
接続 使っているコネクタと、接続が誰のアカウント名義か
影響業務 止まったら何が困るか。手作業での代替手順があるなら一言
ライセンス プレミアムコネクタ使用の有無

ポイントは「接続が誰の名義か」の列です。所有者は管理画面で分かりますが、接続の名義はフローを開かないと分からないため、台帳に書いておく価値が最も高い情報です。

命名規則と「説明」欄

Microsoftのコーディングガイドラインは、フローの部品に説明的で一貫した名前を付け、命名規則を文書化して共有すること、コードのコメントに相当するメモをアクションに付けることを推奨しています。11 実務では、フロー名を「[部署] 業務名 - 処理内容」(例: 「[営業] FAX注文 - PDF保存と担当者通知」)のように揃えるだけで、一覧の可読性が大きく変わります。また、フローの詳細画面には説明(Description)欄があり、Copilotに下書きを生成させることもできるので12、台帳の「目的」と同じ内容をフロー自身にも持たせておくと、台帳が古びたときの保険になります。

台帳を作ると、エラーで止まったときに誰が気づくのかという次の問題が見えてきます。失敗時の通知やリトライの設計は「Power Automateのエラー処理とリトライ設計」で詳しく扱っています。

7. 環境とソリューション ── 「既定の環境に全部」から一歩出る

Power Platformには「環境」という区画があり、何も指定せずに作ったフローはすべて既定の環境(default environment)に入ります。既定の環境はテナントの全ユーザーがアクセスでき、Microsoft 365ライセンスを持つ社員なら誰でもアプリやフローを作れる場所です。個人の生産性向上の遊び場としてはそれでよいのですが、Microsoftのガイダンス自身が、既定の環境には作成者の退職による所有者不在のリソースが溜まりやすいこと、広く共有されたり業務上重要になったりしたフローは専用の環境へ移すべきことを指摘しています。13

中小企業がいきなり本格的な環境分離(開発・テスト・本番)まで整える必要はありません。ただ、次の2つは規模が小さいうちから意識する価値があります。

  • 業務の基幹に入ったフローはソリューションに入れる。ソリューションはフローとその部品をまとめて持ち運ぶための入れ物で、これに入れたフロー(ソリューション対応フロー)は所有者の変更がその場ででき、接続を「接続参照」という差し替えやすい形で持て、バージョン履歴も使えます。314 4章で見た通り、退職時の引き継ぎやすさが段違いです。利用にはDataverseのある環境が必要です。14
  • DLPポリシーを一度は確認する。コネクタを業務用/非業務用に分類し、組み合わせを制限するデータ損失防止(DLP)ポリシーは、野良フローが社内データを外部サービスへ流してしまう事故への安全網です。15 ガバナンス全体の考え方は「Power Automateで業務を自動化する」の9章で触れています。

環境分離・ALM(開発→テスト→本番のパイプライン)・CoE Starter Kitによる全社統制といった話はこの先にありますが、フローが数十本規模になってから検討すれば十分です。まず台帳とソリューション化、その次が環境です。

8. 判断表 ── そのフローは誰の資産か

最後に、個々のフローをどのレベルで管理するかの線引きです。全フローを厳格管理するのは非現実的なので、「止まったら誰が困るか」で3段階に分けます。

状況 位置づけ 最低限やること
本人だけが使う。止まっても本人が手作業に戻るだけ 個人の効率化ツール 台帳に載せるだけ。管理は本人に任せる
部署の複数人が結果に依存。止まると業務が数時間〜1日滞る チームの資産 共同所有者2名以上、接続の名義を確認、通知は共有メールボックス、台帳と説明欄を整備
受注・請求・支払いなど基幹業務に直結。止まると取引先に影響 会社のインフラ ソリューション化+実行アカウント/サービスプリンシパルの設計+失敗時通知。フローの複雑さが限界なら、IT部門・外部委託での作り直しを検討
作った人がすでにおらず、中身を誰も説明できない ブラックボックス 触る前にまず棚卸しと引き継ぎ(4章)。仕様を復元してから、延命か作り直しかを判断

最下段の状態になってしまったフローへの向き合い方は、冒頭で挙げたソースも仕様書もないシステムの引き継ぎと同じです。いきなり作り直すのではなく、トリガー・接続・出力先を観察して「何をしているか」を台帳に起こすところから始めます。幸い、フローはソースコードのないEXEと違って中身が全部見えます。共同所有者にさえなれれば、定義を読み解くこと自体は難しくありません。

また、「そもそもこの処理をPower Automateで持ち続けるべきか」という問いもあります。属人化の温床になりやすい複雑なフローは、PowerShellスクリプトやタスクスケジューラ、あるいは業務システム側の機能に寄せたほうが、Git管理やコードレビューに乗せられて引き継ぎやすいことがあります。この使い分けは「Power AutomateとPowerShell・タスクスケジューラの使い分け」で整理しています。

9. まとめ

  • フローは作成者のアカウントと接続に紐づいています。退職でアカウントが消えてもフロー自体は残りますが、実行履歴は自動削除され、退職者名義の接続を使うアクションは失敗し、プレミアムフローは14日の猶予の後にオフになります。1024
  • 退職前なら、共同所有者の追加→(ソリューション対応なら)所有者変更→接続の差し替え→共有メールボックスへの名義変更、の順で2週間あれば引き継げます。31
  • 退職後でも、管理センターの「リソース→フロー」やPowerShell(Get-AdminFlow/Set-AdminFlowOwnerRole)で孤立フローを発見し、所有者を割り当て直せます。ただし接続の作り直しは避けられません。2
  • 根本対策は、フロー台帳による棚卸し、命名規則と説明欄、通知名義の共有化、そして重要なフローの実行主体を個人から切り離す設計(サービスアカウントは慎重に、基幹はサービスプリンシパル)です。1167
  • 「個人の道具」「チームの資産」「会社のインフラ」のどれなのかをフローごとに決め、管理の重さをそこに合わせる。これが、現場の自動化を萎縮させずに属人化だけを防ぐ現実的な線だと考えています。

作った本人が異動・退職する予定がなくても、この記事の4章までを「防災訓練」として一度やっておくことをお勧めします。フローの棚卸しや引き継ぎ設計、Power Automateに載せるべきかどうかの切り分けで迷うことがあれば、お気軽にご相談ください。

関連記事

関連する相談領域

合同会社小村ソフトでは、担当者の退職・異動で誰も触れなくなった自動化・業務システムの引き継ぎ調査から、Power Automateの運用設計レビュー、フローでは収まらなくなった処理のシステム化まで扱っています。

参考リンク

  1. Microsoft Learn, Share a cloud flow. 共同所有者ができること(実行履歴の確認、フローの編集・停止・削除、所有者の追加)、共有された接続はそのフロー内でしか使えないこと、他の所有者が作成した接続の資格情報は変更できないこと、作成者退職後も有効な所有者がいればフローは動き続けるが退職者の接続を使うアクションは失敗し得るため接続の変更(Modify a connection)が必要なこと、所有者を外す際は接続の資格情報更新が必要なことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, Manage orphaned flows when the owner leaves the organization. 孤立フロー(有効な所有者がいないフロー)の定義、退職者のアカウントに紐づく接続を使うフローが失敗し得ること、Power Platform管理センター(環境→リソース→フロー)での発見と「共有」による所有者追加、Get-AdminFlowOwnerRole・Set-AdminFlowOwnerRole・Get-AdminFlow -CreatedByによる一括処理について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Microsoft Learn, Change the owner of a cloud flow. ソリューション対応フローの所有者は所有者・共同所有者・管理者が変更でき、変更後は新旧所有者が共同所有者になること、スケジュール/自動フローは新所有者のライセンスで実行され反映に最大7日かかる(保存で即時反映)こと、非ソリューションフローは所有者がフローの識別情報の一部でありその場での所有者変更ができないこと、所有者にはサービスアカウントとして使うユーザーアカウントを指定できること、管理者がフローを変更するにはまず自分を所有者・共同所有者に追加する必要があることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Microsoft Learn, Power Automate licensing FAQ. 所有者退職時の対処(ソリューション対応フローの所有者変更、非ソリューションフローはソリューション追加またはエクスポート/インポート)、対応しない場合フローがパフォーマンス低下の上14日でオフになること、およびMultiplexingの節での、ユーザーアカウント共用型サービスアカウントがベストプラクティスとして推奨されないこと(変更者の追跡困難・パスワード管理のリスク・最小権限とアクセス者限定の推奨)、多人数での資格情報共用によるプレミアム機能利用がライセンス上の多重化に当たり得ること、代わりにサービスプリンシパルが推奨されることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. Microsoft Learn, Create flows for popular email scenarios. 「共有メールボックスからメールを送信(V2)」アクションで共有メールボックスから送信できること、事前にメールボックスへのアクセス許可が必要なこと、送信したメールが共有メールボックスの送信済みフォルダーに残ることについて。 ↩ ↩2 ↩3

  6. Microsoft Learn, Formalizing messages and alerts. 定型化された通知は個人名義でなく共有の送信元から送ることの推奨、Teamsの「フローボットとして投稿」系アクション、自動送信であることと連絡先を示す署名を入れる実践について。 ↩ ↩2 ↩3

  7. Microsoft Learn, Understand flow ownership and access. フローの所有者はユーザーアカウントとサービスプリンシパルのいずれかを選べること、サービスプリンシパル所有の利点(退職の影響を受けない安定性・セキュリティ・監査性)、重要なフローにはサービスプリンシパルを推奨すること、共同所有者は必要最小限にし共有は原則実行専用(run-only)で行うべきことについて。 ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, Support for service principal owned flows. サービスプリンシパルのアプリケーションユーザーがフローを所有・実行できること、所有者の退職やライセンス剥奪の影響を避けたいミッションクリティカルなフローに推奨されること、サービスプリンシパルは共同所有者にはなれないこと、ユーザーライセンスを持てないためプレミアム機能を使うフローにはProcessライセンスが必要なこと(標準コネクタのみのフローは除く)について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Microsoft Learn, PowerShell support for Power Apps and Power Automate. 管理用モジュール(Microsoft.PowerApps.Administration.PowerShell)のGet-AdminFlow(全体管理者はテナント全体のフローを取得)、Get-AdminFlowOwnerRole、Export-CsvによるCSV出力、Add-AdminFlowsToSolution、Get-AdminFlowWithHttpActionについて。 ↩ ↩2

  10. Microsoft Learn, Respond to personal data deletion requests (Microsoft Entra ID). ユーザーをMicrosoft Entra IDから削除しても、フローと接続は自動削除されず管理者の手動確認・削除の対象であること、一方で実行履歴は自動的に削除されることについて。 ↩ ↩2

  11. Microsoft Learn, Use consistent naming for flow components. フローの部品に説明的で意味のある名前を付けること、命名規則を文書化して共有すること、アクションにコメント(メモ)を付けて意図を残すことについて。 ↩ ↩2

  12. Microsoft Learn, Generate flow description using AI. フローの詳細画面の「説明」を編集できること、Copilotによる説明文の自動生成が一般提供されていることについて。 ↩

  13. Microsoft Learn, Manage and govern the default Power Platform environment. 既定の環境には組織の全従業員がアクセスできること、作成者の退職により所有者不在のフロー・アプリが溜まりやすく、孤立リソースの整理プロセスを整備すべきこと、広く使われる・業務上重要になったフローやアプリは既定の環境から専用の環境へ移すことが推奨されることについて。 ↩

  14. Microsoft Learn, Understand the benefits of using solution-aware cloud flows. ソリューション対応フローの利点(環境間の移動のしやすさ、接続の代わりに差し替え可能な接続参照を使えること、バージョン履歴)と、ソリューションがDataverseを前提とすることについて。 ↩ ↩2

  15. Microsoft Learn, Data policies. コネクタを業務データ用/非業務データ用/ブロックに分類し、組み合わせを制限するデータ損失防止(DLP)ポリシーによるガバナンスについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Power Automateのフローを作った担当者が退職すると、フローはどうなりますか？
フロー自体は退職者のアカウントを削除しても自動では消えず、共同所有者が残っていれば動き続けます。ただし、フロー内の接続(SharePointやOutlookへの認証)は作成した本人のアカウントに紐づいているため、退職者の接続を使っているアクションはアカウントの無効化・削除で失敗するようになります。また、有効な所有者が誰もいなくなったフローは「孤立フロー」となり、プレミアム機能を使うフローは所有者のライセンスが失われるとパフォーマンスが低下し、対応しなければ14日で無効化されます。退職前の共同所有者追加と接続の差し替えが重要です。
退職者が作ったフローを管理者が引き継ぐことはできますか？
できます。Power Platform管理センターで環境を選び「リソース」→「フロー」を開くと、所有者のいない孤立フローを確認でき、「共有」から新しい所有者を追加できます。フローが多い場合は、管理用PowerShellモジュールのGet-AdminFlowで一覧を取得し、Set-AdminFlowOwnerRoleで共同所有者を一括追加する方法もあります。ただし所有者を引き継いでも、退職者名義の接続はそのままでは動かないため、フロー内の各アクションの接続を新しいアカウントの接続に差し替える作業が別途必要です。
共同所有者を追加しておけば退職対策として十分ですか？
十分ではありません。共同所有者はフローの編集・停止・所有者追加までできますが、他人が作った接続の資格情報を変更することはできず、共有された接続はそのフローの中でしか使えません。退職者の接続を使うアクションは、共同所有者が自分の接続に差し替えて初めて動き続けます。また通知メールが退職者名義で飛び続ける問題も残るため、送信は共有メールボックスからにする、業務の基幹に関わるフローは実行用アカウントやサービスプリンシパル所有に寄せるといった設計とセットで考える必要があります。
フローの実行用に共用のサービスアカウントを作るべきですか？
選択肢にはなりますが、Microsoftはユーザーアカウントを共用するサービスアカウントをベストプラクティスとしては推奨していません。パスワードを複数人で共有するため、誰が変更したのか追跡しにくく、パスワード管理自体もリスクになるからです。使う場合は権限を必要最小限にし、アクセスできる人を絞ります。ミッションクリティカルなフローについては、人のアカウントに依存しないサービスプリンシパル所有が公式に推奨されていますが、設定にはIT側の知識が必要で、プレミアム機能を使う場合はProcessライセンスが必要になる点に注意してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る