最終更新日: 2026-08-13
別のフォームサービスやExcelにある過去回答は、いきなり本番フォームへ全件入れないでください。
最初に移行先の質問項目を確定し、自動メールを止めたテスト用フォームへ3〜10件だけ取り込みます。項目対応、型、件数、メールアドレスを確認できてから、500件以下のまとまりに分けて本番移行します。
FORMLOVAの回答インポートはStandard以上で使え、1回に受け取れるのは最大500件です。同じ内容を24時間以内に再実行すると、通常は初回結果を返して二重登録を防ぎます。ただし、取り込み自体を一括で元に戻す機能はありません。だから、バックアップ、少量テスト、自動処理の停止、移行後の件数照合を一つの手順として扱う必要があります。
先に結論

安全な回答データ移行は、次の順番で進めます。
- 元データを変更せず保管し、移行対象件数を記録する
- 移行先フォームの質問項目と型を確定する
- 有効なメールシーケンスを停止し、複製またはテスト用フォームを用意する
- 3〜10件を構造化済み配列にして少量テストする
- 成功件数、スキップ件数、行エラー、実際の回答表示を確認する
- 1回500件以下に分けて本番取り込みする
- 元件数、取込件数、エラー件数、移行後件数を照合する
特に重要なのは3番です。過去回答を入れるだけのつもりでも、移行先フォームに有効なメールシーケンスがあると、過去の回答者が新規回答者として登録される可能性があります。詳しくは後述します。
回答の移行と、質問の移行は別作業です
「フォームを移行する」という言葉には、少なくとも3つの作業が混ざっています。
| 移行するもの | 目的 | 読む記事 |
|---|---|---|
| 質問、選択肢、必須設定 | 同じ入力画面を作る | Googleフォームの質問をエクスポートする方法 |
| Googleフォームの回答CSV | 元サービスから回答を持ち出す | Googleフォーム回答のCSVダウンロードと文字化け対策 |
| 過去回答の取り込み | 移行先で回答を検索・集計できるようにする | この記事 |
この記事では3つ目だけを扱います。質問を先に作らず回答だけを取り込むことはできません。移行先の項目IDや項目名が決まってから、回答データを対応させます。
Google公式ヘルプでは、Googleフォームの回答をGoogle Sheetsで表示する方法と、CSVでダウンロードする方法が案内されています。元データの出力手順が必要な場合は、先に048の記事で文字化けを含めて確認してください。
最重要注意: 過去回答からフォローメールが始まる可能性があります
これはFORMLOVAの現行実装を、コードとDB定義から確認した結果です。
回答インポートは、検証を通った行をresponsesテーブルへ新しい回答としてINSERTします。一方、メールシーケンスはresponsesへのINSERT後に動くDBトリガーで、有効なシーケンスへ回答を登録します。
そのため、次の条件がそろうと、過去回答者がメールシーケンスへ登録され得ます。
- 移行先フォームに有効なメールシーケンスがある
- インポート行に、移行先でemail型として認識されるメールアドレスがある
- その回答が新しい
responses行として保存される
これは「必ず全員へ即送信される」という断定ではありません。配信停止リスト、メールクォータ、シーケンスの有効状態、各ステップの遅延、Cron処理など、その後の条件があります。ただし、DBトリガーによる登録経路が存在する以上、本番で試してよいリスクではありません。
インポート前に、必ず次の4点を実施してください。
- 対象フォームのメールシーケンスを無効化する
- 可能ならフォームを複製し、テスト用フォームで試す
- 自社管理のテスト用メールアドレスを含む3件程度だけを入れる
- 回答一覧だけでなく、シーケンス登録と送信状況も確認する
無効な状態で回答を入れ、確認後にシーケンスを有効化しても、既存回答を遡って登録するトリガーではありません。新しい回答のINSERT時にだけ判定されます。過去回答と今後の新規回答を分けたい場合、この順番が最も安全です。
FORMLOVAへ渡すのはCSVファイルそのものではありません
FORMLOVAのimport_responsesが実際に受け取る入力は、構造化済みのオブジェクト配列です。CSV、Excel、貼り付けた表は、MCPクライアント側で配列へ変換してから渡します。
たとえば、移行先フォームに「お名前」「メールアドレス」「利用目的」という項目がある場合、入力の形は次のようになります。
[
{
"お名前": "移行テスト1",
"メールアドレス": "migration-test-1@example.com",
"利用目的": "資料確認"
},
{
"お名前": "移行テスト2",
"メールアドレス": "migration-test-2@example.com",
"利用目的": "比較検討"
}
]
実際の顧客情報をAIチャットへ貼り付ける前に、利用中のMCPクライアント、社内規程、委託先、データ保存条件を確認してください。テストでは架空データを使います。
個人情報保護委員会の現行ガイドラインは、個人データの取扱状況を把握し、安全管理措置を講じることを求めています。データ移行でも、対象者、項目、件数、作業者、保管先、削除時期を記録しておくと、作業後に不要な複製を残しにくくなります。
項目名とfield IDのどちらで対応させるか
FORMLOVAは、入力オブジェクトのキーを次の順で解決します。
- 移行先フォームに存在するfield IDと一致すれば、そのIDへ入れる
- IDでなければ、項目ラベルを大文字・小文字を区別せず照合する
- どちらにも一致しなければ、その行を未知のフィールドとしてエラーにする
| 対応方法 | 向いている場面 | 注意点 |
|---|---|---|
| 項目ラベル | 少量移行、項目名が一意で安定している | 同名項目、前後空白、表記変更を事前に整理する |
| field ID | 大量移行、同名項目がある、再現性を優先する | 別フォームへ同じIDを流用しない |
作業前にget_formで移行先の項目構造を確認し、対応表を作ります。
| 元データ列 | 移行先ラベル | field ID | 型 | 変換ルール |
|---|---|---|---|---|
| 氏名 | お名前 | 101 | text | 前後空白を除く |
| メールアドレス | 102 | 空欄と形式不正を分ける | ||
| purpose | 利用目的 | 103 | single_select | 移行先の選択肢表記へ統一する |
| applied_at | 申込日 | 104 | date | ISO形式の文字列へ統一する |
この表は例です。実際のfield IDはフォームごとに異なります。
型エラーと行単位スキップを理解する
現行のインポート処理は、渡された値について主に次を検証します。
| 項目型 | 入力の基本形 | よくあるエラー |
|---|---|---|
| 文字列 | @がない、数値になっている | |
| rating_scale | 1以上の整数 | 小数、0、文字列化できない値 |
| date / datetime | ISO形式として解釈できる文字列 | 日本語日付の揺れ、無効日 |
| multi_select | 配列 | カンマ区切りの1文字列のまま |
| single_select | 文字列または数値 | オブジェクトや配列になっている |
| phone | 文字列 | 表計算ソフトで数値化され、先頭0が落ちる |
未知の項目や型エラーが1つでもある行は、その行全体がスキップされます。他の正常行は取り込まれるため、「実行が成功した」だけでは全件成功を意味しません。戻り値の成功、スキップ、合計と、行番号・項目・理由のエラーを保存してください。
また、現行処理は「渡された値」の型と項目対応を中心に検証します。元データに列そのものがないケースを、移行担当者の確認なしで完全に補えるものではありません。必須項目の欠落、空欄、選択肢の意味変更は、対応表と少量テストで別途確認します。
実際の移行手順
1. 元データと件数を固定する
移行開始時点の原本を読み取り専用で保管します。ファイル名、出力日時、総行数、重複候補数、空メール件数を記録してください。
移行中も旧フォームが回答を受け付けるなら、締切時刻を決めるか、初回移行後の差分を別バッチにします。原本が動き続ける状態では、件数照合ができません。
2. 移行先フォームを確定する
質問、選択肢、型を先に作ります。項目名を後から変える予定があるなら、ラベルではなくfield IDでの対応を検討します。
この段階で、有効なメールシーケンス、ワークフロー、通知、外部連携を一覧にしてください。特にメールシーケンスは停止します。
3. テスト用の3〜10件を作る
正常系だけでは足りません。
- すべての項目が入った正常行
- 任意項目が空の行
- 複数選択を含む行
- 日付を含む行
- 意図的に未知の列または型不正を入れた行
これで、正常行が入り、不正行がスキップされ、エラー理由が読めることを確認できます。
4. 少量インポート後に画面と件数を確認する
実行結果だけでなく、回答一覧から値を確認します。
- 名前、メール、日付、複数選択が正しい項目に入ったか
- 文字コードや改行が壊れていないか
- エラー行が回答一覧へ混ざっていないか
- 自動メールや外部連携が動いていないか
- 回答総数が想定どおり増えたか
5. 500件以下のバッチに分ける
1回の入力上限は500件です。たとえば1,230件なら、500件、500件、230件に分けます。
バッチごとに識別子、元行範囲、入力件数、成功件数、スキップ件数、エラー件数、実行日時を残します。途中で止まっても、どこから再開すべきか判断できます。
6. 最終照合する
次の式が一致することを確認します。
移行対象件数 = 成功件数 + スキップ行件数
移行後の増分 = 全バッチの成功件数
さらに、先頭・中間・末尾から数件ずつ抜き取り、項目単位で元データと照合します。件数だけ合っていても、列対応がずれていれば移行成功ではありません。
24時間の重複ガードとforceの使い分け
FORMLOVAは、フォームIDと入力データから内容ハッシュを作り、同一内容のインポート操作を識別します。
同じフォームへ同じデータを24時間以内に再送すると、通常は新しく取り込まず、初回の成功・スキップ結果を再表示します。通信切断やMCPクライアントの再試行で二重登録しにくくするための仕組みです。
force=trueは、このガードを意図的に越えて同じ内容を新規バッチとして入れる指定です。確認のために何となく付ける値ではありません。
| 状況 | force | 判断 |
|---|---|---|
| 結果表示が消えたので再確認したい | false | 初回結果のリプレイを使う |
| 通信が切れ、入ったか分からない | false | まず再実行し、回答一覧と件数を確認する |
| 同一人物の同一回答を業務上もう1件登録する必要がある | trueを検討 | 理由と承認を記録して実行する |
| テストデータを消さずに同じテストを繰り返したい | 原則使わない | 新しいテスト用値か別フォームを使う |
24時間を過ぎると、同じ内容でも新しい取り込みとして処理され得ます。時間が経てば安全になるのではなく、作業台帳と件数照合が引き続き必要です。
FORMLOVAで確認した一次情報
この記事の製品固有の内容は、2026年8月13日に次を突き合わせて確認しました。
import_responsesの入力は1〜500件の構造化済み配列- 回答インポートはStandard以上
- キーはfield IDまたは項目ラベルで対応
- 不正な行は行単位でスキップし、最大10件までエラー詳細を表示
- インポート行は
source: importの回答として一括INSERT - 同一内容は24時間の重複ガードで初回結果をリプレイ
force=trueは意図的な再取り込みに限ってガードを越える- インポート操作をまとめて元に戻す機能はない
- 有効なメールシーケンスは回答INSERT後のDBトリガーで登録される
「CSVをそのままアップロードすれば、質問構造まで自動で安全に復元される」という仕様ではありません。移行元ファイルを構造化し、既存の移行先項目へ対応させる操作です。
よくある質問
CSVファイルをそのまま渡せますか?
実際のimport_responses入力はオブジェクト配列です。CSVやExcelを使う場合は、MCPクライアント側で見出しと各行を構造化してから渡します。変換後の3件を表示してもらい、列ずれがないことを確認してから実行してください。
Googleフォームの質問も同時に移行できますか?
この記事の対象外です。質問構造を先に移す場合は、Googleフォームの質問をエクスポートする方法を確認してください。回答CSVの出力はGoogleフォーム回答のCSVダウンロードと文字化け対策で扱っています。
500件を超える場合はどうしますか?
500件以下の複数バッチに分けます。元行範囲と各バッチの結果を台帳に残し、最後に合計を照合してください。
エラーが1件あると、全件が失敗しますか?
全行がエラーなら取り込みは行われません。一部の行だけに未知の項目や型エラーがある場合、その行はスキップされ、正常行は取り込まれます。成功件数とスキップ件数を必ず確認してください。
同じデータを間違えて2回送ったらどうなりますか?
同じフォームと同じ内容なら、24時間以内は通常、初回結果が返り二重登録を防ぎます。ただし、force=trueを指定した場合や24時間経過後は新規取り込みになり得ます。
移行後にメールシーケンスを有効化しても過去回答へ送られますか?
確認した現行実装では、登録トリガーは回答のINSERT時に動きます。シーケンスを無効にしてインポートし、確認後に有効化する順番なら、すでに入っている過去回答を遡って自動登録する動作ではありません。実装は将来変わり得るため、大規模移行前にはテスト用フォームで再確認してください。
Disclosure and Verification
著者・検証注記
筆者はFORMLOVAの開発者です。この記事は一般的なCSV移行論だけでなく、FORMLOVAのMCPツール定義、回答INSERT処理、重複防止台帳、メールシーケンス登録トリガーを2026年8月13日に確認して執筆しました。
メールシーケンスへの登録可能性は、回答インポートがresponsesへINSERTする事実と、同テーブルのAFTER INSERTトリガーが有効なシーケンスへ登録する実装を組み合わせた推論です。実際の送信可否や時刻は、メールアドレス、配信停止、クォータ、シーケンス状態、遅延、Cron処理にも依存します。
外部一次資料:
関連記事
まとめ
回答データ移行は、ファイルを入れるだけの作業ではありません。
元データを固定し、質問項目を先に作り、自動処理を止め、少量で型と項目対応を確認する。500件以下のバッチごとに結果を保存し、最後に件数と値を照合する。この順番が、重複、列ずれ、取りこぼし、過去回答者への誤配信を防ぎます。
FORMLOVAで試す場合は、まず無料でアカウントを作成し、Standard以上の複製またはテスト用フォームで、架空データ3件から確認してください。本番データを入れるのは、その結果を確認した後です。


