第1回 問題集（全般）

正解: A. A. 要件が標準機能（Out-of-the-box）で実現できないかを確認する

正解の根拠・詳細解説

技術設計の第一歩は、カスタム開発の前に標準機能で要件を満たせないかを評価することです。不要なカスタム開発はメンテナンスコストを増大させます。

正解: A. A. プラグイン（Plug-in）

正解の根拠・詳細解説

プラグインはDataverseのトランザクション内で同期的に実行されるため、データの整合性を保ちながらリアルタイムにビジネスロジックを適用できます。

正解: A. A. Power Automateクラウドフローまたは非同期プラグイン

正解の根拠・詳細解説

非同期処理が必要な場合は、Power Automateのクラウドフローや非同期モードのプラグインを使うことで、メインのトランザクションをブロックせずに処理を実行できます。

正解: A. A. エラスティックテーブル（Elastic tables）

正解の根拠・詳細解説

エラスティックテーブルはNoSQLベースで大量データや高頻度の書き込みに適しており、ストレージコストを抑えながらスケールできます。

正解: A. A. 仮想テーブル（Virtual tables）

正解の根拠・詳細解説

仮想テーブルは外部データソースのデータをDataverse内のテーブルとして透過的に扱える機能で、データの複製が不要です。

正解: A. A. 行共有（Row sharing）

正解の根拠・詳細解説

行共有を使うと、通常のセキュリティロールでは権限のない特定レコードへの一時的なアクセスを、個別のユーザーやチームに付与できます。

正解: A. A. 使用するコネクタがビジネスデータグループと非ビジネスデータグループのどちらに分類されているか

正解の根拠・詳細解説

DLPポリシーはコネクタを「ビジネス」「非ビジネス」等のグループに分類し、グループ間でのデータ混在を制限するため、使用するコネクタの分類確認が設計上重要です。

正解: A. A. コードコンポーネント（PCF）またはキャンバスコンポーネント

正解の根拠・詳細解説

Power Apps component framework（PCF）のコードコンポーネントやキャンバスコンポーネントライブラリを使うことで、複数アプリ間で再利用可能なUIパーツを構築できます。

正解: A. A. カスタムコネクタ（Custom Connector）

正解の根拠・詳細解説

カスタムコネクタを作成することで、独自APIへの呼び出しロジックをPower Automate・Power Apps・Copilot Studioなど複数のサービスで再利用できます。

正解: A. A. Dataverseのコードコンポーネント（カスタムAPIやプラグイン内のPower Fx関数）

正解の根拠・詳細解説

DataverseはPower Fx関数を使ったロジックの実行をサポートしており、プラグインやカスタムAPIの一部として組み込むことで再利用可能なロジックを設計できます。

正解: A. A. スケジュールトリガーのPower Automateクラウドフロー

正解の根拠・詳細解説

スケジュールトリガーを使ったクラウドフローにより、人手を介さず定期的に処理を自動実行できます。

正解: A. A. オンプレミスデータゲートウェイ経由のコネクタまたはAzure統合

正解の根拠・詳細解説

オンプレミスのデータソースと連携する場合は、オンプレミスデータゲートウェイを使ったコネクタ接続や、Azure Data FactoryなどのAzureサービスを介した統合を設計します。

正解: A. A. ソリューション層とALM（アプリケーションライフサイクル管理）戦略の整備

正解の根拠・詳細解説

複数開発者が関わる場合、ソリューション層を適切に分離し、ALM戦略（開発・テスト・本番環境の分離やパイプライン活用）を整備することが競合回避の鍵です。

正解: A. A. クライアントサイド処理（JavaScript/クライアントAPI）

正解の根拠・詳細解説

クライアントサイドでの処理は、サーバーへの往復（ラウンドトリップ）を減らし、ユーザー体験を向上させるために適しています。

正解: A. A. Power Platform Pipelines

正解の根拠・詳細解説

Power Platform Pipelinesを使うことで、環境間のソリューション移行を標準化・自動化し、安全なALMプロセスを実現できます。

正解: A. A. マネージドID（Managed Identity）またはMicrosoft Entra IDのサービスプリンシパル

正解の根拠・詳細解説

