RAG開発・構築ガイド｜社内チャットボットの作り方・費用・外注先

社内の規程やマニュアルに答える「社内チャットボット」は、多くの場合RAG（検索拡張生成）で作ります。用意の仕方は、既製サービスで始める、クラウドのRAG基盤で自社開発する、開発会社に頼む、の3つです。どれを選ぶかは、文書がどこに置かれているか、閲覧権限を回答に引き継ぐ必要があるか、社内に作り込みと運用を担える開発者がいるかで決まります。費用は、RAG構築の目安を公表している開発会社の例で、PoC（小さく試して効果を確かめる検証）が50万〜200万円、部門向けの本番が200万〜800万円、全社展開が800万〜3,000万円です（ripla）。別の会社はもっと高い目安を出しており、差の理由は後半の費用の節で説明します。

この記事は、社内向けのRAGを用意したい情報システム部門・DX推進の担当者と、実際に手を動かすエンジニアの両方に向けて、「どの方法で作るか」「作る前に何を決めるか」「どう作り、どう精度を測るか」「いくらかかり、誰に頼むか」を1本で判断できるように整理したものです。

本記事の情報について: 製品の仕様・料金と各社の費用の目安は、2026年10月1日時点で各公式ページと公表資料を確認した内容です。プレビュー（試験提供）の機能はその旨を書いています。料金や機能は改定が多いため、契約前に必ず各公式ページで最新の情報を確認してください。費用の目安は各社が自社サイトで公表している値を並べたもので、特定の案件の見積もりではありません。

RAG開発とは何を作ることか（社内チャットボットとの関係）

RAG開発とは、生成AIが答える前に社内文書を検索させ、見つかった文書を根拠に回答させる仕組みを作ることです。社内チャットボットや「社内ChatGPT」は、この仕組みに質問画面を付けたものだと考えると整理しやすくなります。

RAG（Retrieval-Augmented Generation）は、2020年の論文（Lewis et al., 2020）で提案された考え方です。論文は、学習済みの生成モデルに、Wikipediaから作った検索用の索引を組み合わせました。この組み合わせは3つのオープンドメイン質問応答タスクで当時の最高水準を出し、生成モデル単体より具体的で事実に即した文章を生成したと報告しています。ただしこれは当時のモデルとデータでの結果で、「RAGにすれば誤回答が何割減る」という一般的な数字ではありません。

社内向けにRAGが選ばれる理由は3つあります。1つ目は、文書を差し替えるだけで回答の中身を更新でき、モデルを学習し直す必要がないこと。2つ目は、どの文書を根拠にしたかを回答に添えられ、利用者が原文で確かめられること。3つ目は、文書ごとに見せる相手を絞れば、閲覧権限に沿った回答にできることです。反対に、検索で必要な文書を取り逃すと、どれほど優秀な生成AIでも正しく答えられません。RAG開発の作業の中心は、生成AIの選定よりも「何を、誰に、どの鮮度で検索させるか」の設計にあります。

関連文書をすべて生成AIに読ませる方法と比べると、RAGは必要な箇所だけを渡すため、毎回の入力量（＝利用料）を抑えやすく、文書が増えても破綻しにくい傾向があります。反対に、扱う文書が数本から数十本で、使う人も限られるなら、開発は要りません。GoogleのGemini Notebook（NotebookLM）のように、PDFやGoogle ドキュメントを読み込ませると、その資料だけを根拠に出典付きで答えるサービスで足ります。チャットボット全般の種類やツールの違いから知りたい場合は、AIチャットボット完全ガイドを先に読むと全体像がつかめます。

社内RAGを用意する3つの方法と選び方

社内RAGは「既製サービスで始める」「クラウドのRAG基盤で自社開発する」「開発会社に頼む」の3つから選べます。最初の分かれ目は、使っているサービスのAIや既製のRAGサービスで、閲覧権限どおりに答えられれば足りるかどうかです。

上の図のとおり、判断は2つの問いで進みます。どの方法を選んでも、対象文書と答えさせたい質問の決定、閲覧権限の整理、本番に進むかの判断は自社に残ります。

既製サービスで始める

既製サービスは、文書の置き場所とサービスが合えば最も早く始められます。選び方の目安は、文書がどこに集まっているかです。

