チャットボットのSSO連携｜要件整理と受入テスト

社内向けチャットボットにSSOを設定し、担当者のアカウントでログインできても、それだけでは導入完了とはいえません。異動後も以前の部署のナレッジを閲覧できる、退職者の既存セッションが残る、設定不備によって管理者までログインできなくなるといった問題は、正常なログインだけを試しても見つけられません。

SSO（シングルサインオン）は、組織の認証情報を使って複数のサービスへアクセスする仕組みです。チャットボットでは、ログインの手間を減らすだけでなく、誰が、どの入口から、どのナレッジへアクセスでき、いつ利用できなくなるかを管理する認証境界として設計します。そのため、本人確認を行う認証、利用できる情報や操作を決める認可、アカウントを作成・変更・失効するプロビジョニングを分けて考える必要があります。

ここでは、特定製品やIdPの画面操作ではなく、要件整理と受入テストの進め方を扱います。対応方式、連携できる属性、反映時間、対象プランは製品とIdPの組み合わせによって異なります。採用候補の最新公式資料を確認し、秘密鍵、証明書、クライアントシークレットなどの実値は、作業票やチャットへ記載しないでください。

チャットボットにSSOが必要な範囲を最初に決める

SSOの設定値を集める前に、保護する情報と利用者を確定します。社内規程、顧客との契約情報、個別の会員情報など、利用者によって閲覧範囲を分ける必要があるナレッジには認証が必要です。一方、営業時間や一般公開しているサービス案内だけを扱うFAQでは、匿名で利用できる状態を残す方が目的に合う場合があります。

「社内向けだから全員が同じ範囲へアクセスできればよい」とは限りません。社員の部署や雇用区分に加え、委託先、管理者、監査担当、外部会員を切り分けます。閲覧できるナレッジ、会話ログ、設定項目、公開操作が異なる場合は、認証後に適用するロールも必要です。具体的な切り分け方は、チャットボットのアクセス権限設計で確認できます。

SSOを導入する目的も、合否を判定できる表現で記録します。「便利にする」だけでは受入条件になりません。「退職者のアクセスを組織アカウントの停止と連動して止める」「機密ナレッジを対象部署だけに表示する」「管理者の多要素認証をIdP側で統一する」など、テストで確認できる条件へ置き換えます。

利用者画面・管理画面・API・外部チャネルを分ける

製品資料に「SSO対応」と記載されていても、すべての入口に同じ認証が適用されるとは限りません。質問する人が使う利用者画面、FAQを更新する管理画面、外部システムから接続するAPI、TeamsやLINEなどの外部チャネルを別々に扱い、入口ごとに対応方式と対象プランを確認します。

利用者画面はSSOに対応していても、管理画面では別の認証が必要な場合があります。反対に、管理画面だけがSSOの対象となる構成も考えられます。また、APIでは人のブラウザログインと異なる認証方式を使うことがあります。入口ごとに対象者、認証方式、未認証時の動作、公式仕様、契約プラン、設定責任者を記録し、「SSO対応」という一項目だけで合格にしないでください。

認証・認可・プロビジョニングを混同しない

認証は利用者が誰かを確かめる工程、認可はその利用者が閲覧・操作できる範囲を決める工程、プロビジョニングは利用開始から終了までアカウントを管理する工程です。SSOでログインに成功しても、全員に同じ権限が付与されれば認可の問題が残ります。退職者のアカウントやセッションが残れば、プロビジョニングや失効の設計が不十分です。

担当範囲も分けておきます。IdP管理者は組織アカウントとグループ、チャットボット管理者はナレッジとロール、業務責任者は誰に何を見せるかを管理します。障害時に担当者間で判断が止まらないよう、各工程の確認ログ、問い合わせ先、調査する順序まで決めてください。

SAML・OIDC・SCIMの役割と対応条件を確認する

SAMLとOIDCはいずれも認証連携に使われますが、利用するフローや扱う情報は同じではありません。SCIMは主にユーザーやグループの作成・更新・削除を標準化する仕組みであり、ログインそのものを置き換えるものではありません。製品資料に方式名が並んでいるだけで、自社に必要なフローを実現できると判断しないことが重要です。

