OpenShipはVercelの代替？AI SaaS部署判断

「フロントエンドは公開できたのに、Workerやデータベースの運用だけ別サービスになっている」という状態なら、配置先の見直し時期です。

今週は、個人開発ならVercelを継続し、Worker・データベース・自社サーバーが必要なAI SaaSだけをOpenShipへ小さく移して、ロールバックと運用工数を確認してください。OpenShipはVercelを一律に置き換えるものではありません。

最終更新：2026年8月1日。OpenShip公式サイト、公式ドキュメント、公開コードリポジトリ、およびVercel公式資料を照合して確認しています。OpenShipの製品形態、ライセンス、マネージド提供範囲は更新される可能性があるため、契約前に再確認してください。

チーム規模別の判断軸

OpenShipは、クラウド版、自社サーバー運用、両者を組み合わせる形を案内しています。自社のLinuxサーバーへSSHで接続し、コンテナを配置する構成も公式に説明されています。一方、マネージド版の料金や提供時期については、公式ページ上で「提供準備中」とされている箇所があります。したがって、2026年8月時点ではVercelとの月額料金を同じ条件で比較できません。(OpenShip公式サイト)

判断の入口は、次の3種類です。

• 個人開発者・試作段階：初回公開の速さと、障害対応を自分で抱えないことを優先します。
• 成長中のAI SaaSチーム：画面、API、Worker、データベース、キャッシュを一つの流れで管理できるかを確認します。
• データや権限が複雑な組織：配置地域、秘密情報、監査記録、Agentの操作範囲を先に確認します。

この分け方なら、「機能が多い方」を選ぶのではなく、「運用担当者が実際に責任を持てる方」を選べます。

個人開発者は速さと管理範囲を比較する

個人開発や短期の検証では、Vercelのプレビュー環境が強みになります。Gitリポジトリへの変更ごとに固有のプレビューURLを発行でき、Local、Preview、Productionという環境を分けて扱えます。公式資料では、デプロイごとのビルドログやエラー確認、既存デプロイの再実行も案内されています。(Vercelのデプロイ概要)

Vercelの料金体系も、用途によって判断が変わります。公式料金ページでは、Hobbyは個人・非商用向け、Proは月額20ドルからと説明されています。Proには利用クレジットが含まれますが、関数実行、データ転送、ビルド、ストレージなどは別々の使用量として確認する必要があります。(Vercel公式料金ページ)

OpenShipへ移す価値が出るのは、次のような場合です。

• 既存のVPSや社内サーバーを使いたい。
• WebアプリとWorkerを同じネットワークで扱いたい。
• データベースやオブジェクト保存先を自分で決めたい。
• サービス停止時に、プロバイダー側の制約ではなく自分で復旧したい。

反対に、LP、認証付きの小規模ダッシュボード、短期間の試作が中心なら、OpenShipを導入するためのサーバー更新、SSH鍵管理、監視設定、バックアップ確認が追加されます。公開までの時間だけを見ると、Vercelを継続した方が合理的です。

Workerとデータベースは画面表示以外を検証する

AI SaaSでは、画面が開くだけでは配置成功とは言えません。回答生成、非同期処理、利用量集計、メール送信、ファイル保存、再試行処理まで動かす必要があります。

OpenShipの公式サイトでは、PostgreSQL、Redis、MongoDB、MySQL、オブジェクトストレージ、スケジュール処理、ログ、メトリクス、ロールバックを同じ運用面で扱えると説明しています。また、ビルドしたイメージをSSH経由で対象サーバーへ送り、既存バージョンを残したまま切り替える仕組みも案内されています。これは、常駐WorkerやAPIを含む構成をまとめたいチームには有利です。(OpenShip公式サイト)

ただし、公式サイトの機能一覧は製品側の説明です。実際の本番性能や障害復旧時間を示す実測値ではありません。次の項目を自分のアプリで検証してください。

