最終更新日: 2026-10-15
フォーム回答をSheets・CRM・Notionへ渡す前に、元回答ID・対象条件・渡す項目・重複時の扱いを決めます。最初は1件の転記案を確認し、接続先を読み直して完了を確かめます。MCPでマスクされた連絡先を、CRMの本人照合や送信宛先に使ってはいけません。
CSVやGoogle Sheets連携の基本は、FORMLOVAで回答をCSVで書き出す / Google Sheetsに自動連携する方法で扱っています。この記事では、SheetsだけでなくCRMやNotionも含め、渡す項目と確認手順を決めます。
まず結論 -- 外部連携は4つに分けます
以下の列や担当・期限は運用設計の例です。FORMLOVA標準のstatusは new（新規）、in_progress（対応中）、resolved（解決済み）、spam の4値です。担当者、確認待ち、返信期限、AI候補はnotes・既存タグを保持するタグ運用・用途に応じたフォーム項目、または別の運営台帳へ分けます。needs_review は確認用の印で、標準statusではありません。複数回答の状態変更は対象IDごとに実行し、再取得で確認します。
フォーム回答を外部へ渡すときは、次の4つを分けます。
| 決めること | 例 | 決めないと起きること |
|---|---|---|
| 記録先 | Sheets、CRM、Notion | 何でも同じ場所へ流れる |
| 同期条件 | 全件、営業対象のみ、要確認のみ | ノイズや欠落が増える |
| 同期項目 | 要約、カテゴリ、ステータス、URL | 後から検索できない |
| 人間確認 | 作成前確認、更新候補、除外 | 誤登録や個人情報共有が増える |
外部連携は、接続できるかどうかより、接続後に業務が整理されるかどうかで判断します。
フォーム自動化全体の考え方は、親ハブのFORMLOVAでフォーム自動化を始める方法で整理しています。本記事は、その中の「回答を外部ツールへ渡す」部分に絞ります。
転記先を1つ選んでデータ契約を作る
次は未実行の提案例です。まず下書きや架空データで試し、実回答を使う場合はフォーム・期間・扱ってよい情報を決めます。
カテゴリ、相談本文、連絡可否を含むフォームを未公開で下書きにしてください。
指定回答を外部の運営台帳へ渡す案として、元回答ID、送信日時、匿名要約、カテゴリ候補だけのマッピング表を作ってください。必要な外部MCPと権限、重複キー、再取得で確認する項目も示してください。マスク済みメールや電話を本人キーや宛先にせず、外部書き込みは待ってください。
外部へ渡す必要のない情報を削り、同じIDを再試行しても重複しない設計かを確認します。成功ログだけで完了にせず、実行後は転記先のIDと値を読み直し、失敗・不明を別に残します。
この図は運用の考え方を示す既存の概念図です。実画面や動作成功の証拠ではありません。図の自動化範囲も、利用プラン・接続・設定後に成立する設計を示します。
フォーム作成・公開・回答受付・検索・標準status・書き出し・基本分析は無料で使えます。上のAIの整理は接続するAIクライアント側で行い、外部AIの利用条件や費用は別です。カスタム自動返信、リマインド、取り込み、詳細分析、添付、標準のSheets自動同期はスタンダード以上、一斉メールやシーケンスはプレミアム以上です。外部MCPを使うレシピはFreeからでも外部接続・権限・提供元条件がそろえば実行できますが、チャットへ貼るだけで常時監視は始まりません。
外部転記を設計できる受付を作る
上の下書きと確認から無料で試し、運用に必要になった機能を追加できます。
登録してメール確認後、対応AIチャットへ接続し、上の依頼文で下書きを作ります。公開前に内容を確認し、外部AIの利用条件・費用も確認してください。
記録先は目的で選びます
Google Sheets、CRM、Notionは似ているようで、役割が違います。
| 記録先 | 向いている用途 | 向いていない用途 |
|---|---|---|
| Google Sheets | 一覧、共有、軽い集計、週次確認 | 担当者履歴や営業活動の正本 |
| CRM | リード、商談、顧客管理、営業フォロー | すべての問い合わせの保管 |
| Notion | 社内メモ、要望管理、事例、検索できるナレッジ | 即時対応が必要なキュー |
| FORMLOVA回答一覧 | 回答正本、ステータス、フォーム文脈 | 外部チームの二次利用 |
Sheetsは、表で見たいときに強いです。
CRMは、営業や顧客対応につながる回答に強いです。
Notionは、社内ナレッジや要望管理として残したい回答に強いです。
FORMLOVA側は、フォーム回答の正本として残します。
この分担を先に決めると、外部連携が散らかりにくくなります。
正本はFORMLOVA側に残します
MCPのCSV/Excel書き出しはフォーム項目と送信日時で、回答ID・status・owner・notes・tags列は含みません。フォーム全件を書き出し、必要な絞り込みは管理した作業コピーで行います。IDや状態の分析は対応する回答取得で確認し、生メール照合や存在しないCSV列で結合しません。MCPのメール・電話はマスクされるため、マスク値を宛先やCRMの本人キーへ渡しません。標準Sheets自動同期も送信日時とフォーム項目で、owner/status等は別の作業台帳へ分けます。Freeの所有者向け通知は6時間ダイジェストでメール枠の対象外です。回答者向けメールや、チャットで作る未対応レポートとは別です。
外部連携でよくある失敗は、外部ツールを正本にしてしまうことです。
フォーム回答はFORMLOVAにある
Slackに通知された
Sheetsにも行がある
CRMにもコンタクトがある
Notionにもページがある
この状態で、どれが最新か分からなくなると危険です。
おすすめは、FORMLOVA側の回答IDとステータスを正本にすることです。
外部ツールには、次のような戻り道を持たせます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
response_id
form_name
submitted_at
status
owner
source_url
external_record_id
sync_status
synced_at
外部ツールで見た人が、FORMLOVA側の回答へ戻れること。
FORMLOVA側のnotesまたは連携台帳でも、どの外部レコードへ渡したかを確認できること。
この2つがあると、状態が分断されにくくなります。
渡す項目をデータ契約として決めます
外部連携では、原文を全部送るより、業務に使う項目へ整えます。
最小構成は、次のような形です。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
response_id
submitted_at
approved_external_contact_reference（許可された別経路で確認できる場合のみ）
company
category
summary
priority
status
owner
next_action
source_url
external_record_id
sync_status
この項目セットを、データ契約として扱います。
データ契約とは、どの列を、どういう意味で、どの外部ツールへ渡すかを決めることです。
たとえば summary はAI要約でもよいですが、原文の意味を変えないことが前提です。priority はAIが候補を出してもよいですが、重要判断は人間が確認します。owner は担当者候補と担当者確定を分けます。
フォーム回答をAIで要約・分類してから渡す場合は、回答データとチャットするとはも合わせて確認してください。AIは分類、要約、候補提示までに使い、外部登録や重要判断は確認を残します。
Sheetsへ渡すなら、全件ログと業務ビューを分けます
Google Sheetsは、最初の外部連携先として使いやすいです。
ただし、Sheetsへ全件を流す場合でも、用途を分けます。
| Sheetsの使い方 | 向いている場面 | 注意点 |
|---|---|---|
| 全件ログ | 回答が入った証跡を残す | ステータス正本にしない |
| 業務ビュー | 未対応、要確認、週次確認 | 条件を明確にする |
| 集計用データ | 件数、カテゴリ、流入元 | 個人情報を最小化する |
全件ログは、抜け漏れ確認に向いています。
業務ビューは、チームが見るべき回答だけに絞ります。
集計用データは、個人名や自由記述原文をそのまま出さないほうがよい場合があります。
新規回答をSlackへ知らせながらSheetsにも残すなら、FORMLOVAの回答をSlack通知してSheetsに記録が近い入口です。この外部MCPレシピはチャット実行時の確認と実行を支援します。Freeでも外部接続・権限等があれば試せますが、常時同期は始まりません。標準Sheets自動同期はスタンダード以上で、送信日時とフォーム項目だけが自動列です。要約やstatusは別台帳に設計し、マスク済み連絡先を本人キーには使いません。
Workflowページは再利用できるチャット用プロンプトです。接続中のセッションで必要なツールとプランを確認して実行するもので、回答ごとの監視や定期実行が自動で設置されるわけではありません。定期レポート・リマインドは対応するスタンダード以上の設定か別途のスケジューラーが必要で、外部Slack/Sheets MCPは接続・権限・提供元条件も別に確認します。
CRMへ渡すなら、営業対象だけに絞ります
CRMへ入れるべきなのは、すべてのフォーム回答ではありません。
CRMは、営業や顧客対応の記録です。
そのため、営業対象ではない問い合わせ、採用応募、イベントの出欠、営業メール、テスト送信まで入れると、CRMが汚れます。
CRMへ渡す条件は、先に決めます。
送る:
- 導入相談
- 料金相談
- 資料請求
- 既存顧客からの契約相談
- 会社名またはメールドメインが確認できる
送らない:
- テスト送信
- 明らかな営業メール
- 採用応募
- 個人の一般質問
- 連絡許可がない回答
CRMでは、作成と更新も分けます。
MCPのマスク済み連絡先だけでは本人照合できません。許可された外部経路で確認済みの連絡先IDがある場合に限り既存コンタクトとの対応を確認します。確認できない場合は作成・更新を止めます。会社名や関心領域が不足している場合は、すぐ作らず追加確認に回す。
FORMLOVAの回答をHubSpotコンタクト登録は、フォーム回答からHubSpotコンタクトを作成または更新する入口です。営業対象かどうか、担当者を付けるか、フォーム名や要約を保存するかを確認してから使います。
Notionへ渡すなら、検索できる形にします
Notionは、フォーム回答を社内のナレッジや要望管理へ変えるときに向いています。
たとえば、次のような用途です。
- 顧客の声をタグ別に残す
- 機能要望をプロダクトチームで見る
- イベント後の感想を事例として集める
- 採用候補者の質問をFAQ候補にする
- 問い合わせの原因を社内改善メモにする
Notionへ渡すときは、ページ本文に原文を貼る前に、プロパティを整えます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
category
summary
priority
status
received_date
source_url
owner
duplicate_candidate
Notionは自由度が高いぶん、何でもページ化すると探せなくなります。
カテゴリ、優先度、ステータス、元回答へのリンクを必ず持たせます。
FORMLOVAの回答をNotion DBに保存は、回答をNotionデータベースに整理して保存する入口です。既存レコードと重複しそうな場合は更新候補にし、新規回答だけを新しいレコードにする設計が向いています。
同期条件は「送る条件」と「止める条件」を分けます
外部連携では、送る条件だけでは足りません。
止める条件も必要です。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
送る条件:
- category が sales
- priority が high
- followup_permission が yes
- status がnew（要確認は別の印）
- owner_candidate がある
止める条件:
- test_response が true
- spam_or_sales_mail が true
- duplicate_candidate が high
- consent_missing が true
- status がresolved/spam、または分析除外用タグ/台帳フラグがある
- synced_at が存在する
止める条件がないと、重複登録が増えます。
特にCRMとNotionは、あとから削除や統合が面倒です。
送る前に、重複候補、連絡許可、ステータス、既存同期済みかどうかを確認します。
未対応や担当者未設定を先に整理したい場合は、フォーム回答の未対応管理でキューの作り方を確認してください。
連携失敗時の戻り先を決めます
外部連携は、必ず失敗します。
認証が切れる。権限が足りない。必須項目が空。CRM側の重複ルールに引っかかる。Notionデータベースのプロパティ名が変わる。
そのため、失敗時の戻り先を決めます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
sync_status:
- pending
- synced
- skipped
- failed
- needs_review
sync_error:
- missing_email
- duplicate_candidate
- external_auth_required
- missing_required_field
- consent_missing
外部連携が失敗しても、フォーム回答そのものは失われてはいけません。
同期結果は外部連携台帳、または回答のnotesに残します。sync_status は標準statusの追加値や専用列ではありません。失敗した対象IDから再確認できるようにします。
Slack通知だけで追うと、失敗した外部連携が流れてしまいます。通知設計から見直す場合は、フォーム回答をSlack通知する設計も合わせて読むと、通知、記録、ステータスの分担が整理できます。
人間確認を残す場面
外部連携で、人間確認を残したほうがよい場面があります。
| 場面 | 自動でよいこと | 人間確認を残すこと |
|---|---|---|
| AI要約 | 要約候補を作る | 重要顧客の要約確定 |
| CRM登録 | 作成候補を出す | 新規コンタクト作成 |
| 担当者 | 担当者候補を出す | 担当者確定 |
| Notion保存 | ページ案を作る | 機密情報の公開範囲 |
| 除外 | 除外候補を出す | 除外確定 |
AIは、読む順番を作るには便利です。
ただし、外部ツールへの書き込みは業務記録になります。
特にCRM登録、個人情報を含むNotion保存、重要顧客の担当者確定は、人間確認を残してください。
実装前チェックリスト
外部連携を始める前に、次の項目を確認します。
1. どのフォーム回答を対象にするか
2. 正本はFORMLOVA回答一覧に残すか
3. 外部ツールに渡す項目は何か
4. 原文を渡すか、要約だけ渡すか
5. 送る条件は何か
6. 止める条件は何か
7. 重複時は作成ではなく更新候補にするか
8. 連絡許可や個人情報の扱いは問題ないか
9. 連携失敗時にどこで再確認するか
10. 誰が最終確認するか
この10項目を決めてから接続すると、外部連携は安定します。
逆に、先に接続してからルールを考えると、外部ツール側に不要な記録が残りやすくなります。
よくある失敗
フォーム回答の外部連携でよくある失敗は、次の5つです。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 全件をCRMへ入れる | 営業対象外でCRMが汚れる | 営業対象だけ送る |
| Sheetsを正本にする | ステータスが分断される | FORMLOVA側を正本にする |
| Notionに原文を全部入れる | 個人情報や機密が広がる | 要約とリンク中心にする |
| 重複判定がない | 同じ人や同じ案件が増える | update候補を先に出す |
| 失敗時の戻り先がない | 連携漏れに気づけない | sync_statusを持つ |
外部連携は、増やすほど高度になるものではありません。
必要な回答を、必要な外部ツールへ、戻れる形で渡すことが大切です。
まとめ
フォーム回答をSheets、CRM、Notionへ渡すワークフローでは、接続先より先に、記録先、同期条件、同期項目、正本、人間確認を決めます。
Sheetsは、共有表や軽い集計に向いています。
CRMは、営業や顧客対応に進む回答に向いています。
Notionは、社内ナレッジや要望管理として残す回答に向いています。
FORMLOVA側には元回答IDと標準statusを残し、戻り先や同期状態はnotesまたは外部連携台帳で対応付けます。
この分担にすると、外部連携は「データを流す作業」ではなく、フォーム回答を業務へ渡すワークフローになります。
関連記事
- FORMLOVAで回答をCSVで書き出す / Google Sheetsに自動連携する方法
- FORMLOVAでフォーム自動化を始める方法
- FORMLOVAのWorkflow Placeからレシピを見つけて、チャットで設定する方法
- フォーム回答をSlack通知する設計
- フォーム回答をダッシュボード化する方法
執筆・確認情報
この記事はFORMLOVAの自社ブログ記事です。筆者はFORMLOVAの開発者です。2026-06-23に、FORMLOVA内のCSV/Google Sheets、Workflow Place、フォーム自動化、Slack通知設計、未対応管理、Workflow公式レシピを確認し、本記事を外部連携ワークフローの受け皿として分離しました。外部サービスの仕様や料金は変わるため、導入前には最新の公式情報を確認してください。個人情報、採用、法務、医療、金融に関わるフォーム運用は、各社の規程や専門家の確認に合わせてください。
改稿確認（2026-10-15）: 本文の回答操作、プラン境界、書き出し列、提案例を現行リポジトリと照合しました。過去日付の調査は当時の記録であり、架空例は実測成果ではありません。
