Blog

2026.09.02

社内規程 検索 AIの作り方|タイ拠点で誤回答と権限漏れを防ぐ設計

社内規程 検索 AIの作り方|タイ拠点で誤回答と権限漏れを防ぐ設計

「就業規則の最新版はどれか」「休暇申請は何日前までか」「日本人駐在員とタイ人スタッフで手当の条件は違うか」。こうした質問に答える社内規程 検索 AIは、生成AIのなかでも効果を説明しやすい用途です。ただし、PDFをまとめて読み込ませ、回答が自然なら完成という話ではありません。実務で問われるのは、どの版を、いつの時点で、誰の権限で検索し、どの根拠を示し、どこから人の承認に戻すかです。本稿では、タイ拠点でRFPやPoCを始める担当者向けに、版管理、権限トリミング、根拠引用、承認境界、受入試験を一つの設計として整理します。

社内規程 検索 AIは「回答装置」ではなく「規程への案内装置」

最初に用途を正しく定義します。社内規程検索AIの仕事は、社員の質問に対し、閲覧を許された有効な文書から該当箇所を探し、回答案と根拠を返すことです。人事判断を自動化することでも、規程に書かれていない例外を創作することでもありません。

この区別は言葉遊びではありません。「休暇は何日前までに申請するか」は、規程の条文を探す検索業務です。一方、「家族の事情があるので締切後でも認めるべきか」は、権限者が事情を踏まえて決める承認業務です。両者を同じチャット画面で扱うとしても、前者は根拠付き回答、後者は担当部署への引き継ぎという異なる動作が必要です。

一般的なRAGの仕組みや多言語検索の費用構造は、RAG構築の費用と進め方で詳しく説明しています。また、利用チャネルや言語を含む導入全体の考え方は、チャットボット導入の費用と多言語設計も参考になります。本稿はその先、社内規程という「最新版と権限を間違えると困る文書」に対象を絞ります。

単純な全文検索との違い

全文検索は、入力した語を含む文書を見つけるのが得意です。しかしタイ拠点では、社員がタイ語で「出産休暇」と尋ね、正本は英語、補足通知は日本語ということがあります。表記が一致しない質問、言い換え、会話形式の確認には、意味検索と生成による説明が役立ちます。

一方、生成AIは流暢さゆえに、見つからない情報をそれらしく補う危険があります。したがって評価軸は「会話が自然か」だけでは足りません。正しい文書を取得できたか、無効な旧版を除外できたか、閲覧不可文書を一切返さないか、根拠が回答を本当に支えているかを別々に測ります。

失敗の中心はモデルではなく、文書の状態にある

社内規程検索のPoCで最初の10問がうまく答えられても、本番品質とは限りません。テスト担当者が知っている代表質問には、きれいなPDFと明確な条文が用意されがちです。本番では、改定前後の規程が同じフォルダにあり、工場通達だけ有効期間が短く、表の注記に例外があり、スキャンPDFのタイ語がOCRで崩れています。

文書を「ファイル」ではなく「統制されたレコード」として扱う

検索対象の各文書に、少なくとも次のメタデータを持たせます。

項目検索時の役割
文書IDHR-LEAVE-001ファイル名変更後も同一規程を追跡する
版番号Rev. 4旧版との優先関係を決める
発効日2026-07-01質問時点で有効か判定する
失効日空欄、または2026-06-30過去時点検索と現行検索を分ける
適用法人・拠点TH01 / Bangkok HQ別法人の規程混入を防ぐ
対象者区分正社員、派遣、駐在員適用範囲を絞る
正本言語Thai / English翻訳より優先する根拠を示す
承認者HR Director統制済みか確認する
機密区分Internal / HR Restricted権限制御へ渡す
原本URLDMSの恒久リンク利用者が原文を確認する

「最新版」というフォルダ名はメタデータの代わりになりません。最新版フォルダの中に policy_final_v2_revised.pdf が三つある状態では、AI以前に人も判定できないからです。DMSやSharePointを正本にするなら、検索インデックスは正本を複製する場所ではなく、正本の状態を追随する派生物と位置づけます。

回答時点を必ず表示する

