自治体の認証基盤調達チェックリスト

この記事でいう認証基盤は、住民がオンラインで本人確認とログインを行い、住民ポータルや各種手続など複数の行政サービスを同じ ID で使うための基盤です。調達の仕様書では、本人確認の手段だけが詳しく書かれ、連携方式・同意・ログ・移行・契約終了時の扱いが抜けることがあります。仕様書で確認したい観点を、10 の分類に整理しました。

本記事は、2026年10月時点で公開されている国の資料をもとにした一般的な観点の整理です。法令の解釈や、どの要件を必須とするかの判断は、各自治体の所管部門と、必要に応じて専門家に確認してください。引用した資料は改定が続いているため、仕様書を書く時点の最新版を確認してください。

最初に決めること｜住民向けか、職員向けか

「認証基盤」「ID 基盤」という言葉は、自治体の中で次の 3 つの意味で使われます。仕様書の冒頭で、どれを調達するのかを明記しておくと、ベンダーの回答がそろいます。

住民向けの認証基盤 — 住民が本人確認し、住民ポータルやオンライン申請にログインするための基盤。本記事の対象です
職員向けの ID 管理・シングルサインオン — 職員が庁内の業務システムやクラウドサービスに入るための基盤。求められるセキュリティ対策や運用が異なります
業務 ID — 基幹業務システムの標準化で、システム間の連携単位を一意に定めるための ID。デジタル庁の「地方自治体の基幹業務システムの統一・標準化における各種 ID の管理方針」（令和4年8月）で定められているもので、住民がログインに使う ID とは別物です

住民が本人確認をして認証基盤を通じて複数の行政サービスを使う流れと、別枠の職員向け ID・業務 ID — 住民向けの認証基盤は、職員向けの ID 管理や業務 ID とは分けて調達要件を書く

本人確認の手段と、手続ごとの強さ

認証基盤の要件で中心になるのが、本人確認です。デジタル庁の標準ガイドライン「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年9月30日改定）は、本人確認を身元確認・当人認証・フェデレーションに分けて整理しています。DS-511 の適用対象は国の行政機関の手続ですが、自治体が手続ごとに必要な本人確認の強さを考える際の参考になります。

身元確認 — 登録する人が実在する本人であることを確かめる（例：マイナンバーカードによる確認）
当人認証 — ログインのたびに、登録した本人が操作していることを確かめる（例：パスワード、ワンタイムパスワード、カード）
フェデレーション — 信頼できる別の事業者（ID の提供者）が行った確認の結果に依拠して、利用者を確かめる。住民ポータルなどの各サービスが、認証基盤の確認結果を OpenID Connect などで受け取る形がこれに当たり、この場合の認証基盤は確認結果を提供する側になります

仕様書では「マイナンバーカードに対応すること」だけでなく、どの手続にどの強さの本人確認が必要かを一覧にしておくと、過剰な要件や不足を避けられます。お知らせの閲覧のように軽い手続はメールアドレスでのログインで足り、証明書の申請のような手続はマイナンバーカードによる確認を求める、といった段階分けです。

マイナンバーカードの扱い。 マイナンバーカードによる本人確認は、カードの電子証明書を使う公的個人認証サービスの仕組みにもとづきます。デジタル庁は2026年8月25日にデジタル認証アプリの機能をマイナアプリに統合し、行政機関や事業者向けのサービスの呼称を「デジタル認証サービス」に変えました。仕様書に特定のアプリ名を書く場合は、こうした名称の変更に追随できる書き方にしておくと安全です。

ID 連携の方式

住民ポータルや各種のオンライン申請に同じ ID で入れるようにするには、認証基盤と各サービスをつなぐ方式を決める必要があります。方式を独自仕様にすると、サービスを追加するたびに個別開発が発生し、将来の入れ替えも難しくなります。

標準の方式を指定する — OpenID Connect のような標準規格での連携を求める。デジタル庁のデジタル認証サービスも、実装ガイドラインで OpenID Connect の認可コードフローにもとづくことを示しています
接続先を追加する手順と費用 — 新しいサービスをつなぐときに、自治体側・ベンダー側で何が必要か、費用がかかるか
利用者情報の受け渡し — ログインだけでなく、氏名や住所などの登録情報を連携先へ渡す場合の項目、更新や退会の反映方法

