目次
まず同じブックへ書く処理を探す
Power AutomateのExcel Online (Business) actionで「file is locked for shared use」と出たら、同じactionを連打する前に、そのExcelファイルを更新・削除している処理を洗い出します。Microsoftのコネクタ資料は、同一ファイルを複数clientから同時に変更する方法をサポートせず、Excel Desktop、Excel Web、Power Automate、Logic Apps、Power Appsなど複数経路からの同時書き込みを避けるよう案内しています。失敗runだけでなく、同じOneDrive / SharePoint上の別flow、手動編集、他connectorの書き込みも確認してください。
同じfileへの同時更新が見つかったら、retry回数を増やす前にwriterを一つへ整理できるか検討します。二つのflowが同じ表を更新するなら、処理をqueueへ集める、親flowから一つの子flowへ渡す、対象データを別fileに分けるなど、ownerとデータ構造に合う方法を選びます。共有ブックの運用変更が必要なら、利用者へ影響を伝え、所有者と合意してから進めます。
lock時間とretryを混同しない
Excel Online (Business)の公式資料は、connectorを最後に使ってから最大6分、ファイルがupdateまたはdeleteのためlockされる場合があると説明しています。これは「6分待てば必ず解除される」という保証ではありません。別connector操作、別flowのrun、ユーザー編集が続いていれば再び競合します。時刻だけで判断せず、実行履歴と同時writerの状態を照合します。
Power Automateのretry policyは、ネットワークやserviceの一時障害を回復するための仕組みです。Microsoftは固定間隔と指数backoffを説明し、待ち時間を段階的に伸ばす方法を案内しています。しかし、別runやユーザーが同じfileを書き込み中なら、retryを繰り返しても競合原因は残ります。再試行前にwriterが終了したか、前回runがどこまでデータを書いたかを確認します。
Run historyで原因候補を特定する
Run historyから、lock errorの発生時刻、失敗action、対象file、直前に成功したactionを記録します。同じfileを使うflowがある場合、そのrunの開始・終了時刻も並べます。Excelを開いたままの手動編集、別Power Automate flow、Power Apps、Logic Apps、connector経由の更新が同時刻にあれば、同時実行の可能性を調べます。まだ確認できないことを「前のrunのlock」と断定しないでください。
connector利用後にupdate/deleteが最大6分lockされる可能性と、複数clientの同時変更がサポート外であることを合わせて見ます。Run historyだけで一つの原因に決めず、最後にconnectorを使った時刻、別ユーザーや別flowの編集を同じ時間軸に置きます。対象fileのpathや識別子が環境ごとに違う場合、見た目のファイル名だけで同一性を判断しないことも重要です。
失敗actionの前に「行を追加」「表を更新」「Office Scriptを実行」などがあるなら、同じrun内でどこまで処理が完了したかを確認します。flow全体がFailedでも、先行actionがデータを書いた可能性があります。再実行で同じ行を二重追加しないよう、業務上の一意キー、処理済み状態、実行IDを使って対象recordを照合します。
原因別の修正方針
手動編集とflowが重なる場合：編集を止める時間帯を利用者と決める、同じ共有fileの書き込み担当を整理する、またはflowが処理するデータを別の場所へ分ける方法を検討します。lock中のセルを強制解除する操作はせず、編集者とownerに保存状態を確認します。
同じflowのrunが重なる場合：trigger設定とRun historyを確認し、複数runが同時に同じfileへ到達する条件を特定します。Concurrency controlを使う場合は、他runの処理順や待ち行列への影響を事前に見積もります。
Microsoftはtrigger concurrency controlで同時run数を制限できると説明しています。ただし、同資料は有効化すると元へ戻すにはflowを作り直す必要があるとも注意しています。既存flowで安易にONにせず、owner、実行順、待機run、接続や運用の再構築負荷を確認してください。単一bookを直列化したい場合も、全flowへ一律適用せず、必要な子flowだけを制御できるか検討します。
retryが再負荷になっている場合：同一fileへ短時間に接続し続けていないか、retry間隔・上限が障害に合っているかを確認します。指数backoffは一時障害向けの候補ですが、失敗種類が変わらないままretryだけ増やさないでください。lockが残る間の反復更新は、後続データの不整合や二重処理を起こす可能性があります。
Excel connector以外も混在する場合：手動編集、他connector、flow、Logic Apps、Power Appsのどれが書き手かを記録し、書き込み責任者を決めます。複数clientによる同時更新を避ける設計が必要なら、Excel actionのretryだけでなく、データ書き込み経路の一本化をownerと検討します。
安全に再開する手順
-
Failed runを開き、失敗action、対象file、時刻、直前に成功したExcel actionを控えます。共有ログへ認証情報やファイル内の個人情報を貼らないでください。
-
同じfileへアクセスする別run・別flow・Excel Web/Desktopでの手動編集を確認します。書き込み中の処理が残っているなら、所有者へ完了を確認するまで再実行しません。
-
先行actionが行追加や更新を済ませていないかを照合します。業務キーや処理済み状態で既反映データを確認し、同じ操作が重ならないことを確かめます。
-
同時writerをなくす、または順序を管理できた後に必要なretryを設定します。指数backoffなどの一般設定を個別lockの解除保証と扱わず、業務期限とconnectorの応答に合わせます。Concurrency controlを変える場合は、戻せない特性をownerと確認します。
-
再実行後はactionの成功だけでなく、対象行数、更新前後のキー、重複行、後続action、通知を検算します。想定件数と違う場合はflowを止め、追加変更の前にownerへ状況を渡します。
再実行前の確認表
同じfileに別writerがいない。見つかったら、終了時刻と所有者を確認して同時書き込みを避ける。
今回失敗するまでに完了したactionを把握している。行追加済みなら一意キーで重複を確認する。
connectorの最後の利用時刻と最大6分のlock可能性を考慮したが、時間経過だけを解除保証にしていない。
Concurrency controlを変えるなら、元に戻す際にflow再作成が必要な注意を理解し、ownerと確認した。
retryは一時障害向けに使い、同時writerや二重処理を隠していない。
よくある誤解
「FailedだからExcelは何も変わっていない」とは限りません。直前のactionが成功していれば、データを書いた可能性があります。Run historyと業務キーで実状態を確かめてください。
「6分待てば必ずlockが消える」とも限りません。Microsoftの資料はconnector利用後に最大6分lockされる場合を説明しますが、別clientの編集継続まで解消するものではありません。
「retry回数を増やせば直る」も安全な結論ではありません。一時障害ならbackoffが役立つ場合がありますが、同一fileへの同時書き込みはwriterを整理しなければ再発します。
「Concurrency controlは後で元に戻せる」と決めつけないでください。Microsoftのtrigger guidanceは、有効化後に無効へ戻すにはflowを作り直す必要があると注意しています。対象flowのownerと再構築方法を確認せずに変更しないでください。
引き継ぎに残す情報
Workbookの保存場所と識別子、対象table、flow名、trigger、Excel action、失敗時刻、同じfileへ書くclient、成功済みaction、処理済みkey、retry設定、再実行者を記録します。複数の書き込み担当がいるなら、どの経路を誰が所有するかも残します。
再発後に調査を繰り返さないよう、確認済みの同時writer、変更したtrigger/retry、二重処理防止key、再開条件をrunbookに記載します。connectorのlock仕様やUIは変わる可能性があるため、時間や制限はMicrosoftの現行資料と確認日を添えて管理します。
完了条件と次の行動
Reader Jobの完了条件は、lockを単なる一時エラーとして再試行するのではなく、同一fileへのwriterとRun historyから原因候補を絞り、二重処理を防ぐ再開条件を決められることです。対象fileのowner、同時writer、既に反映した行、retryの用途を特定すれば、実行担当へ具体的な調査結果を渡せます。
Concurrency controlを変える場合は、Microsoftが示す戻しにくさを確認しownerの合意を得ます。対象fileに人が編集中、既存runの結果が判別できない、更新済みデータの復元方法がない場合はretryを止め、管理者へ引き継いでください。
この記事は特定のExcel workbookやflowを実際に修復した体験談ではありません。MicrosoftのconnectorとPower Automate公式資料に基づき、lock候補、並列実行、retry、再処理の安全性を分けて診断する手順です。
Sources
Microsoft Learn, Excel Online (Business) connector: https://learn.microsoft.com/en-us/connectors/excelonlinebusiness/（新しいタブで開く）
Microsoft Learn, Optimize Power Automate triggers: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/optimize-power-automate-triggers（新しいタブで開く）
Microsoft Learn, Employ robust error handling: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling（新しいタブで開く）
確認日：2026-10-15。Excel Online (Business)の最大6分lock可能性、同一fileへの同時変更非対応、trigger concurrency controlの特性、retry policyを公式資料で確認。