社内RAG構築の判断基準｜何を決め、自社開発か既存製品かをどう選ぶか

要約

社内RAG（社内の資料をもとにAIが答える仕組み）は、経営者が先に5つのことを決めます。対象の業務と資料、誤った答えの被害、データの閲覧権限、仕組みの担当者です。
自社で作るか既存の製品を使用するかは、他社との差別化要因になる部分かどうかで判断します。
どの方法でも、AIの回答を確認する人を決め、1つの業務で検証してから展開します。

社内の規程やマニュアルをAIに読ませ、社員の質問に答えさせる仕組みをお考えでしょうか。社内RAGの調査を始めても、何から決めればよいのか迷うものです。技術責任者のいない会社では、外注先の提案が妥当かを判断できる人もいません。私のもとにも、AIで実現できると説明を受けていたものの実現しなかった、という相談が寄せられます。

この記事では、社内の資料をもとにAIが答える仕組みの導入で、経営者が決めることをまとめます。自社で作るか既存の製品を使うかの判断基準も示します。基準は、私が相談や開発の現場で使用してきたものです。RAGの技術と個人情報の規制は、判断に必要な範囲に限って説明します。

社内RAGとは何か

RAGとは、社内の資料などから質問に関連する情報を検索し、それをもとにAIに答えさせる手法です。正式には Retrieval-Augmented Generation といいます。検索した情報は、AIへの指示文（プロンプト）に付加して渡します。

通常のAIのチャットとの違いは、答えの根拠を自社の資料から取得する点です。ただし、AIが社内の資料をすべて記憶するわけではありません。質問のたびに関連する可能性のある部分を検索し、その部分をもとに答えます。

経営者にとって重要なのは、AIが関係のない資料を参照すると、答えも誤るという点です。これを防止する技術が「RAG」なのです。

社内RAGの導入は、なぜ失敗するのか

多くの場合、原因はAIの性能ではなく、最初の設計です。AIに任せる範囲が曖昧なまま導入すると、期待どおりの結果が得られません。必要なツールを把握しないまま仕組みを構築し、後から全体を連携できなくなったという相談も頻繁に受けます。必要なツールには、業務の流れを自動化する n8nや、意味の近い文章を探せるベクトルDBがあります。AIが誤った答えを出すという相談も、原因の多くは、最初の設計にあるのです。

n8nは、複数のサービスを連携して業務の流れを自動化するツールです。ベクトルDBは、意味の近い文章を検索できるデータベース（情報を整理して保存する仕組み）です。ベクトルDBは、文章の意味を数値の配列に変換して保存します。

よくある失敗の原因は、ひとまずすべて保存し、後からAIに尋ねようとする考え方です。以前にも、知人の起業家からこの種の相談を受けました。AIが収集した情報を蓄積しているものの、活用できないという内容です。原因は、構造化データと文章を区別せず、同じ場所に保存していたことでした。構造化データとは、金額や日付のように、項目ごとに表で整理できる情報です。

そこで私は、Supabase（データベースなどを提供するサービス）での保存の設計を見直しました。構造化データはテーブル（行と列からなる表）に、文章はベクトルDBに分けて保存します。さらに、目的に応じて検索方法を使い分ける手法を提案しました。経緯は実務ケース「構造化データとベクトルDBを区別せず、AIを活用できていなかった事例」にまとめています。

検索方法を使い分けるのは、社員の質問と資料の用語が一致するとは限らないからです。

検索方法	適した対象	弱点
キーワード検索（入力した語を含む文章を検索する）	型番、エラー番号、製品名など、語が決まっているもの	質問と資料で用語が異なると検出しにくい
ベクトル検索（意味の近い文章を検索する）	表現が異なっても内容が同じ文章	完全に一致する語を見落とすことがある
ハイブリッド検索（2つの検索を組み合わせる）	規程の文章と、番号や固有名詞が混在した資料	2つを組み合わせる分、構成要素が増える

どの検索方法を使用するかは、技術者に一任して問題ありません。経営者は、社員が尋ねるのは文章の内容か、番号や固有名詞かを技術者に伝えましょう。

導入の前に経営者が決めることは何か

決めることは次の5つです。いずれも技術の問題ではなく、経営の判断です。

決めること	具体的な内容	決めない場合に生じること
対象の業務	どの業務の、どの質問に答えさせるか	業務の流れが変わらないまま二度手間が増え、定着しない
登録する資料	どの資料を登録し、どれを登録しないか。どれが最新の版か	古い情報をもとに、誤った答えが出る
誤った答えの被害	誤った答えが拡散したら何が生じるか。誰が確認するか	誤りに気づかず社内で共有し、顧客に伝えてしまう
データの閲覧権限	誰がどの資料を閲覧できるか	閲覧権限のない資料の内容が回答に表示される
仕組みの担当者	仕組みを説明できる人は誰か。その人が不在のとき誰が修正するか	担当者の退職で、誰も運用できなくなる

