サーバーレスとは「待機をやめる」方式|得も制約も1行から導ける、非エンジニア向けのわかりやすい解説

結論から言います。サーバーレスは、サーバーを無くす仕組みではありません。自分でサーバーを24時間待機させておく、という役割をやめる方式です。ここさえ押さえれば、あとに出てくる「速い・遅い」「安い・高い」の話は全部そこから導けます。

サーバーレスとは サーバーレスとは、プログラムを動かすコンピュータを自分で用意して24時間待機させておく、という役割を手放す方式です。サーバー自体はサービス提供側に存在していて、アクセスが来た瞬間だけ動き、終わると片づけられます(次も同じものが使われるとは限りません)。待機していない時間の費用と管理の手間が消える代わりに、最初の1回は起動から始まるので遅い、1回あたりが長い処理には向かない、といった制約が付いてきます。

AIに業務アプリやホームページを作らせていると、「これはサーバーレスなので」という説明に出くわします。サービス名や機能の一覧から入ると、何の話なのかが最後まで掴めません。みやっち🧑‍💻は、この言葉は1行だけ覚えて、残りはその場で導くものだと考えています。

そもそもサーバーとは「24時間電源を入れて待っているコンピュータ」

サーバーレスを理解するには、先に「サーバー」を正確に押さえる必要があります。

サーバーとは、アクセスが来た瞬間に応答するために、24時間電源を入れて待機しているコンピュータです。あなたのホームページが深夜3時に表示できるのは、誰も見ていない深夜3時にも、そのコンピュータが電源の入った状態で待っているからです。

待機には、はっきりした代償があります。誰も来ない時間帯の費用がかかります。OSの更新や監視といった世話も必要です。アクセスが増える日に備えて、何台用意しておくかを事前に決めなければいけません。

ここまでを踏まえると、サーバーレスで消えたものが何かがはっきりします。消えたのはサーバーそのものではなく、「自分が待機させておく」という役割のほうです。だから「サーバーがいらない」という言い方は正確ではありません。正しくは「サーバーを持たない、選ばない、面倒を見ない」です。比べている相手は、自分で借りて常時起動させておく従来の方式です。

得も制約も、この1行から全部導ける

「待機をやめた」を出発点にすると、よく挙げられる長所も短所も、暗記せずに導けます。

「待機をやめる」と何が起きるか得られること付いてくる制約
使われていない時間はプログラムが動いていない動いていない時間のプログラムの実行費用がかからない次のアクセスは起動するところから始まるので、最初の1回が遅い(コールドスタート)
提供側が、来たアクセスに合わせて実行を自動で増やす台数を事前に決めなくてよい。急に増えても自分で足さない1回あたりに長くかかる処理は、動かした時間のぶん費用がかさみやすい
コンピュータを自分で持たないOSの更新も監視も台数の見積もりもしない動かせる時間の上限や同時に動かせる数など、提供側が決めた枠の中で作ることになる
終わったら片づけられる前の処理が残したものを引きずらない前回の続きを当てにできない(ステートレス)

この表は覚えるための表ではありません。1行から出てくるので、忘れてもその場で導き直せる、という形にしてあります。

なお、動かせる時間の上限が何分なのか、同時に何本まで動かせるのか、起動の遅さが実際にどれくらいなのかは、サービスごとに違いますし、更新も速い領域です。判断に使うときは、各社のドキュメントで現在値を確認してください。

「遅いなら、アクセスの多いサイトには使えない」は逆です

ここが一番よく誤解されるところです。「最初の1回が遅い」と聞くと、常時アクセスのあるサイトには向かないように聞こえます。実際は逆です。

2つの制約は、逆の状況で強く出るので、両方が同時に効くことはあまりありません。

  • アクセスがまばらなとき — 起動の遅さは出ます。ただし回数が少ないので、費用は問題になりません
  • アクセスが安定して多いとき — 動き続けているので、起動の遅さはほとんど表に出ません。効いてくるのは費用のほうです

ただし、アクセスが急に増えたときだけは例外で、増えた分は新しく起動するところから始まるので、そこには起動の時間が乗ります。常時多いこと自体は問題になりません。

つまり、判断軸は「速いか遅いか」ではなく、「回数」と「1回の長さ」の2つです。

  • 回数が多く、1回が一瞬で終わるもの(ページの表示、フォームの送信、アプリからの問い合わせへの応答)は得意です
  • 回数は少なくても、1回が長く続くもの(重いデータの一括処理、動かしっぱなしが前提の常駐処理)は苦手です

「サーバーレスは遅い」という言い方は、この2つを混ぜています。あなたが作ろうとしている社内ツールが、1回あたり何秒で終わるものなのか。そこだけ見れば判断できます。

前回の続きを当てにできないから、記憶を外に置くことになる

制約のうち、非エンジニアが一番つまずくのが「前回の続きを当てにできない」です。処理が終わった実行は、いつ片づけられてもおかしくありません。たまたま同じものが使い回されて前の状態が残っていることもありますが、残っている前提では作れない、というのが実際のところです。

