アドベントカレンダー2023#19:DialogflowとGASの連携におけるタイムアウト問題への対応（DEADLINE_EXCEEDED）
問題への対処検討
昨日のブログでは、DialogflowからGoogle Apps Script（GAS）へのリクエスト時に生じたタイムアウト問題を取り上げました。今日はその問題への対処法についてお話しします。
タイムアウト問題の再確認
DialogflowのWebhookはデフォルトで5秒のタイムアウトが設定されています。これを超えると「DEADLINE_EXCEEDED」というエラーが発生します。残念ながら、タイムアウト時間を延長することはできませんので、別のアプローチが必要です。
解決策の定石
タイムアウト問題への一般的な解決策として、以下の方法がありますが、OPENAI APIの処理には30秒かかるため、非同期処理の検討を進めた。
処理の最適化：GAS内の処理を見直し、実行時間を短縮する。
処理の分割：処理を分割して、各処理の時間を短縮する。
非同期処理の検討：非同期処理の導入を検討する。
GASでの非同期処理
GASは、非同期処理を直接サポートしていません。そのため、まずは、スプレッドシートにリクエストの内容を受け付ける処理を作成し、Google Apps Scriptのトリガーを利用して、受け付けた処理があればタスクを実行する、「非同期処理」風な実装が必要があります。これは本来の非同期処理とは異なりますが、GASの実装では最適な方法と判断しました。
シーケンス図の概要
全体の流れを整理するために、シーケンス図を描きました。以下のシーケンス図は、ユーザー、Slack、Dialogflow、GAS、Google Sheets、Trigger、そしてGPT APIを含むシステムの相互作用を示しています。
検索のリクエストの流れ（上段）
ユーザーはSlackを通じてメッセージを送信し、SlackはこのメッセージをDialogflowに転送します。DialogflowはGASに検索リクエストを送信し、GASはこのリクエストをGoogle Sheetsに登録します。その後、DialogflowはSlackを通じてユーザーに「受け付けました」と応答します。
検索結果の返送（下段）
トリガーがGASに処理実行を命じ、GASはGoogle Sheetsからリクエストを取得し、GPT APIにリクエストを送信します。その後、GASは処理結果をSlackに非同期で送信し、Slackはこの結果をユーザーに表示します。このシーケンス図は、ユーザーからの初期リクエストから、システム間での非同期処理を経て最終的な結果がユーザーに返されるまでのプロセスを示しています。
まとめ
本日は、Google Apps Script（GAS）での非同期処理の実装方法について検討しました。GASはステートレスなサーバーサイドJavaScript環境であり、従来のWebブラウザベースのJavaScript環境で一般的に見られるPromiseやasync/awaitを用いた非同期処理を直接サポートしていないため、特別なアプローチが必要です。今回の方法を用いて、まずは動作する基本的なシステムを構築し、それを基に次のステップへと進んでいきたいと思います。