RAG導入前のデータ・文書・権限設計｜社内AI検索の準備ガイド

RAGとは、Retrieval Augmented Generationの略で、AIが外部データや社内文書を検索し、その内容を参照しながら回答を生成する仕組みです。
AWSは、RAGを大規模言語モデルに社内文書などの外部データを加える手法として説明しています。
社内AI検索やFAQ回答では有効な入口ですが、RAGそのものが文書管理や権限管理を自動で解決するわけではありません。

文書を入れる前に業務を決める

最初に決めるべきなのは、どの文書を入れるかではありません。
どの業務で、誰が、どの判断をするために検索するのかを決めることです。
営業担当が提案前に過去資料を探すのか、カスタマーサポートが回答案を作るのか、情報システム部門が社内規程を案内するのかで、必要な文書と権限は変わります。

業務を決めないまま文書を広く取り込むと、検索対象は増えます。
しかし、回答の根拠、最新版、閲覧権限、更新責任が曖昧なままでは、便利なデモで止まりやすくなります。

RAGを技術部品だけで見ない

RAGには、文書取り込み、分割、埋め込み、検索、再ランキング、回答生成、引用表示などの部品があります。
OpenAIのRetrieval APIも、semantic searchによってキーワードが一致しなくても近い内容を探せると説明しています。
一方で、検索できた文書が本当に正しいか、ユーザーが見てよいか、業務判断に使えるかは別の問題です。

技術検証では、数十件のPDFで回答が返れば成功に見えます。
本番運用では、部門別のアクセス権限、古い文書の除外、回答根拠、ログの確認まで必要になります。
RAG導入は、検索技術と文書運用を同時に設計するプロジェクトです。

お問い合わせ

文書を入れる前の棚卸し

RAGの品質は、取り込む文書の量よりも、文書の状態に左右されます。
社内文書は、正式ルール、過去資料、個人メモ、提案書、FAQ、チャットの断片が混ざりやすい領域です。
そのため、最初に文書の正しさと扱いを分けます。

正の文書を決める

まず、AIに参照させる文書を3種類に分けます。
1つ目は正式文書です。
社内規程、業務マニュアル、契約テンプレート、商品仕様、承認済みFAQなどが該当します。
2つ目は参考文書です。
過去提案書、議事録、チャット、問い合わせ履歴など、業務の文脈は分かるが、そのまま正解にできない情報です。
3つ目は除外文書です。
古い価格表、失効した規程、個人メモ、重複ファイル、機密性が高すぎる資料が入ります。

この分類をしないと、AIは古い資料や例外対応を正式ルールのように扱う可能性があります。
RAGのPoCでは回答が自然に見えても、社内の誰が承認した文書なのかが追えなければ、本番業務では使いにくくなります。

更新責任と廃止ルールを持つ

文書棚卸しでは、ファイル名や保存場所だけでなく、更新責任者を決めます。
営業資料なら営業企画、規程なら管理部門、FAQならサポート責任者、仕様書ならプロダクト責任者というように、誰が内容を維持するのかを明確にします。

RAGは最新情報を自動で判断する仕組みではありません。
更新されない文書を検索対象に残すと、古い情報を根拠に回答します。
そのため、公開日、最終更新日、有効期限、廃止済みフラグ、問い合わせ先をメタデータとして持たせる方が、後から運用しやすくなります。

権限設計で止まるRAG

社内AI検索で最も危ないのは、検索できる文書と、ユーザーが見てよい文書がずれることです。
Amazon Bedrock Knowledge BasesのManaged Knowledge Baseは、SharePointやConfluenceなどのコネクタに加え、文書単位のACLによる権限フィルタリングに対応すると説明しています。
このような機能を使う場合でも、元になる社内の権限設計が曖昧なら、本番導入の承認は止まりやすくなります。

元データ側の権限を正にする

RAGの権限は、AI側だけで後付けしない方が安全です。
元の文書管理システム、ファイルサーバー、SaaS、データベース側で、誰が何を見てよいかを整理します。
そのうえで、検索インデックスやベクトルDB側にも同じ権限を反映します。

