※この記事は広告（アフィリエイトリンク）を含みます。
「昨日申し込んだ電話番号が違っていました」「参加人数を2名から3名に変えてください」。イベントや講座の事務局にいると、申込が済んだあとに修正依頼が届くことがよくあります。名簿をスプレッドシートで管理していると、修正のたびに「どの行が最新なのか」「配布資料に古い人数が残っていないか」を確かめる作業が増え、気づかないうちに名簿がずれていきます。
この記事では、エルメ（L Message）のフォームとスプレッドシート連携を使っている、またはこれから使う方に向けて、修正依頼の受け方を整理します。公式マニュアルで確認できた仕組みを軸に、「LINEで減らせる手間」と「人の確認が残る部分」を分けて書きます。確認できなかった点は、その旨をはっきり書きます。
名簿がずれる原因を、修正の経路ごとに切り分ける
名簿のずれは「修正を受け取った場所」と「名簿を直した場所」が別々になるときに起きやすい、というのが整理の出発点です。たとえば、修正はLINEのトークで届き、元の申込はフォームの回答シートに入り、名簿は別のファイルで管理している、という形です。経路が3つあれば、直し忘れが起きる場所も3つあります。
| ずれ方 | 起きやすい理由 | 最初に見直すこと |
|---|---|---|
| 同じ人の行が2つある | 修正のたびに再回答が行として追加され、古い行が残る | 最新行を正とする決め方と、古い行の扱い |
| 修正がトークに埋もれる | 修正依頼が通常の問い合わせと混ざる | 修正を受ける入口を1つにする |
| 名簿の値と配布物がちがう | 名簿は直したが、当日の資料や連絡先リストは古いまま | 名簿から資料を作る順番と更新日の記録 |
| 誰が直したか分からない | 複数人が同じシートを直接書き換える | 直す担当と、直す場所の固定 |
| 人数変更が定員に反映されない | 名簿の修正と定員の管理が別 | 定員の数え方を名簿の1か所に寄せる |
このうち、仕組みで防げる部分と、運用ルールでしか防げない部分があります。次の節で、公式マニュアルから分かる範囲を確認します。
エルメのフォームと回答シートで公式に確認できたこと（取得日2026-10-09）
ここでは、エルメ公式マニュアルのフォーム作成のページと、フォーム回答のGoogleスプレッドシート連携のページを読み、要点だけを自分の言葉でまとめます。画面や仕様は変わることがあるため、実際に設定する前に公式ページで再確認してください。
- フォームの回答は友だち情報と紐づけられる。回答完了後のアクションとして、タグの付与や削除、友だち情報の更新、テンプレート送信、ステップ配信の開始や停止などを設定できる。
- 回答制限として、友だち1人あたりの回答回数を無制限にするか、上限を設けるかを選べる。
- 「既に情報が登録されている場合、初めから入力された状態にする」という設定があり、有効にすると前回の回答が初期表示される。無効だと再度入力が必要になる。
- スプレッドシート連携では、回答者名と各質問への回答が、1回答につき1行で記録される。新しい回答は既存のデータを書き換えず、下に行として追加される。
- 質問項目を追加・削除すると、シートの列も自動で変わる。
- 連携先のシートでは、「シート1」の名前を変えない、シートを足す場合も「シート1」を左端に残す、最終行を非表示にしない、という注意が書かれている。最終行を隠すとデータが更新されなくなる。
ここから言えるのは、「同じフォームで再回答してもらうと、名簿シートには別の行として足される」という読み方が自然だ、という点です。ただし、再回答したとき既存の行が上書きされるのか、追加だけなのかを、フォーム再回答の場面に限って明記したページは、公式で確認できませんでした。設定する際は、テスト用のフォームで実際に1回修正を入れて、シートの動きを自分の目で確かめておくことをおすすめします。
また、回答日時や回答の識別番号の列がシートに入るかどうかも、読んだページでは確認できませんでした。日時の列に頼る運用は、実機で確認してから決めるのが安全です。
LINEで解ける部分と、解けない部分
| 項目 | エルメで扱いやすい部分 | 人の判断が残る部分 |
|---|---|---|
| 修正の受け口 | 修正専用フォームを作り、リッチメニューやトークから同じ入口に誘導する | 口頭・電話で届いた修正を誰が入力するか |
| 回答の記録 | 回答が1行ずつシートに残る。いつ何を回答したかの履歴として使える | 古い行と新しい行のどちらを正とするかの判断 |
| 本人への確認 | 回答完了メッセージで、回答内容のコピーを自動で返せる | 内容が事実として正しいかの確認 |
| 友だち情報の更新 | 1:1チャットの友だち情報欄などから手で書き換えられる。フォームのアクションでも更新できる | 複数の情報（名簿・友だち情報）を同期させること |
| 一括の修正 | 公式の掲載ページでは、CSVによる一括更新の可否は確認できなかった | 大量の修正は別の手段か窓口での確認が必要 |
修正の受け方を3通りに分けて、使い分ける
修正依頼の受け方は、大きく3つに分けられます。どれが正解というより、申込の件数・修正の頻度・名簿の使い方で選びます。
受け方A：同じ申込フォームでもう一度回答してもらう
いちばん手軽な方法です。「既に情報が登録されている場合、初めから入力された状態にする」を有効にしておくと、前回の回答が入った状態で開けるため、変えたい項目だけ直してもらえます。回答制限を無制限にしておく必要がある点に注意してください（上限1回のままだと、修正のための再回答ができません）。
つまずきやすいのは、名簿シートに同じ人の行が増えることです。対処としては、名簿の本体を回答シートと分け、回答シートは「受付ログ」として触らない、という運用が向いています。修正が増えたら、名簿側で最新の1行だけを残します。
受け方B：修正専用のフォームを作る
申込フォームとは別に、「申込内容の修正フォーム」を作る方法です。質問は、お名前、修正したい項目、修正後の内容、の3つ程度に絞ります。回答は別のシートに溜まるので、元の申込シートと修正シートが混ざりません。
回答完了時のアクションで、「修正受付」タグを付けておくと、あとからタグで絞り込んで確認できます。フォーム回答後のアクションの考え方は、フォームの回答後アクションと条件の考え方｜回答でタグを付ける・通知する・次の案内につなぐで整理しています。
受け方C：トークで受けて、事務局が友だち情報欄を直す
件数が少ない場合は、1:1チャットで修正を受け、友だち情報欄の項目を手で直す方法もあります。公式のマニュアルでは、1:1チャットの友だち情報欄や、友だち詳細ページの基本情報から項目の登録・変更・削除ができると説明されています。ただし、友だち情報を直しても、フォーム回答のシートは自動では書き換わらない、という点は別に確認が必要です（連携の方向について、公式で確認できませんでした）。
どの経路でも、窓口をバラバラにしないことが大切です。窓口が散らばる問題は予約の変更依頼がLINE・電話・口頭に散らばる悩み｜窓口を一本にして見落としを防ぐ手順でも扱っています。
名簿を守る運用ルール案とチェックリスト
仕組みを整えても、ルールがないと人が名簿を直接書き換えて元のずれに戻ります。小さな事務局でも守れるよう、最小限のルールを例として挙げます。そのまま使わず、自分の運用に合わせて削ってください。
- 回答シートは「受付ログ」とし、人が直接書き換えない。名簿は別のシートかファイルに置く。
- 名簿には「最終更新日」と「修正の内容」の列を人が足す。誰が直したかの列も1つ置く。
- 同じ人の行が複数ある場合は、いちばん新しい回答を正とする。ただし、回答日時の列があるかは事前に確認する。
- 修正依頼は、フォーム、または1:1チャットのどちらかで受ける。口頭の修正は、受けた人がその場でフォームに入力する。
- 定員、人数、金額に関わる修正は、名簿を直したあとに本人へ確認の連絡を返す。
- 当日の資料（出席簿、名札、連絡先リスト）は、前日の締め時刻の名簿から作る。締め後の修正は別枠で扱う。
毎回の確認用のチェックリストとしては、次の5点が役に立ちます。
- シート1の名前を変えていないか、最終行を隠していないか
- 同じ人の行が増えていないか（お名前で並べ替えて確認）
- 修正後の値が、配布物や名札に反映されているか
- 本人への確認メッセージが送られているか
- 修正受付のタグが付いたままになっていないか（対応済みへ付け替え）
連携まわりの基本操作や、フォームからの転記を減らす考え方は申込フォームの回答を手でスプレッドシートに写す作業を減らす｜フォーム転記の切り分けと、手作業が残る場面も参考になります。
活用例（架空の設計例）
以下は実例ではなく、考え方を示すための架空の設計例です。成果の数字や、実際にこうなったという話ではありません。
設定の想定：月に1回、定員30名の勉強会を開く小さな事務局。申込フォームと、修正専用フォームの2つを用意します。申込フォームは再回答を許可し、前回の回答が初期表示される設定にします。修正専用フォームには「修正受付」タグを付けるアクションを設定します。
| タイミング | やること | 担当 |
|---|---|---|
| 申込受付中 | 申込フォームの回答が回答シートに追記される。名簿は別シートに置く | 自動＋事務局 |
| 修正依頼が届いたとき | 修正専用フォームに誘導。受付タグが付く | 自動 |
| 週に2回 | タグで絞り込み、名簿の該当行を直して「最終更新日」を入れる | 事務局 |
| 前日の締め | 名簿から出席簿と名札リストを作る。締め後の修正は別メモにする | 事務局 |
| 当日 | 別メモの修正を、出席簿に手書きで反映する | 当日担当 |
この設計では、「どこを最新とみなすか」を名簿の1か所に決めているのが要点です。エルメが担うのは受付と記録と本人への確認までで、名簿を正しく保つ判断は、運用ルールと担当者の仕事として残ります。
LINEでの修正受付が向かないケースと、私の見立て
向かないケース
- 申込内容に、診断書や身分証の情報など、とても慎重に扱う個人情報が含まれる。LINEで受けるかどうか自体を、各自の方針や規約で確認してください。
- 金額や契約条件の変更など、書面での合意が必要な内容。LINEの連絡は補助にとどめ、書面や電話、対面で確認する方が安全です。
- 当日や直前の緊急の変更（開始時刻の1時間前など）。トークの見落としが起こりうるため、電話を併用する案内を事前に出しておく方が向いています。
- 修正が毎日大量に発生する。この場合は、フォームの運用以前に、申込の項目設計を見直す余地があります。
私の見立て3点
- 名簿がずれる原因の多くは、機能不足ではなく「正とする場所が2つある」ことだと考えています。まず場所を1つに決め、そのあとに仕組みを足す順番が、手戻りが少ないと見ています。
- フォームの再回答は便利ですが、シートが追記型であることを前提に、受付ログと名簿を分けておく方が安全だと思います。実機での確認を一度は挟むことをおすすめします。
- 修正を「受ける」ことは自動化できても、「内容が正しいかの最終確認」は人に残ります。ここを無理に自動化しようとしない方が、事故が少ないと見ています。
まとめ
申込内容の修正で名簿がずれるときは、(1) 修正を受ける入口を1つにする、(2) 回答シートは追記されるログと考えて名簿を別に持つ、(3) 最新を正とするルールと更新日を名簿に残す、の3点から見直すと整理しやすくなります。公式で確認できた範囲では、回答は1回答1行で追記され、再回答時に前回の回答を初期表示する設定もあります。一方で、再回答時の上書きの有無、回答日時の列、友だち情報とシートの同期、CSVによる一括更新、各機能の対象プランは、公式で確認できませんでした。契約前、設定前に公式で確認してください。
まずは無料プランの範囲で、テスト用のフォームを1つ作り、修正の動きを自分の目で確かめるところから始めるのがおすすめです。
構築代行のご案内（30万円〜・税別）
「自分の事務局に合う受け方を設計したい」「フォームとシートの連携をまとめて整えてほしい」という場合は、構築のご相談を承っています。ご相談は構築代行のご案内ページからどうぞ（30万円〜・税別）。内容によって費用は変わるため、まずは現状の運用をお聞かせください。