• Microsoft 365が中心: Microsoftの公式説明では、Microsoft 365 Copilotは、利用者が少なくとも閲覧権限を持つ組織のデータだけを回答に使います（Microsoft 365 Copilot のプライバシー）。Microsoft 365の外にある文書も、100を超える既製のCopilot コネクタで取り込めます。その中にはネットワーク上のファイル共有も含まれ、同期型のコネクタで取り込んだ文書は、元のシステムの権限に沿って表示が絞られます（Copilot コネクタの概要）。
• Google Workspaceが中心: Googleの管理者向けヘルプによれば、Gemini（Google Workspace）は、利用者が閲覧権限を持つWorkspaceの内容だけにアクセスして回答し、権限のない内容にはアクセスしません（Gemini in Workspace のプライバシー）。
• ChatGPTを全社で使っている: ChatGPTは、Google DriveやSlackなどのサービスとつないで、その情報を会話で使えます。個別のサインインが要るサービスでは、すでにその情報を閲覧できるアカウントでサインインし、使えるデータはアプリの仕様、接続時に与えた権限、管理者の設定で決まります。Business・Enterprise・Eduの各プランでは、つないだサービスの情報が既定でモデルの学習に使われません（ChatGPT のアプリ連携）。

RAG専用のサービスもあります。シナモンAIのSuper RAGは、社内情報をアップロードするだけで自社専用のRAGを使え、手書きやセル結合を含む表など、読み取りが難しい文書の解析を特長に挙げています。料金を公開しており、後半の費用の節で紹介します。Helpfeelは、社内のドキュメントをアップロードするとAIが回答を作る仕組みを、社内ヘルプデスクの用途でも提供しています（Helpfeel）。

既製サービスの限界は、回答画面や回答の形式、独自の業務システムとの連携を自由に変えにくいことです。まず既製サービスで「どの質問に答えられれば業務が楽になるか」を確かめ、足りない部分だけを開発に回す進め方も取れます。

クラウドのRAG基盤で自社開発する

主要なクラウドには、RAGの部品をまとめて提供する基盤があります。Amazon Bedrock Knowledge Basesには、AWSが取り込みから検索までを管理するマネージド型と、保存先などを自分で選んで組む顧客管理型があります（Amazon Bedrock Knowledge Bases の概要）。マネージド型は、取り込み、ベクトルの保存、検索の最適化を自動で扱い、Amazon S3、SharePoint、Confluence、Google Drive、OneDrive、Webクローラーにつなげられます（Amazon Bedrock Knowledge Bases）。Azure AI Searchは、キーワード検索とベクトル検索を組み合わせる検索や、文書単位のアクセス制御を備えた検索基盤です（Azure AI Search の RAG 解説）。Google CloudのVertex AI RAG Engineは、Cloud Storage、Google Drive、Slack、Jira、SharePointからの取り込みに対応しています（Vertex AI RAG Engine の取り込み）。

画面をノーコードで組みたい場合は、Difyのような開発基盤も候補です。Dify Cloudの料金は、年払いの場合でProfessionalが1ワークスペースあたり年590ドル（文書500件・5GBまで）、Teamが年1,590ドル（文書1,000件・20GBまで）で、税は別です。自社のサーバーで動かすCommunity版もあります。Community版はDify独自のオープンソースライセンスに従い、料金ページでは個人開発者や非商用のプロジェクト向けと案内されているため、業務で使う場合はライセンス条件を確認してください（Dify Pricing）。詳しい使い方はDify業務活用ガイドで解説しています。

基盤を使うと検索の仕組みを一から作らずに済みますが、閲覧権限の反映、評価、運用は自社の責任のままです。社内データを外部のAPIに出したくない場合は、ローカルLLMの業務活用ガイドの構成も検討できます。

開発会社に頼む

開発会社に頼むのが向くのは、社内に開発者がいない、複数の業務システムと連携する、部署ごとに見せる文書が細かく違う、期限が厳しい、といった場合です。注意したいのは、開発会社に頼んでも、対象文書の範囲、権限の整理、合格ラインの合意は自社でしか決められないことです。外注先の型と比較、初回に聞く質問は後半の「外注先の選び方と主な依頼先」で扱います。

