2026年チェックリスト：連邦法第152-FZに基づくイベント登録フォーム

登録フォームの実践的チェックリスト：どのデータを収集するか、同意とアクセス権をどう分けるか、公開前に何を確認するか。

連邦法第152-FZに基づくイベント登録フォームは、しばしば古いアンケートから始まります。習慣で氏名、連絡先、会社名、パスポート情報、食事の項目が加えられます。そしてその横に1つの共通チェックボックスが置かれます。しかし登録を公開する前に、各フィールドがなぜ必要か、誰がそれを見るか、いつデータを削除するかを決める必要があります。

私たちAventuraでは、データの流れとチームの行動から始めます。登録がカンファレンスやフォーラムの準備に含まれる場合、フォーム、コミュニケーション、入場管理、各部門の業務を1つの計画で結びつけます。

重要：本記事は私たちの組織的な実務を説明するものであり、法的助言ではありません。個人データの管理者とその弁護士が、処理の根拠、同意文の内容、期間、受領者、通知、具体的な運用スキームを承認します。

フォームのチェックは連邦法第152号に基づきどこから始めるべきか？

要点：まず5つの決定から始めましょう。すなわち、誰がオペレーターか、どのような目的でデータを収集するのか、どのような根拠で処理を行うのか、誰に情報を提供するのか、いつ削除するのか、です。これらの回答が確定する前に、デザイナーやプラットフォームにデザインを渡すのは時期尚早です。インターフェースでは、不要な項目、混在した目的、不明確なアクセス権を修正することはできません。

オペレーターとは、目的、データの構成、およびそれらに対する操作を決定する者とみなされます。企業プロジェクトでは、この役割はしばしばイベントの発注者が担います。プラットフォーム、会場、印刷サービス、コールセンター、運営チームは、その指示に基づいてデータを処理することがあります。しかし、役割は契約書上の会社名ではなく、実際のスキームによって決まります。

フォームの前に、簡単な処理台帳をまとめてください：

1. オペレーターである法人と問い合わせ先；
2. 各処理目的を個別の行に記載；
3. 目的を達成するために不可欠な項目；
4. 選択した法的根拠；
5. データに対する操作、システム、および受領者；
6. 処理期間と削除条件；
7. アクセス、変更、および作業完了の責任者。

原則として、オペレーターは処理開始前にRoskomnadzorに通知します。例外は限定的であり、通常のウェブフォームはほとんどの場合これに該当しません。通知に記載された情報、ロシア国民のデータベースの所在地、および越境移転の有無を個別に確認します。

個人データ処理ポリシーは、収集が行われるページからアクセス可能でなければなりません。ページ上のテキスト、委託先との契約、およびオペレーターの通知が異なるプロセスを記述していてはなりません。フォームに食事や送迎が含まれているのに、書類に「サービスの提供」という抽象的な目的のみが記載されている場合、モデルを見直す必要があります。

目的と最小限フィールドのマトリクス

要約: 実務的なフォームはチームのアクションから組み立てます。各フィールドについて、目的、次のアクション、アクセス権を持つ役割、利用期間を明示します。回答を具体的な業務と結びつけられない場合、そのフィールドは削除するか、任意入力にするか、条件分岐のブランチへ移します。共通の参加者カードは、すべての部門に同じテーブルを意味するわけではありません。

私たちはシンプルなテストを使っています: フィールドの目的 -> 誰が使うか -> どの時点で -> 誰がアクセスできるか -> いつ削除するか。これにより「念のため」の収集を排除し、異なる担当者には記録の異なる部分が必要であることを事前に把握できます。

会社名と役職は、B2Bバッジ、議事進行、ネットワーキングに適しています。オープンなイベントでは必須である必要はありません。電話番号は、電話、SMS、緊急連絡の明確なシナリオがある場合に必要です。確認や変更がemailのみで届く場合、2つ目の連絡先フィールドには別途の根拠が必要です。

イベント参加者登録では、ステータス付きの主要レコードを1つ保持します。各部門は短縮版を受け取ります。受付カウンターには入場用データ、ケータリングには食事カテゴリー、ドライバーには交通ルートが利用可能です。余分な情報はこれらの版には含まれません。

フィールドの確認はカードで行うと便利です:

アクションが明示されていない場合、そのフィールドは削除するのが望ましいです。一部の対象者にのみ必要な場合は、条件付きブロックを使用します。一次登録は氏名、連絡先、参加カテゴリーで構成できます。ホテル、送迎、駐車場、入構管理施設用のデータは、必要なサービスを選択した後に表示されます。

