Googleフォームの予約をカレンダーに自動で入れる方法

Googleフォームで予約を受けていると、次に必ず出てくるのが「カレンダーに手で書き写すのをやめたい」という話です。 回答のスプレッドシートを見ながら、1件ずつGoogleカレンダーに予定を入れる作業は、件数が増えるほど重くなります。

この記事では、フォームで受けた予約をカレンダーに自動で入れる方法を3つに分けて示します。 Apps Scriptで自分で組む形、外部の連携サービスを使う形、予約の受付そのものをカレンダー側に寄せる形です。 そのうえで、自動化しても解決しないことが1つ残ることを説明します。 それは二重予約です。 そこまで読んでから、自分の件数なら自分で組むべきか、予約に特化した仕組みに任せるべきかを決められる状態を目指します。

フォームとカレンダーはそのままでは繋がらない

先に前提を押さえます。 Googleフォームのヘルプには、回答をGoogleスプレッドシートに保存する設定は案内されていますが、回答をGoogleカレンダーの予定として登録する設定は案内されていません。 つまり、フォームで受けた予約をカレンダーに入れるには、間に何かを1つ挟む必要があります。

この「間に挟むもの」が、Apps Scriptか、外部の連携サービスです。 どちらを選んでも、やっていることは同じです。 フォームが送信された瞬間を捉えて、その回答から日時を取り出して、カレンダーの予定を作る、という3つの動きをつなげます。

この組み合わせを検討する人が多いことは、次の説明にも表れています。

GoogleフォームやGoogleカレンダーは、手軽に利用できる便利なツールです。このツールを連携させて、予約システムを作成することはできるのでしょうか？ 出典: rsvia.co.jp

結論を先に書くと、繋げることはできます。 ただし繋げたあとに残る課題があり、そこを知らずに作ると1か月後にやり直すことになります。

自動で入れる3つの方法

1つ目は、Apps Scriptで自分で組む方法です。 Googleが提供している仕組みなので追加の費用はかからず、自由に書けます。 そのかわり、書くのも直すのも自分の仕事になります。

2つ目は、外部の連携サービスを使う方法です。 フォームの送信を引き金にして、カレンダーの予定を作る流れを画面上で組み立てます。 コードを書かずに済みますが、多くは月額の費用がかかります。

3つ目は、予約の受付そのものをカレンダー側に寄せる方法です。 Googleカレンダーの予約スケジュールを使えば、予約が入った時点でカレンダーに予定が入ります。 繋げる作業が要らなくなるかわりに、フォームで聞いていた細かい項目を諦めるか、別に聞くことになります。

どれを選ぶかは、月の件数と、自分で保守できるかどうかで決まります。 以下で順に見ていきます。

Apps Scriptで組む手順の全体像

Apps Scriptで組む場合の流れは4段です。

1段目は、フォームの回答を受けるスプレッドシートを用意することです。 フォームの回答画面から回答の送信先をスプレッドシートに指定します。

2段目は、そのスプレッドシートから拡張機能のApps Scriptを開き、予定を作る関数を書くことです。 関数の中でやることは3つです。 送信された回答から日付と時刻を取り出す、そこから開始時刻と終了時刻を組み立てる、カレンダーに予定を作る、の3つです。

3段目は、フォーム送信時に動くトリガーを設定することです。 Apps Scriptの画面からトリガーを追加し、イベントの種類にフォーム送信時を選びます。

4段目は、権限を許可することです。 初回の実行で、カレンダーへのアクセスを許可する画面が出ます。

書くコードは短いもので足ります。

function onFormSubmit(e) {
  const v = e.namedValues;
  const start = new Date(v['希望日'][0] + ' ' + v['希望時刻'][0]);
  const end = new Date(start.getTime() + 60 * 60 * 1000);
  CalendarApp.getDefaultCalendar().createEvent(
    v['お名前'][0] + ' ' + v['メニュー'][0], start, end,
    { description: v['ご連絡先'][0] }
  );
}

要点は、日付と時刻を別々の質問にしておくことです。 1つの自由記述で「10月5日の14時ごろ」と受け取ると、日時として扱えません。 選択式で日付と時刻を分けて聞いておけば、そのまま組み立てられます。

