アドオンの設計に関する以下のガイドに沿って、ユーザー エクスペリエンス全体を向上させましょう。
一般的なベスト プラクティス
開発するすべてのアドオンで、次のベスト プラクティスを使用することをおすすめします。
開始前にアドオンの所有権を判断する
アドオンは Apps Script プロジェクトで定義されます。このプロジェクトは特定のアカウントが所有しているか、共有ドライブに配置されている必要があります。アドオンをコーディングする前に、プロジェクトを所有するアカウントと、そのパブリッシャーとして機能するアカウントを決定します。また、共同編集者として機能するアカウントを特定し、それらのアカウントがスクリプト プロジェクトとそれに関連付けられた Google Cloud プロジェクトにアクセスできることを確認します。
Google Workspace を拡張する（複製しない）
アドオンは、拡張する Google Workspace アプリケーションに新しい機能を提供するか、複雑なタスクを自動化することを目的としています。アプリケーションにすでに存在する機能を複製するだけのアドオンや、ワークフローを大幅に改善しないアドオンは、公開のためのアドオン審査に合格する可能性は低いでしょう。
スコープを絞り込む
スコープを明示的に定義する場合は、可能な限り最小限の権限のスコープのセットを常に選択してください。たとえば、読み取りアクセスのみが必要な場合は、https://www.googleapis.com/auth/calendar スコープを使用してユーザーのカレンダーへの完全なアクセス権をアドオンにリクエストしないでください。読み取り専用アクセス権の場合は、https://www.googleapis.com/auth/calendar.readonly スコープを使用します。
ライブラリに過度に依存しない
Apps Script のライブラリを使用すると、Apps Script のコードがすべて 1 つのスクリプト プロジェクトに含まれている場合よりも、アドオンの実行速度が遅くなることがあります。Apps Script ライブラリはアドオンで動作しますが、使用するとパフォーマンスが低下する可能性があります。プロジェクトに不要なライブラリを含めないようにし、アドオンの依存度を下げる方法を検討してください。
上記のレイテンシは、サーバーサイド ライブラリとして使用されている Apps Script プロジェクトにのみ適用されます。この遅延を気にすることなく、jQuery などのクライアントサイドの JavaScript ライブラリを自由に使用できます。
Google Workspace アドオンのベスト プラクティス
以下のベスト プラクティスは、Google Workspace アドオンと カードサービスの使用にのみ適用されます。
少ない枚数のカードを使用する
アドオンで使用するカードが多すぎると、ナビゲーション構成が複雑になり、管理が難しくなります。
必要以上にカードを作成しないようにしましょう。
ウィジェット作成関数を使用する
Card などの複雑な UI オブジェクトを作成するコードを記述する場合は、そのコードを独自の関数に配置することを検討してください。この作成関数は、オブジェクトをビルドして返すだけです。これにより、UI を更新する必要があるたびに、そのオブジェクトをすばやく再生成できます。カードサービスでビルダー クラスを使用した後、build() を呼び出すことを忘れないでください。
カードはシンプルにする
特定のカードにウィジェットが多すぎると、画面の大部分が埋め尽くされ、使いにくくなる可能性があります。大きなカード セクションは折りたたみ可能な UI 要素としてレンダリングされますが、これによりユーザーに情報が非表示になります。アドオンを効率化し、ユーザーが必要とするものを過不足なく提供することを目指しましょう。
エラーカードを使用する
エラー条件のカードを作成します。アドオンでエラーが発生した場合は、エラー情報と、可能であればエラーを修正する方法の手順が記載されたカードを表示する必要があります。たとえば、認証に失敗したためにアドオンが Google 以外のサービスに接続できなかった場合は、その旨を記載したカードを表示し、使用されているアカウント情報を確認するようユーザーに求めます。
テストとテスト メッセージを作成する
作成したアドオンはすべて徹底的にテストする必要があります。テストデータを使用してカードとウィジェットを作成するテスト関数をビルドし、オブジェクトが想定どおりに作成されることを確認します。
アクション コールバック関数を使用する場合は、通常、レスポンス オブジェクトを構築する必要があります。次のステートメントを使用して、レスポンスが正しく構築されていることを確認できます。
Logger.log(response.printJson());
実行メニューを使用して、Apps Script エディタから作成したテスト関数を直接実行します。動作するアドオンが完成したら、テストできるように未公開バージョンをインストールしてください。
アドオンが拡張する各ホスト アプリケーションに適したテストデータを使用します。たとえば、アドオンが Gmail を拡張する場合、さまざまなメッセージ コンテンツが指定されたときにアドオンが想定どおりに機能することを確認するために、いくつかのテストメールとそのメッセージ ID が必要になる可能性があります。特定のメッセージのメッセージ ID を取得するには、Gmail API の users.messages.list メソッドを使用してメッセージを一覧表示するか、Apps Script の Gmail サービスを使用します。
カレンダー会議のベスト プラクティス
アドオンで サードパーティ製カレンダーの会議オプションを Google カレンダーに統合する場合は、次の追加のベスト プラクティスに沿ってください。
onCreateFunction ライトを維持する
マニフェストで定義した各 onCreateFunction は、ユーザーがそのタイプの会議ソリューションを作成しようとしたときに同期的に呼び出されます。これらの関数は、会議の作成に必要な最小限の作業のみを行うようにしてください。これらの関数で処理が多すぎると、アドオンのユーザー エクスペリエンスが低下する可能性があります。
会議データに適切な ConferenceData フィールドを使用する
ConferenceData オブジェクトをビルドするときに、会議の詳細（アクセスコード、電話番号、PIN、URI など）を入力できます。この情報には、対応する EntryPoint フィールドを使用してください。これらの詳細は ConferenceData のメモ フィールドに入力しないでください。
カレンダーの予定に会議の詳細情報を追加しない
アドオンで、作成されたサードパーティ製会議に関する情報をカレンダーの予定の説明に追加する必要はありません。カレンダーでは、必要に応じて自動的にこの処理が行われます。