作る前に決めるデータ・権限・更新の条件

社内RAGの成否は、作り始める前に決める5つの条件でほぼ決まります。想定質問（答えられれば成功とする質問）と対象文書、文書の取り込み口、閲覧権限の引き継ぎ方、更新と削除の反映頻度、見つからないときの返し方です。

図の上段は、左側が文書を取り込む準備、右側が質問を受けて閲覧権限で絞り込む流れです。下段は回答のときで、見つかったとき（左）と見つからないとき（右）の返し方です。文書置き場からの取り込み、閲覧権限での絞り込み、更新と削除の反映、見つからないときの返し方を、下の小見出しで順に説明します。どれも後から変えると作り直しが大きい項目です。

想定質問と対象文書

最初に決めるのは「どの質問に答えられれば成功か」です。問い合わせ窓口のメールやチャットの記録から、実際によく来る質問を集め、その回答に必要な文書だけを対象にします。全社の共有フォルダを丸ごと入れると、古い版や下書きが混ざり、回答の根拠が揺れます。

対象文書を決めるときは、規程やマニュアルの新旧版が混在していないか、スキャンしただけのPDFがどれくらいあるか、個人情報や機密が含まれていないかを確かめます。スキャンPDFは文字を読み取る処理（OCR）が必要で、表が多い文書は読み取りの品質が回答の品質を左右します。ここで集めた質問は、後で精度を測る評価用の質問にもなります。

ファイルサーバー（NAS）の文書をどう取り込むか

社内の文書の多くは、部署ごとのファイルサーバー（NAS）に置かれています。取り込み口は製品によって違い、NASに直接つなげるものと、いったんクラウドのストレージへ写す必要があるものがあります。

Microsoft 365 Copilotのコネクタは、既製の接続先にネットワーク上のファイル共有を含み、社内に置いたデータは専用のエージェントを社内に置いて取り込めます（Copilot コネクタの概要）。一方、Amazon Bedrock Knowledge Basesの公式の接続先一覧は、S3やSharePointなどのクラウドのサービスで、2026年10月時点の一覧にNASはありません（Amazon Bedrock Knowledge Bases）。そのため、NASの文書はS3へ同期するか、独自のデータソース（Custom）として取り込む構成が考えられます。S3を使う場合、閲覧権限は設定ファイルで文書ごとに渡せます（Amazon Bedrock の閲覧権限への対応）。

NASからクラウドへ写す構成で見落とされやすいのが、ファイルだけを写すと、フォルダごとのアクセス権が写した先に付いてこないことです。「経理フォルダは経理部だけが開ける」といった区別が消え、全員が検索できる状態になりかねません。写すときに、どのグループが読めるかを文書ごとの情報（メタデータ）として一緒に持たせる設計が必要です。

閲覧権限を回答に引き継げるか

閲覧権限の引き継ぎとは、元の文書置き場で読めない人には、その文書を根拠にした回答も見せないことです。ここが抜けると、チャットボットが「読めないはずの文書の中身」を答えてしまいます。OWASPは生成AIの主なリスクの1つにこの問題を挙げ、アクセス制御が不十分だと個人情報や機密を取り出して開示しうると説明しています。対策には、権限を判別できるベクトルの保存先や、利用者の区分ごとの論理的な分離、検索操作の改ざんできない記録を挙げています（OWASP LLM08:2025）。

製品ごとの対応は、公式の説明で次のように分かれます。

出典: Microsoft 365 Copilot のプライバシー、Copilot コネクタの概要、Azure AI Search の文書単位のアクセス制御、Azure AI Search のセキュリティフィルター、Amazon Bedrock の閲覧権限への対応、Vertex AI RAG Engine の取り込み

権限を引き継げる製品でも、元の文書置き場の権限が広すぎれば、チャットボットはそのまま広く答えます。Microsoftも、SharePointなどの権限モデルを使って適切な人に適切な内容だけが届くようにすることが重要だと説明しています（Microsoft 365 Copilot のプライバシー）。チャットボットを公開する前に、対象フォルダの共有設定を棚卸ししておくのが安全です。社内での生成AIの使い方のルールづくりは生成AIの社内利用ガイドライン、外部から仕込まれた指示への対策はプロンプトインジェクション対策ガイドで扱っています。

