JotformのWebhookでBigQueryに自動蓄積。問い合わせを1件も取りこぼさない設計

問い合わせフォームや申込フォームから、毎日お客様の情報が入ってくる。でも、そのデータは送信通知メールの中に埋もれたまま、誰も見返さない。気づけば「先月の問い合わせって何件だった？」「どの広告から来た人だっけ？」に即答できない。そんな状態になっていないでしょうか。

フォームのデータは、本来は会社の資産です。広告がどれだけ効いたか、どの経路の問い合わせが成約につながりやすいか、月ごとにどう増減しているか。これらはすべてフォームの送信データが起点になります。ところが多くの会社で、そのデータは通知メールとフォーム提供ツールの管理画面に散らばったまま、分析できる形になっていません。

この記事では、Jotform（＝プログラミングなしで問い合わせ・申込フォームを作れるサービス）を例に、フォーム送信データを自動で1か所に集めて、分析に使える状態で蓄積する仕組みを紹介します。技術的な作り方も触れますが、主に知りたいのは「自社でやるべきか外注すべきか」「いくらかかるか」「データを取りこぼさないために何が必要か」のはずです。そこを判断できるところまで書きます。

この種の仕組みで一番こわいのは、コストではありません。一度取りこぼしたデータは、二度と戻ってこないことです。だからこの記事の判断軸は、安さではなく「データ欠損のリスクと、止まったとき誰が直すのか」に置きます。

結論：フォーム送信を「受け取り・取り直し・重複なく溜める」の3部品で組む

フォームデータの蓄積は、次の3つの部品を組み合わせて作ります。

この型の心臓部は、③の「重複させずに溜める」です。理由は次のとおりです。

Webhookは、フォーム送信の瞬間に1回だけ通知が飛んでくる仕組みです。便利な反面、その瞬間に受け取り側が落ちていると、その通知は自動では再送されません。気づかなければ1件が欠損したままになります。これを前提に、「取りこぼしても後から安全に拾い直せる」設計にしておくのがこの仕組みの肝です。重複なく溜める作りにしておけば、後から手作業で1件を入れ直しても、すでに入っていたデータを壊しません。

「絶対に取りこぼさない仕組み」は、外部サービスに依存する以上、作れません。狙うべきは「取りこぼしても安全に復旧できる仕組み」です。

ビフォーアフター：何が変わるか

ポイントは2行目と3行目です。広告の費用対効果を見たいとき、フォームデータが分析できる形で1か所にあるかどうかで、判断のスピードがまるで変わってくる。問い合わせのデータをクリックや広告と突き合わせる土台については、広告クリックから問い合わせ・成約までを計測するパイプラインの設計で詳しく触れています。フォームデータの蓄積は、その計測の入り口にあたります。

全体構成と、実際に流れるデータ

流れはこうなります。

[フォームが送信される]
        ↓ Webhook（送信の瞬間に通知が飛ぶ。共有シークレットで本物か検証）
[受付役：Cloud Run]
        ↓ ① 送信ID（submission_id）だけ受け取る
        ↓ ② そのIDを使い、JotformのAPIから正規のデータを取り直す
        ↓ ③ データベース用の形に整える
        ↓ ④ 送信IDをキーに、重複なく書き込む（MERGE）
[蓄積役：BigQuery]

ここで一つ、見落とされがちな設計判断があります。Webhookで飛んでくる通知には、フォームの中身がある程度含まれています。それをそのまま溜めたくなりますが、通知の中身は形式が安定しないことがあるため、ID（送信を識別する番号）だけ受け取り、正規のデータは改めてAPIから取り直すほうが堅牢。少し遠回りに見えて、この「取り直し」がデータの正確さを支えます。

実際にどんなデータが溜まるかのイメージです。以下は個人情報を伏せ、内容をダミーに置き換えた例です（実データではありません）。

フォームから送られてくる生の情報:

送信ID：sub_000123
日時：2026-05-20 10:42
氏名：（マスク）
連絡先：（マスク）
問い合わせ種別：料金について
流入経路パラメータ：ad_a / spring-campaign

これがBigQueryに溜まると、こういう形で集計できるようになります:

2026-05 月間 問い合わせ：◯◯件（ダミー）
　うち「料金について」：全体の約3割
　うち広告経由（流入経路パラメータあり）：約4割
　→ 広告経由の問い合わせは「料金」起点が多い、といった分析が可能に

通知メールを目で数えていた頃には見えなかった傾向が、溜めるだけで見えるようになります。何を溜めるか・どの軸で見たいかを最初に決めておくと、後の分析がぶれません。

