7つの質問に全て具体的に答えられた開発会社なら、そのまま発注して問題ないですか？

回答の具体性に加え、自社のデータ量・業務要件と紐づけて説明できているかを重視してください。例えば「貴社のデータ量ならチャンキングはこう設計します」のように自社特有の言及がなく一般論の羅列で終わる場合は、商談で「うちの場合は？」と重ねて聞き返すことをおすすめします。

他社より見積金額が大幅に安い開発会社は避けるべきですか？

金額だけで判断せず、データ整備・システム構築・UI・インフラ・保守の5項目に内訳が分解されているか確認してください。安さの理由がデータ整備工数の見積漏れであるケースが多く、稼働後に想定外の追加費用が発生しやすいため、内訳の分解を求めてから比較することをおすすめします。

小規模なPoC発注でも、7つの質問カテゴリを全部聞く必要がありますか？

全て聞く必要はなく、自社の状況に応じて3〜5個をピックアップすれば十分ですが、規模を問わずゴール指標（1）と精度評価・検収基準（3）の2つだけは、PoCの成否判定基準になるため優先的に確認してください。

商談前の情報整理には、どれくらいの期間を見ておけばいいですか？

目安として1〜2週間ですが、優先すべきは対象データの一覧と想定質問セットの2つです。この2つが揃っていれば残りの4項目が多少粗くても商談は進められるため、時間が限られる場合はまずこの2つから着手してください。

検収条件を数値で契約書に明記してもらえない場合、どう対応すればいいですか？

口頭合意だけで進めず、仕様書レベルでも数値条件（例: Faithfulness◯以上）を書面に残すよう交渉してください。応じない場合は、検収時に評価基準が曖昧なまま「感想戦」になるリスクが高い開発会社と判断できます。

RAG導入で開発会社に確認すべき7つの質問｜商談を主導する発注者向けチェックリスト

Q: 7つの質問に全て具体的に答えられた開発会社なら、そのまま発注して問題ないですか？

回答の具体性に加え、 自社のデータ量・業務要件と紐づけて説明できているか を重視してください。例えば「貴社のデータ量ならチャンキングはこう設計します」のように自社特有の言及がなく一般論の羅列で終わる場合は、商談で「うちの場合は？」と重ねて聞き返すことをおすすめします。

Q: 他社より見積金額が大幅に安い開発会社は避けるべきですか？

金額だけで判断せず、 データ整備・システム構築・UI・インフラ・保守の5項目に内訳が分解されているか 確認してください。安さの理由がデータ整備工数の見積漏れであるケースが多く、稼働後に想定外の追加費用が発生しやすいため、内訳の分解を求めてから比較することをおすすめします。

Q: 商談前の情報整理には、どれくらいの期間を見ておけばいいですか？

目安として1〜2週間ですが、優先すべきは 対象データの一覧と想定質問セット の2つです。この2つが揃っていれば残りの4項目が多少粗くても商談は進められるため、時間が限られる場合はまずこの2つから着手してください。

「社内文書を使った生成AI を導入したい」という経営層からの企画を任され、内製は難しいと判断してベンダー数社に見積依頼をかけた——。ところが、返ってきた提案書は各社バラバラで、金額も 3〜5 倍の開きがある。商談で説明を聞いても「チャンキング設計」「ハイブリッド検索」「RAGAS」といった用語が飛び交い、それが正しい話なのか、自社の状況に合っているのかを判断できない。RAG の開発会社（ベンダー）を選んでいるあなたは、今そんな状態にいるのではないでしょうか。

RAG（Retrieval-Augmented Generation、検索拡張生成）は、通常のシステム開発とは違って「社内データの質」と「精度評価のやり方」で成否が決まる特殊な領域です。だからこそ、開発会社の説明を "なんとなく良さそう" で受け止めたまま発注してしまうと、後から「PoC は動いたが本番で精度が出ない」「見積に入っていなかった追加費用が発生する」「セキュリティ要件を満たせない」といった "こんなはずじゃなかった" が高い確率で起こります。

