Serverless

概要

人感センサー付きの照明を思い浮かべてください。誰もいなければ消えていて、誰かが通りかかるとその人のために点灯し、また自動で消えます——自分でスイッチを押すことも、一晩中つけっぱなしにして費用を払うこともありません。サーバーレスはそのように動きます。個々の関数を書くと、クラウドプロバイダーは何かのトリガー（HTTPリクエスト〔ブラウザが送るのと同じ、Webのリクエスト〕、ファイルのアップロード、スケジュールされたタイマーなど）が発生したときだけそれを実行します。裏側には依然としてサーバーがありますが、それを目にすることも管理することもありません。コードが実際に実行された時間分だけ、しばしばミリ秒単位で課金されます。

強み

• プロビジョニング、パッチ適用、稼働維持すべきサーバーがない。
• ゼロから数千の同時実行まで自動でスケールする。
• 従量課金制で、アイドル状態のコードにはコストがかからない。
• クラウドイベント（キュー、ストレージ、データベース）ときれいに連携する。
• バースト的または予測しにくいトラフィックに向いている。

トレードオフ

• コールドスタート：最近実行されていない関数は、起動に余分な時間がかかることがある。
• 実行時間の制限（多くは数分）があり、長時間のジョブは除外される。
• 非常に高く安定した量では、素のサーバーと比べてコストが予想を超えることがある。
• ローカルでのテストとデバッグが、通常のアプリよりも厄介。
• ベンダーロックイン — 各プロバイダーのイベントモデルやAPIが異なる。

使いどころ

トラフィックが不均一で、インフラの面倒を見たくないAPI（アプリケーション・プログラミング・インターフェース——ほかのソフトウェアがあなたのアプリとやり取りするために呼び出す窓口）、Webhook、スケジュールジョブ、イベント駆動のタスクにはサーバーレスを選びましょう。クラウドサービス間のつなぎ込みコードで真価を発揮します。

バイブコーディングとの相性

サーバーレスは、作業の単位が単一の自己完結した関数であるため、AI主導の開発と相性が良いです。エージェントが生成、テスト、デプロイしやすいのです。AWS SAM、Serverless Framework、Vercelのようなフレームワークを使えば、AIは関数、そのトリガー、権限を1つの設定ファイルで定義できます。コツ：エージェントには妥当なタイムアウトとメモリサイズを明示的に設定させ、依存関係を最小限に保たせましょう。パッケージが少ないほどバンドルが小さくなり、コールドスタートが速くなります。

# serverless.yml — AWS Lambda 関数
service: my-api
provider:
  name: aws
  runtime: nodejs20.x
  timeout: 10
functions:
  hello:
    handler: handler.hello
    events:
      - httpApi:
          path: /hello
          method: get

# スタックをデプロイする
npx serverless deploy