Power Platform 受託開発：managed/unmanaged 納品設計で正本を顧客に渡しきる

managed だけで納品を終わらせると、顧客環境にはソースを復元できない状態が残る。
正本は受託者側にあり続け、案件が完了しても保守依頼が続くか、受託者が環境を消せば顧客が困るかの二択になる。
unmanaged を顧客の DEV 環境に渡す設計に変えると、正本は顧客側へ移り、受託者は案件を何も抱えずに終わらせられる。

managed だけで納品すると何が起きるか

managed ソリューション（管理済みソリューション）は、Power Platform 上でアプリやフローをパッケージ化して配布する形式だ。顧客環境にインストールできるが、インストールされた状態からソースを取り出すことはできない。

Microsoft Learn の公式ドキュメントには明示されている。

“You can’t export a managed solution.”
— Export solutions | Microsoft Learn

顧客が managed を受け取っても、そこからソースを復元する手段はない。受託者のテナントにある unmanaged（非管理済み）ソリューションが唯一の正本として残り続ける。
これは「managed-only で納品する」という選択が、意図するかどうかに関わらず生み出す構造だ。

正本が受託者側に残り続けると起きること

正本が手元にある状態では、案件が終わっても受託者はそのソリューションを保持し続けることになる。顧客が機能追加や障害対応を必要とするたびに、受託者に連絡が来る。消したければ顧客が困る。持ち続ければ自分が抱える。

この構造を事後に解消するには、unmanaged から managed の ALM（Application Lifecycle Management：アプリのライフサイクル管理）への正規化作業が必要になる。Microsoft が FastTrack 専門チームの解説ビデオを用意するほどの移行コストが存在しており、後から解決できるとは言いにくい。

参考：Move from unmanaged to managed ALM | Microsoft Learn

正本の移転は後回しにするほど重くなる。

unmanaged 納品フロー：どこに入れるか

解決策は一つだ。unmanaged ソリューションを顧客の DEV（開発）環境に渡す。

フローはこうなる。

受託者 DEV → unmanaged エクスポート
               ↓
顧客 DEV   → unmanaged インポート（ここで正本が顧客側へ移る）
               ↓
           顧客が単体テスト
               ↓
           顧客 DEV から managed エクスポート
               ↓
           ステージング → UAT → 本番（本番には managed のみ）

「unmanaged を顧客に渡す」と「unmanaged を本番に入れる」は別の判断だ。顧客 DEV に unmanaged が入ることで正本が移転し、その後のステージング以降は managed だけが動く。

なお、このフローが機能する前提として、ソリューションは最初から顧客の publisher（発行者）で作る必要がある。

“Carefully select the publisher”
— Move from unmanaged to managed ALM | Microsoft Learn

本番に unmanaged を入れてはいけない 3 つの理由

unmanaged を渡すことと、本番に unmanaged を置くことは根本的に違う。本番に unmanaged を置いてはいけない理由は 3 つある。

1. すべてが非管理レイヤーに落ちる
managed と unmanaged が混在する本番環境では、変更管理の境界が曖昧になる。どの設定が管理対象でどれが野良の変更なのか、追跡できなくなる。

2. managed 運用への切り替えが重くなる
一度 unmanaged で運用を始めた環境を ALM 正規化するコストは高い。前述の FastTrack 専用資料が存在すること自体が、この移行の重さを示している。

3. ソリューションを削除してもコンポーネントは残る
Microsoft Learn にはこう書かれている。

“When an unmanaged solution is deleted, only the solution container of any customizations included in it’s deleted. All the unmanaged customizations remain in effect and belong to the default solution.”
— Solution concepts in ALM | Microsoft Learn

unmanaged ソリューションを削除しても、中のコンポーネントはデフォルトソリューション配下に残り続ける。「削除したからクリーン」にはならない。

納品前に確定する 4 つ

unmanaged を顧客 DEV に渡す設計で開発を始める前に、次の 4 つを先に固める。

publisher とカスタマイズ接頭辞の不変性についてはドキュメントに明示されている。

“Once you introduce a publisher for a component in a managed solution, you can’t change the publisher for the component.” / “you can’t change the names of metadata items after they’re created.”
— Use solutions for your customizations | Microsoft Learn

「とりあえず自分のテナントのデフォルト publisher で開発してから移行する」という判断は、後から取り消せない。この 4 つは合意を後回しにするほど修正コストが上がる。

なお、この設計の前提として顧客テナントに DEV・ステージング・本番の 3 環境が用意されている必要がある。着手時点で環境が 1 つか 2 つしかない案件では、まず環境構成の合意を先に済ませることが条件になる。

個人テナントで設計を試す

受託案件ごとにこの ALM フローをゼロから組むのは非効率だ。M365 Developer Program（月額無料）を使った個人テナントで、DEV / ステージング / 本番の 3 環境構成と publisher 設計のテンプレートを一度作っておくと、次の案件から使い回せる。

→ 関連記事：顧客環境に拘束された時間は、あなたの資産にならない

まとめ

managed だけで納品すると正本が受託者側に固定される。unmanaged を顧客 DEV に渡す設計に変えると、正本は顧客側へ移り、受託者は案件を何も抱えずに終わらせられる。本番には managed のみを入れる原則と、着手前の 4 項目確定がこの設計の両輪だ。

次の一歩：次の案件着手前に、顧客テナントの publisher 名とカスタマイズ接頭辞を確認する。publisher を顧客のものとして最初から作り直す前提で開発環境を構成する。環境変数と接続参照の環境別値を表に起こしておく。