インターフェース上でどの同意を分けるべきか

個人データの処理に関する同意、広告メッセージ、データの拡散は、それぞれ異なる目的を果たします。これらをイベント規約の中に隠したり、一つの必須チェックボックスにまとめたりすることはできません。2025年9月1日以降、個人データの処理に関する同意は、その他の確認情報とは別に取得する必要があります。各選択は個別に記録され、個別に確認されます。

無料の公開登録では、処理の根拠として同意を用いることがよくあります。有料参加の場合、契約の締結や履行のために一部のデータが必要となることがあります。クローズドな企業向け形式では、根拠を独自に確認する必要があります。「同意に基づいてすべてを処理します」という万能な文言では、この作業を代替できません。

電子フォームは、本人の行為を証明できるものでなければなりません。私たちはチームに対し、テキストのバージョン、日時、フォームID、登録記録、各選択の結果を保存するよう求めています。チェックボックスは事前にチェックされていてはいけません。ポリシーへのリンクは近くに残しますが、ポリシー自体が特定の参加者の意思に代わるものではありません。

実務上、インターフェースは次のように分けることができます。

1. オペレーターが登録の根拠として同意を用いる場合の、主要な処理のための必須選択
2. 今後のイベントや提案の広告のための、別個の任意選択
3. 氏名、役職、会社名、写真、参加者カードの公開に関する別個の決定
4. 来場規則、オファー、その他の文書は、処理に関する同意とは別に確認される

広告の拒否が登録を妨げてはなりません。事務連絡メールは申し込みを確認し、住所、プログラムの変更、入場規則をお知らせします。次回イベントの告知やパートナーの提案はマーケティング目的に該当します。詳細な境界線については、スパムなしで参加者にSMSを送るの記事で解説しています。

参加者の公開リストには特に注意が必要です。データが不特定多数の者がアクセスできる状態になる場合、オペレーターは拡散に関する別個の同意を確認します。どの情報を、どのリソースで、どのような目的で、どの期間公開するのかを確認します。登録時の一般的なチェックボックスでは、そのような許可は成立しません。

1つのレコードとチームごとに異なるアクセス権

要点：参加者のデータは管理された1つのマスターレコードに保存し、各部門にはその業務に必要な範囲だけを表示するのが望ましいです。これによりチームは重複する表の数を減らし、不要なアクセスを制限できます。ロールには具体的なフィールド、操作、期間を付与します。「組織委員会向け」の完全なエクスポートは、ほぼ常に担当者の業務範囲より広くなります。

当社のビジネスイベントの実務では、1つのフォームが受付登録、バッジ、食事、交通、宿泊を処理します。メッセージとレポートは別途チームが管理します。すべてのプロセスに全列を含む1つのCSVファイルが渡されると、エラーが発生します。

アクセス権はプロジェクト期間中付与されます。手動変更では、実行者、時刻、変更前と変更後の値が保存されます。エクスポートには所有者、目的、日付が付与されます。マスターレコードの更新後、古いコピーが作業バージョンとして残ってはなりません。

任意選択の拒否はチェーン全体に反映されます。参加者が画像公開に関する決定を変更した場合、そのステータスは撮影チームと編集チームに届く必要があります。このような拒否の組織的な流れについては、写真・動画の同意に関する記事で詳しく説明しています。

スポンサーは登録データベース全体を自動的に受け取ることはありません。連絡先は、参加者による別途明確な操作の後、または別の承認されたモデルに基づいて提供されます。プロジェクトでは、集計指標や任意の関心カードを利用できます。選択肢は参加者リストを渡さないスポンサーコミュニケーションの解説にまとめています。

このようなイベント準備の実務スキームが役立つ場合は、「Aventura」のTelegramチャンネルで公開しています。記事では引き続き、機密性の高いフィールドと条件付きフィールドの検証を行います。

パスポート、食事、写真に個別の確認が必要なのはどのような場合か

要点：パスポート、健康情報、画像は習慣的にフォームへ追加してはならない。こうした各項目には具体的な目的、最小限の範囲、限定されたアクセス権、削除期限が必要である。パスポート情報は自動的に特別カテゴリーに該当するわけではないが、しばしば過剰である。健康情報および画像による本人確認は特別な法的枠組みを含む場合がある。

パスポート欄が適切なのは、それがなければ定められた業務を遂行できない場合に限られる。たとえば、管理区域の要件、契約上または輸送上の手続きなどである。まず施設または受入側から書面による必要項目一覧を取得すること。入場時の氏名リストと書類の目視確認だけで足りる場合もある。