Dataverseに対するサービス間（アプリ間）通信では、対話的にサインインするユーザーが存在しないため、アプリケーション自身のIDでアクセストークンを取得する必要があります。Microsoft Entra IDにアプリケーションを登録してサービスプリンシパルを作成し、Dataverse側ではそのアプリケーションIDに対応する「アプリケーションユーザー」を作成してセキュリティロールを割り当てることで、最小権限に基づいたアクセスが実現できます。Azure FunctionsやApp Serviceなどのホストから接続する場合はマネージドIDを利用すれば、クライアントシークレットや証明書そのものを管理する必要がなくなり、資格情報の漏えいリスクと定期的な更新（ローテーション）の手間を同時に減らせます。一方、ユーザー名とパスワードをコードに埋め込む方式は、多要素認証や条件付きアクセスと両立せず、資格情報がソース管理に混入する危険も高いため推奨されません。やむを得ず秘密情報を使う場合も、Azure Key Vaultなどに退避してコードに直接書かない設計が原則です。

正解: A. A. 対象ユーザーに割り当てられているセキュリティロールの権限設定

正解の根拠・詳細解説

運用上のセキュリティ問題は多くの場合、セキュリティロールの権限不足が原因です。エンティティレベル・フィールドレベルの権限設定を確認します。

正解: A. A. 最小権限の原則（Principle of Least Privilege）

正解の根拠・詳細解説

最小権限の原則に従い、コードコンポーネントが正常に動作するために必要な最小限の権限のみをセキュリティロールに設定することがベストプラクティスです。

正解: A. A. 開発中の変更が本番データやユーザーに影響を与えないようにするため

正解の根拠・詳細解説

開発環境を本番環境から分離することで、開発中の不具合や未完成の機能が本番業務に影響を与えるリスクを排除できます。

正解: A. A. ソリューション依存関係（Dependency）。依存元が存在する場合は依存先を削除できない

正解の根拠・詳細解説

ソリューション依存関係があるコンポーネントは、依存元のコンポーネントが存在する限り削除できません。依存関係はソリューションのエクスポート前に確認すべき重要な要素です。

正解: A. A. 環境変数（Environment Variables）

正解の根拠・詳細解説

環境変数を使うことで、開発・テスト・本番環境ごとに異なる設定値（URL、接続文字列等）をソリューション内にハードコーディングせずに管理できます。

正解: A. A. ソリューション層（Solution Layers）

正解の根拠・詳細解説

ソリューション層により、ベースソリューションに対する変更が積み重なる順序を管理し、どの層がどのコンポーネント設定を上書きしているかを把握できます。

正解: A. A. Power Platform Pipelines

正解の根拠・詳細解説

Power Platform Pipelinesは、ソリューションのステージング（開発→テスト→本番）を標準化し、承認プロセスやデプロイの自動化を実現する機能です。

正解: A. A. Pipelinesの拡張機能（カスタムデプロイ通知/ステップ）

正解の根拠・詳細解説

Power Platform Pipelinesは拡張可能な設計になっており、カスタムのデプロイ前後処理や通知ステップを追加して、組織独自のガバナンス要件に対応できます。

正解: A. A. Power Platform Build Tools

正解の根拠・詳細解説

Power Platform Build Toolsは、Azure DevOpsやGitHub Actionsと統合し、CI/CD（継続的インテグレーション/継続的デプロイ）パイプラインを構築するためのタスク集です。

正解: A. A. 手動操作によるヒューマンエラーを減らし、デプロイの再現性を高めること

正解の根拠・詳細解説

CI/CDによる自動化は、手動でのエクスポート・インポート作業に伴うミスを減らし、毎回同じ手順で確実にデプロイできる再現性を実現します。

正解: A. A. 管理対象ソリューションは本番環境への配布用で編集がロックされる、非管理対象は開発用で自由に編集できる

正解の根拠・詳細解説

管理対象ソリューションは本番環境にデプロイする完成品として扱われ直接編集できません。非管理対象ソリューションは開発環境で自由に編集可能な状態です。

正解: A. A. テスト環境・本番環境にデプロイする場合

正解の根拠・詳細解説

テスト環境や本番環境への配布を目的とする場合は、管理対象ソリューションとしてエクスポートするのが標準的なALMプラクティスです。

正解: A. A. ソリューション依存関係とコンポーネントの変更履歴

正解の根拠・詳細解説

予期しない動作不良の多くは依存関係のあるコンポーネントの変更に起因するため、依存関係マップと変更履歴の確認が最初の調査ステップです。

正解: A. A. ソリューションを機能単位で分割し、各チームが独立したソリューションを担当する

正解の根拠・詳細解説

ソリューションを機能単位（モジュール単位）に分割することで、チーム間の同時編集によるコンフリクトを最小化できます。

正解: A. A. ソリューションのパッケージ化・解凍やコードコンポーネントのビルド・プッシュ

正解の根拠・詳細解説

Power Platform CLI（pac CLI）は、ソリューションのパッケージング、PCFコンポーネントのビルドとプッシュなど、開発者ワークフローを支援するコマンドラインツールです。