更新・削除をどの頻度で反映するか

規程が改定されたのに古い条文で答える、削除したはずの文書が根拠に出てくる。社内RAGでよく起きるこの事故は、更新と削除の反映の設計で防ぎます。反映の頻度は、文書の改定の頻度と、古い回答が出たときの影響の大きさで決めます。

製品によって反映の仕組みは異なります。Copilot コネクタは定期的に変更を確かめ、新規・更新・削除を索引に反映し、同期の頻度は管理者が設定できます（Copilot コネクタの概要）。Azure AI Searchの自動取り込みは、最短5分から最長24時間の間隔で定期実行を設定できます。変更の検知は、Azure StorageとSharePointには組み込みで、他のデータベースなどでは自分で有効にする必要があります（Azure AI Search の取り込みスケジュール）。Amazon Bedrock Knowledge Basesでは、更新日時などのメタデータで最近更新された文書に絞る検索もできます（Amazon Bedrock の検索設定）。

運用で決めておきたいのは、改定から反映までに許せる時間、削除した文書が索引から消えたかの確認方法、反映が失敗したときに誰が気づくかの3つです。規程のように新旧の版が似ている文書は、「有効／廃止」の区分や改定日を文書の情報として持たせ、廃止版を検索の対象から外しておくと、古い条文が混ざる事故を構造的に防げます。

検索で見つからないときの返し方と確認

社内RAGが「見つからない」原因は、大きく3つです。該当する文書がそもそもない、文書はあるが質問した人に閲覧権限がない、文書の取り込み自体に失敗している。利用者からはどれも同じ「答えが出ない」に見えるため、返し方と確認の手順を分けて決めておきます。

返し方の原則は、見つからないときに推測で答えさせないことです。生成AIへの指示で「渡した文書に書かれていないことは答えず、見つからないと返す」と明示し、回答には必ず根拠の文書名を付けます。そのうえで、見つからないときは問い合わせ先の窓口を案内し、質問を記録に残します。記録した質問を週に一度見直せば、「文書がない」なら文書を追加し、「権限がない」なら案内文を見直す、と原因別に手を打てます。

取り込みや権限の照合の失敗は気づきにくいので要注意です。たとえばVertex AI RAG Engineの公式手順は、Google Driveから取り込む場合、サービスアカウントに正しい権限がないとファイルが1件も取り込まれず、エラーメッセージも表示されないと注意しています（Vertex AI RAG Engine の取り込み）。Amazon Bedrock Knowledge Basesのマネージド型は、権限の判定でエラーが起きると該当の文書を返さない（見せすぎない側に倒す）設計で、結果が0件や少なめになることがあります。この場合はエラー応答で権限判定の失敗だと区別できるので、アプリ側でその応答を記録して担当者に知らせる作りにしておきます。一方、渡したメールアドレスが接続先のサービスと一致しないと、その利用者にはそのサービスの文書が何も返らず、エラーにもなりません（Amazon Bedrock の閲覧権限への対応）。取り込んだ文書の件数を元のフォルダの件数と突き合わせる確認と、権限の異なる利用者で答えを確かめるテストを、運用の手順に入れておくと安心です。

作る前の条件を確認するチェックリストです。

• 想定質問を、実際の問い合わせから集めた
• 対象文書を決め、旧版・下書き・機密文書を除いた
• 文書の置き場所（NAS・SharePointなど）ごとに取り込み口を決めた
• 元の置き場所の閲覧権限を回答に引き継ぐ方法を決め、共有設定を棚卸しした
• 改定・削除を反映する頻度と、反映を確かめる方法を決めた
• 見つからないときの返し方、問い合わせ先、記録の見直し担当を決めた
• 取り込み件数を元の件数と突き合わせる確認を手順に入れた

社内の準備がどこまで整っているかを点数で確かめたい場合は、業務の可視化、データ環境、組織体制、AIリテラシー、予算の5つの観点・19項目で診断できるAI自動化 準備度チェックも使えます。

RAG構築の進め方（データ準備から評価まで）

RAGは、文書の前処理、分割、ベクトル化、保存、検索、生成、評価の順に作ります。最初は対象を絞った少量の文書で最後の評価まで一周し、評価の結果を見てから文書を増やすと、作り直しが少なくなります。

