TiDBのシステム開発の発注・外注は、現状把握とPoCから始め、同じRFPで提案を比べてから契約し、本開発、移行、運用引継ぎへと進みます。この順に進めると、業務結果と切替時間を確かめてから導入できます。全体像は、TiDBのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・TiDBのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TiDBのシステム発注・外注で決める範囲
最初に決めるのは、TiDB環境だけを依頼するのか、業務アプリやデータ移行、運用まで含めるのかです。「TiDBを使ったシステム一式」のように範囲をぼかして頼むと、会社ごとに作業範囲が変わり、金額や納品物を比べられなくなります。
発注範囲の分け方（データベース・アプリ・運用）
アプリとDBと運用のどこまでを発注に含めるかで、見積もりも納品物も変わります。そのため、見積もりと納品物をそろえるには、発注範囲を次の4つの区分で作業別に整理しておきます。
- 要件と開発：要件定義とアプリケーション開発
- データベース：TiDBクラスタまたはTiDB Cloudの設計
- 移行と試験：既存DBからの移行、性能・障害試験、本番切替
- 運用：保守と監視
クラウド基盤は自社で用意し、DB設計と移行だけを専門会社へ委託する方法もあります。ただし、受発注や在庫などのアプリも新設するなら、業務要件を担う開発会社とDB専門会社の役割分担を決めておく必要があります。
納品物は作業名とセットで決めます。要件定義書と基本設計書、ER図、テーブル定義書を挙げ、そのうえで性能試験報告書、移行手順書、切戻し手順書を加えます。さらに、監視設計、IaCやソースコード、運用マニュアルも対象に含めます。
それぞれについて、作成者と検収時に確認する内容まで合意します。
発注前に比べるTiDB Cloudと自社運用
運用まで含めた依頼範囲は、TiDB Cloudを使うか自社で運用するかで変わります。
- TiDB Cloud：クラスタ構築や一部の運用負担を抑えやすい
- 自社運用：基盤やノード構成などを細かく設計できる
自社で運用するなら、クラウドやオンプレミスのネットワーク、データ配置、バージョンアップの設計が必要です。さらに、障害対応やバックアップ、監視を担う体制も要ります。
見積もりは、初期構築費と月額費用に分けてもらいます。クラウド利用料やバックアップ、通信の費用を確かめ、監視、サポート、夜間対応が含まれるかも見ます。
TiDB Cloud Starterは、2025年8月12日に旧Serverlessから名称変更されました。最初の5インスタンスには、各インスタンス5GiBの行ストレージ、5GiBの列ストレージ、月5,000万RUの無料枠が案内されています（出典: TiDB公式「TiDB Cloud Starter FAQs」、2026年確認）。
無料枠を超えると従量課金が発生し、無料プランには性能の制限もあります。そのため、本番で使う条件をPoCと同じと考えず、別に確認する必要があります。
TiDBのシステム開発を発注・外注する進め方
発注は段階に区切るとリスクを抑えやすくなります。流れは、現状把握とPoC、提案比較、契約の順に進み、そのあと本開発、移行、運用引継ぎへ移ります。
特に、既存MySQLから移行する場合は、SQLの動作に加えて、業務結果と切替時間を確かめてから本番移行を決めます。
現状把握とPoCによる採用理由の数値化
PoCの条件を決めるには、現行システムの負荷と障害状況を把握しておく必要があります。そのうえで、実業務で重要な処理を選び、代表ワークロードとしてPoCで検証します。
- 負荷：データ量、1日あたりの読み書き件数、ピーク時の同時接続数
- 性能：最も重いSQL、レスポンスタイム、データ増加量
- 業務処理：受発注なら注文登録と在庫引当、会員ならログインと検索、決済なら確定と履歴参照
PoCでは、代表SQLの互換性や実行計画、同時実行の状況、書き込みと集計の混在を測ります。加えて、バックアップ・リストアやフェイルオーバーの動作、監視、費用の見込みも確かめます。
合格条件は、ピーク時のP95応答時間や1時間あたりの処理件数、障害からの復旧時間、月額予算の上限などで決めます。「速くなった気がする」といった表現では、契約や検収で使えません。
同じRFPによる提案と見積もりの比較
PoCの結果と要件をRFPにまとめ、複数の委託先へ同じ資料を渡します。そのうえで、回答期限や質問方法もそろえると、会社ごとの提案力を比べられます。
- 回答条件：回答期限、提案書の形式、質問方法
- 見積条件：内訳と想定スケジュール
- 対応範囲：業務理解、アプリ開発、移行、クラウド、セキュリティ、運用
提案の安さだけで決めると、移行リハーサルや性能試験、夜間切替、監視設計が後から追加されることがあります。そのため、前提条件や除外項目、追加費用の条件も比較表にします。
価格だけでなく、要件への適合度や担当者の経験を評価します。さらに、リスクの説明や納品物、保守体制も見ます。
移行・切替・運用引継ぎの別工程管理
本番移行では、全量移行と増分同期のどちらを使うかを、データ量、書き込みを止められる時間、ネットワーク条件に応じて決めます。そのうえで、整合性確認とリハーサル、切替、ロールバックを順に設計します。
- 全量移行：TiDB Lightningで全量データを高速インポート
- 増分同期：TiDB Data Migration（DM）でMySQL互換DBのbinlogを複製
TiDB公式資料では、1TiB未満の小規模データであれば、DMを使う方法も候補になります。一方で、より大きなデータや短い移行時間が必要な場合は、LightningとDMを組み合わせる考え方が示されています（出典: TiDB公式「Data Migration Overview」、2026年確認）。
方式は一律の基準で決まるわけではないため、実データの件数やハッシュ、業務上の集計結果を照合します。さらに、切替後に問題が起きた場合の復旧手順も確かめます。
TiDBのシステム発注で選べる発注形態と契約形態
発注形態は、要件の確実性や社内技術者の有無、納期、運用責任の所在に合わせて選びます。選択肢には、開発会社への一括委託、専門会社の組み合わせ、自社チームへの技術支援があります。また、契約形態は価格だけで決めないことが大切です。
一括請負の特徴と責任の所在
要件と完成形が固まっていて、納期と予算を管理したい場合は、一社に請負で委託できます。
- 委託範囲：要件定義から開発、移行まで
- 利点：窓口を一本化し、アプリとDBの調整を委託先の責任で進めやすい
TiDBの採用可否や性能目標が決まらないまま全工程を固定価格にすると、条件が変わったときに追加請求や品質低下につながることがあります。
そこで、PoCと要件定義は準委任か小さな請負で行い、結果を踏まえて本開発の請負契約へ移る二段階方式も検討できます。
準委任の特徴と、検証・専門支援への対応
作業量や検証結果が変わりやすい業務では、準委任によって専門家の稼働を確保できます。
- 対象業務：要件整理、PoC、DB設計レビュー
- 専門支援：移行支援、性能チューニング
月単位か工程単位で、稼働時間や担当者、報告内容を定めます。そのうえで、優先順位は自社が決めます。
納品物の完成責任と作業支援の責任は分けて定め、性能目標の達成か、試験と報告書の納品か、切替への立会い範囲かを、契約書と個別発注書に記載します。
複数社体制の役割分担と情報共有の取り決め
複数社を組み合わせる場合は、各社の担当範囲と、どこまでを誰が受け持つかを明らかにします。
- 製品・DB：PingCAPやTiDB Cloudの製品窓口、DB移行・運用会社
- システム：業務アプリ開発会社、クラウドSI
障害時の連絡先や、SQL性能問題の修正担当、クラウド料金の設定と監視の担当は、曖昧になりやすいので注意します。
RACIのような役割表で、要件定義とアプリ、DB、ネットワークの責任者を決めます。そのうえで、セキュリティと移行、監視と夜間対応も役割表の対象にします。
再委託や知的財産権、ソースコードの利用権、秘密情報については、初期契約で確認しておきます。加えて、脆弱性対応と契約終了時のデータ返却も、初期契約の段階で確かめます。
RFPと要件整理に入れるべきTiDB特有の項目
RFPは、「TiDBを導入したい」という希望を伝える資料というより、達成したい業務成果と制約条件を候補会社へ伝える資料です。
現行環境と対象業務、性能、可用性のように項目を分けて記載すると、具体的な提案を得られます。セキュリティや移行、運用は、項目ごとに分けて書きます。予算と納期は、別に示します。
実測値で書く業務要件と性能要件
提案と検収の条件を具体的にするには、業務と性能を実測値で書きます。
- 業務：利用者、権限、画面、外部連携、登録・更新・取消の流れ
- 処理：締め処理、帳票、監査に必要な履歴
- 性能：通常時・ピーク時の接続数、読み書き件数、P95・P99応答時間
- 規模：集計完了時間、データ増加量
「大量アクセスに対応」のような表現は、見積もりにも検収にも使いにくいものです。TiDBでは分散を前提に、主キーやインデックス、トランザクションを設計します。接続プールとリトライ、タイムアウトの設定は、提案の段階で示してもらいます。
TiFlashを使う場合は、分析用レプリカに置くテーブル、更新後に許容する反映遅延、分析クエリと業務処理のリソース配分を、RFPに含めます。
セキュリティとネットワークの制約の先行提示
取り扱う情報に応じて、保護と復旧の条件をRFPに記載しておきます。接続条件は、後から変えると設計と見積もりに影響するため、先に示します。
- 対象情報：個人情報、決済情報、取引情報
- 保護・復旧：保管リージョン、TLS、IAM、管理者権限、監査ログ、バックアップ暗号化、脆弱性対応、RPO・RTO
- 接続：閉域接続、固定IP、VPC、Private Link相当、プロキシ、海外リージョンの可否
個人情報保護委員会のガイドラインは、アクセス制御や識別・認証、不正アクセス防止、漏えい防止などの安全管理措置を示しています（出典: 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」令和7年3月24日施行版）。
クラウドプランの監査ログや権限管理、バックアップ、サポートは、最新仕様で確認するよう依頼します。可用性の条件も、最新仕様で確かめてもらいます。
停止時間と整合性を中心にした移行要件
停止時間と移行の見積もりに必要な条件は、RFPにまとめて示します。
- 現行DB：データ量、テーブル数、更新頻度、binlog保持、文字コード
- 互換性：SQLやストアドプロシージャ、主キー、外部連携先
- 対象外データ：古いデータの保管、削除、匿名化
- 切替条件：許容停止時間、並行稼働、日時、ロールバック判断者
- 検証：リハーサル回数、整合性の確認方法
TiDB公式の移行ツールには、TiDB LightningとDM、BR、sync-diff-inspectorがあります。順に、全量移行と増分同期、バックアップ・リストア、整合性確認に使います。採用ツールと理由は、委託先に提案してもらいます（出典: TiDB公式「Download TiDB Tools」、2026年確認）。
TiDBのシステム発注・外注の費用相場と内訳
費用は、TiDB Cloudやサーバー代だけでなく、アプリ開発、移行、性能検証を含む総額で見ます。クラウドネットワークやセキュリティ、監視、保守の費用も、同じ総額に含めます。
TiDBに特化した日本向けの公開統計は限られています。そこで、一般業務システムの相場にTiDB特有の工程を加えた推定レンジを示します。
案件規模ごとの費用の幅
案件の規模や条件を置いた推定レンジとして、次の区分ごとに比べます。
- 技術検証・PoC：100万〜300万円程度
- 小規模新規開発：簡単な業務アプリを含み300万〜1,000万円程度
- 中規模：受発注・会員・予約システムで1,000万〜3,000万円程度
- 既存DB移行：MySQLからの本番移行を含み1,500万〜5,000万円程度
- 大規模：基幹系、高可用性、複数連携を含み3,000万円〜1億円超の可能性
レンジは、データ量や同時接続数、停止許容時間で変わります。アプリ改修の範囲やSLA、24時間監視の有無でも変わります。そのため、候補会社には前提の人月や作業項目、除外項目、クラウド利用料を分けて提示してもらいます。
工程別とランニング費用に分けた見積もり
見積もりは、初期費用と継続費用に分けてもらい、工程ごとの配分も確かめます。
- 初期費用：要件定義、基本・詳細設計、アプリ開発、TiDB設計、テスト、移行、切替、教育
- 継続費用：TiDB Cloudまたはサーバー、ストレージ、バックアップ、転送、監視、ログ保管、サポート、保守改修、夜間対応
一般業務システムの初期費用は、要件定義が10〜15%、設計が25〜35%、開発・単体テストが30〜40%の配分が目安です。結合・総合テストは15〜20%、移行・導入は5〜10%程度が目安になります。
TiDBでは、移行設計や分散SQL性能試験、障害・復旧試験を独立した項目として確かめます。
保守費は初期開発費の年15〜20%が目安で、クラウド利用料や24時間対応費は別に見ます。たとえば初期開発費が3,000万円なら、年450万〜600万円程度です。ただし、契約範囲と条件によっては再見積もりが必要です。
同じ負荷条件で比べるTiDB Cloudの料金
プランごとに課金基準が異なるため、負荷や保存量をそろえて比べます。
- Starter：消費したリソース
- Essential：プロビジョニングしたRCU
- Premium：実際のRCU消費量とストレージなど
この課金基準は、公式の説明によるものです（出典: TiDB公式「TiDB Cloud Billing」、2026年確認）。そのうえで、読取と書込、SQL CPUや通信、保存量を同じ条件で比べます。バックアップと分析用レプリカも、負荷条件を合わせて見積もります。
2026年6月9日以降に新規作成するTiDB Cloud Essentialは、単一アベイラビリティゾーンに配置されます。リージョン内高可用性をサポートしない変更が案内されています（出典: TiDB Cloud公式「Release Notes in 2026」、2026年確認）。
高可用性が必要な発注では、プラン名だけで決めず、契約時点のリージョンやSLA、障害時の挙動を提案書で確認します。
TiDBのシステム委託先選定と見積比較のポイント
資格やパートナー表記だけで判断せず、TiDBの知識と業務理解の両方を確かめます。分散DB設計やMySQL移行、アプリ改修を実行できるかを見ます。さらに、性能試験やセキュリティ、監視、障害対応についても、担当できるかを確かめます。
担当範囲と成果から見る実績
TiDBの導入実績は、会社名だけでなく、対象の案件と担当した内容を具体的に確かめます。
- 案件条件：業務、データ量、ピーク負荷
- 構成・移行：MySQL移行か新規開発か、TiDB Cloudか自社運用か
- 実施範囲：担当工程と運用開始後の支援期間
可能であれば、匿名化した構成図や、移行前後の性能指標、障害試験の内容を提示してもらいます。
開発元や公式パートナーであることは、候補に入れる理由にはなります。ただし、業務理解や希望する運用の実現を保証するものではありません。
担当エンジニアが、提案だけでなく設計や移行、運用にも関わるか、再委託の工程があるかを確かめます。
見積書の前提条件と抜け漏れの確認
見積もりの前提をそろえ、作業の抜けと不要な構成を確かめます。
- 工程：要件定義、設計、開発、テスト、移行
- 運用：クラウド設定、監視、教育、保守
- 前提：工数・単価、除外項目、追加費用の条件
DB構築費が安くても、アプリ改修やSQLチューニング、移行リハーサルが除外になっていれば、追加費用が生じる可能性があります。同じ見積書で、切戻しや運用設計が含まれているかも確かめます。
また、不要な高可用性や過剰なノード数が含まれる場合もあります。そのため、同じRFPとデータ量、ピーク負荷を前提に見積もりを依頼します。SLAや納期の条件も、同じ形でそろえます。
初期費用と5年間の運用費は分けて比べます。そのうえで、要件適合度や費用、納期、技術提案に重みを付けて評価します。移行リスクや保守体制、担当者、契約条件も、評価の対象に含めます。
保守・SLA・障害対応の発注条件
本番後に必要な作業と、問い合わせや障害時の対応条件は、契約に定めます。
- 運用作業：遅いSQLの調査、容量増加、バックアップ確認、更新、脆弱性対応、一次切り分け
- 対応条件：時間帯、一次応答時間、復旧目標、問い合わせ回数、軽微な改修範囲
自社にDBAがいない場合は、引継ぎ後の体制を特に重視します。そのうえで、監視アラートの受信者や、PingCAPやクラウド事業者への連絡条件、障害後の報告書を確かめます。
運用手順書に加えて、バックアップ復元やフェイルオーバー、切替訓練を受入条件に含めると、契約後の認識差を減らせます。
TiDBのシステム発注・外注に関するよくある質問
発注前に出やすい疑問を、費用や移行、体制、契約の面から、実務上の判断材料とともに確かめます。
TiDBのシステム開発はどの会社に依頼すればよいですか？
業務アプリも必要なら、業務要件を整理できる開発会社を主契約先にし、TiDBに詳しい会社をDB設計・移行の専門パートナーにする方法があります。
既存MySQLの移行や性能問題が中心なら、DB移行・DBA支援の実績を重視します。会社名に加えて、担当範囲や実績、運用体制、納品物を比べます。
TiDB Cloud Starterの無料枠だけで本番運用できますか？
本番で使えるかは、データ量や負荷、可用性に加えて、監査とサポートの要件を含めて判断します。
公式情報では、無料枠を超えると接続制限やスロットリングが発生する条件があるとされています。無料プランには、クエリあたり256MiBのメモリ制限も案内されています（出典: TiDB公式「TiDB Cloud Starter FAQs」、2026年確認）。
本番では、予測負荷に基づく有料枠と上限額を見積もり、試験で確かめます。
MySQLからTiDBへ移行するとき、システムを長時間停止しますか？
停止時間は、データ量や更新頻度、移行方式によって変わります。アプリの切替方法によっても変わります。
全量を一度に移す方法のほか、Lightningで初期データを投入し、DMで増分を同期して短時間で切り替える方法も検討できます。
実データでリハーサルを行い、同期遅延や整合性、切戻し時間を確かめてから、本番日程を決めます。
TiDBのシステム開発の見積もりで特に注意する項目は何ですか？
構築費に加えて、必要な工程と継続費用が含まれるかを確認します。
- 開発・試験：要件定義、アプリ改修、SQL・インデックス設計、性能試験
- 移行・運用：移行リハーサル、バックアップ復元、監視、保守
- 費用・条件：クラウド利用料、データ量、ピーク負荷、可用性、対応時間、除外項目、追加条件
条件を同じ様式でそろえて比べます。価格差が大きいときは、安い会社にすぐ決めず、含まれていない作業を尋ねます。
まとめ
発注範囲には、業務要件やアプリ、移行、性能が含まれます。セキュリティやクラウド費用、運用体制も、発注範囲の中で整理します。現状の負荷やデータを把握し、PoCで採用理由を数値にしておくと、過剰設計や移行事故を避ける出発点になります。
発注前に確認する四つのポイント
発注前に、契約とRFP、費用、委託先の条件を一通り照合します。
- 発注形態：一括請負、準委任、複数社体制のいずれか
- RFP：業務・性能目標、運用形態、移行停止時間、納品物、保守条件の記載
- 費用：初期費用、クラウド、保守、監視、障害対応を含む5年間の総額で比べる
- 委託先：担当範囲、移行実績、PoC計画、運用体制、リスク説明力で選ぶ
相談前にそろえる現状資料
候補会社へ相談する前に、共有する現状資料を次のとおりそろえておきます。
- 現行DB：種類とバージョン、データ量
- 負荷と移行：ピークアクセス、代表SQL、停止可能時間
- 環境と情報：希望クラウド、個人情報の有無
- スケジュール：希望納期
不明な項目は分からないまま示せば、調査やPoCを含む提案を受けられます。TiDBの開発では、将来の負荷と運用責任まで成功条件を共有できる相手を選ぶことが大切です。
▼全体ガイドの記事
・TiDBのシステム開発の完全ガイド
▼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を創業。