APLのライフサイクルを最適化する
レイテンシーを低減して視覚的なUXを向上させるには、ほとんどの場合、既にレンダリングされているAPLドキュメントを使用して、画面上のUIを更新することが効果的です。まったく新しいAPLドキュメントをレンダリングしてUIを置き換えることは、次の3つの理由から避ける必要があります。
- 新しいAPLドキュメントのレンダリングには、クラウド上とデバイス側で常に追加のリソースと操作が必要になります。軽量のAPLテンプレートでも、そのレンダリングにかかる時間は、既にレンダリング済みのAPLドキュメントを再利用する場合に発生するレイテンシーよりも長くなります。
- 新しいAPLドキュメントをレンダリングしてUIを置き換える場合、視覚的な画面遷移をカスタマイズしてよりシームレスに表示しようとしても、それを効果的に実現する方法がありません。
- 新しいAPLドキュメントをレンダリングすると、ローカルのデータコンテキストとViewportの状態はリセットされます。状態情報をデバイスにローカルに保持できないため、スキルでセッションベースの情報を永続化し、新しくレンダリングされた各APLドキュメントに関連情報を送信する必要があります。
以下の図は2つのシナリオを示しています。一方のシナリオでは、ユーザー操作のステップごとにスキルが新しいAPLドキュメントをレンダリングし続けます。もう一方では、画面に既にレンダリングされているAPLドキュメントを更新します。
次のような状況では、既にレンダリング済みのAPLドキュメントを再利用することは適切でない場合があります。
- エクスペリエンス全体を最初から最後までカバーすると、APLテンプレートを高度に動的にする必要が生じ、複雑さとサイズが大幅に増加する可能性があります。
- APLテンプレートが複雑になることが想定される場合、スキルの起動時に実行される画面の初回レンダリングのレイテンシーが非常に高くなったり、全体的なパフォーマンスが低下したりする可能性があります。
- シナリオによっては、ユーザーがAPLエクスペリエンスを進めるにつれて、レンダリングされたAPLコンポーネントの外観やコンテンツが根本から変更されることがあります。たとえば、APLエクスペリエンスが複雑なデータ構造に基づいていて、それらのデータが頻繁に更新される場合、データの変更を反映してUIを更新することは困難になると考えられます。このような状況では、新しいAPLドキュメントをレンダリングする方が効率的な場合があります。
実際には、レンダリング済みのAPLドキュメントを常に置き換えるべきか、再利用するべきかに関する厳密なルールはありません。次のように、両方が混在する状況もあります。
大きいAPLドキュメントを使用した場合に発生する可能性のある初回レンダリングのレイテンシーの高さを考えたとき、スキルの起動時にシームレスなUXを提供するメリットの方が重要であれば、APLドキュメントの不要なレンダリングは避けることをお勧めします。
APLの対話フローを設計する
APLプロジェクトの設計において重要な決定事項の1つが、新しいAPLドキュメントをいつレンダリングするかと、既にレンダリング済みのドキュメントをいつ再利用して、そのコンテンツと依存UI要素を（クラウドから、またはデバイスからローカルに）更新するかを決定することです。これはテンプレートの作成方法やプロジェクトの設定方法に大きく影響するため、時間をかけて最適なAPLエクスペリエンスのライフサイクルを特定する必要があります。そのための最良の方法は、実際のユースケースと、想定されるマルチモーダルユーザーエクスペリエンスから設計を始めることです。
スキルにダイアログベースの音声エクスペリエンスを設計するときは、スキルの言語モデルを構築するインテントとスロットを定義します。それと同様に、マルチモーダルAPLエクスペリエンスを設計するには、ユーザーがエクスペリエンスをどのように進んでいくかを表す対話フローを検討します。これにより、視覚的なUIエクスペリエンス全体をAPLテンプレートに分割する最適な方法、それらを内部で編成して構造化する方法、それらを再レンダリングしたり更新したりする方法とタイミングについての理解が深まります。
APLの対話フローは、次の4ステップのプロセスを使用して設計できます。
ステップ1： 視覚的なユーザーフローを特定する
APLの対話フローを設計する最初のステップは、APLエクスペリエンスに含まれている明確な視覚的ユーザーインターフェースを特定することです。ユーザーがエクスペリエンスを進めるために実行する一連のハッピーパスを定義します。
次の例は、8つの個別のUI画面で構成されるAPLエクスペリエンスの潜在的なユーザーパスを視覚化したものです。ユーザーは、これらのインターフェース間をさまざまな方法で移動できます。矢印はサポートされるユーザーパスを示しています。
既に音声専用のスキルがあり、それをマルチモーダルエクスペリエンスに拡張する場合は、音声ユーザーインターフェース（VUI）の図やスキルインテントの一覧などのデザインの構成要素を再利用して、視覚的なAPLエクスペリエンスでも必要となる一般的なユーザーパスを特定することをお勧めします。同様に、モバイルアプリやウェブインターフェースの既存の視覚エクスペリエンスを移行する場合は、それらの視覚的なユーザーフローをAPLプロジェクトに引き継ぐのが合理的です。
ステップ2： データフローを特定する
通常は、視覚的なAPLエクスペリエンスを表す論理ユーザーフローに加えて、そのフローに沿ったデータが存在します。このデータが使用され、画面に表示されます。視覚的なユーザーフローのステップごとに、どのようなデータがいつ必要になるかを検討します。また、データベース、ウェブサービス、画面自体からキャプチャされたユーザー入力など、データの提供元となるソースもすべて検討します。次の図は、データフローを簡略化して視覚化した例です。
この時点で、個々のユーザーインターフェースの表示方法に関する基本的な構想を作成すると、どのような種類のデータを画面上で表示および処理する必要があり、どのようなデータをユーザーやデバイスからの入力として収集すればよいかを把握するために役立ちます。視覚的なユーザーフローを特定するステップの一環としてこの作業をまだ行っていない場合は、視覚的なUI画面の予想やスケッチを作成することで、入出力データとして必要になる情報をより明確に理解できます。
ステップ3： 画面のナビゲーションと遷移の要件を収集する
視覚的なユーザーフローは、音声ユーザーフローよりもはるかに動的です。また、視覚的なユーザーフローは、音声ユーザーフローほど順次的には進みません。ユーザーが画面間をどのように移動し、さまざまな表示モードをどのように切り替えるかを検討すると、一部のUI領域がほかの領域よりもまとまっていることに気付くことがあります。UIに適切なまとまりを持たせるために、次のベストプラクティスを適用してください。
- 関連する画面間の切り替えがシームレスに行われ、遅延なく視覚的に滑らかに遷移するようにします。たとえば、リスト項目の詳細を表示するUIでは、リストビューと項目の詳細ページの間をシームレスにすばやく行き来できる必要があります。
- 関連するUI領域を互いに一貫性のある状態に保ちます。たとえば、このようなインターフェース間には、さまざまな方法で視覚化される共有データがあるものと想定されます。共有データが更新されたら、UIは目立つ遅延なく自動的に変更される必要があります。
密接に関連するユーザーインターフェースをグループ化し、まとまりのあるユニットを形成して、画面のナビゲーションと遷移の要件を反映するようにします。UI画面のグループ化方法を決定するには、共有データソースや依存関係についても考慮する必要があります。APLエクスペリエンスのデータフローを予測して、これらの画面をグループ化してください。次の図では、8つのUI画面で構成されるAPLユーザーフローを3つのグループに分けています。
ステップ4： 設計を完成させる
ここまでのステップで、画面のナビゲーションに関連する視覚的なユーザーフロー、対応するデータフロー、高レベルのUX要件を特定して組み合わせ、APLエクスペリエンスをまとまりのあるUI画面のグループに編成しました。各UIグループが独自の自己完結型APLドキュメントとしてレンダリングされると想定すると、この構造に基づいて、APLプロジェクトの基本要件をカバーするAPLライフサイクルを作成できます。
最後のステップでは、これらのすべての情報を基に、APLエクスペリエンスで最も一般的な視覚的ユーザーパスをカバーするライフサイクルの想定を作成します。次の図は、APLエクスペリエンスの例を示しています。
結果として視覚化されたAPLエクスペリエンスを基に、設計上重要な以下の質問に答えることができます。
- 目的のAPLエクスペリエンスを作成するために、どのような主要なアーティファクト（APLドキュメント）をプロジェクトで作成する必要があるか？ 上の例では、作成するAPLドキュメントが3つあります。
-
APLエクスペリエンスの一部としてどのような視覚ユーザーインターフェースを作成し、それらをどのように接続するか？ 上の例では、8つの個別のユーザーインターフェースが特定され、目的のユーザーパスをサポートするように配置されます。
- 複数のユーザーインターフェース間をいつどのように遷移させるか？ この質問は、ユーザーステップごとにスキルまたは画面上のAPLドキュメントによって下される重要な決定を問い直すものです。つまり、新しいAPLドキュメントをレンダリングしてUIを置き換えるか、既にレンダリング済みのAPLドキュメントのUIを更新するかを決定します。新しいAPLドキュメントをレンダリングし続けると、APLエクスペリエンスのパフォーマンスとUXの品質に影響する可能性があるため、最適なアプローチを特定することが重要です。詳細については、APLのライフサイクルを理解するを参照してください。
視覚化されたAPLライフサイクルは、常に見直して評価する必要があります。これは以下の質問に答えることで行います。
- 実際的なユーザー要件を適切にカバーしているか？
- 技術的に構築可能か？
- レンダリングされる画面数と更新される画面数の観点から、APLの利用が効率的に行われるか？
これらの質問のすべてに「はい」と答えられない場合でも、対話フローの設計を繰り返すことで懸案事項を解消できます。たとえば、UI画面をより効率的にAPLドキュメントに再グループ化できるように、ユーザーフローとデータフローを見直して変更できます。これらの質問にはっきりと答えられる自信がなくても、心配する必要はありません。実際、ドキュメントテンプレートをデザインしてAPLエクスペリエンスを構築するうちに、後でAPLのライフサイクルが変わることもあります。たとえば、2つのAPLドキュメントを1つにまとめることになったり、当初は予想していなかった技術的な制約のために1つのAPLドキュメントを分割することになったりする場合があります。
関連トピック
最終更新日: 2025 年 11 月 26 日