Power Automateでよくあるエラーと修正方法！これでトラブルも怖くない！

Power Automateでよくあるエラーと修正方法！これでトラブルも怖くない！

「Power Automateのフローが突然止まった！」「エラーメッセージが出たけど、意味が分からない…」「せっかく作った自動化が動かない…」

Power Automate（パワー・オートメイト）を使って業務を自動化していると、避けて通れないのが「エラー」との遭遇です。エラーは、せっかくの自動化プロセスを中断させてしまい、時には業務に支障をきたすこともあります。しかし、エラーは決して「失敗」ではありません。それは、フローの改善点や、あなたが学ぶべき知識を示してくれる「サイン」であり、フローをより堅牢にするための貴重な手がかりなのです。

Power Automateのエラーは多岐にわたりますが、その多くは共通の原因と、具体的な修正方法が存在します。本記事では、Power Automateで頻繁に発生するエラーの種類を具体的にリストアップし、それぞれのエラーがなぜ発生するのか、考えられる限りのエラーメッセージの例を挙げ、そしてどのように修正すればよいのかを、初心者の方にも分かりやすく丁寧に解説していきます。

エラー発生時の基本的な確認事項

具体的なエラータイプに入る前に、どんなエラーでもまず確認すべき基本的なポイントがあります。これらのステップを踏むことで、効率的に問題の原因を特定できます。

フローの実行履歴を確認する:

エラーが発生したフローの実行履歴を開き、どのステップでエラーが発生したかを確認しましょう。エラーになっているステップは、通常赤色のアイコンや「失敗」というステータスで明確に表示されています。

エラーメッセージと詳細情報を確認する:

エラーになっているステップをクリックし、表示されるエラーメッセージの全文と、詳細情報（「出力」や「元のエラー」タブなど、環境によって表示が異なる場合があります）を注意深く読みましょう。ここに原因の手がかりや、APIからの詳細な応答が書かれていることがほとんどです。エラーコードやHTTPステータスコード（例: 400, 401, 403, 404, 500, 502, 504など）も重要な情報です。

入力と出力を確認する:

エラーになっているステップの「入力」データ、そしてその直前のステップの「出力」データを確認しましょう。ステップに渡されたデータが期待通りの形式や内容になっているかを確認することで、データの不整合、型の不一致、または予期せぬ空の値（null）が原因かを判断できます。

もう一度テストしてみる:

ネットワークの一時的な問題、サービスの一時的な不具合などでエラーが発生することもあります。一度だけのエラーなら、条件を変更せずにもう一度テスト実行してみることで解決する場合もあります。

環境と時間帯を考慮する:

特定の時間帯に頻発するか、特定のネットワーク環境（VPN経由など）で発生するかなど、エラーの発生パターンも原因特定のヒントになります。

Power Automateでよくあるエラーとその修正方法【詳細版】

ここでは、Power Automateで頻繁に遭遇するエラーの種類と、それぞれの原因、そして具体的な修正方法を解説します。

エラー：無効な接続 / 認証エラー (Invalid Connection / Authentication Error)

これは、Power Automateが連携先のサービスに接続できない、または認証情報が正しくない場合に発生する、最も一般的なエラーの一つです。

エラーメッセージの例:

Invalid connection

Forbidden

Unauthorized

Access Token is invalid

Unable to authenticate the user

401 Unauthorized (HTTP Status Code)

403 Forbidden (HTTP Status Code)

The resource you are trying to access requires authentication.

Access Denied. You do not have permission to perform this action.

AADSTS500011: The reply URL specified in the request does not match the reply URLs configured for the application.

考えられる原因