• Next.jsのビルドが毎回同じ条件で完了するか。
• APIコンテナとWorkerコンテナが別々に再起動できるか。
• Workerが途中で停止したとき、ジョブが重複実行されないか。
• データベース接続数が増えたとき、アプリが待ち状態にならないか。
• ログからリクエスト、ジョブ、例外を追跡できるか。
• 直前のバージョンへ再配置したとき、環境変数とデータが壊れないか。

Vercelでも、データベースを使えないわけではありません。公式資料では、PostgreSQL、Redis、NoSQL、ベクトルデータベースなどをマーケットプレイス経由で接続し、認証情報を環境変数へ注入する方式が案内されています。つまり、Vercelはフロントエンドだけのサービスではありませんが、データ基盤は外部サービスとの組み合わせになるため、請求先、障害窓口、リージョンを個別に確認する必要があります。(Vercelのストレージ資料)

自社サーバー運用は料金表ではなく月次台帳で比べる

自社運用では、OpenShip自体が公開コードとして提供されていることだけを見て「無料」と判断しないでください。公式サイトには、自社サーバー運用を無償で利用できる旨が記載されていますが、サーバー、通信、バックアップ、監視、ドメイン、障害対応の費用は別に発生します。(OpenShip公式サイト)

月次コストは、最低でも次の項目に分けます。

• アプリ用サーバーとデータベース用サーバー。
• 外部へのデータ転送と追加の固定IP。
• 世代バックアップと別地域への保存。
• メトリクス、ログ保存、通知サービス。
• OS、コンテナ、証明書、依存パッケージの更新。
• 夜間や休日に障害を見る担当者の時間。

Vercelは、Hobbyの非商用制限やProの月額料金、利用量に応じた追加課金を確認しやすい一方、使用量が増えると関数実行、データ転送、ビルド、ストレージの項目が分かれて増えます。OpenShipはサーバーを固定して運用しやすい反面、アクセス急増時のスケール設定や監視を自分で決めなければなりません。

権限とAI Agentは便利さより範囲を先に決める

OpenShipはMCP経由でAI Agentからデプロイ、ログ確認、ドメイン追加などを操作できると説明しています。公式ドキュメントでは、MCPのエンドポイントはPOST /api/mcpで、OAuth 2.1または個人アクセストークンを使い、呼び出しごとに権限を再確認するとされています。読み取り専用や、特定のプロジェクト・サーバーに限定したトークンも用意できます。(OpenShipのMCPドキュメント)

それでも、本番環境でAgentへ全面的な権限を渡すべきとは限りません。特に次の境界を決めてください。

• 本番デプロイは承認後だけ許可する。
• ログ閲覧と削除操作を別のトークンに分ける。
• データベースの接続情報をAgentのプロンプトへ渡さない。
• サーバー全体ではなく、対象プロジェクトだけを許可する。
• MCPの操作履歴を定期的に確認する。

OpenShip公式ページには、監査ログ、秘密情報管理、暗号化、コンプライアンス対応に関する説明があります。しかし、それだけで特定の認証や法令要件を満たすとは判断できません。必要な認証、保存地域、監査証跡、委託先の条件は、契約前に資料と設定画面で確認してください。

OpenShipの公式ページ間では、ライセンス表記に差があります。ダウンロードページではAGPL-3.0、トップページと公開リポジトリではApache-2.0と記載されています。商用利用や改変配布が関係する場合、現在のリポジトリ内のLICENSEとリリース版を確認し、表記差を解消してから採用してください。(OpenShipのダウンロードページ)

移行は三つの段階に分ける

いきなりProduction全体を移すのではなく、次の順番で進めます。これは、OpenShipの導入可否だけでなく、自社運用プラットフォームとしての適性を確認する手順です。

1. 現状の依存関係を洗い出す

vercel.json、環境変数、APIルート、Edge向け処理、Cron、ストレージ、データベース、外部認証を一覧化します。VercelのCronはProductionデプロイで実行され、Previewでは実行されない仕様があるため、移行後のスケジュール処理と同じ動作だと決めつけないでください。(VercelのCronジョブ資料)

2. 低リスク環境を先に配置する

