RAG・社内文書検索AIをどう導入するか。データ棚卸し・権限設計・PoCまで進め方を整理する法人向けガイド【2026年版】

導入全体の手順（全体像）

RAG・社内文書検索AIの導入は、大きく6つの工程に分かれます。前の工程が終わっていないまま次に進むと、あとで手戻りが起きやすくなります。

下の表は、各工程で何をして、何が終われば次に進んでよいかをまとめたものです。自社の状況によって各工程の重さは変わりますが、順番を入れ替えないことが重要です。

対象文書の決め方

最初につまずきやすいのが、全社の文書を一度に対象にしようとすることです。部門をまたいだ文書は形式も更新頻度も持ち主もばらばらで、権限設計と評価の両方が一気に難しくなります。

始める範囲は、よく参照される文書が集まっていて、持ち主がはっきりしている単位に絞るのが現実的です。1つの部門のマニュアルや規程集、よくある質問集のように、範囲と正解を確認しやすい文書群から着手します。

範囲を絞る基準は、参照頻度が高いこと、重複や矛盾するバージョンが少ないこと、持ち主に確認が取れることの3つです。この3つが揃わない文書群は、後回しにしたほうが評価がぶれません。

• 参照頻度が高い（問い合わせが多い、よく検索されている）
• 持ち主（更新・正誤の確認先）がはっきりしている
• 重複・矛盾するバージョンが少ない
• 評価用の質問セットを作れるだけの文書量がある

導入前のデータ棚卸し

対象文書を決めたら、次に何がどこにあるかを一覧にします。この作業を省くと、PoCの途中で想定外の文書形式や、更新が止まった古い文書が紛れ込み、評価がやり直しになります。

特に古い文書の扱いは判断が割れやすい項目です。廃止済みの規程がそのまま検索対象に残ると、AIが古いルールを新しいルールのように回答してしまう事故につながります。

権限設計

社内文書検索AIで最も注意すべき事故は、精度の低さではなく、本来見えてはいけない人に答えが見えてしまうことです。元のファイルサーバーやSharePointでは部門外の人が開けなかった文書でも、検索の仕組みが元の権限を引き継いでいなければ、全社員の質問への回答の一部として出てしまう可能性があります。

これを防ぐ設計を権限設計と呼びます。文書を検索用に取り込む際に、誰がその文書を見てよいかという情報（アクセス権限）を、元のシステムと同じ状態で保つ仕組みがあるかどうかを確認します。

確認の仕方は、実際にテストすることです。閲覧権限を絞ったテスト用アカウントを用意し、その人が本来見られない文書の内容を質問として聞いてみます。AIが答えない、または文書の存在を示さないことを確認してから、本番稼働に進めます。

• 取り込み時にアクセス権限の情報も一緒に引き継げるか
• 権限のないアカウントでの質問テストを本番稼働前に実施したか
• 部門異動・退職時に権限がどのタイミングで反映されるか
• 権限テストは初回だけでなく、文書追加のたびに繰り返すか

現状値と成功指標

導入前に自社の現状を数字で押さえておかないと、導入後に「良くなったかどうか」を判断できません。まず、今どれだけ困っているかを測ります。

目安になるのは、資料を探すのにかかっている時間のアンケート、情報システム部門やヘルプデスクへの「あの資料どこですか」という問い合わせ件数、同じ質問が繰り返される頻度です。これらは自社の実データなので、他社の公表数値より判断材料として確実です。

次に、導入後に何をもって成功とするかを事前に決めます。回答できた割合、実際に正しく答えられた割合、誤った内容を作ってしまう割合を分けて測るのが実務的です。最後のものはハルシネーションと呼ばれ、文書に基づかない、もっともらしいが誤った回答をAIが作ってしまう現象を指します。

• 資料探しにかかっている時間（利用者アンケート）
• ヘルプデスク・情シスへの資料探しに関する問い合わせ件数
• 同じ質問が繰り返される頻度
• 導入後に測る指標: 回答できた割合、正答率、無回答率、ハルシネーション発生率

PoC・無料トライアルの進め方

PoC（概念実証。小規模に試して実用に耐えるか確かめる工程）は、ベンダーが用意したデモ文書ではなく、自社の実文書と、実際に社員が聞きたい質問で行います。デモ環境はきれいに整った条件で作られているため、自社の雑然とした文書では結果が変わることがあります。

実際の質問は、前の工程で確認したヘルプデスクへの問い合わせ内容や、社内チャットでよく聞かれる質問から集めます。想像で質問を作ると、実運用で聞かれる質問とずれてしまいます。

集めた質問をもとに、正解と根拠文書をセットにした評価用の質問セットを作ります。件数の目安は、対象にする文書の種類や部門の数、質問のパターンをひととおり網羅できるかどうかで決めます。各回答を正解・部分正解・誤り・無回答の4段階で判定すると、複数サービスの比較がしやすくなります。

判定は実際にその文書を使う現場の担当者に依頼します。導入担当者だけで判定すると、専門知識がないと分からない誤りを見逃すことがあります。

• 評価用の質問セットは実際の問い合わせから作る（想像で作らない）
• 回答は正解・部分正解・誤り・無回答の4段階で判定する
• 出典（根拠にした文書）が正しく示されているか確認する
• 対象外の質問に「分からない」と答えられるか確認する
• 判定は現場の担当者に依頼する

情報システム・法務の確認事項

技術選定と並行して、情報システム部門・法務部門に確認すべき事項があります。まず、データの保存先とリージョン（データセンターの所在地域）です。海外リージョンにデータが保存される場合、自社の情報管理方針に合うかを確認します。

