Googleフォーム受付ログの保管期限レビューを作る5手順

先に結論：Googleフォームの受付ログを削除・保管延長する前に、案件ID、利用目的、確認予定日、終了状態、人間確認を一件ごとに分けます。期限が来たものと確認予定日が空欄のものを同じ扱いにせず、確認者と処理結果が残る二つのキューへ出してください。

フォームで相談や問い合わせを受けると、回答シートには原文、連絡先、案件の状態、担当者のメモが並びます。受付直後は役立つ情報でも、対応が終わった後は「いつまで残すのか」が曖昧になりがちです。保管期間を決めないまま蓄積すると、必要な記録まで消す不安が残り、逆に全部を残せば次の確認が重くなります。

この記事では、架空の受付5件を例に、受付ログを削除命令の一覧ではなく、次に確認する人へ渡せるキューへ変える方法を説明します。対象はGoogleフォームとスプレッドシートを使う小規模な問い合わせ運用です。法令や契約で定められた保存義務がある場合は、その正本を優先し、以下の表を専門家確認の前段に使ってください。

受付ログをそのまま削除キューにしない理由

受付日だけを見て「古いから削除」と判定すると、終了していない案件、後日の説明に必要な案件、保存義務がある案件が混ざります。反対に「日付がないから残す」とすると、確認されないデータが増えます。先に原文と管理メタデータを分け、利用目的と状態を見えるようにします。

分ける対象	記録する内容	空欄・不一致の時
原文	フォーム回答、受付日時、添付の保管先	原文を勝手に加工せず、参照先を確認
案件	案件ID、担当者、対応状態	重複IDや未設定を確認キューへ
目的	相談、契約前、サポート、記録保存	目的不明として削除しない
期限	確認予定日、根拠、次回レビュー日	期限不明キューへ分ける
処理	確認者、処理結果、処理日、理由	人間確認を止め、担当者へ戻す

この分離はデータを増やすためではありません。原文を守る列と、判断を更新する列を分けることで、後から「なぜ残したか」「なぜ手放したか」を説明できるようにします。AIを使って分類する場合も、AIの分類結果を正本にせず、原文と人の確認結果へ戻れる形を残します。

保管・確認・手放す状態を3つに分ける

受付ログの行ごとに、次の三つの状態を付けます。状態は削除の許可ではなく、次の行動を決めるための仮置きです。

状態	目安	次の行動	残す記録
確認待ち	期限到来、終了確認が必要	担当者が原文と目的を照合	確認者、確認日、処理候補
期限不明	確認予定日や根拠が空欄	利用目的と保存根拠を確認	不足項目、戻し先、次回日
手続き済み	人が処理し、結果が確定	決めた保管・削除手続きへ進む	処理結果、理由、実施日

「確認待ち」と「期限不明」を分けることが重要です。前者は確認日が来たため行動でき、後者は前提が足りないため行動を決められません。期限不明を期限到来とみなして消すと誤削除につながり、確認待ちを無期限に保留すると見直しが止まります。

10列の台帳で5件を確認キューにする

まず新しい台帳を作り、フォームの原文を直接上書きせず、管理用の列を追加します。最低限、次の10列を使います。

案件ID：一意の識別子。空欄や重複を別途確認する。
受付日：表示用の日付と元データの日時を混ぜない。
利用目的：相談、契約前、対応履歴などを一つに絞る。
原文の保管先：回答行や添付ファイルへ戻れる場所を書く。
確認予定日：次に人が確認する日。根拠も残す。
終了状態：対応中、完了、対象外、保留を分ける。
影響：個人情報、契約、金額、顧客対応などを確認する。
確認者：削除や保管延長を判断する人を置く。
処理結果：保管継続、期限更新、手続き済み、要確認など。
処理日と理由：いつ、なぜその結果にしたかを書く。

例えば、A-001は対応完了で確認予定日が来ているため確認待ち、A-002は保留中で期限がないため期限不明、A-003は契約前の相談で根拠の確認が必要なため期限不明、とします。A-004は終了状態と担当者が確認済み、A-005は案件IDが重複しているため、いずれも手続き済みにはしません。

5手順で確認キューを運用する

一度台帳を作って終わりにせず、毎回同じ順番で確認します。

目的を決める：何のために受付ログを残すかを案件ごとに確認します。目的が同じでない行を一つの期限にまとめません。
原文へ戻る：案件ID、受付日時、回答本文、添付の場所を照合します。管理列だけで削除可否を決めません。
状態を付ける：確認予定日と終了状態から確認待ち、期限不明、手続き済みの候補へ分けます。
人が処理する：確認者が保存根拠、例外、契約や個人情報への影響を確認し、結果と理由を書きます。
次回へ戻す：期限更新や保管継続なら次の確認日を設定し、未確定なら不足項目と戻し先を残します。

GASなどで確認候補を抽出する場合も、抽出は通知と一覧化までに留めます。自動削除を実行する前に、確認者の入力、対象外条件、復旧できない処理の扱いを確認してください。入力日付のタイムゾーンや空欄を、環境ごとに同じ意味として扱えるかもテストします。

公開前・運用開始前のチェックリスト

フォームの原文と管理用台帳を分けた
案件IDの空欄・重複・形式不正を確認できる
利用目的と終了状態を一件ずつ説明できる
確認予定日が空欄の行を期限到来と混同しない
確認待ちと期限不明のキューを分けた
原文と添付の保管先へ戻れる
確認者と代理確認者を決めた
契約、個人情報、金額、顧客対応の例外を止められる
処理結果、理由、処理日が残る
次回レビュー日と未確定事項を引き継げる

一つでも空欄があるなら、削除や期限延長を自動化する前に、その空欄を確認キューへ戻します。特に確認者が決まっていない行を「担当者が見れば分かる」と扱わないことが大切です。担当者が休んだ時、次の人が何を見て判断すればよいかが残っていなければ、運用は再現できません。

FAQ：受付ログの保管期限レビュー

受付ログは期限が来たら自動削除すればよいですか？

自動削除を先に決めず、利用目的、終了状態、確認者、例外を確認キューへ分けます。契約や対応履歴に関係するものは人が確認してから処理します。

確認予定日が空欄の受付ログはどうしますか？

期限不明として別キューへ出し、利用目的と担当者を確認します。空欄を期限到来として扱わないことが、誤削除を防ぎます。

最初に作る列は何ですか？

案件ID、受付日、利用目的、原文の保管先、確認予定日、終了状態、影響、確認者、処理結果、処理日を分けます。

AIで受付ログを整理できますか？

分類の下書きには使えますが、削除や保管延長の決定は人が行います。個人情報や契約情報を入力する範囲と、原文へ戻る方法を先に決めてください。

無料診断で、受付業務の戻し先を整理する

受付ログの保管見直しは、削除件数を増やす作業ではありません。目的、状態、確認者、例外、次回日を揃え、担当者が変わっても「どこまで確認できたか」を渡せるようにする作業です。

Miraigentの無料AI導入診断では、フォーム受付、原文の保管、確認作業、人が判断する境界、次の担当者への戻し先を整理できます。まずは最近の受付5件を選び、確認予定日と確認者の空欄を見つけるところから始めてください。