• 連携先のサービス（例：Outlook、SharePoint、Salesforce、Azure DevOpsなど）への認証情報（ユーザー名、パスワード、APIキー、トークンなど）が間違っている、または期限切れになっている。
• パスワードを最近変更したが、Power Automateの接続情報を更新していない。
• 多要素認証（MFA）が設定されているが、認証プロセスが正しく完了していない（例：スマホ認証アプリでの承認を忘れている、SMSコードを入力していない）。
• 連携先のサービス側で、接続に使用しているアカウントが無効になっている、またはアクセス権限が変更・剥奪された（例：SharePointサイトの権限から外された、Salesforceのロールが変更された）。
• コネクションを作成したユーザーが退職するなどしてアカウントが削除された。
• Azure Active Directory (Azure AD) 側のアプリケーション登録や同意（Consent）に問題がある。
• SharePoint Onlineの場合: サイトアクセスを許可するユーザーの権限レベルが不足している。

修正方法:

接続の再認証:

• Power Automateの左側メニューから「データ」→「接続」をクリックします。
• 問題のある接続（Statusが「無効」や「エラー」になっているもの）を見つけ、右側の「…」（その他のコマンド）をクリックし、「接続を修正」または「再接続」を選択します。
• 画面の指示に従って、正しいユーザー名とパスワードで再度認証を行います。多要素認証が求められる場合は、認証アプリやSMSなどで認証を完了させましょう。

アカウント情報の確認:

• フローで利用しているアカウントで、連携先のサービスに直接サインインできるか確認し、アカウントが有効であること、そして必要な操作（ファイル作成、メール送信など）を実行するのに十分な権限があることを確かめます。
• パスワードを忘れた場合は、リセットします。

新しい接続を作成する:

既存の接続の修正がうまくいかない場合や、接続が破損していると疑われる場合は、完全に新しい接続を作成し直す方が確実な場合もあります。フローの該当アクションで、新しく作成した接続を選択し直します。

権限の確認:

SharePointやSalesforceなど、権限管理が複雑なサービスの場合、フローが実行されているアカウント（通常はフローの作成者または共有ユーザー）が、対象のファイル、リスト、レコードなどに対して十分なアクセス権限（例：SharePointにファイルを「作成」する権限、Salesforceのレコードを「更新」する権限）を持っているか、システム管理者に確認してもらいます。

エラー：ファイルまたはアイテムが見つからない (File / Item Not Found)

フローが操作しようとしているファイル、フォルダー、リストアイテム、またはその他のリソースが、指定されたパスやIDに存在しない場合に発生します。

エラーメッセージの例

The file couldn't be found.

Item not found.

No item with ID 'XXX' was found.

The specified path does not exist.

404 Not Found (HTTP Status Code)

Resource not found.

File not found in the specified folder.

Cannot retrieve the properties of the item.

考えられる原因

• アクションで指定したファイルパス、フォルダーパス、リスト名、アイテムIDが間違っている（タイプミス、大文字・小文字の間違い、全角スペースなど）。
• ファイルやアイテムが、フローが実行される前に削除された、または別の場所に手動で移動された。
• 動的なコンテンツを使用してパスやIDを渡している場合、その前のステップで正しくパスやIDが取得できていない（例：フィルター条件が間違っていて、次のアクションに渡すIDが空になっている）。
• フローを実行しているアカウントに、そのファイルやアイテムへのアクセス権限がないため、「見えない」状態になっている。
• OneDriveとSharePointのパスの違い: OneDriveの「マイドキュメント」とSharePointの「共有ドキュメント」では、同じファイル名でも内部的なパスが異なります。

修正方法

パス/IDの徹底的な再確認

フローの該当ステップの設定で、指定しているファイルパス、フォルダーパス、リスト名、アイテムIDが正確であるか、SharePointやOneDriveの実際のURLやパスと完全に一致しているかを細かく確認します。可能であれば、対象のURLをブラウザで開いて、実際にリソースが存在するかを確認しましょう。

動的なコンテンツを使用している場合は、フローの実行履歴で、その動的なコンテンツを生成している前のステップの「出力」を確認し、パスやIDが正しく取得されているか（空になっていないか、期待通りの形式か）を確認します。

アクセス権限の再確認

フローが実行されているアカウント（通常はフローの作成者または共有ユーザー）が、対象のファイルやアイテムに対して十分なアクセス権限（読み取り、書き込み、削除など）を持っているか、SharePointやOneDriveの権限設定を確認します。

