AWS Lambda Layer 2025年版 - Serverless Frameworkでの最新実装パターンとパフォーマンス最適化

最終更新日：2025年09月03日｜公開日：2025年09月03日

writer：益子竜与志

AWS Lambdaにおけるパッケージサイズの最適化は、2025年においても変わらず重要な課題です。コールドスタートの短縮、デプロイ時間の改善、そして何より顧客体験の向上に直結するこのトピックは、サーバーレスアーキテクチャを採用する全てのチームが向き合う必要があります。

本記事では、2025年8月時点の最新仕様に基づき、Serverless FrameworkとLambda Layerを活用したnode_modules共通化の実装方法を解説します。特に、これまで広く使われていたserverless-layersプラグインが2024年6月にアーカイブ化されたことを受け、新たなアプローチへの移行が急務となっています。Node.js 22のサポート開始、AWS SDK v3の扱い、そしてArm64アーキテクチャの活用など、最新のベストプラクティスを交えながら、実践的な実装方法をご紹介します。

AWS Lambda Layer 2025年版 - Serverless Frameworkでの最新実装パターンとパフォーマンス最適化

Lambda Layerの基本概念と2025年の現状

AWS Lambda Layerは、複数のLambda関数で共通利用するライブラリやカスタムランタイムを分離して管理する仕組みです。2025年現在でも、この基本的なコンセプトに変更はありませんが、実装方法や最適化のアプローチは大きく進化しています。

Lambda関数のパッケージサイズに関する制約は変わらず厳格です。ZIPデプロイの場合、アップロード時の最大サイズは50MB、展開後の関数本体と全Layer合算で最大250MBという制限があります。また、一つの関数に適用できるLayerは最大5個までという制約も健在です。

一方で、コンテナイメージを使用する場合は最大10GBまで利用可能になりましたが、Layerを直接アタッチすることはできません。この場合、Dockerfileのビルド段階で/optディレクトリに必要な依存関係を配置することで、Layer相当の機能を実現します。

ランタイムの進化とサポート状況

2025年8月現在、AWS LambdaはNode.js 22（AL2023）を正式サポートしています。Node.js 18は2025年9月1日に非推奨入りし、10月1日には新規作成がブロック、11月1日には既存関数の更新もブロックされる予定です。新規プロジェクトでは、Node.js 22または20を選択することを強く推奨します。

Node.js 18以降のランタイムでは、「HTTP Keep-Alive」がデフォルトで有効になっています。これにより、外部APIとの通信が多いアプリケーションでは、コネクション再利用によるレイテンシ改善が期待できます。また、「ESM（ECMAScript Modules）」と「Top-Level Await」のサポートにより、初期化処理の制御がより柔軟になり、コールドスタートの最適化に寄与します。

AWS SDK v3の扱い方

Node.jsランタイムには、AWS SDK for JavaScript v3の特定マイナーバージョンが同梱されています。リージョンやランタイムバージョンにより異なるため、厳密な互換性管理が必要な場合は、依存関係として明示的にパッケージに含めるか、Layerに同梱することを検討してください。

プロジェクトの方針として、ランタイム同梱版を使用するか、特定バージョンを固定するかを明確にすることが重要です。特に、複数の開発者が関わるプロジェクトや、長期的な保守を前提とする場合は、バージョン固定による予測可能性を優先することをお勧めします。

serverless-layersプラグインの終焉と移行戦略

これまで多くのプロジェクトで採用されていたserverless-layersプラグインは、2024年6月15日にリポジトリがアーカイブ化され、読み取り専用となりました。新規プロジェクトでの採用は避け、既存プロジェクトも計画的な移行が必要です。

代替として推奨されるのは、Serverless Frameworkのネイティブ Layers機能とserverless-esbuildプラグインの組み合わせです。この組み合わせにより、より柔軟で保守性の高い構成を実現できます。

移行のメリットとアプローチ

ネイティブLayers機能への移行には、以下のメリットがあります。

