SharePoint ワークフロー廃止【2】移行先はPower Automateで正解？情シスが判断すべき現実的な課題

MicrosoftはSharePoint ワークフロー廃止後はPower Automateへの移行を推奨しています。その理由は、Microsoft 365全体と連携できる統合基盤であり、将来的な機能拡張もPower Automateに集約されているためです。ただし重要なのは、Microsoft公式の自動変換ツールは存在しないという点です。

また、補足として、SharePoint 2010 ワークフローは2020年に廃止済み、2013 ワークフローはSharePoint Onlineで非推奨となり、オンプレミスでも今後廃止が進む予定です。

移行をツール単体の話ではなく、廃止全体の流れの中で位置づけることが重要です。

▶SharePoint ワークフロー廃止から移行・代替までを俯瞰する解説

SharePoint ワークフローからPower Automateへの移行は、単なるツールの乗り換えではなく、「業務フローの全体再設計」を意味します。自動変換ツールが存在しないため、すべてのフローをゼロから組み直す必要があります。

特に構築時の負担となる、SharePoint ワークフローとの決定的な違いは以下の3点です。

① 「1パッケージ」から「最小単位の積み上げ」へ

SharePoint ワークフローでは「承認プロセス」という一つの機能の中に、通知・期限切れ処理・ステータス変更などがパッケージ化されていました。Power Automateでは、これらをすべてバラバラのアクションとして配置し、線でつなぐ必要があります。

• 承認後の処理: 承認された後に「リストのステータスを更新する」「申請者にメールを送る」といった動作を、条件分岐（Yes/No）を使って一つずつ手作業で定義する必要があります。。
• 例外処理の作り込み: 「承認者が不在の場合」「差し戻しが発生した場合」といった例外的な動きも、すべてロジックとして明示的に組み立てる必要があり、SharePoint ワークフローに比べてステップ数が数倍に膨れ上がります。

SharePoint ワークフローではSharePointのユーザー情報を参照して比較的容易に設定できた「多段階の役職承認」が、Power Automateでは大きな難所となります。

• 標準機能の限界: 標準で取得できるのは「申請者の直属の上司」までです。
• 構築の負担: 「部長 ⇒ 本部長」といった階層を辿るには、Microsft Entra ID（Azure AD）から情報を抽出する複雑なクエリを書くか、別途「承認者マスターリスト」をSharePoint上に作成し、フロー内で毎回そのリストを参照（検索）するロジックを自作する必要があります。

「承認中だけアイテムの編集をロックする」といった、SharePoint ワークフローでは標準設定だった制御も、Power Automateでは高度な設定が求められます。

• アクセス権の操作: 特定のアクション（HTTPリクエスト等）を使用して、アイテム固有の権限を解除・再割り当てするフローを組み込む必要があります。
• ステータスの同期: リスト上の表示ステータスと、実際のフローの進行状況を同期させるための「更新アクション」を随所に配置せねばならず、設計ミスによる「画面と実態の乖離」が起きやすくなります。

Power Automateでの構築が完了しても、実際の運用が始まるとSharePoint ワークフロー時代にはなかった「3つの壁」に直面します。これらはSharePoint ワークフロー廃止の全体像記事でも触れた、情シス担当者が最も警戒すべきリスクです。

Power Automateには、1ユーザーまたは1フローあたりに設定された「アクションの実行回数制限（リクエスト制限）」が存在します。

• 懸念点: 全社規模で利用するフローや、1回の申請で多くのアクション（条件分岐やループ、他サービス連携）を消費する設計の場合、月の途中で制限に達し、承認フローが突然停止するリスクがあります。
• SharePointワークフローとの違い: サーバー負荷を気にせず実行できていたSharePointワークフロー時代とは異なり、常に「実行リソースの残量」を意識した設計と監視が求められます。

「標準機能でできる範囲」を超えた瞬間に、コスト構造が大きく変わります。

• 懸念点: Microsoft 365の標準ライセンスの範囲外となる「Premiumコネクタ」を利用する場合、別途Power Automateの有償ライセンスが必要になります。
• コストの膨張: 組織変更等で特定の機能が必要になった際、一部の管理者だけでなく、フローを利用する全ユーザー分（あるいはフロー単位）の追加課金が発生するケースがあり、予算計画を狂わせる要因となります。

「作って終わり」にならないのがPower Automateの難点です。特に組織変更時のメンテナンスは、SPW以上に情シスの工数を奪います。

• 設定の属人化: フローの接続（コネクション）が作成個人のアカウントに紐付いてしまい、作成者の退職や異動に伴ってフローが動かなくなる「所有権問題」が頻発します。
• メンテナンスの複雑性: 承認ルートをフロー内に直接書き込んでいる場合、人事異動のたびに複雑なフロー図を読み解き、一箇所ずつ手作業で修正しなければなりません。この「保守運用の負荷」に耐えきれず、結局、専用製品への切り替えを再検討する企業が少なくありません。
  
  

これらの課題が自社に当てはまるかは、全体構造を見て判断する必要があります。
▶SharePoint ワークフロー廃止の全体像と判断ポイントを整理する

小規模で個人利用に近い自動化や、通知・簡易承認レベルであればPower Automateは有効な選択肢です。一方で、全社利用の稟議フローや承認人数が多い業務、長期運用を前提とした業務プロセスでは、「作れるかどうか」ではなく「運用し続けられるかどうか」を判断軸にすることが重要です。

Power Automateだけに選択肢を絞るのではなく、Microsoft 365と連携しつつ、運用管理や承認制御をツール側で担えるワークフロー製品を検討する考え方もあります。情シスがすべてを作り込み続けるのではなく、現場と役割分担できる仕組みを選ぶことで、廃止対応が中長期的な業務改善につながるケースも少なくありません。SharePoint ワークフロー廃止から移行・代替までの全体像を整理した解説は、SharePoint ワークフロー廃止の全体像と次に検討すべきフェーズを整理する記事で確認できます。

移行先を決める前に、他の選択肢も含めて整理しておくと後戻りを防げます。
▶SharePoint ワークフロー廃止から移行・代替までの全体像を整理する

Power AutomateはSharePoint ワークフロー廃止後の有力な選択肢ですが、すべての組織にとって最適解とは限りません。移行作業の難易度だけでなく、運用負荷や管理体制まで含めて判断することが重要です。廃止をきっかけに、単なる置き換えではなく業務フロー全体を見直す視点が求められます。