「パスが存在しない場合」のオプション

ファイルを「作成」するアクションなどで、「パスが存在しない場合」のオプションがあれば、必要に応じて「作成する」などを選択します。

条件分岐で存在チェックを追加

ファイルやアイテムが存在するかどうかが不定のシナリオ（例：オプションの添付ファイル）では、それを操作するアクションの前に「OneDrive for Businessの『ファイルが存在するか』アクション」や「SharePointの『項目を取得』の後の『条件』アクションで、取得件数が0かどうかをチェックする」といったステップを追加し、存在しない場合はエラーとして処理を停止させず、別のパス（例：管理者へ通知する、処理をスキップする）に進むようにすることで、フローの堅牢性を高めることができます。

エラー：条件に合致するアイテムがない / データがない (No Item Found Matching Criteria / No Content)

これは、フローがフィルター条件に基づいてデータを取得しようとした際に、その条件に合致するデータが一つも見つからなかった場合に発生します。厳密には「エラー」ではなく、フローが「期待通りのデータが見つからなかった」ことを示し、その後のアクションが失敗する原因となります。

エラーメッセージの例

No items were found that match the criteria.

The query returned no data.

Filter returned no data.

The 'Apply to each' action could not be executed because the provided input was null or empty. (直後のApply to eachで発生しやすい)

No content to process.

考えられる原因

• 「アイテムの取得（SharePoint）」「行のフィルター（Excel Online）」「レコードの取得（Salesforce）」などのアクションで指定したフィルター条件（例：Status eq '承認済み'、LastModified le '2025-01-01'）が間違っている。
• フローが実行された時点で、その条件に合致するデータが実際に一つも存在しなかった。
• 動的なコンテンツで渡されたフィルター値が正しくない、または空（Null）になっている。
• データの形式が期待と異なっていたため、フィルターが機能しなかった（例：数値列なのに文字列で比較している）。
• 「取得元」のサービスにアクセス権限がないため、データが見つからないように見えている。

修正方法

フィルター条件の厳密な再確認:

• 設定したフィルター条件が正しいか、余分なスペース、タイプミス、大文字・小文字の間違いがないかを細かく確認します。
• SharePointリストの列名やExcelのヘッダー名、データベースのフィールド名が正確か、ODataクエリの構文（例：eq の代わりに = を使っていないか、文字列はシングルクォートで囲んでいるか）が正しいかを確認します。
• 可能であれば、実際にその条件で手動で検索してみて、データが見つかるか確認します（例：SharePointリストでビューを作成し、フィルターを設定してみる）。

データが存在しない場合の処理を設定（推奨）

データが見つからないことが予期されるシナリオ（例：日次レポートで、その日にデータがない場合など）では、その後のアクションに進まないように「条件」アクションを追加し、データが存在しない場合の処理（例：通知を停止する、管理者へ通知する、何もしない）を設定することで、フローが不必要にエラーになったり、不完全な処理が実行されたりするのを防げます。

例: 「アイテムを取得」アクションの後に「条件」アクションを置き、条件を「length(outputs('アイテムの取得')?['body']?['value']) is equal to 0」（取得したアイテム数が0の場合）と設定し、「はい」のパスで「通知を送信しない」といった処理にします。これは、「条件」アクションの代わりに「現在の項目が空の場合」や「現在の項目がない場合」といった専用のアクションが提供されているコネクタがあれば、そちらを利用する方が直感的です。

データ型の一致を確認

フィルター条件で比較しているデータ型が一致しているか確認します。数値列を文字列として比較していないか、日付形式が正しいかなど。int(), string(), formatDateTime() などの式を使って、データ型を明示的に変換することで解決する場合があります。

エラー：タイムアウト (Timeout)

フローの特定のステップが、Power Automateまたは連携先のサービスによって設定された時間内に完了しなかった場合に発生します。特に大量のデータを処理するアクションや、外部サービスへの接続で応答が遅い場合に起こりやすいです。

エラーメッセージの例

The request to the backend service timed out.

The action did not complete within the allowed time.

