変更要約: PL-400 第2章を新規作成（ドメイン: Power Apps の改善 + UX 拡張）。高度な canvas アプリ（複雑な Power Fx・コンポーネントライブラリ・canvas からのクラウドフロー・委任 delegation/委任警告・事前読み込み・Monitor）、クライアントスクリプティング（Client API object model formContext/executionContext・OnLoad/OnChange/OnSave・Dataverse Web API・コマンド/ボタン・navigateTo）、PCF コードコンポーネント（init/updateView/getOutputs/destroy・manifest・インターフェイス・package/deploy/consume・Device/Utility/Web API）。
2.1高度な canvas アプリ
複雑な Power Fx、コンポーネントライブラリ、canvas からのクラウドフロー呼び出し、委任（delegation）、Monitor によるトラブルシュートと性能最適化を理解します。
canvas アプリを実務レベルにするには 性能 と 再利用 が鍵です。特に 委任（delegation） の理解が応答性を左右します。
2.1.1Power Fx とコンポーネントライブラリ
複雑なロジックは Power Fx 数式（宣言的な式）で表現し、共通 UI は コンポーネントライブラリ にまとめて複数アプリで再利用します。サーバー処理や統合が必要なときは canvas アプリから Power Automate のクラウドフローを呼び出し、結果を受け取ります。
2.1.2委任（delegation）と性能
委任（delegation） は、フィルター/並べ替え等の処理を データソース側で実行させ、クライアントへ転送する行を抑える仕組みです。委任不可の関数を大規模データに使うと 委任警告が出て先頭の数百行しか処理されません（既定 500〜2000）。委任可能な関数/データソースを選び、必要なら 事前読み込み（pre-load） でアプリ起動時にデータを用意して体感を上げます。委任と事前読み込みは目的が異なります（サーバー処理 vs 起動時取得）。
2.1.3Monitor とトラブルシュート
Monitor は canvas/model-driven アプリの 操作/ネットワーク/数式評価をリアルタイムに追跡し、遅い処理やエラーの原因を特定します。model-driven ではフォーム/ビューの読み込みを最適化します。「アプリの動作を可視化して切り分け」＝Monitor、と覚えます。
決め手：「処理をデータソース側で実行し転送行を抑える」＝委任(delegation)。「委任不可×大規模で先頭数百行のみ」＝委任警告。「起動時にデータを用意」＝事前読み込み。「共通UIを複数アプリで再利用」＝コンポーネントライブラリ。「アプリの操作/数式/NWを追跡して切り分け」＝Monitor。
混同に注意：
①委任(サーバー処理)と事前読み込み(起動時取得)を取り違えない。
②委任警告を無視すると大規模データで欠落。
③Monitorは計測/可視化で自動修正しない。
④コンポーネントライブラリ(canvas再利用)とPCF(コードコントロール)は別。
2.1.4この節のまとめ
- 委任でデータソース側処理・委任警告に注意・事前読み込みは起動時取得
- Power Fxとコンポーネントライブラリで再利用・canvasからクラウドフロー呼出
- Monitorで操作/数式/NWを追跡し遅延/エラーを切り分け
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 大規模なデータソースに対し、フィルターをデータソース側で実行してクライアントへの転送行を最小化したい。最適な考え方はどれですか？
Q2. 委任できない関数を大規模データに使ったときに起こる問題として正しいのはどれですか？
Q3. canvas/model-driven アプリの操作・数式評価・ネットワークをリアルタイムに追跡し、遅い処理を特定したい。最適なのはどれですか？
Q4. 複数の canvas アプリで共通の UI コントロールやロジックを再利用したい。最適なのはどれですか？
Q5. 委任（delegation）と事前読み込み（pre-load）の違いとして正しいのはどれですか？