Serverless Frameworkは、AWS LambdaやAPI Gatewayなどサーバーレスのリソースを設定ファイル1枚で定義し、コマンド一つでデプロイできるCLIツールです。2024年のv4からは料金体系が変わり、組織の年商によっては有料になりました。この記事では、基本の仕組みに加えて「v4の料金」「無料で使える条件」「v4での正しい使い方」「Pythonでの依存同梱」「有料化後の無料の代替」までを、2026年10月時点(本体4.43系)の公式ドキュメントとnpmの公開情報で確かめた内容で整理します。コマンドと設定はそのまま貼り付けて試せる形で載せています。
まとめ:v4は年商200万ドル以下なら無料・課金回避ならoslsかSAM
結論から書きます。Serverless Framework v4は、直近会計年度の年商が200万ドル以下の組織なら無料で使えます。超える組織は有料サブスクリプションが必要で、課金単位は「Lambda関数の数」ではなく「サービスインスタンス(service+stage+region)の数」です。v3はすでに保守が終わっているため、本家を使うならv4が前提になります。
課金を避けたい場合の現実的な逃げ道は2つです。既存のserverless.yml資産をそのまま動かしたいならOSSフォークの「osls」、これから純AWSで新規に作るなら無料のAWS SAMかAWS CDKです。なお、v4ではプロジェクト作成と認証のコマンドがv3から変わっています。古い記事のserverless createやserverless config credentialsをそのまま打つと手順が合わないので、本記事の手順で進めてください。
Serverless Frameworkの仕組みとserverless.ymlの役割
Serverless Frameworkは、サーバーレスアプリケーションの構成をコードとして管理するためのフレームワークです。中心になるserverless.ymlに、サービス名・プロバイダ・関数(functions)・トリガー(events)・付随リソース(resources)を宣言する形です。デプロイ時にはこの定義からAWS CloudFormationのテンプレートが生成され、Lambdaや周辺リソースが1つのスタックとして作成・更新されます。サーバーレス全体の構成パターンと採用判断はサーバーレスアーキテクチャの解説で、実行基盤であるLambda自体の料金とコールドスタートはAWS Lambdaの解説で整理しています。
serverless.ymlの最小構成とCloudFormationへの変換
操作はすべてserverless(短縮形sls)コマンドで行います。HTTPでGETを受けてJSONを返すだけの最小構成は次の2ファイルで動きます。ランタイムは、Lambdaで2025年9月1日に廃止されたnodejs18.xではなく、現行のnodejs22.xを指定しています(AWS Lambdaのランタイム一覧では、nodejs20.xも2026年4月30日に廃止済み)。
# serverless.yml
service: my-service
frameworkVersion: "~4.43.0"
provider:
name: aws
runtime: nodejs22.x
region: ap-northeast-1
functions:
hello:
handler: handler.hello
events:
- httpApi:
path: /hello
method: get
// handler.js
module.exports.hello = async (event) => ({
statusCode: 200,
headers: { "content-type": "application/json" },
body: JSON.stringify({ message: "ok", path: event.rawPath }),
});
この定義で、HTTP APIの/helloにGETが来るとLambda関数helloが呼ばれます。frameworkVersionは書いておくのが安全です。v4のCLIは24時間ごとに自動更新される仕様で、公式は「パッチ版ではなくメジャーかマイナーで固定する」ことを推奨しています(公式のセットアップガイド)。
v4で対応クラウドがAWSのみになった経緯とマルチクラウドの代替手段
かつてはAzureやGoogle Cloudにも対応していましたが、v4ではAWS以外のプロバイダ対応が打ち切られました。公式のv4アップグレードガイドにも、AWS以外のクラウドのサポートを終えたと明記されています。実質的にAWS専用ツールなので、マルチクラウドを1つの記法で扱いたい場合はTerraformでAWSを構築する手順のようなIaCツールが候補になります。
Serverless Framework v4の料金体系と無料で使える年商条件の確認
v4でもっとも注意すべき点が料金です。CLIを使うにはアカウント認証かライセンスキーが必要になり、組織単位で無料か有料かが分かれます。数値は公式の料金ページの2026年10月時点の記載です。
無料で使える組織の判定条件と直近会計年度の年商200万ドル以下の基準
公式の基準では、直近会計年度の年商が200万ドルを超える個人・組織はサブスクリプションの購入が必要です。逆にいえば、200万ドル以下なら無料で使えます。個人開発者やスタートアップの多くはここに当てはまります。判定は会社・団体単位で、自己申告制です。無料の範囲でもアカウント登録とserverless loginでのサインインは求められます。
受託開発では、誰の組織のアカウントで運用するかを契約前に決めておくと、年商判定で迷いません。
クレジット課金の単価4ドルとサービスインスタンス数による試算
有料時の課金はクレジット制です。1クレジットは「10日を超えて稼働した1つのサービスインスタンス」に対応し、Lambdaの関数数や呼び出し回数では課金されません。サービスインスタンスとは、service・stage・regionの組み合わせ1つ(=CloudFormationスタック1つ)のことです。
| 項目 | 2026年10月時点の公式記載 |
|---|---|
| 従量単価 | 1クレジットあたり4ドル |
| 予約購入の割引 | 1年最大29%・2年最大77%・3年最大80% |
| 予約時の最安単価 | 1クレジットあたり1ドルまで |
| 小規模事業者割引 | 年商500万ドル未満などで追加35% |
小規模事業者割引の条件は、年商500万ドル未満・従業員30人未満・調達額500万ドル未満の3つです。試算の例を挙げます。5つのサービスをdev・stg・prodの3ステージで東京リージョンに置くと、サービスインスタンスは15個です。従量単価なら月15クレジット×4ドルで60ドルになります。プルリクエストごとに一時ステージを立てる運用では、10日を超えて残ったステージもクレジットを消費します。不要なステージをserverless removeで消す運用まで含めて見積もってください。
v3の保守終了とv4移行時に既定設定で動かなくなるビルド系プラグイン
公式のv4アップグレードガイドによれば、v3は2025年初めの時点で保守を終えており、セキュリティ修正もバグ修正も提供されません。v4ではビルドツールのesbuildが本体に組み込まれ、TypeScriptのハンドラを追加設定なしでビルドします。その代わり、serverless-esbuild・serverless-webpack・serverless-plugin-typescriptのようにコードをビルドするプラグインは、既定のビルドを外さない限り動きません。esbuildの詳細設定(build.esbuild配下のminify・external・formatなど)はビルド設定のドキュメントに一覧があります。
あわせて、CLI認証の必須化と.envの自動読み込みも入りました。ローカル専用の値を.envに置いていた案件は、本番デプロイに混ざらないか移行前に確かめてください。
v4のインストールからAWSデプロイまでを実際のコマンドで試す手順
ここからは導入から初回デプロイ、削除までを最小手順で通します。本体のnpmパッケージ4.43.0のengines指定はNode.js 18.17.0以上です。ただしNode.js 18はLambda側でも廃止済みなので、手元も22系以降にそろえておくと迷いません。
npmでのインストールとserverlessコマンドによる雛形の作成
v4ではserverless create --templateが公式のCLIリファレンスから外れ、引数なしのserverlessコマンドが対話形式でテンプレート選択からAWS認証まで案内する形に変わりました。テンプレートには「AWS / Node.js / HTTP API」「AWS / Python / Flask API」などが並びます。
npm i -g serverless
serverless --version
# 対話形式でテンプレート選択・サービス名入力・ログインまで進む
serverless
公式ガイドによると、npm 12以降はパッケージのinstallスクリプトを既定でブロックする仕様です。警告が出ても初回のserverless実行時に本体が取得されます。事前に取得するならnpm i -g --allow-scripts=serverless serverlessを使います。社内プロキシ環境では、CLIがinstall.serverless.com・core.serverless.com・api.serverless.comの3ホストへ443番で通信するため、事前に許可が必要です。
serverless login awsでのAWS認証情報設定とCI用のライセンスキー
AWSの認証は、対話セットアップの途中で設定するか、serverless login aws(IAM Identity Centerならserverless login aws sso)で行います。既に~/.aws/credentialsや環境変数AWS_PROFILEでプロファイルを使い分けているなら、それがそのまま参照されます。v3時代のserverless config credentialsは、v4の公式CLIリファレンスに載っていません。
CIではブラウザでのログインができないため、ライセンスキーを渡します。ライセンスキーのドキュメントでは、環境変数SERVERLESS_LICENSE_KEYに設定する方法と、serverless.ymlのlicenseKeyからSSMパラメータストア等を参照する方法が案内されています。
# GitHub Actionsのジョブ内の例(キーはリポジトリのシークレットから注入)
# AWSの認証は別ステップ(OIDCでのロール引き受け等)で済ませておく
- name: Deploy
run: |
npm i -g serverless
serverless deploy --stage prod --region ap-northeast-1
env:
SERVERLESS_LICENSE_KEY: ${{ secrets.SERVERLESS_LICENSE_KEY }}
serverless deployでのステージ・リージョン指定とスタックの上限
デプロイコマンドを実行する場所は、雛形のディレクトリです。--stageで環境を、--regionでリージョンを切り替えます。完了すると払い出されたエンドポイントURLが表示されるので、curlで叩いて動作を確かめます。
serverless deploy --stage dev --region ap-northeast-1
# 表示されたURLにアクセスして応答を確認
curl https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/hello
# クラウド上の関数を直接呼び出してログも表示
serverless invoke -f hello --log --stage dev
# 試し終えたらスタックごと削除(クレジット消費も止まる)
serverless remove --stage dev
初回はスタックの新規作成、2回目以降は差分更新です。デプロイ時には、スタックに含められるリソース数の上限に注意してください。CloudFormationのクォータでは1テンプレートで宣言できるリソースは500個までです。関数1つにつきLambda本体・ロググループ・権限・API Gatewayのルートなど複数のリソースが生まれるので、関数が数十個になったらサービスを分割する設計にしておきます。
Lambda・DynamoDB・API Gatewayを組み合わせたREST APIの組み立て方は、AWSサーバーレスのハンズオンで手順を追えます。
serverless-offlineとinvoke localでのローカル確認
デプロイ前の確認には、関数単体ならserverless invoke local -f hello、API全体ならserverless-offlineプラグインを使います。serverless-offlineの14系はpeerDependenciesがserverless ^4.0.0で、v4向けです(2026年9月時点の最新は14.8系)。
npm i -D serverless-offline
# serverless.yml に追記
# plugins:
# - serverless-offline
serverless offline --stage dev
curl http://localhost:3000/hello
v4には、実際のAWS上のイベントを手元のコードへ中継するserverless devもあります。IAM権限やSQSなど、ローカルで再現しにくいイベントの確認に向きます。
PythonでServerless Frameworkを使うときの依存ライブラリの同梱方法
Serverless FrameworkはPythonのアプリケーションにも対応しているツールです。serverlessの対話メニューで「AWS / Python / Starter」などを選ぶと、handler.pyとserverless.ymlの雛形が生成されます。runtimeはpython3.13やpython3.12など、AWSのランタイム一覧でサポート中のものを指定します。
v3時代との大きな違いは依存ライブラリの扱いです。以前はコミュニティ製のserverless-python-requirementsプラグインが必須でしたが、v4のPythonサポートでは同等の機能が本体に組み込まれ、「外部プラグインは不要」と明記されています。requirements.txtのほか、Pipenv・Poetry・uvのプロジェクトにも対応します。有効化にはcustom.pythonRequirementsブロックを置いておく必要があり、中身は空でも構いません。
# serverless.yml(Python版)
service: py-service
frameworkVersion: "~4.43.0"
provider:
name: aws
runtime: python3.13
region: ap-northeast-1
functions:
hello:
handler: handler.hello
events:
- httpApi:
path: /hello
method: get
custom:
pythonRequirements:
# macOS・WindowsではDockerでLambda互換のビルドを行う
dockerizePip: non-linux
NumPy・Pandas・psycopg2のようにC拡張を含むライブラリは、macOSやWindowsでビルドするとLambda(Amazon Linux)上で動かないことがあります。dockerizePip: non-linuxは、Linux以外の環境のときだけDockerでビルドする設定です。既存プロジェクトからの移行では、plugins欄とpackage.jsonからプラグインを外し、設定ブロックはそのまま残します。
有料化後の無料OSS代替oslsの導入手順とv4系で変わった前提条件
v4の有料化を避けつつ、これまでどおりのserverless.ymlを無料で動かし続けたい場合の選択肢が、OSSフォークのosls(旧名oss-serverless)です。MITライセンスで、PHP用ランタイムBrefのメンテナーが中心となって維持しています。READMEに掲げる目標は「既存のサーバーレスプロジェクトの継続性確保」です。
2026年10月時点で押さえておきたいのは、oslsにも独自の「v4」系が出ている点です。npmのlatestタグは4.4.0(2026年9月25日公開)で、v3系はlegacyタグ(3.78.0)に移りました。本家Serverless Framework v4とは別物で、有料化もありません。osls v4の主な変更は次のとおりです。
- Serverless Dashboard・Enterprise・Console連携とServerless Components、Tencent Cloud対応を削除
- AWS SDK for JavaScript v3へ移行し、IAM Identity Centerの認証に対応
- Node.jsの要件を
^20.19.0または^22.13.0以上、もしくは24以上に引き上げ
# 本家を外してからoslsを入れる
npm uninstall -g serverless
npm install -g osls@4
osls --version
# v3系の挙動を固定したい既存案件ではlegacy版を指定
npm install -g osls@3
パッケージにはosls・serverless・slsの3つのコマンドが入っているため、既存のCIスクリプトのserverless deployはそのまま動きます。既存のv3プロジェクトを止めずに延命したいなら、まずosls@3で置き換えて動作を確認します。そのあとosls@4へ上げる2段階が安全です。逆に、本家v4のesbuild統合やserverless dev、Python依存の本体内蔵を使いたいなら本家v4を選ぶことになります。
osls・AWS SAM・CDK・Terraformと比べた料金と向く場面
有料化を機に、他のサーバーレス/IaCツールへ移る選択肢も現実的です。代表的な5つを料金と向く場面で並べます。
| ツール | 提供元 | 料金 | 向く場面 |
|---|---|---|---|
| Serverless Framework v4 | Serverless, Inc. | 年商200万ドル以下は無料 | 既存資産・豊富なプラグイン |
| osls | Bref関係者のOSS | 無料(MIT) | v3案件を無料で維持 |
| AWS SAM | AWS | 無料 | 純AWSのサーバーレス |
| AWS CDK | AWS | 無料 | アプリと同じ言語でIaC |
| Terraform | HashiCorp | CLIは無料 | マルチクラウド・既存資産 |
選び方はシンプルです。v4の課金だけが理由なら、まずoslsへの置き換えを検討します。新規にAWSだけで作るなら、AWS公式のSAM(CloudFormationの拡張でローカル実行にも対応)か、TypeScriptやPythonでインフラを書けるAWS CDKが有力です。SAMの使い方はAWS SAMの解説にまとめています。
複数クラウドをまたぐ場合や既存のTerraform資産がある場合はTerraformが向きます。ライセンス変更を避けたいならフォークのOpenTofuも選択肢です。Serverless Frameworkを積極的に選ぶ理由は、マルチプロバイダ時代から続くプラグインと既存資産にあります。純AWSの新規用途では、無料の公式ツールが優位というのが2026年時点の力関係です。
Serverless Frameworkを採用する条件と見送るべき場面の判断基準
受託開発でサーバーレス案件の構成を決めてきた立場から、判断を言い切ります。ツール選びで迷う時間は、デプロイ対象のスタック数と組織の年商でほぼ決着します。
本家v4を採用してよい条件は、年商200万ドル以下の組織であること、またはサービスインスタンス数が少なく月数十ドルの課金を許容できることです。esbuildの統合によりTypeScriptの設定が要らず、Pythonの依存同梱も本体だけで済みます。立ち上げの速さはSAMやCDKより上です。
oslsを選ぶ場面は、v3時代のserverless.ymlとプラグイン群を抱え、課金のためだけに書き換えたくない既存案件です。書き換えコストがゼロに近いため、延命策としては最も安く済みます。
見送る場面もはっきりしています。年商200万ドル超の組織で、PRごとのプレビュー環境を多数立てる運用ならクレジットが膨らみます。この条件で新規に採用するツールは、SAMかCDKが候補です。ネットワーク・データベース・コンテナまで含めた基盤全体を1つの道具で管理したい場合も、Lambda中心のServerless Frameworkは守備範囲が狭いので採用しません。Webアプリ自体をLambdaへ載せたい場合は、Lambda Web AdapterとSnapStartの実装条件も比較材料になります。
既存のv3資産の移行先選定や、Lambdaを含むAWS基盤の設計・構築を外部に任せたい場合は、一創のインフラ構築(AWS・Google Cloud・Azure)サービスでご相談いただけます。
よくある質問
Serverless Frameworkの料金・バージョン・代替ツールについて、検索の多い質問に答えます。
Serverless Frameworkは無料で使えますか?
v4では、直近会計年度の年商が200万ドル以下の組織であれば無料で使えます。超える組織は有料サブスクリプションが必要で、課金は1サービスインスタンス(service・stage・regionの組み合わせ)あたり月1クレジット、従量なら1クレジット4ドルです。判定は会社・団体単位の自己申告制で、無料の場合でもアカウント登録とCLIのサインインは求められます。条件は改定されることがあるため、契約前に公式の料金ページで最新を確認してください。
Serverless Framework v4とv3の主な違いは何ですか?
最大の違いは料金体系で、v4から年商200万ドル超の組織は有料になりました。技術面では、esbuildの本体統合によるTypeScriptの自動ビルド、CLI認証の必須化、.envの自動読み込み、Python依存同梱の本体内蔵、AWS以外のプロバイダ対応の終了が挙げられます。コマンド面では、プロジェクト作成が引数なしのserverlessに、AWS認証がserverless login awsに変わりました。v3は保守が終わっているため、本家を使うならv4が前提です。
oslsとは何ですか?v3とv4のどちらを入れるべきですか?
oslsは、本家の有料化を受けて公開されたServerless Framework v3系のオープンソースフォークです。MITライセンスで、Brefのメンテナーが脆弱性修正やランタイム対応を続けています。2026年10月時点のlatestはosls 4.4.0で、AWS SDK v3への移行やDashboard連携の削除が入り、Node.js 20.19以上が必要です。既存のv3案件はまずosls@3で置き換えて動作を確かめ、問題がなければosls@4へ上げる順序が安全です。
PythonでServerless Frameworkは使えますか?
使えます。対話メニューでPythonのテンプレートを選び、runtimeにpython3.13などサポート中の版を指定します。v4では依存ライブラリの同梱機能が本体に組み込まれ、serverless-python-requirementsプラグインは不要になりました。serverless.ymlにcustom.pythonRequirementsブロックを置けば有効になります。NumPyなどC拡張を含むライブラリはdockerizePip: non-linuxで、Lambda互換の環境でビルドするのが確実です。
Serverless FrameworkとAWS SAMはどちらを使うべきですか?
AWSだけで完結し、追加コストを避けたいならAWS SAMが有力です。SAMは無料で、CloudFormationの拡張としてLambdaやAPI Gatewayを簡潔に書け、ローカル実行にも対応します。一方、豊富なプラグインや既存のServerless Framework資産を活かしたい場合は本家v4かoslsを選ぶ価値があります。新規かつ純AWSならSAM、既存資産ありで年商条件内なら本家v4、課金を避けたい既存案件ならosls、という整理が実務的です。
関連記事
- AWS SAMとは?CloudFormationとの違い・CLIの使い方をわかりやすく解説:無料の公式代替を選ぶときの使い方
- AWS CDK(cdk)とは?仕組み・使い方とCloudFormation・Terraformとの違い:コードでIaCを書く場合の比較先
- AWS サーバーレス ハンズオン|Lambda・DynamoDB・API GatewayでREST APIを作る手順【2026年版】:サーバーレス構成の組み立て方
- サーバーレスアーキテクチャとは?構成パターン・AWS実装・採用判断を実装者目線で解説:上位概念と採用判断
- AWS Application Composerとは?Infrastructure Composerへの改称と使い方・料金を実装者目線で解説:サーバーレス構成を図で設計するツール