正解: A. A. 不具合のある変更が本番環境に到達する前に検出すること

正解の根拠・詳細解説

CI/CDパイプラインに自動テストを組み込む目的は、不具合を含む変更が本番環境に到達する前の段階で検出し、フィードバックを開発者へ素早く返すことにあります。Power Platformでは、キャンバスアプリのTest Studioで作成したテスト、プラグインやカスタムワークフローアクティビティに対する単体テスト、Power Apps Test Engineによる自動実行などをビルドやリリースの工程に組み込めます。ソリューションのエクスポートからテスト環境への展開、テスト実行までを自動化しておけば、既存機能が壊れるリグレッションを早い段階で発見でき、修正コストは本番障害として顕在化してから対応する場合よりも大幅に小さくなります。一見するとテスト工程の分だけデプロイが遅くなるように思えますが、手戻りや障害対応にかかる時間が減るため、全体のリードタイムはむしろ短縮されます。テストはライセンス費用やユーザー数を左右するものではなく、リリース可否を判断する品質ゲートとして機能する点を押さえておきましょう。

正解: A. A. Switch関数やIf関数のネスト

正解の根拠・詳細解説

複雑な条件分岐には、Switch関数や入れ子になったIf関数を使用します。ロジックの可読性を保つため、Switch関数が推奨される場合が多いです。

正解: A. A. コンポーネントライブラリ（Component Library）

正解の根拠・詳細解説

コンポーネントライブラリを作成することで、複数のキャンバスアプリ間で同じUIコンポーネントやロジックを再利用でき、保守性が向上します。

正解: A. A. 長時間処理や外部システム連携をアプリのパフォーマンスに影響を与えずに実行できる

正解の根拠・詳細解説

Power Automateクラウドフローにロジックを委ねることで、長時間かかる処理や複雑な外部連携をアプリ本体から分離し、UIの応答性を保てます。

正解: A. A. Monitor（モニターツール）

正解の根拠・詳細解説

Power AppsのMonitorツールは、アプリの実行中に発生する関数呼び出しやAPI呼び出しの詳細なトレースを記録し、パフォーマンス問題の原因特定に役立ちます。

正解: A. A. 事前読み込み（Pre-loading）

正解の根拠・詳細解説

事前読み込み（Pre-loading）により、アプリ起動時に必要なデータをあらかじめ取得しておくことで、ユーザーが操作を始めるまでの待ち時間を短縮できます。

正解: A. A. クエリの委任（Delegation）

正解の根拠・詳細解説

クエリの委任（Delegation）により、Filter・Sort等の処理をクライアント側ではなくデータソース側（サーバー側）で実行させ、大量データでも高速に処理できます。

正解: A. A. フォームに表示されるフィールド数やサブグリッドの数

正解の根拠・詳細解説

モデル駆動型アプリのフォームパフォーマンスは、表示するフィールド数・サブグリッド・関連付けられたビジネスルールの数に大きく影響されるため、不要な要素を削減することが最適化の鍵です。

正解: A. A. ビューの列数とフィルター条件のインデックス利用状況

正解の根拠・詳細解説

ビューのパフォーマンスは表示列数やフィルター条件がインデックスを活用できているかに影響されます。不要な列やインデックスのない複雑なフィルターは遅延の原因になります。

正解: A. A. Monitorツールでの実行トレース確認とブラウザの開発者ツールの併用

正解の根拠・詳細解説

Monitorツールとブラウザの開発者ツール（コンソールログ等）を併用することで、数式実行時のエラーや不具合の原因を効率的に特定できます。

正解: A. A. ライブラリの更新が既存アプリの動作に影響しないよう、バージョニング戦略を設計する

正解の根拠・詳細解説

コンポーネントライブラリの変更は依存する全アプリに影響するため、後方互換性を考慮したバージョニング戦略の設計が重要です。

正解: A. A. 委任可能なフィルター条件を使い、必要なデータのみをサーバー側で絞り込む

正解の根拠・詳細解説

委任可能なフィルター条件を使うことで、サーバー側で必要なデータのみに絞り込んでから取得でき、大量データでもパフォーマンスを維持できます。

正解: A. A. フォームのビジネスルールまたはクライアントスクリプトによる条件制御

正解の根拠・詳細解説

ビジネスルールやクライアントスクリプトを使うことで、特定の条件（フィールドの値等）に応じてフォーム上の表示・非表示を動的に制御できます。

正解: A. A. 画面ごとに必要なデータのみを取得し、不要な数式の再評価を減らす

正解の根拠・詳細解説

