Power AutomateのSharePoint連携とは？トリガー選定・無限ループ回避・権限設計を実装目線で解説

SharePointのリストを台帳にしてPower Automateでフローを組むと、最初の一本はその日のうちに動きます。詰まるのはその次です。同じリストへ書き戻した瞬間にフローが自分自身を呼び続ける、件数が増えると取得結果が合わなくなる、担当者の異動でフロー群が一斉に止まる。いずれも設計の段階で避けられます。この記事では、トリガー選定、ループを止める手順、規模の境界、接続の主体の置き方を、Microsoft Learnの制限値に沿って整理しました。製品そのものの概要はPower Automateとは？基本・できること・料金・導入判断まで解説をご覧ください。

まとめ：トリガー選定と書き戻し対策と接続主体の三点で決まる

先に結論を置きます。トリガーは「アイテムを作成した場合」で足りるなら変更検知系を選ばない。トリガー対象と同じリストへ書き戻すフローには、必ずトリガー条件を1本入れる。接続はサービスアカウントで作り、個人アカウントの接続を本番に残さない。この三点を着手前に決めておくと、後から作り直す工数がほぼ消えます。

規模の線引きも先に引いておきます。アイテムの取得は既定で100件しか返さず、上限を上げてもリストビューのしきい値5,000が天井です。ルックアップ列が12個を超えるリストではアクション自体が失敗する。数万件を1本のフローで舐める設計は成立しません。数字はMicrosoft Learnの記載で、2026年8月時点の値です。

リストとライブラリで分かれるSharePointトリガーの対応関係

SharePointコネクタのトリガーは、リストのアイテムを見るものとライブラリのファイルを見るものに分かれています。名前が似ているうえに非推奨のものが混ざっているため、まず対応関係を押さえます。

アイテム系とファイル系で名前が対になっているトリガーの読み方

Microsoft Learnの「Power Automate 用 Microsoft SharePoint コネクタ」（更新2026年5月14日付・2026年8月時点で確認）が挙げるトリガーは、次のように対応します。

ファイル系の2つには「（プロパティのみ）」が付き、返るのはライブラリの列の値だけです。中身が要るなら、後段で「ファイル コンテンツを取得する」を足します。

更新のみを拾う「アイテムまたはファイルが変更されたとき」は、対になる「アイテムまたはファイルの変更を取得する（プロパティのみ）」と組で使う設計です。このトリガーだけがトリガーウィンドウの開始トークンと終了トークンを出力し、前回チェック以降にどの列が変わったかを推測できます。前提としてバージョン管理の有効化が要り、対象は列の変更のみ。ファイル本体と添付ファイルの変更は取れません。

汎用リストと汎用ドキュメントライブラリだけが対象になるという制約

見落とすと設計が丸ごと崩れるのがこの制約です。同ドキュメントは、リストに対するPower Automateのフローがサポートされるのは汎用リスト（テンプレートID 100）と汎用ドキュメントライブラリ（同101）に限ると明記しています。お知らせ、連絡先、イベント、タスクといったテンプレート由来のリストは対象外。既存の「お知らせ」リストで通知フローを組もうとして、トリガーの一覧に出てこない、と詰まります。

回避策は、汎用リストを新しく作り必要な列を自分で足すことです。テンプレートの画面を捨てる判断になるため、SharePoint側の情報設計から見直します。サイト構成の決め方はSharePointで社内ポータルを作る実装手順｜サイト構成・Webパーツ・権限・ナビ設計を上限値から解説に整理しました。

非推奨のフォルダー系トリガーとサブフォルダーで起動しない挙動

「フォルダーにファイルが作成されたとき [非推奨]」と「フォルダー内でファイルが作成または変更された場合 [非推奨]」は、表示名に非推奨と入っています。推奨される代替は前者が「ファイルの作成時（プロパティのみ）」、後者が「ファイルが作成または変更されたとき（プロパティのみ）」。この2つには、監視対象フォルダーのサブフォルダーにファイルが追加・更新されても起動しない挙動があり、公式はサブフォルダーごとに別のフローを作るよう案内しています。新規実装で選ぶ理由はありません。