同じ質問でも、回答時点によって正解が変わります。チャット画面には「2026年9月2日時点」「HR-LEAVE-001 Rev.4、2026年7月1日発効に基づく」のように表示します。利用者が過去時点を指定できる場合は、現行検索と履歴検索をUI上で明確に分けます。

回答ログにも、質問日時だけでなく、参照文書ID、版、取得チャンク、インデックス更新時刻、モデルまたは回答サービスのバージョンを残します。後日規程が改定されたとき、「今なら違う答えになる」ことと「当時のシステムが誤った」ことを区別するためです。

社内規程 検索 AIの作り方|タイ拠点で誤回答と権限漏れを防ぐ設計 - figure 1

ナレッジ検索 AIの基本構成:取得前に権限を絞る

安全な構成は、認証、認可、検索、回答生成、監査を分けます。利用者がログインすると、ID基盤から所属会社、拠点、部署、雇用区分、役割など、必要最小限の属性またはグループを取得します。検索層はその権限に合う文書だけを候補にし、生成モデルには絞り込み後の断片だけを渡します。

「検索してから隠す」では遅い

危険な設計は、全社の文書を検索し、生成した回答から機密語を削る方式です。モデルに渡った時点で、回答文、ログ、トレース、キャッシュなどに情報が残る可能性があります。権限チェックは出力後ではなく、取得前または取得と同時に行う必要があります。

Microsoftの2026年8月時点の公式文書は、Azure AI Searchで、利用者やグループの識別子を文書側の権限情報と照合して検索結果を絞るパターンを説明しています。同時に、ネイティブACL/RBACやPurview連携の一部は 2026-08-01-preview と明記され、外部で変更された権限の反映に遅延があり得るとも注意しています。ここから得るべき結論は「Azureなら自動的に安全」ではありません。採用製品を問わず、権限情報をどこから取得し、いつ同期し、同期失敗時に閉じるかを仕様にすることです。

OWASPのLLM08:2025も、RAGで権限制御が不十分な場合の不正アクセス、異なる利用者間の情報漏えい、データ汚染を挙げ、権限対応のベクトルストア、データ分類、検証、監視を推奨しています。ベクトルだけを匿名化された安全な数値と思わず、原文と同等に管理対象へ入れます。

権限トリミングの受入条件

RFPには「AD連携可能」とだけ書かず、次を要求します。

  1. 権限のない文書は検索上位候補、引用、要約、会話履歴のいずれにも現れない。
  2. 人事異動やグループ削除が定めた時間内に反映される。
  3. ID基盤や権限照会が失敗した場合、全件表示ではなくゼロ件または安全なエラーになる。
  4. 管理者のデバッグ権限は通常利用と分離し、使用履歴を監査できる。
  5. 文書、チャンク、埋め込み、キャッシュ、ログの削除が連動する。

「権限同期はほぼリアルタイム」という説明では受入判定ができません。「異動登録から15分以内」「権限照会失敗時は0件」「退職アカウントは即時拒否」のように、時間と期待結果で記述します。

根拠引用はリンクだけでなく、版・箇所・一致度まで設計する

就業規則チャットボットに「出典はこちら」とPDFトップへのリンクだけを付けても、利用者は40ページのどこを読めばよいか分かりません。引用には文書名、文書ID、版、発効日、条番号またはページ、引用断片、正本リンクを含めます。

回答と根拠の関係を検査する

検索評価では、次の三つを分けます。

評価問い代表指標
Retrieval正しい根拠を候補に取れたかRecall@k、正解文書の上位到達率
Grounding回答が取得根拠に支えられているか文ごとの根拠充足率、引用整合率
Answer利用者の質問へ正しく答えたか正答、部分正答、回答拒否、誤答

検索に正解文書が入っているのに回答が間違う場合は、プロンプトや文脈構成の問題です。検索自体が外しているなら、チャンク、メタデータ、OCR、クエリ翻訳、ランキングを直します。この切り分けなしにモデルを交換すると、同じ失敗を高価なモデルで繰り返します。

「分からない」を成功として扱う

規程にない質問への拒否は、欠陥ではなく必要な機能です。例えば「勤続3年なら特別ボーナスはいくらか」と聞かれ、該当規程がないなら、「参照可能な有効文書では確認できません。HRへ確認してください」と返すべきです。

