Googleフォームと管理表をAIに作らせた GASは書けなくても使える
先日、筆者が主催した有料のオンライン勉強会で、申込の受付をひととおり用意する必要がありました。フォームで申し込んでもらい、回答をスプレッドシートで管理し、申込者には支払いの案内を自動で返す。運営側にも通知が届くようにする。
珍しい要件ではありません。セミナー、面談、資料請求、社内の備品申請。中小企業なら、だいたい同じものを作ろうとしたことがあるはずです。
これをAIに頼んだら、1本のスクリプトになって返ってきました。実行したら、フォームも管理表も自動返信も、まとめて出来上がっていた。
ただ、この記事で書きたいのはその速さではありません。公開の当日に、参加者の画面で「アクセス権が必要です」と出て、誰も回答できない状態になりました。 直したのは数分ですが、そこで分かったことのほうが役に立ちます。
Googleフォームは作れる。止まるのは、その先
Googleフォームを作ったことがある方は多いと思います。設問を並べて、回答をもらう。回答がスプレッドシートに溜まっていくところまでも標準の機能です。
止まるのはその先でした。
溜まった回答は、送信された順に並んでいるだけです。日程ごとに名簿を分けたい。残席を数えたい。誰が支払い済みかを管理したい。申込者には、その人が選んだ日程に合わせた案内を送りたい。支払いの期限も個別に計算したい。
このあたりから、標準の機能だけでは届かなくなります。だいたいは人がやることになります。毎朝スプレッドシートを開いて、新しい行を別のシートに写して、テンプレートを見ながらメールを書いて、送ったら管理表に印を付ける。申込1件あたり数分の作業が、募集期間中ずっと続くわけです。
この隙間を埋めるための仕組みが、Googleには前からあります。Google Apps Script、略してGASと呼ばれるものです。
Googleのスクリプト編集画面にコードを置いておくと、フォームの送信などをきっかけに、その処理が動きます。誰の権限で動くかは動かし方によって変わり、今回のようにフォーム送信をきっかけにする場合は、その仕掛けを登録した人の権限で動きます。フォーム、スプレッドシート、Gmail、カレンダーをまたいで操作できます。
登場は2009年8月です。17年前からある仕組みということになります。
ただし、ずっと同じものだったわけではありません。機能は少しずつ足されていて、たとえばスクリプトからフォームの公開状態を操作できるようになったのは2025年4月です。機能としてはあたらしいほうです。
変わらなかったのは、使うのに JavaScript というプログラミング言語で書く必要があったことです。少なくとも筆者の場合、壁になっていたのはそこでした。
AIが作るのは、フォームではなく仕組みごと
伝えたのは、要するにこれだけです。Googleフォームから申し込みが入るようにして、それをスプレッドシートで管理できるようにしてほしい。
返ってきたのは373行のスクリプトでした。実行すると、こうなりました。
申込フォーム。 参加条件を確認する設問が先頭の独立したページに置かれ、条件に合わない回答をした人はその時点で別ページへ分岐する作りでした。結果として、対象外の人に全項目を入力させてから断る形にはなっていません。細かく指定した覚えはありません。
管理用のスプレッドシート。 タブが4種類に分かれていました。
| タブ | 役割 |
|---|---|
| 回答の生データ | フォームが書き込む場所 |
| 管理 | 運用のメイン画面。生データから数式で取り込み、ステータス列は手入力 |
| 日程別の名簿 | 確定した人だけが自動で載る閲覧用 |
| 集計 | 日程別の確定数、支払い待ち、残席の自動計算 |
生データと作業用が分かれていると、事故が1つ減ります。フォームが書き込む列を人が並べ替えたり削ったりすると、以降の書き込み位置がずれて壊れます。触る場所と触らない場所を分けておけば、その事故が起きません。
自動返信メール。 申込と同時に支払いの案内が飛びます。期限は申込から24時間後、ただし開催前日の21時を上限にする、という計算まで入っていました。運営側にも通知が届きます。
筆者が一から作るなら、どこから手を付けるかを考えるだけで午前中が終わります。
「公開されている」と「その人が回答できる」は別の設定
速かったのは、コードができるまででした。
まず、実行の前に人がやることがあります。スクリプトを動かすには、そのスクリプトに対して、自分のGoogleアカウントのどこまで触ってよいかを許可する必要があります。ブラウザに確認画面が出て、フォームの作成、メールの送信、スプレッドシートの操作といった項目が並びます。ここを人が読んで押します。AIには押せません。
この画面は流し読みしないでください。AIが書いたコードに、自分のGmailを操作する権限を渡すことになります。 何をするコードなのか、どこにメールを送るのか、既存のファイルを消したり上書きしたりしないか。読んで分からなければ、社内の詳しい人に見てもらってから実行するほうが安全です。会社のアカウントだと、管理者がそもそも実行を制限している場合もあります。
そして実行したあとにも、確認が残ります。ここでつまずきました。
勉強会の当日、終了間際に配るアンケートを別に作っていました。回答用のURLをチャットに貼って、その場で答えてもらう予定でした。
貼った直後に、参加者の画面に「アクセス権が必要です」と表示されました。 誰も回答できません。
その場でAIに状況を伝えたところ、回答できる範囲の設定ではないかという指摘がすぐに返ってきました。フォームの設定を開いて、リンクを知っている人なら回答できる状態に変えたら、そのまま通りました。詰まっていた時間は短くて済んでいます。
引っかかったのはそこではなく、なぜ自分は気づけなかったのかのほうでした。作った本人のアカウントでは、フォームは普通に開きます。編集画面から見ても、回答画面を確認しても、何も問題は起きません。自分の画面で見えているものと、相手の画面に出るものが違っていました。
Googleの公式ヘルプにも、この表示が出る理由として、回答する権限がないことと、権限のないアカウントでログインしていることが挙げられています。そして開けるかどうかは、フォームを作った側の共有設定で決まると書かれています。
ここで区別しておきたいものが2つあります。フォームが公開されているかどうかと、その人が回答できるかどうかは、別の設定です。 公開されていても、回答できる範囲が絞られていれば、範囲の外にいる人は開けません。
この区別は、後から確かめて初めて分かりました。当時の筆者は原因を「スクリプトで作ったフォームは公開されていないからだ」と理解して、手順書にもそう書き残しています。対処の手順そのものは正しく残せたのですが、理由の説明が間違っていました。
Class Form の setPublished の項には、こう書かれています。
フォームが公開されているかどうかを設定します。新しいフォームのデフォルトは true です。
新しく作られたフォームは、既定で公開されています。つまり「スクリプトで作ったから公開されていなかった」という当時の理解は、仕様と食い違っていました。直った原因は、公開状態ではなく回答できる範囲のほうだったわけです。
直った瞬間に安心して、なぜ直ったのかを確かめなかった。手順は残せても、理由を取り違えたまま残すと、次に別の症状が出たときに手順が効きません。
もう1点。公開状態をスクリプトから操作する setPublished() と、状態を調べる isPublished() は、公式には公開に対応したフォームでのみ使えます。対応しているかどうかは supportsAdvancedResponderPermissions() で確認する、と同じページに書かれています。すべてのフォームで無条件に動くものではありません。
実務の教訓としては、こうなります。作ったら、自分ではないアカウントで一度開いてみる。 ログインしていないブラウザで回答URLを開いて、設問が表示されるかを見る。それだけで、当日の慌ただしさは避けられました。
直すのがスクリプトだと、設定が1か所にまとまる
失敗の話が続いたので、良かった点も書きます。
手で作った仕組みを直すときは、手で作ったときと同じ手順をたどり直すことになります。どのメニューだったか、どのチェックボックスだったかを思い出しながら画面を触る。誰かに引き継ぐときは、その手順を文章で書き起こす必要があります。
スクリプトで作ってあると、直すのはスクリプトのほうです。いまどういう設定になっているかが、1つのファイルを読めば分かります。 フォームの設問も、スプレッドシートのタブ構成も、メールの文面も、全部そこにあります。画面をあちこち開いて確かめる必要がありません。
ただし、コードから分かるのは今の状態だけです。いつ何を変えたのか、なぜそうしたのかまでは残りません。そこは別に記録が要ります。
ただし、条件が2つあります。
ひとつは、同じスクリプトを何度実行しても大丈夫な作りになっているかです。実行のたびに新しいフォームやシートが増える、トリガーが二重に登録される、といった作りだと、直すつもりの再実行が事故になります。本番のものを触る前に、テスト用のアカウントかコピーで試してください。
もうひとつは、コードだけでは引き継げないものがあることです。誰のアカウントで動いているか、どの権限を許可したか、フォーム送信をきっかけに動く仕掛けがどこに登録されているか。この手のものはコードを読んでも分かりません。数行でいいので、運用のメモを別に残しておく必要があります。
数字の制約もひとつ。GASからのメール送信には上限があって、公式の一覧によると、一般のGoogleアカウントで1日100受信者、Google Workspaceのアカウントで1日1,500受信者です。通数ではなく受信者数で数えるので、申込者と運営者に1通ずつ送る構成なら、申込1件で2受信者分を使います。上限はアカウント単位で、最初のリクエストから24時間でリセットされます。数百人へ一斉に送る用途だと、個人アカウントでは足りません。
なお、この構成でGoogle側に別途かかる費用はありませんが、Workspaceを契約していればその料金はかかりますし、AIツールの利用料も当然別です。「全部タダでできる」ではありません。
決めたパターンを繰り返す確認は、任せやすい
作ったあとの確認は、ブラウザごとAIに渡しました。Claude in Chromeを使うと、AIが実際にブラウザを操作できます。
フォームを開いて、条件に合わない回答を入れて、別ページに飛ぶか。本申込まで進んだときに、スプレッドシートの正しい列に値が入るか。パターンが何通りもあって、しかも全部やらないと安心できない類の作業です。人がやると、3パターン目あたりから雑になります。
今回に限って言えば、決めたパターンを順番に繰り返す作業は任せやすいという感触でした。ただし、何を確認すべきかを決めるのは人の側です。テストの項目そのものをAIに考えさせて、それで確認した気になるのは別の話になります。
渡すときの注意も1つ。ブラウザを操作させるということは、その画面に映っているものをAIが読むということです。本番の申込者データが並んだ管理表を開いたまま渡すのは避けてください。筆者は架空の名前とテスト用のアドレスで通しました。お金が動く決済まわりの確認は、自分の目でやっています。
さいごに 作れたことと、使える状態になったことは違う
GASは17年前からあって、書ける人はずっと使ってきました。今回変わったのは、コードを書く部分の負担が下がって、書けない人でも使えるようになったことです。技術が新しくなったわけではありません。
同じことは、ほかにもありそうです。長く存在してきたのに、書ける人が社内にいないという理由だけで手つかずだった仕組み。心当たりがあれば、一度頼んでみる価値はあります。
そのうえで、公開する前に見るところを4つだけ挙げておきます。今回つまずいた場所から出てきたものです。
- 自分ではないアカウントで開く。 ログインしていないブラウザで、回答URLが実際に開けるか
- 誰が回答できる状態か。 公開されているか、回答権限の範囲はどうなっているか
- もう一度実行しても壊れないか。 二重に作られるものがないか
- 送信の残り枠。 想定件数がメール送信の上限に収まるか
作れたことと、使える状態になったことは違います。しかもその差は、作った本人の画面には映りません。作り終わったら、自分ではない誰かの立場で、一度だけ触ってみてください。