アンケートシステムの成否は、要件定義の出来で大きく決まります。調査の目的は「顧客満足度を測りたい」「従業員の本音を引き出したい」「市場ニーズを把握したい」と多岐にわたります。そのため、要件定義とRFP（提案依頼書）は、目的と成功指標の確認から始め、機能、コスト、見積りの判断へと順に詰めます。
全体像をまだ把握していない方は、まずアンケートシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・アンケートシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
調査目的とKGI/KPIから始める要件定義
要件定義は、「どんな機能が欲しいか」の一覧から始めず、何のために調査をするのか、その結果をどの意思決定に使うのかを徹底的に言葉にすることを出発点にします。目的が曖昧なまま機能を決めると、機能はそろっていても結果が活用されない、というよくある失敗につながります。そのため、最初の一歩は機能ではなく目的を明確にすることです。
調査目的と成功指標の言語化
最初に行うのは、調査の目的とゴールを言葉にすることです。「顧客満足度を測る」だけでは不十分で、どの指標が、いつまでに、どれだけ改善したら成功と言えるのかまで、KGI（最終目標）とKPI（中間指標）として具体化します。
たとえば「NPSを半年で5ポイント改善する」「解約率を3%下げる」といった数値目標を置くと、そこから逆算して必要な設問や分析、連携が見えてきます。また、目的が定まれば、過剰な機能を入れずに済み、コストの無駄も防げます。
ここで重要なのは、調査結果を「誰が、いつ、どの会議で見て、どんなアクションを決めるのか」という活用フローまで定義することです。
AI導入プロジェクトでも約32%が期待効果に届かなかったという調査（IDC Japan 2024、出典ripla調べ）がありますが、その多くは目的と運用設計の欠落が原因です。
アンケートシステムでも、結果を改善のループに乗せる運用を要件定義の段階で描いておかないと、立派なシステムを作っても形骸化します。目的、指標、活用フローを一組で定義することが、要件定義の土台になります。
- 目的と意思決定：何のために調査し、結果をどの判断に使うか
- KGIとKPI：数値と期限で表した成功指標
調査規模と対象の定義、スコープの確定
目的が定まったら、調査の規模と対象を決めて、スコープを固めます。規模は、年間の調査実施回数、1回あたりの想定回答数、同時アクセスのピークで押さえます。月数万件規模の回答を扱うのか、数百件で十分なのかによって、求められるシステムの作りは変わります。
あわせて、SaaS型の既製ツールで足りるのか、自社業務に合わせた個別開発（フルスクラッチ）が必要なのかという方向性も、このスコープ定義で見えてきます。
標準的な満足度調査ならSaaSで十分なことが多い一方、独自の業務フローへの組み込みや基幹システムとの密な連携が必要な場合や、特殊なセキュリティ要件がある場合は、個別開発が現実的です。
SaaS（月額数十万円）とスクラッチ（初期1,000万円規模）では、5年間の総保有コスト（TCO）の損益分岐がおよそ3.5年とされています（出典ripla試算）。そのため、調査の継続性と要件の特殊性から、どちらが妥当かを早期に見極めることが大切です。
この方向性が要件定義の前半で定まっていないと、後半で機能を詰めても土台が揺らぎ、ベンダー選定の段階で迷走しがちです。スコープ定義は、機能要件に入る前に設計の前提を固める作業として、丁寧に行う価値があります。
- 調査の規模と対象：回答数や同時アクセスを数値で示す
- 開発方式：SaaSか個別開発かの方向性を決める
対象者の属性も整理しておき、配信チャネル（メール・SMS・QR・Web埋め込み）も具体的に決めておきます。これらは後の非機能要件（性能・インフラ）の前提になるため、曖昧なままだとベンダーが適切な構成を見積もれません。
機能要件と非機能要件の整理
目的とスコープが固まったら、機能要件と非機能要件を整理します。機能要件は「何ができるか」を、非機能要件は「どれだけの品質で動くか」を定めるものです。
アンケートシステムでは機能要件に目が行きがちです。しかし、個人情報を扱い、調査期間に回答が集中するという特性があるため、非機能要件もおろそかにできません。両者を同じ深さで詰めることが、品質の担保につながります。
機能要件の必須・優先・将来による分類
機能要件は、並べるだけで終えず、優先度を付けて分類しておくことが大切です。必須機能は「これがないと調査が成立しない」機能で、たとえば多様な設問タイプや条件分岐、回答制御があります。集計や基本的な可視化も、ここに含まれます。
「効果は大きいが初期になくても運用できる」優先機能として、クロス集計やパネル管理、CRM連携を挙げます。
「将来追加でよい」機能としては、AI解析や多言語があります。
機能を盛り込むほど費用は膨らむため、この優先度付けが予算管理の要になります。優先度を付けておけば、見積りが予算を超えたときに、どの機能を初期リリースから外すかを冷静に判断できます。反対に、すべてを必須にしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。
優先度が明確であれば、まず必須機能でリリースし、効果を見ながら優先機能を追加する段階的なリリース計画が立てられます。
とくにAI解析のような高度な機能は、後述するコストとリスクを踏まえ、初期から入れるかを慎重に判断すべき領域です。どの機能を必須とみなすかは、調査の目的と運用体制から逆算して決めるのが原則です。
- 機能の三段階：必須・優先・将来に分けて整理する
- 初期リリースの範囲：初期に入れる機能の範囲を決める
非機能要件（性能・セキュリティ・可用性）
非機能要件では、性能・セキュリティ・可用性を定義します。
なかでも性能は、調査開始直後に回答が集中するアンケートで特に重要です。
セキュリティは、氏名や連絡先、意見といった個人情報を扱うアンケートで極めて重要です。回答データの暗号化やアクセス権限の制御を中心に、IPA（情報処理推進機構）のガイドラインなどを参照しながら要件化します。外部送信の管理やアクセスログの記録も含めます。
情報漏えいが起きて対応に500万円以上かかった事例（出典ripla調べ）もあり、セキュリティ要件の甘さは致命傷になりかねません。
可用性については、稼働率99.9%以上を選定基準とする考え方が一般的です。調査期間中にシステムが止まると回収の機会そのものを失うため、稼働率の目標、障害時の復旧時間、バックアップ体制を定めます。
非機能要件が曖昧なままだと、「遅い」「止まる」「漏れる」といったトラブルが起き、現場の信頼を一気に失います。
- 応答時間の目標：同時アクセス時も画面が遅れない水準を定める
- 個人情報の保護：暗号化とアクセス権限の制御を要件に入れる
「想定する同時アクセス数でも回答画面が遅延しない」という性能要件を明記しておきます。
応答性能の目安として、画面表示は3秒以内（繋ぎの表示があれば5秒以内）といった数値を置く考え方があります。
この目安は、他の対人系システムの調達でも採られており（神戸市の調達仕様などを参考、出典ripla調べ）、回答の離脱を防ぐうえで参考になります。ピーク時に画面が固まれば、回答者は離脱し、回収率も落ちます。
生成AI活用時のコスト要件とハルシネーション対策
自由記述のAI解析を要件に含める場合、通常のシステム要件にはない論点が二つあります。一つはトークン課金を前提としたコスト要件で、もう一つはハルシネーション（誤生成）への対策要件です。
この二つを要件定義で曖昧にしたままにすると、運用開始後にコストが急増したり、誤った分析結果を信じて意思決定を誤ったりするおそれがあります。生成AIを使うなら、要件として必ず明記すべき領域です。
トークン課金を前提としたコスト要件
生成AIによる自由記述解析は、処理する文章量（トークン数）に応じて課金されるため、回答数が増えるほどランニングコストが膨らみます。
要件定義では、想定する解析対象の件数と文章量から、月間のトークンコストを概算しておく必要があります。
たとえば、月10万リクエスト規模（入出力各500トークン想定）でも、Gemini 2.0 Flashなら約3,750円、GPT-4o miniなら約5,600円です。一方、Claude Sonnet 4なら約135,000円になり、モデル選定によってコストは数十倍変わります（出典ripla試算）。
どのモデルを前提に見積もるかを要件に明記しておかないと、ベンダーの見積りを横並びで比べられません。
実際に、トークン課金を月5万円と見込んでいたものが、運用すると月20万円を超えた事例もあります（出典ripla調べ）。
これを防ぐには、月間の利用上限を要件に盛り込みます（予算上限に達したら処理を止める、または低コストモデルに切り替える）。一次分類は低コストのモデルに任せ、重要な要約だけ高性能のモデルを使うといった使い分けを前提に、コストを抑えられる設計を求めるのが賢明です。トークンコストの上限管理は、AI解析を要件に含める際の必須事項です。
- 利用上限：月間の上限と、処理を止める条件
- モデル別の月額：モデルごとの月額概算を比べる
あわせて、解析対象を絞る要件も有効です。具体的には、否定的なコメントや特定キーワードを含む回答だけを優先して解析したり、定例の報告に必要なタイミングだけバッチで処理したりします。こうした運用ルールを要件化すれば、処理量そのものを抑えられます。
コストは「どのモデルを使うか」だけでなく「どれだけ処理するか」でも決まるため、両面から設計することが、トークン課金を予測できる範囲に収める鍵になります。
ハルシネーション対策と情報管理の要件
生成AIには、事実と異なる内容をもっともらしく生成してしまうハルシネーションのリスクがあります。AIが要約した「多かった意見」が実際の回答と食い違っていれば、誤った前提で意思決定をしてしまいます。
AIは下読みと一次整理を担い、最終判断は人が行うという運用ルールを決めておきます。
誤生成を減らすために、プロンプトの設計やRAG（検索拡張生成）の活用などを対策要件として明記します。AIを過信しない設計を要件に組み込むことが、誤判断の防止につながります。
また、情報管理の要件も欠かせません。アンケートの回答を外部の生成AIサービスに送る場合は、その回答データがAIの学習に使われないか、どこに保管されるかを契約や設定の段階で確認する必要があります。
無料版のAIサービスは、入力データが学習に利用される場合があります。
個人情報を含む回答を送ると、情報漏えいにつながりかねません。そのため、要件定義では、利用するAIサービスのデータ取り扱いポリシーを確認し、学習利用の有無、保管場所、保持期間を明確にしておきます。
個人情報を扱う以上は、学習に使われない法人向けプランを前提とすることを要件として固めておくべきです。
- AI要約と元コメントの対応：要約の根拠となった元のコメントを必ず参照できるようにする
- 学習利用の有無と保管場所：利用するAIサービスの取り扱いポリシーで確認する
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをもとにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。
RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較もできません。
アンケートシステムは、SaaSから個別開発まで費用幅が大きいため、RFPで比較の前提を揃えることが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
RFPには、最低限の項目として目的から体制までを盛り込みます。まず、プロジェクトの目的とKGI/KPIを書きます。そのうえで、調査の規模と対象（実施回数・回答数・同時アクセス・チャネル）、必須・優先・将来に分けた機能要件を載せます。
非機能要件（性能・セキュリティ・可用性）も入れます。AI解析を含む場合は、コスト要件とハルシネーション対策要件を加えます。
RFPでは、既存システム（CRM・基幹）との連携要件、予算とスケジュールの目安、開発・運用の体制要求まで書きます。
連携APIの開発費は1件30万〜100万円程度が目安です（出典ripla調べ）。そのため、連携の範囲はRFPで具体的に書きます。
とくに見落とされがちなのが、体制要求と運用設計です。要件不備のまま開発に進むと、再開発に100万〜500万円の追加費用が発生した事例もあります（出典ripla調べ）。
実装体制と運用設計の実態を確認できる項目をRFPに盛り込むことが、ベンダー選定で失敗を防ぐ手立てになります。
- 体制図と担当者：誰が実際に開発・運用するのかを明記させる
- 運用支援：集めた結果を活用フローに乗せる提案をさせる
見積りの妥当性を判断する観点
見積りの妥当性を判断するには、まず相場観を持つことが大切です。標準的な機能なら、SaaS型が月額数千円〜数十万円で導入でき、独自要件や密な連携を伴う個別開発は、規模に応じて初期数百万円〜1,000万円超が目安になります。
相場を見るときは、SaaS（月30万円規模）とスクラッチ（初期1,000万円規模）の5年TCOがおよそ3.5年で損益分岐することも押さえておくと役立ちます（出典ripla試算）。そのうえで、調査の継続性と要件の特殊性から、どちらが妥当かを判断します。
見積りが相場から外れている場合は、安すぎれば必要な機能の漏れを、高すぎれば過剰な要件を疑い、その理由を確認します。
「テスト・デバッグ費」や「ディレクション費」が一式でまとめられていると、後から追加要件が出たときの単価交渉が不利になり、どこにコストがかかっているかも見えにくくなります。
見積りの内訳が細かいほど、優先度の低い機能を削って予算に収める判断もしやすくなります。
運用には最低でも月5〜10時間のリソースが必要とされており（出典ripla調べ）、そのため運用工数も見積りに織り込まれているべきです。
要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得なくなり、見積りの中身が見えやすくなります。riplaは、フルスクラッチ受託と国内開発の立場から、要件の透明な整理と、見積りの内訳・ランニングコストを明示する進め方を重視しています。
要件定義の精度が、見積りの妥当性判断の精度を決めます。
- 機能ごとの工数と単価：機能ごと、工程ごとの内訳を示させる
- AI解析の月額コスト：AI解析を含む場合の、トークン課金を含む月額ランニングコスト
まとめ
アンケートシステムの要件定義・RFP・提案依頼書は、機能の一覧からではなく、調査目的とKGI/KPI、結果の活用フローを言語化するところから始めるのが鉄則です。
そのうえで、調査規模からスコープを固め、機能要件を必須・優先・将来に分類し、性能・セキュリティ・可用性の非機能要件を詰めます。
AI解析を含むなら、トークン課金のコスト要件（月10万リクエストで数千円〜13万円超：出典ripla試算）と、ハルシネーション対策・情報管理の要件を明記します。
これらをRFPに体制要求と運用設計まで含めて書けば、提案を横並びで比べられます。SaaSとスクラッチの5年TCO（損益分岐約3.5年：出典ripla試算）に照らせば、見積りの妥当性も判断できます。
目的を曖昧にしたまま機能だけを並べると、結果が活用されず形骸化します。調査で何を知り、どう意思決定に使うかを起点にした要件こそが、現場で活用されるアンケートシステムを生みます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、目的の言語化から見積りの妥当性判断まで、発注企業と協働で支援します。要件の整理、AI解析のコストとリスク設計、RFP作成も、その流れに含まれます。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。