1. 文書の前処理: PDFやHTMLから本文を取り出し、ヘッダー・フッター・ページ番号などを除きます。更新日、所管部署、有効／廃止、閲覧できるグループを文書ごとの情報として付けておくと、後の絞り込みに使えます。表や段組みが崩れていないかは、代表的な文書を数件抜き出して目で確かめます。
2. 分割（チャンク分割）: 文書を検索の単位に分けます。LangChainの公式ドキュメントは、多くの用途で段落・文・単語の順に大きなまとまりを保とうとする分割器（RecursiveCharacterTextSplitter）から始めるよう勧めています（LangChain Text splitters）。見出しのある文書は見出しの単位で分けると、文脈が切れにくくなります。
3. ベクトル化（埋め込み）: 分けた文章を、意味の近さを測れる数値の列（ベクトル）に変えます。質問と文書は必ず同じモデルで変換します。途中でモデルを変えると全文書の変換をやり直すことになります。
4. 保存: ベクトルと文書の情報を、検索用の保存先（ベクトルデータベース）に入れます。次に述べる次元数の上限に注意します。
5. 検索: 質問をベクトルにして、意味の近い文章を上位から数件取り出します。部署や更新日、閲覧権限での絞り込みをここで必ず掛けます。
6. 生成: 取り出した文章と質問を生成AIに渡し、文章だけを根拠に答え、根拠の文書名を付け、見つからなければそう答えるよう指示します。
7. 評価: 集めておいた質問で、検索と回答の品質を数値で測ります。測り方は後の「評価とPoCの合格ライン」で説明します。

ベクトルデータベースと埋め込みモデルの選び方

保存先は、既存の資産と運用の体制で選びます。主な選択肢を、公式ドキュメントで確認できる特徴で比べます。

埋め込みモデルは、日本語での検索精度、入力できる長さ、次元数で選びます。OpenAIのtext-embedding-3-smallは既定で1,536次元、text-embedding-3-largeは3,072次元で、次元数を短くして使うこともできます（OpenAI Embeddings）。3,072次元のままpgvectorのvector型でHNSWを使うと上限を超えるため、次元を短くするか、halfvec型を使うかを先に決めます。なお、生成と埋め込みのモデルは同じ会社で揃える必要はありません。たとえばAnthropicは自社の埋め込みモデルを提供しておらず、埋め込みにはVoyage AIなどを案内しています（Anthropic Embeddings）。

日本語の文書では、モデルが一度に読める長さにも注意が要ります。NVIDIAの日本語の検証記事によれば、日本語で精度の高いオープンなモデルのmultilingual-E5-largeとRuri-largeは、読める長さが512トークンです。同じ記事は、日本語の検索データセット6つの平均（nDCG@10）で比べ、NVIDIAの埋め込みモデル（Llama-3.2-NV-EmbedQA-1B-v2）に、検索結果を並べ替える同社のモデル（リランカー）を組み合わせると、さらに3.7ポイント上がったと報告しています（NVIDIA 技術ブログ）。これは特定のモデルとデータでの結果なので、自社の質問で比べて決めてください。保存先の詳しい比較はベクトルデータベース比較にまとめています。

精度が出ないときの切り分け

精度が出ないときは、原因が「必要な文書を取り逃している」「関係の薄い文書が上位に混ざっている」「文書は正しいのに生成が根拠を使えていない」「古い版が混ざっている」のどれかを先に見分けます。原因によって打ち手がまったく違うためです。

よくある誤解は、リランカーを入れれば取り逃しも直るというものです。リランカーは、最初の検索で取り出した候補の中で並び順を変えるだけなので、候補に入っていない文書は上位にできません。取り逃しには、検索の方式や分割の見直しで対応します。

もう1つ、表の最後の行のように、検索でも生成でもなく文書の側に原因がある場合は、どの指標を見ても正常に見えます。回答に付いた根拠の文書名と改定日を確かめる習慣が、いちばん早い発見方法です。検索の組み合わせや並べ替えなど精度を上げる技法をさらに詳しく知りたい方は、RAG高度化実践ガイドで、Agentic RAGやGraphRAGまで含めて解説しています。

評価とPoCの合格ライン

