TiDBのシステム開発の発注/外注/依頼/委託方法について

TiDBのシステムを発注・外注するなら、データベースの構築だけでなく、業務要件、MySQLからの移行、性能試験、クラウド料金、障害対応までを一つの発注条件として整理することが重要です。

TiDBはMySQL互換の分散SQLデータベースですが、導入すれば自動的に性能が上がる製品ではありません。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法まで、TiDBのシステム開発を外部へ依頼する際に確認したい実務上のポイントを解説します。

▼全体ガイドの記事
・TiDBのシステム開発の完全ガイド

TiDBのシステムを発注・外注するとき、何を決めますか？

TiDBのシステムを外注するときに最初に決めることは、TiDBの環境だけを依頼するのか、業務アプリケーションやデータ移行、運用まで含めて依頼するのかです。依頼範囲が曖昧なまま「TiDBを使ったシステム一式」と伝えると、会社ごとに見積もりに含める作業が変わり、金額と納品物を比較できなくなります。

発注範囲は、少なくとも「要件定義」「アプリケーション開発」「TiDBクラスタまたはTiDB Cloudの設計」「既存データベースからの移行」「性能・障害試験」「本番切替」「保守・監視」に分けて記載します。たとえば、クラウド基盤は自社で用意し、DB設計と移行だけを専門会社へ委託する方法もあります。一方、受発注や在庫などの業務アプリまで新しく作るなら、DB会社だけでは業務要件を取り切れないため、業務システムの開発会社とDB専門会社の役割分担が必要です。

納品物も作業名とセットで定義します。要件定義書、基本設計書、ER図、テーブル定義書、性能試験報告書、移行手順書、切戻し手順書、監視設計、IaCやソースコード、運用マニュアルなどを列挙し、誰が作成し、検収時に何を確認するかまで合意します。

TiDB Cloudはマネージドサービスとして、クラスタの構築や一部の運用負担を抑えやすい選択肢です。自社運用のTiDBは、クラウドやオンプレミスのネットワーク、ノード構成、データ配置、バージョンアップを細かく設計できる反面、障害対応やバックアップ、監視を担う体制が必要です。見積もりでは、初期構築費だけでなく、月額のクラウド利用料、バックアップ、通信、監視、サポート、夜間対応を分けて示してもらいます。

TiDB Cloud Starterは2025年8月12日に旧Serverlessから名称変更され、最初の5インスタンスには各インスタンス5GiBの行ストレージ、5GiBの列ストレージ、月5,000万RUの無料枠が案内されています（出典: TiDB公式「TiDB Cloud Starter FAQs」、2026年確認）。ただし、無料枠を超えた場合の従量課金や、無料プランの性能制限があるため、本番利用の条件をPoCと同じだと考えないことが大切です。

TiDBのシステム開発を発注・外注する進め方

発注は、技術選定からいきなり本開発へ進めるのではなく、現状把握、PoC、提案比較、契約、本開発、移行、運用引継ぎの順に区切るとリスクを抑えやすくなります。特に既存MySQLからの移行では、SQLが動くかだけでなく、業務結果と切替時間を確認してから本番を決めます。

まず、現行システムのデータ量、1日あたりの読み書き件数、ピーク時の同時接続数、最も重いSQL、レスポンスタイム、障害発生状況、データ増加量を確認します。受発注なら注文登録と在庫引当、会員システムならログインと検索、決済なら決済確定と履歴参照など、実際の業務で重要な処理を代表ワークロードとして選びます。

PoCでは、代表SQLの互換性、実行計画、同時実行、書き込みと集計の混在、バックアップ・リストア、フェイルオーバー、監視、費用見込みを測定します。合格条件は「速くなった気がする」ではなく、たとえばピーク時のP95応答時間、1時間あたりの処理件数、障害から復旧するまでの時間、月額予算の上限など、契約と検収に使える数値へ置き換えます。

PoCの結果と要件をRFPにまとめ、複数の委託先へ同じ資料を渡します。回答期限、提案書の形式、見積もりの内訳、想定スケジュール、質問方法をそろえると、会社ごとの提案力を比較しやすくなります。候補会社を選ぶときは、TiDBを知っているかだけでなく、業務理解、アプリ開発、移行、クラウド、セキュリティ、運用をどこまで自社で担えるかを確認します。

