AWS LambdaでGemini APIを導入しようとした際、デプロイ後の実行時にライブラリの読み込みエラーでハマったので、同じ悩みを持つエンジニアのために備忘録として解決法を残します。
この記事でわかること
- Gemini API（google-generativeai）使用時に「GLIBC_2.28 not found」が出る原因
- AWS Lambda実行環境とビルド環境のバイナリ互換性の重要性
- AWS SAMのコンテナビルド機能を用いた確実な解決手順
[現象] デプロイ後に発生するRuntime.ImportModuleError
Python 3.11や3.12のランタイムを選択し、ローカルやGitHub Actionsで pip install -t . google-generativeai を実行してデプロイしたところ、実行時に以下のエラーが発生しました。
Runtime.ImportModuleError: Unable to import module 'lambda_function':
/lib64/libc.so.6: version 'GLIBC_2.28' not found (required by
/var/task/pydantic_core/_pydantic_core.cpython-312-x86_64-linux-gnu.so)[環境]
- Runtime: Python 3.11 / 3.12
- Architecture: x86_64
- Library: google-generativeai
- Build OS: Ubuntu (GitHub Actions) or macOS
[原因] バイナリ互換性とGLIBCの不一致
google-generativeai が依存している pydantic-core などのライブラリは、パフォーマンス向上のためにC言語で記述されたバイナリモジュール（.soファイル）を含んでいます。
GitHub Actionsの ubuntu-latest や最新のローカルLinux環境でビルドを行うと、その環境に含まれる新しいバージョンの GLIBC（2.28以上など） を参照してリンクされます。しかし、AWS Lambdaの実行環境（Amazon Linux 2023など）が提供するGLIBCはそれよりも古い ため、実行時に「指定されたバージョンのGLIBCが見つからない」というエラーが発生します。
[解決策] Lambda実行環境と同じコンテナでビルドする
この問題を回避するには、ビルド環境と実行環境のOS・ライブラリ構成を完全に一致させる必要があります。最も確実な方法は、AWSが提供するLambdaビルド用コンテナイメージを使用することです。
方法1：AWS SAMを使用する場合（推奨）
AWS SAMを使用している場合は、sam build コマンドに --use-container オプションを付与するだけで解決します。これにより、背後でAmazon Linuxベースのコンテナが立ち上がり、正しい環境でビルドが実行されます。
# Lambda実行環境と同じ環境でライブラリをビルド
sam build --use-container方法2：Dockerで直接ビルドする場合
SAMを使わずにZIPデプロイパッケージを作成する場合は、以下のようにAmazon ECRの公開イメージを使用してビルドします。
# Python 3.12の場合の例
docker run --rm -v $(pwd):/var/task public.ecr.aws/sam/build-python3.12 \
pip install -r requirements.txt -t .| ビルド手法 | GLIBCエラー | 特徴 |
|---|---|---|
| ローカル/GitHub Actions | 発生しやすい | 実行環境との差異を吸収できない |
| SAM (–use-container) | 発生しない | 推奨。最も手軽で安全 |
| Amazon Linuxイメージ | 発生しない | CI/CDに組み込む際に柔軟性が高い |
[まとめ]
Pythonの最新ランタイムで Gemini API などの重厚なライブラリを扱う場合、バイナリの互換性問題は避けられません。GLIBC_2.28 not found が出たら、慌てずに「ビルド環境をLambdaに合わせる」ことを意識しましょう。AWS SAMのコンテナビルドを活用するのが、開発効率と安定性の両面でベストプラクティスです。