令和5年4月から、地方公共団体の個人情報の取扱いにも個人情報保護法の共通ルールが適用されています。具体的な考え方は、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」で確認できます。認証基盤では、次の点を仕様書で確認しておくと運用が安定します。

利用規約と同意の記録 — 誰が、いつ、どの版の規約に同意したかを残せるか
規約を改定したときの再同意 — 改定後の版への同意を、利用者に求められるか
連携の解除と退会 — 利用者が自分で連携を解除・退会できるか、退会後のデータの扱い
代理・家族の扱い — 保護者が子どもの手続を行う場合などの紐付け方。代理の条件は手続ごとの法令等に従います

セキュリティ・ログ・クラウドの要件

総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」は改定が続いており、令和6年10月の改定ではクラウドサービスの利用や委託先の管理に関する記載が見直されました。認証基盤は住民の個人情報を扱うため、次の観点を確認します。

データの保管場所 — 国内に保管されるか
自治体ごとのデータの分離 — 共同利用の基盤の場合、他の団体のデータと混在しないか
暗号化と操作ログ — 機密性の高い情報の暗号化、管理画面の操作履歴の記録と保存期間
クラウドサービスの評価 — 政府のクラウドサービス評価制度である ISMAP の登録状況など、第三者評価をどう確認するか。求める水準は各自治体のセキュリティポリシーにもとづいて判断します

可用性・サービスレベル・サポート

住民が夜間や休日にも手続できる基盤では、止まったときの影響が大きくなります。数値だけを求めるより、定義と連絡のしかたをそろえて確認するのが実務的です。

稼働率の定義 — 目標値か保証値か、計画停止を含むか
計画停止の通知 — いつまでに、どの方法で知らせるか
サポートの受付時間と障害時の連絡 — 受付時間外に障害が起きたときの連絡の流れ

移行と運用

すでに別の仕組みで登録している住民がいる場合、移行の要件が抜けると、公開直前に作業が膨らみます。導入後に職員が使う画面も、仕様書の段階で確認しておきます。

既存の利用者データの取り込み — 取り込める形式、重複した登録の扱い、並行運用の期間
職員の管理画面 — 利用者の照会・訂正、CSV 出力の範囲、管理者ごとの権限設定
問い合わせ対応 — 「ログインできない」などの問い合わせを、履歴付きで扱えるか
導入のスケジュール — 要件確認・構築・試験・公開の各段階の期間と、自治体側の作業

費用の考え方と、契約終了時の扱い

費用は初期費用と月額費用に分かれることが多く、月額が人口規模や登録者数に連動する場合もあります。見積を比べるときは、何に連動して費用が増えるかと、別途費用になる範囲を同じ形でそろえてもらいます。

あわせて、契約を終えるときのデータの返却と、ID の引き継ぎを仕様書に入れておきます。認証基盤は住民の ID そのものを持つため、入れ替えの際に利用者が登録し直しになると、住民の負担が大きくなります。

仕様書に転記できるチェックリスト

ここまでの観点を 10 の分類にまとめました。自治体の要件に合わせて、必須・推奨を付けて使ってください。

表は横にスクロールできます

分類	仕様書で確認する項目	参考になる資料
1. 対象範囲	住民向けか職員向けか。業務 ID との関係	デジタル庁各種 ID の管理方針
2. 本人確認	対応する本人確認の手段。手続ごとに必要な強さ。手段の追加のしやすさ	デジタル庁 DS-511、公的個人認証サービス
3. ID 連携	連携の方式（OpenID Connect 等）。接続先の追加手順と費用。受け渡す利用者情報	OpenID Connect Core 1.0、デジタル認証サービス実装ガイドライン
4. 同意・個人情報	同意の記録、規約改定時の再同意、連携解除・退会、代理・家族の扱い	個人情報保護委員会ガイドライン（行政機関等編）
5. セキュリティ・ログ	暗号化、操作ログの内容と保存期間、管理者の権限	総務省情報セキュリティポリシーガイドライン
6. データの所在・クラウド	保管場所、自治体ごとのデータ分離、第三者評価の確認方法	ISMAP、各自治体のセキュリティポリシー
7. 可用性・サポート	稼働率の定義（目標か保証か）、計画停止の通知、受付時間、障害時の連絡	各ベンダーのサービスレベル合意書
8. 移行	既存データの取り込み形式、重複の扱い、並行運用の期間	—
9. 運用・職員の画面	照会・訂正、CSV 出力の範囲、問い合わせ対応の履歴、導入スケジュール	—
10. 費用・契約終了	費用が連動する指標、別途費用の範囲、契約終了時のデータ返却と ID の引き継ぎ	—