書類項目を特定のグループのみに必要な場合は、全員に表示しないこと。入構証を発行する担当者にアクセスを限定する。業務用の登録システムでは、他の役割には元の情報を伏せて承認済みまたは要確認というステータスのみを表示できる。

食事に関する質問はチームの行動を通じて設定する。疾患の列挙を求める代わりに、必要な食事カテゴリーの選択や実務上の条件の記述を促す。自由記述欄には、診断名や不要な医療情報を記載しないよう依頼を添える。

料理の提供には通常、業務用ID、カテゴリー、提供場所、時間で足りる。このプロセスはイベントのケータリングと連携させ、アクセス範囲を限定する必要がある。

顔が写った通常の写真は、画像そのものを理由に生体データとなるわけではない。生体認証の枠組みが生じるのは、事業者が画像を本人確認に利用する場合である。氏名、役職、会社名、写真の公開掲載は別途の課題であり、公開・配布に関する規制の確認が必要である。

家族向けイベントでは、フォームは子どものデータと法定代理人のデータを分ける必要がある。代理人の役割と権限は個別の状況に応じて確認する。出生証明書やパスポートのコピーは、必要がない限り収集しない。健康情報および付き添いに関する情報は、その業務を担当する者のみが閲覧できるようにする。

外国籍であること自体は、通常のバッジのためにパスポートのコピーを必要とする理由にはならない。拡張的な収集を行う場合でも、主催者には別途の目的と確認済みの根拠が必要である。

委託先、プラットフォーム、データ保管場所

会場、登録プラットフォーム、メール配信サービス、ホテル、輸送委託先へのデータ提供もまた、処理の一部に含まれます。管理者は目的、情報の構成、操作を記載します。さらに、セキュリティ、インシデント対応の手順、削除について個別に確認します。「委託先は連邦法第152号を遵守している」という一言では不十分であり、契約書と実際のアクセス権限の図式が必要です。

処理の委託は実際のデータの流れと一致していなければなりません。会場が入場者リストを受け取る場合、そこにアンケートの回答や広告的な属性は必要ありません。ロジスティクス担当者が待ち合わせ時間の間だけ電話番号を必要とする場合、全参加者の連絡先を自動的に渡してはなりません。ロジスティクスと送迎については、あらかじめ縮小したリストを作成し、更新の責任者を定めています。

連邦法第152号第6条第3部に基づく委託では、必ず次を定めます。

1. 個人データの一覧
2. データに対する操作の一覧と処理の目的
3. データを秘密に保持する義務
4. 第18条第5部および第18条の1の要件
5. 要件の遵守を証明する書類を提供する義務
6. 連邦法第152号第19条に基づくセキュリティ要件
7. 第21条第3部の1に定める事態を管理者に通知する義務

さらにプロジェクトでは、再委託先の選定手順、データの返却または削除、バックアップの取り扱い、タスク完了後にデータの消去を証明する方法について合意することを推奨します。これらの条件は実務上のギャップを埋めるのに役立ちますが、第6条第3部の文言上の一覧には含まれません。

インターネットを通じてロシア国民のデータを収集する場合、記録、体系化、蓄積、保存、更新、抽出がどこで行われるかを確認します。ベンダーの「サーバーはロシア国内」という表示だけでは、バックアップ、分析、グローバルな顧客管理システム（CRM）に関する疑問には答えられません。海外のサポート体制と関与する処理者についても個別に確認する必要があります。

外国人または他国の領域への提供には、越境移転の個別評価が必要です。管理者は、こうした提供を開始する前に、受領者、保護措置、およびロスコムナゾルの通知を確認します。要件の現行版と具体的な手順は、管理者の弁護士が確認する必要があります。

ExcelおよびCSVのエクスポートについても個別に確認してください。各ファイルには、所有者、保管場所、目的、保存期間が必要です。業務用チャットやマネージャーの個人用ノートパソコンが、データベースの恒久的な保管庫になってはなりません。レコードの変更後は古いエクスポートを閉じ、目的の達成後は合意された削除を開始します。

フォームを送信から削除までどう検証するか

要点：フォームはデータの全経路をたどって初めて検証済みとみなされます。テストは入力と確認、条件分岐、レコードの変更とエクスポートを網羅します。その後、チームは意思決定の撤回、アクセスの閉鎖、削除を確認します。「申込受付」というメッセージは最初のステップを確認するだけで、担当者が何を見たかは分かりません。

まず一般参加者の立場で始めます：

