このページでは、Google Chat アプリの作成に使用される一般的なサービス アーキテクチャ アプローチについて説明します。Google Chat に統合する既存のアプリがある場合は、既存の実装を使用または適応できます。新しい Chat アプリを構築する場合は、このページで類似情報をいくつかの方法で確認し、ユースケースに適したアーキテクチャを選択してください。
- 概要の表をご覧ください。
- 各アーキテクチャ スタイルの概要をご覧ください。
- Chat アプリのロジックの概要をご覧ください。
- Chat 用アプリの会話パターン別の概要をご覧ください。
機能と機能の概要
次の表に、Chat アプリの主な機能と推奨される(
)サービス アーキテクチャ スタイルを示します。場合によっては、これらの機能を使用して別のアーキテクチャ スタイルを開発できるものの、他のスタイル( )ほどユースケースに適していないことがあります。特長と機能 |
ウェブサービスまたは HTTP サービス |
Pub/Sub |
Webhook |
Apps Script |
AppSheet |
Dialogflow |
スクリプト |
---|---|---|---|---|---|---|---|
対象読者 |
|||||||
あなたのチーム |
|||||||
あなたの組織 |
|||||||
一般の人々 |
|||||||
ユーザー操作 |
|||||||
自然言語処理を使用する |
|||||||
メッセージ パターン |
|||||||
同期メッセージを送受信する |
|||||||
同期メッセージを送受信し、非同期メッセージを送信する |
|||||||
非同期メッセージをのみ送信する |
|||||||
外部システムから単一の Chat スペースにメッセージを送信する |
|||||||
他のサービスやシステムにアクセスする |
|||||||
他の Google サービスとの統合 |
|||||||
ファイアウォールの内側で通信する |
|||||||
Chat イベントをクエリまたはサブスクライブする |
|||||||
コーディングとデプロイのスタイル |
|||||||
コードなしの開発 |
|||||||
ローコードによる開発 |
|||||||
任意のプログラミング言語での開発 |
|||||||
簡素化された DevOps |
|||||||
DevOps と CI/CD の完全な管理 |
サービス アーキテクチャのスタイル
このセクションでは、Chat アプリの作成に使用される最も一般的なアーキテクチャ アプローチについて説明します。
ウェブサービスまたは HTTP サービス
ウェブまたは HTTP サービスは、デベロッパーが公開チャット アプリを構築する際に最も柔軟性があるため、最も一般的なデプロイ アーキテクチャです。このアーキテクチャは、次のユースケースに推奨されます。
- Chat アプリが Google Workspace Marketplace で一般公開されている。
- Chat アプリは、同期メッセージの送受信、非同期メッセージの送信、外部システムからのメッセージの送信など、すべてのメッセージ パターンを送受信できます。
- Chat アプリは任意のプログラミング言語で開発できます。
- Chat アプリでは、DevOps と CI/CD の完全な管理が必要です。
- Chat アプリ サービスは、クラウドまたはオンプレミス サーバーで実装されます。
この設計では、次の図に示すように、HTTP を使用してリモート サービスと統合するように Chat を構成します。
上の図では、HTTP Chat アプリを操作しているユーザーの情報フローは次のとおりです。
- ユーザーが Chat スペースで Chat アプリにメッセージを送信します。
- HTTP リクエストが、Chat アプリのロジックを含むクラウドまたはオンプレミス システムであるウェブサーバーに送信されます。
- 必要に応じて、Chat アプリのロジックは、プロジェクト管理システムやチケットング ツールなどの外部サードパーティ サービスとやり取りできます。
- ウェブサーバーは、Chat の Chat アプリ サービスに HTTP レスポンスを返します。
- レスポンスがユーザーに配信されます。
- 必要に応じて、Chat アプリは Chat API を呼び出して、メッセージを非同期的に投稿したり、他のオペレーションを実行したりできます。
このアーキテクチャでは、これらの Chat アプリをさまざまなプログラミング言語を使用して設計できるため、システムにすでに存在する既存のライブラリとコンポーネントを柔軟に使用できます。このアーキテクチャを実装する方法はいくつかあります。Google Cloud では、Cloud Functions、Cloud Run、App Engine を使用できます。使用を開始するには、Google Chat アプリを作成するをご覧ください。
Pub/Sub
Chat アプリがファイアウォールの内側に実装されている場合、Chat は HTTP 呼び出しを行うことができません。1 つの方法は、Pub/Sub を使用して、Chat アプリの実装で Chat からのメッセージを伝送するトピックにサブスクライブできるようにすることです。Pub/Sub は、メッセージを生成するサービスと処理するサービスとを切り離す、非同期メッセージング サービスです。このアーキテクチャは、次のユースケースに推奨されます。
- Chat アプリがファイアウォールの内側でビルドされている。
- Chat アプリは、Chat スペースに関するイベントを受信します。
- Chat アプリが組織にデプロイされている。
- Chat アプリは、同期メッセージを送受信でき、非同期メッセージを送信できます。
- Chat アプリは任意のプログラミング言語で開発できます。
- Chat アプリでは、DevOps と CI/CD の完全な管理が必要です。
次の図は、Pub/Sub で構築された Chat アプリのアーキテクチャを示しています。
上の図では、Pub/Sub Chat アプリを操作しているユーザーの情報フローは次のとおりです。
ユーザーが Chat で Chat アプリにメッセージを送信します(ダイレクト メッセージまたは Chat スペース)。または、Chat アプリで有効なサブスクリプションがある Chat スペースでイベントが発生します。
Chat はメッセージを Pub/Sub トピックに送信します。
アプリケーション サーバー(Chat アプリのロジックを含むクラウドまたはオンプレミス システム)は、ファイアウォールを介してメッセージを受信するために Pub/Sub トピックをサブスクライブします。
必要に応じて、Chat アプリは Chat API を呼び出して、メッセージを非同期的に投稿したり、他のオペレーションを実行したりできます。
使用を開始するには、Chat アプリのエンドポイントとして Pub/Sub を使用するをご覧ください。
Webhook
Chat のwebhook URL を呼び出すことで、特定の Chat スペースにのみメッセージを送信できる Chat アプリを作成できます。このアーキテクチャは、次のユースケースにおすすめです。
- Chat アプリがチームにデプロイされている。
- Chat アプリは、外部システムから単一の Chat スペースにメッセージを送信します。
このアーキテクチャでは、次の図に示すように、Chat アプリは特定の Chat スペースに限定され、ユーザー操作は許可されません。
上の図では、Chat アプリの情報フローは次のとおりです。
- Chat アプリのロジックは、プロジェクト管理システムやチケット販売ツールなどの外部サードパーティ サービスから情報を受け取ります。
- Chat アプリのロジックは、Webhook URL を使用して特定の Chat スペースにメッセージを送信できるクラウドまたはオンプレミス システムでホストされます。
- ユーザーは、その特定の Chat スペースの Chat アプリからメッセージを受信できますが、Chat アプリを操作することはできません。
このタイプの Chat アプリは、他の Chat スペースや他のチームと共有することはできません。また、Google Workspace Marketplace に公開することもできません。受信 Webhook は、Chat アプリがアラートやステータスを報告する場合や、一部のタイプの Chat アプリのプロトタイピングにおすすめです。
使用を開始するには、Webhook を使用して Chat にメッセージを送信するをご覧ください。
Apps Script
Chat アプリのロジックはすべて JavaScript で作成できます。Google Apps Script は、Chat アプリ用のローコード開発プラットフォームです。Apps Script は、ユーザー認証のための承認フローおよび OAuth 2.0 トークンを処理します。Apps Script を使用して公開 Chat アプリを作成できますが、1 日あたりの割り当てと上限があるため、おすすめしません。
このアーキテクチャは、次のユースケースにおすすめです。
- Chat アプリがチームまたは組織にデプロイされている。
- Chat アプリは、同期メッセージの送受信、非同期メッセージの送信、外部システムからのメッセージの送信など、すべてのメッセージ パターンを送受信できます。
- Chat アプリでは、簡素化された DevOps 管理が必要です。
このアーキテクチャは、次の図に示すように、Google スプレッドシート、Google スライド、Google カレンダー、Google ドライブ、Google マップ、YouTube などの他の Google Workspace サービスや Google サービスと統合される Chat アプリに便利です。
上の図では、ユーザーが Apps Script Chat アプリを操作すると、次の情報が流れます。
- ユーザーが、ダイレクト メッセージまたは Chat スペースで Chat アプリにメッセージを送信します。
- Google Cloud にある Apps Script で実装された Chat アプリのロジックがメッセージを受信します。
- 必要に応じて、Chat アプリのロジックを Google Workspace サービス(カレンダーやスプレッドシートなど)や、Google マップや YouTube などの他の Google サービスと統合できます。
- Chat アプリのロジックは、Chat の Chat アプリ サービスにレスポンスを返します。
- レスポンスがユーザーに配信されます。
開始するには、Apps Script を使用して Chat アプリを作成するをご覧ください。
AppSheet
AppSheet を使用して、コードなしでドメイン共有 Chat アプリを作成できます。自動構成モードを使用して、次のテンプレートで一般的な Chat アプリのアクションを作成すると、開発プロセスを簡素化できます。ただし、AppSheet ウェブアプリの一部の機能は Chat アプリではご利用いただけません。
このアーキテクチャは、次のユースケースにおすすめです。
- Chat アプリがユーザーとそのチームにデプロイされている。
- Chat アプリは、同期メッセージを送受信でき、非同期メッセージを送信できます。
- Chat アプリでは、簡素化された DevOps 管理が必要です。
次の図は、AppSheet で作成されたチャットアプリのアーキテクチャを示しています。
上の図では、AppSheet Chat アプリを操作しているユーザーの情報フローは次のとおりです。
- ユーザーが、ダイレクト メッセージまたは Chat スペースで Chat アプリにメッセージを送信します。
- Google Cloud にある AppSheet に実装された Chat アプリ ロジックがメッセージを受信します。
- 必要に応じて、Chat アプリのロジックを Google Workspace サービス(Apps Script や Google スプレッドシートなど)と統合できます。
- Chat アプリのロジックは、Chat の Chat アプリ サービスにレスポンスを返します。
- レスポンスがユーザーに配信されます。
始める前に、AppSheet を使用して Chat アプリを作成するをご覧ください。
Dialogflow
会話の自動化と動的レスポンスを実現する自然言語プラットフォームである Dialogflow を使用して Chat アプリを作成できます。このアーキテクチャは、次のユースケースにおすすめです。
- Chat アプリは同期メッセージを送受信できます。
- Chat アプリは、自然言語処理を使用してユーザーに返信し、ユーザーとやり取りします。
次の図は、Dialogflow で構築された Chat アプリのアーキテクチャを示しています。
上の図では、Dialogflow Chat アプリを操作しているユーザーの情報フローは次のとおりです。
- ユーザーが、ダイレクト メッセージまたは Chat スペースで Chat アプリにメッセージを送信します。
- Google Cloud に存在する Dialogflow 仮想エージェントがメッセージを受信して処理し、レスポンスを生成します。
- 必要に応じて、Dialogflow Webhook を使用して、Dialogflow エージェントがプロジェクト管理システムやチケット ツールなどの外部サードパーティ サービスとやり取りできるようにします。
- Dialogflow エージェントは、Chat の Chat アプリ サービスにレスポンスを返します。
- レスポンスが Chat スペースに配信されます。
開始するには、Dialogflow Google Chat アプリを作成するをご覧ください。
コマンドライン アプリケーションまたはスクリプト
ユーザーが Chat で Chat アプリを直接呼び出したり、Chat アプリに返信したりすることなく、Chat にメッセージを送信したり、スペースの作成やスペースのメンバーの管理などの他の操作を実行したりするコマンドライン アプリケーションまたはスクリプトを作成できます。このアーキテクチャは、次のユースケースに推奨されます。
- Chat アプリは任意のプログラミング言語で開発できます。
- Chat アプリでは非同期メッセージをのみ送信できます。
次の図にアーキテクチャを示します。
上の図では、Chat アプリの情報フローは次のとおりです。
- Chat アプリは Chat API を呼び出して、メッセージを送信したり、他のオペレーションを実行したりします。
- チャットがリクエストされたオペレーションを実行します。
- 必要に応じて、Chat アプリが CLI に確認メッセージを出力します。
チャットアプリのロジックの実装
Chat では、Chat アプリのロジックを実装する方法に制限はありません。固定構文のコマンド パーサーを作成したり、高度な AI と言語処理のライブラリやサービスを使用したり、イベントに登録して応答したり、特定の目標に適したその他の処理を行うことができます。
ユーザー操作を処理する
Chat アプリは、さまざまな方法でユーザー操作を受け取って応答できます。ユーザー インタラクションとは、ユーザーが Chat アプリを起動または操作するために行うすべてのアクションです。
コマンド パーサー
コマンド駆動型の Chat アプリは、Chat アプリのインタラクション イベントのペイロードを調べ、このコンテンツからコマンドとパラメータを抽出します。たとえば、スラッシュ コマンドを設定して Chat ユーザーとやり取りするをご覧ください。
別の方法として、メッセージをトークン化し、コマンドを抽出して、コマンドを各コマンドのハンドラ関数にマッピングする辞書を参照することもできます。
ダイアログ ベースのユーザー インターフェース
ダイアログ ベースのアプリは、Chat アプリのインタラクション イベントに応答して、カードベースのダイアログを表示します。このダイアログでは、ユーザーが Chat アプリを操作して、フォームの記入やアクションのリクエストを行うことができます。
ユーザーがダイアログでアクションを実行するたびに、新しいインタラクション イベントが Chat アプリに送信されます。Chat アプリは、ダイアログの更新やメッセージの送信によって応答できます。
自然言語処理
多くの Chat アプリの実装では、自然言語処理(NLP)を使用してユーザーの質問内容を判断します。NLP を実装する方法は数多くあり、任意の方法で実装できます。
Dialogflow ES または Dialogflow CX Chat 統合を使用して Chat アプリの実装で NLP を使用できます。これにより、自動化された会話と動的レスポンスを実現するバーチャル エージェントを作成できます。
Chat にリクエストを積極的に送信する
チャットアプリは、Chat でのユーザーの直接操作によってトリガーされないメッセージやその他のリクエストを Chat に送信することもできます。代わりに、これらの Chat アプリは、サードパーティ アプリケーションやユーザーからのコマンドライン呼び出しなどによってトリガーできますが、ユーザーは Chat でこれらの Chat アプリを直接操作することはできません。
インタラクティブでない Chat アプリは、Chat API を使用して、メッセージやその他のタイプのリクエストを Chat に送信します。
会話パターン
Chat アプリがユーザーとどのようにやり取りするかを検討する必要があります。以降のセクションでは、Chat アプリで実装できる会話パターンについて説明します。
コール アンド レスポンス(同期)
同期呼び出しとレスポンス パターンでは、Chat アプリはユーザーからのメッセージに 1 対 1 で応答します。次の図に示すように、ユーザーが Chat アプリに送信した 1 つのメッセージに対して、Chat アプリから 1 つのレスポンスが返されます。
上の図では、ユーザーが Chat アプリを操作すると、次の情報フローが実行されます。
- ユーザーが Chat アプリに同期メッセージを送信します(「次の会議は何?」など)。
- Chat アプリは、同期メッセージをユーザーに送信します(「Silva 医師 2 時 30 分」など)。
このタイプの会話パターンの場合、ウェブサービス、Pub/Sub、Apps Script、AppSheet、Dialogflow を使用してチャットアプリのアーキテクチャを実装できます。
複数のレスポンス(非同期)
複数のレスポンス パターンには、同期メッセージと非同期メッセージを含めることができます。このパターンは、ユーザーと Chat アプリ間の双方向通信が特徴で、Chat アプリは任意の数の追加メッセージを生成します(次の図を参照)。
上の図では、ユーザーが Chat アプリを操作すると、次の情報フローが実行されます。
- ユーザーが Chat アプリに同期メッセージを送信します(「トラフィックをモニタリング」など)。
- Chat アプリは、リクエストを承認する同期メッセージをユーザーに送信します(「モニタリング中」など)。
- その後、Chat アプリは REST API を呼び出して、1 つ以上の非同期メッセージをユーザーに送信します(「新しいトラフィック」など)。
- ユーザーが Chat アプリに追加の同期メッセージを送信します(「トラフィックを無視」など)。
- Chat アプリは、リクエストを承認する同期メッセージをユーザーに送信します(「モニタリングをオフ」など)。
このタイプの会話パターンの場合、ウェブサービス、Pub/Sub、Apps Script、AppSheet を使用してチャットアプリのアーキテクチャを実装できます。
イベントをクエリまたはサブスクライブする(非同期)
非同期イベントドリブン パターンでは、Chat アプリは Chat API をクエリするか、Google Workspace Events API を使用して Chat スペースまたはユーザーへのサブスクリプションを作成することでイベントを受信します。イベントは、新しいメッセージが投稿されたときや、ユーザーがスペースに参加したときなど、Chat リソースに対する変更を表します。イベント駆動型の Chat アプリは、イベント ペイロードを調べて変更された Chat リソースに関するデータを取得し、それに応じて応答します。
Chat アプリは、スペース、メンバーシップ、メッセージ、リアクションに関するイベントなど、さまざまな種類のイベントを受信できます。Chat アプリが Chat API をクエリするか、アクティブな定期購入を介してイベントを受信すると、Chat アプリは必要に応じて任意の数の非同期レスポンスを生成し、Chat API を使用して Chat に送り返します。
このタイプのロジックを使用すると、チケット管理システムなどの外部システムを更新したり、Chat スペースに非同期でメッセージを送信したりできます。たとえば、新しいユーザーが Chat スペースに参加したときにウェルカム メッセージを送信できます。
次の図は、イベントドリブンの会話パターンの例を示しています。
上の図では、Chat と Chat アプリ間のやり取りは次のようになります。
- Chat アプリが Google Chat スペースをサブスクライブします。
- Chat アプリが定期購入しているスペースが変更された。
- Chat アプリは、Pub/Sub のトピックにイベントを配信します。トピックは、サブスクリプションの通知エンドポイントとして機能します。このイベントには、リソースで変更された内容に関するデータが含まれます。
- Chat アプリは、イベントを含む Pub/Sub メッセージを処理し、必要に応じてアクションを実行します。
このタイプの会話パターンの場合、Pub/Sub、ウェブサービス、Apps Script を使用してチャットアプリのアーキテクチャを実装できます。
イベントの受信と返信の詳細については、Google Chat イベントのイベントを操作するをご覧ください。
Chat アプリからの一方向のメッセージ
Chat アプリからの一方向のメッセージ パターンでは、Chat アプリが Chat スペースに非同期メッセージを送信できますが、ユーザーが Chat アプリを直接操作することはできません。このパターンは会話型またはインタラクティブではありませんが、次の図に示すように、アラーム レポートなどに役立ちます。
上の図では、Chat アプリと同じ空間にいるユーザーの情報フローは次のとおりです。
- Chat アプリは、Chat API を呼び出すか、Webhook URL(「キューのオーバーフロー アラート」など)に投稿して、非同期メッセージをユーザーに送信します。
- 必要に応じて、Chat アプリは追加の非同期メッセージを送信します。
このタイプの会話パターンの場合、ウェブサービス、Webhook、Apps Script、AppSheet、コマンドライン アプリケーション、スクリプトを使用して Chat アプリのアーキテクチャを実装できます。
Chat アプリへの一方向のメッセージ
Chat アプリへの一方向メッセージ パターンでは、ユーザーが Chat アプリにメッセージを送信しても、Chat アプリはリクエストの処理を続行しながら応答しません。このアーキテクチャは技術的には可能ですが、ユーザー エクスペリエンスが低下するため、このパターンは強くおすすめしません。
関連トピック
- Google Chat アプリを作成する
- Chat アプリのエンドポイントとして Pub/Sub を使用する
- 着信 Webhook を使用して Chat にメッセージを送信する
- Apps Script を使用して Chat アプリを作成する
- AppSheet を使用して自動化機能から Chat メッセージを送信する
- Dialogflow ES Chat の統合
- Dialogflow CX Chat の統合。