Gartner の予測では、2025 年末までに生成 AI プロジェクトの少なくとも 30% が PoC 後に見送られ、AI プロジェクトの 60% は 2026 年までにデータ不足で失敗するとされています（AQUA「RAG導入で失敗する原因と対策（Gartner調査から学ぶ成功フレームワーク）」）。この失敗の大半は、ベンダーの技術力不足ではなく "発注時点で握れていなかった前提" が原因です。逆に言えば、発注前の商談で正しい質問を投げられれば、失敗の多くは事前に潰せます。

そこで本記事では、RAG 導入の商談・見積比較の段階で開発会社（ベンダー）にぶつけるべき質問を、7 つのカテゴリに整理してご紹介します。単なる「選び方の観点」ではなく、商談で実際に口に出す質問文と、返ってきた回答を "地雷シグナル" として読み解くコツまで踏み込みます。読み終えた後には、次の商談で「うちのデータ量とセキュリティ要件だとチャンキング設計はどうしますか？」「RAGAS スコアの検収基準はどう握りますか？」といった具体的な質問ができ、発注判断を自信を持って進められる状態になっているはずです。

Contents — 目次

RAGとは？発注前に押さえる最低限の基礎知識
なぜ「開発会社への質問リスト」が必要なのか
開発会社に確認すべき7つのポイント（質問チェックリスト）
見積比較で確認すべき費用の内訳と質問
発注前に自社側で準備しておくべき情報
開発会社を絞り込むための総合判断ステップ
まとめ｜商談を主導する側になるために

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

AI導入を検討しているが、何から始めればよいか分からない
ベンダーの選び方や費用感がつかめず、判断できない
社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

RAGとは？発注前に押さえる最低限の基礎知識

商談で開発会社の説明が理解できないと、質問もできず、地雷も見抜けません。ここでは RAG の仕組みを "商談で使える最低限の共通語彙" として最短でおさらいします。深い技術理解は不要ですが、商談で頻出する 5 つの用語だけは押さえておきましょう。RAG そのもののユースケースや効果に関心がある方は、RAG のビジネス活用ガイドも併せてご覧ください。

RAG の仕組みを一枚絵で理解する（検索から生成のフロー）

RAG は、大きく分けると「検索（Retrieval）」と「生成（Generation）」の 2 段構成で動きます。流れは次のとおりです。

ユーザーが質問を入力する
質問文に近い意味を持つ社内文書を検索する（ベクトル検索・キーワード検索）
見つかった文書の該当箇所を、質問文と一緒に LLM（ChatGPT などの大規模言語モデル）に渡す
LLM が渡された文書を根拠に回答を生成する

ポイントは、LLM そのものは自社の情報を学習していないという点です。あくまで「検索してきた文書」を根拠に、その場で回答を作ります。だからこそ、渡す文書の "検索精度" と "整理状態" が回答品質を左右します。開発会社の提案でも、この「検索側の設計」と「生成側の設計」を分けて説明できているかが、地に足のついた提案かどうかを見分ける最初のシグナルになります。

ファインチューニングとの違い・使い分け

RAG とよく比較されるのが「ファインチューニング」です。ファインチューニングは LLM 自体に自社データを追加学習させて "モデルを賢くする" アプローチです。一方、RAG は LLM を学習させず、外部の検索エンジンから毎回文書を取ってきて回答させる仕組みです。

発注者視点での使い分けは次のとおりです。

RAG が向くケース: 社内文書が頻繁に更新される / 情報ソースを明示したい（監査対応・引用が必要）/ コストを抑えたい
ファインチューニングが向くケース: 特定の文体・書式で回答させたい / ドメイン特化の推論（法律・医療用語など）を強化したい

社内文書の Q&A や FAQ 応答、業務マニュアル参照といった「文書の中身に基づいて答える」用途は、ほぼすべて RAG が第一選択です。商談で開発会社が「まずはファインチューニングを」と提案してきたら、なぜ RAG ではないのか、コストと運用の観点で説明を求めましょう。

商談で頻出する 5 つの用語