まず、プラグイン依存の削減により、将来的なメンテナンスリスクが軽減されます。Serverless Framework本体の機能を使用することで、フレームワークのアップデートと同期した機能改善や不具合修正の恩恵を受けられます。

次に、serverless-esbuildとの組み合わせにより、ツリーシェイキングやミニファイといった最適化が可能になります。これにより、関数本体のサイズを大幅に削減し、コールドスタートの改善に貢献します。

さらに、設定がより直感的になり、チーム内での理解共有が容易になります。独自のプラグイン仕様を覚える必要がなく、公式ドキュメントに基づいた実装が可能です。

2025年版の実装パターン

プロジェクト構成とディレクトリ設計

最新のベストプラクティスに基づいたプロジェクト構成を紹介します。以下のディレクトリ構造は、Layer管理とビルド成果物の分離を明確にし、保守性を高めます。

.
├─ layer/
│   └─ nodejs/
│       └─ node_modules/        # 共通依存パッケージを配置
├─ src/
│   ├─ handlers/
│   │   ├─ api/
│   │   └─ batch/
│   ├─ services/
│   └─ utils/
├─ dist/                         # ビルド成果物
├─ serverless.yml
├─ tsconfig.json
└─ package.json

Node.jsランタイムでは、nodejs/node_modulesというパス構造が必須です。さらに、Node.js 22を使用する場合はnodejs/node22/node_modulesというバージョン固有のパスも利用可能です。

serverless.ymlの詳細設定

以下は、2025年版の推奨設定例です。Node.js 22とArm64アーキテクチャを採用し、パフォーマンスとコスト効率の最適化を図っています。

service: modern-serverless-app

frameworkVersion: '4'

provider:
  name: aws
  runtime: nodejs22.x
  architecture: arm64  # Gravitonプロセッサによる価格性能向上
  region: ap-northeast-1
  stage: ${opt:stage, 'dev'}
  environment:
    NODE_ENV: ${self:provider.stage}
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: '1'  # Keep-Alive明示的有効化
  deploymentBucket:
    name: ${env:DEPLOYMENT_BUCKET, ''}
    serverSideEncryption: AES256
  versionFunctions: false  # 不要なバージョン作成を抑制

plugins:
  - serverless-esbuild
  - serverless-offline

package:
  individually: true
  patterns:
    - '!node_modules/**'     # 関数ZIPからnode_modulesを除外
    - '!layer/**'           # Layer本体を関数ZIPから除外
    - '!src/**'             # ソースコードを除外
    - 'dist/**'             # ビルド成果物のみ含める

custom:
  esbuild:
    bundle: true
    minify: true
    sourcemap: linked       # 本番環境でのデバッグ用
    target: 'node22'
    format: 'esm'           # ESM形式で出力
    platform: 'node'
    exclude: ['@aws-sdk/*'] # SDK v3はランタイム同梱版を使用
    watch:
      pattern: ['src/**/*.ts']
      ignore: ['**/*.test.ts']

layers:
  sharedDependencies:
    path: layer
    name: ${self:service}-${self:provider.stage}-shared-deps
    description: 'Shared dependencies for Lambda functions'
    compatibleRuntimes:
      - nodejs22.x
      - nodejs20.x
    retain: false  # スタック削除時にLayerも削除

functions:
  apiHandler:
    handler: dist/handlers/api/index.handler
    layers:
      - { Ref: SharedDependenciesLambdaLayer }
    events:
      - httpApi:
          path: /api/{proxy+}
          method: ANY
    memorySize: 1024  # Arm64での最適なメモリ設定
    timeout: 29
    environment:
      LOG_LEVEL: ${env:LOG_LEVEL, 'info'}

  batchProcessor:
    handler: dist/handlers/batch/processor.handler
    layers:
      - { Ref: SharedDependenciesLambdaLayer }
    events:
      - schedule:
          rate: rate(5 minutes)
          enabled: true
    memorySize: 2048
    timeout: 300