3つ目以降は後の章で扱います。ここでは、対象の業務と登録する資料を説明します。

対象の業務を1つに絞る

社内RAGを導入する前に、現在の業務の流れを整理しましょう。業務を見直さずにAIだけを追加した例では、二度手間が増えて定着しませんでした。効果が出た例では、いずれも業務の流れの整理が先行していました。実務ケース「AI導入が「目的化」して失敗した例、成功した例」でも説明しています。

「AIなら何でもできる」と、全業務のAI化を目指して失敗する例も見受けられます。まず1つの業務に絞って検証しましょう。

あわせて、実施しないことも先に決めます。私は1,000万円級の開発で、要件定義書（作るものの内容を定めた文書）とは別の一覧を作りました。「やらないことリスト」です。この一覧に発注側と開発側が先に合意したことで、途中の要望で開発の範囲が拡大するのを防止できました。社内RAGでも、答えさせない質問と登録しない資料を洗い出しておきましょう。

登録する資料を選定する

資料は、多いほどよいというわけではありません。大量のデータからAIが正しい情報を特定するのは難しく、誤った回答が出力されやすくなります。誤りに気づかないまま社内や顧客に伝わると、重大なトラブルになります。

社内の資料は、1か所に集約されているとは限りません。どこにある資料を登録するのか、どれが最新の版なのかを、担当者を決めて確認しましょう。

古い情報には注意が必要です。私が税理士や行政書士の事務所のAI導入を支援する際にも、AIが古い法律をもとに誤った情報を出すことがあります。

自社で作るか既存の製品を使うか、どう判断するか

判断の軸は、その仕組みが他社との差別化につながるかどうかです。費用と時間をかける価値があるかを、この軸で判断しましょう。経理や勤怠管理のように自社の強みと関係のない業務なら、私は迷わずSaaSを使用します。SaaSとは、インターネット経由で使用するソフトウェアのサービスです。

一方、私はアフィリエイトの仲介事業で、課金と配信のシステムを自社で開発しました。広告主とサイト運営者を仲介する事業で、そのシステムが顧客に提供するサービスの中核だったからです。

主な選択肢は、次のとおりです。ChatGPT（文章で対話するAIのサービス）を提供する OpenAI の製品も含めました。料金は2026年11月1日時点のものです。

選択肢	機能	確認事項
Microsoft 365 Copilot（Microsoft の業務ソフトのAI）	利用者が閲覧権限を持つ社内データだけを表示する	対象は、条件を満たす Business プランの既存の利用者。追加料金は年払いで1人あたり月 $21.00。2026年7月1日〜12月31日の割引なら、初年度は1人あたり月 $18.00。月払いは1人あたり月 $25.20
Gemini Notebook（Google のAIのサービス）	読み込ませた資料をもとに答える	資料1件の上限は50万語。パソコンからアップロードするファイルは200MBまで
OpenAI の file search	アップロードしたファイルを、意味とキーワードで検索する。Word、PowerPoint、PDF（配布用の文書の形式）などに対応する	API（システム同士を連携する接続仕様）を使用する開発が必要。保存は1GBあたり1日 $0.10（1GBまで無料）。検索の呼び出しは1,000回あたり $2.50
自社で作る（PostgreSQL など）	データベース製品の PostgreSQL に、公開されている拡張機能 pgvector を追加すると、ベクトル検索ができる。キーワード検索とも組み合わせられる	開発費と保守費が継続して発生する。仕組みを説明できる人が必要

製品を選定するときも、自社で作るときも、別のサービスへ移行するときの費用を確認しておきましょう。以前、日本で動画配信の仕組みを作った際、私は費用の安さだけでデータベースを選んでしまいました。別のサービスへ移ろうとしたときに、大規模な作り直しが必要になったのです。以来、私は別の業者へ移行するときの費用を、見積もりの時点で試算しています。

自社で作ってよいのはどのような場合か

判断の基準は次の2点です。故障したときの被害の大きさと、仕組みを説明できる人の有無です。被害が軽く、説明できる人がいるなら、自社で進めてかまいません。

社内で説明できる人が1人しかいない状態は危険です。その人が退職して誰も運用できなくなった例を、私は複数見てきました。

技術の選定でも、運用できる人材がいるかが重要です。アフィリエイトの仲介事業を日本で始めたとき、私は流行の独自技術を避け、実績の豊富な技術を選定しました。運用できる人材を採用しやすく、資料も豊富だからです。その結果、担当者が入れ替わってもシステムは止まりませんでした。流行よりも、誰が運用できるかで選定しましょう。

