WEBツールをどこにおこう？実行環境サービス徹底比較

Webツールを公開するとき、ついこう考えがちです。
「ブラウザで使うものなんだから、NetlifyやVercelに載せればすぐ動くだろう。」
その認識は半分は正しいが半分違います。
フロントエンドの見た目が同じでも、裏側で何をしているかによって、必要な実行環境はまるで変わる。Puppeteer のように、サーバー側でブラウザそのものを起動して処理する仕組みを使う場合、この差はかなり大きくなります。

見た目は静かでも、裏で動いているのは重機。
そこを見落として環境を選ぶと「ローカルでは動くのに本番で動かない」という、実に腹立たしい事故が起きます。その場合の犯人はだいたい「コードじゃなく環境による」というものです。

Puppeteerとは

PuppeteerはただのJavaScript処理ではありません。Puppeteerは、Node.jsからブラウザを自動操作するためのライブラリです。
ページを開く、クリックする、JavaScript実行後の画面を取得する、スクリーンショットを撮る、PDFを生成する。そういった操作をコードで行えます。
ここで重要なのは、Puppeteerが単独で何かを完結させているわけではないこと。Puppeteerは、裏で Chrome や Chromium を実際に起動し、それを遠隔操作しています。これは単なる文字列処理やAPI通信ではありません。サーバーの中でブラウザを一台立ち上げて仕事をさせているということです。

この時点で、必要になるのは「Node.jsが動く環境」ではなく、ブラウザを起動できるだけの実行環境です。ここを雑に扱うと、デプロイ先で派手にコケます。

Chromiumとは

ここで出てくる Chromium は、Google Chromeの土台になっているオープンソースのブラウザプロジェクトです。ざっくり整理すると、以下のように比較できます。

Chrome	Googleが提供する製品版ブラウザ
Chromium	Chromeのベースになるオープンソース版
Puppeteer	Chrome / Chromium を自動操作するための仕組み

Puppeteerを使うというのは、裏で本物のブラウザ本体を動かすことになります。ゆえに、重い。軽い顔して、実際はブラウザ一式を抱えているんです。

比較軸は「軽い処理」か「重い実行環境」か

実行環境サービスを比較するとき、重要なのは知名度ではなく見るべきは、次の4点かと思います。

• ブラウザ本体のような重い依存を扱えるか
• 実行時間に余裕があるか
• OSレベルのライブラリやバイナリを入れられるか
• 毎回短時間で終わる処理を前提にしていないか

この軸で見ると、各サービスの向き不向きはかなりはっきりします。

選択肢① Netlify / Vercel – 軽快だが、重量級処理には不向き

NetlifyやVercelは、静的サイト配信や軽いサーバーレス処理に非常に強いサービスです。HTML / CSS / JavaScript を配る、フォームやWebhookをさばく、ちょっとしたAPIを動かす。こうした用途では優秀です。ただし、Puppeteerのように ブラウザを起動してレンダリングする処理 になると話が変わります。

理由はシンプルで、

• 実行時間に制限がある
• メモリやディスク容量に上限がある
• 大きなバイナリやネイティブ依存が扱いにくい
• コールドスタート時のブラウザ起動コストが重い

といった制約が直撃するからです。

短距離走の選手に長距離走らせるのは向いてません。そんな感覚でいいかと思います

選択肢② Render / Cloud Run – Puppeteer向きの本命

一方で、RenderやCloud Runは、Puppeteerとかなり相性がいいです。
その理由は、コンテナやサーバーに近い形で実行環境を丸ごと持ち込める からです。

このタイプのサービスでは、

• Chromiumをインストールできる
• 必要な依存ライブラリを揃えられる
• フォントやシステム設定も含めて管理しやすい
• サーバーレスより重い処理に耐えやすい

といった利点があり、Puppeteerに必要な「ブラウザを動かせる箱」を、最初から用意しやすいんです。
これが決定的に大きい上にRenderは導入しやすく、手早く公開したいときに強いです。Cloud Runは拡張性や安定性も見据えやすく、より本格運用向きです。

「今すぐ動かしたいならRender」
「後から伸ばしたいならCloud Run」
この見立てはかなり実務的だとおもいます。

選択肢③ Fly.io・Railway・Lambda – 中間層の選択肢

RenderやCloud Runほど王道ではないが、選択肢として有力なのがこのあたりです。

Fly.io	コンテナやVMを柔軟に扱え、リージョン分散にも強い。 Puppeteerのような常駐寄りの処理とも相性がいい。一方で、運用や課金の感覚はやや玄人寄りで、気軽さだけならRenderのほうが素直。
Railway	構築は比較的ラクで、小規模に始めやすい。Dockerベースで組めるなら、Puppeteer運用も現実的。ただし、常駐コストや無料枠の考え方は事前に見ておいたほうがいい。
AWS Lambda	イベント駆動との相性は抜群だが、Puppeteer用途では少し癖がある。 コンテナイメージ運用なら現実的になる一方、コールドスタートやブラウザ起動コストとの戦いになりやすい。「Lambdaだから万能」というより、設計次第で使える くらいに見ておくのが安全。

選択肢④ Cloudflare Workers – そもそも土俵が違う

Cloudflare Workersは、エッジで超高速に動く軽量処理に強い。キャッシュ制御、リクエストの書き換え、認証まわり、軽いAPI。そういう用途では非常に優秀です。ただし、Puppeteerのように ブラウザ本体を起動する前提の処理 とは思想が違います。

結局、どのサービスを選ぶべきか

用途別に整理すると、判断はかなりシンプルになります。

• 静的サイトや軽いAPI中心
  → Netlify / Vercel
• Puppeteerでスクショ・PDF・レンダリングが必要
  → Render / Cloud Run
• イベント駆動やAWS基盤に寄せたい
  → Lambda（設計に工夫が必要）
• エッジ処理を最優先したい
  → Cloudflare Workers（Puppeteer用途は基本別案）

選ぶべきなのは「有名なサービス」ではなく、その処理の重さと性質に合った器です。

技術選定の本質は、コードではなく環境

Puppeteerが動かないと、多くの人はコードを疑います。だが実際には、コードではなく 実行環境の選定ミス であることが少なくありません。見た目の手軽さやサービスの有名さではなく。そのサービスが、どこまで処理を現実的に受け止められるかを見てください。