組むときにつまずく5つの点

実際に組むと、次の順でつまずきます。

第1に、日時が文字列のままであることです。 スプレッドシートに入った値は文字列なので、日時として扱える形に変換する必要があります。 和暦や「14時」のような表記が混ざると、変換に失敗して予定が作られません。 選択肢を「14:00」の形で統一しておくのが確実です。

第2に、タイムゾーンです。 スクリプトのタイムゾーンが日本になっていないと、作られた予定が9時間ずれます。 Apps Scriptのプロジェクトの設定で、タイムゾーンを確かめてください。

第3に、トリガーの選び方です。 フォーム送信時のトリガーには、フォーム側に付けるものとスプレッドシート側に付けるものがあり、受け取れる値が違います。 スプレッドシート側に付けた場合は行の値として受け取り、フォーム側に付けた場合は回答そのものとして受け取ります。 参考にした記事とコードの前提が違うと、値が取れずに止まります。

第4に、実行するアカウントです。 Googleの公式ドキュメントには、インストール可能なトリガーは常に作成者のアカウントで実行されると書かれています。 つまり、スタッフの誰かが作ったスクリプトは、その人のアカウントで動きます。 その人が退職してアカウントを閉じると、予約が静かにカレンダーへ入らなくなります。 店として使うなら、店のアカウントで作るのが安全です。

第5に、失敗したときに気づけないことです。 トリガーが失敗するとエラーの通知メールが届きますが、迷惑メールに入ることがあります。 予約が入っているのにカレンダーに無い、という状態は最悪の事故です。 週に1度、スプレッドシートの件数とカレンダーの件数を突き合わせる確認を入れておくべきです。

割り当て上限を知っておく

Apps Scriptには、1日あたりの割り当てがあります。 公式に公開されている数字を確かめておきます。

カレンダーの予定の作成は、一般ユーザー向けアカウントで1日5,000件、Google Workspaceアカウントで1日10,000件です。 予約の件数でこの上限に当たることはまずありません。

気にすべきなのはメールのほうです。 MailAppなどで送るメールの1日あたりの受信者数は、一般ユーザー向けアカウントで1日100人、Workspaceアカウントで1日1,500人です。 予約の確認メールとリマインダーをスクリプトから送る作りにすると、この上限が先に効いてきます。

トリガーの合計実行時間も上限があります。 一般ユーザー向けアカウントで1日90分、Workspaceアカウントで1日6時間です。 1回のスクリプトの実行時間は6分までで、トリガーはユーザーあたりスクリプトあたり20個までです。

割り当てについては、次のように明記されています。

Google Apps Script サービスには、1 日の割り当てと一部の機能の制限があります。割り当てまたは制限を超えると、スクリプトで例外がスローされ、実行が停止します。 出典: developers.google.com

上限を超えると止まるという点が重要です。 止まったことに気づかないと、予約がカレンダーに入らない日が続きます。

作られる予定に何を書かせるか

自動でカレンダーに入れる場合、予定の中身を先に設計しておくと後が楽になります。 現場で使いやすいのは次の形です。

予定のタイトルには、お名前とメニューを入れます。 「山田様／カット＋カラー」のように、カレンダーの月表示でも判別できる短さにします。 連絡先や要望をタイトルに入れると、月表示で読めなくなるので入れません。

予定の説明には、連絡先、初回か再訪か、要望、フォームの回答へのリンクを入れます。 当日にスマホでカレンダーを開いたときに、必要な情報がその画面で揃う状態を目指します。

予定の色を使い分けるのも効きます。 初回のお客さまだけ色を変えると、準備が必要な予約が月表示で目に入ります。

終了時刻の決め方には注意が要ります。 メニューによって所要時間が違う場合、メニューの選択肢ごとに時間を割り当てる処理を入れないと、すべて同じ長さの予定になります。 所要時間が実際と違う予定がカレンダーに並ぶと、次の予約を受けるときの判断を誤ります。

