会社の​RAGは、​何から​作るか

「RAGを作ってほしい」の中身は、人によって違います

「社内の資料をRAG化してほしい」「うちもRAGを作りたい」。AI推進の現場で、この種の依頼を聞く機会が増えています。ところが、同じ言葉でも頼む人が思い描いているものは、かなり違います。

• 社内規程やマニュアルに、チャットで質問して答えを得たい
• 過去の提案書や議事録を、AIに探させたい
• ベクトルDBを使った検索基盤を、システムとして作ってほしい

最初の2つは「困りごと」で、最後の1つは「作り方」です。作り方の名前が先に出ているので、何のために、どの資料を、誰に使わせるのかが決まらないまま、構築の話が進んでしまうことがあります。

この記事では、RAGとは何かを整理したうえで、会社でRAGを作るときの考え方の軸を示します。結論を先に書くと、**RAGは「ベクトルDBを作ること」ではなく、「正しい資料を、見てよい人に、根拠つきで渡す仕組みを運用すること」**です。

RAGとは何か：探して、根拠として渡してから、答えさせる

RAG（Retrieval-Augmented Generation：検索拡張生成）は、AIに答えさせる前に、関連する情報を知識の置き場所から検索して取り出し、それを根拠として質問に添える方法です。Anthropicは、RAGを「知識ベースから関連情報を取り出し、それをユーザーのプロンプトに加える方法」として説明しています。AWSの解説では、モデルが回答を生成する前に、学習データの外にある信頼できる知識ベースを参照するしくみとされ、出力に出典（引用や参照）を付けられる点も挙げられています。

大事なのは、答えの品質が「探す」段階に大きく左右されることです。探す段階で違う資料や古い資料を拾えば、AIがどれだけ賢くても、間違った根拠から答えを作ってしまいます。

よくある誤解を3つ

誤解1：RAG＝ベクトルDBを作ること。 ベクトル検索はRAGの「探す」を実現する代表的な手段のひとつですが、唯一の手段ではありません。Anthropicの解説でも、意味の近さで探す埋め込み（ベクトル）検索と、単語の一致で探すBM25のような方法が、組み合わせて語られています。さらに、後述するように、既存の保管場所をそのまま検索する形でも、RAGの考え方は成り立ちます。

誤解2：全部の文書を入れれば賢くなる。 取り出す対象が増えるほど、古い版・重複・矛盾した文書も候補に混ざります。「正しい資料を入れる」ことが先で、「たくさん入れる」ことではありません。MicrosoftのSharePoint向けの準備ガイドも、Copilotとエージェントは、資料が最新で適切に管理されているときにうまく機能すると説明しています。

誤解3：RAGにすれば、AIが間違えなくなる。 根拠を渡しても、取り出した箇所が適切でなければ、答えは外れます。Anthropicは、検索の失敗を減らす「Contextual Retrieval」という工夫を紹介し、上位20件の取り出しで失敗する割合が、組み合わせと再順位付けによって5.7%から1.9%（67%の減少）になったと報告しています。裏を返せば、工夫の前の段階では、取り出しの失敗はそれなりに起きるということです。

また、そもそも小さな知識ベースにはRAGが要らない場合もあります。同じAnthropicの解説は、知識ベースが約20万トークン（約500ページ分）より小さければ、全体をプロンプトに入れる方法でもよいと述べています。

作り方は大きく3つ：どこに資料を置き、どう探すか

会社でRAGを実現する方法は、資料の置き場所と探し方で、大きく3つに分けられます。ここでは、公式の案内で確認できた範囲で、各社の仕組みを例にして比べます。

各列の根拠を、確認できた範囲で補足します。