受入試験では、答えがある質問だけでなく、答えがない質問、条件不足の質問、複数規程が矛盾する質問も含めます。回答率を上げる目標は、誤答率を上げる誘惑になります。業務上は「正しく答える」「安全に聞き返す」「人へ渡す」の三択で評価します。

就業規則 チャットボットの承認境界を先に決める

人事領域では、同じ文章でも情報提供と意思決定の境界が重要です。AIが条文を案内することと、社員の権利義務を確定することは同じではありません。

質問・処理AIの役割人の役割
休暇申請期限の確認有効規程と条文を提示不要、ただし例外相談先を表示
手当の一般条件対象区分を確認し規程を提示個別適用の最終確認
懲戒、解雇、ハラスメント相談窓口と関連規程を案内HR・法務が判断、秘密性を確保
給与明細の個人値規程検索とは別の認証済み業務APIへ誘導訂正・例外を承認
工場安全ルール手順と原文を提示現場責任者が停止・再開を判断
規程改定案比較・影響箇所抽出を補助労務・法務・経営が承認

特に懲戒、採用、評価、解雇、医療情報、労働組合に関わる質問は、利用ログ自体がセンシティブになり得ます。チャット全文を「改善目的」で無期限保存する設計は避け、目的、閲覧者、保存期間、匿名化、削除手続きを定めます。

多言語回答では「正本」と「説明」を分ける

タイ拠点では、タイ語で質問し、日本語または英語の規程を参照する場面があります。回答画面に、正本言語、AIによる説明言語、翻訳の扱いを表示します。翻訳文が参考訳なら、正本より強い効力を持つように見せてはいけません。

重要用語は対訳辞書を管理します。例えば probation、severance pay、working day の訳が文書ごとに揺れると、検索結果も説明も不安定になります。法的意味を持つタイ語の用語は、HRや現地専門家が承認した対訳を使い、生成AIだけに決めさせません。

社内規程 検索 AIの作り方|タイ拠点で誤回答と権限漏れを防ぐ設計 - figure 2

タイPDPAを「クラウド可否」だけの話にしない

タイのPersonal Data Protection Act(PDPA)は、個人を直接または間接に識別できる情報を対象とします。社内規程そのものが一般文書でも、規程の付表に社員名がある、質問文に病歴や家族事情が書かれる、ログに社員IDと相談内容が結び付く、といった経路で個人データを処理し得ます。

したがって「規程PDFだから個人情報はない」という入口判定では不十分です。次のデータフローを図にします。

  1. 文書がどこから取り込まれるか。
  2. OCR、埋め込み、検索インデックス、LLM推論がどの環境・地域で処理されるか。
  3. 質問、回答、フィードバック、監査ログを誰が閲覧でき、いつ削除するか。
  4. 委託先と再委託先が何を扱うか。
  5. モデル改善やサービス改善への利用設定がどうなっているか。

法的根拠、通知、委託契約、国外移転、保存期間、データ主体の権利対応は、実際の構成と目的に基づきDPOまたはタイ法の専門家が確認すべき事項です。本稿は特定の構成がPDPAに適合すると保証するものではありません。

ETDAの2024年の組織向けGenerative AI Governance Guidelineは、便益と制約、リスク、導入、ガバナンス上の考慮を一連で扱っています。さらにETDAは2026年7月1日の発信で、AIガバナンスを文書だけで終わらせず、評価、テスト、監査、継続的改善へ移す考えを示しました。社内規程検索でも、プライバシーポリシーを一枚作るだけでなく、権限漏れ試験、誤答レビュー、改定反映時間の測定まで運用に組み込むことが重要です。

PoCを「正答デモ」から受入試験へ変える

PoCの目的は、10問に答える動画を作ることではありません。残る不確実性を、限られた範囲と期間で測定することです。対象部署、文書群、利用者群、言語、除外業務を決め、合否基準を開始前に合意します。

推奨するテストセット