片付けや移動の時間も、予定に含めるか別に取るかを決めておきます。 施術60分に片付け10分が必要なら、予定を70分で作るのが単純です。 別の予定として入れる形にすると、カレンダーが予定で埋まって読みにくくなります。

変更とキャンセルはどう扱うか

自動化でいちばん抜けやすいのが、ここです。

お客さまが予約を変更したい場合、フォームには変更の窓口がありません。 電話かメールで連絡をもらい、こちらでカレンダーの予定を直すことになります。 自動で入れる仕組みだけを作って、変更を手で直す運用にすると、入れた予定と実際の予約が食い違っていきます。

変更まで自動にするなら、次のものを作ることになります。 変更とキャンセルを受ける別のフォーム、予約を特定するための番号、その番号でカレンダーの予定を検索して書き換えるか削除する処理です。 予約の番号をお客さまに伝える必要があるため、確定の連絡も自動で送る作りにしないと成り立ちません。

ここまで作ると、作っているものは予約システムそのものです。 そして、作ったものは自分しか直せません。 予約という止められない業務を、自分1人しか触れない作りに預けることになります。

現実的な落としどころは2つです。 1つは、変更とキャンセルは電話とメールで受けると割り切ることです。 月の件数が少なければ、これで回ります。 もう1つは、お客さま自身が変更と取り消しをできるURLが発行される仕組みに移ることです。 空いた枠がその場で次の人に開くので、取りこぼしも減ります。

どちらを選ぶかは、月のキャンセルと変更の件数で決まります。 月に5件を超えるなら、電話とメールで受ける運用は負担として効いてきます。

連携を作る前に決めておくこと

作り始める前に、次の4つを決めておくと手戻りが減ります。

1つ目は、どのカレンダーに入れるかです。 自分の予定と同じカレンダーに入れると、予約と私用の予定が混ざります。 店の予約用のカレンダーを1つ作って、そこに入れる形にします。

2つ目は、誰のアカウントで作るかです。 インストール可能なトリガーは作成者のアカウントで動くため、店のアカウントで作るのが安全です。 個人のアカウントで作ると、その人が離れたときに止まります。

3つ目は、フォームの項目を固定することです。 スクリプトは質問の文言で値を取り出すため、質問名を変えると動かなくなります。 質問の文言を変えるときは、スクリプトも直すという決めごとを作ります。

4つ目は、確認の手順です。 週に1度、回答の件数とカレンダーの予定の件数を突き合わせます。 数が合わない週があれば、その週のどこで止まったかを調べます。

業種ごとに連携が必要かを考える

自動化が効く仕事と、効かない仕事があります。

効くのは、申し込みを受けてから日程が決まる仕事です。 撮影、出張の見積り、訪問の相談などは、申し込みの内容をカレンダーに残せれば十分です。 在庫の管理が要らないので、フォームとカレンダーの組み合わせで足ります。

効くのは、単発の講座やワークショップもそうです。 開催日が決まっていて定員を数えるだけなら、フォームの回答数の上限で締め切り、開催日の予定は最初から自分でカレンダーに入れておけば済みます。 そもそも連携しなくても回る形です。

効かないのは、時間枠ごとに空きを管理する仕事です。 サロン、整体、教室の個別レッスンのように、1日に複数の枠があって1枠に1人が入る形では、自動化しても二重予約が残ります。 ここは在庫を持つ仕組みが必要です。

効かないのは、スタッフが複数いる仕事もそうです。 誰の枠に入れるかという判断をスクリプトに書くと、シフトが変わるたびに手が入ります。 業種ごとに必要な受け方の違いは業種ごとの使い方に整理されているので、自分の仕事に近い形を見てから、組むか任せるかを決めると外しません。

外部の連携サービスを使う方法

コードを書きたくない場合は、サービス同士を繋ぐ外部のサービスを使う道があります。 フォームの送信を引き金にして、カレンダーの予定を作る流れを画面の操作だけで組み立てられます。

この形の利点は3つあります。 書き換えの作業が要らないこと、失敗したときに画面で履歴を確認できること、カレンダー以外にも通知を流せることです。 予約が入ったらチャットに流す、台帳にも書く、といった枝を足しやすい構造です。