RAGの評価は、検索の品質と回答の品質を分けて測るのが基本です。評価のためのオープンソースのフレームワークRagasは、RAG向けの指標としてContext Precision、Context Recall、Response Relevancy、Faithfulnessなどを用意しています（Ragas の指標一覧）。

前の2つは検索の品質、後の2つは回答の品質を見る指標です。Context Precisionは取り出した文章のうち関係のあるものが上位にあるか、Context Recallは関係する文書や情報をどれだけ取り出せたか（Ragas Context Recall）、Response Relevancyは回答が質問に沿っているかを測ります。Faithfulnessは、回答に含まれる主張のうち、取り出した文章で裏付けられるものの割合で、0〜1の値になります（Ragas Faithfulness）。Faithfulnessは評価用の生成AIに主張を抜き出させて計算するため、評価に使うモデルや指示で値が動きます。絶対値よりも、同じ質問で改善の前後を比べる使い方が向いています。

評価用の質問は、作る前の条件で集めた実際の問い合わせから作ります。1つの文書で答えられる質問、複数の文書をまたぐ質問、対象文書に答えがない質問を混ぜ、正解の回答と根拠の文書の箇所を記録しておきます。答えがない質問に「見つかりません」と返せるかは、社内での信頼に直結するため、必ず入れてください。この質問の一式は、文書やモデルを更新したときに品質が落ちていないかを確かめる回帰テストにも使えます。

合格ラインは、PoCを始める前に業務の責任者と合意しておきます。公式に決まった一律の値はないので、たとえば「よく来る質問で、業務上正しい回答の割合が一次対応の担当者と同程度」「規程の解釈や金額に関わる質問で、根拠と食い違う回答がゼロ」「答えがない質問には必ず見つからないと返す」のように、業務の言葉で決めます。誤回答の影響が大きい用途ほど基準を厳しくし、人が最終確認する運用を前提にします。

本番に進むかを決める会議で使えるチェックリストです。

• 事前に合意した合格ラインを、評価用の質問で満たしている（分野別にも確認した）
• 閲覧権限のない文書を根拠にした回答が出ないことを、権限の異なる利用者で確かめた
• 改定・削除の反映の頻度と確認方法、担当が決まっている
• 見つからないときの返し方と問い合わせ先、記録の見直し担当が決まっている
• 本番の利用量でのAPI利用料・基盤の費用・運用の人の費用を月額で見積もった
• 精度が落ちたときの気づき方と、誰が何を直すかが決まっている

一部の分野だけ合格ラインに届かない場合は、合格した分野だけで始め、残りは文書を整えてから広げる進め方も取れます。改善を続ける期限と回数をあらかじめ決めておかないと、PoCが終わらなくなる点にも注意してください。PoCから本番への移り方はPoCから本番運用への進め方、本番後の監視と改善の仕組みはLLMOps実践ガイドで詳しく解説しています。

RAG開発の費用相場

RAG開発の費用は、公表している開発会社の目安で、PoCが50万〜200万円、部門向けの本番が200万〜800万円、全社展開が800万〜3,000万円です（ripla）。もっと高い目安を出す会社もあり、両者の差は、前提とする規模やデータ整備の範囲の違いから来ています。

TWOSTONE&Sonsは、データの整備が必要な場合に追加で200万〜1,000万円、セキュリティ・権限管理の設計に200万円からと、費用の内訳も示しています。TWOSTONE&Sonsの中規模の業務適用（1,500万〜4,000万円）は、数万件から数十万件の文書を扱う規模を想定しており、riplaの部門向け（200万〜800万円）とは数倍の開きがあります。なお、同じ記事の比較表には、小規模PoCを50万〜200万円、中規模の本番を300万〜1,000万円以上とする目安も載っており、扱う文書の量や前提で桁が変わることが分かります。ripla側も、部門向けの本番でSlack・Confluence・SharePointなどと連携する場合は、さらに50万〜200万円程度が必要としています。自社の案件がどちらに近いかは、対象文書の量と状態（スキャンや表の多さ）、連携するシステムの数、閲覧権限の細かさで見当をつけます。

既製サービスは、初期費用と月額の形で価格を公開している例があります。

