mcpField
A
age-gating-services

age-gating-services

github.com/mukul975セキュリティ32342 回インストール32 週間前に更新
リポジトリ

age-gating-services について

子どもの安全と法令遵守を担うオンラインサービスのチーム向けに、年齢ゲートの設計方法をまとめたスキルです。段階的なアクセス制御、中立的な年齢入力、回避防止、再確認を扱います。

主な機能

  1. 01ハード・ソフト・適応型ゲート
  2. 02中立的な生年月日入力設計
  3. 03年齢ゲートの回避防止策
  4. 04年齢再確認のトリガー
  5. 05法令遵守の確認

活用シーン

  1. 01年齢層に応じた機能の設計
  2. 02未成年者によるゲート回避の防止
  3. 03ゲートでのデータ最小化の計画
  4. 04年齢を再確認する時期の判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill age-gating-services

インストール後、Claude Code で/age-gating-servicesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

詳細

オンラインサービスの年齢制限の実装

概要

年齢制限とは、ユーザーの年齢に応じてオンラインサービスへのアクセスを制限または調整することです。年齢確認の結果をアクセス制御の判断に反映するための仕組みとして機能します。年齢制限には、指定年齢未満のユーザーのアクセスを完全に拒否するハードゲート、若年ユーザー向けに機能を減らしたり保護を強化したりするソフトゲート、年齢層に応じてサービス体験を段階的に調整するアダプティブゲートがあります。効果的な年齢制限では、子どもの保護、ユーザー体験、アクセシビリティ、そして GDPR Art. 8、COPPA、UK Online Safety Act 2023、EU Digital Services Act Art. 28、UK AADC Standard 3 への準拠のバランスを取る必要があります。

年齢ゲートの種類

ハードゲート — アクセスの完全拒否

説明:指定年齢未満のユーザーは、サービスへのアクセスを完全に拒否されます。

使用する場合:

  • 法律で規制されている年齢制限付きの商品やサービス(ギャンブル:18歳以上、アルコールの販売:18歳以上または21歳以上、成人向けコンテンツ:18歳以上)
  • 設計上の対策だけでは子どもへのリスクを十分に軽減できないサービス
  • ビジネスモデルが子どもの安全と根本的に両立しない場合(例:現金取引、暗号資産取引所)

実装要件:

  • アクセスを拒否する理由を明確に説明するメッセージを表示します:「このサービスは18歳以上の方のみご利用いただけます」
  • アクセスを拒否されたユーザーの個人データは収集または保持しません(ゲートの適用に必要な範囲を除く)
  • 可能な場合は、年齢に適した代替サービスの情報を提供します
  • 拒否されたユーザーのデータを、分析を含むいかなる目的にも使用しません

規制上の根拠:

  • UK Gambling Act 2005:リモートギャンブル事業者には年齢確認が義務付けられています
  • UK Online Safety Act 2023 Section 11:プロバイダーは、子どもが最優先で有害なコンテンツに遭遇しないようにしなければなりません
  • EU DSA Art. 28(1):未成年者が利用できるオンラインプラットフォームは、年齢に適した対策を実施しなければなりません
ソフトゲート — 体験の変更

説明:特定の年齢未満と判定されたユーザーはサービスを利用できますが、機能の変更、プライバシー保護の強化、またはコンテンツの制限が適用されます。

使用する場合:

  • 成人と子どもが混在する利用者層を持つサービス
  • 子どもにとってアクセスするメリットがあるものの、追加の保護が必要なサービス
  • 教育プラットフォーム、ソーシャルメディアプラットフォーム、コンテンツ共有サービス

実装:

  • 年齢層を定め、各年齢層に固有の機能セットを設定します
  • 子どものユーザーには、UK AADC の「デフォルトで高いプライバシー」基準を適用します
  • 子どもに高いリスクをもたらす機能を無効にします(知らない相手とのダイレクトメッセージ、公開プロフィール、行動ターゲティング広告)
  • 年齢層に適した機能を有効にします(モデレーション付きフォーラム、教育コンテンツ、年齢に適したおすすめ)

