【Power Automate】共有接続の再認証が想定どおり進まない時の入力条件と処理順の見直し

Power Automateの共有接続は、複数のフローやユーザーで同一の認証情報を利用できる便利な機能です。しかし、再認証が必要になった際に、想定どおりに更新が反映されず、フローがエラーで停止してしまうケースが報告されています。原因は接続自体の問題だけでなく、トリガー条件やアクション内の条件設定、フローの実行順序に起因する場合が少なくありません。本記事では、共有接続の再認証がスムーズに進まない場面において、入力条件と処理順の観点から問題を切り分け、具体的な解決策を解説します。

共有接続の再認証が想定どおり進まない主な原因

共有接続の再認証が失敗する背景には、いくつかの典型的なパターンがあります。まず、トリガー条件に依存した問題です。例えば、SharePointのリストアイテム作成をトリガーとするフローで、「自分が追加した場合のみ」という条件を設定していると、再認証後にフローが期待どおり起動しなくなることがあります。これは、再認証によりユーザーコンテキストが変化し、条件式内のユーザー識別子が異なる値を返すためです。

次に、アクション内の条件設定が原因となるケースです。各アクションの詳細設定で、特定の条件下のみ実行するような条件を追加していると、再認証後その条件が満たされず、アクションがスキップされる場合があります。さらに、フローの処理順も重要です。並列処理を使用していると、複数のアクションが同時に認証を要求し、トークン競合が発生することがあります。結果として、一部のアクションだけ認証が適切に更新されず、エラーが継続します。

トリガー条件の影響

トリガー条件は、フローが起動するかどうかを決定する重要な設定です。共有接続の再認証後、トリガー条件で使用している関数や値が想定と異なる動作をすることがあります。特に、@equals(triggerBody()?['Author'], 'user@domain.com') のようなハードコードされたユーザー名を含む条件は、再認証コンテキストが変更されると正しく機能しません。代わりに、動的な値や @triggerOutputs() を利用した汎用的な条件を使用することを推奨します。

アクション内の条件設定の影響

アクションごとに追加された条件(「条件を追加」ボタンから設定)も、再認証の妨げになることがあります。例えば、あるアクションで「ファイルのプロパティが特定の値と一致する場合のみ実行」と設定していると、再認証後にそのプロパティ値が変わった場合、アクションがスキップされ、結果的にフロー全体が完了しない事態が起こります。このような場合、条件を緩和するか、アクションの実行を必須に変更する必要があります。

処理順と並列処理の影響

Power Automateでは、アクションを並列に実行する設定が可能です。しかし、共有接続の再認証が複数のアクションで同時に行われると、認証サーバー側で競合が発生し、一部のアクションだけが新しいトークンを取得できない現象が起きます。特に、同一の共有接続を複数の並列ブランチで使用している場合に顕著です。解決策として、並列処理を直列に変更するか、各ブランチで異なる共有接続を使用するように設計を変更します。

入力条件の確認ポイント

再認証トラブルに遭遇したら、まず各アクションの入力条件を精査してください。以下の手順に従って、問題の所在を特定することができます。

