# Lambda がランタイムバージョンの更新を管理する方法を理解する
Lambda は、セキュリティ更新、バグ修正、新機能、パフォーマンス強化、およびマイナーバージョンリリースのサポートを使用して、各マネージドランタイムを最新の状態に保ちます。これらのランタイム更新は、ランタイムバージョンとして発行されます Lambda は、関数を以前のランタイムバージョンから新しいランタイムバージョンに移行することによって、ランタイム更新を関数に適用します。
マネージドランタイムを使用する関数の場合、Lambda はデフォルトでランタイム更新を自動的に適用します。自動ランタイム更新により、Lambda はランタイムバージョンにパッチを適用する運用上の負担を取り除きます。大抵のお客様には、自動更新が最適な選択肢です。このデフォルトの動作は、[ランタイム管理設定を構成](runtime-management-configure-settings.md)することで変更できます。
Lambda は、新しい各ランタイムバージョンのコンテナイメージとしての発行も行います。コンテナベースの関数のランタイムバージョンを更新するには、更新されたベースイメージから[新しいコンテナイメージを作成](images-create.md)して、関数を再デプロイする必要があります。
各ランタイムバージョンには、バージョン番号と ARN (Amazon リソースネーム) が関連付けられています。ランタイムのバージョン番号は Lambda が定義する番号付けスキームを使用しており、これはプログラミング言語が使用するバージョン番号とは無関係の番号です。ランタイムバージョン番号は常に連続しているとは限りません。例えば、バージョン 42 の後にバージョン 45 が続く場合があります。ランタイムバージョンの ARN は、各ランタイムバージョンの一意の識別子です。関数の現在のランタイムバージョンの ARN は、または[関数ログの `INIT_START` 行](runtime-management-identify.md)で確認できます。
ランタイムバージョンとランタイム識別子は、それぞれ別個に考える必要があります。各ランタイムには、`python3.14` や `nodejs24.x` などの一意の**ランタイム識別子**があります。これらは主要プログラミング言語の各リリースに対応しています。ランタイムバージョンは、個々のランタイムのパッチバージョンを表しています。
**注記**
同じランタイムバージョン番号の ARN は、AWS リージョンと CPU アーキテクチャによって異なる場合があります。
**Topics**
+ [下位互換性](#runtime-update-compatibility)
+ [ランタイム更新モード](#runtime-management-controls)
+ [2 フェーズのランタイムバージョンロールアウト](#runtime-management-two-phase)
+ [Lambda ランタイム管理設定](runtime-management-configure-settings.md)
+ [Lambda ランタイムバージョンのロールバック](runtime-management-rollback.md)
+ [Lambda ランタイムバージョン変更の特定](runtime-management-identify.md)
+ [Lambda ランタイム管理における責任共有モデルを理解する](runtime-management-shared.md)
+ [高コンプライアンスアプリケーションの Lambda ランタイム更新アクセス許可の制御](runtime-management-hc-applications.md)
## 下位互換性
Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。例えば、セキュリティパッチは、以前のセキュアではない動作に依存する既存の関数に関する内在的な問題を明らかにする可能性があります。
関数を構築してデプロイするときは、今後のランタイム更新との潜在的な非互換性を回避するために、依存関係を管理する方法を理解することが重要です。例えば、関数がパッケージ A に依存していて、パッケージ A がパッケージ B に依存しているとします。両方のパッケージは Lambda ランタイムに含まれています (例えば、SDK またはその依存関係の一部、またはランタイムシステムライブラリの一部である可能性があります）。
次のシナリオを考えてみてください。
| デプロイ | パッチ互換性 | Reason |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい | パッケージ A と B の今後のランタイム更新では、下位互換性を維持します。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい | デプロイが優先されるため、パッケージ A と B の今後のランタイム更新は影響を与えません。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい\$1 | パッケージ B の今後のランタイム更新には下位互換性があります。 \$1A と B が緊密に結合されている場合、互換性の問題が発生する可能性があります。例えば、 AWS SDK for Python の `boto3` パッケージと`botocore` パッケージは一緒にデプロイする必要があります。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | 不可 | パッケージ A の今後のランタイム更新では、パッケージ B の更新バージョンが必要になる場合があります。ただし、デプロイ済のパッケージ B のバージョンが優先され、パッケージ A の更新バージョンとの前方互換性がない場合があります。 |
今後のランタイム更新との互換性を維持するには、次のベストプラクティスに従ってください。
+ **可能であれば、すべての依存関係をパッケージ化します。**AWS SDK とその依存関係を含む、必要なすべてのライブラリをデプロイパッケージに含めます。これにより、安定した互換性のあるコンポーネント一式が保証されます。
+ **ランタイム提供 SDK を控えめに使用する：** 追加のパッケージを含めることができない場合にのみ、ランタイム提供の SDK を使用します (例えば、Lambda コンソールコードエディタまたはインラインコードを AWS CloudFormation テンプレートで使用する場合）。
+ **システムライブラリを上書きしない：** 今後のランタイム更新と競合する可能性のあるカスタムオペレーティングシステムライブラリをデプロイしないでください。
## ランタイム更新モード
Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。例えば、セキュリティパッチは、以前のセキュアではない動作に依存する既存の関数に関する内在的な問題を明らかにする可能性があります。Lambda ランタイム管理コントロールは、ランタイムバージョンの非互換性というまれな状況で、ワークロードに影響が及ぶリスクを軽減するために役立ちます。[関数バージョン](configuration-versions.md) (`$LATEST` または発行済みバージョン) ごとに、以下のランタイム更新モードのいずれかを選択できます。
+ **自動 (デフォルト)** – [2 フェーズのランタイムバージョンロールアウト](#runtime-management-two-phase) を使用して、最新のセキュアなランタイムバージョンに自動的に更新します。ランタイム更新のメリットを常に得るためにも、これは大半のお客様に推奨されるモードです。
+ **関数の更新** – 関数を更新するときに、最新の安全なランタイムバージョンに更新します。関数が更新されると、Lambda が関数のランタイムを最新のセキュアなランタイムバージョンに更新します。このアプローチは、ランタイム更新を関数デプロイと同期させることから、Lambda がランタイム更新を適用するタイミングを制御できます。このモードを使用することで、まれに発生するランタイム更新の非互換性を早期に検出して緩和することができます。このモードを使用するときは、関数を定期的に更新して、それらのランタイムを最新の状態に保つ必要があります。
+ **手動** – ランタイムバージョンを手動で更新します。関数設定でランタイムバージョンを指定します。関数は、このランタイムバージョンを恒久的に使用します。新しいランタイムバージョンに既存の関数との互換性がないというまれな状況でも、このモードを使用して、関数を以前のランタイムバージョンにロールバックすることができます。デプロイ間でのランタイムの整合性を実現するためにも、**[Manual]** (手動) モードは使用しないことをお勧めします。詳細については、「[Lambda ランタイムバージョンのロールバック](runtime-management-rollback.md)」を参照してください。
ランタイム更新を関数に適用する責任は、選択するランタイム更新モードに応じて異なります。詳細については、「[Lambda ランタイム管理における責任共有モデルを理解する](runtime-management-shared.md)」を参照してください。
## 2 フェーズのランタイムバージョンロールアウト
Lambda は、次の順序で新しいランタイムバージョンを導入します。
1. 第 1 フェーズでは、関数が作成または更新されるたびに Lambda が新しいランタイムバージョンを適用します。関数は、[UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) または [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 操作が呼び出されるときに更新されます。
1. 第 2 フェーズでは、**[Auto]** (自動) ランタイム更新モードを使用する関数で、まだ新しいランタイムバージョンに更新されていない関数を Lambda が更新します。
このロールアウトプロセスの全体的な所要時間は、ランタイム更新に含まれるセキュリティパッチの重大度などの複数の要因に応じて異なります。
関数の開発とデプロイを積極的に行っている場合は、第 1 フェーズ中に新しいランタイムバージョンを取得する可能性が高くなります。これは、ランタイム更新を関数の更新に同期します。最新のランタイムバージョンがアプリケーションに悪影響を及ぼすというまれな状況でも、このアプローチによって迅速に是正措置を講じることができます。積極的な開発が行われていない関数でも、第 2 フェーズ中の自動ランタイム更新による運用上のメリットが得られます。
このアプローチは、**[Function update]** (関数の更新) または **[Manual]** (手動) モードに設定された関数には影響しません。**[Function update]** (関数の更新) モードを使用する関数が最新のランタイム更新を受け取るのは、それらの作成時または更新時のみです。**[Manual** (手動) モードを使用する関数は、ランタイム更新を受け取りません。
Lambda は、新しいランタイムバージョンを段階的なローリング形式で AWS リージョン全体に発行します。関数が **[Auto]** (自動) または **[Function update]** (関数の更新) モードに設定されている場合、異なるリージョンに同時にデプロイされた関数、または同じリージョン内で異なる時間にデプロイされた関数が、異なるランタイムバージョンを取得する可能性があります。環境全体でランタイムバージョンの整合性を確保する必要があるお客様は、[コンテナイメージを使用して Lambda 関数をデプロイ](images-create.md)する必要があります。**[手動]** モードは、ランタイムバージョンが関数と互換性がないというまれなイベントで、ランタイムバージョンのロールバックを可能にするための一時的な緩和策として設計されています。