各画面で必要最小限のデータ取得・数式評価に留めることで、画面遷移時の読み込み時間を短縮できます。OnStartへの過度な集約はアプリ起動を遅延させる原因になります。

正解: A. A. ページングやビューのフィルター条件を活用して表示件数を制限する

正解の根拠・詳細解説

サブグリッドのページング設定やビューのフィルター条件を適切に活用することで、表示件数を制限し、フォームの読み込みパフォーマンスを改善できます。

正解: A. A. アプリの起動時間が大幅に遅くなる

正解の根拠・詳細解説

OnStartプロパティに大量の処理（特に委任不可能なクエリ等）を記述すると、アプリ起動時にすべての処理が完了するまで待つ必要があり、起動時間が大幅に遅延します。

正解: A. A. ブラウザの開発者ツール（ネットワークタブ等）とMonitorツール

正解の根拠・詳細解説

モデル駆動型アプリのパフォーマンス問題は、サーバー側の処理時間とクライアント側の描画やスクリプト実行のどちらに原因があるのかを切り分けることが第一歩です。ブラウザーの開発者ツールのネットワークタブでは、Web APIへのリクエストごとの所要時間や応答サイズ、リクエストの件数を確認でき、フォームの読み込み時に不要なデータまで取得していないかを判断できます。さらにPower PlatformのMonitorツールを使うと、フォームのイベント、クライアントスクリプトの実行、ビジネスルール、ネットワーク呼び出しなどが時系列のトレースとして記録され、どの処理が遅延の原因になっているかを具体的に特定できます。実務ではこの情報をもとに、タブやサブグリッドの読み込みを遅延させる、OnLoadで同期実行しているスクリプトを減らす、取得する列を必要最小限に絞るといった改善につなげます。Power BI DesktopやSharePoint Designerは、こうしたランタイムの診断を行うためのツールではありません。

正解: A. A. イベントハンドラーの登録（OnChangeイベント）

正解の根拠・詳細解説

Client APIのイベントハンドラー登録機能を使い、フィールドのOnChangeイベントにJavaScript関数を紐づけることで、値変更時にカスタムロジックを実行できます。

正解: A. A. Dataverse Web API（Xrm.WebApi）

正解の根拠・詳細解説

クライアントスクリプトからDataverseのデータを操作する際は、Client APIのXrm.WebApiオブジェクトを通じてDataverse Web APIを呼び出します。

正解: A. A. コマンドとボタンの表示ルール（Power FxまたはJavaScriptによる条件指定）

正解の根拠・詳細解説

リボンのカスタムボタンの表示・非表示は、Power FxやJavaScriptの表示ルール（Enable/Display Rule）で条件を指定して制御します。

正解: A. A. Xrm.Navigation.navigateTo

正解の根拠・詳細解説

Xrm.Navigation.navigateToを使うことで、クライアントスクリプトからカスタムページへの遷移を実行できます。

正解: A. A. init

正解の根拠・詳細解説

PCFコンポーネントのライフサイクルでは、init メソッドがコンポーネントの初期化時に最初に呼び出され、コンテキストやコンテナの設定を行います。

正解: A. A. updateView

正解の根拠・詳細解説

updateView メソッドは、バインドされたプロパティの値が変化した際に呼び出され、コンポーネントのUIを最新の値で再描画します。

正解: A. A. destroy

正解の根拠・詳細解説

destroy メソッドは、コンポーネントが破棄される際に呼び出され、イベントリスナーの解除などのクリーンアップ処理を行います。

正解: A. A. コンポーネントマニフェスト（ControlManifest.Input.xml）

正解の根拠・詳細解説

ControlManifest.Input.xmlは、PCFコードコンポーネントが使用するプロパティ・リソース・機能を定義するマニフェストファイルです。

正解: A. A. Power Platform CLI（pac pcf push）

正解の根拠・詳細解説

Power Platform CLIのpac pcf pushコマンドを使うことで、開発したPCFコードコンポーネントを開発環境にデプロイ・テストできます。

正解: A. A. Device API

正解の根拠・詳細解説

PCFのDevice APIを使うことで、コンポーネント内からデバイスのカメラ・GPS位置情報・バーコードスキャナーなどの機能にアクセスできます。

正解: A. A. Utility API

正解の根拠・詳細解説

Utility APIには、確認ダイアログやエラーメッセージの表示、進行状況インジケーターの制御などのユーティリティ機能が含まれます。

正解: A. A. WebAPI

正解の根拠・詳細解説

PCFのWebAPIを使うことで、コンポーネント内から直接Dataverseのレコードを取得・作成・更新・削除できます。

