PlanetScaleのシステム開発は、要件整理から定着までの6つのフェーズを順に進めると、安全な運用につながります。各フェーズで決めたことが次の工程の前提になるため、順番を飛ばすと後から仕様や費用が変わりやすくなります。
▼全体ガイドの記事
・PlanetScaleのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
PlanetScaleのシステム開発の全体像
PlanetScaleは業務画面を持たず、アプリケーションが使うデータベース基盤です。このため、契約と接続だけでは開発は完結しません。
業務フローやAPIの設計に加えて、認証や権限、帳票も含めて考えます。さらに、監視、バックアップ、運用体制も設計の対象になります。
VitessとPostgresの切り分け
最初の判断では、既存資産と必要な互換性を基準に、VitessとPlanetScale Postgresを比べます。
- Vitess：MySQL互換で、オンラインのスキーマ変更や将来のシャーディングを求める場合に候補になります。
- PlanetScale Postgres：PostgreSQL拡張機能、既存ORM、分析基盤との互換性を優先するなら、比較の対象になります。
両者はスキーマ変更の手順も異なります。Deploy Requestによるレビューと本番反映は、Vitessに限られます。
一方、Postgresでは開発ブランチで標準DDLを検証し、同じ変更を本番ブランチへ手動で適用するのが基本です。両者に同じ移行手順を当てはめないよう、PlanetScale公式のPostgresブランチ説明を確認します。
PlanetScaleとアプリケーションの責任範囲
標準構成では、ブラウザやスマートフォンアプリに加えて、API・アプリケーションサーバーとPlanetScaleが含まれます。
- データ基盤：PlanetScaleとオブジェクトストレージを使います。
- 外部機能：認証・決済・分析サービスやCI/CD基盤を外部から組み合わせて使います。
PlanetScaleは認証、申請ワークフロー、帳票出力を自動では提供しません。そのため、各機能をDB、アプリ、外部SaaSのどこに持たせるかを、要件定義で決めておく必要があります。
たとえば、顧客管理では、顧客・契約・対応履歴をPlanetScaleに保存できます。一方、ログイン、請求、請求書は、それぞれ外部認証、決済、帳票サービスに分ける設計が考えられます。
境界が曖昧なままだと、権限や監査ログの責任者が決まらず、見積もりや保守にも抜けが生じます。
PlanetScaleのシステム開発の進め方
開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けて管理します。各フェーズに完了条件を設け、次へ進む前に判断を記録しておくと、納期遅延や本番障害を防ぎやすくなります。
1. 要件整理フェーズでの業務と非機能要件の整理
要件整理では、誰がどの業務で、何のデータを、どの頻度で使うかを明らかにします。対象業務は、顧客管理、受発注、予約などに分けて考えます。会員やECも対象になります。
- 現行業務：Excelや既存システムでの入力、承認、検索、出力を、業務フローとして並べます。
- 取引の状態：1件の取引が作成されてから完了するまでに、データがどう変わるかを追います。
画面一覧だけでは、PlanetScaleの設計判断に必要な情報が足りません。そこで、取引ごとのデータの状態も把握しておきます。
あわせて、ピーク時の同時接続数、1日あたりの登録件数、保持期間を決めます。個人情報の種類も、このときに確定させます。
さらに、RTO（目標復旧時間）、RPO（許容データ損失時間）、監査ログ、データ保管リージョンも取り決めておきます。また、移行元が既存MySQLかどうか、停止可能時間は何分か、障害時の一次対応者は誰かを確かめます。
管理者と一般利用者で権限を分けるかどうかも決めます。これらが未確定のままDBを選ぶと、構成と見積もりが大きく変わります。
2. 選定フェーズでのVitess・Postgres・他DBの比較
候補は、VitessとPlanetScale Postgresに加えて、AWS RDSやAurora、Google Cloud SQLなどです。これらを同じ条件で比べます。
- 互換性：既存DB、ORM・フレームワーク、必要な拡張機能との適合を見ます。
- 運用性：リージョン、接続方式、スケール方法、バックアップ復元、担当者のスキルを比べる項目です。
ベンチマークは、サンプルデータではなく、実際の検索条件とピークアクセスに近いデータで行います。
Vitessでは、開発ブランチのスキーマ差分をDeploy Requestでレビューしてから本番へ反映する流れを、PoCで確かめます。公式説明では、レビュー時に不整合や危険な変更を検査する仕組みです。また、条件によっては、反映後30分以内のリバートも可能です。
一方、Instant Deploymentsはリバートできません。そのため、変更の種類と承認フローを事前に確かめておきます。Postgresでは、手動DDLのレビュー、実行担当、失敗時の復元方法を別に設計します。
3. 設計開発フェーズのスキーマと変更手順
設計では、業務上のエンティティをテーブルにして、主キーと検索インデックスを定めます。履歴と論理削除も、あわせて設計します。
- 業務ルール：二重登録の防止、承認済みデータの変更制御、削除権限の仕様。
- 個人情報：マスキング方針と、データの扱い方を設計します。
業務ルールは、アプリケーション側の仕様として持たせる必要があります。PlanetScaleが自動で保証するものではないためです。
接続数が増える構成では、接続プールやPgBouncerも検討し、アプリケーションサーバーからの接続方法を設計します。
Vitessで破壊的な変更を行うときは、追加、移行、削除の順に進めるexpand・migrate・contractを使います。まず、新しい列やテーブルを追加し、旧と新への書き込みを一定期間併存させます。データを確認したあとで、古い構造を削除します。
この方法は、アプリとDBを同時に一気に切り替えるリスクを下げます。なお、Postgresでは同じ自動マージを前提にしません。
Postgresでは、マイグレーションファイルとレビューをCI/CDに組み込みます。適用ログや、ロールバックまたはフォワードフィックスの方法も、同じ流れに含めます。
4. テストフェーズの負荷・復元・権限の確認
テストでは、画面表示に加えて、DB基盤を含む業務が続けられるかを確かめます。単体テストと結合テストも実施します。
- 負荷と障害：ピーク同時接続、重い検索、タイムアウト、リトライ、外部API停止が対象です。
- 復元と権限：バックアップ復元と、権限外データへのアクセスを検証します。
管理者なら全件見えるという単純な条件で済ませず、部署や顧客ごとの境界、契約状態、退職者のデータをテストデータに入れます。
復元テストでは、目標時間内に復元できるかに加えて、アプリケーションの接続先を切り替えられるかまで確かめます。
最大レイテンシやエラー率、復旧所要時間を記録し、復元後の件数差分も残します。合格基準は、数値で決めておきます。基準がないままリリースすると、本番で初めて遅さや復元の可否を判断することになります。
5. 稼働フェーズの移行と切り替え
稼働前には、移行対象のテーブルと件数を確定します。あわせて、文字コード、タイムゾーン、重複ルールも決めておきます。
- 移行条件：既存MySQLから移す場合は、読み取り専用にできる時間と差分の取り込み方法を決めます。
- 切り戻し：旧システムへ戻す条件を定め、担当者と実施時刻をRunbookに記します。
無停止に近づける場合も、書き込みを一時停止するか、二重書き込みで差分を追うかを選びます。
当日は、バックアップを取得してから移行を行い、件数照合と代表ユーザーの業務確認に進みます。その後、監視を開始し、切り戻しを判断します。
照合では、総件数に加えて顧客IDや注文金額を見ます。更新日時やNULL件数など、業務上重要な項目も確かめます。
Vitessにはスキーマ変更の機能がありますが、無条件に安全とは考えず、変更内容とデータの整合性を確認します。
6. 定着フェーズの運用と改善の仕組み
稼働後は、障害対応だけでなく、利用状況とデータ品質を見ながら改善を重ねます。CPUやメモリだけを見ていては、監視が足りません。
- 基盤の監視：クエリのレイテンシ、エラー率、接続数、ストレージ、バックアップ状態が対象です。
- 変更と連携：スキーマ変更履歴と外部APIの失敗率を確認し、対応者と対応時間を決めます。
利用部門には、操作マニュアルを渡すほか、入力ルールや権限申請の手順を伝えます。データ訂正の方法と、障害時の連絡先も共有します。
月次では、未利用機能や重複データを確かめます。四半期ごとには、アクセス権と復元手順を見直します。
定着とは、現場が正しいデータを継続して入力し、意思決定に使える状態を保つことです。技術の完成とは別に、この状態を作る必要があります。
PlanetScaleのシステム開発にかかる費用相場
費用は、PlanetScale利用料、システム開発費、稼働後の運用費に分けて考えます。DBの月額料金だけでは、全体の金額を判断できません。
要件定義、画面・API開発、データ移行の費用も見ます。監視、教育、保守の費用も含めます。ここで示す数字は、公開料金と一般的な工程による目安で、個別見積もりの代わりにはなりません。
PlanetScaleの利用料と請求範囲
2026年の確認時点で、PlanetScaleの公式Postgres料金では、Single Nodeが月額5ドルから、Highly Availableの3ノード構成が月額15ドルからです（出典: PlanetScale公式「Postgres pricing」、2026年確認）。
これは米国東部リージョンを起点にしたクラスター料金です。ただし、ストレージ、バックアップ、通信は別料金の場合があります。追加レプリカやリージョン差も、料金が別になる場合があります。
地域や構成によっても価格は変わります。そのため、見積もりの際は、想定データ量と通信量を入力して確かめます。
- 小規模検証・低トラフィック：DB基盤だけなら、月額5〜100ドル程度が入口になります。
- 中小規模本番：HA構成、複数環境、バックアップ、通信量を含めて、月額100〜1,000ドル程度です。
- 大規模構成：シャーディング、専用環境、厳格なSLA、Enterprise支援が必要なら、月額1,000ドル超の場合があります。
1ドル=150円と仮置きすると、上の3つの規模は順に、月額750〜1万5,000円程度、1万5,000円〜15万円程度、15万円超になります。円換算の額は、為替と利用量で変わる推定の幅です。
開発費の目安と規模・移行・連携の数
一般的なクラウド型業務システムの工程で見ると、画面数が少ないPoCや小規模管理画面は200万〜600万円程度です。期間は1〜3か月程度が目安になります。
- 中小規模：顧客・案件・受発注を扱うシステムで、800万〜3,000万円程度、3〜9か月程度です。
- 基幹系：外部連携、複雑な権限、既存データ移行、高可用性を含む場合は、3,000万円〜1億円超、9か月〜2年以上になることがあります。
これらはPlanetScale固有の価格ではなく、必要な工程から推定した幅です。
工程別の費用配分は、要件定義10〜15%、設計25〜35%、開発・単体テスト30〜40%が目安です。結合・総合テストは15〜20%、移行・教育は5〜10%です（出典: NotebookLM収集Q&A「業務システム全般」、2026年）。
PlanetScaleでは、DB選定と接続方式を設計工程に含めます。移行検証、負荷試験、バックアップ復元試験も、同じ工程に入れます。画面だけで見積もると、データ基盤の検証費用が後から追加されやすくなります。
運用費の算定範囲（監視・保守・復旧訓練）
運用費には、PlanetScale利用料とアプリ保守が含まれます。さらに、監視、問い合わせ、セキュリティ更新も対象になります。
- バックアップ：確認と、復元訓練の実施です。
- 障害対応：障害時のオンコール体制を用意します。
一般に、初期開発費の年15〜20%を保守費用の目安とする考え方があります（出典: NotebookLM収集Q&A「業務システム全般」、2026年）。
たとえば、開発費が3,000万円なら、年間450万〜600万円、月額37万〜50万円程度になります。ただし、対応時間やSLAによって変わります。
PlanetScaleのセキュリティ機能は、プランによって異なります。公式情報では、暗号化とSOCレポートのほか、監査ログ、SSO、プライベート接続も確認できます。
- 接続：標準で暗号化され、AWS PrivateLinkやGCP Private Service Connectも選べます。
- 個人情報：保存リージョン、委託先、アクセス権、ログ保管、契約書を自社基準で確認します。
法令対応は、自社側の確認も加えて初めて完了します。
PlanetScaleのシステム開発で見積もりを取るポイント
見積もりの精度を上げるには、画面数だけでなく、データと運用の条件も発注先へ渡すことが大切です。経験を聞くときは、製品名を知っているかだけで判断せず、エンジン、変更管理、障害対応の範囲を質問します。
RFPに記載するデータ量・ピーク・移行条件
RFPや相談資料には、利用者数と同時接続数のほか、1日・月間の登録件数を記します。データ総量と増加率も、あわせて書いておきます。
- 利用状況：検索条件とデータ保持期間を共有します。
- 既存環境：DBの種類と版、テーブル数、文字コード、外部キーの有無。
- 移行条件：対象外データと許容停止時間を明記します。
実データに近いサンプルと代表クエリがあれば、概算の段階でもDB選定と負荷試験の見積もりが具体化します。
非機能要件は、「高速」や「安全」といった言葉ではなく、検索の95パーセンタイルを何秒以内にするかといった数値で表します。障害から何分以内に復旧するか、何分前までのデータを戻せるかも定義します。
個人情報、決済情報、監査対象データがある場合は、権限や操作ログのほか、暗号化、リージョン、委託契約も初期資料に含めます。
発注先に聞く7つの質問
候補会社には、同じ質問票で経験と対応範囲を尋ねます。移行や承認、障害対応まで同じ項目で聞くと、回答の差をそのまま比べられます。
- VitessとPlanetScale Postgresの対応経験。
- 既存MySQLやPostgreSQLからの移行方法。
- Deploy Requestまたは手動DDLの承認フロー。
- 負荷試験と復元試験の実施範囲。
- 監視と24時間障害対応の有無。
- 個人情報を扱う場合の契約・リージョン確認。
- PlanetScale公式サポートやEnterprise窓口との役割分担。
同じ質問票で比べると、会社名や営業資料では見えない体制の差が分かります。
公開導入実績を確認できない会社は、その事実を前提に評価します。AWSやWebアプリの経験が豊富でも、PlanetScaleを扱えるとは限りません。
担当エンジニアの経験や成果物の範囲を確認します。さらに、レビュー責任、引き継ぎ資料、保守契約も見ておきます。製品提供元と開発会社の、どこまでを誰が受け持つかも、契約書に残します。
TCOと撤退条件の比較
見積もりを比べるときは、初期開発費とPlanetScale利用料を並べます。さらに、ネットワーク、バックアップ、監視の費用と、保守、移行、教育の費用も並べて見ます。
- 拡張：アクセス増加時のスケール方法と、リージョン変更の可否を見ます。
- 撤退：別DBへの移行、データのエクスポート、契約終了時の返却・削除証跡を確認します。
公式事例には、他社クラウドからの移行でコストを削減した例があります。ただし、結果は個別のデータ量や構成によって変わります。そのため、自社でも同じ削減率になるとは断定できません。
PoCでは、接続と代表クエリを検証します。さらに、スキーマ変更とバックアップ復元、障害時の連絡、月額請求も確かめます。
合格条件は、「動いた」で済ませず、想定ピークで許容レイテンシを満たすかなど、検証できる形で決めます。復元時間がRTO以内であることや、本番変更の承認者が決まっていることも、条件にできます。
条件を定めておくと、本開発での過度な安全余裕や、後出しの追加費用を減らせます。
PlanetScaleのシステム開発でよくある質問
料金、既存DBからの移行、開発会社の選び方は、初回相談の段階で確認しておくと計画が安定します。
PlanetScaleのシステム開発は安くできますか？
DB基盤の入口料金は抑えられますが、システム全体が自動的に安くなるとは限りません。
費用は、画面とAPIの開発だけでなく、認証と移行を含めて考えます。テストと監視、保守も同じ見積もりに入れておきます。初期開発費と運用費を分けて、総保有コストで比べます。
小規模な検証から中小規模のシステムまで、開発範囲ごとの費用感を比べます。
- 小規模PoC：200万〜600万円程度。
- 中小規模の業務システム：800万〜3,000万円程度。
いずれも一般的な工程から見た目安で、機能数と連携数によって変わります。
既存のMySQLからPlanetScaleへ移行できますか？
既存MySQLからの移行は候補になります。可否は、互換性と移行条件を確認して判断します。
- 互換性：SQL、外部キー、文字コード、トリガー、ストアド処理。
- 移行条件：データ量と許容停止時間。
複製またはエクスポートしたデータでリハーサルし、件数と、金額・日時・IDなどの重要な項目を照合します。
停止時間を短くする場合は、差分取り込みや段階切り替えも検討します。ただし、方式によっては追加の開発・検証費が発生します。
VitessとPlanetScale Postgresはどちらを選べばよいですか？
既存MySQL資産、オンラインのスキーマ変更、将来のシャーディングを重視するなら、Vitessを優先的に検討します。
一方、PostgreSQL拡張機能や既存のPostgres向けORM、分析・データ処理との互換性を重視するなら、Postgresが候補になります。
判断材料は、代表クエリの性能、移行コスト、変更管理、障害復旧です。名称や評判で決めず、PoCでこれらを比べます。
個人情報を扱うシステムでも利用できますか？
利用できる可能性はあります。ただし、適法性や安全性は、PlanetScaleの機能だけで決まるものではありません。
導入前には、サービスの機能と、自社側で必要な確認事項を整理しておきます。
- サービスと委託先：保管リージョン、暗号化、アクセス制御、監査ログ、契約を確認します。
- 自社の対応：外国にある第三者への提供と、自社アプリの脆弱性対策が対象です。
公式セキュリティ情報で機能を調べ、個人情報保護委員会のガイドラインや自社規程に照らします。判断は、法務・セキュリティの担当者が行います。
開発会社を選ぶときに最も重視することは何ですか？
PlanetScaleの経験に加えて、業務の要件定義から運用定着まで責任を持てるかを見ます。
VitessとPostgresの違いや既存DB移行について質問します。負荷・復元試験、変更承認、障害時の連絡体制も確かめます。
回答が担当者個人の経験に頼らず、成果物と保守契約に反映されていれば、担当が変わっても運用を続けられます。
まとめ
PlanetScaleのシステム開発では、DB接続だけでなく、業務フローとアプリ、セキュリティと運用を一体で設計します。
特に、VitessとPlanetScale Postgresを切り分けたうえで、変更管理と復旧方法を決めることが重要です。
6フェーズの完了条件
各工程では、完了条件を満たしたことを確かめてから、次へ進みます。
- 要件整理で業務・非機能・法務の条件を明らかにします。
- 選定では代表データを使い、候補を比べます。
- 設計開発で、スキーマと変更手順を作ります。
- テストで負荷・権限・復元を検証します。
- 稼働で移行と切り戻し条件を、Runbookにまとめます。
- 定着で、監視、教育、改善の担当を決めます。
順番に進めると、料金の安さだけに引っ張られず、TCOと事業上の効果を比べられます。
相談前に整理する要件と検証条件
相談前には、対象業務と既存DBを一枚にまとめます。利用者数、データ量、許容停止時間も、同じ資料に記します。
RTO・RPOと個人情報の有無も記します。加えて、「VitessとPostgresを比較したい」などの条件も書きます。
バックアップ復元の検証や、本番スキーマ変更の承認者を置くといった要望も伝えます。
- 比較：VitessとPostgresの両方を検討します。
- 検証：復元試験と本番変更の承認者を相談します。
業務を止めずに安全に改善できる状態を目的にすると、実行できる提案を受けやすくなります。
▼全体ガイドの記事
・PlanetScaleのシステム開発の完全ガイド
▼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を創業。