提案の安さだけで決めると、後から移行リハーサル、性能試験、夜間切替、監視設計が追加されることがあります。見積もりの前提条件、除外項目、追加費用が発生する条件を比較表にし、価格以外に、要件適合度、担当者の経験、リスクの説明、納品物、保守体制を評価します。

本番移行では、全量移行、増分同期、データ整合性確認、リハーサル、切替、ロールバックを順番に設計します。TiDB公式ドキュメントでは、TiDB Lightningを全量データの高速インポートに使い、TiDB Data Migration（DM）でMySQL互換データベースのbinlogを複製して停止時間を抑える方式が案内されています（出典: TiDB公式「Data Migration Overview」、2026年確認）。データ量、書き込みを止められる時間、ネットワーク条件に応じて方式を選びます。

公式資料では、1TiB未満の小規模データではDMも選択肢となり、より大きなデータや短い移行時間が求められる場合はLightningとDMを組み合わせる考え方が説明されています。ただし、これは案件の一律基準ではありません。実データで件数、ハッシュ、業務上の集計結果を照合し、切替後に問題があった場合の復旧手順まで委託先と確認します。

TiDBのシステム発注で選べる発注形態と契約形態

TiDBのシステム開発では、開発会社へ一括で委託する方法、専門会社を組み合わせる方法、自社チームへ技術支援を受ける方法があります。要件の確実性、社内の技術者、納期、運用責任の所在によって適した形が変わるため、契約形態を価格だけで決めないことが大切です。

要件と完成形がある程度固まっており、納期と予算を管理したい場合は、要件定義から開発、移行までを一社へ請負で委託する方法が候補になります。窓口が一本化され、アプリとデータベースの調整を委託先の責任で進めやすい点が利点です。

ただし、TiDBの採用可否や性能目標まで未確定の段階で全工程を固定価格にすると、前提条件の変更が追加請求や品質低下につながることがあります。PoCと要件定義を準委任または小さな請負で先に実施し、結果を踏まえて本開発の請負契約へ移る二段階方式も検討できます。

要件整理、PoC、DB設計レビュー、移行支援、性能チューニングのように、作業量や検証結果が事前に変動しやすい業務では、準委任契約で専門家の稼働を確保する方法があります。月単位や工程単位で稼働時間、担当者、報告内容を定め、自社が優先順位を決めながら進められます。

準委任で注意したいのは、成果物の完成責任と作業支援の責任を混同しないことです。性能目標を達成するのか、性能試験を実施して報告書を納品するのか、切替を成功させるためにどこまで立ち会うのかを、契約書と個別発注書に具体的に書きます。

PingCAPやTiDB Cloudの製品窓口、業務アプリ開発会社、クラウドSI、DB移行・運用の専門会社を組み合わせると、各社の強みを活かせます。その一方で、障害時にどの会社へ連絡するのか、SQLの性能問題を誰が直すのか、クラウド料金の設定と監視を誰が担うのかが曖昧になりやすい構成です。

RACIのような役割表を作り、要件定義、アプリ、DB、ネットワーク、セキュリティ、移行、監視、夜間対応の責任者を決めます。再委託の可否、知的財産権、ソースコードの利用権、秘密情報、脆弱性対応、契約終了時のデータ返却も、複数社体制では初期契約から確認しておきます。

RFPと要件整理に入れるべきTiDB特有の項目

RFPは「TiDBを導入したい」という希望を書く資料ではなく、達成したい業務成果と制約条件を候補会社へ同じように伝える資料です。現行環境、対象業務、性能、可用性、セキュリティ、移行、運用、予算、納期を分けて書くと、委託先から具体的な提案を得られます。

業務要件には、利用者、権限、画面、外部連携、登録・更新・取消の流れ、締め処理、帳票、監査に必要な履歴を記載します。性能要件には、通常時とピーク時の同時接続数、読み書き件数、P95やP99の応答時間、集計の完了時間、データ増加量を入れます。「大量アクセスに対応」という表現だけでは、見積もりも検収もできません。

TiDBでは、データの分散を前提に主キー、インデックス、トランザクション、接続プール、リトライ、タイムアウトを設計します。TiFlashを利用する場合は、どのテーブルを分析用レプリカへ置くか、更新後にどの程度の反映遅延を許容するか、分析クエリと業務処理のリソースをどう分けるかもRFPへ含めます。

個人情報、決済情報、取引情報を扱う場合は、データ保管リージョン、TLS、IAM、管理者権限、監査ログ、バックアップ暗号化、脆弱性対応、RPOとRTOをRFPに記載します。個人情報保護委員会のガイドラインでは、アクセス制御、識別・認証、不正アクセス防止、漏えい防止などの安全管理措置が示されています（出典: 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」令和7年3月24日施行版）。

