変更要約: PL-400 第1章を新規作成（ドメイン: 技術設計 + ソリューション構築/ALM）。技術アーキテクチャの設計（ビジネスロジック配置先 business rule/plug-in/Power Automate/client scripting・テーブル種別 standard/virtual/elastic・DLP/セキュリティロール/チーム/業務単位/行共有）、ソリューションコンポーネントの設計（canvas component/PCF コードコンポーネント・カスタムコネクタ・Power Fx/plug-in/custom API・統合）、ALM（managed/unmanaged・ソリューション層・環境変数・Pipelines・Build Tools CI/CD）。
1.3アプリケーションライフサイクル管理（ALM）
managed/unmanaged ソリューション、ソリューション依存関係と層、環境変数、Power Platform Pipelines、Build Tools による CI/CD を理解します。
ソリューションは Power Platform の 配布と変更管理 の単位です。健全な ALM が品質と再現性を支えます。
1.3.1managed と unmanaged ソリューション
unmanaged ソリューション は 開発環境での編集可能 な作業用で、コンポーネントを自由に変更できます。managed ソリューション は テスト/本番へ配布する読み取り専用（ロック） の成果物で、直接編集しません。開発は unmanaged、配布は managed、が基本です。複数ソリューションが同じコンポーネントを変更すると ソリューション層（solution layers） が積み重なり、最上位の層が有効になります。
1.3.2環境変数と依存関係
環境変数（environment variables） は環境ごとに変わる値（URL/キー/構成）を ソリューションに含めつつ環境ごとに設定 でき、ハードコードを避けて移送性を高めます。ソリューション依存関係 を管理し、依存先を含めて正しい順序で移送します。
1.3.3Pipelines と CI/CD
Power Platform Pipelines は Power Platform 内で開発→テスト→本番へソリューションを 自動移送 する仕組みで、ローコードに統合されています。より高度な自動化は Power Platform Build Tools（Azure DevOps/GitHub Actions）で CI/CD パイプライン を組み、エクスポート/インポート/テストを自動化します。
決め手：「開発環境で編集する作業用」＝unmanaged。「本番へ配布する読み取り専用」＝managed。「環境ごとに変わる値をソリューションに含める」＝環境変数。「Power Platform内で自動移送」＝Pipelines。「Azure DevOps/GitHubでCI/CD」＝Build Tools。「同一コンポーネントの上書き優先」＝ソリューション層。
混同に注意：
①managed(配布/ロック)とunmanaged(開発/編集可)を取り違えない。
②本番でunmanagedを直接編集しない。
③環境変数とソリューション層は別概念(値の外部化 vs 上書き優先)。
④Pipelines(プラットフォーム内)とBuild Tools(Azure DevOps/GitHub)を区別。
1.3.4この節のまとめ
- unmanaged=開発編集可/managed=配布ロック・本番はmanaged
- 環境変数で値を外部化・ソリューション層は上書き優先・依存順に移送
- Pipelines=プラットフォーム内自動移送/Build Tools=Azure DevOps-GitHubのCI/CD
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. テスト/本番環境へ配布する、直接編集できない読み取り専用のソリューションはどれですか？
Q2. 開発環境でコンポーネントを自由に編集しながら開発するためのソリューションはどれですか？
Q3. 環境ごとに変わる API の URL を、ソリューションに含めつつ環境ごとに設定してハードコードを避けたい。最適なのはどれですか？
Q4. Power Platform 内で開発→テスト→本番へソリューションを自動的に移送したい。最適なのはどれですか？
Q5. Azure DevOps や GitHub Actions でエクスポート/インポート/テストを自動化する CI/CD を構築したい。最適なのはどれですか？