年齢認証法は誰に年齢確認を委ねるのか

Linuxのユーザー記録に生年月日項目が追加された

2026年3月18日、複数のLinuxディストリビューションで使われるシステム管理ソフトウェア**systemdの開発コードにbirthDate項目が追加されました。**ユーザー記録に生年月日を保存できるようにする、任意の項目です。この変更だけで、すべてのLinuxユーザーが生年月日を入力しなければならなくなるわけではありません。systemdの変更履歴

systemdを開発したレナート・ペッタリングは、この項目は任意であり、アプリに年齢を伝えるAPIでも、利用ポリシーを強制する仕組みそのものでもないと説明しました。一方、変更の提案者はカリフォルニア州法やコロラド州法案など、年齢確認を求める立法の動きを追加の理由として挙げました。¹法や法案の要求に対応しようとする議論が、オペレーティングシステムのデータ構造にまで影響を及ぼしたわけです。ペッタリングの説明

この論争では、誰が年齢を確認し、アプリにどんな情報を伝え、その作業のコストと責任を誰が負うのかを併せて見る必要があります。子どもの保護という目的に同意していても、実装方式によって個人情報の流れと企業の負担は変わってくるからです。

カリフォルニア州法が求めるのは年齢区分の伝達

カリフォルニア州知事のギャビン・ニューサムは、2025年10月13日にAB-1043に署名しました。この法の運用義務は2027年1月1日から適用されます。オペレーティングシステムとアプリストア、アプリ開発者が年齢情報をやり取りするよう定めた法律です。

オペレーティングシステムの提供者は、アカウントを設定する際に、アカウント所有者が機器利用者の生年月日や年齢を表示できる入力手段を提供しなければなりません。アプリが要求すれば、13歳未満、13〜15歳、16〜17歳、18歳以上という年齢区分をAPIで伝えるよう定めています。APIとは、プログラム同士が情報をやり取りする通路です。この法がアプリに求める情報は、生年月日全体や氏名ではなく年齢区分です。

法はオペレーティングシステムの提供者を、コンピューター・モバイル機器など汎用機器のオペレーティングシステムを開発・許諾・管理する主体として広く定義しています。そのため、WindowsやAndroidのような商用製品だけでなく、Linuxディストリビューションにもどのような義務が生じるのかについて論争が起きています。ボランティアが管理するプロジェクトがどこまで責任を負うべきかも重要な問題です。

アプリ開発者にも義務があります。アプリをダウンロードし実行する際に年齢信号を要求しなければならず、受け取った情報は関連法の遵守に使わなければなりません。オペレーティングシステムとアプリのいずれも、必要最小限の情報のみをやり取りすべきで、法が求めていない目的で第三者に提供してはなりません。機器を起動するたびにすべてのアプリに実名や生年月日を配信せよという規定ではありません。AB-1043原文

他の地域でも似たような議論が進んでいます。コロラド州のSB26-051は2026年3月3日に上院を28対7で通過し、下院での審議に進みました。ただし州ごとに、対象がオペレーティングシステムなのかアプリストアなのか、自己申告を受け付けるのか別途の検証を求めるのかが異なります。審議中の法案と、すでに成立した法、実際に施行されている義務を分けて読む必要があります。コロラド州議会の記録

確認手続きをオペレーティングシステムやアプリストアに任せれば、個々のアプリは同じ検証を繰り返す負担を減らせます。その代わり、その役割を担う事業者や開発プロジェクトには新たな義務が生じます。カリフォルニア州法のように、アプリ開発者にも信号を要求し活用する義務を課す場合があるため、ソーシャルメディア企業がすべて規制の対象外になるとは言えません。

Metaはアプリストアが認証を担う方式を支持

Metaはアプリストアで年齢を確認し、保護者の承認を得る方式を公然と支持してきました。複数のアプリで同じ手続きを繰り返さなくて済み、保護者が管理しやすいという説明です。この方式が採用されれば、AppleやGoogleのようなアプリストア運営者が確認手続きを担うことになるという事業上の利害関係もあります。Metaの2025年の立場

立法過程に関与していたという報道もあります。2024年10月のPluribus Newsの取材で、ルイジアナ州のキム・カーバー議員は、Metaのロビイストがアプリストアの年齢確認条項の文言を持ち込んだと述べました。当時の条項はApple側の反対ロビー活動を経て、最終案から外れたと報じられています。これは2025年のHB-570ではなく、その前年の立法過程に関する話です。Pluribus Newsの報道

2025年7月、Bloombergは、Metaが**Digital Childhood Alliance（DCA）**に資金を提供していると報じました。アプリストアの年齢確認義務を推進する団体と技術企業の間の利害関係を検討する理由となる報道です。Bloombergの報道

