Power AutomateのSharePointトリガーが動かない原因と直し方

スポンサーリンク
スポンサーリンク

SharePointのリストに新しいアイテムを登録したのに、Power Automateのフローが一向に動かない。そんな状況に頭を抱えていませんか?

 

結論からお伝えすると、Power AutomateのSharePointトリガーが動かない原因は、接続切れや権限不足だけではありません。

 

SharePoint特有の「ポーリング仕様」や「サブフォルダーの制限」が絡んでいるケースが実務ではかなり多いです。

 

筆者もフリーランスとしてSharePoint連携のフローを組む機会が多く、トリガーが反応しないトラブルに何度も遭遇してきました。

 

原因を切り分けずに接続の再認証だけを繰り返し、時間を無駄にした経験もあります。

 

この記事では、Power AutomateのSharePointトリガーが動かない原因を症状別に整理し、実際に効果があった直し方を順番に解説します。

 

フローをオフ・オンした際の見落としがちな挙動まで踏み込んで紹介しますので、ぜひ最後まで参考にしてください。

スポンサーリンク

Power AutomateのSharePointトリガーが動かない主な原因

SharePointトリガーが反応しない場合、原因は大きく3つのパターンに分かれます。

まずは自分の症状がどれに近いか、以下の表で確認してみてください。

 

トリガー名 動作方式 見落としやすい仕様
アイテムが作成されたとき ポーリング型 確認頻度に応じたタイムラグが発生
アイテムが作成または変更されたとき ポーリング型 フロー自身の更新で再トリガーされやすい
指定したフォルダーにファイルが作成されたとき ポーリング型 サブフォルダー内の作成・変更には反応しない

 

まずはトリガーの種類ごとの仕様を理解しておくと、原因の切り分けが一気に楽になります。順番に見ていきましょう。

ポーリング型トリガーだから「即時」ではない

Power AutomateのSharePointトリガーは、多くがポーリング型と呼ばれる方式で動作しています。

 

ポーリング型とは、一定の間隔でSharePoint側に変更がないか確認しに行く仕組みのことです。

 

そのため、アイテムを登録した瞬間にフローが動くとは限りません。確認頻度はライセンスの種類によって変わり、無料プランでは数分単位のタイムラグが出ることもあります。

 

トリガーがポーリング型かどうかは、フローの詳細設定にある「ピークコード」からも確認できます。

 

recurrenceという項目があればポーリング型、なければWebhook型と判断できるはずです。

サブフォルダーの作成・変更には反応しない仕様

ドキュメントライブラリでよくある見落としが、サブフォルダーの扱いです。

 

Microsoftの公式ドキュメントでも、指定フォルダー内のサブフォルダーでファイルが作成・変更された場合、トリガーは実行されないと明記されています。

 

「フォルダー直下には反応するのに、その中の子フォルダーだけ反応しない」という場合、まさにこの仕様が原因です。

 

🔄
サブフォルダーでトリガーが反応しない仕組み
監視対象フォルダー

直下のファイル

サブフォルダー内
直下のファイル
トリガーが反応する
🚫
サブフォルダー内
トリガーが反応しない

 

サブフォルダーごとにも監視が必要な場合は、それぞれのフォルダーに対して個別のフローを作成するのが、現時点で案内されている対処法です。

接続(コネクタ)が期限切れになっている

意外と多いのが、SharePointコネクタの接続そのものが無効になっているケースです。Microsoft 365のパスワード変更や多要素認証の更新後に、接続が一括で切れることがあります。

 

接続エラーはトリガー画面に「トリガーを修正してください」というバナーで表示されることが多く、気づきにくいのが厄介な点です。フローの詳細画面から接続状態を確認する習慣をつけておきましょう。

 

Outlookコネクタでも同様の接続切れが起きやすく、Power Automateでメール送信できないエラーの原因と直し方|症状別に解説でも同じ原因を扱っています。あわせて確認してみてください。

スポンサーリンク

症状ごとの直し方

原因がわかったところで、実際の症状に合わせた直し方を見ていきます。

 

エラーメッセージの有無によって、確認すべき場所が変わってきます。

フローが「一度もトリガーされていない」場合の切り分け

実行履歴に記録が一切ない場合、まずはトリガーのステータスバナーを確認してください。

 

4xx系のエラーコードが表示されていれば、フォルダー名の変更やリストの削除など、利用者側で直す必要がある問題です。

 

一方で5xx系のエラーコードは、Microsoft側の一時的な問題であることが多く、しばらく待てば自然に回復するとされています。

 

慌てて設定をいじる前に、まずはコード番号を確認するのが近道です。

「トリガーを修正してください」と表示される場合

このエラーには、ユーザーまたはグループ列・ルックアップ列・タスクの結果列などの「参照系」の列が関係していることがあります。SharePointには、こうした列がクエリ内で12列を超えると処理を拒否する仕様があるためです。

 

解決策は、トリガーで使用するビューの列数を12列以下に絞ることです。以下の手順で対応できます。

 

ルックアップ列のしきい値エラー対処

STEP 1
参照系の列を12列以下にした専用ビューを作成

トリガーの詳細オプション →「ビューによる列の制限」

← ここで指定
トリガーのエラーが解消される

 

なお、SharePoint側の権限設定が原因でアイテムが操作できず、結果的にトリガーも動かないように見えるケースもあります。

 

権限まわりのトラブルはSharePointリスト編集できない・権限エラーの原因と直し方【症状別】で詳しく整理していますので、あわせてチェックしてみてください。

