managed ソリューションで納品した後、特定のコンポーネントだけ更新が当たらない——この状況で最初に疑うべきはコードではなくソリューションレイヤーだ。
新版をインポートしても変わらない。「カスタマイズを上書き」オプションを選んでも変わらない。その原因の多くは非管理レイヤー（unmanaged layer）が managed レイヤーの上に乗っていることにある。メンテの第一手はレイヤーを確認することから始まる。
更新が反映されない理由：非管理レイヤーが上に乗っているから
Power Platform のソリューションには「レイヤー」という構造がある。managed（管理済み）と unmanaged（非管理）の変更が重なるとき、どちらが実行時の動作を決めるかを示す順番だ。managed solution とは編集できない状態でパッケージ化されたソリューションで、本番配布を前提に作られる。
顧客が本番の Maker ポータルでコンポーネントを直接編集すると、その変更は非管理レイヤーとして managed レイヤーの上に積み重なる。
Microsoft のドキュメント（「Solution layers in Power Platform」2024年）はこう明示している：
“Unmanaged customizations reside at the top layer for a component and subsequently define the runtime behavior of the component.”
非管理レイヤーは常にトップ——つまり、常に優先される。新しい managed ソリューションを何度インポートしても、非管理レイヤーが存在するコンポーネントにはその更新が届かない。
なお、model-driven app・フォーム・サイトマップはこの原則の例外で「マージ」動作（双方の変更を統合する）になる。それ以外のコンポーネントは「上のレイヤーが全体を決める」ため、非管理レイヤーが存在する限り managed 側の変更は実行時の動作に影響しない。
どこで確認するか：ソリューションレイヤービューを開く
確認は Maker ポータルから直接できる。
- 対象ソリューションを開く
- 更新が当たっていないコンポーネントのオプションメニューを開く
- 「ソリューションレイヤーを表示」を選択
ここで非管理レイヤーがリストの上部に表示されていれば、それが原因だ。
XrmToolBox のような補助ツールでレイヤーを探索することもできる可能性があるが、ツールによって検出できないコンポーネント種別がある場合もある。Maker 画面での直接確認が最も確実な手段だ。
見つかったら何をするか：削除は不可逆、顧客 GO が必須
非管理レイヤーが確認できたら、次の順で対処する。
ステップ 1：顧客の変更を自分の正本（管理ソリューション）に取り込む
非管理レイヤーを削除すると、そこに加えられた変更は消える。削除前に、顧客が加えた変更が正式な仕様として必要かどうかを確認し、必要であれば自分の管理ソリューションに反映しておく。これは公式手順には明示されていない工程だが、後から「消えた」とならないための前処理として位置づける。
ステップ 2：顧客に Remove active customizations（アクティブなカスタマイズを削除）を依頼する
この操作は顧客側の作業として依頼する。実施前に必ず GO を取ること。公式ドキュメント（「Solution layers in Power Platform」2024年）はこう述べている：
“Removing active unmanaged customizations can’t be reversed or undone. All data associated with the unmanaged customization can be lost.”
取り消せない、関連データが消える可能性がある。この 2 点を顧客に伝えた上で承認を得てから進める。
操作は Maker ポータルで行う：対象コンポーネントのソリューションレイヤー画面から非管理レイヤーを選択し、コマンドバーの「アクティブなカスタマイズを削除」を実行する。
補足として、非管理レイヤーがそのコンポーネントの唯一のレイヤー（基底レイヤー）の場合、Remove active customizations では削除できない。その場合はコンポーネントそのものを削除する必要がある。
ステップ 3：新版の managed ソリューションをインポートする
非管理レイヤーが除去された後に新版をインポートすると、managed 側の更新が正常に反映される。
「カスタマイズを上書き」が効かない理由
import 時に「カスタマイズを上書き（Overwrite Customizations）」を選んでも、非管理レイヤーの問題は解決しない。
このオプションが効くのは managed レイヤー同士の衝突——別の managed ソリューションが上位レイヤーとして競合している場合（後述のケース 3）だ。非管理レイヤーを除去するには「Remove active customizations」の実行が必要であり、import オプションでは代替できない。
公式トラブルシュートドキュメント（「Changes aren’t effective after solution import」2024年）もケース 1 として非管理レイヤーをトップに挙げており、解決手段として Overwrite Customizations は推奨されていない。
Update・Upgrade・Stage for Upgrade の使い分け（補足）
非管理レイヤーを除去した後、新版をどの方式でインポートするかも判断が必要だ。
| 方式 | コンポーネント削除 | 特徴 |
|---|---|---|
| Update | 不可 | 追加・変更のみ。新版で削除したコンポーネントは旧版が残る |
| Upgrade | 実行する | 新版にないコンポーネントを削除。クリーンな更新 |
| Stage for Upgrade | 後工程に分離 | 旧版と新版を一時共存させ、Apply Upgrade 実行時に削除を完了 |
詳細は Microsoft Learn「Upgrade or update a solution」（2024年）を参照。
納品時に書く一行
「非管理レイヤーは常に優先する」という構造上、本番環境で直接編集が行われた時点で後工程のリスクが生まれる。この原則を踏まえると、納品ドキュメントに一文入れておくだけで後工程の工数を大幅に減らせる。
「本番で直接編集しないでください。編集すると以後の更新がその箇所に適用されなくなります。」
縛りではなく説明だ。なぜ直接編集を避けるべきかを顧客が理解しているかどうかで、次回以降の保守難易度が変わる。
参考：公式トラブルシュートが示す 3 つのケース
公式ドキュメント「Changes aren’t effective after solution import」（2024年）は更新が当たらない原因を 3 つに整理している。
- ケース 1：非管理レイヤーがトップにある（本記事の主題）→ Remove active customizations
- ケース 2：インポート後に「すべてのカスタマイズを公開」を実行していない（publish 忘れ）
- ケース 3：別の managed ソリューションのレイヤーがトップにある → そのソース環境で変更し新版を再インポート
本記事はケース 1 を扱う。症状が同じでもケース 2・3 の可能性もあるため、レイヤービューで原因を確認してから対処に進むのが確実だ。
まとめ
managed ソリューションの更新が反映されないとき、最初に確認すべきはソリューションレイヤービューだ。非管理レイヤーがトップにある場合、コードを見ても問題は解決しない。レイヤーを見ることがメンテナンスの起点になる。
次の一歩：本番環境の更新が詰まったら、Maker ポータルのソリューションレイヤービューを開いて非管理レイヤーの有無を確認する。Remove active customizations は不可逆なため、実施前に変更内容の把握と顧客 GO を必ず取ること。