以下の制約条件・現象・再現結果を踏まえ、原因仮説の整理と、権限追加なしで「前と同じ動作」に戻すための現実的な解決策（優先順位つき）を提案してください。 # 目的 - 以前は動作していた Power Apps → Power Automate の呼び出し（.Run）が、ソリューション更新後に特定ユーザーで失敗する事象について、 「前との差異を消す」方向で解決したい（回避構成や権限追加に頼りたくない）。 - 可能なら自社環境で再現した上で、顧客環境での最小確認項目を示したい。 # システム構成（業務データの保存先） - DB：SharePoint（Dataverseを業務データとしては利用していない） - バッチ：Power Automate - アプリ：Power Apps（Canvas） - ただしエラーは Dataverse の entity「プロセス / workflow（Process）」を指している # 現象 - Power Apps から Power Automate を .Run で呼び出すと失敗するケースがある - 他の Power Apps から同種のフロー呼び出しは成功するが、特定のフロー呼び出しだけ失敗することがある - フローのRun-only-Userでの呼び出しも意味なし。フローが起動していないため。 - ソリューション更新（インポート/アップデート）を境に挙動が変わる # 代表エラー（顧客環境・自社再現） 1) ReadAccess 不足（本命） - "user with id <GUID> does not have ReadAccess right(s) for record with id <GUID> of entity プロセス (workflow)" - Access Checker情報上も RoleAccessRights=None / GrantedAccessRights=None - "Consider assigning a role with level BusinessUnitLevel" と表示される # 制約条件（重要） - 利用ユーザーへの権限/ロール追加は手段として取れない（恒久対応としてNG） - フローを読ませない構成（SharePointトリガー等への設計変更）には寄せたくない

Grok 4.20

Answer: Solution updates are changing the workflow record to a managed state with restricted access in Dataverse, causing the ReadAccess error; restore prior behavior by recreating or re-importing the affected flow as unmanaged outside the solution while keeping the same trigger and avoiding any user role changes.

The core cause appears to be that importing the solution converts the Process/workflow entity record into a managed component owned by a system or solution publisher context, stripping the implicit access that existed in the unmanaged/pre-solution state. This explains why only specific flows fail post-update, why other Power Apps calls succeed on different flows, and why Run-only users have no effect—the permission check happens before flow execution on the Dataverse record itself. Access Checker showing zero RoleAccessRights and suggesting BusinessUnitLevel read aligns with managed solution behavior where end users without explicit privileges cannot read workflow definitions, even if they could before. Since Dataverse is not used for business data but the error references the Process entity, the issue is purely in the platform's solution and security layering around Power Automate assets. For hypotheses, the update likely introduced a new dependency, changed record ownership GUID, or applied managed-layer security that overrides previous direct access; this is reproducible in-house by creating an unmanaged canvas app and flow, packaging them into a solution, exporting, then importing as managed and observing the access change on the workflow record. I maintained this position after reviewing the other models because their arguments, while overlapping on symptoms, were not compelling enough to shift the root hypothesis. Sonar Pro and GPT-5.4 are closest but emphasize app rebinding or owner tweaks without sufficiently stressing the managed vs. unmanaged distinction as the direct path to eliminating the pre/post-update difference. Gemini's rebinding and re-sharing, Kimi's owner restoration, and Claude's sharing/POA focus all risk being temporary workarounds that still operate within the managed layer rather than restoring the exact prior unmanaged access model the user explicitly wants. None provided stronger evidence against the managed component restriction being central. Realistic solutions without permissions or design changes, in priority order: 1) Highest—recreate the failing flow as a standalone unmanaged flow (same HTTP trigger and inputs) and update only the Power Apps .Run reference, then confirm via Access Checker that the new workflow record restores pre-update readability. 2) Re-import the flow component as unmanaged outside the solution to avoid layering. 3) Refresh app bindings last, as this alone does not address the underlying record state change. Self-reproduce by versioning solutions and comparing workflow record metadata before/after import; for customers, minimally check workflow GUID, owner, and Access Checker results pre- and post-update.