無限トリガーループの警告が出る場合

「アイテムが作成または変更されたとき」をトリガーに使い、そのフロー内で同じリストのアイテムを更新していると、無限ループの警告が表示されることがあります。

 

フロー自身の更新が新たなトリガーを呼び、それがまた更新を呼ぶ、という連鎖が起きてしまうわけです。

 

回避するには「アイテムが作成されたとき」トリガーに変更するか、更新済みかどうかを判定するトリガー条件を追加しましょう。

スポンサーリンク

フローをオフ→オンに戻したときに起こる見落としがちな挙動

ここまでの内容と少し毛色が違いますが、実務で地味に困るのがフローの再開タイミングです。

 

トリガーの動作方式によって、オフの間に起きた変更の扱いが大きく異なります。

ポーリングトリガーは「保留イベント」を溜め込んでいる

SharePointの多くのトリガーはポーリング型のため、フローがオフの間に登録されたアイテムも、内部的には保留状態として記録され続けています。

 

そしてフローを再びオンにした瞬間、溜まっていた保留イベントがまとめて処理される仕様になっています。

 

これはWebhook型トリガーとは逆の挙動で、Webhook型はオフの間のイベントをそのまま取りこぼす仕様です。

 


オフ→オン再開時の挙動の違い
🚀 ポーリング型トリガー
オフの間の変更も保留され、オンに戻すとまとめて実行される。
⚠️ Webhook型トリガー
オフの間に発生したイベントは処理されず、そのまま消える。
💡

ポイント
再開前に対象リストの更新件数を確認し、大量実行に備えておきましょう。

大量実行を避けるための安全な再開手順

フローを止めていた期間が長いほど、保留イベントの件数は増えます。再開時にまとめて大量実行されると、通知メールが一気に届いたり、Exchange Onlineの送信上限に触れたりする恐れがあります。

 

どうしてもオフの間の変更を反映させたくない場合は、既存のフローを削除してから新規に作り直すという方法が案内されています。

 

オン・オフの切り替えだけでは、保留イベントを消せない点に注意してください。

スポンサーリンク

放置すると危険な二次トラブルと予防策

トリガーそのものは直っても、別の要因で気づかないうちにフローが止まってしまうこともあります。あわせて押さえておきましょう。

90日ルールでフローが自動的に無効化される

Microsoft 365に付帯するプランやフリープランのPower Automateでは、90日間フローが実行されないと警告メールが届き、その後30日以内に実行がなければ自動的に無効化される仕様になっています。

 

SharePointトリガーが正常でも、そもそもフローがこのルールでオフにされていれば当然動きません。実行頻度が低いフローには、月1回程度の空実行を仕込んでおくと安心です。

パスワード変更・多要素認証更新後の接続切れ

組織全体でパスワードポリシーが変更されたタイミングで、複数のフローが同時に止まることがあります。特にSharePointやTeamsのコネクタは影響を受けやすい傾向です。

 

定期的なパスワード変更が予定されている場合は、変更後のチェックリストに「Power Automateの接続再認証」を加えておくとよいでしょう。

管理者モードがオンだと全フローが止まる

Power Platform管理センターで環境の管理者モードがオンになっていると、その環境のすべてのバックグラウンドプロセスが停止し、フローもトリガーされなくなります。

 

複数のフローが同時に動かなくなった場合は、個別のトリガー設定を疑う前に、環境全体の管理者モードを確認してみてください。

スポンサーリンク

Q&A【よくある疑問まとめ】

Q. トリガーが反応しないのと、承認フローの通知だけ届かないのは何が違いますか?
A. まず実行履歴に記録が残っているかどうかで切り分けてください。記録が一切なければトリガー側の問題、記録はあるのに通知だけ届かなければ送信アクション側の問題です。筆者もこの2つを混同し、原因調査に余計な時間をかけてしまった経験があります。実行履歴の有無を最初に確認する習慣をつけておくと、無駄な作業を減らせます。
Q. SharePoint標準の「アラート」機能とPower Automateのトリガー、どちらを使うべきですか?
A. 通知だけで完結するならアラート機能で十分ですが、承認や複数システムとの連携が必要な場合はPower Automateが向いています。アラートは即時性に優れる一方、Power Automateのポーリングトリガーは確認頻度に依存するため、数分程度のタイムラグが生じる仕様です。目的に応じて使い分けるのが実務的な判断といえるでしょう。
Q. 長期間オフにしていたフローを再開すると、過去の変更もすべて処理されますか?
A. SharePointの多くのトリガーはポーリング型のため、オフの間の変更もオンに戻した瞬間にまとめて処理されます。筆者の環境でも、2週間ほど止めていたフローを再開した際に数十件のアイテムが一気に処理され、通知が短時間に集中したことがありました。再開前に対象リストの件数を確認しておくと安心です。
スポンサーリンク

まとめ

Power AutomateのSharePointトリガーが動かない原因は、接続切れだけでなく、ポーリング仕様やサブフォルダーの制限、ルックアップ列のしきい値など多岐にわたります。

 

まずは実行履歴とエラーコードを確認し、4xx系か5xx系かで対応方針を分けるのが基本です。そのうえで、この記事で紹介した症状別の直し方を順番に試してみてください。

 

フローを長期間オフにしていた場合は、再開時の大量実行にも注意が必要です。トリガーの仕組みを正しく理解しておけば、SharePoint連携のトラブルにも落ち着いて対処できるようになるはずです。

タイトルとURLをコピーしました