あわせて押さえたいのが、ファイルの移動と同期ではフローが起動しない仕様です。ライブラリ間で移動しても作成日時や更新日時といったカスタムメタデータは変わらないため、移動先の更新系フローはトリガーされない。同期クライアント経由も同じ扱いです。「ここに置けば処理される」運用は、移動ではなくアップロードを前提に組みます。

項目更新の無限ループが起きる仕組みとトリガー条件で止める三つの手

SharePoint連携で最も多い事故が、フローが自分自身を呼び続けるループです。仕組みが分かれば対策は3手に絞れます。

トリガー対象と同じリストへ書き戻すフローが自分を再び呼ぶ構造

原因は一行で済みます。トリガーで指定したリストと同一のリストを更新するアクションが、フローの中にあるからです。「アイテムを作成か変更した場合」で起動し、処理の最後に同じアイテムのステータス列を更新する。この更新が変更として検知され、フローがもう一度動く。その2回目もまた同じ更新を行い、以降は止まりません。

放置した場合の挙動も知っておいたほうがよい。Microsoft Learnの制限一覧（更新2026年8月17日付・2026年8月時点で確認）によれば、継続的にスロットルされているクラウドフローと、継続的に失敗するトリガーやアクションを持つフローは、いずれも14日でオフになります。最終的には自動で止まりますが、それまではPower Platformの要求数を消費し続ける。Low相当のプロファイルなら24時間あたり10,000要求という枠を、1本のループフローが食い潰す構図です。

トリガー条件に式を入れて起動そのものをふるい落とす設定の手順

第一の手が、トリガー条件です。設定はトリガー右上の3点メニューから「設定」を開き、トリガーの条件へ式を入れます。式は先頭に@を付ける決まりで、条件を複数並べた場合はすべてを満たしたときだけフローが実行されます。日本マイクロソフトのサポートブログが挙げている記法は次の形です。

@not(empty(triggerBody()['OData__x30ab__x30b9__x30bf__x30e0__xff11_']))
@equals(triggerBody()['MyColumn1'], '12345')

1本目が「カスタム列が空でないとき」、2本目が「列の値が12345のとき」。日本語の列名は内部名がエンコードされるため1本目のような文字列になり、内部名はリスト設定の列の設定画面から拾えます。

ループ対策としてよく使うのは、更新者で弾く形です。フローの書き戻しをサービスアカウントで行っておき、そのアカウントが編集した変更では起動しないようにします。

@not(equals(triggerBody()['Editor']['Email'], '[email protected]'))

トリガー条件は起動前の判定なので、条件に合わない変更では実行そのものが生成されず、履歴も残りません。要求数の消費を抑える意味でも、後段の条件アクションより効きます。

書き戻し先を別のリストへ逃がす設計と三つの手の使い分けの基準

第二の手が、書き戻し先をトリガー対象と別のリストにすることです。処理結果を「処理ログ」リストへ入れる、あるいはトリガー対象外のライブラリへファイルを吐く。トリガーが見ているリストを一切触らない構造にしてしまえば、条件式の保守が不要になります。

第三の手が、フラグ列を1つ足して、フラグが未処理のときだけ起動するトリガー条件を置き、処理の最後にフラグを立てる形です。この場合フラグ更新でもう一度ポーリングは起きますが、条件で弾かれるため実行はされません。

使い分けの基準はこう置いています。書き戻し先を分けられるなら第二の手が一番堅い。同じアイテムに状態を持たせたいなら第三の手。既存フローの改修で構造を変えたくない場合に第一の手で凌ぐ。更新者による判定を入れるなら、その接続がどのアカウントのものかを台帳に残す。残していないと、アカウント変更でループが再発します。

トリガーの同時実行制御を一度オンにすると元へ戻せない仕様への備え