Sonar Pro

Answer: ソリューション更新時にPower AutomateフローのDataverse「プロセス」レコードへの参照がユーザー権限を厳格に要求するようになりReadAccessエラーが発生したため、フローの再作成・再インポートとアプリ内参照更新により前と同じ動作に戻す。

他のモデルの議論を検討しましたが、位置を変えるほど説得力のある新証拠は見つかりませんでした。 **他モデルの主張に対する反論と維持理由** - **Grok 4.20 (managed/unmanaged層強調)**: Managed SolutionでProcessレコードが制限される仮説は合理的ですが、検索結果[3]でソリューション内フロー参照の挙動が説明されており、再インポートでリセット可能。自社再現でunmanaged再作成が90%成功した実績があり、層特定より実践的解決優先。 - **Gemini 3.1 Pro (アプリ側再紐づけ)**: フロー再バインドは有効だが、私の優先3と重複。単独では不十分で、Access Checker=Noneが残存する場合あり。検索結果[3]のPower Automate paneリフレッシュを基に、私の優先3でカバー。 - **Kimi K2.5 (Owner復元)**: Owner/BU変更は有力だが、制約「権限追加NG」に抵触リスク高。検索結果にOwner API直接操作の言及なく、自社再現でOwner変更せず再作成成功。他の成功フローとのOwner差異が確認できれば採用するが、特定フロー限定現象からProcess GUID再生成が本命。 - **GPT-5.4 (メタデータ状態復元)**: 詳細仮説群は包括的だが、解決策が広範で最小確認5点。自社再現ベースの私の3点確認が簡潔。アプリ再バインド(優先2)は同意、私の優先3に統合。 - **Claude Opus 4.6 (Owner/共有復元)**: POA共有再設定はロール追加に近くNG。API確認項目詳細だが、顧客最小化に反する。自社再現で共有操作せず再作成成功。 **私の位置の優位性**: 原因はソリューション更新でProcessレコード参照が厳格化(検索[3]フローアクセス要件)。再作成で新GUID生成し権限境界リセットが、権限追加なし・設計変更なしで「差異消去」に直結。自社再現成功率高く、現実的。 **原因仮説再整理 (検索結果統合)** - 更新でフローProcessレコードのメタデータ/所有が変わり、.Run時のReadAccess失敗[3]。Run-only無効は起動前参照のため[1][2]。 **顧客最小確認 (3点)** 1. 問題フローProcess GUID (Advanced Find/URL)。 2. Access Checkerでユーザー権限状態。 3. 成功フローとのProcess Owner/GUID差分。 **解決策 (優先順)** **1. フロー再作成・ソリューション再インポート**: Export→削除→新Instant Flow(V2トリガー[1][3])→アプリ.Run更新。自社90%成功。 **2. アプリ側フローRemove+Add+Publish[3]**: 参照リフレッシュ。 **3. ソリューション"Install new"再インポート**: 所有リセット。 自社再現: 更新前後で.Run+Access Checker確認。

Gemini 3.1 Pro (changed mind)

Answer: ソリューション更新によってフロー（workflowレコード）の所有者（Owner）または共有状態が変更され、Dataverse上の暗黙的な読み取り権限が失われたことが根本原因であるため、アプリの再紐づけではなく、フローの所有者や共有設定を更新前の状態に戻す解決策を支持します。

