認証基盤や本人確認まわりの設計に関わってきたエンジニアが案件の打診を受けたとき、まず気になるのが「どこまで厳しくすればよいか」という点です。厳しくしておけば安心だという感覚は、現場だけのものではありませんでした。デジタル庁が2025年9月30日に決定したガイドライン¹は、保証レベルを段階的な概念として整理し直し、必要以上に厳格な手法を用いることの反作用にも触れています³。この記事では、その整理をもとに、案件で求められる本人確認の水準をどう確かめ、積み上げてきた経験をどう言葉にして伝えるかを見ていきます。

1. 「高ければよい」ではなくなった

保証レベルは、段階を選ぶための物差しです

認証基盤の案件を打診されると、要件定義の場で「本人確認の水準は厳しめにしておいてほしい」と言われることがあります。強くしておけば指摘を受けないという判断は、設計を任されてきたエンジニアであれば一度は選んだことがあるはずです。責任の所在が曖昧なときほど、その傾向は強くなりがちでした。

デジタル庁が2025年9月30日に決定したガイドライン¹は、この判断の前提そのものを整理し直しています。保証レベルとは、本人確認の確からしさを段階的に表現する概念であると位置づけられています¹。強いか弱いかという一本の軸ではなく、対象の手続に見合う段階をどこに置くかという物差しです。

この物差しを知っておくと、打診された案件で「なぜその水準なのか」を尋ねられたときに、勘ではなく整理された理由をもとに答えられるようになります。次に見直されたのは、その物差しをどう使うかという部分です。

「高ければ高いほどよい」という感覚が見直された

保証レベルを決める場面で、迷ったときは高い方を選んでおくという進め方は、これまで珍しいものではありませんでした。ガイドラインも、レベルは高ければ高いほどよいと捉えられることが少なくなかったと述べています²。

この一文が意味を持つのは、現場の感覚が公式な文書の中で名指しされたという点です。感覚として共有されてきたものが、見直す前提として明文化されたことで、案件の設計者は「高くしておけば無難」という選び方から離れる根拠を持てるようになりました。

とはいえ、これは水準を軽くしてよいという話ではありません。次の章では、必要以上に厳しくすることが具体的に何を損なうのかを見ていきます。案件の打診で厳しさを求められたときに、その理由を一緒に確かめる材料になります。

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

2. 厳しくしすぎると、何が損なわれるのか

望ましいとは言えない、という整理

「厳しくしておけば安心」という進め方には、見落としがちな代償があります。ガイドラインは、必要以上に厳格な本人確認手法を用いることは、プライバシー等の観点では望ましいとは言えないと明確に述べています³。

この一文は、水準を軽くしてよいという意味ではありません。対象の手続に見合わない厳しさを重ねることが、利用者のプライバシーという別の価値との釣り合いを崩すという整理です。強さそのものではなく、釣り合いが論点になっています。

案件の打診で「厳しめに」と言われたときに、この整理を知っているかどうかで返せる問いが変わります。「対象の手続に照らして、その厳しさは釣り合っていますか」と尋ねられる立場になれます。

事業目的や公平性を阻害する懸念

厳しい手法を重ねると、確認の手間が増え、対応できる利用者の範囲が狭くなることがあります。ガイドラインは、厳格な手法によって利用の制約が生じることで、手続やサービスが本来満たす事業目的や公平性を阻害してしまう懸念があると述べています⁴。

つまり、水準を上げることそのものが目的化すると、本来届けたい相手にサービスが届かなくなる恐れがあるという整理です。設計の善し悪しは、強さの一本の指標だけでは測れません。

この整理を持っておくと、打診の場で水準を提案するときに「なぜその厳しさなのか」だけでなく「その厳しさで誰が使いづらくなるか」まで説明できる立場になります。次は、この観点を打診の場でどう確かめるかです。

打診の場で確かめておきたい問い

保証レベルの妥当性は、案件の打診を受けた時点でひととおり確かめておくと、後から水準を見直す手間を減らせます。対象の手続の目的、想定する利用者、水準を選んだ理由、見直しの機会という4つの観点を、次の表に整理しました。打診の場でこの4点を尋ねると、要件の背景を握った状態で参画できます。

確かめる問い	その問いで見えること	見えないと起きやすいこと
対象の手続の目的は何か	事業目的や公平性とどう関わる水準か	目的に見合わない厳しさを重ねやすい
想定する利用者層は誰か	制約が生じたときに誰が使いづらくなるか	一部の利用者を締め出す設計になりやすい
なぜその水準が必要か、理由は示せるか	勘ではなく整理された理由があるか	厳しくした理由を後から説明できなくなる
見直しの機会はいつ設けるか	段階を選び直す前提を持っているか	一度決めた水準がそのまま固定される

3. 本人確認は3つの部品に分かれている

5つの言葉に分かれている

