PlanetScaleのシステム開発の完全ガイド

PlanetScaleのシステムとは、PlanetScaleをデータベース基盤に採用し、Webサービスや業務アプリのデータを安全かつ拡張性高く扱う構成です。

PlanetScaleを使ったシステム開発では、データベースの選択だけでなく、アプリケーション、認証、外部連携、監視、バックアップ、データ移行までを一体で設計する必要があります。本記事では、PlanetScaleのシステムの全体像、VitessとPostgresの違い、開発の進め方、費用相場、セキュリティ、開発会社・ベンダーの選び方、失敗を防ぐ確認事項までを、2026年時点の情報をもとに解説します。

PlanetScaleのシステムとは何ですか？全体像を解説します

PlanetScaleのシステムは、PlanetScaleだけで業務画面や業務フローが完成する製品ではありません。データを保存・検索するデータベースを中心に、利用者が操作する画面、API、認証、ファイル保管、通知、分析、CI/CDを組み合わせて、一つのサービスとして構築します。

基本構成はアプリケーションとデータベースの分離です

一般的な構成は、ブラウザやスマートフォンアプリ、API・アプリケーションサーバー、PlanetScale、オブジェクトストレージ、外部認証・決済・分析サービス、監視・CI/CDで成り立ちます。PlanetScaleはデータベースの可用性やスケーラビリティを担いますが、ログイン画面、権限画面、帳票、ワークフロー、メール配信を自動で用意するわけではありません。

そのため要件定義では、データベースに任せる範囲と、アプリケーションや周辺サービスで実装する範囲を最初に分けます。たとえば顧客情報はPlanetScaleに保存し、契約書PDFはオブジェクトストレージに保存し、利用者の権限判定はアプリケーション側で行うといった分担です。この境界を曖昧にすると、後から権限・監査・バックアップの設計をやり直すことになります。

業務システム・SaaS・会員基盤などに利用できます

利用例は、顧客管理、受発注管理、予約管理、在庫・商品管理、ECの会員基盤、社内申請、SaaSのテナント管理、モバイルアプリのバックエンドなどです。特に、利用者やデータが増える見込みがあり、開発中のスキーマ変更を本番へ安全に届けたいサービスと相性が良いです。

一方で、会計・給与・法定帳票のように制度対応が中心となる業務では、既存のパッケージやSaaSを使い、PlanetScaleは独自画面や連携部分に限定する方法もあります。すべてをスクラッチ開発する前に、業務の標準化が目的か、独自の顧客体験やデータ連携が目的かを整理することが重要です。

価値はデータベース運用の負担を減らし、開発速度を高めることです

PlanetScaleの価値は、サーバーを用意することだけではありません。ブランチで変更を分離し、差分をレビューし、必要な変更を本番へ届ける流れを整えることで、開発者が本番データベースを直接操作する場面を減らせます。アクセス増加への対応、レプリカ、接続数、バックアップ、障害時の切り分けを含めて設計することで、開発チームが機能開発に集中しやすくなります。

PlanetScaleの種類と選び方を整理します

PlanetScaleを選ぶときは、同じサービス名でもデータベースエンジンと運用機能が異なることに注意が必要です。特に、Vitess系のMySQL互換データベースと、PlanetScale Postgresを同じ手順で扱えると考えると、スキーマ変更や本番反映で問題が起きます。

Vitess系はMySQL互換と安全なスキーマ変更が特徴です

Vitess系はMySQL互換の既存資産を活かしやすく、ブランチ、Deploy Request、スキーマ差分の確認、レビュー、オンラインDDLを組み合わせた変更管理ができます。公式ドキュメントでは、Deploy Requestにより本番への非ブロッキングなスキーマ変更を行い、反映後30分以内であればリバートできる仕組みが案内されています。ただし、即時反映を選んだ変更はリバートできないため、便利な機能ほど適用条件を確認してから運用します（出典: PlanetScale公式Deploy Requestドキュメント、2026年）。

既存のMySQLから移行する場合は、SQL方言、外部キー、文字コード、AUTO_INCREMENT、トランザクション、ORMの接続方法を確認します。移行前に本番に近いデータ量でクエリを測り、重い検索をインデックスや検索基盤へ分離できるかを確認すると、移行後の性能問題を減らせます。

