SharePointの承認ワークフロー Power Automateでの作り方と設計のポイント

休暇申請、稟議、経費精算、資料の公開可否。承認を伴う手続きは、いまだに紙の回覧やメールのやり取りで運用されている職場が少なくありません。誰のところで止まっているのか分からない、承認の記録が個人のメールボックスにしか残っていない、という状態は珍しくないはずです。

SharePointとPower Automateを組み合わせれば、申請から承認、結果の記録までを1つの流れとして自動化できます。追加のシステムを購入する必要はなく、すでに契約しているMicrosoft 365の範囲で始められます。

ただし、SharePointにおける「承認」には性格の異なる2つの機能があり、混同したまま調べ始めると求めている情報にたどり着けません。本記事では、その違いの整理から、実際の作成手順、多段階承認などの応用、そして運用でつまずく点までを順番にまとめます。

確認したいポイント	結論	詳細
SharePointで承認はできる？	標準機能とフローの2通り	リストの「コンテンツの承認」と、Power Automateの承認アクションのどちらかを使います。
どちらを選べばいい？	通知や分岐が要るならフロー	単純な公開可否なら標準機能、承認者の振り分けや結果による処理の分岐が必要ならフローです。
昔のワークフローは使える？	2013ワークフローは廃止済み	2010は2020年11月、2013は2026年4月2日に完全廃止され、Power Automateへの移行が必要です。
多段階承認はできる？	承認アクションを直列に並べる	「上司の取得」と組み合わせれば、組織階層に沿って上長からその上長へと段階的に回せます。

この記事でわかること

• SharePointの「コンテンツの承認」とPower Automateの承認フローの違いと選び方
• リストの設計から承認フローの作成までの具体的な手順
• 多段階承認や金額による承認者の振り分けなど、実務で必要になる応用
• 承認者の異動やフロー所有者への依存など、運用でつまずく点と対策
• 旧SharePointワークフローの廃止状況と、移行を検討する際の考え方

▼ 社内の申請・承認業務をどこまで効率化できるか整理したい方へ Microsoft 365や生成AIを使った業務効率化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

SharePointの「承認」には2つの意味がある

最初に整理しておきたいのが、言葉の指す内容です。同じ承認でも、SharePointの標準機能を指す場合と、Power Automateで作る承認フローを指す場合があります。目的が違うため、選び方を誤ると余計な作り込みが発生します。

SharePointの標準機能「コンテンツの承認」

1つ目が、リストやドキュメントライブラリに用意されているコンテンツの承認です。これを有効にすると、新しく追加されたアイテムや更新されたファイルは、承認されるまで他のユーザーには見えない状態になります。

アイテムには承認ステータスが付き、保留中、承認済み、却下といった状態で管理されます。公開前のチェックを挟みたい、という用途に特化した仕組みだと考えると分かりやすくなります。

設定は数クリックで済み、フローを作る必要もありません。ただし、誰が承認するかを細かく指定したり、承認者へ通知を飛ばしたりといった制御はできません。

なお、コンテンツの承認はドキュメントライブラリでも使えます。公開用のフォルダに置かれたファイルを、責任者が確認してから全社に見えるようにする、といった運用に向いています。

Power Automateで作る承認フロー

2つ目が、Power Automateの承認コネクタを使って組み立てる承認フローです。申請が登録されたら指定の承認者へ依頼を送り、結果に応じて処理を分けるという、業務プロセスそのものを自動化できます。

承認者は、メールやTeams、Power Automateの画面から承認と却下を選べます。コメントを添えることもでき、その内容をリストに書き戻すこともできます。

一般に「SharePointで承認ワークフローを作りたい」という場合、求められているのはこちらです。本記事でも以降はこの承認フローを中心に扱います。

どちらを使うかの判断

判断は用途で決まります。公開してよいかどうかの単純なチェックだけならコンテンツの承認、承認者の振り分けや通知、結果による処理の分岐が必要ならPower Automateです。