最低でも次の種類を含めます。

  • 現行版に明記された単純質問
  • 条件が二つ以上ある質問
  • 表、脚注、別紙を読まないと答えられない質問
  • 日本語文書をタイ語で尋ねる交差言語質問
  • 旧版なら答えが違う質問
  • 権限のある人とない人で結果が変わる質問
  • 規程に答えがない質問
  • 個別判断を求め、人へ渡すべき質問
  • 表記ゆれ、誤字、略語を含む質問
  • 文書内の命令文がAIの指示に見えるプロンプトインジェクション試験

各質問には、期待する文書IDと版、許容回答、禁止回答、必要な聞き返し、引き継ぎ先を付けます。評価者が後から感覚で点数を付けないよう、ゴールドセットを先に作ります。

合否指標の例

以下は標準値ではなく、100問の検証セットを使う社内規程検索PoCの「設計例」です。業務リスクに応じて厳しくしてください。

指標合格例注記
正解文書が上位5件に入る率95%以上文書取得の評価
根拠引用が回答を支える率95%以上回答文単位で判定
重大誤答0件権利、懲戒、安全等の誤案内
権限漏れ0件1件でも不合格
答えなし質問の安全な拒否90%以上人への引き継ぎを含む
改定反映時間30分以内合意したSLAの例
P95応答時間8秒以内ネットワーク条件を固定

「95%」だけを見るのは危険です。簡単な質問95問が正解で、懲戒や休暇権利の5問を誤るシステムは業務上受け入れられません。重大度を付け、権限漏れと重大誤答はゼロ許容にします。

NISTの枠組みをチェックリスト化する

NIST AI 600-1は、生成AIの信頼性リスクを設計、開発、利用、評価にわたって管理するための任意の横断的プロファイルです。タイ法ではありませんが、PoCだけでなく運用までを見る整理軸として使えます。

  • Govern: 責任者、禁止用途、承認者、変更管理を定める。
  • Map: 利用者、影響を受ける人、文書、データフロー、失敗時の影響を把握する。
  • Measure: 正答、根拠、権限、拒否、速度、言語別性能を測る。
  • Manage: 重大度で優先順位を付け、停止、修正、再試験の手順を持つ。

フレームワーク名をRFPに書くだけでは効果はありません。誰が、どの証跡を、いつ確認するかへ変換します。

RFPに書くべき要件:機能一覧より証跡を要求する

ベンダー比較では、モデル名やベクトルDB名より、要件をどの証跡で受け入れるかが重要です。

要件領域RFPで求める内容受入証跡
文書統制版、発効日、失効日、拠点、対象者を保持文書台帳と更新試験ログ
権限制御元システムの権限を検索時に反映、失敗時は閉じる役割別の負例テスト
根拠条文・ページ・版・正本URLを表示回答と引用の照合表
多言語質問言語と正本言語が違う場合の評価言語別スコアと誤訳一覧
安全な拒否根拠不足・権限不足・条件不足を区別拒否テスト結果
監査文書版、検索結果、回答、利用者、時刻を追跡マスキング済み監査ログ
運用改定、削除、障害、モデル変更時の手順Runbookと復旧演習
データ保護保管場所、委託先、暗号化、保持、削除データフローと契約資料

提案書の「精度90%以上」は、母集団、採点方法、言語、質問難度がなければ比較できません。自社のテストセットで再現できる数値だけを採用します。また、プレビュー機能へ依存する提案には、一般提供までの代替策、API変更時の費用、権限同期の制約を明記させます。

8週間PoCの進め方と費用の考え方

次は、1拠点、3言語、規程300ファイル、利用者50名を仮定したモデル計画です。以下の配分比率はTOMAS TECHの公開価格でも市場統計でもなく、見積項目の抜けを確認するためのモデル例です。OCR品質、DMS連携、ID連携、文書の整理度で大きく変わります。

主作業完了条件
1用途、禁止範囲、責任者、データフロー1ページのスコープと承認境界
2文書棚卸し、版・権限メタデータ設計対象台帳と除外一覧
3OCR、チャンク、対訳辞書、インデックス代表文書を検索可能
4認証・権限トリミング、引用UI役割別テストが通る
5100問ゴールドセット作成HRが期待結果を承認
6検索・回答・拒否の改善指標の一次測定
7セキュリティ、PDPA、運用レビューリスクと残課題を記録
8再試験、RFP/本番判断合否と次フェーズ見積