ドキュメントサイト、管理画面のPreview、利用者の少ないAPIなどをOpenShipへ移します。メインの課金処理や本番データベースは、最初の検証対象から外します。

3. ビルドとヘルスチェックを確認する

トップページだけでなく、ログイン、API呼び出し、ストリーミング応答、Worker起動、データベース書き込み、キャッシュ、ファイル保存を確認します。ビルド成功率だけでなく、失敗時に原因をログから特定できるかも見ます。

4. ロールバックを実行する

意図的に不具合のあるリリースを配置し、直前のバージョンへ戻します。確認するのは「戻せたか」だけではありません。ドメイン、環境変数、Worker、データベースのスキーマが一致した状態で復旧できるかを確認します。

Vercelにも既存デプロイへドメインを戻すInstant Rollbackがあり、再ビルドを待たずに復旧する方式が案内されています。ただし、ロールバック時に環境変数が再ビルドされない点も公式資料に記載されています。両者を比べるときは、ボタンの有無ではなく、実際の障害復旧手順を比較してください。(Vercelのロールバック資料)

5. 運用工数を記録して拡大する

7日間程度の検証期間を設け、デプロイ、ログ確認、バックアップ確認、証明書更新、障害対応にかかった時間を記録します。この期間は本記事の判断用に設ける運用テストであり、OpenShipの公式性能値ではありません。

本番移行前の確認項目

次のチェックで、1つでも担当者が決まらない項目があれば、全量移行を延期してください。

• [ ] Next.jsのビルドコマンドとNode.jsのバージョンを固定した
• [ ] APIとWorkerの起動、停止、再起動を確認した
• [ ] データベースの接続先とバックアップ復元手順を文書化した
• [ ] Redisやキューの重複実行を検証した
• [ ] オブジェクト保存先と署名付きURLの有効期限を確認した
• [ ] Preview環境とProduction環境の秘密情報を分離した
• [ ] デプロイ失敗時のログを担当者が読める
• [ ] ロールバック後に環境変数とドメインを確認できる
• [ ] MCPやAgentの権限をプロジェクト単位に制限した
• [ ] OS更新、監視通知、バックアップ確認の担当者を決めた

自社の開発環境やAI Agentの運用分離まで検討する場合は、クラウド開発環境の選び方も合わせて確認してください。Agentを本番へ接続する場合は、AI Agentの本番環境セキュリティのように、権限分離と作業範囲を先に決めるのが安全です。

OpenShipとVercelの使い分け

• Vercelを継続する判断：フロントエンド、Next.js、プレビュー、エッジ配信を重視し、サーバー更新や監視を担当したくない場合。
• OpenShipを試す判断：Worker、常駐API、PostgreSQL、Redis、既存VPS、社内サーバーを一つの配置フローで扱いたい場合。
• 部分移行の判断：Previewや低リスクAPIだけをOpenShipへ移し、本番フロントエンドはVercelに残したい場合。
• 全量移行の判断：バックアップ、監視、権限、ロールバック、障害対応をチーム内で継続的に運用できる場合。

最初から「OpenShipはVercelより優れている」と考える必要はありません。AI SaaSの構成が複雑になるほど、どこで実行するかより、誰が障害時に復旧するかが重要になります。

Vercelはフロントエンド中心の開発で、プレビュー、エッジ配信、低い運用負担をまとめやすい反面、利用量に応じた課金、外部データサービスとの組み合わせ、基盤の配置自由度に制約があります。OpenShipは自社サーバー、Worker、データベース、混在環境を扱いやすい一方、サーバー費用、監視、更新、バックアップ、権限管理を自分で負担します。

そのため、今週の最適解は全量移行ではありません。まず低リスクのAI SaaS環境をOpenShipへ移し、ビルド成功率、ロールバック時間、月間の運用工数を記録してください。隔離したビルド環境や一時的な検証用サーバーが必要なら、Hashvpsのクラウド環境やリモートMacを含め、手元の開発環境と本番環境を分ける構成も候補になります。