両方を併用することもできます。フローで承認を取り、その結果を使ってコンテンツの承認ステータスを更新するという構成です。ただし管理する箇所が増えるため、必要性をよく検討してから採用してください。

どちらを使う場合も、承認の対象になるデータはSharePointのリストやライブラリに置くことになります。まずはデータの置き場所を決めてから、承認の仕組みを選ぶという順序で進めてください。

旧SharePointワークフローは廃止済み

古い資料を参照している場合は注意が必要です。SharePoint Designerで作成する従来のワークフローは、すでに提供が終了しています。SharePoint 2010ワークフローは2020年11月に、SharePoint 2013ワークフローは2026年4月2日をもって完全に廃止されました（出典：Microsoft「SharePoint 2013 ワークフローの廃止」）。

これらを使っていた組織は、Power Automateなどへの移行が必要です。移行にあたっては、まず既存のワークフロー定義、所有者、依存関係、対象の業務プロセスを棚卸しすることが推奨されています。

単純に同じものを作り直すのではなく、移行のタイミングで業務そのものを見直すほうが結果的に効率的です。長年の運用で形骸化した承認段階が残っているケースは、決して珍しくありません。

標準の「コンテンツの承認」を使う

まずは簡単なほうから確認します。フローを作らずに済むなら、それに越したことはありません。設定手順と、使える場面の見極めを整理します。

有効にする手順

対象のリストまたはライブラリで、設定からバージョン設定を開き、コンテンツの承認を必須にする項目をはいに変更します。これだけで機能が有効になります。

あわせて、承認されていない下書きアイテムを誰が閲覧できるかも指定できます。作成者と承認権限を持つユーザーだけに限定する設定にしておけば、未承認の内容が他のメンバーの目に触れることはありません。

なお、この機能を有効にすると既存のアイテムの見え方も変わります。運用中のリストで設定する場合は、影響範囲を確認してから切り替えてください。

承認ステータスの扱い

有効にすると、各アイテムに承認ステータスの列が追加されます。承認権限を持つユーザーが、アイテムごとに承認または却下を行う形です。却下時にはコメントを残せます。

ビューをステータスで絞り込んでおくと、未承認のものだけを一覧で確認できます。承認担当者用のビューを別に用意しておくと、日々の確認作業が楽になります。

向いている場面と限界

向いているのは、社内報やマニュアルの公開前チェックのように、誰が承認するかが固定されていて、承認自体が単純な可否判断で済む業務です。設定が数分で終わる点は大きな利点です。

一方で、承認依頼の通知は飛びません。承認者が自発的にリストを見に行く運用になるため、確認が遅れがちになります。金額や部署によって承認者を変えたい、多段階で回したいといった要件にも対応できません。

これらが必要になった時点で、Power Automateの出番です。標準機能で始めて、足りなくなったらフローへという進め方も現実的な選択肢になります。

承認フローを作る前の準備

ここからはPower Automateでの構築です。フローを作る前に、申請データを受け止めるSharePointリストを設計しておく必要があります。ここが雑だと、後から作り直しになります。

リストに用意する列

申請内容そのものの項目に加えて、承認ステータス、承認者、承認日時、承認コメントを保持する列を用意します。フローの結果を書き戻す先として必要になります。

承認ステータスは自由入力ではなく選択肢列にしておきます。申請中、承認済み、却下、差し戻しといった値を定義しておけば、集計もビューでの絞り込みも安定します。

承認者の列は、ユーザー列にしておくと後の処理が楽になります。フローから承認依頼の宛先として直接渡せるためです。文字列で氏名を保持する設計にすると、同姓同名や表記ゆれで詰まります。

申請日や申請者の列は、既定で用意されている作成日時と作成者を使えば足ります。同じ情報を別の列で二重に持つと、どちらが正なのか分からなくなるため避けてください。

申請者と承認者の権限を設計する

見落とされやすいのが権限です。申請者が他人の申請を閲覧・編集できてよいのかを、最初に決めておいてください。既定のままだと、リストの閲覧権限を持つ全員が全件を見られます。

