はじめに
AWS Lambdaを使い始めたはいいものの、IAMロールの設定、API Gatewayとの紐付け、CloudFormationテンプレートの記述……と、コード自体よりも「配線」に時間を取られた経験はありませんか。マネジメントコンソールでポチポチ設定していくと、その環境は二度と同じ手順で再現できなくなり、チームに引き継ぐときにも苦労します。
この「配線疲れ」を解消するために生まれたのが、今回紹介するServerless Frameworkです。YAMLファイル1枚に関数・トリガー・権限をまとめて記述するだけで、AWS Lambdaを中心としたサーバーレス構成をコマンド1つでデプロイできます。2015年の登場以来、サーバーレス構築ツールの事実上の標準として使われ続けています。
Serverless Frameworkとは
Serverless Frameworkは、AWS Lambdaをはじめとするマネージドクラウドサービス上に、自動スケールし、アイドル時のコストがゼロになるアプリケーションを構築するためのCLIツールです。GitHubのスター数は約46.9k、フォーク数は5.7kと、サーバーレス領域のOSSとしてはトップクラスの規模を誇ります。
コアはNode.js製で、Node.js・Python・Java・Go・C#・Ruby・PHPなど幅広い言語のLambda関数に対応しています。2024年にリリースされたv4では、TypeScriptによるネイティブサポートやデプロイ差分表示、AWS SSOログインなどが追加され、現在も活発に開発が続いています（2026年8月時点の最新版はv4.40.0）。
主な特徴
- 宣言的なIaC -
serverless.ymlに関数・イベント・リソースを書くだけで、裏側でCloudFormationテンプレートが自動生成されます。手作業でのマネジメントコンソール操作が不要になります - 巨大なプラグインエコシステム - 1,000以上の公式・コミュニティプラグインが公開されており、オフライン実行やモニタリング連携などをコマンド1つで拡張できます
- マルチプロバイダー対応の設計思想 - AWSが主戦場ですが、フレームワーク自体は特定クラウドに縛られない設計になっており、他クラウド向けプラグインも存在します
インストール
Serverless FrameworkはNode.js製のCLIツールなので、npm経由でグローバルインストールするのが基本です。
npm install -g serverless
インストール後はsls（serverlessの省略コマンド）が使えるようになります。
sls --version
新規プロジェクトを作る場合は、テンプレートを指定してcreateするのが手早い方法です。
sls create --template aws-nodejs --path my-service
cd my-service
基本的な使い方
プロジェクトの心臓部がserverless.ymlです。ここに関数定義とトリガーとなるイベントを記述します。
# serverless.yml
service: my-service
provider:
name: aws
runtime: nodejs20.x
region: ap-northeast-1
functions:
hello:
handler: handler.hello
events:
- httpApi:
path: /hello
method: get
handlerが指すファイルには、実際のLambda関数の処理を書きます。
// handler.js
module.exports.hello = async (event) => {
return {
statusCode: 200,
body: JSON.stringify({ message: 'Hello from Lambda!' }),
}
}
準備ができたら、デプロイはコマンド1つです。
sls deploy
実行すると、API Gatewayのエンドポイント、IAMロール、CloudWatch Logsなど必要なAWSリソースがまとめて作成され、デプロイ完了後にエンドポイントURLが表示されます。ローカルで動作確認だけしたい場合は、実際にデプロイせずに関数を呼び出すこともできます。
sls invoke local --function hello
実践的なユースケース
Serverless Frameworkは書き方のパターンによって使い勝手が大きく変わります。代表的な3つの使い方を見ていきましょう。
環境ごとにステージを分ける
開発環境と本番環境を同じコードベースで管理したい場合、--stageオプションでデプロイ先を切り替えられます。
# serverless.yml
provider:
name: aws
stage: ${opt:stage, 'dev'}
environment:
TABLE_NAME: ${self:service}-${self:provider.stage}-users
sls deploy --stage dev
sls deploy --stage production
${self:provider.stage}のような変数参照を使うと、テーブル名やリソース名にステージ名を自動で埋め込めるため、開発環境と本番環境のリソースが衝突する心配がありません。
DynamoDBなど周辺リソースを一緒に定義する
Lambda関数だけでなく、DynamoDBテーブルのようなインフラリソースも同じYAMLの中で管理できます。
# serverless.yml
functions:
createUser:
handler: handler.createUser
events:
- httpApi:
path: /users
method: post
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:PutItem
Resource: !GetAtt UsersTable.Arn
resources:
Resources:
UsersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: ${self:service}-${self:provider.stage}-users
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- AttributeName: id
KeyType: HASH
BillingMode: PAY_PER_REQUEST
resourcesブロックの中身はCloudFormationの構文そのものなので、Lambda関数に必要な最小権限のIAMポリシーとDynamoDBテーブルを、1つのファイルの中で対にして管理できます。アプリケーションコードとインフラ定義が同じリポジトリ・同じレビューフローに乗る点が、コンソール操作との一番の違いです。
プラグインでローカル実行環境を再現する
デプロイのたびに動作確認するのは非効率です。serverless-offlineプラグインを使うと、API Gatewayの挙動をローカルでエミュレートできます。
npm install --save-dev serverless-offline
# serverless.yml
plugins:
- serverless-offline
sls offline
これでhttp://localhost:3000にローカルサーバーが立ち上がり、実際にデプロイすることなくAPIの挙動を確認できます。フロントエンドと並行して開発する際、デプロイ待ちの時間がなくなるのは大きな効率化になります。
まとめ
Serverless Frameworkの要点を振り返ります。
serverless.yml1枚で関数・イベント・インフラリソースを宣言的に管理でき、マネジメントコンソールでの手作業から解放されるsls deployひとつでCloudFormationテンプレートの生成からデプロイまで自動化される- ステージ変数やDynamoDB連携、
serverless-offlineなど、実務で必要になる仕組みが最初から揃っている
なお、v4からはライセンス体系が変わり、個人開発や年間売上2億円未満の組織は引き続き無料で使えますが、それを超える組織は有料サブスクリプションが必要になっている点は把握しておくとよいでしょう。AWS SAMやCDKと比較検討されることも多いツールですが、YAMLベースのシンプルさと巨大なプラグインエコシステムは、今なお「まずはこれで始める」選択肢として説得力があります。気になった方は、まずsls createで小さなAPIを1つデプロイしてみてください。