Microsoft Dynamics 365において、カスタマイズ管理の基本となる概念として「Unmanaged Solution」と「Managed Solution」があります。
しかし、これらの背後でシステムがどのように変更を管理・適用しているのかを深く理解するためには、「Solution Layer（ソリューション層）」という仕組みを正しく把握することが非常に重要です。
特に複数のベンダーが関与する環境では、このLayerの理解が、衝突の回避やアップグレード管理、トラブル対応の鍵を握ります。
Solution Layerとは何か？
Dynamics 365では、各種コンポーネント（エンティティ、フィールド、フォーム、ビュー、ビジネスルールなど）に対する変更が、「レイヤー（層）」という形で積み重なって記録されます。
この仕組みは「Solution Layer Stack」とも呼ばれ、最終的にどのカスタマイズが有効になるかは、このレイヤーの順序によって決定されます。
ポイント：
- 各Solutionが1つのレイヤーを構成します。
- 最後に読み込まれた（上位の）レイヤーが優先されて動作に影響を与えます。
- 層構造を可視化することで、どの変更が影響しているかを明確に把握できます。
UnmanagedとManagedの違いとLayerの影響
| 種類 | 特徴 | Layerへの影響 |
|---|---|---|
| Unmanaged Solution | 開発用。直接システムに変更を加える。 | 個別のLayerは生成されず、ベースに統合される。 |
| Managed Solution | 本番環境用。インストール・アップグレード・削除が可能。 | ソリューションごとに明確なレイヤーが追加される。 |
特にManaged Solutionを使うことで、変更の出所や影響範囲を正確に追跡できるようになります。
なぜSolution Layerが重要か？
複数のベンダーが同一環境にカスタマイズを導入する場合、以下のような課題が発生します：
- 変更の衝突
- 上書きによる不具合
- ベンダー別の影響範囲の特定
こうした状況において、Solution Layerを活用することで：
- どのベンダーの変更が有効になっているかを特定できる
- 意図しない上書きを回避できる
- 問題発生時に迅速に影響ソリューションを特定・ロールバック可能
といった管理上のメリットが得られます。
マルチソリューション環境での管理のベストプラクティス
1. ベンダー単位でManaged Solutionを分割
各ベンダーが独立したソリューションを提供するように設計し、命名ルールも統一（例：VendorA_Sales_1_0_0_0）。これにより変更履歴や影響範囲が明確になります。
2. 本番環境ではUnmanaged Solutionを使用しない
Unmanagedは変更がシステムに直接書き込まれるため、追跡が困難です。本番環境では必ずManaged Solutionを使用しましょう。
3. Solution Layerの可視化を活用
Power Apps 管理ポータルでは、各コンポーネントの「レイヤー構造」を確認できます。予期しない上書きや競合の原因特定に役立ちます。
4. PatchとUpgradeの使い分け
- 小さな変更 → Patch
- 大きな機能追加や改善 → Upgrade
これにより、レイヤーが無駄に肥大化するのを防げます。
実例：Solution Layer Stackの構成
例：1つのフォーム項目に対して以下のようなレイヤーが存在するケース
- Base System Layer（Microsoft初期定義）
- Vendor A Managed Solution（Sales系の拡張）
- Vendor B Managed Solution（ポータル用カスタマイズ）
- Internal ITによる追加カスタマイズ
このように、最新の変更が上位に積み重なるため、「どの変更が最終的に有効か」がすぐに確認できます。
まとめ
Dynamics 365において、Solution Layerの仕組みを理解することは、システム管理・トラブルシュート・アップグレード計画のすべてに直結します。
特にマルチソリューション環境においては、レイヤーを正しく活用することで：
- 各社の変更を安全に共存させる
- 意図しない影響を防ぐ
- 柔軟かつトレーサブルな開発体制を維持する
といった多くの利点があります。
コメント