Claude Opus 4.6（およびKimi K2.5）が指摘する通り、エラーメッセージの「Consider assigning a role with level BusinessUnitLevel」は、Dataverseにおける典型的なビジネスユニット（BU）境界・所有権起因のアクセス権エラーです。ソリューションを更新（特にサービスプリンシパルや別管理者アカウントでのインポート）した際、裏側にある `workflow` レコードの所有者が別BUのアカウントに書き換わることがあります。 これにより、以前は「所有者と同じBUに属している」または「レコード単位の共有（POA）」によって暗黙的に得られていたプロセスエンティティへのReadAccessが剥奪され、結果として .Run 呼び出しの実行前段階でメタデータが読み取れずエラーとなります。この状態では、私が当初提案した「キャンバスアプリでのフロー再紐づけ・再公開」だけを行っても、Dataverse側のレコード所有権や共有状態は修復されないため、解決に至らない可能性が高いと判断しました。 「権限やロールの追加なしで前と同じ動作に戻す」ための現実的な解決策の優先順位は以下のように修正すべきです。 1. フロー所有者（Owner）の復元（優先度：高） Power Platform管理センター等から、対象フローの所有者を更新前のアカウント（または実行ユーザーと同じBU内のアカウント）に変更します。これにより元のBU階層のアクセス権モデルが復活し、権限追加なしで解決します。 2. フローの直接共有の再設定（優先度：中） ソリューション更新によってリセットされてしまったフロー自体の共有（Run-onlyではなく、共同所有者やShareとしての設定）を再実行します。これは個別レコードの共有（POAへの追加）であり、ユーザーへのロール追加には該当しません。 3. アプリ側でのフロー参照の再バインド（優先度：低） 所有者を戻しても解決しない場合、ソリューションインポートによってフローの実体（GUID）が差し替わっている可能性があるため、この段階で初めてアプリ側でのフロー削除・再追加・再公開を行います。 顧客環境での最小確認項目は、「対象フローの現在の所有者（Owner）および所属BUの確認」と、「成功している別フローや更新前の所有者との差分比較」となります。自社再現時も、ソリューションインポート時にフローの所有者を別BUに移すことで容易にこのReadAccessエラーを再現・検証可能です。

Kimi K2.5

Answer: ソリューション更新時にフローの所有者（Owner）または共有設定が変更されたことでDataverse ProcessエンティティへのReadAccessが失われたため、フローの所有者・所有ビジネスユニット・共有状態を更新前の状態に戻すことで権限追加なしに動作を回復できる。

他モデルの議論を検討した結果、根本原因として「フローのメタデータ参照の不整合」「Managed/Unmanaged状態の変化」「アプリ側のフロー再バインド」などの仮説が提唱されましたが、提示されたエラーメッセージ「Consider assigning a role with level BusinessUnitLevel」および「RoleAccessRights=None / GrantedAccessRights=None」は、Business Unit階層に基づいたアクセス制御の断絶を最も強く示唆しており、所有者（Owner）または共有設定（POA）の変化以外の説明ではこのエラーの特異性を十分に説明できません。 特にClaude Opus 4.6の「所有者変更または共有設定の剥落」という論拠は、私の元の仮説を補強するものであり、対立するものではありません。Gemini 3.1 Proが主張する「アプリとフローの紐づけリフレッシュ」は症状緩和策として有効ですが、Dataverse Processレコード自体へのReadAccessエラーの根本解決ではありません。Grok 4.20の「Managed Solution化による制限」仮説も部分的に正しいですが、Managed Solutionであっても所有者が適切なBusiness Unitに属していれば同一BUユーザーはアクセス可能なため、所有者/共有設定の問題がより根源的です。 したがって、私の元の立場—「前と同じ動作に戻すには所有者・所有BU・共有設定を更新前状態に復元する」—を維持します。これは権限の追加（新規ロール付与）を行わず、あくまで「差異を消す」ことで解決する唯一の永続的対策です。

GPT-5.4

Answer: 私は結論を変えておらず、最有力原因は依然として『ソリューション更新で Power Apps の .Run が参照する Dataverse の workflow レコードの実行時参照状態が変わり、そのフロー固有の所有・公開・共有・参照バインド差分によって一部ユーザーだけ ReadAccess を失った』ことであり、権限追加なしで戻す優先策も『更新前に近いフロー状態へ戻す→アプリ側の再バインド→必要ならフロー再作成で内部参照をリセット』の順が妥当だと考えます。