見える範囲を分けたい場合、アイテムごとに権限を細かく設定する方法は推奨されません。管理が複雑になるうえ、件数が増えると制限にも触れます。リスト自体を分ける、あるいは申請画面をアプリ側で用意して直接アクセスさせない構成を検討してください。

承認のルールを先に決める

フローを組み始める前に、誰が承認するのか、何段階あるのか、却下された場合はどうなるのかを言葉にしておきます。ここが曖昧なまま作ると、途中で構造を変えることになります。

あわせて、承認の期限、期限を過ぎた場合の扱い、承認者が不在のときの代理も決めておきます。紙の運用では暗黙に処理されていた部分が、自動化すると必ず表面化します。

▼ 申請・承認業務の設計からご相談いただけます どの業務から電子化すべきか、どこまでフローで作り込むべきかは、業務の実態によって変わります。現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

承認フローの作成手順

準備ができたら、フローを組み立てます。トリガー、承認アクション、結果による分岐、通知という4つの要素で、基本形は完成します。

トリガーを設定する

Power Automateで自動化したクラウドフローを新規作成し、SharePointの「項目が作成されたとき」をトリガーに選びます。サイトのアドレスとリスト名を指定すれば設定は完了です。

既存の申請を編集したときにも動かしたい場合は、「項目が作成または変更されたとき」を選びます。ただし、フロー自身が書き戻した更新でも再度トリガーが動くため、無限ループを防ぐ条件が必要になります。

公式のチュートリアルでも、SharePoint Onlineのリストを作成してから休暇の承認を要求する流れが示されています（出典：Microsoft Learn「Power Automate での承認ワークフローを作成し、テストします」）。

「開始して承認を待機」を追加する

次のステップで承認コネクタを検索し、「開始して承認を待機」アクションを追加します。これが承認依頼を送り、応答があるまでフローを止めておくアクションです。長期間応答がない場合の扱いは、後述する期限の設計とあわせて決めておいてください。

設定するのは、承認の種類、タイトル、担当者、詳細です。担当者には、リストの承認者列から取得した値を動的に指定します。詳細欄には申請内容の要約を入れておくと、承認者が中身を開かずに判断できます。

アイテムへのリンクも詳細に含めておいてください。判断に迷ったときに元データを確認できるかどうかで、承認のスピードが変わります。

承認の種類を選ぶ

承認の種類には複数の選択肢があります。「承認/拒否 – 最初に応答」は誰か1人が応答した時点で確定し、「すべてのユーザーの承認が必要」は指定した全員の承認を待ちます。

複数人のうち誰でもよい場合は前者、全員の合意が必要な場合は後者を選びます。承認と却下以外の選択肢を出したい場合は、カスタム応答を使って独自の選択肢を定義できます。

「差し戻し」のような第三の選択肢が必要な業務では、カスタム応答が有効です。ただし、選択肢を増やすほど後続の分岐も増えるため、本当に必要かを確認してから採用してください。

結果で分岐して書き戻す

承認アクションの後ろに条件を置き、結果が承認か却下かで処理を分けます。それぞれの分岐で、SharePointの「項目の更新」アクションを使ってステータスと承認日時、コメントを書き戻します。

結果をリストに残すことが重要です。フローの実行履歴は一定期間で消えるため、誰がいつ何を承認したかの記録はリスト側に持たせておく必要があります。

最後に、申請者へ結果を通知します。承認された場合は次の手続きの案内を、却下された場合はコメントを添えて理由を伝える構成にしておくと、問い合わせが減ります。

▼ 作ったフローが使われない、で止まっていませんか 運用に乗せるところまで含めて、承認プロセスの設計や社内への定着をご一緒に進めます。 ＞ 相談予約はこちら

実務で必要になる応用パターン

基本形が動いたら、実際の業務ルールに合わせていきます。多段階承認、承認者の振り分け、差し戻し、期限管理の4つは、多くの現場で共通して必要になります。