公開記録を集めたOSINT調査²も、Metaと関連団体のロビー活動を追跡しています。こうした資料は、登録済みのロビイストや法案、報告された支出を調べていく出発点になり得ます。ただし、企業の総ロビー費用を特定の一つの法案のコストとして計算したり、ロビイストの数だけで法案の文言を支配したと断定するには、追加の根拠が必要です。

団体の税務申告記録も同様です。IRSの990-N簡易申告は、通常年間総収入が5万ドル以下の小規模団体のための手続きです。その申告があるという事実だけで、実際の収入が2万5千ドル未満だと計算したり、別の非公開の資金経路があると結論づけたりすることはできません。ロビー記録の「モニタリング中」「修正済み」といった状態表示も、それ自体で賛否や隠れた意図を証明するものではありません。IRSの案内

過去の事例も参考になります。Washington Postは2022年、Metaがコンサルティング会社Targeted Victoryを通じて、TikTokを子どもにとって危険なサービスとして描くキャンペーンを行っていたと報じました。子どもの安全をめぐる論争に、競合企業の利害が介入し得ることを示した事例です。ただし、この過去のキャンペーンだけで、今のすべての年齢認証法が同じ目的で作られたと判断することはできません。

私は、企業が子どもの安全を語るとき、その提案がコストと責任をどこに配分するのかも併せて見る必要があると考えます。政策の効果を評価するには、企業の主張だけでなく、法の条文と実際の実装、ロビー記録を合わせて読む必要があります。

EUは必要な年齢要件のみを証明する技術を開発

EUでは、プラットフォームの子ども保護義務と、個人情報の開示を抑えた年齢確認技術を併せて推進しています。

EUのデジタルサービス法（DSA）第28条は、未成年者がアクセスできるオンラインプラットフォームに適切かつ比例的な保護措置を求めています。この条項は、月間利用者4,500万人以上の超大規模プラットフォームだけを対象とした一律の年齢認証義務ではありません。小規模事業者には別途の例外があり、超大規模プラットフォームにはリスク評価と緩和の義務が追加されます。第28条自体も、未成年者かどうかを判断するために追加の個人情報を処理するよう強制するものではないと明記しています。DSA原文

EU欧州委員会が開発する年齢確認アプリの基本設計は、サービスに対して18歳以上であることの証明のみを提示するというものです。証明の発行を受ける際には本人確認が必要になる場合がありますが、その後訪れるサービスには氏名や正確な生年月日を伝えないよう設計されています。発行者がどのサービスで証明が使われたかを知り得ないようにし、サービス側が複数回の利用を紐づけにくくすることも目標です。

参照実装はオープンソースで公開されています。2025年7月に最初のバージョン、10月に2番目のバージョンが公開され、デンマーク・ギリシャ・スペイン・フランス・イタリアなどが参加して試験を行っています。この年齢確認アプリは、将来的に欧州デジタルアイデンティティウォレット（EUDI Wallet）と互換性を持たせるべく開発されている別事業です。2026年1月に公開されたAndroid向け実装には、ゼロ知識証明（ZKP）³も追加されました。EUの2025年10月発表、開発ロードマップ

ゼロ知識証明は情報開示を抑えるうえで有用ですが、それだけでサービス全体の個人情報保護を保証するわけではありません。機器やアプリがどのような記録を残すのか、証明の発行者と検証者がどのような情報を見られるのかまで確認する必要があります。対応機器の外にいる利用者が排除されないかどうかも見ておくべきです。

カリフォルニア州法とEUの技術設計は、そもそも比較する対象が異なります。一方はオペレーティングシステムやアプリなどに課す法的義務であり、もう一方は年齢を証明する具体的な実装案です。

どちらのアプローチにも、サービスに伝える情報を制限するという要素があります。カリフォルニア州法もアプリに、生年月日全体の代わりに年齢区分を送るよう定めています。EUの実装はこれに加えて、証明の発行と利用を分離し、利用履歴を紐づけにくくする技術を組み合わせています。どちらの場合も、収集する情報と共有する情報、残る記録をそれぞれ確認しなければ、個人情報保護のレベルを評価することはできません。

Oswarldの視点

私はこの問題において、年齢確認技術をうまく作ることと同じくらい、その技術によってどんな被害を減らそうとしているのかを明確にすることが重要だと考えます。

この記事を書くきっかけになったJaromilの文章は、コンテンツを分類・遮断することと、保護者の判断を区別しています。特定のコンテンツを制限する規則と、子どもの状況を知る大人が利用時間や例外を決めることは異なる、という指摘です。年齢情報一つで、この二つの役割を両方代替するのは難しいという指摘に同意します。

GTM戦略を策定する中で、複雑な社会問題を一つの技術的解決策として説明し売り込む手法を数え切れないほど見てきました。だからこそ、年齢確認を子ども保護の答えとして提示するときも、実際に被害が発生する地点とどれだけつながっているのかを、まず確かめるようになります。年齢をより正確に把握すれば減る被害は何か、別の対策が必要な被害は何かを分けて見る必要があります。