PostgresはPostgreSQL前提の拡張性と互換性を見ます

Postgresを選ぶ場合は、PostgreSQL向けのORM、拡張機能、分析クエリ、JSON型、全文検索、既存の運用ノウハウを活用しやすいかを確認します。業務システムのデータ構造がPostgreSQL前提で設計されている場合や、将来の分析・データ連携でPostgreSQLの機能を使う場合に候補となります。

ただし、現在の公式ドキュメントでは、PlanetScale Postgresのブランチ間にVitessのようなDeploy Requestによるスキーマ自動マージはありません。開発ブランチでDDLを検証した後、同じ変更を本番ブランチへ手動適用する運用が基本です（出典: PlanetScale公式Postgres Branchingドキュメント、2026年）。マイグレーションツール、レビュー、適用担当、ロールバック手順を自社の開発フローに組み込む必要があります。

エンジンは機能ではなく要件と運用体制で選びます

選定基準は、ベンチマークの速さだけでは不十分です。既存DBとの互換性、1日の書き込み量、ピーク時の同時接続数、許容レイテンシ、RTO・RPO、外部キーの扱い、監査ログ、障害対応時間、将来のシャーディング要否を一覧化します。

小規模な検証ではSingle Nodeで始められても、本番では高可用性構成、バックアップ、監視、プライベート接続、追加レプリカが必要になる場合があります。PoCの構成をそのまま本番へ拡大するのではなく、本番相当の非機能要件を満たす構成へ段階的に見直します。

PlanetScaleのシステム開発の進め方を4段階で解説します

PlanetScaleを採用する開発は、データベースを契約してから画面を作るだけでは成功しません。業務要件、データモデル、移行、権限、性能、障害対応を早い段階でつなぎ、各工程で検証可能な成果物を残します。

▶ 詳細はこちら：PlanetScaleのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 要件定義で業務・データ・非機能要件を決めます

最初に、誰が、どの業務で、どのデータを、どの頻度で登録・参照・更新するかを整理します。顧客、商品、注文、請求、権限、操作履歴などの主要エンティティを洗い出し、保持期間、削除ルール、個人情報の範囲、データの所有者を決めます。

同時に、ピークアクセス、許容する応答時間、月間データ増加量、RTO・RPO、メンテナンス可能時間、障害通知の方法を数値化します。たとえば「速い画面」ではなく「通常時95パーセンタイルで2秒以内」「重大障害は4時間以内に復旧」のように書くと、DB構成と見積もりを比較しやすくなります。

2. データモデルとPoCで実データに近い検証を行います

次に、テーブル、主キー、インデックス、リレーション、履歴、テナント分離の設計を作ります。PlanetScaleのシステムでは、後からの変更を想定して、列の追加・非NULL化・削除・名称変更をどの順序で行うかまで確認します。業務画面の試作だけでなく、代表的な検索、集計、登録、更新、バッチ処理を実際に動かすことが重要です。

PoCでは、同時接続数、読み取りと書き込みの比率、ピーク時の応答時間、接続プールの上限、スロークエリ、バックアップ復元時間を測ります。データ量が少ない検証環境で問題が出なくても、本番で10倍・100倍の件数になればインデックス設計や通信量が変わるため、将来の規模を想定した負荷試験が必要です。

3. 開発・データ移行・テストを並行して進めます

実装では、アプリケーションの機能開発とデータベースのマイグレーションを分離し、レビュー可能な小さな単位で進めます。Vitess系なら開発ブランチでスキーマを変更し、Deploy Requestの差分・警告・影響範囲を確認してから本番へ反映します。Postgresでは同じ仕組みが自動で働かないため、DDLの適用順と実行者を明確にします。

既存DBからの移行では、全件移行、差分同期、切り替え、旧環境の参照停止という手順を設計します。移行リハーサルを少なくとも1回、本番に近い件数で行い、件数照合、金額合計、文字化け、時刻ずれ、重複、権限漏れを確認します。画面テストだけでなく、バッチ、外部連携、障害復旧も総合テストの対象にします。

4. リリース後の監視・復元訓練・改善まで設計します