閉域接続、固定IP、VPC、Private Link相当の接続、プロキシ経由、海外リージョンの利用可否などは、後から変えると設計と見積もりに大きく影響します。クラウドの利用プランについても、監査ログ、権限管理、バックアップ、サポート、可用性の条件を最新仕様で確認するよう依頼します。

既存MySQLから移行する場合は、データ量だけでなく、テーブル数、更新頻度、binlogの保持、文字コード、SQLやストアドプロシージャの互換性、主キーの設計、外部連携の接続先を一覧化します。移行対象外の古いデータをどう保管するか、削除や匿名化が必要かも、見積もり前に決めておきます。

RFPには、許容停止時間、並行稼働の可否、切替日時、ロールバックの判断者、移行リハーサルの回数、整合性検証の方法を明記します。TiDB公式の移行ツールには、全量移行のTiDB Lightning、増分同期のDM、バックアップ・リストアのBR、整合性確認のsync-diff-inspectorなどがあるため、委託先に採用ツールと理由を提案してもらいます（出典: TiDB公式「Download TiDB Tools」、2026年確認）。

TiDBのシステム発注・外注の費用相場と内訳

TiDBのシステム開発費は、TiDB Cloudやサーバーの利用料だけで決まりません。業務アプリの新規開発、データ移行、分散SQLの性能検証、クラウドネットワーク、セキュリティ、監視、保守を含めた総額で見る必要があります。TiDB固有の日本向け公開統計は限られるため、以下は一般的な業務システムの相場にTiDB特有の工程を加味した、見積もりのたたき台となる推定レンジです。

技術検証やPoCは100万〜300万円程度、簡単な業務アプリを含む小規模な新規開発は300万〜1,000万円程度、中規模の受発注・会員・予約システムは1,000万〜3,000万円程度が一つの目安です。既存MySQLからの本番移行を伴う案件は1,500万〜5,000万円程度、大規模な基幹系や高可用性、複数システム連携まで含める案件は3,000万円〜1億円超となる可能性があります。

これらは公開されたTiDB単体の定価ではなく、一般業務システムの開発、移行、性能試験、運用設計を含めた推定レンジです。データ量、同時接続数、停止許容時間、アプリ改修の範囲、SLA、24時間監視の有無で変動します。候補会社からはレンジの数字だけでなく、前提となる人月、作業項目、除外項目、クラウド利用料を分けて提示してもらいます。

初期費用は、要件定義、基本・詳細設計、アプリ開発、TiDB設計、テスト、移行、切替、教育に分けます。一般業務システムの配分を参考にすると、要件定義10〜15%、設計25〜35%、開発・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%程度が目安になりますが、TiDB案件では移行設計、分散SQLの性能試験、障害・復旧試験を独立した項目として確認します。

ランニング費用には、TiDB Cloudまたはサーバー、ストレージ、バックアップ、データ転送、監視、ログ保管、サポート、保守改修、夜間対応を含めます。保守費は一般的に初期開発費の年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に詳しい会社を選ぶときは、資格やパートナー表記だけで判断しません。自社の業務を理解し、分散データベースの設計、MySQL移行、アプリ改修、性能試験、セキュリティ、監視、障害対応まで、実際のプロジェクトとして進められるかを確認します。

実績を聞くときは、「TiDBの導入実績がありますか」だけで終わらせず、対象業務、データ量、ピーク負荷、MySQLからの移行か新規開発か、TiDB Cloudか自社運用か、担当した工程、運用開始後の支援期間を確認します。可能であれば匿名化した構成図や、移行前後の性能指標、障害試験の内容を提示してもらいます。

開発元や公式パートナーであることは候補に入れる理由になりますが、発注者の業務を理解してくれることや、期待する運用を担えることを自動的に保証するものではありません。担当予定のエンジニアが提案段階だけでなく設計・移行・運用にも参加するのか、再委託される工程があるのかを確認します。

見積書は、要件定義、設計、開発、テスト、移行、クラウド設定、監視、教育、保守に分け、各項目の工数と単価を確認します。TiDBの構築費が安く見えても、アプリ改修やSQLチューニング、移行リハーサル、切戻し、運用設計が除外されていれば、後から追加になる可能性があります。逆に、不要な高可用性や過剰なノード数が含まれている場合もあります。