商談で高い頻度で登場する用語を最小限で押さえておきます。用語をすべて説明できる必要はありませんが、"聞いた瞬間に文脈が把握できる" 状態を目指します。

ベクトルDB: 文書を数値の並び（ベクトル）に変換して保存する専用データベース。意味が近い文書を高速に探すために使う。Pinecone / Weaviate / pgvector などが代表例
埋め込み（Embedding）: 文書や質問文をベクトルに変換する処理。使う埋め込みモデル（OpenAI、Cohere、多言語モデルなど）で検索精度が変わる
チャンキング: 長い社内文書を検索しやすい単位に切り分けること。切り方（文字数・意味単位・見出し単位）で精度が大きく変わる、地味だが重要な設計項目
Retriever（リトリーバー）: 質問に対して関連文書を取ってくる仕組み。ベクトル検索単独か、キーワード検索と組み合わせた「ハイブリッド検索」かで精度が変わる
RAGAS: RAG の回答品質を自動評価するためのオープンソースフレームワーク。Faithfulness（根拠との一致度）、Answer Relevancy（質問への的確さ）、Context Precision / Recall（検索の的中度）などの指標を提供する（RAGAS 公式ドキュメント）

これら 5 つの用語が説明抜きに商談で飛び交うことがあります。相手の話に登場したときに「その部分について、うちの場合はどう設計されますか？」と聞き返せる状態になれば、商談の主導権はぐっと発注者側に寄ります。

なぜ「開発会社への質問リスト」が必要なのか

商談で "空気を読んで頷いてしまう" と、後から「なぜあの時に聞かなかったのか」という後悔が高い確率で起こります。ここでは、なぜ RAG 発注に "質問リスト" という武装が必要なのか、失敗の構造から確認します。

PoC 止まり・精度不足の失敗パターンと発注側の責任範囲

Gartner の予測は前述のとおり、生成 AI プロジェクトの 30% が PoC 後に見送られ、60% がデータ不足で失敗するとされています（AQUA「RAG導入で失敗する原因と対策」）。この失敗を細かく分解すると、以下のパターンに集約されます。

ゴール指標が曖昧なまま PoC を始めた: 「AI が答える」ことがゴールになり、業務削減時間や CS 応答率などの効果指標が握られていない
対象データの範囲が定まっていない: 「社内文書全部」といったスコープで発注し、実際にはフォルダ横断で権限・重複・鮮度の問題が噴出する
精度の "合格ライン" が数値で握られていない: 「良い感じの精度」で合意した結果、検収で "感想戦" になる
前提と違うデータ量・種類が来て工数が破綻する: PDF スキャン画像・表・Excel など、ベンダーが想定していなかった形式が混ざる
保守・改善サイクルが契約に入っていない: 稼働後に精度が下がっても運用契約がなく、改善が止まる

こうした失敗の根本原因は、開発会社の技術力ではなく "発注時点ですり合わせできていなかった前提" にあります。つまり、質問さえ投げていれば防げた失敗が大半を占めます。

"選び方 6 観点" だけでは不十分な理由

RAG 開発会社の選び方を扱う競合記事の多くは「実績・技術力・セキュリティ・費用・サポート・体制」といった 6 前後の観点を並べて終わります。しかしこれは、"どんな基準で見るか" のフレームに過ぎず、"実際に商談で口に出す質問" の粒度までは踏み込んでいません。

たとえば「セキュリティを確認する」と言っても、「データは自社の閉域網に置けますか？」と「暗号化はどのフェーズで施しますか？」では、返ってくる情報の粒度がまるで違います。前者はマーケティング資料の抜粋で答えられますが、後者は実装経験がないと具体的に答えられません。質問の粒度を上げるほど、開発会社の実力差がクリアに出ます。これが「質問リスト」を持つことの実利です。

開発会社に確認すべき7つのポイント（質問チェックリスト）

ここからが本題です。RAG 発注で失敗しないために、開発会社（ベンダー）に確認すべきポイントを 7 つのカテゴリに整理しました。各カテゴリでは、「商談で口に出す質問文」 と 「返答の読み方（良い返答／地雷シグナル）」 をセットで示します。すべての質問を暗記する必要はありませんが、自社の状況に合わせて 3〜5 個ピックアップし、次の商談に持ち込んでみてください。