Layerの依存関係管理

Layer用の依存関係は、独立したpackage.jsonで管理することを推奨します。これにより、開発用の依存関係と本番用の依存関係を明確に分離できます。

// layer/nodejs/package.json
{
  "name": "lambda-shared-dependencies",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "axios": "^1.7.0",
    "date-fns": "^3.6.0",
    "lodash": "^4.17.21",
    "uuid": "^10.0.0"
  }
}

Layer用の依存関係をインストールする際は、以下のコマンドを実行します。

cd layer/nodejs
npm ci --production  # package-lock.jsonに基づく厳密なインストール
cd ../..

パフォーマンス最適化の実践

初期化処理の最適化

ESMとTop-Level Awaitを活用することで、Lambda関数の初期化処理を効率化できます。以下は、データベース接続やAWSサービスクライアントの初期化を最適化した例です。

// handlers/api/index.ts
import { APIGatewayProxyHandlerV2 } from 'aws-lambda';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient } from '@aws-sdk/lib-dynamodb';

// Top-Level Awaitで初期化を完了
const dynamoClient = new DynamoDBClient({
  region: process.env.AWS_REGION,
  maxAttempts: 3,
});

const docClient = DynamoDBDocumentClient.from(dynamoClient, {
  marshallOptions: {
    convertEmptyValues: true,
    removeUndefinedValues: true,
  },
});

// 設定の事前読み込み
const config = await loadConfiguration();

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  // ビジネスロジックの実装
  // 初期化は既に完了しているため、リクエスト処理に集中
  try {
    const result = await processRequest(event, docClient, config);
    return {
      statusCode: 200,
      body: JSON.stringify(result),
    };
  } catch (error) {
    console.error('Request processing failed:', error);
    return {
      statusCode: 500,
      body: JSON.stringify({ error: 'Internal server error' }),
    };
  }
};

async function loadConfiguration() {
  // 環境変数やParameter Storeからの設定読み込み
  return {
    apiEndpoint: process.env.API_ENDPOINT,
    cacheEnabled: process.env.CACHE_ENABLED === 'true',
  };
}

バンドルサイズの最適化戦略

serverless-esbuildを使用したバンドル最適化には、いくつかの重要な設定ポイントがあります。

まず、「external」設定により、ランタイムに含まれるパッケージをバンドルから除外します。AWS SDK v3はランタイムに同梱されているため、明示的に除外することでバンドルサイズを削減できます。

次に、「minify」オプションを有効にすることで、コードの圧縮とデッドコードの除去を行います。ただし、本番環境でのデバッグを考慮し、「sourcemap」も併せて設定することが重要です。

さらに、「treeshake」はデフォルトで有効になっており、使用されていないコードを自動的に除去します。これにより、大規模なライブラリを使用している場合でも、実際に使用される部分のみがバンドルに含まれます。

Arm64アーキテクチャの活用

AWS Gravitonプロセッサを使用するArm64アーキテクチャは、価格性能比で優位性があります。x86_64と比較して、約20%のコスト削減と、特定のワークロードでは最大34%のパフォーマンス向上が報告されています。

Arm64への移行を検討する際は、以下の点を確認してください。

使用しているネイティブ依存関係がArm64をサポートしているかを確認します。特に、画像処理ライブラリやデータベースドライバなど、C/C++で実装された拡張機能を使用している場合は注意が必要です。

Lambda拡張機能やカスタムランタイムを使用している場合、Arm64版が提供されているかを確認します。主要なAPMツールやモニタリングソリューションの多くは、既にArm64をサポートしています。

開発環境とのアーキテクチャ差異による問題を避けるため、Dockerを使用したローカル開発環境の構築を検討します。

移行時の注意事項と対策

既存プロジェクトからの移行手順

serverless-layersプラグインを使用している既存プロジェクトから、ネイティブLayers機能への移行は、慎重な計画と段階的な実施が必要です。

