PaaS — コードを置くだけ（Heroku / Vercel / Render）

📖 このページのゴール：PaaS（パース）＝プラットフォーム・アズ・ア・サービス（アプリを動かす“土台”をまるごと借りるしくみ）を、たとえ話でつかむ。「git push（ギット・プッシュ＝コードを送る操作）したら、もう動いている」というラクさと、その代わりに増える“ロックイン”という落とし穴を知る。 ← 目次・はじめにへもどる

🍕 ひとことのたとえ

PaaS は 宅配ピザです。

焼いて、家まで届けてくれるのはぜんぶお任せ（＝サーバーやOSの用意・運用はクラウドがやる）。
でも テーブルを用意して、飲み物を出すのはあなた（＝アプリのコードと、その中のデータは自分の担当）。

家でいうなら 家具付きの賃貸です。建物・水道・電気（土台）は大家さん持ち。あなたは荷物（アプリ）を運び込んで暮らすだけ。配線も水回りも自分でいじらない代わりに、模様替え（細かい改造）には制約があります。

🟢 キモは「git push したら動く」体験。前のページまでの「サーバーを借りて、OSを入れて、ミドルウェアを設定して…」がまるごと消える。コードを送れば、ビルド（組み立て）も起動も公開もクラウドが面倒を見てくれます。

あなたがやること：             クラウドがやること：
  コードを git push      →     ・コードを受け取る
  （あとは見てるだけ）          ・必要な部品を組み立てる（ビルド）
                              ・サーバーを用意して起動する
                              ・URL を発行して公開する
                              ・落ちたら再起動・台数も調整

🧩 どこまで自分で、どこからお任せ？

PaaS は「はしご」のかなり上の方（任せる側）。ランタイム（言語の実行環境）まではクラウドが用意してくれて、あなたが触るのはアプリのコードとデータだけです。

レイヤー（層）	だれの担当？
物理ハード／ネットワーク／仮想化	☁️ クラウド
OS（基本ソフト）	☁️ クラウド
ミドルウェア（DB・Webサーバー）	☁️ クラウド
ランタイム（言語の実行環境）	☁️ クラウド
アプリのコード	🙋 あなた
データ・設定・アクセス権（鍵）	🙋 あなた

🔑 鉄則はここでも同じ：どんなに任せても、データ・設定・アクセス権（鍵）は最後まであなたの責任。土台のセキュリティはお任せできても、アプリのバグ・公開してよいデータ・環境変数（かんきょうへんすう＝鍵やパスワードを入れておく設定値）の管理はあなたの仕事です。

🛠 代表的なサービス（実名）

サービス	ひとことで
Heroku（ヘロク）	PaaS の元祖。`git push heroku` で動く手軽さの代名詞
Google App Engine	Google のPaaS。アクセス増減に自動で追従
AWS Elastic Beanstalk	AWS 上でアプリを“置くだけ”に近づける土台
Vercel（バーセル）	フロントエンド／Next.js（ネクスト・ジェイエス）の定番。プッシュで即デプロイ
Netlify（ネットリファイ）	静的サイト・フロントに強い定番
Render（レンダー）	Heroku の乗り換え先として人気。Web・DB・バッチを一通り
Railway（レイルウェイ）	設定少なめでサクッと動かせる新顔
Fly.io（フライ）	アプリを世界各地に近い場所で動かせる

🔧 境界はあいまい：Vercel / Netlify は「PaaS＋サーバーレス」のハイブリッド（フロントは土台お任せ、裏側の処理は“使った分だけ”のサーバーレス的なしくみ）。分類はキッチリ分かれているわけではなく、「はしごのどのへんか」でとらえるのがコツです。

👍 向いている / 👎 向かない