ポイント1: ゴール指標を数値で握るための質問

RAG プロジェクトが漂流する最大の原因は、ゴールが「AI が使えるようになる」で止まっていることです。発注前に、開発会社と一緒に "どうなれば成功か" を数値で握りましょう。

質問例:

「今回のプロジェクトの成功指標は、業務時間削減率・回答正答率・利用率のどれで測るべきだと考えますか？」
「PoC の完了条件と、本番リリースの完了条件を数値で定義するとしたら、何をどう握るのがおすすめですか？」
「他社の類似プロジェクトでは、どの指標を検収条件にしていましたか？」

良い返答: 業界・用途ごとの指標例（例: 社内FAQ なら "想定質問セット 100 件のうち正答率 80% 以上") を具体的な数値と実績で提示できる。

地雷シグナル: 「PoC で見えてから決めましょう」で流す / 「精度は上がる想定です」といった主観表現に終始する / 数値目標の議論を避ける。ゴールを握らない発注は、あとで検収時に "感想戦" になります。

ポイント2: 対象データの範囲と品質に関する質問

RAG の回答精度は、渡すデータの状態でほぼ決まります。「どのデータをスコープに入れるか」「そのデータの状態はどう扱うか」を、発注前に必ずすり合わせましょう。

質問例:

「対象データはこの 3 種類（例: 業務マニュアル PDF / 議事録 Word / 商品仕様 Excel）ですが、それぞれの前処理の見積工数はどれくらいですか？」
「PDF に画像・図表が含まれる場合、OCR や表構造抽出はスコープに入りますか？追加費用の目安は？」
「データの更新頻度（月次 / 日次 / リアルタイム）に応じて、どんな運用設計になりますか？」
「重複文書・古い版・アクセス権限が異なる文書が混ざっている場合、どう扱いますか？」

良い返答: データ形式ごとの前処理工数を分解して見積れる / 更新頻度に応じたパイプライン設計を具体的に説明できる / データ棚卸しの支援メニューがある。

地雷シグナル: 「一式で対応します」でデータ形式別の工数を出さない / データ品質の話をせず「モデルで頑張ります」と回答をずらす。この構造は、発注後に「想定よりデータが汚れていた」という理由で追加費用が発生する典型パターンです。

ポイント3: 精度評価と検収基準に関する質問

「精度が上がる」は感覚語です。何をもって "精度 OK" とするかを、発注前に評価指標と数値で握るのが RAG プロジェクトの検収トラブルを防ぐ最短ルートです。

質問例:

「精度評価は RAGAS のような自動評価ツールを使いますか？Faithfulness・Answer Relevancy・Context Precision のどの指標を、いくつ以上で合格とする想定ですか？」（RAGAS 公式ドキュメント参照）
「評価用データセット（想定質問 + 正解回答のペア）は、御社が用意しますか？弊社が用意しますか？件数の目安は？」
「検索精度（Recall@k）と生成精度を分けて評価しますか？それぞれの目標値は？」
「検収時に精度が目標に届かなかった場合、追加改善はどこまでスコープ内ですか？」

良い返答: 使用する評価指標名（RAGAS・Recall@k・BLEU 等）を具体的に挙げる / 評価データセットの用意主体と件数（100〜300 件が一般的）を明示する / 未達時の追加改善の範囲を契約書レベルで説明できる。

地雷シグナル: 「体感で確認します」/「エンジニアがレビューします」で自動評価の話が出てこない / 評価データセットを "誰が用意するか" が曖昧。この状態のまま検収を迎えると、精度議論が水掛け論になります。

ポイント4: 技術構成とアーキテクチャに関する質問

技術詳細まで理解する必要はありませんが、「なぜその構成を選んだか」を説明できるベンダーかどうかは、実力差がクリアに出るポイントです。

質問例:

