タグアーカイブ Prisma

Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。

本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。

料金体系の基本比較

料金体系の基本比較

両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。

リクエスト単価(100万回あたり)
Prisma Compute $1.00 vs Vercel Pro $0.60
Vercelが約40%安い
メモリ単価(GB時間あたり)
Prisma Compute $0.006 vs Vercel Pro $0.0106
Prismaが約43%安い
CPU単価(vCPU時間あたり)
Prisma Compute $0.064 vs Vercel Pro $0.128
Prismaが半額
外向き帯域単価(GBあたり)
Prisma Compute $0.025 vs Vercel Pro $0.15
Prismaが1/6の価格
エッジリクエストとシート料金(ワークフロー)
Prisma Compute 無料 vs Vercel Pro エッジ $2.00/100万, シート $20/ユーザー/月
Prismaは開発者数やエッジ呼出に課金しない
Prisma Compute(予定価格)  Vercel Pro  Prismaが有利  Vercelが有利

リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。

実ワークロードでのコスト試算

実ワークロードでのコスト試算

月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。

Prisma Compute(予定価格)
リクエスト (2000万) $20.00
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
Vercel Pro(1シート)
リクエスト (2000万) $12.00
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
Prisma Compute ~$98  Vercel Pro ~$236  差額は約2.4倍。メモリ、CPU、帯域の単価差が総額を押し上げている。

この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。

料金差を生む構造的要因

料金差を生む構造的要因

なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。

ワークとワークフローの分離

ホスティング料金は「アプリが稼働中に行う実作業(ワーク)」と「デプロイやプレビューなど開発プロセス(ワークフロー)」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。

ワーク(アプリ稼働)
リクエスト / メモリ / CPU / 帯域
Prisma Compute 課金
Vercel 課金
ワークフロー(開発プロセス)
開発者シート / エッジリクエスト / デプロイ / プレビュー
Prisma Compute 無料
Vercel 課金
Prisma Compute  Vercel  差が生まれるのはワークフロー部分。特にシート料金は人数比例で拡大する。

Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。

データベース隣接配置によるエグレス抑制

Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。

一般的な構成(Before)
アプリ (Vercel等)ネットワーク越しDB (Supabase等)
アプリ-DB間通信が外向き帯域として課金
Prisma Compute(After)
アプリ (Prisma Compute) Prisma Postgres
同一基盤内で通信が完結。エグレスコストなし

データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行するAPIサーバーなどでは、Vercel+外部DB構成のエグレス費用が無視できなくなる。

開発者の声と注意点

開発者の声と注意点

VercelのFluid Computeは適合するワークロードでは大幅な削減効果を発揮する。リンク短縮サービスdub.coの創業者Steven Tey氏は、Xで「Vercelの利用タブが壊れたのかと思った」と述べ、Fluid有効化後に請求が50%減少したと報告している。

しかし、一部の開発者からは予想外の料金跳ね上がりに関する声も上がっている。Redditのr/nextjsスレッドでは、あるCTOがフロントエンドのみのNext.jsアプリの月額請求が「100ドル未満から800ドル超」に急増し、Cloudflare Workersへ移行後は「同じトラフィックで20ドル未満」になったと述べた。同スレッドでは「Vercelのフロントエンドは素晴らしく安いが、バックエンドは高すぎる」という見方や、Deployment Protection Exceptionsで150ドル請求された事例も共有されている。

好例
dub.coのSteven Tey氏
Fluid Computeを有効化 → 請求が50%減少
注意例
匿名CTO(Reddit)
フロントエンドのみのNext.jsアプリ → 月$100未満→$800超に急増
Cloudflare Workers移行後 → 同トラフィックで$20未満
開発者の不満は料金そのものより、請求の中身がワークフローの進行後に初めて可視化される点に集中している。

Prisma Computeはパブリックベータの段階であり、実際の課金が始まっていないため、利用者からの本格的なフィードバックはまだない。Prisma Blogの著者は、フィードバックが集まり次第、この比較記事を更新する意向を示している。

