重要なポイント
- アクセス制御は機能ではなくアーキテクチャである。 セルフホスト型社内チャットボットは、各セッションが取得できる範囲を従業員のアイデンティティに基づいて限定しなければならない——それは検索層とアイデンティティプロバイダーで強制するものであり、モデルに丁寧にお願いすることではない。
- 人事コンテンツは、ほぼ他のどの社内用途よりもセルフホストの強い根拠となる。 給与テーブル、傷病休暇の詳細、懲戒記録はまさに、第三者LLM APIが不要な処理者を追加してしまうデータそのものである。
- Dify・Flowise・Open WebUIなどビジュアルビルダーは、社内チャットアプリへの最速の道であり、ゼロから構築するものではない——ツール個別の詳細は各レビュー記事を参照。本ガイドは社内ヘルプデスク・人事用途に特化した構築パターンを扱う。
- SSOは、アクセス制御モデル全体が依存するアイデンティティ境界である。 チャットボットは誰が何を見られるかを判断する独自のユーザーデータベースを持つべきではなく、既存のIdPからグループ/役割クレームを取得すべきだ。
- ITヘルプデスクと人事Q&Aはリスクプロファイルの異なる別のワークロードである。 VPNリセットの誤答は不便で済むが、傷病休暇ポリシーの誤答はコンプライアンスと信頼の問題になる——それぞれ別に設計・テストすべきだ。
- 偏向率は実際に回避されたチケットに対して測定してこそ意味を持ち、チャットボット利用量に対してではない——Botが対応するカテゴリのチケット作成数を前後比較で追跡し、セッション数は追跡しない。
📍 一文で説明
Dify・Flowise・Open WebUIなどのビジュアルビルダーを使ってセルフホスト型LLM上に社内ITヘルプデスク・人事Botを構築し、モデルではなくSSOと検索範囲によって従業員単位のアクセス制御を強制する。
💬 簡潔に説明
チャットボット自体は誰が何を見られるかを決して判断しない——それを決めるのはログインシステムと文書フィルターだ。だからこそ、ある従業員の人事質問が別の従業員の給与や傷病休暇の記録を表示することはない。
クイックファクト
- アクセス制御層: 検索層とアイデンティティ層で強制され、モデルのプロンプトでは強制されない——プロンプト指示はセキュリティ境界ではない。
- 最も機密性の高い人事データカテゴリ: 給与・報酬、医療・休暇の詳細、懲戒記録、人事評価内容。
- このパターンで一般的なSSOプロトコル: OpenID Connect(OIDC)とSAML——アーキテクチャを確定する前に、使用するセルフホストビルダーのバージョン・エディションが何をサポートするか確認すること。
- 社内チャットアプリの構築パターンが確立している展開プラットフォーム: Dify・Flowise・Open WebUI——いずれもセルフホスト可能で、本サイトの別記事で詳しくレビュー済み。
- 偏向率はチケット量指標であり、同一チケットカテゴリの基準期間と比較して測定するもので、セッション数や満足度の指標ではない。
ITヘルプデスクBot vs 人事ポリシーBot:異なるワークロード
ITヘルプデスクと人事は、インフラを共有する2つの別々のBot展開として扱うべきであり、単一の汎用「社内アシスタント」として扱うべきではない。 データ機密性、アクセス制御の粒度、誤答への許容度がそれぞれ異なる。
| 項目 | ITヘルプデスクBot | 人事ポリシー/福利厚生Bot |
|---|---|---|
| 典型的な質問 | 「VPNトークンをリセットしたい」「PCが遅い」 | 「有給残日数は?」「育児休業の仕組みは?」 |
| データ機密性 | 低~中——端末/アカウントのメタデータ | 高——給与、医療、休暇、懲戒 |
| 必要なアクセス範囲 | 主に文書レベル(ランブック、ポリシー) | 文書レベル+従業員ごとの行レベル |
| 誤答のコスト | 不便、チケット再オープン | コンプライアンスリスク、信頼毀損 |
| 成功指標 | 定義済みカテゴリの偏向率 | ポリシー引用の正確性+エスカレーション率 |
人事コンテンツが特にセルフホストの恩恵を受ける理由
人事Botは「たまたま人事の話をするチャットボット」ではない——遅かれ早かれ、従業員が他人には決して言わないような質問をされる存在である。 給与比較、休暇申請の裏にある家族の医療事情、進行中の懲戒手続きに関連する質問は、人事Botにとって特殊なケースではなく通常のトラフィックだ。
- 給与・報酬データを第三者LLM APIに送ることは、ほとんどの企業が社内で人事と直属の上司にのみ制限している情報に、外部の処理者を追加することになる。
- 医療・休暇の詳細(傷病休暇に関連する申請、障害配慮に関する質問)は、多くのプライバシー枠組みで特別カテゴリの個人データに該当する——このカテゴリに触れるRAGパイプラインに適用される管理策セットはGDPR準拠のローカルRAGを参照。
- 懲戒・人事評価記録は誤った扱いをした場合に直接的な法的リスクを伴う——これらを取得できる人事Botは、展開全体の中で最も厳格なアクセス範囲を必要とする。
- 推論と検索を自社管理のインフラに留めるだけでは、GDPR、労使協議義務、業界固有の規則を満たすことにはならない——データフロー図から1つの処理者を取り除くに過ぎず、すべての義務を満たすわけではない。
- コンプライアンスを超えた実務上のメリットは、ナレッジベースに何を入れるかについて人事チームが格段に率直になれることだ。自社インフラから一切出ないなら、薄められたFAQページではなく本当に役立つBotになる。
アクセス制御:この展開の成否を分ける要件
社内人事/ITBotで最も難しい単一の要件はモデルの品質ではない——従業員Aのセッションが従業員Bの有給残日数、給与メモ、人事ファイルを絶対に取得できないという保証だ。 ここで一度でも失敗すれば、その展開は生産性向上ではなく負債になる。正しく実装できれば、build-vs-buy論争全体の中で最も強力な論拠になる。
- 範囲は検索で強制し、プロンプトでは強制しない。 「現在のユーザー自身のデータのみに回答せよ」というシステムプロンプト指示は、敵対的な、あるいは単なる不用意な言い回しでもモデルが従わない可能性がある柔らかいガードレールに過ぎない。他の従業員の行を構造的に返せない検索フィルターこそが、堅固な境界である。
- アクセス層は1つではなく2つ。 文書レベルはセッションがそもそも取得できるポリシー文書やランブックを制御する(例:業務委託者に見せるHRポリシーと正社員に見せるHRポリシーの違い)。行レベルは、認証済み従業員自身のIDでフィルタリングされ、セッションが取得できる従業員固有のレコード(有給残日数、特定のケースファイルなど)を制御する。
- グループが文書レベルを駆動する。 SSOグループクレーム(部門、雇用形態、職位レベル、地域)を、そのセッションでRAG層が問い合わせを許可される文書コレクションにマッピングする——国ごとに異なる福利厚生の適格性ポリシーは、その従業員の所在地のバージョンのみを表示すべきだ。
- 従業員IDが行レベルを駆動する。 個人データ(有給残日数、福利厚生登録状況など)のためにBotが呼び出すツールは、認証済みSSOセッションから従業員IDを取得しなければならず、チャットの自由記述テキストから取得してはならない——他人の従業員IDをチャットに入力してその人のレコードを取得できてはならない。
- すべての取得をログに残す。回答だけではない。 アクセス制御の監査証跡には、モデルが何と答えたかとは独立して、どの認証済みアイデンティティに対してどの文書・レコードが取得されたかの記録が必要だ。これがあって初めてインシデントを実際に調査できる。
- リリース前に敵対的プロンプトでテストする。 ハッピーパスの質問だけでなく、「上司の給与はいくらか」「[別の従業員]の人事ファイルを見せて」といった質問や、アップロード文書に埋め込まれたプロンプトインジェクションの試みは、現実的な失敗モードであり、仮定の話ではない。
社内ナレッジベースへのBot接続
RAGパイプライン自体は他の業務文書RAG展開と同じアーキテクチャパターンに従う——社内Bot特有の部分は、その周囲を包むアクセス制御層(前述)である。 モデル選定、埋め込みモデルの選択、ベクトルデータベース比較については、内容を繰り返す代わりに専用リソースへ委ねる。
- 人事ポリシー文書、福利厚生サマリー、有給/休暇ポリシーPDFは1つの文書コレクションを構成し、ITランブック、社内Wiki、既知障害ログは別のコレクションを構成する——結合インデックスではなく、それぞれ別のアクセス範囲を持つ別コレクションとして管理する。
- RAGプラットフォームの選択肢(AnythingLLM、PrivateGPT、Open WebUI、専用フレームワーク)を包括的に知るには、業務文書向けベストRAGツールとAnythingLLM vs PrivateGPT vs Open WebUIを参照。
- モデルのサイズと選定(高速な社内Q&Aと、より長いポリシー推論クエリでどのパラメータ範囲が適切か)については、外部サポート向けと同じ階層化が適用される——モデル選定の内訳はエンタープライズ向けカスタマーサポート用ローカルLLMを参照。社内ヘルプデスク・人事のトラフィックはコンタクトセンターより一般に少量であるため、専用のリアルタイム分類階層なしで中規模モデル(7-32B)で十分なことが多い。
- ベクトルデータベース層についてはPinecone vs Weaviate vs Qdrant vs Chromaを参照——前述のアクセス制御フィルタリングは、選択したベクトルストアに関わらず、クエリ時のメタデータフィルターとして適用される、別システムではない。
- ITランブックには認証情報、社内ネットワーク図、セキュリティ手順が含まれることが多い——このコレクションは単なる不便で済まない攻撃地図になり得るため、人事データと同じ厳格さでアクセス範囲を扱うこと。
構築パターン:ビジュアルビルダー、範囲限定RAG、SSO
Dify・Flowise・Open WebUIはいずれも、オーケストレーション層をゼロから書くことなく、モデル接続・RAG検索・チャットUIから成る社内チャットアプリを組み立てられる。 以下のパターンは構造的にはこの3つで共通であり、ツール固有のセットアップ、ライセンス、現在の機能状況は各専用レビュー記事で扱い、ここでは繰り返さない。
- 1一般的な機能の豊富さではなく、社内アプリの要件でビルダーを選ぶ
Why it matters: Open WebUIはチャット中心で、ユーザーグループとモデルアクセス制御をネイティブに備えており、この用途に必要な文書レベルの範囲設定に直接対応する。Difyは、単純なQ&Aを超えてBotが社内ツール(チケット作成、有給残日数照会)を呼び出す必要がある場合に、より完全なLLMOps/エージェント層を追加する。Flowiseはより軽量なビジュアルフロービルダーである——選定前に[Difyレビュー](/ja/power-local-llm/dify-ai-workflow-builder-review)と[Flowiseレビュー](/ja/power-local-llm/flowise-ai-visual-workflow-builder-review)で現在の機能・保守状況を確認すること。 - 2OpenAI互換エンドポイントの背後にモデルを配置する
Why it matters: vLLMや同様のOpenAI互換サーバー経由で提供すれば、基盤モデルが変わってもビルダー層は移植可能なままとなり、チャットアプリとモデル選択が分離される。 - 3範囲の異なる2つの文書コレクションを構築する:人事とIT
Why it matters: 人事とIT両方の知識を1つのアクセスポリシーを持つ単一インデックスに結合しない——機密性も想定利用者も異なる。 - 4SSO(OIDC/SAML)を認証層として組み込む
Why it matters: チャットボットは独自のログインシステムを持つべきではなく、部門・役割の正データである既存の会社アイデンティティプロバイダーからアイデンティティとグループクレームを取得すべきだ。 - 5グループクレームを文書レベルの範囲に、従業員IDを行レベルの範囲にマッピングする
Why it matters: このステップこそが実際に従業員間のデータ露出を防ぐ——詳細は前述のアクセス制御セクションの二層モデルを参照。 - 6完全な偏向の前にエージェントアシストでパイロット運用する
Why it matters: 人事/IT担当者が定義された期間、Botの回答案をレビューしてから、エンドユーザーへ直接回答させる——どのRAG展開でもリスクを下げる段階的ロールアウトと同じ考え方だ。 - 7取得をログに残し、エスカレーション経路を設定する
Why it matters: RAG層が確信を持って範囲内のソースで回答できないクエリは、モデルに推測させるのではなく、ヘルプデスクチケットや人事担当者など人間に回すべきだ。
SSO連携パターン
社内Botにとって、SSOは任意の利便機能ではない——アクセス制御モデル全体が依拠するアイデンティティ境界そのものだ。 これがなければ、チャットボットは誰が質問しているかを確実に知る方法を持たないか、あるいは実際のシステムと必然的にずれていく第二の並行アイデンティティシステムを維持することになる。
- OpenID Connect(OIDC)とSAMLは、セルフホスト型チャットアプリを会社のアイデンティティプロバイダー(Okta、Azure AD/Entra ID、Google Workspaceなど)に接続する際に一般的に使われる2つのプロトコルだ——どのプロトコルをどこまで統合できるかはビルダープラットフォームとエディションによって異なるため、プロジェクトの範囲を決める前に現行バージョンでのサポート状況を確認すること。
- アイデンティティプロバイダーはグループ・部門所属の唯一の正データであるべきで、チャットボットはセッション開始時にそれらのクレームを読み取り、重複した名簿を維持しない。
- セッションレベルのクレーム(部門、雇用形態、職位、地域)は、アクセス制御セクションで述べた通り、そのセッションでRAG層が問い合わせを許可される文書コレクションを決定する。
- 個人データの照会(有給残日数、福利厚生ステータス)では、Botが呼び出すツールは認証済みSSOセッショントークンから従業員IDを取得しなければならず、チャットにユーザーが入力したテキストからではない——これにより、他人のIDを入力してそのレコードを取得することができなくなる。
- チャットボットのセッションタイムアウトと再認証ポリシーは、チャットアプリ側で緩く独自に設定するのではなく、会社の既存のSSOセッションポリシーに合わせるべきだ。
ITチケット偏向率を誠実に測定する
「偏向率」は、実際に回避されたチケットではなくチャットボットのセッション数を数えることで簡単に水増しできる——実際の基準値がなければその数字は無意味だ。 人事Botの場合、対応する指標は偏向率ではなく回答精度と適切なエスカレーション率である。ほとんどの人事対応はエンドツーエンドで完全自動化すべきではないからだ。
- リリース前に、Botが影響を与えるべきチケットカテゴリ(パスワードリセット、VPNアクセス、ソフトウェア申請、よくある操作方法の質問)を定義し、比較可能な過去期間からそれらのカテゴリの基準チケット作成数を取得する。
- 偏向されたチケットとは、従業員の質問がチャットで解決されたために作成されなかったチケットのことであり、単に発生したチャットセッションではなく、結局チケット開設に終わったセッションでもない。
- 偏向率は、定義済みカテゴリのチケット作成量のパーセンテージ変化として、そのカテゴリにおけるBotの回答精度と合わせて報告する——高い偏向率と低い精度が組み合わさっている場合、通常は従業員が助けを得たのではなく質問することをやめただけを意味する。
- 人事については、エスカレーション率(Botが自ら回答せず正しく人間に回した頻度)を主要な品質指標として追跡する——曖昧または機微な質問で決してエスカレーションしないBotは、エスカレーションしすぎるBotより大きなリスクである。
- 基準値は定期的に取り直す。あるカテゴリのチケット量は、ポリシー変更やシステム修正によってBotとは無関係に自然に減少することがあり、その減少をBotの手柄とすることは効果を過大評価する。
よくある失敗
失敗する社内Bot展開のほとんどは、モデル選定やツール選びではなく、アクセス制御の範囲設定で失敗している。
- 構造的に検索で強制する代わりに、「現在のユーザー自身のデータのみ回答せよ」というシステムプロンプト指示をアクセス制御メカニズムとして頼りにすること——これは敵対的な言い回しはもちろん、時には普通の言い回しでも破綻する。
- 人事とIT両方のコンテンツを1つのアクセスポリシーを持つ共有インデックスに結合すること。適切に範囲設定された2つの別コレクションにすべきである。
- SSOを省略し、「とりあえず」独自のログインやオープンアクセスのチャットアプリを構築すること。これは信頼できるアイデンティティシグナルを持たないか、管理されない技術的負債として蓄積する。
- Botが低リスクなITヘルプデスクカテゴリで実績を積む前に、機微なカテゴリ(休暇、懲戒、報酬)で人事のセルフサービス偏向を開始すること。
- 実際のチケット作成数を基準値と比較する代わりに、チャットボット利用量で偏向率を測定すること——これは経営陣に対してROIを過大に見せる。
- リリース前に敵対的プロンプト(他の従業員のデータを尋ねる、アップロード文書経由のプロンプトインジェクション)をテストしないこと。
出典
- OpenID Connect仕様 — アイデンティティクレームに基づくアクセス範囲設定に関連して参照したSSOプロトコル。
- SAML 2.0仕様、OASIS — エンタープライズで広く使われる代替SSOプロトコル。
- Open WebUIドキュメント — 構築パターンに関連して参照したユーザーグループ・モデルアクセス制御機能。
- vLLMドキュメント — モデル接続ステップに関連して参照したOpenAI互換サービング層。
よくある質問
チャットボット経由で、ある従業員が別の従業員の人事データを見てしまうのをどう防ぐか?
アクセス範囲を検索層とアイデンティティプロバイダーで強制し、モデルのプロンプトでは行わない。文書レベルの範囲(セッションが問い合わせられるポリシー文書)はSSOグループクレームによって決まり、行レベルの範囲(有給残日数のような従業員固有のレコードをセッションが照会できるか)は、チャットに入力されたテキストからではなく、SSOセッショントークンから取得した認証済み従業員自身のIDによって決まる。プロンプト指示だけではセキュリティ境界にはならず、敵対的な言い回しでも通常の言い回しでも破綻し得る。
Dify、Flowise、Open WebUIはこのアクセス制御を自前で強制できるか?
Open WebUIはネイティブなユーザーグループ・モデルアクセス制御機能を備えており、文書レベルの範囲設定にうまく対応する。DifyとFlowiseは、検索フィルタリングとアイデンティティクレームのロジックを自ら構築するワークフロー/オーケストレーション層を提供する。本ガイドで述べた従業員単位の行レベルフィルタリングは、プラットフォームのRAGとアイデンティティ統合の上に自分で設定するものであり、あらゆるエッジケースに対してあらかじめ完成した機能として提供されるわけではない——使用しているセルフホストバージョンでの現在の機能をDifyレビューとFlowiseレビューで確認すること。
なぜ人事チャットボットのデータを第三者クラウドLLM APIから遠ざけるべきなのか?
人事コンテンツには日常的に給与・報酬額、医療・休暇の詳細、懲戒・人事評価記録が含まれるからだ。これらはほとんどの企業が社内で人事と直属の上司にのみ制限しているカテゴリであり、多くのプライバシー枠組みで強化された保護対象となる。そのコンテンツを第三者APIへ送ることは、多くの組織が社内で特に制限しているデータに外部処理者を追加することになる。セルフホストはその処理者をデータフロー図から取り除くが、それ単独では適用されるすべてのコンプライアンス義務を満たすわけではない——必要な管理策セットは専用ガイドGDPR準拠のローカルRAGを参照。
ITヘルプデスクBotと人事ポリシーBotの違いは何か?
これらはリスクプロファイルの異なる別のワークロードであり、単一の統合された「社内アシスタント」ではなく、インフラを共有する別の展開として構築すべきだ。ITヘルプデスクの質問(パスワードリセット、VPNアクセス)はデータ機密性が低く、誤答のコストも低い。人事の質問(有給残日数、休暇ポリシー、福利厚生)はデータ機密性が高く、文書レベルに加えて従業員単位の行レベル範囲を必要とし、誤ったまたは漏洩した回答は不便で済まずコンプライアンスと信頼の問題になる。
セルフホスト型社内チャットボットにSSOはどう統合されるか?
チャットボットは独自のログインシステムを維持する代わりに、OpenID ConnectまたはSAMLを通じて会社の既存のアイデンティティプロバイダー経由で従業員を認証する。アイデンティティプロバイダーはログイン時にグループ・部門・役割クレームをセッションへ渡し、RAG層はそのクレームを使ってそのセッションが問い合わせを許可される文書コレクションをフィルタリングする——これがアクセス制御モデル全体の基盤となる仕組みだ。正確なプロトコルサポートと統合の深さはビルダープラットフォームとエディションによって異なるため、プロジェクトの範囲を決める前に現在の対応状況を確認すること。
ITチケット偏向率を正確に測定するには?
リリース前にBotが影響を与えるべき具体的なチケットカテゴリを定義し、比較可能な過去期間からそれらのカテゴリの基準チケット作成数を取得し、リリース後のそれらのカテゴリのチケット作成数の減少率をBotの回答精度と合わせて報告する。実際に回避されたチケットではなくチャットボットのセッション数を数えることは数字を水増しする。高い偏向率と低い精度の組み合わせは通常、従業員が助けを得たのではなく質問することをやめただけを意味する。
人事チャットボットは回答を完全自動化すべきか、それとも常に人間を介在させるべきか?
ほとんどの人事展開はエージェントアシストから始めるべきだ——Botがポリシー引用付きで回答案を作成し、人事チームメンバーが従業員に届く前にレビューする——そして、リスクが最も低く定義が明確なカテゴリ(一般的な有給残日数照会、標準的なポリシーFAQ)のみ直接セルフサービスへ拡大する。機微なカテゴリ(医療事情に関連する休暇、懲戒案件、報酬に関する質問)は設計上人間へ回すべきであり、エスカレーション率を自動化の失敗としてではなく、主要な品質指標として追跡すべきだ。
社内ヘルプデスクや人事チャットボットにはどのモデルサイズが適切か?
社内ヘルプデスク・人事のトラフィックは外部コンタクトセンターより一般に少量であるため、7-32Bパラメータ範囲の中規模モデル(例:Qwen2.5/Qwen3やMistral)で、検索に基づくQ&Aとポリシー推論クエリの両方に通常十分であり、大量ライブチャットのコンタクトセンターが必要とするような専用の小型モデルによるリアルタイム分類階層は不要なことが多い。より詳細なモデル階層化はエンタープライズ向けカスタマーサポート用ローカルLLMを参照。ここではより少ない量的要件でそれが適用される。
ITランブックは人事データと同じ厳格なアクセス制御を必要とするか?
はい。ITランブックには認証情報、社内ネットワークトポロジー、セキュリティ手順が含まれることが多く、人事記録のような個人データではないものの、誤った対象へ漏洩すれば攻撃地図として機能するコンテンツだ。IT知識を本質的に低リスクとして扱うのではなく、ランブックへのアクセスを役割と必要性(ITスタッフや特定のエスカレーション階層など)で範囲設定し、人事コンテンツと同じ文書レベルのアクセス制御メカニズムを使うこと。