どの方式で作るか：データ欠損リスクと保守責任で比べる

フォームデータを溜める方法は一つではありません。ここで方式を「安さ」で並べると判断を誤ります。フォームデータは1件の欠損が顧客機会の損失に直結するので、データ欠損のリスクと、止まったとき誰が直すのかを軸に並べます。

今回サーバーレス自作を選んだ理由は、安さではありません。「1件も落とせないデータを、止まっても安全に拾い直せる形で溜めたい」という条件に、最も素直に応えられるからです。重複しない書き込み・自動リトライ・取りこぼし監視という、欠損対策を自分の設計として組み込めます。ノーコードSaaSでも作れますが、その場合は「連携が止まったらどう気づくか」を別途自分で設計しないと、静かに欠損が積み上がります。

いくらかかるか：運用費だけで判断しない

コストは4つに分けて見てください。一番見落とされるのが「障害対応」、つまり止まったとき誰が直すのかです。

運用コスト自体は小さく収まります。送信のたびに数秒〜十数秒だけ動く処理なので、サーバーを24時間立てる必要がなく、無料枠の範囲に収まることが多いです。

ただし、フォームデータの場合、安さは判断の主役になりません。主役は障害対応です。Webhookは取りこぼした通知が自動では再送されないため、止まったときに「誰が・どれだけ早く気づいて・どう直すか」が決まっていないと、安く動いていても損失が静かに積み上がります。

外注する場合の見積もりも、この「初期構築の作業量＋欠損対策（重複なし書き込み・リトライ・監視）の設計」が基準になります。具体的な費用は要件（フォームの種類・項目数・個人情報の有無・既存基盤との接続）で変わるため、相場で語るより作業量と「欠損対策をどこまで作り込むか」で見積もるほうが実態に合います。

自社でやるべきか、外注すべきか

「安いなら自社で」と即決する前に、次の3点で判断してください。安さより、止まったときの責任の所在が論点です。

特に1つ目が重要です。この仕組みは普段は静かに動きますが、外部サービスの仕様変更や権限切れで突然止まることがあります。止まったことに気づけて、ログをたどって原因を特定し、取りこぼした分を安全に拾い直せる人が社内にいるか。いなければ、その役割ごと外注したほうが安全です。

こんなケースは無理に作らないほうがいい

正直に、向かないケースも挙げておきます。

• 問い合わせが月に数件しかない：手で管理画面を見るほうが速い。仕組みを作る手間が浮く工数を上回ります
• 分析する予定が当面ない：溜めるだけで活用しないなら、ツール標準のエクスポートで十分です
• フォーム項目が頻繁に変わる：項目が変わるたびに改修が要るため、まず項目を固めてから作るほうが安く済みます

「フォーム経由のデータを、広告や顧客分析の土台として継続して使いたい」という会社ほど、この仕組みの費用対効果が高くなります。

つまずきポイント：実際にここで止まった

実際に作って運用すると、決まったところで詰まります。自社で挑戦する方の予習にも、外注先への確認項目にも使えます。

つまずき1：認証キーを交換したのに、古いキーが使われ続ける

JotformのAPIキー（＝外部サービスにアクセスするための合鍵）は、安全のため専用の保管庫に入れて使います。ここで罠なのが、キーを新しいものに交換しても、動いている仕組みの側が古いキーを覚えたまま動き続けることがある点です。処理を速くするために一度読んだキーを記憶しておく作りが一般的で、その記憶は仕組みを再起動するまで消えません。

キーを交換したら、仕組みの再起動（＝新しい設定での入れ直し）までがワンセット。これを知らないと「キーを替えたのに、なぜか古いキーで動いている」という不可解な状態に悩まされます。外注するなら「認証キーの交換手順はどうなりますか」と確認しておくと安心です。

つまずき2：データの保管場所（リージョン）指定を忘れて「データが無い」と誤診する

BigQueryのデータは、どの地域のデータセンター（リージョン＝データを置く場所）に保管するかが決まっています。取りこぼしが起きていないか確認しようとしたとき、この場所の指定を省くと「そんなデータは見つからない」という返事が来ます。データは無事にあるのに、違う場所を探していただけなのです。

障害かと焦って調べたら場所の指定漏れだった、というのは定番のつまずきです。データが消えたように見えても、まず「正しい場所を見ているか」を疑う。これだけで無駄な調査を1時間減らせます。

