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