だから、覚えておきたいものは外に置くことになります。サーバーレスでアプリを作ると、覚えておきたいものの種類に応じて、だいたいこの3つの置き場が要ります。

  1. ファイルの置き場 — アップロードされた画像やPDFのように、そのまま取っておきたいもの
  2. 表形式のデータベース — 顧客の一覧、申込の記録のように、行が増えていく形で貯まるもの
  3. 設定値の置き場 — 料金表や機能のオンオフのように、毎回読むけれど滅多に変わらないもの

AIが構成を提案してきたときに、見慣れないサービス名が3つも4つも並んでいて面食らうことがあると思います。あれは流行りの寄せ集めではなく、待機をやめた代償として必要になった部品です。この順番で見ると、提案の意味が読めるようになります。

業務アプリの場合、実際にはデータとログインをまとめて別のサービスに預ける形が多くなります。その具体的な作り方は非エンジニアが動く業務アプリをAIに作らせる記事にまとめてあります。

比喩はタクシーを使う。制約まで運べるから

サーバーレスの説明でよく使われるのが「電気」や「コンセント」です。使った分だけ払う、という一点は伝わりますが、そこで止まります。コールドスタートも、前回の続きを当てにできないことも説明できません。比喩は得だけを運ぶものではなく、制約まで運べるものを選んでください。

その条件を満たすのがタクシーです。

タクシーサーバーレス
乗った分だけ払う動いた分だけ費用がかかる
車検も洗車も運転手の手配もこちらの仕事ではないOSの更新も監視もしない
10人で出かけるなら10台呼べばいい増えたアクセスに合わせて提供側が実行を増やす
呼んでから到着するまで待つ最初の1回は起動から始まる(コールドスタート)
毎日長距離を走るなら自家用車のほうが安いずっと動かし続ける処理には向かない
降りたら荷物は置いていけない。次も同じ車が来るとは限らない前回の続きを当てにできないので、データは外に置く(ステートレス)

比喩がここまで運べると、説明を聞き直さなくても自分で判断できます。「これはタクシーで行く用事か、自家用車で行く用事か」に置き換えるだけです。

事業者としては、置くものと置かないものを分ければいい

仕組みの話は、ここまでで終わりです。あとは自分の事業で何をどちらに置くか、という判断だけが残ります。

サーバーレスに置くもの — 常時動かしておく必要がないもの。ホームページ、問い合わせフォーム、申込があったときの通知、月末だけ動く集計、お客さんが使う小さな画面。

サーバーレスに置かないもの — ずっと重い処理を回し続けるもの、動かしっぱなしが前提のもの。

この線引きが効いてくるのは、社内ツールを1本ずつ増やしていくときです。従来なら、ツールを1本作るたびに「すでにあるサーバーに相乗りさせる手間を引き受けるか、これだけのために1台増やすか」を先に決める必要がありました。使われていない時間は動かない方式なら、まず置いてみて、あまり使われなかったらそのまま置いておける。この方式に変えると、試作の敷居が一段下がります。

みやっち🧑‍💻の場合、このサイトを含む自社の2サイトをVercelで運用しています。2026年9月には構成を別の会社へ全面移行するかを検討して、見送りました。その判断の中身と、どこに置くかの比較はVercelとCloudflareの違いの記事に全部書いたので、置き場所を選ぶ段階の方はそちらを読んでください。この記事は言葉の意味だけを担当しています。

そもそも業務アプリを買うか外注するか自分で作るかで迷っている段階なら、業務アプリの作り方の記事のほうが先です。ホームページを自分で持つところから始めたい方はホームページを4時間で公開した実録が入口になります。作ったものを動く場所に配置して使える状態にする工程はデプロイという言葉で呼ばれています(公開もこの工程です)。

「知っている」ではなく、動いている状態を持つ

サーバーレスという言葉を正しく説明できるようになっても、それ自体は何も生みません。価値が出るのは、自分の業務の言い回しに合った小さなツールが、実際に動いてURLで開ける状態になったときです。

そしてこの方式が本当に効くのは、そういう小さなツールを何本も持っている人です。汎用のSaaSは他社の業務に合わせて作られているので、自社の言い回しに合わせるには限界があります。1本ずつ外注する形では、思いついた日に試す速さは出にくくなります。対話型のAIで作れるのは試作を共有するところまでで、自分の業務データや運用に合わせて使い続ける形にはなりません。Claude Code・Codexで自分で作れるようになって初めて、「待機をやめる」置き方が自分の事業の武器になります。

AI Crewでは、非エンジニアの経営者・個人事業主・士業が、自分の業務アプリを作って動かすところまで一緒に進めています。何から作るかを具体的に決めたい方は、まず無料セミナーでお会いしましょう。

関連記事

「AI Crew」は株式会社AI Orchestraの登録商標(登録第6942947号)です。