「チャンキングは何を基準に（文字数・意味単位・見出し単位）どのサイズで切りますか？その選定理由は？」
「Retriever はベクトル検索単独ですか、キーワード検索とのハイブリッドですか？どちらを選ぶ理由は？」
「LLM は OpenAI・Anthropic・オープンソースモデルのどれを使う想定ですか？選定基準は精度・コスト・データ主権のどれを優先していますか？」
「ベクトル DB は Pinecone / Weaviate / pgvector / OpenSearch のどれですか？なぜその選定ですか？」

良い返答: 各コンポーネントの選定理由を "自社の要件（データ量・レイテンシ・コスト・データ主権）と紐づけて" 説明できる / 代替案とのトレードオフを比較して答えられる。

地雷シグナル: 「弊社の標準構成です」で理由を説明しない / 全案件で同じ構成を推奨してくる / 質問に対して抽象的な "ベストプラクティス" 論に逃げる。RAG は用途によって最適構成が変わるため、"標準構成の押し付け" は要注意です。

ポイント5: セキュリティと運用要件に関する質問

社内文書を扱う RAG は、セキュリティ要件を発注前に握らないと、後からアーキテクチャの作り直しが発生します。特に金融・医療・行政向けは、質問の粒度を上げましょう。

質問例:

「データはどのクラウド（AWS / Azure / GCP）のどのリージョンに保管されますか？国内リージョン限定は可能ですか？」
「LLM API に送るデータが学習利用されない契約（データオプトアウト）は可能ですか？OpenAI Enterprise / Azure OpenAI などの選択肢は？」
「保管時・通信時の暗号化はどう実装されますか？鍵管理は誰が持ちますか？」
「ユーザー単位のアクセス権限（誰がどの文書に基づく回答を得られるか）は、どう実装されますか？」
「オンプレミス・閉域網でのデプロイに対応可能ですか？その場合の追加コストと納期は？」

良い返答: リージョン・データオプトアウトの選択肢を具体的に説明できる / 権限制御の実装パターン（メタデータフィルタ / インデックス分割）を提示できる / オンプレ対応の場合の制約を正直に説明する。

地雷シグナル: 「一般的な SaaS レベルのセキュリティです」で個別要件に踏み込まない / 権限制御の話が抜け落ちる。RAG の権限制御は "検索段階でフィルタする" のか "回答生成後にフィルタする" のかで実装難易度が大きく変わるため、ここを詰められないベンダーは要注意です。

ポイント6: SLA・保守・改善サイクルに関する質問

RAG は "作って終わり" のシステムではなく、稼働後にデータを追加し、精度を改善しながら育てていくものです。保守契約の中身を発注前に確認しましょう。

質問例:

「月額保守費用の内訳を、監視・データ追加・精度改善・障害対応で分けて示してもらえますか？」
「精度改善のサイクル（月次 / 四半期）と、改善の作業範囲はどこまでですか？」
「障害発生時の初動対応時間と、復旧目標時間の SLA はどう定義されますか？」
「LLM API のバージョンアップ（例: GPT-4 → GPT-5）が起きた場合、リグレッション評価と追随はどう対応しますか？」

良い返答: 保守項目を分解して工数レベルで説明できる / 改善サイクルに具体的なプロセス（月次レポート・改善会議）がある / SLA を数値で明示できる。

地雷シグナル: 保守を「月 X 万円」の一式で提示し内訳を出さない / SLA が「ベストエフォート」だけで数値がない / LLM のバージョンアップ対応が契約に含まれない。稼働後に精度が下がったとき、動ける保守契約かどうかを見抜くのがここのポイントです。

ポイント7: 引き渡し資産と発注後の内製移行に関する質問

将来的にデータ整備や運用を内製に切り替えたい場合、"渡してもらえる資産" の中身を発注前に握っておかないと、ベンダーロックインが起きます。

質問例:

「納品時に渡していただける資産は何ですか？（設計ドキュメント・ソースコード・評価用データセット・チャンキング設定・プロンプトテンプレート）」
「稼働後のログ・評価スコアは、弊社側で常時参照できる形で提供いただけますか？」
「将来、運用を内製化する場合、引き継ぎのためのドキュメント・トレーニングは提供可能ですか？」
「ソースコードの著作権と改変権はどう扱われますか？」

