Googleフォームでは難しい注文受付をGAS＋スプレッドシートで構築した開発対応事例

この記事は、公開アプリや配布ツールの紹介ではなく、開発請負で対応した開発対応事例です。顧客名、実データ、商品名、価格、数量、案件固有の運用情報は出さず、同じような業務で応用しやすい形に一般化して整理しています。

小規模な直販や季節商品の注文受付では、最初はGoogleフォームで十分に見えることがあります。ただ、送料、合計金額、受付上限、確認画面、メール通知まで入ってくると、単純なフォームだけでは対応しづらくなります。

今回は、農産物の直販向け注文受付を題材に、Google Apps ScriptとGoogleスプレッドシートを使って、注文画面、管理表、通知メールをつなぐWebアプリとして構築した事例を紹介します。

GASとGoogleスプレッドシートで注文受付システムを構築する流れの概要図 — Googleフォームでは難しい送料計算、確認画面、受注管理、メール通知をGAS Webアプリとスプレッドシートでつなぐ構成イメージです。

ご相談内容

相談内容は、季節商品の注文をWeb上で受け付けたいというものでした。

単に名前、住所、商品、数量を送ってもらうだけなら、Googleフォームでも始められます。しかし、実際の受注販売では、次のような条件が絡みます。

商品ごとに価格や注文単位が異なる
地域や配送条件によって送料が変わる
注文内容を確認してから送信してもらいたい
受付上限や受付締切を管理したい
受付メールや発送通知メールを送りたい
管理者側で商品、送料、メール文面を変更したい

このような場合、回答を集めるだけのフォームではなく、スプレッドシートの設定値を読み込みながら画面を動かす構成が向いています。

Googleフォームだけでは難しい点

Googleフォームは、固定項目の回答を集める用途には非常に便利です。

一方で、注文受付のように「入力内容に応じて計算する」「管理表の値で選択肢を変える」「送信前に確認画面を出す」といった要件が増えると、標準機能だけでは限界が出ます。

今回のような受注販売では、特に次の点が課題になります。

必要な処理	Googleフォームだけの場合	GAS Webアプリの場合
商品マスタの読み込み	手作業で選択肢を更新しやすい	スプレッドシートから読み込める
送料計算	標準機能では難しい	地域・数量・条件で計算できる
合計金額表示	送信前の動的表示が難しい	画面上で即時に表示できる
確認画面	標準の確認では細かい制御が難しい	業務専用の確認画面を作れる
受付上限・締切	手動管理になりやすい	スプレッドシート側の設定で制御できる
メール文面	固定的になりやすい	用途別に文面を組み立てられる

つまり、スプレッドシートを「回答の保存先」として使うだけならGoogleフォームで十分です。スプレッドシートを「画面や処理を動かす設定データ」として使うなら、GAS Webアプリの方が設計しやすくなります。

採用した構成

構成は、注文画面、HTML Serviceで作るGAS Webアプリ、Googleスプレッドシートの管理表を組み合わせた形です。

注文者はスマートフォンやPCから注文画面を開きます。画面側では、商品一覧や送料条件を読み込み、数量や配送先に応じて合計金額を表示します。送信前には確認画面を出し、内容を確認してから注文を登録します。

管理者側は、スプレッドシートで次のような情報を管理します。

商品名、価格、受付可否
送料表や配送条件
受付締切、受注上限
受付メール、発送通知メールの文面
注文一覧、発送管理、CSV出力用データ

専用のデータベースを最初から用意せず、管理者が普段触りやすいスプレッドシートを管理画面の代わりに使う構成です。

注文フォームの流れ

注文画面では、注文者が商品と数量を選び、氏名、連絡先、配送先などを入力します。

画面上では、入力内容に応じて小計、送料、合計金額を表示します。注文前に金額が見えるため、注文者側も管理者側も認識ズレを減らしやすくなります。

送信前には確認画面を挟みます。入力フォームから直接登録するのではなく、注文内容、配送先、合計金額を確認してから登録することで、送信後の修正依頼を減らします。

登録後は、スプレッドシートへ注文データを保存し、必要に応じて受付メールを送信します。後続処理として、発送通知メールや配送システム連携用CSVの出力にもつなげられる構成にしています。

スプレッドシートで管理できるようにした理由

小規模な受注販売では、商品、価格、送料、受付期間が毎回同じとは限りません。

これらをコードに直接書いてしまうと、内容を変えるたびに開発者が修正する必要があります。そこで、変更されやすい値はスプレッドシート側で管理できるようにしました。

スプレッドシートで管理する形にしておくと、管理者が商品や文面を直しやすくなります。運用しながら少しずつ設定を調整できるため、小さく始める業務アプリと相性がよいです。

一方で、スプレッドシートは本格的なデータベースではありません。大量アクセス、高度な権限管理、複雑な検索、厳密な監査ログが必要な場合は、別のDBや業務システムを検討する必要があります。

技術的に意識した点

GAS Webアプリでは、画面側からサーバー側の処理を呼ぶときにgoogle.script.runを使います。

注文登録や商品マスタ取得では、通信中の表示、成功時の画面更新、失敗時のエラーメッセージを分けて扱う必要があります。ここを共通化しておくと、注文画面、確認画面、管理処理が増えても実装を保ちやすくなります。

また、同時に注文が入る可能性がある処理では、LockServiceのような排他制御も検討します。受注上限や受付番号のように、複数人が同時に触るとずれやすい処理は、単純な書き込みだけで済ませない方が安全です。

商品マスタや送料表の読み込みは、必要に応じてCacheServiceを使うと軽くできます。毎回スプレッドシートを読み込むと表示が遅くなるため、頻繁に変わらない設定値はキャッシュする判断も有効です。

向いている業務

この構成は、次のような業務に向いています。

農産物、食品、季節商品の注文受付
既存顧客向けの注文フォーム
少量多品目の商品受付
地域や数量で送料が変わる注文
予約、申込、現場依頼などの受付管理
管理者はスプレッドシートで確認したい業務

フル機能のECサイトを作るほどではないが、Googleフォームだけでは足りない。この中間にある業務に向いています。

開発依頼につなげる場合の整理ポイント

同じような注文受付システムを作る場合は、最初に次の情報を整理すると進めやすくなります。

受付したい商品やサービスの種類
価格、数量、送料、割引などの計算ルール
注文者へ見せたい確認内容
管理者が変更したい項目
受付メール、発送通知メールなどの文面
受注上限、締切、受付停止の条件
出力したい一覧やCSVの形式

これらが整理できていると、Googleフォームで十分か、GAS Webアプリにした方がよいかを判断しやすくなります。

まとめ

注文受付は、一見するとフォームを作るだけに見えます。しかし、送料、合計金額、確認画面、受付上限、メール通知まで入ってくると、業務ルールを画面に反映する設計が必要になります。

GASとGoogleスプレッドシートを組み合わせると、管理者がスプレッドシートで商品や設定を管理しながら、注文者には専用の入力画面を見せる構成を作れます。

Googleフォームで足りない部分を、いきなり大規模なECシステムにせず、小さなWebアプリとして補う。小規模な直販、季節商品の注文受付、既存顧客向けの申込管理では、この考え方が使いやすい選択肢になります。