移行プロセスの第一段階として、現在の依存関係とLayerサイズを把握します。以下のコマンドで、現在のLayer構成を確認できます。

# 現在のLayerサイズを確認
aws lambda list-layers --region ap-northeast-1 | jq '.Layers[] | {LayerName, LatestMatchingVersion}'

# 特定のLayerの詳細を確認
aws lambda get-layer-version --layer-name <layer-name> --version-number <version> --region ap-northeast-1

第二段階では、新しい構成での動作検証を行います。開発環境で新しい設定をテストし、パフォーマンスやコスト面での改善を測定します。

第三段階として、段階的な本番環境への適用を行います。カナリアデプロイやブルー/グリーンデプロイを活用し、リスクを最小限に抑えながら移行を進めます。

250MB制限への対応策

Lambda関数とLayerの合計サイズが250MBを超える場合、いくつかの対策を検討する必要があります。

最も効果的な対策は、依存関係の見直しと最小化です。使用頻度の低いパッケージや、特定の機能でのみ使用されるパッケージは、動的インポートや条件付きロードを検討します。

// 条件付きロードの例
export async function processImage(imageData: Buffer) {
  if (process.env.IMAGE_PROCESSING_ENABLED === 'true') {
    // 必要な場合のみ重いライブラリをロード
    const sharp = await import('sharp');
    return sharp.default(imageData).resize(200, 200).toBuffer();
  }
  return imageData;
}

それでもサイズ制限に収まらない場合は、コンテナイメージを使用したデプロイを検討します。コンテナイメージは最大10GBまでサポートしており、大規模な依存関係を持つアプリケーションにも対応できます。

デプロイ時のトラブルシューティング

Layer適用時によく発生する問題とその解決方法をまとめます。

「ResourceConflictException」が発生する場合、既存のLayerバージョンとの競合が原因です。Layer名を変更するか、既存のLayerを削除してから再デプロイを実行します。

「InvalidParameterValueException」でLayerのパスが正しくないというエラーが出る場合、nodejs/node_modulesというディレクトリ構造が正しく作成されているか確認します。特に、手動でZIPファイルを作成している場合は、ディレクトリ階層に注意が必要です。

デプロイ後に「Runtime.ImportModuleError」が発生する場合、Layerに含まれるべきモジュールが正しくパッケージされていない可能性があります。Layer内のpackage.jsonと実際にインストールされたモジュールが一致しているか確認します。

コンテナイメージとの使い分け

コンテナイメージが適するケース

Lambda関数の実装において、コンテナイメージを選択すべきケースが明確に存在します。

機械学習モデルや画像処理ライブラリなど、大規模な依存関係を持つアプリケーションでは、250MBの制限を簡単に超えてしまいます。コンテナイメージなら10GBまで利用可能なため、こうした制約から解放されます。

また、既存のDockerベースのCI/CDパイプラインがある場合、コンテナイメージへの移行は比較的スムーズです。ビルド、テスト、デプロイのプロセスを大きく変更することなく、Lambda環境でも同じワークフローを維持できます。

ローカル開発環境との一貫性を重視する場合も、コンテナイメージが有効です。開発者のマシンと本番環境で完全に同一のイメージを使用できるため、「ローカルでは動くのに本番では動かない」という問題を防げます。

ハイブリッドアプローチの実装

プロジェクトの特性に応じて、ZIPデプロイとコンテナイメージを併用するハイブリッドアプローチも検討価値があります。

例えば、APIエンドポイントのような軽量な関数はZIPデプロイとLayerで実装し、バッチ処理や画像処理のような重い処理はコンテナイメージで実装するという使い分けが可能です。

# コンテナイメージの例（重い処理用）
FROM public.ecr.aws/lambda/nodejs:22

# 必要な依存関係を/optにコピー（Layer相当）
COPY layer/nodejs/node_modules /opt/nodejs/node_modules