SAMLの役割と構成要素はOASISのSAML V2.0 Technical Overview、OIDCの認証フローとID Tokenの位置付けはOpenID FoundationのOpenID Connect Core 1.0、SCIMによるユーザーやグループの管理はIETFのRFC 7644で確認できます。ただし、規格に定義された機能を各製品がすべて提供しているとは限りません。

候補となる構成ごとに、IdP起点・サービス起点など必要な開始方法、識別子、属性、署名や暗号化の条件、メタデータ交換、証明書や秘密情報の更新、グループ同期、対象プランを公式資料で照合します。台帳には秘密情報の値ではなく、保管場所、更新責任者、期限前の通知方法、切替手順、失敗時の切戻し手順を記録します。

IdP属性とチャットボット側ユーザー・権限を対応させる

属性マッピングでは、同一人物を継続して識別するために何を使うかが中心となります。メールアドレスは分かりやすい一方、氏名変更、ドメイン変更、組織再編によって変わることがあります。製品が対応する不変識別子と既存アカウントの対応方法を確認し、メールアドレスの変更によって別のユーザーが作成されないようにします。

属性が欠けた利用者へ管理者権限を自動で付与する設定は避けます。未定義の部署やグループが届いた場合は、最小権限を付与する、利用を拒否する、管理者の確認を待つ、のいずれかへ安全側に倒します。複数グループに所属する場合の優先順位や、権限を外す変更が権限追加より遅れないかも確認が必要です。

受入テストでは、メールアドレスを変更した利用者が不変識別子によって既存ユーザーへ対応付くかを試します。属性が欠損した利用者については、管理者へ昇格せず、決められた最小権限または利用拒否が適用され、確認担当者が異常を把握できることまで確認します。

入社・異動・退職時の作成・変更・失効を設計する

SSO連携には、初回ログイン時にアカウントを自動作成する方式と、事前同期によってアカウントを用意する方式があります。対応状況は製品によって異なるため、初回ログイン前に必要な処理、割り当てられていない利用者の動作、ライセンス上限に達した場合の扱いを公式資料で確認します。

異動時は、追加される権限だけでなく、外れる権限を確認します。部署Aから部署Bへ異動した利用者を旧グループから外し、旧部署のナレッジ、開いたままの画面、既存セッション、保存済みリンクへアクセスできないことを試します。権限が失効するまでの時間に加え、所有していたFAQや会話レビューを誰へ引き継ぐかも決めてください。

退職時は、IdPのアカウント停止、チャットボット側の無効化、既存セッション、個人用APIキー、外部チャネル、通知先、所有データを別項目として追跡します。SCIM同期を利用する場合も即時に反映されるとは推測せず、公式仕様の反映条件と自社構成での実測を確認します。同期失敗時の通知、再同期、手動失効、完了確認についても担当者を定めます。

再雇用時には、以前のアカウントや権限をそのまま戻すのか、新しい所属と承認内容に基づいて設定し直すのかを決めます。不変識別子の扱いによっては過去のユーザーへ対応付くため、古い権限や通知先、所有データが意図せず復活しないことも受入条件に含めます。

入社・異動・退職の試験結果は、実施日時、変更元、期待する権限、実際に付与された権限、反映完了時刻、確認者とともに残します。認証イベントや設定変更を追跡する項目は、チャットボット監査ログの設計を参照して整理できます。

SSO強制前に管理者ロックアウトを防ぐ

SSOを全員へ強制した直後に、属性名の誤りや証明書の問題によって誰も管理画面へ入れなくなる事態を防ぐ必要があります。まず少人数のテストグループへ適用し、一般利用者と管理者の両方で確認します。設定担当者とは別の管理者がログインでき、設定を確認できることも確かめてください。

製品が公式に提供している場合に限り、SSO対象外の緊急管理者や復旧経路を用意します。通常業務では常用せず、資格情報の保管方法、利用時の承認者、定期確認、利用後の記録を決めます。独自の裏口を作るのではなく、提供元が示す公式の復旧手順に従います。