ループとは別に、同じフローが大量に並列起動して後段のシステムを叩き潰すことがあります。対策は同時実行制御ですが、扱いに注意が要ります。既定は無効で、有効にすると並列度を1から100で指定でき、既定値は25。そして一度適用すると元に戻せません。Microsoft Learnの設計指針は、解除するには新しいフローを作り直す必要があると明記しています。

SharePointトリガーの場合はさらに癖があります。同コネクタのドキュメントは、SharePointトリガーを使うフローでは同時実行制御の有効化・無効化を元に戻せず、試すとCannotDisableTriggerConcurrencyエラーが出ると記載しています。回避策はフローをエクスポートしてJSONの同時実行制御の要素を削除し、インポートし直すこと。既定のまま触らないのが無難で、どうしても要るなら対象の処理だけを子フローへ切り出し、子フロー側に当てます。

アイテム件数が増えたリストで壊れる四つの境界と回避策の当て方

小さいリストでは見えず、運用半年で顕在化するのが規模の境界です。数字を先に把握すれば設計から外せます。

アイテムの取得の既定100件とリストビューしきい値5000の関係

Microsoft Learnの「アイテムの取得とファイルの取得の詳細な分析」（更新2026年5月14日付・2026年8月時点で確認）は、既定のアイテム制限が100で、既定でページ分割されると記載しています。サイトアドレスとリスト名を指定しただけのアクションは100件しか返しません。詳細設定の「上位カウント」で引き上げられますが、上限はリストビューのしきい値である5,000。これを超える値を入れるとエラーダイアログが出ます。

厄介なのが、5,000件を超えたリストでフィルタークエリを使ったときの挙動です。同ドキュメントは、先頭5,000件にフィルター条件へ一致するアイテムがない場合、レコードが返らないことがあると注意しています。0件が返ってきたのにリストには該当データがある、という不可解な結果はこれ。対処はアクション設定でページ分割を有効にすることです。取得列を絞るなら、詳細オプションの「ビューで列を制限する」で列のしきい値の問題を避けられます。

ルックアップ列が12個を超えるとアクション自体が失敗する境界

リストやライブラリにルックアップ列がある場合、アイテムの取得とファイルの取得が返せるのは最大12個までです。同ドキュメントは、しきい値を超えるとPower Automateのフローが失敗すると明記しています。参照列を増やしがちなマスタ連携のリストでは、実際に踏みます。

この12にはPersonやGroupの列も数えられるため、「登録者」「承認者」「部署」を足すだけで枠が埋まる。回避策はルックアップ列を含まないビューを指定するか、参照をやめて値をコピーで持つかの二択です。

接続ごと600回60秒という調整制限とフロー側の上限値の関係

SharePointコネクタの調整制限は、接続ごとのAPI呼び出しが60秒あたり600回。帯域は接続ごと60秒あたり1,000MBです。ここで数えるのは接続単位なので、同じサービスアカウントの1接続を全フローで共有していると、フローの本数ではなく合計呼び出し数で頭打ちになります。Apply to eachでリスト更新を回す設計は、この上限に一番早く当たる形です。

フロー側の上限も押さえておきます。ワークフローごとのアクションは500、変数は250。単一実行の継続時間は30日で、実行履歴の保持も30日。Apply to eachの並列度は既定1で、1から50まで変更できます。数値はいずれも2026年8月17日更新の制限一覧に基づく、2026年8月時点の値です。

添付ファイル90MBという上限が要件そのものを縛ってくる場面

SharePointコネクタがサポートするリストアイテムの添付ファイルサイズは最大90MB。Logic Appsから使う場合は最大100MBで、それを超えるとバッファーサイズの制限で失敗する可能性があると公式に記載があります。大きなファイルはMicrosoft Graph APIや中間ストレージへ逃がす前提で組む。設計図面や動画を扱うライブラリでは、この90MBが要件そのものを左右します。

権限とサービスアカウントを先に決めるSharePoint連携の設計方針

フローは「誰の権限で動くのか」が曖昧なまま本番へ出がちです。ここが後から一番高くつきます。

