キャンバスアプリ／クラウドフローが本番運用環境に反映されないときの確認ポイント

こんにちは。システムソリューション営業本部の吾妻です。


以前、ALMの観点から、Power Platform環境を使い分ける管理手法についてご紹介しました。

【Dataverseガバナンス】 Power Platform環境の管理 | QES ブログ
株式会社QUICK E-Solutionsから、皆さまへお役立ち情報を発信するブログです。ぜひご覧ください。
 

この管理手法を用いて、開発・検証・運用の3環境でソリューションパッケージを順番に展開（デプロイ）していく際に、「キャンバスアプリやクラウドフローを修正してソリューションを入れ直したのに、運用環境に反映されない」というトラブルがまれに発生します。

そこで今回は、なぜこのような事象が発生するのか、どのようにトラブルシューティングすればいいのか、について解説したいと思います。

ALMのおさらい

ALMとは、Application Lifecycle Management（アプリケーション ライフサイクル 管理）の略で、システムの開発から運用・保守・廃止までの一連のプロセスを体系的に管理する手法です。




Power Platformでは、ALMを実現するために、「コンポーネントをまとめて管理する機能」「環境を分離する機能」「パイプラインでデプロイを自動化する機能」が用意されています。

コンポーネントをまとめて管理する機能

「コンポーネントをまとめて管理する機能」は、Power Platformではソリューションが担っています。「ソリューション」という箱の中に、キャンバスアプリやモデル駆動型アプリ、クラウドフロー、テーブル、サイトマップ、プロセス、Webリソースなどの「ソリューションコンポーネント（オブジェクトと呼ぶこともあります）」という中身を入れていくイメージです。

ソリューションには、エクスポートする際のオプションとして、「アンマネージドソリューション」と「マネージドソリューション（管理ソリューション）」の2つがあり、以下のように使い分けます。

1つの環境の中に、複数のマネージドソリューションをインポートすることもでき、その場合は、次の図のような階層構造をとります。



レイヤーの最下層には、コンポーネントのメタ情報を管理している基本（Base）ソリューションがあります（厳密には、各マネージドソリューションの最下層）。その上に、マネージドソリューションが古い方から新しいへと重ねられていき、一番上はアンマネージドレイヤー（環境内で直接手動で行われた変更）となっています。

環境を分離する機能

「環境を分離する機能」であるPower Platform環境を利用することによって、1つのシステムに対して、開発環境・検証環境・運用環境の3つの環境を用意して、アプリやフローを順番に展開していくことで、システムの信頼性を高め、デグレや不具合の発生を防ぐことができます。

また、個々の環境の使い分け方として、開発環境では、アンマネージドソリューションとして内容を変更できる状態とし、検証環境・運用環境では、マネージドソリューションとして環境にインポートして、パッケージ（を展開したソリューション）の中にあるコンポーネントを編集できない状態とすることを推奨しています。

さらに、特に運用環境では、キャンバスアプリの所有者や、自動化フロー（タイマートリガーをもつフローなど）の実行ユーザーとして、ライセンス（Power Platform 要求の制限など）やアクセス制御（Dataverseレコードの所有者）の観点から、専用のシステムアカウントを払い出して、割り当てることが多いと思います。

前提知識をおさらいしたところで、「ソリューションパッケージを入れ直したのに、運用環境に反映されない」ときのトラブルシューティング方法について解説します。

原因：「アンマネージドレイヤー」

「ソリューションパッケージを入れ直したのに、運用環境に反映されない」トラブルは、多くの場合「アンマネージドレイヤーが作成されている」ことが原因です。

なぜアンマネージドレイヤーが作成されるのか？

マネージドソリューションは、原則としてインポート後に中身を直接編集できません。 しかし、ソリューションを環境にインポートする際には、接続参照や環境変数といった、その環境固有の情報を設定する必要があります。ソリューションをインポートする際のウィザードの中で、つながり参照や環境変数を編集する場合には、Power Platformの標準機能としてALMに対応しているので問題ありませんが、インポートが完了したあとで、改めてこの環境に合わせた設定操作を行ってしまうと、意図せずアンマネージドレイヤーを生成する引き金となることがあります。特に問題となりやすいのが、接続参照です。

例えば、開発環境と運用環境では、セキュリティの観点からフローの実行ユーザーを別にすることが推奨されるのですが、一旦担当者が運用環境へソリューションをインポートを完了させたあとで、接続情報を運用環境用のものに再設定するような場合があります。Power Platform環境を管理している人と、アプリを管理する人が分かれている場合によくあるパターンです。この、インポートとは無関係に接続情報を再設定する操作が「環境に対する直接の変更」とみなされ、そのコンポーネント（フローなど）の上にアンマネージドレイヤーが作られてしまいます。

これに対し、意図的に、開発環境から運用環境までの設計・実装の一環として明確な目的をもってアンマネージドレイヤーを作成することもあります。意図したものか、意図しないものかの判断にあたっては、変更操作が「ソリューションインポート後にソリューションコンポーネントを直接編集したものかどうか」が基準となります。運用環境では、可能な限りマネージドソリューションの範囲内で設定を完了させ、直接編集を避けることが推奨されます。Power Platform管理センターで「アンマネージドカスタマイズをブロックする」設定を有効化することで、開発者にALMに基づいてアンマネージドレイヤーを作らせないように強制させるのも1つの方法です。

