自治体で生成AIの利用が広がるほど、「誰が使っているのか」「その職員は何を参照できるのか」「異動や退職後も権限が残っていないか」が重要になります。生成AIサービスの機能や回答精度だけを比較しても、認証と権限管理が弱ければ、安全な業務利用は実現できません。
必要なのは、SSO、多要素認証、職員ID連携を別々の機能として導入することではなく、職員の在籍・所属・役割を起点に、ログイン、利用権限、データ参照範囲、利用停止、監査までを一つの流れとして設計することです。本記事では、自治体生成AIに必要な認証基盤の実装ポイントを、調達・構築・運用の視点から整理します。
SSO・MFA・職員ID連携は役割が異なる
最初に押さえたいのは、SSO、多要素認証、職員ID連携は同じものではないという点です。
| 機能 | 主な役割 | 防げる問題 | 単独では解決できないこと |
|---|---|---|---|
| SSO | 複数サービスのログインを統合する | パスワード乱立、個別アカウント管理 | 本人確認の強度、業務権限の妥当性 |
| MFA | 二つ以上の異なる要素で本人確認を強化する | パスワード漏えいによる不正ログイン | 異動・退職後の権限残存 |
| 職員ID連携 | 採用・異動・休職・退職をアカウントへ反映する | 登録漏れ、削除漏れ、手作業の遅延 | データごとの閲覧可否の判断 |
| 認可・権限管理 | ログイン後に実行できる操作を制御する | 他部署情報の過剰閲覧、管理機能の誤使用 | 本人確認そのもの |
つまり、SSOは「入口の統一」、MFAは「入口での本人確認強化」、職員ID連携は「人事異動に追随する仕組み」、認可は「入った後にできることの制限」です。この四つをつなげて初めて、自治体生成AIの安全な利用基盤になります。
まずネットワーク構成と情報区分を確定する
自治体の認証設計は、一般企業向けSaaSの設定をそのまま当てはめることはできません。マイナンバー利用事務系、LGWAN接続系、インターネット接続系のどこから生成AIへ接続するのか、採用する三層分離モデルがα、α’、β、β’のいずれかによって、接続経路や端末要件が変わるためです。
総務省の情報セキュリティポリシー関連ガイドラインは2025年3月に改定され、監査ガイドラインにもα’、β、β’の各モデルに対応する追加監査項目が設けられています。したがって、製品選定より先に、対象業務、利用端末、接続元ネットワーク、入力可能な情報、保存先、ログの保管場所を明確にする必要があります。参考：e-Gov「地方公共団体における情報セキュリティポリシーに関するガイドライン」等の改定、デジタル庁「国・地方ネットワークの将来像」関連資料
「クラウド型生成AIを使うからインターネット接続系」と単純化するのも危険です。ローカルブレイクアウト、閉域接続、セキュアブラウザ、VDIなどの方式ごとに、IdPへ到達できる経路、認証画面の表示可否、端末証明書の利用、ログ取得の責任分界を確認します。
SSOはクラウドIdPを中心に設計する
SSOでは、自治体が管理するIdPを認証の中心に置き、生成AIサービス側へ職員のパスワードを持たせない構成が基本です。連携方式は、SAML 2.0またはOpenID Connect（OIDC）が中心になります。OIDCはOAuth 2.0の上に構築された本人認証の仕組みで、IDトークンを通じて認証結果や利用者属性を連携します。参考：OpenID Connect Core 1.0
調達仕様では「SSO対応」とだけ書かず、少なくとも次を確認します。
- 自治体側IdPを利用できるか
- SAMLとOIDCのどちらに対応するか
- 電子メールアドレスではなく、変更されない職員識別子を主キーにできるか
- 署名、発行者、受信者、期限、nonceなどを適切に検証できるか
- IdP起点とサービス起点のログイン方式、セッション時間、再認証条件を設定できるか
- 個人アカウントや別テナントへのログインを制限できるか
- 障害時用アカウントを通常運用から分離し、利用時に記録と通知を残せるか
SSOは利便性を高めますが、IdPが止まると複数業務へ影響が広がります。冗長化、時刻同期、証明書更新、秘密鍵管理、障害時の手順まで含めて設計する必要があります。
MFAは「回数」ではなく攻撃耐性で選ぶ
多要素認証は、知識情報、所持情報、生体情報など、異なる種類の要素を組み合わせて本人確認を行います。ただし、MFAを導入しただけで、すべてのフィッシングや乗っ取りを防げるわけではありません。承認通知を何度も送り付ける攻撃や、偽サイトへワンタイムコードを入力させる攻撃もあります。
高い安全性が求められる生成AI環境では、WebAuthn/FIDO2に基づくパスキー、セキュリティキー、端末にひも付いた証明書など、フィッシング耐性を持つ方式を優先します。WebAuthnは公開鍵暗号を使い、端末内蔵認証器や外付けセキュリティキーなどによる認証を扱う標準です。参考：W3C Web Authentication
一方で、庁内端末、共有端末、窓口端末、テレワーク端末では利用条件が異なります。スマートフォン持込みを前提にせず、職員証ICカード、端末内蔵認証、生体認証、セキュリティキーなどから業務環境に合う組合せを選びます。また、紛失、機種変更、PIN忘れ、災害対応時の代替認証を含む復旧手順を整えなければ、強固な認証が業務停止の原因になります。
職員ID連携は人事情報を起点に自動化する
自治体では、毎年の定期人事異動に加え、兼務、併任、休職、派遣、会計年度任用職員、委託先職員など、多様な状態が発生します。生成AIだけを個別管理すると、異動後も旧所属の情報を参照できる、退職者のアカウントが残るといった問題が起こります。
実装では、人事給与システムなどを信頼できる情報源として位置付け、ディレクトリ、クラウドIdP、生成AIサービスへ順番に反映します。IdPからSaaSへのアカウント作成・更新・無効化にはSCIMが利用できます。SCIMは、ユーザーやグループなどのID情報を、HTTPを介して作成・変更・取得・削除するための標準です。参考：IETF RFC 7644：SCIM Protocol
ただし、「SCIM対応」と「異動情報が即時に正しく反映されること」は同義ではありません。同期の実行間隔、再試行、エラー通知、部分失敗、手動変更の上書き、退職時に削除するか無効化するかを定義する必要があります。特に退職・契約終了・長期休職などは、通常の夜間バッチを待たずに停止できる経路を設けます。
職員IDの主キーには、氏名やメールアドレスではなく、人事異動や改姓でも変わらない一意の識別子を使います。また、所属コードをそのまま生成AIの権限名に直結させるのではなく、「人事属性→業務ロール→生成AI権限」という変換表を設けると、組織改編時の影響を抑えられます。
認証後のデータ参照権限まで連動させる
自治体生成AIでは、ログインできることと、庁内データを参照できることを分けて考えます。RAGで規程、マニュアル、議事録、過去文書などを検索する場合、一般職員、管理職、特定部署、プロジェクト担当者では参照可能範囲が異なります。
そのため、職員IDの所属・役割・兼務情報をRBAC（役割ベースアクセス制御）やABAC（属性ベースアクセス制御）へ変換し、文書や検索インデックスのメタデータと照合します。検索結果を生成AIへ渡した後で隠すのではなく、検索段階で権限のない情報を取得しない構成が重要です。
また、グループ変更からRAG側への反映に時間差がある場合は、その時間を仕様として明示します。権限情報を更新できない状態では新しい権限を付与せず、必要に応じて検索を停止する「安全側に倒す」設計が求められます。
条件付きアクセスとテナント制御を組み合わせる
正しいIDとMFAだけでは、私物端末や危険な接続元からの利用、個人向け生成AIへの情報送信を十分に防げません。IdPの条件付きアクセスを利用し、管理対象端末、端末証明書、接続元、時間帯、リスク判定などを組み合わせてアクセス可否を決めます。
さらに、自治体が契約した生成AIテナントだけを許可し、個人アカウントや未承認サービスへのアクセスを制御します。DLPによる機密情報の検知・送信制御、ダウンロード制限、コピー制御も、業務と情報区分に応じて組み合わせます。
認証・権限・生成AI操作のログをつなぐ
監査やインシデント調査では、IdPの認証ログだけでは不十分です。「誰が、いつ、どの端末から、どの認証方式で入り、どのデータを参照し、何を入力し、どの操作を行ったか」を追跡できる必要があります。
最低限、認証成功・失敗、MFA結果、権限変更、アカウント作成・停止、管理者操作、生成AIへの入力、参照データ、出力、共有・ダウンロードを関連付けます。職員ID、セッションID、端末IDなど共通の識別子を持たせ、時刻を同期し、SIEM等で横断的に検索できる構成にします。ログには個人情報や機密情報が含まれ得るため、閲覧権限、保存期間、マスキング、改ざん防止も決めておきます。
調達仕様書に盛り込みたい確認項目
自治体が生成AIを調達する際は、製品機能だけでなく運用結果を確認できる表現にします。
| 分野 | 仕様書で確認する内容 |
|---|---|
| SSO | 自治体指定IdP、SAML/OIDC、署名・証明書更新、セッション制御 |
| MFA | 対応方式、フィッシング耐性、端末制約、復旧・再登録手順 |
| ID連携 | SCIM/API対応、同期間隔、異動・退職・休職時の処理、失敗通知 |
| 権限 | RBAC/ABAC、グループ連携、管理者権限分離、RAGの権限継承 |
| テナント | 契約テナント限定、個人アカウント遮断、データ保存場所 |
| ログ | 取得項目、保存期間、出力API、時刻同期、改ざん防止 |
| 障害対応 | IdP・連携停止時の動作、緊急停止、非常用アカウント |
| 検収 | 正常系だけでなく異動、退職、同期失敗、権限剥奪の試験 |
政府機関向けの生成AI調達・利活用ガイドラインも、利活用促進とリスク管理を一体で進める考え方を示しています。自治体へそのまま適用する文書ではありませんが、調達時のリスク整理には参考になります。参考：デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」
小さく始めてもID設計は後回しにしない
導入は、①対象業務と情報区分の整理、②職員IDと業務ロールの定義、③IdP・SSO・MFAの接続試験、④少人数でのID連携実証、⑤異動・退職・障害を含む検収、⑥段階展開の順で進めます。
小規模な実証でも共有アカウントを使わず、実運用と同じ職員IDで試すことが重要です。共有アカウントでは、利用者別の権限制御も監査もできず、本番移行時に設計をやり直すことになります。技術試験だけでなく、人事担当、情報政策担当、原課、セキュリティ担当、委託事業者の役割分担と連絡経路も確認します。
まとめ
自治体生成AIの認証基盤では、SSO、MFA、職員ID連携を一体で設計しなければなりません。SSOでログインを統合し、MFAで本人確認を強化し、人事情報を起点とするID連携で異動・退職に追随させ、さらに認可によって参照データと操作範囲を制御します。
重要なのは、「ログインできたから安全」と考えないことです。ネットワーク構成、管理端末、契約テナント、RAGのアクセス制御、ログ監査、障害時対応までを一つのIDベースの仕組みとして整えることで、生成AIの利便性と行政情報の保護を両立できます。
JAICでは、自治体のネットワーク構成や既存の職員ID管理を踏まえ、生成AI導入前の業務整理、認証・権限設計、運用ルール、職員研修までを一体で支援します。
コメント