「本人確認」とひとまとめに語られがちですが、ガイドラインが挙げるキーワードを見ると、実際には複数の言葉に分かれています。本人確認、デジタルアイデンティティ、身元確認、当人認証、フェデレーションという5つです⁵。

この分かれ方を知っていると、打診された案件の要件が「どの部品の話か」を切り分けられるようになります。身元確認は「誰であるか」を確かめる部分、当人認証は「その人が今アクセスしているか」を確かめる部分というように、担う役割が異なります。

フェデレーションは、この確認結果を別のサービスと共有する仕組みを指す言葉です。ひとまとめに「認証」と呼んでいたものを部品に分けて考えられると、案件の要件定義でどこを設計する話なのかを取り違えにくくなります。

ガイドラインが示す範囲

このガイドラインは、国の行政機関が行政手続等で申請者の本人確認を行う際の、デジタルアイデンティティに関する枠組み、対策基準、リスクの評価手順、本人確認手法の選定方法等を示した標準ガイドライン附属文書です⁶。

対象は行政手続であり、民間のサービスに同じ基準が義務づけられているわけではありません。ただし、リスクを評価してから水準を選ぶという進め方そのものは、案件の設計を任されるエンジニアにとって参照しやすい型です。

部品ごとの役割とガイドラインが示す範囲を押さえたところで、次は現場で変わりつつある脅威の側に目を向けます。部品の設計は、狙われ方が変われば見直しの対象になります。

図の作成：Remogu編集部。ガイドラインが挙げる本人確認関連の言葉を整理したもので、統計データではありません

4. 脅威の側も変わっている

脅威も高度化の一途をたどっている

水準を選ぶ根拠を持てたとしても、確認する対象そのものが変わらなければ意味がありません。ガイドラインは、本人確認書類の偽造、オンラインサービスにおけるフィッシング攻撃、生成AIを悪用したディープフェイクによるなりすましなど、本人確認に対する脅威が高度化の一途をたどっていると述べています⁷。

これらは手口の名前として挙げられているだけで、具体的な回避策までは書かれていません。ただ、確認方法が固定されたままでは、変わっていく脅威に置いていかれるという構図は読み取れます。水準の選び方と同じく、脅威の側も「一度決めて終わり」にはできません。

認証基盤の案件で経験を積んできたエンジニアにとって、これは打診の場で語れる材料になります。「以前の水準のまま止まっていないか」を確かめられる視点を持っていることが、案件で信頼を得る入り口になります。

設計を止めずに見直す視点

脅威が変わり続ける以上、設計の側も一度決めた水準に留まり続けるわけにはいきません。打診された案件で「この水準は誰が、いつ見直す想定か」を確かめておくと、参画後に水準の妥当性を問われたときに困らずに済みます。

見直しの主体をクライアント側とだけ決めておくと、実際に見直す場面が来ないまま水準が固定されがちです。設計に関わるメンバーとして、見直しの契機をどこに置くかを協議する立場を持てるかどうかが、案件での役割の広さを左右します。

次の表では、ガイドラインが挙げる脅威の変化と、設計で持っておきたい見直しの方向を並べています。打診の場で脅威の話が出たときに、この整理をもとに答えられるようにしておくと落ち着いて対応できます。

脅威の変化と、設計で持っておきたい方向

脅威の名前を知っているだけでは、案件で語れる材料にはなりません。ガイドラインが挙げる3つの脅威⁷それぞれについて、設計側がどの方向で持ちこたえるかを整理すると、打診の場で「更新を止めていない」という姿勢を具体的に示せます。次の表と図に、その整理をまとめました。

脅威の変化	設計で持っておきたい方向
本人確認書類の偽造	確認の手順を固定せず、定期的に見直す前提を持つ
フィッシング攻撃	当人認証の場面を用途ごとに分けて設計する
生成AIを悪用したなりすまし	単一の確認方法に頼り切らない設計にする

図の作成：Remogu編集部。ガイドラインが挙げる脅威と設計の対応関係を整理したもので、統計データではありません

5. 他人が確認した結果を使うときの前提

確からしさは、確認した側の手法に依存する

フェデレーションを使うと、自社で身元確認をやり直さずに済むという利点があります。ただしガイドラインは、取得した属性情報の正確性や保証レベルは、IDプロバイダが実施した身元確認の手法に依存すると述べています⁸。

つまり、確認結果を借りてくる時点で、その確からしさは自社の設計ではなく相手側の手法で決まっているということです。フェデレーションを組み込めば水準の話が終わるわけではなく、相手がどう確認したかという前提を引き継ぐことになります。

あわせてガイドラインは、IDプロバイダが身元確認を実施した時点から属性情報が変更されている可能性がある点にも触れています⁸。確認は一度きりの点ではなく、時間とともにずれていく前提で扱う必要があります。

受け入れ可能かは、あらかじめ合意しておく

では、借りてきた確からしさをそのまま受け入れてよいかは、誰がどう判断するのでしょうか。ガイドラインは、正確性や保証レベルが対象手続において受け入れ可能なものであるかは、「信頼関係の確立」プロセスにおいてあらかじめ確認・合意することが必要だと述べています⁹。

