パフォーマンス目標の定義に関する推奨事項
この Power Platform Well-Architected パフォーマンス効率チェックリストのレコメンデーションに適用されます:
| PE:01 | パフォーマンス目標を定義します。 パフォーマンス目標は、ワークロード要件に関連付けられた数値である必要があります。 すべてのワークロード フローにパフォーマンス目標を実装する必要があります。 |
|---|
このガイドでは、パフォーマンス目標を確立して公開するための推奨事項について説明します。 パフォーマンス目標は、パフォーマンスの目標を定義するメトリックです。 これらのメトリックは、単一の数値または数値範囲として表されます。 これらは、継続的な改善を推進する明確で具体的なメトリックです。 パフォーマンス目標は、改善のための数値的基盤であり、チームが特定の目標に向けて取り組みを調整するのに役立ちます。 明確なパフォーマンス目標がなければ、チームはパフォーマンスの問題に関するフォーカスと説明責任を欠く可能性があります。 パフォーマンス目標を設定することで、チームは特定の目標に向けて取り組み、継続的な改善を推進することができます。
定義
| 任期 | Definition |
|---|---|
| データ フロー | システム内またはシステム間でのデータの移動。 |
| Dependency | ワークロードが依存するコンポーネント。 |
| Flow | ワークロードで特定の関数を実行する一連の操作。 ワークロードのコンポーネント間でのデータの移動とプロセスの実行が含まれます。 "フロー" は Power Automate フローを示す場合がありますが、このコンテキストでは、特定の実装に関連付けられていない汎用シーケンスを指します。 |
| メトリック | 一定の間隔で収集される数値。 メトリックは、特定の時点におけるシステムのいくつかの側面を説明します。 |
| パフォーマンス ターゲット | パフォーマンスの目標を定義するメトリック。 これらのメトリックは、単一の数値または数値範囲として表されます。 |
| ユーザー フロー | アプリケーションまたはシステム内でユーザーが実行するアクションのパスまたはシーケンスです。 |
| Workflow | タスクを達成するためにワークロードが実行する一連の手順。 |
主要な設計戦略
パフォーマンス目標の確立は、ワークロードのパフォーマンス効率を達成するための重要なステップです。 パフォーマンス目標は、ワークロードの望ましいパフォーマンス レベルを定義し、それらの目標を達成するための効果を測定するのに役立ちます。 パフォーマンス目標は、ワークロードの効率を測定および比較するためのベンチマークを提供します。 このベンチマークは、改善領域を明確にするのに役立ちます。 また、目標は、タスクを組織の目標に合わせて調整し、ビジネス成果を向上させます。 さらに、パフォーマンス目標はリソース割り当てのガイダンスを提供し、最適なパフォーマンスを維持しながら、ワークロードがさまざまな需要に適応できるようにします。
パフォーマンス目標を早期に設定する
ワークロードを展開する前にパフォーマンス目標を設定します。 パフォーマンス目標には調査が必要です。 市場調査、競合分析、アンケートを実施して、パフォーマンス目標の範囲を生成します。 パフォーマンス目標がない既存の運用ワークロードの場合は、運用データとユーザー フィードバックを使用してパフォーマンス目標を確立します。
パフォーマンス要件を決定する
パフォーマンス要件の決定とは、応答時間、スループット、レイテンシなど、ワークロードにとって重要なパフォーマンス指標を特定することです。 これらのパフォーマンス目標を組織のビジネス目標と一致させることで、クラス最高の製品でも平均的な製品でも、ワークロードが必要な基準を満たすことができます。 たとえば、応答時間の短縮、スループット率の向上、リソース使用の最適化を目指すことができます。
パフォーマンス目標を設定するときは、組織の目標とユーザー ベースの明確なニーズに合わせることが重要です。 ユーザーが最終的にパフォーマンスの成功を判断するため、パフォーマンス目標をユーザーの期待値に一致させる必要性が強調されます。 このバランスにより、パフォーマンス目標が意図したユーザー エクスペリエンスとワークロードの全体的な効率を確実に捉えることができます。
ワークロードのパフォーマンスを総合的に評価して最適化するには、次のパフォーマンス目標の設定を検討する必要があります:
- 個々のコンポーネント: 個々のコンポーネントはワークロードの個別のユニットまたはセグメントであり、それぞれが個別のパフォーマンス属性と要求を持つ可能性があります。
- ユーザーフロー: これらの経路は、ユーザーがワークロードをどのように操作するかを示し、その流動性を確保することで、ユーザー エクスペリエンスを直接向上させます。
- ワークフロー: ワークフロー定義の内部プロセスは、特定の結果を達成するために作成され、多くの場合、運用効率を決定します。
- データ フロー: データ フローは、ワークロード内のデータの移動と相互作用を指し、潜在的な非効率性やボトルネックを特定するのに役立ちます。
- 外部依存関係: 外部依存関係は、パフォーマンスに大きな影響を与える可能性のある、主要なワークロード (統合されたサード パーティのサービスまたはツール) の外部の要素です。
- テクノロジー レベル: テクノロジー レベルは、API アクセスの速度、データベース操作の待機時間、潜在的なネットワーク遅延などの直接的なパフォーマンス指標です。
- ビジネス トランザクション: 購入の完了やサービスの予約など、エンドツーエンドのユーザー ビジネス トランザクションをシームレスに実行することは、ユーザー満足度に直接結びついています。
- ワークロード全体: この総合的なメトリックは、ワークロードのすべてのコンポーネントと側面を網羅した総体的なパフォーマンスの概要を示します。
主要な指標を特定する
主要なパフォーマンス指標の特定には、ワークロードのパフォーマンス目標達成に向けた進捗状況を追跡するための重要な測定値を決定することが含まれます。 この特定は、パフォーマンス効率を測定および改善するための定量化可能な方法を提供します。
重点を置く主要な指標を特定するときは、可用性、キャパシティ、応答時間に関連するメトリックを考慮してください:
可用性: エラー率は可用性のパフォーマンス メトリックです。 エラー率は、一定期間内に失敗した要求の割合を表します。 エラー率の一般的な目標は、要求の 0.1 パーセントです。
キャパシティ: スループットとコンカレンシーはキャパシティ メトリックの例です。 スループットとは、指定された時間内に特定の数のトランザクションを処理する能力を指します。 たとえば、外部システムとのアプリケーション統合では、月に 1,000 万件の更新トランザクションを維持する必要があるかもしれません。 コンカレンシーとは、同時ユーザーまたはアクションの尺度です。
応答時間: 待機時間と読み込み時間は、一般的な応答時間メトリックです。 待機時間は、要求への応答にかかる時間です (200 ミリ秒)。 読み込み時間は、アプリケーションまたは Web ページが対話可能になるまでにかかる時間です。 一般的な目標は、顧客検索要求の 99% が 2 秒未満で完了することです。
ディフレクション率: 会話型 AI のコンテキストでは、ディフレクションは、セルフサービスを通じて完了したリクエストのうち、ライブ エージェントによって処理されるリクエストの割合を測定します。 これによって、自動化できるタスクの数を示し、チームの作業量を削減します。 エージェントの転換率の最適化は、投資収益率 (ROI) や顧客満足度 (CSAT) などのビジネス目標の達成を目指す企業にとって、またエージェントの総合的なパフォーマンスの向上を目指す企業にとっても、最優先の課題のひとつです。 エージェントのパフォーマンスを向上させる際に役立つ Copilot Studio の主要指標には、解決率、エスカレーション率、CSAT (顧客満足度) などがあります。
具体的な目標を設定する
主要な指標を特定したら、各指標のパフォーマンス目標またはしきい値を指定する必要があります。 パフォーマンス目標は測定可能で現実的であり、ワークロードの目標と一致している必要があります。 たとえば、目標応答時間を 500 ミリ秒 (ms) 未満に設定したり、目標エラー率を 1 パーセント未満に設定したりできます。
パフォーマンスの定性的評価は避けてください。 たとえば、速い、遅いが何を意味するかついて、ユーザーによって意見が異なります。 関係者は、"速い" の意味とそれを測定する方法に同意する必要があります。
数値目標を使用することで、時間の経過に伴うパフォーマンスを客観的に評価できます。 具体的なパフォーマンス目標を設定する際には、次の推奨事項を考慮してください:
ユーザーを考慮する: パフォーマンス目標を設定するときは、ユーザー中心の視点を採用します。 ユーザーをパフォーマンスの最終的な判断者と認識することは、パフォーマンス目標がユーザーの期待と一致することが保証されます。 この一致には、組織の目標とユーザー ベースの明確な要件の両方を考慮することが含まれます。 これら 2 つの側面を統合すると、目的のユーザー エクスペリエンスと全体的なワークロードの有効性を反映するようにパフォーマンス目標をカスタマイズできます。 ユーザーの期待を考慮したパフォーマンス目標を定義することで、高品質のユーザー エクスペリエンスを提供し、ユーザーのニーズを満たすように努めることができます。 ただし、ユーザーにパフォーマンス要件を尋ねる際には注意が必要です。 ユーザーは単に、システムが "可能な限り高速" であることを望んでいると述べているだけかもしれませんが、これは有益ではありません。 何が遅すぎると考えているのか、または許容できないパフォーマンスとはどのようなものなのかを明確にし、そこから逆方向に作業します。 こうすることで、より現実的な要件が得られます。
タスクを考慮する: ユーザーがシステムで実行するさまざまなタスクを考慮します。 一部のタスクは、パフォーマンスの観点か他のタスクよりも重要です。 たとえば、顧客の情報をすばやく調べる必要がある営業担当者は、月次営業レポートを確認する同じユーザーよりも高いパフォーマンスを必要とします。 パフォーマンスにとって重要なタスクに重点を置き、それらが要件を満たしていることを確認します。 重要なタスクごとに、どれくらいの時間がかかると思うかをユーザーと話し合います。 具体的に、一度に 1 つのタスクに焦点を当てます。 同じワークロード内でのタスクごとに異なる要件があることになりますが、これは理にかなっています。
パーセンタイルを使用する: P99、P95、P50 などのパーセンタイルは、パフォーマンス評価の結果を表すためによく使用されます。 数値にデータのどの部分が含まれているかを示します。 たとえば、P99 にはデータの 99% が含まれます。 単純な平均ではなくパーセンタイルを使用して、ワークロードのパフォーマンスをより包括的に把握します。 パーセンタイルを測定するには、通常は監視ツールまたはログ記録メカニズムを使用して、一定期間にわたってパフォーマンス データを収集します。 次に、このデータを分析して、さまざまなパーセンタイルにおける応答時間の値を決定します。
達成可能な目標を設定する: 使用しているサービスのベースライン パフォーマンスを考慮し、達成可能な目標を設定します。 基盤となるプラットフォームを抽象化するサービスを使用する場合は、コントロールできない要素に関連付けられた目標を設定しないでください。 たとえば、カスタム ロジックを組み込む前に、ベースライン パフォーマンスがすでに 250 ミリ秒である場合、画面の読み込みに 200 ミリ秒の目標を設定することは非現実的です。
パフォーマンス目標を文書化して公開する
パフォーマンス目標の文書化と公開とは、すべてのパフォーマンス目標を一元化された場所に記録することです。 パフォーマンス目標の達成は、開発チームと運用チームの間で共有される責任です。 ワークロードが常にこれらの目標を達成または上回るようにするため、チームにアクションを実行するための情報とアクセスを提供します。
パフォーマンス目標を文書化して公開するには、次の推奨事項を考慮してください:
パフォーマンス目標を文書化する: すべてのパフォーマンス目標を文書化します。 すべてのパフォーマンス目標が一元化された場所に文書化され、開発チームと運用チームの両方が簡単にアクセスできるようにします。 連携を促進し、リアルタイムの意思決定を支援します。
パフォーマンス目標を公開する: すべての担当チームは、パフォーマンス目標を確認して、そこから実行可能なタスクを作成できる必要があります。 ダッシュボードやレポートなどの情報ラジエーターを使用して、パフォーマンス目標にアクセスできるようにします。
実行可能にする: ドキュメントと情報ラジエーターは、明確な次のステップを提案する必要があります。 たとえば、エラーの増加は即時のチェックを促す可能性があり、また、目標を継続的に達成することはそのベンチマークの再評価を示唆する可能性があります。
ユーザー フィードバックを評価する
ユーザー フィードバックを評価するには、ユーザーの反応や提案を積極的に探し、分析する必要があります。 ユーザー フィードバックを積極的に収集して分析することで、ユーザーのニーズや期待に関する貴重な分析情報が得られます。 定期的なコミュニケーションは、変化する好みや技術トレンドに合わせてパフォーマンス目標を調整するのに役立ちます。 ユーザーのニーズに焦点を当てるということは、ワークロードが技術的なベンチマークに一致するだけでなく、継続的に改良されることを意味します。 ユーザー満足度を重視したこのアプローチにより、ワークロードが長期的に適切で成功し続けることになります。
Power Platform の促進
Power Platform は、Azure Monitor エコシステムの一部である Application Insights と統合します。 Azure Monitor は、リソースを監視し、パフォーマンス目標を測定するための完全な機能セットを提供するフルスタック監視サービスです。 Azure Monitor はプラットフォーム メトリックを収集し、すぐに使用できるダッシュボードを提供します。 メトリックに基づいてアラートを構成でき、メトリックを保存して相関させ、信頼できる唯一の情報源を確保することもできます。 標準テレメトリおよびカスタム トレース イベントをログに記録して分析する方法については、Application Insights を使用してシステム生成ログを分析する を参照してください。
Power Platform は、サービス保護制限を適用することで、一貫した可用性とパフォーマンスを保証します。 これらの制限は通常、ワークロードが通常の使用時に遭遇しない程度に高いものです。 ただし、ワークロードが大量のデータ、一括操作、またはデータ移行を処理する場合は、これらの制限に達する可能性があります。 ワークロード開発者であれば、サービス保護制限がどのように適用されるか、また制限を超える可能性を減らすためにワークロードをどのように設計するかを知っておく必要があります。 制限が発生した場合にどのように対処するかについても計画する必要があります。 詳細については、以下を参照してください。
Copilot Studio には、エージェントの主要業績評価指標を表示する包括的な分析セットがあります。 複数のグラフは、エージェントのトピックの傾向と使用状況を示します。 これらのグラフは AI を使用して、エージェントのパフォーマンスに最大の影響を与えるトピックを強調表示します。 また、カスタム分析戦略 を設計して、すぐに使用できる分析ではカバーされないレポートを作成することもできます。
パフォーマンス効率チェックリスト
完全なレコメンデーションのセットを参照してください。