例(BrightPath Learning):

機能8歳未満8~12歳13~15歳16~17歳18歳以上
アカウント作成保護者による管理のみ保護者の承認が必要保護者への通知付きで本人が作成本人が作成本人が作成
プロフィールの公開範囲該当なし非公開のみ非公開(デフォルト)、友達のみも選択可能非公開(デフォルト)、公開も選択可能ユーザーが選択
ダイレクトメッセージ無効定型メッセージのみ連絡先とのモデレーション付きテキストのみ連絡先との無制限のメッセージ制限なし
コンテンツのおすすめ編集者が選定コンテンツベースのアルゴリズムコンテンツベースのアルゴリズムコンテンツ+行動ベース(オプトイン)完全なパーソナライズ
データ共有なしなしなし(デフォルト)同意した場合は任意プライバシーポリシーに従う
広告なしなしコンテキスト広告のみコンテキスト広告のみ行動ターゲティング広告(同意した場合)
アダプティブゲート — 段階的なアクセス

説明:ユーザーの推定年齢または確認済み年齢に基づいてサービスがユーザー体験を動的に調整し、ユーザーの成長に応じて制限を段階的に緩和します。

使用する場面:

  • ユーザーが複数の段階を年齢とともに移行する、長期的な関係を想定したサービス
  • アクセスの変更を急激にせず、シームレスな体験を提供したいプラットフォーム

実装:

  • 年齢に連動した機能の解放スケジュールを定めます
  • 年齢に応じて新しい機能が利用可能になったときは、ユーザー(該当する場合は保護者にも)に通知します
  • 重要な年齢の節目(例:ユーザーが13歳、16歳、18歳に達したとき)に、年齢の再確認を求めます
  • 各機能を解放する理由を、子どもの最善の利益の観点から記録します

中立的な年齢確認プロンプトの設計

中立的な年齢確認プロンプトは、「正しい」回答や適用される年齢の基準を示すことなく、ユーザーの年齢を収集します。これは、簡単な回避を防ぐうえで非常に重要です。

設計原則
  1. 年齢の基準を明かさない:プロンプトで必要な年齢を示してはいけません。「このサービスを利用するには13歳以上である必要があります。生年月日を入力してください。」は避けてください。代わりに「生年月日を入力してください。」とします。

  2. 年齢欄ではなく、生年月日欄を使う:子どもは年齢の基準を超える数字なら何でも入力できるため、「何歳ですか?」という単純な欄より、生年月日のほうがごまかしにくくなります。

  3. 初期値を中立にしたスクロール式の日付選択欄を使う:日付選択欄の初期値で「正しい」回答を示してはいけません。未選択の状態にするか、現在の日付を初期値にします(その場合、年齢は0歳となるため、実際の生年月日の入力を促せます)。

  4. すぐにフィードバックを返さない:ユーザーが年齢の基準に満たない日付を入力した場合、すぐに「年齢が低すぎます」と表示してはいけません。そうすると、子どもに偽の日付を入力し直すよう教えることになります。代わりに登録フローを完了させてから、保護者に知らせます。

  5. 再試行までの待機期間を設ける:年齢を理由にアクセスを拒否した場合、Cookie またはデバイスフィンガープリントを設定し、別の日付による即時の再試行を防ぎます。一般的な最低期間は24時間です。

  6. 誘導する質問をしない:「13歳以上ですか?」のように、子どもに何と答えるべきかを直接伝える質問は避けてください。「何年に生まれましたか?」または「生年月日を入力してください。」を使います。

中立的なプロンプトに関するICOのガイダンス

ICOの年齢確認ガイダンス(AADCと同時に公開)には、次のように記載されています。「年齢の自己申告を利用する場合、子どもが偽の年齢を入力するよう促したり、偽の年齢を簡単に入力できたりする設計にしてはいけません。年齢制限では、必要な年齢を示したり、制限を回避するために子どもが何を入力すればよいかを明らかにしたりしてはいけません。」

