2026年10月8日にAWSのServerless Computing本文とNISTのクラウド定義を再確認した。サーバーレスはサーバーが存在しない意味ではなく、基盤のプロビジョニングや管理の一部を事業者へ委ね、イベント・リクエスト単位で実行する構成を含む。コールドスタート、実行時間・同時実行・通信、状態保存、監視、権限、料金、ベンダー固有の制約と障害時の再実行を設計し、運用責任が消えるとは考えない。
30秒で要点
サーバーレスは、サーバーが存在しない仕組みではありません。実行基盤の管理の一部をサービスへ委ね、アプリの処理を動かす方式です。どこまで委ねられるかは、サービスと実行方式で異なります。
- 管理するサーバー台数は減らせても、入力、権限、データ、障害対応の責任は残ります。
- 自動拡張には同時実行や接続先の上限があり、費用にも複数の要因があります。
- 同期HTTPと非同期イベントでは、成功の意味と再試行の責任を分けます。
本稿ではAWS Lambdaを具体例にします。仕様の数値は2026年10月4日の確認内容です。他社サービスや、Lambda内の別方式へそのまま当てはめないでください。
FaaSとBaaSでは、委ねる対象が違う
FaaS（Function as a Service）は、イベントなどに応じて関数を実行する基盤です。BaaS（Backend as a Service）は、認証やデータ保存などのバックエンド機能を利用するサービスの考え方です。一つのアプリで併用することもあります。
ただし「サーバーレス」という名称だけでは、料金体系、最小稼働数、利用できるランタイム、更新責任は決まりません。製品名の一覧より、使う機能と責任の境界を確認する方が採用判断に役立ちます。
表が収まらない場合は、横にスクロールできます
| 委ねやすい部分の例 | アプリ側で確認すること |
|---|---|
| 実行環境の用意と配置 | 対応ランタイム、依存関係、初期化の時間 |
| 要求に応じた実行環境の増減 | 同時実行上限、DB接続数、過負荷時の応答 |
| イベントの配送や再試行 | 重複、期限切れ、処理結果、回収担当 |
| 基盤の監視情報の提供 | 業務上の失敗検知、通知先、ログの保存と費用 |
マネージド認証を使っても、自社データのどの操作を許すかは別の判断です。認証と認可の分担はWeb認証入門で扱っています。
同期の返答と、非同期の完了を区別する
HTTP APIなら、利用者はその場の返答を待ちます。長い処理では、いったん受付IDを返し、後で完了状態を確認する設計が候補になります。その場合「受け付けた」と「処理が完了した」は異なる状態です。
Lambdaの非同期呼び出しでは、関数がエラーを返した場合の再試行だけでなく、成功したイベントを再び受け取る可能性も公式に説明されています。処理しきれないイベントには期限や最終失敗があり、回収先と調査手順が必要です。Lambdaの非同期エラー処理
注文や課金では、イベントIDや業務操作IDを使って、処理済みの結果と副作用を整合して記録します。「同じIDを見たら飛ばす」というメモリ内の配列だけでは、再起動や並列実行を扱えません。外部APIの応答が消えた場合も、相手が未処理と決めつけず照合します。
API Gatewayからの同期呼び出し、キューを読むイベントソースマッピング、Lambda自身の非同期呼び出しは別の経路です。再試行の主体と条件を、実際に使う経路の資料で確かめます。
実行時間と同時実行には、方式ごとの制限がある
Lambdaの通常のタイムアウト設定はデフォルト3秒、最大900秒です。公式資料には、Managed Instancesの非同期呼び出しや一部を除くイベントソースマッピングでは最大5,400秒という別条件もあります。「Lambdaはすべて15分」と一括しないことが大切です。タイムアウトの公式仕様
上限まで時間を延ばせば解決するとは限りません。外部APIやDBで待ち続ければ、同時実行の枠と費用を使います。呼び出し元が待てる時間、接続先の期限、関数全体の期限を合わせます。通常の処理時間だけでなく、大きな入力や遅い接続先でも確認します。
自動拡張しても、DBの接続上限は消えない
Lambdaの同時実行数は、その時点で進行中の要求の数です。平均的な目安は「平均の毎秒要求数 × 平均処理時間（秒）」で求められます。同時実行と拡張の説明
たとえば平均100件／秒で平均0.2秒なら、平均の同時実行は約20です。これは仮定を置いた計算で、必要容量の保証ではありません。集中アクセスや遅い要求の裾、再試行があれば増えます。関数が増えた結果、DB接続や外部APIの上限を先に使い切ることもあります。
初回実行や実行環境の追加では初期化が必要になることがあります。いわゆるコールドスタートの影響は、コード、依存関係、ランタイムなどによって変わります。初回と再利用時を分け、利用者が受け取る応答時間を測ります。
クラウドを使わず、HTTP処理の中身を確認する
以下はAPI Gateway HTTP APIのpayload format 2.0を想定した、公開の挨拶用ハンドラーです。認証もDB更新も行いません。秘密や利用者の入力をログへ丸ごと出さず、メソッドと名前の形式を確認します。実際のイベント構造はHTTP APIのLambda連携仕様を参照してください。
handler.mjsとして保存します。クエリのnameは省略可能で、指定時は空白を除いて1〜40 Unicodeコードポイントとします。同じキーの複数指定は拒否します。この単位は、画面に見える文字数と常に一致するわけではありません。
const reply = (statusCode, value, extraHeaders = {}) => ({
statusCode,
headers: { 'content-type': 'application/json; charset=utf-8', ...extraHeaders },
body: JSON.stringify(value),
});
export async function handler(event) {
const method = event?.requestContext?.http?.method;
if (event?.version !== '2.0' || typeof method !== 'string') {
return reply(400, { error: 'Unsupported event' });
}
if (method !== 'GET') {
return reply(405, { error: 'Method not allowed' }, { allow: 'GET' });
}
if (typeof event.rawQueryString !== 'string') {
return reply(400, { error: 'Invalid query' });
}
const names = new URLSearchParams(event.rawQueryString).getAll('name');
const name = names.length === 0 ? 'World' : names[0].trim();
if (names.length > 1 || [...name].length < 1 || [...name].length > 40) {
return reply(400, { error: 'Invalid name' });
}
return reply(200, { message: `Hello, ${name}!` });
}同じフォルダにcheck.mjsを置き、Node.js 24系でnode check.mjsを実行すると、200とJSONの挨拶を確認できます。外部通信もサーバーの起動も行いません。
import { handler } from './handler.mjs';
const response = await handler({
version: '2.0',
requestContext: { http: { method: 'GET' } },
rawQueryString: 'name=First%20byte',
});
console.log(response.statusCode, response.body);名前の省略、空文字、長すぎる名前、重複キー、POST、不正なイベントもローカルで確認しました。これは関数の入出力の検証であり、Lambdaへ配備した実績ではありません。.mjsとexportした関数の関係はNode.jsハンドラーの公式説明に沿っています。配備する場合のハンドラー指定はhandler.handlerです。
業務APIへ発展させるには、ルート設定、認証と対象データの認可、実行ロール、入力サイズ、タイムアウト、監視、濫用対策を追加して確認します。ローカルの成功だけを公開の判断材料にしないでください。
費用は、関数の実行料だけで比較しない
Lambda Functionsでは要求数と実行時間・割当メモリが費用要因になります。Provisioned Concurrencyのように事前確保した容量には、設定した量と時間に応じた料金があります。連携サービスや転送も別の費用です。Lambda料金ページ
表が収まらない場合は、横にスクロールできます
| 見積もりの項目 | 確認する前提 |
|---|---|
| 要求数 | 正常要求だけでなく再試行や不要な呼び出しも含むか |
| 実行時間とメモリ | 待ち時間や初期化、入力サイズでどう変わるか |
| 容量の事前確保 | 無通信の時間帯にも費用が残るか |
| API・キュー・DB・保存 | 読み書き回数、保持期間、最小容量はどうか |
| ログ・監視・ネットワーク | 保存量、転送経路、通知や調査に何が必要か |
| 運用作業 | 障害の照合、再処理、依存更新を誰が担うか |
単価はリージョン、方式、契約などで異なるため、ここでは固定金額を例示しません。通常時、集中時、再試行が増える障害時の3通りで使用量を見積もります。予算通知が届くことと、支出が自動で止まることも別です。
最初の候補は、結果と責任を追える処理にする
実行が短く、入力と出力が明確で、負荷に波がある処理は検討しやすい候補です。長時間動き続ける処理、厳しい遅延条件、特別なOS機能、継続的に高い負荷がある処理では、別の実行方式とも比較します。サーバーレスが必ず安いとは限りません。
まず一つの処理について、正常、入力不正、接続先停止、重複、期限切れを検証計画に並べます。それぞれで「返す状態」「保存する結果」「通知する担当」を決めます。アラートを受けても、どの業務を再処理してよいか分からなければ運用は止まります。
観測するのはHTTP応答だけではありません。重複除去した受付件数に対する業務完了件数、未完了の最古時間、応答時間の分布、期間あたりの費用と正常完了1件あたりの費用を分けます。利用者への結果と、基盤上の成功を照合してから対象を広げます。
処理の分割とデータ整合はマイクロサービス入門、更新と公開の条件はCI/CD入門、継続運用の担当と復旧は運用保守ガイドへ進んでください。