コスト・リスク・時間で比較する

技術に詳しくない経営者には、私はコスト、リスク、時間の3つの観点で説明します。社内RAGなら、次のようになります。

既存の製品: 開発費は抑えられますが、利用者数や使用量に応じた料金が毎月発生します。時間はかからず、すぐに検証できます。リスクは、製品で対応できる範囲に業務を合わせることと、別の製品へ移行するときの費用です。
自社で作る: 開発費に加えて、保守費が継続して発生します。設計から始めるので時間もかかります。リスクは、説明できる人が不在になると誰も修正できないことです。その代わり、画面や答えの形式を自社の業務に合わせられます。

個人情報とデータの閲覧権限はどう決めるか

個人データを登録するなら、提供元がそのデータを機械学習に使用しないことを先に確認します。機械学習とは、データからAIに学習させることです。データの閲覧権限は、元の資料のアクセス権限（閲覧できる人の設定）に合わせます。

個人情報保護委員会は、生成AI（文章や画像を生成するAI）を使用する事業者に注意を喚起しています。本人の同意なく個人データを入力し、提供元がAIの回答を生成する以外の目的で取り扱うと、法律違反の可能性があるという内容です。

主な提供元の説明は、次のとおりです。

OpenAI: 標準の設定では、顧客のデータを学習に使用しません。対象は ChatGPT Business、ChatGPT Enterprise、API Platform などです。
Microsoft 365 Copilot: 指示文やAIの回答は、AIの学習に使用されません。社内のデータも同様です。
Google Workspace の Gemini: Google の業務向けサービスのAIです。入力内容を人が確認することはなく、生成AIの学習にも使用されません。

これらは提供元の説明です。自社が契約するプランが対象に含まれているかを、契約の前に確認しましょう。

データの閲覧権限は、自社で作るときほど注意が必要です。自社で作る場合は、データごとの閲覧権限も用意しなければなりません。異動や退職のときに、誰が権限を変更し、いつ反映されるかも決めておきましょう。

社内規程も必要です。私は次のようなトラブルを見てきました。AIのチャットに機密情報を入力する例、スタッフがデータベースを破損させる例、情報が持ち出される例です。総務省の令和7年版情報通信白書では、生成AIの活用方針を定めた日本企業は2024年度調査で49.7%でした。2023年度調査の42.7%より増加していますが、中小企業では「方針を明確に定めていない」という回答が約半数です。社内RAGの導入は、規程を見直す機会にもなります。社内規程の内容は、記事「生成AIの社内ルールの作り方｜何を決め、誰が確認し、誰が責任を持つか」で説明しています。

AIの回答を誰がどのように確認するか

AIは誤った答えを出力することがあります。これを前提にして、元の資料と照合する人を決めます。

RAGでも誤りが解消しない理由の1つは、資料の分割方法にあります。RAGでは、大規模な文書をチャンク（文書の断片）に分割して照合します。しかし、分けると前後のつながりが失われるのです。Anthropic社は、チャンクに前後の説明を補って測定しました。その結果、検索で上位20個に必要なチャンクが入らない失敗が49%減りました。さらに検索結果を並べ替える処理を追加すると、この失敗は67%減りました。ただし、失敗は大きく減りますが、なくなるわけではないのです。

確認方法は、次のとおりです。

答えに元の資料が表示される製品を選ぶ。OpenAI の file search では、参照した資料を示す注釈が付く
数値と固有名詞は、必ず元の資料と照合する
文章の内容は、根拠を一次情報（元の資料や公式の発表）までさかのぼって確認する
法律や税務に関わる答えは、最後に専門家が確認する
本番で使用する前に、本番に近いデータで検証する

最後の項目が重要なのは、動作することと正しいことは別だからです。私自身、AI導入の初期に、AIが出力した数値が実際の取引データと合わず、顧客への報告に影響が出たことがあります。データの出典を明確にし、複数の情報源と照合して解決しました。日ごろの確認方法は「AIの回答を、そのまま信じないために実践していること」にまとめています。古い法律をもとに答えた例は実務ケースで紹介しています。

外注するときは何を確認するか

外注先の提案は、見積もりの内容と進め方で判断します。CTO（技術の最高責任者）がいない会社では、外注先の説明をそのまま受け入れがちです。あとになって、高すぎる保守費や、修正も乗り換えも難しいシステムに気づくのです。

見積もりでは、設計から保守までの工数（必要な作業量）の割合を確認しましょう。極端に安い見積もりには、必要な作業が入っていないことが多くあります。高すぎる見積もりには、いらない作業費用が追加されているかもしれません。保守費は、開発費の何%という数字ではなく、内容で判断しましょう。