正解: A. A. 依存するライブラリが先に読み込まれていないと関数が未定義エラーになるため

正解の根拠・詳細解説

JavaScriptライブラリ間に依存関係がある場合、依存元が先に読み込まれていないと、関数呼び出し時に「未定義」エラーが発生するため、読み込み順序の設定は重要です。

正解: A. A. OnSaveイベントでのexecutionContext.getEventArgs().preventDefault()

正解の根拠・詳細解説

OnSaveイベントハンドラー内でpreventDefault()を呼び出すことで、特定の条件下でフォームの保存処理自体をキャンセルできます。

正解: A. A. コンポーネントからホストアプリケーションへ出力値（バインドされたプロパティの更新値）を返すこと

正解の根拠・詳細解説

PCF（Power Apps Component Framework）のコードコンポーネントは、init、updateView、getOutputs、destroyというライフサイクルメソッドで構成されます。getOutputsは、コンポーネント内部でユーザー操作などにより変化した値を、マニフェストで出力可能と定義したプロパティの形でホスト（フォームやビュー）へ返すためのメソッドです。コンポーネント側で値が変わったときにnotifyOutputChangedを呼び出すと、フレームワークがgetOutputsを呼び出し、その戻り値のオブジェクトがバインドされた列に反映されます。つまり、notifyOutputChangedが「変更が起きたことを知らせる合図」、getOutputsが「実際の値を渡す口」という役割分担になっています。初期化やコンテナーの準備はinit、イベントハンドラーの解除などの後片付けはdestroyが担当し、ネットワーク接続の確認はいずれのメソッドの責務でもありません。この流れを理解しておくと、入力した値がフォームに反映されない不具合の切り分けが容易になります。

正解: A. A. Pre-operation（ステージ20）

正解の根拠・詳細解説

Pre-operationステージ（20）はメインのデータベース操作（トランザクション）の直前に実行され、操作対象データの最終調整に使われます。

正解: A. A. Pre-validation（ステージ10）

正解の根拠・詳細解説

Pre-validationステージ（10）は、セキュリティチェック（権限確認）よりも前に実行される最も早いステージで、トランザクション外で動作します。

正解: A. A. Post-operation（ステージ40）

正解の根拠・詳細解説

Post-operationステージ（40）はメインのデータベース操作が完了した後に実行され、関連レコードへの通知や後続処理に適しています。

正解: A. A. 対象レコードのデータ、実行ユーザーID、メッセージ名などの実行時情報

正解の根拠・詳細解説

実行コンテキストには、対象エンティティのデータ（Target）、実行ユーザー、メッセージ名（Create/Update等）、深さ（Depth）などのプラグイン実行時情報が含まれます。

正解: A. A. 操作対象のレコードのデータ（変更されたフィールドの値）

正解の根拠・詳細解説

Targetパラメータには、Create・Update操作で渡された変更後のレコードデータ（変更フィールドの値）が含まれます。

正解: A. A. Pre Image（事前イメージ）

正解の根拠・詳細解説

Pre Imageを登録することで、プラグイン実行時に更新前（変更前）のレコードの値を取得し、変更前後の値を比較するロジックを実装できます。

正解: A. A. Post Image（事後イメージ）

正解の根拠・詳細解説

Post Imageを登録することで、操作完了後の完全なレコードの値（Targetに含まれない未変更フィールドも含む）を取得できます。

正解: A. A. Organization Service（IOrganizationServiceインターフェース）

正解の根拠・詳細解説

プラグイン内では、IOrganizationServiceインターフェース（Organization Service）を使ってDataverseのレコードに対するCRUD操作を実行します。

正解: A. A. 不要なクエリの実行を避け、必要なフィールドのみを取得する（列セットの絞り込み）

正解の根拠・詳細解説

ColumnSet（取得する列の指定）を絞り込み、不要なデータ取得を避けることで、プラグインの実行パフォーマンスを最適化できます。

正解: A. A. カスタムAPI（Custom API）

正解の根拠・詳細解説

カスタムAPIを作成することで、標準のCRUD操作にとらわれない独自のメッセージ（操作）をDataverse上で定義し、複数の場所から呼び出せます。

正解: A. A. Plug-in Registration Tool

正解の根拠・詳細解説

Plug-in Registration Toolを使うことで、コンパイルしたプラグインアセンブリをDataverse環境にアップロードし、ステップ（実行タイミング）を登録できます。

正解: A. A. カスタムAPIのメタデータ設定（リクエスト・レスポンスパラメータ定義）

正解の根拠・詳細解説

カスタムAPIのリクエスト・レスポンスパラメータは、DataverseのカスタムAPIメタデータとして事前に定義し、それに対応する処理をプラグインコードで実装します。