弱点も3つあります。 1つ目は費用です。 無料の枠がある場合も、月あたりの実行回数に制限があり、予約の件数が増えると有料の段に入ります。 2つ目は、間に1社増えることです。 お客さまの名前と連絡先が、フォームとカレンダーのほかにその会社を通ることになります。 どこまでのデータが渡るかを、繋ぐ前に確かめる必要があります。 3つ目は、動くまでに時間差が出る場合があることです。 数分の遅れは実務では問題になりませんが、直前の予約を受ける仕事では気になることがあります。

費用の面では、計算しておく価値があります。 連携サービスの月額と、予約に特化した仕組みの月額を並べると、後者のほうが安いことは珍しくありません。 どの機能がどのプランに入るかは料金の表で、予約件数とスタッフ数の上限とあわせて確かめられます。

自動化しても二重予約は防げない

ここが、この記事でいちばん伝えたい点です。

フォームの回答をカレンダーに自動で入れる仕組みを作っても、二重予約は防げません。 理由は、フォームが時間の在庫を持っていないからです。

予約に特化した仕組みは「10月5日14:00の枠は残り0」という在庫を持っていて、1件入ればその枠を候補から消します。 フォームの「10月5日 14:00」という選択肢は、ただの文字列です。 何人がそれを選んだかを判断しないので、2人が選べば2件とも受け付けます。

自動化は、この2件を両方ともカレンダーに入れるだけです。 むしろ、手で書き写していたときには気づけた重なりが、自動化によって見落とされることもあります。

同じことは、キャンセルにも当てはまります。 お客さまが予約を取り消したいとき、フォームには取り消しの窓口がありません。 電話かメールで連絡をもらい、こちらでカレンダーの予定を消すことになります。 取り消しの自動化まで組むなら、取り消し用のフォームを別に作り、予定を検索して削除する処理を書くことになります。 ここまで作ると、作っているものは予約システムそのものです。

自動化で解決するのは、書き写しの手間だけです。 二重予約とキャンセルの受付は、在庫を持つ仕組みでなければ解決しません。 空き枠の自動計算とキャンセルURLが標準で入っているかどうかは、できることの機能一覧で確かめられます。

予約スケジュールに寄せるという選択

繋げるのをやめて、受付の側をカレンダーに寄せる方法もあります。 Googleカレンダーの予約スケジュールなら、予約が入った時点でカレンダーに予定が入るため、間に何も挟む必要がありません。

ただし条件があります。 Googleのヘルプでは、個人のGoogleアカウントとWorkspace Business Starterプランでは予約ページを1つだけ作れると書かれています。 複数の予約スケジュールの作成、リマインダーメールの自動送信、予約に対する支払いの受け付けなどは、対象のプランでのみ使える機能として一覧になっています。 Workspaceの公開料金は、年間プランでStandardが1ユーザーあたり月額1,600円（税別、2026年9月時点）です。

聞ける項目にも差が出ます。 予約フォームの必須項目は名、姓、メールアドレスで、そこに項目を追加していく形です。 フォームで聞いていた持ち物やアレルギー、要望などを足せますが、メニューごとに所要時間を変えることはできません。 1つの予約スケジュールに設定できる予約の長さは1種類です。

また、設定にはパソコンが必要です。 AndroidやiPhone、iPadのカレンダーアプリでは予約スケジュールを作成できないと明記されています。

連携が動いているかを確かめる4つの点

作ったあと、実際に動いているかを確かめる手順を決めておきます。 予約が入っているのにカレンダーに無い状態は、気づくのが遅れるほど損失が大きくなります。

第1に、自分で1件予約を入れてみることです。 公開したフォームから実際に送信して、カレンダーに予定が入るか、開始と終了の時刻が合っているか、説明に連絡先が入っているかを見ます。 テストの予定は、確かめたあとに消します。

第2に、日をまたいだ動きを見ることです。 その場では動いても、翌日以降に止まることがあります。 公開した翌日と翌週に、もう一度1件入れて確かめます。