認証基盤の調達で確認する10の分類を並べたチェックリストのイメージ — 10 の分類で確認すると、本人確認以外の要件の抜けに気づきやすい

製品を比べるときの例：RinX の場合

当社の自治体向け統合 ID 基盤 RinX（リンクス）を例に、上のチェックリストに沿って公開している内容を示します。他の製品を比べるときも、同じ分類で回答をそろえると比較しやすくなります。

本人確認 — マイナンバーカード（公的個人認証）、LINE、メールアドレス。使う手段は自治体ごとに相談して決めます
ID 連携 — OpenID Connect によるシングルサインオン、住民ポータルなどへの利用者情報の自動連携
同意・個人情報 — 同意文書の管理と、規約改定時の再同意。保護者アカウントへの子どもの紐付け
セキュリティ・データ — 国内でのデータ保管、自治体ごとのデータ分離、機密性の高い情報の暗号化、管理画面の操作履歴の記録
可用性・サポート — 稼働率の目標値 99.0%（保証値ではありません）、計画停止を除く 24 時間 365 日の提供、サポート窓口は平日 10:00〜17:00
移行・運用 — 既存の利用者データの一括取り込み、利用者の照会・訂正・CSV 出力、管理者ごとの権限設定、問い合わせ対応の履歴
導入期間と費用 — 外部システムとの連携を含めて約 4〜5 か月が目安。費用は初期導入費用と月額利用料で、いずれも自治体の人口規模に応じて目安が決まります。このほか、登録者数に応じた ID 管理費が別途かかり、専用サーバー環境や自治体独自の機能は別途お見積りです

まとめ

調達するのが住民向けの認証基盤か、職員向けの ID 管理かを仕様書の冒頭で明記する
手続ごとに必要な本人確認の強さを一覧にし、手段を後から追加できるかを確認する
連携は標準の方式を指定し、接続先を追加するときの手順と費用を確かめる
同意の記録・操作ログ・稼働率の定義を、言葉の定義まで含めてそろえる
既存データの移行と、契約終了時のデータ返却・ID の引き継ぎを入れておく

RinX の機能・導入の流れ・費用の考え方は、サービスページで確認できます。

サービスを見る

よくある質問

Q1. 認証基盤と、職員向けのシングルサインオンは何が違いますか？

使う人と守る対象が違います。住民向けの認証基盤は、住民の本人確認と、住民ポータルなどへのログインを扱います。職員向けのシングルサインオンは、職員が庁内の業務システムやクラウドサービスに入るためのものです。求めるセキュリティ対策や運用が異なるため、仕様書は分けて書くのが一般的です。

Q2. マイナンバーカードによるログインだけに対応すれば十分ですか？

手続によります。証明書の申請のように厳格な本人確認が必要な手続ではマイナンバーカードが適しますが、お知らせの閲覧のような手続まで求めると、使う人が限られます。手続ごとに必要な強さを決め、メールアドレスなどの手段と組み合わせる設計が考えられます。

Q3. ISMAP への登録は必須ですか？

本記事では断定しません。クラウドサービスに求める第三者評価の水準は、各自治体の情報セキュリティポリシーにもとづいて判断されます。仕様書では、登録状況や評価の内容をどの資料で確認するかを明記しておくと、比較がしやすくなります。

Q4. 稼働率は仕様書にどう書けばよいですか？

数値だけでなく、目標値か保証値か、計画停止を含むか、下回ったときの扱いを確認します。あわせて、計画停止の通知方法と、障害時の連絡の流れをそろえておくと、運用時の行き違いを防げます。

Q5. 導入にはどれくらいの期間がかかりますか？

連携するサービスの数や移行の有無で変わります。RinX の場合は、外部システムとの連携を含めてご相談から公開まで約 4〜5 か月が目安です。要件確認・構築・試験・公開の段階ごとに、自治体側の作業も見積もっておくと安全です。

出典・参考資料

いずれも2026年10月29日に内容を確認しています。

RinX（リンクス）

本人確認・マイページ・外部連携をひとつの基盤で提供する、自治体向けの統合 ID 基盤です。