予算枠は固定金額ではなく、総予算を100とする配分モデルで比較すると誤解が減ります。初期仮説は、文書整理・OCR 15%、検索/回答プロトタイプ 35%、ID・権限連携 20%、テスト設計と実施 20%、運用設計・教育 10%です。これは市場価格ではなく、見積項目の抜けを発見するための配分例です。既存DMSにAPIがあり、特殊な手書きOCRや基幹システムへの書き戻しを含まないケースを想定しています。

文書が整理済みなら前処理比率は下がります。逆に部署ごとの例外グループが多い、アクセス権を複数システムから合成する、過去時点検索も提供する場合は、権限連携とテストの比率が増えます。ベンダーには総額だけでなく、文書数、対象言語数、権限パターン数、ゴールドセット件数、再試験回数を数量として提示してもらいます。これなら前提が変わったときの増減を追跡できます。LLMの利用料だけを比較しても、プロジェクト総額は決まりません。

社内規程 検索 AIの作り方|タイ拠点で誤回答と権限漏れを防ぐ設計 - figure 3

本番後の運用:規程改定のたびに再試験する

社内規程検索AIは、公開した日に完成するシステムではありません。規程、組織、権限、モデル、検索サービスが変わります。変更の種類ごとに再試験範囲を決めます。

最低限の運用サイクル

  1. 規程管理者が正本を承認し、発効日と旧版の失効日を登録する。
  2. 取り込み処理が差分を反映し、件数、失敗、権限を検証する。
  3. 当該規程の代表質問と、旧版を返さない負例を自動試験する。
  4. HRが重要回答を確認してから一般利用へ反映する。
  5. 未回答、低評価、引き継ぎを定期レビューし、文書不足と検索不良を分ける。
  6. モデルや埋め込みを変更するときは、同じゴールドセットで回帰試験する。

利用率だけをKPIにすると、チャットを使わせることが目的になります。見るべきは、問い合わせの自己解決率、HRへ渡った質問の分類、根拠閲覧率、旧版回答ゼロ、権限事故ゼロ、改定反映SLAです。問い合わせが減らない場合も、AIの精度だけでなく、規程が曖昧、例外が多い、承認経路が見えないといった業務側の原因が発見できます。

版改訂を止めないRACIを決める

「規程が変わったら誰かがAIも直す」では、最初の人事異動で運用が止まります。文書ごとにRACIを決めます。ResponsibleはDMSへの登録とメタデータ入力を行う規程管理者、Accountableは発効を承認する部門長、Consultedは労務・法務・情報セキュリティ、Informedはヘルプデスクと利用部門です。検索基盤の運用者は規程内容を承認せず、承認済み状態を正しく反映する責任を持ちます。この分離により、IT担当者が意味を判断して旧版を消すような危険な属人運用を避けられます。

緊急通達には通常改定と別の経路を用意します。有効期間、対象拠点、上書きする文書ID、承認者を必須にし、期限到来時に自動失効させます。ただし自動失効後に参照先がゼロになる場合は、単に消すのではなく規程管理者へアラートを出します。通常版、緊急版、参考資料の優先順位を検索ロジックに埋め込むだけでなく、利用者画面にも「臨時通達を優先」と表示します。

監査ログは「全文保存」ではなく検証目的から逆算する

監査で再現したいのは、誰が何を質問したかだけではありません。どの認証主体が、どの権限スナップショットで、どの文書ID・版・チャンクを取得し、どの回答サービス版が何を返したかです。一方、質問全文には健康、家族、懲戒相談などが含まれ得ます。そこで、アクセス監査用イベント、品質改善用サンプル、セキュリティ調査用の詳細ログを分け、閲覧権限と保持期間を別にします。

例えば通常のアクセス監査には利用者の仮名ID、時刻、文書ID、許可・拒否結果、相関IDを残し、回答全文は原則含めません。品質改善に全文が必要なら、対象期間とサンプル率を定め、センシティブ表現をマスキングし、HRが承認した担当者だけが閲覧します。セキュリティ事故時に詳細を保全する手続きも、通常運用から分離します。ログが多いほど安全なのではなく、目的に必要な証跡を、必要な人だけが、必要な期間扱えることが重要です。