第3に、件数を突き合わせることです。 週に1度、回答のスプレッドシートの行数と、その週にカレンダーへ入った予定の件数を比べます。 数が合わない週があれば、その週の回答を1件ずつ見て、どの形の入力で止まったのかを調べます。 止まる原因は、たいてい日時の表記のゆれです。

第4に、エラーの通知が届く先を確かめることです。 トリガーが失敗すると通知のメールが届きますが、迷惑メールに振り分けられることがあります。 一度わざとエラーになる状態を作って、通知が自分の受信箱に届くかを見ておくと安心です。

この4つを最初にやっておけば、あとは月に1度の突き合わせで足ります。 逆に、作ったまま確かめないでいると、止まっていることに1か月気づかない事態が起こります。

自分で組むか、任せるかを時間で決める

最後に、判断の基準を時間で置きます。

自分で組む価値があるのは、次の条件に当たるときです。 月の予約が30件までで、書き写しの手間を減らすことだけが目的で、二重予約は折り返しの連絡で調整できている場合です。 この規模なら、スクリプトを一度書けば当分そのまま動きます。

任せたほうが早いのは、次のどれかに当たるときです。 第1に、二重予約が一度でも起きているときです。 自動化では解決しないので、在庫を持つ仕組みが要ります。 第2に、リマインダーを自動で送りたいときです。 スクリプトから送る形にすると、一般のアカウントでは1日100人という上限に当たる可能性が出ます。 第3に、スタッフが2人以上いるときです。 誰の枠に入れるかという判断は、スクリプトでは書けても保守が重くなります。 第4に、作った人以外がその仕組みを直せないときです。 インストール可能なトリガーは作成者のアカウントで動くので、その人が離れると止まります。

時間で換算すると判断が早くなります。 スクリプトを最初に書いて動かすまでに、慣れていない人なら3時間ほどかかります。 そのあとも、フォームの項目を変えるたびにスクリプトを直すことになり、年に何度か手が入ります。 自分の1時間を3,000円で見れば、最初の3時間で9,000円ぶんです。 予約に特化した仕組みの月額がそれを下回るなら、金額でも手間でも任せたほうが得になります。

自分で組んだ仕組みには、もう1つ見えない費用があります。 動いているあいだは気づきませんが、止まったときに予約が消えます。 予約という売上に直結する部分を、自分だけが直せる作りに預けるかどうかは、金額とは別に考える価値があります。 乗り換えを検討する場合は、同じ使い方で各社の金額を並べた他社との比較の形で、件数とスタッフ数の上限を見比べるのが確実です。 料金や契約の細かい条件はよくある質問にまとめられている形の情報を先に読み、フォームの回答をCSVで書き出して顧客として取り込めるかまで確かめてから移ってください。

Q1. GoogleフォームとGoogleカレンダーは標準の機能だけで連携できますか？

Googleフォームのヘルプでは、回答をスプレッドシートに保存する設定は案内されていますが、回答をカレンダーの予定として登録する設定は案内されていません。連携するにはApps Scriptを書くか、外部の連携サービスを挟むことになります。

Q2. Apps Scriptでの連携に費用はかかりますか？

Apps Script自体の利用に追加の費用はかかりません。ただし1日あたりの割り当てがあり、カレンダーの予定の作成は一般アカウントで1日5,000件、トリガーの合計実行時間は1日90分までです。上限を超えると実行が停止します。

Q3. カレンダーに自動で入れれば二重予約は防げますか？

防げません。フォームは時間枠の在庫を持たないため、同じ時間に2人が送信すれば2件とも受け付けられ、自動化はその2件を両方カレンダーに入れます。二重予約を防ぐには、空き枠を自動で計算して埋まった枠を候補から消す仕組みが必要です。

Q4. 連携の仕組みが止まったことに気づく方法はありますか？

トリガーが失敗するとエラーの通知メールが届きますが、迷惑メールに入ることがあります。週に1度、回答のスプレッドシートの件数とカレンダーの予定の件数を突き合わせる確認を入れておくのが確実です。予約があるのにカレンダーに無い状態は、気づくのが遅れるほど損失が大きくなります。