有害コンテンツそのものだけでなく、レコメンドアルゴリズムや、利用者を特定の選択へ誘導するダークパターン⁴、利用を続けさせるサービス設計も子どもに影響を与える可能性があります。年齢確認は保護措置を適用するうえで役立つことがありますが、コンテンツやレコメンド方式をどう変えるかについての議論を代替することはできません。

また、年齢確認のために作られた機能が、後に別の身元情報を確認する用途に使われる可能性にも警戒すべきです。現行の法がそうした拡張を命じているという意味ではありません。設計の当初から利用目的や情報の保存期間、第三者提供の範囲を狭く定め、実際にそれが守られているかを確認しなければならないという意味です。私は、子どもの保護を強化しつつも、不必要な身元確認は減らす方向が必要だと考えます。

おわりに

年齢認証法を見るときは、法律の名称よりも、そこで求められている行動を読み取る必要があります。誰が情報を収集し、アプリに何を伝えるのか、アプリはその情報をどう使うべきなのかによって、効果と負担は変わってきます。

Metaをはじめとする企業の立法への関与も、同じ基準で見るべきです。確認手続きを他の事業者に委ねるべきだという提案にどんな利点があり、責任がどのように分かれるのかを検討できます。ロビー活動があったという事実と、法律が特定の企業に免責を与えているという主張は、それぞれ別の根拠が必要です。

EUの年齢証明技術は、サービスに不必要な身元情報を渡さない方法を示しています。こうした設計が実際に追跡を防げるのか、複数の機器で使えるのか、保護効果があるのかは、実装と運用を通じて確認する必要があります。

私は、年齢確認の便利さだけで政策を判断してほしくないと思います。子どもが受ける被害をどれだけ減らすのかと、その過程ですべての利用者にどのような情報提供を求めるのかを、併せて評価すべきだと考えます。

参考資料と関連リンク

• Jaromil、Do Not Turn Child Protection Into Internet Access Control、2026年。コンテンツ制限と保護者の判断の違いを論じる記事です。
• California Legislature、AB-1043、2025年。年齢区分の伝達と開発者の義務、情報利用の制限を確認できます。
• systemd、birthDate追加の提案、ペッタリングの説明、2026年。任意保存項目の範囲を説明しています。
• Meta、Working With Parents to Enroll Teens Into Teen Accounts、2025年。アプリストアで年齢確認と保護者の承認を得ようという同社の立場です。
• Pluribus News、Meta lobbies for app store age verification laws、2024年。カーバー議員が説明した法案文言の提案とロビー活動の過程です。
• upper-up、Meta Lobbying and Other Findings、2026年。公開記録を追跡した個人調査で、個々の主張と一次資料を対照しながら読むべき資料です。
• European Union、Digital Services Act、2022年。第19条・第28条・第34〜35条で、適用範囲と未成年者保護義務を確認できます。
• European Commission、The Age Verification Manual、2026年。EUの年齢証明手続きと開発中の実装を説明しています。
• Washington Post、Facebook paid Republican strategy firm to malign TikTok、2022年。Targeted Victoryを通じたキャンペーンについての報道です。

筆者のアン・グァンソプ（安光涉）は世宗大学校経営学科教授であり、INLEVEL9のリードコンサルタントである。大学では経営データ管理、ビジネスアナリティクスなど統計およびデータ分析を教える一方、現場ではGTM戦略とAI戦略コンサルティングを率い、技術とビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ（HEMA）研究で学術論文を発表し、日々グローバルなAI論文をキュレーションするDaily Arxivプロジェクトを運営している。高麗大学校技術経営専門大学院の修士課程とKMBAを卒業した。著書に『考えを委ねる人々：ホモ・ブレインレス』がある。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

각주

1. 年齢確認・保証（Age Assurance）とは、年齢を自己申告する方式や、推定・検証する方式を包括する概念です。法律ごとに求められる確認レベルと担当主体は異なります。 ↩

2. OSINT（Open Source Intelligence）とは、ニュースや公的記録など公開された情報を収集・分析する調査手法です。公開情報に基づいているという事実だけで、すべての分析結果が検証されたことになるわけではありません。 ↩

3. ゼロ知識証明（Zero-Knowledge Proof）とは、秘密情報そのものを明かさずに、ある命題が真であることを検証させる暗号学的な手法です。年齢確認においては、詳細な生年月日を公開せずに、必要な年齢条件を満たしていることを証明するために活用できます。 ↩

4. ダークパターン（Dark Pattern）とは、利用者を欺いたり、望まない行動へ誘導する画面・手続きの設計を指します。同意の拒否や、サブスクリプションの解約を難しくする手法などがこれに該当します。 ↩