# アプリケーションコードをコピー
COPY dist ${LAMBDA_TASK_ROOT}

# ネイティブ依存関係のインストール
RUN dnf install -y python3-pip && \\\\
    pip3 install --target /opt/python numpy pandas

ENV NODE_PATH=/opt/nodejs/node_modules:$NODE_PATH
ENV PYTHONPATH=/opt/python:$PYTHONPATH

CMD ["index.handler"]

モニタリングとパフォーマンス測定

CloudWatch Insightsを活用した分析

Lambda関数のパフォーマンスを継続的に改善するには、詳細なモニタリングが不可欠です。CloudWatch Logs Insightsを使用することで、Layer適用前後のパフォーマンス差を定量的に評価できます。

-- コールドスタート分析クエリ
fields @timestamp, @initDuration, @duration, @memorySize, @maxMemoryUsed
| filter @type = "REPORT"
| stats
    avg(@initDuration) as avg_init,
    avg(@duration) as avg_duration,
    max(@initDuration) as max_init,
    pct(@initDuration, 95) as p95_init
by bin(5m)

このクエリにより、初期化時間（コールドスタート）と実行時間の傾向を把握できます。Layer導入前後でこれらの指標を比較することで、改善効果を数値化できます。

X-Rayによる詳細トレース

AWS X-Rayを使用したトレースにより、関数内部の処理時間を詳細に分析できます。特に、Layer内のモジュール読み込み時間や、外部APIコールのレイテンシを可視化することで、ボトルネックを特定できます。

// X-Rayトレースの実装例
import { captureAWSv3Client } from 'aws-xray-sdk-core';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';

// AWS SDKクライアントをX-Rayでラップ
const dynamoClient = captureAWSv3Client(
  new DynamoDBClient({ region: process.env.AWS_REGION })
);

// カスタムセグメントの追加
import * as AWSXRay from 'aws-xray-sdk-core';

export const handler = async (event) => {
  const segment = AWSXRay.getSegment();
  const subsegment = segment.addNewSubsegment('CustomProcessing');

  try {
    // 処理の実行
    const result = await performBusinessLogic(event);
    subsegment.addAnnotation('processed_items', result.count);
    return result;
  } finally {
    subsegment.close();
  }
};

プロビジョンドコンカレンシーとの組み合わせ

厳密なレイテンシ要件への対応

金融取引やリアルタイムゲームなど、厳密なレイテンシ要件がある場合は、プロビジョンドコンカレンシーの活用を検討します。

プロビジョンドコンカレンシーを設定することで、指定した数の実行環境が常に初期化済みの状態で待機します。これにより、コールドスタートを完全に排除できますが、待機中も課金が発生するため、コスト効率を慎重に評価する必要があります。

# serverless.ymlでのプロビジョンドコンカレンシー設定
functions:
  criticalApi:
    handler: dist/handlers/critical.handler
    layers:
      - { Ref: SharedDependenciesLambdaLayer }
    provisionedConcurrency: 5  # 5つの実行環境を常時確保
    reservedConcurrency: 10    # 最大同時実行数を制限

プロビジョンドコンカレンシーとLayerを組み合わせる場合、初期化時間の短縮効果が相乗的に働きます。Layer化により関数本体が軽量化されているため、プロビジョニングされた環境の準備も高速に完了します。

Auto Scalingの設定

プロビジョンドコンカレンシーは、Application Auto Scalingと連携して動的に調整できます。時間帯やメトリクスに基づいて、プロビジョンドコンカレンシーの数を自動的に増減させることで、コストを最適化しながら性能要件を満たせます。

// CDKでのAuto Scaling設定例
import { ScalableTarget, ServiceNamespace } from '@aws-cdk/aws-applicationautoscaling';

const target = new ScalableTarget(this, 'ScalableTarget', {
  serviceNamespace: ServiceNamespace.LAMBDA,
  maxCapacity: 10,
  minCapacity: 2,
  resourceId: `function:${lambdaFunction.functionName}:provisioned`,
  scalableDimension: 'lambda:function:ProvisionedConcurrency',
});

