ビデオ通話アプリの発注では、RFP（提案依頼書）と要件定義書の質が成否を左右します。特に、非機能要件を検収条件として数値で書けるかが鍵です。
配信方式や負荷テスト、契約面まで発注側の視点で解説します。全体像をまだ把握していない方は、まずビデオ通話アプリ開発の完全ガイドから読むと進めやすいでしょう。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
非機能要件のSLA・検収条件への落とし込み
ビデオ通話は、映像と音声をリアルタイムにやり取りします。そのため、何人が同時に使うのか、遅延は何ミリ秒以下に抑えるのか、パケットロスや障害時にどう振る舞うのかといった非機能要件が、品質を決めます。RFPでは、機能一覧よりも先に、この非機能要件を固めておく必要があります。
「映像と音声でやり取りできる」という機能要件は、どのベンダーでも実現できます。一方で、「劣悪な回線でも途切れない」「大人数でも遅延が小さい」という品質は、設計次第で差が出ます。特に、この品質を曖昧なまま発注すると、検収で揉める最大の原因になります。
同時接続数・遅延・エラー率の数値定義
非機能要件の核は、品質を数値で定義することです。想定する最大同時接続数（例：1ルーム最大50人、サービス全体で同時1万セッション）や、許容する遅延（例：双方向通話で300ミリ秒以下）を、RFPに明記します。ネットワーク劣化時の耐性（例：パケットロス30%でも通話継続）や、エラー率（例：接続失敗率1%未満）も、RFPの条件として書きます。
実在するサービスの実績を参考にすると、数値は現実的になります。たとえばstand.fmは、Agoraへの切り替えで「最大70%のパケットロスに耐え遅延2秒以下」を実現しており、こうした一次データが参考になります（出典：Agora導入事例）。
これらの数値は、単なる希望ではなく「検収条件」として書くことで意味を持ちます。たとえば「同時接続50人・遅延300ms以下・エラー率1%未満を負荷テストで実証できれば検収合格」と定義すれば、ベンダーは何を達成すべきかが明確になります。発注側も、客観的に合否を判定できます。
曖昧な「快適に使えること」では、双方の解釈がずれて紛争になります。そのため、品質を検収条件へ言い換える作業が、要件定義の最大の山場になります。
- 検収条件の書き方：希望の表現を、負荷テストで合否を判定できる条件に置き換える
- 参考にする水準：実在するサービスの実績を、数値を決める際の目安にする
可用性と障害時の挙動の要件化
非機能要件には、可用性（どれだけ止まらないか）と障害時の挙動も含めます。配信基盤を一つに頼ると、その基盤に障害が起きた時点でサービス全体が止まってしまいます。
可用性は後から足すのが難しいため、RFPの段階で明記しておくことが欠かせません。そのうえで、通話中に通信が切れたときの再接続の挙動、ピーク時のスパイクへの耐性、監視とアラートの仕組みも要件に含めます。
これらは平常時には見えませんが、トラブル発生時にサービスの信頼性を分けます。そのため、要件定義では「正常系」だけでなく「異常系」をどこまで定義できるかが、ベンダーの力量を引き出す鍵になります。
ビデオ通話に必要な機能そのものの整理は、関連記事『ビデオ通話アプリの必要機能や標準機能の一覧について』もあわせてご覧ください。
- 配信基盤の切り替え：主要な配信基盤に障害が起きたときの、別系統への切り替えを求める
- 異常系の範囲：通話中の再接続、ピーク時のスパイク、監視とアラートまで要件に含める
DeNAのPocochaは、Amazon IVSへの単一依存を避けてTencent CSSなども併用しています。Strategyパターンで配信基盤を動的に選択している事例です（出典：DeNA技術事例）。
配信方式・負荷テスト・録画の要件化
非機能要件を定めたら、それを技術的にどう実現するかの方針も、RFPに織り込みます。配信方式、負荷テストの条件、録画やデータの取り扱いは、見積もりの金額を動かす項目です。そのため、各社の提案を公平に比べるためにも、RFPで明示しておくことが欠かせません。
RFPで問う配信方式と自前・外部SDKの選定
配信方式をどこまで指定するかは、RFPの設計思想にかかわります。発注側は最大同時接続人数と品質要件を明確に示します。
方式を指定しすぎると、ベンダーの知見を活かせません。一方で、丸投げすると各社の提案を比べられなくなります。
自前のWebRTC構築と外部SDK（Agora等）では、初期費用とランニングコストの構造が大きく異なります。SDKはMAUや接続数に応じた月額が継続的にかかるため、たとえばチャットSDKでは、10K MAUでTencent RTC Chatが月額約399ドルです。
また、Sendbirdは月額約749ドルといった水準です。月額の数字だけで比べると、目先の安さに惑わされやすくなります。
手法ごとのメリット・デメリットは、関連記事『ビデオ通話アプリの必要機能や標準機能の一覧について』でも触れています。
- 方式の指定：数値の要件は発注側が示し、P2P、SFU、MCUといった方式は提案に任せる
- 費用の比べ方：自前構築と外部SDKを、初期費用とランニングを分けた3年間のTCOで比べる
RFPでは、配信方式と自前構築か外部SDKかの選定について、根拠とともに提案してもらう形が理想です。
負荷テスト要件と録画データの保管要件
ビデオ通話アプリで検収条件を客観的に確かめる手段は、負荷テストです。負荷テストでは、遅延・パケットロス・エラー率が目標値を満たすことを実証します。
リリース初日にアクセスが集中してデータベースがデッドロックを起こし、炎上するといった失敗は、負荷テストを要件化していなかったケースで起きがちです。テストのシナリオまで定義しておけば、リリース後の事故を未然に防げます。
録画機能を持つ場合は、録画データの保管要件も見落とせません。録画は個人情報を含む映像と音声であるため、保存場所やアクセス権などを定めておく必要があります。録画はストレージとサーバー費用が利用量に比例して膨らむため、保存期間を区切るだけでもランニングコストを抑えられます。
データの取り扱いを曖昧にしたまま運用を始めると、後からプライバシーやコストの問題が噴出します。だからこそ、要件定義の段階で、データのライフサイクル全体を設計しておくことが大切です。
- テストの条件：想定ピークの同時接続数、対象人数、合否の目標値をRFPに書く
- 録画データの保管：保存期間、暗号化、削除ポリシーを要件として定義する
契約面の要件（著作権・所有権・ロックイン回避）
要件には技術仕様だけでなく、契約面の取り決めも含まれます。後々のトラブルで深刻になりやすいのは、むしろ契約面の不備です。ソースコードの権利、インフラの所有権、ベンダーへの依存度は、RFPと契約で明確に定めておかないと、運用フェーズで自社の自由を損ないます。
ソースコード著作権とインフラ所有権の担保
開発を委託する際、何も取り決めなければ、ソースコードの著作権はベンダー側に残ることがあります。将来、別のベンダーに乗り換えたり、自社で改修したりするときに、コードの権利が手元になければ身動きが取れません。
また、クラウドのアカウントやドメイン、配信基盤の契約名義といったインフラは、ベンダー名義のままだと、契約終了時にデータやサーバーの移管が進みにくくなります。最悪の場合は、サービスを人質に取られたような状態になります。
AWSなどのクラウドアカウントも、同じ考え方で扱うと安全です。これらの取り決めは、開発が始まってからでは交渉が難しくなります。だからこそ、RFPの段階で前提条件として提示しておくことが欠かせません。
- 著作権の帰属：成果物のソースコードは発注者に帰属すると、RFPと契約に明記する
- インフラの名義：クラウドアカウントは自社で開設し、ベンダーには作業権限だけを付与する
ロックイン回避・準委任と請負の使い分け
ベンダーロックイン（特定の業者に依存して抜けられない状態）を避けるには、ドキュメントの整備とナレッジトランスファー（知識移転）を要件に含めることが有効です。こうした取り決めがあれば、将来の体制変更にも耐えられます。さらに、配信基盤を抽象化して付け替え可能にする設計も、技術的なロックイン回避の有力な手段です。
契約形態の選択も、要件定義の一部です。仕様が固まりきらない段階と、成果物の責任を明確にしたい段階とでは、適した契約が異なります。
ただし請負では、ベンダーが成果の責任を負う分のリスクバッファとして、準委任比1.3〜1.5倍の係数が見積もりに乗るのが一般的です。そのため、どのフェーズをどの契約で進めるかをRFPで示しておくと、見積もりの根拠が明確になります。
契約や見積もりの判断基準は、関連記事『ビデオ通話アプリ開発/導入のメリット/デメリット/効果と判断基準について』もあわせてご覧ください。
- 納品物：設計書、運用手順書、構成図を必須にし、開発の節目で引き継ぎの場を設ける
- 契約形態：探索的な段階は準委任、仕様が確定した段階は請負と、フェーズごとに分ける
まとめ
ビデオ通話アプリのRFPと要件定義を振り返ると、核心は性能要件を検収条件に書き換えることにあります。同時接続数や遅延を数値で定め、「満たせば検収合格」というSLAに落とし込みます。特に、主観的な「快適さ」を、誰が見ても同じ判定ができる定量条件にすることが大切です。
可用性や障害時のフェイルオーバーといった異常系も、正常系と同じ精度で要件にします。想定ピークでの負荷テストも検収条件に含めます。また、配信方式や録画データの保管を明示しておくことが、ベンダーに意図を正確に伝える土台になります。
著作権の帰属やインフラ所有権、ロックイン回避を契約で担保しておけば、運用フェーズでも自社の自由を守れます。請負契約には準委任比1.3〜1.5倍の係数がかかる点も踏まえ、フェーズに応じた契約形態を選びましょう。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、性能要件を検収条件へ落とし込む要件定義と、発注側の権利を守る契約設計で、ビデオ通話アプリ開発を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。