つまずき3：止まったとき「気づける」設計を最初に入れる

ある案件で、運用中にデータの取り込みが1件止まったことがありました。気づいたのは、事前に「取り込みが失敗したら通知する」監視を入れておいたからです。逆に言えば、監視がなければ静かに1件欠けたまま、誰も気づきませんでした。

調査の流れはこうでした。まずクラウドのログから、いつ・どの送信で失敗したかを特定します。次にそのIDで手動でAPIを叩いてみると、正常にデータが取れる。データそのものは正規のものでした。原因は、Jotform側がその瞬間だけ一時的なエラー（502などのサーバー側エラー）を返しただけ、という稀な事象でした。コードもツールも、どこも壊れていなかったのです。

確認後、重複なし書き込み（MERGE）の設計だったおかげで、止まった1件をローカルから安全に入れ直せました。すでに入っていたデータと重複する心配がないので、「もう入っているかも」という不安なく回収できます。これが、最初に「重複なく溜める」設計にしておく価値です。

つまずき4：一時的な失敗は自動で拾い直す

1件の手動回収で済んだとはいえ、外部サービスの瞬間的なエラーを毎回手で拾うのは続きません。そこで、一時的なエラーなら数秒待って自動で再試行する仕組み（リトライ）を入れました。ポイントは、何でも再試行しないことです。

「時間を置けば直る可能性があるもの」だけを再試行対象にする。この切り分けを入れたことで、瞬間的な障害は自動で拾い直され、手動回収がほぼ不要になりました。

導入前チェックリスト

着手する前に、次を整理しておくと設計がぶれません。自社で作る場合も、外注で相見積もりを取る場合も、この5つが揃っていると話が早く進みます。

• どのフォームのデータを溜めるか（問い合わせ／申込／資料請求 など）
• 何の分析に使うか（広告効果測定／問い合わせ種別の傾向／月次件数 など）→ 溜める項目が決まる
• 個人情報が含まれるか（含むなら、保護とアクセス制限の設計が必須）
• 1件の欠損をどこまで許せるか（広告効果測定なら許せない → 監視と復旧設計を厚くする）
• 止まったとき誰が気づいて直すか（社内に担当を置くか、保守ごと外注するか）

最後の2つが、この仕組みの設計の厚みと、自社か外注かの判断をほぼ決めます。

まとめ：「取りこぼさない」より「安全に拾い直せる」を設計する

フォームデータの蓄積で大事なのは、派手な機能ではありません。

1. 受け取り・取り直し・重複なく溜めるの3部品で組む
2. 主役の論点は安さではなく、データ欠損リスクと、止まったとき誰が直すか
3. Webhookは取りこぼしても自動では再送されない前提で、重複なし書き込み・自動リトライ・取りこぼし監視をセットで入れる
4. 運用費は小さいが、判断は初期構築・保守・障害対応を分けた総コストで見る

補足のハマりどころをひとつ。この構成で溜めたデータの送信時刻が、後から9時間ずれていると発覚したことがあります。フォーム側の日本時間がそのままUTC（世界標準時）としてBigQueryに格納されていたのが原因でした。単独で使っている分には気づきませんが、アクセスログ等と時刻で突き合わせた瞬間に一致率が激減して発覚します（このときは突合の一致率が2割台まで落ち、時間窓を広げて9割台に回復しました）。Webhookで時刻を保存するときは、タイムゾーンを明示してUTCに正規化してから書き込む。地味ですが、後の分析の成否を分けます。

外部サービスに依存する以上、「絶対に取りこぼさない」は作れません。だからこそ「取りこぼしても安全に拾い直せる」設計にしておく。フォームのデータのような、1件も落とせない会社の資産を扱うときの基本です。

フォームのデータを資産にしたい方へ

「フォームには毎日問い合わせが来ているのに、分析できる形になっていない」「広告がどれだけ効いたか、フォームのデータから追えていない」。そう感じている会社は少なくありません。ただ、フォームデータを溜める仕組みは、作って終わりではなく「止まったときに気づいて拾い直せるか」で価値が決まります。

f2t.jpでは、こうしたフォーム連携・データ基盤の設計から、データ欠損対策（重複なし書き込み・自動リトライ・監視）と個人情報保護を含む堅牢化、運用の引き継ぎまで一貫してお手伝いしています。まずは「どのフォームを・何の分析に使い・個人情報をどう守り・止まったとき誰が直すか」を一緒に整理するところから始められます。お問い合わせフォームから、自社のフォームデータの活用についてご相談ください。