他にも、ソリューションパッケージのインポートが何らかの理由で正常に完了しなかった場合に、アンマネージドレイヤーが作成されてしまう場合があります。ソリューションごと削除して、インポートしなおすことで、解消することが多いです。

アンマネージドレイヤーのもたらす影響

アンマネージドレイヤーは、ソリューションの階層構造において常に最上位に位置します。

一度このレイヤーが作成されると、それ以降に新しいバージョンのマネージドソリューションをインポート（更新）しても、その変更内容が最上位のアンマネージドレイヤーによって覆い隠されてしまいます。 結果として、開発者から見ると「最新のソリューションを入れたはずなのに、古い状態のまま変わらない」という現象が発生するのです。

ソリューションが更新されないときの確認ポイント

ソリューションパッケージをインポートしても運用環境に変更内容が反映されない場合は、トラブルシューティングとして以下の5点を確認してみてください。

①アンマネージドレイヤーの確認

前段で解説した「アンマネージドレイヤー」が生成されていないか確認し、削除しても問題ないことを確認できたら、削除します。

意図せず作成されたアンマネージドレイヤーについては、原則（自己責任で）削除して問題ないかと思います。また、環境内で直接コンポーネントを編集したことによって「意図的に作成したアンマネージドレイヤー」についても、一旦（自己責任で）削除します。ソリューションを上書き更新するためのインポート作業が完了したあとで、再度コンポーネント編集を実施して、アンマネージドレイヤーを作り直すことになります。

• 確認方法:

  1. 対象の環境で「ソリューション」を開きます

  2. 最新の状態になっていないコンポーネント（キャンバスアプリやクラウドフローなど）を選択します

  3. コマンドバーにある「ソリューションレイヤーの表示」を選択します

  4. ソリューション列が「Active」となっているレイヤー（アンマネージドレイヤー）が存在するか確認します

• 対処法:

  • アンマネージドレイヤーが存在する場合、それを選択して「アクティブなカスタマイズを削除する」または「アンマネージドレイヤーの削除」を実行します（Power Appsのバージョンによってラベルは異なりますが、同じ操作です）

②インポート履歴の確認

ソリューションのインポートが成功したように見えても、実際には警告が出ていたり、一部が失敗していたりして、完全には完了していない場合があります。特に、不完全にインポート処理が行われたために、アンマネージドレイヤーが生成されている場合には、①と同様に削除する必要があります。

• 確認方法:

  1. 対象の環境で「ソリューション」を開きます

  2. 左側のナビゲーションから「履歴」を選択します

  3. 該当するソリューションのインポート履歴を確認し、「状態」が「成功」となっているか確認します

• 対処法:

  • エラーメッセージが表示されている場合は、その内容に従って移行元のソリューションを修正し、再度エクスポート・インポートします。

③パッケージバージョンの確認

ソリューションパッケージのバージョン番号はZipファイルの名前に含まれていますが、そのパッケージに具体的にどのバージョンのコンポーネントが含まれているかは、ファイル名だけでは判断できません。そのため、誤って古いバージョン（ファイル名ではなく、中に含まれているコンポーネントの「バージョン」を意味します）のソリューションパッケージをインポートしてしまう可能性があります。

バージョンが古い場合は、開発環境 / 検証環境から最新のソリューションをエクスポートし直して、再度運用環境にインポートします。

④コンポーネントの状態確認

ソリューションの更新は成功していても、クラウドフローや接続参照などのコンポーネントが、「オフ」の状態になっていることがあります。マネージドソリューションの場合はそこまで多くありませんが、ユーザーに割り当てられているライセンスの状況や、接続設定の変更などをきっかけに自動的にオフに変更されている場合があります。

• 確認方法:

  1. ソリューション内から、更新が反映されないクラウドフローやキャンバスアプリを開きます

  2. クラウドフローの状態が「オン」になっているか確認します

• 対処法:

  • オフになっている場合は、「オン」に切り替えます

⑤ブラウザのキャッシュクリア

特にキャンバスアプリの変更が反映されない場合、ブラウザに古いバージョンの情報がキャッシュとして残っている可能性があります。

キャッシュファイルを無視して強制的に再読み込みするために、スーパーリロード（ショートカットキー：Ctrl + Shift + R）を試すか、ブラウザのメニューから、履歴・Cookie・キャッシュを消去します。

まとめ

本記事では、Power PlatformでALMを実践する際にまれに発生する、「ソリューションパッケージを入れ直したのに、運用環境に反映されない」というトラブルの原因と対処法を解説しました。


QES技術ブログでは、参考事例やサンプルもご紹介していますので、以下のリンクからご覧ください。

QESでは Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある／利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。

Power Platform（ローコード開発） ｜ QES
ローコード開発ツール「Microsoft Power Platform」で現場からアプリ開発・DXを推進！QESはマイクロソフト認定パートナー、「パートナー・オブ・ザ・イヤー」受賞パートナーとしてお客様の Power Platform 活用を包括的に支援しています。
 

---

このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。