接続を作成した人の権限でフローが動くという前提の重さと影響範囲

SharePointコネクタの接続は、接続を作成したユーザーの資格情報で確立されます。フローが読み書きできる範囲は、そのアカウントがSharePoint上で持っている範囲と一致する。担当者が自分のアカウントで接続を作ったフローは、その担当者が異動して権限を失った時点で失敗し始めます。失敗が続けば14日でフロー自体がオフになる。

対策は、業務用のサービスアカウントを1つ用意し、そのアカウントで接続を作ることです。フローはソリューションの中に置き、接続参照として持たせると、所有者の付け替えと環境の移送が扱いやすくなります。同じ方針をTeamsコネクタ側にも当てる場合の考え方はPower AutomateのTeams連携とは？カード通知・メンション・承認の実装と権限設計を解説で整理しました。

もう一点、90日間トリガーされないクラウドフローはオフになる可能性があります。PremiumライセンスまたはPower Automate Process、フローごとのライセンスを持つユーザーが所有するフローは、この停止の対象外。年度末だけ動かす類のフローをどのアカウントに持たせるかは、ライセンスの割り当てと合わせて決めます。権利の区分そのものはPower Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説【2026年版】に整理しました。

削除トリガーがサイトコレクション管理者の接続を要求する理由と対応

権限設計で必ず個別対応が要るのが、削除の検知です。「アイテムを削除した場合」と「ファイルを削除する場合」は、削除されたアイテムのプロパティを取得するためにサイトコレクション管理者アカウントでSharePointサイトへ接続する必要がある、と公式ドキュメントが明記しています。一般ユーザー権限のサービスアカウントでは、削除は検知できても中身が取れません。

ここでサービスアカウントにサイトコレクション管理者を与えるかどうかは、素直に判断が割れます。与えるなら、そのアカウントの接続を使う他のフローもサイト全体を触れることになる。削除検知だけを別アカウント・別接続に分離するのが折衷案です。削除検知が要件に無いなら、権限を上げない選択のほうが安全側に倒れます。

テナントの条件付きアクセスとゲストアカウントで連携が止まる場面

サービスアカウントを作った後に踏むのが、テナント側のポリシーです。SharePointコネクタのドキュメントは、多要素認証やデバイスコンプライアンスポリシーといった条件付きアクセスのポリシーが、このコネクタ経由で使えるデータへのアクセスをブロックする場合があると記載しています。人が使わない前提のアカウントに対話型の多要素認証が当たると、接続の再認証で詰まる。ポリシーの除外設定は情報システム部門と先に握っておきます。

ゲストユーザーアカウントも制約を受けます。同ドキュメントによれば、ゲストはコネクタ操作でドロップダウンリストの情報を表示・取得できません。外部パートナーのアカウントでフローを作る運用は成立しないと考えたほうがよい。

権限を絞る根拠をもう一つ。「SharePointにHTTP要求を送信する」アクションは、その接続がアクセス権を持つ任意のSharePoint REST APIを実行できます。接続主体の権限がそのまま攻撃面になるため、権限はサイト単位で切ります。

内製で組み切れる範囲と外部の実装支援へ切り出す判断の分かれ目

ここまでの制限値を踏まえると、どこまで自社で組みどこから外に出すかの線は明確に引けます。判断を条件付きで言い切ります。

内製で回せるのは単一サイトコレクションかつ書き戻しなしの範囲

内製で完結させてよいのは、次の条件を全部満たすときです。対象が単一のサイトコレクション内の汎用リストで、アイテム数が5,000を大きく下回り、トリガー対象への書き戻しがなく、通知や承認1段で終わり、削除の検知を含まない。この範囲なら、ノーコードのまま作れて、作った人以外でも読めます。

