Power Automateのsolutionを移行して接続エラーになる場合、connection referenceと実際のconnectionを分けて確認します。referenceが存在するだけでは、移行先の正しいidentityで正しいresourceへ接続できる証拠にはなりません。environment、connector、割当先connection、flowを有効にする人を対応表にします。
本稿はsolution-aware cloud flowの移行後診断です。solution import、connection作成・再認証、権限変更、flow有効化・実行は実施していません。対応表は架空の設計例で、特定環境での移行成功や接続確認を主張するものではありません。
目次
connector・connection・referenceを区別する
Microsoftのconnection reference資料（新しいタブで開く）は、connectionをconnectorの認証接続、referenceを特定connectorのconnectionを参照するsolution componentとして説明しています。solution内のflowはreferenceを介してconnectionへ結び付きます。
表は横にスクロールできます
| 要素 | 意味 | 別に確認すること |
|---|---|---|
| connector | 利用するAPIの入口 | 対象actionと対応機能 |
| connection | 認証済みの接続 | identity・有効性・利用権限 |
| connection reference | solutionからconnectionへの参照 | 移行先で何へ割り当てたか |
| 対象resource | site/list/mailbox等 | 接続identityの必要権限 |
| 環境変数等 | URLやIDなどの環境差 | 開発先が残っていないか |
ownerを変更しただけでconnectionも新ownerへ置き換わるとは限りません。表示名が同じconnectionでも、認証accountや接続先が違う場合があるため、名前だけで選ばないようにします。
移行元と移行先の対応表を作る
対象solutionとバージョン、flow、referenceの識別子、connectorを確認します。移行先environmentを画面で確定し、各referenceに必要なconnectionを並べます。開発用のsiteやmailboxへつながる設定を、本番用と取り違えないようにします。
表は横にスクロールできます
| 参照の架空例 | 必要な移行先条件 | 接続だけでは確認できないこと |
|---|---|---|
| 社内listの読取 | 承認済みidentityのSharePoint接続 | 正しいsite/listの読取 |
| 通知mailbox | 用途に合うOutlook接続 | 差出人・共有mailbox条件 |
| 業務DB更新 | 対象環境のDB接続 | tableと更新範囲 |
| custom connector | 移行先のconnector定義 | 環境固有IDと依存順序 |
secretやpasswordは表へ入れません。connectionの管理者、想定identity、必要resource、確認状態を記録し、未割当と認証失効、対象権限不足を別の状態にします。
未割当・invalid・有効化権限を分ける
Power Automate error reference（新しいタブで開く）は、ConnectionNotConfiguredやInvalidConnectionなどを区別しています。messageと、どのactionがどのreferenceを使うかを見ます。存在しないconnectionへの参照と、存在するが認証が壊れたconnectionを同じ再割当で直そうとしないようにします。
移行先のSolutionsから対象componentを開き、referenceに実際のconnectionが設定されているか確認します。権限者が割当を変える場合は、対象referenceと利用flow一覧、元のconnection、変更後identityを記録します。共通referenceなら複数flowへ影響するため、一つのerrorを直すつもりで他flowの接続主体まで変えないことが重要です。
referenceの更新は非同期に保存されると公式資料は案内しています。画面を保存した直後の表示だけで完了せず、更新の詳細や現在の割当を読み戻します。処理中に連続して別のconnectionへ替え、どの値が採用されたか不明にしないようにします。
flowを有効にする人のconnection利用条件を確認する
公式reference資料は、flowを有効にする人が、そのflowで使うconnectionを所有するか利用権限を持つ必要があると説明しています。solutionの編集権限と、connectionを使って有効化できる条件は別です。
別の人のconnectionを使う場合、connectorの共有可否と公式の条件を確認します。OAuth connectionを誰にでも共有できると決めつけず、connectionの所有者が有効化する方法など、利用中の認証方式に合う経路を選びます。エラーを消すため全員をownerやadminへ追加する処置にはしません。
有効化できても、resourceに対する読取・更新権限が足りなければ、実行時には別の失敗になります。「有効化」「認証」「resource操作」の終点を別々に確認します。
custom connectorとsolution外flowは追加条件を確認する
custom connectorはenvironment固有の識別子を持つため、環境copy後にreferenceを直す必要がある場合があります。公式資料には、custom connectorをreferenceやflowより先に別solutionでimportする依存順序も案内されています。標準connectorの割当と同じ前提にせず、対象の依存関係を確認します。
solution外で作ったflowを後からsolutionへ追加した場合も、自動的にすべてがconnection referenceへ移るとは限りません。現行のflow checkerや定義で、実connectionを直接使っている部分とreferenceを使う部分を確認します。接続をremoveして付け直す変更は、影響と復旧手順を決めてから権限者が行います。
小さな検証で、移行先へ反映した結果を確認する
許可された検証環境で、割当の読取、flow有効化、最小限のaction、必要なtriggerの順に確認します。書込や送信を伴う場合は、検証用resourceと一意な処理IDを用意し、移行元と移行先の両方で同じ入力が二重に動かないようにします。本稿でその検証を実行したという意味ではありません。
表は横にスクロールできます
| 確認段階 | 成功の根拠 | 残る確認 |
|---|---|---|
| reference割当 | 読み戻したconnectionが想定どおり | connectionの認証状態 |
| flow有効化 | 対象flowが有効になる | trigger・actionの実処理 |
| action実行 | 正しいresource・identity・結果 | 全routeと副作用 |
| 切替 | 旧経路と重複しない | 未処理入力と旧run |
失敗したら、今回の割当差分と現在の外部状態を確認します。単に旧connectionへ戻せば、すでに行った更新まで戻るとは限りません。変更前後のreference、依存flow、対象resource、検証結果、未確認の認証・policy条件を残し、どこまで移行できたか説明できる状態で運用へ渡します。