次に、入力した文書や質問が、サービス提供者側のAIモデルの学習に使われるかどうかです。学習利用の可否と、オプトアウト（学習に使わないよう設定できるか）の方法を、契約前に確認します。

ログの扱いも重要です。誰がいつ何を検索し、AIが何を答えたかというログがどこまで保存され、誰が閲覧できるか、保存期間はどれくらいかを確認します。監査で必要になった場合にログを取り出せるかも合わせて見ておきます。

セキュリティ体制を確認する手がかりとして、ISMS（ISO/IEC 27001。組織が情報セキュリティを計画的に管理・運用できているかを認証する制度です）や、SOC 2（セキュリティ・可用性・処理の完全性・機密保持・プライバシーの観点で、公認会計士〈CPA〉が検証して発行する報告書。米国公認会計士協会AICPAの枠組みです）の取得状況をベンダーに尋ねる方法があります。ISMSの認証制度とSOC 2の定義は、2026年8月時点で公式サイトの説明を確認しています。

ただし、これらの認証・報告書がないことが即座に導入不可を意味するわけではありません。これは出典で確認した内容ではなく実務上の考え方ですが、認証・報告書の対象範囲（どの製品・どの拠点・どの期間が対象か）まで確認しておくと安心です。

• データの保存先・リージョン
• 入力データの学習利用可否とオプトアウトの方法
• ログの保存範囲・保存期間・閲覧権限
• 監査時にログを取り出せるか
• ISMS（ISO/IEC 27001）の認証取得の有無と認証範囲
• SOC 2 報告書の有無と対象範囲・対象期間（Type 1は一時点、Type 2は一定期間の評価）
• 個人情報・機密情報を含む文書を対象にする場合の法務確認

運用担当と継続作業

導入して終わりではなく、運用が始まってからの作業が発生し続けます。文書は日々更新されるため、誰がいつ更新分をAIに反映させるかを決めておく必要があります。

もう一つ重要なのが、AIが答えられなかった質問・間違えた質問の拾い上げです。ログから無回答や低評価の質問を定期的に確認し、不足している文書を追加する、あるいは人が正しい回答を用意する運用に回します。

運用担当は、情報システム部門だけで抱えないほうが続きやすくなります。文書の内容が正しいかどうかを判断できるのは各部門の担当者なので、情シスと現場の文書オーナーが役割を分けて見る体制が現実的です。

• 文書更新をAIに反映させる頻度と担当者
• 無回答・低評価の質問をログから拾い上げる仕組み
• 拾い上げた質問への対応（文書追加・回答の用意）を誰が行うか
• 情報システム部門と各部門の文書オーナーの役割分担
• ログレビューの頻度（例: 月次）

稟議に必要な費用・効果の書き方

稟議を通すには、費用と効果を同じ土俵で並べる必要があります。効果側の数字は、この記事の「現状値と成功指標」で測った自社の実データを使います。他社の事例やベンダーの謳い文句をそのまま効果として書くと、実態とずれて後で説明に詰まります。

費用側は、ライセンス料だけでなく、初期設定・データ棚卸し・権限設計・運用担当の工数まで含めて見積もります。料金体系の考え方は、費用相場を扱う別記事で整理しているので、そちらを参照してください。本記事では具体的な料金には触れません。

一度に全社展開の予算を求めるのではなく、PoCの予算と本番展開の予算を分けて申請する方法もあります。PoCの結果を自社の実データとして示せれば、本番展開の稟議は通しやすくなります。

• 効果は自社で測った現状値（問い合わせ件数・所要時間）を使う
• 費用はライセンス料に加え、棚卸し・権限設計・運用工数を含める
• PoC予算と本番展開予算を分けて申請する方法もある
• リスク低減効果（権限設計による情報漏えい防止）も効果として書ける

失敗しやすいパターン

ここまでの手順を踏まずに進めると起きやすい失敗を、実際につまずきやすい順に整理しました。

• 全社の文書を一度に投入する（範囲が広すぎて評価も権限設計も破綻する）
• 権限設計を後回しにする（本来見えてはいけない文書の内容が回答に出る事故につながる）
• 評価基準を決めずにPoCを始める（「なんとなく良さそう」という主観で契約してしまう）
• 文書の持ち主（オーナー）が不在のまま進める（更新が止まり、内容が陳腐化する）
• 無料トライアルの短期間・少量データだけで全社展開を判断する（本番規模ではデータ量も文書の種類も増え、結果が変わることがある）
• AIの回答を人が確認しないまま社内に公開する運用にする（誤った回答がそのまま広まる）

本記事の方針

本記事はfree-ai-tools.jp（合同会社IGS運営・i-gs.co.jp）の法人向けAIツール比較メディアが独自に作成しています。RAG・社内文書検索AIの導入手順・チェック項目は一般的な導入プロセスとして整理したものであり、特定サービスの機能や優劣を評価するものではありません。

料金の具体的な金額は本記事では扱っていません。費用の考え方は、費用相場を整理した別記事（RAG・社内文書検索AIの費用相場ガイド）をご確認ください。

ISMS・SOC 2に関する記述は、2026年8月時点でISMS-AC公式サイトおよびAICPA公式サイトで確認した内容に基づきます。認証の取得状況は変更される可能性があるため、契約前に各ベンダーの最新情報を確認してください。

RAGという仕組みの定義は、2020年に発表された原典の論文に基づいています。