リリース後は、CPUやメモリだけでなく、クエリのレイテンシ、エラー率、接続数、ロック、レプリカ遅延、ストレージ、通信量を監視します。業務システムでは、注文登録の失敗や請求データの不整合のように、インフラ指標だけでは分からない業務指標もアラートへ加えます。

バックアップが存在することと、復元できることは別です。復元先の用意、復元時間の測定、接続先の切り替え、データ整合性の確認、利用者への告知までを訓練します。月次または四半期で復元試験を行うと、担当者が変わっても復旧手順を維持しやすくなります。

▶ 詳細はこちら：PlanetScaleのシステム開発でおすすめの開発会社/ベンダー6選と選び方

PlanetScaleのシステム開発費用と料金相場を解説します

PlanetScaleのシステム費用は、データベース利用料とシステム開発費を分けて考えます。利用料が低く見えても、画面・API、認証、データ移行、テスト、監視、保守の工数が必要になるため、月額料金だけで安いと判断してはいけません。以下の開発費は、一般的な業務システム相場と必要工程から算出した概算です。

▶ 詳細はこちら：PlanetScaleのシステム開発の見積相場や費用/コスト/値段について

データベース利用料は構成・ストレージ・通信量で変わります

2026年8月時点の公式Postgres料金では、Single Nodeが月額5ドルから、Highly Availableの3ノード構成が月額15ドルからです。これは最小構成の入口であり、コンピュート、ストレージ、バックアップ、外向き通信、追加レプリカ、リージョンなどで請求額が変わります。公式料金表では、本番ブランチのパブリック通信に月100GB、非HA構成や開発ブランチに月10GBの込み枠が示され、プライベート接続は超過分が1GBあたり0.01ドルです（出典: PlanetScale公式Postgres料金表、2026年）。

検証・小規模本番では月額5〜100ドル程度、中小規模の本番でHA構成や複数環境、通信量を含めると月額100〜1,000ドル程度、大規模な高可用性・追加レプリカ・専用環境・Enterprise支援まで求めると月額1,000ドルを超える場合があります。1ドル150円で単純換算すると、月750円〜15万円程度、15万円〜150万円程度、150万円超の層です。実際の請求額はリージョンと利用量で変わるため、契約前に構成を入れた料金表で試算します。

開発費は200万円台から1億円超まで幅があります

画面数が少ないPoCや小規模な管理画面は200万〜600万円、顧客・案件・受発注を扱う中小企業向けシステムは800万〜3,000万円、複雑な権限、外部連携、データ移行、高可用性、基幹連携を含むシステムは3,000万円〜1億円超が一つの目安です。開発期間はそれぞれ1〜3か月、3〜9か月、9か月〜2年以上となる場合があります。

この金額はPlanetScaleが公開している開発価格ではなく、要件定義、設計、実装、テスト、移行、教育の工程から推定した相場です。特に既存DBの移行でデータクレンジングが必要な場合、業務部門の確認時間や並行稼働期間が増えるため、画面数だけで開発費を比較しないことが大切です。

見積もりは工程と運用費を分けて確認します

費用配分は、要件定義10〜15%、設計25〜35%、開発・単体テスト30〜40%、結合・総合テスト15〜20%、移行・教育5〜10%を目安にします。運用開始後は、アプリケーション保守、監視、バックアップ復元訓練、障害対応、セキュリティ更新を含め、初期開発費の年15〜20%程度を保守費として見込むと、予算を立てやすくなります。

たとえば3,000万円の開発では、年間450万〜600万円、月37万〜50万円程度が保守費の目安です。ここへPlanetScaleの利用料、監視サービス、ログ保管、外部API、サポート契約が加わります。公式事例で20〜30%の削減や、移行前の8倍にあたるコスト差が紹介されていても、利用量やチーム構成が異なるため、自社の現行運用費と比較することが必要です（出典: PlanetScale公式導入事例、2026年掲載）。

料金ではなくTCOと事業効果で判断します