改定リハーサルを本番前に一度行う

受入試験の最終日に、架空の規程をRev.4からRev.5へ改定し、発効前、発効後、旧版参照、権限変更、撤回までを通しで試します。確認するのは、DMS登録からインデックス反映までの時間、旧版が現行質問へ出ないこと、過去時点検索では旧版が残ること、引用表示がRev.5へ切り替わること、失敗時にロールバックできることです。これを行うと、デモでは見えなかった承認待ち、同期ジョブ、キャッシュ、監視通知の切れ目が明らかになります。本番移行判定には、正答率だけでなく、この改定リハーサルの証跡も含めます。

FAQ:社内規程・ナレッジ検索 AIのよくある質問

社内規程 検索 AIと普通の社内検索は何が違いますか?

普通の検索は文書候補を返すのが中心です。社内規程検索AIは、質問の言い換えや多言語を扱い、該当箇所に基づく説明を返せます。ただし説明を生成する分、誤答の管理が必要です。正本リンク、版、発効日、引用箇所を併記し、利用者が原文へ戻れることが前提です。

ナレッジ検索 AIなら回答の誤りはなくなりますか?

なくなりません。RAGは社内文書を根拠として渡せますが、検索ミス、旧版混入、OCR誤り、矛盾する文書、生成時の取り違えは残ります。検索、根拠整合、最終回答を別々に評価し、根拠がないときは回答しない設計が必要です。

就業規則 チャットボットはタイPDPAに対応できますか?

製品名だけでは判断できません。規程、質問文、回答、社員ID、ログのどこに個人データがあるか、目的、法的根拠、通知、委託、保管地域、保存期間、権利対応を実構成で確認します。DPOやタイ法専門家によるレビューをPoCに含めるのが安全です。

ドキュメント 検索 生成AIで部署別の閲覧権限を維持できますか?

可能ですが、設計と試験が必要です。利用者のグループと文書権限を検索時に照合し、許可された文書だけをモデルへ渡します。権限同期の遅延、異動・退職、照会障害、管理者操作まで負例試験を行い、障害時に全件表示しないことを確認します。

何ファイルからRAGが必要ですか?

ファイル数だけでは決まりません。文書量、更新頻度、権限の複雑さ、言語、回答速度、引用要件で判断します。少数の短い文書なら、固定コンテキストや整理済みFAQの方が簡単です。PoC前に文書棚卸しを行い、最も単純な構成から比較します。

PoCの成功をどう判定しますか?

開始前に、正しい文書の取得率、引用整合率、重大誤答ゼロ、権限漏れゼロ、安全な拒否率、改定反映時間、応答時間を合意します。代表的な質問だけでなく、旧版、権限なし、答えなし、言語横断、個別判断の質問を含むゴールドセットで判定します。

まとめ:問い合わせ前に決めるべき六つのこと

社内規程検索AIの成否は、モデルの知識量より、次の六つで決まります。

  1. どの文書・版を正本とするか。
  2. いつの時点の回答かをどう示すか。
  3. 誰がどの文書を検索できるか。
  4. 回答と根拠をどの粒度で結び付けるか。
  5. 何をAIが答え、何を人へ戻すか。
  6. どの負例を含む試験で受け入れるか。

この六つが決まれば、RFPは「チャットボットを作れる会社」の比較から、「自社の規程統制を壊さず、証跡付きで運用できる構成」の比較に変わります。反対に、ここが曖昧なままでは、デモが流暢でも本番判断はできません。

TOMAS TECHでは、タイ拠点の社内規程・多言語文書を対象に、文書棚卸し、権限設計、PoCの100問テスト、RFP要件化までの検討段階からご相談いただけます。製品選定前に「何を受入条件にすべきか」を整理したい場合も、お問い合わせフォームから現在の文書量、言語、利用部署をお知らせください。

参考情報

※本稿は2026年9月2日時点の公開情報に基づく一般的な技術・運用上の解説であり、法的助言ではありません。法令適用、労務判断、国外移転、契約条件は、実際のデータフローに基づきDPOおよび現地専門家へ確認してください。