この一文が示すのは、受け入れ可能かどうかは後から個別に判断する話ではなく、事前に取り決めておく話だということです。案件の設計段階でこの合意が置かれているかどうかは、打診を受けた時点で確かめておきたい点です。

認証基盤の経験を積んできたエンジニアであれば、この「事前の合意」という視点そのものが、案件で語れる強みになります。次の表では、その経験をどう4つの層に分けて言葉にするかを整理しました。

認証基盤の経験を4つの層で書き出す

認証基盤に関わってきた経験は、「認証まわりを担当していました」とひとことでまとめると伝わりにくくなります。設計・実装・運用・合意形成という4つの層に分けて書き出すと、打診の場でどの部分を任せられる人材かが伝わりやすくなります。次の表に、層ごとに書き出す内容を整理しました。

層	書き出す内容
設計	保証レベルをどう選び、その理由をどう整理したか
実装	身元確認・当人認証・フェデレーションをどう組み合わせたか
運用	属性情報が古くなっていないかをどう扱ってきたか
合意形成	受け入れ可能かをどう事前に確認・合意してきたか

図の作成：Remogu編集部。ガイドラインが示すIDプロバイダとの関係を整理したもので、統計データではありません

6. まとめ

認証基盤の案件で問われているのは、水準を強くする技術ではありません。対象の手続に見合う段階を選び、その理由を説明できることです。ガイドラインが示した整理は、これまで感覚で決めてきた部分に、言葉にできる根拠を与えてくれます¹。

厳しくしすぎれば、プライバシーや事業目的、公平性を損なう懸念があります³。緩めすぎればよいという話でもありません。問われているのは、対象の手続に見合った位置を選び、その理由を人に説明できる状態にしておくことです。

本人確認、身元確認、当人認証、フェデレーションという部品に分けて考える視点や、他人が確認した結果を借りるときの前提を押さえておく視点は、案件の打診で「この人になら任せられる」と感じてもらえる材料になります。

Remoguはリモート案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です¹⁰。認証基盤の経験を積んできたエンジニアであれば、その経験を4つの層で書き出したうえで、まず自分に合う案件情報を確かめてみると、次の一歩が具体的になります。

水準を選ぶ根拠を持てているかどうかは、打診を受けた時点でしか確かめられません。まず登録して、積み上げてきた経験に見合う条件を確かめてみることから始めてみましょう。

7. よくある質問

このガイドラインは、民間のサービスにも適用されるのか

本ガイドラインは、国の行政機関が行政手続等で本人確認を行う際の、デジタルアイデンティティに関する枠組み・対策基準・リスクの評価手順・本人確認手法の選定方法等を示した標準ガイドライン附属文書です⁶。対象は行政手続であり、民間のサービスに同じ基準がそのまま義務づけられているわけではありません。ただし、リスクを評価してから水準を選ぶという進め方そのものは、業種を問わず参照しやすい型です。

水準を下げる提案は通るのか

下げてよいかどうかは個別の案件ごとに事情が異なり、この記事だけで判断できるものではありません。ガイドラインが示しているのは、必要以上に厳格な手法を用いることがプライバシー等の観点で望ましいとは言えないという整理です³。この整理を根拠に、対象の手続に見合う水準かどうかを協議の材料にすることはできます。

フェデレーションを使えば楽になるのか

自社で身元確認をやり直さずに済むという意味では負担が減ります。ただし、属性情報の正確性や保証レベルは、IDプロバイダが実施した身元確認の手法に依存し、確認時点から変わっている可能性もあります⁸。受け入れ可能かどうかは、あらかじめ合意しておく必要があり⁹、導入すれば水準の検討が要らなくなるとは言い切れません。

認証基盤の経験は、どう書けば伝わるのか

「認証まわりを担当していました」とひとことでまとめると、案件の打診で何を任せられる人材かが伝わりにくくなります。設計・実装・運用・合意形成という4つの層に分けて、それぞれで何を判断してきたかを書き出すと、担ってきた役割が具体的に伝わります。まずは自分の経験をこの4層で整理したうえで、Remoguで自分に合う案件情報を確かめてみると、次の一歩を踏み出しやすくなります。

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

出典・参考情報

＊1 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」本ガイドラインの改定に当たって（2025年9月30日）
＊2 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」本ガイドラインの改定に当たって（2025年9月30日）
＊3 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」本ガイドラインの改定に当たって（2025年9月30日）
＊4 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」本ガイドラインの改定に当たって（2025年9月30日）
＊5 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」キーワード（2025年9月30日）
＊6 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」概要（2025年9月30日）
＊7 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」1.1 背景と目的（2025年9月30日）
＊8 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」3.3 フェデレーション（2025年9月30日）
＊9 デジタル庁「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」3.3 フェデレーション（2025年9月30日）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）