マッチングアプリの年齢確認を設計する：事業者篇

法令の確認と事業の設計を分ける

日本のインターネット異性紹介事業に該当するサービスでは、18歳未満の利用に起因する被害を防ぐため、法第11条に基づく確認が必要になる。警察庁の解釈基準は、書き込みの掲載や閲覧、相互連絡など、利用者に開放する機能に応じて確認する場面を示している。事業の該当性はアプリの名前ではなく、実際の機能で判断する。

最初に分けたいのは年齢確認と本人性の確認だ。前者は18歳未満ではないことを確かめる。後者は、例えば提出書類の顔写真とその場で撮った顔を照合し、提出者との一致を調べる。自撮りと顔照合は後者を強める選択肢であり、年齢確認の法定方式すべてに必須ではない。逆に、年齢だけ確認できても、なりすましや不正利用が消えるわけではない。

法令が認める方法を先に押さえる

2026年4月改正後の施行規則には、通常の年齢確認として次の七つの経路がある。ここでいう「方式」は法令上の経路であり、画面や審査をどう作るかという実装方式とは別だ。

連絡先や会う日時・場所などの特定情報を扱わない利用形態には、自己申告で足りる限定的な例外もある。通常のメッセージ機能まで開放する設計に、その例外をそのまま当てはめない。同じ利用過程で一度確認済みなら、毎画面で再提出させる必要もない。

カードの券面情報には、方式によって個人番号を含むデータもある。年齢確認に必要な生年月日を扱う設計と、不要な番号まで収集・保管しない設計を分けて考える。

確認方式を費用と負荷で比較する

実装としては、法令上の方式に撮影・審査・外部サービスを組み合わせる。「eKYC」はオンラインでの確認手続きの総称として使われ、顔照合を必ず意味する言葉ではない。次の表は、導入を検討する際に比較すべき項目を並べたものだ。難度は利用する製品や既存システムで変わるため、順位ではなく必要な準備を示す。

横にスクロールして比較できます

公表価格の一例として、Liquidのベーシックは税抜で初期5万円、月額固定3万円、書類撮影のみ50円/件、書類と容貌の撮影150円/件と案内する^*1。仮に月1,000件の撮影なら、固定費と従量費の計算上は前者が月8万円、後者が月18万円。初期費、再提出、社内工数、保管、追加機能は別だ。同社は法令対応や大規模マッチングサービスをカスタムプランの想定先にも挙げており、ベーシックの表示額で法定確認に対応できるとは限らない。契約前に対象となる施行規則の方式、審査範囲、保存先、例外対応、料金を同じ見積書で確かめる。

*1　Liquidの公表料金を2026/10/01に確認。上の月額は掲載単価からの計算例で、契約見積もりではない。

マイナンバーカードの公的個人認証は、デジタル庁が署名用20円/件、利用者証明用2円/件の検証手数料と、当面の無料措置を案内している^*2。これを導入総額とみなせない。カード読取、検証者の要件、連携先への支払い、画面実装、サポートは別に見積もる。自社目視は「1件いくら」と先に決めず、実測した処理時間×担当者の実際の人件費＋再提出・監督・保管費で見積もる。

*2　デジタル庁の公表条件を2026/10/01に確認。無料措置の対象・期間は契約時点で再確認する。

目視審査は業務フローまで設計する

目視なら始めやすそうに見えても、撮影から判定までを人任せにすると審査が止まる。少なくとも次の順番で運用を定義したい。

利用者の待ち時間を縮めるには、撮り直し理由を具体的に伝え、確認済みの機能と未開放の機能を分けて示すことも重要だ。自動審査を入れても、読み取り失敗や不正の疑いを扱う担当は残る。

Webとアプリで実装を分けて考える

ブラウザではファイル選択やカメラ撮影を入口にできるが、端末・ブラウザで動きが違う。PC利用者にはスマートフォンへの切替やファイル送信、外部認証アプリへの遷移を案内する。Web NFCだけでマイナンバーカードの必要な情報を直接読み取れると想定せず、認証アプリ連携または専用の実装を選ぶ。

ネイティブアプリではiOS・Androidそれぞれのカメラ/NFC APIやeKYC SDKを使える。権限拒否、IC読取の中断、外部アプリから戻らない場合、OS更新を実機で試す。アプリ内で完結するかより、再開できるかと代替経路があるかを重視したい。

横にスクロールして比較できます

どちらの入口でも、判定結果は共通のサーバーに集める。アップロードURLの期限、通信の保護、審査担当者の権限、検証結果と元画像の分離、状態変更の履歴、退会時の削除を設計する。画面だけでメッセージボタンを隠しても、APIが未確認者の送信を受け付ければ制限にならない。

顔照合は追加の選択肢

書類の顔写真とその場で撮った顔を比べる方法は、書類の持ち主かを確かめる助けになる。ただし、顔から年齢が確定するわけではない。写真の品質、端末、照合方式によって誤って一致・不一致と判定する可能性がある。顔照合を採用するなら、誤判定の再審査と代替手段を用意する。

判断の順序は、まず法定の年齢確認で必要な情報を定め、次に、なりすまし対策として顔照合を足す根拠があるかを決めることだ。容貌画像や顔特徴を取るなら、目的、委託先、閲覧者、保存期間、削除の扱いを設計し、利用者への説明を整えたい。米国NISTの顔照合評価は性能差や誤判定を考える参考になるが、日本の年齢確認に顔照合を義務づける資料ではない。

主流サービスは何を選んでいるか

公式ヘルプを同じ目線で読むと、確認の入口は一つに収束していない。各社の案内は変わり得るため、ここでは2026/10/01に確認した公表内容だけを比べる。

横にスクロールして比較できます

この表は各社の公開手順の比較であり、審査精度、内部コスト、法的適合性を評価したものではない。利用者がどこで離脱するか、何日画像を残すかまで同じ表から推定できない。

書類を預かる責任を考える

2026年9月のタイムズカーWebサイトへの不正アクセスでは、約660万アカウントの情報が第三者に取得され、うち約160万アカウントで本人確認書類画像の漏えいが確認されたと報じられた^*3。これはカーシェアの事案であり、マッチングアプリや顔照合に起きた事故ではない。報道だけで侵入原因や保存期間の是非も断定できない。

*3　Impress Watchの2026/09/28・2026/09/29の報道を2026/10/01に確認。数値は人数ではなくアカウント数。

それでも、身分証画像を預かる事業者にとっては、漏えい時の影響を設計段階で考える材料になる。取得する部分を絞る、元画像と確認結果を分ける、閲覧権限を限定する、不要になった画像を消す。加えて、委託先の管理、異常検知、事故時の連絡と本人通知の手順を運用まで落とし込む。強い本人確認を選ぶほど、大量の画像や生体情報を保有してよいということにはならない。

開始前のチェックリスト

年齢確認の設計は、強い方式を一つ選んで終わりではない。法定の条件を満たす経路を土台に、本人性の追加確認、利用者の負担、預かる情報の量を一緒に調整することが、運用し続けられる安全につながる。