AIアシスタントの発注は、要件を整理し、RFPで提案を募って、要件定義書で仕様を合意する流れで進みます。曖昧な要件での発注は失敗を招くと、現場で繰り返し示されています。
全体像はAIアシスタントの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・AIアシスタントの完全ガイド
AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
AIアシスタント開発でRFP・要件定義書が重要になる理由
AIアシスタント開発は、従来のシステム開発より要件が曖昧になりやすい特徴があります。業務効率化や問い合わせ対応の負担軽減といった、漠然とした期待から始まります。
何をどこまで自動化するかを詰めないまま見積もりへ進むこともあります。そうした状態でRFPを出すと、各社の想定範囲がばらつき、提案を同じ条件で比べられません。RFPと要件定義書は、こうした事態を避けるために、自社の要求水準を明確にし、各社を公平に比べるための文書です。
曖昧な発注が認識齟齬と失敗を招く構造
AIアシスタント開発では、発注者とベンダーの間で「完成」のイメージがずれることがあります。
- 発注者の期待：社内の質問に、ほぼ正確に答える状態
- ベンダーの完成像：指定した文書を参照して回答を生成する機能
そのため、要件定義書では、支援する範囲と精度を数値と文章で合意しておきます。曖昧なままだと、検収の場面で評価が食い違います。
認識がずれたまま進むと、追加開発の費用負担をめぐる交渉に時間を取られることもあります。
もう一つの問題は、生成AIの出力が確率的に揺らぐことです。同じ質問でも回答が変わり、誤った内容を返す場合もあります。
生成AIの特性を前提に、許容する誤答率と、回答できない場合の対応を定義しておきます。こうすれば、「100%正確」という期待と現実との差を埋められます。
加えて、有人対応へ引き継ぐ条件も、あらかじめ決めておきます。AIの限界を前提にした要件設計が、現実的な合意形成の出発点になります。
発注後の手戻りは、無視できないほどのコストになります。たとえば、要件が固まらないまま開発を進め、仕様変更を重ねると、当初の見積もりより数割増しになることも珍しくありません。
そこで、発注前にRFPと要件定義書で前提を固めておけば、その後の手戻りを大幅に減らせます。さらに、要件定義は準備作業にとどまらず、プロジェクト全体の予算と納期を大きく左右します。
RFPと要件定義書の役割分担
RFP（提案依頼書）は、発注者が解決したい課題や提案の前提を示し、ベンダーから提案を募る文書です。
要件定義書は、採用するベンダーと具体的な仕様を合意し、契約後の設計の土台にする文書です。
- RFPで各社から提案を募る
- 提案を比べて、ベンダーを絞り込む
- 要件定義書で、詳細な仕様を詰める
実務では両文書の境界は厳密ではなく、RFPにも業務範囲や非機能要件、セキュリティの前提を書きます。
情報が不足すると見積もりの精度が上がらない一方で、要求を詰め込みすぎると、ベンダーの工夫を妨げる場合があります。
技術の選択肢が幅広いAIアシスタントでは、達成したい状態と譲れない制約を示し、実現手段はベンダーに委ねる書き分けが有効です。
RFPには、目的と背景、業務範囲、参照データを書きます。さらに、求める精度や品質、セキュリティとガバナンスの前提も書きます。加えて、予算とスケジュール、評価観点、提案依頼項目も揃えます。
前提を共有すれば、ベンダーは条件に沿った提案を作れます。RFPの完成度は、その後の提案の質を左右します。
要件定義書に盛り込むべき必須項目（機能・非機能・データ・セキュリティ）
AIアシスタントの要件定義書は、項目群ごとに整理すると抜け漏れを防げます。
- 機能・データ：対象業務、参照情報、処理内容
- 非機能・セキュリティ：性能や安全性の基準
- SLA・精度目標：品質と受け入れ水準
- 運用保守・見積前提：体制と費用条件
各区分で、どこまでを誰が受け持つかを決めておくと、後の認識齟齬を防げます。
機能要件とデータ要件の書き方
機能要件では、AIアシスタントに実行させる業務やタスクを具体的に書きます。
- 対象範囲：業務やタスク、参照文書の種類
- 利用方法：対話形式と外部システム連携
- 対応条件：有人対応への引き継ぎ要否
具体的には、人事規程・経理マニュアル・過去の問い合わせ履歴を参照し、回答できない質問は担当部署へ引き継ぐ、と書きます。「社内問い合わせに答える」という表現だけでは、実際の動きが定まりません。
欲しい機能を「必須」と「あれば望ましい」に分けておくと、予算に応じて範囲を調整できます。
データ要件は、AIアシスタントの精度を直接左右します。RAG（検索拡張生成）では、読み込む文書の種類、形式、量を明記します。
手書きのスキャンや複雑な表が含まれる場合は、要件定義書に記載します。記載がないと、前処理の工数が膨らむ原因になります。
元データの洗い出しと前処理を、発注者とベンダーのどちらが担うかは、契約で明確にしておきます。どこまでを誰が受け持つかが曖昧だと、運用開始後に責任の押し付け合いが起きるおそれがあります。
RAG導入の進め方には、5段階のフレームワークがあります。最初にデータ準備を行い、チャンキング設計と検索方式の選定を経て、生成の制御と評価に進みます。
データ準備には、プロジェクト全体の工数の40〜60%を割くべきだという考え方が、プロジェクト管理の鉄則として示されています。
そのため、この工数配分とデータ整備の範囲は先に決めておきます。決めないまま進めると、整備が不十分になり、回答精度が伸びない結果を招きます。
機能要件と並んで、データ要件の範囲と担当の区切りを丁寧に定めます。
非機能要件とセキュリティ要件の整理
非機能要件では、品質や性能の基準を定義します。測定できる形で書いておくと、後の品質トラブルを防げます。
- 応答速度：質問から回答までの許容時間
- 同時利用：ピーク時のアクセス数への耐性
- 品質管理：可用性と操作ログの保全
応答時間は利用体験を左右します。同時利用者数を見込んでおかないと、利用が広がったときに動作が重くなり、導入後に使われなくなる場合があります。
社内の機密情報を扱うため、セキュリティ要件は要件定義書の中核になります。部署や役職によって閲覧の可否が分かれる情報は、利用者の権限に応じて回答を制御します。
権限制御がないと、見せるべきでない情報が回答に混ざるおそれがあります。そのため、RFPには、閲覧権限に応じた回答制御と、参照データへのアクセス制御を盛り込みます。
入力した社内データが生成AIの学習に使われない契約や設定になっているかは、要件として定めます。併せて、不正入力の検知・遮断と、参照データの改ざん検知ができるかを定めます。
厳格な対策ほど工数と費用が増えるため、セキュリティは機能要件や費用との調整が必要です。
扱うデータの機密度に応じて対策に強弱をつけ、高機密の情報を扱う部分に重点を置きます。
この要件設計によって、コストと安全性を両立させられます。
デジタル庁「調達チェックシート」を民間RFPに転用する評価観点
AIアシスタントのRFP作成では、デジタル庁が公開する調達チェックシートが、強力な下敷きになります。AIを安全かつ責任を持って運用できるかを確認するうえで役立ちます。
官公庁の調達向けの枠組みですが、民間企業のRFPにも応用できます。AI調達の知見が乏しい場合でも、要件の抜け漏れを大幅に減らせます。
公的機関の枠組みを土台にすることは、他社と差がつく要件定義書を作る、実践的な近道です。
チェックシートの基本要件と民間RFPへの落とし込み
デジタル庁の調達チェックシートでは、AIガバナンスやセキュリティインシデントへの対応体制などの観点が示されています（出典：デジタル庁）。
- ガバナンス：AIの利用方針と体制
- インシデント対応：発生時の手順と連絡体制
- 透明性：プロンプトや判断根拠の確認
- 検証可能性：運用の中身を確かめられる状態
行政向けの観点ですが、社内に導入する民間企業にとっても重要な評価軸です。RFPに明記しておけば、安全性を軽視するベンダーを見極められます。
生成AIの技術と安全性の論点は日々変わります。そのため、信頼できる枠組みに沿ってRFPを作ることが、品質を担保する現実的な手段になります。
特に、透明性要件は、AIアシスタント特有の論点として重視します。生成AIは判断の過程が見えにくく、誤回答の原因を追いにくいという課題があります。
回答の根拠となった参照文書を示せるか、判断ログを保全できるかを、RFPに明記します。そのうえで、原因を追跡できる状態を契約段階で合意しておくと、運用時の安心につながります。
評価観点の要件定義書への整理
チェックシートの観点をベンダー評価に使うには、各社へ同じ前提で提案を求めることが欠かせません。
- 要件区分：機能・非機能・セキュリティ・データ
- 品質と体制：SLA・精度目標・運用保守
- 費用条件：見積もりの前提
提案の前提をそろえてこそ、比較が成り立ちます。RFPで評価軸を示しておけば、各社を同じ土俵で並べられます。
評価項目を要件定義書に織り込めば、根拠に基づいてベンダーを選べます。
AIアシスタントは、構築して終わりではなく、運用しながら精度を高めていくものです。そのため、費用の安さだけでなく、その後の改善を支える体制も見ます。
回答できなかった質問を集めて改善に反映する仕組みがあるか、データ整備を支援してくれるかを確認します。
データ準備は精度を左右します。発注者に丸投げするベンダーでは、十分な精度に届かない場合があります。そこで、改善体制とデータ整備の支援を評価項目に加えると、選定の質を高められます。
評価項目に重みを付けて点数化すると、各社を客観的に比べられます。たとえば、セキュリティを重視する場合は配点を高くし、機能や費用とのバランスも数値で見ます。
提案を受けた後に評価軸を決めると、特定のベンダーに有利な判断が入りやすくなります。そのため、RFPを出す前に評価の枠組みを固めておくことが、公平で説明できる選定につながります。
隠れコストと精度目標をRFPで握るための実務ポイント
初期開発費だけを見ると、運用時に総額が逆転する場合があります。精度目標が曖昧なままだと、検収時にトラブルが起きる原因になります。
隠れコストを洗い出して、精度目標を受け入れ基準としてRFPに書きます。発注後の予算超過や検収トラブルを防ぐためです。
隠れコストのRFPでの明示
AIアシスタントの開発費は、規模や進め方で変わります。たとえば、小規模なPoC（概念実証）は50万〜200万円程度が目安です。
中規模の本番構築は1,500万〜4,000万円程度が一般的な目安とされています。
PoCで検証してから進めるのか、本番運用を見据えるのかを、RFPに記載します。
開発フェーズが曖昧だと、各社の想定範囲がずれ、見積もりを比べられません。
初期開発費以上に注意すべきなのは、運用時に継続して発生する隠れコストです。
- 継続費の明示：保守費・DB拡張費・API従量課金の見積もり
- 月額試算：想定問い合わせ量を前提にした試算
運用保守費の目安は初期費用の15〜25%程度で、ものによっては年間20〜30%です。
ベクトルデータベースのスケーリング費用や生成AIのAPI従量課金は、利用拡大に伴い膨らみます。
RFPでは、初期費用と運用時の費用を分けて提示してもらうよう求めます。そこで、総保有コスト（TCO）の観点で比べ、導入後の維持費を把握します。
コスト構造を要件定義で合意しておけば、想定外の維持費を避けられます。
費用の透明性を求めることは、ベンダーの誠実さを見極める材料にもなります。
精度目標の受け入れ基準化
精度目標は、AIアシスタントのRFPで最も合意が難しい項目です。「精度が高いこと」という書き方では、評価が主観的になり、検収時のトラブルにつながります。
- Context Precision：検索した文書の的確さ
- Faithfulness：回答が参照文書に忠実か
各指標をどの水準で測るかを、RFPに記載します。精度を数値で語れる体制かどうかも、技術力を見極める材料になります。
受け入れ基準には、測定方法と判定基準を組み合わせて定めます。具体的には、代表的な業務質問100件を使い、参照文書に基づく正答率が一定水準以上かを確認する方法があります。明らかな誤答が一定割合を超えないことを、条件にすることもできます。
テストデータに加えて、誰がどのように判定するかまで合意しておけば、納品時に客観的に評価できます。
生成AIには、100%の正答を求めない前提で設計することが現実的です。そのうえで、許容できる誤答率を定めます。
要件には、回答の自信が低い場合に「わかりません」と答える条件や、有人対応へ引き継ぐ条件も含めます。
運用に耐える精度を測定できる形にし、改善を続ける前提でRFPを設計します。精度目標は、運用しながら見直すものとして合意しておきます。この前提が、導入を成功させる要点です。
まとめ
AIアシスタントは、要件が曖昧なまま発注すると認識齟齬による失敗につながります。そこで、要件定義書には、機能や非機能、データやセキュリティの必須項目を整理します。
デジタル庁の調達チェックシートを民間RFPに転用し、AIガバナンスや透明性を評価軸に加えると、RFPの抜け漏れを抑えられます。費用の目安は、PoCが50万〜200万円、中規模の本番構築が1,500万〜4,000万円です。
運用保守費は初期費用の15〜25%程度で、ものによっては年間20〜30%が発生します。ベクトルDBの拡張費やAPI従量課金なども、要件定義の段階で明らかにします。また、データ準備には全体工数の40〜60%を割く前提で、担当範囲を合意します。
Context PrecisionやFaithfulnessなどの指標を、受け入れ基準に含めます。RFPは要求水準を明らかにし、各社を同じ条件で比べるための文書です。その作成に時間をかけることが、プロジェクト全体の成否を左右します。
要件定義書を整えておけば、認識齟齬のないベンダー選定と、AIアシスタントの導入につながります。
▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。