ベスト プラクティス

アドオンの設計に関するガイドに沿って、ユーザーの全体的なエクスペリエンスを改善します。

一般的なベスト プラクティス

開発するすべてのアドオンで、次のベスト プラクティスに従うことをおすすめします。

開始前にアドオンの所有権を特定する

アドオンは Apps Script プロジェクトで定義されます。このプロジェクトは、特定のアカウントが所有するか、共有ドライブに配置する必要があります。アドオンをコーディングする前に、プロジェクトを所有するアカウントと、パブリッシャーとして機能するアカウントを決定します。また、コラボレーション パートナーとして機能するアカウントを決定し、それらのアカウントがスクリプト プロジェクトとそれに関連付けられた Cloud Platform プロジェクトにアクセスできることを確認します。

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());

作成したテスト関数は、[Run] メニューを使用して Apps Script エディタから直接実行できます。有効なアドオンが機能したら、テストできるように公開されていないバージョンをインストールしてください。

アドオンが拡張するホスト アプリケーションごとに適切なテストデータを使用します。たとえば、アドオンが Gmail を拡張する場合は、さまざまなメッセージ コンテンツが渡されたときにアドオンが想定どおりに機能することを確認するために、いくつかのテストメールとそのメッセージ ID が必要になる可能性があります。特定のメッセージのメッセージ ID を取得するには、Gmail API Users.messages.list メソッドを使用してメッセージを一覧表示するか、Apps Script の Gmail サービスを使用します。

カレンダー カンファレンスのベスト プラクティス

アドオンでサードパーティのカレンダー会議オプションを Google カレンダーに統合する場合は、次のベスト プラクティスにも従ってください。

onCreateFunction ライトを点灯したままにする

マニフェストで定義した各 onCreateFunction は、ユーザーがそのタイプの会議ソリューションを作成しようとすると同期的に呼び出されます。これらの関数は、会議の作成に必要な最小限の作業のみを行うようにしてください。これらの関数で処理を行うことが多すぎると、アドオンのユーザー エクスペリエンスが低下する可能性があります。

会議データに適切な ConferenceData フィールドを使用する

ConferenceData オブジェクトを作成するときに、会議に関する詳細情報(アクセスコード、電話番号、ピン、URI など)を入力できます。この情報には、対応する EntryPoint フィールドを使用します。これらの詳細は、ConferenceData メモ フィールドに配置しないでください。

Google カレンダーの予定に会議の詳細情報を追加しない

アドオンで、作成されたサードパーティのミーティングに関する情報を Google カレンダーの予定の説明に追加する必要はありません。Google カレンダーでは、必要に応じてこの処理が自動的に行われます。