正解: A. A. 業務上の重要なイベント発生時に、外部システムへ通知を送信すること

正解の根拠・詳細解説

Dataverseのビジネスイベントは、特定の業務上のイベント（例：注文確定）が発生した際に、Azure Service Bus等を通じて外部システムへ通知するための仕組みです。

正解: A. A. Open API定義（OpenAPI/Swagger仕様）

正解の根拠・詳細解説

既存のREST APIをカスタムコネクタとして利用するには、まずそのAPIのOpen API定義（Swagger/OpenAPI仕様）を作成または取得する必要があります。

正解: A. A. クライアントID・クライアントシークレット・認証URL・トークンURL

正解の根拠・詳細解説

OAuth 2.0認証を実装する際は、クライアントID、クライアントシークレット、認証エンドポイントURL、トークンエンドポイントURLなどをカスタムコネクタの認証設定で指定します。

正解: A. A. ポリシーテンプレート（Policy Templates）

正解の根拠・詳細解説

ポリシーテンプレートを使うことで、ヘッダーの追加・レスポンスの変換・リトライロジックなど、コネクタの実行時の挙動を柔軟に変更できます。

正解: A. A. Azure Functionをデプロイし、そのOpenAPI定義からカスタムコネクタを作成する

正解の根拠・詳細解説

AzureサービスをPower Platformと連携する場合、まずAzure Functionsなどをデプロイし、そのAPI定義（OpenAPI）をもとにカスタムコネクタを作成するのが典型的な流れです。

正解: A. A. GitHub・Azure・既存のOpenAPI定義

正解の根拠・詳細解説

カスタムコネクタの作成時には、GitHubで公開されているOpenAPI定義、Azureサービスの定義、既存のOpenAPI/Swaggerファイルなどからインポートできます。

正解: A. A. コネクタ内のコード（C#によるリクエスト/レスポンス変換ロジック）

正解の根拠・詳細解説

カスタムコネクタでは、C#で記述したコードを使ってリクエスト・レスポンスのデータ形式を変換するロジックを実装できます。

正解: A. A. バッチ処理（$batchリクエスト）

正解の根拠・詳細解説

複数のレコードを作成・更新する場合、$batchリクエストを使うことで複数の操作を1つのHTTPリクエストにまとめ、パフォーマンスを向上できます。

正解: A. A. If-Match（ETag）

正解の根拠・詳細解説

If-MatchヘッダーにレコードのETag値を指定することで、他のユーザーによる更新と競合していないかを検出する楽観的同時実行制御を実装できます。

正解: A. A. 429（Too Many Requests）

正解の根拠・詳細解説

API制限に達した場合、Dataverse Web APIは429（Too Many Requests）を返し、Retry-Afterヘッダーで再試行までの推奨待機時間を示します。

正解: A. A. Retry-Afterヘッダーの値に従って待機し、リトライポリシーを実装する

正解の根拠・詳細解説

429エラーを受け取った場合は、レスポンスのRetry-Afterヘッダーが示す時間だけ待機してからリトライするポリシーを実装するのがベストプラクティスです。

正解: A. A. Organization Serviceは.NET向けのSDKベースAPI、Web APIはRESTベースで言語を問わず利用可能

正解の根拠・詳細解説

Organization Serviceは.NET SDKを使ったAPIで、Web APIはOData準拠のRESTful APIとして言語やプラットフォームを問わず利用できます。

正解: A. A. $expandクエリオプション

正解の根拠・詳細解説

$expandクエリオプションを使うことで、関連エンティティのデータを1回のリクエストで一緒に取得でき、リクエスト数を削減できます。

正解: A. A. ユーザーが対話的にログインするアプリケーション

正解の根拠・詳細解説

認可コードフローは、ユーザーが対話的にログインしてアクセスを許可するシナリオ（Webアプリ等）に適しています。バックグラウンドサービスにはクライアントクレデンシャルフローが適しています。

正解: A. A. クライアントクレデンシャルフロー（サービスプリンシパル認証）

正解の根拠・詳細解説

クライアントクレデンシャルフローは、ユーザーの介在なしにアプリケーション自体の資格情報（クライアントID・シークレット）で認証するため、バックグラウンドサービスに適しています。

正解: A. A. Azure Functions

正解の根拠・詳細解説

Azure Functionsを使うことで、Power Platformから呼び出される長時間実行処理をサーバーレスでオフロードし、メインのトランザクションをブロックしません。

正解: A. A. タイマートリガー（Timer Trigger）

正解の根拠・詳細解説