また、週に一度、動作するものを見せてもらいましょう。私の経験で成功したのは、週1回の進捗共有と動作確認を徹底した案件です。失敗したのは、仕様書を渡して一任した案件でした。納品の間際になって、依頼と異なるものが届いたのです。

性能や障害対応の条件も、文書にしておきましょう。私は起業したばかりの頃の案件で、想定アクセス数や障害時の対応を曖昧にしたまま契約したことがあります。稼働後に、説明と異なるというトラブルになりました。以来、これらの条件は数値で文書化しています。

どの順番で進めるか

順番は、次のとおりです。

業務の流れを整理し、1つの業務を選定する
答えさせる質問、登録する資料、実施しないことを洗い出す
データの閲覧権限と、回答を確認する人を決める
既存の製品で検証し、社員の実際の質問に答えられるかを確認する
完璧を待たずに運用を開始し、利用状況の記録をもとに改善する
既存の製品では不十分で、他社との差別化に関わる場合に限り、自社で作る範囲を検討する

5番目は、私が開発で継続している方法です。私は完成度70%で運用を開始し、利用状況の記録をもとに改善を重ねています。

RAGの動作を確認したい方は、私が公開しているRAG検索デモをお試しください。

よくある質問

Q: すでに Microsoft 365 を使用しています。Copilot を選べばよいですか。

社内の規程やマニュアルを探すだけなら、自社で開発せず、Copilot を最初に検討しましょう。ただし、対象は条件を満たす Business プランの既存の利用者です。また、Copilot は利用者が閲覧権限を持つデータを表示します。閲覧権限が広すぎる資料がないか、先に点検しましょう。

Q: 自社で作るべきなのは、どのような場合ですか。

AIの答えが、顧客に提供するサービスの中心になる場合です。そのうえで、故障したときの被害と、説明できる人の有無を確認します。説明できる人がいないなら、プロトタイプまでにとどめましょう。

Q: 社内RAGの回答は、そのまま信じてよいですか。

そのまま信じてはいけません。RAGでも誤った回答は出力されます。数値と固有名詞は元の資料と照合し、法律や税務の答えは専門家が確認しましょう。

Q: 外注先に「RAGで作りましょう」と言われました。何を確認すればよいですか。

どの業務のどの質問に答える仕組みなのか、既存の製品ではなぜ不十分なのかを確認しましょう。見積もりでの設計から保守までの工数の割合と、公開後に誰が修正するのかも確認が必要です。

まとめ

社内RAGは、資料を保存してAIに尋ねるだけの仕組みではありません。AIに任せる範囲を先に決めます。
経営者が決めるのは、業務と資料、誤った答えの被害、データの閲覧権限と担当者です。
自社で作るか既存の製品を使用するかは、他社との差別化要因になる部分かどうかで判断します。
自社で作るなら、故障したときの被害と、説明できる人の有無を確認します。
個人データを登録するなら、機械学習に利用されないことを確認します。データの閲覧権限は元の資料の権限に合わせます。
AIの回答を確認する人を決め、1つの業務で検証してから展開します。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない会社の、技術の判断と開発体制づくりを支援しています。社内RAGの導入の是非、自社開発か既存製品か、外注先の提案が妥当かを、一緒に整理します。無料でご相談いただけます。まずはお気軽にお問い合わせください。

参考・出典

Microsoft Learn（Azure AI Search の RAG の概要）: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
Anthropic「Contextual Retrieval」: https://www.anthropic.com/news/contextual-retrieval
Supabase Docs（ハイブリッド検索）: https://supabase.com/docs/guides/ai/hybrid-search
pgvector（GitHub）: https://github.com/pgvector/pgvector
OpenAI Docs（file search）: https://developers.openai.com/api/docs/guides/tools-file-search
OpenAI Docs（料金）: https://developers.openai.com/api/docs/pricing
OpenAI「Enterprise privacy」: https://openai.com/enterprise-privacy/
Microsoft Learn（Microsoft 365 Copilot のデータとプライバシー）: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy
Microsoft（Microsoft 365 Copilot の料金）: https://www.microsoft.com/en-us/microsoft-365-copilot/pricing
Google Workspace（Gemini の FAQ）: https://knowledge.workspace.google.com/admin/gemini/gemini-for-google-workspace-faq
Google ヘルプ（Gemini Notebook の資料の上限）: https://support.google.com/notebooklm/answer/16269187?hl=en
Microsoft Learn（Azure AI Search の文書単位のアクセス制御）: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日）: https://www8.cao.go.jp/cstp/ai/ai_team/6kai/shiryouchuuikanki.pdf
総務省「令和7年版情報通信白書」: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html