504 Gateway Timeout (HTTP Status Code)

The proxy or gateway did not receive a timely response from the upstream server.

Connection to [Service Name] timed out.

考えられる原因

• アクションが処理するデータ量が多すぎる（例：数万行のExcelデータの一括読み込み、数千件のリストアイテムの更新）。
• 連携先のサービスが一時的に遅延している、または高負荷状態にある。
• ネットワークの帯域が不足している、または通信経路に問題がある。
• カスタムコネクタやHTTPコネクタでのWeb API呼び出しで、API側の処理に時間がかかっている、または応答が遅い。
• 「Apply to each」ループ内で、非常に時間のかかるアクション（例：大容量ファイルの処理、複雑なAI Builderアクション）が多数実行されており、ループ全体の実行時間が長くなりすぎている。
• フローの実行時間がPower Automateの最大制限（例：無料プランでは5分、有料プランでも30日間など）を超過している。

修正方法

処理を分割し、最適化する

• 一度に処理するデータ量を減らします。例えば、大量のリストアイテムを一度に取得して処理するのではなく、フィルターやビューを使って少量のデータを複数回に分けて取得・処理する（ページネーションの実装）ことを検討します。
• Power Automateの「並列処理」オプション（「Apply to each」アクションの設定で、同時実行数を変更可能）を有効にすることで、複数のアイテムを同時に処理し、全体の処理時間を短縮できる場合があります。ただし、API制限に注意が必要です。

タイムアウト設定の調整

フローデザイナーの該当アクションの設定を開き、「設定」→「タイムアウト」の値を長くできる場合があります（デフォルトは通常1分）。ただし、極端に長くするとフロー全体の実行時間が長くなり、他の問題を引き起こす可能性もあります。すべてのコネクタでタイムアウト設定の変更がサポートされているわけではありません。

遅延アクションの追加

API呼び出しが連続するステップの間や、次のアクションに進む前に、強制的に数秒間待機させる「遅延」アクションを挿入することで、API制限に達するのを防いだり、連携先のサービスが応答する時間を与えたりできます。

連携先のパフォーマンスを確認

外部サービス側の状態（システム障害、メンテナンス、高負荷など）を、そのサービスのステータスページなどで確認します。

フローの構造を最適化する:

• 「Apply to each」ループ内で、不必要なAPI呼び出しや、冗長な処理がないかを見直します。例えば、ループ内で繰り返し同じデータを取得するのではなく、ループの外で一度だけ取得して変数に格納し、ループ内で変数を利用するなど、API呼び出しの回数を最小限に抑える設計を心がけましょう。
• SharePointの「アイテムの取得」で複雑なフィルターや並び替えを行う場合、インデックス列を設定することでデータベースの応答速度が向上し、タイムアウトを防げる場合があります。

ライセンスプランの見直し

現在のライセンスプランの実行回数やAPIリクエスト上限が不足している場合は、より上位のPower Automateライセンス（Power Automate Premiumなど）へのアップグレードを検討します。

エラー：コンテンツサイズ制限 (Content Size Limit Exceeded)

アクションが処理しようとしているデータのサイズが、Power Automateまたは連携先のサービスによって設定された許容範囲を超えている場合に発生します。特に大きなファイルを扱う場合に起こりやすいです。

エラーメッセージの例

• The file size exceeds the maximum limit.
• The content-length of the payload cannot exceed 'X' bytes.
• Request body too large.
• File is too large to be processed.

考えられる原因

• フローが非常に大きなファイルをアップロード、ダウンロード、または変数として扱おうとしている。
• 画像やBase64エンコードされたファイルコンテンツなど、見かけ以上にデータサイズが大きい場合。
• テキストエリアに大量の文字列を挿入しようとしている。
• Power Automateの実行履歴のログに表示できるデータのサイズにも上限があり、そのためにエラーになる場合もあります。

修正方法

ファイルサイズの削減

可能であれば、ファイルを圧縮する、解像度を下げる、不必要なメタデータを削除するなどしてファイルサイズを小さくします。

代替手段の検討