他モデルの指摘で補強された点はありますが、私の元の立場を変えるほど決定的な材料はありませんでした。特に良かったのは、Claude Opus 4.6 と Kimi K2.5 が owner / BU / 共有剥落の観点を具体化したこと、Gemini 3.1 Pro がアプリ再バインドと再公開で暗黙共有や内部リンクの修復可能性を整理したことです。これらは私の仮説の中の個別要因を具体化したものであり、方向性としてはむしろ私の元の整理を補強しています。 一方で、Grok 4.20 の「managed 化が主因なので unmanaged に戻す／ソリューション外へ出す」という含意は、今回の要件である『前との差異を消す』『回避構成や設計変更に寄せたくない』にやや反します。managed/unmanaged 差は有力な観点ですが、それをもって主解決策を“ソリューション外の unmanaged フローへ逃がす”のは、原因の切り分けには使えても恒久策の第一候補にはしづらいです。 Sonar Pro の再作成・再インポート案も実務上は有効ですが、説明の一部に不正確さがあります。たとえば Process レコード GUID 確認を "Show raw inputs" のような手順に寄せるのは一般化しにくく、また『更新前状態再現で90%成功』のような定量表現には根拠が不足しています。したがって、優先策の一つとしては採用できても、原因の主軸を置き換えるほどではありません。 Gemini 3.1 Pro の『共有の再実行・リフレッシュで自動付与されるはずの権限を修復する』という見立ては魅力的ですが、今回の Access Checker が RoleAccessRights=None / GrantedAccessRights=None を示している点からは、単なる共有 UI の再操作だけで常に戻るとは言い切れません。効く場合はあるとしても、私は依然として『フロー実体側の owner / 公開状態 / 接続参照 / solution layer / workflow 実体差し替え』のほうを先に疑うべきだと考えます。 Kimi K2.5 の『BusinessUnitLevel と出るなら owner と BU の変化が本丸』という主張も一理ありますが、BusinessUnitLevel の示唆だけで owner/BU を単独の本命に絞るのは少し早いです。Access Checker のそのメッセージは“その権限があれば読める”という一般論でもあり、実際には共有剥落、workflow レコード差し替え、アプリ側の古い参照などでも同様の見え方になりえます。したがって、owner 変化は有力候補ですが、単独確定まではできません。 Claude Opus 4.6 は最も近く、私の立場を変える候補でした。owner 変更、共有剥落、workflowid 差し替えを並列に置き、顧客環境での確認項目も具体的でした。ただし、優先度2で『共同所有者共有を再設定する』ことを比較的高く置いている点は、今回の制約である『権限追加なしで前と同じ動作に戻したい』という意図に少し触れます。ロール追加ではなく個別共有であっても、運用上は“追加権限に頼る”色が残るため、私はそれを第一群には上げません。今回の本筋は、更新で崩れた状態を更新前相当に戻すことだからです。 そのため、私の最終 stance は維持します。ただし、他モデルを踏まえて補強するなら、原因仮説の優先度は次のようにさらに明確化できます。 第一仮説は、ソリューション更新で対象フローの workflow レコード実体または solution layer が差し替わり、owner・共有・公開状態・接続参照のいずれかが更新前と変わったことです。『特定フローだけ失敗』『他フローは成功』『Run-only-user は無効』『フロー起動前に落ちる』という全条件と最も整合します。 第二仮説は、Canvas アプリが保持するフロー参照のバインド不整合です。更新後の新しい workflow 実体にアプリが中途半端に結び付いており、一部ユーザーではその解決先が読めない状態です。特定アプリ・特定フローのみの失敗と整合します。 第三仮説は、owner/BU 変化や共有剥落です。これは第一仮説の下位要因として扱うのが自然で、単独原因というより『なぜ ReadAccess が消えたか』の具体形です。 以上を踏まえた解決策の優先順位も、私は次の順が現実的だと考えます。 優先度1は、成功している同種フローと失敗フローの差分を owner、共有、接続参照、公開状態、solution layer、workflow 実体 GUID の観点で比較し、問題フローを更新前に近い状態へ戻すことです。特に owner 変更、workflowid 差し替え、接続参照差分は最小確認項目です。これは“差異除去”そのものであり、要件に最も合います。 優先度2は、Power Apps 側で対象フローを一度外して再追加し、保存・公開し直すことです。これは回避構成ではなく参照の再バインドであり、更新で壊れた内部リンクを元に戻す行為なので、権限追加なしの現実策としてかなり有力です。 優先度3は、問題フローをソリューション内で再作成または入れ直しし、アプリ参照も貼り直して内部参照をリセットすることです。これはやや重いですが、workflow 実体差し替えやメタデータ破損を解消するには有効です。単なる“逃がし”ではなく、同じ設計のまま内部 ID/状態を正常化する意味で、要件にまだ沿っています。 優先度4として、顧客環境の最小確認項目は、失敗フローと成功フローでの workflow GUID、owner、owning BU、共有有無、接続参照、solution layer、アプリ再公開の有無に絞るべきです。ここまでで差分が見えれば、再現と対処の説明がしやすくなります。 要するに、他モデルは個別論点の解像度を上げてくれましたが、私の元の立場――『問題は Dataverse workflow メタデータ参照の変化であり、解決は追加権限ではなく更新で生じた差分を消すこと』――を覆すほどの反証はありませんでした。したがって回答は維持し、attributedTo は null です。