部門、役職、顧客、案件、雇用形態、プロジェクト参加状況によって、見られる文書は変わります。
たとえば、人事規程は全社員が見られても、評価履歴や候補者情報は限定されるべきです。
営業資料でも、全社共通のパンフレットと、特定顧客の値引き条件は同じ扱いにできません。

返答前の再確認を設計する

権限設計では、検索時だけでなく、回答生成の直前と回答表示時にも確認します。
検索結果の中に権限外の断片が混ざると、AIが回答文に要約してしまう可能性があります。
この場合、元文書を直接表示していなくても、情報漏えいに近い問題が起きます。

実務では、ユーザーID、所属、役職、案件参加、文書の機密区分を使って、検索対象と回答表示を制御します。
また、引用元を表示し、ユーザーが根拠文書へアクセスできない場合は回答しない、というルールも必要です。
便利さより先に、見せてはいけない情報を出さない設計を決めてください。

people-walking-through-data-center-corridor

AI時代のデータ基盤とは？BI・DWHからAIが使える基盤へ

生成AIやAIエージェントを業務で使うには、ツール選定より先に、自社のデータ、業務文書、会話、KPI定義、権限をAIが安全に参照できる状態へ整える必要があります。この記事では、従来のBI・DWH中心のデータ統合基盤と、AI時代に必要なデータ・ナレッジ基盤の違いを、経営者と実務担当者の双方が判断できる形で解説します。

検索品質を決めるデータ準備

RAGの回答品質は、モデルだけでなく検索品質で決まります。
検索品質は、文書の分割、メタデータ、同義語、文書構造、再ランキング、評価データで変わります。
ここを見ずにモデルを変えても、期待した改善にならないことがあります。

チャンク分割とメタデータを見る

文書を小さな単位に分けることをチャンク分割と呼びます。
分割が粗すぎると、不要な文脈まで検索されます。
細かすぎると、回答に必要な前後関係が欠けます。
契約書、FAQ、議事録、仕様書、社内規程では、適した分割単位が異なります。

加えて、文書にはメタデータを付けます。
部署、文書種別、対象業務、顧客名、公開日、更新日、機密区分、言語、有効期限などです。
この情報があると、検索結果を絞り込みやすくなり、回答の根拠も確認しやすくなります。

検索結果を調整する

RAGでは、近い文書を取るだけでは足りません。
OpenAIのRetrieval APIでは、検索結果の関連性が十分でない場合、ranking optionsやscore thresholdで取得結果を調整できると説明されています。
これは、社内文書検索でも重要な考え方です。

たとえば、営業担当が「契約更新時の値引き条件」を聞いたとき、一般的な価格表、過去の個別値引き、最新の承認ルールが同時に候補に出るかもしれません。
このとき、どの文書を優先し、どの文書は参考扱いにするかを決めておかないと、AIはもっともらしいが実務では使えない回答を出します。
検索品質は、社内の業務ルールとセットで調整する必要があります。

PoC前に作る評価データ

RAGのPoCは、回答が返るかを見る場ではありません。
本番で使える検索品質、引用、権限、拒否判断を確認する場です。
そのため、PoC前にテスト質問と正解文書を作ります。

想定質問と正解文書を用意する

評価データには、実際の利用者が聞く質問を入れます。
社内規程なら「副業申請は誰が承認するか」、営業資料なら「この業界向けの導入事例はどれか」、サポートなら「このエラーの一次対応は何か」といった質問です。
それぞれに対して、参照すべき文書、回答に含めるべき内容、引用してよい箇所を決めます。

同時に、回答してはいけない質問も作ります。
権限外の顧客情報、未公開の人事情報、期限切れの価格表を聞かれたときに、AIが回答を控えられるかを見るためです。
このテストを入れないと、PoCは都合のよい質問だけで成功してしまいます。

評価項目を4つに分ける

RAGの評価は、正答率だけでは足りません。
以下の4つを分けて確認すると、改善すべき箇所が見えやすくなります。