• Power Automateで直接処理するのが難しいほど大きなファイルの場合は、Azure Blob StorageやSharePointなどの専用ストレージサービスに直接アップロードし、そのファイルへのURLをPower Automateで取得して、SharePointやTeamsで共有するなど、別の方法を検討します。これにより、Power Automateのペイロード制限を回避できます。
• 大きなファイルを扱うための専用コネクタやAPIが提供されているか確認します。

ストリーミング対応のコネクタの利用:

一部のコネクタやアクションは、大きなファイルをストリーミングで処理するオプションを持っています。そのような機能が提供されていれば利用を検討します。

データソースの最適化:

データベースから大量のテキストを取得する場合、必要な列のみを選択するなどして取得するデータ量を減らします。

エラー：APIの制限超過 / スロットリング (API Rate Limit Exceeded / Throttling)

短時間で多数のAPIリクエストを送信しすぎた場合に、連携先のサービス（例：Microsoft Graph API、SharePoint API、Salesforce APIなど）から拒否されるエラーです。これは、サービスの負荷を保護するために設けられた制限です。

エラーメッセージの例

• Rate limit exceeded.
• Too many requests.
• 429 Too Many Requests (HTTP Status Code)
• API call limit reached for [Service Name].
• Throttled by the service.

考えられる原因

• フローが非常に頻繁に実行される、または「Apply to each」ループ内で多数のAPI呼び出しが短時間に集中して行われている。
• Power AutomateのライセンスプランのAPIリクエスト上限（テナントやユーザーごとの1日あたりのAPIコール数）に達している。
• 連携先のサービス自体が、短時間でのAPI呼び出しに厳しい制限（スロットリング）を設けている。
• 複数のフローが同時に同じサービスに対して大量のAPIコールを行っている。

修正方法

実行頻度とAPI呼び出しの削減:

• トリガーの実行頻度を減らす（例：1分おきではなく5分おき、あるいは30分おきにする）。
• 「Apply to each」ループ内で不必要なAPI呼び出しがないか見直し、可能であればループの外で一度にデータを取得して変数に格納し、ループ内で変数を利用するなど、API呼び出しの回数を最小限に抑える設計を行います。
• 連携先のサービスがバッチ処理（複数の操作を一つのAPIリクエストで実行）が可能なAPIを提供していれば、それを利用してAPI呼び出しの回数を減らします。

遅延アクションの追加

API呼び出しが連続するステップの間や、特に「Apply to each」ループ内での個々のアクションの実行後に、「遅延」（Delay）アクションを挿入し、数秒間（例：1〜5秒）待機させることで、API制限に達するのを防ぐことができます。これにより、APIサーバーに過度な負荷をかけずに済みます。

再試行ポリシーの調整

該当アクションの「設定」で、「再試行ポリシー」を設定します。API制限は一時的なものであることが多いため、エラーが発生した場合に数秒間隔で数回（例：間隔10秒、回数3回）再試行するように設定することで、一時的なエラーを乗り越え、フローが正常に完了する可能性を高められます。

ライセンスプランの見直し

現在のライセンスプランのAPIリクエスト上限が、ビジネス要件に対して恒常的に不足している場合は、より上位のPower Automateライセンス（Power Automate Premium、Power Automate Process Miningなど）へのアップグレードを検討します。これにより、利用可能なAPIリクエスト数が増加します。

フローの分散

一つの非常に大きなフローで全ての処理を行うのではなく、複数の小さなフローに分割し、それぞれのフローが異なるタイミングで実行されるように調整することで、API制限を分散させることができます。

エラー：条件の記述ミス / 論理エラー (Conditional Error / Logical Error)

これは、フローの論理的な設計ミス、条件式の記述ミス、またはデータ型の不一致によって、フローが意図しない動作をする、またはエラーが発生する場合です。特定のエラーメッセージが表示されず、単にステップが「失敗」する、あるいはフローは成功したと表示されるのに結果が期待と異なる、といった形で現れることが多いです。

エラーメッセージの例