多段階承認を組む

上長の承認を得た後にさらに部門長の承認が必要、といった要件では、承認アクションを直列に並べます。1つ目が承認された場合のみ、2つ目の承認アクションへ進む構成です。

承認者を自動で決めたい場合は、Office 365 ユーザーコネクタの「上司の取得」アクションが使えます。申請者の上長を取得し、さらにその上長を取得すれば、組織階層に沿った多段階承認が組めます。

ただし、この方法は組織情報が正しく登録されていることが前提です。上長が設定されていないアカウントがあると、その時点でフローが失敗します。取得できなかった場合の代替経路を用意しておいてください。

段階が増えるほど、途中で止まったときの影響も大きくなります。本当にその段階が必要かを確認したうえで、最小限の構成から始めることをおすすめします。

条件によって承認者を変える

金額や申請区分によって承認ルートが変わる業務は多くあります。条件アクションやスイッチで分岐させ、それぞれの分岐に承認アクションを置くのが基本の作りです。

分岐が増えて見通しが悪くなる場合は、承認ルールを別のSharePointリストに持たせる方法があります。区分と金額帯に対応する承認者をマスタとして管理し、フローはそれを参照するだけにする構成です。

この設計にしておくと、ルールが変わってもリストを直すだけで済み、フローには手を入れずに運用できます。人事異動が多い組織ほど効果があります。

差し戻しと再申請

却下と差し戻しは性格が違います。却下は手続きの終了、差し戻しは修正して再提出してもらうことです。業務上どちらも必要なら、カスタム応答で選択肢を分けます。

差し戻しの場合は、ステータスを差し戻し中に更新し、申請者へ修正依頼を通知します。修正後に再度フローが動くよう、更新をトリガーに含める設計が必要です。

このとき、フロー自身の書き戻しで再びトリガーが動かないよう注意してください。ステータスの値やトリガー条件を使って、意図した更新のときだけ動くようにします。

期限とリマインド

承認が止まったまま放置されるのは、電子化しても起こります。一定期間応答がなければリマインドを送る、あるいは上位者へエスカレーションする仕組みを入れておいてください。

実装としては、承認アクションと待機のアクションを並行して動かし、期限が来たら通知するという構成が使われます。あるいは、未承認のアイテムを定期的に抽出して一括で催促する別フローを用意する方法もあります。

後者のほうが作りは単純で、複数の申請をまとめて催促できるため実用的です。毎朝、滞留している申請の一覧を承認者へ送るだけでも効果があります。

▼ 自社の承認ルールに合う形をご一緒に設計します 多段階承認、金額による分岐、代理承認など、実際の運用ルールに落とし込む部分も含めてご相談いただけます。 ＞ 相談予約はこちら

運用でつまずきやすい点

フローが完成しても、運用に乗せると別の問題が出てきます。人の異動と、フローの所有者に関する問題が特に多く見られます。

承認者の異動と退職

承認者を固定で指定していると、その人が異動や退職をした時点でフローが止まります。アカウントが無効になっていれば、承認依頼の送信そのものが失敗します。

対策は、承認者を個人ではなく役割で管理することです。前述の承認ルールマスタを用意しておけば、担当が変わってもリストを更新するだけで対応できます。

あわせて、承認待ちのまま止まっている申請をどうするかも決めておきます。異動の際に引き継ぐ手順を運用に組み込んでおかないと、宙に浮いた申請が残ります。

代理承認の仕組みも検討対象です。長期休暇や出張の間だけ別の人が承認できるよう、承認者マスタに代理者の列を用意し、条件によって宛先を切り替える構成が使えます。

フローの所有者に依存する

クラウドフローは作成者のアカウント権限で動きます。作成者が退職すると、フローが残っていても動かなくなる可能性があります。

対策としては、共有アカウントで作成する、複数人を所有者に設定する、ソリューションとして管理するといった方法があります。全社で使う承認フローほど、この点は最初に決めておくべきです。