TCOには、DB利用料だけでなく、インフラ担当者の工数、移行時の停止損失、障害による売上機会の損失、性能改善、監査対応、バックアップ復元試験、開発環境のブランチ費用まで含めます。公式事例では、データベース移行に必要だった手作業や障害対応が減り、チームが機能開発へ時間を戻せたという効果が報告されています。これはすべての案件に同じ割合で再現する数字ではありませんが、月額料金だけでは見えない比較軸です。

セキュリティ・可用性・運用で確認すべきこと

PlanetScaleを採用すればセキュリティ対策が自動的に終わるわけではありません。データ分類、アクセス権、アプリケーションの認可、暗号化、ログ、脆弱性対応、委託先管理を、データベースサービスの責任範囲と自社の責任範囲に分けて設計します。

個人情報とデータ保存リージョンを契約前に確認します

個人情報や特定個人情報を扱う場合は、保存場所、バックアップの場所、サポート担当者がアクセスする可能性、委託契約、削除方法、監査証跡を確認します。個人情報保護委員会は、外国にある第三者のクラウドサービスを利用する場合、サービス提供者が直接データを取り扱わない場合でも、安全管理措置の一環として外国の制度を把握する必要があると説明しています（出典: 個人情報保護委員会FAQ、2026年確認）。

開発会社へ依頼する場合は、データフロー図、保存国・保存リージョン、アクセス権限表、暗号化方式、ログの保持期間、インシデント時の連絡経路を納品物に含めます。「クラウドなので安全」という説明だけで終わらせず、法務・情報システム・現場責任者が確認できる資料に落とし込むことが重要です。

高可用性と復旧目標を構成へ反映します

Single Nodeは検証や停止が許容される用途に向き、高可用性構成は本番の継続運用を重視する用途に向きます。ただし、HA構成にしてもアプリケーションのバグ、誤削除、権限設定ミス、外部サービス障害まで防げるわけではありません。RTO・RPOを決め、バックアップ、レプリカ、復元手順、切り戻し判断を組み合わせます。

また、読み取りが多い場合はレプリカ、データ量や書き込み量が非常に大きい場合はシャーディングを検討します。シャーディングは設定を増やすだけの対策ではなく、分割キー、クロスシャード検索、集計、再配置、障害時の影響範囲まで設計する必要があります。最初から複雑な構成にせず、計測値が基準を超えた段階で拡張できる設計にします。

移行リスクは停止時間とデータ整合性で評価します

既存DBからの移行では、切り替え時の停止をゼロにできるかだけでなく、差分同期中の更新、時刻・文字コード、採番、重複、外部キー、個人情報のマスキングを確認します。切り替え後に旧DBへ戻す可能性があるなら、双方向同期や二重書き込みによる不整合も検討が必要です。

移行リハーサルの結果は、件数一致率、重要項目の合計値、最大停止時間、移行に要した時間、エラー件数、切り戻し可能時間として記録します。経営判断に必要な数字がそろうため、単なる技術検証ではなく、業務継続計画の一部として扱えます。

PlanetScaleのシステム開発会社・ベンダーの選び方

PlanetScaleのシステム開発会社を選ぶときは、製品名を知っているかだけでなく、業務要件、データ設計、アプリ開発、移行、監視、保守を一つの計画にできるかを確認します。開発会社とデータベースの提供元の役割分担も、提案段階で明確にします。

実績はPlanetScaleの利用経験と業務実績を分けて確認します

確認したい実績は、PlanetScaleを使った件数だけではありません。既存DBからの移行、利用者が増えるサービス、受発注や予約などの業務データ、外部API連携、個人情報、24時間運用の経験が自社要件に近いかを確認します。公開できない案件でも、課題、規模、担当範囲、障害対応、移行後の改善指標を匿名化して説明できるかを見ます。

提案書では、Vitess系とPostgresのどちらを想定したか、採用理由、代替案、将来の移行可能性を質問します。製品名だけを並べる提案より、要件に対して採用しない条件まで説明できる提案の方が、長期運用のリスクを見極めやすくなります。

担当体制と保守範囲を契約前に固定します

担当者の役割を、プロジェクト責任者、業務設計者、アプリケーション開発者、DB設計者、セキュリティ担当、運用担当に分けて確認します。誰がスキーマ変更をレビューするのか、障害時に誰が一次切り分けをするのか、夜間休日の連絡先はどこかを、提案書と契約書に記載します。

