Power Automateで"The newly created B2B guest user could not be ensured ~"エラーに対処した話

Power Automateで「Entra側のB2Bゲストユーザー作成が間に合わない」エラーに対処した話

概要

SharePoint上のフォルダを外部ユーザー（Gmail等の社外アドレス）に共有するPower Automateフローで、以下のエラーが断続的に発生するようになった。

The newly created B2B guest user could not be ensured on the site collection
due to the instant-on issue on Entra. Please retry sharing in a few moments.

「アイテムまたはフォルダーへのアクセス権の付与」アクションで発生し、ステータスコードは 400。本記事では原因の切り分けと、最終的に採用した対処方法をまとめる。

環境

• Power Automate（クラウドフロー）
• トリガー：SharePointリストのステータス変更
• 対象アクション：SharePoint「アイテムまたはフォルダーへのアクセス権の付与」
• 共有先：社外アドレス（外部ゲストユーザーとして初めて共有する相手）

発生していた問題

あるタイミングから、外部ユーザーへのフォルダ共有アクションが高頻度で失敗するようになった。エラーメッセージを読む限り、SharePointが共有処理の中で対象ユーザーをEntraのB2Bゲストユーザーとして新規作成しようとするが、そのユーザーがまだ site collection 側で認識される前に権限付与を試みてしまい、失敗しているようだった。

「Please retry sharing in a few moments」とある通り、時間を置いて再試行すれば成功することが多かった。実際、失敗した申請を後から手動で再実行すると、成功していた。

最初に試したこと：単純な遅延の追加

権限付与アクションの前に「遅延」アクションを挟み、数分待ってから実行する方法をまず試した。

遅延（5分）→ アイテムまたはフォルダーへのアクセス権の付与

しかし、これでは解決しなかった。5分待っても、それどころか10分待っても最初の1回目で失敗するケースが続いた。

ここで気づいたのは、**「待つべきタイミングが逆」**だったということ。Entra側でのゲストユーザー作成は、権限付与アクションを実行した瞬間に開始されるようだ。つまり、アクションを叩く前にどれだけ待っても、Entra側では何も起きていない。待つ意味があるのは「1回目を叩いた後」であって「叩く前」ではなかった。

再試行ポリシーが効かない理由

Power Automateの各アクションには標準で「再試行ポリシー」が設定できる。既定では一時的なエラーに対して指数間隔で自動リトライしてくれる便利な機能だが、これは特定のステータスコードにのみ適用されるようだ。

再試行ポリシーは、接続の例外だけでなく、HTTP 状態コード 408、429、および 5xx として表れる断続的なエラーにも適用されます。

出典：堅牢なエラー処理を採用する - Power Automate | Microsoft Learn

今回のエラーはステータス 400。408・429・5xxのいずれにも該当しないため、再試行ポリシーを何回・どんな間隔に設定しても一切発火しない。実際、対象アクションは既定の再試行ポリシー（自動で最大4回リトライ）が有効な状態だったにもかかわらず、失敗は一発目で確定しており、二回目が試行されることはなかった。これは400が再試行ポリシーの対象外であることの裏付けにもなった。

400番台のエラーは、Power Automateの組み込み再試行ポリシーでは救えない

採用した対処：スコープ＋実行条件による手動リトライ

公式ドキュメントで紹介されている「スコープを使ったtry-catchパターン」と「実行後の設定（実行条件）」を組み合わせ、失敗時に自前で待機・再試行する構造を組んだ。

構成

【スコープ】
   遅延①（1分）
     ↓
   アクセス権の付与①
     ↓（失敗 or タイムアウトの場合のみ）
   遅延②（3分）
     ↓
   アクセス権の付与②
     ↓（失敗 or タイムアウトの場合のみ）
   遅延③（8分）
     ↓
   アクセス権の付与③
【スコープここまで】
  ↓（スコープが失敗した場合のみ）
Teamsへ通知
  ↓
終了（ステータス：失敗）

ポイント

1. スコープで囲むことで、内部の成否を1つの結果に集約する

スコープの中で①が失敗し②で成功しても、外から見えるのは「スコープ＝成功」のみ。中間の失敗やスキップは外部に影響しない。もしスコープを使わずに直列でアクションを並べた場合、1回目が成功した瞬間に2回目・3回目が「スキップ」扱いになり、後続処理でスキップを許可していないと予期せず止まってしまう。

2. 実行条件（実行後の設定）の使い分け

各「遅延」アクションの実行条件を「失敗した場合」「タイムアウトの場合」のみに設定し、前段が成功していれば実行されないようにする。これにより、1回目で成功すれば即座にスコープが終了し、無駄な待機が発生しない。

3. 前段の遅延はほぼ意味がない

冒頭で触れた通り、権限付与アクションを実行する前にどれだけ待っても、Entraのゲストユーザー作成は始まっていない。効果があるのは「失敗した後の待機」であり、「実行前の待機」ではなかった。この構造にしてからは、最初の遅延は最小限（1分程度）にとどめ、リトライ間の待機（3分・8分）に重みを置いている。

4. Teams通知＋終了アクションで検知可能にする

スコープが3回とも失敗した場合のみTeamsに通知を飛ばし、続けて「終了」アクション（ステータス：失敗）を置く。通知だけだと通知アクション自体は成功するため実行履歴上「成功」に見えてしまうが、終了アクションでステータスを明示することで、実行履歴からも失敗を判別できるようにした。

結果

この構造に変更後、実際に1回目が失敗して2回目で成功するケースが確認でき、フォルダ共有の失敗が解消した。逆に言うと、フロー変更後、すべてにおいて２回目で成功している。１回目は失敗。3回とも失敗するケースはまだ観測できていないが、その場合はTeams通知で検知できる設計にした。

まとめ

• 400系のエラーはPower Automateの再試行ポリシー（408/429/5xx対象）では救えない
• 「実行前に待つ」と「失敗後に待って再試行する」は効果がまったく異なる。今回のようなタイミング依存のエラーは後者でなければ意味がない
• スコープ＋実行条件の組み合わせで、簡易的なtry-catch構造を自前で作れる
• 通知だけでは実行履歴が「成功」に見えるので、検知したいなら「終了」アクションでステータスを明示するのがおすすめ

参考

• 堅牢なエラー処理を採用する - Power Automate | Microsoft Learn