1. スマートフォンでフォームを開き、キーボードで操作する；
2. 送信前にオペレーターと目的が表示されることを確認する；
3. 基本の必須項目のみ入力する；
4. 広告、公開、スポンサー連絡先は空のままにする；
5. 任意の選択を強制されずに登録する；
6. 日付、場所、データ修正方法が記載された確認を受け取る；
7. レコードがマスターリストに一度だけ表示されることを確認する；
8. バッジ用リストとメッセージ用リストの項目を目的マトリクスと照合する。

次に条件分岐を確認します。送迎を選択した場合、交通関連の項目のみが表示される必要があります。ホテルには宿泊日と宿泊条件が必要ですが、共通フォームに銀行カード情報は不要です。ホテル専用リストの実務的な構成は、イベントのルーミングリストに関する記事で確認できます。

例外を確認します：

• バッジ印刷前後の氏名修正；
• 主要連絡先の変更；
• 再送信と重複；
• 参加のキャンセルと復元；
• 登録をキャンセルせずに広告を拒否；
• 公開に関する決定の変更；
• 締切後の個別オプションの受付終了；
• 誤ったフライトが誤った確認ではなく確認中ステータスになること。

遅い登録は、すでに受付終了したホテル、送迎、特別食を約束してはいけません。フォームは利用可能なオプションを表示し、判断が難しいリクエストは確認のために担当者へ送ります。締切日と例外のロジックは、B2Bイベントの遅い登録に関する記事にまとめています。

インターフェースの後はロールを確認します。各アカウントでログインし、不要な項目が非表示になっていることを確認します。バッジ、セキュリティ、食事、送迎、宿泊用のリストをエクスポートします。列の構成はマトリクスと一致している必要があります。

次に任意の選択を撤回し、関連するすべてのリストを確認します。

最終シナリオでプロジェクトを締めくくります。チームは一時アクセスを無効化し、テストレコードを削除し、承認された削除または匿名化を実行します。一般的な規則として、法律は特定の状況における処理の停止と破棄の期限を定めていますが、具体的な保存マトリクスを「撤回まで」という一言で置き換えることはできません。自動処理の場合、破棄は証明書とログからのエクスポートで確認します。

登録開始前の7つのミス

問題のほとんどはプロセスの混在によって生じます。1つのチェックボックスですべてをカバーし、完全なアンケートがすべての取引先に送られ、広告がサービスメールに紛れ込み、保存期間を誰も設定しません。これらのミスは開始前に見つけられます。確認には、インターフェース・書類・契約書を突き合わせ、テスト登録を経てエクスポートを調べるだけで十分です。

1. すべての判断に1つのチェックボックス。 処理、広告、公開、パートナー、来場規則には個別の確認が必要です。
2. 同意がボタンの中に隠れている。 「申請を送信」のクリックで、複数の書類や目的が気づかれずに承諾されてはいけません。
3. 目的のない必須項目。 生年月日、性別、住所、パスポート、会社名や役職は、過去のテンプレートにあったという理由だけで収集されています。
4. 不明確な運営者。 フォームにはプロジェクトのブランド、ポリシーは別の主体、データベースは第三の組織がアクセス可能になっています。
5. 全員に同じエクスポート。 会場、印刷、ケータリング、交通、マーケティングが完全なCSVを受け取ります。
6. 業務用連絡先が広告用になる。 登録確認後、本人が個別に選択しないまま将来の提案のメール配信に含まれます。
7. 処理の終了がない。 データはCRM、メール、チャット、ローカル表、入退場システム、バックアップに残ります。

受け入れ時の有効な手法：委託先にテスト登録で3つの実操作を実行してもらいましょう。フィールドの変更、ロールに対する表示制限、承認済みシナリオに沿ったレコード削除です。デモンストレーションによって、約束されたアーキテクチャと実際のアーキテクチャの相違がすぐに明らかになります。

ローンチ当日に確認すべきこと

要点：受付開始当日、チームはスマートフォンで、さまざまなロールになりきってフォームを一通り試します。まず文言、必須項目、個別の選択肢を確認します。次にアクセス権、メール、エクスポート、操作ログをチェックします。修正後は、最初のページから担当者側にデータが表示されるまで、全経路を再度たどります。

法的・組織的モデル

• [ ] 運営者が明示され、問い合わせ用の有効な連絡先が記載されている。
• [ ] 各目的が項目、根拠、受領者、保存期間と結びついている。
• [ ] ポリシーがフォームのページから閲覧でき、実際の運用と一致している。
• [ ] Roskomnadzorへの通知とその記載内容を運営者が確認している。
• [ ] データベースの所在地と越境移転の可能性を確認している。
• [ ] 処理者との契約に、データ、処理操作、セキュリティ、削除が明記されている。