良い返答: 引き渡し資産のリストを事前に提示できる / ログ・評価スコアの参照方法（管理画面 / API）を具体化できる / 内製移行を想定した契約オプションがある。

地雷シグナル: 「ソースコードは弊社の資産です」で交渉に応じない / 評価データセット・プロンプトを "ブラックボックス" にする。この場合、他社への切り替えや内製化ができず、実質的なベンダーロックインになります。

見積比較で確認すべき費用の内訳と質問

複数社の見積を並べたとき、金額が 3〜5 倍ばらつくことがよくあります。ばらつきの正体は "スコープの粒度が違う" ことです。見積の内訳を揃えて比較しないと、安く見えて後から追加費用が積み上がる、という失敗が起きます。ここでは見積比較で確認すべき項目と、追加費用を防ぐための質問を整理します。

見積書で確認すべき費用内訳の 5 項目

RAG の見積は、次の 5 項目に分解して示されているか確認します。

データ整備・前処理費用: 対象データの棚卸し・OCR・表構造抽出・チャンキング設計・埋め込み処理。RAG では実はここが人的工数の大きな割合を占めます
システム構築費用: Retriever・LLM 連携・回答ロジックの実装
UI 開発費用: チャット画面・検索画面・管理画面
インフラ費用（初期・月額）: ベクトル DB・クラウドリソース・LLM API 従量料金
運用・保守費用（月額）: 監視・データ追加・精度改善・障害対応

参考として、費用相場は PoC で 50〜300 万円、本番構築で 300〜1,500 万円、月額保守で 10〜80 万円のレンジで語られることが多いです（各社公開の相場情報より。例: GXO「RAG導入の費用相場と内訳」、ripla「RAG開発・構築のコストと費用の相場」。費用の見方の詳細は RAG システムの発注方法（費用・データ準備・ベンダー選定の 3 ステップ）を参照）。ただし、このレンジは対象データ量・要件の複雑さで大きく変わるため、金額そのものより "内訳がスコープ別に分解されているか" を優先して見てください。

追加費用が発生する典型パターンと事前確認の質問

RAG プロジェクトで追加費用が発生する典型パターンは、次の 4 つです。発注前の質問で、そのリスクを潰しておきましょう。

データ形式の想定外: PDF スキャン画像・表・音声など、見積時に想定していなかったデータ形式が混ざる → 「対象データにこれらが含まれる場合、追加費用の目安と条件は？」
精度未達時の追加改善: 検収時に精度目標に届かず、追加チューニングが発生 → 「精度未達時の追加改善は、どこまでが初期見積に含まれ、どこから追加費用ですか？」
保守範囲外の運用作業: データ追加・新規カテゴリ対応・プロンプト調整が保守外扱いになる → 「月次保守の範囲外になる作業を、具体例で挙げてもらえますか？」
LLM API の従量課金: 想定より利用が伸びて API 費用が跳ねる → 「利用量の見積前提と、想定を超えた場合の課金構造は？アラート設定はありますか？」

これらを見積比較の段階で "全社に同じ質問" として投げると、各社の対応力の差が定量的に見えます。同じ質問への回答が、単価だけでなく "どこまで具体的に説明できるか" というベンダー実力の差として現れます。

発注前に自社側で準備しておくべき情報

質問を投げるだけでは、開発会社も具体的な提案を返せません。RAG は "発注側の準備" が回答品質を決める側面があるため、商談前に自社で用意しておくべき情報を整理しておきましょう。

商談前に用意する 6 つの情報

商談の一次情報として、次の 6 つを整理して臨むと、見積の精度と提案の具体性が一段上がります。