承認の履歴をどう残すか

内部統制や監査の観点では、誰がいつ何を承認したのかを後から追える状態が求められます。フローの実行履歴は保持期間があるため、それだけに頼るのは危険です。

リスト側に承認者、承認日時、コメントを書き戻し、バージョン管理を有効にしておくと、変更の経緯まで残せます。件数が多い業務では、専用の履歴リストを別に用意する構成も検討してください。

承認依頼が埋もれる

メールで承認依頼が届く運用では、他のメールに埋もれて気づかれないことがあります。Teamsへの通知を併用する、未処理の一覧を定期的に配信するといった工夫が有効です。

承認者の立場からは、複数のフローからバラバラに依頼が来る状態も負担になります。Power Automateの承認画面に一覧として集まることを周知しておくだけでも、確認の習慣がつきやすくなります。

社内に定着させるための設計

最後に、作った仕組みを使い続けてもらうための観点です。技術的に動くことと、現場が使うことは別の問題として考える必要があります。

申請画面をどうするか

SharePointリストの標準フォームでも申請はできますが、項目が多いと使いにくくなります。Power Appsでフォームをカスタマイズすれば、入力の順序や必須チェックを業務に合わせて作り込めます。

より簡単に済ませたい場合は、Microsoft Formsで受け付けてリストへ転記する構成もあります。社外からの申請を受ける場合は、この方法のほうが権限の設計が単純になります。

利用者向けの案内も用意してください。申請の出し方、承認の仕方、困ったときの連絡先を1枚にまとめておくだけで、導入直後の問い合わせが大きく減ります。

紙の運用をそのまま移さない

電子化でよくある失敗が、紙の回覧をそのまま再現してしまうことです。押印のためだけに存在していた段階や、形式的な確認まで自動化すると、手間だけが残ります。

移行のタイミングで、各承認段階に本当に判断が伴っているかを点検してください。承認者が実質的に内容を見ていない段階は、通知だけに変える、あるいは廃止するという選択肢もあります。業務全体の見直し方は業務効率化アイデア55選の記事でも整理しています。

関係部署と早めに合意する

承認プロセスの変更は、経理や内部監査など他部署の要件に関わることがあります。証憑の保存方法、承認の証跡、金額の権限規程との整合など、確認すべき点は少なくありません。

作り終えてから指摘を受けると、大幅な手戻りになります。設計の段階で関係部署に見てもらい、要件を引き出しておくほうが結果的に早く進みます。

作った人に依存しない体制にする

内製した仕組みで最も多い失敗は、作成者の異動とともに誰も触れなくなることです。部署内に最低2人は中身が分かる人を置き、設計の意図をメモとして残すことが確実な対策になります。

どのリストのどの列を使っているか、承認者はどう決まるか、止まったときに誰へ連絡するか。この3点を1枚にまとめておくだけで、引き継ぎの負担は大きく下がります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

SharePointの承認には、公開前のチェックに使う標準の「コンテンツの承認」と、Power Automateで組み立てる承認フローの2つがあります。通知や承認者の振り分け、結果による分岐が必要なら後者を選びます。

なお、SharePoint Designerで作る従来のワークフローは、2010が2020年11月に、2013が2026年4月2日をもって完全に廃止されました。該当する仕組みが残っている場合は、移行を前提に計画を立ててください。

フローの作成は、リストの列と権限、承認ルールを先に決めてから着手します。トリガーに「項目が作成されたとき」、続けて「開始して承認を待機」を置き、結果で分岐してステータスを書き戻す。これが基本形です。

そして、承認者の異動、フロー所有者への依存、承認履歴の保存、依頼の埋没。この4点は必ず表面化します。設計段階で対策を織り込み、紙の運用をそのまま移さないこと。ここまで考えて初めて、承認の電子化は現場に定着します。

▼ 申請・承認の電子化を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからフロー設計、社内への定着支援までを一貫してご支援しています。 何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら