本記事はk-IDの提供による寄稿記事です。

ゲームのアカウント運用やコンプライアンス業務に携わっている方であれば、今年に入って「年齢シグナル(age signal)」という言葉を耳にする機会が増えたのではないでしょうか。AppleやGoogle、そのほか一部のプラットフォームが、ユーザーのおおよその年齢をアプリ開発者に伝える仕組みを提供し始めています。これは実際に有用な動きです。すべてのアプリが子どもや保護者に同じ質問を何度も繰り返さずに済むからです。ただし、これはあくまでもプロセスの出発点であり、終着点ではありません。
本記事では、年齢シグナルとは実際に何なのか、現実的にどの程度の情報が得られるのか、そして見落とされがちな「シグナルを受け取ったあとに何をすべきか」について解説します。
k-IDの詳細はこちらそもそも「プラットフォームの年齢シグナル」とは何か
たとえば、12歳の子どもがiPhoneでゲームを起動したとします。このときAppleはアプリに対して、「このユーザーは6歳から12歳の間である」あるいは単に「子どもである」といった情報を渡すことができます。これが年齢シグナルです。生年月日そのものではありませんし、身分証明書で検証された情報でもありません。多くの場合、保護者がデバイスやアカウントをどう設定したか、あるいはユーザーが過去にどこかの画面で何を入力したかに基づいています。
Appleにおけるこの仕組みは「Declared Age Range API」と呼ばれます。同社が2025年に導入し、2026年初頭にブラジル、オーストラリア、シンガポールといった特定の国へと対象を広げた、より大きなツール群の一部です。GoogleもAndroid向けに同様の仕組みを用意しています。狙いは明確で、すべてのアプリが個別に子どもや保護者へ誕生日を尋ねるのではなく、スマートフォンやアプリストアがすでに把握している情報を、アプリ側にそのまま伝えられるようにすることにあります。
プラットフォームがこうした仕組みを整備している背景には、規制当局がそれを期待し始めているという事情があります。たとえば米テキサス州では、アプリストアに対してユーザーの年齢確認と、その情報の開発者への提供を義務づける法律が成立しました。ほかの地域でも同様の動きが進んでいます。つまり年齢シグナルは、「あれば便利な機能」から、コンプライアンス対応を構成する現実的な要素へと変わりつつあるのです。
年齢シグナルが“出発点”にすぎない6つの理由
年齢シグナルが何を与えてくれるのかを冷静に見極めておくと、その上に何を積み上げるべきかが見えてきます。ここでは6つの観点から整理します。
①「要件」ではなく、判断材料のひとつにすぎない
ほとんどの地域で、プラットフォームの年齢シグナルを利用するかどうかは義務ではなく任意です。年齢シグナルに言及している法律――テキサス州はその代表例です――でも、多くは他の確認手段と併せて「考慮すること」を開発者に求めているにとどまり、それ単体でコンプライアンスを満たすとはしていません。ブラジルの子ども保護法はさらに踏み込んでおり、シグナルの裏付けとなる手法が十分に強固である場合にのみ、それを有効なものと認めています。しかも、AppleやGoogleの方式がその基準を満たすかどうかについて、規制当局はまだ見解を示していません。
②すべてのユーザーをカバーできるわけではない
プラットフォームがこのデータを持っているのは、ユーザーが前段階のどこかでオプトインした場合に限られます。そして同意を求める画面が増えるほど、ユーザーが拒否する機会も同じだけ増えていきます。そのため、シグナルをまったく持たないユーザーが一定の割合で必ず発生します。いずれにせよ、そうしたユーザー向けの導線は別途用意しておかなければなりません。
③多くは自己申告に基づいている
これらのシグナルの大半は、保護者やユーザーが過去に一度入力した情報に由来するものであり、身分証明書による確認を経たものではありません。プロダクト上の多くの判断を下す材料としては、これで十分に合理的でしょう。ただし、厳密な本人確認を前提とする法律の下では、あくまで軽量な入力情報のひとつにとどまります。
④「機能」であって「コンプライアンス対応」そのものではない
Appleはこの点を自社の規約でかなり明確にしています。Declared Age Range APIが提供するのは自己申告による年齢範囲であり、そのデータの利用方法(販売、広告ターゲティング、プロファイリングの禁止)を制限したうえで、COPPAや英国のAge Appropriate Design Code、EUのDSAといった法律を遵守する責任はあくまで開発者側にあると明記されています。これはApple側の設計として理にかなったものです。同社は用途を明確に絞ったプロダクトツールを用意し、コンプライアンス上の判断はアプリを開発する側に委ねた、ということになります。
⑤正確な数値ではなく、範囲やラベルにすぎない
「ティーン」や「管理対象アカウント」といった区分は、出発点としては有用です。しかし、その人物が13歳なのか17歳なのかまでは教えてくれません。実際に各年齢で何が許可されているのかを確認していくと、この差が決定的な意味を持つ場面は少なくないのです。
⑥デバイスによって結果が変わりうる
同じ人物であっても、iPhoneではある年齢、Androidタブレットでは別の年齢、自社アプリに直接入力した情報ではさらに別の年齢として現れることがあります。しかも、これらが食い違った場合にどのシグナルを信頼すべきかというルールは、どのプラットフォームも提供していません。その判断は、自社のプロダクト側に委ねられたままなのです。
本番は“年齢がわかったあと”―GDPR・ルートボックス・チャットに見る3つの現実
見落とされがちなのは、まさにここです。仮に完璧に正確な年齢がわかったとしても、それだけでは何をすべきかまではわかりません。年齢は答えではなく、あくまで入力にすぎないからです。ユーザーのおおよその年齢を把握したあと、それが自社の特定のプロダクトにとって何を意味するのか、そしてそのユーザーがいる国で現時点において適用される法律の下で何を意味するのかを、改めて考える必要があります。
具体例を3つ挙げると、このことがより明確になります。