👍 向いている	👎 向かない
速度が命：とにかく早く公開したい	OS・ミドルウェアを細かく制御したい
Web アプリ・API が中心	重い／特殊な処理（GPU・常駐の特殊プロセスなど）
運用を持ちたくない（当番・パッチを避けたい）	規模が出たときコストが急に膨らむのを避けたい
少人数・インフラ専任がいない	将来の乗り換えを軽くしたい（＝ロックインを避けたい）

💰 コスト感

無料枠〜従量課金（じゅうりょうかきん＝使った分だけ払う）。小さく始めるなら月0円〜で動かせることも多い。
ただし 規模が出ると急に高くなりがち。アクセスやデータが増えるほど料金も跳ね、IaaS（自分でサーバーを借りる）より割高になる局面があります。
だから 使用量と請求は“監視”が前提。「気づいたら高額」を防ぐため、利用量アラートを早めに設定するのが定石です。

🟢 安い＝総額が安い、ではない。少人数なら「運用の人件費が浮く」分も含めて、トータルで得かを見ましょう。

🔒 セキュリティ

土台（ハード・OS・ミドルウェア）の守りはお任せ＝あなたが守る範囲はぐっと減る。パッチ当ても基本クラウド側。
でも 減るだけでゼロにはならない。アプリ自体の脆弱性（ぜいじゃくせい＝攻撃される弱点）・公開してよいデータの線引き・環境変数に入れた鍵の管理は、引き続きあなたの責任です。

🔧 長期メンテ

日々のメンテは超ラク。サーバーの面倒見はクラウドがやってくれます。
ただし 使っているランタイムの EOL（イー・オー・エル＝提供終了）とバージョン追従は自分ごと。「古い言語バージョンが打ち切り」になったら、上げる作業は発生します。

⚠️ ロックイン（いちばんの落とし穴）

PaaS は便利な反面、そのサービス独自の機能に依存しすぎると、後で抜け出しにくくなります（＝ベンダーロックイン）。

独自の便利機能はほどほどに。標準的な作り（普通のDB・普通の構成）を保てば、いざという時の引っ越しが軽くなります。
「今は速度優先で割り切る／でも逃げ道は残しておく」——このバランス感覚が、PaaS と長くつき合うコツです。

🏢 誰が使う？

ペルソナ	PaaS との相性
大企業	△ 部分採用（一部のWeb・社内ツールで活用。基幹は別構成が多い）
中堅ベンチャー	◯ 一部に採用（スピードが要る所だけ PaaS、コアは IaaS/コンテナ）
スタートアップ	◎ 大本命（速度命・運用を持たない。例：Vercel など）
個人	◎ 最適（無料枠・メンテ最小で、作って即公開できる）

📝 ことばメモ

PaaS（パース）：アプリを動かす“土台”ごと借りるしくみ。コードを置けば動く。
git push（ギット・プッシュ）：コードをサーバーへ送る操作。PaaS ではこれが“公開ボタン”代わり。
デプロイ：作ったアプリを、実際に動く場所に配置して公開すること。
ランタイム：プログラムを動かすための言語の実行環境（例：Node.js・Python など）。
環境変数（かんきょうへんすう）：鍵やパスワードなどを、コードに直接書かずに入れておく設定値。
ベンダーロックイン：特定サービスの独自機能に依存し、他へ移りにくくなること。
EOL（イー・オー・エル）：そのバージョンの提供終了。来たら新しい版へ上げる必要がある。

🟢 ひとことで言うと

PaaS は 「git push したら動く」宅配ピザ型。土台（OS・ミドル・ランタイム）はぜんぶお任せで、あなたはコードとデータだけに集中できます。速度命の Web/API・少人数・運用を持ちたくない人に最適。ただし規模が出るとコストが急増しがちで、独自機能に頼りすぎるとロックインに。便利さに乗りつつ、逃げ道（標準的な作り）も残すのが賢い使い方です。

➡️ 次へ

次のページ：サーバーレス・BaaS — バックエンドごと借りる（Lambda / Cloudflare / Firebase / Supabase） → ← 目次・はじめにへもどる