保守費に含まれる範囲も重要です。監視、脆弱性対応、軽微な改修、PlanetScaleの料金変更への対応、バックアップ復元試験、障害報告、月次レポートが含まれるかを確認します。納品後にDBの知識が自社へ残らない状態を避けるため、設計書、ER図、データ辞書、運用手順書、移行手順書を引き継ぎます。

相見積もりでは同じ質問票で比較します

相見積もりでは、同じ要件一覧とデータ項目一覧を渡し、要件定義、設計、開発、移行、テスト、保守の金額を分けて出してもらいます。比較する質問は、VitessとPostgresの対応範囲、接続プール、負荷試験の方法、バックアップ復元時間、障害時のSLA、個人情報の取り扱い、開発環境の費用、追加レプリカや通信量の見積もりです。

価格が最も低い提案ではなく、前提条件が明確で、変更時の追加費用が説明され、運用担当が自社に残る提案を選びます。見積もりの安さが、テスト・移行・監視を削った結果でないかを確認すると、公開後の予算超過を防ぎやすくなります。

▶ 詳細はこちら：PlanetScaleのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：PlanetScaleのシステム開発の発注/外注/依頼/委託方法について

よくある質問（FAQ）

最後に、PlanetScaleのシステムを検討する際によくある疑問へ回答します。料金、既存DBからの移行、PostgresとVitessの選択は、初期相談で特に確認されやすい論点です。

PlanetScaleは無料で使えますか？

2026年8月時点では、公式のPostgres料金でSingle Nodeが月額5ドルから案内されています。無料利用を前提にせず、開発ブランチ、ストレージ、バックアップ、通信量、追加レプリカを含めた月額予算を用意します。為替変動もあるため、円換算は予算上の仮置きとし、契約前に最新の公式料金を確認します。

既存のMySQLからPlanetScaleへ移行できますか？

移行できる可能性はありますが、SQL互換だけで判断せず、外部キー、文字コード、トリガー、バッチ、ORM、接続方式、データ量を確認します。全件移行と差分同期を組み合わせ、移行リハーサルで件数・金額・時刻・重複を照合し、切り戻し手順まで確認してから本番切り替えを行います。

VitessとPostgresはどちらを選べばよいですか？

既存のMySQL資産を活かし、安全なスキーマ変更とオンライン移行を重視するならVitess系が候補です。PostgreSQLの拡張機能や既存ORM、分析基盤との互換性を優先するならPostgresを比較します。最終的には、実データに近い負荷試験と、開発・本番のDDL適用手順を確認して決めます。

開発会社へ依頼するときに何を準備すればよいですか？

業務フロー、利用者と権限、主要データ項目、既存DBの種類と容量、外部連携、ピークアクセス、RTO・RPO、個人情報の有無、希望リリース時期を準備します。すべてが決まっていなくても、未確定事項と優先順位を示すと、開発会社が調査・PoC・本開発の段階に分けて提案しやすくなります。

まとめ：PlanetScaleのシステムは要件と運用まで設計して選びます

PlanetScaleのシステムは、データベース運用の負担を抑えながら、Webサービス、SaaS、業務システムの成長に対応しやすい構成です。特に、ブランチとDeploy Requestによる安全なスキーマ変更を活かしたい案件、アクセスやデータが増える案件、アプリケーション開発へ集中したいチームで検討価値があります。

選定前に押さえる3つのポイント

第一に、Vitess系とPostgresではスキーマ変更の運用が異なるため、採用エンジンを要件から決めます。第二に、PlanetScaleの利用料と開発費、保守費、移行費、通信・バックアップ費を分け、TCOで比較します。第三に、個人情報、リージョン、RTO・RPO、負荷試験、復元試験、障害対応を開発会社との契約範囲へ落とし込みます。

小さく検証し、数字をそろえて本開発へ進みます

最初から大規模なシャーディングや複雑な高可用性構成を作るのではなく、実データに近いPoCで性能、料金、移行、復元、運用負荷を測ります。その結果をもとに、PlanetScaleを採用する範囲と、別のパッケージ・クラウドサービスで実装する範囲を決めることが、長く使えるシステムにつながります。