1. Power Automateポータル(https://make.powerautomate.com)にサインインし、該当するフローを開きます。
2. フロー編集画面で、トリガーを選択し、「トリガー条件」のリンクをクリックします。高度モードで表示されている式を確認してください。式に固定のユーザー名や古い接続参照が含まれていないか確認します。
3. 各アクションの「…」メニューから「設定」を開き、「条件を追加」で設定された条件がないか確認します。条件がある場合は、その条件式が再認証後も成立するかどうかを検討します。
4. アクションの「接続プロパティ」を確認し、使用している接続が共有接続として正しく設定されているか、また最新の認証情報が反映されているかを確認します。接続プロパティはアクションの詳細ペインに表示されます。
5. トリガー条件やアクション条件に、@triggerBody() や @outputs() などの動的コンテンツを使用している場合は、その値が再認証後に想定どおりになるかテスト実行で確認します。

処理順の見直し手順

フローの処理順が原因で再認証がうまくいかない場合、以下の手順で見直しを行います。とくに、並列処理が多用された複雑なフローでは、一つひとつ確認する必要があります。

1. フロー編集画面で、アクションの配置を視覚的に確認します。並列ブランチ(二重線で表示)が存在するかどうかを特定します。
2. 各並列ブランチ内で、同一の共有接続を使用しているアクションがないか確認します。もしあれば、そのアクションを同一ブランチにまとめるか、直列に変更します。
3. 並列処理を直列に変更するには、ブランチの追加や削除を行います。アクションの順序をドラッグ&ドロップで入れ替え、依存関係を考慮して直列の流れにします。
4. フローの「テスト」機能で、テスト実行を行います。テストデータを使用して、再認証が正しく行われるか、またエラーが発生しないかを確認します。
5. 直列処理に変更した後も問題が解決しない場合は、各アクションの「実行後」の設定(タイムアウトや再試行ポリシー)が影響していないか確認します。

状況別の比較表

状況	考えられる原因	確認手順	解決策
再認証ボタンがグレーアウトして操作できない	フローの所有者と接続の所有者が異なる、または権限不足	フローの「所有者」タブで所有者一覧を確認し、現在のユーザーが含まれているか確認	フロー所有者に再認証を依頼するか、自身を所有者として追加してもらう
再認証後にフローが起動しない	トリガー条件が再認証後のコンテキストに合わなくなった	トリガー条件の高度式を表示し、固定値がないか確認	条件式を動的コンテンツに変更する(例: @equals(triggerBody()?['Author'], 'user@domain.com') を削除)
一部のアクションだけ認証エラーが続く	アクションが個別に古い接続を参照している、または並列処理の競合	エラーアクションの接続プロパティを開き、接続名と共有接続の一覧を比較	すべてのアクションで同一の共有接続を使用するように変更し、フローを保存後再テスト
再認証が完了してもフロー実行履歴にエラーが残る	再認証のタイミングとフロー実行タイミングのずれ	フロー実行履歴の「エラーの詳細」で、認証エラーのタイムスタンプを確認	再認証後にフローを保存し直し、新規のテスト実行でエラーが再現しないか確認

具体的な操作手順(再認証の一連の流れ)

ここでは、共有接続を再認証する標準的な手順を説明します。この手順に加えて、前述の入力条件および処理順の確認も合わせて行ってください。

1. Power Automateポータルにサインインし、左ナビゲーションから「データ」→「接続」をクリックします。
2. 接続一覧から該当する共有接続を探し、接続名をクリックして詳細を開きます。
3. 「認証の編集」または「更新」ボタンが表示されている場合は、クリックして認証情報を再入力します。多くの場合、サインイン画面が開くので、適切なアカウントでログインします。
4. 更新が完了したら、接続詳細画面で「状態」が「接続済み」になっていることを確認します。
5. 次に、該当のフローを開き、各アクションの接続設定が新しい共有接続を参照しているか確認します。アクションの「…」→「設定」→「接続」でドロップダウンから選択し直すことができます。
6. すべてのアクションの接続が統一されたら、フローを保存します。
7. フローをテスト実行し、エラーが解消されたか確認します。テスト実行で問題がなければ、運用環境で再開して問題ありません。

管理者へ確認すべき情報

上記の手順を試しても問題が解決しない場合、管理者に以下の点を確認してください。環境によっては、管理者権限が必要な設定が原因で再認証がブロックされている可能性があります。

• データ損失防止ポリシー(DLP): DLPポリシーで、フローで使用しているコネクタ(例:SharePoint、Outlook)が許可されているかどうか。特に共有接続を明示的に許可する設定になっているか確認します。
• コネクタのアクセス権限: コネクタの「共有」設定で、組織全体または特定のセキュリティグループに許可が与えられているか。アクセス権限がないと再認証ができない場合があります。
• ユーザーのライセンス: Power Automateのライセンス(Premium または Standard)によって、共有接続の使用が制限されることがあります。Premiumライセンスが必要なコネクタもあるため、ライセンス割り当てを確認します。
• テナント全体の認証設定: Azure Active Directoryの条件付きアクセスポリシーや多要素認証(MFA)の設定が、Power Automateの接続に影響を与えていないか確認します。

よくある質問

Q1: 共有接続の再認証は誰が行うべきですか?
A: 通常は接続の所有者が再認証を行います。フロー所有者が異なる場合は、フローの「所有者」タブで確認し、接続所有者に依頼してください。フロー所有者と接続所有者が同一でない場合、再認証ボタンがグレーアウトすることがあります。

Q2: 再認証の際に「アクセスが拒否されました」と表示される原因は?
A: ユーザーにその接続へのアクセス権限がないか、DLPポリシーでブロックされている可能性があります。管理者に権限設定とDLPポリシーを確認してもらってください。また、対象のサービス(例:SharePoint)へのアクセス権限が適切かも確認します。

Q3: 複数のフローで同じ共有接続を使用している場合、再認証は1回で済みますか?
A: はい、共有接続自体は1回の再認証で更新されます。ただし、各フロー内のアクションが古い接続を参照している場合は、フローごとに接続設定を更新する必要があります。自動的には反映されませんので、注意してください。

Q4: トリガー条件にユーザー名を含めると再認証で問題が起きるのはなぜですか?
A: 再認証によりユーザーコンテキストが変わり、条件式内のユーザー名が期待する値と一致しなくなるためです。たとえば、再認証を行ったユーザーが元のフロー所有者と異なる場合、@triggerOutputs() の値が変わる可能性があります。動的コンテンツを使用するか、条件自体を削除することを検討してください。

Q5: 並列処理を使用しているフローで再認証が失敗するのはなぜですか?
A: 並列処理では複数のアクションが同時に認証トークンを要求するため、サーバー側で競合が発生することがあります。特に、同一の共有接続を複数の並列ブランチで使用している場合に顕著です。直列処理に変更するか、ブランチごとに異なる共有接続を使うように設計を見直してください。

まとめ

共有接続の再認証が想定どおり進まない場合、まずトリガー条件やアクション内の条件設定を見直すことが重要です。固定値を使わず、動的コンテンツを活用することで、再認証後のコンテキスト変化に対応できます。次に、フローの処理順を確認し、並列処理が競合を引き起こしていないかチェックします。並列処理が原因であれば直列処理への変更を検討します。これらの切り分け手順を実践することで、再認証トラブルの解決時間を大幅に短縮できるでしょう。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。