ChatGPTに聞いても、結局うちの就業規則や過去案件の話は分からないんですよね
これは、社内ナレッジAIの導入を検討していた中堅BtoB企業の情報システム担当者から出た、現場コメントです。同社では、営業、総務、人事、CSがそれぞれ共有フォルダや社内ポータルを検索し、見つからなければ詳しい人にSlackで聞き直す運用が続いていました。汎用AIはメール文案や要約には使えても、社内独自の規程、提案書、FAQ、過去の議事録まではそのまま答えられません。結果として、現場には「AIに聞く」「資料を探す」「人に確認する」という二度手間が残っていました。
そこで同社は、対象を人事・総務問い合わせに絞り、社内文書を整理したうえで、RAGを使った社内ナレッジAIを試験運用しました。導入前後3か月、社内問い合わせ120件を対象に比較したところ、一次回答に必要な平均確認時間は約40％削減されました。ただし、この数値は同社の運用条件に基づくものであり、すべての企業で同じ結果が出るわけではありません。
この記事では、社内データ活用を進めたい情シス・DX推進・データ基盤担当者に向けて、RAG、ナレッジ基盤、ベクター検索、ドキュメント整備、アクセス権限、メタデータ、PII保護、精度評価をどう設計するかを整理します。目指すのは、社員が企業内検索AIに質問し、根拠文書を確認しながら業務判断の入口に立てる状態です。ただし、RAGは万能ではありません。古い文書、権限設計の不備、評価不足があれば、誤回答や情報漏えいのリスクは残ります。自社のナレッジ基盤をどう整えるべきか、現場の運用に重ねながら読み進めてください。
なぜ汎用AIだけでは社内業務に答えられないのか
生成AIの導入が進むと、多くの企業で最初に見えてくるのは「便利だが、業務の核心には届かない」という課題です。
メール文面の作成、議事録の要約、アイデア出し、一般的な調査には、ChatGPTのような汎用AIが役立ちます。一方で、次のような質問になると、回答の正確性を担保しにくくなります。
- 当社の出張旅費規程では、前泊はどの条件で認められるのか
- A社向けの過去提案では、どの課題を重視していたのか
- この製品の社内FAQでは、障害時の一次対応をどう定義しているのか
- 2024年度の営業会議で決まった価格改定方針は何だったのか
これらの答えは、インターネット上の一般情報ではなく、社内規程、過去議事録、提案資料、FAQ、マニュアル、社内チャットのやり取りなどに含まれています。つまり、AIの文章生成能力以前に、AIが参照できる社内ナレッジが整っていないことが問題になります。
この状態では、社員はまず社内ポータルや共有フォルダを検索します。見つからなければ、詳しい人にSlackやTeamsで質問します。質問を受けた人は、過去資料や自分の記憶をたどって回答します。さらに、回答を受け取った社員は、それが最新版なのか、正式なルールなのか、例外対応なのかを確認しなければなりません。
結果として、生成AIを導入しても「結局、人に聞いた方が早い」という感覚が残ります。社内ナレッジAIを実現するには、AIツールを入れるだけでは不十分です。社内データを業務で参照できる形に整え、検索・権限・更新・評価まで含めたナレッジ基盤として設計する必要があります。
RAGとは何か
RAGとは、Retrieval-Augmented Generationの略で、日本語では「検索拡張生成」と呼ばれます。AIが回答を生成する前に、関連する外部情報を検索し、その内容を文脈として使って回答する仕組みです。OWASPのLLMアプリケーション向け資料でも、RAGは外部知識源と大規模言語モデルを組み合わせ、回答の文脈適合性を高める技術として説明されています。
RAGを社内ナレッジAIに使う場合、基本的な流れは次のようになります。
- 社員が自然文で質問する
- 質問内容に関連する社内文書を検索する
- 検索された文書の該当箇所をAIに渡す
- AIが文書内容をもとに回答を生成する
- 回答とあわせて、参照元の文書名や該当箇所を表示する
重要なのは、RAGは社内文書をAIに丸ごと暗記させる仕組みではないという点です。必要なときに関連文書を検索し、その内容を使って回答する仕組みです。そのため、社内規程やマニュアルが更新された場合も、モデル自体を再学習するのではなく、参照対象となるナレッジ基盤を更新する運用が基本になります。
企業内の情報は日々変わります。制度改定、組織変更、製品仕様の更新、価格表の変更、顧客対応方針の見直しが起きれば、文書も更新されます。RAGは、こうした変化のある社内情報を扱ううえで、比較的現実的なアプローチです。
ただし、RAGを使えば必ず正確になるわけではありません。検索対象の文書が古い、検索結果が不適切、回答ルールが曖昧、権限管理が弱いといった状態では、誤回答や情報漏えいのリスクが残ります。RAGの定義やLLMアプリケーションにおけるリスクの確認には、OWASPの「OWASP Top 10 for LLM Applications 2025」が参考になります。
RAGで実現できること・できないこと
RAGを導入すると、社内ナレッジAIや企業内検索AIとして、次のような活用がしやすくなります。
人事・総務領域では、社員が「育休申請はいつまでに必要ですか」と質問したときに、就業規則や人事FAQを参照して回答できます。営業領域では、「製造業向けの過去提案でよく出る課題は何ですか」と聞くと、過去提案書や商談メモから傾向を整理できます。CS領域では、「このエラーが出たときの一次対応を教えてください」と聞くと、製品FAQや障害対応マニュアルをもとに回答できます。
一方で、RAGには限界もあります。
- 参照する文書が間違っていれば、回答も間違う可能性があります。
- 古い規程、未承認のドラフト、重複したFAQ、担当者の個人的なメモが混在していれば、AIはそれらを正しく区別できないことがあります。
- 検索で適切な文書が見つからなければ、回答の質は上がりません。
- アクセス権限の設計が不十分だと、本来見てはいけない情報が回答に混ざるリスクがあります。
RAGの精度は、生成AIの文章力だけでなく、検索精度に大きく左右されます。ベクター検索を使えば意味の近い文書を探しやすくなりますが、それだけで業務上の正確性が保証されるわけではありません。
経営会議資料、人事評価情報、顧客別の契約条件、未公開の財務情報などは、誰でも参照できてよい情報ではありません。RAG導入は、単なるAI導入ではなく、社内ナレッジ運用の再設計です。技術だけでなく、文書管理、権限管理、運用ルール、精度評価をあわせて考える必要があります。
ナレッジ基盤設計の第一歩は対象業務を絞ること
社内データをAIに活用しようとすると、最初に「社内の全資料をAIに読み込ませたい」という話が出ることがあります。しかし、初期段階から全社の文書を対象にするのは慎重に考えるべきです。
社内文書は、形式、品質、更新頻度、機密度、利用者がばらばらです。範囲を広げすぎると、検索精度の検証、権限管理、文書更新、問い合わせ分析のすべてが難しくなります。
最初は、対象業務を絞ることが重要です。初期導入に向いているのは、次のような領域です。
- 人事・総務の社内問い合わせ対応
- 経費精算や出張規程に関するFAQ
- 製品マニュアルや障害対応手順の検索
- 営業提案書や導入事例の検索
- 社内研修コンテンツに関する質問対応
- 情シスのアカウント申請・ツール利用手順の案内
これらに共通するのは、質問のパターンがある程度繰り返されること、参照すべき文書が存在すること、回答に根拠が求められることです。
逆に、経営判断、法的判断、人事評価、顧客との個別交渉など、責任や文脈の重い領域は、最初の対象としては慎重に扱うべきです。AIに結論を出させるのではなく、判断材料を整理する用途にとどめる方が安全です。
ドキュメント整備がRAGの精度を左右する
RAGの成否は、AIモデルの性能だけでは決まりません。参照するドキュメントの品質が、回答の正確性に大きく影響します。
社内には、多くの場合、次のような文書が混在しています。
- 最新版と旧版が同じフォルダに残っている
- ファイル名だけでは内容や対象部署が分からない
- PDF化されていて本文検索しづらい
- 画像化された資料でテキスト抽出できない
- 同じ内容が複数のFAQに重複している
- 担当者しか意味が分からない略語が多い
- 正式文書と作業メモが区別されていない
この状態でRAGを導入すると、AIは自然な文章で回答できても、根拠として適切な文書を選べないことがあります。
そのため、RAGの前段階として、ドキュメント整備が必要です。まず、対象業務に関する文書を棚卸しします。どの文書が正式版なのか、どれが過去版なのか、どの部署が管理しているのかを確認します。
次に、文書の粒度を整えます。1つのPDFに複数の制度や手順が詰め込まれている場合、AIが該当箇所を探しにくくなります。章立て、見出し、FAQ形式、表形式などを整えることで、検索しやすくなります。
さらに、文書ごとにメタデータを付与します。メタデータとは、文書そのものに付ける補足情報です。部署、文書種別、作成日、更新日、版数、公開範囲、機密区分、対象業務などが該当します。
メタデータが整っていると、「最新の人事規程だけを参照する」「営業部向けの提案資料だけを検索する」「管理者権限のある人だけが見られる文書を除外する」といった制御がしやすくなります。
ベクター検索とキーワード検索をどう使い分けるか
RAGの文脈では、ベクター検索という言葉がよく出てきます。
ベクター検索とは、文章を数値のベクトルに変換し、意味が近い文章同士を探す検索方法です。従来のキーワード検索が「同じ単語が含まれているか」を重視するのに対し、ベクター検索は「意味が近いか」を重視します。
たとえば、社員が「出張の前泊はできますか」と質問したとします。社内規程には「宿泊を伴う移動」「前日移動」「業務上必要な場合」と書かれているかもしれません。キーワードが完全に一致しなくても、ベクター検索であれば意味の近い文書を探しやすくなります。
ただし、ベクター検索だけに頼るのは危険です。
業務文書では、品番、制度名、文書番号、部署名、顧客名、契約条項など、正確な文字列一致が重要なケースもあります。こうした情報は、キーワード検索の方が適している場合があります。
そのため、実務ではベクター検索とキーワード検索を組み合わせる設計が有効です。自然文の質問に対して意味の近い文書を探しつつ、文書番号や規程名などの明確な条件ではキーワード検索を使う。さらに、検索結果をメタデータで絞り込む。こうした複数の検索方法を組み合わせることで、企業内検索AIとしての実用性が高まります。
| 検索方法 | 向いている用途 | 注意点 |
|---|---|---|
| ベクター検索 | 自然文の質問から、意味の近い文書を探す用途。表現が完全一致しない場合にも関連文書を見つけやすい。 | 制度名、文書番号、品番などの厳密な一致が必要な検索では、単独利用に注意が必要。 |
| キーワード検索 | 規程名、文書番号、顧客名、契約条項など、文字列の一致が重要な用途。 | 言い換えや表記ゆれが多い質問では、該当文書を見落とす可能性がある。 |
| メタデータ絞り込み | 部署、公開範囲、更新日、文書種別などで検索対象を制御する用途。 | メタデータが不十分だと、検索対象の制御が難しくなる。 |
アクセス権限は後回しにしない
社内ナレッジAIを設計するうえで、アクセス権限は初期段階から検討すべき重要項目です。
RAGでは、AIが社内文書を参照して回答します。もし検索対象に本来見てはいけない文書が含まれていれば、AIの回答を通じて情報が漏れる可能性があります。OWASP Top 10 for LLM Applications 2025でも、RAGやファインチューニングはLLM出力を関連性の高いものにする一方で、プロンプトインジェクションなどの脆弱性を完全に解消するものではないと説明されています。
特に注意が必要なのは、次のような情報です。
- 経営会議の議事録
- 人事評価や異動に関する資料
- 顧客別の契約条件
- 未公開の価格表
- NDA対象の提案資料
- 個人情報を含む問い合わせ履歴
- 未公開財務情報
- M&Aや新規事業に関する検討資料
RAGのアクセス権限設計では、「AIが何を知っているか」ではなく、「質問者が何を見てよいか」を基準にする必要があります。
同じ質問をしても、営業部の社員、人事部の社員、経営層、外部パートナーでは、参照できる文書を変えるべきです。AIの回答も、その権限範囲内で生成される必要があります。
この設計を後回しにすると、対象文書を広げるたびに情報漏えいリスクが高まります。初期段階から、部署単位、プロジェクト単位、役職単位、文書種別単位でのアクセス制御を検討しておくことが重要です。LLMアプリケーションにおけるプロンプトインジェクションやRAG運用上のリスク確認には、OWASPの「OWASP Top 10 for LLM Applications 2025」が参考になります。
PII保護と機密情報の扱い
社内データ活用では、PII保護も欠かせません。PIIとは、個人を識別できる情報のことです。氏名、住所、メールアドレス、電話番号、社員番号、顧客担当者名などが該当します。
生成AIサービスに個人情報を入力する際は、個人情報保護法上の取扱いや本人同意、利用目的、第三者提供の該当性などを確認する必要があります。個人情報保護委員会も、生成AIサービスの利用に関する注意喚起を公表しています。
RAGのナレッジ基盤に個人情報を含む文書を登録する場合、次のような対策が必要です。
- AIに参照させる必要がある情報かを判断する
- 個人名がなくても業務回答が可能であれば、登録前にマスキングする
- 人事情報や顧客情報は、全社員が検索できる状態にしない
- 回答時には「担当者A」「営業責任者」「申請者本人」のように一般化する
- チャットログや検索ログの保存期間、閲覧権限、監査方法を決める
社員が質問文に個人情報や機密情報を入力する可能性もあります。社内ナレッジAIは便利ですが、便利さだけを優先すると情報管理のリスクが高まります。RAGの設計では、使いやすさと安全性を同時に満たす必要があります。生成AIサービスに個人情報を入力する際の注意点については、個人情報保護委員会の「生成AIサービスの利用に関する注意喚起等について」が参考になります。
回答ルールをプロンプトで明確にする
RAGでは、検索された文書をAIに渡すだけでは不十分です。AIがどのように回答すべきかを、プロンプトで明確にする必要があります。
社内規程を参照するAIであれば、次のようなルールが必要です。
- 参照文書に書かれている内容だけをもとに回答する
- 根拠となる文書名と該当箇所を示す
- 文書に明記されていない場合は、推測で答えない
- 古い文書と新しい文書が矛盾する場合は、更新日を示して両方を提示する
- 判断が必要な場合は、担当部署への確認を促す
- 個人情報や機密情報を不要に出力しない
特に重要なのは、「分からない」と言える設計です。
AIにとって危険なのは、根拠がないのに自然な文章で答えてしまうことです。社内業務では、もっともらしい誤回答が大きな問題になります。経費精算、契約確認、顧客対応、人事制度などでは、誤った回答が社員や顧客の行動に影響する可能性があります。
そのため、RAGの回答ルールでは、「該当する文書が見つからない場合は回答できないと明示する」「一般論で補完しない」「担当部署への確認を案内する」といった制約を入れることが大切です。
精度評価は導入後に必ず行う
RAGは、構築して終わりではありません。導入後の精度評価と改善が、実運用では重要になります。
社内ナレッジAIの精度評価では、単に「回答が自然か」だけを見るべきではありません。少なくとも、次の観点を分けて評価する必要があります。
検索精度質問に対して、適切な文書が検索されているかを確認します。回答が間違っている場合、AIの文章生成ではなく、検索結果に問題がある可能性があります。
回答精度検索された文書の内容を正しく要約し、業務上誤解のない形で回答できているかを確認します。
根拠の妥当性回答と出典が対応しているかを確認します。出典として表示された文書に、実際には回答の根拠が書かれていない場合、ユーザーは誤って信頼してしまいます。
回答拒否の適切性についても検証が必要です。分からない質問に対して、無理に答えず、確認先を案内できているかを評価します。
業務利用後のフィードバック現場が回答を使った結果、追加確認が必要だったのか、自己解決できたのか、誤解が生じたのかを確認します。
評価用の質問セットを用意し、月次で確認するだけでも、RAGの品質は改善しやすくなります。たとえば、人事FAQであれば、よくある質問30件を用意し、期待回答、参照すべき文書、NG回答例をまとめておくと評価しやすくなります。
Kanataを活用する場合の運用イメージ
RAGや社内ナレッジAIを実装する方法は複数あります。自社開発、クラウド型の検索サービス、既存グループウェアとの連携、AI活用プラットフォームの利用など、選択肢は企業の体制やセキュリティ要件によって変わります。
その中で、KanataのようなBtoB向けAI活用プラットフォームを使う場合は、単独の検索システムとしてではなく、日常業務の中で使うAIアプリとして設計することが重要です。
たとえば、部門ごとにプロジェクトを分けます。人事・総務プロジェクト、営業支援プロジェクト、CSナレッジプロジェクト、情シスヘルプデスクプロジェクトのように、扱うデータと利用者が近い単位で分けると、権限管理と運用がしやすくなります。
次に、各プロジェクトの学習データライブラリに、規程、FAQ、マニュアル、提案資料、議事録、研修資料などを登録します。このとき、文書の更新日、対象部署、公開範囲、版数を整理しておくと、後の運用が安定します。
さらに、プロンプトライブラリに回答ルールを登録します。たとえば、「社内規程にないことは推測で答えない」「出典を必ず示す」「古い文書と新しい文書があれば新しい文書を優先する」といったルールです。これにより、担当者ごとにAIへの指示がばらつくことを防げます。
社員は、AIチャットアプリを通じて「この場合、どの規程を見ればよいですか」「過去の類似提案はありますか」と自然文で質問できます。AI要約やeラーニングと組み合わせれば、会議録を要約してナレッジ化する、研修動画の内容に質問できるようにする、過去の資料をもとに新人教育コンテンツを作るといった運用も考えられます。
Kanataを使う利点は、AIチャット、要約、学習データ、プロンプト、研修コンテンツを業務単位で扱いやすい点にあります。ただし、導入すれば自動的にナレッジ基盤が整うわけではありません。文書整備、権限設計、評価運用は、どのツールを使う場合でも必要です。
小さく始めて、評価しながら広げる
社内ナレッジAIを成功させるには、小さく始めることが大切です。
最初から全社データを対象にするのではなく、問い合わせが多く、文書が比較的整っており、効果を測りやすい業務から始めます。たとえば、人事FAQ、情シスの利用手順、営業提案資料の検索、製品マニュアルのQ&Aなどです。
初期導入では、次のような流れが現実的です。
- 対象業務を1つ選ぶ
- よくある質問を20〜50件ほど集める
- 質問に答えるために必要な文書を棚卸しし、最新版だけを整理する
- 文書にメタデータを付け、アクセス権限を確認する
- RAGを使ったAIチャットを作成する
- 社員に試してもらい、回答の正確性、根拠の分かりやすさ、検索漏れ、回答できないケースを記録する
- 1〜2か月運用したうえで、問い合わせ対応時間、自己解決率、エスカレーション件数、回答の修正件数などを確認する
数値だけでなく、現場のコメントも重要です。「探す場所が分かるようになった」「新人でも一次確認できるようになった」「古い資料が見つかって混乱した」といった声が、次の改善につながります。
このサイクルを回しながら、対象業務を少しずつ広げていくのが安全です。
まとめ
RAGは、社内データをAIに活用するための有効な仕組みです。汎用AIだけでは答えられない社内独自の規程、FAQ、マニュアル、提案資料、議事録などを参照し、根拠付きで回答する社内ナレッジAIを実現しやすくなります。
しかし、RAGは魔法の検索エンジンではありません。ナレッジ基盤が整っていなければ、AIは古い文書や不適切な文書をもとに回答してしまいます。アクセス権限が曖昧であれば、情報漏えいのリスクが高まります。精度評価をしなければ、現場で本当に使える状態にはなりません。
だからこそ、RAG導入では、技術選定より先に次の問いを整理する必要があります。
- どの業務から始めるのか
- どの社内文書を正式なナレッジとして扱うのか
- 誰がその文書を管理するのか
- 誰がどの情報を見てよいのか
- AIの回答をどの基準で評価するのか
- 古くなった情報をどう更新するのか
企業内検索AIの目的は、社員の判断をAIに丸投げすることではありません。探す時間を減らし、根拠にたどり着きやすくし、確認の質を上げることです。その結果として、現場の二度手間が減り、詳しい人への問い合わせが整理され、組織の知識が再利用されやすくなります。
RAGを導入するということは、社内の知識を「個人の記憶」から「組織で使える基盤」へ移すことです。まずは小さな業務から、文書整備、権限設計、精度評価をセットで始めることが現実的です。
Q&A
RAGと通常のChatGPT利用は何が違いますか？
通常のChatGPT利用では、モデルが持つ一般知識やユーザーが入力した情報をもとに回答します。RAGでは、回答前に社内文書やFAQなどを検索し、その内容を文脈としてAIに渡します。そのため、社内規程や過去資料など、企業固有の情報を根拠にした回答を作りやすくなります。
社内文書をすべて登録すれば、社内ナレッジAIはすぐ使えますか？
すぐに高精度で使えるとは限りません。最新版と旧版の混在、重複文書、曖昧なファイル名、権限設定の不足があると、誤回答や情報漏えいのリスクがあります。まずは対象業務を絞り、正式文書を整理し、メタデータとアクセス権限を整えることが重要です。
ベクター検索だけで十分ですか？
十分とは限りません。ベクター検索は意味の近い文書を探すのに向いていますが、品番、契約条項、制度名、文書番号など、正確な文字列一致が必要な場面ではキーワード検索も重要です。実務では、ベクター検索、キーワード検索、メタデータによる絞り込みを組み合わせる設計が有効です。
RAG導入で最初に取り組みやすい業務は何ですか？
人事・総務FAQ、情シスの利用手順、経費精算や出張規程、製品マニュアル、営業提案資料の検索などが候補になります。質問が繰り返され、参照すべき文書が存在し、回答に根拠が求められる業務から始めると、効果と課題を検証しやすくなります。
RAG導入時に最も注意すべきリスクは何ですか？
主なリスクは、誤回答、古い情報の参照、アクセス権限の不備、個人情報や機密情報の漏えいです。対策として、文書整備、権限設計、PII保護、回答ルール、出典表示、精度評価をセットで設計する必要があります。RAGは判断を代替するものではなく、根拠にたどり着くための支援として位置づけることが大切です。
