本記事は、2026年11月2日時点で公開されている資料をもとにした一般的な観点の整理です。用語の定義や制度は改訂が続くため、実際の仕様書の作成や調達の時点で、各出典の最新の内容を確認してください。個別の手続きの要件や、法令の解釈は、各自治体の所管部門と、システムを提供する事業者、必要に応じて専門家に確認してください。
用語の一覧
用語の一覧です。用語名から、各定義へ移れます。
表は横にスクロールできます
| 分野 | 用語(五十音順ではなく、理解の順) |
|---|---|
| 本人確認の基本(5 語) | 身元確認・当人認証・フェデレーション・保証レベル・DS-511 |
| 電子証明書(7 語) | 公的個人認証サービス・署名用電子証明書・利用者証明用電子証明書・基本 4 情報・スマートフォン用電子証明書・マイナアプリ・デジタル認証サービス |
| ID 連携(8 語) | シングルサインオン・OpenID Connect・ID プロバイダ・依拠当事者・ID トークン・認可コードフロー・PKCE・SAML |
| 住民向けの仕組み(6 語) | 住民 ID・名寄せ・デジタル市民証・行政カード化・親子アカウントの紐付け・代理人設定 |
| 同意と個人情報(5 語) | 利用目的の特定・同意管理・再同意・個人情報ファイル簿・定型約款 |
| 運用(3 語) | 並行期間・休眠アカウント・アカウント回復 |
本人確認の基本
身元確認(Identity Proofing)
DS-511 は、身元確認を「申請者を一意に識別するとともに、その実在性を確認すること」と定義しています。申請や利用者登録のときに行う確認と整理できます(本記事の整理)。 詳しくは「行政手続きの本人確認の水準」で整理しています。
当人認証(Authentication)
DS-511 は、当人認証を「申請者の当人性を確認すること」と定義し、手続を利用しようとする者が、身元確認時に登録された者と同一の人物であることを、紐づけて登録した認証器等を用いて確認するものとしています。ログインのときに働く確認と整理できます(本記事の整理)。 詳しくは「行政手続きの本人確認の水準」で整理しています。
フェデレーション(Federation)
DS-511 は、フェデレーションを「身元確認や当人認証を、他者に依拠して実現すること」と定義しています。信頼できる ID プロバイダと連携し、ID プロバイダが行った身元確認や当人認証の結果に関する情報を入手して、手続での本人確認を実現します。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
保証レベル(身元確認保証レベル・当人認証保証レベル)
DS-511 は、保証レベルを「本人確認の確からしさを段階的に表現するためのレベル」とし、「身元確認保証レベル」と「当人認証保証レベル」の 2 種類を定めています。それぞれレベル 1〜3 の 3 段階で、手続のリスクの影響度(低位・中位・高位)に対応し、数字が大きいほど厳格な対策が求められます。高いほど良いとは限らず、手続のリスクに応じた適切なレベルを選ぶことが目的です。 詳しくは「行政手続きの本人確認の水準」で整理しています。
DS-511
デジタル庁の標準ガイドラインで、正式名称は「行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」です。2025年9月30日にデジタル社会推進会議幹事会が決定し、「DS-500」を全面改定して文書番号を変えたものです。適用対象は国の行政機関が提供する行政手続・行政サービスで、自治体には直接適用されないため、自治体の仕様書では「参考にする資料」として書きます。 詳しくは「行政手続きの本人確認の水準」で整理しています。
電子証明書
公的個人認証サービス(JPKI)
デジタル庁は、マイナンバーカードの IC チップに搭載された電子証明書を利用して(マイナンバーは利用しません)、オンラインで利用者本人の認証や、文書が改ざんされていないことの確認を公的に行うためのサービスと説明しています。国と地方公共団体が共同で管理する法人である地方公共団体情報システム機構(J-LIS)が運営しています。 詳しくは「署名用電子証明書と利用者証明用電子証明書の違い」で整理しています。
署名用電子証明書
インターネットで申込みや契約などの電子文書を作成・送信するときに使われ、その文書が「利用者が作成した真正なものであり、利用者が送信したもの」であることを確かめられる電子証明書です(デジタル庁)。基本 4 情報を保持し、暗証番号は英数字 6〜16 桁です。15 歳未満の人には、原則として付けられません。 詳しくは「署名用電子証明書と利用者証明用電子証明書の違い」で整理しています。
利用者証明用電子証明書
主にインターネットサイトなどにログインするときに使われ、ログインした人が利用者本人であることを確かめられる電子証明書です(デジタル庁)。基本 4 情報を保持せず、暗証番号は数字 4 桁です。 詳しくは「署名用電子証明書と利用者証明用電子証明書の違い」で整理しています。
基本 4 情報
住所、氏名、性別、生年月日の 4 項目です。署名用電子証明書は電子証明書の中に保持し、利用者証明用電子証明書は保持しません。これが 2 つの証明書の主な差異で、氏名や住所が変わると、署名用としての機能を使えなくなります(デジタル庁の自治体向けよくある質問)。 詳しくは「署名用電子証明書と利用者証明用電子証明書の違い」で整理しています。
スマートフォン用電子証明書
マイナンバーカードと同等の機能(署名用電子証明書と利用者証明用電子証明書)を持った、スマートフォン用の電子証明書です(デジタル庁『マイナアプリ(自治体向け)』)。スマートフォンでは暗証番号の代わりに生体認証を使えますが、署名用電子証明書は対象外とされています(民間事業者向けガイドライン 第 1.8 版)。 詳しくは「署名用電子証明書と利用者証明用電子証明書の違い」で整理しています。
マイナアプリ
デジタル庁が 2026年8月25日に提供を開始したアプリで、「マイナポータルアプリ」と「デジタル認証アプリ」の機能を統合したものです。マイナポータルアプリから呼称を変更したもので、すでに使っている住民はアップデートすることで利用を始められます。 詳しくは「マイナアプリ統合で、自治体の本人確認はどう変わるか」で整理しています。
デジタル認証サービス
行政機関や民間事業者向けのサービス名で、2026年8月25日に旧「デジタル認証アプリサービス」から呼称が変わりました。利用者証明用電子証明書を使う「認証 API」と、署名用電子証明書を使う「署名 API」の 2 種類が提供されています。 詳しくは「マイナアプリ統合で、自治体の本人確認はどう変わるか」で整理しています。
ID 連携
シングルサインオン(SSO)
この用語集では、SSO を「住民が一度ログインすると、複数のサービスに再ログインなしで入れること」という利用者の体験の意味で使います。この体験を実現するために ID プロバイダと利用側サービスの間で結果を受け渡す仕組みを「ID 連携」と呼びますが、一般には両者がほぼ同じ意味で使われることもあります。職員向けの SSO は別の話です。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
OpenID Connect(OIDC)
OpenID Connect Core 1.0 は、OAuth 2.0 の上に作られた、シンプルな ID の層と説明されています(OpenID Foundation の原本)。ログインの結果を別のサービスに渡すための標準規格です。DS-511 は OpenID Connect も SAML も指定していません。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
ID プロバイダ
DS-511 は、連携モデルにおいて、申請者に対する身元確認や当人認証を行い、その結果に関する情報を依拠当事者へ連携する主体と定義しています。OpenID Connect では OpenID Provider(OP)にあたります(対応は本記事の整理)。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
依拠当事者(Relying Party)
DS-511 は、連携モデルにおいて、身元確認や当人認証を ID プロバイダに依拠する主体と定義しています。自治体では、住民ポータルや図書館、各種申請のシステムなど、ログイン結果を受け取る利用側サービスがこれにあたります(本記事の整理)。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
ID トークン
OpenID Connect で、ログインの結果を運ぶデータです。JSON Web Token(JWT)の形式で、OpenID Connect Core 1.0 は、発行者(iss)、利用者の識別子(sub)、宛先(aud)、有効期限(exp)、発行時刻(iat)の 5 つを必須としています。DS-511 の「アサーション」に対応します(対応は本記事の整理)。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
認可コードフロー
OpenID Connect Core 1.0 の 3.1 節に定められた、住民向けのログインで標準的な流れです。ID プロバイダが認可コードをブラウザ経由で返し、利用側サービスがそれを ID プロバイダへ直接送って ID トークンを受け取ります。認可コード自体にはログインの結果は入っていません。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
PKCE
認可コードを途中で横取りして使われる攻撃への対策で、RFC 7636(2015年9月)が定めています。RFC 9700(2025年1月)は、公開クライアントには PKCE を使わなければならず、機密クライアントにも使うことを推奨しています。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
SAML
OASIS が定めた、認証・属性・認可に関する XML 形式のアサーションと、それを伝えるプロトコルです(SAML 2.0、OASIS Standard、2005年3月15日)。OpenID Connect とどちらが優れているかは一概には言えず、連携先のサービスがどちらに対応しているかで決まることが多くなります。 詳しくは「自治体の OpenID Connect による SSO 入門」で整理しています。
住民向けの仕組み
住民 ID
住民が本人確認をして、住民ポータルやオンライン申請などにログインするための ID です。サービスごとに別々の利用者番号やアカウントを、住民 1 人につき 1 つの共通の ID に切り替える取り組みが「住民 ID の統合」です(本記事での定義)。基幹業務システムで、システム間の連携単位を定める「業務 ID」(デジタル庁、令和4年8月)とは別物です。 詳しくは「住民 ID の統合」で整理しています。
名寄せ
複数のサービスにある同じ人のデータを、1 人にまとめることです。DS-511 は、身元確認の脅威として「重複登録」と「別人との誤紐づけ」を挙げています。誤統合は戻しにくいため、迷うときは寄せない、という考え方を整理しています。 詳しくは「住民 ID の統合」で整理しています。
デジタル市民証
国の制度名ではありません。この用語集では、自治体または委託を受けた事業者が独自に提供する、スマートフォンに発行する住民であることなどを示す証を指します。公的な本人確認書類と同じように使えるかは、提供元の定めで確認する必要があります。 詳しくは「デジタル市民証とは」で整理しています。
行政カード化(市民カード化)
マイナンバーカードを図書館カードなどの各種の資格証として使う、デジタル庁の構想です。令和7年3月(v1.10)の資料は「市民カード化」、令和8年7月(v2.0)の資料は「行政カード化」と題されています。 詳しくは「デジタル市民証とは」で整理しています。
親子アカウントの紐付け
住民向けのオンラインサービスで、保護者のアカウントに子どもを結び付け、子どもに関する手続きや情報の確認を保護者が行えるようにする仕組みです。どの手続きを代わりに行えるか、どう親子関係を確認するかは、サービスを提供する自治体が決めます。 詳しくは「子育て手続きの親子アカウント紐付け」で整理しています。
代理人設定
マイナポータルの機能で、委任する人が、代理人に許可するサービスや参照を許可する情報、代理できる期間などを設定し、マイナンバーカードを読み込ませて登録します(デジタル庁の操作マニュアル)。パスポートの申請の代理は、法定代理人に限られます。 詳しくは「子育て手続きの親子アカウント紐付け」で整理しています。
同意と個人情報
利用目的の特定
行政機関等は、個人情報がどのような事務又は業務の用に供され、どのような目的に使われるかを、できるだけ具体的かつ個別的に特定しなければなりません(個人情報保護法第61条第1項、個人情報保護委員会のガイドライン(行政機関等編))。利用目的の変更は、変更前と相当の関連性を有すると合理的に認められる範囲に限られます。 詳しくは「自治体の住民向けサービスの同意管理」で整理しています。
同意管理
この用語集では、利用規約や個人情報の取扱いへの同意を、何に求めるか、どう示してどう取るか、どう記録するか、改定時にどうするか、撤回をどう受けるかまで通して設計・運用することを指します(「自治体の住民向けサービスの同意管理」の整理)。行政機関等の利用目的の明示は法令上の義務で、住民の同意によって成り立つものではありません。 詳しくは「自治体の住民向けサービスの同意管理」で整理しています。
再同意
利用規約などを改定したときに、住民に改めて同意を求めることです。一律に必要と決まっているわけではなく、どの改定は周知で足り、どの改定で再同意を求めるかの基準を、最初に決めておきます(本記事の整理)。 詳しくは「自治体の住民向けサービスの同意管理」で整理しています。
個人情報ファイル簿
行政機関の長等が、保有する個人情報ファイルの存在と概要を明らかにして透明性を図るために、一定の事項を記載して作成・公表する帳簿です(個人情報保護法第75条第1項)。本人の数が 1,000 人未満のファイルは、作成・公表の義務の対象外です(個人情報保護委員会 Q&A)。 詳しくは「住民 ID の統合」で整理しています。
定型約款
民法第548条の2は、定型約款を「定型取引において、契約の内容とすることを目的としてその特定の者により準備された条項の総体」と定めています。自治体の住民向けサービスの利用規約に、この規定が適用されるかを直接述べた公的資料は確認できていないため、個別に確認が必要です。 詳しくは「自治体の住民向けサービスの同意管理」で整理しています。
運用
並行期間
ID の統合や切り替えで、一定期間、旧ログインと新しい ID を併存させ、新しい ID への移行を促す期間です。住民が自分のタイミングで移れる一方、二重管理が続くため、旧ログインの受付を終える日を決めておきます(本記事の整理)。 詳しくは「住民 ID の統合」で整理しています。
休眠アカウント
長く使われていないアカウントです。何年使われていなければ休眠とするかについて、資料に一律の期間は示されていないため、自治体で基準を決めます。新しい基盤へ持ち込むかどうかは、利用目的と保有の必要性の問題として扱います(本記事の整理)。 詳しくは「住民 ID の統合」で整理しています。
アカウント回復
DS-511 は、利用者がパスワードを忘れた場合や認証器を紛失した場合に備え、アカウントの回復手段を検討するよう求めています。回復手段が攻撃の起点にされないよう、採用している当人認証手法と同等以上の強度の手法を選ぶこととされています。 詳しくは「行政手続きの本人確認の水準」で整理しています。
9 本の記事の対応
用語の詳しい説明は、次の 9 本の記事にあります。分野から、読む記事を選べます。
表は横にスクロールできます
| 分野 | 記事 | 主に扱う用語 |
|---|---|---|
| 本人確認の基本 | 行政手続きの本人確認の水準 | 身元確認・当人認証・保証レベル・DS-511 |
| 電子証明書 | 署名用電子証明書と利用者証明用電子証明書の違い | 署名用・利用者証明用・基本 4 情報・スマートフォン用 |
| 電子証明書 | マイナアプリ統合で、自治体の本人確認はどう変わるか | マイナアプリ・デジタル認証サービス |
| ID 連携 | 自治体の OpenID Connect による SSO 入門 | SSO・OpenID Connect・ID トークン・PKCE・SAML |
| 住民向けの仕組み | デジタル市民証とは | デジタル市民証・行政カード化 |
| 住民向けの仕組み | 子育て手続きの親子アカウント紐付け | 親子アカウントの紐付け・代理人設定 |
| 同意と個人情報 | 自治体の住民向けサービスの同意管理 | 利用目的の特定・同意管理・再同意・定型約款 |
| 運用 | 住民 ID の統合 | 住民 ID・名寄せ・並行期間・休眠アカウント |
| 全体(調達) | 自治体の認証基盤 調達チェックリスト | 上のすべてを仕様書の観点にまとめたチェックリスト |
RinX の場合
当社の自治体向け統合 ID 基盤 RinX(リンクス)は、本人確認・マイページ・外部連携をひとつの基盤で提供します。この用語集の用語に関わる内容として、サービスページで公開している内容は次のとおりです。
- 本人確認の手段 — マイナンバーカードによる本人確認(公的個人認証)、LINE、メールアドレスのログインに対応しています。利用する手段は、自治体ごとにご相談のうえ決定します
- ID 連携 — OpenID Connect によるシングルサインオンと、住民ポータルなどへの利用者情報の自動連携に対応しています
- 住民向けの機能 — Web ブラウザで利用できるマイページ(専用アプリは不要)、スマートフォンに表示するデジタル市民証、お子さまのアカウントの紐付けを備えています
- 同意 — 個人情報の利用目的に対する同意の管理と、利用規約などの同意文書の管理(改定時の再同意の取得)に対応しています
- 既存データ — 既存の利用者データの一括取り込みに対応しています
上の用語の定義は、RinX に固有のものではなく、公的資料と各記事の整理に基づいています。個別の要件は、お問い合わせの際にご相談ください。RinX に関する記事は、RinX の記事一覧にまとめています。
まとめ
- 本人確認は、身元確認(実在性の確認)、当人認証(登録した本人との同一性の確認)、フェデレーション(他者への依拠)に分けて考える。保証レベルの対象は、身元確認と当人認証
- 署名用電子証明書は電子署名、利用者証明用電子証明書はログインに使う。基本 4 情報を保持するのは署名用だけ
- DS-511 は国の行政機関向けの資料で、自治体には直接適用されない。仕様書には「参考にする資料」として、名称・決定日・確認日を添えて書く
- ID 連携の方式(OpenID Connect、SAML)は、DS-511 では指定されていない。連携先の対応状況に応じて決める
- 「本記事の整理」と書かれた説明は、公的資料の定義ではない。仕様書に使うときは、出典の最新版で確認する
RinX の機能・導入の流れ・費用の考え方は、サービスページで確認できます。
よくある質問
Q1. 身元確認と当人認証は、何が違いますか?
身元確認は、申請者を一意に識別し、その実在性を確認することで、申請や利用者登録のときに行います。当人認証は、手続を利用しようとする者が、身元確認時に登録された者と同一の人物であることを、登録した認証器等で確認することで、ログインのときに働きます(いずれも DS-511 の定義。場面は本記事の整理)。保証レベルは、この 2 つについて別々に判定します。
Q2. 署名用電子証明書と利用者証明用電子証明書は、何が違いますか?
署名用は、電子文書に電子署名を付け、作成者と改ざんされていないことを確かめるための証明書で、利用者証明用は、ログインなどで本人であることを確かめるための証明書です。主な差異は基本 4 情報(住所、氏名、性別、生年月日)を保持するかどうかで、署名用は保持し、利用者証明用は保持しません。暗証番号は、署名用が英数字 6〜16 桁、利用者証明用が数字 4 桁です。
Q3. DS-511 は、自治体にも適用されますか?
DS-511 の適用対象は、国の行政機関が提供する行政手続・行政サービスで、位置付けは政府情報システムの整備及び管理に関するルールです。自治体には直接適用されません。自治体の仕様書では、名称、決定日、確認日を添えて「参考にする資料」として書き、従うべき基準のようには書きません。手続の根拠法令が本人確認の方法を定めている場合は、その定めに従います。
Q4. OpenID Connect と SAML は、どちらを選べばよいですか?
どちらが優れているかは一概には言えず、連携先のサービスがどちらに対応しているかで決まることが多くなります。DS-511 には、OpenID Connect も SAML も記載がなく、国が OpenID Connect を求めているとは言えません。仕様書では、方式を指定したうえで、連携先の対応状況に応じて代替の方式を認めるかどうかを書いておくと、連携先の追加が円滑になります。
Q5. 住民 ID と業務 ID は、同じものですか?
別物です。住民 ID は、住民が本人確認をして住民ポータルなどにログインするための ID です。業務 ID は、基幹業務システムの標準化で、システム間の連携単位を一意に定めるための ID で、デジタル庁の「各種 ID の管理方針」(令和4年8月)で定められています。仕様書の冒頭で、どちらを調達するのかを書き分けます。
Q6. どの記事から読めばよいですか?
調達の全体像を知りたい場合は、「自治体の認証基盤 調達チェックリスト」から読むと、10 の観点で仕様書に書くことを確認できます。本人確認の強さを決めたい場合は「行政手続きの本人確認の水準」、住民向けの ID 連携は「自治体の OpenID Connect による SSO 入門」、既存のアカウントをまとめる場合は「住民 ID の統合」が出発点です。上の「9 本の記事の対応」の表から、分野ごとに選べます。
出典・参考資料
いずれも2026年11月2日に内容を確認しています。
- デジタル社会推進標準ガイドライン DS-511『行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン』(2025年9月30日、デジタル社会推進会議幹事会決定)digital.go.jp
- デジタル庁『公的個人認証サービス(JPKI)導入』(最終更新 2026年10月13日)digital.go.jp
- デジタル庁『マイナアプリ(自治体向け)』(最終更新 2026年8月25日)digital.go.jp
- デジタル庁『よくある質問(FAQ):自治体向けマイナンバーカード利活用』(最終更新 2026年9月18日)digital.go.jp
- デジタル庁『マイナアプリ(旧マイナポータルアプリ)』services.digital.go.jp
- デジタル庁『デジタル認証サービス』services.digital.go.jp
- デジタル庁・総務省『公的個人認証サービス利用のための民間事業者向けガイドライン -第1.8版-』(平成27年9月、令和8年4月改正)soumu.go.jp
- デジタル庁『地方自治体の基幹業務システムの統一・標準化における各種 ID の管理方針』(令和4年8月31日)digital.go.jp
- デジタル庁『【資料3】自治体の皆様へ ~マイナンバーカードの行政カード化構想を進めるために ご参考資料』(令和8年7月、v2.0)digital.go.jp
- デジタル庁『自治体の皆様へ ~マイナンバーカードの市民カード化構想を進めるために ご参考資料』(令和7年3月、v1.10)digital.go.jp
- デジタル庁『マイナポータル操作マニュアル 代理人/全体概要』img.myna.go.jp
- 個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン(行政機関等編)』(令和4年1月、令和8年10月一部改正)ppc.go.jp
- 個人情報保護委員会『個人情報の保護に関する法律についてのQ&A(行政機関等編)』(令和4年2月、令和8年4月更新)ppc.go.jp
- e-Gov 法令検索『民法』(明治29年法律第89号)第548条の2〜第548条の4laws.e-gov.go.jp
- OpenID Foundation『OpenID Connect Core 1.0 incorporating errata set 2』(Final、2023年12月15日)openid.net
- IETF『RFC 7636 Proof Key for Code Exchange by OAuth Public Clients』(2015年9月)rfc-editor.org
- IETF『RFC 9700 Best Current Practice for OAuth 2.0 Security』(BCP 240、2025年1月)rfc-editor.org
- OASIS『Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0』(OASIS Standard、2005年3月15日)docs.oasis-open.org
関連サービス
RinX(リンクス)
本人確認・マイページ・外部連携をひとつの基盤で提供する、自治体向けの統合 ID 基盤です。


