行政サービスも金融サービスも、窓口に足を運ばずに完結する場面が広がっています。申し込みから契約まで画面の中で完結すると、実在する人物であることの確認を、対面での目視に頼ることができなくなります。そこに、なりすましを試みる側にとっての新しい入口が生まれています。この記事では、デジタル本人確認・eKYCの案件でエンジニアがどこに関わり、何を設計するのかを、保証レベルという考え方を軸に整理します。

1. なぜいまデジタル本人確認・eKYCの案件が増えているのか

手続きのオンライン化が、なりすましの入口を広げている

銀行口座の開設、電子契約サービスへの入会、行政の各種申請など、対面が前提だった手続きが次々にオンラインへ置き換わっています。手続きの手前にあるのが本人確認で、なりすましを防ぐ最初の関門になります。窓口の職員が身分証と顔を見比べる代わりに、システムがその役割を担うようになったことで、この関門を設計する仕事そのものが、いまエンジニアに求められる領域になっています。

本人確認書類の偽造やフィッシング攻撃に加え、生成AIを悪用したディープフェイクによるなりすましなど、脅威は高度化しています⁴。画像や音声を模倣する技術が身近になったことで、書類の見た目を確認するだけの手法は追いつきにくくなっています。対策を後から足すのではなく、設計の段階から組み込む発想が求められる場面が増えています。

DS-511が示す、本人確認を設計するための共通の地図

こうした変化の中で、本人確認の設計をどう進めればよいか、拠りどころとなる資料が公開されました。DS-511は、行政手続等での本人確認について、デジタルアイデンティティの枠組み・対策基準・リスク評価手順・本人確認手法の選定方法を示した標準ガイドラインです¹。行政向けの資料ではありますが、身元確認と当人認証を切り分けて考える構成は、民間のサービス設計にもそのまま参考になります。

案件によって要件がまちまちに見えるのは、参照する基準がばらばらだからです。DS-511のような共通の地図を持っておくと、初めて関わる案件でも「今どの工程を設計しているのか」を素早く見極められます。個々の技術要素を覚えることよりも、この地図の骨格を理解しておくことのほうが、案件ごとに変わる要件を読み解く力になります。次の章では、その骨格である身元確認と当人認証の関係を見ていきます。

図の作成：Remogu編集部。本人確認をめぐる脅威の高度化の流れを整理したもので、統計データではありません

2. 本人確認の骨格＝身元確認と当人認証

「誰であるか」を確かめる身元確認と、「本人であるか」を確かめる当人認証

本人確認と聞くと、ひとつの工程のように感じられるかもしれません。実際には、性格の異なる2つの工程を束ねた言葉です。本人確認は、身元確認（Identity Proofing）と当人認証（Authentication）に分けて整理されます³。設計の要件定義でこの2つを区別せずに話を進めると、後になって「どちらの工程の話をしていたのか」がずれてしまい、手戻りの原因になります。

身元確認は、最初にこの人が誰であるかを確かめる工程です。書類や公的な記録と突き合わせて行われることが一般的で、登録や契約といった節目で一度行われます。一方の当人認証は、名乗っている本人が、今アクセスしている本人と一致するかを確かめる工程です。ログインのたびに繰り返される、継続的な確認になります。開発の現場では、身元確認をオンボーディングの一部として、当人認証をログイン基盤の一部として、別々のチームが担当することも珍しくありません。

この2つを同じものとして設計してしまうと、最初の登録は厳重なのに、日々のログインは形だけという食い違いが起こりやすくなります。1回の身元確認よりも、繰り返される当人認証のほうが、日常のセキュリティを左右する場面は増えます。

身元確認と当人認証、それぞれの役割

エンジニアの視点で見ると、この2つの工程は求められる技術も設計の勘所も異なります。身元確認は書類の読み取りや外部の記録との照合精度が問われ、当人認証はフィッシングへの耐性と利便性の両立が問われます。案件の概要やRFPを読むときも、この2つのどちらを主に扱う案件なのかを見極めることで、必要になる技術スタックの見当がつきやすくなります。次の表に、それぞれの目的とタイミング、エンジニアとしての関わり方を整理しました。

観点	身元確認（Identity Proofing）	当人認証（Authentication）
目的	この人が誰であるかを確かめる	名乗る本人と、今アクセスしている本人が一致するかを確かめる
タイミング	登録や契約などの節目で一度	ログインや重要な操作のたびに繰り返す
主な手がかり	本人確認書類や公的な記録との突き合わせ	パスワード・生体情報・所持しているデバイスなど
エンジニアの関わり方	書類読み取りや記録照合の仕組みづくり	認証方式の設計とフィッシングへの耐性の確保

役割の違いを意識して設計に関わることが、次に説明する保証レベルの考え方にもつながります。

図の作成：Remogu編集部。身元確認と当人認証の関係を整理したもので、統計データではありません

3. 保証レベルの考え方

保証レベルは「高ければ高いほど良い」わけではない