開発費とは別に、毎月の費用もかかります。生成AIと埋め込みのAPI利用料、検索基盤の利用料、文書の追加や改定の反映、精度の見直しにかかる人の費用です。見積もりを取るときは、「月にどれくらいの質問を想定し、そのときの毎月の費用はいくらか」まで出してもらうと、稼働後に予算を超える事故を防げます。

極端に安い見積もりを受け取ったら、データの整備、閲覧権限の設計、評価用の質問づくり、稼働後の運用が範囲から外れていないかを確かめてください。TWOSTONE&Sonsが別に示しているデータ整備（追加200万〜1,000万円）や権限管理の設計（200万円〜）が抜けていると、本番の前に追加の費用が発生しがちです。

見積もりを依頼する前に揃えておくと、各社の提案を同じ条件で比べやすくなります。想定質問の例、対象文書の量と置き場所、閲覧権限の区分の数、連携するシステム、利用者数、合格ラインの考え方の6つです。

外注先の選び方と主な依頼先

外注先は、既製サービスの提供会社、クラウドに強い受託開発会社、生成AIの開発・活用を支援する会社に分かれます。どの型を選ぶかは、既製の範囲で足りるか、どのクラウドを使っているか、独自の要件がどれだけあるかで決まります。

表の会社や製品は、型ごとの代表例として公式ページで提供内容を確認できたものです。推薦の順位ではありません。顧客窓口向けの製品と社内向けの製品では得意分野が違うため、「社内の誰が、どの文書について質問するのか」を伝えて提案を受けてください。

初回の打ち合わせで聞く質問

外注先の実力は、具体的な設計の判断を語れるかで分かります。初回の打ち合わせで、次の10問を聞いてみてください。

1. 想定質問と対象文書を、最初に一緒に決めてもらえますか
2. NASやSharePointなど置き場所ごとに、どう取り込み、閲覧権限をどう回答に引き継ぎますか
3. 文書の改定や削除が回答に反映されるまでの時間と、反映を確かめる方法は何ですか
4. 答えが見つからないとき、何を返し、どこへ案内しますか
5. 精度を何の指標で測り、合格ラインをどう合意しますか（検索と回答を分けて）
6. 社内のデータを外部のAPIに送りますか。保存場所と、学習に使われるかどうかは
7. 既製サービスやクラウドの基盤で足りる部分を、どう判断しましたか
8. 運用（文書の追加、モデルの更新、障害対応）を誰がどの頻度で担い、費用はどうなりますか
9. 評価用の質問一式、評価結果、設計書、ソースコードは納品物に含まれ、権利はどうなりますか
10. 生成AIや埋め込みのモデルを後から差し替えるとき、どれくらいの手間がかかりますか

質問2〜4に一般論でしか答えられない会社は、社内向けで最も事故が起きやすい部分の経験が浅い可能性があります。質問9の評価用の質問一式と評価結果は、後で別の会社に切り替えるときや内製に移すときの土台になるので、必ず納品物に含めてください。業務を聞く前から特定の製品だけを勧める場合も注意が必要です。AIエージェントまで含めて開発会社を比べたい場合はAIエージェント開発の費用と進め方、提案依頼書の書き方はRFPの書き方ガイドが参考になります。

状況別の読み分け早見表

いまの状況に近い行から、次に読むところを選んでください。

よくある質問

社内RAG・チャットボット開発の相談先

koromoは、生成AIを使ったプロダクト開発と、AI導入の戦略づくりを支援しています。この記事で扱った対象文書と質問の決め方、NASやSharePointの文書の取り込みと閲覧権限の引き継ぎ、PoCの範囲と合格ラインの設計、Claude Codeなどを使った開発の進め方について、技術相談を受け付けています。

次のような段階の方は、相談いただくと判断が早く進みます。

• 既製サービスを試したが、部署ごとの閲覧権限や業務システムとの連携が満たせない
• 試作したRAGの精度が出ず、取り逃しなのか生成の問題なのかを切り分けたい
• 開発会社から見積もりを取ったが、範囲と金額が妥当か判断できない

一方で、答えさせたい質問や対象文書がまだ決まっていない段階や、既製サービスで業務が足りている場合は、先に上のチェックリストで条件を整理したり、既製サービスを試したりするほうが早く成果につながります。