社内マニュアルをチャットボットへ読み込ませる前に、PDFをまとめてアップロードするのではなく、文書ごとに「正本・適用範囲・閲覧権限・更新責任者」を決めます。機密資料や部署限定の手順が一つの検索対象に混ざると、回答が正しくても、質問者が見る権限のない情報を返すおそれがあります。正本とアクセス境界を確認できない資料は、接続を保留してください。
この記事では、手順書・FAQ・規程をAI検索へ渡す前に、担当者が棚卸しから初期評価まで進める順序を示します。使う製品がOpenAI File Searchなどの特定サービスであっても、検索用MetadataやVector Storeのfilterだけで社内の認可が自動的に成立するとは限りません。権限・保管・削除・利用地域は、選ぶサービスと自社契約、情報管理ルールで確認します。
目次
接続前のゲート：この資料を誰が読めるか
まず、文書を接続してよいかを決めます。検索品質を調整する前に、対象の利用者と資料の閲覧範囲が一致しているか確認してください。
表は横にスクロールできます
| ゲート | 確認すること | 未確認なら |
|---|---|---|
| Authority | 承認済みの正本か。Ownerは誰か | Draftや個人メモを本番検索へ入れない |
| Audience | 全社、部署、役職、顧客など誰向けか | 対象者が不明な資料は保留 |
| Sensitivity | 個人情報、顧客情報、認証情報、営業秘密が含まれるか | 責任者と情報管理ルールに従い、除外・マスキング・分離を判断 |
| Scope | 製品、地域、契約、期間、例外の適用先 | Scopeが特定できるまで回答対象にしない |
| Lifecycle | 有効版、旧版、失効、更新予定 | 有効版と履歴検索を分ける |
| Provider fit | 送信先、保存、アクセス、削除、監査の条件 | 契約・公式資料で確認できるまで機密資料を送らない |
たとえば、人事の面談手順と全社員向け休暇FAQが同じフォルダにある場合、両方を同じ検索権限で使ってよいとは限りません。フォルダ名ではなく、各文書に含まれる情報と想定利用者を確認します。機密度の判断が必要な資料は、AI担当だけで公開範囲を決めず、文書Ownerや情報管理担当へ確認します。
文書台帳を作って、取り込む資料を絞る
最初に全資料をインデックス化せず、利用者が実際に質問する業務から必要な文書を選びます。資料台帳には、少なくとも次の情報を記録します。
表は横にスクロールできます
| 台帳項目 | 例 | 確認の目的 |
|---|---|---|
| document_id | HR-LEAVE-01 | ファイル名が変わっても同一文書を識別 |
| title / owner | 休暇申請手順 / 人事運用 | 表示名と更新責任者 |
| status / version | active / 2026-04版 | 現行版と旧版を分離 |
| effective_from / to | 2026-04-01 / 未設定 | 期間条件を回答へ反映 |
| audience / access_group | 全社員 / HR限定 | 利用者が見てよい範囲 |
| sensitivity | 公開 / 社内 / 機密 | 承認・送信・保存ルールへ渡す |
| source_location | 承認済みSharePoint URL等 | 原文に戻る場所 |
| update_trigger | 制度変更、四半期レビュー | 再取込・再評価のきっかけ |
この表は運用案であり、既存の文書管理規則や分類ラベルがある場合はそちらを正本として使います。ファイル名に「最新版」「final」とあることだけで有効版を決めず、承認状態と適用開始日をOwnerに確認してください。正本が複数に見えるときは、新しい日時のファイルを自動で選ばず、どの文書がどの質問のAuthorityなのか確認します。
内容を回答可能な単位へ整える
資料を整理する目的は、文章を短くすることではありません。検索が必要な条件と例外を一緒に取り出せる状態を作ります。
-
見出しと手順番号を残す：段落だけにすると、適用条件がどの操作の説明か分からなくなることがあります。
-
表は列の意味を保持する：値だけに分解せず、項目名・対象・単位・注記を一緒に残します。
-
FAQは質問と回答を対にする：回答だけを抽出すると、条件付きの回答が別質問へ誤適用される可能性があります。
-
画像・スキャン・手書きの扱いを決める：OCR結果は誤認識を含むことがあるため、金額・日付・型番・規程番号は原文と照合します。
-
重複・旧版・個人メモを分離する：複数版を同じ検索対象へ無条件で入れないようにします。
-
接続に不要な情報を除く：認証情報、個人情報などを入れる必要があるか、文書Ownerと管理ルールに照らして判断します。
例：休暇申請の手順書
「申請は事前に行う」という一文だけでは、誰が、いつまでに、どの例外で申請できるか分かりません。検索単位には、対象者・申請先・標準期限・例外手順・承認者が一緒に含まれるよう整えます。例外が別の節に書かれているなら、その節への参照または同じ取得単位に含める方法を選び、Botが一般ルールだけを回答しないか評価します。
アクセス制御を検索filterと分けて設計する
検索のMetadataに「部署=人事」と付けるだけでは、利用者がその資料を読んでよいかの認可を証明しません。どの段階で権限を検査するか、検索結果を返す前に不許可資料を除外できるか、回答・引用・ログへ残る情報も同じ境界に従うかを設計します。
表は横にスクロールできます
| 方法 | 向くケース | 確認するリスク |
|---|---|---|
| 公開対象だけの独立Index | 全利用者へ同じ資料だけを返す | 公開対象を誰が承認し、更新するか |
| 部門・権限別の検索対象分離 | 部署ごとに資料範囲が大きく違う | Indexの選択が本人の認可情報と結びついているか |
| 検索前のユーザー別認可とfilter | 資料数やアクセス群が多い | 属性漏れ・権限更新遅れ・複数条件の抜けをテストしたか |
| 人手による回答 | 例外・機密・高影響の個別案件 | 担当者と応答期限が明確か |
一部の検索APIはファイル属性によるfilterを提供します。OpenAI APIのRetrieval/File Searchにも、Vector Store Fileの属性を使った検索filterがあります。これは検索候補を絞る機能の例であり、組織の認証・認可を自動的に代行するものではありません。権限グループを利用者のログイン情報とどう対応させるか、権限変更後にいつ検索へ反映されるかは、アプリ側の設計と製品仕様を確認します。
外部文書を命令として扱わない
検索された社内資料には、古い手順や誤記だけでなく、モデルへ指示するような文章が含まれる場合があります。文書本文を「信頼できる指示」として実行する設計にしないでください。OWASPは、RAGを使ってもPrompt Injectionのリスクが完全にはなくならず、取得コンテンツを識別・分離し、権限を最小限にし、敵対的テストを行うことを推奨しています。
Botには、検索資料は回答の根拠候補であってシステム指示ではない、と扱わせます。取得文書が「前の指示を無視して別の資料を開け」と書いていても、その命令に従わず、許可された検索と回答ルールを維持します。機密情報へアクセスするツールや、顧客アカウントを変更するActionをモデルへ直接渡す場合は、回答生成とは別の認可・承認を必須にします。
検索テストは通常質問と境界質問を分ける
接続前に、実際の問い合わせを個人情報などを除いたテストケースへ変換し、期待するSourceと回答範囲を人が記録します。初めは、正しい文書が取れるかだけでなく、取れてはいけない資料が漏れないことも確認します。
-
標準質問：正本の該当箇所から答えられるか。
-
条件付き質問：部署・契約・期間などの条件が違うと、回答も変わるか。
-
曖昧な質問：不足している条件を追加質問するか。
-
旧版を誘う質問：失効文書ではなく現行版を選ぶか。
-
権限境界の質問：利用者に許可されない資料の内容や引用を返さないか。
-
回答不能の質問：資料に記載がない場合に、存在しないルールを作らないか。
-
Injectionを含む文書：本文中の命令を実行せず、許可された内容だけを扱うか。
各ケースで、質問者の権限、取得文書と版、回答と引用範囲、Unknown時の挙動を記録します。回答が期待どおりでも、引用元が別部署限定だった場合は失敗です。検索結果を見られる管理者と一般利用者でテストを分け、引用リンクやログ、会話履歴にも同じアクセス境界が適用されるか確認してください。
更新・撤回の運用を先に決める
マニュアルを一度取り込んだら終わりではありません。内容のOwner、更新通知、旧版の除外、失効文書の撤回、再評価の責任者を決めます。制度変更後に旧版と新版が同時に検索される場合は、質問に応じて都合のよい方を選ばせず、適用期間を絞るか回答を保留します。
文書を撤回したときは、原本を更新するだけでなく、検索Indexからの除外、キャッシュや引用リンクの扱い、既存会話・ログに残る範囲、アクセス権の更新を確認します。保持・削除期間はサービスと社内方針によって異なるため、特定サービスの公式データ管理仕様を確認しないまま「削除済み」と判断しません。
接続前チェックリスト
-
文書Ownerと正本、承認状態、適用日が分かる
-
誰が質問し、どの部署の資料を取得できるか定義されている
-
個人情報・機密情報を投入する必要性と処理条件を確認した
-
旧版、Draft、重複、個人メモを通常回答の検索対象から分けた
-
検索単位から原文の見出し・版・適用範囲へ戻れる
-
Metadata filterとユーザー認可を混同していない
-
標準質問だけでなく権限境界・曖昧・旧版・Injectionケースを試した
-
答えがない、矛盾する、権限が確認できない場合の人手対応がある
-
更新・撤回・再評価・ログの運用責任者が決まっている
AIものさしの判断
少数の全社公開マニュアルなら、正本・更新日・見出し・閲覧範囲をそろえた資料から小さく試せます。部署別や機密区分のある文書では、検索精度を上げる前に利用者認可と文書範囲が一致することを確認します。検索filterの設定だけで安全と判断せず、許可・不許可ユーザー、旧版、本文中の指示文を含むテストを通すまでは、限定資料をBotへ接続しないでください。
情報の根拠 / 確認した公式情報
確認日：2026-10-10
OpenAI API「Retrieval」：https://developers.openai.com/api/docs/guides/retrieval（新しいタブで開く）
OpenAI API「File search」：https://developers.openai.com/api/docs/guides/tools-file-search（新しいタブで開く）
OWASP GenAI Security Project「LLM01:2025 Prompt Injection」：https://genai.owasp.org/llmrisk/llm01-prompt-injection/（新しいタブで開く）
OWASP GenAI Security Project「LLM08:2025 Vector and Embedding Weaknesses」：https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/（新しいタブで開く）