評価項目	確認する内容	主な改善対象
検索	必要な文書を取れているか	文書分割、メタデータ
根拠	引用元が正しいか	出典表示、最新版管理
権限	見てよい情報だけ使ったか	ACL、ユーザー属性
拒否	答えない判断ができたか	ガードレール、運用ルール

この表をPoC前に作ると、モデルを変えるべきなのか、文書を直すべきなのか、権限を直すべきなのかが分かれます。
失敗原因を1つにまとめないことが、本番化に向けた改善の第一歩です。

AI導入の進め方と失敗原因｜企業が先に決める実務設計ガイド2026

企業のAI導入は、ツールを入れる前に、対象業務、データ、権限、KPI、運用責任を決めなければ成果につながりません。本記事では、AI導入が失敗する原因を分解し、PoC前に企業が決めるべき進め方を実務視点で整理します。

本番運用へ進める手順

RAG導入は、文書棚卸しから本番運用までを段階で進めます。
最初から全社文書を対象にすると、権限、文書量、評価データが一気に複雑になります。
まずは業務と文書範囲を絞り、小さく本番化できる型を作る方が現実的です。

図では、業務選定から運用改善までを5ステップで示します。
大事なのは、文書の取り込みを最初の作業にしないことです。
業務、文書、権限、評価、運用を順番に決めると、RAGを社内検索で終わらせず、業務で使えるAI基盤へ近づけられます。

5ステップで準備する

進め方は、次の順番が基本です。
まず対象業務を選び、文書を棚卸しし、権限を確認し、評価データを作り、小さく本番運用へ進めます。

この順番を飛ばして文書取り込みから始めると、後から「誰に見せてよいか」「どれが最新版か」「回答が正しいか」に戻ることになります。
一方で、最初から完璧な全社ナレッジ基盤を作る必要もありません。
問い合わせ対応、営業資料検索、社内規程検索など、1つの業務で準備の型を作り、別業務へ展開する方が失敗範囲を抑えられます。

外部支援を使うべき場面

外部支援を使うべきなのは、RAG製品の導入作業が分からないときだけではありません。
文書管理、データ基盤、権限、業務フロー、評価データ、既存システム連携が社内で分断されている場合も、第三者が入る価値があります。

とくに、事業部門は検索したい文書を知っているが、権限設計は情報システム部門に依存し、文書の正は管理部門が持つ、という状況は珍しくありません。
この場合、RAG導入は技術論だけでは進みません。
業務責任者、文書責任者、情報システム部門、セキュリティ担当が同じ判断表を見られる状態を作ることが先です。

まとめ

RAG導入は、社内文書を検索しやすくする施策ではなく、業務で使う知識、文書、権限、評価、運用責任を整理する設計課題です。
失敗を避けるには、文書を取り込む前に、正の文書、参考文書、除外文書を分け、更新責任者と廃止ルールを決める必要があります。
成功条件は、必要な文書を検索できること、ユーザー権限を守れること、根拠と最新版を確認できること、答えてはいけない質問を拒否できることです。

一方で、これらを社内だけで進めると、文書整理は事業部門、権限は情シス、データ基盤は別チーム、AI開発は外部ベンダーに分かれやすくなります。
Phinx（フィンクス）は、課題整理からデータ基盤、RAG、AI-native開発、既存システム連携、導入後の運用定着までを一体で見られる体制を持っています。
RAGをデモで終わらせず、業務で使える社内AI検索へ落とし込める点がPhinxの強みです。

出典

AWS Prescriptive Guidance「Understanding Retrieval Augmented Generation」 https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html
Amazon Bedrock User Guide「Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases」 https://docs.aws.amazon.com/en_en/bedrock/latest/userguide/knowledge-base.html
OpenAI Developers「Retrieval」 https://developers.openai.com/api/docs/guides/retrieval
Microsoft「The AI adoption journey: Moving from AI pilots to transformation at scale with Microsoft Foundry」 https://adoption.microsoft.com/files/agents/MicrosoftFoundryAIAdoptionJourney.pdf