対象業務・想定ユーザー: どの業務で・誰が使うのか（例: 営業部門 30 名の商品仕様問い合わせ対応）
対象データの一覧と概算量: どのフォルダ・システムに・どの形式で・どれくらいの量あるか（例: SharePoint 5 フォルダ、PDF 約 3,000 件、Excel 約 500 件）
想定 KPI: どうなれば成功か（例: 問い合わせ対応時間を月 40 時間削減）
想定質問セット（サンプル 20〜50 件）: 現場で実際に来る質問と "正解" のペア
セキュリティ・コンプライアンス要件: データ保管場所・オプトアウトの要否・アクセス権限の粒度
既存システム連携要件: 認証（SSO）・チャットツール（Teams / Slack）・BI ツールへの連携有無

このリストを商談前に開発会社と共有すると、提案書の抽象度が下がり、金額のばらつきも縮まります。特に 4 の「想定質問セット」は、そのまま精度評価用のデータセットに転用できる ため、準備しておく価値がとても高い情報です。

準備不足のまま発注した場合に起きること

上記の情報が揃わないまま発注を進めると、次のような問題が高い確率で起こります。

見積が "テンプレートの一式金額" になり、他社比較の物差しが揃わない
開発が始まってから対象データの実態と乖離が判明し、追加見積が発生
検収時に「合格ライン」の合意がなく、"感想戦" になる
稼働後に「思っていた業務効果と違う」というギャップが噴出する

準備不足は "ベンダーが優秀でも救えない" 領域です。発注前に自社側で 1〜2 週間かけて情報整理をするだけで、その後のプロジェクト成功率が大きく変わります。

開発会社を絞り込むための総合判断ステップ

質問を投げ、回答を受け取ったら、次はそれをどう総合判断につなげるかです。ここでは 2〜3 社の最終比較で使える簡易フレームと、契約直前の再確認ポイントを整理します。

回答スコアリングの簡易フレーム（3 段階評価）

7 つの質問カテゴリ × 各社の回答を、次の 3 段階でスコアリングしてみてください。

◎（3 点）: 質問に対して自社要件と紐づけた具体解を返し、代替案とのトレードオフまで説明できた
○（2 点）: 一般的なベストプラクティスは返せたが、自社要件と紐づけた具体化までは至らない
△（1 点）: 抽象的な回答・カタログ的な回答に終始し、具体性がない

7 カテゴリ × 3 点満点 = 21 点で各社を採点すると、"金額" と "回答の具体性" の 2 軸で比較できます。金額が同水準でも、スコアが 15 点と 8 点の会社では、発注後の成功確率がまったく違います。金額の安さで選ぶより、"質問に対して自社要件と紐づけて答えられるか" を優先することを強くおすすめします（内製・外注の判断そのものに立ち返りたい場合は RAG 開発・構築ガイド（内製 vs 外注の判断）をご覧ください）。

契約直前に再確認する 3 項目

最終候補が絞れたら、契約書を交わす直前に次の 3 項目だけは必ず再確認してください。

検収条件の数値化: 「想定質問セット X 件に対して、Faithfulness Y 以上、Answer Relevancy Z 以上」といった数値条件が契約書または仕様書に明記されているか
SLA と保守範囲: 月額保守に含まれる作業と含まれない作業が、具体例レベルで書き分けられているか
引き渡し資産と権利関係: 納品物・ログ・評価スコア・ソースコードの所有権と改変権が明文化されているか

この 3 項目は、稼働後にトラブルになったときに "泣きを見ない" ための保険です。契約直前の空気に飲まれず、書面で握ってから捺印しましょう。

まとめ｜商談を主導する側になるために

RAG 導入で開発会社に確認すべきポイントを、7 つのカテゴリに整理してご紹介しました。振り返ってみると、質問の中核はいつも同じ問いに帰着します。「あなたは、うちの状況に合わせた具体解を、数値と実績で説明できますか？」——この問いに具体的に答えられる開発会社（ベンダー）を見つけることが、RAG 発注の成否を分けます。

商談を "受け身で説明を聞く場" から "質問で主導する場" に変えるための最初の一歩は、社内でのゴール指標の握りとデータ棚卸しです。「どの業務の・誰の・どんな質問に・どの文書で答えさせたいか」を書き出すことから始めてみてください。それが、地雷を発注前に潰し、自信を持って開発会社（ベンダー）に発注するための出発点になります。