チャットボットのアクセス権限設計｜役割を分ける方法

新しい担当者にチャットボットの編集を頼んだところ、その人が公開設定や利用者追加まで変更できる状態だった。反対に、問い合わせ対応の担当者が必要な会話を確認できず、管理者へ毎回転送を頼んでいる。こうした行き違いは、ログインできる人だけを決め、操作ごとのアクセス権限を分けていない場合に起こりやすくなります。

チャットボットには、質問する利用者だけでなく、回答元となるナレッジを整える人、公開を判断する人、会話ログを確認する人、利用者を管理する人が関わります。全員に同じ管理権限を渡すと、当初は作業が早く進むように見えます。しかし、誤公開や不要な情報閲覧が起きたときに、影響範囲を限定できません。

閲覧・質問・編集・公開・ログ閲覧・ユーザー管理を分け、役割、付与理由、期限、承認者を一枚の表で管理するのが、チャットボットのアクセス権限設計の出発点です。さらに、異動や退職に伴う変更、緊急時の剥奪、定期的な棚卸しまで決めて初めて、設計が日々の運用につながります。

アクセス権限はログインの有無だけでは決まらない

ここで最初に分けたいのが「認証」と「認可」です。認証は、ID、パスワード、外部の認証基盤などを使って、その利用者が誰かを確かめること。認可は、確認できた利用者に対して、どのデータを見せ、どの操作を許可するかを判断することです。ログインに成功した事実だけでは、ナレッジの編集や公開を許してよい根拠にはなりません。

たとえば、店舗スタッフは社内向けボットへ質問できても、回答元の資料は変更できない。本部のコンテンツ担当は下書きを編集できるものの、本番公開は別の責任者が行う。品質担当は会話ログを確認する一方、利用者の追加は情報システム部門に限る。このように、同じチャットボットを使う人でも、業務上の役割によって必要な操作は変わります。

アクセス制御を考えるときは、画面の名称より先に「誰が、何の業務のために、どの情報へ、何をするか」を書き出します。ボット単位、部署単位、拠点単位で対象を絞れる製品もありますが、設定できる粒度は製品によって異なります。製品紹介に「権限管理」と書かれていても、質問利用と管理画面利用を分けられるだけなのか、操作単位まで分けられるのかを実機や仕様書で確かめます。

最初に役割別の権限表を作る

権限名から考え始めると、「管理者」「編集者」といった大きな区分だけで話が進みがちです。先に業務で発生する操作を六つに分け、それぞれを本当に必要とする役割へ印を付けます。役割ごとに権限を定め、その役割を担当者へ割り当てれば、担当者ごとに個別設定を積み上げる場合よりも、付与理由と差分を確認しやすくなります。

これは完成形ではなく、話し合いを始めるための例です。「閲覧」が公開済みナレッジの閲覧なのか、管理画面の設定閲覧なのか、「ログ閲覧」が会話本文を含むのか集計値だけなのかによって、必要な保護は変わります。実際の表には対象ボット、部署・拠点、データ範囲も加え、曖昧な「可」を残さないようにします。

判断の軸は最小権限、つまり担当業務に必要な最小限のアクセスだけを許す考え方です。米国国立標準技術研究所（NIST）のleast privilegeの用語定義でも、利用者やプロセスへ、割り当てた作業を実行するために必要な最小限の権限だけを与える原則が示されています。単に全員の権限を弱くするのではなく、業務に足りる範囲を説明できる状態にすることが要点です。

申請書には、申請者、対象者、所属、役割、対象ボット、必要な操作、業務上の理由、開始日、終了日、承認者を記録します。「既存担当者と同じだから」という理由だけで権限を複製せず、操作ごとに必要性を確認します。複数店舗や部門の分離も必要なら、複数店舗・拠点を分けて運用する考え方と合わせて、どの単位で情報を隔てるかを決めてください。

最小権限と職務分離を一緒に考える

最小権限が「必要以上の操作を渡さない」考え方なら、職務分離は「影響の大きい処理を一人で完結させない」考え方です。ナレッジの作成、内容確認、本番公開、利用者追加、ログ確認を一人へ集中させると、誤りや不適切な変更があっても別の視点で止めにくくなります。