タイマートリガーを使うことで、Azure Functionsをcron式で指定したスケジュールに従って定期実行できます。

正解: A. A. Queueトリガー（Azure Storage Queue/Service Busトリガー）

正解の根拠・詳細解説

Queueトリガーを設定することで、Azure Storage QueueやAzure Service Busにメッセージが追加されたタイミングでAzure Functionsを自動実行できます。

正解: A. A. マネージドID（Managed Identity）の利用

正解の根拠・詳細解説

マネージドIDを利用することで、Azure Functionsは資格情報を管理せずに、Azure ADを通じて安全にPower Platformへ認証できます。

正解: A. A. Dataverseコネクタの「行の追加」「行の更新」アクション

正解の根拠・詳細解説

Dataverseコネクタが提供する「行の追加」「行の更新」などのアクションを使うことで、フロー内でDataverseのレコードを直接操作できます。

正解: A. A. 式（Expressions）

正解の根拠・詳細解説

Power Automateの式（Expression）機能を使うことで、文字列操作・数値計算・日付処理などの複雑なロジックをフローのステップ内に実装できます。

正解: A. A. Azure Key Vault

正解の根拠・詳細解説

Azure Key Vaultを利用することで、フロー内で使用するAPIキーやパスワードなどの機密情報を安全に保管し、フローからセキュアに参照できます。

正解: A. A. 実行後（Run After）の設定によるエラーハンドリング

正解の根拠・詳細解説

各アクションの「実行後（Configure run after）」設定を使うことで、前のアクションが失敗した場合の代替処理（エラーハンドリング）を構成できます。

正解: A. A. リトライポリシー（Retry Policy）

正解の根拠・詳細解説

各アクションにはリトライポリシーを設定でき、一時的なエラー発生時に指定した間隔・回数で自動的に再試行させることができます。

正解: A. A. トリガー条件（Trigger Conditions）

正解の根拠・詳細解説

トリガー条件を設定することで、特定の条件を満たさないイベントでのフロー実行をトリガーの段階でフィルタリングし、不要な実行を削減できます。

正解: A. A. 子フロー（Child Flow）

正解の根拠・詳細解説

子フロー（再利用可能なコンポーネントとしてのフロー）を作成することで、共通ロジックを複数の親フローから呼び出して再利用できます。

正解: A. A. ユーザーの資格情報に依存せず、アプリケーション自体の権限で安全に認証するため

正解の根拠・詳細解説

サービスプリンシパル認証を使うことで、特定ユーザーのアカウントに依存せず、アプリケーション専用の権限设定で安全に外部APIへアクセスできます。

正解: A. A. $filter

正解の根拠・詳細解説

$filterクエリオプションを使うことで、条件に基づいたレコードの絞り込みをWeb API呼び出し時に指定できます。

正解: A. A. プラグイントレースログ（Plug-in Trace Log）の実行時間

正解の根拠・詳細解説

プラグイントレースログには各プラグイン実行の処理時間が記録されており、これを確認することでボトルネックとなっている処理を特定できます。

正解: A. A. バインドの種類（Entity/EntityCollection/Global）を適切に選択する

正解の根拠・詳細解説

カスタムAPIを定義する際は、バインドの種類（Global、Entity、EntityCollection）を要件に合わせて選択します。Globalは特定のテーブルに紐づかない汎用的な処理、Entityは単一レコードを対象とする処理、EntityCollectionはテーブル単位で複数のレコードを一括して扱う処理に適しています。一括適用のような操作を想定する場合はEntityCollectionバインドを選ぶと、呼び出し側はテーブル単位でAPIを実行でき、対象となるレコードの集合をパラメーターとして受け渡す設計がしやすくなります。逆に、単一レコード用のEntityバインドで一括処理を実現しようとすると、レコードごとに呼び出しが発生してラウンドトリップが増え、パフォーマンスとトランザクション制御の両面で不利になります。バインドの種類は呼び出し方法そのものを規定するため、公開後に変更すれば既存の呼び出し元へ影響が及びます。設計段階で想定する呼び出しパターンを整理したうえで決定することが重要です。

正解: A. A. IServiceEndpointNotificationServiceを使ったサービスエンドポイント通知

正解の根拠・詳細解説

IServiceEndpointNotificationServiceを使うことで、Dataverseのイベント発生時にAzure Service BusやEvent Hub等の外部サービスエンドポイントへ通知を送信できます。

正解: A. A. サービスエンドポイント（Service Endpoint）の登録

正解の根拠・詳細解説

Plug-in Registration Toolで、まずAzure Service BusへのサービスエンドポイントをDataverse環境に登録し、その後ステップ（どのイベントで通知するか）を構成します。