• （特定のエラーメッセージは出ず、単に「失敗」ステータス）
• The 'if' condition was not met. (条件アクションが「いいえ」のパスに進むべきなのに「はい」に進んだり、その逆だったりする場合)
• The expression could not be evaluated.
• Invalid template expression.
• An array, a string or an object is required. (JSONや配列操作で、空の値や間違ったデータ型が渡された場合)

考えられる原因

• 「条件」アクションで設定した条件式が間違っている（例：A == "True" とすべきところを A = True と記述した、大文字・小文字が異なっている、文字列比較でスペースが入っている）。
• 動的なコンテンツで渡された値が期待するデータ型（文字列、数値、真偽値など）と異なっている（例：数値として扱うべき値を文字列として比較している）。
• フローのロジックが複雑になりすぎ、論理的な誤りがある（例：必要なデータが取得される前にアクションを実行しようとしている）。
• 「Apply to each」のループ内で、必要なデータが取得できていない、または変数が正しく初期化されていない、あるいはスコープ外の変数を使用しようとしている。
• JSONデータをパースする際に、JSONスキーマが実際のデータ構造と一致していない。
• 空（Null）の値を処理する際の考慮が不足している。

修正方法

条件式の厳密な再確認とデバッグ:

条件アクションの設定を再度開き、式や値が正確かを確認します。特に、文字列の比較では大文字・小文字、全角/半角スペースに注意します。

「式」ビルダーを使って式を作成し、関数名や引数の構文が正しいか、エラーがないかを確認します。複雑な式は、小さな部分に分解して「作成」（Compose）アクションで出力し、途中の値を確認しながらデバッグすると効率的です。

equals(), contains(), startsWith(), endsWith() といった正確な関数を使っているかを確認します。

入力と出力の確認を徹底する

フローの実行履歴で、条件アクションや問題が発生しているアクションの直前のステップの「出力」を詳細に確認し、条件で評価しようとしている値が、期待通りの形式や内容で渡されているかを確認します。データ型が一致しているかは特に重要です。

変数とデータ型の適切な管理

• 変数を定義する際に、そのデータ型（文字列、数値、真偽値、配列、オブジェクトなど）を正しく設定しているか確認します。
• 異なるデータ型の間で操作を行う場合は、string(), int(), float(), bool() などの式を使って、明示的にデータ型を変換することで、型不一致のエラーを回避できる場合があります。
• JSONデータを扱う場合は、「JSONの解析」（Parse JSON）アクションで正確なスキーマを指定し、データ構造の不整合を防ぎます。

フローの構造を整理し、視覚化する

• 複雑なフローの場合、論理的な誤りを発見するために、フローをより小さなセクションに分割し、それぞれを「スコープ」アクションでまとめることを推奨します。これにより、フローの可読性が向上し、問題の切り分けが容易になります。
• 「作成」（Compose）アクションをフローの途中に挟み込み、特定のアクションの出力や変数の内容を一時的に表示させることで、フロー実行中にデータがどのように変化しているかを確認し、デバッグの助けとすることができます。

Null（空の値）処理の考慮

動的なコンテンツの中には、状況によって値が空（Null）になる可能性があるものがあります。Nullのまま次のアクションに渡されるとエラーになる場合があるため、「条件」アクションでNullチェックを行うか、coalesce()などの式を使ってデフォルト値を設定するなどの対策が必要です。

まとめ

Power Automateにおけるエラーは、自動化の「壁」のように感じるかもしれませんが、それは同時に、あなたのスキルを磨き、フローをより堅牢に、より正確にするための「教師」でもあります。

今回解説した様々なエラーの原因と修正方法を理解しておくことで、エラーが発生しても慌てることなく、冷静に、そして体系的に対処できるようになるでしょう。

エラーメッセージを丁寧に読み解くこと。フローの実行履歴を細かく確認し、入力と出力を比較すること。そして、仮説を立てて修正し、再度テストする。 このサイクルを粘り強く繰り返すことが、Power Automateのスキルを飛躍的に向上させ、どんなトラブルにも対応できる自信を育むための最も効果的な方法です。