• 段階適用: テスト利用者、限定部署、全利用者の順に対象を広げる。
• 別管理者: 設定担当者以外が管理画面へ入り、設定を元へ戻せることを確認する。
• 変更承認: メタデータ、証明書、ドメイン、強制設定の変更を複数人で確認する。
• 更新管理: 証明書や秘密情報の期限、通知先、更新手順、旧値の失効を記録する。
• 復旧連絡: IdP担当、製品担当、業務責任者、提供元サポートへ連絡する順序を決める。

強制適用の当日は、切戻しを判断する責任者と実際に操作する担当者を待機させます。失敗条件を「ログインできない利用者が多い」のような曖昧な表現にせず、「管理者がログインできない」「必須部署の属性が欠損している」「誤った管理権限が付与される」など、即時に判定できる条件として定めます。

MFA・セッション・ログアウト・条件付きアクセスを確認する

IdPでMFAを必須にしても、チャットボット側で長期間有効なセッションが残れば、期待する再認証の頻度と実際の動作が一致しません。ログイン時のMFA、機密操作前の再認証、セッションの有効期限、アイドル時間、端末変更、パスワード変更後の動作をそれぞれ確認します。

IdPからログアウトしても、チャットボット側のセッションまで終了するとは限りません。単一ログアウトへの対応状況に加え、ブラウザを閉じた場合、共有端末、複数タブ、モバイル端末での挙動を試します。連動したログアウトに対応していない場合は、その制約を利用者へ説明し、端末管理やセッション期限によって補う方法を検討します。

条件付きアクセスを利用する場合は、端末の準拠状態、接続場所、リスク、外部利用者などの条件が、IdPとチャットボットの構成でどこまで適用されるかを確認します。委託先やゲストが組織のMFAを利用できない場合も、全利用者の条件を緩和してはいけません。別グループ、別の認証経路、公開情報だけを扱う環境など、対象を限定した方法を選びます。

本番適用前の受入テストと復旧手順を作る

受入テストは、正常な社員一人がログインできることだけで終えてはいけません。利用者種別、入口、属性、ライフサイクル、障害条件を組み合わせます。各ケースには、前提条件、操作、期待結果、実際の結果、証跡、重大度、再試験日を記録します。証跡には秘密情報や不要な個人情報を残さないでください。

IdP障害の試験では、新規ログイン、既存セッション、管理画面、APIがそれぞれどう動くかを記録します。あわせて、利用者向けの表示、緊急管理経路、問い合わせ先、復旧後の再同期、障害中に行った手動変更の照合まで確認してください。机上で手順を読むだけでなく、許可されたテスト環境で実際に操作します。ほかの異常系や証跡管理は、チャットボット公開前テストケースも参考になります。

証明書などの更新は、有効期限の直前に初めて試してはいけません。期限前に新旧設定の切替を試し、失敗時に旧設定へ戻せること、切替完了後に旧値を失効できることまで確認します。更新担当者が不在の場合の代行者と、期限通知を受ける連絡先も受入条件へ含めます。

合格条件には、必須ケースをすべて通過すること、重大な過剰権限がないこと、別の管理者が復旧できること、監査記録から操作を追跡できることを含めます。一つでも満たさない場合は強制適用を延期し、修正後に該当ケースと影響範囲を再試験します。確定した条件はAIチャットボット要件定義チェックリストへ反映し、参照した製品資料の版と確認日も添えてください。

チャットボットのSSO連携に関するFAQ

関連ガイド

• チャットボットのアクセス権限設計 — 認証後のロールと最小権限を決める際に確認できます。
• チャットボット監査ログの設計 — SSO設定の変更や認証イベントを追跡する記録項目を整理できます。
• 社内FAQチャットボットの導入手順 — 受入後に、テスト利用者から対象部署へ利用範囲を広げる手順を確認できます。
• Socratesのセキュリティ方針 — 公開済みの方針を確認し、未確認の製品機能と区別するために参照してください。