項目とインターフェース

• [ ] 必須項目は必要最小限にとどまっている。
• [ ] 条件付きブロックは対象グループにのみ表示される。
• [ ] 処理への同意は独立して用意され、事前にチェックされていない。
• [ ] 広告と配信は、独立した任意の同意として分けられている。
• [ ] 参加者は任意のチェックを入れずにフォームを送信できる。
• [ ] エラーは何を修正すべきかを示し、他の回答を消去しない。
• [ ] 項目ラベルが見え、キーボードフォーカスが分かり、モバイルのボタンが押しやすい。

データとアクセス権

• [ ] マスターレコードは一度だけ作成される。
• [ ] バッジ、警備、食事、交通、ホテルがそれぞれ必要な列のセットを受け取る。
• [ ] 完全エクスポートは権限が制限され、ログに記録される。
• [ ] 手動編集では編集者、時刻、変更内容が保存される。
• [ ] 更新後、古いエクスポートは業務用として使えなくなる。
• [ ] 一時的なロールには無効化日が設定されている。

コミュニケーションと完了

• [ ] 確認メールに日付、場所、次のステップ、修正用の窓口が含まれている。
• [ ] サービスメッセージには、別途の同意なしに広告が含まれていない。
• [ ] 任意の選択を拒否すると、関連するすべてのリストが更新される。
• [ ] 処理停止の請求と広告配信の拒否を受け付ける窓口が機能している。
• [ ] 運営者側と委託先側で削除の責任者が定められている。
• [ ] 破棄には報告書とログが用意されている。

最初のテストグループの後、指摘事項を1つのリストにまとめ、フォームを修正して全経路を再度たどってください。変更後に個別の項目だけを確認しても、全体の再実行の代わりにはなりません。新たな必須項目によって、モバイルのシナリオ、メール、条件分岐が壊れる可能性があるからです。

主催者の責任範囲

要点：イベントチームは、データの流れを分かりやすく設計し、各部門が必要最低限の情報を受け取れることを確認します。個人データの管理者は、処理の目的と手段について決定します。その法務担当者は、法的根拠、同意文書の内容、保存期間、通知、契約スキームを承認します。それぞれの役割は連携して機能しますが、互いの役割を代替するものではありません。

Aventuraでは、項目とステータスの運用マップを作成できます。これには各役割のアクセス権、テストシナリオ、委託先への引き継ぎ、アクセス権の閉鎖が含まれます。私たちは、単一の同意文書をあらゆるイベントの解決策として提示することはありません。公開カンファレンス、社内限定会議、ファミリーデー、ホテル宿泊を伴う旅行では、それぞれ異なるプロセスが生じます。

この作業の実務的な成果はシンプルです。各項目には理由があり、各役割には境界があり、各データ出力には責任者がおり、データには明確なライフサイクルの終わりがあります。その後、管理者と法務担当者がこのスキームを確認し、書類を承認します。

フォーム、会場、コミュニケーション、委託先の業務を連携させる必要がある場合は、ビジネスイベントの開催の形式をご覧ください。登録をプロジェクト全体の計画に組み込み、発注者とその法務担当者による共同確認に備えてプロセスを準備します。

出典

• 基本概念：連邦法第152-FZ号第3条。
• 処理の原則：連邦法第152-FZ号第5条。
• 処理の条件および委託：連邦法第152-FZ号第6条。
• 本人の同意：連邦法第152-FZ号第9条。
• 特別カテゴリーのデータ：連邦法第152-FZ号第10条。
• 配布が許可されたデータ：連邦法第152-FZ号第10.1条。
• 生体認証個人データ：連邦法第152-FZ号第11条。
• 越境移転：連邦法第152-FZ号第12条。
• 通信手段を用いた直接的な販促：連邦法第152-FZ号第15条。
• データ収集とローカライゼーション：連邦法第152-FZ号第18条。
• 事業者のポリシーと措置：連邦法第152-FZ号第18.1条。
• 個人データの安全性：連邦法第152-FZ号第19条。
• 処理の停止および消去：連邦法第152-FZ号第21条。
• Roskomnadzorへの通知：連邦法第152-FZ号第22条。
• 電気通信ネットワークを通じた広告：連邦法第38-FZ号第18条。
• 同意の別途作成：2025年6月24日付連邦法第156-FZ号。
• 消去の確認：2022年10月28日付Roskomnadzor命令第179号。
• 通知の様式：2022年10月28日付Roskomnadzor命令第180号。