本人確認をどこまで厳しくするか、判断に迷う場面があります。書類を1点求めるだけでよいのか、複数の証跡を突き合わせる形にするのか、判断の材料が無いまま設計を進めてしまう案件も見かけます。その判断の基準になるのが、保証レベルという考え方です。保証レベルとは、本人確認の確からしさを段階的に表現する概念です²。

厳しくすればするほど安全になると考えたくなりますが、それは正確ではありません。必要以上に厳格な本人確認手法を取り入れることは、プライバシー等の観点で望ましくない場合があります⁵。書類の提出項目を増やしたり、認証の手順を重ねたりすることは、離脱や負担の増加という別のリスクを生みます。

厳格さを積み増すことよりも、その手続きが背負うリスクに見合った確認を選ぶことのほうが、設計としての一貫性を持ちます。過不足のない確認の程度を選ぶことが、保証レベルという考え方の核になります。設計に関わるときは、事業側が想定しているリスクを先に聞き出し、確認の手順を後から積み増す形にしないことが、手戻りを減らす進め方になります。

リスクに応じた保証レベルの選び方

保証レベルを考えるときは、手続きの先にあるリスクの大きさを起点にします。誤りや不正が起きたときの影響が小さい場面と、金銭や本人以外にも影響が及ぶ場面とでは、選ぶ確認の程度が変わります。同じサービスの中でも、操作ごとにリスクの重さは変わるため、サービス全体を一律の保証レベルで覆う設計は、かえって使い勝手を損ねることがあります。次の表は、場面の例とリスク、確認の程度の考え方を整理したものです。

場面の例	想定されるリスク	確認の程度の考え方
会員情報を閲覧するだけの操作	誤りが起きても影響は限定的	簡易な確認で足りる場合が多い
金銭のやり取りを伴う手続き	誤りや不正のコストが大きい	相応に厳格な確認を検討する
本人以外にも影響が及ぶ重要な手続き	取り返しがつきにくい	慎重に確認を重ねる
確認を必要以上に厳しくする場合	プライバシー等の観点で不利になる場合がある5	過不足のない設計を心がける

この整理からわかるのは、確認の程度は一律に決まるものではなく、案件ごとに考え直す必要があるということです。設計の初期段階で、この整理を関係者と共有しておくことが、後戻りの少ない設計につながります。表計算のように機械的に当てはめるのではなく、事業の性質や利用者層を踏まえて確認の程度を選ぶ視点が、エンジニアに求められています。

図の作成：Remogu編集部。保証レベルの考え方を整理したもので、統計データではありません

4. フィッシング・ディープフェイクに強い設計

パスワードとワンタイムコードだけでは、守りきれない場面が増えている

当人認証というと、パスワードやワンタイムコードを思い浮かべる場面が一般的です。ただ、これらの方式は、精巧に作られたフィッシングサイトの前では効果を失う場面があります。利用者が入力した情報がそのまま偽のサイトへ渡ってしまえば、パスワードの複雑さもワンタイムコードの有効期限の短さも、防御としての意味を失います。本人確認書類の偽造やフィッシング攻撃に加え、生成AIを悪用したディープフェイクによるなりすましなど、脅威は高度化しています⁴。

こうした流れを受けて、認証方式そのものを見直す動きも進んでいます。米国NISTのデジタルアイデンティティガイドラインSP 800-63が2025年8月に全面改定されるなど、国際的な見直しが進んでいます⁶。特定の技術を指定するというより、フィッシングに強い認証方式へ置き換えていく方向性が、各国で共有されつつあります。

知識だけで確認する方式よりも、所持しているデバイスや生体情報を組み合わせた方式のほうが、フィッシングへの耐性は高まります。ディープフェイクについても、静止した画像だけで判定するのではなく、複数の手がかりを組み合わせて検知する設計が求められます。認証を強めるほど利用者の負担も増えるため、どこまでの耐性を求めるかは、3章で触れた保証レベルの考え方に立ち戻って判断することになります。

フィッシング・ディープフェイクへの対策の観点

フィッシングとディープフェイクは性質の異なる脅威ですが、どちらも本人であるかのように見せかけるという点で共通しています。片方の対策だけを厚くしても、もう片方の入口が空いたままでは、なりすましのリスクは残ります。次の表に、それぞれの課題と見直しの方向を整理しました。設計に関わるときは、この3つの観点をあわせて検討することが手がかりになります。

観点	従来の課題	見直しの方向
認証方式	パスワードは詐取されやすい	フィッシングに強い認証方式へ置き換える
なりすましの検知	画像だけでは見分けにくい	複数の手がかりを組み合わせて検知する
標準への追随	各国の基準が個別に動いてきた	国際的な見直しの動きを把握し続ける6

図の作成：Remogu編集部。フィッシング・ディープフェイクへの対策の観点を整理したもので、統計データではありません

5. リモート・フリーランス案件でどう関わるか

認証基盤・ID連携の経験が活きる場面