• A：コネクタ型。 ClaudeのMicrosoft 365コネクタは、利用者ごとの権限で動き、「Claudeを通じて、Microsoft 365で直接見られないものにはアクセスできない」と説明されています。SharePointの検索は組織全体が対象で、サイトを限定する検索は、現時点では非対応です。Google Driveのコネクタも「既存の権限を反映する」とされ、必要な依頼のときだけ取得する設計です。MicrosoftのCopilotは、Microsoft Graph経由で、利用者が少なくとも閲覧権限を持つデータだけを使うと説明されています。
• B：アップロード型。 Claudeのプロジェクトは、プロジェクトの知識が上限に近づくと自動でRAGモードに切り替わり、容量が最大10倍まで広がります（有料プランが対象）。ただし、いつRAGを使うかは選べず、内容の更新がどう反映されるかは、公式ヘルプに説明がありません。
• C：自前型。 AWSの解説は、資料とその埋め込み（検索用データ）の両方を更新し続ける必要があると述べています。Anthropicの報告のように、検索の工夫で失敗率を下げる余地は大きい一方で、その工夫を作って保つのは自社の仕事になります。

会社で作るときの考え方：5つの軸

作り方を選ぶ前に、会社として決めておくことがあります。どの方式を選んでも、次の5つが曖昧なままだと、答えの質は上がりません。

• 正本。 AIは、置かれた資料を区別して読んでくれるとは限りません。「どれが最新の正しい版か」は、人が決めて、置き場所で見分けられるようにします。
• 権限。 Microsoftは、Copilotが利用者が閲覧できるデータだけを使う以上、SharePointなどの権限設定を適切に保つことが重要だと説明しています。準備ガイドには、過剰共有（広い共有リンクなど）の洗い出し、非アクティブなサイトの整理、特定のサイトを検索から外す設定などが挙がっています。「AIが勝手に見せる」のではなく、「元々見えてしまう状態だった」ことが表に出る、という点に注意が必要です。
• 鮮度。 同じ準備ガイドに、非アクティブなサイトやオーナー不在のサイトを見つけて整理する仕組みが挙げられています。更新責任者がいない資料は、答えの根拠として危ない資料です。
• 出典。 出典が示されれば、利用者は元の文書を開いて確かめられます。AWSの解説も、RAGの利点として出典の提示を挙げています。Microsoftも、Copilotの応答には根拠として使った情報への引用が保存されると説明しています。
• 評価。 「よさそう」で運用を始めず、質問集で測ります。測り方は限定部分で具体的に示します。

GPTsやGemが終わると、ナレッジ共有はどう変わるか

これまで、社内ナレッジの共有といえば、ChatGPTの「GPTs」に資料（knowledge）を添付し、そのボットを配る形がよく使われました。本稿執筆時点（2026年10月）で、OpenAIはGPTsについて、新規作成の終了と、2026年12月11日のカスタムGPT停止を案内しています。GoogleのGemは、法人向けの終了が2027年3月1日より早くないとされています。詳しくは「チャットボットを配る時代から、手順を配る時代へ」にまとめました。

資料を添付したボットを配る形は、「ボットを配る」前提の上に成り立っていました。ボットを前提にしない共有では、資料そのものをボットの中に抱えさせる必要が薄れます。僕の見立てでは、変わるのは次のところです。

Skillは、手順・判断基準・出力の型を持つ「仕事のマニュアル」です（「毎回ゼロから説明していませんか」）。そして、Skillに加えて外部サービスへの接続を束ねたものが、プラグインです（「スキルとプラグインで、社内の作業手順を標準化する観点」）。この組み合わせで、RAGの3つの問い、つまり「どこを探すか」「誰に見せるか」「どう答えるか」を、一つの配布物にまとめられます。

僕自身、顧客向けに、SharePointを中心にしたCopilot Studio配置の設計をしたことがあります。そこで固めたのは、SharePointの一覧と文書庫を正本にするという考え方でした。チャットの画面は、その正本を読む窓口にすぎません。会話の履歴は、監査用のログに業務の記憶を預けず、利用者×案件ごとの独立した保管先に持つ設計にしました。この設計は検証計画の段階で、顧客環境での実装・公開までは行っていません。ただ、「正本を決め、窓口は後から付ける」という順番は、RAGの設計でもそのまま通用すると考えています。