この記事のポイント

  • Vercelはリクエスト単価で優位だが、メモリ、CPU、帯域ではPrisma Computeが大幅に安い予定価格を提示している
  • 月間2000万リクエストの試算ではPrisma Computeが約98ドル、Vercel Proが約236ドルと2.4倍の開きがあった
  • 請求差の主因はワークフロー課金(シート料金、エッジリクエスト)とデータベース隣接によるエグレス抑制
  • VercelのFluid Computeは適切なワークロードで削減効果を発揮する一方、トラフィックに比例しない請求急増の事例も報告されている
  • Prisma Computeはまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる
Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Nextの早期アクセスが2026年5月22日に開始された。PostgresとMongoDBを対象に、データベース定義をコントラクトとして記述すれば、マイグレーションや型チェックをフレームワークが自動処理する。エージェントと連携する開発ワークフローにより、データ層の構築速度が大幅に向上する見込みだ。

開発者がコントラクトを書くと、あとはPrisma Nextがデータベースマイグレーション、クエリの型検査、エラー時の意味のあるメッセージを生成する。エージェントがコードを提案し、型検査を通過することで、安全なクエリが担保される仕組みだ。

1行のコマンドで始まるオンボーディング

1行のコマンドで始まるオンボーディング

新しいフレームワークを習得するには、ドキュメントを読み、小さなプロジェクトで試行錯誤を重ねる。慣れるまでに数週間を要することも多い。Prisma Nextはその学習曲線を1行のコマンドで解消する。npm create prisma@next を実行すれば、プロジェクトの骨組みと、エージェントを即座に専門家にする多数のスキルが自動生成される。

npm create prisma@next

ドキュメントを熟読する代わりに、エージェントがフレームワークの慣用句をリアルタイムに提示する。質問があればエージェントに尋ねればよく、コマンドの意味や設計の意図をその場で説明してくれる。まるで熟練者が隣で教えてくれているような体験だ。

従来のフレームワーク学習
STEP 1 ドキュメントを通読する
STEP 2 小さなサンプルを作成する
STEP 3 エラーを修正しつつ慣用句を覚える
Prisma Nextのオンボーディング
STEP 1 npm create prisma@next を実行
STEP 2 エージェントがプロジェクトとスキルを構築
STEP 3 質問があればエージェントに聞くだけ
従来は3週間かかっていた学習が、数分で開発を始められる状態になる。

既存プロジェクトへの導入

既存のプロジェクトに追加する場合もnpx prisma-next@latest initで簡単にセットアップできる。その後、エージェントに「読んでいる本を追跡する小さなアプリを構築して」と指示するだけで、スキーマ定義からクエリ作成までを自律的に進める。

コントラクトを書けばデータベース管理はフレームワーク任せ

コントラクトを書けばデータベース管理はフレームワーク任せ

Prisma Nextの中心にあるのが、アプリケーションとデータベースの間の契約であるコントラクトだ。開発者はモデルを定義するだけで、クエリの型検査や自動補完、そしてデータベースマイグレーションの計画と実行をフレームワークに委ねられる。

// contract.prisma
model Book {
  id       String   @id @default(uuid())
  title    String
  author   String
  addedAt  DateTime @default(now())
}
コントラクト(contract.prisma)
アプリケーション 依存関係 データベース 契約に従ってデータを保管
自動化されるタスク
クエリの型検査
自動補完
マイグレーション計画の生成
データベースとの整合性維持
開発者はコントラクトを編集するだけで、データベースとの一貫性が保たれる。

このコントラクトは可読性が高く、更新も容易だ。Prisma Nextではこれが唯一の真実の情報源となる。モデルを変更すると、フレームワークが自動的にマイグレーションを計画し、データベースが常にコントラクトを満たすように調整する。

エージェントによる機能追加の流れ

「著者テーブルを追加し、名前と経歴を持たせ、書籍と紐付けてほしい」といった自然言語での指示をエージェントに与えるだけで、コントラクトが更新される。エージェントは型検査を通過するまで内部でクエリの検証を繰り返し、最終的に安全なコードを出力する。

型安全クエリと高速な反復開発

型安全クエリと高速な反復開発

Prisma Nextのクエリはすべてコントラクトに対して型検査される。開発者(あるいはエージェント)がクエリを書くと、型エラーが即座にフィードバックされる。このループが高速なため、アプリケーションの出荷速度が格段に上がる。

const books = await db.orm.Book
  .where({ addedThisWeek: true })
  .all();

このクエリは、コントラクトで定義されたBookモデルに基づいて型が決定される。エージェントが生成したクエリも同じ型検査を通過するため、人間が書いたコードと同等の安全性が保証される。