例①:GDPRにおける「15歳」の意味は国によって違う
年齢シグナルが、あるユーザーを15歳だと示しているとします。EUのGDPRでは、未成年者が保護者の同意なしにデータ処理へ同意できる年齢は一律に定められておらず、国によって13歳から16歳までばらつきがあります。そのため、基準が15歳のフランスにいる15歳のユーザーは自身の判断で手続きを進められる一方、基準が16歳のドイツにいる15歳のユーザーには保護者の同意が必要になります。年齢シグナルはどちらのケースでも同一です。しかし、それに基づいて求められる対応はまったく異なります。
例②:ルートボックスは「ティーン」に開放してよいのか
あるいは、ルートボックスを実装したゲームを運営しているとしましょう。ユーザーがティーンだとわかったところで、そもそも未成年にルートボックスの利用が認められているかどうかまではわかりません。未成年向けにルートボックスの仕組みを制限・禁止している国もあれば、確率の開示を義務づける国、まったく規制していない国もあります。年齢シグナルはどこでも同じでも、その下にあるルールブックは国ごとに異なるのです。
例③:チャットは「オフ」にすべきか、「警告」で足りるか
チャット機能のようなシンプルな例でも、事情は変わりません。「ティーン」というシグナルだけでは、アプリがデフォルトで公開チャットをオフにすべきなのか、メッセージを送れる相手を制限すべきなのか、それとも警告表示を出すだけで足りるのかまでは判断できません。英国のAge Appropriate Design Codeのようなルールは、まさにこうした機能単位の判断について具体的に定めていますが、そのロジックは年齢情報そのものには含まれていないのです。
いずれの例でも、年齢を知ること自体は簡単な部分です。本当に大変なのは、その年齢がこの機能で、この市場で、この法律の下で何を可能にし、何を制限するのかを見極めること。そして、ルールが変わり続けるなかで、事業を展開するすべての国において、それを一貫して実行し続けることなのです。
k-IDが担う役割―シグナルを「実行できる判断」へ変える
私たちk-IDが日々のほとんどの時間を費やしているのが、まさにこのレイヤーです。まだ年齢シグナルをお持ちでない場合は、ユーザーの年齢を直接判定するお手伝いができます。すでにApple、Google、あるいはそのほかの仕組みからシグナルを取得している場合は、当社のシステムがそのシグナルを取り込み、同一のコンプライアンスロジックにかけて処理します。どの同意フローを適用すべきか、どの機能を制限すべきか、プラットフォームごとにシグナルが食い違った場合にどう扱うべきか――こうした判断を自動化できます。
いずれの場合も、目指すゴールは同じです。「この人はおおよそ何歳か」という情報を、そのユーザーがどの国にいても正しく機能する、プロダクトが実際に実行できる判断へと変換すること。年齢シグナルは、そのゴールまでの道のりの一部を進めてくれます。しかし、そこから先――受け取ったシグナルをどう扱うかを詰めていく作業にこそ、本当の労力が必要なのです。
k-IDの詳細はこちら