正解: A. A. 大量のイベントデータをリアルタイムでストリーミング処理する分析シナリオ

正解の根拠・詳細解説

Azure Event Hubは大量のイベントデータをリアルタイムでストリーミング処理するのに適しており、データ分析やリアルタイム監視のシナリオでDataverseイベントの送信先として使われます。

正解: A. A. 軽量で単純なHTTP POST通知に適しているが、大量・高頻度イベントには不向き

正解の根拠・詳細解説

Webhookは軽量なHTTP POST通知の仕組みで、シンプルな連携には適していますが、Azure Service BusやEvent Hubと比較すると大量・高頻度のイベント処理にはあまり向いていません。

正解: A. A. Power AutomateのDataverseトリガー（クラウドフロー）

正解の根拠・詳細解説

Power Automateのクラウドフローに用意されているDataverseトリガー（行が作成された時等）も、Dataverseイベントをリスニングする方法の1つです。

正解: A. A. 変更の追跡（Change Tracking）

正解の根拠・詳細解説

変更の追跡（Change Tracking）機能を使うことで、前回の同期以降に変更・作成・削除されたレコードのみを効率的に検出し、差分同期を実現できます。

正解: A. A. 変更トークン（deltaリンクまたはDataverseの変更追跡トークン）

正解の根拠・詳細解説

変更の追跡では、前回取得時に返された変更トークン（deltaリンク）を次回のリクエストに渡すことで、その時点以降の変更のみを取得できます。

正解: A. A. UpsertRequestメッセージ

正解の根拠・詳細解説

UpsertRequestメッセージを使うことで、対象レコードの存在有無を判定し、存在すれば更新・存在しなければ新規作成する処理を1回のリクエストで実行できます。

正解: A. A. 代替キー（Alternate Keys）

正解の根拠・詳細解説

代替キー（Alternate Key）を定義することで、Dataverseの内部GUIDではなく、外部システムの一意な業務キー（例：従業員番号）を使ってレコードを特定・操作できます。

正解: A. A. 事前にDataverseのGUIDを取得せずに外部システムのキーで直接レコードを特定・更新できる

正解の根拠・詳細解説

代替キーを使うことで、外部システムの業務キーをそのまま使ってUpsertRequestを実行でき、事前にGUIDを取得する追加クエリが不要になります。

正解: A. A. 変更元を識別するフラグやタイムスタンプ比較によるループ検出

正解の根拠・詳細解説

双方向同期では、変更元（システムAからの変更かシステムB自身の変更か）を識別するフラグやタイムスタンプの比較により、無限ループを防ぐ設計が必要です。

正解: A. A. バッチ処理とリトライポリシーを組み合わせた段階的なインポート

正解の根拠・詳細解説

バッチ処理で複数操作をまとめつつ、リトライポリシーで一時的なエラーに対応することで、API制限（スロットリング）の影響を抑えながら大量データを安全にインポートできます。

正解: A. A. 複数の異なるサブスクライバーが同じイベントを受け取る必要がある場合

正解の根拠・詳細解説

Azure Service Busのトピックはパブリッシュ/サブスクライブモデルをサポートし、複数の異なるサブスクライバーが同じイベントを受け取る必要があるシナリオに適しています。

正解: A. A. エラーログとデッドレターキューの活用

正解の根拠・詳細解説

エラーログを記録し、処理失敗したメッセージをデッドレターキューに退避させることで、後から原因調査や再処理を行える設計が推奨されます。

正解: A. A. 統合ロジックを疎結合に設計し、各システムの変更が他に影響しにくい構成にする

正解の根拠・詳細解説

Dataverseと複数の外部システムを連携する大規模ソリューションでは、統合部分をいかに疎結合に保つかが保守性を左右する。接続先のURLやパラメータは環境変数として外部化し、開発・検証・本番の各環境でソリューションを作り直さずに切り替えられるようにする。認証情報はAzure Key Vaultなどの安全な場所で管理し、プラグインのコードに直接埋め込まないことが前提となる。処理は連携先ごとにカスタムコネクタやAzure Functionsといった単位で分割し、Service Bus経由の非同期連携を活用すれば、外部システムの障害や遅延がDataverse側のトランザクションに波及しにくくなる。すべてのロジックを1つの巨大なプラグインに集約すると、1か所の変更で広範囲の再テストが必要になるうえ、同期プラグインの実行時間制限にも抵触しやすい。接続情報のハードコーディングは環境移行や接続先変更のたびに改修を強いることになる。例外を握りつぶさず適切に記録し、再試行できる設計にしておくことも運用上不可欠である。