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