GoogleフォームとNotionを連携する方法｜回答を重複なく受付DBへ送る

すでにWebサイトや案内メールで配布しているGoogleフォームを、Notionで管理したい。そんな場合はフォームを作り直さず、Googleフォームを回答の入口、Notionを受付後の対応場所としてつなげます。

この記事で扱うのは、Googleフォームに届いた回答をNotionへ登録する連携です。Notionでフォーム自体を作る方法は、Notionフォームの作り方で説明しています。

連携方法は、変更する人と運用する人で選ぶ

方法	向いているケース	先に確認すること
自動化サービス	業務担当者が画面で項目を対応付けたい	フォーム回答の検知方法、実行上限、再実行機能
Google Apps Script（GAS）	自社の項目や例外処理に合わせたい	保守担当者、トリガー所有者、失敗時の確認先
回答シート経由	Sheetsで整形・審査した後にNotionへ送る	フォーム回答とシート行の対応が崩れないこと

どの方法でも、「回答が届いたらページを作る」だけでは十分ではありません。質問を追加したときにどの列へ入るか、同じ処理をやり直したらどうなるかまで決めます。

以下では、回答IDを扱いやすいフォーム側のGASトリガーを例にします。自動化サービスを選ぶ場合も、同じ対応表を設定の確認に使えます。

先にNotionの受け皿を用意する

架空の「サービス相談フォーム」なら、最初は次の項目で十分です。

Googleフォーム側	Notion側	扱い
フォームID＋回答ID	外部回答ID／テキスト	同じ回答かを判定するキー
送信日時	受付日時／日付	連携した日時と分ける
会社名	会社名／テキスト	回答をそのまま保持
相談の件名	件名／タイトル	空欄なら回答ID等で仮の件名を付ける
相談内容	ページ本文	長文を扱う場所
メールアドレス	返信先／メール	フォームで収集している場合だけ保存
添付ファイル	元ファイルへのリンク	閲覧権限はDrive側で確認
フォームにない項目	対応状況・担当者	Notionで担当者が更新

Notion側の「対応状況」は、新規登録時だけ「未確認」にします。回答が訂正されたときに、対応中の案件を未確認へ戻さないためです。

API連携用のNotionコネクションを作り、この受付DBへのアクセスを与えます。接続の基本設定はNotionインテグレーションの解説を参照してください。

GASは「フォーム側」と「回答シート側」で受け取る値が違う

Googleの送信イベントには、フォーム側とスプレッドシート側の2種類があります。

トリガーの設置場所	主に受け取るもの	今回の用途
Googleフォーム	e.response	回答ID、各設問の回答を取得
回答先スプレッドシート	e.namedValues、e.values、e.range	追加されたシート行を処理

フォーム側のコードで e.namedValues を使うなど、異なる種類のサンプルを混ぜると動きません。Googleのイベント仕様で、設置する場所と受け取る値を合わせます。Google公式：イベントオブジェクト

設定は次の順で進めます。

1. 対象フォームに紐づくApps Scriptプロジェクトを開く。
2. 送信を受ける関数を用意し、フォームのインストール型「フォーム送信時」トリガーを設定する。
3. トリガーを作るアカウントで必要な権限を認可する。
4. テスト用の回答をフォーム画面から実際に送信する。
5. 実行履歴で回答IDとNotionのページIDを確認する。

関数名を onFormSubmit にするだけで、必要なトリガー設定まで済むわけではありません。また、インストール型トリガーは作成者の権限で動きます。個人の異動・退職時に接続が止まらないよう、誰が所有し、誰が引き継ぐかを決めておきます。Google公式：インストール型トリガー

回答を受け取ったら、作成前に回答IDで検索する

フォーム側の FormResponse では、送信済み回答のIDや回答項目を取得できます。回答者の名前や送信時刻を組み合わせて擬似的なIDを作るより、これを使う方が照合しやすくなります。Google公式：FormResponse

処理の流れは、次のようにします。

フォームの送信イベント
  → フォームID＋回答IDを取得
  → 設問ごとの回答を変換
  → Notionの「外部回答ID」を検索
     0件：新しく登録
     1件：回答由来の項目だけ更新
     2件以上：重複として保留
  → NotionページIDと処理結果を記録

同じ回答を再処理しても、Notionの行が増えないことを確認します。ただし、検索と作成は一度の処理で保証されるわけではありません。同じ回答を並行処理しないようにし、途中で通信が切れたときも、作成結果を検索してから再試行します。

NotionへのHTTPリクエストや認証情報の置き方は、GASとNotion APIの接続例にまとめています。

設問の名前を変えても、別の列へ入らないようにする

「ご相談内容」を「お問い合わせ内容」に変えた途端に回答が空欄になる。これは、質問文をそのまま対応付けのキーにしていると起きやすい問題です。

GASでフォームの項目を扱う場合は、各項目のIDを使って対応表を持たせます。質問の並び順だけで「3番目はメール」と判断することも避けます。項目IDは、フォームを複製したり設問を作り直したりした場合には改めて確認してください。Google公式：Item

変更	連携側で確かめること
質問文だけを変更	同じ項目IDを参照できているか
選択肢を追加	Notionの分類へ変換できるか
複数選択へ変更	文字列ではなく複数の値として扱えるか
必須項目を任意へ変更	空欄でも登録できるか
フォームを複製	フォームID・項目ID・トリガーを設定し直したか

フォームを変更した担当者が、テスト回答を1件送るところまで作業に含めると、連携の不具合を早く見つけられます。

添付ファイルと回答訂正は、別の確認経路を用意する

ファイルのリンクをNotionに保存しても、Notionの閲覧者がDriveファイルを開けるとは限りません。実際に対応する担当者のアカウントでリンクを開き、必要な範囲で共有を設定します。連携を通すために「リンクを知っている全員」へ公開する必要はありません。

回答者が送信後に訂正できるフォームでは、訂正が連携に反映されるかも確かめます。採用したトリガーやサービスで編集を検知できると決めつけず、検知できない場合は回答IDを指定して再取得する運用や定期照合を用意します。

訂正を取り込む場合も、返信履歴や担当者メモは残します。たとえば相談内容が変わったら「回答変更あり」を付け、担当者が差分を確認する形にすれば、すでに返信した前提が変わったことに気づけます。

運用開始前に送る5件のテスト回答

通常の回答、任意項目が空の回答、複数選択の回答、添付ありの回答、送信後に訂正した回答を1件ずつ用意します。それぞれについて、Notionの値、元の回答との対応、担当者からの添付閲覧を確認します。

最後に同じ回答をもう一度処理し、件数が増えず、Notionで追記したメモが残ることを確かめます。これができれば、既存フォームのURLを変えることなく、受付後の仕事をNotionへ移していけます。