特に分けたいのは、ナレッジ編集と公開、ユーザー申請と承認、ログを調査する人と調査対象の設定を変更する人です。公開責任者は文章の誤字だけでなく、回答根拠、対象者、公開範囲、個人情報や社外秘の混入、有人対応へ切り替える条件を確認します。利用者管理では、申請者が自分の権限を承認できない流れにします。

ただし、人数の少ない組織で全操作を完全に分離すると、更新が止まることもあります。そこで、影響の大きさに応じて分け方を変えます。営業時間の表記修正と、契約条件や安全に関わる回答の変更を同じ承認強度にする必要はありません。高影響の変更は公開前に二者で確認し、軽微な変更は変更記録を残して事後確認する、と区分すれば日常業務へ組み込みやすくなります。

ナレッジ編集と公開を二者確認にする

二者確認は、編集者が下書きを作り、別の公開責任者が確認してから本番へ反映する流れです。公開ボタンを二人で同時に押すことではありません。変更内容と根拠、影響範囲、テスト結果を、編集者以外の人が判断できる材料としてそろえるところに意味があります。

1. 編集者が変更理由、根拠資料、対象の質問、変更前後、希望公開日を記録する。
2. 下書き環境または公開前の確認方法で、代表質問、言い換え、境界質問を試す。
3. 公開責任者が回答内容、公開範囲、個人情報・機密情報、有人切替条件を確認する。
4. 承認者、承認日時、公開した版を記録して本番へ反映する。
5. 公開後に代表質問を再確認し、問題があれば戻す版と連絡先を使って対応する。

チャットボットの回答範囲や有人対応の境界は、チャットボット運用ルールの作り方と同じ正本を参照すると、公開承認で見る項目がぶれにくくなります。アクセス権限表を整えても、承認時の確認項目が決まっていなければ、確認は形式的なものにとどまります。

製品側に下書き、承認待ち、公開者限定といった機能がない場合は、補完統制を用意します。たとえば、編集できる時間を限定する、変更票と画面差分を別の人が確認する、公開前にバックアップや復旧手順を確かめる、公開直後に責任者が実際の質問で確認する方法です。システム上の制御と同等とは限らないため、補完策で残るリスクも記録します。そのうえで、実施者、確認者、証跡、復旧手順を明確にします。

異動・退職・委託先の権限をライフサイクルで管理する

権限は付与した時点で終わりではありません。入社・参加時に付与し、異動や担当変更時に組み替え、退職・契約終了時に削除する流れを、joiner・mover・leaver（JML）と呼ぶことがあります。名称より重要なのは、人事や委託管理上の変更と、チャットボット側の権限変更を同じ期限で処理することです。

異動では新しい権限の追加に目が向き、以前の権限が残りやすくなります。「営業からサポートへ」のように役割が変わる場合は、追加申請と削除申請を一つの作業票にします。退職時は、最終出社日ではなくアクセスを停止すべき日時を人事・管理部門と合わせます。共有アカウントがあると誰の操作か追いにくいため、可能なら個人を識別できる利用方法へ切り替えます。

委託先には、作業開始時から終了日を設定します。契約が延長される可能性があっても、無期限で付与せず、業務責任者が必要性を再確認して延長します。委託会社の担当交代を自社で把握できない状態も避けます。交代・離任の連絡期限、端末紛失時の連絡先、再委託の扱いを契約担当と運用表の両方へ反映します。

緊急時は通常申請を待たずに剥奪できるようにする

端末の紛失、不審な操作、誤った大量公開、退職者アカウントの残存が見つかったとき、通常の申請締切まで待つわけにはいきません。緊急剥奪の条件、連絡経路、実行できる担当者、確認者を平時に決めます。夜間や休日に誰も操作できないなら、製品提供者への連絡方法や暫定的に公開を止める手順も確認しておきます。

緊急時は、対象アカウントや該当権限を停止して影響を限定し、その後に事実を確認します。ただし、調査に必要な記録まで不用意に消さないよう注意が必要です。製品がどの操作履歴を残すか、停止後も誰が確認できるか、保存期間はどの程度かを事前に確かめます。会話ログに個人情報が含まれる可能性がある場合は、AIチャットボットで個人情報を扱う際の注意点も踏まえ、閲覧者と利用目的を限定します。

定期棚卸しとログ確認を続ける

