※本記事はプロモーションを含みます
目次
Googleフォームから送信されたデータに対して、スプレッドシートを開いて手動で確認し、返信メールを作成するような作業は、数が少ないうちは問題ありません。ただし、毎日数件から数十件の申し込みや問い合わせが入るようになると、あっという間に業務のボトルネックになります。なので、このような状況を打破するために、GASを使ってGoogleフォーム送信時にスクリプトを自動実行する仕組みを導入することが自動化の第一歩となります。というのは、フォームが送信された瞬間にプログラムが動き出し、回答内容を読み取って指定の処理を行うことで、タイムラグのない即時対応が可能になるからです。この記事では、この連携のやり方と、実際に組んでみたときに発生しがちなデータの取り回しの問題、そしてその回避方法について確認しましょう。
フォーム送信時にスプレッドシート側のGASを自動実行させる状況と基本のスクリプト
いつ使うか：顧客からの問い合わせフォームや、社内の備品購入申請フォームなど、回答が送信されたタイミングで即座に何かしらのアクションを起こしたい場面で使います。ただし、手動での確認待ちをなくすための標準的な設計として、送信イベントをフックしてGASを即時起動させる方法が最も確実です。なので、送信直後に自動でお礼メールを送信する、チャットツールに通知を飛ばす、別のスプレッドシートに整形して転記する、といった処理を実行しましょう。
function onFormSubmit(e) {
const responses = e.namedValues;
Logger.log("回答者メール: " + responses["メールアドレス"][0]);
}注意と回避：このスクリプトは、単体で書いただけでは自動実行されません。なので、GASのイベントトリガーを使って、「フォーム送信時」にこの関数が動くように紐付ける必要があります。トリガー設定を忘れると連携ができず全く動かないので注意しましょう。引数として渡されているイベントオブジェクト e には、送信されたフォームのすべての回答内容が格納されています。ただし、ここでよくつまづくのが、e.namedValues の中身の構造です。というのは、フォームの質問タイトルがキーになり、その回答が「配列」として格納されているという点が非常に重要だからです。たとえ単一のテキストボックスからの回答であっても、配列の形式をとっています。なので、コード上で [0] をつけて最初の要素を取り出さなければならない点に注意しましょう。この [0] をつけ忘れると、メールアドレスの文字列のつもりで処理を進めたのに、配列オブジェクトとして扱われてしまい、後続のメール送信処理などでエラーになります。というのは、プログラムが型の違いを解釈できないからです。なので、回避策としては、回答を取り出す際には必ず配列のインデックスを指定して値を取り出すことを習慣づけましょう。
送信された回答データの取り出し方と配列の扱いでズレる点
いつ使うか：イベントオブジェクト e から特定の回答データを抽出して、後続のプログラムに渡したい場合に使います。ただし、フォームには名前、メールアドレス、問い合わせ内容など複数の質問項目があります。なので、それらを正確にプログラム側で受け取りましょう。
注意と回避：先ほどのコード例では e.namedValues を使って回答データを取得しました。ただし、もうひとつ e.values というプロパティも存在します。e.values は、スプレッドシートの左端の列から順番に、回答内容がただの配列として格納されているものです。一見するとインデックス番号だけでアクセスできるのでシンプルに思えます。なので、初心者には扱いやすく見えます。ただし、実務においてはこの e.values の使用は避けたほうが無難です。というのは、運用途中でGoogleフォームの質問の順番を入れ替えたり、新しい質問を途中に差し込んだりすると、スプレッドシートの列の順番がずれてしまうからです。列の順番が変わると、プログラム側が期待しているインデックス番号と実際の回答データが合致しなくなります。なので、「メールアドレスの宛先に、別の質問の回答文が入力されてしまい送信エラーになる」といった深刻な事故を引き起こします。
これを回避するために、列の順番ではなく「質問のタイトル」をキーとしてデータを引っ張ってくる e.namedValues を使用しましょう。これなら、フォーム側で質問の順番をどれだけ入れ替えても、質問のタイトルさえ変更されていなければ正しくデータを取得できます。ただし、ここでも注意すべきズレが存在します。というのは、フォームを作成した担当者が、後から質問のタイトルを微妙に変更してしまうケースがあるからです。たとえば「メールアドレス」という質問タイトルを、より丁寧にしようと「ご連絡先メールアドレス」と変更したとします。なので、データを取得しようとしていたGAS側のコードは、そのキーを見つけられなくなり、エラーを吐いて止まります。この事態を回避するための運用ルールとして、GASと連携させているGoogleフォームの質問タイトルは、稼働開始後に安易に変更してはいけないということを、フォームの管理者全員に徹底しておきましょう。ただし、どうしてもタイトルを変えたい場合は、GASのコード側のキー名も同時に修正するというセット作業を忘れないようにしましょう。
スプレッドシートと連携している場合の行追加タイミングによる挙動の違い
いつ使うか：Googleフォームから送信されたデータを、いったんGoogleスプレッドシートに書き出し、そのスプレッドシート側にバインドされたGASをフォーム送信時に実行させたい場合に使います。ただし、データの一覧性や過去データの加工を考えると、フォームと連携したスプレッドシート側にスクリプトを書くケースが一般的です。なので、この設定手順を確認しましょう。
注意と回避：スプレッドシート側にGASを書く場合、トリガーの設定を「スプレッドシートのイベント」としての「フォーム送信時」にする必要があります。ただし、ここでの挙動について正確に把握しておかないと、期待したデータが取れないというズレが発生します。フォームからデータが送信されると、まずスプレッドシートの最下段に新しい行が追加され、そこに回答データが流し込まれます。なので、それとほぼ同時に、設定しておいた送信時のトリガーが引かれてGASが起動します。ただし、この「行の追加・書き込み」と「GASの起動」は非同期に近い形で動くため、ごくまれにタイミングのズレが生じることがあります。
通常であれば、イベントオブジェクト e を通じて送信されたばかりのデータを受け取れるので問題ありません。ただし、プログラムの中でシートの最終行のデータを直接読みに行こうとすると、予期せぬトラブルに見舞われることがあります。フォームがほぼ同時に複数人から送信された場合、スプレッドシートには一気に複数の行が追加されます。なので、その状態で最終行を取得すると、自分が処理しようとしていた回答の行ではなく、直後に別の人が送信して追加された行番号を取得してしまう可能性があるのです。このズレを回避するためには、スプレッドシートのセルを直接読みに行くのではなく、必ずイベントオブジェクト e の中に入っているデータを信用して使いましょう。というのは、イベントオブジェクトの中身は、その瞬間に送信された1回分のデータが完全にパッケージ化されているため、他の送信データと混ざることは絶対にないからです。
また、スプレッドシート側に独自の計算式を仕込んでおき、フォームからデータが入った瞬間に計算結果を出して、その結果をGASで送信したいと考えることがあるかもしれません。ただし、フォームからデータが送信された際、スプレッドシートは「新しい行を挿入」してデータを書き込みます。なので、あらかじめその行に計算式を入力して待機させていたとしても、行挿入によって計算式が押し出されたり、無視されたりしてしまいます。もし送信されたデータをもとに何らかの計算を行いたいのであれば、すべてGASのプログラム内で数値を計算してから、改めて別のセルに書き込むか、そのまま次の処理に渡すという設計にしましょう。
即時自動返信を連携して組む際のエラー回避とテストの回し方
いつ使うか：回答内容からメールアドレスを抽出し、問い合わせフォーム送信直後にお礼メールを自動送信するパイプラインを構築する際に使います。ただし、即時自動返信は、ユーザーに対して確かに受け付けましたという安心感を与えるための標準設計です。なので、確実に動作するように構築しましょう。
注意と回避：この自動返信システムを構築して本番稼働させる前には、必ず自分自身でテスト送信を繰り返すことになります。ただし、テスト段階でよく発生するトラブルがいくつかあります。まずひとつ目が、GASの初回実行時に求められる「権限の承認」プロセスにまつわる問題です。トリガーを設定して自動実行に任せていると、バックグラウンドで処理が走るため、権限の承認画面が画面上にポップアップしてきません。なので、トリガーを設定したのにフォームを送信しても何も起きないという状態に陥ります。これを回避するためには、トリガーを設定した後、フォームを送信してテストをする前に、一度GASのエディタ画面から手動で関数を動かしてみましょう。手動実行ではイベントオブジェクトが渡されないためエラーになります。ただし、その前にアクセス権限を許可するかどうかの確認画面が表示されます。なので、そこで承認を完了させておくことで、以降のトリガー実行が正常に行われるようになります。
さらに、テストの回し方にもコツがあります。本番と同じように何度もフォームの画面を開いて手入力して送信ボタンを押すのは、非常に時間がかかり非効率です。なので、プログラムのロジック部分をテストしたい場合は、イベントオブジェクト e と全く同じ構造を持ったダミーのオブジェクトを作成するテスト用の関数を別途用意しておくことをおすすめします。ダミーのデータを用意して、本来動かしたい関数にそれを引数として渡して実行しましょう。というのは、フォームを介さずにGASのエディタ上だけで処理の正確性を何度も検証できるからです。メールの文面が正しく改行されているか、差し込みデータが正しい位置に入っているかなどの微調整は、このダミーデータを活用したテストで完結させておきましょう。なので、最終的な通しテストとして数回だけ実際のフォーム画面から送信してみる、という手順を踏むと、開発のスピードが劇的に向上します。
運用開始から数ヶ月が経過すると、突然自動返信が届かなくなったという報告があがるケースがあります。ただし、この場合、疑うべきはGASのコードそのもののバグではなく、周辺環境の変化です。というのは、誰かがGoogleフォームの質問項目名を編集してしまったケースや、スプレッドシートの連携を一度解除して再度連携し直したことでGASのトリガーが切れてしまったケースが考えられるからです。特に質問項目名の変更はコード内のキー指定と直結しているため、致命的なエラーを引き起こします。なので、運用ルールとして、フォームの編集権限を持つ人間を最小限に絞ることや、項目の追加や変更を行う場合は事前に影響範囲をテスト環境で確認するといった運用方針を取り入れましょう。