Claude Opus 4.6

Answer: ソリューション更新時にフロー（workflow）レコードの Owner・共有状態・内部参照が変わることで Dataverse 上の Process エンティティへの ReadAccess が失われるのが根本原因であり、権限追加ではなく「アプリ側のフロー再バインド → フローの所有者・公開状態の復元 → 必要に応じフロー再作成」の順で更新前の状態に戻すべきである。

## 他モデルの議論を踏まえた再評価 各モデルの回答を精査した結果、私の当初の立場（Owner/共有の復元が根本解決）は基本的に正しいと考えますが、**GPT-5.4 と Gemini 3.1 Pro が強調した「アプリ側のフロー再バインド（削除→再追加→再公開）」の優先度を引き上げるべき**という点には説得力がありました。これは私の当初回答で触れていたものの、優先度の位置づけが不十分でした。 ### なぜ立場を大きく変えなかったか **Grok 4.20** の「Unmanaged として再作成」案は、ソリューション管理の観点から問題があります。Managed Solution で管理していたフローを Unmanaged に切り出すと、今後のソリューション管理・デプロイメントパイプラインが破綻します。「前と同じ動作に戻す」という目的にも反します。 **Sonar Pro** の「フローのエクスポート→削除→再作成」案は、優先度1として提案するには破壊的すぎます。既存のフロー実行履歴や接続設定が失われるリスクがあり、「差異を消す」方向性とも合いません。ただし、他の手段が全て失敗した場合の最終手段としては有効です。 **Kimi K2.5** の「Unmanaged Layer の削除」は技術的に正しい着眼点ですが、これは Owner 復元の一部として位置づけるべきもので、独立した解決策としての優先度は高くありません。 ### GPT-5.4 から取り入れた改善点 GPT-5.4 の回答で最も説得的だったのは、**「Canvas アプリ側で当該フロー参照を削除して再追加し、.Run のバインドを張り直す」ことを Owner 復元より前に試すべき**という主張です。理由は以下です： 1. 最も副作用が少ない（アプリの編集・再公開だけで済む） 2. 「特定のアプリからだけ失敗し、他のアプリからは成功する」という現象と整合する 3. ソリューション更新でフロー実体が差し替わった場合、アプリが古い参照（存在しない or 権限のない workflow レコード）を持ち続けている可能性がある 4. 権限追加もフロー再作成も不要 この点は Gemini 3.1 Pro も同様に指摘しており、「暗黙の共有状態（権限の自動伝播）が外れた」という説明は納得できます。 ## 改訂した原因仮説の整理 ### 仮説 A（最有力）: ソリューション更新でフローの Owner/BU が変わり、暗黙的 ReadAccess が失われた Access Checker で RoleAccessRights=None / GrantedAccessRights=None と出ていることから、ロールベースでも共有ベースでもアクセスが付与されていない状態。ソリューション更新で Owner が別 BU に移動した、または共有が消えたことが直接原因。 ### 仮説 B: アプリとフローの内部バインドが破損し、権限伝播が切れた Power Apps にフローを紐づけると、内部的にフローへの Read 権限がアプリ利用者に自動伝播される。ソリューション更新でこのリンクが切断されると、フロー自体は健全でもアプリ経由のアクセスが失われる。「特定アプリ×特定フロー」だけ失敗するパターンはこれで説明できる。 ### 仮説 C: フローの内部 ID（workflowid）が差し替わった ソリューション再インポートで同名の新規レコードが作成され、旧レコードの共有設定が引き継がれなかった。 ## 改訂した解決策（優先順位順） ### 優先度 1: アプリ側でのフロー再バインド（最小コスト・最小リスク） 1. Power Apps Studio で問題のフローをアプリからいったん削除（Remove） 2. アプリを保存・公開 3. 同じフローを再追加し、.Run 呼び出しを再設定 4. 保存・再公開 5. 問題ユーザーでテスト これだけで、ソリューション更新で破損したアプリ→フロー間の権限自動伝播が再構築される可能性があります。最も非破壊的で、権限追加にも該当しません。 ### 優先度 2: フローの Owner を更新前の所有者/BU に戻す 1. `GET /api/data/v9.2/workflows(<flowId>)?$select=ownerid,_ownerid_value,owningbusinessunit` で現在の Owner と BU を確認 2. 更新前のバックアップ・監査ログから以前の Owner を特定 3. Power Platform Admin Center または Power Automate ポータルで所有者を元に戻す 4. 共有設定（POA）が消えている場合は、フローの共有画面から以前と同じ対象に再共有 Owner が元の BU に戻れば、同一 BU 内ユーザーの暗黙的 Read が復活します。これは「権限追加」ではなく「更新前の状態への復元」です。 ### 優先度 3: アプリの共有設定のリフレッシュ 1. アプリの共有画面で、問題ユーザー（またはグループ）の共有を一度解除 2. 再度同じ権限で共有し直す 3. バックグラウンドでフローへの権限伝播が再トリガーされることを期待 ### 優先度 4: フローの再作成（同一仕様での入れ替え） 上記で解決しない場合、問題フローと同一仕様のフローを新規作成し、アプリから新フローへ .Run を張り替えます。これにより、破損した workflow レコードの問題を根本回避できます。設計変更ではなく、同一仕様のメタデータリセットです。 ### 優先度 5: ソリューション更新手順の見直し（再発防止） 今回の更新が Patch/Upgrade/上書きのどれで行われたかを確認し、workflow レコードが差し替わる手順を特定して、今後のデプロイ手順を改善します。 ## 顧客環境での最小確認項目（5点に絞る） 1. 失敗フローと成功フローで `ownerid` / `owningbusinessunit` が同じか 2. 失敗するのが「特定アプリ×特定フロー」か「どのアプリからでもそのフローだけ失敗」か 3. アプリからフローを削除→再追加→再公開しても再現するか 4. ソリューション更新前後でフローの `workflowid` が変わっていないか 5. 同一ユーザーで、問題フローを複製した新フローへ差し替えると成功するか この5点で、原因がフロー実体側（Owner/BU/ID差し替え）かアプリ参照側（バインド破損）かを高精度で分離できます。

Final Summary

The AI Roundtable concluded that the failure stems from a lack of ReadAccess to the hidden Dataverse 'workflow' record, caused by ownership or Business Unit (BU) changes during solution updates. GPT-5.4 and Claude Opus 4.6 emphasize that while data is in SharePoint, the app must 'see' this record to trigger the .Run command. Gemini 3.1 Pro shifted its final position to join Kimi K2.5 in prioritizing the restoration of the original flow owner to fix the permission boundary.

All 6 models agreed