逆に、次のどれか1つでも当てはまったら、内製のまま進めるのは止めたほうがよい。複数のサイトコレクションを横断する。リストが5,000件を超えて伸び続ける。トリガー対象と同じリストへ書き戻す。削除を検知してサイトコレクション管理者権限が要る。監査ログや再実行が要件に入っている。承認の作り込みまで踏み込む場合の制限はPower Automate 承認ワークフローの作り方｜多段階と30日制限にまとめました。

Power Automateで受けず別の基盤へ寄せるべき処理の見極め

そもそもPower Automateで受けない判断も要ります。5,000件超の突合を毎日回す、失敗時に途中から再開する、複数リストの更新をまとめて成功か失敗かに揃える。この3つはクラウドフローの構造と噛み合いません。アクション500・変数250・実行30日という枠と、接続ごと600回60秒という調整制限に収まらないからです。バッチ処理はAzure Logic AppsやFunctions、あるいは業務システム側へ寄せる。SharePointは台帳と画面に徹させるほうが、結果的に安く済みます。

設計の線引きから実装、運用の引き継ぎまで含めて相談したい場合は、Power Automate導入支援・RPA移行で受けています。既存フローの棚卸しと、内製に残す範囲の切り分けから入る進め方も取れます。他社がどのあたりまで自動化したかはPower Automateの導入事例｜経理・人事・営業の自動化パターンと外注の線引きにまとめました。

よくある質問

お知らせリストやタスクリストでフローが作れないのはなぜですか？

Power Automateのフローがサポートするのは、汎用リスト（テンプレートID 100）と汎用ドキュメントライブラリ（同101）だけだからです。お知らせ、連絡先、イベント、タスクといったテンプレート由来のリストは、現時点で対象外と公式に記載されています。汎用リストを新しく作り、必要な列を自分で定義し直すのが回避策になります。

トリガーが動くまでどれくらい時間がかかりますか？

SharePointトリガーはポーリング型で、Power Automateがリストやライブラリの変更を定期的にチェックします。公式は、変更が1件なら数分以内に実行が発生することが多いとしています。ただし、ポーリング間隔までの時間や追加編集によって、1回の実行が複数の変更をまとめて拾うことがある。即時性が要件なら、この揺れを前提に組んでください。

無限ループはトリガー条件と条件アクションのどちらで止めますか？

トリガー条件です。条件アクションはフローが起動した後の分岐なので、実行そのものは発生し、要求数と実行履歴を消費します。トリガー条件は起動前の判定で、条件に合わなければ実行が生成されません。式は先頭に@を付け、複数書いた場合は全部を満たしたときだけ実行される仕様になっています。

フローを作った担当者が退職したら連携はどうなりますか？

接続はその担当者の資格情報で動いているため、アカウントが無効になると接続が切れ、フローは失敗します。継続的に失敗するフローは14日でオフになります。避けるには、業務用のサービスアカウントで接続を作り、フローをソリューションに入れて接続参照として持たせる。既に個人アカウントで動いているフローがあるなら、棚卸しと接続の差し替えから着手してください。

5,000件を超えたリストからアイテムを全件取得できますか？

「アイテムの取得」の上位カウントはリストビューのしきい値である5,000が上限で、それを超える値はエラーになります。5,000件超のリストでフィルタークエリを使う場合、先頭5,000件に一致がないと0件が返ることがあるため、アクション設定でページ分割を有効にする必要があります。全件を舐める処理が要件なら、別の基盤へ切り替えるのが現実的です。

関連記事

• Power Automateとは？基本・できること・料金・導入判断まで解説：製品の概要と導入判断を発注検討の目線で。
• SharePointで社内ポータルを作る実装手順｜サイト構成・Webパーツ・権限・ナビ設計を上限値から解説：連携元のSharePoint側のサイト構成と権限設計。
• Power Automate 承認ワークフローの作り方｜多段階と30日制限：リスト起点で承認を組むときの実装と制限。
• Power Automateのクラウドフローとデスクトップフローの違いとは？トリガー種別・実行基盤・ライセンス差で選び分ける：どの種別のフローで組むかの判断。
• Power Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説【2026年版】：権利の区分と見積もり手順。