COPPAに関するFTCのガイダンス

FTCは、執行措置(例:Musical.ly/TikTok、2019年)において、年齢確認画面は「子どもが偽の年齢を入力するよう促さない」設計でなければならないと述べています。FTCは、中立でない年齢確認画面を、サービスが子どもからデータを収集していると実際に認識していたことを示す証拠とみなします。

回避の防止

技術的な対策
対策説明効果
Cookie によるロックアウトユーザーが年齢ゲートに失敗した際に永続的な Cookie を設定し、24~72 時間の再試行を防止します中程度 — Cookie は削除できます
デバイスフィンガープリンティングブラウザーやデバイスの特性を使用して、同じデバイスからの再試行を識別します中~高 — Cookie より回避が困難です
IP ベースのレート制限一定時間内に同じ IP アドレスから行える年齢ゲートの試行回数を制限します低 — IP アドレスは変わるうえ、共有 IP(学校など)では誤検知が発生します
メール確認ループアカウント作成前にメール確認を必須とします。ゲートに失敗した未成年ユーザーは、同じメールアドレスを再利用できません中程度 — 子どもは新しいメールアドレスを作成できます
段階的なエスカレーション自己申告で失敗した後の再試行では、より高い保証レベルの確認方法を必須とします高 — 回避の難易度が段階的に上がります
最後の砦としての保護者の同意子どもがゲートを回避した場合でも、意味のあるデータ収集を開始する前に保護者の同意を必須とします高 — 確認の負担を保護者に移します
組織的な対策
  1. スタッフのトレーニング:カスタマーサポートスタッフは、年齢のしきい値を明かさずに、年齢に関する問い合わせに対応できるようトレーニングを受ける必要があります
  2. モニタリング:回避を示唆するパターンがないか、登録データを定期的に分析します(例:最低年齢とまったく同じ年齢を申告するユーザーが不自然に多い)
  3. 苦情への対応:子どもが年齢ゲートを回避したことを保護者が報告するためのプロセスを確立します
  4. 定期的な再確認:重要な節目(年次アカウントレビュー、機能のロック解除など)に、ユーザーの年齢を再確認します

再確認のトリガー

年齢ゲートは一度限りの確認にすべきではありません。以下のイベントを再確認のトリガーとします。

トリガー対応根拠
ユーザーが新たな年齢区分に達した(例:13歳、16歳、18歳になった)年齢を確認し、機能のロックを解除または変更しますユーザーの成長に合わせて、年齢に適した体験を提供できます
アカウントの復旧アクセスを復元する前に年齢を確認しますアカウントの共有や、より年齢の低いユーザーへの譲渡を防ぎます
生年月日の変更リクエスト年齢データの変更には保護者の確認を必須とします子どもが自分の年齢を実際より上に変更するのを防ぎます
不審なアクティビティのパターンより高い保証レベルの確認へエスカレーションします行動上の兆候が申告された年齢と一致しません
年次アカウントレビュー年齢の申告が引き続き正確であることを確認します定期的な健全性チェックを行います
機能のアップグレードリクエスト年齢制限のある機能の場合、年齢を確認します年齢制限のある機能への早すぎるアクセスを防ぎます

BrightPath Learning Inc. — 年齢ゲートのアーキテクチャ