target.scaleToTrackMetric('TargetTracking', {
  targetValue: 0.7,
  predefinedMetric: PredefinedMetric.LAMBDA_PROVISIONED_CONCURRENCY_UTILIZATION,
});

将来を見据えた設計指針

レスポンスストリーミングの活用

Lambda関数のレスポンスストリーミングは、大きなレスポンスを段階的にクライアントに送信できる機能です。Node.jsの管理ランタイムで利用可能で、Time to First Byte（TTFB）の改善に貢献します。

レスポンスストリーミングを使用する場合、Layerに含めるストリーミング処理用のライブラリを慎重に選定する必要があります。ストリーム処理に特化した軽量なライブラリを選ぶことで、全体的なパフォーマンスを向上させることができます。

// レスポンスストリーミングの実装例
import { streamifyResponse } from 'lambda-stream';
import { Readable } from 'stream';

export const handler = streamifyResponse(async (event, responseStream) => {
  const pipeline = new Readable({
    read() {
      // データを段階的に生成
      for (let i = 0; i < 1000; i++) {
        this.push(JSON.stringify({ index: i, data: generateData(i) }) + '\\\\n');
      }
      this.push(null); // ストリーム終了
    }
  });

  pipeline.pipe(responseStream);
  await responseStream.finished();
});

エッジコンピューティングへの展開

Lambda@EdgeやCloudFront Functionsなど、エッジロケーションで実行される関数では、さらに厳しいサイズ制限があります。Lambda@Edgeの場合、ビューワーリクエスト/レスポンスでは1MB、オリジンリクエスト/レスポンスでは50MBという制限があり、Layerのサポートも限定的です。

エッジ環境への展開を見据えた設計では、コア機能とエッジ機能を明確に分離し、エッジでは最小限の処理のみを行うアーキテクチャが推奨されます。

まとめ

2025年のAWS Lambda開発において、Layer活用とパッケージ最適化は引き続き重要なテーマです。serverless-layersプラグインのアーカイブ化を契機に、よりモダンで保守性の高いアプローチへの移行が求められています。

Serverless Frameworkのネイティブ Layers機能とserverless-esbuildの組み合わせは、現時点での最適解といえます。Node.js 22への移行、Arm64アーキテクチャの採用、ESMとTop-Level Awaitの活用など、最新の機能を積極的に取り入れることで、パフォーマンスとコスト効率の両立が可能になります。

一方で、プロジェクトの特性に応じた柔軟な選択も重要です。依存関係が大規模な場合はコンテナイメージ、厳密なレイテンシ要件がある場合はプロビジョンドコンカレンシーなど、適切な技術選択により、ビジネス要件を満たす最適なソリューションを構築できます。

継続的なモニタリングと改善、そして新機能への適応により、サーバーレスアーキテクチャの真の価値を引き出すことができるでしょう。技術の進化は速いですが、本質的な価値である「ビジネスロジックへの集中」と「運用負荷の軽減」を常に意識しながら、最適な実装を追求していくことが重要です。

この記事を書いた人

ソリューションアーキテクト益子竜与志

複数のITベンチャーで技術責任者／経営企画を歴任し、事業戦略とプロダクト成長を主導。2017年にRagate株式会社を創業し、サーバーレス技術の黎明期よりAWS・サーバーレス開発プロジェクトを牽引し、AWS Top Engineers 2024 ( Service ) ・AWS Rising Star Partners of the Year – Japan賞を受賞。経営課題/戦略を起点としたDX戦略策定とクラウドシステムデリバリを強みに、SMB市場を中心に数多くの企業変革を支援。GLOBIS経営大学院MBAで培った経営戦略・マーケティングミックスの知見と、AWS／先端技術の深い専門性を掛け合わせ、価値創出を加速させている。

【保有資格・認定】