候補会社へは、同じRFP、同じデータ量、同じピーク負荷、同じSLA、同じ納期を提示し、初期費用と5年間の運用費を分けて比較します。評価軸は、要件適合度、費用、納期、技術提案、移行リスク、保守体制、担当者、契約条件の順に重み付けすると、最安値だけに引っ張られにくくなります。

本番稼働後は、クラスタやインスタンスが動くだけでなく、遅いSQLの調査、容量増加、バックアップの確認、バージョンアップ、脆弱性対応、障害時の一次切り分けが必要です。平日日中だけの保守なのか、夜間・休日も対応するのか、一次応答時間、復旧目標、問い合わせ回数、軽微な改修の範囲を契約に書きます。

自社にDBAがいない場合は、運用引継ぎ後の体制を特に重視します。監視アラートを誰が受け、どの条件でPingCAPやクラウド事業者へエスカレーションし、障害後にどの報告書を提出するかを確認します。運用手順書だけでなく、実際のバックアップ復元、フェイルオーバー、切替訓練を受入条件に含めると、契約後の認識差を減らせます。

TiDBのシステム発注・外注に関するよくある質問

TiDBのシステムを発注するときは、技術的な疑問と同じくらい、費用、移行、体制、契約の疑問が出てきます。ここでは発注前に特に質問されやすい内容へ、実務で判断しやすい形で回答します。

業務アプリの開発まで必要なら、業務要件を整理できるシステム開発会社を主契約先にし、TiDBに詳しい会社をDB設計・移行の専門パートナーとして組み合わせる方法があります。既存MySQLの移行や性能問題が中心なら、DB移行・DBA支援の実績を重視して選びます。会社名だけでなく、担当範囲、実績、運用体制、成果物を比較することが大切です。

小規模な検証や開発環境では無料枠を活用できますが、本番運用が可能かはデータ量、負荷、可用性、監査、サポート要件で判断します。公式情報では、無料枠を超えると接続制限やスロットリングが発生する条件があり、無料プランにはクエリあたり256MiBのメモリ制限も案内されています（出典: TiDB公式「TiDB Cloud Starter FAQs」、2026年確認）。本番では予測負荷に基づく有料枠と上限額を見積もり、試験で確認します。

停止時間は、データ量、更新頻度、移行方式、アプリケーションの切替方法によって変わります。全量データを一度に移す方式だけでなく、Lightningで初期データを投入し、DMで増分を同期してから短時間で切り替える方式も検討できます。実データで移行リハーサルを行い、同期遅延、整合性検証、切戻し時間を確認してから本番日程を決めます。

TiDBの構築費だけでなく、要件定義、アプリ改修、SQL・インデックス設計、性能試験、移行リハーサル、バックアップ復元、監視、保守、クラウド利用料が含まれているかを確認します。また、見積もりの前提データ量、ピーク負荷、可用性、サポート時間、除外項目、追加費用の条件を同じ様式で比較します。価格の差が大きいときは、安い会社へすぐ決めず、何が含まれていないかを質問します。

まとめ

TiDBのシステムを発注・外注するときは、TiDBの構築だけを依頼するのではなく、業務要件、アプリケーション、データ移行、性能、セキュリティ、クラウド費用、運用体制まで含めて発注範囲を決めます。まずは現状の負荷とデータを把握し、PoCで採用理由を数値化することが、過剰設計や移行事故を避ける出発点です。

発注形態は一括請負、準委任、複数社体制のどれが自社に合うかを決めます。RFPには、業務と性能の目標、TiDB Cloudか自社運用か、移行停止時間、セキュリティ、納品物、保守条件を記載します。見積もりは初期費用だけでなく、クラウド利用料、保守、監視、障害対応を含む5年間の総額で比較します。委託先は、TiDBの知識だけでなく、担当範囲、移行実績、PoC計画、運用体制、リスクの説明力で選びます。

候補会社へ相談する前に、現行データベースの種類とバージョン、データ量、ピークアクセス、代表SQL、停止可能時間、希望クラウド、個人情報の有無、希望納期を整理します。情報が不足していても、分からない項目を分からないまま提示すれば、委託先から調査やPoCを含む現実的な提案を受けられます。TiDBのシステム開発は、安い構築先を探すことではなく、将来の負荷と運用責任まで含めて、成功条件を共有できるパートナーを選ぶことが重要です。

▼全体ガイドの記事
・TiDBのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。