登録フロー
User visits brightpathlearning.eu
│
├─ "Enter your date of birth" [scrollable date picker, no default selection]
│
├─ Age calculated from DOB and current date
│
├─ Age >= applicable threshold (country-dependent, 13-16)?
│  ├─ YES → Standard registration flow for independent user
│  │         ├─ Verification: email confirmation
│  │         └─ Experience: Standard features with AADC-compliant defaults
│  │
│  └─ NO → Child registration flow
│           ├─ "Please ask a parent or guardian to help you sign up"
│           ├─ Child enters parent's email address
│           ├─ Parent receives direct notice with consent request
│           ├─ Parent completes verification (credit card micro-transaction)
│           ├─ Parent reviews and approves processing purposes
│           └─ Child account created with age-appropriate restrictions
│
├─ Age < 8?
│  ├─ YES → Parent-managed-only account
│  │         ├─ Parent sets up account entirely
│  │         ├─ Child cannot modify settings
│  │         └─ Simplified interface (illustrated, limited text)
│  │
│  └─ NO → Child-managed account with parental oversight
│           ├─ Child can navigate the app independently
│           ├─ Parent dashboard shows activity and can modify settings
│           └─ Age-appropriate interface (text with icons)
│
└─ User enters DOB indicating age < 5?
   └─ "This app is designed for children aged 5 and older.
       Please come back when you're a bit older!"
       [No data retained from this interaction]
回避防止の実装
  1. Cookie によるロックアウト:ユーザーが入力した生年月日から算出される年齢が5歳未満の場合、安全な Cookie を設定し、48時間の再試行を防止します
  2. しきい値を明かさない:アプリは最低年齢を明示しません。登録フローは年齢に応じてシームレスに変化します
  3. 保護者による最後の砦:子どもが虚偽の生年月日を入力して同意フローを回避した場合でも、メール確認が完了するまではサービスが収集するデータを最小限に抑えます。確認済みのメールアドレスがない場合、アカウントは永続データを保持しないデモモードに制限されます
  4. 異常検知:登録データを毎週自動分析し、申告された生年月日がしきい値と一致するアカウント(例:ちょうど13歳)にフラグを立て、手動レビューを促します

規制コンプライアンスマトリクス

要件GDPR Art. 8COPPAUK AADC Std 3UK OSAEU DSA Art. 28
年齢スクリーニングが必要はいはいはいはいはい
中立的なプロンプトが必要暗黙的FTC ガイダンスICO ガイダンスOfcom の規範暗黙的
基準年齢未満の場合、保護者の同意が必要はいはい推奨該当なし該当なし
制限対象コンテンツへのハードゲートいいえいいえいいえはい(有害なコンテンツ)暗黙的
複合サービス向けのソフトゲート暗黙的暗黙的はいはいはい
再確認が必要暗黙的暗黙的推奨暗黙的暗黙的
ゲートでのデータ最小化Art. 5(1)(c)312.7Standard 8暗黙的暗黙的

よくあるコンプライアンス上の不備

  1. 中立的でない年齢ゲート:最低年齢要件を表示したり、「13歳以上ですか?」というプロンプトを使用したりして、子どもにうそをつく方法を教えてしまう
  2. 回避防止策がない:生年月日を変えて何度でも再試行できるようにする
  3. ゲートを通過する前にデータを収集する:年齢ゲートの完了前に、分析トラッカーを実行したり、広告 Cookie を設定したり、デバイス識別子を収集したりする
  4. ソフトゲートが適切な場面でハードゲートを使用する:機能を変更すれば安全に利用できるサービスへの、子どものアクセスを全面的に拒否する
  5. 再確認を行わない:継続的な確認の仕組みを設けず、最初の年齢申告を恒久的なものとして扱う
  6. コンプライアンスを装うためだけの年齢ゲート:簡単に回避できる年齢ゲートを実装し、それを COPPA または GDPR Art. 8 への完全な準拠として扱う

統合ポイント

  • 年齢確認方法:年齢ゲートは、年齢確認または年齢推定の結果に基づいて制御する適用レイヤーです
  • GDPR の保護者同意:年齢ゲートによって保護者の同意が必要かどうかを判断し、ユーザーを適切な手続きに案内します
  • UK AADC の実装:AADC Standard 3 は年齢に適した適用を求めており、年齢ゲートによって実装されます
  • 子どものプライバシー通知:年齢ゲートの結果に基づいて表示するプライバシー通知のバージョンが決まります
  • 子どものデータ最小化:年齢ゲートの通過時および通過前のデータ収集は、データ最小化の原則に従う必要があります

コメント