デジタル本人確認・eKYCの案件は、行政や金融に限らず、会員登録やオンライン契約を扱うサービス全般に広がっています。Web開発や業務システムの構築、認証基盤の運用に携わってきた経験は、身元確認と当人認証の設計に、そのまま活かせる場面があります。案件の入口も、新規のサービス立ち上げに限らず、既存の認証基盤を見直す改修案件や、フィッシング対策の強化を目的とした案件など、さまざまな形で見つかります。

求められるのは、法令の細部を覚えることよりも、リスクに応じて確認の程度を設計する視点です。データ連携の経験があれば、身元確認で得た情報をどう安全に受け渡すかという設計にも関われます。セキュリティ設計の経験があれば、フィッシングやディープフェイクへの耐性を高める認証方式の選定にも関われます。要件定義の段階から関わる案件では、事業側の担当者にリスクの考え方を説明する役割を任されることもあり、技術と業務の橋渡しになる経験を積めます。

フェデレーションによるID連携という視点

本人確認の仕組みを、サービスごとに一から作るとは限りません。フェデレーションと呼ばれる仕組みで、信頼できる主体が行った身元確認や当人認証の結果を、複数のサービス間で連携して使う設計も広がっています。単独で確認を作り込むことよりも、連携できる形で設計することのほうが、複数サービスにまたがる案件では価値を持ちます。標準化された連携の仕組みを理解しておくと、初めて関わるサービスでも、既存の認証基盤にどう接続するかを短い時間で見通せるようになります。ID連携の設計経験は、この分野でも強みになります。

リモート・フリーランスの案件でも、こうした認証基盤やID連携の設計に関わる機会は広がっています。Remogu（株式会社LASSIC運営）が扱う案件の90%以上がフルリモート可能です⁷。場所にとらわれず、認証基盤の設計に集中できる環境を選びやすくなっています。

案件ごとに求められる保証レベルも、関わる技術要素も異なります。次にまとめとして、ここまでの考え方を整理します。

6. まとめ

身元確認と当人認証を、リスクに見合った設計にする

デジタル本人確認・eKYCの案件が増えている背景には、脅威の高度化があります⁴。DS-511が示す通り、本人確認は身元確認と当人認証という2つの工程に分けて設計します³。そのうえで、保証レベルという考え方を使い、リスクに見合った確認の程度を選びます²。ここまでの5つの章は、それぞれ独立した知識ではなく、1つの設計判断を支える一続きの考え方として読むと理解しやすくなります。

厳しくすることよりも、リスクに見合った設計を選ぶことのほうが、利用者にとっても運営側にとっても無理のない仕組みになります。フィッシングやディープフェイクへの備えは、認証方式を置き換え、標準の動きを追い続けることで積み重なっていきます⁶。制度や規格は今後も見直され続けるため、一度決めた設計を固定的なものと考えず、更新していく前提で関わる姿勢が長く役立ちます。

Web開発や認証基盤、データ連携で培ってきた経験は、この分野の設計にそのまま活かせます。まずは登録して、自分の経験に合う案件の条件を確認してみましょう。

7. よくある質問

認証の専門知識がなくても関われますか

身元確認と当人認証という骨格を理解していれば、専門知識を積み上げている途中の段階でも関わり方はあります。書類照合の仕組みづくりや、ログの設計といった周辺の工程から入り、当人認証やフィッシング対策の設計へと経験を広げていく進み方が現実的です。最初から全体を任される案件だけでなく、部分的な実装から関わる案件もあるため、自分の現在地に合う案件を探すことがはじめの一歩になります。

どんなスキルが活きますか

Web開発、業務システムの構築、認証基盤の運用、データ連携の設計といった経験は、身元確認や当人認証の設計にそのまま活かせます。セキュリティ設計の経験があれば、フィッシングやディープフェイクへの耐性を高める認証方式の選定にも関われます。設計の全体を見渡す経験は、部分的な実装の経験より重宝される場面が増えています。過去に認証まわりの不具合対応や障害対応に関わった経験も、リスクを具体的に想像する力として活きます。

保証レベルはどう決めればよいですか

保証レベルは、本人確認の確からしさを段階的に表現する概念です²。手続きの先にあるリスクの大きさを起点に考え、必要以上に厳格な確認を取り入れることは、プライバシー等の観点で望ましくない場合があると理解したうえで⁵、過不足のない確認の程度を選びます。決め方に迷うときは、誤りが起きたときに誰にどれだけの影響が及ぶかを先に書き出しておくと、確認の程度を関係者と合意しやすくなります。

Web・業務システムの経験は活きますか

活きます。身元確認では書類読み取りや外部記録との照合精度、当人認証ではフィッシングへの耐性と利便性の両立が問われます。業務システムやデータ連携で培った設計の経験は、どちらの工程に関わるときも土台になります。特に、複数のシステムをまたいでデータを受け渡した経験は、フェデレーションによるID連携の設計を理解するうえでも近道になります。

案件はフルリモートでもできますか

案件によって条件は異なりますが、フルリモートで進められる案件が中心です。5章で触れた通り、Remoguが扱う案件はフルリモートが中心です⁷。まずは登録して、自分の経験に合う条件を確認してみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊2 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊3 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊4 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊5 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊6 デジタル社会推進会議幹事会「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能