RFP・要件定義書・提案依頼書は、音声認識システムの発注で開発会社に求める内容をまとめた文書です。目的、精度、費用、セキュリティ、運用、契約条件を具体的に書くと、提案を比べやすくなります。全体像は音声認識システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・音声認識システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
音声認識システムのRFPに盛り込む構成要素
RFPは、実現したいこと、制約、評価基準をベンダーに示す設計図です。音声認識では、一般的な項目に加えて、認識精度や利用環境といった特有の要件も漏れなく書きます。
目的・背景と業務要件の記述
RFPの冒頭では、音声認識を導入する目的と背景を明記します。現状の課題と、導入後に実現したい状態を具体的に書くことが出発点になります。
用途によって必要な機能や精度は異なるため、目的が曖昧だと、ベンダーから的外れな提案を受けるおそれがあります。
続いて業務要件では、利用者、利用環境、利用頻度を具体的に書きます。1日あたりの処理量と同時利用数に加えて、使う端末とネットワークも書きます。これらが分かると、ベンダーは規模に合った構成を提案できます。
音声の種類も提案を左右します。電話回線、対面の会話、騒音のある環境のどれを扱うかで、必要なエンジンや構成が変わります。
- コールセンター：電話回線の音声を扱う場面
- 議事録作成：対面の会話を扱う場面
- 現場入力：騒音環境でハンズフリー入力する場面
対象範囲・予算・スケジュールの明示
RFPでは、開発範囲、予算、スケジュールを明確にします。対象がエンジンだけなのか、CRM・CTI連携や運用保守まで含むのかを区切っておくと、各社の提案を同じ条件で比べられます。
- 対象範囲：開発と運用保守のどこまでを依頼するか
- 予算：小規模は数百万円、生成AIや基幹連携を含む大規模は1,000万円超の場合もある
- スケジュール：PoC（精度検証）の期間を含める
どこまでをベンダーが責任を持つかも、あわせて示します。範囲が曖昧だと、各社が置く前提が異なり、提案金額を比べられなくなります。認識の食い違いも生じます。
予算の目安を可能な範囲で示せば、ベンダーはその範囲で最適な提案を組み立てられます。
実環境での検証を省いて本番の開発に進むと、仕組みが形だけのものになるおそれがあります。そのため、RFPの段階で検証を前提にしておくことが、堅実な出発点になります。
認識精度・稼働率などの非機能要件
音声認識のRFPでは、非機能要件、とりわけ認識精度と稼働率の定義が重要で、同時に難しい項目でもあります。
認識精度も稼働率も、測定できる数値で示します。数値の明確さは、提案の質を左右するとともに、契約後のトラブル防止にもつながります。「高精度」を基準にするには、数値に置き換える必要があります。
認識精度の測定方法と目標値の定義
認識精度は、音声認識システムの核となる要件です。「精度95%」という目標に加えて、測り方と条件まで定めておく必要があります。
- 利用環境：静かな場所や騒音下など、自社の実環境が前提
- 実測方法：自社の音声サンプルを使うPoCの測定を基準にすること
コールセンター系の自治体調達の事例も、目標を考える際の参考になります。その事例では、回答率の目標を導入月50%、2ヶ月後60%、最終的に70%以上と段階的に設定しました。
初期から完璧を求めず、辞書のチューニングで精度を上げていく前提を置きます。そのうえで、初期精度と運用後の改善目標を分けて定め、改善の担当者も決めておきます。
稼働率99.9%・応答速度のSLA設定
業務に組み込む場合、稼働率（可用性）のSLAは欠かせません。止められない業務では、年間99.9%以上を基準とすることが一般的です。
自治体の調達でも、同じ目標が掲げられました。99.9%は、年間の停止時間に換算すると約8.8時間にあたります。
提案では、この稼働率を満たすインフラ構成と保守体制を示してもらいます。リアルタイム認識の場合は、応答速度もSLAに含めます。
- 通常の応答：3秒以内
- 繋ぎ言葉を挟む場合：5秒以内
応答が遅いと、ライブ字幕や応対支援には使いにくくなります。
自治体の事例では、年間7.5万件の受電の70%が流入し、解決率60%を想定して約2.5万件への対応を見込みました。受電規模の前提を示しておくと、ベンダーは現実に合った規模で提案を組み立てられます。
トークン課金とAI特有のコスト要件
生成AIを組み合わせる音声認識では、従来の開発にはなかったコスト要件をRFPに含める必要があります。
トークン課金は従量制のため、見積もりを誤ると運用費が膨らみます。そこで、要件定義の段階で費用の前提を明確にしておくと、稟議の後に予算超過を招く事態を防ぎやすくなります。
トークン課金を前提としたコスト試算要件
要約や分類に生成AIを使う場合、処理量に応じて課金されます。まず想定する月間の処理量を示し、それをもとにベンダーへ費用の試算を求めます。
試算例では、月10万リクエスト、入出力各500トークンの場合、軽量モデルは月数千円規模です。一方、高性能モデルは月十数万円規模に達するなど、モデルによって差が出ます。
試算が甘いと、運用費は急増します。たとえば、月5万円の見込みに対し、実際は月20万円を超えた事例もあります。
利用量が増えた場合に備え、次の対策を要件に含めます。
- 利用量の上限：コスト上限のアラートを設定する
- モデル選択：用途に応じた使い分け
- キャッシュ：活用により課金を抑える
利用量で費用が変わる前提をRFPで問うと、ベンダーのコスト設計力が見えてきます。
ハルシネーション対策と精度保証の要件
生成AIを要約や応対支援に使う場合、事実に基づかない回答への対策が欠かせません。存在しない決定事項や誤った情報は、業務に重大な影響を及ぼします。
- 回答範囲：RAG（検索拡張生成）で社内データに限定する
- 根拠の提示：回答の出典を明示する設計を求める
一部のサービスには、正答率を保証するプランがあります。チャットボットの領域では、95%を保証する事業者もあります。
音声認識でも、同じようにベンダーの責任範囲を明確にします。保証範囲、改善の分担、未達時の対応を定めます。精度が出ない場合に誰が何をするかをRFPで問うことは、発注側を守る手立てになります。
セキュリティ・運用に関する要件
音声データには個人情報や機微情報が含まれることが多く、セキュリティ要件は欠かせません。
導入後の運用体制も、あわせて設計します。運用体制は、システムを長く使い続けるための要件です。曖昧なままだと、情報漏えいを招いたり、運用が形だけのものになったりします。
個人情報・データ取り扱いの要件
クラウドの音声認識エンジンに音声を送信する場合は、データの扱いを厳格に定める必要があります。送信データの保管や利用の条件は、次の項目で明記します。
- 学習利用：送信データをAI学習に使わないこと
- 保存と削除：保存期間と削除ポリシー
- 暗号化：採用する暗号化方式
医療や金融のように要配慮情報を扱う場合は、外部への送信を避け、オンプレミスや閉域網を要件とするケースも多くあります。
情報漏えいの対応には、500万円以上の費用がかかることもあります。そのため、セキュリティ要件は妥協せずに定めることが、結果的に費用の抑制にもつながります。
さらに、アクセス権限、操作ログ、監査への対応も要件に含めます。特に、誰がどのデータにアクセスできるかの設計は、機微情報を扱ううえでの前提になります。
運用体制と保守・チューニングの要件
導入後は辞書を育てながら精度を改善し続ける前提で設計します。そのため、RFPに保守・調整体制を含め、担当者と頻度を決めておきます。
- 誤認識の分析：誤りの傾向を把握する
- 辞書の更新：業務に合わせた内容の見直し
- モデルの調整：精度改善に向けた調整
これらの運用作業には、最低でも月5〜10時間程度のリソースが必要とされます。
運用の要件が曖昧だと、改善が止まり、現場で使われなくなるおそれがあります。
ベンダーが伴走するのか、自社で運用するのかを決めて、役割を明確にします。要件が不足していると、後から100万〜500万円規模の再開発費が生じることもあります。
RFPと要件定義に時間をかけることは、こうした手戻りを防ぐ、費用対効果の高い投資になります。
riplaはフルスクラッチ受託の立場から、運用の伴走まで含めた要件設計を重視しています。
連携・検収・契約に関する要件
認識精度や費用、セキュリティの要件を固めたら、外部連携、検収基準、契約上の責任範囲を定めます。発注側を守る最後の要件となるため、丁寧に定義します。
曖昧なまま発注すると、追加費用や責任をめぐるトラブルにつながります。
CRM・CTIとの連携要件の具体化
CRM（顧客管理）、CTI（電話とコンピュータの統合）、既存の業務システムとつなぐことで、音声認識の価値が高まります。
RFPには、連携の内容を具体的に書きます。次の項目で整理すると、ベンダーが見積もりやすくなります。
- 対象と項目：どのシステムのどの項目を扱うか
- 方向と時点：どちら向きに、いつ連携するか
- リアルタイム表示：通話を文字起こしして応対画面に表示する
- 履歴保存：要約をCRMの対応履歴へ自動保存する
連携の定義が甘いと、ベンダーはその部分をスコープ外として見積もることがあります。すると後から別途の開発が必要だと言われ、追加費用を求められるおそれがあります。
API開発は1件あたり30万〜100万円規模になることもあります。複数の連携を組むと、費用は積み上がっていきます。
必要な連携を最初に洗い出し、RFPに書いておくことが、予算管理で欠かせません。連携範囲が曖昧なままだと、隠れたコストが生じるおそれがあります。
検収基準と責任範囲・費用内訳の定義
検収基準は、要件定義の実効性を担保するものです。PoCの精度目標、稼働率99.9%、応答3秒以内を、合格条件として契約に含めます。
自社の実環境で測る認識精度についても、合格の水準を数値で定めます。検収条件が曖昧だと、動作しただけで合格となり、本番運用で精度不足が表面化するおそれがあります。
精度が目標に届かなかった場合に、誰がどこまで改善するのかを契約前に決めておきます。追加の調整が保守契約に含まれるかも、あわせて確認します。
曖昧なままだと、稼働後に「契約外」として対応を断られるおそれがあります。費用は総額だけでなく、次の内訳で提示してもらいます。
- 初期・検証：初期構築費とPoC費用
- 利用・連携：ライセンス費と連携開発費
- 運用：保守費とトークン課金の見込み
内訳をもとに、TCO（総保有コスト）で各社を比べます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義を支援しています。支援では、連携の整理や検収基準、責任範囲の明確化を含めて、契約後のトラブルを防ぐ進め方を重視しています。
拡張性とデータ移行性の要件
RFPで見落とされやすいのが、将来の拡張性です。一部門や一拠点から始めて、効果に応じて範囲や処理量を広げていくことがあります。
拡張時には、次の点にどう対応するかを確認します。
- 利用規模：利用部門や同時処理数の増加
- 機能：導入後の機能追加
初期構成だけで発注すると、拡大時に大規模な改修と想定外の費用が生じるおそれがあります。早い段階で確かめておけば、数年後に作り直す事態を避けられます。
データの所有権と、エクスポートの可否も明記します。音声、辞書、チューニング結果が独自形式で囲い込まれると、乗り換えの際に移せないおそれがあります。文字起こしの履歴についても、同じことが起こりえます。
標準形式での出力と、辞書や調整結果の引き継ぎを契約条件に含めておけば、ベンダーロックインを避け、将来の選択肢を残せます。
拡張と移行を含めて、ライフサイクル全体で要件を定めることが、総コストの抑制につながります。
まとめ
RFPでは、目的と範囲を起点に、要件を精度から運用まで定義します。実環境での測定方法と改善の担当を明確にしておくと、契約後のトラブルを避けやすくなります。
機能の一覧だけでなく、測定できる数値と責任の所在を記すことが大切です。そのうえで、PoC、トークン課金の抑制策、運用体制まで盛り込み、比べられる提案を受け取りましょう。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、PoCを起点にした要件整理から運用の伴走まで支援しています。全体像は音声認識システムの完全ガイドをご覧ください。
▼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を創業。