申請手順が整っていても、組織変更の連絡漏れや一時権限の延長によって、実態は少しずつずれます。そのため、月次や四半期など、組織や担当者の変化に合う間隔で権限を棚卸しします。頻度を一律に決めるのではなく、公開やユーザー管理のように影響の大きい権限、委託先や休職者のように状態が変わりやすい対象を優先します。

棚卸しでは、アカウントが存在するかだけでなく、現在の所属、担当業務、対象ボット、付与された役割、最終利用、終了日、承認者を照合します。利用実態が曖昧なまま残さず、業務責任者が継続の必要性を判断します。不要なら削除し、判断できない場合は期限を区切って一時停止するなど、結論と対応日を記録してください。

ログは集めるだけでは統制になりません。誰が、どの頻度で、どの事象を確認し、異常を見つけたら誰へ渡すかを決めます。一方で、製品に監査ログ機能があると仮定してはいけません。記録される操作、操作者の識別方法、検索・出力の可否、保存期間、時刻、改変防止、退職後の参照可否を仕様確認項目にします。

役割を分離できない、期限付き権限を設定できない、必要なログが出ない場合は、その差をリスクとして記録します。そのうえで、管理者を少人数に限定する、権限台帳と実画面を定期照合する、公開前後の画面を保存する、委託終了日に担当者が手動で停止して別の人が確認する、といった補完統制を置きます。補完策には実施者、頻度、証跡、見直し期限が必要です。「注意して運用する」だけでは、担当交代後に続きません。

導入前に製品へ確認する項目

アクセス権限の要件表ができたら、製品固有の役割名に無理に合わせず、六つの操作を実際に分離できるか確認します。ヘルプページの記述に加えて、試用環境で一般利用者、編集者、公開責任者のテストアカウントを用意し、権限のない画面のURLへ直接アクセスした場合に、表示や操作が拒否されるかも試します。

• 閲覧・質問・編集・公開・ログ閲覧・ユーザー管理をどの単位で分けられるか
• ボット、部署、拠点、グループごとに対象データを限定できるか
• 下書き、承認、公開、差し戻し、版の復旧をどう扱うか
• アカウント停止と権限変更が反映されるまでの時間はどの程度か
• 期限付き付与、グループ連携、認証方式を利用できる条件は何か
• どの操作ログが、どの期間、どの形式で確認・出力できるか
• 緊急停止、サポート連絡、データ保護、契約終了時の手順はどうなっているか

公的な調達要件の例として、横浜市のAIチャットボット業務説明資料では、個別IDの付与や必要最小限の権限、情報資産・端末・接続元に応じたアクセス制御などが示されています。自社で同じ要件が必須という意味ではありませんが、IDだけでなく情報、端末、接続方法まで確認する視点の参考になります。

また、製品ごとの考え方を比較する際は、OpenAIのRBAC解説や、amieのアクセス制御に関する案内のような公式資料を参照できます。ただし、他製品の役割名や設定方法をSocratesへそのまま当てはめることはできません。自社要件と検討製品の最新仕様を一項目ずつ照合します。

アクセス権限設計を始める7ステップ

1. 対象ボット、利用部署、扱う情報、公開範囲を一覧にする。
2. 閲覧、質問、編集、公開、ログ閲覧、ユーザー管理の六操作へ分ける。
3. 一般利用者、編集者、公開責任者、品質担当、利用者管理者の役割表を作る。
4. 高影響の変更は編集と公開を分け、二者確認の記録様式を決める。
5. 申請、承認、付与、異動、退職、委託終了、緊急剥奪の連絡経路をつなぐ。
6. 製品仕様との不足を洗い出し、必要なら期限管理や事後確認の補完策を置く。
7. 棚卸し日、ログ確認担当、例外の見直し期限を決め、テストアカウントで確認する。

最初から組織全体の例外をすべて整理しようとすると、権限表が複雑になり、確認が進みにくくなります。まず一つのチャットボットを選び、現在関わる人と六操作を並べてください。公開とユーザー管理の権限を持つ人、期限のない委託先、異動後も残る権限から確認すると、優先度の高い差を見つけやすくなります。

チャットボットのアクセス権限に関するよくある質問

関連記事

• チャットボットのセキュリティポリシーを整える
• 複数店舗・拠点を分けて運用する考え方
• AIチャットボットで個人情報を扱う際の注意点
• チャットボット運用ルールの作り方