クエリ作成の反復ループ
1 エージェントがクエリを書く
2 型検査による即時フィードバック
3 型検査を通過したクエリが確定
4 データベースが対応可能な安全なクエリ
エージェントはツール呼び出し内でこのループを自律的に繰り返す。

マイグレーションを記述する必要がなくなる

マイグレーションを記述する必要がなくなる

データベースのマイグレーションは、多くの開発者にとって最も苦痛を伴う作業の一つだ。構文を正しく記述し、エラーをデバッグし、本番環境で失敗した場合にはさらに時間を費やす。Prisma Nextでは、この負荷から完全に開放される。

マイグレーション作業の変化
従来の方法(Before)
SQLマイグレーションファイルを手動で記述
構文ミスやデプロイ時のトラブルシューティング
本番障害発生時に復旧作業
Prisma Nextの方法(After)
エージェントがコントラクトを編集
フレームワークがTypeScriptマイグレーションを自動生成
トランザクションで安全に適用(Postgres)
エージェントは意図を伝えるだけで、実際のマイグレーションコードは書かずに済む。

TypeScriptで書かれたマイグレーションファイル

生成されるマイグレーションファイルはTypeScriptで記述され、人間が確認しやすい形式だ。prisma-next migration plan を実行すると、ops.json とともにレビュー可能なマイグレーションが出力される。エージェントがSQLを生成するのではなく、フレームワークが決定論的に生成するため、信頼性が高い。

// migrations/app/20260515T0900_add_book_published_at/migration.ts
export default class M extends Migration {
  override describe() {
    return { from: "sha256:…prev", to: "sha256:…next" };
  }

  override get operations() {
    return [
      addColumn("public", "book", {
        name: "publishedAt",
        typeSql: "timestamptz",
        defaultSql: "",
        nullable: true,
      }),
    ];
  }
}

Postgresでは、マイグレーション全体が単一のトランザクション内で実行される。どこかで問題が発生してもロールバックされ、データベースは元の状態を保つ。MongoDBの場合は段階的に安全な手順で計画される。こうした保護機構によって、エージェントに安全に作業を委任できる。

並行ブランチでのマイグレーション競合を自動解決

並行ブランチでのマイグレーション競合を自動解決

複数ブランチで同時にマイグレーションを作成すると、マージ時に順序の衝突が起きることがある。Prisma NextはGitのコミットグラフのようにマイグレーション履歴を扱い、この問題を解消する。

ダイヤモンド型マイグレーショングラフの例
main
branch A のマイグレーション
branch B のマイグレーション
main(両方マージ後)
フレームワークはこの形状を理解し、正しい適用順序を自動的に判断する。prisma-next migration graph で可視化できる。

prisma-next-migration-review スキルをエージェントが活用することで、新しいマイグレーションがmainに到達した場合も、グラフを読み取り、ブランチをリベースし、migration planを再実行する。結果として、衝突なくクリーンにマージできる。複数のエージェントが並行して作業しても、特別な手順を覚える必要はない。

定期的なアップグレードとフィードバックの簡便さ

定期的なアップグレードとフィードバックの簡便さ

Prisma Nextは日々アップデートされており、アップグレードも簡単だ。エージェントに「prisma nextをアップグレードして」と指示するだけで、最新バージョンに更新してくれる。問題が見つかった場合も、エージェントに「これはバグだ」「この機能が欲しい」と伝えれば、適切な報告チャンネルを選び、構造化されたフィードバックを提出してくれる。

コミュニティでの成果発表も歓迎されている。Prismaの公式アカウントで紹介されたり、Prisma NextのREADMEにリンクが掲載される可能性もある。本格的にデプロイする場合、Prisma Postgresの無料枠を活用できる。なお、Prisma Nextはまだ本番環境向けではない。プロダクションには引き続きPrisma 7を推奨するが、一般提供時にはPrisma 8となる予定だ。

この記事のポイント

  • Prisma NextはPostgresとMongoDBに対応し、データベース定義をコントラクトとして扱う
  • 1行のコマンドでプロジェクトをセットアップし、エージェントが即座に開発を支援する
  • 型安全クエリにより、人間とエージェントのどちらが書いたコードも信頼できる
  • マイグレーションはフレームワークが自動生成し、トランザクションで安全に適用される
  • 並行ブランチでの競合もグラフベースの履歴管理で自動解決される